From pthubert@cisco.com Fri Mar 1 00:24:47 2013 Return-Path: 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 F1FE821E8041 for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 00:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.68 X-Spam-Level: X-Spam-Status: No, score=-9.68 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O1YwAt8cITD for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 00:24:46 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 378DB21E8040 for <6tsch@ietf.org>; Fri, 1 Mar 2013 00:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4062; q=dns/txt; s=iport; t=1362126286; x=1363335886; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UsGTYRdUHC0aj70eAUp5VegdtwvkBhmsvoPFTnrUHQc=; b=KqE2kHYkbFz8L2GrNM/yLEqC6D0ileWQ9hdKH7U04bfH1rbmV6K9+jtn ovl/u3bUHb3JduuIf5KX1+J0LDloJ5bCWUZuDLv4iUiCkUQNz2Y7XBaRV Ny7lOPafjaxXFtlsg83H4mICadU0TWxo2shhZp9jeQJnwsm2u5ZDXVEyl k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAP9kMFGtJV2d/2dsb2JhbABEDsInfhZzgh8BAQEDAQEBAWsLBQcEAgEIEQQBAQsdBycLFAkIAgQBDQUIiAUGDMEMBI5jJgsHBoJZYQOINZ55gkk/gWkkGg X-IronPort-AV: E=Sophos;i="4.84,760,1355097600"; d="scan'208";a="182556084" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 01 Mar 2013 08:24:45 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r218OjV0001638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Mar 2013 08:24:45 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 1 Mar 2013 02:24:45 -0600 From: "Pascal Thubert (pthubert)" To: Qin Wang , Alfredo Grieco Thread-Topic: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH Thread-Index: AQHOFeL2OUoo6lZbLE+/zj7QsF5tkJiQfeMQ Date: Fri, 1 Mar 2013 08:24:45 +0000 Deferred-Delivery: Fri, 1 Mar 2013 08:24:00 +0000 Message-ID: References: <512C36F4.4000409@eecs.berkeley.edu> <512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.98.64] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "6tsch@ietf.org" <6tsch@ietf.org>, 'Xavier Vilajosana' Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 08:24:47 -0000 I agree Qin, Fact is, we need a name for what you call a logical channel. A name that is= not already overloaded 4 times. I'd suggest something like a bundle. A bundle would be an aggregation of time slots of equal properties. A link = (what IPv6 sees) becomes a set of bundles. Depending on priority, flow, mul= ticast etc... when IP pushes a pack to a link, 6TUS will have to find which= bundle within a link maps the criteria for that packet. The question becomes what (opaque) info the IP layer needs to pass to 6TUS.= And whether that information comes all form the packet or if for instance = the incoming bundle for a packet is already informative enough. On the side: - the physical size of a bundle can be dynamic as you suggested earlier, un= less we are talking to hard reservation. - but then we have to define a fallback bundle for an dynamic bundle that i= s temporarily overflowing. Cheers, Pascal -----Original Message----- From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Q= in Wang Sent: jeudi 28 f=E9vrier 2013 19:40 To: Alfredo Grieco Cc: 6tsch@ietf.org; 'Xavier Vilajosana' Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH Hi Alfredo, When you say "primary broadcast channel", you mean a physical or logical ch= annel, for example one of the 16 channels in 2.4GHz band, or a set of links= among neighbors? I think using a set of links as broadcast channel, instead of a fixed physi= cal or logic channel, is more flexible and bandwidth efficient. How do you = think? Qin > Hi Xavi and all, > > Sorry for the delayed reply. > > I agree that I broadcast channel is required. I was wondering that if=20 > we set up a broadcast channel, its bandwidth should scale with the=20 > size of the network. The more node the more the signaling to be sent=20 > in broadcast. > > Should we imagine a primary broadcast channel that convey also the=20 > information to signal the presence of further additional broadcast=20 > channels ? > > Cheers > > Alfredo > > -----Messaggio originale----- > Da: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] Per conto=20 > di Xavier Vilajosana > Inviato: Tuesday, February 26, 2013 5:16 AM > A: 6tsch@ietf.org > Oggetto: [6tsch] DIOs/DAOs and broadcast channels on TSCH > > Hi, > > I have a question that i want to discuss, the question is whether we=20 > need a broadcast channel in TSCH or not and what kind of support 6tus=20 > should provide. (the answer can be depends... but lets see some cases) > > a) ADV need broadcast channels in case they are used to synchronize=20 > the network. IEEE 802.15.4e provides the timekeeping flag to set that=20 > channels as used for synchronization and shared flag can make them broadc= ast. > b) Those networks that do not need ADV for synchronization then can=20 > use any TX link for ADV, this means that if it is not shared only the=20 > node listening on that link will get the ADV. However as this=20 > periodically occurs the ADV might eventually be listened in all=20 > channels. > c)Some DAOs and all DIOs require a broadcast channel. Should the=20 > schedule provide that? in case of a), can the same link be used? How=20 > this link should be installed in the nodes? > d)Is the scheduler of the network who should setup a broadcast channel=20 > independent of the broadcast channel set for ADV? can it be the same?=20 > Or in contrast, 6tus can configure the EB so it indicates a broadcast=20 > channel.. > e).. > > I would like to know what is your opinion on that. > > cheers! > Xavi > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch From pthubert@cisco.com Fri Mar 1 06:58:26 2013 Return-Path: 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 A146311E80AD; Fri, 1 Mar 2013 06:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aki9fNP86e-f; Fri, 1 Mar 2013 06:58:20 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B793421F9269; Fri, 1 Mar 2013 06:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8663; q=dns/txt; s=iport; t=1362149900; x=1363359500; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=khM1j521TtGgKW8Vb7S0/pvRydjSkP8GOwHDmAze77w=; b=hXxAonT/QQ9PXx3kUdAL29OuTOdtRl9cjk3wWT9a6N8I6tPsLAGvGtc4 O3f4g7FA5/2JZ3Q5u2hwCYGBQhGWcoxcnUKFcL3dwW3f9Gz2+kz5ONEF9 RVyocP0YJfuiEqteLtt3uswhabdvXBC2ytF9u1Z61IMz2A0PFjTXDgMAN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABzBMFGtJV2Z/2dsb2JhbABEwjN8FnOCHwEBAQMBOj8FCwIBCCICEhAyJQIEAQkEDQGIBAYMwQqHEYYygSAxB4JfYQOTApQsgwiBcjU X-IronPort-AV: E=Sophos;i="4.84,761,1355097600"; d="scan'208";a="182669861" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 01 Mar 2013 14:58:17 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r21EwHP0030923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Mar 2013 14:58:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Fri, 1 Mar 2013 08:58:17 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "roll@ietf.org" , "Tom Phinney (tom.phinney@COX.NET)" Thread-Topic: [Roll] comments on draft-phinney-roll-rpl-industrial-applicability Thread-Index: AQHOFeOzAFgeSP3LvEeUZPv2g83+c5iQtCMA Date: Fri, 1 Mar 2013 14:58:16 +0000 Deferred-Delivery: Fri, 1 Mar 2013 14:58:00 +0000 Message-ID: References: <20381.1362077015@sandelman.ca> In-Reply-To: <20381.1362077015@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.98.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "6tsch@ietf.org" <6tsch@ietf.org>, "draft-phinney-roll-rpl-industrial-applicability@tools.ietf.org" Subject: Re: [6tsch] [Roll] comments on draft-phinney-roll-rpl-industrial-applicability 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 14:58:27 -0000 Dear Michael: [Pascal] Thanks for the comments : ) {this email was written in several sittings over 10 days. Probably I missed= some stuff} Section 1.3 says: 1.3. Out of scope requirements This applicability statement does not address requirements related to wireless LLNs employed in factory automation and related applications. So, as I understand things, this document applies to *plants*, but not automated factories. Forgive me for my ignorance, but I guess this means it applies to a oil refinery or chemical plant, but not to a car manu= facturer. (Even though, we call them "auto plants") I'm just trying to understand where the line is and why. [Pascal] You are correct. The industry makes a difference between Factory A= utomation (discrete manufacturing of individual products) and Process Contr= ols (continuous production). These are really 2 different activities, and F= actory Automation may require much stricter behaviors for very rapid operat= ions. At ISA, WG 11 has standardized ISA100.11a for Process Control, and the info= rmation you find in the draft leverages that experience. WG16 has been work= ing on Factory Automation. =3D=3D=3D=3D >The domain of applicability for the RPL protocol may include all > phases but the Normal Operation phase, where the bandwidth allocation > and the routes are usually optimized by an external Path Computing > Engine (PCE), e.g. an ISA100.11a System Manager. So, RPL could be used during phases P1, P2, P4, P5 and P6, but not during P= 3, (Normal Operation), unless a new OF was defined that interacted with the= PCE? [Pascal] Roughly yes, and this is the work we are starting at 6TSCH. In mor= e details, there will be flows that can use distributed routing but critica= l flows will need the PCE. (Last time I read the document, I was sure it said that LLNs could be used = only during P3) Given that, I guess the "X" in figure 1 means that RPL *can* be used? section 2.1.2 then says: For factory automation networks, the basic communications cycle for control is typically much faster, on the order of 100 Hz or more. but, I thought factory automation was out of scope? [Pascal] Yes, still this is good info.=20 =3D=3D=3D=3D=3D section 2.1.3: I think that I'm confused about Source-Sink(SS) vs Peer-to-multipeer(P2MP) = given that 2.1.3 says that the sink is usually a multicast address. Is the distinction that in P2MP multiple packets are unicast? Or is the distinction that P2MP is primary from outside the LLN, downward i= nto the LLN, while SS is within the LLN? [Pascal] let me quote Tom here: " There are three distinct paradigms used for the bulk of industrial automat= ion and control communication: 1) publish/subscribe, where an association exists between one source and on= e or a few recipients, all of which are identifiable, where publication is = periodic within strict time limits (though sometimes instances are suppress= ed due to source compression of the stream). When pub/sub is used for close= d-loop control, it is subject to timing attacks where deliberately induced = message delivery jitter can destabilize a control loop. Sequentiality and n= on-loss are insufficient to detect this; it must be based on source time st= amping , such as transport time-of-origination time stamping, that is check= ed at the receiver, or the equivalent, to discard anything that is not rece= ived within the proper cycle. In essence there is a fixed-acceptable-delay = pipeline between the publisher and the subscriber, generally with a transit= delay less than twice the publication period. COAP does not appear to be s= uitable for this communication paradigm without additional augmentation. 2) source/sink, where any of a number of sources logically multicasts (howe= ver that is implemented) to a predefined group address for the sinks, where= the membership in that group is time-varying and unknown to the sources. T= ransport time-of-origination time stamps here are used for message authenti= cation and perhaps in conjunction with source compression of related-interv= al time stamps in the application messaging. Arrival order and timing is of= relatively little interest here, as is message loss detection (except for = whatever impact that latter might have on security alerting).=20 3) client/server or peer/peer, where all of the traditional properties hold= and the specialized ones listed above generally do not. " My understanding is that this is more an upper layer paradigm then a routin= g issue. Pub/sub relates to periodic data that can be buffered to be read a= synchronously, like the periodic publication of a measurement. Tom? =3D=3D=3D=3D=3D=3D Or is it that the source is always on the LLN, and the sink is always elsew= here, and the fact that it's a multicast/anycast destination is just a ques= tion of how to implement redundancy in the data collection systems?=20 [Pascal] Not just redundancy. You might have a copy for a local actuator an= d a copy for a supervisory system, a log... page 13, section 2.1.4: says:=20 With rare exception, the control algorithms used with PS messaging in the process automation industries - those managing continuous material flows - rely on fixed-period sampling, computation and transfer of outputs, while those in the factory automation industries - those managing discrete manufacturing operations - rely on bounded delay between sampling of inputs, control computation and transfer of outputs to physical actuators that affect the controlled process. it seems that there are possibly two completely different industrial requir= ements here which can not, and should not, be satisfied with a single DAG. = Are two documents appropriate here? [Pascal] It is more than a different DAG, it is a different plant... I read= your question as do we want an additional draft for factory automation?=20 =3D=3D=3D=3D=3D > Note: Although there are known patent applications for duocast and > N-cast, at the time of this writing the patent assignee, Honeywell > International, has offered to permit cost-free RAND use in those > industrial wireless standards that have chosen to employee the > technology, under a reciprocal licensing requirement relative to that > use. =20 Can we get an official IPR statement via: http://www.ietf.org/ipr/file-disclosure on this? I don't think it is particularly relevant to the document, but pe= rhaps I could be wrong. you need to update [I-D.ietf-roll-rpl] to RFC6550. [Pascal] Done in 03 : ) 4.3.1 says: > Because the actual link capacity depends on the particular link=20 > technology used within an industrial automation network deployment,=20 > the Trickle parameters are specified in terms of the link's maximum=20 > capacity for conveying link-local multicast messages. If the link can=20 > convey m link-local multicast packets per second on average, the=20 > expected time it takes to transmit a link-local multicast packet is=20 > 1/m seconds. I am pleased that a formula is being provided, but I am uncomfortable that = this document is not more specific to actual link technology used. Can this document pick 1-2 actual link technologies and deal with them? [Pascal] We are working on those concepts at 6TSCH, ccing the ML. =3D=3D=3D=3D=3D=3D=3D=3D 5.: > The possibility of dynamically updating the metrics in use in the > network as well as the frequency of network updates allows deployment > characteristics (e.g., network density) to be discovered during > network bring-up and to be used to tailor network parameters once the > network is operational rather than having to rely on precise pre- > configuration. This also allows the network parameters and the > overall routing protocol behavior to evolve during the lifetime of > the network. I don't know how this discovery is going to occur. Someone trying to build a sensor that is going to satisfy an RFP for device= s to work in a network envisioned by this document needs to know what to include in their code base. As the code space is very finite, they need to know exactly what is important here. [Pascal] Finding the values for parameters is more of a deployment issue, s= o I read your question as 'which parameters are critical for the device to = operate in industrial environment and which range for those parameters'. Ag= ain, work at 6TSCH may help. Cheers, Pascal From qinwang@berkeley.edu Fri Mar 1 08:54:08 2013 Return-Path: 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 4033521E80CA for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 08:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4bEXDFtTQL0 for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 08:54:07 -0800 (PST) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0F94C21E80CC for <6tsch@ietf.org>; Fri, 1 Mar 2013 08:54:07 -0800 (PST) Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UBTDc-00049U-4r; Fri, 01 Mar 2013 08:54:01 -0800 Received: from 136.152.36.142 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 1 Mar 2013 08:54:00 -0800 Message-ID: <4b8fab46a18b44f897b740a9b9bcd7bf.squirrel@calmail.berkeley.edu> In-Reply-To: References: <512C36F4.4000409@eecs.berkeley.edu> <512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com> Date: Fri, 1 Mar 2013 08:54:00 -0800 From: "Qin Wang" To: "Pascal Thubert (pthubert)" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "6tsch@ietf.org" <6tsch@ietf.org>, Alfredo Grieco , 'Xavier Vilajosana' , Qin Wang Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:54:08 -0000 Pascal, Thank you for your comments. Very good point. Right now, I have not very good answer for it. But I think it should be answered in the 6tus draft. Qin > I agree Qin, > > Fact is, we need a name for what you call a logical channel. A name that > is not already overloaded 4 times. I'd suggest something like a bundle. > > A bundle would be an aggregation of time slots of equal properties. A link > (what IPv6 sees) becomes a set of bundles. Depending on priority, flow, > multicast etc... when IP pushes a pack to a link, 6TUS will have to find > which bundle within a link maps the criteria for that packet. > > The question becomes what (opaque) info the IP layer needs to pass to > 6TUS. And whether that information comes all form the packet or if for > instance the incoming bundle for a packet is already informative enough. > > On the side: > - the physical size of a bundle can be dynamic as you suggested earlier, > unless we are talking to hard reservation. > - but then we have to define a fallback bundle for an dynamic bundle that > is temporarily overflowing. > > Cheers, > > Pascal > > -----Original Message----- > From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of > Qin Wang > Sent: jeudi 28 février 2013 19:40 > To: Alfredo Grieco > Cc: 6tsch@ietf.org; 'Xavier Vilajosana' > Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH > > Hi Alfredo, > > When you say "primary broadcast channel", you mean a physical or logical > channel, for example one of the 16 channels in 2.4GHz band, or a set of > links among neighbors? > > I think using a set of links as broadcast channel, instead of a fixed > physical or logic channel, is more flexible and bandwidth efficient. How > do you think? > > Qin > > >> Hi Xavi and all, >> >> Sorry for the delayed reply. >> >> I agree that I broadcast channel is required. I was wondering that if >> we set up a broadcast channel, its bandwidth should scale with the >> size of the network. The more node the more the signaling to be sent >> in broadcast. >> >> Should we imagine a primary broadcast channel that convey also the >> information to signal the presence of further additional broadcast >> channels ? >> >> Cheers >> >> Alfredo >> >> -----Messaggio originale----- >> Da: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] Per conto >> di Xavier Vilajosana >> Inviato: Tuesday, February 26, 2013 5:16 AM >> A: 6tsch@ietf.org >> Oggetto: [6tsch] DIOs/DAOs and broadcast channels on TSCH >> >> Hi, >> >> I have a question that i want to discuss, the question is whether we >> need a broadcast channel in TSCH or not and what kind of support 6tus >> should provide. (the answer can be depends... but lets see some cases) >> >> a) ADV need broadcast channels in case they are used to synchronize >> the network. IEEE 802.15.4e provides the timekeeping flag to set that >> channels as used for synchronization and shared flag can make them >> broadcast. >> b) Those networks that do not need ADV for synchronization then can >> use any TX link for ADV, this means that if it is not shared only the >> node listening on that link will get the ADV. However as this >> periodically occurs the ADV might eventually be listened in all >> channels. >> c)Some DAOs and all DIOs require a broadcast channel. Should the >> schedule provide that? in case of a), can the same link be used? How >> this link should be installed in the nodes? >> d)Is the scheduler of the network who should setup a broadcast channel >> independent of the broadcast channel set for ADV? can it be the same? >> Or in contrast, 6tus can configure the EB so it indicates a broadcast >> channel.. >> e).. >> >> I would like to know what is your opinion on that. >> >> cheers! >> Xavi >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > From twatteyne@gmail.com Fri Mar 1 08:57:01 2013 Return-Path: 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 0393F21F93A6 for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 08:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpsIbQhqV08n for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 08:57:00 -0800 (PST) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1163021F91FD for <6tsch@ietf.org>; Fri, 1 Mar 2013 08:57:00 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id wy12so1834140pbc.21 for <6tsch@ietf.org>; Fri, 01 Mar 2013 08:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=KV4nhS8+qnu+UFaSSy5MxsbyoOpNAGq2OTsZhBqHYpM=; b=d5kwugKW9H9IVpPRB9S85gUWWJokxulLrOolJBSbNSlY01Owm21r07CqndIpc/TFb3 frhAXbTfcPpGqnlxyI3TpDGNNyFrjK1/q+J8oOui0fBr/M41fr9r5+5zjwOh9Ed+wfFJ 8XUbEEYBydtT3OSddGgnQuGKJiMnMacDpefzYvoiCuIiAa80kOiaR6NdgvzKfVFFJIFk lk32mjS8+9F5ejcCmokOYj9VWQtu680nJJqgix5BL5kl/9KfiNdwYauE9xvEmrmzcMZs TVlXlNQs7T+n1/lrPb7mRqGKd1gzPdgTqzNzbTftr4utEh9JhHl4rziAbDTGLaWVXHQc tFXQ== MIME-Version: 1.0 X-Received: by 10.68.227.202 with SMTP id sc10mr15355849pbc.109.1362157019717; Fri, 01 Mar 2013 08:56:59 -0800 (PST) Sender: twatteyne@gmail.com Received: by 10.68.227.71 with HTTP; Fri, 1 Mar 2013 08:56:59 -0800 (PST) In-Reply-To: <4b8fab46a18b44f897b740a9b9bcd7bf.squirrel@calmail.berkeley.edu> References: <512C36F4.4000409@eecs.berkeley.edu> <512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com> <4b8fab46a18b44f897b740a9b9bcd7bf.squirrel@calmail.berkeley.edu> Date: Fri, 1 Mar 2013 08:56:59 -0800 X-Google-Sender-Auth: Mn4bfu5WdPAwXuimvMZn3tpEPEE Message-ID: From: Thomas Watteyne To: "6tsch@ietf.org" <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b2eda154bf69f04d6dfe54b Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:57:01 -0000 --047d7b2eda154bf69f04d6dfe54b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pascal, Qin, Quick clarifying question: what would the difference be between a bundle and a path? The latter is defined as the set of links between two neighbors. I guess one major difference is QoS. In that case, would a bundle be equivalent to "path between A and B on slotframe 5"? Thomas On Fri, Mar 1, 2013 at 8:54 AM, Qin Wang wrote: > Pascal, > > Thank you for your comments. Very good point. Right now, I have not very > good answer for it. But I think it should be answered in the 6tus draft. > > Qin > > > > > I agree Qin, > > > > Fact is, we need a name for what you call a logical channel. A name tha= t > > is not already overloaded 4 times. I'd suggest something like a bundle. > > > > A bundle would be an aggregation of time slots of equal properties. A > link > > (what IPv6 sees) becomes a set of bundles. Depending on priority, flow, > > multicast etc... when IP pushes a pack to a link, 6TUS will have to fin= d > > which bundle within a link maps the criteria for that packet. > > > > The question becomes what (opaque) info the IP layer needs to pass to > > 6TUS. And whether that information comes all form the packet or if for > > instance the incoming bundle for a packet is already informative enough= . > > > > On the side: > > - the physical size of a bundle can be dynamic as you suggested earlier= , > > unless we are talking to hard reservation. > > - but then we have to define a fallback bundle for an dynamic bundle th= at > > is temporarily overflowing. > > > > Cheers, > > > > Pascal > > > > -----Original Message----- > > From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf > Of > > Qin Wang > > Sent: jeudi 28 f=E9vrier 2013 19:40 > > To: Alfredo Grieco > > Cc: 6tsch@ietf.org; 'Xavier Vilajosana' > > Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH > > > > Hi Alfredo, > > > > When you say "primary broadcast channel", you mean a physical or logica= l > > channel, for example one of the 16 channels in 2.4GHz band, or a set of > > links among neighbors? > > > > I think using a set of links as broadcast channel, instead of a fixed > > physical or logic channel, is more flexible and bandwidth efficient. Ho= w > > do you think? > > > > Qin > > > > > >> Hi Xavi and all, > >> > >> Sorry for the delayed reply. > >> > >> I agree that I broadcast channel is required. I was wondering that if > >> we set up a broadcast channel, its bandwidth should scale with the > >> size of the network. The more node the more the signaling to be sent > >> in broadcast. > >> > >> Should we imagine a primary broadcast channel that convey also the > >> information to signal the presence of further additional broadcast > >> channels ? > >> > >> Cheers > >> > >> Alfredo > >> > >> -----Messaggio originale----- > >> Da: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] Per conto > >> di Xavier Vilajosana > >> Inviato: Tuesday, February 26, 2013 5:16 AM > >> A: 6tsch@ietf.org > >> Oggetto: [6tsch] DIOs/DAOs and broadcast channels on TSCH > >> > >> Hi, > >> > >> I have a question that i want to discuss, the question is whether we > >> need a broadcast channel in TSCH or not and what kind of support 6tus > >> should provide. (the answer can be depends... but lets see some cases) > >> > >> a) ADV need broadcast channels in case they are used to synchronize > >> the network. IEEE 802.15.4e provides the timekeeping flag to set that > >> channels as used for synchronization and shared flag can make them > >> broadcast. > >> b) Those networks that do not need ADV for synchronization then can > >> use any TX link for ADV, this means that if it is not shared only the > >> node listening on that link will get the ADV. However as this > >> periodically occurs the ADV might eventually be listened in all > >> channels. > >> c)Some DAOs and all DIOs require a broadcast channel. Should the > >> schedule provide that? in case of a), can the same link be used? How > >> this link should be installed in the nodes? > >> d)Is the scheduler of the network who should setup a broadcast channel > >> independent of the broadcast channel set for ADV? can it be the same? > >> Or in contrast, 6tus can configure the EB so it indicates a broadcast > >> channel.. > >> e).. > >> > >> I would like to know what is your opinion on that. > >> > >> cheers! > >> Xavi > >> _______________________________________________ > >> 6tsch mailing list > >> 6tsch@ietf.org > >> https://www.ietf.org/mailman/listinfo/6tsch > >> > >> _______________________________________________ > >> 6tsch mailing list > >> 6tsch@ietf.org > >> https://www.ietf.org/mailman/listinfo/6tsch > >> > > > > > > _______________________________________________ > > 6tsch mailing list > > 6tsch@ietf.org > > https://www.ietf.org/mailman/listinfo/6tsch > > > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > --047d7b2eda154bf69f04d6dfe54b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pascal, Qin,

Quick clarifying question: what would the d= ifference be between a bundle and a path? The latter is defined as the set = of links between two=A0neighbors. I guess one major difference is QoS. In t= hat case, would a bundle be equivalent to "path between A and B on slo= tframe 5"?

Thomas


On F= ri, Mar 1, 2013 at 8:54 AM, Qin Wang <qinwang@berkeley.edu> wrote:
Pascal,

Thank you for your comments. Very good point. Right now, I have not very good answer for it. But I think it should be answered in the 6tus draft.
Qin



> I agree Qin,
>
> Fact is, we need a name for what you call a logical channel. A name th= at
> is not already overloaded 4 times. I'd suggest something like a bu= ndle.
>
> A bundle would be an aggregation of time slots of equal properties. A = link
> (what IPv6 sees) becomes a set of bundles. Depending on priority, flow= ,
> multicast etc... when IP pushes a pack to a link, 6TUS will have to fi= nd
> which bundle within a link maps the criteria for that packet.
>
> The question becomes what (opaque) info the IP layer needs to pass to<= br> > 6TUS. And whether that information comes all form the packet or if for=
> instance the incoming bundle for a packet is already informative enoug= h.
>
> On the side:
> - the physical size of a bundle can be dynamic as you suggested earlie= r,
> unless we are talking to hard reservation.
> - but then we have to define a fallback bundle for an dynamic bundle t= hat
> is temporarily overflowing.
>
> Cheers,
>
> Pascal
>
> -----Original Message-----
> From: 6tsch-bounces@ietf.org= [mailto:6tsch-bounces@ietf.o= rg] On Behalf Of
> Qin Wang
> Sent: jeudi 28 f=E9vrier 2013 19:40
> To: Alfredo Grieco
> Cc: 6tsch@ietf.org; 'Xavier = Vilajosana'
> Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH
>
> Hi Alfredo,
>
> When you say "primary broadcast channel", you mean a physica= l or logical
> channel, for example one of the 16 channels in 2.4GHz band, or a set o= f
> links among neighbors?
>
> I think using a set of links as broadcast channel, instead of a fixed<= br> > physical or logic channel, is more flexible and bandwidth efficient. H= ow
> do you think?
>
> Qin
>
>
>> Hi Xavi and all,
>>
>> Sorry for the delayed reply.
>>
>> I agree that I broadcast channel is required. I was wondering that= if
>> we set up a broadcast channel, its bandwidth should scale with the=
>> size of the network. The more node the more the signaling to be se= nt
>> in broadcast.
>>
>> Should we imagine a primary broadcast channel that convey also the=
>> information to signal the presence of further additional broadcast=
>> channels ?
>>
>> Cheers
>>
>> Alfredo
>>
>> -----Messaggio originale-----
>> Da: 6tsch-bounces@ietf.o= rg [mailto:6tsch-bounces@ietf= .org] Per conto
>> di Xavier Vilajosana
>> Inviato: Tuesday, February 26, 2013 5:16 AM
>> A: 6tsch@ietf.org
>> Oggetto: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>>
>> Hi,
>>
>> I have a question that i want to discuss, the question is whether = we
>> need a broadcast channel in TSCH or not and what kind of support 6= tus
>> should provide. (the answer can be depends... but lets see some ca= ses)
>>
>> a) ADV need broadcast channels in case they are used to synchroniz= e
>> the network. IEEE 802.15.4e provides the timekeeping flag to set t= hat
>> channels as used for synchronization and shared flag can make them=
>> broadcast.
>> b) Those networks that do not need ADV for synchronization then ca= n
>> use any TX link for ADV, this means that if it is not shared only = the
>> node listening on that link will get the ADV. However as this
>> periodically occurs the ADV might eventually be listened in all >> channels.
>> c)Some DAOs and all DIOs require a broadcast channel. Should the >> schedule provide that? in case of a), can the same link be used? H= ow
>> this link should be installed in the nodes?
>> d)Is the scheduler of the network who should setup a broadcast cha= nnel
>> independent of the broadcast channel set for ADV? can it be the sa= me?
>> Or in contrast, 6tus can configure the EB so it indicates a broadc= ast
>> channel..
>> e)..
>>
>> I would like to know what is your opinion on that.
>>
>> cheers!
>> Xavi
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

--047d7b2eda154bf69f04d6dfe54b-- From mcr@sandelman.ca Fri Mar 1 10:35:41 2013 Return-Path: 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 3D7C321F90EE; Fri, 1 Mar 2013 10:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK0Lksdrv-Qj; Fri, 1 Mar 2013 10:35:40 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF7A21F9040; Fri, 1 Mar 2013 10:35:36 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2D99220168; Fri, 1 Mar 2013 13:42:54 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E5E0C63A5B; Fri, 1 Mar 2013 13:34:23 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D028263769; Fri, 1 Mar 2013 13:34:23 -0500 (EST) From: Michael Richardson To: "roll@ietf.org" In-Reply-To: References: <20381.1362077015@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "6tsch@ietf.org" <6tsch@ietf.org>, "draft-phinney-roll-rpl-industrial-applicability@tools.ietf.org" Subject: Re: [6tsch] [Roll] comments on draft-phinney-roll-rpl-industrial-applicability 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 18:35:41 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "pthubert" =3D=3D pthubert writes: pthubert> [Pascal] Thanks for the comments : ) pthubert> [Pascal] You are correct. The industry makes a difference pthubert> between Factory Automation (discrete manufacturing of pthubert> individual products) and Process Controls (continuous pthubert> production). These are really 2 different activities, and pthubert> Factory Automation may require much stricter behaviors for pthubert> very rapid operations. At ISA, WG 11 has standardized I guess this means that individual products are things which can come out of a production step, and then accumulate before going into the next step. (The kind of thing Goldratt warns us against having anywhere other than at a CCR) pthubert> So, RPL could be used during phases P1, P2, P4, P5 and P6, pthubert> but not during P3, (Normal Operation), unless a new OF was pthubert> defined that interacted with the PCE? pthubert> [Pascal] Roughly yes, and this is the work we are starting pthubert> at 6TSCH. In more details, there will be flows that can pthubert> use distributed routing but critical flows will need the pthubert> PCE. I think that we need to think about: 1) are the P1/P2/P4/P5 and P6 phases distinct in some way? I think that there are significant security differences between them, and the number of type of DAGs that need to be constructed may very a lot. This has implications that intermediate (storing!) nodes may have to have much large capacities for DAGs during non-P3 than they do for P3. Or not... My examination of RPL code to date suggests that some of what lets it fit into the smallest devices is because they support only a single DAG. (no tables, no searches, no code to sort A from B...) 2) how do you bootstrap *securely* into P3 operation? Does this require a rekey? It seems to me that it does. pthubert> 1) publish/subscribe, where an association exists between pthubert> one source and one or a few recipients, all of which are pthubert> identifiable, where publication is periodic within strict So, layer-6 multicasts carried on layer-3 unicast to known subscribers...=20 pthubert> 2) source/sink, where any of a number of sources logically pthubert> multicasts (however that is implemented) to a predefined 1:N multicast pthubert> 3) client/server or peer/peer, where all of the pthubert> traditional properties hold and the specialized ones pthubert> listed above generally do not. and this is 1:1 pthubert> page 13, section 2.1.4: says: pthubert> With rare exception, the control algorithms used with pthubert> PS messaging in the process automation industries - those pthubert> managing continuous material flows - rely on fixed-period pthubert> sampling, computation and transfer of outputs, while those pthubert> in the factory automation industries - those managing pthubert> discrete manufacturing operations - rely on bounded delay pthubert> between sampling of inputs, control computation and pthubert> transfer of outputs to physical actuators that affect the pthubert> controlled process. pthubert> it seems that there are possibly two completely different pthubert> industrial requirements here which can not, and should pthubert> not, be satisfied with a single DAG. Are two documents pthubert> appropriate here? pthubert> [Pascal] It is more than a different DAG, it is a pthubert> different plant... I read your question as do we want an pthubert> additional draft for factory automation? So, factory automation and plant control are not present in the same building. When someone comes along with factory automation expertise, they will need to write a draft. I'm not sure why factory automation is mentioned again. Let's just say: Tthe control algorithms used with PS messaging in the process automation industries - those managing continuous material flows - rely on fixed-period sampling, computation and transfer of outputs. As a result.. X, Y, Z. >> Note: Although there are known patent applications for duocast >> and N-cast, at the time of this writing the patent assignee, >> Honeywell International, has offered to permit cost-free RAND use >> in those industrial wireless standards that have chosen to >> employee the technology, under a reciprocal licensing requirement >> relative to that use. pthubert> Can we get an official IPR statement via: pthubert> http://www.ietf.org/ipr/file-disclosure pthubert> on this? I don't think it is particularly relevant to the pthubert> document, but perhaps I could be wrong. Not sure why it is mentioned then. pthubert> you need to update [I-D.ietf-roll-rpl] to RFC6550. pthubert> [Pascal] Done in 03 : ) pthubert> 4.3.1 says: >> Because the actual link capacity depends on the particular link >> technology used within an industrial automation network >> deployment, the Trickle parameters are specified in terms of the >> link's maximum capacity for conveying link-local multicast >> messages. If the link can convey m link-local multicast packets >> per second on average, the expected time it takes to transmit a >> link-local multicast packet is 1/m seconds. pthubert> I am pleased that a formula is being provided, but I am pthubert> uncomfortable that this document is not more specific to pthubert> actual link technology used. Can this document pick 1-2 pthubert> actual link technologies and deal with them? pthubert> [Pascal] We are working on those concepts at 6TSCH, ccing pthubert> the ML. But, wait. 6tsch is important for P3 only. The other phases need to have something written down. I think it's pretty important to have some concrete numbers for some actual technologies that actually are being deployed. Without that, it's pretty hard for academics to run simulations, or for people thinking about RPL extensions in field X to think how this might work (or not) in another field they aren't an expert in. Also, we need that set of layer 2s to be listed so that the security requirements of layer 2 can be expressed. Again, non-P3 vs P3 might require a rekey. pthubert> 5.: >> The possibility of dynamically updating the metrics in use in the >> network as well as the frequency of network updates allows >> deployment characteristics (e.g., network density) to be >> discovered during network bring-up and to be used to tailor >> network parameters once the network is operational rather than >> having to rely on precise pre- configuration. This also allows >> the network parameters and the overall routing protocol behavior >> to evolve during the lifetime of the network. mcr> I don't know how this discovery is going to occur. mcr> Someone trying to build a sensor that is going to satisfy mcr> an RFP for devices to work in a network envisioned by this mcr> document needs to know what to include in their code base. mcr> As the code space is very finite, they need to know mcr> exactly what is important here. pthubert> [Pascal] Finding the values for parameters is more of a pthubert> deployment issue, so I read your question as 'which pthubert> parameters are critical for the device to operate in pthubert> industrial environment and which range for those pthubert> parameters'. Again, work at 6TSCH may help. Yes, that's what I'm saying. The text talks about "dynamically updating the metrics in use" That says to me that it's not about the values of the metrics, but in changing which metrics are used. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUTD0r4qHRg3pndX9AQLjzgP/WJOvskNU4GAg0okJ/xqOSDKupg4894wP vpNC7l2Uy/5OdE7jNcpKJR6+Jewx4QpQ2ZNGanwrQFo0w6ZkiR+AJiXmBMEMPpk5 1kTYWo8sxEcsr5MNIo0zghIGSag7ejlBVmf8UF9ekkfQwzdxqzFbtJdNvc3VjFUK JnSEabpHEi8= =gFJT -----END PGP SIGNATURE----- --=-=-=-- From qinwang@berkeley.edu Fri Mar 1 10:46:16 2013 Return-Path: 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 2BCDC21E809E for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 10:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.632 X-Spam-Level: X-Spam-Status: No, score=-5.632 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5xxanXytubg for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 10:46:15 -0800 (PST) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0A221E8047 for <6tsch@ietf.org>; Fri, 1 Mar 2013 10:46:15 -0800 (PST) Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UBUy5-0007EF-9F; Fri, 01 Mar 2013 10:46:07 -0800 Received: from 136.152.36.142 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 1 Mar 2013 10:46:05 -0800 Message-ID: In-Reply-To: References: <512C36F4.4000409@eecs.berkeley.edu> <512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com> <4b8fab46a18b44f897b740a9b9bcd7bf.squirrel@calmail.berkeley.edu> Date: Fri, 1 Mar 2013 10:46:05 -0800 From: "Qin Wang" To: "Thomas Watteyne" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 18:46:16 -0000 Thomas, In the discussion, "broadcast channel" is used, which is not defined very clear. In the context of TSCH, "Channel" already has specific meaning, no matter "physical channel" or "logic channel". So, we need some word to denote "broadcast channel", i.e. a set of links, on which one node is in Tx mode, neighbors are in Rx mode. So, for me, "a bundle" is same as "a path with broadcast feature". How do you think? Qin > Pascal, Qin, > > Quick clarifying question: what would the difference be between a bundle > and a path? The latter is defined as the set of links between > two neighbors. I guess one major difference is QoS. In that case, would a > bundle be equivalent to "path between A and B on slotframe 5"? > > Thomas > > > On Fri, Mar 1, 2013 at 8:54 AM, Qin Wang wrote: > >> Pascal, >> >> Thank you for your comments. Very good point. Right now, I have not very >> good answer for it. But I think it should be answered in the 6tus draft. >> >> Qin >> >> >> >> > I agree Qin, >> > >> > Fact is, we need a name for what you call a logical channel. A name >> that >> > is not already overloaded 4 times. I'd suggest something like a >> bundle. >> > >> > A bundle would be an aggregation of time slots of equal properties. A >> link >> > (what IPv6 sees) becomes a set of bundles. Depending on priority, >> flow, >> > multicast etc... when IP pushes a pack to a link, 6TUS will have to >> find >> > which bundle within a link maps the criteria for that packet. >> > >> > The question becomes what (opaque) info the IP layer needs to pass to >> > 6TUS. And whether that information comes all form the packet or if for >> > instance the incoming bundle for a packet is already informative >> enough. >> > >> > On the side: >> > - the physical size of a bundle can be dynamic as you suggested >> earlier, >> > unless we are talking to hard reservation. >> > - but then we have to define a fallback bundle for an dynamic bundle >> that >> > is temporarily overflowing. >> > >> > Cheers, >> > >> > Pascal >> > >> > -----Original Message----- >> > From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf >> Of >> > Qin Wang >> > Sent: jeudi 28 février 2013 19:40 >> > To: Alfredo Grieco >> > Cc: 6tsch@ietf.org; 'Xavier Vilajosana' >> > Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH >> > >> > Hi Alfredo, >> > >> > When you say "primary broadcast channel", you mean a physical or >> logical >> > channel, for example one of the 16 channels in 2.4GHz band, or a set >> of >> > links among neighbors? >> > >> > I think using a set of links as broadcast channel, instead of a fixed >> > physical or logic channel, is more flexible and bandwidth efficient. >> How >> > do you think? >> > >> > Qin >> > >> > >> >> Hi Xavi and all, >> >> >> >> Sorry for the delayed reply. >> >> >> >> I agree that I broadcast channel is required. I was wondering that if >> >> we set up a broadcast channel, its bandwidth should scale with the >> >> size of the network. The more node the more the signaling to be sent >> >> in broadcast. >> >> >> >> Should we imagine a primary broadcast channel that convey also the >> >> information to signal the presence of further additional broadcast >> >> channels ? >> >> >> >> Cheers >> >> >> >> Alfredo >> >> >> >> -----Messaggio originale----- >> >> Da: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] Per conto >> >> di Xavier Vilajosana >> >> Inviato: Tuesday, February 26, 2013 5:16 AM >> >> A: 6tsch@ietf.org >> >> Oggetto: [6tsch] DIOs/DAOs and broadcast channels on TSCH >> >> >> >> Hi, >> >> >> >> I have a question that i want to discuss, the question is whether we >> >> need a broadcast channel in TSCH or not and what kind of support 6tus >> >> should provide. (the answer can be depends... but lets see some >> cases) >> >> >> >> a) ADV need broadcast channels in case they are used to synchronize >> >> the network. IEEE 802.15.4e provides the timekeeping flag to set that >> >> channels as used for synchronization and shared flag can make them >> >> broadcast. >> >> b) Those networks that do not need ADV for synchronization then can >> >> use any TX link for ADV, this means that if it is not shared only the >> >> node listening on that link will get the ADV. However as this >> >> periodically occurs the ADV might eventually be listened in all >> >> channels. >> >> c)Some DAOs and all DIOs require a broadcast channel. Should the >> >> schedule provide that? in case of a), can the same link be used? How >> >> this link should be installed in the nodes? >> >> d)Is the scheduler of the network who should setup a broadcast >> channel >> >> independent of the broadcast channel set for ADV? can it be the same? >> >> Or in contrast, 6tus can configure the EB so it indicates a broadcast >> >> channel.. >> >> e).. >> >> >> >> I would like to know what is your opinion on that. >> >> >> >> cheers! >> >> Xavi >> >> _______________________________________________ >> >> 6tsch mailing list >> >> 6tsch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/6tsch >> >> >> >> _______________________________________________ >> >> 6tsch mailing list >> >> 6tsch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/6tsch >> >> >> > >> > >> > _______________________________________________ >> > 6tsch mailing list >> > 6tsch@ietf.org >> > https://www.ietf.org/mailman/listinfo/6tsch >> > >> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > From qinwang@berkeley.edu Fri Mar 1 10:46:16 2013 Return-Path: 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 A0FE321E8047 for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 10:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.621 X-Spam-Level: X-Spam-Status: No, score=-5.621 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV559cMwUVHZ for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 10:46:15 -0800 (PST) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 07A8E21E803F for <6tsch@ietf.org>; Fri, 1 Mar 2013 10:46:06 -0800 (PST) Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UBUy3-0003Nc-Kk; Fri, 01 Mar 2013 10:46:05 -0800 Received: from 136.152.36.142 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 1 Mar 2013 10:46:03 -0800 Message-ID: <9b80b0914c7559ac2b8fd46bd2f7a0c5.squirrel@calmail.berkeley.edu> In-Reply-To: References: <512C36F4.4000409@eecs.berkeley.edu> <512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com> <4b8fab46a18b44f897b740a9b9bcd7bf.squirrel@calmail.berkeley.edu> Date: Fri, 1 Mar 2013 10:46:03 -0800 From: "Qin Wang" To: "Thomas Watteyne" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 18:46:16 -0000 Thomas, In the discussion, "broadcast channel" is used, which is not defined very clear. In the context of TSCH, "Channel" already has specific meaning, no matter "physical channel" or "logic channel". So, we need some word to denote "broadcast channel", i.e. a set of links, on which one node is in Tx mode, neighbors are in Rx mode. So, for me, "a bundle" is same as "a path with broadcast feature". How do you think? Qin > Pascal, Qin, > > Quick clarifying question: what would the difference be between a bundle > and a path? The latter is defined as the set of links between > two neighbors. I guess one major difference is QoS. In that case, would a > bundle be equivalent to "path between A and B on slotframe 5"? > > Thomas > > > On Fri, Mar 1, 2013 at 8:54 AM, Qin Wang wrote: > >> Pascal, >> >> Thank you for your comments. Very good point. Right now, I have not very >> good answer for it. But I think it should be answered in the 6tus draft. >> >> Qin >> >> >> >> > I agree Qin, >> > >> > Fact is, we need a name for what you call a logical channel. A name >> that >> > is not already overloaded 4 times. I'd suggest something like a >> bundle. >> > >> > A bundle would be an aggregation of time slots of equal properties. A >> link >> > (what IPv6 sees) becomes a set of bundles. Depending on priority, >> flow, >> > multicast etc... when IP pushes a pack to a link, 6TUS will have to >> find >> > which bundle within a link maps the criteria for that packet. >> > >> > The question becomes what (opaque) info the IP layer needs to pass to >> > 6TUS. And whether that information comes all form the packet or if for >> > instance the incoming bundle for a packet is already informative >> enough. >> > >> > On the side: >> > - the physical size of a bundle can be dynamic as you suggested >> earlier, >> > unless we are talking to hard reservation. >> > - but then we have to define a fallback bundle for an dynamic bundle >> that >> > is temporarily overflowing. >> > >> > Cheers, >> > >> > Pascal >> > >> > -----Original Message----- >> > From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf >> Of >> > Qin Wang >> > Sent: jeudi 28 février 2013 19:40 >> > To: Alfredo Grieco >> > Cc: 6tsch@ietf.org; 'Xavier Vilajosana' >> > Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH >> > >> > Hi Alfredo, >> > >> > When you say "primary broadcast channel", you mean a physical or >> logical >> > channel, for example one of the 16 channels in 2.4GHz band, or a set >> of >> > links among neighbors? >> > >> > I think using a set of links as broadcast channel, instead of a fixed >> > physical or logic channel, is more flexible and bandwidth efficient. >> How >> > do you think? >> > >> > Qin >> > >> > >> >> Hi Xavi and all, >> >> >> >> Sorry for the delayed reply. >> >> >> >> I agree that I broadcast channel is required. I was wondering that if >> >> we set up a broadcast channel, its bandwidth should scale with the >> >> size of the network. The more node the more the signaling to be sent >> >> in broadcast. >> >> >> >> Should we imagine a primary broadcast channel that convey also the >> >> information to signal the presence of further additional broadcast >> >> channels ? >> >> >> >> Cheers >> >> >> >> Alfredo >> >> >> >> -----Messaggio originale----- >> >> Da: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] Per conto >> >> di Xavier Vilajosana >> >> Inviato: Tuesday, February 26, 2013 5:16 AM >> >> A: 6tsch@ietf.org >> >> Oggetto: [6tsch] DIOs/DAOs and broadcast channels on TSCH >> >> >> >> Hi, >> >> >> >> I have a question that i want to discuss, the question is whether we >> >> need a broadcast channel in TSCH or not and what kind of support 6tus >> >> should provide. (the answer can be depends... but lets see some >> cases) >> >> >> >> a) ADV need broadcast channels in case they are used to synchronize >> >> the network. IEEE 802.15.4e provides the timekeeping flag to set that >> >> channels as used for synchronization and shared flag can make them >> >> broadcast. >> >> b) Those networks that do not need ADV for synchronization then can >> >> use any TX link for ADV, this means that if it is not shared only the >> >> node listening on that link will get the ADV. However as this >> >> periodically occurs the ADV might eventually be listened in all >> >> channels. >> >> c)Some DAOs and all DIOs require a broadcast channel. Should the >> >> schedule provide that? in case of a), can the same link be used? How >> >> this link should be installed in the nodes? >> >> d)Is the scheduler of the network who should setup a broadcast >> channel >> >> independent of the broadcast channel set for ADV? can it be the same? >> >> Or in contrast, 6tus can configure the EB so it indicates a broadcast >> >> channel.. >> >> e).. >> >> >> >> I would like to know what is your opinion on that. >> >> >> >> cheers! >> >> Xavi >> >> _______________________________________________ >> >> 6tsch mailing list >> >> 6tsch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/6tsch >> >> >> >> _______________________________________________ >> >> 6tsch mailing list >> >> 6tsch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/6tsch >> >> >> > >> > >> > _______________________________________________ >> > 6tsch mailing list >> > 6tsch@ietf.org >> > https://www.ietf.org/mailman/listinfo/6tsch >> > >> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > From twatteyne@gmail.com Fri Mar 1 11:15:40 2013 Return-Path: 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 2097321E803F for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 11:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLpLpmYOfE+1 for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 11:15:39 -0800 (PST) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id 14F8921F91DB for <6tsch@ietf.org>; Fri, 1 Mar 2013 11:15:37 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so1549558dak.16 for <6tsch@ietf.org>; Fri, 01 Mar 2013 11:15:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=FFXPR7DcHwQX3A70StKjUEpooE3QRGijpDGN3Fcq0fw=; b=yxwzDdIiIeOGhWedA/mlIMIHP+upyUMg6EKdM1Aaa/MHjL+VpwPXFvZnyiTRGVOQIC cHFsDZj79ZI2WIRJNhvzlwFWImlZlncN+NvgFs02jcjh5d+j/SJ7hRhdiiKRZDbKJ2a5 fqxQizHyQ9g0rIRUQMM6Ws7c8UXTLbLxnjJmolMZo2NYpMggZ0fHLMwNr86ziHkXGzVn OAQkLqEXS3JjZq7ISXiKH1uuxzNr418Qn2vnoSJ3DIOCZNesH13cN7NK7g1JWv4GNV5u vIiKiHGYUmqN6zO5MtjPL7CFQCJGwqFDvTAWyCnr2GXsM8ysc9PxncfP9K2vwK8STlsZ qtgg== MIME-Version: 1.0 X-Received: by 10.68.2.132 with SMTP id 4mr15888357pbu.221.1362165325348; Fri, 01 Mar 2013 11:15:25 -0800 (PST) Sender: twatteyne@gmail.com Received: by 10.68.227.71 with HTTP; Fri, 1 Mar 2013 11:15:25 -0800 (PST) Date: Fri, 1 Mar 2013 11:15:25 -0800 X-Google-Sender-Auth: Kac5V_d6cD8TfFMxy7cwMBSqrbo Message-ID: From: Thomas Watteyne To: IETF 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=bcaec521576b57c5e604d6e1d498 Subject: [6tsch] minutes WebEx 1 March 2013 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 19:15:40 -0000 --bcaec521576b57c5e604d6e1d498 Content-Type: text/plain; charset=ISO-8859-1 All, Notes of today's meeting below. Please correct inline and reply. Thomas --- Present: - Alfredo Grieco - Herman Storey - Maria Rita Palattella - Normann Finn - Pascal Thubert - Qin Wang - Raghuram Sudhaakar - Thomas Watteyne - Tina Tsou - Tom Phinney - Xavi Vilajosana Agenda: - Presentation of the backbone router draft [15min] . http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-03 - 6tus [15min] . thoughts on where 6tus fits in architecture . thoughts on where 6tus fits in 6tsch work - mailing list topics [30min] . Broadcast channels . Mapping channels to flows . DIS, DIO, DAO, ND, hard-reserved, lazy-reserved, best-effort Minutes: - [09.03] meeting starts - [09.03] Move phone call to 1h earlier? [Pascal] . Pascal has gotten unicast requests for this change, especially from Asia . Pascal asks for rough consensus on phone call. . rough consensus reached . Pascal to ask same question on ML before rescheduling - Backbone Router Presentation [Pascal] . Pascal presents http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-03 using slides: . Goal of BR: . several independent wireless mesh networks appear as one IPv6 subnet (i.e. share same /64 prefix). . allows a mote to move from one mesh network to other without requiring a new IPv6 address . works with different technologies: RPL, 6LoWPAN, other. . Each "root" of a mesh network (6LBR, RPL root, etc) is a BR . BRs are connected by a Transit Link, i.e. they live in one broadcast domain . each BR serves as an ND proxy for the motes in its mesh. . draft specifies how BRs claim and defend addresses, and how resolutions are revolved . Clarifying questions: . [Thomas] requirements on transit link? [Pascal] broadcast domain, same as regular ND - Thoughts on 6tsch and 6tus [Thomas] . Thomas presents thoughts of what 6tus is and how fits in 6tsch architecture using slides: . Many scheduling policies exist which are valid and should be supported: - centralized scheduling engine (i.e. PCE) - distributed approach (i.e. RSVP) . 6tus introduces the distinction between hard and soft links (which becomes an extra flag in TSCH links): - 6tus will not move hard links. These are typically installed by a PCE. - 6tus will monitor and if necessary move soft links. . 6tus defines the mechanism on which policies can build: - commands which can be called by upper layer (API) - header formats (6tus defines 3 new IEs) - protocol for neighbor motes to negotiate adding/delete/moving links. . Remarks: . [Pascal] "link" is used everywhere, we need a better name for it. "slot"? "cell"? . [Pascal] 6tus should introduce the concept of virtual bandwidth (similar to virtual memory): the routing layer should consider having some bandwidth, but only part of it can be scheduled at some time. Extra bandwidth can be scheduled on-the-fly, or some overflow mechanism can exist. . [Pascal] in a PCE setting, the PCE should not have to contact both A and B to establish an A->B link. Instead, it should only contact mote A, which should use 6tus to propagate request to mote B. . [Maria Rita, Qin, Xavi, Pascal] In a PCE setting, it is important that the PCE knows as much as possible to handle QoS (e.g. schedule more links that required). 6tus should contain some feedback mechanism to the PCE. . [Pascal] 6tus should discuss how to handle DIS. - [09.54] Liaison work [Pascal] . ISA100.20 . ISA100.20 is looking for a format to send commands from system manager to motes. . Thinking about CoAP, EXI, netconf. . [Thomas] Who could be liaison? . [Pascal] options are Pascal, Pat Kinney, Herman Storey . [Pascal] time permitting, Herman could present ISA100.20 status on 6TSCH call . IoT6 . architecture close to 6tsch . key people are Antonio Skarmeta and Antonio Jara from U. Murcia, Spain . [Thomas] Who could be liaison? . [Maria Rita] could get more information - [10.00] recording . [Pascal] is recording, OK to make available to people who could not make it? . rough consensus on call that's no problem. . [Tom] we can alternate between 2 times. . [Tom] mention that meetings are recorded when sending poll to reschedule meeting. - [10.04] end of meeting --bcaec521576b57c5e604d6e1d498 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,
Notes of today's meeting below. Please correct inli= ne and reply.
Thomas

---

<= /div>
Present:
- Alfredo Grieco
- Herman Storey
- Maria Rita Palattella
- Normann Finn
- Pascal Thubert
- Qin Wang
- Raghuram Sudhaakar
- Thomas Watteyne
- Tina Tsou
- Tom Phinney
- Xavi Vilajosana

Agenda:
- Presentation of the backbone = router draft =A0[15min]
- 6tus [15min]
= =A0 =A0 . thoughts on where 6tus fits= in architecture
=A0= =A0 . thoughts on where 6tus fits in 6tsch work
- mailing list topics [30min]
=A0 =A0 . Broadcast ch= annels
=A0 =A0 . Map= ping channels to flows
=A0 =A0 =A0 =A0 . DIS, DIO, DAO,= ND, hard-reserved, lazy-reserved, best-effort

Minutes:
- [09.03] meeting starts<= /div>
- [09.03] Move phone call t= o 1h earlier? [Pascal]
=A0 =A0 . Pascal has gotten unicast requests for this change, especially= from Asia
=A0 =A0 . Pascal asks for rough = consensus on phone call.
=A0 =A0 . rough consensus reached
=A0 =A0 . Pascal to ask same question on ML before resch= eduling
- Backbone Router Presentation [= Pascal]
=A0 =A0 =A0 using slides:=
=A0 =A0 =A0 =A0 . Goal of = BR:
=A0 =A0 =A0 =A0 = =A0 =A0 . several independent wireless mesh networks appear as one IPv6
=A0 =A0 =A0 =A0 =A0 =A0 =A0 subn= et (i.e. share same /64 prefix).
=A0 =A0 =A0 =A0 =A0 =A0 . allows a mote to move from one mesh = network to other without
=A0 =A0 =A0 =A0 =A0 =A0 =A0 requ= iring a new IPv6 address
=A0 =A0 =A0 =A0 . works with different technologies: RPL, 6LoWPAN, oth= er.
=A0 =A0 =A0 =A0 = . Each "root" of a mesh network (6LBR, RPL root, etc) is a BR
=A0 =A0 =A0 =A0 . BRs are connec= ted by a Transit Link, i.e. they live in one broadcast
=A0 =A0 =A0 =A0 =A0 domain
<= div>=A0 =A0 =A0 =A0 . each BR serves = as an ND proxy for the motes in its mesh.
=A0 =A0 =A0 =A0 . draft specifie= s how BRs claim and defend addresses, and how
=A0 =A0 =A0 =A0 =A0 resolutions are revolved
=A0 =A0 . Clarifying q= uestions:
=A0 =A0 =A0 =A0 . [Thomas] requi= rements on transit link?
=A0 =A0 =A0 =A0 =A0 [Pascal] broadcast domain, same as regular ND
- Thoughts on 6tsch and = 6tus [Thomas]
=A0 =A0 . Thomas presents though= ts of what 6tus is and how fits in 6tsch
=A0 =A0 =A0 architecture using slides:
=A0 =A0 =A0 =A0 . Many scheduling p= olicies exist which are valid and should be
=A0 =A0 =A0 =A0 =A0 supported:
=A0 =A0 =A0 =A0 =A0 = =A0 - centralized scheduling engine (i.e. PCE)
=A0 =A0 =A0 =A0 =A0 =A0 - distributed approach = (i.e. RSVP)
=A0 =A0 =A0 =A0 . 6tus introduce= s the distinction between hard and soft links (which
=A0 =A0 =A0 =A0 =A0 becomes an extra flag = in TSCH links):
=A0 =A0 =A0 =A0 =A0 =A0 - 6tus w= ill not move hard links. These are typically installed by a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 PCE.
=A0 =A0 =A0 =A0 =A0 = =A0 - 6tus will monitor and if necessary move soft links.
=A0 =A0 =A0 =A0 . 6tus defines t= he mechanism on which policies can build:
=A0 =A0 =A0 =A0 =A0 =A0 - commands which can be calle= d by upper layer (API)
=A0 =A0 =A0 =A0 =A0 =A0 - header= formats (6tus defines 3 new IEs)
=A0 =A0 =A0 =A0 =A0 =A0 - protocol for neighbor motes to=A0ne= gotiate=A0adding/delete/moving
=A0 =A0 =A0 =A0 =A0 =A0 =A0 link= s.
=A0 =A0 . Remarks= :
=A0 =A0 =A0 =A0 . = [Pascal] "link" is used everywhere, we need a better name for it.=
=A0 =A0 =A0 =A0 =A0 "slot&q= uot;? "cell"?
=A0 =A0 =A0 =A0 . [Pascal] 6tus should introduce the concept of virtual= bandwidth
=A0 =A0 =A0 =A0 =A0 (similar to = virtual memory): the routing layer should consider having
= =A0 =A0 =A0 =A0 =A0 some bandwidth, b= ut only part of it can be scheduled at some time.
=A0 =A0 =A0 =A0 =A0 Extra bandwi= dth can be scheduled on-the-fly, or some overflow
=A0 =A0 =A0 =A0 =A0 mechanism can exist.
=A0 =A0 =A0 =A0 . [Pasca= l] in a PCE setting, the PCE should not have to contact both A
=A0 =A0 =A0 =A0 =A0 and B to est= ablish an A->B link. Instead, it should only contact mote
=A0 =A0 =A0 =A0 =A0 A, which shoul= d use 6tus to propagate request to mote B.
=A0 =A0 =A0 =A0 . [Maria Rita, Q= in, Xavi, Pascal] In a PCE setting, it is important that the
=A0 =A0 =A0 =A0 =A0 PCE knows as m= uch as possible to handle QoS (e.g. schedule more links
=A0 =A0 =A0 =A0 =A0 that require= d). 6tus should contain some feedback mechanism to the
=A0 =A0 =A0 =A0 =A0 PCE.
=A0 =A0 =A0 =A0 . [Pascal] 6tus sho= uld discuss how to handle DIS.
- [09.54] Liaison work [Pascal]<= /font>
=A0 =A0 . ISA100.20<= /font>
=A0 =A0 =A0 =A0 . IS= A100.20 is looking for a format to send commands from system
=A0 =A0 =A0 =A0 =A0 manager to m= otes.
=A0 =A0 =A0 = =A0 . Thinking about CoAP, EXI, netconf.
=A0 =A0 =A0 =A0 . [Thomas] Who could be liaison?
=A0 =A0 =A0 =A0 . [Pascal] optio= ns are Pascal, Pat Kinney, Herman Storey
=A0 =A0 =A0 =A0 . [Pascal] time permitting, Herman cou= ld present ISA100.20 status on
=A0 =A0 =A0 =A0 =A0 6TSCH call
=A0 =A0 . IoT6=
=A0 =A0 =A0 =A0 . architec= ture close to 6tsch
=A0 =A0 =A0 =A0 . key people are= Antonio Skarmeta and Antonio Jara from U. Murcia,
=A0 =A0 =A0 =A0 =A0 Spain
<= font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 . [Thomas] Who could b= e liaison?
=A0 =A0 =A0 =A0 . [Maria Rita] c= ould get more information
- [10.00] recording
=A0 =A0 . [Pascal] is recording, OK to make available to people who c= ould not make
=A0 =A0 =A0 it?
=A0 =A0 . rough consensus on call th= at's no problem.
=A0 =A0 . [Tom] we can alternate between 2 times.
=A0 =A0 . [Tom] mention that mee= tings are recorded when sending poll to reschedule
=A0 =A0 =A0 meeting.
- [10.04] end of meeting

--bcaec521576b57c5e604d6e1d498-- From mcr@sandelman.ca Fri Mar 1 11:19:56 2013 Return-Path: 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 1E14521F8ABA for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 11:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4cRiISh8fkb for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 11:19:55 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBCA21F8425 for <6tsch@ietf.org>; Fri, 1 Mar 2013 11:19:55 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5098220168 for <6tsch@ietf.org>; Fri, 1 Mar 2013 14:27:13 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id D93A963A5B; Fri, 1 Mar 2013 14:18:42 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BDD2863769 for <6tsch@ietf.org>; Fri, 1 Mar 2013 14:18:42 -0500 (EST) From: Michael Richardson To: "6tsch@ietf.org" <6tsch@ietf.org> In-Reply-To: References: <512C36F4.4000409@eecs.berkeley.edu> <512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 19:19:56 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "pthubert" =3D=3D pthubert writes: pthubert> Fact is, we need a name for what you call a logical pthubert> channel. A name that is not already overloaded 4 pthubert> times. I'd suggest something like a bundle. pthubert> A bundle would be an aggregation of time slots of equal pthubert> properties. A link (what IPv6 sees) becomes a set of pthubert> bundles. Depending on priority, flow, multicast pthubert> etc... when IP pushes a pack to a link, 6TUS will have to pthubert> find which bundle within a link maps the criteria for that pthubert> packet. Basically this is kinda an inverse mux. Generally, the bigger thing is called an aggregate. It's also a construction term: http://en.wikipedia.org/wiki/Construction_aggregate so, if it's an unloaded word you want, why not pick one of: sand, gravel, stone, slag, .... I note that it says: "aggregates are used as a stable foundation or road/rail base with predictable, uniform properties" which seems exactly what we are trying to get... =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUTD/EoqHRg3pndX9AQL2XQQAl6LIIdeUFfhdi9dwH9CJ4iEzpZc2XeRR Q2QlMzEH+liDoeYNSXDErb9ggtGDyzoPoFATAC72c5sPw9GMkP96yIu8bCPDzfYe fyxJOBU1mXBWu1sqKn66rgnBO3JxItw/l7xKlGyM+18X0Igj52Yo/p6+5MsUzLvj KpTc0lZlY6E= =KAtq -----END PGP SIGNATURE----- --=-=-=-- From tom.phinney@cox.net Fri Mar 1 11:42:23 2013 Return-Path: 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 48A2E21F85DA for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 11:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWsPHBg5yrAY for <6tsch@ietfa.amsl.com>; Fri, 1 Mar 2013 11:42:22 -0800 (PST) Received: from fed1rmfepo201.cox.net (fed1rmfepo201.cox.net [68.230.241.146]) by ietfa.amsl.com (Postfix) with ESMTP id C143521F85EE for <6tsch@ietf.org>; Fri, 1 Mar 2013 11:42:21 -0800 (PST) Received: from fed1rmimpo305 ([68.230.241.173]) by fed1rmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130301194221.LOJS19285.fed1rmfepo201.cox.net@fed1rmimpo305> for <6tsch@ietf.org>; Fri, 1 Mar 2013 14:42:21 -0500 Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo305 with cox id 6KiL1l00c3gAAro01KiLC8; Fri, 01 Mar 2013 14:42:21 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020204.5131049D.0057,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=W9Hmo2qk c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=6t4AJK7m8D8A:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=k8pYvbRhVL0A:10 a=48vgC7mUAAAA:8 a=rbl1wQeSwIs0QDm_BuAA:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=1XBuBeO_FlPd5T-q:21 a=3Rh-E_-K3_sQRJYf:21 a=JyzrQi_NOIWKAaGf:21 a=mbYREmtDDBfCLQwKCHNpxg==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <5131049C.9020504@cox.net> Date: Fri, 01 Mar 2013 12:42:20 -0700 From: Tom Phinney User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "roll@ietf.org" , "6tsch@ietf.org" <6tsch@ietf.org> References: <20381.1362077015@sandelman.ca> <17207.1362162863@sandelman.ca> In-Reply-To: <17207.1362162863@sandelman.ca> X-Enigmail-Version: 1.1.1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-phinney-roll-rpl-industrial-applicability@tools.ietf.org" Subject: Re: [6tsch] [Roll] comments on draft-phinney-roll-rpl-industrial-applicability X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Tom Phinney 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 19:42:23 -0000 Apologies to those who receive this e-mail on more than one list.


First, the traditional industry differentiation between "factory automation" and "process control" is that factory automation is focused on discrete manufacturing steps (and thus is often referred to as "discrete parts manufacturing") while process control involves continuous processing of fluids and quasi-fluids (e.g., sand, cereal and other materials whose flow rate can be measured by a mass flowmeter).

Many real-world plants use hybrids of these two manufacturing styles. For example, a soup canning plant, or drink bottling plant (e.g., a brewery), or a dairy that bottles milk and packages ice cream, or a pharmaceutical plant, or a car tire manufacturing plant, all use continuous-flow manufacturing processes (process control) to make the raw product in batches, and discrete part manufacturing processes (factory automation) to package the product. This hybrid mode of operation is often referred to as "batch processing" and has its own terminology and set of standards that build on those of the other two manufacturing regimes. ISA, the Industrial Society for Automation, has developed standards that address both continuous process control and batch processes that are fed materials from a continuous process. (Most ISA standards then become IEC standards.)


Second, the distinction between peer/peer, client/server, publish/subscribe and source/sink is as follows:

1a) peer/peer is a 1:1 relationship of known correspondents, usually connected (i.e., a longer-term association with coordinated residual state information at both ends). This relationship can be symmetric (i.e., federation) or asymmetric (i.e., client/server).

1b) client/server is an asymmetric peer-peer relationship of "known" correspondents in which the client is always the initiator of the relationship. In cases where the provided service is transactional, the association often is more transient than in a symmetric peer-peer relationship. In this case the server may be a member of a server farm, in which case the correspondent is known by role, not device ID.

2) publish/subscribe is a 1:N relationship of known correspondents, which is best implemented as a multi-peer connection (i.e., a longer-term association with coordinated residual state information at the endpoints). Some industrial communication technologies, such as IEC 61158 Type 1 (Foundation Fieldbus H1) provide multi-peer connections within the lower four comm layers to directly support such operation. Timeliness is usually important in the publish/subscribe relationship, whether it be the timeliness of daily newspaper delivery or the timeliness of information delivery between devices acting in concert in closed-loop continuous control. As a consequence, untimely retransmission is not of significant value.

3) source/sink is a M:N relationship of unknown correspondents, which is best implemented by connectionless lower layer services. In the automation environment it is used primarily for reporting of alerts, which include a) device-local events and b) alarms about the monitored process. Alerts are reportable by every device that is involved in sensing and controlling the process -- the M of M:N -- and are reported to all devices that are interested in receiving such reports -- the N of M:N. That latter set includes all human operator workstations that are focused on the monitored process, all historians that are tracking information in the monitored process, etc. There is never a need for comm-layer-initiated retransmission of such information; other application-layer mechanisms come into play to retrieve recent reporting history from individual members of the M set when loss of a report is detected an an N endpoint. To make such loss detection and bulk recovery possible, each alert source includes a local monotonically-increasing sequence number in each alert report.

So, in summary,
1a) peer/peer is 1:1 and typically connected;
1b) client/server is 1:1 and often connected, particularly when the association is longer than a single transaction,
2) publish/subscribe is 1:N with known N, and connected in a long-term relationship;
3) source/sink is M:N with unknown M and N, and connectionless.

Typically 1a) and 1b) use unicast in each direction; 2) uses unicast in the subscriber-to-publisher direction and multicast to a publication-specific group address in the publisher-to-subscriber direction; and 3) uses multicast to a group address identifying the reported information scope (e.g., "unit_N_alerts").

-Tom
=====
On 2013.03.01 11:34, Michael Richardson wrote: 

      

        

          

            

              

                
"pthubert" == pthubert  <Pascal> writes:


              

            

          

        

      

      
    pthubert> [Pascal] Thanks for the comments : )

    pthubert> [Pascal] You are correct. The industry makes a difference
    pthubert> between Factory Automation (discrete manufacturing of
    pthubert> individual products) and Process Controls (continuous
    pthubert> production). These are really 2 different activities, and
    pthubert> Factory Automation may require much stricter behaviors for
    pthubert> very rapid operations.  At ISA, WG 11 has standardized

I guess this means that individual products are things which can come
out of a production step, and then accumulate before going into the next
step. (The kind of thing Goldratt warns us against having anywhere other
than at a CCR)

    pthubert> So, RPL could be used during phases P1, P2, P4, P5 and P6,
    pthubert> but not during P3, (Normal Operation), unless a new OF was
    pthubert> defined that interacted with the PCE?

    pthubert> [Pascal] Roughly yes, and this is the work we are starting
    pthubert> at 6TSCH. In more details, there will be flows that can
    pthubert> use distributed routing but critical flows will need the
    pthubert> PCE.

I think that we need to think about:
1) are the P1/P2/P4/P5 and P6 phases distinct in some way?
   I think that there are significant security differences between them,
   and the number of type of DAGs that need to be constructed may very
   a lot. This has implications that intermediate (storing!) nodes may
   have to have much large capacities for DAGs during non-P3 than they
   do for P3.  Or not...
   My examination of RPL code to date suggests that some of what lets it
   fit into the smallest devices is because they support only a single DAG.
   (no tables, no searches, no code to sort A from B...)

2) how do you bootstrap *securely* into P3 operation?
   Does this require a rekey?  It seems to me that it does.

    pthubert> 1) publish/subscribe, where an association exists between
    pthubert> one source and one or a few recipients, all of which are
    pthubert> identifiable, where publication is periodic within strict

So, layer-6 multicasts carried on layer-3 unicast to known
subscribers... 

    pthubert> 2) source/sink, where any of a number of sources logically
    pthubert> multicasts (however that is implemented) to a predefined

1:N multicast

    pthubert> 3) client/server or peer/peer, where all of the
    pthubert> traditional properties hold and the specialized ones
    pthubert> listed above generally do not.

and this is 1:1


    pthubert> page 13, section 2.1.4: says:

    pthubert>    With rare exception, the control algorithms used with
    pthubert> PS messaging in the process automation industries - those
    pthubert> managing continuous material flows - rely on fixed-period
    pthubert> sampling, computation and transfer of outputs, while those
    pthubert> in the factory automation industries - those managing
    pthubert> discrete manufacturing operations - rely on bounded delay
    pthubert> between sampling of inputs, control computation and
    pthubert> transfer of outputs to physical actuators that affect the
    pthubert> controlled process.

    pthubert> it seems that there are possibly two completely different
    pthubert> industrial requirements here which can not, and should
    pthubert> not, be satisfied with a single DAG.  Are two documents
    pthubert> appropriate here?

    pthubert> [Pascal] It is more than a different DAG, it is a
    pthubert> different plant... I read your question as do we want an
    pthubert> additional draft for factory automation?

So, factory automation and plant control are not present in the same
building.  When someone comes along with factory automation expertise,
they will need to write a draft.

I'm not sure why factory automation is mentioned again.
Let's just say:

Tthe control algorithms used with PS messaging in the process automation
industries - those managing continuous material flows - rely on fixed-period
sampling, computation and transfer of outputs.   As a result.. X, Y, Z.

    >> Note: Although there are known patent applications for duocast
    >> and N-cast, at the time of this writing the patent assignee,
    >> Honeywell International, has offered to permit cost-free RAND use
    >> in those industrial wireless standards that have chosen to
    >> employee the technology, under a reciprocal licensing requirement
    >> relative to that use.

    pthubert> Can we get an official IPR statement via:
    pthubert> http://www.ietf.org/ipr/file-disclosure

    pthubert> on this?  I don't think it is particularly relevant to the
    pthubert> document, but perhaps I could be wrong.

Not sure why it is mentioned then.

    pthubert> you need to update [I-D.ietf-roll-rpl] to RFC6550.

    pthubert> [Pascal] Done in 03 : )

    pthubert> 4.3.1 says:

    >> Because the actual link capacity depends on the particular link
    >> technology used within an industrial automation network
    >> deployment, the Trickle parameters are specified in terms of the
    >> link's maximum capacity for conveying link-local multicast
    >> messages.  If the link can convey m link-local multicast packets
    >> per second on average, the expected time it takes to transmit a
    >> link-local multicast packet is 1/m seconds.

    pthubert> I am pleased that a formula is being provided, but I am
    pthubert> uncomfortable that this document is not more specific to
    pthubert> actual link technology used.  Can this document pick 1-2
    pthubert> actual link technologies and deal with them?

    pthubert> [Pascal] We are working on those concepts at 6TSCH, ccing
    pthubert> the ML.

But, wait. 6tsch is important for P3 only.
The other phases need to have something written down.
I think it's pretty important to have some concrete numbers for some
actual technologies that actually are being deployed.    Without that,
it's pretty hard for academics to run simulations, or for people
thinking about RPL extensions in field X to think how this might work
(or not) in another field they aren't an expert in.

Also, we need that set of layer 2s to be listed so that the security
requirements of layer 2 can be expressed.  Again, non-P3 vs P3 might
require a rekey.

    pthubert> 5.:
    >> The possibility of dynamically updating the metrics in use in the
    >> network as well as the frequency of network updates allows
    >> deployment characteristics (e.g., network density) to be
    >> discovered during network bring-up and to be used to tailor
    >> network parameters once the network is operational rather than
    >> having to rely on precise pre- configuration.  This also allows
    >> the network parameters and the overall routing protocol behavior
    >> to evolve during the lifetime of the network.

   mcr> I don't know how this discovery is going to occur.
   mcr> Someone trying to build a sensor that is going to satisfy
   mcr> an RFP for devices to work in a network envisioned by this
   mcr> document needs to know what to include in their code base.
   mcr> As the code space is very finite, they need to know
   mcr> exactly what is important here.

    pthubert> [Pascal] Finding the values for parameters is more of a
    pthubert> deployment issue, so I read your question as 'which
    pthubert> parameters are critical for the device to operate in
    pthubert> industrial environment and which range for those
    pthubert> parameters'. Again, work at 6TSCH may help.

Yes, that's what I'm saying.

The text talks about "dynamically updating the metrics in use"

That says to me that it's not about the values of the metrics, but in
changing which metrics are used.



    

  


From mcr@sandelman.ca  Fri Mar  1 12:04:48 2013
Return-Path: 
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 7EAB121E80C6; Fri,  1 Mar 2013 12:04:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZXd8QP3IMfV; Fri,  1 Mar 2013 12:04:47 -0800 (PST)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04E21E803F; Fri,  1 Mar 2013 12:04:47 -0800 (PST)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id A877F20168; Fri,  1 Mar 2013 15:11:55 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 2940463A5C; Fri,  1 Mar 2013 15:03:25 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 186C363A5B; Fri,  1 Mar 2013 15:03:25 -0500 (EST)
From: Michael Richardson 
To: "roll@ietf.org" , "6tsch@ietf.org" <6tsch@ietf.org>
In-Reply-To: <5131049C.9020504@cox.net>
References: <20381.1362077015@sandelman.ca>  <17207.1362162863@sandelman.ca> <5131049C.9020504@cox.net>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Subject: Re: [6tsch] [Roll] comments on draft-phinney-roll-rpl-industrial-applicability
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Mar 2013 20:04:48 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Tom" =3D=3D Tom Phinney  writes:
    Tom>    Apologies to those who receive this e-mail on more than one
    Tom> list.  First, the traditional industry differentiation between
    Tom> "factory automation" and "process control" is that factory
    Tom> automation is focused on discrete manufacturing steps (and thus
    Tom> is often referred to as "discrete parts manufacturing") while
    Tom> process control involves continuous processing of fluids and
    Tom> quasi-fluids (e.g., sand, cereal and other materials whose flow
    Tom> rate can be measured by a mass flowmeter).  Many real-world
    Tom> plants use hybrids of these two manufacturing styles.=20=20

So, given that many plants are hybrids, are you saying that this
document applies only to the process control parts of the plant?

Or that hybrid plants are also out of scope?

If there are scope constraints, what exactly are they?=20

What happens in a hydrid plant might be significantly more complicated,
as it involves two kinds of networks; if there is a desire to have the
different pieces interconnected.

=2D-=20
]               Never tell me the odds!                 | ipv6 mesh network=
s [=20
]   Michael Richardson, Sandelman Software Works        | network architect=
  [=20
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails  =
  [=20
=09

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQCVAwUAUTEJjYqHRg3pndX9AQIyNwQArn+lzUGyYsGzUEG8z2+EBJsB+kEK2zDF
7yQpOo1smDzD1RXoSGqExH9ktyaiM/twHuvi2Ua4IsQOIpz+Ya6MN8UMy0Ef7E/2
HZe+CauGk+lYZTxK4FmxO6bCzpaRRtXtKMuQz5bAHbE/Z5VyS13ypH36BKgMx2nI
k2YDnoIiJkg=
=Ra17
-----END PGP SIGNATURE-----
--=-=-=--

From qinwang@berkeley.edu  Fri Mar  1 12:09:09 2013
Return-Path: 
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 62A5621F8E0E for <6tsch@ietfa.amsl.com>; Fri,  1 Mar 2013 12:09:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.211
X-Spam-Level: 
X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.388,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVMewFRGFrse for <6tsch@ietfa.amsl.com>; Fri,  1 Mar 2013 12:09:08 -0800 (PST)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBDA21F8E09 for <6tsch@ietf.org>; Fri,  1 Mar 2013 12:09:08 -0800 (PST)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UBWGP-0004y7-3N; Fri, 01 Mar 2013 12:09:06 -0800
Received: from 136.152.36.142 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 1 Mar 2013 12:09:05 -0800
Message-ID: <5b22240b87d48b6314c835aa4b701dc0.squirrel@calmail.berkeley.edu>
In-Reply-To: <25024.1362165522@sandelman.ca>
References: <512C36F4.4000409@eecs.berkeley.edu> <512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com>   <25024.1362165522@sandelman.ca>
Date: Fri, 1 Mar 2013 12:09:05 -0800
From: "Qin Wang" 
To: "Michael Richardson" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Mar 2013 20:09:09 -0000

"inverse mux" is a good word to describe 6tus. I would like to connect a
Mux with the inverse mux. They together work as follows.

(1)Upper layer (e.g. RPL) push message to 6tus, as input of Inverse Mux,
with information like DestAddr, Priority,....

(2)"Inverse Mux" Function, according to some rule, push the message into
corresponding Queue/Bundle/..., i.e. input of Mux.

(3)"Mux" Funtion, according to some rule, feed the packets in different
Queues/Bundles into TSCH. The reason for using Mux is that there is only
one communication action in one slot at most.

Does it make sense?

Qin






>
>>>>>> "pthubert" == pthubert   writes:
>     pthubert> Fact is, we need a name for what you call a logical
>     pthubert> channel. A name that is not already overloaded 4
>     pthubert> times. I'd suggest something like a bundle.
>
>     pthubert> A bundle would be an aggregation of time slots of equal
>     pthubert> properties. A link (what IPv6 sees) becomes a set of
>     pthubert> bundles. Depending on priority, flow, multicast
>     pthubert> etc... when IP pushes a pack to a link, 6TUS will have to
>     pthubert> find which bundle within a link maps the criteria for that
>     pthubert> packet.
>
> Basically this is kinda an inverse mux.
> Generally, the bigger thing is called an aggregate.
>
> It's also a construction term:
>      http://en.wikipedia.org/wiki/Construction_aggregate
>
> so, if it's an unloaded word you want, why not pick one of: sand,
> gravel, stone, slag, ....  I note that it says:
>
>   "aggregates are used as a stable foundation or road/rail base with
>   predictable, uniform properties"
>
> which seems exactly what we are trying to get...
>
>
> --
> Michael Richardson , Sandelman Software Works
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From tom.phinney@cox.net  Fri Mar  1 13:32:08 2013
Return-Path: 
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 7B8B921F8870 for <6tsch@ietfa.amsl.com>; Fri,  1 Mar 2013 13:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[AWL=0.157,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wK8yAymlUq0 for <6tsch@ietfa.amsl.com>; Fri,  1 Mar 2013 13:32:07 -0800 (PST)
Received: from fed1rmfepo202.cox.net (fed1rmfepo202.cox.net [68.230.241.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9409E21F8B88 for <6tsch@ietf.org>; Fri,  1 Mar 2013 13:32:07 -0800 (PST)
Received: from fed1rmimpo210 ([68.230.241.161]) by fed1rmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130301213202.GZGB1243.fed1rmfepo202.cox.net@fed1rmimpo210> for <6tsch@ietf.org>; Fri, 1 Mar 2013 16:32:02 -0500
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo210 with cox id 6MY01l00M3gAAro01MY2dl; Fri, 01 Mar 2013 16:32:02 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020206.51311E52.008D,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=Q80MFfKa c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=fUqkgGA-opkA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=kefdhCRHuhUA:10 a=48vgC7mUAAAA:8 a=7fnSsO-jmgmup-exoxwA:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=4vB-4DCPJfMA:10 a=lZB815dzVvQA:10 a=2u8-7BD2COMLsqic:21 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <51311E50.7010604@cox.net>
Date: Fri, 01 Mar 2013 14:32:00 -0700
From: Tom Phinney 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "roll@ietf.org" , "6tsch@ietf.org" <6tsch@ietf.org>
References: <20381.1362077015@sandelman.ca>		<17207.1362162863@sandelman.ca> <5131049C.9020504@cox.net> <795.1362168205@sandelman.ca>
In-Reply-To: <795.1362168205@sandelman.ca>
X-Enigmail-Version: 1.1.1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [6tsch] [Roll] comments on	draft-phinney-roll-rpl-industrial-applicability
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney 
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Mar 2013 21:32:08 -0000



  
    
  
  
    The continuous and discrete manufacturing parts
      of hybrid manufacturing plants are ALWAYS connected; it would be
      pointless to build such a plant if that were not the case.

      

      It is useful to consider the differences. Continuous processes use
      closed-loop control based on fixed-period process sampling and
      outputs to process actuators. The highest frequency of such
      control loops is usually 4 H, though a few compressor surge
      control loops that operate at a 9 Hz to 11 Hz rate may also be
      present. These process control systems are potential users of
      wireless communications because their fixed timing is compatible
      (in theory) with TSCH-like time schedules.

      

      It is important to understand that the publish-subscribe messaging
      used for process automation does not require 100% delivery. The
      control algorithms traditionally are designed to tolerate the loss
      of three or fewer consecutive messages before receiving another
      message in the series. However, typically loss of four consecutive
      messages triggers the equipment to shift to a fallback control
      strategy. It is this statistic that leads to use of duocast (with
      its approximate squaring of message loss rates) for high-speed
      loops, since most plant managers will not tolerate more than one
      such shift to a fallback control strategy per year, per plant, and
      there can be thousands of 1 Hz and 4 Hz control loops operating in
      the plant.

      

      Discrete processes use a different form of control that is cyclic
      but not periodic. This is usually implemented in PLCs
      (programmable logic controllers) that execute a
      variable-execution-duration program that repeats as soon as it
      finishes each iteration, leading to cyclic but aperiodic behavior.
      The duration of each execution cycle is usually a few ms,
      typically 3 ms to 10 ms, with a perhaps 50% maximum variance in
      cycle-to-cycle.execution time. The
      messaging involved in such automation typically require higher
      data rates than those offered by IEEE 802.15.4, and any wireless
      messaging itself would typically be single-hop, from a
      router/local-controller that is part of the manufacturing device
      to multiple wireless backbone routers arranged high on opposite
      walls in a roofed factory. High-data-rate optical signaling would
      be a good match for this communication.

      

      The variance in cycle-to-cycle times provides a significant
      challenge for comm technologies based on scheduled pairing of
      senders and receivers. That, coupled with the typically single-hop
      aspect of the communication, makes it likely that a non-TSCH
      approach will be optimal for such systems.

      

      The communication between the continuous process controllers of a
      plant and the discrete automation controllers typically occurs on
      a 100 Mbit/s or faster backbone comm link. Wireless is not
      involved, and there is no reason to anticipate that it will be in
      the future. Since the physical systems that implement the
      continuous and discrete processes are interconnected (e.g., pipes
      with valves connected to bottle handling-and-filling apparatus in
      a soda bottling plant), wired interconnection between backbone
      controllers is typically not a significant issue.

      

      I hope that the above discussion helps understand the differences
      in operating mode, timescales, comm needs and other high-level
      aspects of the continuous and discrete portions of a hybrid plant.
      There are others receiving this e-mail who are much more familiar
      with such plants and processes than I, so if I have erred
      substantially, I trust that they will post a correction to this
      list.

      

      -Tom

      =====

    On 2013.03.01 13:03, Michael Richardson wrote:
    

      

      

        

          

            

              

                
"Tom" == Tom Phinney <tom.phinney@cox.net> writes:


              

            

          

        

      

      
    Tom>    Apologies to those who receive this e-mail on more than one
    Tom> list.  First, the traditional industry differentiation between
    Tom> "factory automation" and "process control" is that factory
    Tom> automation is focused on discrete manufacturing steps (and thus
    Tom> is often referred to as "discrete parts manufacturing") while
    Tom> process control involves continuous processing of fluids and
    Tom> quasi-fluids (e.g., sand, cereal and other materials whose flow
    Tom> rate can be measured by a mass flowmeter).  Many real-world
    Tom> plants use hybrids of these two manufacturing styles.  

So, given that many plants are hybrids, are you saying that this
document applies only to the process control parts of the plant?

Or that hybrid plants are also out of scope?

If there are scope constraints, what exactly are they? 

What happens in a hydrid plant might be significantly more complicated,
as it involves two kinds of networks; if there is a desire to have the
different pieces interconnected.



      

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


    

  


From mcr@sandelman.ca  Sat Mar  2 08:54:50 2013
Return-Path: 
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 072E421F8540; Sat,  2 Mar 2013 08:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtpFAOex4pGU; Sat,  2 Mar 2013 08:54:49 -0800 (PST)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDE321F8519; Sat,  2 Mar 2013 08:54:49 -0800 (PST)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 763AB20168; Sat,  2 Mar 2013 12:02:09 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 640A463A5B; Sat,  2 Mar 2013 11:53:35 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 554D663769; Sat,  2 Mar 2013 11:53:35 -0500 (EST)
From: Michael Richardson 
To: "roll@ietf.org" , "6tsch@ietf.org" <6tsch@ietf.org>
In-Reply-To: 
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Subject: Re: [6tsch] [Roll] comments on draft-phinney-roll-rpl-industrial-applicability
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Mar 2013 16:54:50 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Tom" =3D=3D Tom Phinney  writes:
    Tom> variance in cycle-to-cycle.execution time. The messaging
    Tom> involved in such automation typically require higher data rates
    Tom> than those offered by IEEE 802.15.4, and any wireless messaging

...

    Tom>    The communication between the continuous process controllers
    Tom> of a plant and the discrete automation controllers typically
    Tom> occurs on a 100 Mbit/s or faster backbone comm link. Wireless
    Tom> is not involved, and there is no reason to anticipate that it

mcr> So, given that many plants are hybrids, are you saying that
mcr> this document applies only to the process control parts of the
mcr> plant?

So, I take it that you are agreeing with this statement.

And disagreeing that "hybrid plants are also out of scope", because
all process plants have a factory automation component, but that the
factory automation component is out of scope.

Further, you have made it clear that there is no direct interconnection
between the two networks.

=2D-=20
Michael Richardson , Sandelman Software Works=20
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQCVAwUAUTIuj4qHRg3pndX9AQIK1gQAkEmBHYT3UGjnTRR52unzFjwlwAqwOrpP
wtY5A8Xbkarnh5e/oT+H6iypdseFpGG27C3i7prMV0UAW4pYgKav9XH1eWiKc4uq
Zld0bb79l54Rr5pS9AkFb0AaygszyIXHVhB3fYxOB4/vhlzcaoiVmyaHPqX8tEPL
H4HeM79YCuk=
=uN1v
-----END PGP SIGNATURE-----
--=-=-=--

From tom.phinney@cox.net  Sat Mar  2 09:59:18 2013
Return-Path: 
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 ED3F821F8505 for <6tsch@ietfa.amsl.com>; Sat,  2 Mar 2013 09:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Level: 
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.877,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chRW40093k8Z for <6tsch@ietfa.amsl.com>; Sat,  2 Mar 2013 09:59:18 -0800 (PST)
Received: from fed1rmfepo202.cox.net (fed1rmfepo202.cox.net [68.230.241.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEDF21F84BE for <6tsch@ietf.org>; Sat,  2 Mar 2013 09:59:12 -0800 (PST)
Received: from fed1rmimpo209 ([68.230.241.160]) by fed1rmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130302175851.XNNC1243.fed1rmfepo202.cox.net@fed1rmimpo209> for <6tsch@ietf.org>; Sat, 2 Mar 2013 12:58:51 -0500
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo209 with cox id 6hyr1l0093gAAro01hyrgr; Sat, 02 Mar 2013 12:58:51 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020201.51323DDB.0094,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=SfMpgItu c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=mu-2PAB6mIwA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=zKXdt2971PUA:10 a=OyP9-m7eLojCRTrj5WcA:9 a=QEXdDO2ut3YA:10 a=4vB-4DCPJfMA:10 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <51323DDA.6050301@cox.net>
Date: Sat, 02 Mar 2013 10:58:50 -0700
From: Tom Phinney 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "roll@ietf.org" , "6tsch@ietf.org" <6tsch@ietf.org>
References: <29193.1362243215@sandelman.ca>
In-Reply-To: <29193.1362243215@sandelman.ca>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [6tsch] [Roll] comments on draft-phinney-roll-rpl-industrial-applicability
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney 
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Mar 2013 17:59:19 -0000

On 2013.03.02 09:53, Michael Richardson wrote:
>>>>>> "Tom" == Tom Phinney  writes:
>     Tom> variance in cycle-to-cycle.execution time. The messaging
>     Tom> involved in such automation typically require higher data rates
>     Tom> than those offered by IEEE 802.15.4, and any wireless messaging
>
> ...
>
>     Tom>    The communication between the continuous process controllers
>     Tom> of a plant and the discrete automation controllers typically
>     Tom> occurs on a 100 Mbit/s or faster backbone comm link. Wireless
>     Tom> is not involved, and there is no reason to anticipate that it
>
> mcr> So, given that many plants are hybrids, are you saying that
> mcr> this document applies only to the process control parts of the
> mcr> plant?
>
> So, I take it that you are agreeing with this statement.
Essentially yes. While the higher-layer parts of industrial wireless
protocols such as WirelessHART and ISA-100.11a are more-or-less suitable
for use in the factory automation environment, in general the time
scales of required reporting and action are such that IEEE 802.15.4 will
not be appropriate. Of course there may be some parts of the plant, such
as mechanical interlocks against human intrusion, that are workable with
a 100 ms or 250 ms or even 1 s reporting delay, but that will not be
true for limit switches and other such devices in factory automation
lines that typically must report every few ms.
> And disagreeing that "hybrid plants are also out of scope", because
> all process plants have a factory automation component, but that the
> factory automation component is out of scope.
Essentially yes, because the ROLL/RPL mechanism is focused on
self-organizing multi-hop networks where significant variance in
reporting delays is generally tolerable. The portions of process
automation networks where tight time constraints apply are typically one
hop off the backbone, so ROLL/RPL would be used only for self-organizing
system startup or recover after a plant disaster (e.g., explosion, fire,
tornado tearing up the plant, etc.). Likewise for most factory
automation systems, due to the information timeliness demands of the
PLCs that typically automate such processes.
> Further, you have made it clear that there is no direct interconnection
> between the two networks.
If you don't consider a wired Ethernet connection between routers to be
a direct connection, then that must be the case. I personally would not
phrase it that way; rather, the two networks do not interact directly in
their network organization, although their members communicate as
directly as their differing communications technologies permit.

Note that this is also true for IEEE 802.15.4 systems that communicate
with 802.11 systems; their networks do not interact directly in their
network organization, even though they use the same spectral RF band in
the same 3D spatial region. This is particularly the case where ETSI 300
328 v1.8.1 applies, since the process system may have to use at least
fifteen IEEE 802.15.4 channels when the distances involved require
operation at greater than 10 dBm EIRP and timeliness considerations do
not permit indefinitely-repeated deferral to ongoing IEEE 802.11
transmissions.


From pascal.thubert@gmail.com  Sun Mar  3 08:06:11 2013
Return-Path: 
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 42AD821F871C for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 08:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+0628xzjQB8 for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 08:06:10 -0800 (PST)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F04C921F8717 for <6tsch@ietf.org>; Sun,  3 Mar 2013 08:06:07 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id fe20so4293204lab.1 for <6tsch@ietf.org>; Sun, 03 Mar 2013 08:06:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=PJ2SO3An/p7fqJycktM5m3+7CKwPJ9NtSGeGCGN8aAY=; b=T4QfAIcSGh+IJCbHs9CkEfpogH7lmZirtW1neY/fX1SerRwbbCxOuDMiLRHI0b6M5P Bq7HsiqyqKWCJPq7J/skGItCgWGpU0VQxDGQ/L/Y90KngDdyjorag5FgTWwXVJarmfo9 Qo/IpJKM8eBufFoZ3NlqtHS60UFupfpyLRjxz6EGlCJCsI3Up/DcYx4+ACCWc0UnL9s1 XCDviKfnBqKvY5KmV6pIHQIRfsGKVgXfDP6uVZyWJQvMkHl7t++zIM4Z9P/+eJo/dby6 OhdBFFHh7cmb6Qw5CR07x5DLYmIaw7c+/f4K+WasnFZ76WZCclfLJRvnpzBhofGmXCL4 UEDQ==
MIME-Version: 1.0
X-Received: by 10.112.9.10 with SMTP id v10mr3390879lba.47.1362326766664; Sun, 03 Mar 2013 08:06:06 -0800 (PST)
Received: by 10.112.27.39 with HTTP; Sun, 3 Mar 2013 08:06:06 -0800 (PST)
In-Reply-To: <9b80b0914c7559ac2b8fd46bd2f7a0c5.squirrel@calmail.berkeley.edu>
References: <512C36F4.4000409@eecs.berkeley.edu> <512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com>   <4b8fab46a18b44f897b740a9b9bcd7bf.squirrel@calmail.berkeley.edu>  <9b80b0914c7559ac2b8fd46bd2f7a0c5.squirrel@calmail.berkeley.edu>
Date: Sun, 3 Mar 2013 17:06:06 +0100
Message-ID: 
From: Pascal Thubert 
To: Qin Wang 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 03 Mar 2013 16:06:11 -0000

Hi Qin and Thomas:

A path in my mind denotes a set of consecutive hops that a packet may
take to go from A to B. Seems similar to route though the route is a
particular selection of candidate paths.
I think you're using path as a one hop thing. So we'll have to agree
but let us make sure that we select words that are specific and
reflect the image we want to give.

By link I want to stay close to what RPL and AUTOCONF agreed upon,
which is whatever my radio can reach. It is a one hop thing. What a
link really represents is still open. We could decide to divide the
radio in multiple subinterfaces, each one being a different link for
IP. But it seems that we are not taking that direction so far, and
that the radio interface is one link that connects to some parents and
some children, and has unicast and broadcast capabilities.

Behind the IP scene, the link is divided in time slots of different
properties. I suggested to group time slots of an exact same set of
properties as a bundle (of time slots). There would be receive bundles
from parents and children, and unicast transmission bundles to the
parents and children. And there would be at least one multicast
transmission bundle which is the one Qin is discussing.

This is what I had in mind...

Pascal

2013/3/1 Qin Wang :
> Thomas,
>
> In the discussion, "broadcast channel" is used, which is not defined very
> clear. In the context of TSCH, "Channel" already has specific meaning, no
> matter "physical channel" or "logic channel". So, we need some word to
> denote "broadcast channel", i.e. a set of links, on which one node is in
> Tx mode, neighbors are in Rx mode.
>
> So, for me, "a bundle" is same as "a path with broadcast feature".
>
> How do you think?
>
> Qin
>
>
>
>
>> Pascal, Qin,
>>
>> Quick clarifying question: what would the difference be between a bundle
>> and a path? The latter is defined as the set of links between
>> two neighbors. I guess one major difference is QoS. In that case, would =
a
>> bundle be equivalent to "path between A and B on slotframe 5"?
>>
>> Thomas
>>
>>
>> On Fri, Mar 1, 2013 at 8:54 AM, Qin Wang  wrote:
>>
>>> Pascal,
>>>
>>> Thank you for your comments. Very good point. Right now, I have not ver=
y
>>> good answer for it. But I think it should be answered in the 6tus draft=
.
>>>
>>> Qin
>>>
>>>
>>>
>>> > I agree Qin,
>>> >
>>> > Fact is, we need a name for what you call a logical channel. A name
>>> that
>>> > is not already overloaded 4 times. I'd suggest something like a
>>> bundle.
>>> >
>>> > A bundle would be an aggregation of time slots of equal properties. A
>>> link
>>> > (what IPv6 sees) becomes a set of bundles. Depending on priority,
>>> flow,
>>> > multicast etc... when IP pushes a pack to a link, 6TUS will have to
>>> find
>>> > which bundle within a link maps the criteria for that packet.
>>> >
>>> > The question becomes what (opaque) info the IP layer needs to pass to
>>> > 6TUS. And whether that information comes all form the packet or if fo=
r
>>> > instance the incoming bundle for a packet is already informative
>>> enough.
>>> >
>>> > On the side:
>>> > - the physical size of a bundle can be dynamic as you suggested
>>> earlier,
>>> > unless we are talking to hard reservation.
>>> > - but then we have to define a fallback bundle for an dynamic bundle
>>> that
>>> > is temporarily overflowing.
>>> >
>>> > Cheers,
>>> >
>>> > Pascal
>>> >
>>> > -----Original Message-----
>>> > From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behal=
f
>>> Of
>>> > Qin Wang
>>> > Sent: jeudi 28 f=E9vrier 2013 19:40
>>> > To: Alfredo Grieco
>>> > Cc: 6tsch@ietf.org; 'Xavier Vilajosana'
>>> > Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH
>>> >
>>> > Hi Alfredo,
>>> >
>>> > When you say "primary broadcast channel", you mean a physical or
>>> logical
>>> > channel, for example one of the 16 channels in 2.4GHz band, or a set
>>> of
>>> > links among neighbors?
>>> >
>>> > I think using a set of links as broadcast channel, instead of a fixed
>>> > physical or logic channel, is more flexible and bandwidth efficient.
>>> How
>>> > do you think?
>>> >
>>> > Qin
>>> >
>>> >
>>> >> Hi Xavi and all,
>>> >>
>>> >> Sorry for the delayed reply.
>>> >>
>>> >> I agree that I broadcast channel is required. I was wondering that i=
f
>>> >> we set up a broadcast channel, its bandwidth should scale with the
>>> >> size of the network. The more node the more the signaling to be sent
>>> >> in broadcast.
>>> >>
>>> >> Should we imagine a primary broadcast channel that convey also the
>>> >> information to signal the presence of further additional broadcast
>>> >> channels ?
>>> >>
>>> >> Cheers
>>> >>
>>> >> Alfredo
>>> >>
>>> >> -----Messaggio originale-----
>>> >> Da: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] Per conto
>>> >> di Xavier Vilajosana
>>> >> Inviato: Tuesday, February 26, 2013 5:16 AM
>>> >> A: 6tsch@ietf.org
>>> >> Oggetto: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>>> >>
>>> >> Hi,
>>> >>
>>> >> I have a question that i want to discuss, the question is whether we
>>> >> need a broadcast channel in TSCH or not and what kind of support 6tu=
s
>>> >> should provide. (the answer can be depends... but lets see some
>>> cases)
>>> >>
>>> >> a) ADV need broadcast channels in case they are used to synchronize
>>> >> the network. IEEE 802.15.4e provides the timekeeping flag to set tha=
t
>>> >> channels as used for synchronization and shared flag can make them
>>> >> broadcast.
>>> >> b) Those networks that do not need ADV for synchronization then can
>>> >> use any TX link for ADV, this means that if it is not shared only th=
e
>>> >> node listening on that link will get the ADV. However as this
>>> >> periodically occurs the ADV might eventually be listened in all
>>> >> channels.
>>> >> c)Some DAOs and all DIOs require a broadcast channel. Should the
>>> >> schedule provide that? in case of a), can the same link be used? How
>>> >> this link should be installed in the nodes?
>>> >> d)Is the scheduler of the network who should setup a broadcast
>>> channel
>>> >> independent of the broadcast channel set for ADV? can it be the same=
?
>>> >> Or in contrast, 6tus can configure the EB so it indicates a broadcas=
t
>>> >> channel..
>>> >> e)..
>>> >>
>>> >> I would like to know what is your opinion on that.
>>> >>
>>> >> cheers!
>>> >> Xavi
>>> >> _______________________________________________
>>> >> 6tsch mailing list
>>> >> 6tsch@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/6tsch
>>> >>
>>> >> _______________________________________________
>>> >> 6tsch mailing list
>>> >> 6tsch@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/6tsch
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > 6tsch mailing list
>>> > 6tsch@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/6tsch
>>> >
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch



--=20
Pascal

From mcr@sandelman.ca  Sun Mar  3 14:01:20 2013
Return-Path: 
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 0166721F8825 for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 14:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 vR0jVJyliDnC for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 14:01:19 -0800 (PST)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 686C521F8807 for <6tsch@ietf.org>; Sun,  3 Mar 2013 14:01:19 -0800 (PST)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5D28720168 for <6tsch@ietf.org>; Sun,  3 Mar 2013 17:08:45 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 864A310473; Sun,  3 Mar 2013 17:00:06 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 78D32251E5 for <6tsch@ietf.org>; Sun,  3 Mar 2013 17:00:06 -0500 (EST)
From: Michael Richardson 
To: "6tsch@ietf.org" <6tsch@ietf.org>
In-Reply-To: <5b22240b87d48b6314c835aa4b701dc0.squirrel@calmail.berkeley.edu>
References: <512C36F4.4000409@eecs.berkeley.edu> <512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com>   <25024.1362165522@sandelman.ca> <5b22240b87d48b6314c835aa4b701dc0.squirrel@calmail.berkeley.edu>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 03 Mar 2013 22:01:20 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Qin" =3D=3D Qin Wang  writes:
    Qin> "inverse mux" is a good word to describe 6tus. I would like to
    Qin> connect a Mux with the inverse mux. They together work as
    Qin> follows.

    Qin> (1)Upper layer (e.g. RPL) push message to 6tus, as input of
    Qin> Inverse Mux, with information like DestAddr, Priority,....

    Qin> (2)"Inverse Mux" Function, according to some rule, push the
    Qin> message into corresponding Queue/Bundle/..., i.e. input of Mux.

    Qin> (3)"Mux" Funtion, according to some rule, feed the packets in
    Qin> different Queues/Bundles into TSCH. The reason for using Mux is
    Qin> that there is only one communication action in one slot at
    Qin> most.

    Qin> Does it make sense?

Do you put the inverse MUX above or below the 6lowpan fragmentation
layer?  Can different 6lowpan fragments travel on different slots?





=2D-=20
Michael Richardson , Sandelman Software Works=20



--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQCVAwUAUTPH5oqHRg3pndX9AQLqegP9Gf+v/JGK7O9WVpfDI1+TTDSM497D9UUw
0EMxRvS8h1BtRd8EwCEyfJwG5+XjVjjL5vqJdob0sLhEZZPPE+Qj5x84UnKjX0+s
0IhVeq4e0tjikNPNWRdnnqZzc0wTSTFey/4vweMIgNwdf0sGugM8E8nWSuVnoQ3F
D4Ith5s7pL4=
=a7EV
-----END PGP SIGNATURE-----
--=-=-=--

From twatteyne@gmail.com  Sun Mar  3 15:56:55 2013
Return-Path: 
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 0436C21F88E6 for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 15:56:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.377
X-Spam-Level: 
X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 9csavCld3V+h for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 15:56:54 -0800 (PST)
Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2B821F88E1 for <6tsch@ietf.org>; Sun,  3 Mar 2013 15:56:51 -0800 (PST)
Received: by mail-pb0-f52.google.com with SMTP id ma3so2725964pbc.11 for <6tsch@ietf.org>; Sun, 03 Mar 2013 15:56:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=GgHnt5H31xsuOPzq0Aext0yCzOmSAEV+KNH2I2QqDas=; b=l+1ubemw7KDMSLupVqYEpWTvBxbw7HvTlccKxcge5NGzmFk5oedR8tWw0PymJf18Xi BKjEkXS2EJ9fGK9c7E/AJzEgPMgrc86KIg4GQ5C2eGCNbgC0rtFx4PKfzwKtQhnqBzg2 VeHXW1XSMuGnXHDGrZvFVBM6l3er8Fggeo0W2qE6zzybrFwWCdXVhcL0rnHdytAEege8 0AzZt1IBek6fK0l/wIwYjuzgsf2cnV+51ifcKRYJtJRtwUe8N7AUZm0jLEIhRgmCUx19 XKB7ggnACnLXRkmMUhBRfxv6/iIL/J0rRUQvqa7QN0PeCoiUoG/6Y137NDesHBo2/MZ3 yWug==
MIME-Version: 1.0
X-Received: by 10.66.232.228 with SMTP id tr4mr21544658pac.38.1362355010876; Sun, 03 Mar 2013 15:56:50 -0800 (PST)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Sun, 3 Mar 2013 15:56:50 -0800 (PST)
Date: Sun, 3 Mar 2013 15:56:50 -0800
X-Google-Sender-Auth: mIvLuRTg11ard1Pu6bH7CxRZstQ
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b111da37b3a6e04d70dfe98
Subject: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 03 Mar 2013 23:56:55 -0000

--047d7b111da37b3a6e04d70dfe98
Content-Type: text/plain; charset=ISO-8859-1

All,

>From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
thread, it appears apparent that the IEEE802.15.4e standard uses terms
which are confusing, especially when taken into a broader context.

For example:
- "link"
   . in IEEE802.15.4e: "single slot scheduled from A to B"
   . general definition: generic term for single-hop connection, often
related to broadcast domain
- "path"
   . IEEE802.15.4e: "group of links between A and B"
   . general definition: multi-hop route between source and destination.

We are often confused ourselves at those "colliding" definitions, so I
believe there is a need to provide some definitions. This can be done as
part of a next revision of
http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or
some other draft if considered appropriate by the group.

What follows is a number of terms, and tentative definitions. Let's
edit/circulate this e-mail for a couple of days, then decide what makes it
into the official definitions list.

- slot:
   - A timeslot in the TSCH schedule. A slot can be scheduled or
unscheduled. During an *unscheduled* slot, the node does not communicate.
When a slot is *scheduled*, it is assigned a slotframe, it is assigned a
neighbor address (which can be the broadcast address), and one of more of
the following flags: TX, RX, shared, timeskeeping, hard. A *broadcast *slot
is an alias for "a scheduled slot with neighbor address the broadcast
address".
   - note: this term would replace the term "link" in the IEEE802.15.4e
standard.
- bundle:
   - A group of equivalent scheduled slots, i.e. slots which are scheduled,
on the same slotframe, with the same neighbor and with the same flags. The *
size* of the bundle refers to the number of slots it contains. Given the
length of the slotframe, the size of the bundle translates directly into
reserved bandwidth.
- (inversed) mux:
   - *Qin*, would you mind giving a tentative definition here?

Thomas

--047d7b111da37b3a6e04d70dfe98
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

All,


For example:
- "link"
=A0 =A0. in IEEE802.15.4e: "single slot scheduled =
from A to B"




=A0 =A0. general definition: gen=
eric term for single-hop connection, often related to broadcast domain



- "path"
<=
div>=A0 =A0. IEEE802.15.4e: "gro=
up of links between A and B"
=A0 =A0. general definition: multi-hop route between source a=
nd destination.





We are often confused ourselves at those "=
colliding" definitions, so I believe there is a need to provide some d=
efinitions. This can be done as part of a next revision of=A0http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-0=
1, or some other draft if considered appropriate by the group.




What follows is a number of terms, and tentativ=
e definitions. Let's edit/circulate this e-mail for a couple of days, t=
hen decide what makes it into the official definitions list.





- slot:
=A0 =A0- A timeslot in the TSCH schedule. A slot can be sch=
eduled or unscheduled. During an unscheduled slot, the node does not=
 communicate. When a slot is scheduled, it is assigned a slotframe, =
it is assigned a neighbor address (which can be the broadcast address), and=
 one of more of the following flags: TX, RX, shared, timeskeeping, hard. A =
broadcast slot is an alias for "a scheduled slot with neighbor =
address the broadcast address".




=A0 =A0- note: this term would r=
eplace the term "link" in the IEEE802.15.4e standard.
- bundle:
=A0 =A0- A group of equivalent scheduled =
slots, i.e. slots which are scheduled, on the same slotframe, with the same=
 neighbor and with the same flags. The size of the bundle refers to =
the number of slots it contains. Given the length of the slotframe, the siz=
e of the bundle translates directly into reserved bandwidth.


- (inversed) mux:
=A0 =A0- Qin, would you min=
d giving a tentative definition here?



Thomas






--047d7b111da37b3a6e04d70dfe98--

From pascal.thubert@gmail.com  Sun Mar  3 22:29:32 2013
Return-Path: 
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 6F2C321F85AD for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 22:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1]
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 mMYT7-IgJnvB for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 22:29:28 -0800 (PST)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0D97E21F85AC for <6tsch@ietf.org>; Sun,  3 Mar 2013 22:29:27 -0800 (PST)
Received: by mail-lb0-f177.google.com with SMTP id go11so3688415lbb.36 for <6tsch@ietf.org>; Sun, 03 Mar 2013 22:29:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sPZ49ejD6WS6Oha7ZiRrMkBVR5OBQ+X7tHG+JDb8V2I=; b=kDl5O69cI22OOCk4nba2XIhAY5pNGNK9cD9Mv8wj77UFJnxrVNzLeZDYTvae61sSG/ pk07y3/KyEvUkzdCULLA08bsKnJ4tBlIfqZ3yR1ApyaJySh09pCJAW/LEKuESarqBG8q o5n7wXDh+wdj+c/7usVOx7sfBwz1TTxOhXGQBQwSdqo15NUj2IkM43LrXE2ylqzg/RRN u+mj5Hk+YmUE1/FkDNNzIMsMzz5yzcRHpkwi8+vmjY0ZpFv8B8CI0ihFYo4sM01voqHu 2gzaDu3YhSbFDD66yCw9PB569TcDNyLuDOKxoWtpsDhiqEOuFLyWqukjG/RucTAwqqPe SsmQ==
MIME-Version: 1.0
X-Received: by 10.152.46.17 with SMTP id r17mr16866778lam.47.1362378566896; Sun, 03 Mar 2013 22:29:26 -0800 (PST)
Received: by 10.112.27.39 with HTTP; Sun, 3 Mar 2013 22:29:26 -0800 (PST)
In-Reply-To: 
References: 
Date: Mon, 4 Mar 2013 07:29:26 +0100
Message-ID: 
From: Pascal Thubert 
To: Thomas Watteyne 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 06:29:32 -0000

Thomas:

I agree with the problem and like your definitions. This tells me that
we need to start our own terminology document.
I'd suggest it includes ROLL's which is going to IESG review, as well
as AUTOCONF, both by reference so that it stays strictly consistent.

cheers,

Pascal

2013/3/4 Thomas Watteyne :
> All,
>
> From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
> thread, it appears apparent that the IEEE802.15.4e standard uses terms which
> are confusing, especially when taken into a broader context.
>
> For example:
> - "link"
>    . in IEEE802.15.4e: "single slot scheduled from A to B"
>    . general definition: generic term for single-hop connection, often
> related to broadcast domain
> - "path"
>    . IEEE802.15.4e: "group of links between A and B"
>    . general definition: multi-hop route between source and destination.
>
> We are often confused ourselves at those "colliding" definitions, so I
> believe there is a need to provide some definitions. This can be done as
> part of a next revision of
> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or some
> other draft if considered appropriate by the group.
>
> What follows is a number of terms, and tentative definitions. Let's
> edit/circulate this e-mail for a couple of days, then decide what makes it
> into the official definitions list.
>
> - slot:
>    - A timeslot in the TSCH schedule. A slot can be scheduled or
> unscheduled. During an unscheduled slot, the node does not communicate. When
> a slot is scheduled, it is assigned a slotframe, it is assigned a neighbor
> address (which can be the broadcast address), and one of more of the
> following flags: TX, RX, shared, timeskeeping, hard. A broadcast slot is an
> alias for "a scheduled slot with neighbor address the broadcast address".
>    - note: this term would replace the term "link" in the IEEE802.15.4e
> standard.
> - bundle:
>    - A group of equivalent scheduled slots, i.e. slots which are scheduled,
> on the same slotframe, with the same neighbor and with the same flags. The
> size of the bundle refers to the number of slots it contains. Given the
> length of the slotframe, the size of the bundle translates directly into
> reserved bandwidth.
> - (inversed) mux:
>    - Qin, would you mind giving a tentative definition here?
>
> Thomas
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



-- 
Pascal

From qinwang@berkeley.edu  Sun Mar  3 22:33:41 2013
Return-Path: 
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 CA7FF21F85AF for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 22:33:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level: 
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4]
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 68mIqtk5X6ru for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 22:33:37 -0800 (PST)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id D9A8A21F85AD for <6tsch@ietf.org>; Sun,  3 Mar 2013 22:33:37 -0800 (PST)
Received: from cm03ws.ist.berkeley.edu ([169.229.218.165] helo=calmail.berkeley.edu) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UCOxs-0007eA-8K; Sun, 03 Mar 2013 22:33:37 -0800
Received: from 76.88.33.145 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Sun, 3 Mar 2013 22:33:36 -0800
Message-ID: 
In-Reply-To: 
References: 
Date: Sun, 3 Mar 2013 22:33:36 -0800
From: "Qin Wang" 
To: "Thomas Watteyne" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 06:33:41 -0000

Thomas,

In my mind, there is a picture described as follows.

IP packet => 6LowPan.Fragment => (inverse_mux => mux) => TSCH

Where inverse_mux and mux are two modules of 6tus.

(1)inverse_mux: input includes DestAddr, Priority, MAC_payload, and
others; output is a group of bundles (or queues). The function of
inverse_mux is pushing the MAC_payload into one bundle according to the
DestAddr and Priority.

(2)mux: input parallel all of the bundles; and corresponding to each
active link in TSCH schedule, mux will output a packet which is selected
from the first elements of each bundle, according to the feature of the
active link and QoS policy of selection run by the mux. The packet will be
transmitted in the active link by TSCH.

Is it clear?

Qin








> All,
>
> From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
> thread, it appears apparent that the IEEE802.15.4e standard uses terms
> which are confusing, especially when taken into a broader context.
>
> For example:
> - "link"
>    . in IEEE802.15.4e: "single slot scheduled from A to B"
>    . general definition: generic term for single-hop connection, often
> related to broadcast domain
> - "path"
>    . IEEE802.15.4e: "group of links between A and B"
>    . general definition: multi-hop route between source and destination.
>
> We are often confused ourselves at those "colliding" definitions, so I
> believe there is a need to provide some definitions. This can be done as
> part of a next revision of
> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or
> some other draft if considered appropriate by the group.
>
> What follows is a number of terms, and tentative definitions. Let's
> edit/circulate this e-mail for a couple of days, then decide what makes it
> into the official definitions list.
>
> - slot:
>    - A timeslot in the TSCH schedule. A slot can be scheduled or
> unscheduled. During an *unscheduled* slot, the node does not communicate.
> When a slot is *scheduled*, it is assigned a slotframe, it is assigned a
> neighbor address (which can be the broadcast address), and one of more of
> the following flags: TX, RX, shared, timeskeeping, hard. A *broadcast
> *slot
> is an alias for "a scheduled slot with neighbor address the broadcast
> address".
>    - note: this term would replace the term "link" in the IEEE802.15.4e
> standard.
> - bundle:
>    - A group of equivalent scheduled slots, i.e. slots which are
> scheduled,
> on the same slotframe, with the same neighbor and with the same flags. The
> *
> size* of the bundle refers to the number of slots it contains. Given the
> length of the slotframe, the size of the bundle translates directly into
> reserved bandwidth.
> - (inversed) mux:
>    - *Qin*, would you mind giving a tentative definition here?
>
> Thomas
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From pascal.thubert@gmail.com  Sun Mar  3 22:41:13 2013
Return-Path: 
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 3D25521F8555 for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 22:41:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001]
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 t4CQHgqhrKyk for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 22:41:12 -0800 (PST)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5395521F8554 for <6tsch@ietf.org>; Sun,  3 Mar 2013 22:41:12 -0800 (PST)
Received: by mail-la0-f49.google.com with SMTP id fs13so4661684lab.36 for <6tsch@ietf.org>; Sun, 03 Mar 2013 22:41:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XjEha0X2GKYGqixLDcF4D2sz5bFI9Of8nU8bS/OmnyU=; b=kH3xzLDcQhIIWCZDPET6o5EdR5Xg0LxW/n3VhiEznsewAG5WxvCR8gAcHpr/VxxWp0 VeHfBxitXQry8Pc4JLtM1nQs2G+mTNL589FFDn4SzxBZL215TxMhM8cK3Yv7tswzqgiM 0YM4eP1oENGHEmXMxOZG1TXcCMEdj64UvWZ19W/Dg7HNU74WxXgYQUQmabL2doYXaDqA qK3woEt2oUNtfuJfawOQyO8nr0EpdAcJF4+1ZAUA7SQ90r384c8NOgZi5O5m1OA3Y/Nt i8VFNuRuoEzdNc3DB6DjJJI/z3563EjgxfNrIWHfosBdR0VTeAz6OIi+RmiB10OqC7JY 5dJA==
MIME-Version: 1.0
X-Received: by 10.152.46.17 with SMTP id r17mr16893403lam.47.1362379271201; Sun, 03 Mar 2013 22:41:11 -0800 (PST)
Received: by 10.112.27.39 with HTTP; Sun, 3 Mar 2013 22:41:11 -0800 (PST)
In-Reply-To: 
References:  
Date: Mon, 4 Mar 2013 07:41:11 +0100
Message-ID: 
From: Pascal Thubert 
To: Qin Wang 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Thomas Watteyne , IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 06:41:13 -0000

Hello Qin,

I understand the concepts and the need for mux and i-mux.
What I do not see in your definition is the abstract concept of flow
which maps a particular track (which I would define as a particular -
reserved - sequence of bundles along a path).
Probably everything is in the packet (flow label?) but maybe not.
maybe the track is identified by the incoming bundle that must match
teh outgoing bundle along the track so there is an track-ID somewhere
in your parameters...

Cheers,

Pascal


2013/3/4 Qin Wang :
> Thomas,
>
> In my mind, there is a picture described as follows.
>
> IP packet => 6LowPan.Fragment => (inverse_mux => mux) => TSCH
>
> Where inverse_mux and mux are two modules of 6tus.
>
> (1)inverse_mux: input includes DestAddr, Priority, MAC_payload, and
> others; output is a group of bundles (or queues). The function of
> inverse_mux is pushing the MAC_payload into one bundle according to the
> DestAddr and Priority.
>
> (2)mux: input parallel all of the bundles; and corresponding to each
> active link in TSCH schedule, mux will output a packet which is selected
> from the first elements of each bundle, according to the feature of the
> active link and QoS policy of selection run by the mux. The packet will be
> transmitted in the active link by TSCH.
>
> Is it clear?
>
> Qin
>
>
>
>
>
>
>
>
>> All,
>>
>> From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
>> thread, it appears apparent that the IEEE802.15.4e standard uses terms
>> which are confusing, especially when taken into a broader context.
>>
>> For example:
>> - "link"
>>    . in IEEE802.15.4e: "single slot scheduled from A to B"
>>    . general definition: generic term for single-hop connection, often
>> related to broadcast domain
>> - "path"
>>    . IEEE802.15.4e: "group of links between A and B"
>>    . general definition: multi-hop route between source and destination.
>>
>> We are often confused ourselves at those "colliding" definitions, so I
>> believe there is a need to provide some definitions. This can be done as
>> part of a next revision of
>> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or
>> some other draft if considered appropriate by the group.
>>
>> What follows is a number of terms, and tentative definitions. Let's
>> edit/circulate this e-mail for a couple of days, then decide what makes it
>> into the official definitions list.
>>
>> - slot:
>>    - A timeslot in the TSCH schedule. A slot can be scheduled or
>> unscheduled. During an *unscheduled* slot, the node does not communicate.
>> When a slot is *scheduled*, it is assigned a slotframe, it is assigned a
>> neighbor address (which can be the broadcast address), and one of more of
>> the following flags: TX, RX, shared, timeskeeping, hard. A *broadcast
>> *slot
>> is an alias for "a scheduled slot with neighbor address the broadcast
>> address".
>>    - note: this term would replace the term "link" in the IEEE802.15.4e
>> standard.
>> - bundle:
>>    - A group of equivalent scheduled slots, i.e. slots which are
>> scheduled,
>> on the same slotframe, with the same neighbor and with the same flags. The
>> *
>> size* of the bundle refers to the number of slots it contains. Given the
>> length of the slotframe, the size of the bundle translates directly into
>> reserved bandwidth.
>> - (inversed) mux:
>>    - *Qin*, would you mind giving a tentative definition here?
>>
>> Thomas
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch



-- 
Pascal

From qinwang@berkeley.edu  Sun Mar  3 22:48:14 2013
Return-Path: 
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 324A221F856D for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 22:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level: 
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4]
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 PmjT11x+XdKJ for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 22:48:13 -0800 (PST)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id BC5F921F855A for <6tsch@ietf.org>; Sun,  3 Mar 2013 22:48:13 -0800 (PST)
Received: from cm03ws.ist.berkeley.edu ([169.229.218.165] helo=calmail.berkeley.edu) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UCPBy-0004wu-MZ; Sun, 03 Mar 2013 22:48:13 -0800
Received: from 76.88.33.145 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Sun, 3 Mar 2013 22:48:11 -0800
Message-ID: <7a286af86536ae8284fd948056d8c424.squirrel@calmail.berkeley.edu>
In-Reply-To: <22446.1362348006@sandelman.ca>
References: <512C36F4.4000409@eecs.berkeley.edu> <512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com>   <25024.1362165522@sandelman.ca> <5b22240b87d48b6314c835aa4b701dc0.squirrel@calmail.berkeley.edu> <22446.1362348006@sandelman.ca>
Date: Sun, 3 Mar 2013 22:48:11 -0800
From: "Qin Wang" 
To: "Michael Richardson" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 06:48:14 -0000

Michael,

I think both inverse_mux and mux are below the 6lowpan fragmentation, i.e.
a IP packet is divided into several MAC-payloads (i.e. fragments), and the
MAC-payloads will be transmitted in several links, i.e. (slotOffset,
channelOffset).

How do you think?

Qin



>
>>>>>> "Qin" == Qin Wang  writes:
>     Qin> "inverse mux" is a good word to describe 6tus. I would like to
>     Qin> connect a Mux with the inverse mux. They together work as
>     Qin> follows.
>
>     Qin> (1)Upper layer (e.g. RPL) push message to 6tus, as input of
>     Qin> Inverse Mux, with information like DestAddr, Priority,....
>
>     Qin> (2)"Inverse Mux" Function, according to some rule, push the
>     Qin> message into corresponding Queue/Bundle/..., i.e. input of Mux.
>
>     Qin> (3)"Mux" Funtion, according to some rule, feed the packets in
>     Qin> different Queues/Bundles into TSCH. The reason for using Mux is
>     Qin> that there is only one communication action in one slot at
>     Qin> most.
>
>     Qin> Does it make sense?
>
> Do you put the inverse MUX above or below the 6lowpan fragmentation
> layer?  Can different 6lowpan fragments travel on different slots?
>
>
>
>
>
> --
> Michael Richardson , Sandelman Software Works
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


From qinwang@berkeley.edu  Sun Mar  3 23:06:34 2013
Return-Path: 
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 15A7221F8606 for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 23:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level: 
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4]
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 mNqT-PgAyJPB for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 23:06:33 -0800 (PST)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8239121F8602 for <6tsch@ietf.org>; Sun,  3 Mar 2013 23:06:33 -0800 (PST)
Received: from cm03ws.ist.berkeley.edu ([169.229.218.165] helo=calmail.berkeley.edu) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UCPTi-0006E1-IZ; Sun, 03 Mar 2013 23:06:32 -0800
Received: from 76.88.33.145 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Sun, 3 Mar 2013 23:06:30 -0800
Message-ID: 
In-Reply-To: 
References:   
Date: Sun, 3 Mar 2013 23:06:30 -0800
From: "Qin Wang" 
To: "Pascal Thubert" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: Thomas Watteyne , IETF 6TSCH <6tsch@ietf.org>, Qin Wang 
Subject: Re: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 07:06:34 -0000

Pascal,

Let me give a example. Assume, there is two broadcast bundles, with
priority High and Low; There are three unicast bundles, with priority
High, Mid, and Low. The interface to upper layer is as follows.

SendData.request (DestAddr, Priority, MesseageLen, Message,SecurityLevel,..)

The inverse_mux receive the request, and push the message into
corresponding bundle according to the DestAddr (broadcast/unicast) and
Priority.

If the next active link in TSCH schedule is featured as broadcast link,
mux will choose one packet from the two broadcast bundles according to QoS
policy, e.g. packet in high priority bundle should be transmitted first.

similarly, if the next active link is featured as unicast link, mux will
choose one packet, which has matched DestAddr, from higher priority
bundle.

The selected packet will be transmitted in the link by TSCH.

Does I answer your question?

Qin




> Hello Qin,
>
> I understand the concepts and the need for mux and i-mux.
> What I do not see in your definition is the abstract concept of flow
> which maps a particular track (which I would define as a particular -
> reserved - sequence of bundles along a path).
> Probably everything is in the packet (flow label?) but maybe not.
> maybe the track is identified by the incoming bundle that must match
> teh outgoing bundle along the track so there is an track-ID somewhere
> in your parameters...
>
> Cheers,
>
> Pascal
>
>
> 2013/3/4 Qin Wang :
>> Thomas,
>>
>> In my mind, there is a picture described as follows.
>>
>> IP packet => 6LowPan.Fragment => (inverse_mux => mux) => TSCH
>>
>> Where inverse_mux and mux are two modules of 6tus.
>>
>> (1)inverse_mux: input includes DestAddr, Priority, MAC_payload, and
>> others; output is a group of bundles (or queues). The function of
>> inverse_mux is pushing the MAC_payload into one bundle according to the
>> DestAddr and Priority.
>>
>> (2)mux: input parallel all of the bundles; and corresponding to each
>> active link in TSCH schedule, mux will output a packet which is selected
>> from the first elements of each bundle, according to the feature of the
>> active link and QoS policy of selection run by the mux. The packet will
>> be
>> transmitted in the active link by TSCH.
>>
>> Is it clear?
>>
>> Qin
>>
>>
>>
>>
>>
>>
>>
>>
>>> All,
>>>
>>> From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
>>> thread, it appears apparent that the IEEE802.15.4e standard uses terms
>>> which are confusing, especially when taken into a broader context.
>>>
>>> For example:
>>> - "link"
>>>    . in IEEE802.15.4e: "single slot scheduled from A to B"
>>>    . general definition: generic term for single-hop connection, often
>>> related to broadcast domain
>>> - "path"
>>>    . IEEE802.15.4e: "group of links between A and B"
>>>    . general definition: multi-hop route between source and
>>> destination.
>>>
>>> We are often confused ourselves at those "colliding" definitions, so I
>>> believe there is a need to provide some definitions. This can be done
>>> as
>>> part of a next revision of
>>> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or
>>> some other draft if considered appropriate by the group.
>>>
>>> What follows is a number of terms, and tentative definitions. Let's
>>> edit/circulate this e-mail for a couple of days, then decide what makes
>>> it
>>> into the official definitions list.
>>>
>>> - slot:
>>>    - A timeslot in the TSCH schedule. A slot can be scheduled or
>>> unscheduled. During an *unscheduled* slot, the node does not
>>> communicate.
>>> When a slot is *scheduled*, it is assigned a slotframe, it is assigned
>>> a
>>> neighbor address (which can be the broadcast address), and one of more
>>> of
>>> the following flags: TX, RX, shared, timeskeeping, hard. A *broadcast
>>> *slot
>>> is an alias for "a scheduled slot with neighbor address the broadcast
>>> address".
>>>    - note: this term would replace the term "link" in the IEEE802.15.4e
>>> standard.
>>> - bundle:
>>>    - A group of equivalent scheduled slots, i.e. slots which are
>>> scheduled,
>>> on the same slotframe, with the same neighbor and with the same flags.
>>> The
>>> *
>>> size* of the bundle refers to the number of slots it contains. Given
>>> the
>>> length of the slotframe, the size of the bundle translates directly
>>> into
>>> reserved bandwidth.
>>> - (inversed) mux:
>>>    - *Qin*, would you mind giving a tentative definition here?
>>>
>>> Thomas
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>
>
>
> --
> Pascal
>



From maria-rita.palattella@uni.lu  Sun Mar  3 23:45:00 2013
Return-Path: 
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 EBC3421F8682 for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 23:45:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 9Dte7AaU06Ux for <6tsch@ietfa.amsl.com>; Sun,  3 Mar 2013 23:44:58 -0800 (PST)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id BDA5B21F8717 for <6tsch@ietf.org>; Sun,  3 Mar 2013 23:44:57 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,777,1355094000"; d="scan'208,217";a="22637307"
Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 04 Mar 2013 08:44:56 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.01.0438.000; Mon, 4 Mar 2013 08:44:56 +0100
From: Maria Rita PALATTELLA 
To: Thomas Watteyne , IETF 6TSCH <6tsch@ietf.org>
Thread-Topic: [6tsch] 6tsch definitions
Thread-Index: AQHOGGrLPMmmCJiG/k618WcwIw6eppiVH1yQ
Date: Mon, 4 Mar 2013 07:44:55 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.91.0.78]
Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D1851C330hoshiunilux_"
MIME-Version: 1.0
Subject: Re: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 07:45:01 -0000

--_000_F085911F642A6847987ADA23E611780D1851C330hoshiunilux_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thomas,

I totally agree with you and Pascal about the need of  introducing  ad-hoc =
definitions for 6tus, in order to avoid any kind of confusion when integrat=
ing IEEE802.15.4e with 6LoWPAN, RPL and other standards.

Maybe it is the case to have a specific draft, including all the definition=
s we may need,  and keep the other draft as a general overview of problems =
and goals. What do you think?

Even though I like your definition of "slot" scheduled/unscheduled/broadcas=
t, I have a "little" concern. In our discussion we are not taking in accoun=
t that the link definition in IEEE802.15.4e includes also the channel offse=
t value.  In fact, a node A needs to know not only the time slot, but also =
the channel offset (and thus, the frequency) on which it will be allowed to=
 transmit to a its parent node B.

Shall we then use another type of definition, like RESERVED/UNRESERVED CELL=
  or Scheduled/Unscheduled cell, where a CELL within the slotframe's grid  =
is given by   (time slot, channel offset) .

The same concern comes when we define the path. We have somehow to specify =
that each equivalent slot may be scheduled  on different channel offset.  S=
o, according to your definition,  they are  "slots which are scheduled, on =
the same slotframe, with the same neighbor and with the same flags, on the =
same and/or different channel offsets".

Maria Rita

From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of T=
homas Watteyne
Sent: Monday, March 04, 2013 12:57 AM
To: IETF 6TSCH
Subject: [6tsch] 6tsch definitions

All,

>From the discussions in the "DIOs/DAOs and broadcast channels on TSCH" thre=
ad, it appears apparent that the IEEE802.15.4e standard uses terms which ar=
e confusing, especially when taken into a broader context.

For example:
- "link"
   . in IEEE802.15.4e: "single slot scheduled from A to B"
   . general definition: generic term for single-hop connection, often rela=
ted to broadcast domain
- "path"
   . IEEE802.15.4e: "group of links between A and B"
   . general definition: multi-hop route between source and destination.

We are often confused ourselves at those "colliding" definitions, so I beli=
eve there is a need to provide some definitions. This can be done as part o=
f a next revision of http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-l=
ln-context-01, or some other draft if considered appropriate by the group.

What follows is a number of terms, and tentative definitions. Let's edit/ci=
rculate this e-mail for a couple of days, then decide what makes it into th=
e official definitions list.

- slot:
   - A timeslot in the TSCH schedule. A slot can be scheduled or unschedule=
d. During an unscheduled slot, the node does not communicate. When a slot i=
s scheduled, it is assigned a slotframe, it is assigned a neighbor address =
(which can be the broadcast address), and one of more of the following flag=
s: TX, RX, shared, timeskeeping, hard. A broadcast slot is an alias for "a =
scheduled slot with neighbor address the broadcast address".
   - note: this term would replace the term "link" in the IEEE802.15.4e sta=
ndard.
- bundle:
   - A group of equivalent scheduled slots, i.e. slots which are scheduled,=
 on the same slotframe, with the same neighbor and with the same flags. The=
 size of the bundle refers to the number of slots it contains. Given the le=
ngth of the slotframe, the size of the bundle translates directly into rese=
rved bandwidth.
- (inversed) mux:
   - Qin, would you mind giving a tentative definition here?

Thomas

--_000_F085911F642A6847987ADA23E611780D1851C330hoshiunilux_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Thomas,=



 <=
/p>

I totally agree with you =
and Pascal about the need of  introducing  ad-hoc definitions for=
 6tus, in order to avoid any kind of confusion when integrating IEEE802.15.=
4e
 with 6LoWPAN, RPL and other standards. 


 <=
/p>

Maybe it is the case to h=
ave a specific draft, including all the definitions we may need,  and =
keep the other draft as a general overview of problems and goals.
 What do you think?


 <=
/p>

Even though I like your d=
efinition of “slot” scheduled/unscheduled/broadcast, I have a &=
#8220;little” concern. In our discussion we are not taking in account=
 that
 the link definition in IEEE802.15.4e includes also the channel offse=
t value.  In fact, a node A needs to know not only the time sl=
ot, but also the channel offset (and thus, the frequency) on which it will =
be allowed to transmit to a its parent
 node B.


 <=
/p>

Shall we then use another=
 type of definition, like RESERVED/UNRESERVED CELL  or Scheduled/Unsch=
eduled cell, where a CELL within the slotframe’s grid  is given
 by   (time slot, channel offset) .


 <=
/p>

The same concern comes wh=
en we define the path. We have somehow to specify that each equivalent slot=
 may be scheduled  on different channel offset.  So, according
 to your definition,  they are  “slots which are scheduled, on the same slotframe, with the same nei=
ghbor and with the same flags, on the same and/or different channel offsets=
”.


 <=
/p>

Maria Rita


 <=
/p>

From: 6tsch-bo=
unces@ietf.org [mailto:6tsch-bounces@ietf.org]
On Behalf Of Thomas Watteyne

Sent: Monday, March 04, 2013 12:57 AM

To: IETF 6TSCH

Subject: [6tsch] 6tsch definitions


 


=
All,




 






=
>From the discussions in the "DIOs/DAOs and broadcast channels on =
TSCH" thread, it appears apparent that the IEEE802.15.4e standard uses=
 terms which are confusing, especially when taken into a broader
 context.






 






=
For example:






=
- "link"






=
   . in IEEE802.15.4e: "single slot scheduled from A to B&qu=
ot;






=
   . general definition: generic term for single-hop connection, =
often related to broadcast domain






=
- "path"






=
   . IEEE802.15.4e: "group of links between A and B"






=
   . general definition: multi-hop route between source and desti=
nation.






 






=
We are often confused ourselves at those "colliding" definitions,=
 so I believe there is a need to provide some definitions. This can be done=
 as part of a next revision of http://tools.iet=
f.org/html/draft-watteyne-6tsch-tsch-lln-context-01,
 or some other draft if considered appropriate by the group.






 






=
What follows is a number of terms, and tentative definitions. Let's edit/ci=
rculate this e-mail for a couple of days, then decide what makes it into th=
e official definitions list.






 






=
- slot:






=
   - A timeslot in the TSCH schedule. A slot can be scheduled or =
unscheduled. During an
unscheduled slot, the node does not communicate. When a slot is s=
cheduled, it is assigned a slotframe, it is assigned a neighbor address=
 (which can be the broadcast address), and one of more of the following fla=
gs: TX, RX, shared, timeskeeping,
 hard. A broadcast slot is an alias for "a scheduled slot with =
neighbor address the broadcast address".






=
   - note: this term would replace the term "link" in t=
he IEEE802.15.4e standard.






=
- bundle:






=
   - A group of equivalent scheduled slots, i.e. slots which are =
scheduled, on the same slotframe, with the same neighbor and with the same =
flags. The
size of the bundle refers to the number of slots it contains. Given =
the length of the slotframe, the size of the bundle translates directly int=
o reserved bandwidth.






=
- (inversed) mux:






=
   - Qin, would you mind giving a tentative definition her=
e?






 






=
Thomas








--_000_F085911F642A6847987ADA23E611780D1851C330hoshiunilux_--

From pthubert@cisco.com  Mon Mar  4 03:46:55 2013
Return-Path: 
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 0A69521F8A5A for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 03:46:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 D6wc8sxx-H8h for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 03:46:54 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAA421F8A3E for <6tsch@ietf.org>; Mon,  4 Mar 2013 03:46:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7966; q=dns/txt; s=iport; t=1362397614; x=1363607214; h=from:to:subject:date:message-id:mime-version; bh=y+tMzOtvezi6U3cDnyXM+ft20XmRT/06rfQNM0AgCfo=; b=FlOecWNPNaqtGZLdSEBzY+yq/H5cRgpdV1N8Cil/3TPfy0YGtqfOpaLj CPaDgXNi/kO8i7C41b1OeSR/pgM1V9VkAkGp0rLs6+B5w0gk8zkTRborJ //F3SbcrUjouUinp9qxjnShbMA3l98cg5gRfTr2MOszAV3O4jY0hQQ4Fh k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAKGINFGtJV2Y/2dsb2JhbAArGoJDhA27fQ1zFnOCHwEBAQQjCl4BGQQBAQsdAwIEMBQJCQEEEwiICwwuphmOVZFeBI5cFhAHCoIuMmEDpzKDCIIn
X-IronPort-AV: E=Sophos;i="4.84,778,1355097600";  d="scan'208,217";a="183377227"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 04 Mar 2013 11:46:54 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r24Bkrjl020343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Mon, 4 Mar 2013 11:46:53 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 05:46:53 -0600
From: "Pascal Thubert (pthubert)" 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: Recording of the 6TSCH call, March 1st, 2013
Thread-Index: Ac4YzdAP7wlDNM8lQWirSpjAD3FFmw==
Date: Mon, 4 Mar 2013 11:46:53 +0000
Deferred-Delivery: Mon, 4 Mar 2013 11:46:00 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.49.80.24]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835CD5F46xmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: [6tsch] Recording of the 6TSCH call, March 1st, 2013
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 11:46:55 -0000

--_000_E045AECD98228444A58C61C200AE1BD835CD5F46xmbrcdx01ciscoc_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBhbGw7DQoNCkEgbnVtYmVyIG9mIHBlb3BsZSBzdWdnZXN0ZWQgd2UgbWFpbnRhaW4gYSBj
YWxsIHJlY29yZCBmb3IgdGhvc2Ugd2hvIGNhbm5vdCBhdHRlbmQgYXQgdGhlIHRpbWUgb2YgdGhl
IG1lZXRpbmcuDQpQbGVhc2Ugbm90ZSB0aGF0IHdlIGhhZCBhIHJvdWdoIGNvbnNlbnN1cyBkdXJp
bmcgdGhlIGNhbGwgdG8gbW92ZSBpdCBhbiBob3VyIGVhcmxpZXIuIFRoaXMgbWlnaHQgaGVscCBw
ZW9wbGUgaW4gQXNpYSwgYXMgd2VsbCBhcyBJU0ExMDAgbWVtYmVycy4NCknigJlsbCB0cnkgdG8g
Z2V0IHRoZSBzYW1lIGNvbnNlbnN1cyBvbiB0aGUgbGlzdCBhbmQgaWYgSSBzdWNjZWVkLCB3ZeKA
mWxsIG1vdmUgdGhlIGNhbGwgYW5kIGJhc2UgaXQgb24gVVMgc2F2aW5ncyBwZXIgVG9t4oCZcyBz
dWdnZXN0aW9uLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQpGcm9tOiBtZXNzZW5nZXJAd2ViZXgu
Y29tIFttYWlsdG86bWVzc2VuZ2VyQHdlYmV4LmNvbV0NClNlbnQ6IHZlbmRyZWRpIDEgbWFycyAy
MDEzIDE5OjA2DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KU3ViamVjdDogWW91ciBy
ZWNvcmRpbmcgIjZUU0NILTIwMTMwMzAxIDE3MDItMSIgaXMgYXZhaWxhYmxlIGZvciB2aWV3aW5n
DQoNClBhc2NhbCBUaHViZXJ0LA0KDQpZb3VyIHJlY29yZGluZyBpcyBub3cgYXZhaWxhYmxlIG9u
IHRoZSBXZWJFeCBzZXJ2aWNlIHNpdGUuIENsaWNrIHRoZSBsaW5rIGJlbG93IHRvIHBsYXkgaXQ6
DQoNCmh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvbHNyLnBocD9BVD1wYiZTUD1N
QyZySUQ9NjY0MDkzMjImcktleT0yNTQxMDVjNjhmZWZhODgwDQoNCjZUU0NILTIwMTMwMzAxIDE3
MDItMQ0KRnJpZGF5LCBNYXJjaCAxLCAyMDEzIDY6MDIgcG0gUGFyaXMgVGltZQ0KNTYgTWludXRl
cw0KDQoNCg==

--_000_E045AECD98228444A58C61C200AE1BD835CD5F46xmbrcdx01ciscoc_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44
NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX
b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp
Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0
Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv
eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi
IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EZWFy
IGFsbDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkEgbnVtYmVyIG9mIHBlb3BsZSBzdWdnZXN0ZWQgd2UgbWFpbnRhaW4g
YSBjYWxsIHJlY29yZCBmb3IgdGhvc2Ugd2hvIGNhbm5vdCBhdHRlbmQgYXQgdGhlIHRpbWUgb2Yg
dGhlIG1lZXRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBub3RlIHRo
YXQgd2UgaGFkIGEgcm91Z2ggY29uc2Vuc3VzIGR1cmluZyB0aGUgY2FsbCB0byBtb3ZlIGl0IGFu
IGhvdXIgZWFybGllci4gVGhpcyBtaWdodCBoZWxwIHBlb3BsZSBpbiBBc2lhLCBhcyB3ZWxsIGFz
IElTQTEwMCBtZW1iZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZbGwgdHJ5
IHRvIGdldCB0aGUgc2FtZSBjb25zZW5zdXMgb24gdGhlIGxpc3QgYW5kIGlmIEkgc3VjY2VlZCwg
d2XigJlsbCBtb3ZlIHRoZSBjYWxsIGFuZCBiYXNlIGl0IG9uIFVTIHNhdmluZ3MgcGVyIFRvbeKA
mXMgc3VnZ2VzdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXNj
YWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1lc3NlbmdlckB3
ZWJleC5jb20gW21haWx0bzptZXNzZW5nZXJAd2ViZXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+
IHZlbmRyZWRpIDEgbWFycyAyMDEzIDE5OjA2PGJyPg0KPGI+VG86PC9iPiBQYXNjYWwgVGh1YmVy
dCAocHRodWJlcnQpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFlvdXIgcmVjb3JkaW5nICZxdW90OzZU
U0NILTIwMTMwMzAxIDE3MDItMSZxdW90OyBpcyBhdmFpbGFibGUgZm9yIHZpZXdpbmc8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QYXNj
YWwgVGh1YmVydCwNCjxicj4NCjxicj4NCllvdXIgcmVjb3JkaW5nIGlzIG5vdyBhdmFpbGFibGUg
b24gdGhlIFdlYkV4IHNlcnZpY2Ugc2l0ZS4gQ2xpY2sgdGhlIGxpbmsgYmVsb3cgdG8gcGxheSBp
dDoNCjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2Fs
ZXMvbHNyLnBocD9BVD1wYiZhbXA7U1A9TUMmYW1wO3JJRD02NjQwOTMyMiZhbXA7cktleT0yNTQx
MDVjNjhmZWZhODgwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lz
Y29zYWxlcy9sc3IucGhwP0FUPXBiJmFtcDtTUD1NQyZhbXA7cklEPTY2NDA5MzIyJmFtcDtyS2V5
PTI1NDEwNWM2OGZlZmE4ODA8L2E+DQo8YnI+DQo8YnI+DQo2VFNDSC0yMDEzMDMwMSAxNzAyLTEg
PGJyPg0KRnJpZGF5LCBNYXJjaCAxLCAyMDEzIDY6MDIgcG0gUGFyaXMgVGltZSA8YnI+DQo1NiBN
aW51dGVzIDxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9ib2R5Pg0KPC9odG1sPg0K

--_000_E045AECD98228444A58C61C200AE1BD835CD5F46xmbrcdx01ciscoc_--

From mcr@sandelman.ca  Mon Mar  4 07:11:31 2013
Return-Path: 
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 498D121F88D6 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 07:11:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 BjgD5pB2zsTa for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 07:11:30 -0800 (PST)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id C1B5021F89B3 for <6tsch@ietf.org>; Mon,  4 Mar 2013 07:11:28 -0800 (PST)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4738820168; Mon,  4 Mar 2013 10:18:56 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 6E294636BE; Mon,  4 Mar 2013 10:11:23 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5C0A7636BB; Mon,  4 Mar 2013 10:11:23 -0500 (EST)
From: Michael Richardson 
To: "Qin Wang" 
In-Reply-To: <7a286af86536ae8284fd948056d8c424.squirrel@calmail.berkeley.edu>
References: <512C36F4.4000409@eecs.berkeley.edu> <512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com>   <25024.1362165522@sandelman.ca> <5b22240b87d48b6314c835aa4b701dc0.squirrel@calmail.berkeley.edu> <22446.1362348006@sandelman.ca> <7a286af86536ae8284fd948056d8c424.squirrel@calmail.berkeley.edu>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 15:11:31 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Qin" =3D=3D Qin Wang  writes:
    Qin> I think both inverse_mux and mux are below the 6lowpan
    Qin> fragmentation, i.e.  a IP packet is divided into several
    Qin> MAC-payloads (i.e. fragments), and the MAC-payloads will be
    Qin> transmitted in several links, i.e. (slotOffset, channelOffset).

    Qin> How do you think?

I know that when you fragment, you very poor ETX or high congestion if
the fragments get lost.  Multipathing the fragments seems to guarantee
that different fragments might get lost.  How do we know what paths are
broken (and avoid them at layer 3) if no packets are assembled because a
fragment was always lost.=20

I think therefore that while it might be acceptable for application
layer data to be multi-pathed, I think that RPL packets need to stick to
a single path at a time.

=2D-=20
Michael Richardson , Sandelman Software Works=20



--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQCVAwUAUTS5m4qHRg3pndX9AQIdXAP/cYbyP8kpQASI4v54q6cCtdOg9jWKfgpg
IqbuGTRgCMb5EEhUOeEvkmspig/R0zQr98iRs6OeCc+y1gdL4pB+/T/EXGLdzU4A
rbmtoAgDaGFwkyxKseuuyeUOqT6ABZF/hw1VarRR3mVEJagw05q6YgH8h1S9cSP1
VhZKLJcMh6Y=
=iwm5
-----END PGP SIGNATURE-----
--=-=-=--

From qinwang@berkeley.edu  Mon Mar  4 08:52:56 2013
Return-Path: 
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 8D53E21F8D35 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 08:52:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.3
X-Spam-Level: 
X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 uF3UpeFMYJz5 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 08:52:49 -0800 (PST)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3509121F8D3A for <6tsch@ietf.org>; Mon,  4 Mar 2013 08:52:49 -0800 (PST)
Received: from cm01ws.ist.berkeley.edu ([169.229.218.163] helo=calmail.berkeley.edu) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UCYd2-0006xv-KP; Mon, 04 Mar 2013 08:52:46 -0800
Received: from 76.88.33.145 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Mon, 4 Mar 2013 08:52:44 -0800
Message-ID: <9d79c7df6ddc18ee704ad198d94b6ba6.squirrel@calmail.berkeley.edu>
In-Reply-To: <29433.1362409883@sandelman.ca>
References: <512C36F4.4000409@eecs.berkeley.edu> <512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com>   <25024.1362165522@sandelman.ca> <5b22240b87d48b6314c835aa4b701dc0.squirrel@calmail.berkeley.edu> <22446.1362348006@sandelman.ca> <7a286af86536ae8284fd948056d8c424.squirrel@calmail.berkeley.edu> <29433.1362409883@sandelman.ca>
Date: Mon, 4 Mar 2013 08:52:44 -0800
From: "Qin Wang" 
To: "Michael Richardson" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "6tsch@ietf.org" <6tsch@ietf.org>, Qin Wang 
Subject: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 16:52:56 -0000

Michael,

By my understanding, selecting next hop neighbor is the responsibility of
L3, e.g. RPL, instead of 6tus. Thus, all of the fragments from one packet
should go to one neighbor. But, 6tus will provide statistics to tell upper
layer the link quality with each neighbor. In 6tus and TSCH, the way to
improve link quality is channel hopping.

I think the interface between 6tus and upper layer is something like
following.
- SendData.request (DestAddr, Priority, MessageLen, Message, ....)
- SendData.confirm (..., Status)

The Status in SendData.confirm will tell upper layer if the sending is
successful or not, and then upper layer can do Retry, assemble, or other
operation.

How do you think?

Qin



>
>>>>>> "Qin" == Qin Wang  writes:
>     Qin> I think both inverse_mux and mux are below the 6lowpan
>     Qin> fragmentation, i.e.  a IP packet is divided into several
>     Qin> MAC-payloads (i.e. fragments), and the MAC-payloads will be
>     Qin> transmitted in several links, i.e. (slotOffset, channelOffset).
>
>     Qin> How do you think?
>
> I know that when you fragment, you very poor ETX or high congestion if
> the fragments get lost.  Multipathing the fragments seems to guarantee
> that different fragments might get lost.  How do we know what paths are
> broken (and avoid them at layer 3) if no packets are assembled because a
> fragment was always lost.
>
> I think therefore that while it might be acceptable for application
> layer data to be multi-pathed, I think that RPL packets need to stick to
> a single path at a time.
>
> --
> Michael Richardson , Sandelman Software Works
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


From tom.phinney@cox.net  Mon Mar  4 09:45:18 2013
Return-Path: 
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 5AE7B21F8D8C for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 09:45:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.141
X-Spam-Level: 
X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
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 64iHw7dvtYAD for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 09:45:17 -0800 (PST)
Received: from fed1rmfepo101.cox.net (fed1rmfepo101.cox.net [68.230.241.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9E321F8D8B for <6tsch@ietf.org>; Mon,  4 Mar 2013 09:45:17 -0800 (PST)
Received: from fed1rmimpo209 ([68.230.241.160]) by fed1rmfepo101.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130304174516.TGQL25001.fed1rmfepo101.cox.net@fed1rmimpo209> for <6tsch@ietf.org>; Mon, 4 Mar 2013 12:45:16 -0500
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo209 with cox id 7VlA1l00B3gAAro01VlGKn; Mon, 04 Mar 2013 12:45:16 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020201.5134DDAC.0103,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=SfMpgItu c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=mLQ_44PPUyUA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=zGXPisOAeQsA:10 a=48vgC7mUAAAA:8 a=VTX4i9FPLaU1IQBWPJ0A:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=lZB815dzVvQA:10 a=_SoKeXCvIIxQyIgw:21 a=Xl4WOGUDXL4pidpg:21 a=RvNPoag5qWHHvdFr:21 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <5134DDA5.9070305@cox.net>
Date: Mon, 04 Mar 2013 10:45:09 -0700
From: Tom Phinney 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: 6tsch@ietf.org
References: <512C36F4.4000409@eecs.berkeley.edu>	<512f2a1c.260eb40a.5ba7.ffffd737@mx.google.com>			<25024.1362165522@sandelman.ca>	<5b22240b87d48b6314c835aa4b701dc0.squirrel@calmail.berkeley.edu>	<22446.1362348006@sandelman.ca>	<7a286af86536ae8284fd948056d8c424.squirrel@calmail.berkeley.edu>	<29433.1362409883@sandelman.ca> <9d79c7df6ddc18ee704ad198d94b6ba6.squirrel@calmail.berkeley.edu>
In-Reply-To: <9d79c7df6ddc18ee704ad198d94b6ba6.squirrel@calmail.berkeley.edu>
X-Enigmail-Version: 1.1.1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney 
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 17:45:18 -0000



  
    
  
  
    L3 specifies the next L3 neighbor. Because of the
      information hiding that occurs due to layering, L3 cannot be aware
      of the detailed substructure within and internal organization of
      L2. Thus it is an L2 responsibility to determine and specify the
      next L2 neighbor in the route to that next L3 neighbor, as well as
      the ultimate L2 address that corresponds to that next L3 neighbor
      (which often is the L2 address of either a backbone router, for
      transmissions out of the wireless subnet, or of the addressed
      endpoint device, for transmissions from the backbone into the
      wireless subnet).

      

      The history of networking shows pretty conclusively that proper
      layering leads to longevity and reuse of components, whereas
      hybridization of layers leads to short-lived solutions that are
      difficult or impossible to maintain as the individual employed
      technologies evolve.

      

      It is worth noting that it is possible for intermediary L2 nodes
      to obtain L3 information from a conveyed L3 PDU without violating
      layering (by invoking a local L3 method that legitimately looks
      into the conveyed L3 PDU at the relaying L2 node), but that
      approach does not work when the L2 PDU that is being relayed
      contains a non-initial fragment of the L3 PDU. In that case the
      originating L2 node needs to use a local L3 method to extract the
      L3 information from the L3 PDU, or obtain it as interface control
      information when the L3 SDU is passed to L2, and then prepend it
      as an additional header to the conveyed L3 fragment within the L2
      PDU so that the intermediate L2 relays have access to that
      information. The types of information where such "hinting" or
      duplicate conveyance is appropriate might be priority, flow
      labeling, or other aspects that would affect the forwarding
      behavior of those intermediary L2 relays.

      ===

      

    

    On 2013.03.04 09:52, Qin Wang wrote:
    

      
Michael,

By my understanding, selecting next hop neighbor is the responsibility of
L3, e.g. RPL, instead of 6tus. Thus, all of the fragments from one packet
should go to one neighbor. But, 6tus will provide statistics to tell upper
layer the link quality with each neighbor. In 6tus and TSCH, the way to
improve link quality is channel hopping.

I think the interface between 6tus and upper layer is something like
following.
- SendData.request (DestAddr, Priority, MessageLen, Message, ....)
- SendData.confirm (..., Status)

The Status in SendData.confirm will tell upper layer if the sending is
successful or not, and then upper layer can do Retry, assemble, or other
operation.

How do you think?

Qin





      

        

        

          

            

              

                

                  
"Qin" == Qin Wang <qinwang@berkeley.edu> writes:


                

              

            

          

        

        
    Qin> I think both inverse_mux and mux are below the 6lowpan
    Qin> fragmentation, i.e.  a IP packet is divided into several
    Qin> MAC-payloads (i.e. fragments), and the MAC-payloads will be
    Qin> transmitted in several links, i.e. (slotOffset, channelOffset).

    Qin> How do you think?

I know that when you fragment, you very poor ETX or high congestion if
the fragments get lost.  Multipathing the fragments seems to guarantee
that different fragments might get lost.  How do we know what paths are
broken (and avoid them at layer 3) if no packets are assembled because a
fragment was always lost.

I think therefore that while it might be acceptable for application
layer data to be multi-pathed, I think that RPL packets need to stick to
a single path at a time.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works


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



      

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



    

  


From xvilajosana@eecs.berkeley.edu  Mon Mar  4 14:48:44 2013
Return-Path: 
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 5FFCC21F88FC for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 14:48:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 WAtvduEtCII9 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 14:48:43 -0800 (PST)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF7121F88E2 for <6tsch@ietf.org>; Mon,  4 Mar 2013 14:48:42 -0800 (PST)
Received: from airbears-136-152-39-6.airbears.berkeley.edu ([136.152.39.6] helo=[10.10.64.103]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UCeBT-000261-FO for 6tsch@ietf.org; Mon, 04 Mar 2013 14:48:41 -0800
Message-ID: <513524C7.70505@eecs.berkeley.edu>
Date: Mon, 04 Mar 2013 14:48:39 -0800
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: 6tsch@ietf.org
References:   
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 22:48:44 -0000

Hi,

as regard to a path, IMHO is the upper layer (above 6tus) who might take 
care of building the paths and maintaining them (or at least use 6tus to 
maintain them). If we look at a path node by node we can see a bundle at 
each node pointing to  its parent (the node's parent in the path). 6tus 
can be in charge of monitoring that the bandwidth requirement is being 
met (i.e whether the bundle needs more slots or not). The use of a flow 
label depends on the path reservation protocol (i.e RSVP or an extension 
to RPL) and the use of a mapping between "input bundle id and output 
bundle id" can be embedded in the packet (as a label) or keep it locally 
in each node as a switching table (i.e in node A all the packets that 
arrive at bundle X leave the node at bundle Y) .

with respect to the mux - i-mux function, If I don't understand 
incorrectly the role of the mux is to act as a selector of which packet 
needs to be sent at a particular timeslot (according to certain 
priority, and other options, etc..). i-mux feeds 6tus with packets and 
according to a configuration, mux determines the packet that needs to be 
sent in the upcoming slot.

Qin am I wrong?
X

On 03/03/13 22:41, Pascal Thubert wrote:
> Hello Qin,
>
> I understand the concepts and the need for mux and i-mux.
> What I do not see in your definition is the abstract concept of flow
> which maps a particular track (which I would define as a particular -
> reserved - sequence of bundles along a path).
> Probably everything is in the packet (flow label?) but maybe not.
> maybe the track is identified by the incoming bundle that must match
> teh outgoing bundle along the track so there is an track-ID somewhere
> in your parameters...
>
> Cheers,
>
> Pascal
>
>
> 2013/3/4 Qin Wang :
>> Thomas,
>>
>> In my mind, there is a picture described as follows.
>>
>> IP packet => 6LowPan.Fragment => (inverse_mux => mux) => TSCH
>>
>> Where inverse_mux and mux are two modules of 6tus.
>>
>> (1)inverse_mux: input includes DestAddr, Priority, MAC_payload, and
>> others; output is a group of bundles (or queues). The function of
>> inverse_mux is pushing the MAC_payload into one bundle according to the
>> DestAddr and Priority.
>>
>> (2)mux: input parallel all of the bundles; and corresponding to each
>> active link in TSCH schedule, mux will output a packet which is selected
>> from the first elements of each bundle, according to the feature of the
>> active link and QoS policy of selection run by the mux. The packet will be
>> transmitted in the active link by TSCH.
>>
>> Is it clear?
>>
>> Qin
>>
>>
>>
>>
>>
>>
>>
>>
>>> All,
>>>
>>>  From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
>>> thread, it appears apparent that the IEEE802.15.4e standard uses terms
>>> which are confusing, especially when taken into a broader context.
>>>
>>> For example:
>>> - "link"
>>>     . in IEEE802.15.4e: "single slot scheduled from A to B"
>>>     . general definition: generic term for single-hop connection, often
>>> related to broadcast domain
>>> - "path"
>>>     . IEEE802.15.4e: "group of links between A and B"
>>>     . general definition: multi-hop route between source and destination.
>>>
>>> We are often confused ourselves at those "colliding" definitions, so I
>>> believe there is a need to provide some definitions. This can be done as
>>> part of a next revision of
>>> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or
>>> some other draft if considered appropriate by the group.
>>>
>>> What follows is a number of terms, and tentative definitions. Let's
>>> edit/circulate this e-mail for a couple of days, then decide what makes it
>>> into the official definitions list.
>>>
>>> - slot:
>>>     - A timeslot in the TSCH schedule. A slot can be scheduled or
>>> unscheduled. During an *unscheduled* slot, the node does not communicate.
>>> When a slot is *scheduled*, it is assigned a slotframe, it is assigned a
>>> neighbor address (which can be the broadcast address), and one of more of
>>> the following flags: TX, RX, shared, timeskeeping, hard. A *broadcast
>>> *slot
>>> is an alias for "a scheduled slot with neighbor address the broadcast
>>> address".
>>>     - note: this term would replace the term "link" in the IEEE802.15.4e
>>> standard.
>>> - bundle:
>>>     - A group of equivalent scheduled slots, i.e. slots which are
>>> scheduled,
>>> on the same slotframe, with the same neighbor and with the same flags. The
>>> *
>>> size* of the bundle refers to the number of slots it contains. Given the
>>> length of the slotframe, the size of the bundle translates directly into
>>> reserved bandwidth.
>>> - (inversed) mux:
>>>     - *Qin*, would you mind giving a tentative definition here?
>>>
>>> Thomas
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>
>


From qinwang@berkeley.edu  Mon Mar  4 15:28:35 2013
Return-Path: 
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 5039821F87D1 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 15:28:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.624
X-Spam-Level: 
X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=0.975,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 f6rbTZkvMmfN for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 15:28:34 -0800 (PST)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6C15E21F87BA for <6tsch@ietf.org>; Mon,  4 Mar 2013 15:28:34 -0800 (PST)
Received: from cm03ws.ist.berkeley.edu ([169.229.218.165] helo=calmail.berkeley.edu) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UCeo4-0006TT-Hc; Mon, 04 Mar 2013 15:28:34 -0800
Received: from 76.88.33.145 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Mon, 4 Mar 2013 15:28:32 -0800
Message-ID: <87e07ca69b9c972ce15909d2b3bd7b04.squirrel@calmail.berkeley.edu>
In-Reply-To: <513524C7.70505@eecs.berkeley.edu>
References:    <513524C7.70505@eecs.berkeley.edu>
Date: Mon, 4 Mar 2013 15:28:32 -0800
From: "Qin Wang" 
To: "Xavier Vilajosana" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 23:28:35 -0000

Xavi,

Regarding the function of mux, you are right. For i-mux, I want to clarify
my thought. i-mux is also part of 6tus, which function is to shape data
flow, i.e. push incoming packets into proper bundle queue. I call it
bundle queue, because the element in the queue have same properties, like
broadcast/unicast, priority.

Regarding to the definition of "Path", there is some difference between
your thought and Thomas's definition. In Thomas's document:

**The union of all links between two neighbors, A and B, is called a
"path".**

My understanding is Thomas use "Path" refer to one hop connection, instead
of multi-hop route. But because the one hop connection is part of
end-to-end route, its bandwidth is also required by the protocols like
RSVP.

Make sense?

Qin




> Hi,
>
> as regard to a path, IMHO is the upper layer (above 6tus) who might take
> care of building the paths and maintaining them (or at least use 6tus to
> maintain them). If we look at a path node by node we can see a bundle at
> each node pointing to  its parent (the node's parent in the path). 6tus
> can be in charge of monitoring that the bandwidth requirement is being
> met (i.e whether the bundle needs more slots or not). The use of a flow
> label depends on the path reservation protocol (i.e RSVP or an extension
> to RPL) and the use of a mapping between "input bundle id and output
> bundle id" can be embedded in the packet (as a label) or keep it locally
> in each node as a switching table (i.e in node A all the packets that
> arrive at bundle X leave the node at bundle Y) .
>
> with respect to the mux - i-mux function, If I don't understand
> incorrectly the role of the mux is to act as a selector of which packet
> needs to be sent at a particular timeslot (according to certain
> priority, and other options, etc..). i-mux feeds 6tus with packets and
> according to a configuration, mux determines the packet that needs to be
> sent in the upcoming slot.
>
> Qin am I wrong?
> X
>
> On 03/03/13 22:41, Pascal Thubert wrote:
>> Hello Qin,
>>
>> I understand the concepts and the need for mux and i-mux.
>> What I do not see in your definition is the abstract concept of flow
>> which maps a particular track (which I would define as a particular -
>> reserved - sequence of bundles along a path).
>> Probably everything is in the packet (flow label?) but maybe not.
>> maybe the track is identified by the incoming bundle that must match
>> teh outgoing bundle along the track so there is an track-ID somewhere
>> in your parameters...
>>
>> Cheers,
>>
>> Pascal
>>
>>
>> 2013/3/4 Qin Wang :
>>> Thomas,
>>>
>>> In my mind, there is a picture described as follows.
>>>
>>> IP packet => 6LowPan.Fragment => (inverse_mux => mux) => TSCH
>>>
>>> Where inverse_mux and mux are two modules of 6tus.
>>>
>>> (1)inverse_mux: input includes DestAddr, Priority, MAC_payload, and
>>> others; output is a group of bundles (or queues). The function of
>>> inverse_mux is pushing the MAC_payload into one bundle according to the
>>> DestAddr and Priority.
>>>
>>> (2)mux: input parallel all of the bundles; and corresponding to each
>>> active link in TSCH schedule, mux will output a packet which is
>>> selected
>>> from the first elements of each bundle, according to the feature of the
>>> active link and QoS policy of selection run by the mux. The packet will
>>> be
>>> transmitted in the active link by TSCH.
>>>
>>> Is it clear?
>>>
>>> Qin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> All,
>>>>
>>>>  From the discussions in the "DIOs/DAOs and broadcast channels on
>>>> TSCH"
>>>> thread, it appears apparent that the IEEE802.15.4e standard uses terms
>>>> which are confusing, especially when taken into a broader context.
>>>>
>>>> For example:
>>>> - "link"
>>>>     . in IEEE802.15.4e: "single slot scheduled from A to B"
>>>>     . general definition: generic term for single-hop connection,
>>>> often
>>>> related to broadcast domain
>>>> - "path"
>>>>     . IEEE802.15.4e: "group of links between A and B"
>>>>     . general definition: multi-hop route between source and
>>>> destination.
>>>>
>>>> We are often confused ourselves at those "colliding" definitions, so I
>>>> believe there is a need to provide some definitions. This can be done
>>>> as
>>>> part of a next revision of
>>>> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01,
>>>> or
>>>> some other draft if considered appropriate by the group.
>>>>
>>>> What follows is a number of terms, and tentative definitions. Let's
>>>> edit/circulate this e-mail for a couple of days, then decide what
>>>> makes it
>>>> into the official definitions list.
>>>>
>>>> - slot:
>>>>     - A timeslot in the TSCH schedule. A slot can be scheduled or
>>>> unscheduled. During an *unscheduled* slot, the node does not
>>>> communicate.
>>>> When a slot is *scheduled*, it is assigned a slotframe, it is assigned
>>>> a
>>>> neighbor address (which can be the broadcast address), and one of more
>>>> of
>>>> the following flags: TX, RX, shared, timeskeeping, hard. A *broadcast
>>>> *slot
>>>> is an alias for "a scheduled slot with neighbor address the broadcast
>>>> address".
>>>>     - note: this term would replace the term "link" in the
>>>> IEEE802.15.4e
>>>> standard.
>>>> - bundle:
>>>>     - A group of equivalent scheduled slots, i.e. slots which are
>>>> scheduled,
>>>> on the same slotframe, with the same neighbor and with the same flags.
>>>> The
>>>> *
>>>> size* of the bundle refers to the number of slots it contains. Given
>>>> the
>>>> length of the slotframe, the size of the bundle translates directly
>>>> into
>>>> reserved bandwidth.
>>>> - (inversed) mux:
>>>>     - *Qin*, would you mind giving a tentative definition here?
>>>>
>>>> Thomas
>>>> _______________________________________________
>>>> 6tsch mailing list
>>>> 6tsch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


From qinwang@berkeley.edu  Mon Mar  4 15:52:48 2013
Return-Path: 
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 C200E11E80E5 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 15:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.819
X-Spam-Level: 
X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=0.780,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 3gmhhrj-sIub for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 15:52:48 -0800 (PST)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3875A11E80DE for <6tsch@ietf.org>; Mon,  4 Mar 2013 15:52:48 -0800 (PST)
Received: from cm03ws.ist.berkeley.edu ([169.229.218.165] helo=calmail.berkeley.edu) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UCfBW-0002gY-Hd; Mon, 04 Mar 2013 15:52:48 -0800
Received: from 76.88.33.145 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Mon, 4 Mar 2013 15:52:46 -0800
Message-ID: <3a15a455ce180f26c2ad2485410c7701.squirrel@calmail.berkeley.edu>
In-Reply-To: 
References: 
Date: Mon, 4 Mar 2013 15:52:46 -0800
From: "Qin Wang" 
To: "Thomas Watteyne" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2013 23:52:49 -0000

Thomas,

Before I can add some about mux, we need to discuss more about the
definition of "bundle". We have two different angle to use the word of
bundle now.

(1) One angle is to describe the communication resource of TSCH, i.e. like
your defined, bundle is a set of links (or slots, BTW, I prefer "Link"),
which have some common features, like same slotframe, same flag, same
neighbors.

(2) Another angle is to describe the incoming data flow in order to shape
data flow and meet QoS requirements, which is the meaning of bundle in
i-mux -mux.

The two kinds of bundle may be mapping to each other one by one, may be
not. IMHO, we need the two angles, because the first one is useful in
building and maintaining schedule; and the second one is useful in data
convey from upper layer to TSCH after the communication schedule has be
established.

So, maybe we need two terms for the two purpose, respectively? How do you
think?

Qin



> All,
>
> From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
> thread, it appears apparent that the IEEE802.15.4e standard uses terms
> which are confusing, especially when taken into a broader context.
>
> For example:
> - "link"
>    . in IEEE802.15.4e: "single slot scheduled from A to B"
>    . general definition: generic term for single-hop connection, often
> related to broadcast domain
> - "path"
>    . IEEE802.15.4e: "group of links between A and B"
>    . general definition: multi-hop route between source and destination.
>
> We are often confused ourselves at those "colliding" definitions, so I
> believe there is a need to provide some definitions. This can be done as
> part of a next revision of
> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or
> some other draft if considered appropriate by the group.
>
> What follows is a number of terms, and tentative definitions. Let's
> edit/circulate this e-mail for a couple of days, then decide what makes it
> into the official definitions list.
>
> - slot:
>    - A timeslot in the TSCH schedule. A slot can be scheduled or
> unscheduled. During an *unscheduled* slot, the node does not communicate.
> When a slot is *scheduled*, it is assigned a slotframe, it is assigned a
> neighbor address (which can be the broadcast address), and one of more of
> the following flags: TX, RX, shared, timeskeeping, hard. A *broadcast
> *slot
> is an alias for "a scheduled slot with neighbor address the broadcast
> address".
>    - note: this term would replace the term "link" in the IEEE802.15.4e
> standard.
> - bundle:
>    - A group of equivalent scheduled slots, i.e. slots which are
> scheduled,
> on the same slotframe, with the same neighbor and with the same flags. The
> *
> size* of the bundle refers to the number of slots it contains. Given the
> length of the slotframe, the size of the bundle translates directly into
> reserved bandwidth.
> - (inversed) mux:
>    - *Qin*, would you mind giving a tentative definition here?
>
> Thomas
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From robert.assimiti@nivis.com  Mon Mar  4 18:27:14 2013
Return-Path: 
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 3A14821F8771 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 18:27:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6]
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 RQjgViURWEf5 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 18:27:13 -0800 (PST)
Received: from relay-S04-HUB002.domainlocalhost.com (relay-s04-hub002.domainlocalhost.com [74.115.207.101]) by ietfa.amsl.com (Postfix) with ESMTP id CC96D21F8740 for <6tsch@ietf.org>; Mon,  4 Mar 2013 18:27:12 -0800 (PST)
Received: from S04-MBX01-08.s04.local ([169.254.8.186]) by S04-HUB002.s04.local ([10.30.12.48]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 21:27:11 -0500
From: Robert Assimiti 
To: "Pascal Thubert (pthubert)" , Maria Rita PALATTELLA , Xavier Vilajosana , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] DIOs/DAOs and broadcast channels on TSCH
Thread-Index: AQHOE9f8p0IEqvYGvEuLadPVJxUrA5iMGWoAgAA1bACAChp1gA==
Date: Tue, 5 Mar 2013 02:27:10 +0000
Message-ID: <8CF9EAFF7636FC419FEE1042DC36C12FB67398@S04-MBX01-08.s04.local>
References: <512C36F4.4000409@eecs.berkeley.edu>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.30.12.151]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2013 02:27:14 -0000

Pascal,

I have a suggestion. Rather than defining the priorities and traffic flows =
associated with them, we should provide a framework and mechanism that supp=
ort various priorities.

In order to support prioritized traffic flows one would have to come up wit=
h a priority based media access scheme.

This could be accomplished by:

1. Using prioritized links=20
2. Using prioritized slotframes
3. ??? other schemes

All of these require 802.15.4e-TSCH enhancements/additions.=20

Robert Assimiti


-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of P=
ascal Thubert (pthubert)
Sent: Tuesday, February 26, 2013 6:07 AM
To: Maria Rita PALATTELLA; Xavier Vilajosana; 6tsch@ietf.org
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hi Xavi and Maria-Rita:

We may find a number of asynchronous types. I can see:

1) RPL signaling, highest priority
2) best effort traffic, lowest priority and with no reservation at all, for=
 lesser importance sensors like corrosion.
3) lazy reservation overflow, when a small jitter is acceptable. Virtual ba=
ndwidth was reserved but physical slots are only allocated upon observed us=
e.=20

For all 3, transmission is statistical, and all 3 will be governed by QoS a=
s opposed to reservation.

So basically we'll probably need some time slots with priority to accommoda=
te either parent to any child (shared reception slot though a given packet =
may be unicast) or any child to parent (shared emission with contention) tr=
affic.=20

Is that doable?

Pascal


-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of M=
aria Rita PALATTELLA
Sent: mardi 26 f=E9vrier 2013 08:55
To: Xavier Vilajosana; 6tsch@ietf.org
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hello Xavi,
from my point of view, having a TSCH broadcast channel could be useful in s=
everal situations:

>>>a) ADV need broadcast channels in case they are used to synchronize the =
network. IEEE 802.15.4e provides the timekeeping flag to set that channels =
as used for synchronization and shared flag can make them broadcast.
>>>b) Those networks that do not need ADV for synchronization then can use =
any TX link for ADV, this means that if it is not shared only the node list=
ening on that link will get the ADV. However as this periodically occurs th=
e ADV might eventually be listened  >>>in all channels.

1) synchronization (as you said in [a]): it will allow to have a faster set=
-up phase for synchronizing all the motes in the network. While, using  any=
 TX link ([b]), even though this will hop from one channel to another, it w=
ill imply a longer set-up phase, because each mote will be able to synchron=
ize at a different time (when it is in listen mode on the "right" channel).
=20
>>>c)Some DAOs and all DIOs require a broadcast channel. Should the schedul=
e provide that? in case of a), can the same link be used? How this link sho=
uld be installed in the nodes?

2) transmission of RPL messages (DAOs and DIOs). If we want TSCH works with=
 RPL, then we should reserve some slots of the schedule for exchanging info=
rmation between L3 and L2. I am not sure we should use the same link used f=
or synchronization, maybe it could be better to have 2 different ones, dedi=
cated to different purposes. Anyway, this is something to check.=20

>>>d)Is the scheduler of the network who should setup a broadcast channel i=
ndependent of the broadcast channel set for ADV? can it be the same? Or in =
contrast, 6tus can configure the EB so it indicates a broadcast channel..

3) transmission of signaling messages for setting up the schedule. Let's  a=
ssume there is a scheduler that builds the schedule for the network. In ord=
er to assign some links to each of them, it  will need to broadcast the inf=
ormation related to ( timeOffset, ChannelOffset). As for the synchronizatio=
n, having a broadcast channel dedicated to the signaling will allow to set =
up the schedule in shorter time.=20

Maybe, because there are 16 available channels in  IEEE802.15.4/15.4e PHY, =
using some of them as broadcast channels for synchronization/exchange of cr=
oss-layer info/set up of the schedule wouldn't  be a big problem. In many a=
pplications, a smaller set of channels (< 16) will be enough for building a=
 reliable schedule.=20

6tus, as adaptation layer, may have a key role in the configuration of such=
 broadcast channels, but we will need to think  "how/when" it should take c=
are of that.

For now, let's see what other 6tus members think about!

Maria Rita

=20


-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of X=
avier Vilajosana
Sent: Tuesday, February 26, 2013 5:16 AM
To: 6tsch@ietf.org
Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hi,

I have a question that i want to discuss, the question is whether we need a=
 broadcast channel in TSCH or not and what kind of support 6tus should prov=
ide. (the answer can be depends... but lets see some cases)

a) ADV need broadcast channels in case they are used to synchronize the net=
work. IEEE 802.15.4e provides the timekeeping flag to set that channels as =
used for synchronization and shared flag can make them broadcast.
b) Those networks that do not need ADV for synchronization then can use any=
 TX link for ADV, this means that if it is not shared only the node listeni=
ng on that link will get the ADV. However as this periodically occurs the A=
DV might eventually be listened in all channels.
c)Some DAOs and all DIOs require a broadcast channel. Should the schedule p=
rovide that? in case of a), can the same link be used? How this link should=
 be installed in the nodes?
d)Is the scheduler of the network who should setup a broadcast channel inde=
pendent of the broadcast channel set for ADV? can it be the same? Or in con=
trast, 6tus can configure the EB so it indicates a broadcast channel..
e)..

I would like to know what is your opinion on that.

cheers!
Xavi
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch

From twatteyne@gmail.com  Mon Mar  4 22:11:50 2013
Return-Path: 
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 AE76C21F8771 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 22:11:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 nBlVsC01NMed for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 22:11:37 -0800 (PST)
Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8274B21F86A8 for <6tsch@ietf.org>; Mon,  4 Mar 2013 22:11:37 -0800 (PST)
Received: by mail-pb0-f51.google.com with SMTP id un15so3950221pbc.38 for <6tsch@ietf.org>; Mon, 04 Mar 2013 22:11:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=p4xEDhgLYO/iYmG1p3W4RSYO1ZgsXNbN3Uy4dCLL7QU=; b=teux5pRIS14ZmcP5df3yy8sGVu8J6RXnVWlgDuT3CbPX+oS0G05uABMZ4yReJY6Suk 7ZxW5O2oqP8MKCSZV8ivUbuSSP3as95KnU7bkZ8zuHT0mkk6OpaJb7NxHaTi04xEwETJ 8h0qBg7GjVLfg8TPpMquILm4gtNvW0OUkpMZNqLR7ROhqYU29EPUARfYNHQ1A9/3uYKh IDx46RKO/2Spm6oZnVjIuINbZCgs+ZOuzl0lqwPodi/1sfP2mqRmiNHdyMOsPbm6kg3Z e6KtHz8DlTkxlddTNjy9vQqJJ02vlmSrrznhfwZ0lUUHwXA46qt2yhH1ScmMJD9w4rrP u9rQ==
MIME-Version: 1.0
X-Received: by 10.68.189.234 with SMTP id gl10mr7049158pbc.15.1362463892686; Mon, 04 Mar 2013 22:11:32 -0800 (PST)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Mon, 4 Mar 2013 22:11:32 -0800 (PST)
In-Reply-To: 
References: 
Date: Mon, 4 Mar 2013 22:11:32 -0800
X-Google-Sender-Auth: 9G1-9Pt6v5rFr8RNOigeZ8UnHIM
Message-ID: 
From: Thomas Watteyne 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=e89a8ff24e915882f204d72758d3
Subject: Re: [6tsch] Recording of the 6TSCH call, March 1st, 2013
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2013 06:11:50 -0000

--e89a8ff24e915882f204d72758d3
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Pascal,
Having the call an hour earlier works for me.
Thomas

On Mon, Mar 4, 2013 at 3:46 AM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

>  Dear all;****
>
> ** **
>
> A number of people suggested we maintain a call record for those who
> cannot attend at the time of the meeting.****
>
> Please note that we had a rough consensus during the call to move it an
> hour earlier. This might help people in Asia, as well as ISA100 members.*=
*
> **
>
> I=92ll try to get the same consensus on the list and if I succeed, we=92l=
l
> move the call and base it on US savings per Tom=92s suggestion.****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* messenger@webex.com [mailto:messenger@webex.com]
> *Sent:* vendredi 1 mars 2013 19:06
> *To:* Pascal Thubert (pthubert)
> *Subject:* Your recording "6TSCH-20130301 1702-1" is available for viewin=
g
> ****
>
> ** **
>
> Pascal Thubert,
>
> Your recording is now available on the WebEx service site. Click the link
> below to play it:
>
>
> https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D66409322=
&rKey=3D254105c68fefa880
>
> 6TSCH-20130301 1702-1
> Friday, March 1, 2013 6:02 pm Paris Time
> 56 Minutes
>
>
> ****
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

--e89a8ff24e915882f204d72758d3
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Pascal,
Having the call an hour earlier works for me.
Thomas<=
br>

On Mon, Mar 4, 2013 at 3:46 AM, Pasc=
al Thubert (pthubert) <pthubert@cisco.com> wrote:













Dear all;


=A0<=
/p>

A number of people sugges=
ted we maintain a call record for those who cannot attend at the time of th=
e meeting.



Please note that we had a=
 rough consensus during the call to move it an hour earlier. This might hel=
p people in Asia, as well as ISA100 members.



I=92ll try to get the sam=
e consensus on the list and if I succeed, we=92ll move the call and base it=
 on US savings per Tom=92s suggestion.



=A0<=
/p>

Cheers,


=A0<=
/p>

Pascal=



=A0<=
/p>

From: messenger@webex.com [=
mailto:messenger@w=
ebex.com]


Sent: vendredi 1 mars 2013 19:06

To: Pascal Thubert (pthubert)

Subject: Your recording "6TSCH-20130301 1702-1" is availab=
le for viewing


=A0


Pascal Thubert,




Your recording is now available on the WebEx service site. Click the link b=
elow to play it:




https://ci=
sco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D66409322&=
;rKey=3D254105c68fefa880




6TSCH-20130301 1702-1 

Friday, March 1, 2013 6:02 pm Paris Time 

56 Minutes 













_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





--e89a8ff24e915882f204d72758d3--

From twatteyne@gmail.com  Mon Mar  4 22:18:32 2013
Return-Path: 
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 1F5DE21F8621 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 22:18:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.026
X-Spam-Level: 
X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.350,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1]
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 8JYCjjvG6qrE for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 22:18:31 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74A7021F861B for <6tsch@ietf.org>; Mon,  4 Mar 2013 22:18:31 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id wz12so3989105pbc.3 for <6tsch@ietf.org>; Mon, 04 Mar 2013 22:18:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=GFwqWqojR+UqInQSjsS3c9WMD6pKJCbIdHmz16twuR0=; b=TTEVqI+WGQSxVMgLsUJeA2If85eukiqErajFi9/MJ8WGuRz7crAI4Uv0mcZvFAdHyh EGvqAHQIpLUBEZSgaFYxNAAM2EEOHcGKFilMPb863f5i6Xe6Adw+aU9SOFLyNHq9IdEN Ktfx+W0UJLoTdVkb7X9unWvQDiDGzUs1y3HuUurpWjmeJRWt8rd1D+xsM28Yx8kdErCq QQdrLVaNcCUMpZ5K83FfJKw3B7GydBqtSqZFhYdLxiAkv6dzMJc7ObgbxeKLELFpfkzz JR5AQotnsfHPNEYSzwZ+GZZ4ykeuqo+BkSIbSYws7DepplwlIzfVc+ohiLZuOPGhi8tj FglQ==
MIME-Version: 1.0
X-Received: by 10.68.117.104 with SMTP id kd8mr35027661pbb.1.1362464310776; Mon, 04 Mar 2013 22:18:30 -0800 (PST)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Mon, 4 Mar 2013 22:18:30 -0800 (PST)
In-Reply-To: 
References:  
Date: Mon, 4 Mar 2013 22:18:30 -0800
X-Google-Sender-Auth: dNFb79BX6R5uwAq2hHsWTdb_yMk
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b07233044122304d72771d3
Subject: Re: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2013 06:18:32 -0000

--047d7b07233044122304d72771d3
Content-Type: text/plain; charset=ISO-8859-1

Pascal,
I second that, adding ROLL and.AUTOCONF makes perfect sense.
Thomas

On Sun, Mar 3, 2013 at 10:29 PM, Pascal Thubert wrote:

> Thomas:
>
> I agree with the problem and like your definitions. This tells me that
> we need to start our own terminology document.
> I'd suggest it includes ROLL's which is going to IESG review, as well
> as AUTOCONF, both by reference so that it stays strictly consistent.
>
> cheers,
>
> Pascal
>
> 2013/3/4 Thomas Watteyne :
> > All,
> >
> > From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
> > thread, it appears apparent that the IEEE802.15.4e standard uses terms
> which
> > are confusing, especially when taken into a broader context.
> >
> > For example:
> > - "link"
> >    . in IEEE802.15.4e: "single slot scheduled from A to B"
> >    . general definition: generic term for single-hop connection, often
> > related to broadcast domain
> > - "path"
> >    . IEEE802.15.4e: "group of links between A and B"
> >    . general definition: multi-hop route between source and destination.
> >
> > We are often confused ourselves at those "colliding" definitions, so I
> > believe there is a need to provide some definitions. This can be done as
> > part of a next revision of
> > http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or
> some
> > other draft if considered appropriate by the group.
> >
> > What follows is a number of terms, and tentative definitions. Let's
> > edit/circulate this e-mail for a couple of days, then decide what makes
> it
> > into the official definitions list.
> >
> > - slot:
> >    - A timeslot in the TSCH schedule. A slot can be scheduled or
> > unscheduled. During an unscheduled slot, the node does not communicate.
> When
> > a slot is scheduled, it is assigned a slotframe, it is assigned a
> neighbor
> > address (which can be the broadcast address), and one of more of the
> > following flags: TX, RX, shared, timeskeeping, hard. A broadcast slot is
> an
> > alias for "a scheduled slot with neighbor address the broadcast address".
> >    - note: this term would replace the term "link" in the IEEE802.15.4e
> > standard.
> > - bundle:
> >    - A group of equivalent scheduled slots, i.e. slots which are
> scheduled,
> > on the same slotframe, with the same neighbor and with the same flags.
> The
> > size of the bundle refers to the number of slots it contains. Given the
> > length of the slotframe, the size of the bundle translates directly into
> > reserved bandwidth.
> > - (inversed) mux:
> >    - Qin, would you mind giving a tentative definition here?
> >
> > Thomas
> >
> > _______________________________________________
> > 6tsch mailing list
> > 6tsch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tsch
> >
>
>
>
> --
> Pascal
>

--047d7b07233044122304d72771d3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Pascal,
I second that, adding ROLL and.AUTOCONF makes perfect sense.
Thomas

On Sun, Mar 3, 2013 at 10:=
29 PM, Pascal Thubert <pascal.thubert@gmail.com> wrot=
e:


Thomas:



I agree with the problem and like your definitions. This tells me that

we need to start our own terminology document.

I'd suggest it includes ROLL's which is going to IESG review, as we=
ll

as AUTOCONF, both by reference so that it stays strictly consistent.



cheers,



Pascal



2013/3/4 Thomas Watteyne <=
watteyne@eecs.berkeley.edu>:


> All,

>

> From the discussions in the "DIOs/DAOs and broadcast channels on =
TSCH"

> thread, it appears apparent that the IEEE802.15.4e standard uses terms=
 which

> are confusing, especially when taken into a broader context.

>

> For example:

> - "link"

> =A0 =A0. in IEEE802.15.4e: "single slot scheduled from A to B&quo=
t;

> =A0 =A0. general definition: generic term for single-hop connection, o=
ften

> related to broadcast domain

> - "path"

> =A0 =A0. IEEE802.15.4e: "group of links between A and B"

> =A0 =A0. general definition: multi-hop route between source and destin=
ation.

>

> We are often confused ourselves at those "colliding" definit=
ions, so I

> believe there is a need to provide some definitions. This can be done =
as

> part of a next revision of

> http://tools.ietf.org/html/draft-watteyne-6tsch=
-tsch-lln-context-01, or some

> other draft if considered appropriate by the group.

>

> What follows is a number of terms, and tentative definitions. Let'=
s

> edit/circulate this e-mail for a couple of days, then decide what make=
s it

> into the official definitions list.

>

> - slot:

> =A0 =A0- A timeslot in the TSCH schedule. A slot can be scheduled or
> unscheduled. During an unscheduled slot, the node does not communicate=
. When

> a slot is scheduled, it is assigned a slotframe, it is assigned a neig=
hbor

> address (which can be the broadcast address), and one of more of the
> following flags: TX, RX, shared, timeskeeping, hard. A broadcast slot =
is an

> alias for "a scheduled slot with neighbor address the broadcast a=
ddress".

> =A0 =A0- note: this term would replace the term "link" in th=
e IEEE802.15.4e

> standard.

> - bundle:

> =A0 =A0- A group of equivalent scheduled slots, i.e. slots which are s=
cheduled,

> on the same slotframe, with the same neighbor and with the same flags.=
 The

> size of the bundle refers to the number of slots it contains. Given th=
e

> length of the slotframe, the size of the bundle translates directly in=
to

> reserved bandwidth.

> - (inversed) mux:

> =A0 =A0- Qin, would you mind giving a tentative definition here?

>

> Thomas

>


> _______________________________________________

> 6tsch mailing list

> 6tsch@ietf.org

> https://www.ietf.org/mailman/listinfo/6tsch

>







--

Pascal





--047d7b07233044122304d72771d3--

From twatteyne@gmail.com  Mon Mar  4 22:27:32 2013
Return-Path: 
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 D19A221F89E9 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 22:27:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level: 
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.533,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 pUuCm4S458w1 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 22:27:31 -0800 (PST)
Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id ACEE321F89D3 for <6tsch@ietf.org>; Mon,  4 Mar 2013 22:27:25 -0800 (PST)
Received: by mail-pb0-f48.google.com with SMTP id wy12so3968605pbc.35 for <6tsch@ietf.org>; Mon, 04 Mar 2013 22:27:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=r4qe1eZRZBl2dfKzQHq4QOA7uhs1KsaHWT1jqTDAz2w=; b=UsUEPOto1WYGHQ82Zio1hjs31CqfFVs24bC32QiFmhIilT5b4SX8g0TOa6RbGgC7pg /PaLTJGaZ2HcYKfm55eu9P0k5oycuTlRkgtdS7nqTO5jgVbkd3gqyAtM1p/cWraQY5UP 2BUzbthf0e0SfpiF474aAZDLkUKeMUcKSdpNHnx20wD0yJlYufhMcfUeqdhAI0o9NJ6Y 9R4+tMoPm84n9MMszfzXNau6FBQak7Coku52PORZ1UVoGv/GFy9l2JuCq1xWjwbFGxrY TZOPMQpTPU5LpR8vtDonF6aP4eDlim458ePWhaoQP5As7DGbUL0EWcUOr3qJoJ6sVGKR YUCg==
MIME-Version: 1.0
X-Received: by 10.68.24.133 with SMTP id u5mr34226310pbf.144.1362464845245; Mon, 04 Mar 2013 22:27:25 -0800 (PST)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Mon, 4 Mar 2013 22:27:25 -0800 (PST)
In-Reply-To: 
References:  
Date: Mon, 4 Mar 2013 22:27:25 -0800
X-Google-Sender-Auth: eXMLgbAsfT2QMR3iL-XdvCMfa-w
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=bcaec521577d1f6a5904d727916a
Subject: Re: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2013 06:27:32 -0000

--bcaec521577d1f6a5904d727916a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Maria Rita,

I agree that a cell (or whatever we end up calling it) is assigned a
channel offset, and that in a network, multiple cells can occur at the same
time, yielding simultaneous communication between different pairs of motes
at difference frequencies.

Yet, a single mote can only do one thing at a time, and so at a given
timeslot, it will have to pick which cell to execute if it has multiple in
its schedule at that timeslot (does this make sense?). My idea was simply
to call it slot (which is rather common in TDMA), but I'm perfectly happy
calling it cell if people agree that it's not confusing.

What do others think: slot or cell?

Thomas

On Sun, Mar 3, 2013 at 11:44 PM, Maria Rita PALATTELLA <
maria-rita.palattella@uni.lu> wrote:

>  Thomas,****
>
> ** **
>
> I totally agree with you and Pascal about the need of  introducing  ad-ho=
c
> definitions for 6tus, in order to avoid any kind of confusion when
> integrating IEEE802.15.4e with 6LoWPAN, RPL and other standards. ****
>
> ** **
>
> Maybe it is the case to have a specific draft, including all the
> definitions we may need,  and keep the other draft as a general overview =
of
> problems and goals. What do you think?****
>
> ** **
>
> Even though I like your definition of =93slot=94
> scheduled/unscheduled/broadcast, I have a =93little=94 concern. In our
> discussion we are not taking in account that the link definition in
> IEEE802.15.4e includes also the *channel offset* value.  In fact, a node
> A needs to know not only the time slot, but also the channel offset (and
> thus, the frequency) on which it will be allowed to transmit to a its
> parent node B.****
>
> ** **
>
> Shall we then use another type of definition, like RESERVED/UNRESERVED
> CELL  or Scheduled/Unscheduled cell, where a CELL within the slotframe=92=
s
> grid  is given by   (time slot, channel offset) .****
>
> ** **
>
> The same concern comes when we define the path. We have somehow to specif=
y
> that each equivalent slot may be scheduled  on different channel offset.
>  So, according to your definition,  they are  =93slots which are schedule=
d,
> on the same slotframe, with the same neighbor and with the same flags, on
> the same and/or different channel offsets=94.****
>
> ** **
>
> Maria Rita****
>
> ** **
>
> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On Behalf
> Of *Thomas Watteyne
> *Sent:* Monday, March 04, 2013 12:57 AM
> *To:* IETF 6TSCH
> *Subject:* [6tsch] 6tsch definitions****
>
> ** **
>
> All,****
>
> ** **
>
> From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
> thread, it appears apparent that the IEEE802.15.4e standard uses terms
> which are confusing, especially when taken into a broader context.****
>
> ** **
>
> For example:****
>
> - "link"****
>
>    . in IEEE802.15.4e: "single slot scheduled from A to B"****
>
>    . general definition: generic term for single-hop connection, often
> related to broadcast domain****
>
> - "path"****
>
>    . IEEE802.15.4e: "group of links between A and B"****
>
>    . general definition: multi-hop route between source and destination.*=
*
> **
>
> ** **
>
> We are often confused ourselves at those "colliding" definitions, so I
> believe there is a need to provide some definitions. This can be done as
> part of a next revision of
> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or
> some other draft if considered appropriate by the group.****
>
> ** **
>
> What follows is a number of terms, and tentative definitions. Let's
> edit/circulate this e-mail for a couple of days, then decide what makes i=
t
> into the official definitions list.****
>
> ** **
>
> - slot:****
>
>    - A timeslot in the TSCH schedule. A slot can be scheduled or
> unscheduled. During an *unscheduled* slot, the node does not communicate.
> When a slot is *scheduled*, it is assigned a slotframe, it is assigned a
> neighbor address (which can be the broadcast address), and one of more of
> the following flags: TX, RX, shared, timeskeeping, hard. A *broadcast *sl=
ot
> is an alias for "a scheduled slot with neighbor address the broadcast
> address".****
>
>    - note: this term would replace the term "link" in the IEEE802.15.4e
> standard.****
>
> - bundle:****
>
>    - A group of equivalent scheduled slots, i.e. slots which are
> scheduled, on the same slotframe, with the same neighbor and with the sam=
e
> flags. The *size* of the bundle refers to the number of slots it
> contains. Given the length of the slotframe, the size of the bundle
> translates directly into reserved bandwidth.****
>
> - (inversed) mux:****
>
>    - *Qin*, would you mind giving a tentative definition here?****
>
> ** **
>
> Thomas****
>

--bcaec521577d1f6a5904d727916a
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Maria Rita,

I agree that a cell (or whatever we end up c=
alling it) is assigned a channel offset, and that in a network, multiple ce=
lls can occur at the same time, yielding=A0simultaneous=A0communication bet=
ween different pairs of motes at difference frequencies.



Yet, a single mote can only do one thing at a time, and=
 so at a given timeslot, it will have to pick which cell to execute if it h=
as multiple in its schedule at that timeslot (does this make sense?). My id=
ea was simply to call it slot (which is rather common in TDMA), but I'm=
 perfectly happy calling it cell if people agree that it's not confusin=
g.



What do others think: slot or cell?

Thomas

On Sun, Mar 3, 2013 at 11:44=
 PM, Maria Rita PALATTELLA <maria-rita.palattella@uni.lu>=
; wrote:













Thomas,


=A0<=
/p>

I totally agree with you =
and Pascal about the need of =A0introducing =A0ad-hoc definitions for 6tus,=
 in order to avoid any kind of confusion when integrating IEEE802.15.4e
 with 6LoWPAN, RPL and other standards. 


=A0<=
/p>

Maybe it is the case to h=
ave a specific draft, including all the definitions we may need, =A0and kee=
p the other draft as a general overview of problems and goals.
 What do you think?


=A0<=
/p>

Even though I like your d=
efinition of =93slot=94 scheduled/unscheduled/broadcast, I have a =93little=
=94 concern. In our discussion we are not taking in account that
 the link definition in IEEE802.15.4e includes also the channel offse=
t value. =A0In fact, a node A needs to know not only the time slot,=
 but also the channel offset (and thus, the frequency) on which it will be =
allowed to transmit to a its parent
 node B.


=A0<=
/p>

Shall we then use another=
 type of definition, like RESERVED/UNRESERVED CELL=A0 or Scheduled/Unschedu=
led cell, where a CELL within the slotframe=92s grid =A0is given
 by =A0=A0(time slot, channel offset) .


=A0<=
/p>

The same concern comes wh=
en we define the path. We have somehow to specify that each equivalent slot=
 may be scheduled=A0 on different channel offset. =A0So, according
 to your definition,=A0 they are =A0=93sl=
ots which are scheduled, on the same slotframe, with the same neighbor and =
with the same flags, on the same and/or different channel offsets=94.



=A0<=
/p>

Maria Rita<=
/span>


=A0<=
/p>

From: 6tsch-bounces@ietf.org=
 [mailto:6t=
sch-bounces@ietf.org]
On Behalf Of Thomas Watteyne

Sent: Monday, March 04, 2013 12:57 AM

To: IETF 6TSCH

Subject: [6tsch] 6tsch definitions


=A0


=
All,




=A0






=
>From the discussions in the=A0"DIOs/DAOs and broadcast channels on TSC=
H" thread, it appears apparent that the IEEE802.15.4e standard uses te=
rms which are confusing, especially when taken into a broader
 context.






=A0






=
For example:






=
- "link"






=
=A0 =A0. in IEEE802.15.4e: "single slot scheduled from A to B"






=
=A0 =A0. general definition: generic term for single-hop connection, often =
related to broadcast domain






=
- "path"






=
=A0 =A0. IEEE802.15.4e: "group of links between A and B"






=
=A0 =A0. general definition: multi-hop route between source and destination=
.






=A0






=
We are often confused ourselves at those "colliding" definitions,=
 so I believe there is a need to provide some definitions. This can be done=
 as part of a next revision of=A0http://tools.ietf.o=
rg/html/draft-watteyne-6tsch-tsch-lln-context-01,
 or some other draft if considered appropriate by the group.<=
u>






=A0






=
What follows is a number of terms, and tentative definitions. Let's edi=
t/circulate this e-mail for a couple of days, then decide what makes it int=
o the official definitions list.







=A0






=
- slot:






=
=A0 =A0- A timeslot in the TSCH schedule. A slot can be scheduled or unsche=
duled. During an
unscheduled slot, the node does not communicate. When a slot is s=
cheduled, it is assigned a slotframe, it is assigned a neighbor address=
 (which can be the broadcast address), and one of more of the following fla=
gs: TX, RX, shared, timeskeeping,
 hard. A broadcast slot is an alias for "a scheduled slot with =
neighbor address the broadcast address".






=
=A0 =A0- note: this term would replace the term "link" in the IEE=
E802.15.4e standard.






=
- bundle:






=
=A0 =A0- A group of equivalent scheduled slots, i.e. slots which are schedu=
led, on the same slotframe, with the same neighbor and with the same flags.=
 The
size of the bundle refers to the number of slots it contains. Given =
the length of the slotframe, the size of the bundle translates directly int=
o reserved bandwidth.






=
- (inversed) mux:






=
=A0 =A0- Qin, would you mind giving a tentative definition here?






=A0






=
Thomas












--bcaec521577d1f6a5904d727916a--

From twatteyne@gmail.com  Mon Mar  4 22:40:21 2013
Return-Path: 
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 015A421F86D9 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 22:40:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level: 
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.400,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 5B95CGpl8w+p for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 22:40:19 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C127321F86D6 for <6tsch@ietf.org>; Mon,  4 Mar 2013 22:40:19 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id wz12so3988630pbc.31 for <6tsch@ietf.org>; Mon, 04 Mar 2013 22:40:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=PRiGA8R4F3xTZNUhG70IeHy06QeFqq0lXFavf4TnI40=; b=DCWbRCviqPhHWrqIhc/RXTqd3jgoR5SYrzAYcFbRuleRMpb+bt24tWlhUArV9/GBap 6aTislDPvjlmqbmBW9wi+6pSjV9HEycJlZLYaz66hc2fAtfU3h4UEBBOKp4UJ4VLYIzB eluG8UhYW0vypNjzTTR+naEvy1iJ+il8P4vbP5etE5z/R2diUDlxSYIZEZnlAFflc9Me IBABbmcb8QruHvcNUSpLh5npJzm7zVqTQ2PJA3751RCNYnGz0f4AFHXd4X1Y2fovJ/3Y 88Ybh0EuO6yp86Fc/ZVw848D8huk88Ho9dF0F/bQYSzimPQ1buV2i/mVDow/ndHD3vQQ EY/Q==
MIME-Version: 1.0
X-Received: by 10.68.50.231 with SMTP id f7mr14138367pbo.221.1362465619182; Mon, 04 Mar 2013 22:40:19 -0800 (PST)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Mon, 4 Mar 2013 22:40:18 -0800 (PST)
In-Reply-To: <3a15a455ce180f26c2ad2485410c7701.squirrel@calmail.berkeley.edu>
References:  <3a15a455ce180f26c2ad2485410c7701.squirrel@calmail.berkeley.edu>
Date: Mon, 4 Mar 2013 22:40:18 -0800
X-Google-Sender-Auth: RdmrUw4_-0yS-Ln7ijzkXlKBFDE
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=bcaec52e58bf40c65004d727bf23
Subject: Re: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2013 06:40:21 -0000

--bcaec52e58bf40c65004d727bf23
Content-Type: text/plain; charset=ISO-8859-1

Qin,

[Quick questions about definition: do you mean that you prefer the term
link over slot or cell? Are you not afraid that people will mistake a TSCH
link with, say a broadcast domain? I believe this is what started this
thread. If you do not agree, please speak up.]

In my mind, a bundle is a group of slots which are entirely equivalent.
That is, once a packet has made it into some queue, it can go out on any
slot of the bundle. That is, there can be multiple bundles from mote A to
mote B. Does this definition work for you? I can absolutely be convinced
otherwise, but, if possible, I'd like to keep the number of new definitions
are concepts to a minimum, so if possible keep a single term.

Thoughts?

Thomas

On Mon, Mar 4, 2013 at 3:52 PM, Qin Wang  wrote:

> Thomas,
>
> Before I can add some about mux, we need to discuss more about the
> definition of "bundle". We have two different angle to use the word of
> bundle now.
>
> (1) One angle is to describe the communication resource of TSCH, i.e. like
> your defined, bundle is a set of links (or slots, BTW, I prefer "Link"),
> which have some common features, like same slotframe, same flag, same
> neighbors.
>
> (2) Another angle is to describe the incoming data flow in order to shape
> data flow and meet QoS requirements, which is the meaning of bundle in
> i-mux -mux.
>
> The two kinds of bundle may be mapping to each other one by one, may be
> not. IMHO, we need the two angles, because the first one is useful in
> building and maintaining schedule; and the second one is useful in data
> convey from upper layer to TSCH after the communication schedule has be
> established.
>
> So, maybe we need two terms for the two purpose, respectively? How do you
> think?
>
> Qin
>
>
>
> > All,
> >
> > From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
> > thread, it appears apparent that the IEEE802.15.4e standard uses terms
> > which are confusing, especially when taken into a broader context.
> >
> > For example:
> > - "link"
> >    . in IEEE802.15.4e: "single slot scheduled from A to B"
> >    . general definition: generic term for single-hop connection, often
> > related to broadcast domain
> > - "path"
> >    . IEEE802.15.4e: "group of links between A and B"
> >    . general definition: multi-hop route between source and destination.
> >
> > We are often confused ourselves at those "colliding" definitions, so I
> > believe there is a need to provide some definitions. This can be done as
> > part of a next revision of
> > http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or
> > some other draft if considered appropriate by the group.
> >
> > What follows is a number of terms, and tentative definitions. Let's
> > edit/circulate this e-mail for a couple of days, then decide what makes
> it
> > into the official definitions list.
> >
> > - slot:
> >    - A timeslot in the TSCH schedule. A slot can be scheduled or
> > unscheduled. During an *unscheduled* slot, the node does not communicate.
> > When a slot is *scheduled*, it is assigned a slotframe, it is assigned a
> > neighbor address (which can be the broadcast address), and one of more of
> > the following flags: TX, RX, shared, timeskeeping, hard. A *broadcast
> > *slot
> > is an alias for "a scheduled slot with neighbor address the broadcast
> > address".
> >    - note: this term would replace the term "link" in the IEEE802.15.4e
> > standard.
> > - bundle:
> >    - A group of equivalent scheduled slots, i.e. slots which are
> > scheduled,
> > on the same slotframe, with the same neighbor and with the same flags.
> The
> > *
> > size* of the bundle refers to the number of slots it contains. Given the
> > length of the slotframe, the size of the bundle translates directly into
> > reserved bandwidth.
> > - (inversed) mux:
> >    - *Qin*, would you mind giving a tentative definition here?
> >
> > Thomas
> > _______________________________________________
> > 6tsch mailing list
> > 6tsch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tsch
> >
>
>
>

--bcaec52e58bf40c65004d727bf23
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Qin,

[Quick questions about definition: do you mean that=
 you prefer the term link over slot or cell? Are you not afraid that people=
 will mistake a TSCH link with, say a broadcast domain? I believe this is w=
hat started this thread. If you do not agree, please speak up.]



In my mind, a bundle is a group of slots which are enti=
rely equivalent. That is, once a packet has made it into some queue, it can=
 go out on any slot of the bundle. That is, there can be multiple bundles f=
rom mote A to mote B. Does this definition work for you? I can=A0absolutely=
=A0be convinced otherwise, but, if possible, I'd like to keep the numbe=
r of new definitions are concepts to a minimum, so if possible keep a singl=
e term.



Thoughts?

Thomas
On Mon, Mar 4, 2013 at 3:52 PM, Qin Wang <q=
inwang@berkeley.edu> wrote:


Thomas,



Before I can add some about mux, we need to discuss more about the

definition of "bundle". We have two different angle to use the wo=
rd of

bundle now.



(1) One angle is to describe the communication resource of TSCH, i.e. like<=
br>
your defined, bundle is a set of links (or slots, BTW, I prefer "Link&=
quot;),

which have some common features, like same slotframe, same flag, same

neighbors.



(2) Another angle is to describe the incoming data flow in order to shape
data flow and meet QoS requirements, which is the meaning of bundle in

i-mux -mux.



The two kinds of bundle may be mapping to each other one by one, may be

not. IMHO, we need the two angles, because the first one is useful in

building and maintaining schedule; and the second one is useful in data

convey from upper layer to TSCH after the communication schedule has be

established.



So, maybe we need two terms for the two purpose, respectively? How do you
think?



Qin








> All,

>

> From the discussions in the "DIOs/DAOs and broadcast channels on =
TSCH"

> thread, it appears apparent that the IEEE802.15.4e standard uses terms=


> which are confusing, especially when taken into a broader context.

>

> For example:

> - "link"

> =A0 =A0. in IEEE802.15.4e: "single slot scheduled from A to B&quo=
t;

> =A0 =A0. general definition: generic term for single-hop connection, o=
ften

> related to broadcast domain

> - "path"

> =A0 =A0. IEEE802.15.4e: "group of links between A and B"

> =A0 =A0. general definition: multi-hop route between source and destin=
ation.

>

> We are often confused ourselves at those "colliding" definit=
ions, so I

> believe there is a need to provide some definitions. This can be done =
as

> part of a next revision of

> http://tools.ietf.org/html/draft-watteyne-6tsch=
-tsch-lln-context-01, or

> some other draft if considered appropriate by the group.

>

> What follows is a number of terms, and tentative definitions. Let'=
s

> edit/circulate this e-mail for a couple of days, then decide what make=
s it

> into the official definitions list.

>

> - slot:

> =A0 =A0- A timeslot in the TSCH schedule. A slot can be scheduled or

> unscheduled. During an *unscheduled* slot, the node does not com=
municate.

> When a slot is *scheduled*, it is assigned a slotframe, it is assigned=
 a


> neighbor address (which can be the broadcast address=
), and one of more of


> the following flags: TX, RX, shared, timeskeeping, hard. A *broa=
dcast

> *slot


> is an alias for "a scheduled slot with neighbor=
 address the broadcast

> address".

> =A0 =A0- note: this term would replace the term "link" in th=
e IEEE802.15.4e

> standard.

> - bundle:

> =A0 =A0- A group of equivalent scheduled slots, i.e. slots which are
> scheduled,

> on the same slotframe, with the same neighbor and with the same flags.=
 The


> *

> size* of the bundle refers to the number of slots it contains. Given t=
he


> length of the slotframe, the size of the bundle tran=
slates directly into

> reserved bandwidth.

> - (inversed) mux:


> =A0 =A0- *Qin*, would you mind giving a tentative definition her=
e?

>

> Thomas


> ______________________________=
_________________

> 6tsch mailing list

> 6tsch@ietf.org

> https://www.ietf.org/mailman/listinfo/6tsch

>









--bcaec52e58bf40c65004d727bf23--

From twatteyne@gmail.com  Mon Mar  4 22:59:02 2013
Return-Path: 
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 A068A21F8645 for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 22:59:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.056
X-Spam-Level: 
X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1]
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 20FONIG7gcOZ for <6tsch@ietfa.amsl.com>; Mon,  4 Mar 2013 22:59:01 -0800 (PST)
Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6907921F856E for <6tsch@ietf.org>; Mon,  4 Mar 2013 22:59:01 -0800 (PST)
Received: by mail-pb0-f46.google.com with SMTP id uo15so3991231pbc.5 for <6tsch@ietf.org>; Mon, 04 Mar 2013 22:59:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Ugo7HxPR8Cs0/Gn5Ta5uSJiBpTCcFtBKgpzjtV3/KzM=; b=ieb27EAiv0Z0Y8Nr+aJFfySeci6yygMovdCVFlLnij8K4hDMek8NVG4UPj2GBFg7Lo 4inhnW+zYmdorW0T5XQ2w4BUIpQXpLOIMrsaB44pdbj2wFIyP6cP4kC1Joc5bvYe++Ee 8St7XEhJTYKwSPUnpPrvPXLA3cek91r5TLFxB7fxXYPbpaRGPLFzgLeWT9Xpzkb6AQ+G hYdiZHeyZj/WOfUWgyx38JSoEBKQkNdhqEeA0/coHKmzsJn9PRRE1OKHFiuRbrdBrt9E qGiUxNwAPOtgjA2hsNaf0Xeold/fGjlQb6Tu6NDpCnBDXM3AJYW22rwju14KkpAhzfGp JWUA==
MIME-Version: 1.0
X-Received: by 10.68.227.202 with SMTP id sc10mr34499466pbc.109.1362466740831;  Mon, 04 Mar 2013 22:59:00 -0800 (PST)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Mon, 4 Mar 2013 22:59:00 -0800 (PST)
In-Reply-To: <8CF9EAFF7636FC419FEE1042DC36C12FB67398@S04-MBX01-08.s04.local>
References: <512C36F4.4000409@eecs.berkeley.edu>   <8CF9EAFF7636FC419FEE1042DC36C12FB67398@S04-MBX01-08.s04.local>
Date: Mon, 4 Mar 2013 22:59:00 -0800
X-Google-Sender-Auth: KYMej_zUSxJNEJczV9kqt3XUbw0
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b2eda151bbde304d72802c9
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2013 06:59:02 -0000

--047d7b2eda151bbde304d72802c9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1

What is your opinion on Qin's suggestion to have a priority translating
into queues/bundles? (Qin, please correct me if I'm wrong).

TSCH assigns a priority to slotframes, and leaves the rest for us to figure
out. I have a hard time deciding whether our discussions suggest that:
1. slotframe priority is much too coarse and what we need is really
bundle-based priorities, OR
2. what we are inventing for bundles can really be achieved by using
good-old slotframes, and that all we are discussing (including queuing) is
actually already present in TSCH. That is, we can apply everything we are
discussing in the context of a bundle to a slotframe: we would end up
having a slotframe per type of traffic, i.e. a final destination and a QoS
level. Slotframes could also encompass label switching (i.e. packet I
receive on RX links of slotframe 3 need to be sent on TX links of the same
slotframe). The only thing missing is that you need to write the slotframe
ID in the packet in case you have two TX cells in the same slot.

Again, while this is a very open-ended question, it has a big impact of our
next steps, and I'd like to get the list's opinion.

I'd like to avoid as much as possible to reinvent concepts that are already
present. Looking forward to being proven wrong.

Thomas

On Mon, Mar 4, 2013 at 6:27 PM, Robert Assimiti
wrote:

> Pascal,
>
> I have a suggestion. Rather than defining the priorities and traffic flow=
s
> associated with them, we should provide a framework and mechanism that
> support various priorities.
>
> In order to support prioritized traffic flows one would have to come up
> with a priority based media access scheme.
>
> This could be accomplished by:
>
> 1. Using prioritized links
> 2. Using prioritized slotframes
> 3. ??? other schemes
>
> All of these require 802.15.4e-TSCH enhancements/additions.
>
> Robert Assimiti
>
>
> -----Original Message-----
> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of
> Pascal Thubert (pthubert)
> Sent: Tuesday, February 26, 2013 6:07 AM
> To: Maria Rita PALATTELLA; Xavier Vilajosana; 6tsch@ietf.org
> Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>
> Hi Xavi and Maria-Rita:
>
> We may find a number of asynchronous types. I can see:
>
> 1) RPL signaling, highest priority
> 2) best effort traffic, lowest priority and with no reservation at all,
> for lesser importance sensors like corrosion.
> 3) lazy reservation overflow, when a small jitter is acceptable. Virtual
> bandwidth was reserved but physical slots are only allocated upon observe=
d
> use.
>
> For all 3, transmission is statistical, and all 3 will be governed by QoS
> as opposed to reservation.
>
> So basically we'll probably need some time slots with priority to
> accommodate either parent to any child (shared reception slot though a
> given packet may be unicast) or any child to parent (shared emission with
> contention) traffic.
>
> Is that doable?
>
> Pascal
>
>
> -----Original Message-----
> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of
> Maria Rita PALATTELLA
> Sent: mardi 26 f=E9vrier 2013 08:55
> To: Xavier Vilajosana; 6tsch@ietf.org
> Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>
> Hello Xavi,
> from my point of view, having a TSCH broadcast channel could be useful in
> several situations:
>
> >>>a) ADV need broadcast channels in case they are used to synchronize th=
e
> network. IEEE 802.15.4e provides the timekeeping flag to set that channel=
s
> as used for synchronization and shared flag can make them broadcast.
> >>>b) Those networks that do not need ADV for synchronization then can us=
e
> any TX link for ADV, this means that if it is not shared only the node
> listening on that link will get the ADV. However as this periodically
> occurs the ADV might eventually be listened  >>>in all channels.
>
> 1) synchronization (as you said in [a]): it will allow to have a faster
> set-up phase for synchronizing all the motes in the network. While, using
>  any TX link ([b]), even though this will hop from one channel to another=
,
> it will imply a longer set-up phase, because each mote will be able to
> synchronize at a different time (when it is in listen mode on the "right"
> channel).
>
> >>>c)Some DAOs and all DIOs require a broadcast channel. Should the
> schedule provide that? in case of a), can the same link be used? How this
> link should be installed in the nodes?
>
> 2) transmission of RPL messages (DAOs and DIOs). If we want TSCH works
> with RPL, then we should reserve some slots of the schedule for exchangin=
g
> information between L3 and L2. I am not sure we should use the same link
> used for synchronization, maybe it could be better to have 2 different
> ones, dedicated to different purposes. Anyway, this is something to check=
.
>
> >>>d)Is the scheduler of the network who should setup a broadcast channel
> independent of the broadcast channel set for ADV? can it be the same? Or =
in
> contrast, 6tus can configure the EB so it indicates a broadcast channel..
>
> 3) transmission of signaling messages for setting up the schedule. Let's
>  assume there is a scheduler that builds the schedule for the network. In
> order to assign some links to each of them, it  will need to broadcast th=
e
> information related to ( timeOffset, ChannelOffset). As for the
> synchronization, having a broadcast channel dedicated to the signaling wi=
ll
> allow to set up the schedule in shorter time.
>
> Maybe, because there are 16 available channels in  IEEE802.15.4/15.4e PHY=
,
> using some of them as broadcast channels for synchronization/exchange of
> cross-layer info/set up of the schedule wouldn't  be a big problem. In ma=
ny
> applications, a smaller set of channels (< 16) will be enough for buildin=
g
> a reliable schedule.
>
> 6tus, as adaptation layer, may have a key role in the configuration of
> such broadcast channels, but we will need to think  "how/when" it should
> take care of that.
>
> For now, let's see what other 6tus members think about!
>
> Maria Rita
>
>
>
>
> -----Original Message-----
> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of
> Xavier Vilajosana
> Sent: Tuesday, February 26, 2013 5:16 AM
> To: 6tsch@ietf.org
> Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>
> Hi,
>
> I have a question that i want to discuss, the question is whether we need
> a broadcast channel in TSCH or not and what kind of support 6tus should
> provide. (the answer can be depends... but lets see some cases)
>
> a) ADV need broadcast channels in case they are used to synchronize the
> network. IEEE 802.15.4e provides the timekeeping flag to set that channel=
s
> as used for synchronization and shared flag can make them broadcast.
> b) Those networks that do not need ADV for synchronization then can use
> any TX link for ADV, this means that if it is not shared only the node
> listening on that link will get the ADV. However as this periodically
> occurs the ADV might eventually be listened in all channels.
> c)Some DAOs and all DIOs require a broadcast channel. Should the schedule
> provide that? in case of a), can the same link be used? How this link
> should be installed in the nodes?
> d)Is the scheduler of the network who should setup a broadcast channel
> independent of the broadcast channel set for ADV? can it be the same? Or =
in
> contrast, 6tus can configure the EB so it indicates a broadcast channel..
> e)..
>
> I would like to know what is your opinion on that.
>
> cheers!
> Xavi
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>

--047d7b2eda151bbde304d72802c9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1

What is your opinion on Qin's suggestion to have =
a priority translating into queues/bundles? (Qin, please correct me if I=
9;m wrong).

TSCH assigns a priority to slotframes,=
 and leaves the rest for us to figure out. I have a hard time deciding whet=
her our discussions suggest that:


1. slotframe priority is much too coarse and what we need is really bu=
ndle-based priorities, OR
2. what we are inventing for bundles ca=
n really be achieved by using good-old slotframes, and that all we are disc=
ussing (including queuing) is actually already present in TSCH. That is, we=
 can apply everything we are discussing in the context of a bundle to a slo=
tframe: we would end up having a slotframe per type of traffic, i.e. a fina=
l destination and a QoS level. Slotframes could also encompass label switch=
ing (i.e. packet I receive on RX links of slotframe 3 need to be sent on TX=
 links of the same slotframe). The only thing missing is that you need to w=
rite the slotframe ID in the packet in case you have two TX cells in the sa=
me slot.=A0



Again, while this is a very open-ended question, it has=
 a big impact of our next steps, and I'd like to get the list's opi=
nion.

I'd like to avoid as much as possible to=
 reinvent concepts that are already present. Looking forward to being prove=
n wrong.



Thomas

On Mon, Mar 4,=
 2013 at 6:27 PM, Robert Assimiti <robert.assimiti@nivis.com&g=
t; wrote:


Pascal,



I have a suggestion. Rather than defining the priorities and traffic flows =
associated with them, we should provide a framework and mechanism that supp=
ort various priorities.



In order to support prioritized traffic flows one would have to come up wit=
h a priority based media access scheme.



This could be accomplished by:



1. Using prioritized links

2. Using prioritized slotframes

3. ??? other schemes



All of these require 802.15.4e-TSCH enhancements/additions.



Robert Assimiti






-----Original Message-----

From: 6tsch-bounces@ietf.org =
[mailto:6tsch-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)

Sent: Tuesday, February 26, 2013 6:07 AM

To: Maria Rita PALATTELLA; Xavier Vilajosana; 6tsch@ietf.org

Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH



Hi Xavi and Maria-Rita:



We may find a number of asynchronous types. I can see:



1) RPL signaling, highest priority

2) best effort traffic, lowest priority and with no reservation at all, for=
 lesser importance sensors like corrosion.

3) lazy reservation overflow, when a small jitter is acceptable. Virtual ba=
ndwidth was reserved but physical slots are only allocated upon observed us=
e.



For all 3, transmission is statistical, and all 3 will be governed by QoS a=
s opposed to reservation.



So basically we'll probably need some time slots with priority to accom=
modate either parent to any child (shared reception slot though a given pac=
ket may be unicast) or any child to parent (shared emission with contention=
) traffic.




Is that doable?



Pascal





-----Original Message-----

From: 6tsch-bounces@ietf.org =
[mailto:6tsch-bounces@ietf.org] On Behalf Of Maria Rita PALATTELLA

Sent: mardi 26 f=E9vrier 2013 08:55

To: Xavier Vilajosana; 6tsch@ietf.org=


Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH



Hello Xavi,

from my point of view, having a TSCH broadcast channel could be useful in s=
everal situations:



>>>a) ADV need broadcast channels in case they are used to synchro=
nize the network. IEEE 802.15.4e provides the timekeeping flag to set that =
channels as used for synchronization and shared flag can make them broadcas=
t.


>>>b) Those networks that do not need ADV for synchronization then=
 can use any TX link for ADV, this means that if it is not shared only the =
node listening on that link will get the ADV. However as this periodically =
occurs the ADV might eventually be listened =A0>>>in all channels.=





1) synchronization (as you said in [a]): it will allow to have a faster set=
-up phase for synchronizing all the motes in the network. While, using =A0a=
ny TX link ([b]), even though this will hop from one channel to another, it=
 will imply a longer set-up phase, because each mote will be able to synchr=
onize at a different time (when it is in listen mode on the "right&quo=
t; channel).




>>>c)Some DAOs and all DIOs require a broadcast channel. Should th=
e schedule provide that? in case of a), can the same link be used? How this=
 link should be installed in the nodes?



2) transmission of RPL messages (DAOs and DIOs). If we want TSCH works with=
 RPL, then we should reserve some slots of the schedule for exchanging info=
rmation between L3 and L2. I am not sure we should use the same link used f=
or synchronization, maybe it could be better to have 2 different ones, dedi=
cated to different purposes. Anyway, this is something to check.




>>>d)Is the scheduler of the network who should setup a broadcast =
channel independent of the broadcast channel set for ADV? can it be the sam=
e? Or in contrast, 6tus can configure the EB so it indicates a broadcast ch=
annel..




3) transmission of signaling messages for setting up the schedule. Let'=
s =A0assume there is a scheduler that builds the schedule for the network. =
In order to assign some links to each of them, it =A0will need to broadcast=
 the information related to ( timeOffset, ChannelOffset). As for the synchr=
onization, having a broadcast channel dedicated to the signaling will allow=
 to set up the schedule in shorter time.




Maybe, because there are 16 available channels in =A0IEEE802.15.4/15.4e PHY=
, using some of them as broadcast channels for synchronization/exchange of =
cross-layer info/set up of the schedule wouldn't =A0be a big problem. I=
n many applications, a smaller set of channels (< 16) will be enough for=
 building a reliable schedule.




6tus, as adaptation layer, may have a key role in the configuration of such=
 broadcast channels, but we will need to think =A0"how/when" it s=
hould take care of that.



For now, let's see what other 6tus members think about!



Maria Rita









-----Original Message-----

From: 6tsch-bounces@ietf.org =
[mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana

Sent: Tuesday, February 26, 2013 5:16 AM

To: 6tsch@ietf.org

Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH



Hi,



I have a question that i want to discuss, the question is whether we need a=
 broadcast channel in TSCH or not and what kind of support 6tus should prov=
ide. (the answer can be depends... but lets see some cases)



a) ADV need broadcast channels in case they are used to synchronize the net=
work. IEEE 802.15.4e provides the timekeeping flag to set that channels as =
used for synchronization and shared flag can make them broadcast.

b) Those networks that do not need ADV for synchronization then can use any=
 TX link for ADV, this means that if it is not shared only the node listeni=
ng on that link will get the ADV. However as this periodically occurs the A=
DV might eventually be listened in all channels.


c)Some DAOs and all DIOs require a broadcast channel. Should the schedule p=
rovide that? in case of a), can the same link be used? How this link should=
 be installed in the nodes?

d)Is the scheduler of the network who should setup a broadcast channel inde=
pendent of the broadcast channel set for ADV? can it be the same? Or in con=
trast, 6tus can configure the EB so it indicates a broadcast channel..


e)..



I would like to know what is your opinion on that.



cheers!

Xavi

_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





--047d7b2eda151bbde304d72802c9--

From pthubert@cisco.com  Tue Mar  5 00:21:23 2013
Return-Path: 
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 6427E21F8896 for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 00:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Level: 
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=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 1bhmr1btLY5N for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 00:21:22 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EB8F021F88EA for <6tsch@ietf.org>; Tue,  5 Mar 2013 00:21:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7857; q=dns/txt; s=iport; t=1362471682; x=1363681282; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lu17xOcSriV+kSZBLXoWlIbNYF/v1uqX9oVHdpMkid8=; b=aL1Ex8m1DfKLGDd8nvwFvopP5nptXTmClKzWDSdo6uoKr2gWuTPexHN4 zA45WARObXrTYx4NG9a9SqZAYWLuMqmZaEZxucWPl4ZjzbZ8TTjEjDwhx SZsUm5nZPqfrdsJHeMN63YQNSpUhAGzBkVsGBEf5Nw2jEGG6txL2gy2c3 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAGCqNVGtJXHA/2dsb2JhbABEDsJGgQQWc4IfAQEBBAEBAWsLDAQCAQgRBAEBCx0HJwsUCQgCBAENBQiICwyuOJAxBI5bJgsHBoJZYQOINopQlDKCST+CJw
X-IronPort-AV: E=Sophos;i="4.84,786,1355097600"; d="scan'208";a="183815973"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 05 Mar 2013 08:21:21 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r258LLUu023976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Mar 2013 08:21:21 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 02:21:21 -0600
From: "Pascal Thubert (pthubert)" 
To: Robert Assimiti , Maria Rita PALATTELLA , Xavier Vilajosana , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] DIOs/DAOs and broadcast channels on TSCH
Thread-Index: AQHOE9f8p0IEqvYGvEuLadPVJxUrA5iMGWoAgAA1bACAChp1gIAAYJQg
Date: Tue, 5 Mar 2013 08:21:21 +0000
Deferred-Delivery: Tue, 5 Mar 2013 08:21:00 +0000
Message-ID: 
References: <512C36F4.4000409@eecs.berkeley.edu>   <8CF9EAFF7636FC419FEE1042DC36C12FB67398@S04-MBX01-08.s04.local>
In-Reply-To: <8CF9EAFF7636FC419FEE1042DC36C12FB67398@S04-MBX01-08.s04.local>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.82.224]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Shitanshu Shah \(svshah\)" 
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2013 08:21:23 -0000

Hello Robert:

Yes, certainly.=20

The only priority we want to define is that of the flow we control, that is=
, RPL, and management (PCE commands), and that much will be easy since it i=
s network priority.

I have to learn more on the MAC to be helpful, but I can see that:
- we start up with enough QoS-ruled bundles to boot the network. In those b=
undles, QoS determines priority and network priority is the highest.
- we build hard reserved tracks for critical flows, and the mapping to bund=
les and then cells is plain.=20
- we also build lazy tracks where cells on the way may need to be allocated=
 to cope to extra traffic. In that case, packets may be degraded to QoS-rul=
ed bundles, or dropped.
- and then we have all the traffic of lesser criticality that plays with tr=
aditional QoS in QoS-ruled bundles.
=20
For all those, we'll need to define DSCPs and per hop behavior. Shitanshu (=
cc'ed) is helping us on that.

Cheers,

Pascal


-----Original Message-----
From: Robert Assimiti [mailto:robert.assimiti@nivis.com]=20
Sent: mardi 5 mars 2013 03:27
To: Pascal Thubert (pthubert); Maria Rita PALATTELLA; Xavier Vilajosana; 6t=
sch@ietf.org
Subject: RE: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Pascal,

I have a suggestion. Rather than defining the priorities and traffic flows =
associated with them, we should provide a framework and mechanism that supp=
ort various priorities.

In order to support prioritized traffic flows one would have to come up wit=
h a priority based media access scheme.

This could be accomplished by:

1. Using prioritized links=20
2. Using prioritized slotframes
3. ??? other schemes

All of these require 802.15.4e-TSCH enhancements/additions.=20

Robert Assimiti


-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of P=
ascal Thubert (pthubert)
Sent: Tuesday, February 26, 2013 6:07 AM
To: Maria Rita PALATTELLA; Xavier Vilajosana; 6tsch@ietf.org
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hi Xavi and Maria-Rita:

We may find a number of asynchronous types. I can see:

1) RPL signaling, highest priority
2) best effort traffic, lowest priority and with no reservation at all, for=
 lesser importance sensors like corrosion.
3) lazy reservation overflow, when a small jitter is acceptable. Virtual ba=
ndwidth was reserved but physical slots are only allocated upon observed us=
e.=20

For all 3, transmission is statistical, and all 3 will be governed by QoS a=
s opposed to reservation.

So basically we'll probably need some time slots with priority to accommoda=
te either parent to any child (shared reception slot though a given packet =
may be unicast) or any child to parent (shared emission with contention) tr=
affic.=20

Is that doable?

Pascal


-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of M=
aria Rita PALATTELLA
Sent: mardi 26 f=E9vrier 2013 08:55
To: Xavier Vilajosana; 6tsch@ietf.org
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hello Xavi,
from my point of view, having a TSCH broadcast channel could be useful in s=
everal situations:

>>>a) ADV need broadcast channels in case they are used to synchronize the =
network. IEEE 802.15.4e provides the timekeeping flag to set that channels =
as used for synchronization and shared flag can make them broadcast.
>>>b) Those networks that do not need ADV for synchronization then can use =
any TX link for ADV, this means that if it is not shared only the node list=
ening on that link will get the ADV. However as this periodically occurs th=
e ADV might eventually be listened  >>>in all channels.

1) synchronization (as you said in [a]): it will allow to have a faster set=
-up phase for synchronizing all the motes in the network. While, using  any=
 TX link ([b]), even though this will hop from one channel to another, it w=
ill imply a longer set-up phase, because each mote will be able to synchron=
ize at a different time (when it is in listen mode on the "right" channel).
=20
>>>c)Some DAOs and all DIOs require a broadcast channel. Should the schedul=
e provide that? in case of a), can the same link be used? How this link sho=
uld be installed in the nodes?

2) transmission of RPL messages (DAOs and DIOs). If we want TSCH works with=
 RPL, then we should reserve some slots of the schedule for exchanging info=
rmation between L3 and L2. I am not sure we should use the same link used f=
or synchronization, maybe it could be better to have 2 different ones, dedi=
cated to different purposes. Anyway, this is something to check.=20

>>>d)Is the scheduler of the network who should setup a broadcast channel i=
ndependent of the broadcast channel set for ADV? can it be the same? Or in =
contrast, 6tus can configure the EB so it indicates a broadcast channel..

3) transmission of signaling messages for setting up the schedule. Let's  a=
ssume there is a scheduler that builds the schedule for the network. In ord=
er to assign some links to each of them, it  will need to broadcast the inf=
ormation related to ( timeOffset, ChannelOffset). As for the synchronizatio=
n, having a broadcast channel dedicated to the signaling will allow to set =
up the schedule in shorter time.=20

Maybe, because there are 16 available channels in  IEEE802.15.4/15.4e PHY, =
using some of them as broadcast channels for synchronization/exchange of cr=
oss-layer info/set up of the schedule wouldn't  be a big problem. In many a=
pplications, a smaller set of channels (< 16) will be enough for building a=
 reliable schedule.=20

6tus, as adaptation layer, may have a key role in the configuration of such=
 broadcast channels, but we will need to think  "how/when" it should take c=
are of that.

For now, let's see what other 6tus members think about!

Maria Rita

=20


-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of X=
avier Vilajosana
Sent: Tuesday, February 26, 2013 5:16 AM
To: 6tsch@ietf.org
Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hi,

I have a question that i want to discuss, the question is whether we need a=
 broadcast channel in TSCH or not and what kind of support 6tus should prov=
ide. (the answer can be depends... but lets see some cases)

a) ADV need broadcast channels in case they are used to synchronize the net=
work. IEEE 802.15.4e provides the timekeeping flag to set that channels as =
used for synchronization and shared flag can make them broadcast.
b) Those networks that do not need ADV for synchronization then can use any=
 TX link for ADV, this means that if it is not shared only the node listeni=
ng on that link will get the ADV. However as this periodically occurs the A=
DV might eventually be listened in all channels.
c)Some DAOs and all DIOs require a broadcast channel. Should the schedule p=
rovide that? in case of a), can the same link be used? How this link should=
 be installed in the nodes?
d)Is the scheduler of the network who should setup a broadcast channel inde=
pendent of the broadcast channel set for ADV? can it be the same? Or in con=
trast, 6tus can configure the EB so it indicates a broadcast channel..
e)..

I would like to know what is your opinion on that.

cheers!
Xavi
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch

From alfredo.grieco@gmail.com  Tue Mar  5 01:47:16 2013
Return-Path: 
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 9B19E21F887F for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 01:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level: 
X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DYN_RDNS_SHORT_HELO_HTML=0.499, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877,  RDNS_DYNAMIC=0.1]
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 VJHkMzUanFAr for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 01:47:15 -0800 (PST)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E218B21F8873 for <6tsch@ietf.org>; Tue,  5 Mar 2013 01:47:13 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id d46so1523120wer.31 for <6tsch@ietf.org>; Tue, 05 Mar 2013 01:47:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=Zx6i05kpY+2LduDnSSOhIpgEceQZbdIG9YJJBsfY53A=; b=ouCkBGX9snUIDDWdgEBHeTFfFgCMPUP2ee4qzk/TvHPDYUkRZOfGm7Fzw2cT1l9GPP eiT6xPWGiifEQ/zpUGJB1AFYsIwFs4JR+euk2t2gpQIKCIBPPVmKlezxBl6UGGpqp500 hwAWjUyxJkZlvDXCTAT1xDiAoDVi9P3jyS/kFmmGhQ3BubipgspwjVn4cONqkkH3iSi8 F0kxls7RGnzieoK+8sUyA17q2aY6JJVty+fRvTXoJpve2An1Y0emQpzReU98RIEqfkXB /7dOOu8p8HhPCU1+GamsgrakBPHK5qrYC4ZHL4tYmOIwslr1HUGWmyVlZolEWAl84/xj OSRg==
X-Received: by 10.180.74.228 with SMTP id x4mr17428517wiv.0.1362476833115; Tue, 05 Mar 2013 01:47:13 -0800 (PST)
Received: from GriecoPC (AAubervilliers-652-1-232-141.w83-112.abo.wanadoo.fr. [83.112.239.141]) by mx.google.com with ESMTPS id eo1sm19188868wib.8.2013.03.05.01.47.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 05 Mar 2013 01:47:12 -0800 (PST)
From: "Alfredo Grieco" 
To: "'Thomas Watteyne'" , "'IETF 6TSCH'" <6tsch@ietf.org>
References: 	<3a15a455ce180f26c2ad2485410c7701.squirrel@calmail.berkeley.edu> 
In-Reply-To: 
Date: Tue, 5 Mar 2013 10:47:09 +0100
Message-ID: <5135bf20.4163b40a.17f4.6285@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0131_01CE198E.CA250FC0"
X-Mailer: Microsoft Office Outlook 12.0
thread-index: Ac4ZbFE27pY78cgFRh2EWAuLuafZAwAGfbMg
Content-Language: en-us
Subject: [6tsch] R:  6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2013 09:47:16 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0131_01CE198E.CA250FC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi All,
 
Why not speaking about Resource Block (as in cellular systems) to identify a
time slot-channel pair ?
 
Cheers
 
Alfredo
 
Da: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] Per conto di
Thomas Watteyne
Inviato: Tuesday, March 05, 2013 7:40 AM
A: IETF 6TSCH
Oggetto: Re: [6tsch] 6tsch definitions
 
Qin,
 
[Quick questions about definition: do you mean that you prefer the term link
over slot or cell? Are you not afraid that people will mistake a TSCH link
with, say a broadcast domain? I believe this is what started this thread. If
you do not agree, please speak up.]
 
In my mind, a bundle is a group of slots which are entirely equivalent. That
is, once a packet has made it into some queue, it can go out on any slot of
the bundle. That is, there can be multiple bundles from mote A to mote B.
Does this definition work for you? I can absolutely be convinced otherwise,
but, if possible, I'd like to keep the number of new definitions are
concepts to a minimum, so if possible keep a single term.
 
Thoughts?
 
Thomas
 
On Mon, Mar 4, 2013 at 3:52 PM, Qin Wang  wrote:
Thomas,

Before I can add some about mux, we need to discuss more about the
definition of "bundle". We have two different angle to use the word of
bundle now.

(1) One angle is to describe the communication resource of TSCH, i.e. like
your defined, bundle is a set of links (or slots, BTW, I prefer "Link"),
which have some common features, like same slotframe, same flag, same
neighbors.

(2) Another angle is to describe the incoming data flow in order to shape
data flow and meet QoS requirements, which is the meaning of bundle in
i-mux -mux.

The two kinds of bundle may be mapping to each other one by one, may be
not. IMHO, we need the two angles, because the first one is useful in
building and maintaining schedule; and the second one is useful in data
convey from upper layer to TSCH after the communication schedule has be
established.

So, maybe we need two terms for the two purpose, respectively? How do you
think?

Qin



> All,
>
> From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
> thread, it appears apparent that the IEEE802.15.4e standard uses terms
> which are confusing, especially when taken into a broader context.
>
> For example:
> - "link"
>    . in IEEE802.15.4e: "single slot scheduled from A to B"
>    . general definition: generic term for single-hop connection, often
> related to broadcast domain
> - "path"
>    . IEEE802.15.4e: "group of links between A and B"
>    . general definition: multi-hop route between source and destination.
>
> We are often confused ourselves at those "colliding" definitions, so I
> believe there is a need to provide some definitions. This can be done as
> part of a next revision of
> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or
> some other draft if considered appropriate by the group.
>
> What follows is a number of terms, and tentative definitions. Let's
> edit/circulate this e-mail for a couple of days, then decide what makes it
> into the official definitions list.
>
> - slot:
>    - A timeslot in the TSCH schedule. A slot can be scheduled or
> unscheduled. During an *unscheduled* slot, the node does not communicate.
> When a slot is *scheduled*, it is assigned a slotframe, it is assigned a
> neighbor address (which can be the broadcast address), and one of more of
> the following flags: TX, RX, shared, timeskeeping, hard. A *broadcast
> *slot
> is an alias for "a scheduled slot with neighbor address the broadcast
> address".
>    - note: this term would replace the term "link" in the IEEE802.15.4e
> standard.
> - bundle:
>    - A group of equivalent scheduled slots, i.e. slots which are
> scheduled,
> on the same slotframe, with the same neighbor and with the same flags. The
> *
> size* of the bundle refers to the number of slots it contains. Given the
> length of the slotframe, the size of the bundle translates directly into
> reserved bandwidth.
> - (inversed) mux:
>    - *Qin*, would you mind giving a tentative definition here?
>
> Thomas
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


 

------=_NextPart_000_0131_01CE198E.CA250FC0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi =
All,
 
Why not speaking about =
Resource Block (as in cellular systems) to identify a time slot-channel =
pair ?
 
Cheers
 
Alfredo
 
Da: 6tsch-bounces@ietf.org =
[mailto:6tsch-bounces@ietf.org] Per =
conto di Thomas Watteyne
Inviato: Tuesday, March 05, 2013 =
7:40 AM
A: IETF =
6TSCH
Oggetto: Re: =
[6tsch] 6tsch definitions
 
Qin,
 
=

[Quick questions about definition: do you =
mean that you prefer the term link over slot or cell? Are you not afraid =
that people will mistake a TSCH link with, say a broadcast domain? I =
believe this is what started this thread. If you do not agree, please =
speak up.]
 
=

In my mind, a bundle is a group of slots =
which are entirely equivalent. That is, once a packet has made it into =
some queue, it can go out on any slot of the bundle. That is, there can =
be multiple bundles from mote A to mote B. Does this definition work for =
you? I can absolutely be convinced otherwise, but, if =
possible, I'd like to keep the number of new definitions are concepts to =
a minimum, so if possible keep a single =
term.
 
=

Thoughts?
 
=

Thomas
=

 
On Mon, Mar 4, 2013 at 3:52 PM, Qin Wang =
<qinwang@berkeley.edu> =
wrote:
Thomas,

Before I can add some about =
mux, we need to discuss more about the
definition of =
"bundle". We have two different angle to use the word =
of
bundle now.

(1) One angle is to describe the communication =
resource of TSCH, i.e. like
your defined, bundle is a set of links =
(or slots, BTW, I prefer "Link"),
which have some common =
features, like same slotframe, same flag, same
neighbors.

(2) =
Another angle is to describe the incoming data flow in order to =
shape
data flow and meet QoS requirements, which is the meaning of =
bundle in
i-mux -mux.

The two kinds of bundle may be mapping =
to each other one by one, may be
not. IMHO, we need the two angles, =
because the first one is useful in
building and maintaining schedule; =
and the second one is useful in data
convey from upper layer to TSCH =
after the communication schedule has be
established.

So, maybe =
we need two terms for the two purpose, respectively? How do =
you
think?

Qin



> All,
>
> From =
the discussions in the "DIOs/DAOs and broadcast channels on =
TSCH"
> thread, it appears apparent that the IEEE802.15.4e =
standard uses terms
> which are confusing, especially when taken =
into a broader context.
>
> For example:
> - =
"link"
>    . in IEEE802.15.4e: "single =
slot scheduled from A to B"
>    . general =
definition: generic term for single-hop connection, often
> =
related to broadcast domain
> - "path"
>   =
 . IEEE802.15.4e: "group of links between A and =
B"
>    . general definition: multi-hop route =
between source and destination.
>
> We are often confused =
ourselves at those "colliding" definitions, so I
> =
believe there is a need to provide some definitions. This can be done =
as
> part of a next revision of
> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-ll=
n-context-01, or
> some other draft if considered appropriate =
by the group.
>
> What follows is a number of terms, and =
tentative definitions. Let's
> edit/circulate this e-mail for a =
couple of days, then decide what makes it
> into the official =
definitions list.
>
> - slot:
>    - A =
timeslot in the TSCH schedule. A slot can be scheduled =
or
> =
unscheduled. During an *unscheduled* slot, the node does not =
communicate.
> When a slot is *scheduled*, it is assigned a =
slotframe, it is assigned a
> neighbor address (which can be the =
broadcast address), and one of more =
of
> the =
following flags: TX, RX, shared, timeskeeping, hard. A =
*broadcast
> *slot
> is an alias for "a scheduled slot =
with neighbor address the broadcast
> address".
> =
   - note: this term would replace the term "link" =
in the IEEE802.15.4e
> standard.
> - bundle:
>   =
 - A group of equivalent scheduled slots, i.e. slots which =
are
> scheduled,
> on the same slotframe, with the same =
neighbor and with the same flags. =
The
> =
*
> size* of the bundle refers to the number of slots it contains. =
Given the
> =
length of the slotframe, the size of the bundle translates directly =
into
> reserved bandwidth.
> - (inversed) =
mux:
> =
   - *Qin*, would you mind giving a tentative definition =
here?
>
> Thomas
> =
_______________________________________________
> 6tsch mailing =
list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>=


 

------=_NextPart_000_0131_01CE198E.CA250FC0--


From qinwang@berkeley.edu  Tue Mar  5 08:32:43 2013
Return-Path: 
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 34AF711E80B8 for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 08:32:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level: 
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 9BrJlXXX2WDk for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 08:32:42 -0800 (PST)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6D921F89D8 for <6tsch@ietf.org>; Tue,  5 Mar 2013 08:32:42 -0800 (PST)
Received: from cm01ws.ist.berkeley.edu ([169.229.218.163] helo=calmail.berkeley.edu) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UCunB-0005Gd-3O; Tue, 05 Mar 2013 08:32:42 -0800
Received: from 76.88.33.145 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Tue, 5 Mar 2013 08:32:41 -0800
Message-ID: <3e6c9f9a2bebd5e68c7e947fb9332708.squirrel@calmail.berkeley.edu>
In-Reply-To: 
References:  <3a15a455ce180f26c2ad2485410c7701.squirrel@calmail.berkeley.edu> 
Date: Tue, 5 Mar 2013 08:32:41 -0800
From: "Qin Wang" 
To: "Thomas Watteyne" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] 6tsch definitions
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2013 16:32:43 -0000

Thomas,

I think, comparing with "slot", "link" carries more information like
channelOffset; comparing with "cell", "link" has more sense about
communication. But, indeed, "link" may cause some confuse. So, if everyone
prefers "slot" or "cell" or other term, I have no problem.

I agree with you that we should limit definition in minimum. With the
following definition of bundle, I just have one problem, i.e. whether the
priority is part of the bundle features or not? If yes, how to give a
bundle a priority and how to use the priority? If not, how to feed the
packets with different priorities in the queue to the bundle(s), FIFO, or
something else?

Thanks

Qin




> Qin,
>
> [Quick questions about definition: do you mean that you prefer the term
> link over slot or cell? Are you not afraid that people will mistake a TSCH
> link with, say a broadcast domain? I believe this is what started this
> thread. If you do not agree, please speak up.]
>
> In my mind, a bundle is a group of slots which are entirely equivalent.
> That is, once a packet has made it into some queue, it can go out on any
> slot of the bundle. That is, there can be multiple bundles from mote A to
> mote B. Does this definition work for you? I can absolutely be convinced
> otherwise, but, if possible, I'd like to keep the number of new
> definitions
> are concepts to a minimum, so if possible keep a single term.
>
> Thoughts?
>
> Thomas
>
> On Mon, Mar 4, 2013 at 3:52 PM, Qin Wang  wrote:
>
>> Thomas,
>>
>> Before I can add some about mux, we need to discuss more about the
>> definition of "bundle". We have two different angle to use the word of
>> bundle now.
>>
>> (1) One angle is to describe the communication resource of TSCH, i.e.
>> like
>> your defined, bundle is a set of links (or slots, BTW, I prefer "Link"),
>> which have some common features, like same slotframe, same flag, same
>> neighbors.
>>
>> (2) Another angle is to describe the incoming data flow in order to
>> shape
>> data flow and meet QoS requirements, which is the meaning of bundle in
>> i-mux -mux.
>>
>> The two kinds of bundle may be mapping to each other one by one, may be
>> not. IMHO, we need the two angles, because the first one is useful in
>> building and maintaining schedule; and the second one is useful in data
>> convey from upper layer to TSCH after the communication schedule has be
>> established.
>>
>> So, maybe we need two terms for the two purpose, respectively? How do
>> you
>> think?
>>
>> Qin
>>
>>
>>
>> > All,
>> >
>> > From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
>> > thread, it appears apparent that the IEEE802.15.4e standard uses terms
>> > which are confusing, especially when taken into a broader context.
>> >
>> > For example:
>> > - "link"
>> >    . in IEEE802.15.4e: "single slot scheduled from A to B"
>> >    . general definition: generic term for single-hop connection, often
>> > related to broadcast domain
>> > - "path"
>> >    . IEEE802.15.4e: "group of links between A and B"
>> >    . general definition: multi-hop route between source and
>> destination.
>> >
>> > We are often confused ourselves at those "colliding" definitions, so I
>> > believe there is a need to provide some definitions. This can be done
>> as
>> > part of a next revision of
>> > http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01,
>> or
>> > some other draft if considered appropriate by the group.
>> >
>> > What follows is a number of terms, and tentative definitions. Let's
>> > edit/circulate this e-mail for a couple of days, then decide what
>> makes
>> it
>> > into the official definitions list.
>> >
>> > - slot:
>> >    - A timeslot in the TSCH schedule. A slot can be scheduled or
>> > unscheduled. During an *unscheduled* slot, the node does not
>> communicate.
>> > When a slot is *scheduled*, it is assigned a slotframe, it is assigned
>> a
>> > neighbor address (which can be the broadcast address), and one of more
>> of
>> > the following flags: TX, RX, shared, timeskeeping, hard. A *broadcast
>> > *slot
>> > is an alias for "a scheduled slot with neighbor address the broadcast
>> > address".
>> >    - note: this term would replace the term "link" in the
>> IEEE802.15.4e
>> > standard.
>> > - bundle:
>> >    - A group of equivalent scheduled slots, i.e. slots which are
>> > scheduled,
>> > on the same slotframe, with the same neighbor and with the same flags.
>> The
>> > *
>> > size* of the bundle refers to the number of slots it contains. Given
>> the
>> > length of the slotframe, the size of the bundle translates directly
>> into
>> > reserved bandwidth.
>> > - (inversed) mux:
>> >    - *Qin*, would you mind giving a tentative definition here?
>> >
>> > Thomas
>> > _______________________________________________
>> > 6tsch mailing list
>> > 6tsch@ietf.org
>> > https://www.ietf.org/mailman/listinfo/6tsch
>> >
>>
>>
>>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From qinwang@berkeley.edu  Tue Mar  5 09:20:02 2013
Return-Path: 
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 9D10921F8833 for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 09:20:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.442
X-Spam-Level: 
X-Spam-Status: No, score=-5.442 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4]
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 N0m-XCDk+dJu for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 09:20:01 -0800 (PST)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7A92F21F87C3 for <6tsch@ietf.org>; Tue,  5 Mar 2013 09:20:01 -0800 (PST)
Received: from cm01ws.ist.berkeley.edu ([169.229.218.163] helo=calmail.berkeley.edu) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UCvWw-0000LU-Jc; Tue, 05 Mar 2013 09:20:00 -0800
Received: from 76.88.33.145 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Tue, 5 Mar 2013 09:19:58 -0800
Message-ID: 
In-Reply-To: 
References: <512C36F4.4000409@eecs.berkeley.edu>   <8CF9EAFF7636FC419FEE1042DC36C12FB67398@S04-MBX01-08.s04.local> 
Date: Tue, 5 Mar 2013 09:19:58 -0800
From: "Qin Wang" 
To: "Thomas Watteyne" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2013 17:20:03 -0000

Thomas,

Here is example to explain what my problem is.

Assume: there are two slotframes: slotframe-1, length=16; slotframe-2,
length=64. By the current definition of slotframe priority, slotframe-1
has higher priority. The two slotframes start from ASN=0.

Assume: for nodeA to nodeB, there are 1 Tx slot in slotframe-1, saying
slot 7; there are 2 Tx slots in slotframe-2, saying slot-16 and slot-48.

Assume: when ASN=47, there are two packets in the queue, with priority Low
and High, respectively.

Then, the question is: in slot-48, which packet will be transmitted? If
thinking packet priority should be associated with slotframe priority,
then, the packet with Low priority should be sent out. But, if thinking
the QoS of data flow, the packet with High priority should be sent out.

That is the problem in my mind. Do I miss something?

Qin


> +1
>
> What is your opinion on Qin's suggestion to have a priority translating
> into queues/bundles? (Qin, please correct me if I'm wrong).
>
> TSCH assigns a priority to slotframes, and leaves the rest for us to
> figure
> out. I have a hard time deciding whether our discussions suggest that:
> 1. slotframe priority is much too coarse and what we need is really
> bundle-based priorities, OR
> 2. what we are inventing for bundles can really be achieved by using
> good-old slotframes, and that all we are discussing (including queuing) is
> actually already present in TSCH. That is, we can apply everything we are
> discussing in the context of a bundle to a slotframe: we would end up
> having a slotframe per type of traffic, i.e. a final destination and a QoS
> level. Slotframes could also encompass label switching (i.e. packet I
> receive on RX links of slotframe 3 need to be sent on TX links of the same
> slotframe). The only thing missing is that you need to write the slotframe
> ID in the packet in case you have two TX cells in the same slot.
>
> Again, while this is a very open-ended question, it has a big impact of
> our
> next steps, and I'd like to get the list's opinion.
>
> I'd like to avoid as much as possible to reinvent concepts that are
> already
> present. Looking forward to being proven wrong.
>
> Thomas
>
> On Mon, Mar 4, 2013 at 6:27 PM, Robert Assimiti
> wrote:
>
>> Pascal,
>>
>> I have a suggestion. Rather than defining the priorities and traffic
>> flows
>> associated with them, we should provide a framework and mechanism that
>> support various priorities.
>>
>> In order to support prioritized traffic flows one would have to come up
>> with a priority based media access scheme.
>>
>> This could be accomplished by:
>>
>> 1. Using prioritized links
>> 2. Using prioritized slotframes
>> 3. ??? other schemes
>>
>> All of these require 802.15.4e-TSCH enhancements/additions.
>>
>> Robert Assimiti
>>
>>
>> -----Original Message-----
>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf
>> Of
>> Pascal Thubert (pthubert)
>> Sent: Tuesday, February 26, 2013 6:07 AM
>> To: Maria Rita PALATTELLA; Xavier Vilajosana; 6tsch@ietf.org
>> Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>>
>> Hi Xavi and Maria-Rita:
>>
>> We may find a number of asynchronous types. I can see:
>>
>> 1) RPL signaling, highest priority
>> 2) best effort traffic, lowest priority and with no reservation at all,
>> for lesser importance sensors like corrosion.
>> 3) lazy reservation overflow, when a small jitter is acceptable. Virtual
>> bandwidth was reserved but physical slots are only allocated upon
>> observed
>> use.
>>
>> For all 3, transmission is statistical, and all 3 will be governed by
>> QoS
>> as opposed to reservation.
>>
>> So basically we'll probably need some time slots with priority to
>> accommodate either parent to any child (shared reception slot though a
>> given packet may be unicast) or any child to parent (shared emission
>> with
>> contention) traffic.
>>
>> Is that doable?
>>
>> Pascal
>>
>>
>> -----Original Message-----
>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf
>> Of
>> Maria Rita PALATTELLA
>> Sent: mardi 26 février 2013 08:55
>> To: Xavier Vilajosana; 6tsch@ietf.org
>> Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>>
>> Hello Xavi,
>> from my point of view, having a TSCH broadcast channel could be useful
>> in
>> several situations:
>>
>> >>>a) ADV need broadcast channels in case they are used to synchronize
>> the
>> network. IEEE 802.15.4e provides the timekeeping flag to set that
>> channels
>> as used for synchronization and shared flag can make them broadcast.
>> >>>b) Those networks that do not need ADV for synchronization then can
>> use
>> any TX link for ADV, this means that if it is not shared only the node
>> listening on that link will get the ADV. However as this periodically
>> occurs the ADV might eventually be listened  >>>in all channels.
>>
>> 1) synchronization (as you said in [a]): it will allow to have a faster
>> set-up phase for synchronizing all the motes in the network. While,
>> using
>>  any TX link ([b]), even though this will hop from one channel to
>> another,
>> it will imply a longer set-up phase, because each mote will be able to
>> synchronize at a different time (when it is in listen mode on the
>> "right"
>> channel).
>>
>> >>>c)Some DAOs and all DIOs require a broadcast channel. Should the
>> schedule provide that? in case of a), can the same link be used? How
>> this
>> link should be installed in the nodes?
>>
>> 2) transmission of RPL messages (DAOs and DIOs). If we want TSCH works
>> with RPL, then we should reserve some slots of the schedule for
>> exchanging
>> information between L3 and L2. I am not sure we should use the same link
>> used for synchronization, maybe it could be better to have 2 different
>> ones, dedicated to different purposes. Anyway, this is something to
>> check.
>>
>> >>>d)Is the scheduler of the network who should setup a broadcast
>> channel
>> independent of the broadcast channel set for ADV? can it be the same? Or
>> in
>> contrast, 6tus can configure the EB so it indicates a broadcast
>> channel..
>>
>> 3) transmission of signaling messages for setting up the schedule. Let's
>>  assume there is a scheduler that builds the schedule for the network.
>> In
>> order to assign some links to each of them, it  will need to broadcast
>> the
>> information related to ( timeOffset, ChannelOffset). As for the
>> synchronization, having a broadcast channel dedicated to the signaling
>> will
>> allow to set up the schedule in shorter time.
>>
>> Maybe, because there are 16 available channels in  IEEE802.15.4/15.4e
>> PHY,
>> using some of them as broadcast channels for synchronization/exchange of
>> cross-layer info/set up of the schedule wouldn't  be a big problem. In
>> many
>> applications, a smaller set of channels (< 16) will be enough for
>> building
>> a reliable schedule.
>>
>> 6tus, as adaptation layer, may have a key role in the configuration of
>> such broadcast channels, but we will need to think  "how/when" it should
>> take care of that.
>>
>> For now, let's see what other 6tus members think about!
>>
>> Maria Rita
>>
>>
>>
>>
>> -----Original Message-----
>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf
>> Of
>> Xavier Vilajosana
>> Sent: Tuesday, February 26, 2013 5:16 AM
>> To: 6tsch@ietf.org
>> Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>>
>> Hi,
>>
>> I have a question that i want to discuss, the question is whether we
>> need
>> a broadcast channel in TSCH or not and what kind of support 6tus should
>> provide. (the answer can be depends... but lets see some cases)
>>
>> a) ADV need broadcast channels in case they are used to synchronize the
>> network. IEEE 802.15.4e provides the timekeeping flag to set that
>> channels
>> as used for synchronization and shared flag can make them broadcast.
>> b) Those networks that do not need ADV for synchronization then can use
>> any TX link for ADV, this means that if it is not shared only the node
>> listening on that link will get the ADV. However as this periodically
>> occurs the ADV might eventually be listened in all channels.
>> c)Some DAOs and all DIOs require a broadcast channel. Should the
>> schedule
>> provide that? in case of a), can the same link be used? How this link
>> should be installed in the nodes?
>> d)Is the scheduler of the network who should setup a broadcast channel
>> independent of the broadcast channel set for ADV? can it be the same? Or
>> in
>> contrast, 6tus can configure the EB so it indicates a broadcast
>> channel..
>> e)..
>>
>> I would like to know what is your opinion on that.
>>
>> cheers!
>> Xavi
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From pthubert@cisco.com  Tue Mar  5 10:02:53 2013
Return-Path: 
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 9742F11E80A4 for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 10:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 S-34gCsYW1TO for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 10:02:52 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BD99C21F8650 for <6tsch@ietf.org>; Tue,  5 Mar 2013 10:02:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3747; q=dns/txt; s=iport; t=1362506573; x=1363716173; h=from:to:subject:date:message-id:mime-version; bh=wZOMQ7/sddy3j3qC0BlTKFCyWU4fQ90NRFeiTrKQFps=; b=ZHbGccwimDwpOAyYHK9zBZ4Nwv/XwOz6UGJVKkiLRX3HMEEL/d2MIrLp QAazeKnQnreHhJvO6hO+SXsLPhlSGGuLj05mtT6kj83CO+5h4ANr1guMt fB+7z6fD2E6H+P3Z3jaWsjWFFCATvC+tL7CX0Gs6EWB+OeQL92Wkb924U Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAOIyNlGtJXG+/2dsb2JhbABFhGLAEIFsFnOCLQEELV4BDB5WJgEEG4gLmz6RFZAJjlyDF2EDpziDCIIn
X-IronPort-AV: E=Sophos;i="4.84,788,1355097600";  d="scan'208,217";a="184057805"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 05 Mar 2013 18:02:38 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r25I2cSu024571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Tue, 5 Mar 2013 18:02:38 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 12:02:38 -0600
From: "Pascal Thubert (pthubert)" 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: moving the 6TSCH call ahead by one hour
Thread-Index: Ac4Zy4R3Bew+oUX5S4uHn8lkgVqu+g==
Date: Tue, 5 Mar 2013 18:02:37 +0000
Deferred-Delivery: Tue, 5 Mar 2013 18:02:00 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.82.224]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835CD76F1xmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: [6tsch] moving the 6TSCH call ahead by one hour
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Mar 2013 18:02:53 -0000

--_000_E045AECD98228444A58C61C200AE1BD835CD76F1xmbrcdx01ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all;

I received repeated requests to move the call to Fridays 8AM PAC / 17:00 CE=
T. So I asked for a rough consensus on Friday and found no blocking situati=
on.
In case this is really an issue for you please let me know unicast. I'll co=
nfirm by Thursday whether or not the call is moved, and if so I will provid=
e the new Webex arrangements.
Also: please note that there will be no call during the week of the IETF.

Cheers;

Pascal


--_000_E045AECD98228444A58C61C200AE1BD835CD76F1xmbrcdx01ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear all;


 


I received repeated requests to move the call to Fri=
days 8AM PAC / 17:00 CET. So I asked for a rough consensus on Friday and fo=
und no blocking situation.


In case this is really an issue for you please let m=
e know unicast. I’ll confirm by Thursday whether or not the call is m=
oved, and if so I will provide the new Webex arrangements.



Also: please note that there will be no call during =
the week of the IETF.


 


Cheers;


 


Pascal


 






--_000_E045AECD98228444A58C61C200AE1BD835CD76F1xmbrcdx01ciscoc_--

From twatteyne@gmail.com  Tue Mar  5 19:58:46 2013
Return-Path: 
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 D18B111E80A5 for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 19:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1]
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 cUeCHDK9avX3 for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 19:58:45 -0800 (PST)
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE0511E80EA for <6tsch@ietf.org>; Tue,  5 Mar 2013 19:58:45 -0800 (PST)
Received: by mail-pb0-f45.google.com with SMTP id ro8so5418732pbb.4 for <6tsch@ietf.org>; Tue, 05 Mar 2013 19:58:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=C0gSRjJRVcBosgLc5+4durfGDJzGl+Ms19Ea3DUHGKo=; b=CxgvhamzPFpqcS2X4k1V33xVMtoLZDa4unuEV4g4JOwGQtu52yzvqI26UmcMqAB+BF ChyrEjuY0Cos0odOZHKUDzrmRXwMsOubtWk/i8cuxyNUcSwjSHDk1zviID5DWgWlHncp gMgPDxLhA/SLzxFpBMmpfKGKNzztXpzAlon2DUEDhfiFeBwVIsp1lhrQRn6j72tvht0n 8F+DItHWyxoaCgTJPFJlv7j1J2nRAM5p0/GSRohMKO3m/FeDbBwNKSUemXRh61ro0wpW mtwzXZf2Z/fej1HKSwyPXJg5hoY73Sa4QAHTm3fnUHaU4Yq7lNXCVo62JLEI62PrcnVO olsQ==
MIME-Version: 1.0
X-Received: by 10.68.248.74 with SMTP id yk10mr42322855pbc.38.1362542324558; Tue, 05 Mar 2013 19:58:44 -0800 (PST)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Tue, 5 Mar 2013 19:58:44 -0800 (PST)
In-Reply-To: 
References: <512C36F4.4000409@eecs.berkeley.edu>   <8CF9EAFF7636FC419FEE1042DC36C12FB67398@S04-MBX01-08.s04.local>  
Date: Tue, 5 Mar 2013 19:58:44 -0800
X-Google-Sender-Auth: mmniLoUXdLljgavfMZikC1JD3MU
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b2e0a173fe93104d7399b16
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Mar 2013 03:58:47 -0000

--047d7b2e0a173fe93104d7399b16
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Qin,

What I mean is that slotframe identifiers could be chosen according to the
priority of the data they carry. If you assign identifiers 1 and 2 to the
slotframes in your example, it's because you consider the traffic sent on
slotframe 1 to be more important that slotframe 2. When sending a packet, a
higher layer indicates the priority of the packet, here 1 or 2. That packet
will then be transmitted on the corresponding slotframe. Of course, if at a
particular slot two packets can be transmitted, the one with highest
priority wins.

What I'm trying to get at it that we don't have to consider that there is
one slotframe, in which slots are assigned one of n priorities, but rather
n slotframes, each of a given priority.

Thomas

On Tue, Mar 5, 2013 at 9:19 AM, Qin Wang  wrote:

> Thomas,
>
> Here is example to explain what my problem is.
>
>
>
> Assume: for nodeA to nodeB, there are 1 Tx slot in slotframe-1, saying
> slot 7; there are 2 Tx slots in slotframe-2, saying slot-16 and slot-48.
>
> Assume: when ASN=3D47, there are two packets in the queue, with priority =
Low
> and High, respectively.
>
> Then, the question is: in slot-48, which packet will be transmitted? If
> thinking packet priority should be associated with slotframe priority,
> then, the packet with Low priority should be sent out. But, if thinking
> the QoS of data flow, the packet with High priority should be sent out.
>
> That is the problem in my mind. Do I miss something?
>
> Qin
>
>
> > +1
> >
> > What is your opinion on Qin's suggestion to have a priority translating
> > into queues/bundles? (Qin, please correct me if I'm wrong).
> >
> > TSCH assigns a priority to slotframes, and leaves the rest for us to
> > figure
> > out. I have a hard time deciding whether our discussions suggest that:
> > 1. slotframe priority is much too coarse and what we need is really
> > bundle-based priorities, OR
> > 2. what we are inventing for bundles can really be achieved by using
> > good-old slotframes, and that all we are discussing (including queuing)
> is
> > actually already present in TSCH. That is, we can apply everything we a=
re
> > discussing in the context of a bundle to a slotframe: we would end up
> > having a slotframe per type of traffic, i.e. a final destination and a
> QoS
> > level. Slotframes could also encompass label switching (i.e. packet I
> > receive on RX links of slotframe 3 need to be sent on TX links of the
> same
> > slotframe). The only thing missing is that you need to write the
> slotframe
> > ID in the packet in case you have two TX cells in the same slot.
> >
> > Again, while this is a very open-ended question, it has a big impact of
> > our
> > next steps, and I'd like to get the list's opinion.
> >
> > I'd like to avoid as much as possible to reinvent concepts that are
> > already
> > present. Looking forward to being proven wrong.
> >
> > Thomas
> >
> > On Mon, Mar 4, 2013 at 6:27 PM, Robert Assimiti
> > wrote:
> >
> >> Pascal,
> >>
> >> I have a suggestion. Rather than defining the priorities and traffic
> >> flows
> >> associated with them, we should provide a framework and mechanism that
> >> support various priorities.
> >>
> >> In order to support prioritized traffic flows one would have to come u=
p
> >> with a priority based media access scheme.
> >>
> >> This could be accomplished by:
> >>
> >> 1. Using prioritized links
> >> 2. Using prioritized slotframes
> >> 3. ??? other schemes
> >>
> >> All of these require 802.15.4e-TSCH enhancements/additions.
> >>
> >> Robert Assimiti
> >>
> >>
> >> -----Original Message-----
> >> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf
> >> Of
> >> Pascal Thubert (pthubert)
> >> Sent: Tuesday, February 26, 2013 6:07 AM
> >> To: Maria Rita PALATTELLA; Xavier Vilajosana; 6tsch@ietf.org
> >> Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
> >>
> >> Hi Xavi and Maria-Rita:
> >>
> >> We may find a number of asynchronous types. I can see:
> >>
> >> 1) RPL signaling, highest priority
> >> 2) best effort traffic, lowest priority and with no reservation at all=
,
> >> for lesser importance sensors like corrosion.
> >> 3) lazy reservation overflow, when a small jitter is acceptable. Virtu=
al
> >> bandwidth was reserved but physical slots are only allocated upon
> >> observed
> >> use.
> >>
> >> For all 3, transmission is statistical, and all 3 will be governed by
> >> QoS
> >> as opposed to reservation.
> >>
> >> So basically we'll probably need some time slots with priority to
> >> accommodate either parent to any child (shared reception slot though a
> >> given packet may be unicast) or any child to parent (shared emission
> >> with
> >> contention) traffic.
> >>
> >> Is that doable?
> >>
> >> Pascal
> >>
> >>
> >> -----Original Message-----
> >> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf
> >> Of
> >> Maria Rita PALATTELLA
> >> Sent: mardi 26 f=E9vrier 2013 08:55
> >> To: Xavier Vilajosana; 6tsch@ietf.org
> >> Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
> >>
> >> Hello Xavi,
> >> from my point of view, having a TSCH broadcast channel could be useful
> >> in
> >> several situations:
> >>
> >> >>>a) ADV need broadcast channels in case they are used to synchronize
> >> the
> >> network. IEEE 802.15.4e provides the timekeeping flag to set that
> >> channels
> >> as used for synchronization and shared flag can make them broadcast.
> >> >>>b) Those networks that do not need ADV for synchronization then can
> >> use
> >> any TX link for ADV, this means that if it is not shared only the node
> >> listening on that link will get the ADV. However as this periodically
> >> occurs the ADV might eventually be listened  >>>in all channels.
> >>
> >> 1) synchronization (as you said in [a]): it will allow to have a faste=
r
> >> set-up phase for synchronizing all the motes in the network. While,
> >> using
> >>  any TX link ([b]), even though this will hop from one channel to
> >> another,
> >> it will imply a longer set-up phase, because each mote will be able to
> >> synchronize at a different time (when it is in listen mode on the
> >> "right"
> >> channel).
> >>
> >> >>>c)Some DAOs and all DIOs require a broadcast channel. Should the
> >> schedule provide that? in case of a), can the same link be used? How
> >> this
> >> link should be installed in the nodes?
> >>
> >> 2) transmission of RPL messages (DAOs and DIOs). If we want TSCH works
> >> with RPL, then we should reserve some slots of the schedule for
> >> exchanging
> >> information between L3 and L2. I am not sure we should use the same li=
nk
> >> used for synchronization, maybe it could be better to have 2 different
> >> ones, dedicated to different purposes. Anyway, this is something to
> >> check.
> >>
> >> >>>d)Is the scheduler of the network who should setup a broadcast
> >> channel
> >> independent of the broadcast channel set for ADV? can it be the same? =
Or
> >> in
> >> contrast, 6tus can configure the EB so it indicates a broadcast
> >> channel..
> >>
> >> 3) transmission of signaling messages for setting up the schedule. Let=
's
> >>  assume there is a scheduler that builds the schedule for the network.
> >> In
> >> order to assign some links to each of them, it  will need to broadcast
> >> the
> >> information related to ( timeOffset, ChannelOffset). As for the
> >> synchronization, having a broadcast channel dedicated to the signaling
> >> will
> >> allow to set up the schedule in shorter time.
> >>
> >> Maybe, because there are 16 available channels in  IEEE802.15.4/15.4e
> >> PHY,
> >> using some of them as broadcast channels for synchronization/exchange =
of
> >> cross-layer info/set up of the schedule wouldn't  be a big problem. In
> >> many
> >> applications, a smaller set of channels (< 16) will be enough for
> >> building
> >> a reliable schedule.
> >>
> >> 6tus, as adaptation layer, may have a key role in the configuration of
> >> such broadcast channels, but we will need to think  "how/when" it shou=
ld
> >> take care of that.
> >>
> >> For now, let's see what other 6tus members think about!
> >>
> >> Maria Rita
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf
> >> Of
> >> Xavier Vilajosana
> >> Sent: Tuesday, February 26, 2013 5:16 AM
> >> To: 6tsch@ietf.org
> >> Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH
> >>
> >> Hi,
> >>
> >> I have a question that i want to discuss, the question is whether we
> >> need
> >> a broadcast channel in TSCH or not and what kind of support 6tus shoul=
d
> >> provide. (the answer can be depends... but lets see some cases)
> >>
> >> a) ADV need broadcast channels in case they are used to synchronize th=
e
> >> network. IEEE 802.15.4e provides the timekeeping flag to set that
> >> channels
> >> as used for synchronization and shared flag can make them broadcast.
> >> b) Those networks that do not need ADV for synchronization then can us=
e
> >> any TX link for ADV, this means that if it is not shared only the node
> >> listening on that link will get the ADV. However as this periodically
> >> occurs the ADV might eventually be listened in all channels.
> >> c)Some DAOs and all DIOs require a broadcast channel. Should the
> >> schedule
> >> provide that? in case of a), can the same link be used? How this link
> >> should be installed in the nodes?
> >> d)Is the scheduler of the network who should setup a broadcast channel
> >> independent of the broadcast channel set for ADV? can it be the same? =
Or
> >> in
> >> contrast, 6tus can configure the EB so it indicates a broadcast
> >> channel..
> >> e)..
> >>
> >> I would like to know what is your opinion on that.
> >>
> >> cheers!
> >> Xavi
> >> _______________________________________________
> >> 6tsch mailing list
> >> 6tsch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/6tsch
> >> _______________________________________________
> >> 6tsch mailing list
> >> 6tsch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/6tsch
> >> _______________________________________________
> >> 6tsch mailing list
> >> 6tsch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/6tsch
> >> _______________________________________________
> >> 6tsch mailing list
> >> 6tsch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/6tsch
> >>
> > _______________________________________________
> > 6tsch mailing list
> > 6tsch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tsch
> >
>
>
>

--047d7b2e0a173fe93104d7399b16
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Qin,

What I mean is that slotframe identifiers could be =
chosen according to the priority of the data they carry. If you assign iden=
tifiers 1 and 2 to the slotframes in your example, it's because you con=
sider the traffic sent on slotframe 1 to be more important that slotframe 2=
. When sending a packet, a higher layer indicates the priority of the packe=
t, here 1 or 2. That packet will then be transmitted on the corresponding s=
lotframe. Of course, if at a particular slot two packets can be transmitted=
, the one with highest priority wins.



What I'm trying to get at it that we don't have=
 to consider that there is one slotframe, in which slots are assigned one o=
f n priorities, but rather n slotframes, each of a given priority.



Thomas

On T=
ue, Mar 5, 2013 at 9:19 AM, Qin Wang <qinwang@berkeley.edu> wrote:


Thomas,



Here is example to explain what my problem is.






Assume: for nodeA to nodeB, there are 1 Tx slot in slotframe-1, saying

slot 7; there are 2 Tx slots in slotframe-2, saying slot-16 and slot-48.


Assume: when ASN=3D47, there are two packets in the queue, with priority Lo=
w

and High, respectively.



Then, the question is: in slot-48, which packet will be transmitted? If

thinking packet priority should be associated with slotframe priority,

then, the packet with Low priority should be sent out. But, if thinking

the QoS of data flow, the packet with High priority should be sent out.



That is the problem in my mind. Do I miss something?



Qin






> +1

>

> What is your opinion on Qin's suggestion to have a priority transl=
ating

> into queues/bundles? (Qin, please correct me if I'm wrong).

>

> TSCH assigns a priority to slotframes, and leaves the rest for us to
> figure

> out. I have a hard time deciding whether our discussions suggest that:=


> 1. slotframe priority is much too coarse and what we need is really
> bundle-based priorities, OR

> 2. what we are inventing for bundles can really be achieved by using
> good-old slotframes, and that all we are discussing (including queuing=
) is

> actually already present in TSCH. That is, we can apply everything we =
are

> discussing in the context of a bundle to a slotframe: we would end up<=
br>
> having a slotframe per type of traffic, i.e. a final destination and a=
 QoS

> level. Slotframes could also encompass label switching (i.e. packet I<=
br>
> receive on RX links of slotframe 3 need to be sent on TX links of the =
same

> slotframe). The only thing missing is that you need to write the slotf=
rame

> ID in the packet in case you have two TX cells in the same slot.

>

> Again, while this is a very open-ended question, it has a big impact o=
f

> our

> next steps, and I'd like to get the list's opinion.

>

> I'd like to avoid as much as possible to reinvent concepts that ar=
e

> already

> present. Looking forward to being proven wrong.

>

> Thomas

>

> On Mon, Mar 4, 2013 at 6:27 PM, Robert Assimiti

> <robert.assimiti@nivis=
.com>wrote:

>

>> Pascal,

>>

>> I have a suggestion. Rather than defining the priorities and traff=
ic

>> flows

>> associated with them, we should provide a framework and mechanism =
that

>> support various priorities.

>>

>> In order to support prioritized traffic flows one would have to co=
me up

>> with a priority based media access scheme.

>>

>> This could be accomplished by:

>>

>> 1. Using prioritized links

>> 2. Using prioritized slotframes

>> 3. ??? other schemes

>>

>> All of these require 802.15.4e-TSCH enhancements/additions.

>>

>> Robert Assimiti

>>

>>

>> -----Original Message-----

>> From: 6tsch-bounces@ietf=
.org [mailto:6tsch-bounces@ie=
tf.org] On Behalf

>> Of

>> Pascal Thubert (pthubert)

>> Sent: Tuesday, February 26, 2013 6:07 AM

>> To: Maria Rita PALATTELLA; Xavier Vilajosana; 6tsch@ietf.org

>> Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

>>

>> Hi Xavi and Maria-Rita:

>>

>> We may find a number of asynchronous types. I can see:

>>

>> 1) RPL signaling, highest priority

>> 2) best effort traffic, lowest priority and with no reservation at=
 all,

>> for lesser importance sensors like corrosion.

>> 3) lazy reservation overflow, when a small jitter is acceptable. V=
irtual

>> bandwidth was reserved but physical slots are only allocated upon<=
br>
>> observed

>> use.

>>

>> For all 3, transmission is statistical, and all 3 will be governed=
 by

>> QoS

>> as opposed to reservation.

>>

>> So basically we'll probably need some time slots with priority=
 to

>> accommodate either parent to any child (shared reception slot thou=
gh a

>> given packet may be unicast) or any child to parent (shared emissi=
on

>> with

>> contention) traffic.

>>

>> Is that doable?

>>

>> Pascal

>>

>>

>> -----Original Message-----

>> From: 6tsch-bounces@ietf=
.org [mailto:6tsch-bounces@ie=
tf.org] On Behalf

>> Of

>> Maria Rita PALATTELLA

>> Sent: mardi 26 f=E9vrier 2013 08:55

>> To: Xavier Vilajosana; 6tsch@iet=
f.org

>> Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

>>

>> Hello Xavi,

>> from my point of view, having a TSCH broadcast channel could be us=
eful

>> in

>> several situations:

>>

>> >>>a) ADV need broadcast channels in case they are used t=
o synchronize

>> the

>> network. IEEE 802.15.4e provides the timekeeping flag to set that<=
br>
>> channels

>> as used for synchronization and shared flag can make them broadcas=
t.

>> >>>b) Those networks that do not need ADV for synchroniza=
tion then can

>> use

>> any TX link for ADV, this means that if it is not shared only the =
node

>> listening on that link will get the ADV. However as this periodica=
lly

>> occurs the ADV might eventually be listened =A0>>>in all =
channels.

>>

>> 1) synchronization (as you said in [a]): it will allow to have a f=
aster

>> set-up phase for synchronizing all the motes in the network. While=
,

>> using

>> =A0any TX link ([b]), even though this will hop from one channel t=
o

>> another,

>> it will imply a longer set-up phase, because each mote will be abl=
e to

>> synchronize at a different time (when it is in listen mode on the<=
br>
>> "right"

>> channel).

>>

>> >>>c)Some DAOs and all DIOs require a broadcast channel. =
Should the

>> schedule provide that? in case of a), can the same link be used? H=
ow

>> this

>> link should be installed in the nodes?

>>

>> 2) transmission of RPL messages (DAOs and DIOs). If we want TSCH w=
orks

>> with RPL, then we should reserve some slots of the schedule for
>> exchanging

>> information between L3 and L2. I am not sure we should use the sam=
e link

>> used for synchronization, maybe it could be better to have 2 diffe=
rent

>> ones, dedicated to different purposes. Anyway, this is something t=
o

>> check.

>>

>> >>>d)Is the scheduler of the network who should setup a b=
roadcast

>> channel

>> independent of the broadcast channel set for ADV? can it be the sa=
me? Or

>> in

>> contrast, 6tus can configure the EB so it indicates a broadcast
>> channel..

>>

>> 3) transmission of signaling messages for setting up the schedule.=
 Let's

>> =A0assume there is a scheduler that builds the schedule for the ne=
twork.

>> In

>> order to assign some links to each of them, it =A0will need to bro=
adcast

>> the

>> information related to ( timeOffset, ChannelOffset). As for the
>> synchronization, having a broadcast channel dedicated to the signa=
ling

>> will

>> allow to set up the schedule in shorter time.

>>

>> Maybe, because there are 16 available channels in =A0IEEE802.15.4/=
15.4e

>> PHY,

>> using some of them as broadcast channels for synchronization/excha=
nge of

>> cross-layer info/set up of the schedule wouldn't =A0be a big p=
roblem. In

>> many

>> applications, a smaller set of channels (< 16) will be enough f=
or

>> building

>> a reliable schedule.

>>

>> 6tus, as adaptation layer, may have a key role in the configuratio=
n of

>> such broadcast channels, but we will need to think =A0"how/wh=
en" it should

>> take care of that.

>>

>> For now, let's see what other 6tus members think about!

>>

>> Maria Rita

>>

>>

>>

>>

>> -----Original Message-----

>> From: 6tsch-bounces@ietf=
.org [mailto:6tsch-bounces@ie=
tf.org] On Behalf

>> Of

>> Xavier Vilajosana

>> Sent: Tuesday, February 26, 2013 5:16 AM

>> To: 6tsch@ietf.org

>> Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH

>>

>> Hi,

>>

>> I have a question that i want to discuss, the question is whether =
we

>> need

>> a broadcast channel in TSCH or not and what kind of support 6tus s=
hould

>> provide. (the answer can be depends... but lets see some cases)
>>

>> a) ADV need broadcast channels in case they are used to synchroniz=
e the

>> network. IEEE 802.15.4e provides the timekeeping flag to set that<=
br>
>> channels

>> as used for synchronization and shared flag can make them broadcas=
t.

>> b) Those networks that do not need ADV for synchronization then ca=
n use

>> any TX link for ADV, this means that if it is not shared only the =
node

>> listening on that link will get the ADV. However as this periodica=
lly

>> occurs the ADV might eventually be listened in all channels.

>> c)Some DAOs and all DIOs require a broadcast channel. Should the
>> schedule

>> provide that? in case of a), can the same link be used? How this l=
ink

>> should be installed in the nodes?

>> d)Is the scheduler of the network who should setup a broadcast cha=
nnel

>> independent of the broadcast channel set for ADV? can it be the sa=
me? Or

>> in

>> contrast, 6tus can configure the EB so it indicates a broadcast
>> channel..

>> e)..

>>

>> I would like to know what is your opinion on that.

>>

>> cheers!

>> Xavi

>> _______________________________________________

>> 6tsch mailing list

>> 6tsch@ietf.org

>> https://www.ietf.org/mailman/listinfo/6tsch

>> _______________________________________________

>> 6tsch mailing list

>> 6tsch@ietf.org

>> https://www.ietf.org/mailman/listinfo/6tsch

>> _______________________________________________

>> 6tsch mailing list

>> 6tsch@ietf.org

>> https://www.ietf.org/mailman/listinfo/6tsch

>> _______________________________________________

>> 6tsch mailing list

>> 6tsch@ietf.org

>> https://www.ietf.org/mailman/listinfo/6tsch

>>

> _______________________________________________

> 6tsch mailing list

> 6tsch@ietf.org

> https://www.ietf.org/mailman/listinfo/6tsch

>









--047d7b2e0a173fe93104d7399b16--

From pister@eecs.berkeley.edu  Tue Mar  5 20:37:54 2013
Return-Path: 
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 3AC3A11E80FF for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 20:37:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.398
X-Spam-Level: 
X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4]
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 4rre4z4jbGjy for <6tsch@ietfa.amsl.com>; Tue,  5 Mar 2013 20:37:52 -0800 (PST)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 63DFA11E80F3 for <6tsch@ietf.org>; Tue,  5 Mar 2013 20:37:52 -0800 (PST)
Received: from c-98-210-49-50.hsd1.ca.comcast.net ([98.210.49.50] helo=[192.168.1.100]) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1UD66w-0004y4-KG for 6tsch@ietf.org; Tue, 05 Mar 2013 20:37:52 -0800
Message-ID: <5136C7FD.9070108@eecs.berkeley.edu>
Date: Tue, 05 Mar 2013 20:37:17 -0800
From: Kris Pister 
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: IETF 6TSCH <6tsch@ietf.org>
References: <512C36F4.4000409@eecs.berkeley.edu>   <8CF9EAFF7636FC419FEE1042DC36C12FB67398@S04-MBX01-08.s04.local>   
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000100030804000007020507"
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Mar 2013 04:37:54 -0000

This is a multi-part message in MIME format.
--------------000100030804000007020507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

+1

On 3/5/2013 7:58 PM, Thomas Watteyne wrote:
> Qin,
>
> What I mean is that slotframe identifiers could be chosen according to 
> the priority of the data they carry. If you assign identifiers 1 and 2 
> to the slotframes in your example, it's because you consider the 
> traffic sent on slotframe 1 to be more important that slotframe 2. 
> When sending a packet, a higher layer indicates the priority of the 
> packet, here 1 or 2. That packet will then be transmitted on the 
> corresponding slotframe. Of course, if at a particular slot two 
> packets can be transmitted, the one with highest priority wins.
>
> What I'm trying to get at it that we don't have to consider that there 
> is one slotframe, in which slots are assigned one of n priorities, but 
> rather n slotframes, each of a given priority.
>
> Thomas
>
> On Tue, Mar 5, 2013 at 9:19 AM, Qin Wang  > wrote:
>
>     Thomas,
>
>     Here is example to explain what my problem is.
>
>
>
>     Assume: for nodeA to nodeB, there are 1 Tx slot in slotframe-1, saying
>     slot 7; there are 2 Tx slots in slotframe-2, saying slot-16 and
>     slot-48.
>
>     Assume: when ASN=47, there are two packets in the queue, with
>     priority Low
>     and High, respectively.
>
>     Then, the question is: in slot-48, which packet will be
>     transmitted? If
>     thinking packet priority should be associated with slotframe priority,
>     then, the packet with Low priority should be sent out. But, if
>     thinking
>     the QoS of data flow, the packet with High priority should be sent
>     out.
>
>     That is the problem in my mind. Do I miss something?
>
>     Qin
>
>
>     > +1
>     >
>     > What is your opinion on Qin's suggestion to have a priority
>     translating
>     > into queues/bundles? (Qin, please correct me if I'm wrong).
>     >
>     > TSCH assigns a priority to slotframes, and leaves the rest for us to
>     > figure
>     > out. I have a hard time deciding whether our discussions suggest
>     that:
>     > 1. slotframe priority is much too coarse and what we need is really
>     > bundle-based priorities, OR
>     > 2. what we are inventing for bundles can really be achieved by using
>     > good-old slotframes, and that all we are discussing (including
>     queuing) is
>     > actually already present in TSCH. That is, we can apply
>     everything we are
>     > discussing in the context of a bundle to a slotframe: we would
>     end up
>     > having a slotframe per type of traffic, i.e. a final destination
>     and a QoS
>     > level. Slotframes could also encompass label switching (i.e.
>     packet I
>     > receive on RX links of slotframe 3 need to be sent on TX links
>     of the same
>     > slotframe). The only thing missing is that you need to write the
>     slotframe
>     > ID in the packet in case you have two TX cells in the same slot.
>     >
>     > Again, while this is a very open-ended question, it has a big
>     impact of
>     > our
>     > next steps, and I'd like to get the list's opinion.
>     >
>     > I'd like to avoid as much as possible to reinvent concepts that are
>     > already
>     > present. Looking forward to being proven wrong.
>     >
>     > Thomas
>     >
>     > On Mon, Mar 4, 2013 at 6:27 PM, Robert Assimiti
>     > >wrote:
>     >
>     >> Pascal,
>     >>
>     >> I have a suggestion. Rather than defining the priorities and
>     traffic
>     >> flows
>     >> associated with them, we should provide a framework and
>     mechanism that
>     >> support various priorities.
>     >>
>     >> In order to support prioritized traffic flows one would have to
>     come up
>     >> with a priority based media access scheme.
>     >>
>     >> This could be accomplished by:
>     >>
>     >> 1. Using prioritized links
>     >> 2. Using prioritized slotframes
>     >> 3. ??? other schemes
>     >>
>     >> All of these require 802.15.4e-TSCH enhancements/additions.
>     >>
>     >> Robert Assimiti
>     >>
>     >>
>     >> -----Original Message-----
>     >> From: 6tsch-bounces@ietf.org 
>     [mailto:6tsch-bounces@ietf.org ] On
>     Behalf
>     >> Of
>     >> Pascal Thubert (pthubert)
>     >> Sent: Tuesday, February 26, 2013 6:07 AM
>     >> To: Maria Rita PALATTELLA; Xavier Vilajosana; 6tsch@ietf.org
>     
>     >> Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>     >>
>     >> Hi Xavi and Maria-Rita:
>     >>
>     >> We may find a number of asynchronous types. I can see:
>     >>
>     >> 1) RPL signaling, highest priority
>     >> 2) best effort traffic, lowest priority and with no reservation
>     at all,
>     >> for lesser importance sensors like corrosion.
>     >> 3) lazy reservation overflow, when a small jitter is
>     acceptable. Virtual
>     >> bandwidth was reserved but physical slots are only allocated upon
>     >> observed
>     >> use.
>     >>
>     >> For all 3, transmission is statistical, and all 3 will be
>     governed by
>     >> QoS
>     >> as opposed to reservation.
>     >>
>     >> So basically we'll probably need some time slots with priority to
>     >> accommodate either parent to any child (shared reception slot
>     though a
>     >> given packet may be unicast) or any child to parent (shared
>     emission
>     >> with
>     >> contention) traffic.
>     >>
>     >> Is that doable?
>     >>
>     >> Pascal
>     >>
>     >>
>     >> -----Original Message-----
>     >> From: 6tsch-bounces@ietf.org 
>     [mailto:6tsch-bounces@ietf.org ] On
>     Behalf
>     >> Of
>     >> Maria Rita PALATTELLA
>     >> Sent: mardi 26 février 2013 08:55
>     >> To: Xavier Vilajosana; 6tsch@ietf.org 
>     >> Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>     >>
>     >> Hello Xavi,
>     >> from my point of view, having a TSCH broadcast channel could be
>     useful
>     >> in
>     >> several situations:
>     >>
>     >> >>>a) ADV need broadcast channels in case they are used to
>     synchronize
>     >> the
>     >> network. IEEE 802.15.4e provides the timekeeping flag to set that
>     >> channels
>     >> as used for synchronization and shared flag can make them
>     broadcast.
>     >> >>>b) Those networks that do not need ADV for synchronization
>     then can
>     >> use
>     >> any TX link for ADV, this means that if it is not shared only
>     the node
>     >> listening on that link will get the ADV. However as this
>     periodically
>     >> occurs the ADV might eventually be listened  >>>in all channels.
>     >>
>     >> 1) synchronization (as you said in [a]): it will allow to have
>     a faster
>     >> set-up phase for synchronizing all the motes in the network. While,
>     >> using
>     >>  any TX link ([b]), even though this will hop from one channel to
>     >> another,
>     >> it will imply a longer set-up phase, because each mote will be
>     able to
>     >> synchronize at a different time (when it is in listen mode on the
>     >> "right"
>     >> channel).
>     >>
>     >> >>>c)Some DAOs and all DIOs require a broadcast channel. Should the
>     >> schedule provide that? in case of a), can the same link be
>     used? How
>     >> this
>     >> link should be installed in the nodes?
>     >>
>     >> 2) transmission of RPL messages (DAOs and DIOs). If we want
>     TSCH works
>     >> with RPL, then we should reserve some slots of the schedule for
>     >> exchanging
>     >> information between L3 and L2. I am not sure we should use the
>     same link
>     >> used for synchronization, maybe it could be better to have 2
>     different
>     >> ones, dedicated to different purposes. Anyway, this is something to
>     >> check.
>     >>
>     >> >>>d)Is the scheduler of the network who should setup a broadcast
>     >> channel
>     >> independent of the broadcast channel set for ADV? can it be the
>     same? Or
>     >> in
>     >> contrast, 6tus can configure the EB so it indicates a broadcast
>     >> channel..
>     >>
>     >> 3) transmission of signaling messages for setting up the
>     schedule. Let's
>     >>  assume there is a scheduler that builds the schedule for the
>     network.
>     >> In
>     >> order to assign some links to each of them, it  will need to
>     broadcast
>     >> the
>     >> information related to ( timeOffset, ChannelOffset). As for the
>     >> synchronization, having a broadcast channel dedicated to the
>     signaling
>     >> will
>     >> allow to set up the schedule in shorter time.
>     >>
>     >> Maybe, because there are 16 available channels in
>      IEEE802.15.4/15.4e
>     >> PHY,
>     >> using some of them as broadcast channels for
>     synchronization/exchange of
>     >> cross-layer info/set up of the schedule wouldn't  be a big
>     problem. In
>     >> many
>     >> applications, a smaller set of channels (< 16) will be enough for
>     >> building
>     >> a reliable schedule.
>     >>
>     >> 6tus, as adaptation layer, may have a key role in the
>     configuration of
>     >> such broadcast channels, but we will need to think  "how/when"
>     it should
>     >> take care of that.
>     >>
>     >> For now, let's see what other 6tus members think about!
>     >>
>     >> Maria Rita
>     >>
>     >>
>     >>
>     >>
>     >> -----Original Message-----
>     >> From: 6tsch-bounces@ietf.org 
>     [mailto:6tsch-bounces@ietf.org ] On
>     Behalf
>     >> Of
>     >> Xavier Vilajosana
>     >> Sent: Tuesday, February 26, 2013 5:16 AM
>     >> To: 6tsch@ietf.org 
>     >> Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>     >>
>     >> Hi,
>     >>
>     >> I have a question that i want to discuss, the question is
>     whether we
>     >> need
>     >> a broadcast channel in TSCH or not and what kind of support
>     6tus should
>     >> provide. (the answer can be depends... but lets see some cases)
>     >>
>     >> a) ADV need broadcast channels in case they are used to
>     synchronize the
>     >> network. IEEE 802.15.4e provides the timekeeping flag to set that
>     >> channels
>     >> as used for synchronization and shared flag can make them
>     broadcast.
>     >> b) Those networks that do not need ADV for synchronization then
>     can use
>     >> any TX link for ADV, this means that if it is not shared only
>     the node
>     >> listening on that link will get the ADV. However as this
>     periodically
>     >> occurs the ADV might eventually be listened in all channels.
>     >> c)Some DAOs and all DIOs require a broadcast channel. Should the
>     >> schedule
>     >> provide that? in case of a), can the same link be used? How
>     this link
>     >> should be installed in the nodes?
>     >> d)Is the scheduler of the network who should setup a broadcast
>     channel
>     >> independent of the broadcast channel set for ADV? can it be the
>     same? Or
>     >> in
>     >> contrast, 6tus can configure the EB so it indicates a broadcast
>     >> channel..
>     >> e)..
>     >>
>     >> I would like to know what is your opinion on that.
>     >>
>     >> cheers!
>     >> Xavi
>     >> _______________________________________________
>     >> 6tsch mailing list
>     >> 6tsch@ietf.org 
>     >> https://www.ietf.org/mailman/listinfo/6tsch
>     >> _______________________________________________
>     >> 6tsch mailing list
>     >> 6tsch@ietf.org 
>     >> https://www.ietf.org/mailman/listinfo/6tsch
>     >> _______________________________________________
>     >> 6tsch mailing list
>     >> 6tsch@ietf.org 
>     >> https://www.ietf.org/mailman/listinfo/6tsch
>     >> _______________________________________________
>     >> 6tsch mailing list
>     >> 6tsch@ietf.org 
>     >> https://www.ietf.org/mailman/listinfo/6tsch
>     >>
>     > _______________________________________________
>     > 6tsch mailing list
>     > 6tsch@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/6tsch
>     >
>
>
>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


--------------000100030804000007020507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1

    

    
On 3/5/2013 7:58 PM, Thomas Watteyne
      wrote:

    

    
Qin,
      


      

      
What I mean is that slotframe identifiers could be chosen
        according to the priority of the data they carry. If you assign
        identifiers 1 and 2 to the slotframes in your example, it's
        because you consider the traffic sent on slotframe 1 to be more
        important that slotframe 2. When sending a packet, a higher
        layer indicates the priority of the packet, here 1 or 2. That
        packet will then be transmitted on the corresponding slotframe.
        Of course, if at a particular slot two packets can be
        transmitted, the one with highest priority wins.

      


      

      
What I'm trying to get at it that we don't have to consider
        that there is one slotframe, in which slots are assigned one of
        n priorities, but rather n slotframes, each of a given priority.

      


      

      
Thomas

        

          


            
On Tue, Mar 5, 2013 at 9:19 AM, Qin
              Wang <qinwang@berkeley.edu>
              wrote:

              
Thomas,

                

                Here is example to explain what my problem is.

                

                

                

                Assume: for nodeA to nodeB, there are 1 Tx slot in
                slotframe-1, saying

                slot 7; there are 2 Tx slots in slotframe-2, saying
                slot-16 and slot-48.

                

                Assume: when ASN=47, there are two packets in the queue,
                with priority Low

                and High, respectively.

                

                Then, the question is: in slot-48, which packet will be
                transmitted? If

                thinking packet priority should be associated with
                slotframe priority,

                then, the packet with Low priority should be sent out.
                But, if thinking

                the QoS of data flow, the packet with High priority
                should be sent out.

                

                That is the problem in my mind. Do I miss something?

                

                    Qin

                  
                

                  


                    

                    > +1

                    >

                    > What is your opinion on Qin's suggestion to
                    have a priority translating

                    > into queues/bundles? (Qin, please correct me if
                    I'm wrong).

                    >

                    > TSCH assigns a priority to slotframes, and
                    leaves the rest for us to

                    > figure

                    > out. I have a hard time deciding whether our
                    discussions suggest that:

                    > 1. slotframe priority is much too coarse and
                    what we need is really

                    > bundle-based priorities, OR

                    > 2. what we are inventing for bundles can really
                    be achieved by using

                    > good-old slotframes, and that all we are
                    discussing (including queuing) is

                    > actually already present in TSCH. That is, we
                    can apply everything we are

                    > discussing in the context of a bundle to a
                    slotframe: we would end up

                    > having a slotframe per type of traffic, i.e. a
                    final destination and a QoS

                    > level. Slotframes could also encompass label
                    switching (i.e. packet I

                    > receive on RX links of slotframe 3 need to be
                    sent on TX links of the same

                    > slotframe). The only thing missing is that you
                    need to write the slotframe

                    > ID in the packet in case you have two TX cells
                    in the same slot.

                    >

                    > Again, while this is a very open-ended
                    question, it has a big impact of

                    > our

                    > next steps, and I'd like to get the list's
                    opinion.

                    >

                    > I'd like to avoid as much as possible to
                    reinvent concepts that are

                    > already

                    > present. Looking forward to being proven wrong.

                    >

                    > Thomas

                    >

                    > On Mon, Mar 4, 2013 at 6:27 PM, Robert Assimiti

                    > <robert.assimiti@nivis.com>wrote:

                    >

                    >> Pascal,

                    >>

                    >> I have a suggestion. Rather than defining
                    the priorities and traffic

                    >> flows

                    >> associated with them, we should provide a
                    framework and mechanism that

                    >> support various priorities.

                    >>

                    >> In order to support prioritized traffic
                    flows one would have to come up

                    >> with a priority based media access scheme.

                    >>

                    >> This could be accomplished by:

                    >>

                    >> 1. Using prioritized links

                    >> 2. Using prioritized slotframes

                    >> 3. ??? other schemes

                    >>

                    >> All of these require 802.15.4e-TSCH
                    enhancements/additions.

                    >>

                    >> Robert Assimiti

                    >>

                    >>

                    >> -----Original Message-----

                    >> From: 6tsch-bounces@ietf.org
                    [mailto:6tsch-bounces@ietf.org]
                    On Behalf

                    >> Of

                    >> Pascal Thubert (pthubert)

                    >> Sent: Tuesday, February 26, 2013 6:07 AM

                    >> To: Maria Rita PALATTELLA; Xavier
                    Vilajosana; 6tsch@ietf.org

                    >> Subject: Re: [6tsch] DIOs/DAOs and
                    broadcast channels on TSCH

                    >>

                    >> Hi Xavi and Maria-Rita:

                    >>

                    >> We may find a number of asynchronous types.
                    I can see:

                    >>

                    >> 1) RPL signaling, highest priority

                    >> 2) best effort traffic, lowest priority and
                    with no reservation at all,

                    >> for lesser importance sensors like
                    corrosion.

                    >> 3) lazy reservation overflow, when a small
                    jitter is acceptable. Virtual

                    >> bandwidth was reserved but physical slots
                    are only allocated upon

                    >> observed

                    >> use.

                    >>

                    >> For all 3, transmission is statistical, and
                    all 3 will be governed by

                    >> QoS

                    >> as opposed to reservation.

                    >>

                    >> So basically we'll probably need some time
                    slots with priority to

                    >> accommodate either parent to any child
                    (shared reception slot though a

                    >> given packet may be unicast) or any child
                    to parent (shared emission

                    >> with

                    >> contention) traffic.

                    >>

                    >> Is that doable?

                    >>

                    >> Pascal

                    >>

                    >>

                    >> -----Original Message-----

                    >> From: 6tsch-bounces@ietf.org
                    [mailto:6tsch-bounces@ietf.org]
                    On Behalf

                    >> Of

                    >> Maria Rita PALATTELLA

                    >> Sent: mardi 26 février 2013 08:55

                    >> To: Xavier Vilajosana; 6tsch@ietf.org

                    >> Subject: Re: [6tsch] DIOs/DAOs and
                    broadcast channels on TSCH

                    >>

                    >> Hello Xavi,

                    >> from my point of view, having a TSCH
                    broadcast channel could be useful

                    >> in

                    >> several situations:

                    >>

                    >> >>>a) ADV need broadcast channels
                    in case they are used to synchronize

                    >> the

                    >> network. IEEE 802.15.4e provides the
                    timekeeping flag to set that

                    >> channels

                    >> as used for synchronization and shared flag
                    can make them broadcast.

                    >> >>>b) Those networks that do not
                    need ADV for synchronization then can

                    >> use

                    >> any TX link for ADV, this means that if it
                    is not shared only the node

                    >> listening on that link will get the ADV.
                    However as this periodically

                    >> occurs the ADV might eventually be listened
                     >>>in all channels.

                    >>

                    >> 1) synchronization (as you said in [a]): it
                    will allow to have a faster

                    >> set-up phase for synchronizing all the
                    motes in the network. While,

                    >> using

                    >>  any TX link ([b]), even though this will
                    hop from one channel to

                    >> another,

                    >> it will imply a longer set-up phase,
                    because each mote will be able to

                    >> synchronize at a different time (when it is
                    in listen mode on the

                    >> "right"

                    >> channel).

                    >>

                    >> >>>c)Some DAOs and all DIOs
                    require a broadcast channel. Should the

                    >> schedule provide that? in case of a), can
                    the same link be used? How

                    >> this

                    >> link should be installed in the nodes?

                    >>

                    >> 2) transmission of RPL messages (DAOs and
                    DIOs). If we want TSCH works

                    >> with RPL, then we should reserve some slots
                    of the schedule for

                    >> exchanging

                    >> information between L3 and L2. I am not
                    sure we should use the same link

                    >> used for synchronization, maybe it could be
                    better to have 2 different

                    >> ones, dedicated to different purposes.
                    Anyway, this is something to

                    >> check.

                    >>

                    >> >>>d)Is the scheduler of the
                    network who should setup a broadcast

                    >> channel

                    >> independent of the broadcast channel set
                    for ADV? can it be the same? Or

                    >> in

                    >> contrast, 6tus can configure the EB so it
                    indicates a broadcast

                    >> channel..

                    >>

                    >> 3) transmission of signaling messages for
                    setting up the schedule. Let's

                    >>  assume there is a scheduler that builds
                    the schedule for the network.

                    >> In

                    >> order to assign some links to each of them,
                    it  will need to broadcast

                    >> the

                    >> information related to ( timeOffset,
                    ChannelOffset). As for the

                    >> synchronization, having a broadcast channel
                    dedicated to the signaling

                    >> will

                    >> allow to set up the schedule in shorter
                    time.

                    >>

                    >> Maybe, because there are 16 available
                    channels in  IEEE802.15.4/15.4e

                    >> PHY,

                    >> using some of them as broadcast channels
                    for synchronization/exchange of

                    >> cross-layer info/set up of the schedule
                    wouldn't  be a big problem. In

                    >> many

                    >> applications, a smaller set of channels
                    (< 16) will be enough for

                    >> building

                    >> a reliable schedule.

                    >>

                    >> 6tus, as adaptation layer, may have a key
                    role in the configuration of

                    >> such broadcast channels, but we will need
                    to think  "how/when" it should

                    >> take care of that.

                    >>

                    >> For now, let's see what other 6tus members
                    think about!

                    >>

                    >> Maria Rita

                    >>

                    >>

                    >>

                    >>

                    >> -----Original Message-----

                    >> From: 6tsch-bounces@ietf.org
                    [mailto:6tsch-bounces@ietf.org]
                    On Behalf

                    >> Of

                    >> Xavier Vilajosana

                    >> Sent: Tuesday, February 26, 2013 5:16 AM

                    >> To: 6tsch@ietf.org

                    >> Subject: [6tsch] DIOs/DAOs and broadcast
                    channels on TSCH

                    >>

                    >> Hi,

                    >>

                    >> I have a question that i want to discuss,
                    the question is whether we

                    >> need

                    >> a broadcast channel in TSCH or not and what
                    kind of support 6tus should

                    >> provide. (the answer can be depends... but
                    lets see some cases)

                    >>

                    >> a) ADV need broadcast channels in case they
                    are used to synchronize the

                    >> network. IEEE 802.15.4e provides the
                    timekeeping flag to set that

                    >> channels

                    >> as used for synchronization and shared flag
                    can make them broadcast.

                    >> b) Those networks that do not need ADV for
                    synchronization then can use

                    >> any TX link for ADV, this means that if it
                    is not shared only the node

                    >> listening on that link will get the ADV.
                    However as this periodically

                    >> occurs the ADV might eventually be listened
                    in all channels.

                    >> c)Some DAOs and all DIOs require a
                    broadcast channel. Should the

                    >> schedule

                    >> provide that? in case of a), can the same
                    link be used? How this link

                    >> should be installed in the nodes?

                    >> d)Is the scheduler of the network who
                    should setup a broadcast channel

                    >> independent of the broadcast channel set
                    for ADV? can it be the same? Or

                    >> in

                    >> contrast, 6tus can configure the EB so it
                    indicates a broadcast

                    >> channel..

                    >> e)..

                    >>

                    >> I would like to know what is your opinion
                    on that.

                    >>

                    >> cheers!

                    >> Xavi

                    >>
                    _______________________________________________

                    >> 6tsch mailing list

                    >> 6tsch@ietf.org

                    >> https://www.ietf.org/mailman/listinfo/6tsch

                    >>
                    _______________________________________________

                    >> 6tsch mailing list

                    >> 6tsch@ietf.org

                    >> https://www.ietf.org/mailman/listinfo/6tsch

                    >>
                    _______________________________________________

                    >> 6tsch mailing list

                    >> 6tsch@ietf.org

                    >> https://www.ietf.org/mailman/listinfo/6tsch

                    >>
                    _______________________________________________

                    >> 6tsch mailing list

                    >> 6tsch@ietf.org

                    >> https://www.ietf.org/mailman/listinfo/6tsch

                    >>

                    > _______________________________________________

                    > 6tsch mailing list

                    > 6tsch@ietf.org

                    > https://www.ietf.org/mailman/listinfo/6tsch

                    >

                    

                    

                  

                

              

            

            

          

        

      

      

      

      

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


    

    

  


--------------000100030804000007020507--

From pthubert@cisco.com  Thu Mar  7 01:20:10 2013
Return-Path: 
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 9104B21F8B08 for <6tsch@ietfa.amsl.com>; Thu,  7 Mar 2013 01:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.598
X-Spam-Level: 
X-Spam-Status: No, score=-11.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 ljKs-UhPf95N for <6tsch@ietfa.amsl.com>; Thu,  7 Mar 2013 01:20:07 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 31F1921F8995 for <6tsch@ietf.org>; Thu,  7 Mar 2013 01:20:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15022; q=dns/txt; s=iport; t=1362648006; x=1363857606; h=from:to:subject:date:message-id:mime-version; bh=auVXKEGGvwTRkgYcbuN+FgIEOlU96YkbUvWdZJtDkSA=; b=ig0K+bXaHHqx8osfwtjHz1Wcfv+h8uM4oL53utJn/jmZpPgRXMBN5Y97 VbS/TUc84oNsarJx4pw3xgDqOEplJrmMM2YTeHEFjSYkv/us+d8GhJ8Hw FYoIAtxvJ6Z2Qyb3ETFRfvLpTzqQvMnrdCmy8pSHcT8m8WHAj9n613wv1 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAIZaOFGtJV2b/2dsb2JhbAApFwOEHYQPvB5tdBZzgiwBBCMKKBElARwOCgQMAwMCBDAUEAIBAQMTCIgLDC6ZMI5VhA+OWY1LG3ULIhwHghUyYQOXaY9TgjhRgXI1
X-IronPort-AV: E=Sophos;i="4.84,800,1355097600";  d="scan'208,217";a="184757652"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 07 Mar 2013 09:20:05 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r279K5Xp031156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Thu, 7 Mar 2013 09:20:05 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.167]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 03:20:05 -0600
From: "Pascal Thubert (pthubert)" 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: Updated Meeting invitation for 6TSCH Weekly Call
Thread-Index: Ac4bFNqNslnOpI5BTP+JzxJTAlXSEQ==
Date: Thu, 7 Mar 2013 09:20:05 +0000
Deferred-Delivery: Thu, 7 Mar 2013 09:20:00 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.49.80.14]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835CE4E2Axmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: [6tsch] Updated Meeting invitation for 6TSCH Weekly Call
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Mar 2013 09:20:11 -0000

--_000_E045AECD98228444A58C61C200AE1BD835CE4E2Axmbrcdx01ciscoc_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBhbGwsDQoNCldlIGhhdmUgYSBjb25zZW5zdXMgdGhhdCB0aGUgY2FsbCBjYW4gYmUgbW92
ZWQgYW4gaG91ciBlYXJsaWVyIG9uIEZyaWRheXMuDQpQbGVhc2Ugbm90ZSB0aGF0IGZvbGxvd2lu
ZyBUb23igJlzIHJlY29tbWVuZGF0aW9uLCB0aGUgY2FsbCBpcyBub3cgYWxpZ25lZCB0byBVUyBw
YWNpZmljIHRpbWUgZm9yIHRoZSBEU1QgPT0gc3VtbWVyIHRpbWUgc3dpdGNoLg0KRm9yIGluc3Rh
bmNlLCB0d2ljZSBhIHllYXIsIHRoZSB0aW1lIG9mIHRoZSBjYWxsIHdpbGwgY2hhbmdlIGJ5IG9u
ZSBob3VyIGluIEV1cm9wZSB3aGlsZSBpdCBzdGF5cyBjb25zaXN0ZW50IGluIHRoZSBVUy4NCg0K
Q2hlZXJzLA0KDQpQYXNjYWwNCg0KVG9waWM6IDZUU0NIIFdlZWtseQ0KRGF0ZTogRXZlcnkgRnJp
ZGF5LCBmcm9tIEZyaWRheSwgTWFyY2ggOCwgMjAxMyB0byBGcmlkYXksIE1hcmNoIDcsIDIwMTQN
ClRpbWU6IDg6MDAgYW0sIFBhY2lmaWMgU3RhbmRhcmQgVGltZSAoU2FuIEZyYW5jaXNjbywgR01U
LTA4OjAwKQ0KTWVldGluZyBOdW1iZXI6IDIwNiA4MDIgOTEzDQpNZWV0aW5nIFBhc3N3b3JkOiBz
aXh0dXMNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQpUbyBqb2luIHRoZSBvbmxpbmUgbWVldGluZyAoTm93IGZyb20gbW9iaWxlIGRl
dmljZXMhKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KMS4gR28gdG8gaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBo
cD9FRD0yMTk2MTUwMDcmVUlEPTAmUFc9TlpUUmtOREF3T1RFMSZSVD1NaU0wDQoyLiBFbnRlciB5
b3VyIG5hbWUgYW5kIGVtYWlsIGFkZHJlc3MuDQozLiBFbnRlciB0aGUgbWVldGluZyBwYXNzd29y
ZDogc2l4dHVzDQo0LiBDbGljayAiSm9pbiBOb3ciLg0KDQpUbyB2aWV3IGluIG90aGVyIHRpbWUg
em9uZXMgb3IgbGFuZ3VhZ2VzLCBwbGVhc2UgY2xpY2sgdGhlIGxpbms6DQpodHRwczovL2Npc2Nv
LndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP0VEPTIxOTYxNTAwNyZVSUQ9MCZQVz1OWlRSa05E
QXdPVEUxJk9SVD1NaU0wDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkFMRVJUOlRvbGwtRnJlZSBEaWFsIFJlc3RyaWN0
aW9ucyBmb3IgKDQwOCkgYW5kICg5MTkpIEFyZWEgQ29kZXMNCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhlIGFmZmVj
dGVkIHRvbGwgZnJlZSBudW1iZXJzIGFyZTogKDg2NikgNDMyLTk5MDMgZm9yIHRoZSBTYW4gSm9z
ZS9NaWxwaXRhcyBhcmVhIGFuZCAoODY2KSAzNDktMzUyMCBmb3IgdGhlIFJUUCBhcmVhLg0KDQpQ
bGVhc2UgZGlhbCB0aGUgbG9jYWwgYWNjZXNzIG51bWJlciBmb3IgeW91ciBhcmVhIGZyb20gdGhl
IGxpc3QgYmVsb3c6DQotIFNhbiBKb3NlL01pbHBpdGFzICg0MDgpIGFyZWE6IDUyNS02ODAwDQot
IFJUUCAoOTE5KSBhcmVhOiAzOTItMzMzMA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUbyBqb2luIHRoZSB0ZWxlY29uZmVyZW5jZSBv
bmx5DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQoxLiBEaWFsIGludG8gQ2lzY28gV2ViRXggKHZpZXcgYWxsIEdsb2JhbCBBY2Nlc3MgTnVt
YmVycyBhdA0KaHR0cDovL2Npc2NvLmNvbS9lbi9VUy9hYm91dC9kb2luZ19idXNpbmVzcy9jb25m
ZXJlbmNpbmcvaW5kZXguaHRtbA0KMi4gRm9sbG93IHRoZSBwcm9tcHRzIHRvIGVudGVyIHRoZSBN
ZWV0aW5nIE51bWJlciAobGlzdGVkIGFib3ZlKSBvciBBY2Nlc3MgQ29kZSBmb2xsb3dlZCBieSB0
aGUgIyBzaWduLg0KDQpTYW4gSm9zZSwgQ0E6ICsxLjQwOC41MjUuNjgwMCBSVFA6ICsxLjkxOS4z
OTIuMzMzMA0KDQpVUy9DYW5hZGE6ICsxLjg2Ni40MzIuOTkwMyBVbml0ZWQgS2luZ2RvbTogKzQ0
LjIwLjg4MjQuMDExNw0KDQpJbmRpYTogKzkxLjgwLjQzNTAuMTExMSBHZXJtYW55OiArNDkuNjE5
LjY3NzMuOTAwMg0KDQpKYXBhbjogKzgxLjMuNTc2My45Mzk0IENoaW5hOiArODYuMTAuODUxNS41
NjY2DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCkZvciBhc3Npc3RhbmNlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoxLiBHbyB0byBodHRwczovL2Npc2NvLndlYmV4LmNvbS9j
aXNjb3NhbGVzL21jDQoyLiBPbiB0aGUgbGVmdCBuYXZpZ2F0aW9uIGJhciwgY2xpY2sgIlN1cHBv
cnQiLg0KDQpZb3UgY2FuIGNvbnRhY3QgbWUgYXQ6DQpwdGh1YmVydEBjaXNjby5jb208bWFpbHRv
OnB0aHViZXJ0QGNpc2NvLmNvbT4NCjMzLTQ5LTcyMyAyNjM0DQoNClRvIGFkZCB0aGlzIG1lZXRp
bmcgdG8geW91ciBjYWxlbmRhciBwcm9ncmFtIChmb3IgZXhhbXBsZSBNaWNyb3NvZnQgT3V0bG9v
ayksIGNsaWNrIHRoaXMgbGluazoNCmh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMv
ai5waHA/RUQ9MjE5NjE1MDA3JlVJRD0wJklDUz1NSSZMRD0xJlJEPTImU1Q9MSZTSEEyPUFBQUFB
bXZJQ0lwRnlaNGltRTVzZVRiN2lqWlVvTXVFZ3cxaDJwWEdJR1NNeVFFYiZSVD1NaU0wDQoNCg0K
DQoNCg0KDQpodHRwOi8vd3d3LndlYmV4LmNvbQ0KDQpDQ1A6KzE0MDg1MjU2ODAweDIwNjgwMjkx
MyMNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhpcyBXZWJFeCBzZXJ2aWNlIGluY2x1ZGVzIGEgZmVh
dHVyZSB0aGF0IGFsbG93cyBhdWRpbyBhbmQgYW55IGRvY3VtZW50cyBhbmQgb3RoZXIgbWF0ZXJp
YWxzIGV4Y2hhbmdlZCBvciB2aWV3ZWQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVk
LiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBz
dWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byB0aGUgcmVjb3JkaW5nLCBk
aXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgbWVldGluZyBob3N0IHByaW9yIHRvIHRoZSBz
dGFydCBvZiB0aGUgcmVjb3JkaW5nIG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLiBQbGVhc2Ug
bm90ZSB0aGF0IGFueSBzdWNoIHJlY29yZGluZ3MgbWF5IGJlIHN1YmplY3QgdG8gZGlzY292ZXJ5
IGluIHRoZSBldmVudCBvZiBsaXRpZ2F0aW9uLg0K

--_000_E045AECD98228444A58C61C200AE1BD835CE4E2Axmbrcdx01ciscoc_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44
NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX
b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp
Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0
Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv
eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi
IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIg
YWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPldlIGhhdmUgYSBjb25zZW5zdXMgdGhhdCB0aGUgY2FsbCBjYW4gYmUgbW92
ZWQgYW4gaG91ciBlYXJsaWVyIG9uIEZyaWRheXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5QbGVhc2Ugbm90ZSB0aGF0IGZvbGxvd2luZyBUb23igJlzIHJlY29tbWVuZGF0aW9uLCB0
aGUgY2FsbCBpcyBub3cgYWxpZ25lZCB0byBVUyBwYWNpZmljIHRpbWUgZm9yIHRoZSBEU1QgPT0g
c3VtbWVyIHRpbWUgc3dpdGNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBpbnN0
YW5jZSwgdHdpY2UgYSB5ZWFyLCB0aGUgdGltZSBvZiB0aGUgY2FsbCB3aWxsIGNoYW5nZSBieSBv
bmUgaG91ciBpbiBFdXJvcGUgd2hpbGUgaXQgc3RheXMgY29uc2lzdGVudCBpbiB0aGUgVVMuDQo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFzY2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NClRvcGlj
OiA2VFNDSCBXZWVrbHkgPGJyPg0KRGF0ZTogRXZlcnkgRnJpZGF5LCBmcm9tIEZyaWRheSwgTWFy
Y2ggOCwgMjAxMyB0byBGcmlkYXksIE1hcmNoIDcsIDIwMTQgPGJyPg0KVGltZTogODowMCBhbSwg
UGFjaWZpYyBTdGFuZGFyZCBUaW1lIChTYW4gRnJhbmNpc2NvLCBHTVQtMDg6MDApIDxicj4NCk1l
ZXRpbmcgTnVtYmVyOiAyMDYgODAyIDkxMyA8YnI+DQpNZWV0aW5nIFBhc3N3b3JkOiBzaXh0dXMg
PGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLSA8YnI+DQpUbyBqb2luIHRoZSBvbmxpbmUgbWVldGluZyAoTm93IGZy
b20gbW9iaWxlIGRldmljZXMhKSA8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NCjEuIEdvIHRvIDxhIGhyZWY9Imh0dHBzOi8v
Y2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvai5waHA/RUQ9MjE5NjE1MDA3JmFtcDtVSUQ9MCZh
bXA7UFc9TlpUUmtOREF3T1RFMSZhbXA7UlQ9TWlNMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6
Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9FRD0yMTk2MTUwMDcmYW1wO1VJRD0w
JmFtcDtQVz1OWlRSa05EQXdPVEUxJmFtcDtSVD1NaU0wPC9hPg0KPGJyPg0KMi4gRW50ZXIgeW91
ciBuYW1lIGFuZCBlbWFpbCBhZGRyZXNzLiA8YnI+DQozLiBFbnRlciB0aGUgbWVldGluZyBwYXNz
d29yZDogc2l4dHVzIDxicj4NCjQuIENsaWNrICZxdW90O0pvaW4gTm93JnF1b3Q7LiA8YnI+DQo8
YnI+DQpUbyB2aWV3IGluIG90aGVyIHRpbWUgem9uZXMgb3IgbGFuZ3VhZ2VzLCBwbGVhc2UgY2xp
Y2sgdGhlIGxpbms6IDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nv
c2FsZXMvai5waHA/RUQ9MjE5NjE1MDA3JmFtcDtVSUQ9MCZhbXA7UFc9TlpUUmtOREF3T1RFMSZh
bXA7T1JUPU1pTTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNj
b3NhbGVzL2oucGhwP0VEPTIxOTYxNTAwNyZhbXA7VUlEPTAmYW1wO1BXPU5aVFJrTkRBd09URTEm
YW1wO09SVD1NaU0wPC9hPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+DQpBTEVSVDpUb2xsLUZy
ZWUgRGlhbCBSZXN0cmljdGlvbnMgZm9yICg0MDgpIGFuZCAoOTE5KSBBcmVhIENvZGVzIDxicj4N
Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0gPGJyPg0KPGJyPg0KVGhlIGFmZmVjdGVkIHRvbGwgZnJlZSBudW1iZXJzIGFyZTog
KDg2NikgNDMyLTk5MDMgZm9yIHRoZSBTYW4gSm9zZS9NaWxwaXRhcyBhcmVhIGFuZCAoODY2KSAz
NDktMzUyMCBmb3IgdGhlIFJUUCBhcmVhLg0KPGJyPg0KPGJyPg0KUGxlYXNlIGRpYWwgdGhlIGxv
Y2FsIGFjY2VzcyBudW1iZXIgZm9yIHlvdXIgYXJlYSBmcm9tIHRoZSBsaXN0IGJlbG93OiA8YnI+
DQotIFNhbiBKb3NlL01pbHBpdGFzICg0MDgpIGFyZWE6IDUyNS02ODAwIDxicj4NCi0gUlRQICg5
MTkpIGFyZWE6IDM5Mi0zMzMwIDxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVG8gam9pbiB0aGUgdGVsZWNvbmZl
cmVuY2Ugb25seSA8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tIDxicj4NCjEuIERpYWwgaW50byBDaXNjbyBXZWJFeCAodmlldyBhbGwg
R2xvYmFsIEFjY2VzcyBOdW1iZXJzIGF0IDxicj4NCjxhIGhyZWY9Imh0dHA6Ly9jaXNjby5jb20v
ZW4vVVMvYWJvdXQvZG9pbmdfYnVzaW5lc3MvY29uZmVyZW5jaW5nL2luZGV4Lmh0bWwiIHRhcmdl
dD0iX2JsYW5rIj5odHRwOi8vY2lzY28uY29tL2VuL1VTL2Fib3V0L2RvaW5nX2J1c2luZXNzL2Nv
bmZlcmVuY2luZy9pbmRleC5odG1sPC9hPg0KPGJyPg0KMi4gRm9sbG93IHRoZSBwcm9tcHRzIHRv
IGVudGVyIHRoZSBNZWV0aW5nIE51bWJlciAobGlzdGVkIGFib3ZlKSBvciBBY2Nlc3MgQ29kZSBm
b2xsb3dlZCBieSB0aGUgIyBzaWduLg0KPGJyPg0KPGJyPg0KU2FuIEpvc2UsIENBOiAmIzQzOzEu
NDA4LjUyNS42ODAwIFJUUDogJiM0MzsxLjkxOS4zOTIuMzMzMCA8YnI+DQo8YnI+DQpVUy9DYW5h
ZGE6ICYjNDM7MS44NjYuNDMyLjk5MDMgVW5pdGVkIEtpbmdkb206ICYjNDM7NDQuMjAuODgyNC4w
MTE3IDxicj4NCjxicj4NCkluZGlhOiAmIzQzOzkxLjgwLjQzNTAuMTExMSBHZXJtYW55OiAmIzQz
OzQ5LjYxOS42NzczLjkwMDIgPGJyPg0KPGJyPg0KSmFwYW46ICYjNDM7ODEuMy41NzYzLjkzOTQg
Q2hpbmE6ICYjNDM7ODYuMTAuODUxNS41NjY2IDxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KRm9yIGFzc2lzdGFu
Y2UgPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLSA8YnI+DQoxLiBHbyB0byA8YSBocmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9j
aXNjb3NhbGVzL21jIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lz
Y29zYWxlcy9tYzwvYT4NCjxicj4NCjIuIE9uIHRoZSBsZWZ0IG5hdmlnYXRpb24gYmFyLCBjbGlj
ayAmcXVvdDtTdXBwb3J0JnF1b3Q7LiA8YnI+DQo8YnI+DQpZb3UgY2FuIGNvbnRhY3QgbWUgYXQ6
IDxicj4NCjxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20iPnB0aHViZXJ0QGNpc2Nv
LmNvbTwvYT4gPGJyPg0KMzMtNDktNzIzIDI2MzQgPGJyPg0KPGJyPg0KVG8gYWRkIHRoaXMgbWVl
dGluZyB0byB5b3VyIGNhbGVuZGFyIHByb2dyYW0gKGZvciBleGFtcGxlIE1pY3Jvc29mdCBPdXRs
b29rKSwgY2xpY2sgdGhpcyBsaW5rOg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJl
eC5jb20vY2lzY29zYWxlcy9qLnBocD9FRD0yMTk2MTUwMDcmYW1wO1VJRD0wJmFtcDtJQ1M9TUkm
YW1wO0xEPTEmYW1wO1JEPTImYW1wO1NUPTEmYW1wO1NIQTI9QUFBQUFtdklDSXBGeVo0aW1FNXNl
VGI3aWpaVW9NdUVndzFoMnBYR0lHU015UUViJmFtcDtSVD1NaU0wIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9FRD0yMTk2MTUwMDcmYW1w
O1VJRD0wJmFtcDtJQ1M9TUkmYW1wO0xEPTEmYW1wO1JEPTImYW1wO1NUPTEmYW1wO1NIQTI9QUFB
QUFtdklDSXBGeVo0aW1FNXNlVGI3aWpaVW9NdUVndzFoMnBYR0lHU015UUViJmFtcDtSVD1NaU0w
PC9hPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGEgaHJlZj0i
aHR0cDovL3d3dy53ZWJleC5jb20iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LndlYmV4LmNv
bTwvYT4gPGJyPg0KPGJyPg0KQ0NQOiYjNDM7MTQwODUyNTY4MDB4MjA2ODAyOTEzIyA8YnI+DQo8
YnI+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGlzIFdlYkV4IHNlcnZpY2UgaW5jbHVkZXMgYSBmZWF0
dXJlIHRoYXQgYWxsb3dzIGF1ZGlvIGFuZCBhbnkgZG9jdW1lbnRzIGFuZCBvdGhlciBtYXRlcmlh
bHMgZXhjaGFuZ2VkIG9yIHZpZXdlZCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQu
IEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1
Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50DQogdG8gdGhlIHJlY29yZGluZywg
ZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIG1lZXRpbmcgaG9zdCBwcmlvciB0byB0aGUg
c3RhcnQgb2YgdGhlIHJlY29yZGluZyBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi4gUGxlYXNl
IG5vdGUgdGhhdCBhbnkgc3VjaCByZWNvcmRpbmdzIG1heSBiZSBzdWJqZWN0IHRvIGRpc2NvdmVy
eSBpbiB0aGUgZXZlbnQgb2YgbGl0aWdhdGlvbi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_E045AECD98228444A58C61C200AE1BD835CE4E2Axmbrcdx01ciscoc_--

From pthubert@cisco.com  Thu Mar  7 08:12:47 2013
Return-Path: 
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 1120821F8C7C for <6tsch@ietfa.amsl.com>; Thu,  7 Mar 2013 08:12:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.098
X-Spam-Level: 
X-Spam-Status: No, score=-12.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 TZKpLLo5yP8m for <6tsch@ietfa.amsl.com>; Thu,  7 Mar 2013 08:12:46 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B820821F8C20 for <6tsch@ietf.org>; Thu,  7 Mar 2013 08:12:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21040; q=dns/txt; s=iport; t=1362672765; x=1363882365; h=from:to:subject:date:message-id:mime-version; bh=4WWpvHQMOgAGon/erNU5u9IzeO+VmK7Wd9AQM0/aodQ=; b=iqH/tGvtFsqFvnOOAsjLboQxn0krF4B9CzATiyNP4nVuLUR+eNZ4Msod 7dOvBqS1cSFcfgJk8NI1JkJouRTehSJ3tRBeYelAmQN1BjlRz+MFOkgDy a/O3MEHKWhfOASXlqufCN1BL0l6J1feD9Ho6o/OqRYuiKoCxoV0XqJH9l c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAHm7OFGtJV2Y/2dsb2JhbAApFwOEG4QPvB9rdhZtB4IsAQEBBCMKKBElARkDAQEBCwoEDAMDAgQwFAkHAgEBAxMIiAsMLplhjlWED44OjUsbdQsbBwoSB4IVMmEDl2mPU4I4UYFyNQ
X-IronPort-AV: E=Sophos;i="4.84,803,1355097600";  d="scan'208,217";a="181906854"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 07 Mar 2013 16:12:45 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r27GCj7b030524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Thu, 7 Mar 2013 16:12:45 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.167]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 10:12:44 -0600
From: "Pascal Thubert (pthubert)" 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: Agenda for the March 8th call
Thread-Index: Ac4bTmsjwiVYAA0RTUyZBg4al42bkA==
Date: Thu, 7 Mar 2013 16:12:44 +0000
Deferred-Delivery: Thu, 7 Mar 2013 16:12:00 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.49.80.14]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835CE52D4xmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: [6tsch] Agenda for the March 8th call
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Mar 2013 16:12:47 -0000

--_000_E045AECD98228444A58C61C200AE1BD835CE52D4xmbrcdx01ciscoc_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBhbGwsDQoNCi8hXCBEU1QgaXMgbmV4dCB3ZWVrIGluIHRoZSBVUy4gQ29vbCB0aGluZywg
dGhlcmUgd2lsbCBiZSBubyBjYWxsIGR1ZSB0byBJRVRGIC8hXA0KDQpJbnRyb2R1Y2UgdGVybWlu
b2xvZ3kgZHJhZnQ6IDEwbWluIChNUlApDQpDaGFuZ2VzIGluIG90aGVyIGRyYWZ0czogMTBtaW4g
KGVkaXRvcnMpDQpBZ2VuZGFzIGZvciBuZXcgd2VlayBtZWV0aW5nczogMTAgKFBUKQ0KRFNDUHMg
YW5kIHByaW9yaXRpZXMgLyBpbXV4L211eDogMzAgbWluDQoNCkFzIHVzdWFsLCBpZiB5b3Ugd2lz
aCB0byBhZGQgc3R1ZmYsIHBsZWFzZSBsZXQgbWUga25vdyBob3cgbXVjaCB0aW1lIHlvdSBuZWVk
IGFuZCBzZW5kIHNsaWRlcyBpbiBhZHZhbmNlIHNvIEkgY2FuIHVwbG9hZCB0aGVtLg0KDQovIVwg
dGhlIGNhbGwgd2lsbCBiZSByZWNvcmRlZCBhbmQgYXZhaWxhYmxlIGZyb20gV2ViZXggLyFcDQoN
CkNoZWVycywNCg0KUGFzY2FsDQoNCkZyb206IDZ0c2NoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0
bzo2dHNjaC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGFzY2FsIFRodWJlcnQgKHB0
aHViZXJ0KQ0KU2VudDogamV1ZGkgNyBtYXJzIDIwMTMgMTA6MjANClRvOiA2dHNjaEBpZXRmLm9y
Zw0KU3ViamVjdDogWzZ0c2NoXSBVcGRhdGVkIE1lZXRpbmcgaW52aXRhdGlvbiBmb3IgNlRTQ0gg
V2Vla2x5IENhbGwNCg0KRGVhciBhbGwsDQoNCldlIGhhdmUgYSBjb25zZW5zdXMgdGhhdCB0aGUg
Y2FsbCBjYW4gYmUgbW92ZWQgYW4gaG91ciBlYXJsaWVyIG9uIEZyaWRheXMuDQpQbGVhc2Ugbm90
ZSB0aGF0IGZvbGxvd2luZyBUb23igJlzIHJlY29tbWVuZGF0aW9uLCB0aGUgY2FsbCBpcyBub3cg
YWxpZ25lZCB0byBVUyBwYWNpZmljIHRpbWUgZm9yIHRoZSBEU1QgPT0gc3VtbWVyIHRpbWUgc3dp
dGNoLg0KRm9yIGluc3RhbmNlLCB0d2ljZSBhIHllYXIsIHRoZSB0aW1lIG9mIHRoZSBjYWxsIHdp
bGwgY2hhbmdlIGJ5IG9uZSBob3VyIGluIEV1cm9wZSB3aGlsZSBpdCBzdGF5cyBjb25zaXN0ZW50
IGluIHRoZSBVUy4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KVG9waWM6IDZUU0NIIFdlZWtseQ0K
RGF0ZTogRXZlcnkgRnJpZGF5LCBmcm9tIEZyaWRheSwgTWFyY2ggOCwgMjAxMyB0byBGcmlkYXks
IE1hcmNoIDcsIDIwMTQNClRpbWU6IDg6MDAgYW0sIFBhY2lmaWMgU3RhbmRhcmQgVGltZSAoU2Fu
IEZyYW5jaXNjbywgR01ULTA4OjAwKQ0KTWVldGluZyBOdW1iZXI6IDIwNiA4MDIgOTEzDQpNZWV0
aW5nIFBhc3N3b3JkOiBzaXh0dXMNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUbyBqb2luIHRoZSBvbmxpbmUgbWVldGluZyAoTm93
IGZyb20gbW9iaWxlIGRldmljZXMhKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KMS4gR28gdG8gaHR0cHM6Ly9jaXNjby53ZWJleC5jb20v
Y2lzY29zYWxlcy9qLnBocD9FRD0yMTk2MTUwMDcmVUlEPTAmUFc9TlpUUmtOREF3T1RFMSZSVD1N
aU0wDQoyLiBFbnRlciB5b3VyIG5hbWUgYW5kIGVtYWlsIGFkZHJlc3MuDQozLiBFbnRlciB0aGUg
bWVldGluZyBwYXNzd29yZDogc2l4dHVzDQo0LiBDbGljayAiSm9pbiBOb3ciLg0KDQpUbyB2aWV3
IGluIG90aGVyIHRpbWUgem9uZXMgb3IgbGFuZ3VhZ2VzLCBwbGVhc2UgY2xpY2sgdGhlIGxpbms6
DQpodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP0VEPTIxOTYxNTAwNyZV
SUQ9MCZQVz1OWlRSa05EQXdPVEUxJk9SVD1NaU0wDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkFMRVJUOlRvbGwtRnJl
ZSBEaWFsIFJlc3RyaWN0aW9ucyBmb3IgKDQwOCkgYW5kICg5MTkpIEFyZWEgQ29kZXMNCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCg0KVGhlIGFmZmVjdGVkIHRvbGwgZnJlZSBudW1iZXJzIGFyZTogKDg2NikgNDMyLTk5MDMg
Zm9yIHRoZSBTYW4gSm9zZS9NaWxwaXRhcyBhcmVhIGFuZCAoODY2KSAzNDktMzUyMCBmb3IgdGhl
IFJUUCBhcmVhLg0KDQpQbGVhc2UgZGlhbCB0aGUgbG9jYWwgYWNjZXNzIG51bWJlciBmb3IgeW91
ciBhcmVhIGZyb20gdGhlIGxpc3QgYmVsb3c6DQotIFNhbiBKb3NlL01pbHBpdGFzICg0MDgpIGFy
ZWE6IDUyNS02ODAwDQotIFJUUCAoOTE5KSBhcmVhOiAzOTItMzMzMA0KDQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUbyBqb2luIHRoZSB0
ZWxlY29uZmVyZW5jZSBvbmx5DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQoxLiBEaWFsIGludG8gQ2lzY28gV2ViRXggKHZpZXcgYWxsIEds
b2JhbCBBY2Nlc3MgTnVtYmVycyBhdA0KaHR0cDovL2Npc2NvLmNvbS9lbi9VUy9hYm91dC9kb2lu
Z19idXNpbmVzcy9jb25mZXJlbmNpbmcvaW5kZXguaHRtbA0KMi4gRm9sbG93IHRoZSBwcm9tcHRz
IHRvIGVudGVyIHRoZSBNZWV0aW5nIE51bWJlciAobGlzdGVkIGFib3ZlKSBvciBBY2Nlc3MgQ29k
ZSBmb2xsb3dlZCBieSB0aGUgIyBzaWduLg0KDQpTYW4gSm9zZSwgQ0E6ICsxLjQwOC41MjUuNjgw
MCBSVFA6ICsxLjkxOS4zOTIuMzMzMA0KDQpVUy9DYW5hZGE6ICsxLjg2Ni40MzIuOTkwMyBVbml0
ZWQgS2luZ2RvbTogKzQ0LjIwLjg4MjQuMDExNw0KDQpJbmRpYTogKzkxLjgwLjQzNTAuMTExMSBH
ZXJtYW55OiArNDkuNjE5LjY3NzMuOTAwMg0KDQpKYXBhbjogKzgxLjMuNTc2My45Mzk0IENoaW5h
OiArODYuMTAuODUxNS41NjY2DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCkZvciBhc3Npc3RhbmNlDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoxLiBHbyB0byBodHRwczovL2Np
c2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL21jDQoyLiBPbiB0aGUgbGVmdCBuYXZpZ2F0aW9uIGJh
ciwgY2xpY2sgIlN1cHBvcnQiLg0KDQpZb3UgY2FuIGNvbnRhY3QgbWUgYXQ6DQpwdGh1YmVydEBj
aXNjby5jb208bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4NCjMzLTQ5LTcyMyAyNjM0DQoNClRv
IGFkZCB0aGlzIG1lZXRpbmcgdG8geW91ciBjYWxlbmRhciBwcm9ncmFtIChmb3IgZXhhbXBsZSBN
aWNyb3NvZnQgT3V0bG9vayksIGNsaWNrIHRoaXMgbGluazoNCmh0dHBzOi8vY2lzY28ud2ViZXgu
Y29tL2Npc2Nvc2FsZXMvai5waHA/RUQ9MjE5NjE1MDA3JlVJRD0wJklDUz1NSSZMRD0xJlJEPTIm
U1Q9MSZTSEEyPUFBQUFBbXZJQ0lwRnlaNGltRTVzZVRiN2lqWlVvTXVFZ3cxaDJwWEdJR1NNeVFF
YiZSVD1NaU0wDQoNCg0KDQoNCg0KDQpodHRwOi8vd3d3LndlYmV4LmNvbQ0KDQpDQ1A6KzE0MDg1
MjU2ODAweDIwNjgwMjkxMyMNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhpcyBXZWJFeCBzZXJ2aWNl
IGluY2x1ZGVzIGEgZmVhdHVyZSB0aGF0IGFsbG93cyBhdWRpbyBhbmQgYW55IGRvY3VtZW50cyBh
bmQgb3RoZXIgbWF0ZXJpYWxzIGV4Y2hhbmdlZCBvciB2aWV3ZWQgZHVyaW5nIHRoZSBzZXNzaW9u
IHRvIGJlIHJlY29yZGVkLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2Fs
bHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byB0
aGUgcmVjb3JkaW5nLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgbWVldGluZyBob3N0
IHByaW9yIHRvIHRoZSBzdGFydCBvZiB0aGUgcmVjb3JkaW5nIG9yIGRvIG5vdCBqb2luIHRoZSBz
ZXNzaW9uLiBQbGVhc2Ugbm90ZSB0aGF0IGFueSBzdWNoIHJlY29yZGluZ3MgbWF5IGJlIHN1Ympl
Y3QgdG8gZGlzY292ZXJ5IGluIHRoZSBldmVudCBvZiBsaXRpZ2F0aW9uLg0K

--_000_E045AECD98228444A58C61C200AE1BD835CE52D4xmbrcdx01ciscoc_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl
OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ
Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt
b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx
Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9
DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk
bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0
YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi
b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9
IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVhciBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4vIVwgRFNUIGlzIG5l
eHQgd2VlayBpbiB0aGUgVVMuIENvb2wgdGhpbmcsIHRoZXJlIHdpbGwgYmUgbm8gY2FsbCBkdWUg
dG8gSUVURiAvIVw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkludHJvZHVjZSB0ZXJtaW5vbG9neSBkcmFmdDogMTBtaW4g
KE1SUCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hhbmdlcyBpbiBvdGhlciBkcmFm
dHM6IDEwbWluIChlZGl0b3JzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZ2VuZGFz
IGZvciBuZXcgd2VlayBtZWV0aW5nczogMTAgKFBUKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5EU0NQcyBhbmQgcHJpb3JpdGllcyAvIGltdXgvbXV4OiAzMCBtaW48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFz
IHVzdWFsLCBpZiB5b3Ugd2lzaCB0byBhZGQgc3R1ZmYsIHBsZWFzZSBsZXQgbWUga25vdyBob3cg
bXVjaCB0aW1lIHlvdSBuZWVkIGFuZCBzZW5kIHNsaWRlcyBpbiBhZHZhbmNlIHNvIEkgY2FuIHVw
bG9hZCB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+LyFcIHRoZSBjYWxsIHdpbGwgYmUgcmVjb3JkZWQgYW5kIGF2
YWlsYWJsZSBmcm9tIFdlYmV4IC8hXDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5QYXNjYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw
Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IDZ0c2NoLWJvdW5j
ZXNAaWV0Zi5vcmcgW21haWx0bzo2dHNjaC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm
IE9mIDwvYj5QYXNjYWwgVGh1YmVydCAocHRodWJlcnQpPGJyPg0KPGI+U2VudDo8L2I+IGpldWRp
IDcgbWFycyAyMDEzIDEwOjIwPGJyPg0KPGI+VG86PC9iPiA2dHNjaEBpZXRmLm9yZzxicj4NCjxi
PlN1YmplY3Q6PC9iPiBbNnRzY2hdIFVwZGF0ZWQgTWVldGluZyBpbnZpdGF0aW9uIGZvciA2VFND
SCBXZWVrbHkgQ2FsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPldlIGhhdmUgYSBjb25zZW5zdXMgdGhhdCB0aGUgY2FsbCBjYW4gYmUgbW92ZWQgYW4g
aG91ciBlYXJsaWVyIG9uIEZyaWRheXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Q
bGVhc2Ugbm90ZSB0aGF0IGZvbGxvd2luZyBUb23igJlzIHJlY29tbWVuZGF0aW9uLCB0aGUgY2Fs
bCBpcyBub3cgYWxpZ25lZCB0byBVUyBwYWNpZmljIHRpbWUgZm9yIHRoZSBEU1QgPT0gc3VtbWVy
IHRpbWUgc3dpdGNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBpbnN0YW5jZSwg
dHdpY2UgYSB5ZWFyLCB0aGUgdGltZSBvZiB0aGUgY2FsbCB3aWxsIGNoYW5nZSBieSBvbmUgaG91
ciBpbiBFdXJvcGUgd2hpbGUgaXQgc3RheXMgY29uc2lzdGVudCBpbiB0aGUgVVMuDQo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+UGFzY2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NClRvcGljOiA2VFND
SCBXZWVrbHkgPGJyPg0KRGF0ZTogRXZlcnkgRnJpZGF5LCBmcm9tIEZyaWRheSwgTWFyY2ggOCwg
MjAxMyB0byBGcmlkYXksIE1hcmNoIDcsIDIwMTQgPGJyPg0KVGltZTogODowMCBhbSwgUGFjaWZp
YyBTdGFuZGFyZCBUaW1lIChTYW4gRnJhbmNpc2NvLCBHTVQtMDg6MDApIDxicj4NCk1lZXRpbmcg
TnVtYmVyOiAyMDYgODAyIDkxMyA8YnI+DQpNZWV0aW5nIFBhc3N3b3JkOiBzaXh0dXMgPGJyPg0K
PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSA8YnI+DQpUbyBqb2luIHRoZSBvbmxpbmUgbWVldGluZyAoTm93IGZyb20gbW9i
aWxlIGRldmljZXMhKSA8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NCjEuIEdvIHRvIDxhIGhyZWY9Imh0dHBzOi8vY2lzY28u
d2ViZXguY29tL2Npc2Nvc2FsZXMvai5waHA/RUQ9MjE5NjE1MDA3JmFtcDtVSUQ9MCZhbXA7UFc9
TlpUUmtOREF3T1RFMSZhbXA7UlQ9TWlNMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9jaXNj
by53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9FRD0yMTk2MTUwMDcmYW1wO1VJRD0wJmFtcDtQ
Vz1OWlRSa05EQXdPVEUxJmFtcDtSVD1NaU0wPC9hPg0KPGJyPg0KMi4gRW50ZXIgeW91ciBuYW1l
IGFuZCBlbWFpbCBhZGRyZXNzLiA8YnI+DQozLiBFbnRlciB0aGUgbWVldGluZyBwYXNzd29yZDog
c2l4dHVzIDxicj4NCjQuIENsaWNrICZxdW90O0pvaW4gTm93JnF1b3Q7LiA8YnI+DQo8YnI+DQpU
byB2aWV3IGluIG90aGVyIHRpbWUgem9uZXMgb3IgbGFuZ3VhZ2VzLCBwbGVhc2UgY2xpY2sgdGhl
IGxpbms6IDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMv
ai5waHA/RUQ9MjE5NjE1MDA3JmFtcDtVSUQ9MCZhbXA7UFc9TlpUUmtOREF3T1RFMSZhbXA7T1JU
PU1pTTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVz
L2oucGhwP0VEPTIxOTYxNTAwNyZhbXA7VUlEPTAmYW1wO1BXPU5aVFJrTkRBd09URTEmYW1wO09S
VD1NaU0wPC9hPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+DQpBTEVSVDpUb2xsLUZyZWUgRGlh
bCBSZXN0cmljdGlvbnMgZm9yICg0MDgpIGFuZCAoOTE5KSBBcmVhIENvZGVzIDxicj4NCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0gPGJyPg0KPGJyPg0KVGhlIGFmZmVjdGVkIHRvbGwgZnJlZSBudW1iZXJzIGFyZTogKDg2Nikg
NDMyLTk5MDMgZm9yIHRoZSBTYW4gSm9zZS9NaWxwaXRhcyBhcmVhIGFuZCAoODY2KSAzNDktMzUy
MCBmb3IgdGhlIFJUUCBhcmVhLg0KPGJyPg0KPGJyPg0KUGxlYXNlIGRpYWwgdGhlIGxvY2FsIGFj
Y2VzcyBudW1iZXIgZm9yIHlvdXIgYXJlYSBmcm9tIHRoZSBsaXN0IGJlbG93OiA8YnI+DQotIFNh
biBKb3NlL01pbHBpdGFzICg0MDgpIGFyZWE6IDUyNS02ODAwIDxicj4NCi0gUlRQICg5MTkpIGFy
ZWE6IDM5Mi0zMzMwIDxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVG8gam9pbiB0aGUgdGVsZWNvbmZlcmVuY2Ug
b25seSA8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tIDxicj4NCjEuIERpYWwgaW50byBDaXNjbyBXZWJFeCAodmlldyBhbGwgR2xvYmFs
IEFjY2VzcyBOdW1iZXJzIGF0IDxicj4NCjxhIGhyZWY9Imh0dHA6Ly9jaXNjby5jb20vZW4vVVMv
YWJvdXQvZG9pbmdfYnVzaW5lc3MvY29uZmVyZW5jaW5nL2luZGV4Lmh0bWwiIHRhcmdldD0iX2Js
YW5rIj5odHRwOi8vY2lzY28uY29tL2VuL1VTL2Fib3V0L2RvaW5nX2J1c2luZXNzL2NvbmZlcmVu
Y2luZy9pbmRleC5odG1sPC9hPg0KPGJyPg0KMi4gRm9sbG93IHRoZSBwcm9tcHRzIHRvIGVudGVy
IHRoZSBNZWV0aW5nIE51bWJlciAobGlzdGVkIGFib3ZlKSBvciBBY2Nlc3MgQ29kZSBmb2xsb3dl
ZCBieSB0aGUgIyBzaWduLg0KPGJyPg0KPGJyPg0KU2FuIEpvc2UsIENBOiAmIzQzOzEuNDA4LjUy
NS42ODAwIFJUUDogJiM0MzsxLjkxOS4zOTIuMzMzMCA8YnI+DQo8YnI+DQpVUy9DYW5hZGE6ICYj
NDM7MS44NjYuNDMyLjk5MDMgVW5pdGVkIEtpbmdkb206ICYjNDM7NDQuMjAuODgyNC4wMTE3IDxi
cj4NCjxicj4NCkluZGlhOiAmIzQzOzkxLjgwLjQzNTAuMTExMSBHZXJtYW55OiAmIzQzOzQ5LjYx
OS42NzczLjkwMDIgPGJyPg0KPGJyPg0KSmFwYW46ICYjNDM7ODEuMy41NzYzLjkzOTQgQ2hpbmE6
ICYjNDM7ODYuMTAuODUxNS41NjY2IDxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KRm9yIGFzc2lzdGFuY2UgPGJy
Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LSA8YnI+DQoxLiBHbyB0byA8YSBocmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3Nh
bGVzL21jIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxl
cy9tYzwvYT4NCjxicj4NCjIuIE9uIHRoZSBsZWZ0IG5hdmlnYXRpb24gYmFyLCBjbGljayAmcXVv
dDtTdXBwb3J0JnF1b3Q7LiA8YnI+DQo8YnI+DQpZb3UgY2FuIGNvbnRhY3QgbWUgYXQ6IDxicj4N
CjxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20iPnB0aHViZXJ0QGNpc2NvLmNvbTwv
YT4gPGJyPg0KMzMtNDktNzIzIDI2MzQgPGJyPg0KPGJyPg0KVG8gYWRkIHRoaXMgbWVldGluZyB0
byB5b3VyIGNhbGVuZGFyIHByb2dyYW0gKGZvciBleGFtcGxlIE1pY3Jvc29mdCBPdXRsb29rKSwg
Y2xpY2sgdGhpcyBsaW5rOg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20v
Y2lzY29zYWxlcy9qLnBocD9FRD0yMTk2MTUwMDcmYW1wO1VJRD0wJmFtcDtJQ1M9TUkmYW1wO0xE
PTEmYW1wO1JEPTImYW1wO1NUPTEmYW1wO1NIQTI9QUFBQUFtdklDSXBGeVo0aW1FNXNlVGI3aWpa
VW9NdUVndzFoMnBYR0lHU015UUViJmFtcDtSVD1NaU0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9FRD0yMTk2MTUwMDcmYW1wO1VJRD0w
JmFtcDtJQ1M9TUkmYW1wO0xEPTEmYW1wO1JEPTImYW1wO1NUPTEmYW1wO1NIQTI9QUFBQUFtdklD
SXBGeVo0aW1FNXNlVGI3aWpaVW9NdUVndzFoMnBYR0lHU015UUViJmFtcDtSVD1NaU0wPC9hPg0K
PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cDov
L3d3dy53ZWJleC5jb20iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LndlYmV4LmNvbTwvYT4g
PGJyPg0KPGJyPg0KQ0NQOiYjNDM7MTQwODUyNTY4MDB4MjA2ODAyOTEzIyA8YnI+DQo8YnI+DQpJ
TVBPUlRBTlQgTk9USUNFOiBUaGlzIFdlYkV4IHNlcnZpY2UgaW5jbHVkZXMgYSBmZWF0dXJlIHRo
YXQgYWxsb3dzIGF1ZGlvIGFuZCBhbnkgZG9jdW1lbnRzIGFuZCBvdGhlciBtYXRlcmlhbHMgZXhj
aGFuZ2VkIG9yIHZpZXdlZCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQuIEJ5IGpv
aW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVj
b3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50DQogdG8gdGhlIHJlY29yZGluZywgZGlzY3Vz
cyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIG1lZXRpbmcgaG9zdCBwcmlvciB0byB0aGUgc3RhcnQg
b2YgdGhlIHJlY29yZGluZyBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi4gUGxlYXNlIG5vdGUg
dGhhdCBhbnkgc3VjaCByZWNvcmRpbmdzIG1heSBiZSBzdWJqZWN0IHRvIGRpc2NvdmVyeSBpbiB0
aGUgZXZlbnQgb2YgbGl0aWdhdGlvbi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9ib2R5Pg0KPC9odG1sPg0K

--_000_E045AECD98228444A58C61C200AE1BD835CE52D4xmbrcdx01ciscoc_--

From svshah@cisco.com  Thu Mar  7 16:17:11 2013
Return-Path: 
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 8465521F8715 for <6tsch@ietfa.amsl.com>; Thu,  7 Mar 2013 16:17:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.598
X-Spam-Level: 
X-Spam-Status: No, score=-12.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 SLJpNePuQWrY for <6tsch@ietfa.amsl.com>; Thu,  7 Mar 2013 16:17:10 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFE921F8714 for <6tsch@ietf.org>; Thu,  7 Mar 2013 16:17:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18075; q=dns/txt; s=iport; t=1362701830; x=1363911430; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=+C6629WOKRkwgCqrHSbm88pp5ahKD/jZ6mphT/9ogI0=; b=Ha/eDoXkw/1XMUXzBrpxwc/r3JwT0bUvCIRNRmeRkVtUFyjajC3hz8L9 mnbn6RNG3H/j3rxsGSN02X/JNj1QgvCWf9N9KXdtijBwWimQqWBMCeWUX KIoYyyXPVyzfdEZ6H7Nfp2KNyJ1mqzWnvdOXI6xI8v6opjeSE5QaDJNSp U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIFAOEsOVGtJXG+/2dsb2JhbAAqFwOEFq5liSYBhlqBUoFfFnSCLAEBAQQtKBElAQgRAwEBAQsKBAwDORQJBwEBAQEDARIIiAsMLq0Ljg2NSxt1CxUBBQcKAREHgkdhA5dpj1OBMIEIUYFyNQ
X-IronPort-AV: E=Sophos;i="4.84,804,1355097600";  d="scan'208,217";a="185068831"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 08 Mar 2013 00:17:09 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r280H9TM017051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Fri, 8 Mar 2013 00:17:09 GMT
Received: from xmb-aln-x10.cisco.com ([169.254.5.82]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 18:17:09 -0600
From: "Shitanshu Shah (svshah)" 
To: "Pascal Thubert (pthubert)" , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] Agenda for the March 8th call
Thread-Index: Ac4bTmsjwiVYAA0RTUyZBg4al42bkAAMxaAA
Date: Fri, 8 Mar 2013 00:17:08 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [10.154.208.159]
Content-Type: multipart/alternative; boundary="_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151CF558xmbalnx10ciscoc_"
MIME-Version: 1.0
Subject: Re: [6tsch] Agenda for the March 8th call
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2013 00:17:11 -0000

--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151CF558xmbalnx10ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Hi Pascal

http://datatracker.ietf.org/doc/draft-svshah-tsvwg-lln-diffserv-recommendat=
ions/ looks like may be relevant to your last topic in the agenda.
If so and if agenda permits, I can briefly talk about it.

Cheers,
Shitanshu

From: "Pascal Thubert (pthubert)" >
Date: Thursday, March 7, 2013 8:12 AM
To: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: [6tsch] Agenda for the March 8th call

Dear all,

/!\ DST is next week in the US. Cool thing, there will be no call due to IE=
TF /!\

Introduce terminology draft: 10min (MRP)
Changes in other drafts: 10min (editors)
Agendas for new week meetings: 10 (PT)
DSCPs and priorities / imux/mux: 30 min

As usual, if you wish to add stuff, please let me know how much time you ne=
ed and send slides in advance so I can upload them.

/!\ the call will be recorded and available from Webex /!\

Cheers,

Pascal

From: 6tsch-bounces@ietf.org [mailto:6tsch-b=
ounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: jeudi 7 mars 2013 10:20
To: 6tsch@ietf.org
Subject: [6tsch] Updated Meeting invitation for 6TSCH Weekly Call

Dear all,

We have a consensus that the call can be moved an hour earlier on Fridays.
Please note that following Tom=92s recommendation, the call is now aligned =
to US pacific time for the DST =3D=3D summer time switch.
For instance, twice a year, the time of the call will change by one hour in=
 Europe while it stays consistent in the US.

Cheers,

Pascal

Topic: 6TSCH Weekly
Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 206 802 913
Meeting Password: sixtus


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=
=3DNZTRkNDAwOTE1&RT=3DMiM0
2. Enter your name and email address.
3. Enter the meeting password: sixtus
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkN=
DAwOTE1&ORT=3DMiM0

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita=
s area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access =
Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
pthubert@cisco.com
33-49-723 2634

To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&LD=
=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&=
RT=3DMiM0






http://www.webex.com

CCP:+14085256800x206802913#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent to the recording, discuss your concerns =
with the meeting host prior to the start of the recording or do not join th=
e session. Please note that any such recordings may be subject to discovery=
 in the event of litigation.

--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151CF558xmbalnx10ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <52725396D85E744FB661B4C18341747E@cisco.com>
Content-Transfer-Encoding: quoted-printable












Hi Pascal







http://datatracker.ietf.org/doc/draft-svshah-tsvwg-ll=
n-diffserv-recommendations/ looks like may be relevant to your last top=
ic in the agenda.


If so and if agenda permits, I can briefly talk about it.







Cheers,


Shitanshu









From: "Pascal Thubert (pthuber=
t)" <pthubert@cisco.com&g=
t;

Date: Thursday, March 7, 2013 8:12 =
AM

To: "6tsch@ietf.org" <6ts=
ch@ietf.org>

Subject: [6tsch] Agenda for the Mar=
ch 8th call

















Dear all,


 


/!\ DST is next week in the US. Co=
ol thing, there will be no call due to IETF /!\


 


Introduce terminology draft: 10min=
 (MRP)


Changes in other drafts: 10min (ed=
itors)


Agendas for new week meetings: 10 =
(PT)


DSCPs and priorities / imux/mux: 3=
0 min


 


As usual, if you wish to add stuff=
, please let me know how much time you need and send slides in advance so I=
 can upload them.


 


/!\ the call will be recorded and =
available from Webex /!\


 


Cheers,


 




Pascal




 






From:
6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org]
On Behalf Of Pascal Thubert (pthubert)

Sent: jeudi 7 mars 2013 10:20

To: 6tsch@ietf.org

Subject: [6tsch] Updated Meeting invitation for 6TSCH Weekly Call






 


Dear all,


 


We have a consensus that the call c=
an be moved an hour earlier on Fridays.



Please note that following Tom=92s =
recommendation, the call is now aligned to US pacific time for the DST =3D=
=3D summer time switch.


For instance, twice a year, the tim=
e of the call will change by one hour in Europe while it stays consistent i=
n the US.



 


Cheers,


 


Pascal




Topic: 6TSCH Weekly 

Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014 
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) 

Meeting Number: 206 802 913 

Meeting Password: sixtus 





------------------------------------------------------- 

To join the online meeting (Now from mobile devices!) 

------------------------------------------------------- 

1. Go to 
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=
=3DNZTRkNDAwOTE1&RT=3DMiM0

2. Enter your name and email address. 

3. Enter the meeting password: sixtus 

4. Click "Join Now". 



To view in other time zones or languages, please click the link: 

https://cisco=
.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkNDAwOT=
E1&ORT=3DMiM0



---------------------------------------------------------------- 

ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes 

---------------------------------------------------------------- 



The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita=
s area and (866) 349-3520 for the RTP area.




Please dial the local access number for your area from the list below: 

- San Jose/Milpitas (408) area: 525-6800 

- RTP (919) area: 392-3330 



------------------------------------------------------- 

To join the teleconference only 

------------------------------------------------------- 

1. Dial into Cisco WebEx (view all Global Access Numbers at 

http://cisco.com/en/US/about/doing_business/conferen=
cing/index.html

2. Follow the prompts to enter the Meeting Number (listed above) or Access =
Code followed by the # sign.




San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 



US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 



India: +91.80.4350.1111 Germany: +49.619.6773.9002 



Japan: +81.3.5763.9394 China: +86.10.8515.5666 



------------------------------------------------------- 

For assistance 

------------------------------------------------------- 

1. Go to https://cisco.webex.com/ciscosales/mc

2. On the left navigation bar, click "Support". 



You can contact me at: 

pthubert@cisco.com 

33-49-723 2634 



To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:


https:=
//cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&=
amp;LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMu=
Egw1h2pXGIGSMyQEb&RT=3DMiM0













http://www.webex.com=
 



CCP:+14085256800x206802913# 



IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent
 to the recording, discuss your concerns with the meeting host prior to the=
 start of the recording or do not join the session. Please note that any su=
ch recordings may be subject to discovery in the event of litigation.












--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151CF558xmbalnx10ciscoc_--

From twatteyne@gmail.com  Thu Mar  7 16:47:56 2013
Return-Path: 
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 5AF4221F86F2 for <6tsch@ietfa.amsl.com>; Thu,  7 Mar 2013 16:47:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.576
X-Spam-Level: 
X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=1.400,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 IGf3jALR3pDb for <6tsch@ietfa.amsl.com>; Thu,  7 Mar 2013 16:47:55 -0800 (PST)
Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 43EA021F86C8 for <6tsch@ietf.org>; Thu,  7 Mar 2013 16:47:55 -0800 (PST)
Received: by mail-pb0-f46.google.com with SMTP id uo15so761402pbc.5 for <6tsch@ietf.org>; Thu, 07 Mar 2013 16:47:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FkQtLzDJ6bGVjQIrpaLn5/IzjF7tm9bRLEdFV1lRaHw=; b=1CS3+u4BkRiJVdSDbLVCrQeKIb2ubkQr9P3PIrnE0KytFt1S64BxOwiyFs/DqmbUB8 Jgh17RLYQ0HW524bZd/lkECcqfh8f3Kyuj7u91GxIJhKHqZbhyMXWzQJNcisWMAeGXrS JawzxVS987s0Bva/XGRn8sMoUhJmjis5BK8UNBCQQJk+e0Jxn0yPDLjfcBuZZdKSUbzb M7fazRwkWfaANdF8/937pesIRkUNGqWOLl5SEmZ8pqlMSRT6y0WxAJVTB5u3PJYsT5iV MS64mfqEqvpb8EK0aIP2nhXX2tFyKNRY39y4uWvsxSuQVfu2/a37fplB720mNqWJ1Ssu hICg==
MIME-Version: 1.0
X-Received: by 10.66.163.33 with SMTP id yf1mr1199440pab.109.1362703675019; Thu, 07 Mar 2013 16:47:55 -0800 (PST)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Thu, 7 Mar 2013 16:47:54 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 7 Mar 2013 16:47:54 -0800
X-Google-Sender-Auth: gpYAMdKoB8haAPiQ2sYg8Th6b9Q
Message-ID: 
From: Thomas Watteyne 
To: "Shitanshu Shah (svshah)" 
Content-Type: multipart/alternative; boundary=047d7b6dc9e07bd66e04d75f2cc2
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] Agenda for the March 8th call
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2013 00:47:56 -0000

--047d7b6dc9e07bd66e04d75f2cc2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Shitanshu,

I agree. Could you spend a couple of minutes (max 10) to present this draft=
?

Thanks,
Thomas

On Thu, Mar 7, 2013 at 4:17 PM, Shitanshu Shah (svshah) w=
rote:

>
>  Hi Pascal
>
>
> http://datatracker.ietf.org/doc/draft-svshah-tsvwg-lln-diffserv-recommend=
ations/
> looks like may be relevant to your last topic in the agenda.
> If so and if agenda permits, I can briefly talk about it.
>
>  Cheers,
> Shitanshu
>
>   From: "Pascal Thubert (pthubert)" 
> Date: Thursday, March 7, 2013 8:12 AM
> To: "6tsch@ietf.org" <6tsch@ietf.org>
> Subject: [6tsch] Agenda for the March 8th call
>
>   Dear all,****
>
> ** **
>
> /!\ DST is next week in the US. Cool thing, there will be no call due to
> IETF /!\****
>
> ** **
>
> Introduce terminology draft: 10min (MRP)****
>
> Changes in other drafts: 10min (editors)****
>
> Agendas for new week meetings: 10 (PT)****
>
> DSCPs and priorities / imux/mux: 30 min****
>
> ** **
>
> As usual, if you wish to add stuff, please let me know how much time you
> need and send slides in advance so I can upload them.****
>
> ** **
>
> /!\ the call will be recorded and available from Webex /!\****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org<6tsch-bounc=
es@ietf.org>]
> *On Behalf Of *Pascal Thubert (pthubert)
> *Sent:* jeudi 7 mars 2013 10:20
> *To:* 6tsch@ietf.org
> *Subject:* [6tsch] Updated Meeting invitation for 6TSCH Weekly Call****
>
> ** **
>
> Dear all,****
>
> ** **
>
> We have a consensus that the call can be moved an hour earlier on Fridays=
.
> ****
>
> Please note that following Tom=92s recommendation, the call is now aligne=
d
> to US pacific time for the DST =3D=3D summer time switch.****
>
> For instance, twice a year, the time of the call will change by one hour
> in Europe while it stays consistent in the US. ****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
>
> Topic: 6TSCH Weekly
> Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014
> Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
> Meeting Number: 206 802 913
> Meeting Password: sixtus
>
>
> -------------------------------------------------------
> To join the online meeting (Now from mobile devices!)
> -------------------------------------------------------
> 1. Go to
> https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTR=
kNDAwOTE1&RT=3DMiM0
> 2. Enter your name and email address.
> 3. Enter the meeting password: sixtus
> 4. Click "Join Now".
>
> To view in other time zones or languages, please click the link:
>
> https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTR=
kNDAwOTE1&ORT=3DMiM0
>
> ----------------------------------------------------------------
> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
> ----------------------------------------------------------------
>
> The affected toll free numbers are: (866) 432-9903 for the San
> Jose/Milpitas area and (866) 349-3520 for the RTP area.
>
> Please dial the local access number for your area from the list below:
> - San Jose/Milpitas (408) area: 525-6800
> - RTP (919) area: 392-3330
>
> -------------------------------------------------------
> To join the teleconference only
> -------------------------------------------------------
> 1. Dial into Cisco WebEx (view all Global Access Numbers at
> http://cisco.com/en/US/about/doing_business/conferencing/index.html
> 2. Follow the prompts to enter the Meeting Number (listed above) or Acces=
s
> Code followed by the # sign.
>
> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
>
> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
>
> India: +91.80.4350.1111 Germany: +49.619.6773.9002
>
> Japan: +81.3.5763.9394 China: +86.10.8515.5666
>
> -------------------------------------------------------
> For assistance
> -------------------------------------------------------
> 1. Go to https://cisco.webex.com/ciscosales/mc
> 2. On the left navigation bar, click "Support".
>
> You can contact me at:
> pthubert@cisco.com
> 33-49-723 2634
>
> To add this meeting to your calendar program (for example Microsoft
> Outlook), click this link:
>
> https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&=
LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQE=
b&RT=3DMiM0
>
>
>
>
>
>
> http://www.webex.com
>
> CCP:+14085256800x206802913#
>
> IMPORTANT NOTICE: This WebEx service includes a feature that allows audio
> and any documents and other materials exchanged or viewed during the
> session to be recorded. By joining this session, you automatically consen=
t
> to such recordings. If you do not consent to the recording, discuss your
> concerns with the meeting host prior to the start of the recording or do
> not join the session. Please note that any such recordings may be subject
> to discovery in the event of litigation. ****
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

--047d7b6dc9e07bd66e04d75f2cc2
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Shitanshu,

I agree. Could you spend a couple of minutes =
(max 10) to present this draft?

Thanks,
=
Thomas

On Thu, Mar 7, 2013 at 4:17 PM, Sh=
itanshu Shah (svshah) <svshah@cisco.com> wrote:














Hi Pascal







http://datatracker.ietf.org/doc/dra=
ft-svshah-tsvwg-lln-diffserv-recommendations/ looks like may be relevan=
t to your last topic in the agenda.



If so and if agenda permits, I can briefly talk about it.







Cheers,


Shitanshu










From: "Pascal Thubert (pthuber=
t)" <pthube=
rt@cisco.com>

Date: Thursday, March 7, 2013 8:12 =
AM

To: "6tsch@ietf.org" <6tsch@ietf.org>

Subject: [6tsch] Agenda for the Mar=
ch 8th call

















Dear all,


=A0


/!\ DST is next week in the US. Cool thing, =
there will be no call due to IETF /!\


=A0


Introduce terminology draft: 10min (MRP)<=
/u>


Changes in other drafts: 10min (editors)<=
/u>


Agendas for new week meetings: 10 (PT)


DSCPs and priorities / imux/mux: 30 min


=A0


As usual, if you wish to add stuff, please l=
et me know how much time you need and send slides in advance so I can uploa=
d them.



=A0


/!\ the call will be recorded and available =
from Webex /!\


=A0


Cheers,


=A0




Pascal




=A0






From:
6tsch-bounces@i=
etf.org [ma=
ilto:6tsch-bounces@ietf.org]
On Behalf Of Pascal Thubert (pthubert)

Sent: jeudi 7 mars 2013 10:20

To: 6tsch@ietf.o=
rg

Subject: [6tsch] Updated Meeting invitation for 6TSCH Weekly Call=







=A0


Dear all,


=A0


We have a consensus that the call can be move=
d an hour earlier on Fridays.



Please note that following Tom=92s recommenda=
tion, the call is now aligned to US pacific time for the DST =3D=3D summer =
time switch.



For instance, twice a year, the time of the c=
all will change by one hour in Europe while it stays consistent in the US.



=A0


Cheers,


=A0


Pascal




Topic: 6TSCH Weekly 

Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014 
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) 

Meeting Number: 206 802 913 

Meeting Password: sixtus 





------------------------------------------------------- 

To join the online meeting (Now from mobile devices!) 

------------------------------------------------------- 

1. Go to 
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=
=3DNZTRkNDAwOTE1&RT=3DMiM0

2. Enter your name and email address. 

3. Enter the meeting password: sixtus 

4. Click "Join Now". 



To view in other time zones or languages, please click the link: 

https://cisco=
.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkNDAwOT=
E1&ORT=3DMiM0




---------------------------------------------------------------- 

ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes 

---------------------------------------------------------------- 



The affected toll free numbers are: (866) 432-9903 for the San Jose/=
Milpitas area and (866) 349-3520 for the RTP area.




Please dial the local access number for your area from the list below: 

- San Jose/Milpitas (408) area: 525-6800 

- RTP (919) area: 392-3330 



------------------------------------------------------- 

To join the teleconference only 

------------------------------------------------------- 

1. Dial into Cisco WebEx (view all Global Access Numbers at 

http://cisco.com/en/US/about/doing_business/conferen=
cing/index.html

2. Follow the prompts to enter the Meeting Number (listed above) or Access =
Code followed by the # sign.




San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 



US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 



India: +91.80.4350.1111 Germany: +49.619.6773.9002 



Japan: +81.3.5763.9394 China: +86.10.8515.5666 



------------------------------------------------------- 

For assistance 

------------------------------------------------------- 

1. Go to https://cisco.webex.com/ciscosales/mc

2. On the left navigation bar, click "Support". 



You can contact me at: 

pthubert@cisco.com<=
/a> 

33-49-723 2634 



To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:


https:=
//cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&=
amp;LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMu=
Egw1h2pXGIGSMyQEb&RT=3DMiM0














http://www.webex.com=
 



CCP:+14085256800x206802913# 



IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent
 to the recording, discuss your concerns with the meeting host prior to the=
 start of the recording or do not join the session. Please note that any su=
ch recordings may be subject to discovery in the event of litigation.














_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





--047d7b6dc9e07bd66e04d75f2cc2--

From svshah@cisco.com  Thu Mar  7 20:43:32 2013
Return-Path: 
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 926C021F86A1 for <6tsch@ietfa.amsl.com>; Thu,  7 Mar 2013 20:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.598
X-Spam-Level: 
X-Spam-Status: No, score=-12.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 Iy9B-XRVVgdU for <6tsch@ietfa.amsl.com>; Thu,  7 Mar 2013 20:43:31 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCDB21F869E for <6tsch@ietf.org>; Thu,  7 Mar 2013 20:43:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20787; q=dns/txt; s=iport; t=1362717807; x=1363927407; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=yomt5MkpJmJScYg/L1Y3S8L7iyGAh9NwXXkMTo0Y+gg=; b=AHBclKzKJl4mMjzDLGCDtuogEx7fZdA7ta3Z0HaXAW8U5GAznoVhnmIk PqY1lHewSKjRnFf8jaY+RWa5U0+MDjKx2X7EPfhHid1c8cArIgYyeF6Lc pKmizmXiWDInZZqTz6VGon6SPerCstth/KwYgFXFJk31RZ+EDjK9wuzaN g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoMFAOJrOVGtJV2a/2dsb2JhbAAqFwMOhAiuZ4kmAYZagVKBXxZ0giwBAQEEAQEBUhEICxIBCBEDAQEBCwoEDAMuCxQJBwEBAQEDDgUIiAsMLq04jguNSxt1CxUBBQcEBgEJCAeCR2EDl2mPU4EwgQgSP4FyNQ
X-IronPort-AV: E=Sophos;i="4.84,806,1355097600";  d="scan'208,217";a="185199426"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 08 Mar 2013 04:43:26 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r284hQA8008968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Mar 2013 04:43:26 GMT
Received: from xmb-aln-x10.cisco.com ([169.254.5.82]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 22:43:15 -0600
From: "Shitanshu Shah (svshah)" 
To: Thomas Watteyne 
Thread-Topic: [6tsch] Agenda for the March 8th call
Thread-Index: Ac4bTmsjwiVYAA0RTUyZBg4al42bkAAMxaAAABHWnAD//7uigA==
Date: Fri, 8 Mar 2013 04:43:15 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [10.21.124.93]
Content-Type: multipart/alternative; boundary="_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151CF690xmbalnx10ciscoc_"
MIME-Version: 1.0
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] Agenda for the March 8th call
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2013 04:43:32 -0000

--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151CF690xmbalnx10ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Sure Thomas. 5 minutes should be more than enough.

Thanks
Shitanshu

From: Thomas Watteyne >
Date: Thursday, March 7, 2013 4:47 PM
To: Shitanshu Shah >
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] Agenda for the March 8th call

Shitanshu,

I agree. Could you spend a couple of minutes (max 10) to present this draft=
?

Thanks,
Thomas

On Thu, Mar 7, 2013 at 4:17 PM, Shitanshu Shah (svshah) > wrote:

Hi Pascal

http://datatracker.ietf.org/doc/draft-svshah-tsvwg-lln-diffserv-recommendat=
ions/ looks like may be relevant to your last topic in the agenda.
If so and if agenda permits, I can briefly talk about it.

Cheers,
Shitanshu

From: "Pascal Thubert (pthubert)" >
Date: Thursday, March 7, 2013 8:12 AM
To: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: [6tsch] Agenda for the March 8th call

Dear all,

/!\ DST is next week in the US. Cool thing, there will be no call due to IE=
TF /!\

Introduce terminology draft: 10min (MRP)
Changes in other drafts: 10min (editors)
Agendas for new week meetings: 10 (PT)
DSCPs and priorities / imux/mux: 30 min

As usual, if you wish to add stuff, please let me know how much time you ne=
ed and send slides in advance so I can upload them.

/!\ the call will be recorded and available from Webex /!\

Cheers,

Pascal

From:6tsch-bounces@ietf.org [mailto:6tsch-bo=
unces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: jeudi 7 mars 2013 10:20
To: 6tsch@ietf.org
Subject: [6tsch] Updated Meeting invitation for 6TSCH Weekly Call

Dear all,

We have a consensus that the call can be moved an hour earlier on Fridays.
Please note that following Tom=92s recommendation, the call is now aligned =
to US pacific time for the DST =3D=3D summer time switch.
For instance, twice a year, the time of the call will change by one hour in=
 Europe while it stays consistent in the US.

Cheers,

Pascal

Topic: 6TSCH Weekly
Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 206 802 913
Meeting Password: sixtus


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=
=3DNZTRkNDAwOTE1&RT=3DMiM0
2. Enter your name and email address.
3. Enter the meeting password: sixtus
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkN=
DAwOTE1&ORT=3DMiM0

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access =
Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.88=
24.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002<=
tel:%2B49.619.6773.9002>

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
pthubert@cisco.com
33-49-723 2634

To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&LD=
=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&=
RT=3DMiM0






http://www.webex.com

CCP:+14085256800x206802913#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent to the recording, discuss your concerns =
with the meeting host prior to the start of the recording or do not join th=
e session. Please note that any such recordings may be subject to discovery=
 in the event of litigation.

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



--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151CF690xmbalnx10ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <5817F1A052C9644CAA07306ABB001C16@cisco.com>
Content-Transfer-Encoding: quoted-printable












Sure Thomas. 5 minutes should be more than enough.







Thanks


Shitanshu









From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Thursday, March 7, 2013 4:47 =
PM

To: Shitanshu Shah <svshah@cisco.com>

Cc: "6tsch@ietf.org" <6ts=
ch@ietf.org>

Subject: Re: [6tsch] Agenda for the=
 March 8th call











Shitanshu,






I agree. Could you spend a couple of minutes (max 10) to present this =
draft?







Thanks,


Thomas




On Thu, Mar 7, 2013 at 4:17 PM, Shitanshu Shah (=
svshah) 
<svshah@cisco.com<=
/a>> wrote:











Hi Pascal







http://datatracker.ietf.org/doc/dra=
ft-svshah-tsvwg-lln-diffserv-recommendations/ looks like may be relevan=
t to your last topic in the agenda.


If so and if agenda permits, I can briefly talk about it.







Cheers,


Shitanshu









From: "Pascal Thubert (pthuber=
t)" <pthube=
rt@cisco.com>

Date: Thursday, March 7, 2013 8:12 =
AM

To: "6tsch@ietf.org" <6tsch@ietf.org>

Subject: [6tsch] Agenda for the Mar=
ch 8th call



















Dear all,


 


/!\ DST is next week in the US. Co=
ol thing, there will be no call due to IETF /!\


 


Introduce terminology draft: 10min=
 (MRP)


Changes in other drafts: 10min (ed=
itors)


Agendas for new week meetings: 10 =
(PT)


DSCPs and priorities / imux/mux: 3=
0 min


 


As usual, if you wish to add stuff=
, please let me know how much time you need and send slides in advance so I=
 can upload them.


 


/!\ the call will be recorded and =
available from Webex /!\


 


Cheers,


 




Pascal




 






From:6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org]
On Behalf Of Pascal Thubert (pthubert)

Sent: jeudi 7 mars 2013 10:20

To: 6tsch@ietf.o=
rg

Subject: [6tsch] Updated Meeting invitation for 6TSCH Weekly Call=







 


Dear all,


 


We have a consensus that the call c=
an be moved an hour earlier on Fridays.



Please note that following Tom=92s =
recommendation, the call is now aligned to US pacific time for the DST =3D=
=3D summer time switch.


For instance, twice a year, the tim=
e of the call will change by one hour in Europe while it stays consistent i=
n the US.



 


Cheers,


 


Pascal




Topic: 6TSCH Weekly 

Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014 
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) 

Meeting Number: 206 802 913 

Meeting Password: sixtus 





------------------------------------------------------- 

To join the online meeting (Now from mobile devices!) 

------------------------------------------------------- 

1. Go to 
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=
=3DNZTRkNDAwOTE1&RT=3DMiM0

2. Enter your name and email address. 

3. Enter the meeting password: sixtus 

4. Click "Join Now". 



To view in other time zones or languages, please click the link: 

https://cisco=
.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkNDAwOT=
E1&ORT=3DMiM0



---------------------------------------------------------------- 

ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes 

---------------------------------------------------------------- 



The affected toll free numbers are: 
(866) 432-9903 for the San Jose/Milpitas area and 
(866) 349-3520 for the RTP area. 



Please dial the local access number for your area from the list below: 

- San Jose/Milpitas (408) area: 525-6800 

- RTP (919) area: 392-3330 



------------------------------------------------------- 

To join the teleconference only 

------------------------------------------------------- 

1. Dial into Cisco WebEx (view all Global Access Numbers at 

http://cisco.com/en/US/about/doing_business/conferen=
cing/index.html

2. Follow the prompts to enter the Meeting Number (listed above) or Access =
Code followed by the # sign.




San Jose, CA: 
+1.408.525.6800 RTP: 
+1.919.392.3330 



US/Canada: +1.866.432.9903 United Kingdom:
+44.20.8824.0117



India: +91.80.4350.1111 Germany:
+49.619.6773.9002



Japan: +81.3.5763.9394 China:
+86.10.8515.5666



------------------------------------------------------- 

For assistance 

------------------------------------------------------- 

1. Go to https://cisco.webex.com/ciscosales/mc

2. On the left navigation bar, click "Support". 



You can contact me at: 

pthubert@cisco.com<=
/a> 

33-49-723 2634 



To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:


https:=
//cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&=
amp;LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMu=
Egw1h2pXGIGSMyQEb&RT=3DMiM0













http://www.webex.com=
 



CCP:+14085256800x206802913# 



IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent
 to the recording, discuss your concerns with the meeting host prior to the=
 start of the recording or do not join the session. Please note that any su=
ch recordings may be subject to discovery in the event of litigation.
















_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch



















--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151CF690xmbalnx10ciscoc_--

From twatteyne@gmail.com  Thu Mar  7 23:34:45 2013
Return-Path: 
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 36DE121F85D9 for <6tsch@ietfa.amsl.com>; Thu,  7 Mar 2013 23:34:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level: 
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=0.225,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 hIu-M+-KLyVr for <6tsch@ietfa.amsl.com>; Thu,  7 Mar 2013 23:34:44 -0800 (PST)
Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 759AF21F85D4 for <6tsch@ietf.org>; Thu,  7 Mar 2013 23:34:44 -0800 (PST)
Received: by mail-pa0-f42.google.com with SMTP id kq12so1114786pab.29 for <6tsch@ietf.org>; Thu, 07 Mar 2013 23:34:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=iTHzEy+7mFHeX3wbvU3pcgVmNsocHpVT6aivz3oHN2o=; b=u+ko4/HpHxY+2uyPWxLQsHKST5V+PWaToVG1GeE6qCz5mGqy+kzTBandc2Ug4/xtzQ DLehfGC77CLZgOrH5YktHccFTg0m1NKepPQr1XRBt104txl5k5ooVJIpGK/Buc2uCADR 7m/CfzuFxQAz07qCGShcKi1O3F5Uw/E1sB8shS9jP9iD8XM2bFsIGack36pV2pmeAnk5 zkVNqyj3sUz9DOQKcxK1tpzPoMR+IMoys47dUEk1CkGSoemuWaxMGdVvAoBqMmxWnwbi SqG5/pO+cWLbHhcXrIPEt1b2RjU6V7OXvU+a8zrhCnzbypklwaoEhQv0xIP0i2XHobHn OnPg==
MIME-Version: 1.0
X-Received: by 10.66.227.196 with SMTP id sc4mr2694926pac.38.1362728084279; Thu, 07 Mar 2013 23:34:44 -0800 (PST)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Thu, 7 Mar 2013 23:34:44 -0800 (PST)
Date: Thu, 7 Mar 2013 23:34:44 -0800
X-Google-Sender-Auth: bZ4k9hgNKyDk3PZKx_h-iqBxzpQ
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b15aa8f639c1304d764dbed
Subject: [6tsch] priority and priority
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2013 07:34:45 -0000

--047d7b15aa8f639c1304d764dbed
Content-Type: text/plain; charset=ISO-8859-1

All,

I believe that we have been discussing two different notions of priority:
- *Packet Priority*: Assuming an existing data flow in a network, some
packets are marked as "high priority", the rest as "low priority". All
packets are part of the same flow, but high priority packets are treated
with more urgency that low priority packets. This translates into a set
of queuing rules. This is the notion illustrated by Pascal in his "traffic
lights in a city" analogy (where high priority packets are police cars
passing other vehicles) and used in Qin's mux/i-mux.
- *Flow Priority*, which is slightly different. In a network, multiple
classes of traffic co-exist. This results in multiple data flows. Different
data flows have a different combination of destination, priority, bandwidth
and latency. A network-wide policy defines whether data flows are entirely
independent, or if some over-flowing is allowed. In TSCH, a flow translated
into a slotframe. In case of contention (e.g. at a given slot a mote can
send a packet from each flow), flow priority arbitrates which packet goes
first. Note that this is entirely within the TSCH spec.

These two definitions are complementary: different flows can exist in a
network, but inside a flow, some high priority packets can "pass" other
packets. The network policy defines how those two interact; e.g. a
highest-priority packet can be allowed to "jump" into another flow, if
needed.

We need to define how this materializes in a network. Here is a proposal:

Each data flow turns into a TSCH slotframe. The scheduling entity populates
the slots in the slotframe in such as way that the slots "point to" some
destination. In a typical case, slots in a slotframe are equivalent: to end
up at mote A, take any slot in slotframe 1. This allows us to use
label-switching approach, which I'm sure will pop up in some future draft.
We can end up with different slotframes for different destinations, or for
different types of traffic to the same destination.

Optionally, packets can contain some priority field (probably DSCP, as per
http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-recommendations-00?)
which serves as the "high priority" marker. A policy then regulates how
this translates to queuing and flow equivalence rules.

DSCP can also be used by the higher layer to indicate to which flow this
packet pertains, and with what (optional) priority. Upon receiving a packet
from a higher layer, the 6tsch layer could inspect the DSCP and some set of
rules would tell him which flow to send it on. Once it is in a flow, the
full DSCP is not needed, and there is lots of opportunity to elide some
information while the packet is on the LLN. I'm hoping that Shitanshu a.o.
can help decide on the applicability of this.

Thomas

--047d7b15aa8f639c1304d764dbed
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

All,

I believe that we have been discussing two differen=
t notions of priority:
- Packet=A0Priority: Assuming an ex=
isting data flow in a network, some packets are marked as "high priori=
ty", the rest as "low priority". All packets are part of the=
 same flow, but high priority packets are treated with more urgency that lo=
w priority packets. This translates into a set of=A0queuing=A0rules. This i=
s the notion illustrated by Pascal in his "traffic lights in a city&qu=
ot; analogy (where high priority packets are police cars passing other vehi=
cles) and used in Qin's mux/i-mux.



- Flow=A0Priority, which is=A0slightly different. In a network,=
 multiple classes of traffic co-exist. This results in multiple data flows.=
 Different data flows have a different combination of destination, priority=
, bandwidth and latency. A network-wide policy defines whether data flows a=
re entirely independent, or if some over-flowing is allowed. In TSCH, a flo=
w translated into a slotframe. In case of contention (e.g. at a given slot =
a mote can send a packet from each flow), flow priority arbitrates which pa=
cket goes first. Note that this is entirely within the TSCH spec.




These two definitions are complementary: different flow=
s can exist in a network, but inside a flow, some high priority packets can=
 "pass" other packets. The network policy defines how those two i=
nteract; e.g. a highest-priority packet can be allowed to "jump" =
into another flow, if needed.




We need to define how this materializes in a network. H=
ere is a proposal:

Each data flow turns into a TSC=
H slotframe. The scheduling entity populates the slots in the slotframe in =
such as way that the slots "point to" some destination. In a typi=
cal case, slots in a slotframe are equivalent: to end up at mote A, take an=
y slot in slotframe 1. This allows us to use label-switching approach, whic=
h I'm sure will pop up in some future draft. We can end up with differe=
nt slotframes for different destinations, or for different types of traffic=
 to the same destination.




Optionally, packets can contain some priority field (pr=
obably=A0DSCP, as per=A0http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-recommendations=
-00?) which serves as the "high priority" marker. A policy th=
en regulates how this translates to queuing and flow equivalence rules.


DSCP can also be used by the higher layer to indicate t=
o which flow this packet pertains, and with what (optional) priority. Upon =
receiving a packet from a higher layer, the 6tsch layer could inspect the D=
SCP and some set of rules would tell him which flow to send it on. Once it =
is in a flow, the full DSCP is not needed, and there is lots of opportunity=
 to elide some information while the packet is on the LLN. I'm hoping t=
hat=A0Shitanshu a.o. can help decide on the applicability of this.



Thomas


--047d7b15aa8f639c1304d764dbed--

From alfredo.grieco@gmail.com  Fri Mar  8 00:56:17 2013
Return-Path: 
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 6C58621F8629 for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 00:56:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 MSVEw88HjA1f for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 00:56:16 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E583E21F85A4 for <6tsch@ietf.org>; Fri,  8 Mar 2013 00:56:15 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id dr12so2160221wgb.23 for <6tsch@ietf.org>; Fri, 08 Mar 2013 00:56:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=7Ubj4BTfeDok7cFjLsT1lGyMLOTXkKskS1r7T8uC+Gw=; b=SCwESAF0Hg1nLBep/ZLdeKkIQTZnvS/S6DHogbzwnljm87eN9SfpryRHy6EfrKe6wG P5gJ6/xNDzuHuQw1gX9Dez0Yw72uMMeHKhxAzdLRLFjgKb6I3j4E+R+YIyUkexYmlN+f LrqTtkzVjumOYBnccU9XHNb/SVU5W97+TQum0yf6iVk7YwNEnbs6Lopbt3KMfdu7Ae7K 19NJieFZCwaZb3PJrV3TyWFdgA1HBdon+EEU4/G9hBQot/jzHxTZsRMfYiV9vVOvJOMX Upkib2Ar1oSfTGudcfr/WYh4TctjRlTbbjPXPjM6dwg9GgOvkLuA13OnidFzyQeL2bZE 9o/w==
X-Received: by 10.194.120.169 with SMTP id ld9mr2231719wjb.24.1362732975010; Fri, 08 Mar 2013 00:56:15 -0800 (PST)
Received: from GriecoPC ([131.254.253.108]) by mx.google.com with ESMTPS id ex15sm37957534wid.5.2013.03.08.00.56.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 Mar 2013 00:56:14 -0800 (PST)
From: "Alfredo Grieco" 
To: "'Thomas Watteyne'" , "'IETF 6TSCH'" <6tsch@ietf.org>
References: 
In-Reply-To: 
Date: Fri, 8 Mar 2013 09:56:11 +0100
Message-ID: <5139a7ae.6f0db50a.1fa0.ffffce49@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01CE1BE3.2AD8F1F0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac4bz2qL7wv9hfiyQSeqk6DZ5dnGXwACrnjw
Content-Language: en-us
Subject: [6tsch] R:  priority and priority
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2013 08:56:17 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_008F_01CE1BE3.2AD8F1F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Thomas and all,
 
I think that the adoption of label switching approaches is totally
appropriate in this context and can help solving several issues, including
priority.
 
As a matter of fact, the label (as in MPLS) can encode many different
properties: priority, destination node, kind of application, and whatever we
want.
 
The point is we should adopt some lightweight label dissemination mechanism
for the LLN context, but I am sure that approaches based on RSVP (one among
others) could surely fit well.
 
Cheers
 
Alfredo
 
Da: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] Per conto di
Thomas Watteyne
Inviato: Friday, March 08, 2013 8:35 AM
A: IETF 6TSCH
Oggetto: [6tsch] priority and priority
 
All,
 
I believe that we have been discussing two different notions of priority:
- Packet Priority: Assuming an existing data flow in a network, some packets
are marked as "high priority", the rest as "low priority". All packets are
part of the same flow, but high priority packets are treated with more
urgency that low priority packets. This translates into a set of queuing
rules. This is the notion illustrated by Pascal in his "traffic lights in a
city" analogy (where high priority packets are police cars passing other
vehicles) and used in Qin's mux/i-mux.
- Flow Priority, which is slightly different. In a network, multiple classes
of traffic co-exist. This results in multiple data flows. Different data
flows have a different combination of destination, priority, bandwidth and
latency. A network-wide policy defines whether data flows are entirely
independent, or if some over-flowing is allowed. In TSCH, a flow translated
into a slotframe. In case of contention (e.g. at a given slot a mote can
send a packet from each flow), flow priority arbitrates which packet goes
first. Note that this is entirely within the TSCH spec.
 
These two definitions are complementary: different flows can exist in a
network, but inside a flow, some high priority packets can "pass" other
packets. The network policy defines how those two interact; e.g. a
highest-priority packet can be allowed to "jump" into another flow, if
needed.
 
We need to define how this materializes in a network. Here is a proposal:
 
Each data flow turns into a TSCH slotframe. The scheduling entity populates
the slots in the slotframe in such as way that the slots "point to" some
destination. In a typical case, slots in a slotframe are equivalent: to end
up at mote A, take any slot in slotframe 1. This allows us to use
label-switching approach, which I'm sure will pop up in some future draft.
We can end up with different slotframes for different destinations, or for
different types of traffic to the same destination.
 
Optionally, packets can contain some priority field (probably DSCP, as per
http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-recommendations-0
0?) which serves as the "high priority" marker. A policy then regulates how
this translates to queuing and flow equivalence rules.
 
DSCP can also be used by the higher layer to indicate to which flow this
packet pertains, and with what (optional) priority. Upon receiving a packet
from a higher layer, the 6tsch layer could inspect the DSCP and some set of
rules would tell him which flow to send it on. Once it is in a flow, the
full DSCP is not needed, and there is lots of opportunity to elide some
information while the packet is on the LLN. I'm hoping that Shitanshu a.o.
can help decide on the applicability of this.
 
Thomas

------=_NextPart_000_008F_01CE1BE3.2AD8F1F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Dear Thomas and =
all,
 
I think that the adoption of =
label switching approaches is totally appropriate in this context and =
can help solving several issues, including =
priority.
 
As a matter of fact, the label =
(as in MPLS) can encode many different properties: priority, destination =
node, kind of application, and whatever we =
want.
 
The point is we should adopt =
some lightweight label dissemination mechanism for the LLN context, but =
I am sure that approaches based on RSVP (one among others) could surely =
fit well.
 
Cheers
 
Alfredo
 
Da: 6tsch-bounces@ietf.org =
[mailto:6tsch-bounces@ietf.org] Per =
conto di Thomas Watteyne
Inviato: Friday, March 08, 2013 =
8:35 AM
A: IETF =
6TSCH
Oggetto: [6tsch] =
priority and priority
 
All,
 
=

I believe that we have been discussing two =
different notions of priority:
- Packet Priority: Assuming an =
existing data flow in a network, some packets are marked as "high =
priority", the rest as "low priority". All packets are =
part of the same flow, but high priority packets are treated with more =
urgency that low priority packets. This translates into a set =
of queuing rules. This is the notion illustrated by Pascal in =
his "traffic lights in a city" analogy (where high priority =
packets are police cars passing other vehicles) and used in Qin's =
mux/i-mux.
- Flow Priority, which =
is slightly different. In a network, multiple classes of traffic =
co-exist. This results in multiple data flows. Different data flows have =
a different combination of destination, priority, bandwidth and latency. =
A network-wide policy defines whether data flows are entirely =
independent, or if some over-flowing is allowed. In TSCH, a flow =
translated into a slotframe. In case of contention (e.g. at a given slot =
a mote can send a packet from each flow), flow priority arbitrates which =
packet goes first. Note that this is entirely within the TSCH =
spec.
 
=

These two definitions are complementary: =
different flows can exist in a network, but inside a flow, some high =
priority packets can "pass" other packets. The network policy =
defines how those two interact; e.g. a highest-priority packet can be =
allowed to "jump" into another flow, if =
needed.
 
=

We need to define how this materializes in a =
network. Here is a proposal:
 
=

Each data flow turns into a TSCH slotframe. =
The scheduling entity populates the slots in the slotframe in such as =
way that the slots "point to" some destination. In a typical =
case, slots in a slotframe are equivalent: to end up at mote A, take any =
slot in slotframe 1. This allows us to use label-switching approach, =
which I'm sure will pop up in some future draft. We can end up with =
different slotframes for different destinations, or for different types =
of traffic to the same =
destination.
 
=

Optionally, packets can contain some priority =
field (probably DSCP, as per http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-=
recommendations-00?) which serves as the "high priority" =
marker. A policy then regulates how this translates to queuing and flow =
equivalence rules.
 
=

DSCP can also be used by the higher layer to =
indicate to which flow this packet pertains, and with what (optional) =
priority. Upon receiving a packet from a higher layer, the 6tsch layer =
could inspect the DSCP and some set of rules would tell him which flow =
to send it on. Once it is in a flow, the full DSCP is not needed, and =
there is lots of opportunity to elide some information while the packet =
is on the LLN. I'm hoping that Shitanshu a.o. can help decide on =
the applicability of this.
 
=

Thomas

------=_NextPart_000_008F_01CE1BE3.2AD8F1F0--


From twatteyne@gmail.com  Fri Mar  8 09:40:14 2013
Return-Path: 
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 0D58E21F8756 for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 09:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.776
X-Spam-Level: 
X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 dKla90kziCea for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 09:40:12 -0800 (PST)
Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9E12421F874E for <6tsch@ietf.org>; Fri,  8 Mar 2013 09:40:12 -0800 (PST)
Received: by mail-pb0-f51.google.com with SMTP id un15so1392982pbc.10 for <6tsch@ietf.org>; Fri, 08 Mar 2013 09:40:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=YmUoOCXSxDlWudPii+y/qNkpWq3/Ywvq7n4js7YyeB4=; b=v+S7qudYRtT6XYgM1Ope2H8VY8tvfkjrfl9VRG+bPsQCvX/Izp1uSvVR+OmwDICrEH TunuESXnp99XLh3hfDmPCyKDlHe7hdMx2Xi005WncTnkuZEaVV9OOGPDdGcCeOuD7c6X UqARot0Z8yJfmsEsAHyCFPBFVO0NPJAtrcngjD77ZB2OZFTtXpXuhTf2s70IIXPnlSUb 9k3QOnxw+O7WXLrWsTzdqn8QGh5SgXEQBcBanC0mGqrVippkMrnLbOGB1C+ThxuAlE9I 54Jm5iVlVWjSV5IOTfy9NO+U1j38a9Dyev3sNrnZhqzrsDeRguXNiIkj1wmlBt541i46 tr0g==
MIME-Version: 1.0
X-Received: by 10.68.137.161 with SMTP id qj1mr4599785pbb.168.1362764411804; Fri, 08 Mar 2013 09:40:11 -0800 (PST)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Fri, 8 Mar 2013 09:40:11 -0800 (PST)
Date: Fri, 8 Mar 2013 09:40:11 -0800
X-Google-Sender-Auth: ZfCULXUEs5W-lkirWEoshiN1ovg
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b2e42a6ae5bde04d76d504e
Subject: [6tsch] minutes WebEx 8 March 2013
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2013 17:40:14 -0000

--047d7b2e42a6ae5bde04d76d504e
Content-Type: text/plain; charset=ISO-8859-1

All,
Notes of today's meeting below. Please correct inline and reply.
Thomas

---

*** Timestamps in PST. ***

Present:
- Herman Storey
- Maria Rita Palattella
- Norman Finn
- Pascal Thubert
- Qin Wang
- Shitanshu Shah
- Thomas Watteyne
- Tina Tsou
- Tom Phinney
- Xavi Vilajosana

Agenda:
- Introduction to the terminology draft [10min] [Maria Rita]
- Diffserv Recommendations for LLN class of traffic [5min] [Shitanshu]
   -
http://datatracker.ietf.org/doc/draft-svshah-tsvwg-lln-diffserv-recommendations/
- Agenda for new week meetings [10min] [Pascal]
- Changes in other drafts [10min]
   - draft-watteyne-6tsch-tsch-lln-context [Thomas]
   - draft-wang-6tsch-6tus [Qin]
   - draft-thubert-6tsch-architecture [Pascal]
- Mailing list discussions [30min]
   - DSCPs and priorities [Thomas]
   - imux/mux [Qin]

Minutes:
- [08.04] meeting starts
- [08.05] Introduction to the new terminology draft [Maria Rita]
   - [Pascal] This draft extends ROLL and autoconf terminology, which are
included as references.
   - [Maria Rita] Presents slides.
   - [Maria Rita] draft was triggered by the fact that "link" and "path"
have different meaning in TSCH and IETF parlance.
   - [Maria Rita] "Cell": Single element in the TSCH schedule. Replaces
"link" term in TSCH.
   - [Maria Rita] "Bundle": A group of equivalent scheduled cells. Replaces
(although not exactly) "path" term in TSCH.
   - [Maria Rita] Draft there to avoid confusion, we will include other
terms as work progresses.
   - [Maria Rita] Draft will be published on Monday.
- [08.14] Diffserv Recommendations for LLN class of traffic [Shitanshu]
   - draft at
http://datatracker.ietf.org/doc/draft-svshah-tsvwg-lln-diffserv-recommendations/
   - Shitanshu presents slides.
   - Context: this draft was presented at the last IETF meeting in Atlanta.
   - Goal: using Diffserv in context of LLN
   - Motivation: RFC4594 is well documented recommendation for traditional
classes of traffic. Yet, does not cover LLN. What this draft does it:
      - categorize LLN
      - lists explicit recommendations for LLN
      - always keeping RFC4594 as a reference
   - source points to mark appropriate DSCP code point
   - LLN Traffic Classes identified from ROLL requirement drafts
      - 6 categories: alerts/alarms, control signals, deterministic control
signals, Video Monitoring/feed, Query-based data, Periodic Reporting/log &
software downloads.
      - each class characterized in terms of loss, delay and jitter. Some
classes are different from RFC4594, justifying the need for this new draft.
Example: deterministic control signals.
   - [Tom] Alerts/Alarms traffic are bursty because multiple network
elements can signal the same physical events (e.g. explosion).
   - [Herman] You don't want to loose any alert/alarm packets
   - [Shitanshu] Agreed, will update draft.
   - [Herman] Is there a class for network management?
   - [Pascal] In some cases, network control needs to be the highest
priority since network falls apart when no network control packets can be
transmitted.
   - [Pascal] DSCP will play key role in packet priority. There is no DSCP
for flow priority.
   - [Pascal] PHB means "per hop behavior"
   - [Shitanshu] Draft proposed code-point EF
   - [Herman] Why are emergency action outside of IP networks?
   - [Shitanshu] Other techniques are used which are not IP.
   - [Herman] There are IP-based solutions. Operate as dedicated network,
not connected to complete Internet (non routable subnet), but use IP
address.
   - [Shitanshu] We can remove the term IP.
- [08.35] Agenda for new week meetings [Pascal]
   - Tuesday (Caribbean 2):
      - admin
         - we will have 5-10min during the ROLL meeting to present 6tsch
         - 6tsch meeting follows ROLL meeting, same room
         - we need to leave 15min before end to set up next meeting, so we
will really only have one hour.
         - we will have projector, not clear whether we will be able to
provide live online feed.
      - Goal: prepare for successful BoF in Berlin
      - Scope: the backbone with PCE (Path Computation Entity) and one or
more LLN running 6LoWPAN, 6TSCH, RPL.
      - we use draft-phinney-roll-rpl-industrial-applicability as a
starting point.
      - goals and deliverables:
         - informational: LLN context, architecture, terminology
         - new: 6tus, protocol for reserving track
         - adapt existing: OF for RPL, fragment forwarding (problems
because don't have DSCP)
         - extern docs: backbone router (from 6MAN), PCE (is a WG, need to
coordinate)
      - dependencies and liaison:
         - IEEE 802.1TSN (Norman)
         - ISA100.20 are defining arbstraction for management layer to
manage the managers (e.g. blacklist channels). We could use same formats.
         - IoT6. European project. They use very similar architecture as
ours.
   - Wednesday (Boca 2)
      - admin:
         - in Boca 2, which we can stay in past 1pm.
      - we will go over different drafts
         - draft-phinney-roll-rpl-industrial-applicability.
            - published at
http://tools.ietf.org/html/draft-phinney-roll-rpl-industrial-applicability-02
            - [Tom] Analysis of classifications of types of communications
that occur. Applies to all automation systems, worked out over years by
many people.
            - [Pascal] Good source of inspiration.
         - draft-watteyne-6tsch-tsch-lln-context
            - published at
http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01
            - [Thomas] do not expect -02 for Orlando, but will need
rewording for new terminology.
         - draft-wang-6tsch-6tus
            - [Pascal] Caution, we cannot reinvent MPLS.
            - [Xavi] will be published on Monday.
         - draft-palattella-6tsch-terminology
            - see presentation above
            - will be published on Monday.
         - draft-thubert-6tsch-architecture
            - [Pascal] will be work-in-progress for a long time, since
incorporates changes/concepts from other drafts.
            - [Pascal] More text to follow: network synchronization, 6tus,
management, etc.
            - [Thomas] Can be seen a index for other drafts, could serve as
first draft to read when familiarizing with 6tsch.
- [08.55] Priority discussion
   - [Thomas] We don't have much time left, so instead of starting
discussion, will prepare slides for Wednesday meeting.
   - [Pascal] Will add slot for Wednesday meeting.
   - [Pascal] Pascal will meet with Shitanshu on Monday morning, Thomas
will meet with Pascal on Monday evening and Tuesday.
- [10.00]
   - [Thomas] Will be meeting stay at this time?
   - [Tom,Pascal] For the moment yes
   - [Pascal] There is not call next week because of IETF meeting.
- [10.05] Meeting ends.

--047d7b2e42a6ae5bde04d76d504e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


All,

Notes of today's meeting below. Please correct inline and reply.
<=
div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13p=
x;background-color:rgb(255,255,255)">Thomas


---



*=
** Timestamps in PST. ***

Present:


- Herman Store=
y
=
- Maria Rita Palattella
- Norman Finn


- Pascal Thube=
rt
- Qin Wang
- Shitanshu Shah


- Thomas Watte=
yne
- Tom Phinney


- Xavi Vilajos=
ana
Agenda:


- Introduction=
 to the terminology draft [10min] [Maria Rita]
- Diffserv Recommendations for=
 LLN class of traffic [5min] [Shitanshu]



- Agenda for n=
ew week meetings [10min] [Pascal]
- Changes in other drafts [10min]

=A0 =A0- draft-watt=
eyne-6tsch-tsch-lln-context [Thomas]
=A0 =A0- draft-wang-6tsch-6tus [Qin]

=A0 =A0- draft-thub=
ert-6tsch-architecture [Pascal]
- Mailing list discussions [30min]
=A0 =A0- DSC=
Ps and priorities [Thomas]


=A0 =A0- imux/=
mux [Qin]

Minutes:


- [08.04] meet=
ing starts
- [08.05] Introduction to the new terminology draft [Maria Rita]


=A0 =A0- [Pasc=
al] This draft extends ROLL and autoconf terminology, which are included as=
 references.
=A0 =A0- [Maria Rita] Presents slides.


=A0 =A0- [Mari=
a Rita] draft was triggered by the fact that "link" and "pat=
h" have different meaning in TSCH and IETF parlance.
=
=A0 =A0- [Maria Rit=
a] "Cell": Single element in the TSCH schedule. Replaces "li=
nk" term in TSCH.


=A0 =A0- [Mari=
a Rita] "Bundle": A group of equivalent scheduled cells. Replaces=
 (although not exactly) "path" term in TSCH.
=A0 =A0- [Maria Rita] =
Draft there to avoid confusion, we will include other terms as work progres=
ses.


=A0 =A0- [Mari=
a Rita] Draft will be published on Monday.
- [08.14] Diffserv Recommendations=
 for LLN class of traffic [Shitanshu]



=A0 =A0- Shita=
nshu presents slides.
=A0 =A0- Context: this draft was presented at the last =
IETF meeting in Atlanta.


=A0 =A0- Goal:=
 using Diffserv in context of LLN
=A0 =A0- Motivation: RFC4594 is well docume=
nted recommendation for traditional classes of traffic. Yet, does not cover=
 LLN. What this draft does it:


=A0 =A0 =A0 - =
categorize LLN
=A0 =A0 =A0 - lists explicit recommendations for LLN
=A0 =A0 =A0=
 - always keeping RFC4594 as a reference


=A0 =A0- sourc=
e points to mark appropriate DSCP code point
=A0 =A0- LLN Traffic Classes i=
dentified from ROLL requirement drafts


=A0 =A0 =A0 - =
6 categories: alerts/alarms, control signals, deterministic control signals=
, Video Monitoring/feed, Query-based data, Periodic Reporting/log & sof=
tware downloads.


=A0 =A0 =A0 - =
each class characterized in terms of loss, delay and jitter. Some classes a=
re different from RFC4594, justifying the need for this new draft. Example:=
 deterministic control signals.


=A0 =A0- [Tom]=
 Alerts/Alarms traffic are bursty because multiple network elements can sig=
nal the same physical events (e.g. explosion).
=A0 =A0- [Herman] You don'=
t want to loose any alert/alarm packets


=A0 =A0- [Shit=
anshu] Agreed, will update draft.
=A0 =A0- [Herman] Is there a class for netw=
ork management?


=A0 =A0- [Pasc=
al] In some cases, network control needs to be the highest priority since n=
etwork falls apart when no network control packets can be transmitted.


=A0 =A0- [Pasc=
al] DSCP will play key role in packet priority. There is no DSCP for flow p=
riority.
=A0 =A0- [Pascal] PHB means "per hop behavior"

=A0 =A0- [Shit=
anshu] Draft proposed code-point EF
=A0 =A0- [Herman] Why are emergency actio=
n outside of IP networks?


=A0 =A0- [Shit=
anshu] Other techniques are used which are not IP.
=A0 =A0- [Herman] There ar=
e IP-based solutions. Operate as dedicated network, not connected to comple=
te Internet (non routable subnet), but use IP address.


=A0 =A0- [Shit=
anshu] We can remove the term IP.
- [08.35] Agenda for new week meetings [Pas=
cal]


=A0 =A0- Tuesd=
ay (Caribbean 2):
=A0 =A0 =A0 - admin
=A0 =A0 =A0 =A0 =A0- we will have 5-10min=
 during the ROLL meeting to present 6tsch


=A0 =A0 =A0 =
=A0 =A0- 6tsch meeting follows ROLL meeting, same room
=A0 =A0 =A0 =A0 =A0- w=
e need to leave 15min before end to set up next meeting, so we will really =
only have one hour.


=A0 =A0 =A0 =
=A0 =A0- we will have projector, not clear whether we will be able to provi=
de live online feed.
=A0 =A0 =A0 - Goal: prepare for successful BoF in Berlin=



=A0 =A0 =A0 - =
Scope: the backbone with PCE (Path Computation Entity) and one or more LLN =
running 6LoWPAN, 6TSCH, RPL.
=A0 =A0 =A0 - we use draft-phinney-roll-rpl-ind=
ustrial-applicability as a starting point.


=A0 =A0 =A0 - =
goals and deliverables:
=A0 =A0 =A0 =A0 =A0- informational: LLN context, arch=
itecture, terminology


=A0 =A0 =A0 =
=A0 =A0- new: 6tus, protocol for reserving track
=A0 =A0 =A0 =A0 =A0- adapt e=
xisting: OF for RPL, fragment forwarding (problems because don't have D=
SCP)


=A0 =A0 =A0 =
=A0 =A0- extern docs: backbone router (from 6MAN), PCE (is a WG, need to co=
ordinate)
=A0 =A0 =A0 - dependencies and liaison:


=A0 =A0 =A0 =
=A0 =A0- IEEE 802.1TSN (Norman)
=A0 =A0 =A0 =A0 =A0- ISA100.20 are defining a=
rbstraction for management layer to manage the managers (e.g. blacklist cha=
nnels). We could use same formats.


=A0 =A0 =A0 =
=A0 =A0- IoT6. European project. They use very similar architecture as ours=
.
=
=A0 =A0- Wednesday (Boca 2)


=A0 =A0 =A0 - =
admin:
=A0 =A0 =A0 =A0 =A0- in Boca 2, which we can stay in past 1pm.<=
/div>
=A0 =A0 =
=A0 - we will go over different drafts


=A0 =A0 =A0 =
=A0 =A0- draft-phinney-roll-rpl-industrial-applicability.


=A0 =A0 =A0 =
=A0 =A0 =A0 - [Tom] Analysis of classifications of types of communications =
that occur. Applies to all automation systems, worked out over years by man=
y people.


=A0 =A0 =A0 =
=A0 =A0 =A0 - [Pascal] Good source of inspiration.
=A0 =A0 =A0 =A0 =A0- draft=
-watteyne-6tsch-tsch-lln-context



=A0 =A0 =A0 =
=A0 =A0 =A0 - [Thomas] do not expect -02 for Orlando, but will need rewordi=
ng for new terminology.
=A0 =A0 =A0 =A0 =A0- draft-wang-6tsch-6tus

=A0 =A0 =A0 =
=A0 =A0 =A0 - [Pascal] Caution, we cannot reinvent MPLS.
<=
font color=3D"#222222" face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =A0 =
=A0 - [Xavi] will be published on Monday.


=A0 =A0 =A0 =
=A0 =A0- draft-palattella-6tsch-terminology
=A0 =A0 =A0 =A0 =A0 =A0 - see pre=
sentation above


=A0 =A0 =A0 =
=A0 =A0 =A0 - will be published on Monday.
=A0 =A0 =A0 =A0 =A0- draft-thubert=
-6tsch-architecture


=A0 =A0 =A0 =
=A0 =A0 =A0 - [Pascal] will be work-in-progress for a long time, since inco=
rporates changes/concepts from other drafts.
=A0 =A0 =A0 =A0 =A0 =A0 - [Pas=
cal] More text to follow: network synchronization, 6tus, management, etc.


=A0 =A0 =A0 =
=A0 =A0 =A0 - [Thomas] Can be seen a index for other drafts, could serve as=
 first draft to read when familiarizing with 6tsch.
- [08.55] Priority discus=
sion


=A0 =A0- [Thom=
as] We don't have much time left, so instead of starting discussion, wi=
ll prepare slides for Wednesday meeting.
=A0 =A0- [Pascal] Will add slot for =
Wednesday meeting.


=A0 =A0- [Pasc=
al] Pascal will meet with Shitanshu on Monday morning, Thomas will meet wit=
h Pascal on Monday evening and Tuesday.
- [10.00]


=A0 =A0- [Thom=
as] Will be meeting stay at this time?
=A0 =A0- [Tom,Pascal] For the moment y=
es


=A0 =A0- [Pasc=
al] There is not call next week because of IETF meeting.
<=
font color=3D"#222222" face=3D"courier new, monospace">- [10.05] Meeting en=
ds.




--047d7b2e42a6ae5bde04d76d504e--

From twatteyne@gmail.com  Fri Mar  8 09:57:43 2013
Return-Path: 
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 2F7A921F87D7 for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 09:57:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level: 
X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=0.180,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 OIrb0DSHslRK for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 09:57:42 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5186E21F8745 for <6tsch@ietf.org>; Fri,  8 Mar 2013 09:57:42 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id wz12so1416747pbc.17 for <6tsch@ietf.org>; Fri, 08 Mar 2013 09:57:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=WteRZXm7U+8OpD34SjpBO3MBUA/8+KFtByUObzX+U74=; b=j2RDT2YRPoWqkd2y6VNQfBSM2Bng7RvXYF1H9XHuyiJPLP3C8jO8lSrP+t7+ulIkZg l9RKQlVLJ6DthvZhcr52yA87/S3V2MYeTX43tNVLu032UzNQ7O/tm4S3ZDG+smcHCzkn 3daPYhWKIslB75vA0cR7itcCEnFLBWut4mpVie7PuQSuaXG1My3X3gye4JpKZcdNcsX7 0yi/uF+l3giAH/7W4s6eUm/xiX73YZ5z83/WyyQIdorn7L/fxSDLTTipMiTTv7Nby+vN 019wphTISZ1/EPr3yjth1eeFzZvYcAd9mbRdtp9o0cN6L8xXZPmpVNGlwTneEZKd5cgO n/Hw==
MIME-Version: 1.0
X-Received: by 10.68.248.74 with SMTP id yk10mr4725800pbc.38.1362765461314; Fri, 08 Mar 2013 09:57:41 -0800 (PST)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Fri, 8 Mar 2013 09:57:41 -0800 (PST)
In-Reply-To: <11629.1362765364@sandelman.ca>
References: <11629.1362765364@sandelman.ca>
Date: Fri, 8 Mar 2013 09:57:41 -0800
X-Google-Sender-Auth: 24GbbVwqkzyNof3thSdrH_fy5VM
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/mixed; boundary=047d7b2e0a173cbccd04d76d8f8a
Subject: [6tsch] Fwd: [Roll] DRAFT agenda for 2013-03-12 09:00
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2013 17:57:43 -0000

--047d7b2e0a173cbccd04d76d8f8a
Content-Type: multipart/alternative; boundary=047d7b2e0a173cbcca04d76d8f88

--047d7b2e0a173cbcca04d76d8f88
Content-Type: text/plain; charset=ISO-8859-1

For those of you who are not on the ROLL ML.

---------- Forwarded message ----------
From: Michael Richardson 
Date: Fri, Mar 8, 2013 at 9:56 AM
Subject: [Roll] DRAFT agenda for 2013-03-12 09:00
To: roll@ietf.org



This is still subject to change.

It has been uploaded at 12:55, but I think that there is a delay before
it shows up in the meeting materials.

1) Note Well    and Agenda Bashing      (09:00 - 5min)
2) Document status                      (09:05 - 10min)
   - what document is there.
3) Applicability Statements
   - industrial                         (09:15 - 10min)
   - home/building                      (09:25 - 10min)
   - metering/AMI                       (09:35 - 10min)
4) discussion/question: do applicability statements stand alone? (09:45 -
15min)
5) 6TSCH summary/invite                 (10:00 - 10min)



--
Michael Richardson
-on the road-



_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--047d7b2e0a173cbcca04d76d8f88
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

For those of you who are not on the ROLL ML.

---------- Forwarded message ----------
From: Michael Richardson <mcr+ietf@sandelman.ca>

Date: Fri, Mar 8, 2013 at 9:56 AM
Subject: [Roll] DRAFT agenda for 2013-=
03-12 09:00
To: roll@ietf.org



This is still subject to change.



It has been uploaded at 12:55, but I think that there is a delay before

it shows up in the meeting materials.



1) Note Well =A0 =A0and Agenda Bashing =A0 =A0 =A0(09:00 - 5min)

2) Document status =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(09:05 - 10mi=
n)

=A0 =A0- what document is there.

3) Applicability Statements

=A0 =A0- industrial =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (09:15 =
- 10min)

=A0 =A0- home/building =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(09:25 - =
10min)

=A0 =A0- metering/AMI =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (09:35 - =
10min)

4) discussion/question: do applicability statements stand alone? (09:45 - 1=
5min)

5) 6TSCH summary/invite =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (10:00 - 10min)







--

Michael Richardson

-on the road-






_______________________________________________

Roll mailing list

Roll@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/roll





--047d7b2e0a173cbcca04d76d8f88--
--047d7b2e0a173cbccd04d76d8f8a
Content-Type: application/pgp-signature
Content-Disposition: attachment
Content-Transfer-Encoding: base64
X-Attachment-Id: c55db991d0cb0a30_0.0.1

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTAgKEdO
VS9MaW51eCkNCg0KaVFFY0JBQUJBZ0FHQlFKUk9pWTBBQW9KRUtEMEtRN0dqM1AyblJvSUFKdWFv
a0RoVTA2TW44RWpMbG1JMXJOaQ0KQitJeW1ZbUFZc1g1cklBNmN2MEx2UXNnekNueEk4RnM2alhr
bEdLZmFCYUxoUnJCVW1aQ21kdzUrY3ZVWkpHZw0KbFN1eGx6ZFZwNkZlRHZmNzRoYmVJNGc1ajJV
VUorcEZ5bUhNREMzZlV1aUNqcjJ3Y004RnVrUXUxelN3Lzl5eQ0KK0ZIYnRzWjJ6MGpRRXJHRVo1
TG54cTEwM3Z4bG1WZVV0cHhrV1hkNjdtVVJvTnJ3ZlJKM1cyc2NEMVlJWDVEUA0KMm54RUk1aUQ2
MENnclAvUmRWdnNwM3lvZjhWZFg1YjQwZGZqRzVOOVJ6bzdrVWZ1QVlscW83Wk5ndEhySis4SQ0K
KzVWcnVVQXI1eGFhMEY2cEUxK0NlQWpuUjcxbXYyQ2d5Q1VKVEluQlFEMHlPL3RPVjU3dDR0Rk9l
RGNjaDFvPQ0KPWx4TTgNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ==
--047d7b2e0a173cbccd04d76d8f8a--

From pthubert@cisco.com  Fri Mar  8 10:00:44 2013
Return-Path: 
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 EB3E421F8751 for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 10:00:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.265
X-Spam-Level: 
X-Spam-Status: No, score=-11.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3N6Y2n5B1d7q for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 10:00:39 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C294D21F862A for <6tsch@ietf.org>; Fri,  8 Mar 2013 10:00:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39354; q=dns/txt; s=iport; t=1362765638; x=1363975238; h=from:to:subject:date:message-id:mime-version; bh=7AqpD/DX/7WRyAu/yk9ZA71vjr08T3fnsIVi1p2r2tw=; b=KjcPhJ0fvm9Lg0L8jFMGk1s/XIt3iZj7Q1MNON2n0Qfe+t0HUXEpmOlM b/F1aBuZc1mmlmub/KxM22NDK7jyR9M+ZADvekMuDUIIq2ay8ySK+9ank ZiSGBdLKoDIul+wxyTCNxjHin3ORKMog5vhuH+WqsdqTYTUX3BuPHXZY4 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtQFAL0mOlGtJV2Y/2dsb2JhbAApGg6EBa5oiSYBiCyBWxZ0giwBAQEELUEdARkBAwEBCxYBBjkUAwYJAQQBEggTh3gMLrpnjlsmBwqCYGEDl3GPVIJLP4In
X-IronPort-AV: E=Sophos;i="4.84,809,1355097600";  d="scan'208,217";a="182418691"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 08 Mar 2013 18:00:38 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r28I0bpV001365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Mar 2013 18:00:37 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 12:00:37 -0600
From: "Pascal Thubert (pthubert)" 
To: Thomas Watteyne , IETF 6TSCH <6tsch@ietf.org>
Thread-Topic: Recording of WebEx 8 March 2013
Thread-Index: Ac4cJqoHrr0o9aCGQV6RNiA9Xw+CqA==
Date: Fri, 8 Mar 2013 18:00:36 +0000
Deferred-Delivery: Fri, 8 Mar 2013 18:00:00 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.84.15]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835CF1F81xmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: [6tsch] Recording of WebEx 8 March 2013
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2013 18:00:45 -0000

--_000_E045AECD98228444A58C61C200AE1BD835CF1F81xmbrcdx01ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Thomas:

I had an error coming from the recording so I stopped it and retried.
The initial 10 minutes are thus missing but it appears that most of the mee=
ting is available:

https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D66584037&r=
Key=3D04f7d34938f3bce6

Cheers,

Pascal

From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of T=
homas Watteyne
Sent: vendredi 8 mars 2013 18:40
To: IETF 6TSCH
Subject: [6tsch] minutes WebEx 8 March 2013

All,
Notes of today's meeting below. Please correct inline and reply.
Thomas

---

*** Timestamps in PST. ***

Present:
- Herman Storey
- Maria Rita Palattella
- Norman Finn
- Pascal Thubert
- Qin Wang
- Shitanshu Shah
- Thomas Watteyne
- Tina Tsou
- Tom Phinney
- Xavi Vilajosana

Agenda:
- Introduction to the terminology draft [10min] [Maria Rita]
- Diffserv Recommendations for LLN class of traffic [5min] [Shitanshu]
   - http://datatracker.ietf.org/doc/draft-svshah-tsvwg-lln-diffserv-recomm=
endations/
- Agenda for new week meetings [10min] [Pascal]
- Changes in other drafts [10min]
   - draft-watteyne-6tsch-tsch-lln-context [Thomas]
   - draft-wang-6tsch-6tus [Qin]
   - draft-thubert-6tsch-architecture [Pascal]
- Mailing list discussions [30min]
   - DSCPs and priorities [Thomas]
   - imux/mux [Qin]

Minutes:
- [08.04] meeting starts
- [08.05] Introduction to the new terminology draft [Maria Rita]
   - [Pascal] This draft extends ROLL and autoconf terminology, which are i=
ncluded as references.
   - [Maria Rita] Presents slides.
   - [Maria Rita] draft was triggered by the fact that "link" and "path" ha=
ve different meaning in TSCH and IETF parlance.
   - [Maria Rita] "Cell": Single element in the TSCH schedule. Replaces "li=
nk" term in TSCH.
   - [Maria Rita] "Bundle": A group of equivalent scheduled cells. Replaces=
 (although not exactly) "path" term in TSCH.
   - [Maria Rita] Draft there to avoid confusion, we will include other ter=
ms as work progresses.
   - [Maria Rita] Draft will be published on Monday.
- [08.14] Diffserv Recommendations for LLN class of traffic [Shitanshu]
   - draft at http://datatracker.ietf.org/doc/draft-svshah-tsvwg-lln-diffse=
rv-recommendations/
   - Shitanshu presents slides.
   - Context: this draft was presented at the last IETF meeting in Atlanta.
   - Goal: using Diffserv in context of LLN
   - Motivation: RFC4594 is well documented recommendation for traditional =
classes of traffic. Yet, does not cover LLN. What this draft does it:
      - categorize LLN
      - lists explicit recommendations for LLN
      - always keeping RFC4594 as a reference
   - source points to mark appropriate DSCP code point
   - LLN Traffic Classes identified from ROLL requirement drafts
      - 6 categories: alerts/alarms, control signals, deterministic control=
 signals, Video Monitoring/feed, Query-based data, Periodic Reporting/log &=
 software downloads.
      - each class characterized in terms of loss, delay and jitter. Some c=
lasses are different from RFC4594, justifying the need for this new draft. =
Example: deterministic control signals.
   - [Tom] Alerts/Alarms traffic are bursty because multiple network elemen=
ts can signal the same physical events (e.g. explosion).
   - [Herman] You don't want to loose any alert/alarm packets
   - [Shitanshu] Agreed, will update draft.
   - [Herman] Is there a class for network management?
   - [Pascal] In some cases, network control needs to be the highest priori=
ty since network falls apart when no network control packets can be transmi=
tted.
   - [Pascal] DSCP will play key role in packet priority. There is no DSCP =
for flow priority.
   - [Pascal] PHB means "per hop behavior"
   - [Shitanshu] Draft proposed code-point EF
   - [Herman] Why are emergency action outside of IP networks?
   - [Shitanshu] Other techniques are used which are not IP.
   - [Herman] There are IP-based solutions. Operate as dedicated network, n=
ot connected to complete Internet (non routable subnet), but use IP address=
.
   - [Shitanshu] We can remove the term IP.
- [08.35] Agenda for new week meetings [Pascal]
   - Tuesday (Caribbean 2):
      - admin
         - we will have 5-10min during the ROLL meeting to present 6tsch
         - 6tsch meeting follows ROLL meeting, same room
         - we need to leave 15min before end to set up next meeting, so we =
will really only have one hour.
         - we will have projector, not clear whether we will be able to pro=
vide live online feed.
      - Goal: prepare for successful BoF in Berlin
      - Scope: the backbone with PCE (Path Computation Entity) and one or m=
ore LLN running 6LoWPAN, 6TSCH, RPL.
      - we use draft-phinney-roll-rpl-industrial-applicability as a startin=
g point.
      - goals and deliverables:
         - informational: LLN context, architecture, terminology
         - new: 6tus, protocol for reserving track
         - adapt existing: OF for RPL, fragment forwarding (problems becaus=
e don't have DSCP)
         - extern docs: backbone router (from 6MAN), PCE (is a WG, need to =
coordinate)
      - dependencies and liaison:
         - IEEE 802.1TSN (Norman)
         - ISA100.20 are defining arbstraction for management layer to mana=
ge the managers (e.g. blacklist channels). We could use same formats.
         - IoT6. European project. They use very similar architecture as ou=
rs.
   - Wednesday (Boca 2)
      - admin:
         - in Boca 2, which we can stay in past 1pm.
      - we will go over different drafts
         - draft-phinney-roll-rpl-industrial-applicability.
            - published at http://tools.ietf.org/html/draft-phinney-roll-rp=
l-industrial-applicability-02
            - [Tom] Analysis of classifications of types of communications =
that occur. Applies to all automation systems, worked out over years by man=
y people.
            - [Pascal] Good source of inspiration.
         - draft-watteyne-6tsch-tsch-lln-context
            - published at http://tools.ietf.org/html/draft-watteyne-6tsch-=
tsch-lln-context-01
            - [Thomas] do not expect -02 for Orlando, but will need rewordi=
ng for new terminology.
         - draft-wang-6tsch-6tus
            - [Pascal] Caution, we cannot reinvent MPLS.
            - [Xavi] will be published on Monday.
         - draft-palattella-6tsch-terminology
            - see presentation above
            - will be published on Monday.
         - draft-thubert-6tsch-architecture
            - [Pascal] will be work-in-progress for a long time, since inco=
rporates changes/concepts from other drafts.
            - [Pascal] More text to follow: network synchronization, 6tus, =
management, etc.
            - [Thomas] Can be seen a index for other drafts, could serve as=
 first draft to read when familiarizing with 6tsch.
- [08.55] Priority discussion
   - [Thomas] We don't have much time left, so instead of starting discussi=
on, will prepare slides for Wednesday meeting.
   - [Pascal] Will add slot for Wednesday meeting.
   - [Pascal] Pascal will meet with Shitanshu on Monday morning, Thomas wil=
l meet with Pascal on Monday evening and Tuesday.
- [10.00]
   - [Thomas] Will be meeting stay at this time?
   - [Tom,Pascal] For the moment yes
   - [Pascal] There is not call next week because of IETF meeting.
- [10.05] Meeting ends.

--_000_E045AECD98228444A58C61C200AE1BD835CF1F81xmbrcdx01ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Thanks Thomas:=



 <=
/p>

I had an error coming fro=
m the recording so I stopped it and retried.


The initial 10 minutes ar=
e thus missing but it appears that most of the meeting is available:




https://ci=
sco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D66584037&=
;rKey=3D04f7d34938f3bce6







Cheers,=



 <=
/p>

Pascal


 <=
/p>

From: 6tsch-bo=
unces@ietf.org [mailto:6tsch-bounces@ietf.org]
On Behalf Of Thomas Watteyne

Sent: vendredi 8 mars 2013 18:40

To: IETF 6TSCH

Subject: [6tsch] minutes WebEx 8 March 2013


 




=
All,






=
Notes of today's meeting below. Please correct inline and reply.=







=
Thomas






=
 






=
---








 






*** Timestamps in PST. ***<=
o:p>






 






Present:






- Herman Storey<=
/p>





- Maria Rita Palattella






- Norman Finn





- Pascal Thubert=







- Qin Wang






- Shitanshu Shah=







- Thomas Watteyne






- Tina Tsou






- Tom Phinney





- Xavi Vilajosana






 






Agenda:






- Introduction to the terminology =
draft [10min] [Maria Rita]






- Diffserv Recommendations for LLN=
 class of traffic [5min] [Shitanshu]







- Agenda for new week meetings [10=
min] [Pascal]






- Changes in other drafts [10min]<=
/span>






   - draft-watteyne-6tsc=
h-tsch-lln-context [Thomas]






   - draft-wang-6tsch-6t=
us [Qin]






   - draft-thubert-6tsch=
-architecture [Pascal]






- Mailing list discussions [30min]=







   - DSCPs and prioritie=
s [Thomas]






   - imux/mux [Qin]






 






Minutes:






- [08.04] meeting starts






- [08.05] Introduction to the new =
terminology draft [Maria Rita]






   - [Pascal] This draft=
 extends ROLL and autoconf terminology, which are included as references.






   - [Maria Rita] Presen=
ts slides.






   - [Maria Rita] draft =
was triggered by the fact that "link" and "path" have d=
ifferent meaning in TSCH and IETF parlance.






   - [Maria Rita] "=
Cell": Single element in the TSCH schedule. Replaces "link" =
term in TSCH.






   - [Maria Rita] "=
Bundle": A group of equivalent scheduled cells. Replaces (although not=
 exactly) "path" term in TSCH.






   - [Maria Rita] Draft =
there to avoid confusion, we will include other terms as work progresses.






   - [Maria Rita] Draft =
will be published on Monday.






- [08.14] Diffserv Recommendations=
 for LLN class of traffic [Shitanshu]







   - Shitanshu presents =
slides.






   - Context: this draft=
 was presented at the last IETF meeting in Atlanta.






   - Goal: using Diffser=
v in context of LLN






   - Motivation: RFC4594=
 is well documented recommendation for traditional classes of traffic. Yet,=
 does not cover LLN. What this draft does it:






      - categorize =
LLN






      - lists expli=
cit recommendations for LLN






      - always keep=
ing RFC4594 as a reference






   - source points to ma=
rk appropriate DSCP code point






   - LLN Traffic Classes=
 identified from ROLL requirement drafts






      - 6 categorie=
s: alerts/alarms, control signals, deterministic control signals, Video Mon=
itoring/feed, Query-based data, Periodic Reporting/log & software
 downloads.






      - each class =
characterized in terms of loss, delay and jitter. Some classes are differen=
t from RFC4594, justifying the need for this new draft. Example:
 deterministic control signals.






   - [Tom] Alerts/Alarms=
 traffic are bursty because multiple network elements can signal the same p=
hysical events (e.g. explosion).






   - [Herman] You don't =
want to loose any alert/alarm packets






   - [Shitanshu] Agreed,=
 will update draft.






   - [Herman] Is there a=
 class for network management?






   - [Pascal] In some ca=
ses, network control needs to be the highest priority since network falls a=
part when no network control packets can be transmitted.<=
/p>





   - [Pascal] DSCP will =
play key role in packet priority. There is no DSCP for flow priority.






   - [Pascal] PHB means =
"per hop behavior"






   - [Shitanshu] Draft p=
roposed code-point EF






   - [Herman] Why are em=
ergency action outside of IP networks?






   - [Shitanshu] Other t=
echniques are used which are not IP.






   - [Herman] There are =
IP-based solutions. Operate as dedicated network, not connected to complete=
 Internet (non routable subnet), but use IP address.






   - [Shitanshu] We can =
remove the term IP.






- [08.35] Agenda for new week meet=
ings [Pascal]






   - Tuesday (Caribbean =
2):






      - admin






         =
- we will have 5-10min during the ROLL meeting to present 6tsch=







         =
- 6tsch meeting follows ROLL meeting, same room






         =
- we need to leave 15min before end to set up next meeting, so we will real=
ly only have one hour.






         =
- we will have projector, not clear whether we will be able to provide live=
 online feed.






      - Goal: prepa=
re for successful BoF in Berlin






      - Scope: the =
backbone with PCE (Path Computation Entity) and one or more LLN running 6Lo=
WPAN, 6TSCH, RPL.






      - we use draf=
t-phinney-roll-rpl-industrial-applicability as a starting point.






      - goals and d=
eliverables:






         =
- informational: LLN context, architecture, terminology





         =
- new: 6tus, protocol for reserving track






         =
- adapt existing: OF for RPL, fragment forwarding (problems because don't h=
ave DSCP)






         =
- extern docs: backbone router (from 6MAN), PCE (is a WG, need to coordinat=
e)






      - dependencie=
s and liaison:






         =
- IEEE 802.1TSN (Norman)






         =
- ISA100.20 are defining arbstraction for management layer to manage the ma=
nagers (e.g. blacklist channels). We could use same formats.






         =
- IoT6. European project. They use very similar architecture as ours.






   - Wednesday (Boca 2)<=
/span>






      - admin:






         =
- in Boca 2, which we can stay in past 1pm.






      - we will go =
over different drafts






         =
- draft-phinney-roll-rpl-industrial-applicability.







         =
   - [Tom] Analysis of classifications of types of communications that=
 occur. Applies to all automation systems, worked out over years by many pe=
ople.






         =
   - [Pascal] Good source of inspiration.






         =
- draft-watteyne-6tsch-tsch-lln-context







         =
   - [Thomas] do not expect -02 for Orlando, but will need rewording f=
or new terminology.






         =
- draft-wang-6tsch-6tus






         =
   - [Pascal] Caution, we cannot reinvent MPLS.






         =
   - [Xavi] will be published on Monday.






         =
- draft-palattella-6tsch-terminology






         =
   - see presentation above






         =
   - will be published on Monday.






         =
- draft-thubert-6tsch-architecture






         =
   - [Pascal] will be work-in-progress for a long time, since incorpor=
ates changes/concepts from other drafts.






         =
   - [Pascal] More text to follow: network synchronization, 6tus, mana=
gement, etc.






         =
   - [Thomas] Can be seen a index for other drafts, could serve as fir=
st draft to read when familiarizing with 6tsch.






- [08.55] Priority discussion






   - [Thomas] We don't h=
ave much time left, so instead of starting discussion, will prepare slides =
for Wednesday meeting.






   - [Pascal] Will add s=
lot for Wednesday meeting.






   - [Pascal] Pascal wil=
l meet with Shitanshu on Monday morning, Thomas will meet with Pascal on Mo=
nday evening and Tuesday.






- [10.00]






   - [Thomas] Will be me=
eting stay at this time?






   - [Tom,Pascal] For th=
e moment yes






   - [Pascal] There is n=
ot call next week because of IETF meeting.






- [10.05] Meeting ends.










--_000_E045AECD98228444A58C61C200AE1BD835CF1F81xmbrcdx01ciscoc_--

From tom.phinney@cox.net  Fri Mar  8 10:19:46 2013
Return-Path: 
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 61BFA21F874B for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 10:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.159
X-Spam-Level: 
X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=-1.300,  BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
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 4VjuzSGGwtCW for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 10:19:42 -0800 (PST)
Received: from fed1rmfepo101.cox.net (fed1rmfepo101.cox.net [68.230.241.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3D61621F8644 for <6tsch@ietf.org>; Fri,  8 Mar 2013 10:19:42 -0800 (PST)
Received: from fed1rmimpo210 ([68.230.241.161]) by fed1rmfepo101.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130308181941.RPCR25001.fed1rmfepo101.cox.net@fed1rmimpo210> for <6tsch@ietf.org>; Fri, 8 Mar 2013 13:19:41 -0500
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo210 with cox id 96Kh1l00D3gAAro016Khzz; Fri, 08 Mar 2013 13:19:41 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020201.513A2BBD.01A6,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=Q80MFfKa c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=mPkyY4alenMA:10 a=NiL0GWOVAAAA:8 a=xSAkylHiAkU9y6SEGUQA:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=8ZwbW6lFucIA:10 a=lNvVVlmzPuZBikIP:21 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <513A2BBD.8010407@cox.net>
Date: Fri, 08 Mar 2013 11:19:41 -0700
From: Tom Phinney 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "6tsch@ietf.org" <6tsch@ietf.org>
X-Enigmail-Version: 1.1.1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [6tsch] Winter / summer time
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney 
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2013 18:19:46 -0000



  

    
  
  
    In North America, the US, Canada and parts of
      northern Mexico begin summer time on 2013.03.10 and return to
      winter time on 2013.11.03.

      Continental Europe begins summer time on 2013.03.31 and returns to winter time on
      2013.10.27.

      The UK begins and ends summer time on the same dates as
      continental Europe.

      China, Japan, South Korea and Russia do not go on summer time.

    Within the US, Arizona and Hawaii do not
      go on summer time.

    

    See http://www.timeanddate.com/time/dst/2013.html
      for other countries

      

      So, what time UTC does the 6TSCH teleconference start on
      2013.03.24? Presumably this will also be the time for the meetings
      on 2013.11.01.

      And what time UTC does the 6TSCH
      teleconference start on 2013.03.31?
      Presumably this will also be the time for all meetings through
      2013.10.25.

      

      I have no personal preference about start time because I live
      almost year round in areas that are at UTC+07:00 when I am living
      there. But as a result I always have to convert other people's
      usually-unstated time basis, since they often schedule meetings in
      terms of their local winter time or summer time without
      considering that their time will shift one hour back and forth on
      specific days early and late in the year. Then they are surprised
      when the rest of the world does not shift synchronously with them.

      

      When scheduling persistent international teleconferences it is
      wise to consider when the telecon will occur during Winter time,
      and during Summer time, because many people will have conflicting
      scheduling requirements during the transition intervals when
      different countries have or have not shifted their default time.

    
  


From mcr@sandelman.ca  Fri Mar  8 15:01:58 2013
Return-Path: 
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 69E7A21F85B0 for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 15:01:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.244
X-Spam-Level: 
X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HOST_MISMATCH_NET=0.311]
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 GJD9WCAwJwXu for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 15:01:58 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id B5BB721F85A1 for <6tsch@ietf.org>; Fri,  8 Mar 2013 15:01:57 -0800 (PST)
Received: from sandelman.ca (unknown [199.119.232.224]) by relay.sandelman.ca (Postfix) with ESMTPS id CA5D622060; Fri,  8 Mar 2013 23:01:55 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C6405CA0D0; Fri,  8 Mar 2013 14:09:29 -0500 (EST)
From: Michael Richardson 
To: IETF 6TSCH <6tsch@ietf.org>
In-reply-to: 
References: 
Comments: In-reply-to Thomas Watteyne  message dated "Fri, 08 Mar 2013 09:40:11 -0800."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 08 Mar 2013 14:09:29 -0500
Message-ID: <16457.1362769769@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: Thomas Watteyne 
Subject: Re: [6tsch] minutes WebEx 8 March 2013
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2013 23:01:58 -0000

--==-=-=
Content-Type: multipart/mixed; boundary="=-=-="

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Thomas" =3D=3D Thomas Watteyne  writes:
    Thomas> Tuesday (Caribbean 2): - admin - we will have 5-10min during
    Thomas> the ROLL meeting to present 6tsch - 6tsch meeting follows
    Thomas> ROLL meeting, same room=20

Further, the 6tsch is *last* on the ROLL agenda, and I do not think that
ROLL will fill the entire 2.5 hours allocated.

    Thomas> - we need to leave 15min before end
    Thomas> to set up next meeting, so we will really only have one
    Thomas> hour.  - we will have projector, not clear whether we will
    Thomas> be able to provide live online feed.  - Goal: prepare for

generally, the microphones stay on (and live) through-out lunch.
It's often fun to listen after a session ends, as most people chatting
near the chair's table don't know the mic is on...  the things you can
learn...

    Thomas> (Norman) - ISA100.20 are defining arbstraction for
    Thomas> management layer to manage the managers (e.g. blacklist
    Thomas> channels). We could use same formats.  - IoT6. European
    Thomas> project. They use very similar architecture as ours.  -

Does ISA100.20 include a protocol for communication with a PCE?

    Thomas> in past 1pm.  - we will go over different drafts -
    Thomas> draft-phinney-roll-rpl-industrial-applicability.  -
    Thomas> published at
    Thomas> http://tools.ietf.org/html/draft-phinney-roll-rpl-industrial-ap=
plicability-02

will become draft-ietf-roll-industrial-applicability soon.
Note that ID document submission tool *opens* again on Monday morning,
but do not assume anyone has read new documents.


--=-=-=
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Description: Signature

=2D-=20
Michael Richardson
=2Don the road-

--=-=-=--

--==-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJROjdpAAoJEKD0KQ7Gj3P2vX8IALdKaqVzX31j8vIuTemUHfMS
xj9QTaa7LhZ8OTdUl3IXHCYyS9kXmMlt9qkWSDT1+TH024EOFchmXzcAK927p20h
D4BKyLo/72M08/pozj26B8UST+QQoVTrP18CbGDAv15p1O24IeDYBX3h0UcR+NS9
aM3OySYubQ9t+c0ZQRlkBLU6D71q00TWl1P9nO8ivVtMa0wscB/xFCU0qFmxClMm
N43SwC2i7HFlSsxl4IG6ybZ4kNz43H1UzjvhXmAoPywnIOjvD/y2yMFYx2XpjSmy
S6GRePltoSFqJwv1O6PLYt3mf3JjCJjN0g1AtFF19KQsmecclhbGUmS+QXz7IR0=
=ajiv
-----END PGP SIGNATURE-----
--==-=-=--

From mcr@sandelman.ca  Fri Mar  8 22:26:41 2013
Return-Path: 
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 7D1C721F8554 for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 22:26:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.244
X-Spam-Level: 
X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HOST_MISMATCH_NET=0.311]
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 fjpDj5ClPRcA for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 22:26:41 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id EB34621F852A for <6tsch@ietf.org>; Fri,  8 Mar 2013 22:26:40 -0800 (PST)
Received: from sandelman.ca (unknown [209.128.20.133]) by relay.sandelman.ca (Postfix) with ESMTPS id 4E2E22206B for <6tsch@ietf.org>; Sat,  9 Mar 2013 06:26:40 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A0888CA0D6 for <6tsch@ietf.org>; Fri,  8 Mar 2013 21:19:44 -0500 (EST)
From: Michael Richardson 
To: "6tsch@ietf.org" <6tsch@ietf.org>
In-reply-to: 
References: <512C36F4.4000409@eecs.berkeley.edu> 
Comments: In-reply-to Maria Rita PALATTELLA  message dated "Tue, 26 Feb 2013 07:55:28 +0000."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 08 Mar 2013 21:19:44 -0500
Message-ID: <18297.1362795584@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Mar 2013 06:26:41 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Maria" =3D=3D Maria Rita PALATTELLA  w=
rites:
    Maria> 3) transmission of signaling messages for setting up the
    Maria> schedule. Let's assume there is a scheduler that builds the
    Maria> schedule for the network. In order to assign some links to
    Maria> each of them, it will need to broadcast the information
    Maria> related to ( timeOffset, ChannelOffset). As for the
    Maria> synchronization, having a broadcast channel dedicated to the
    Maria> signaling will allow to set up the schedule in shorter time.

    Maria> Maybe, because there are 16 available channels in
    Maria> IEEE802.15.4/15.4e PHY, using some of them as broadcast
    Maria> channels for synchronization/exchange of cross-layer info/set
    Maria> up of the schedule wouldn't be a big problem. In many
    Maria> applications, a smaller set of channels (< 16) will be enough
    Maria> for building a reliable schedule.

Are there multicasts that need to go out other than RPL DIOs?
Those will go out based upon trickle... in a stable network, the DIOs
will be rare compared to actual traffic... if the network data is also
so light as to be able to easily allocate many channels, then... why
doesd not need 6tsch at all... the LLN should have lots of bandwidth to
get the controls through.

So it seems to me that really taking any channels up for broadcast would
be a bad idea if there are other options.


=2D-=20
Michael Richardson
=2Don the road-

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJROpxAAAoJEKD0KQ7Gj3P2FzgH/Rmsah02437oyeY8mBwKRxwK
UEYr9MLQcKjupTnBlArsnmKxCuExqPy+mq0yq9YrDxqZp3A2xl52W4+dNW4U9AXx
2XhR+oF6Vzzv1IMRzdFGtY0NGNbSmXkvBNkbg0Pmo2p7YXYIEc7IB/wFwSQRtcXG
xesqlAlldTnIef1M5aNuvgmWLXQ79fYBRNagnkDJtXOxOC4kQtp/j7ilewIGt8mm
Av1QZiuLpKs+C/S+CONo39Gixht1OCYV1WHnY0brKJiWsrKUtOVef4K2oHK+RMYF
i70wkHe5+AoiriFafJdqLLE7K7Gz4fGi/iKx0mMJlJsBE2Lmpv6CXG4JiKumzwI=
=Pmgx
-----END PGP SIGNATURE-----
--=-=-=--

From mcr@sandelman.ca  Fri Mar  8 22:26:41 2013
Return-Path: 
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 C23C421F8555 for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 22:26:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.944
X-Spam-Level: 
X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_22=0.6]
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 dPBS9G3GiPLj for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 22:26:41 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0814621F8546 for <6tsch@ietf.org>; Fri,  8 Mar 2013 22:26:41 -0800 (PST)
Received: from sandelman.ca (unknown [209.128.20.133]) by relay.sandelman.ca (Postfix) with ESMTPS id 5F7362206E for <6tsch@ietf.org>; Sat,  9 Mar 2013 06:26:40 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EB836CA0DA for <6tsch@ietf.org>; Fri,  8 Mar 2013 21:55:28 -0500 (EST)
From: Michael Richardson 
To: IETF 6TSCH <6tsch@ietf.org>
In-reply-to: 
References: 
Comments: In-reply-to Thomas Watteyne  message dated "Thu, 07 Mar 2013 23:34:44 -0800."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 08 Mar 2013 21:55:28 -0500
Message-ID: <19015.1362797728@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [6tsch] priority and priority
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Mar 2013 06:26:41 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Thomas" =3D=3D Thomas Watteyne  writes:
    Thomas> I believe that we have been discussing two different notions
    Thomas> of priority: - *Packet Priority*: Assuming an existing data
    Thomas> flow in a network, some packets are marked as "high
    Thomas> priority", the rest as "low priority". All packets are part
    Thomas> of the same flow, but high priority packets are treated with
    Thomas> more urgency that low priority packets. This translates into

the word 'flow' is ambiguous.
    It IETF land, a flow is a 2 or 3-tuple of
    (source,dest,sometimes-protocol-sometimes-flow-label)=20
    (a microflow is a 5-tuple, SA,DA,protocol,source-port,dest-port)

How can a flow have high priority packets and low priority packets?

Why are these two types of packets using the same DODAG?

High priority packets presumeably require lower latency, and therefore
it might make sense to use a more direct route through a more costly
node.  Or, if a particular PAN is congested, they might get priority
access to the slots, while lower priority traffic might have to take a
more circuitous route around the edges...

    Thomas> DSCP can also be used by the higher layer to indicate to
    Thomas> which flow this packet pertains, and with what (optional)
    Thomas> priority. Upon receiving a packet from a higher layer, the
    Thomas> 6tsch layer could inspect the DSCP and some set of rules
    Thomas> would tell him which flow to send it on. Once it is in a

Well, just think instead that 6tsch could "inspect" the DSCP, say that
the 6tsch API will provide an way for the layer 3 to express the
DSCP-equivalent.=20

=2D-=20
Michael Richardson
=2Don the road-



--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJROqSgAAoJEKD0KQ7Gj3P2yNcH/2byRw+TIK7DXsudosXjru04
7FtzCqSlkllTdVzOlYlZThh+CoY5T4VZhdKCpKkuEpcsjy0umR5SSNOZcCKlSnyh
9sFJDnUpBFVxhHbWZk0RvQ4j6wbqCwrHyzw5wFW2V6zpkgFHzMBCEbFvvCIEjDgf
PUo6WGstJ4ATSOOz1dfqGJjtUGfz84WnYKabwRtYHIJRID4r/Z03Km1qX+0Nwo8R
vdMMtQV4fbwsoSFGMydHXkE4NFsBXq1CEKcMBAc2hw6Dqf0xVg8EqJVq446esQoP
lmVrOVflbIfdfRB4KN3B7Vfdp953pa/8C0+KQfJvyPfebvy78xErpqyscwj6+TI=
=EUab
-----END PGP SIGNATURE-----
--=-=-=--

From twatteyne@gmail.com  Fri Mar  8 22:33:23 2013
Return-Path: 
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 91ADA21F856E for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 22:33:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Level: 
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1]
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 u8VQ1y7q5R7m for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 22:33:22 -0800 (PST)
Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id B0B0521F8546 for <6tsch@ietf.org>; Fri,  8 Mar 2013 22:33:22 -0800 (PST)
Received: by mail-pb0-f50.google.com with SMTP id up1so1940920pbc.23 for <6tsch@ietf.org>; Fri, 08 Mar 2013 22:33:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=+gcH5L8Tsr8d/jWp8cWxp8ZpFLOTwuGw183tL+bSL1U=; b=w3SPB5Oyo5SNu0UiVI46Y0NBA1pROCSwow/4MhxlhCoUpeTT7PY7j6tp2Q59i4qowE jrI2XB8V9SwY/8eG8MH1vNCkz+VVm0CESk12toecUzu86NL0zui/t4XwsH1cr5w0PKoO 7h4q6IIKgDRy0GnQR/nKztCGkq7pp2TJNMEnrZjyFDAtOc/a0qCiPBfBgf6ABs7tqolf Rh7K9++R9aHd7AK9JvlKJw+/yDP2il7nU3eqbwGY79R+HlEglZx5e0t2kfaP6PC7x51W eI9aDMCoqrKlesE7iA+2KtwujrctzSPSb2AqRcPVRdTUawpMGAjzaYJbY17HnEk66Ikv 5h8A==
MIME-Version: 1.0
X-Received: by 10.68.117.104 with SMTP id kd8mr9060689pbb.1.1362810802194; Fri, 08 Mar 2013 22:33:22 -0800 (PST)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Fri, 8 Mar 2013 22:33:22 -0800 (PST)
In-Reply-To: <19015.1362797728@sandelman.ca>
References:  <19015.1362797728@sandelman.ca>
Date: Fri, 8 Mar 2013 22:33:22 -0800
X-Google-Sender-Auth: gvCO3mZUcVRtB4OcdJa-TIH0WqY
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b072330c4845104d7781dd8
Subject: Re: [6tsch] priority and priority
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Mar 2013 06:33:23 -0000

--047d7b072330c4845104d7781dd8
Content-Type: text/plain; charset=ISO-8859-1

Michael,

I agree that the term flow is almost as overloaded as link or path. This is
not a final term and we will have to come up with a better term.
Suggestions?

If I get your point correctly, you are suggesting that there should be no
packet priorities, only flows priority. In a TSCH context, this would
translate into a slotframe per flow, where flow also incorporates the
notion of priority. Correct? This is a very important discussion we started
over the phone earlier today, but which we will continue Wednesday in
Orlando. I hope you can be there.

Thomas

On Fri, Mar 8, 2013 at 6:55 PM, Michael Richardson wrote:

>
> >>>>> "Thomas" == Thomas Watteyne  writes:
>     Thomas> I believe that we have been discussing two different notions
>     Thomas> of priority: - *Packet Priority*: Assuming an existing data
>     Thomas> flow in a network, some packets are marked as "high
>     Thomas> priority", the rest as "low priority". All packets are part
>     Thomas> of the same flow, but high priority packets are treated with
>     Thomas> more urgency that low priority packets. This translates into
>
> the word 'flow' is ambiguous.
>     It IETF land, a flow is a 2 or 3-tuple of
>     (source,dest,sometimes-protocol-sometimes-flow-label)
>     (a microflow is a 5-tuple, SA,DA,protocol,source-port,dest-port)
>
> How can a flow have high priority packets and low priority packets?
>
> Why are these two types of packets using the same DODAG?
>
> High priority packets presumeably require lower latency, and therefore
> it might make sense to use a more direct route through a more costly
> node.  Or, if a particular PAN is congested, they might get priority
> access to the slots, while lower priority traffic might have to take a
> more circuitous route around the edges...
>
>     Thomas> DSCP can also be used by the higher layer to indicate to
>     Thomas> which flow this packet pertains, and with what (optional)
>     Thomas> priority. Upon receiving a packet from a higher layer, the
>     Thomas> 6tsch layer could inspect the DSCP and some set of rules
>     Thomas> would tell him which flow to send it on. Once it is in a
>
> Well, just think instead that 6tsch could "inspect" the DSCP, say that
> the 6tsch API will provide an way for the layer 3 to express the
> DSCP-equivalent.
>
> --
> Michael Richardson
> -on the road-
>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

--047d7b072330c4845104d7781dd8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Michael,

I agree that the term flow is almost as overloa=
ded as link or path. This is not a final term and we will have to come up w=
ith a better term. Suggestions?

If I get your poin=
t correctly, you are suggesting that there should be no packet priorities, =
only flows priority. In a TSCH context, this would translate into a slotfra=
me per flow, where flow also incorporates the notion of priority. Correct? =
This is a very important discussion we started over the phone earlier today=
, but which we will continue Wednesday in Orlando. I hope you can be there.=




Thomas

On Fri, Mar 8,=
 2013 at 6:55 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:




>>>>> "Thomas" =3D=3D Thomas Watteyne <watteyne@eecs.berkeley.edu> w=
rites:

=A0 =A0 Thomas> I believe that we have been discussing two different not=
ions

=A0 =A0 Thomas> of priority: - *Packet Priority*: Assuming an existing d=
ata

=A0 =A0 Thomas> flow in a network, some packets are marked as "high=


=A0 =A0 Thomas> priority", the rest as "low priority". Al=
l packets are part

=A0 =A0 Thomas> of the same flow, but high priority packets are treated =
with

=A0 =A0 Thomas> more urgency that low priority packets. This translates =
into



the word 'flow' is ambiguous.

=A0 =A0 It IETF land, a flow is a 2 or 3-tuple of

=A0 =A0 (source,dest,sometimes-protocol-sometimes-flow-label)

=A0 =A0 (a microflow is a 5-tuple, SA,DA,protocol,source-port,dest-port)


How can a flow have high priority packets and low priority packets?



Why are these two types of packets using the same DODAG?



High priority packets presumeably require lower latency, and therefore

it might make sense to use a more direct route through a more costly

node. =A0Or, if a particular PAN is congested, they might get priority

access to the slots, while lower priority traffic might have to take a

more circuitous route around the edges...



=A0 =A0 Thomas> DSCP can also be used by the higher layer to indicate to=


=A0 =A0 Thomas> which flow this packet pertains, and with what (optional=
)

=A0 =A0 Thomas> priority. Upon receiving a packet from a higher layer, t=
he

=A0 =A0 Thomas> 6tsch layer could inspect the DSCP and some set of rules=


=A0 =A0 Thomas> would tell him which flow to send it on. Once it is in a=




Well, just think instead that 6tsch could "inspect" the DSCP, say=
 that

the 6tsch API will provide an way for the layer 3 to express the

DSCP-equivalent.



--

Michael Richardson

-on the road-






_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





--047d7b072330c4845104d7781dd8--

From tom.phinney@cox.net  Fri Mar  8 23:36:03 2013
Return-Path: 
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 143E521F8589 for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 23:36:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.491
X-Spam-Level: 
X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
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 HhI7jzSUIzfS for <6tsch@ietfa.amsl.com>; Fri,  8 Mar 2013 23:36:02 -0800 (PST)
Received: from fed1rmfepo103.cox.net (fed1rmfepo103.cox.net [68.230.241.145]) by ietfa.amsl.com (Postfix) with ESMTP id 35C8C21F8595 for <6tsch@ietf.org>; Fri,  8 Mar 2013 23:36:02 -0800 (PST)
Received: from fed1rmimpo305 ([68.230.241.173]) by fed1rmfepo103.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130309073601.YCEV30259.fed1rmfepo103.cox.net@fed1rmimpo305> for <6tsch@ietf.org>; Sat, 9 Mar 2013 02:36:01 -0500
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo305 with cox id 9Kc01l0083gAAro01Kc18k; Sat, 09 Mar 2013 02:36:01 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020201.513AE661.0088,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=W9Hmo2qk c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=6etX-ORWL8YA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=EaCufb_MCHMA:10 a=pGLkceISAAAA:8 a=FWe59-56bP0sH6r4uYkA:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=5MpX6VxFRJLqPTZk:21 a=0Bs8fi0_bc5_5If7:21 a=d1ILODLvc2aPxxOM:21 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <513AE660.2040403@cox.net>
Date: Sat, 09 Mar 2013 00:36:00 -0700
From: Tom Phinney 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: 6tsch@ietf.org
References: 	<19015.1362797728@sandelman.ca> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [6tsch] priority and priority
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney 
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Mar 2013 07:36:03 -0000



  
    
  
  
    I don't know what real-world use this technology is being designed
    to support, but the discussion fragments quoted at the end below
    seem to me to be moving away from reality.

    

    In the industrial automation world where I spent most of my career,
    it makes sense to have different inbound flows for differing
    purposes. Most sensor devices would have the following flows 1), 2)
    and 3):

    1) a dedicated inbound flow per field device (mote) for periodic
    deterministic control traffic, where the number of expected hops has
    to be small when the loop rate is high;

    2) a shared inbound flow for usually-infrequent alerts (i.e., device
    events and process alarms), probably with at least 2-level packet
    queuing priority, perhaps using CSMA/CA to provide some slight
    statistical bias in channel access priority based on packet
    priority;

    3) a shared inbound flow for server-to-client responses, typically
    in response to a program-initiated or operator-initiated action at
    an engineering workstation in a control room.

    

    Every process actuator (i.e., mote that can directly manipulate the
    process) will also have another flow 4), analogous to 1) but in the
    outbound direction, from the control room to the field to transfer
    the computed actuator setting to the device. Such devices also have
    inbound flow 1) to transfer actuator status at the same periodic
    rate.

    

    If communication problems are experienced on flow 1), it is
    desirable to be able to use one or more of the other flows as a
    backup mechanism for inbound control traffic, whether full
    determinism can be maintained or not. Packet queuing priority
    definitely makes sense here, so that such traffic can leapfrog
    non-deterministic traffic in the output queue of the originating
    mote and of any intermediary relaying motes. As mentioned in 2), it
    may also make sense to use CSMA/CA to provide some slight
    statistical bias in channel access priority based on packet
    priority, at least for flows where the transaction template has a
    non-null CSMA/CA sensing interval before the scheduled Data PDU
    transmission of the transaction.

    

    The reason for priority on the alerts is that process alarms from
    class 1 - 2 devices, (or class 0 - 2 if class 0 uses wireless),
    would usually be configured to be higher priority than those for
    classes 3 - 5. (Some class 3 devices might also be assigned that
    higher alarm priority.) Where safety alarms are concerned, such as
    the "man down" alarm that Herman Storey mentioned on Thursday's
    call, those alarms would tend to use another flow 5), similar to 2),
    with a very low expected rate but with dedicated slots to provide a
    clear virtual channel (to the extent possible). The time constants
    for such alarms are long enough (seconds) compared to much of the
    flow 1) traffic that the incremental cost of flow 5), which is so
    similar to flow 2), probably would not be very much, perhaps 2% of
    the total network capacity. It is tempting to just have a 3-way
    CSMA/CA interval for flow 2), but the reality of the CSMA/CA
    priority assessment mechanism is that it is very weak, given
    physical modem delays, inter-mote timing skews and the old
    hidden-node problem. Thus CSMA/CA prioritization does not seem
    reliable enough to trust for safety purposes.

    

    Of course a system will have other flows, many allocated on a demand
    basis in response to some occasional need, such as firmware download
    or captured waveform upload.

    

    The basic timing of continuous control loops it that the total delay
    from sensing the process to driving the actuator generally has to be
    less than twice the period of the loop. In such cases the needed
    control strategy is both relatively simple and relatively stable,
    However, if the total input-to-output delay exceeds twice the loop
    period, the control becomes much more difficult and less able to
    respond to fast transients. Jitter is a problem only when a process
    value message is delivered in the wrong cycle; it does not matter
    whether the delivery is at the 10% or 90% point in the proper cycle.
    Authenticated timestamping of the message, as occurs via the UDP
    transport nonce in ISA100.11a, provides a means of discarding
    process value messages that are delivered too late, thus converting
    those situations to ones of message loss. That is the desired way of
    handling late delivery, because the control loop is stable under
    message loss but not when the values are deliberately selectively
    delayed into the wrong delivery cycle. (Honeywell demonstrated years
    ago that it was possible to destablize most control loops with such
    deliberately jittered delivery.)

    

    -Tom

    =====

    On 2013.03.08 23:33, Thomas Watteyne wrote:
    
Michael,
      


      

      
I agree that the term flow is almost as overloaded as link or
        path. This is not a final term and we will have to come up with
        a better term. Suggestions?

      


      

      
If I get your point correctly, you are suggesting that there
        should be no packet priorities, only flows priority. In a TSCH
        context, this would translate into a slotframe per flow, where
        flow also incorporates the notion of priority. Correct? This is
        a very important discussion we started over the phone earlier
        today, but which we will continue Wednesday in Orlando. I hope
        you can be there.

      


      

      
Thomas

        

        
On Fri, Mar 8, 2013 at 6:55 PM, Michael
          Richardson <mcr+ietf@sandelman.ca>
          wrote:

          
How can a flow have high priority
            packets and low priority packets?

            

            Why are these two types of packets using the same DODAG?

          

        

      

    

  


From pister@eecs.berkeley.edu  Sat Mar  9 09:37:17 2013
Return-Path: 
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 3683021F86AF for <6tsch@ietfa.amsl.com>; Sat,  9 Mar 2013 09:37:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level: 
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=0.600,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 uNI312Uf0aR4 for <6tsch@ietfa.amsl.com>; Sat,  9 Mar 2013 09:37:15 -0800 (PST)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id E1F3B21F85E2 for <6tsch@ietf.org>; Sat,  9 Mar 2013 09:37:15 -0800 (PST)
Received: from c-98-210-49-50.hsd1.ca.comcast.net ([98.210.49.50] helo=[192.168.1.100]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1UENho-000223-EX; Sat, 09 Mar 2013 09:37:14 -0800
Message-ID: <513B733A.9010003@eecs.berkeley.edu>
Date: Sat, 09 Mar 2013 09:36:58 -0800
From: Kris Pister 
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Tom Phinney 
References: 	<19015.1362797728@sandelman.ca>  <513AE660.2040403@cox.net>
In-Reply-To: <513AE660.2040403@cox.net>
Content-Type: multipart/alternative; boundary="------------010207080501070102010107"
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] priority and priority
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Mar 2013 17:37:17 -0000

This is a multi-part message in MIME format.
--------------010207080501070102010107
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom - I agree with everything that you wrote in the email below except 
the first sentence.  Perhaps I'm missing something, but it seems to me 
that your enumeration of various flows with different requirements fits 
quite well with the discussion fragment quoted at the end below.  Can 
you help me understand the differences?

My bias is that we should have
{flow priority (equating to slotframe priority) OR link priority (TX, 
RX, uni-, multi-)} AND {packet priority}.

ksjp

On 3/8/2013 11:36 PM, Tom Phinney wrote:
> I don't know what real-world use this technology is being designed to 
> support, but the discussion fragments quoted at the end below seem to 
> me to be moving away from reality.
>
> In the industrial automation world where I spent most of my career, it 
> makes sense to have different inbound flows for differing purposes. 
> Most sensor devices would have the following flows 1), 2) and 3):
> 1) a dedicated inbound flow per field device (mote) for periodic 
> deterministic control traffic, where the number of expected hops has 
> to be small when the loop rate is high;
> 2) a shared inbound flow for usually-infrequent alerts (i.e., device 
> events and process alarms), probably with at least 2-level packet 
> queuing priority, perhaps using CSMA/CA to provide some slight 
> statistical bias in channel access priority based on packet priority;
> 3) a shared inbound flow for server-to-client responses, typically in 
> response to a program-initiated or operator-initiated action at an 
> engineering workstation in a control room.
>
> Every process actuator (i.e., mote that can directly manipulate the 
> process) will also have another flow 4), analogous to 1) but in the 
> outbound direction, from the control room to the field to transfer the 
> computed actuator setting to the device. Such devices also have 
> inbound flow 1) to transfer actuator status at the same periodic rate.
>
> If communication problems are experienced on flow 1), it is desirable 
> to be able to use one or more of the other flows as a backup mechanism 
> for inbound control traffic, whether full determinism can be 
> maintained or not. Packet queuing priority definitely makes sense 
> here, so that such traffic can leapfrog non-deterministic traffic in 
> the output queue of the originating mote and of any intermediary 
> relaying motes. As mentioned in 2), it may also make sense to use 
> CSMA/CA to provide some slight statistical bias in channel access 
> priority based on packet priority, at least for flows where the 
> transaction template has a non-null CSMA/CA sensing interval before 
> the scheduled Data PDU transmission of the transaction.
>
> The reason for priority on the alerts is that process alarms from 
> class 1 - 2 devices, (or class 0 - 2 if class 0 uses wireless), would 
> usually be configured to be higher priority than those for classes 3 - 
> 5. (Some class 3 devices might also be assigned that higher alarm 
> priority.) Where safety alarms are concerned, such as the "man down" 
> alarm that Herman Storey mentioned on Thursday's call, those alarms 
> would tend to use another flow 5), similar to 2), with a very low 
> expected rate but with dedicated slots to provide a clear virtual 
> channel (to the extent possible). The time constants for such alarms 
> are long enough (seconds) compared to much of the flow 1) traffic that 
> the incremental cost of flow 5), which is so similar to flow 2), 
> probably would not be very much, perhaps 2% of the total network 
> capacity. It is tempting to just have a 3-way CSMA/CA interval for 
> flow 2), but the reality of the CSMA/CA priority assessment mechanism 
> is that it is very weak, given physical modem delays, inter-mote 
> timing skews and the old hidden-node problem. Thus CSMA/CA 
> prioritization does not seem reliable enough to trust for safety purposes.
>
> Of course a system will have other flows, many allocated on a demand 
> basis in response to some occasional need, such as firmware download 
> or captured waveform upload.
>
> The basic timing of continuous control loops it that the total delay 
> from sensing the process to driving the actuator generally has to be 
> less than twice the period of the loop. In such cases the needed 
> control strategy is both relatively simple and relatively stable, 
> However, if the total input-to-output delay exceeds twice the loop 
> period, the control becomes much more difficult and less able to 
> respond to fast transients. Jitter is a problem only when a process 
> value message is delivered in the wrong cycle; it does not matter 
> whether the delivery is at the 10% or 90% point in the proper cycle. 
> Authenticated timestamping of the message, as occurs via the UDP 
> transport nonce in ISA100.11a, provides a means of discarding process 
> value messages that are delivered too late, thus converting those 
> situations to ones of message loss. That is the desired way of 
> handling late delivery, because the control loop is stable under 
> message loss but not when the values are deliberately selectively 
> delayed into the wrong delivery cycle. (Honeywell demonstrated years 
> ago that it was possible to destablize most control loops with such 
> deliberately jittered delivery.)
>
> -Tom
> =====
> On 2013.03.08 23:33, Thomas Watteyne wrote:
>> Michael,
>>
>> I agree that the term flow is almost as overloaded as link or path. 
>> This is not a final term and we will have to come up with a better 
>> term. Suggestions?
>>
>> If I get your point correctly, you are suggesting that there should 
>> be no packet priorities, only flows priority. In a TSCH context, this 
>> would translate into a slotframe per flow, where flow also 
>> incorporates the notion of priority. Correct? This is a very 
>> important discussion we started over the phone earlier today, but 
>> which we will continue Wednesday in Orlando. I hope you can be there.
>>
>> Thomas
>>
>> On Fri, Mar 8, 2013 at 6:55 PM, Michael Richardson 
>> > wrote:
>>
>>     How can a flow have high priority packets and low priority packets?
>>
>>     Why are these two types of packets using the same DODAG?
>>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


--------------010207080501070102010107
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Tom - I agree with everything that you wrote in the email below
    except the first sentence.  Perhaps I'm missing something, but it
    seems to me that your enumeration of various flows with different
    requirements fits quite well with the discussion fragment quoted at
    the end below.  Can you help me understand the differences?

    

    My bias is that we should have 

    {flow priority (equating to slotframe priority) OR link priority
    (TX, RX, uni-, multi-)} AND {packet priority}.

    

    ksjp

    

    
On 3/8/2013 11:36 PM, Tom Phinney
      wrote:

    

    

      
      I don't know what real-world use this technology is being designed
      to support, but the discussion fragments quoted at the end below
      seem to me to be moving away from reality.

      

      In the industrial automation world where I spent most of my
      career, it makes sense to have different inbound flows for
      differing purposes. Most sensor devices would have the following
      flows 1), 2) and 3):

      1) a dedicated inbound flow per field device (mote) for periodic
      deterministic control traffic, where the number of expected hops
      has to be small when the loop rate is high;

      2) a shared inbound flow for usually-infrequent alerts (i.e.,
      device events and process alarms), probably with at least 2-level
      packet queuing priority, perhaps using CSMA/CA to provide some
      slight statistical bias in channel access priority based on packet
      priority;

      3) a shared inbound flow for server-to-client responses, typically
      in response to a program-initiated or operator-initiated action at
      an engineering workstation in a control room.

      

      Every process actuator (i.e., mote that can directly manipulate
      the process) will also have another flow 4), analogous to 1) but
      in the outbound direction, from the control room to the field to
      transfer the computed actuator setting to the device. Such devices
      also have inbound flow 1) to transfer actuator status at the same
      periodic rate.

      

      If communication problems are experienced on flow 1), it is
      desirable to be able to use one or more of the other flows as a
      backup mechanism for inbound control traffic, whether full
      determinism can be maintained or not. Packet queuing priority
      definitely makes sense here, so that such traffic can leapfrog
      non-deterministic traffic in the output queue of the originating
      mote and of any intermediary relaying motes. As mentioned in 2),
      it may also make sense to use CSMA/CA to provide some slight
      statistical bias in channel access priority based on packet
      priority, at least for flows where the transaction template has a
      non-null CSMA/CA sensing interval before the scheduled Data PDU
      transmission of the transaction.

      

      The reason for priority on the alerts is that process alarms from
      class 1 - 2 devices, (or class 0 - 2 if class 0 uses wireless),
      would usually be configured to be higher priority than those for
      classes 3 - 5. (Some class 3 devices might also be assigned that
      higher alarm priority.) Where safety alarms are concerned, such as
      the "man down" alarm that Herman Storey mentioned on Thursday's
      call, those alarms would tend to use another flow 5), similar to
      2), with a very low expected rate but with dedicated slots to
      provide a clear virtual channel (to the extent possible). The time
      constants for such alarms are long enough (seconds) compared to
      much of the flow 1) traffic that the incremental cost of flow 5),
      which is so similar to flow 2), probably would not be very much,
      perhaps 2% of the total network capacity. It is tempting to just
      have a 3-way CSMA/CA interval for flow 2), but the reality of the
      CSMA/CA priority assessment mechanism is that it is very weak,
      given physical modem delays, inter-mote timing skews and the old
      hidden-node problem. Thus CSMA/CA prioritization does not seem
      reliable enough to trust for safety purposes.

      

      Of course a system will have other flows, many allocated on a
      demand basis in response to some occasional need, such as firmware
      download or captured waveform upload.

      

      The basic timing of continuous control loops it that the total
      delay from sensing the process to driving the actuator generally
      has to be less than twice the period of the loop. In such cases
      the needed control strategy is both relatively simple and
      relatively stable, However, if the total input-to-output delay
      exceeds twice the loop period, the control becomes much more
      difficult and less able to respond to fast transients. Jitter is a
      problem only when a process value message is delivered in the
      wrong cycle; it does not matter whether the delivery is at the 10%
      or 90% point in the proper cycle. Authenticated timestamping of
      the message, as occurs via the UDP transport nonce in ISA100.11a,
      provides a means of discarding process value messages that are
      delivered too late, thus converting those situations to ones of
      message loss. That is the desired way of handling late delivery,
      because the control loop is stable under message loss but not when
      the values are deliberately selectively delayed into the wrong
      delivery cycle. (Honeywell demonstrated years ago that it was
      possible to destablize most control loops with such deliberately
      jittered delivery.)

      

      -Tom

      =====

      On 2013.03.08 23:33, Thomas Watteyne wrote:
      
Michael,
        


        

        
I agree that the term flow is almost as overloaded as link
          or path. This is not a final term and we will have to come up
          with a better term. Suggestions?

        


        

        
If I get your point correctly, you are suggesting that
          there should be no packet priorities, only flows priority. In
          a TSCH context, this would translate into a slotframe per
          flow, where flow also incorporates the notion of priority.
          Correct? This is a very important discussion we started over
          the phone earlier today, but which we will continue Wednesday
          in Orlando. I hope you can be there.

        


        

        
Thomas

          

          
On Fri, Mar 8, 2013 at 6:55 PM,
            Michael Richardson <mcr+ietf@sandelman.ca>
            wrote:

            
How can a flow have high priority
              packets and low priority packets?

              

              Why are these two types of packets using the same DODAG?

            

          

        

      

      

      

      

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


    

    

  


--------------010207080501070102010107--

From tom.phinney@cox.net  Sat Mar  9 11:27:18 2013
Return-Path: 
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 2F25B21F86CD for <6tsch@ietfa.amsl.com>; Sat,  9 Mar 2013 11:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.708
X-Spam-Level: 
X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
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 xYUqRdg1rvIx for <6tsch@ietfa.amsl.com>; Sat,  9 Mar 2013 11:27:17 -0800 (PST)
Received: from fed1rmfepo202.cox.net (fed1rmfepo202.cox.net [68.230.241.147]) by ietfa.amsl.com (Postfix) with ESMTP id 199AA21F866E for <6tsch@ietf.org>; Sat,  9 Mar 2013 11:27:17 -0800 (PST)
Received: from fed1rmimpo209 ([68.230.241.160]) by fed1rmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130309192716.ITSJ1243.fed1rmfepo202.cox.net@fed1rmimpo209> for <6tsch@ietf.org>; Sat, 9 Mar 2013 14:27:16 -0500
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo209 with cox id 9XTD1l00F3gAAro01XTGCK; Sat, 09 Mar 2013 14:27:16 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A02020A.513B8D14.0096,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=SfMpgItu c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=6etX-ORWL8YA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=EaCufb_MCHMA:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=x5MetO17QSO3MrbJAl8A:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=4vB-4DCPJfMA:10 a=lZB815dzVvQA:10 a=JV_zEMxAglh9_qjN:21 a=XbbkJyn9Lk3nnnla:21 a=QN8VwI8zlsXhctRq:21 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <513B8D11.9050606@cox.net>
Date: Sat, 09 Mar 2013 12:27:13 -0700
From: Tom Phinney 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: 6tsch@ietf.org
References: 	<19015.1362797728@sandelman.ca>		<513AE660.2040403@cox.net> <513B733A.9010003@eecs.berkeley.edu>
In-Reply-To: <513B733A.9010003@eecs.berkeley.edu>
X-Enigmail-Version: 1.1.1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [6tsch] priority and priority
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney 
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Mar 2013 19:27:18 -0000



  
    
  
  
    Kris (et al),

      

      Thank you for your reply and general concurrence.

      

      In my post below I was objecting to the conclusion in the
      originally quoted interchange, recolored in
        red at the end below, that flow priority suffices. My
      example flow 2) is one in which packet priority makes sense WITHIN
      the flow. Note also my text in blue below,
      highlighting a similar conclusion for use of flows 2) and/or 3) as
      backup channels for flow 1) when flow 1) becomes too unreliable.

      

      My post below was an attempt to point out that queuing priority
      AND flow priority need not be disjoint approaches; in my opinion
      they can and should both exist concurrently in systems that deal
      with real-world problems, at least in the industrial and process
      automation markets. They each provide some functionality that the
      other lacks, giving an overall system that is superior in its
      performance of critical functions to one that restricts itself to
      flow priority, or to queuing priority, but without supporting
      both. My post below was an attempt to sketch a common scenario in
      that market where the two priority mechanisms interplay to provide
      a superior system.

      

      Perhaps my concept of flow differs from those of the original two
      correspondents. If so, I would appreciate instruction/correction.
      My scenario below was one where resources assigned to secondary
      flows would be used when the primary flow 1) fails. If others'
      notions of flow are not coupled to contracts and resource
      allocation in forwarding DL and NL routers, potentially including slot prioritization among
      concurrent slots, then what use is it?

      

      -Tom

      =====

    On 2013.03.09 10:36, Kris Pister wrote:
    

      
      Tom - I agree with everything that you wrote in the email below
      except the first sentence.  Perhaps I'm missing something, but it
      seems to me that your enumeration of various flows with different
      requirements fits quite well with the discussion fragment quoted
      at the end below.  Can you help me understand the differences?

      

      My bias is that we should have 

      {flow priority (equating to slotframe priority) OR link priority
      (TX, RX, uni-, multi-)} AND {packet priority}.

      

      ksjp

      

      
On 3/8/2013 11:36 PM, Tom Phinney
        wrote:

      

      

        
        I don't know what real-world use this technology is being
        designed to support, but the discussion fragments quoted at the
        end below seem to me to be moving away from reality.

        

        In the industrial automation world where I spent most of my
        career, it makes sense to have different inbound flows for
        differing purposes. Most sensor devices would have the following
        flows 1), 2) and 3):

        1) a dedicated inbound flow per field device (mote) for periodic
        deterministic control traffic, where the number of expected hops
        has to be small when the loop rate is high;

        2) a shared inbound flow for usually-infrequent alerts (i.e.,
        device events and process alarms), probably with at least
        2-level packet queuing priority, perhaps using CSMA/CA to
        provide some slight statistical bias in channel access priority
        based on packet priority;

        3) a shared inbound flow for server-to-client responses,
        typically in response to a program-initiated or
        operator-initiated action at an engineering workstation in a
        control room.

        

        Every process actuator (i.e., mote that can directly manipulate
        the process) will also have another flow 4), analogous to 1) but
        in the outbound direction, from the control room to the field to
        transfer the computed actuator setting to the device. Such
        devices also have inbound flow 1) to transfer actuator status at
        the same periodic rate.

        

        If communication problems are experienced on flow 1), it is desirable to be able to use one or more
          of the other flows as a backup mechanism for inbound control
          traffic, whether full determinism can be maintained or
        not. Packet queuing priority definitely
          makes sense here, so that such traffic can leapfrog
          non-deterministic traffic in the output queue of the
          originating mote and of any intermediary relaying motes.
        As mentioned in 2), it may also make sense to use CSMA/CA to
        provide some slight statistical bias in channel access priority
        based on packet priority, at least for flows where the
        transaction template has a non-null CSMA/CA sensing interval
        before the scheduled Data PDU transmission of the transaction.

        

        The reason for priority on the alerts is that process alarms
        from class 1 - 2 devices, (or class 0 - 2 if class 0 uses
        wireless), would usually be configured to be higher priority
        than those for classes 3 - 5. (Some class 3 devices might also
        be assigned that higher alarm priority.) Where safety alarms are
        concerned, such as the "man down" alarm that Herman Storey
        mentioned on Thursday's call, those alarms would tend to use
        another flow 5), similar to 2), with a very low expected rate
        but with dedicated slots to provide a clear virtual channel (to
        the extent possible). The time constants for such alarms are
        long enough (seconds) compared to much of the flow 1) traffic
        that the incremental cost of flow 5), which is so similar to
        flow 2), probably would not be very much, perhaps 2% of the
        total network capacity. It is tempting to just have a 3-way
        CSMA/CA interval for flow 2), but the reality of the CSMA/CA
        priority assessment mechanism is that it is very weak, given
        physical modem delays, inter-mote timing skews and the old
        hidden-node problem. Thus CSMA/CA prioritization does not seem
        reliable enough to trust for safety purposes.

        

        Of course a system will have other flows, many allocated on a
        demand basis in response to some occasional need, such as
        firmware download or captured waveform upload.

        

        The basic timing of continuous control loops it that the total
        delay from sensing the process to driving the actuator generally
        has to be less than twice the period of the loop. In such cases
        the needed control strategy is both relatively simple and
        relatively stable, However, if the total input-to-output delay
        exceeds twice the loop period, the control becomes much more
        difficult and less able to respond to fast transients. Jitter is
        a problem only when a process value message is delivered in the
        wrong cycle; it does not matter whether the delivery is at the
        10% or 90% point in the proper cycle. Authenticated timestamping
        of the message, as occurs via the UDP transport nonce in
        ISA100.11a, provides a means of discarding process value
        messages that are delivered too late, thus converting those
        situations to ones of message loss. That is the desired way of
        handling late delivery, because the control loop is stable under
        message loss but not when the values are deliberately
        selectively delayed into the wrong delivery cycle. (Honeywell
        demonstrated years ago that it was possible to destablize most
        control loops with such deliberately jittered delivery.)

        

        -Tom

        =====

        On 2013.03.08 23:33, Thomas Watteyne wrote:
        
Michael,
          


          

          
I agree that the term flow is almost as overloaded as
            link or path. This is not a final term and we will have to
            come up with a better term. Suggestions?

          


          

          
If I get your point correctly, you are suggesting that
             there should be no packet priorities,
              only flows priority. In a TSCH context, this would
            translate into a slotframe per flow, where flow also
            incorporates the notion of priority. Correct? This is a very
            important discussion we started over the phone earlier
            today, but which we will continue Wednesday in Orlando. I
            hope you can be there.

          


          

          
Thomas

            

            
On Fri, Mar 8, 2013 at 6:55 PM,
              Michael Richardson <mcr+ietf@sandelman.ca>
              wrote:

              
How can a flow
                  have high priority packets and low priority packets?

                

                Why are these two types of packets using the same DODAG?

              

            

          

        

        

        

        

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


      

      

      

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


    

  


From pister@eecs.berkeley.edu  Sat Mar  9 12:22:51 2013
Return-Path: 
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 794E821F84BE for <6tsch@ietfa.amsl.com>; Sat,  9 Mar 2013 12:22:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level: 
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 uUKSnGAbN1RN for <6tsch@ietfa.amsl.com>; Sat,  9 Mar 2013 12:22:50 -0800 (PST)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 14A2A21F84B2 for <6tsch@ietf.org>; Sat,  9 Mar 2013 12:22:50 -0800 (PST)
Received: from c-98-210-49-50.hsd1.ca.comcast.net ([98.210.49.50] helo=[192.168.1.100]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1UEQI4-0008P1-4i; Sat, 09 Mar 2013 12:22:49 -0800
Message-ID: <513B9A0A.3090501@eecs.berkeley.edu>
Date: Sat, 09 Mar 2013 12:22:34 -0800
From: Kris Pister 
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Tom Phinney 
References: 	<19015.1362797728@sandelman.ca>		<513AE660.2040403@cox.net> <513B733A.9010003@eecs.berkeley.edu> <513B8D11.9050606@cox.net>
In-Reply-To: <513B8D11.9050606@cox.net>
Content-Type: multipart/alternative; boundary="------------010902060308080801010806"
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] priority and priority
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Mar 2013 20:22:51 -0000

This is a multi-part message in MIME format.
--------------010902060308080801010806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

got it.  I think that you and I are pretty closely aligned then.

ksjp

On 3/9/2013 11:27 AM, Tom Phinney wrote:
> Kris (et al),
>
> Thank you for your reply and general concurrence.
>
> In my post below I was objecting to the conclusion in the originally 
> quoted interchange, recolored in red at the end below, that flow 
> priority suffices. My example flow 2) is one in which packet priority 
> makes sense WITHIN the flow. Note also my text in blue below, 
> highlighting a similar conclusion for use of flows 2) and/or 3) as 
> backup channels for flow 1) when flow 1) becomes too unreliable.
>
> My post below was an attempt to point out that queuing priority AND 
> flow priority need not be disjoint approaches; in my opinion they can 
> and should both exist concurrently in systems that deal with 
> real-world problems, at least in the industrial and process automation 
> markets. They each provide some functionality that the other lacks, 
> giving an overall system that is superior in its performance of 
> critical functions to one that restricts itself to flow priority, or 
> to queuing priority, but without supporting both. My post below was an 
> attempt to sketch a common scenario in that market where the two 
> priority mechanisms interplay to provide a superior system.
>
> Perhaps my concept of flow differs from those of the original two 
> correspondents. If so, I would appreciate instruction/correction. My 
> scenario below was one where resources assigned to secondary flows 
> would be used when the primary flow 1) fails. If others' notions of 
> flow are not coupled to contracts and resource allocation in 
> forwarding DL and NL routers, potentially including slot 
> prioritization among concurrent slots, then what use is it?
>
> -Tom
> =====
> On 2013.03.09 10:36, Kris Pister wrote:
>> Tom - I agree with everything that you wrote in the email below 
>> except the first sentence.  Perhaps I'm missing something, but it 
>> seems to me that your enumeration of various flows with different 
>> requirements fits quite well with the discussion fragment quoted at 
>> the end below.  Can you help me understand the differences?
>>
>> My bias is that we should have
>> {flow priority (equating to slotframe priority) OR link priority (TX, 
>> RX, uni-, multi-)} AND {packet priority}.
>>
>> ksjp
>>
>> On 3/8/2013 11:36 PM, Tom Phinney wrote:
>>> I don't know what real-world use this technology is being designed 
>>> to support, but the discussion fragments quoted at the end below 
>>> seem to me to be moving away from reality.
>>>
>>> In the industrial automation world where I spent most of my career, 
>>> it makes sense to have different inbound flows for differing 
>>> purposes. Most sensor devices would have the following flows 1), 2) 
>>> and 3):
>>> 1) a dedicated inbound flow per field device (mote) for periodic 
>>> deterministic control traffic, where the number of expected hops has 
>>> to be small when the loop rate is high;
>>> 2) a shared inbound flow for usually-infrequent alerts (i.e., device 
>>> events and process alarms), probably with at least 2-level packet 
>>> queuing priority, perhaps using CSMA/CA to provide some slight 
>>> statistical bias in channel access priority based on packet priority;
>>> 3) a shared inbound flow for server-to-client responses, typically 
>>> in response to a program-initiated or operator-initiated action at 
>>> an engineering workstation in a control room.
>>>
>>> Every process actuator (i.e., mote that can directly manipulate the 
>>> process) will also have another flow 4), analogous to 1) but in the 
>>> outbound direction, from the control room to the field to transfer 
>>> the computed actuator setting to the device. Such devices also have 
>>> inbound flow 1) to transfer actuator status at the same periodic rate.
>>>
>>> If communication problems are experienced on flow 1), it is 
>>> desirable to be able to use one or more of the other flows as a 
>>> backup mechanism for inbound control traffic, whether full 
>>> determinism can be maintained or not. Packet queuing priority 
>>> definitely makes sense here, so that such traffic can leapfrog 
>>> non-deterministic traffic in the output queue of the originating 
>>> mote and of any intermediary relaying motes. As mentioned in 2), it 
>>> may also make sense to use CSMA/CA to provide some slight 
>>> statistical bias in channel access priority based on packet 
>>> priority, at least for flows where the transaction template has a 
>>> non-null CSMA/CA sensing interval before the scheduled Data PDU 
>>> transmission of the transaction.
>>>
>>> The reason for priority on the alerts is that process alarms from 
>>> class 1 - 2 devices, (or class 0 - 2 if class 0 uses wireless), 
>>> would usually be configured to be higher priority than those for 
>>> classes 3 - 5. (Some class 3 devices might also be assigned that 
>>> higher alarm priority.) Where safety alarms are concerned, such as 
>>> the "man down" alarm that Herman Storey mentioned on Thursday's 
>>> call, those alarms would tend to use another flow 5), similar to 2), 
>>> with a very low expected rate but with dedicated slots to provide a 
>>> clear virtual channel (to the extent possible). The time constants 
>>> for such alarms are long enough (seconds) compared to much of the 
>>> flow 1) traffic that the incremental cost of flow 5), which is so 
>>> similar to flow 2), probably would not be very much, perhaps 2% of 
>>> the total network capacity. It is tempting to just have a 3-way 
>>> CSMA/CA interval for flow 2), but the reality of the CSMA/CA 
>>> priority assessment mechanism is that it is very weak, given 
>>> physical modem delays, inter-mote timing skews and the old 
>>> hidden-node problem. Thus CSMA/CA prioritization does not seem 
>>> reliable enough to trust for safety purposes.
>>>
>>> Of course a system will have other flows, many allocated on a demand 
>>> basis in response to some occasional need, such as firmware download 
>>> or captured waveform upload.
>>>
>>> The basic timing of continuous control loops it that the total delay 
>>> from sensing the process to driving the actuator generally has to be 
>>> less than twice the period of the loop. In such cases the needed 
>>> control strategy is both relatively simple and relatively stable, 
>>> However, if the total input-to-output delay exceeds twice the loop 
>>> period, the control becomes much more difficult and less able to 
>>> respond to fast transients. Jitter is a problem only when a process 
>>> value message is delivered in the wrong cycle; it does not matter 
>>> whether the delivery is at the 10% or 90% point in the proper cycle. 
>>> Authenticated timestamping of the message, as occurs via the UDP 
>>> transport nonce in ISA100.11a, provides a means of discarding 
>>> process value messages that are delivered too late, thus converting 
>>> those situations to ones of message loss. That is the desired way of 
>>> handling late delivery, because the control loop is stable under 
>>> message loss but not when the values are deliberately selectively 
>>> delayed into the wrong delivery cycle. (Honeywell demonstrated years 
>>> ago that it was possible to destablize most control loops with such 
>>> deliberately jittered delivery.)
>>>
>>> -Tom
>>> =====
>>> On 2013.03.08 23:33, Thomas Watteyne wrote:
>>>> Michael,
>>>>
>>>> I agree that the term flow is almost as overloaded as link or path. 
>>>> This is not a final term and we will have to come up with a better 
>>>> term. Suggestions?
>>>>
>>>> If I get your point correctly, you are suggesting that there should 
>>>> be no packet priorities, only flows priority. In a TSCH context, 
>>>> this would translate into a slotframe per flow, where flow also 
>>>> incorporates the notion of priority. Correct? This is a very 
>>>> important discussion we started over the phone earlier today, but 
>>>> which we will continue Wednesday in Orlando. I hope you can be there.
>>>>
>>>> Thomas
>>>>
>>>> On Fri, Mar 8, 2013 at 6:55 PM, Michael Richardson 
>>>> > wrote:
>>>>
>>>>     How can a flow have high priority packets and low priority packets?
>>>>
>>>>     Why are these two types of packets using the same DODAG?
>>>>
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


--------------010902060308080801010806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    got it.  I think that you and I are pretty closely aligned then.

    

    ksjp

    

    
On 3/9/2013 11:27 AM, Tom Phinney
      wrote:

    

    

      
      Kris (et al),

        

        Thank you for your reply and general concurrence.

        

        In my post below I was objecting to the conclusion in the
        originally quoted interchange, recolored
          in red at the end below, that flow priority suffices.
        My example flow 2) is one in which packet priority makes sense
        WITHIN the flow. Note also my text in
          blue below, highlighting a similar conclusion for use
        of flows 2) and/or 3) as backup channels for flow 1) when flow
        1) becomes too unreliable.

        

        My post below was an attempt to point out that queuing priority
        AND flow priority need not be disjoint approaches; in my opinion
        they can and should both exist concurrently in systems that deal
        with real-world problems, at least in the industrial and process
        automation markets. They each provide some functionality that
        the other lacks, giving an overall system that is superior in
        its performance of critical functions to one that restricts
        itself to flow priority, or to queuing priority, but without
        supporting both. My post below was an attempt to sketch a common
        scenario in that market where the two priority mechanisms
        interplay to provide a superior system.

        

        Perhaps my concept of flow differs from those of the original
        two correspondents. If so, I would appreciate
        instruction/correction. My scenario below was one where
        resources assigned to secondary flows would be used when the
        primary flow 1) fails. If others' notions of flow are not
        coupled to contracts and resource allocation in forwarding DL
        and NL routers, potentially including
        slot prioritization among concurrent slots, then what use is it?

        

        -Tom

        =====

      On 2013.03.09 10:36, Kris Pister wrote:
      

        
        Tom - I agree with everything that you wrote in the email below
        except the first sentence.  Perhaps I'm missing something, but
        it seems to me that your enumeration of various flows with
        different requirements fits quite well with the discussion
        fragment quoted at the end below.  Can you help me understand
        the differences?

        

        My bias is that we should have 

        {flow priority (equating to slotframe priority) OR link priority
        (TX, RX, uni-, multi-)} AND {packet priority}.

        

        ksjp

        

        
On 3/8/2013 11:36 PM, Tom Phinney
          wrote:

        

        

          
          I don't know what real-world use this technology is being
          designed to support, but the discussion fragments quoted at
          the end below seem to me to be moving away from reality.

          

          In the industrial automation world where I spent most of my
          career, it makes sense to have different inbound flows for
          differing purposes. Most sensor devices would have the
          following flows 1), 2) and 3):

          1) a dedicated inbound flow per field device (mote) for
          periodic deterministic control traffic, where the number of
          expected hops has to be small when the loop rate is high;

          2) a shared inbound flow for usually-infrequent alerts (i.e.,
          device events and process alarms), probably with at least
          2-level packet queuing priority, perhaps using CSMA/CA to
          provide some slight statistical bias in channel access
          priority based on packet priority;

          3) a shared inbound flow for server-to-client responses,
          typically in response to a program-initiated or
          operator-initiated action at an engineering workstation in a
          control room.

          

          Every process actuator (i.e., mote that can directly
          manipulate the process) will also have another flow 4),
          analogous to 1) but in the outbound direction, from the
          control room to the field to transfer the computed actuator
          setting to the device. Such devices also have inbound flow 1)
          to transfer actuator status at the same periodic rate.

          

          If communication problems are experienced on flow 1), it is desirable to be able to use one or
            more of the other flows as a backup mechanism for inbound
            control traffic, whether full determinism can be
          maintained or not. Packet queuing
            priority definitely makes sense here, so that such traffic
            can leapfrog non-deterministic traffic in the output queue
            of the originating mote and of any intermediary relaying
            motes. As mentioned in 2), it may also make sense to
          use CSMA/CA to provide some slight statistical bias in channel
          access priority based on packet priority, at least for flows
          where the transaction template has a non-null CSMA/CA sensing
          interval before the scheduled Data PDU transmission of the
          transaction.

          

          The reason for priority on the alerts is that process alarms
          from class 1 - 2 devices, (or class 0 - 2 if class 0 uses
          wireless), would usually be configured to be higher priority
          than those for classes 3 - 5. (Some class 3 devices might also
          be assigned that higher alarm priority.) Where safety alarms
          are concerned, such as the "man down" alarm that Herman Storey
          mentioned on Thursday's call, those alarms would tend to use
          another flow 5), similar to 2), with a very low expected rate
          but with dedicated slots to provide a clear virtual channel
          (to the extent possible). The time constants for such alarms
          are long enough (seconds) compared to much of the flow 1)
          traffic that the incremental cost of flow 5), which is so
          similar to flow 2), probably would not be very much, perhaps
          2% of the total network capacity. It is tempting to just have
          a 3-way CSMA/CA interval for flow 2), but the reality of the
          CSMA/CA priority assessment mechanism is that it is very weak,
          given physical modem delays, inter-mote timing skews and the
          old hidden-node problem. Thus CSMA/CA prioritization does not
          seem reliable enough to trust for safety purposes.

          

          Of course a system will have other flows, many allocated on a
          demand basis in response to some occasional need, such as
          firmware download or captured waveform upload.

          

          The basic timing of continuous control loops it that the total
          delay from sensing the process to driving the actuator
          generally has to be less than twice the period of the loop. In
          such cases the needed control strategy is both relatively
          simple and relatively stable, However, if the total
          input-to-output delay exceeds twice the loop period, the
          control becomes much more difficult and less able to respond
          to fast transients. Jitter is a problem only when a process
          value message is delivered in the wrong cycle; it does not
          matter whether the delivery is at the 10% or 90% point in the
          proper cycle. Authenticated timestamping of the message, as
          occurs via the UDP transport nonce in ISA100.11a, provides a
          means of discarding process value messages that are delivered
          too late, thus converting those situations to ones of message
          loss. That is the desired way of handling late delivery,
          because the control loop is stable under message loss but not
          when the values are deliberately selectively delayed into the
          wrong delivery cycle. (Honeywell demonstrated years ago that
          it was possible to destablize most control loops with such
          deliberately jittered delivery.)

          

          -Tom

          =====

          On 2013.03.08 23:33, Thomas Watteyne wrote:
          
Michael,
            


            

            
I agree that the term flow is almost as overloaded as
              link or path. This is not a final term and we will have to
              come up with a better term. Suggestions?

            


            

            
If I get your point correctly, you are suggesting that
               there should be no packet
                priorities, only flows priority. In a TSCH
              context, this would translate into a slotframe per flow,
              where flow also incorporates the notion of priority.
              Correct? This is a very important discussion we started
              over the phone earlier today, but which we will continue
              Wednesday in Orlando. I hope you can be there.

            


            

            
Thomas

              

              
On Fri, Mar 8, 2013 at 6:55 PM,
                Michael Richardson <mcr+ietf@sandelman.ca>
                wrote:

                
How can a
                    flow have high priority packets and low priority
                    packets?

                  

                  Why are these two types of packets using the same
                  DODAG?

                

              

            

          

          

          

          

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


        

        

        

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


      

      

      

      

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


    

    

  


--------------010902060308080801010806--

From svshah@cisco.com  Sat Mar  9 21:04:27 2013
Return-Path: 
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 3F83C21F851C for <6tsch@ietfa.amsl.com>; Sat,  9 Mar 2013 21:04:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.598
X-Spam-Level: 
X-Spam-Status: No, score=-11.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 y8FeA1YAzu3f for <6tsch@ietfa.amsl.com>; Sat,  9 Mar 2013 21:04:25 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C454C21F8633 for <6tsch@ietf.org>; Sat,  9 Mar 2013 21:04:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25316; q=dns/txt; s=iport; t=1362891865; x=1364101465; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=rhDTLp6wCcYeQWDwwsDLU+Vl/GWD2Nspxzcyzf8nk0A=; b=HzZn7NpPNdvlD6/yFY7OGNBCKHLNPAkoT7dNhoduMVy4x+sAil433cDi BMoQbsUbXXdMV3Ln1qzFOyCFQ2C3VdS7GkRcp00qROT8WRoTrk4K8gkrZ jstMj9ltk4UVDcTzTZ/FmtPoxyO9d8FGepeAaqTkGo5hNwv2tolCVD2Ui U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAM4TPFGtJXG+/2dsb2JhbABDhBrANYFeFnSCKwEBAQQBAQEXVB0BCBEDAQILHS4LFAkIAgQBCQkIAYgKDLwYjUQJgRAgBhIGgllhA6dKgwqBczU
X-IronPort-AV: E=Sophos;i="4.84,817,1355097600";  d="scan'208,217";a="185762275"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 10 Mar 2013 05:04:23 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2A54MCL022300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Mar 2013 05:04:22 GMT
Received: from xmb-aln-x10.cisco.com ([169.254.5.82]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Sat, 9 Mar 2013 23:04:22 -0600
From: "Shitanshu Shah (svshah)" 
To: Tom Phinney , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] priority and priority
Thread-Index: AQHOG89uote0gTOlJkW2KjLq2WdT9ZidEBIAgAA84QCAABGAAIAAp+kAgAAezYCAABskgA==
Date: Sun, 10 Mar 2013 05:04:22 +0000
Message-ID: 
In-Reply-To: <513B8D11.9050606@cox.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [10.21.147.180]
Content-Type: multipart/alternative; boundary="_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151D0155xmbalnx10ciscoc_"
MIME-Version: 1.0
Subject: Re: [6tsch] priority and priority
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 Mar 2013 05:04:27 -0000

--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151D0155xmbalnx10ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Tom, All,

In general I agree with your assessment for need for packet priority.

If forwarding service required is similar to all packets for a given class,=
 packet priority is all what is required for such services. Like traffic cl=
asses in your example for deterministic class, alerts, server-client respon=
se etc..  Treating such class of traffic at the aggregate level per packet =
priority (eg. Based on certain L3 or L2 level code-points) is what is neede=
d for forwarding(queuing) service.

I also lack to understand, what is the definition of flow, is it micro-flow=
 that has been eluded before?
For micro-flows belonging to the same service class (eg. Belonging to alert=
 class), what kind of differentiation needed for different flows within tha=
t class? I would imagine that queuing is expensive and scarce resources in =
these systems as well just like it is for traditional Layer2 switches (at t=
he least in the hardware). Thus probably very expensive to imagine as many =
queues as many set of flows with different priority.

However, a sort of differentiation that can be imagined at flow level may b=
e for other parameters (but not queuing behavior). For example, limiting ra=
te of a flow that is fed in to the queuing system.excessive traffic to be d=
ropped or re-marked to lower priority code-point. Or during congestion drop=
 traffic from certain flows over others.

I understand RSVP provides a way to enable integrated queuing service. At t=
he same time, RSVP also has a way to enable reservation based on Diffserv. =
It is later that I am trying to highlight where packet priority is used for=
 the forwarding decision, and flow classification may be used to constrain =
other parameters like rate.

Taking deterministic class in particular,
As I am not so much familiar with Industrial Automation, what I am not clea=
r if for a given PAN, could there be different set of flows with different =
deterministic parameters? If there are then I can see some impact to queuin=
g discipline and packet priority itself may not be sufficient. But I am not=
 sure why there would be an application (PAN) with devices with different s=
et of deterministic flows. I can also see them causing conflicts when it co=
mes to channel reservation.

Regards,
Shitanshu


From: Tom Phinney >
Reply-To: Tom Phinney >
Date: Saturday, March 9, 2013 11:27 AM
To: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] priority and priority

Kris (et al),

Thank you for your reply and general concurrence.

In my post below I was objecting to the conclusion in the originally quoted=
 interchange, recolored in red at the end below, that flow priority suffice=
s. My example flow 2) is one in which packet priority makes sense WITHIN th=
e flow. Note also my text in blue below, highlighting a similar conclusion =
for use of flows 2) and/or 3) as backup channels for flow 1) when flow 1) b=
ecomes too unreliable.

My post below was an attempt to point out that queuing priority AND flow pr=
iority need not be disjoint approaches; in my opinion they can and should b=
oth exist concurrently in systems that deal with real-world problems, at le=
ast in the industrial and process automation markets. They each provide som=
e functionality that the other lacks, giving an overall system that is supe=
rior in its performance of critical functions to one that restricts itself =
to flow priority, or to queuing priority, but without supporting both. My p=
ost below was an attempt to sketch a common scenario in that market where t=
he two priority mechanisms interplay to provide a superior system.

Perhaps my concept of flow differs from those of the original two correspon=
dents. If so, I would appreciate instruction/correction. My scenario below =
was one where resources assigned to secondary flows would be used when the =
primary flow 1) fails. If others' notions of flow are not coupled to contra=
cts and resource allocation in forwarding DL and NL routers, potentially in=
cluding slot prioritization among concurrent slots, then what use is it?

-Tom
=3D=3D=3D=3D=3D
On 2013.03.09 10:36, Kris Pister wrote:
Tom - I agree with everything that you wrote in the email below except the =
first sentence.  Perhaps I'm missing something, but it seems to me that you=
r enumeration of various flows with different requirements fits quite well =
with the discussion fragment quoted at the end below.  Can you help me unde=
rstand the differences?

My bias is that we should have
{flow priority (equating to slotframe priority) OR link priority (TX, RX, u=
ni-, multi-)} AND {packet priority}.

ksjp

On 3/8/2013 11:36 PM, Tom Phinney wrote:
I don't know what real-world use this technology is being designed to suppo=
rt, but the discussion fragments quoted at the end below seem to me to be m=
oving away from reality.

In the industrial automation world where I spent most of my career, it make=
s sense to have different inbound flows for differing purposes. Most sensor=
 devices would have the following flows 1), 2) and 3):
1) a dedicated inbound flow per field device (mote) for periodic determinis=
tic control traffic, where the number of expected hops has to be small when=
 the loop rate is high;
2) a shared inbound flow for usually-infrequent alerts (i.e., device events=
 and process alarms), probably with at least 2-level packet queuing priorit=
y, perhaps using CSMA/CA to provide some slight statistical bias in channel=
 access priority based on packet priority;
3) a shared inbound flow for server-to-client responses, typically in respo=
nse to a program-initiated or operator-initiated action at an engineering w=
orkstation in a control room.

Every process actuator (i.e., mote that can directly manipulate the process=
) will also have another flow 4), analogous to 1) but in the outbound direc=
tion, from the control room to the field to transfer the computed actuator =
setting to the device. Such devices also have inbound flow 1) to transfer a=
ctuator status at the same periodic rate.

If communication problems are experienced on flow 1), it is desirable to be=
 able to use one or more of the other flows as a backup mechanism for inbou=
nd control traffic, whether full determinism can be maintained or not. Pack=
et queuing priority definitely makes sense here, so that such traffic can l=
eapfrog non-deterministic traffic in the output queue of the originating mo=
te and of any intermediary relaying motes. As mentioned in 2), it may also =
make sense to use CSMA/CA to provide some slight statistical bias in channe=
l access priority based on packet priority, at least for flows where the tr=
ansaction template has a non-null CSMA/CA sensing interval before the sched=
uled Data PDU transmission of the transaction.

The reason for priority on the alerts is that process alarms from class 1 -=
 2 devices, (or class 0 - 2 if class 0 uses wireless), would usually be con=
figured to be higher priority than those for classes 3 - 5. (Some class 3 d=
evices might also be assigned that higher alarm priority.) Where safety ala=
rms are concerned, such as the "man down" alarm that Herman Storey mentione=
d on Thursday's call, those alarms would tend to use another flow 5), simil=
ar to 2), with a very low expected rate but with dedicated slots to provide=
 a clear virtual channel (to the extent possible). The time constants for s=
uch alarms are long enough (seconds) compared to much of the flow 1) traffi=
c that the incremental cost of flow 5), which is so similar to flow 2), pro=
bably would not be very much, perhaps 2% of the total network capacity. It =
is tempting to just have a 3-way CSMA/CA interval for flow 2), but the real=
ity of the CSMA/CA priority assessment mechanism is that it is very weak, g=
iven physical modem delays, inter-mote timing skews and the old hidden-node=
 problem. Thus CSMA/CA prioritization does not seem reliable enough to trus=
t for safety purposes.

Of course a system will have other flows, many allocated on a demand basis =
in response to some occasional need, such as firmware download or captured =
waveform upload.

The basic timing of continuous control loops it that the total delay from s=
ensing the process to driving the actuator generally has to be less than tw=
ice the period of the loop. In such cases the needed control strategy is bo=
th relatively simple and relatively stable, However, if the total input-to-=
output delay exceeds twice the loop period, the control becomes much more d=
ifficult and less able to respond to fast transients. Jitter is a problem o=
nly when a process value message is delivered in the wrong cycle; it does n=
ot matter whether the delivery is at the 10% or 90% point in the proper cyc=
le. Authenticated timestamping of the message, as occurs via the UDP transp=
ort nonce in ISA100.11a, provides a means of discarding process value messa=
ges that are delivered too late, thus converting those situations to ones o=
f message loss. That is the desired way of handling late delivery, because =
the control loop is stable under message loss but not when the values are d=
eliberately selectively delayed into the wrong delivery cycle. (Honeywell d=
emonstrated years ago that it was possible to destablize most control loops=
 with such deliberately jittered delivery.)

-Tom
=3D=3D=3D=3D=3D
On 2013.03.08 23:33, Thomas Watteyne wrote:
Michael,

I agree that the term flow is almost as overloaded as link or path. This is=
 not a final term and we will have to come up with a better term. Suggestio=
ns?

If I get your point correctly, you are suggesting that there should be no p=
acket priorities, only flows priority. In a TSCH context, this would transl=
ate into a slotframe per flow, where flow also incorporates the notion of p=
riority. Correct? This is a very important discussion we started over the p=
hone earlier today, but which we will continue Wednesday in Orlando. I hope=
 you can be there.

Thomas

On Fri, Mar 8, 2013 at 6:55 PM, Michael Richardson > wrote:
How can a flow have high priority packets and low priority packets?

Why are these two types of packets using the same DODAG?



_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/=
6tsch



_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/=
6tsch

--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151D0155xmbalnx10ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <7E9ED461C8C7A047B0B5A542C5EC9139@cisco.com>
Content-Transfer-Encoding: quoted-printable












Hi Tom, All,







In general I agree with your assessment for need for packet priority.<=
/div>






If forwarding service required is similar to all packets for a given c=
lass, packet priority is all what is required for such services. Like =
traffic classes in your example for deterministic class, alerts, server-cli=
ent response etc..  Treating such class
 of traffic at the aggregate level per packet priority (eg. Based on certai=
n L3 or L2 level code-points) is what is needed for forwarding(queuing) ser=
vice.







I also lack to understand, what is the definition of flow, is it micro=
-flow that has been eluded before?


For micro-flows belonging to the same service class (eg. Belonging to =
alert class), what kind of differentiation needed for different flows withi=
n that class? I would imagine that queuing is expensive and scarce resource=
s in these systems as well just
 like it is for traditional Layer2 switches (at the least in the hardware).=
 Thus probably very expensive to imagine as many queues as many set of flow=
s with different priority.







However, a sort of differentiation that can be imagined at flow level =
may be for other parameters (but not queuing behavior). For example, limiti=
ng rate of a flow that is fed in to the queuing system.excessive traffic to=
 be dropped or re-marked to lower
 priority code-point. Or during congestion drop traffic from certain flows =
over others.







I understand RSVP provides a way to enable integrated queuing service.=
 At the same time, RSVP also has a way to enable reservation based on Diffs=
erv. It is later that I am trying to highlight where packet priority is use=
d for the forwarding decision, and
 flow classification may be used to constrain other parameters like rate.






Taking deterministic class in particular,


As I am not so much familiar with Industrial Automation, what I am not=
 clear if for a given PAN, could there be different set of flows with diffe=
rent deterministic parameters? If there are then I can see some impact to q=
ueuing discipline and packet priority
 itself may not be sufficient. But I am not sure why there would be an appl=
ication (PAN) with devices with different set of deterministic flows. I can=
 also see them causing conflicts when it comes to channel reservation.






Regards,


Shitanshu














From: Tom Phinney <tom.phinney@cox.net>

Reply-To: Tom Phinney <tom.phinney@cox.net>

Date: Saturday, March 9, 2013 11:27=
 AM

To: "6tsch@ietf.org" <6ts=
ch@ietf.org>

Subject: Re: [6tsch] priority and p=
riority











Kris (et al)=
,



Thank you for your reply and general concurrence.



In my post below I was objecting to the conclusion in the originally quoted=
 interchange,
recolored in red at the end below, that flow=
 priority suffices. My example flow 2) is one in which packet priority make=
s sense WITHIN the flow. Note also my text
in blue below, highlighting a similar conclu=
sion for use of flows 2) and/or 3) as backup channels for flow 1) when flow=
 1) becomes too unreliable.



My post below was an attempt to point out that queuing priority AND flow pr=
iority need not be disjoint approaches; in my opinion they can and should b=
oth exist concurrently in systems that deal with real-world problems, at le=
ast in the industrial and process
 automation markets. They each provide some functionality that the other la=
cks, giving an overall system that is superior in its performance of critic=
al functions to one that restricts itself to flow priority, or to queuing p=
riority, but without supporting
 both. My post below was an attempt to sketch a common scenario in that mar=
ket where the two priority mechanisms interplay to provide a superior syste=
m.



Perhaps my concept of flow differs from those of the original two correspon=
dents. If so, I would appreciate instruction/correction. My scenario below =
was one where resources assigned to secondary flows would be used when the =
primary flow 1) fails. If others'
 notions of flow are not coupled to contracts and resource allocation in fo=
rwarding DL and NL routers,
potentially including slot prioritization among=
 concurrent slots, then what use is it?



-Tom

=3D=3D=3D=3D=3D

On 2013.03.09 10:36, Kris Pister wrote:

T=
om - I agree with everything that you wrote in the email below except the f=
irst sentence.  Perhaps I'm missing something, but it seems to me that=
 your enumeration of various flows with different
 requirements fits quite well with the discussion fragment quoted at the en=
d below.  Can you help me understand the differences?



My bias is that we should have 

{flow priority (equating to slotframe priority) OR link priority (TX, RX, u=
ni-, multi-)} AND {packet priority}.



ksjp




On 3/8/2013 11:36 PM, Tom Phinney wrote:




I don't kno=
w what real-world use this technology is being designed to support, but the=
 discussion fragments quoted at the end below seem to me to be moving away =
from reality.



In the industrial automation world where I spent most of my career, it make=
s sense to have different inbound flows for differing purposes. Most sensor=
 devices would have the following flows 1), 2) and 3):

1) a dedicated inbound flow per field device (mote) for periodic determinis=
tic control traffic, where the number of expected hops has to be small when=
 the loop rate is high;

2) a shared inbound flow for usually-infrequent alerts (i.e., device events=
 and process alarms), probably with at least 2-level packet queuing priorit=
y, perhaps using CSMA/CA to provide some slight statistical bias in channel=
 access priority based on packet
 priority;

3) a shared inbound flow for server-to-client responses, typically in respo=
nse to a program-initiated or operator-initiated action at an engineering w=
orkstation in a control room.



Every process actuator (i.e., mote that can directly manipulate the process=
) will also have another flow 4), analogous to 1) but in the outbound direc=
tion, from the control room to the field to transfer the computed actuator =
setting to the device. Such devices
 also have inbound flow 1) to transfer actuator status at the same periodic=
 rate.



If communication problems are experienced on flow 1), it is desirable to be able to use one or more of the other flows as a ba=
ckup mechanism for inbound control traffic, whether full determinism=
 can be maintained or not.
Packet queuing priority definitely makes sense here=
, so that such traffic can leapfrog non-deterministic traffic in the output=
 queue of the originating mote and of any intermediary relaying motes. As mentioned in 2), it may also
 make sense to use CSMA/CA to provide some slight statistical bias in chann=
el access priority based on packet priority, at least for flows where the t=
ransaction template has a non-null CSMA/CA sensing interval before the sche=
duled Data PDU transmission of the
 transaction.



The reason for priority on the alerts is that process alarms from class 1 -=
 2 devices, (or class 0 - 2 if class 0 uses wireless), would usually be con=
figured to be higher priority than those for classes 3 - 5. (Some class 3 d=
evices might also be assigned that
 higher alarm priority.) Where safety alarms are concerned, such as the &qu=
ot;man down" alarm that Herman Storey mentioned on Thursday's call, th=
ose alarms would tend to use another flow 5), similar to 2), with a very lo=
w expected rate but with dedicated slots to
 provide a clear virtual channel (to the extent possible). The time constan=
ts for such alarms are long enough (seconds) compared to much of the flow 1=
) traffic that the incremental cost of flow 5), which is so similar to flow=
 2), probably would not be very
 much, perhaps 2% of the total network capacity. It is tempting to just hav=
e a 3-way CSMA/CA interval for flow 2), but the reality of the CSMA/CA prio=
rity assessment mechanism is that it is very weak, given physical modem del=
ays, inter-mote timing skews and
 the old hidden-node problem. Thus CSMA/CA prioritization does not seem rel=
iable enough to trust for safety purposes.



Of course a system will have other flows, many allocated on a demand basis =
in response to some occasional need, such as firmware download or captured =
waveform upload.



The basic timing of continuous control loops it that the total delay from s=
ensing the process to driving the actuator generally has to be less than tw=
ice the period of the loop. In such cases the needed control strategy is bo=
th relatively simple and relatively
 stable, However, if the total input-to-output delay exceeds twice the loop=
 period, the control becomes much more difficult and less able to respond t=
o fast transients. Jitter is a problem only when a process value message is=
 delivered in the wrong cycle; it
 does not matter whether the delivery is at the 10% or 90% point in the pro=
per cycle. Authenticated timestamping of the message, as occurs via the UDP=
 transport nonce in ISA100.11a, provides a means of discarding process valu=
e messages that are delivered too
 late, thus converting those situations to ones of message loss. That is th=
e desired way of handling late delivery, because the control loop is stable=
 under message loss but not when the values are deliberately selectively de=
layed into the wrong delivery cycle.
 (Honeywell demonstrated years ago that it was possible to destablize most =
control loops with such deliberately jittered delivery.)



-Tom

=3D=3D=3D=3D=3D

On 2013.03.08 23:33, Thomas Watteyne wrote:


Michael,






I agree that the term flow is almost as overloaded as link or path. Th=
is is not a final term and we will have to come up with a better term. Sugg=
estions?







If I get your point correctly, you are suggesting that 
there should be no packet priorities, only flows priority. In a TSCH=
 context, this would translate into a slotframe per flow, where flow also i=
ncorporates the notion of priority. Correct? This is a very important discu=
ssion we started over the phone
 earlier today, but which we will continue Wednesday in Orlando. I hope you=
 can be there.







Thomas




On Fri, Mar 8, 2013 at 6:55 PM, Michael Richards=
on 
<mcr+ietf@sandelman.ca> wrote:



How can a flow have high priority packets and low p=
riority packets?



Why are these two types of packets using the same DODAG?












 


_______________________________________________
6tsch mailing list
6tsch@ietf.org=
https://www.ietf.org/mailman/listinfo/6tsch







_______________________________________________
6tsch mailing list
6tsch@=
ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch










--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151D0155xmbalnx10ciscoc_--

From tom.phinney@cox.net  Sat Mar  9 22:38:52 2013
Return-Path: 
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 C0E4821F87F6 for <6tsch@ietfa.amsl.com>; Sat,  9 Mar 2013 22:38:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.816
X-Spam-Level: 
X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
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 7OXC4K5vqDZn for <6tsch@ietfa.amsl.com>; Sat,  9 Mar 2013 22:38:51 -0800 (PST)
Received: from fed1rmfepo101.cox.net (fed1rmfepo101.cox.net [68.230.241.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1E76921F87EE for <6tsch@ietf.org>; Sat,  9 Mar 2013 22:38:51 -0800 (PST)
Received: from fed1rmimpo110 ([68.230.241.159]) by fed1rmfepo101.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130310063850.WNME25001.fed1rmfepo101.cox.net@fed1rmimpo110> for <6tsch@ietf.org>; Sun, 10 Mar 2013 01:38:50 -0500
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo110 with cox id 9ieq1l0013gAAro01ieqq5; Sun, 10 Mar 2013 01:38:50 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020209.513C2A7A.012C,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=AfVv6QrG c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=6etX-ORWL8YA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=EaCufb_MCHMA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=pGLkceISAAAA:8 a=z6CjuD5U5iviipf19yYA:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=4vB-4DCPJfMA:10 a=lZB815dzVvQA:10 a=nrGIj6q7Qwc59BcS:21 a=3D8q4eU96cW2qDjC:21 a=hxiB2op52JEKGHP5:21 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <513C2A79.3020807@cox.net>
Date: Sat, 09 Mar 2013 23:38:49 -0700
From: Tom Phinney 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "6tsch@ietf.org" <6tsch@ietf.org>
References: 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [6tsch] priority and priority
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney 
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 Mar 2013 06:38:52 -0000



  
    
  
  
    Shitanshu et al,

      

      I sense that I may be viewing related applications through very
      different lenses than the rest of you. The disconnect is
      undoubtedly mine, since I am not grounded in IETF terminology the
      way that  you all are.

      

      https://tools.ietf.org/id/draft-phinney-roll-rpl-industrial-applicability-02.txt
      provides much of the background for the following.

      

      Automation of continuous processes often involves large physical
      plants with km of piping, hundreds to thousands of valves and
      thousands to tens of thousands of sensors. Much of the high-value
      and critical equipment typically is concentrated in areas of about
      1 hectare (i.e., 100 m on a side), typically extending 10 m or
      more in the air. Other parts are spread over a large area, with
      most equipment within 2-3 m of the ground. The largest plant I
      ever visited was 10k ha (100 square miles);  the area in which
      outdoor communication is required in these plants can be enormous.

      

      At the other extreme, a pharmaceutical plant may contain many
      dozen chemical reactors, each with associated piping and valving,
      each organized as a column of equipment on a skid that can be
      moved and replaced as necessary. Such a structure is suitable for
      managing chemical or biological reactions that only work at small
      scale, as well as for providing fine-grained traceability of final
      product, which latter is required by the health agencies of many
      governments.

      

      From an automation perspective these plants are more similar than
      dissimilar: each has a set of closed-loop control and monitoring
      functions that have specific timeliness requirements, where the
      individual flows that represent purpose-specific communications
      relationships can be ranked in terms of both criticality and their
      acceptable distribution of delivery delay.

      

      In general, criticality varies inversely with

       1) the communication class (see 2.1.1 in the above document), and

       2) the reporting period. (Note that loop rate is the
      inverse of reporting period.) 

      

      A third contributing factor is the role of the specific loop in
      the plant; within a class at a given loop rate those components
      whose failure has a greater consequence tend to be higher on the
      scale.

      

      This 3-component ranking does not lead immediately to a linear
      priority structure, because control communications is essentially
      deadline scheduled rather than prioritized. As noted in the
      earlier e-mail, delivery early or late in a given reporting period
      makes no difference; it is only missed delivery deadlines that are
      consequential. Even then, the control strategies that have evolved
      during the last 50 years tolerate a few successive losses
      (generally <= 3) after which they mode-shift to a backup regime
      that emphasizes plant safety over product.

      

      An example may help. Modern toothpaste is mixed in big batch
      reactors. It includes various corrosive and toxic components,
      including fluoride. A breakdown in control of the mixing process,
      or of history collection due to lost reports, may lead to tonnes
      of toxic waste (because governments require uninterrupted history
      collection to monitor the contents and safety of such "medical"
      products). Although the industry has developed mechanisms to span
      and recover from brief to moderate communication outages in
      history collection, a failure of the process historian's database
      will trigger such a toxic waste disposal problem for the plant
      manager.

      

      Getting back to the prior discussion, publish-subscribe
      communications may be assigned to flows. When communications
      redundancy is employed, as it often is for the highest-ranked
      monitoring and control loops, the resulting (usually two) assigned
      flows must be disjoint throughout the network, never converging to
      any point that would provide a common failure mode until they
      reach their final destination, which today is usually a
      fault-tolerant server farm.

      

      Source-sink communications, which is used for stateless device
      events and stateful process alarms -- the latter go into alarm,
      then later return to normal -- has much reduced timeliness
      constraints, particularly when there is lots of other alarm
      traffic. There is usually a contractual commitment that the first
      process alarm that occurs in a period of relatively quiescent
      plant operation will be reported within 5 s, often to 4 sigma to 6
      sigma confidence. On the other hand, the 70th alarm in a ten
      minute period has no reporting timeliness requirements; it simply
      should not be lost. As with historizing and control loops, the
      industry has developed mechanisms to retrieve process alarm status
      even when the reporting messages are lost, so per-message loss is
      not a major issue. Application-layer-triggered retries push those
      initial alarms persistently; but once the system is flooded with
      alarms the delivery requirements change. It is for that reason
      that WirelessHART mandated that each 802.15.4 router have only a
      single alarm forwarding buffer, causing alarm backlogs to build up
      at the originators (where intelligent alarm reordering and
      aggregation can occur) rather than in intermediary router queues.

      

      Client-server communications is used primarily to respond to human
      or programmatic requests for detailed status of remote devices.
      Periodic publish-subscribe communications typically sends only a
      single float32 and a coded status byte; when that status byte
      indicates problems in the device or with the process, a secondary
      retrieval of more detailed information from the device is usually
      required. That communication typically requires timeliness
      suitable to sustain human interaction; if it takes too long the
      operator will attempt to accelerate the process by demanding even
      more data.

      

      Because the bandwidth available for such state retrieval is
      typically quite low, the centralized side of the automation system
      typically caches the data from each such report, thereby being
      able to present rapid and relatively reliable information to
      centralized automation programs that work with such data. For that
      same reason, much of the data that is reported by such
      client-server communications is reported by exception (rather than
      as a bulky record) when that is permitted.

      

      If the above gives the impression that these systems are complex
      and their communications needs not easily ordered into a linear
      set, then I have succeeded in providing some background. The most
      interesting aspects of these systems is that the plant owners have
      substantial incentives to improve their processes and increase
      anticipatory maintenance, both of which lead to greater revenue.
      The scale of the problems is large, but so are the potential
      profits. It is not an accident that many of the world's most
      valuable corporations have a significant portion of their profits
      generated by such plants. Thus they are more willing than most to
      try new technology, and to invest in it heavily if it proves
      reliable and improves the bottom line.

      

      Cheers,

      -Tom

      =====

      

      

    

    On 2013.03.09 22:04, Shitanshu Shah (svshah) wrote:
    

      
      


      

      
Hi Tom, All,

      


      

      
In general I agree with your assessment for need for packet
        priority.

      


      

      
If forwarding service required is similar to all packets for
        a given class, packet priority is all what is required for such
        services. Like traffic classes in your example for deterministic
        class, alerts, server-client response etc..  Treating such class
        of traffic at the aggregate level per packet priority (eg. Based
        on certain L3 or L2 level code-points) is what is needed for
        forwarding(queuing) service.

      


      

      
I also lack to understand, what is the definition of flow, is
        it micro-flow that has been eluded before?

      
For micro-flows belonging to the same service class (eg.
        Belonging to alert class), what kind of differentiation needed
        for different flows within that class? I would imagine that
        queuing is expensive and scarce resources in these systems as
        well just like it is for traditional Layer2 switches (at the
        least in the hardware). Thus probably very expensive to imagine
        as many queues as many set of flows with different priority.

      


      

      
However, a sort of differentiation that can be imagined at
        flow level may be for other parameters (but not queuing
        behavior). For example, limiting rate of a flow that is fed in
        to the queuing system.excessive traffic to be dropped or
        re-marked to lower priority code-point. Or during congestion
        drop traffic from certain flows over others.

      


      

      
I understand RSVP provides a way to enable integrated queuing
        service. At the same time, RSVP also has a way to enable
        reservation based on Diffserv. It is later that I am trying to
        highlight where packet priority is used for the forwarding
        decision, and flow classification may be used to constrain other
        parameters like rate.

      


      

      
Taking deterministic class in particular,

      
As I am not so much familiar with Industrial Automation, what
        I am not clear if for a given PAN, could there be different set
        of flows with different deterministic parameters? If there are
        then I can see some impact to queuing discipline and packet
        priority itself may not be sufficient. But I am not sure why
        there would be an application (PAN) with devices with different
        set of deterministic flows. I can also see them causing
        conflicts when it comes to channel reservation.

      


      

      
Regards,

      
Shitanshu

      


      

      


      

      
        

          From: Tom Phinney
          <tom.phinney@cox.net>

          Reply-To: Tom Phinney
          <tom.phinney@cox.net>

          Date: Saturday, March
          9, 2013 11:27 AM

          To: "6tsch@ietf.org"
          <6tsch@ietf.org>

          Subject: Re: [6tsch]
          priority and priority

        

        


        

        

          
Kris
              (et al),

              

              Thank you for your reply and general concurrence.

              

              In my post below I was objecting to the conclusion in the
              originally quoted interchange,
              recolored in red at the end below,
              that flow priority suffices. My example flow 2) is one in
              which packet priority makes sense WITHIN the flow. Note
              also my text
              in blue below, highlighting a
              similar conclusion for use of flows 2) and/or 3) as backup
              channels for flow 1) when flow 1) becomes too unreliable.

              

              My post below was an attempt to point out that queuing
              priority AND flow priority need not be disjoint
              approaches; in my opinion they can and should both exist
              concurrently in systems that deal with real-world
              problems, at least in the industrial and process
              automation markets. They each provide some functionality
              that the other lacks, giving an overall system that is
              superior in its performance of critical functions to one
              that restricts itself to flow priority, or to queuing
              priority, but without supporting both. My post below was
              an attempt to sketch a common scenario in that market
              where the two priority mechanisms interplay to provide a
              superior system.

              

              Perhaps my concept of flow differs from those of the
              original two correspondents. If so, I would appreciate
              instruction/correction. My scenario below was one where
              resources assigned to secondary flows would be used when
              the primary flow 1) fails. If others' notions of flow are
              not coupled to contracts and resource allocation in
              forwarding DL and NL routers,
            potentially including slot
              prioritization among concurrent slots, then what use is it?

              

              -Tom

              =====

            On 2013.03.09 10:36, Kris Pister wrote:
            
Tom - I agree with everything that you wrote
              in the email below except the first sentence.  Perhaps I'm
              missing something, but it seems to me that your
              enumeration of various flows with different requirements
              fits quite well with the discussion fragment quoted at the
              end below.  Can you help me understand the differences?

              

              My bias is that we should have 

              {flow priority (equating to slotframe priority) OR link
              priority (TX, RX, uni-, multi-)} AND {packet priority}.

              

              ksjp

              

              
On 3/8/2013 11:36 PM, Tom
                Phinney wrote:

              

              
I don't know what real-world use this
                technology is being designed to support, but the
                discussion fragments quoted at the end below seem to me
                to be moving away from reality.

                

                In the industrial automation world where I spent most of
                my career, it makes sense to have different inbound
                flows for differing purposes. Most sensor devices would
                have the following flows 1), 2) and 3):

                1) a dedicated inbound flow per field device (mote) for
                periodic deterministic control traffic, where the number
                of expected hops has to be small when the loop rate is
                high;

                2) a shared inbound flow for usually-infrequent alerts
                (i.e., device events and process alarms), probably with
                at least 2-level packet queuing priority, perhaps using
                CSMA/CA to provide some slight statistical bias in
                channel access priority based on packet priority;

                3) a shared inbound flow for server-to-client responses,
                typically in response to a program-initiated or
                operator-initiated action at an engineering workstation
                in a control room.

                

                Every process actuator (i.e., mote that can directly
                manipulate the process) will also have another flow 4),
                analogous to 1) but in the outbound direction, from the
                control room to the field to transfer the computed
                actuator setting to the device. Such devices also have
                inbound flow 1) to transfer actuator status at the same
                periodic rate.

                

                If communication problems are experienced on flow 1), it is desirable to be able to use one
                  or more of the other flows as a backup mechanism for
                  inbound control traffic, whether full
                determinism can be maintained or not.
                Packet queuing priority definitely
                  makes sense here, so that such traffic can leapfrog
                  non-deterministic traffic in the output queue of the
                  originating mote and of any intermediary relaying
                  motes. As mentioned in 2), it may also make
                sense to use CSMA/CA to provide some slight statistical
                bias in channel access priority based on packet
                priority, at least for flows where the transaction
                template has a non-null CSMA/CA sensing interval before
                the scheduled Data PDU transmission of the transaction.

                

                The reason for priority on the alerts is that process
                alarms from class 1 - 2 devices, (or class 0 - 2 if
                class 0 uses wireless), would usually be configured to
                be higher priority than those for classes 3 - 5. (Some
                class 3 devices might also be assigned that higher alarm
                priority.) Where safety alarms are concerned, such as
                the "man down" alarm that Herman Storey mentioned on
                Thursday's call, those alarms would tend to use another
                flow 5), similar to 2), with a very low expected rate
                but with dedicated slots to provide a clear virtual
                channel (to the extent possible). The time constants for
                such alarms are long enough (seconds) compared to much
                of the flow 1) traffic that the incremental cost of flow
                5), which is so similar to flow 2), probably would not
                be very much, perhaps 2% of the total network capacity.
                It is tempting to just have a 3-way CSMA/CA interval for
                flow 2), but the reality of the CSMA/CA priority
                assessment mechanism is that it is very weak, given
                physical modem delays, inter-mote timing skews and the
                old hidden-node problem. Thus CSMA/CA prioritization
                does not seem reliable enough to trust for safety
                purposes.

                

                Of course a system will have other flows, many allocated
                on a demand basis in response to some occasional need,
                such as firmware download or captured waveform upload.

                

                The basic timing of continuous control loops it that the
                total delay from sensing the process to driving the
                actuator generally has to be less than twice the period
                of the loop. In such cases the needed control strategy
                is both relatively simple and relatively stable,
                However, if the total input-to-output delay exceeds
                twice the loop period, the control becomes much more
                difficult and less able to respond to fast transients.
                Jitter is a problem only when a process value message is
                delivered in the wrong cycle; it does not matter whether
                the delivery is at the 10% or 90% point in the proper
                cycle. Authenticated timestamping of the message, as
                occurs via the UDP transport nonce in ISA100.11a,
                provides a means of discarding process value messages
                that are delivered too late, thus converting those
                situations to ones of message loss. That is the desired
                way of handling late delivery, because the control loop
                is stable under message loss but not when the values are
                deliberately selectively delayed into the wrong delivery
                cycle. (Honeywell demonstrated years ago that it was
                possible to destablize most control loops with such
                deliberately jittered delivery.)

                

                -Tom

                =====

                On 2013.03.08 23:33, Thomas Watteyne wrote:
                

                  Michael,
                  


                  

                  
I agree that the term flow is almost as
                    overloaded as link or path. This is not a final term
                    and we will have to come up with a better term.
                    Suggestions?

                  


                  

                  
If I get your point correctly, you are suggesting
                    that 
                      there should be no packet priorities, only flows
                      priority. In a TSCH context, this would
                    translate into a slotframe per flow, where flow also
                    incorporates the notion of priority. Correct? This
                    is a very important discussion we started over the
                    phone earlier today, but which we will continue
                    Wednesday in Orlando. I hope you can be there.

                  


                  

                  
Thomas

                    

                    
On Fri, Mar 8, 2013 at 6:55
                      PM, Michael Richardson 
                        <mcr+ietf@sandelman.ca>
                      wrote:

                      

                        How can a flow have high
                          priority packets and low priority packets?

                        

                        Why are these two types of packets using the
                        same DODAG?

                      

                    

                  

                

                

                

                

                
_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch

              

              

              

_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch

            

          

        

      
    

  


From pister@eecs.berkeley.edu  Sun Mar 10 13:26:07 2013
Return-Path: 
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 31AA711E80DC for <6tsch@ietfa.amsl.com>; Sun, 10 Mar 2013 13:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.398
X-Spam-Level: 
X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 lhiZ0sBIjQgZ for <6tsch@ietfa.amsl.com>; Sun, 10 Mar 2013 13:26:05 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5713511E80C5 for <6tsch@ietf.org>; Sun, 10 Mar 2013 13:26:05 -0700 (PDT)
Received: from c-98-210-49-50.hsd1.ca.comcast.net ([98.210.49.50] helo=[192.168.1.100]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1UEmok-0000ar-4N; Sun, 10 Mar 2013 13:26:04 -0700
Message-ID: <513CEC45.9080209@eecs.berkeley.edu>
Date: Sun, 10 Mar 2013 13:25:41 -0700
From: Kris Pister 
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Shitanshu Shah (svshah)" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080705000205050608040400"
Cc: "6tsch@ietf.org" <6tsch@ietf.org>, Tom Phinney 
Subject: Re: [6tsch] priority and priority
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 Mar 2013 20:26:07 -0000

This is a multi-part message in MIME format.
--------------080705000205050608040400
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Shitanshu -
 > As I am not so much familiar with Industrial Automation, what I am not
 > clear if for a given PAN, could there be different set of flows with 
different
 > deterministic parameters?
    I don't think that the things that Tom is writing about are specific 
to industrial automation.  Most WSN applications have similar kinds of 
flows.  Building automation, smart grid, smart home, etc. all have most 
if not all of the various flows and requirements enumerated in rfc5637.

For example, light switches, burglar alarms, and thermostats have very 
different deterministic requirements.

ksjp

On 3/9/2013 9:04 PM, Shitanshu Shah (svshah) wrote:
>
> Hi Tom, All,
>
> In general I agree with your assessment for need for packet priority.
>
> If forwarding service required is similar to all packets for a given 
> class, packet priority is all what is required for such services. 
> Like traffic classes in your example for deterministic class, alerts, 
> server-client response etc..  Treating such class of traffic at the 
> aggregate level per packet priority (eg. Based on certain L3 or L2 
> level code-points) is what is needed for forwarding(queuing) service.
>
> I also lack to understand, what is the definition of flow, is it 
> micro-flow that has been eluded before?
> For micro-flows belonging to the same service class (eg. Belonging to 
> alert class), what kind of differentiation needed for different flows 
> within that class? I would imagine that queuing is expensive and 
> scarce resources in these systems as well just like it is for 
> traditional Layer2 switches (at the least in the hardware). Thus 
> probably very expensive to imagine as many queues as many set of flows 
> with different priority.
>
> However, a sort of differentiation that can be imagined at flow level 
> may be for other parameters (but not queuing behavior). For example, 
> limiting rate of a flow that is fed in to the queuing system.excessive 
> traffic to be dropped or re-marked to lower priority code-point. Or 
> during congestion drop traffic from certain flows over others.
>
> I understand RSVP provides a way to enable integrated queuing service. 
> At the same time, RSVP also has a way to enable reservation based on 
> Diffserv. It is later that I am trying to highlight where packet 
> priority is used for the forwarding decision, and flow classification 
> may be used to constrain other parameters like rate.
>
> Taking deterministic class in particular,
> As I am not so much familiar with Industrial Automation, what I am not 
> clear if for a given PAN, could there be different set of flows with 
> different deterministic parameters? If there are then I can see some 
> impact to queuing discipline and packet priority itself may not be 
> sufficient. But I am not sure why there would be an application (PAN) 
> with devices with different set of deterministic flows. I can also see 
> them causing conflicts when it comes to channel reservation.
>
> Regards,
> Shitanshu
>
>
> From: Tom Phinney >
> Reply-To: Tom Phinney >
> Date: Saturday, March 9, 2013 11:27 AM
> To: "6tsch@ietf.org " <6tsch@ietf.org 
> >
> Subject: Re: [6tsch] priority and priority
>
> Kris (et al),
>
> Thank you for your reply and general concurrence.
>
> In my post below I was objecting to the conclusion in the originally 
> quoted interchange, recolored in red at the end below, that flow 
> priority suffices. My example flow 2) is one in which packet priority 
> makes sense WITHIN the flow. Note also my text in blue below, 
> highlighting a similar conclusion for use of flows 2) and/or 3) as 
> backup channels for flow 1) when flow 1) becomes too unreliable.
>
> My post below was an attempt to point out that queuing priority AND 
> flow priority need not be disjoint approaches; in my opinion they can 
> and should both exist concurrently in systems that deal with 
> real-world problems, at least in the industrial and process automation 
> markets. They each provide some functionality that the other lacks, 
> giving an overall system that is superior in its performance of 
> critical functions to one that restricts itself to flow priority, or 
> to queuing priority, but without supporting both. My post below was an 
> attempt to sketch a common scenario in that market where the two 
> priority mechanisms interplay to provide a superior system.
>
> Perhaps my concept of flow differs from those of the original two 
> correspondents. If so, I would appreciate instruction/correction. My 
> scenario below was one where resources assigned to secondary flows 
> would be used when the primary flow 1) fails. If others' notions of 
> flow are not coupled to contracts and resource allocation in 
> forwarding DL and NL routers, potentially including slot 
> prioritization among concurrent slots, then what use is it?
>
> -Tom
> =====
> On 2013.03.09 10:36, Kris Pister wrote:
>> Tom - I agree with everything that you wrote in the email below 
>> except the first sentence.  Perhaps I'm missing something, but it 
>> seems to me that your enumeration of various flows with different 
>> requirements fits quite well with the discussion fragment quoted at 
>> the end below.  Can you help me understand the differences?
>>
>> My bias is that we should have
>> {flow priority (equating to slotframe priority) OR link priority (TX, 
>> RX, uni-, multi-)} AND {packet priority}.
>>
>> ksjp
>>
>> On 3/8/2013 11:36 PM, Tom Phinney wrote:
>>> I don't know what real-world use this technology is being designed 
>>> to support, but the discussion fragments quoted at the end below 
>>> seem to me to be moving away from reality.
>>>
>>> In the industrial automation world where I spent most of my career, 
>>> it makes sense to have different inbound flows for differing 
>>> purposes. Most sensor devices would have the following flows 1), 2) 
>>> and 3):
>>> 1) a dedicated inbound flow per field device (mote) for periodic 
>>> deterministic control traffic, where the number of expected hops has 
>>> to be small when the loop rate is high;
>>> 2) a shared inbound flow for usually-infrequent alerts (i.e., device 
>>> events and process alarms), probably with at least 2-level packet 
>>> queuing priority, perhaps using CSMA/CA to provide some slight 
>>> statistical bias in channel access priority based on packet priority;
>>> 3) a shared inbound flow for server-to-client responses, typically 
>>> in response to a program-initiated or operator-initiated action at 
>>> an engineering workstation in a control room.
>>>
>>> Every process actuator (i.e., mote that can directly manipulate the 
>>> process) will also have another flow 4), analogous to 1) but in the 
>>> outbound direction, from the control room to the field to transfer 
>>> the computed actuator setting to the device. Such devices also have 
>>> inbound flow 1) to transfer actuator status at the same periodic rate.
>>>
>>> If communication problems are experienced on flow 1), it is 
>>> desirable to be able to use one or more of the other flows as a 
>>> backup mechanism for inbound control traffic, whether full 
>>> determinism can be maintained or not. Packet queuing priority 
>>> definitely makes sense here, so that such traffic can leapfrog 
>>> non-deterministic traffic in the output queue of the originating 
>>> mote and of any intermediary relaying motes. As mentioned in 2), it 
>>> may also make sense to use CSMA/CA to provide some slight 
>>> statistical bias in channel access priority based on packet 
>>> priority, at least for flows where the transaction template has a 
>>> non-null CSMA/CA sensing interval before the scheduled Data PDU 
>>> transmission of the transaction.
>>>
>>> The reason for priority on the alerts is that process alarms from 
>>> class 1 - 2 devices, (or class 0 - 2 if class 0 uses wireless), 
>>> would usually be configured to be higher priority than those for 
>>> classes 3 - 5. (Some class 3 devices might also be assigned that 
>>> higher alarm priority.) Where safety alarms are concerned, such as 
>>> the "man down" alarm that Herman Storey mentioned on Thursday's 
>>> call, those alarms would tend to use another flow 5), similar to 2), 
>>> with a very low expected rate but with dedicated slots to provide a 
>>> clear virtual channel (to the extent possible). The time constants 
>>> for such alarms are long enough (seconds) compared to much of the 
>>> flow 1) traffic that the incremental cost of flow 5), which is so 
>>> similar to flow 2), probably would not be very much, perhaps 2% of 
>>> the total network capacity. It is tempting to just have a 3-way 
>>> CSMA/CA interval for flow 2), but the reality of the CSMA/CA 
>>> priority assessment mechanism is that it is very weak, given 
>>> physical modem delays, inter-mote timing skews and the old 
>>> hidden-node problem. Thus CSMA/CA prioritization does not seem 
>>> reliable enough to trust for safety purposes.
>>>
>>> Of course a system will have other flows, many allocated on a demand 
>>> basis in response to some occasional need, such as firmware download 
>>> or captured waveform upload.
>>>
>>> The basic timing of continuous control loops it that the total delay 
>>> from sensing the process to driving the actuator generally has to be 
>>> less than twice the period of the loop. In such cases the needed 
>>> control strategy is both relatively simple and relatively stable, 
>>> However, if the total input-to-output delay exceeds twice the loop 
>>> period, the control becomes much more difficult and less able to 
>>> respond to fast transients. Jitter is a problem only when a process 
>>> value message is delivered in the wrong cycle; it does not matter 
>>> whether the delivery is at the 10% or 90% point in the proper cycle. 
>>> Authenticated timestamping of the message, as occurs via the UDP 
>>> transport nonce in ISA100.11a, provides a means of discarding 
>>> process value messages that are delivered too late, thus converting 
>>> those situations to ones of message loss. That is the desired way of 
>>> handling late delivery, because the control loop is stable under 
>>> message loss but not when the values are deliberately selectively 
>>> delayed into the wrong delivery cycle. (Honeywell demonstrated years 
>>> ago that it was possible to destablize most control loops with such 
>>> deliberately jittered delivery.)
>>>
>>> -Tom
>>> =====
>>> On 2013.03.08 23:33, Thomas Watteyne wrote:
>>>> Michael,
>>>>
>>>> I agree that the term flow is almost as overloaded as link or path. 
>>>> This is not a final term and we will have to come up with a better 
>>>> term. Suggestions?
>>>>
>>>> If I get your point correctly, you are suggesting that there should 
>>>> be no packet priorities, only flows priority. In a TSCH context, 
>>>> this would translate into a slotframe per flow, where flow also 
>>>> incorporates the notion of priority. Correct? This is a very 
>>>> important discussion we started over the phone earlier today, but 
>>>> which we will continue Wednesday in Orlando. I hope you can be there.
>>>>
>>>> Thomas
>>>>
>>>> On Fri, Mar 8, 2013 at 6:55 PM, Michael Richardson 
>>>> > wrote:
>>>>
>>>>     How can a flow have high priority packets and low priority packets?
>>>>
>>>>     Why are these two types of packets using the same DODAG?
>>>>
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


--------------080705000205050608040400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Shitanshu - 

    > As I am not so much familiar with Industrial Automation, what I
    am not

    > clear if for a given PAN, could there be different set of flows
    with different 

    > deterministic parameters?

       I don't think that the things that Tom is writing about are
    specific to industrial automation.  Most WSN applications have
    similar kinds of flows.  Building automation, smart grid, smart
    home, etc. all have most if not all of the various flows and
    requirements enumerated in rfc5637.

    

    For example, light switches, burglar alarms, and thermostats have
    very different deterministic requirements.

    

    ksjp

    

    
On 3/9/2013 9:04 PM, Shitanshu Shah
      (svshah) wrote:

    

    

      
      


      

      
Hi Tom, All,

      


      

      
In general I agree with your assessment for need for packet
        priority.

      


      

      
If forwarding service required is similar to all packets for
        a given class, packet priority is all what is required for such
        services. Like traffic classes in your example for deterministic
        class, alerts, server-client response etc..  Treating such class
        of traffic at the aggregate level per packet priority (eg. Based
        on certain L3 or L2 level code-points) is what is needed for
        forwarding(queuing) service.

      


      

      
I also lack to understand, what is the definition of flow, is
        it micro-flow that has been eluded before?

      
For micro-flows belonging to the same service class (eg.
        Belonging to alert class), what kind of differentiation needed
        for different flows within that class? I would imagine that
        queuing is expensive and scarce resources in these systems as
        well just like it is for traditional Layer2 switches (at the
        least in the hardware). Thus probably very expensive to imagine
        as many queues as many set of flows with different priority.

      


      

      
However, a sort of differentiation that can be imagined at
        flow level may be for other parameters (but not queuing
        behavior). For example, limiting rate of a flow that is fed in
        to the queuing system.excessive traffic to be dropped or
        re-marked to lower priority code-point. Or during congestion
        drop traffic from certain flows over others.

      


      

      
I understand RSVP provides a way to enable integrated queuing
        service. At the same time, RSVP also has a way to enable
        reservation based on Diffserv. It is later that I am trying to
        highlight where packet priority is used for the forwarding
        decision, and flow classification may be used to constrain other
        parameters like rate.

      


      

      
Taking deterministic class in particular,

      
As I am not so much familiar with Industrial Automation, what
        I am not clear if for a given PAN, could there be different set
        of flows with different deterministic parameters? If there are
        then I can see some impact to queuing discipline and packet
        priority itself may not be sufficient. But I am not sure why
        there would be an application (PAN) with devices with different
        set of deterministic flows. I can also see them causing
        conflicts when it comes to channel reservation.

      


      

      
Regards,

      
Shitanshu

      


      

      


      

      
        

          From: Tom Phinney <tom.phinney@cox.net>

          Reply-To: Tom Phinney
          <tom.phinney@cox.net>

          Date: Saturday, March
          9, 2013 11:27 AM

          To: "6tsch@ietf.org"
          <6tsch@ietf.org>

          Subject: Re: [6tsch]
          priority and priority

        

        


        

        

          
Kris
              (et al),

              

              Thank you for your reply and general concurrence.

              

              In my post below I was objecting to the conclusion in the
              originally quoted interchange,
              recolored in red at the end below,
              that flow priority suffices. My example flow 2) is one in
              which packet priority makes sense WITHIN the flow. Note
              also my text
              in blue below, highlighting a
              similar conclusion for use of flows 2) and/or 3) as backup
              channels for flow 1) when flow 1) becomes too unreliable.

              

              My post below was an attempt to point out that queuing
              priority AND flow priority need not be disjoint
              approaches; in my opinion they can and should both exist
              concurrently in systems that deal with real-world
              problems, at least in the industrial and process
              automation markets. They each provide some functionality
              that the other lacks, giving an overall system that is
              superior in its performance of critical functions to one
              that restricts itself to flow priority, or to queuing
              priority, but without supporting both. My post below was
              an attempt to sketch a common scenario in that market
              where the two priority mechanisms interplay to provide a
              superior system.

              

              Perhaps my concept of flow differs from those of the
              original two correspondents. If so, I would appreciate
              instruction/correction. My scenario below was one where
              resources assigned to secondary flows would be used when
              the primary flow 1) fails. If others' notions of flow are
              not coupled to contracts and resource allocation in
              forwarding DL and NL routers,
            potentially including slot
              prioritization among concurrent slots, then what use is it?

              

              -Tom

              =====

            On 2013.03.09 10:36, Kris Pister wrote:
            
Tom - I agree with everything that you wrote
              in the email below except the first sentence.  Perhaps I'm
              missing something, but it seems to me that your
              enumeration of various flows with different requirements
              fits quite well with the discussion fragment quoted at the
              end below.  Can you help me understand the differences?

              

              My bias is that we should have 

              {flow priority (equating to slotframe priority) OR link
              priority (TX, RX, uni-, multi-)} AND {packet priority}.

              

              ksjp

              

              
On 3/8/2013 11:36 PM, Tom
                Phinney wrote:

              

              
I don't know what real-world use this
                technology is being designed to support, but the
                discussion fragments quoted at the end below seem to me
                to be moving away from reality.

                

                In the industrial automation world where I spent most of
                my career, it makes sense to have different inbound
                flows for differing purposes. Most sensor devices would
                have the following flows 1), 2) and 3):

                1) a dedicated inbound flow per field device (mote) for
                periodic deterministic control traffic, where the number
                of expected hops has to be small when the loop rate is
                high;

                2) a shared inbound flow for usually-infrequent alerts
                (i.e., device events and process alarms), probably with
                at least 2-level packet queuing priority, perhaps using
                CSMA/CA to provide some slight statistical bias in
                channel access priority based on packet priority;

                3) a shared inbound flow for server-to-client responses,
                typically in response to a program-initiated or
                operator-initiated action at an engineering workstation
                in a control room.

                

                Every process actuator (i.e., mote that can directly
                manipulate the process) will also have another flow 4),
                analogous to 1) but in the outbound direction, from the
                control room to the field to transfer the computed
                actuator setting to the device. Such devices also have
                inbound flow 1) to transfer actuator status at the same
                periodic rate.

                

                If communication problems are experienced on flow 1), it is desirable to be able to use one
                  or more of the other flows as a backup mechanism for
                  inbound control traffic, whether full
                determinism can be maintained or not.
                Packet queuing priority definitely
                  makes sense here, so that such traffic can leapfrog
                  non-deterministic traffic in the output queue of the
                  originating mote and of any intermediary relaying
                  motes. As mentioned in 2), it may also make
                sense to use CSMA/CA to provide some slight statistical
                bias in channel access priority based on packet
                priority, at least for flows where the transaction
                template has a non-null CSMA/CA sensing interval before
                the scheduled Data PDU transmission of the transaction.

                

                The reason for priority on the alerts is that process
                alarms from class 1 - 2 devices, (or class 0 - 2 if
                class 0 uses wireless), would usually be configured to
                be higher priority than those for classes 3 - 5. (Some
                class 3 devices might also be assigned that higher alarm
                priority.) Where safety alarms are concerned, such as
                the "man down" alarm that Herman Storey mentioned on
                Thursday's call, those alarms would tend to use another
                flow 5), similar to 2), with a very low expected rate
                but with dedicated slots to provide a clear virtual
                channel (to the extent possible). The time constants for
                such alarms are long enough (seconds) compared to much
                of the flow 1) traffic that the incremental cost of flow
                5), which is so similar to flow 2), probably would not
                be very much, perhaps 2% of the total network capacity.
                It is tempting to just have a 3-way CSMA/CA interval for
                flow 2), but the reality of the CSMA/CA priority
                assessment mechanism is that it is very weak, given
                physical modem delays, inter-mote timing skews and the
                old hidden-node problem. Thus CSMA/CA prioritization
                does not seem reliable enough to trust for safety
                purposes.

                

                Of course a system will have other flows, many allocated
                on a demand basis in response to some occasional need,
                such as firmware download or captured waveform upload.

                

                The basic timing of continuous control loops it that the
                total delay from sensing the process to driving the
                actuator generally has to be less than twice the period
                of the loop. In such cases the needed control strategy
                is both relatively simple and relatively stable,
                However, if the total input-to-output delay exceeds
                twice the loop period, the control becomes much more
                difficult and less able to respond to fast transients.
                Jitter is a problem only when a process value message is
                delivered in the wrong cycle; it does not matter whether
                the delivery is at the 10% or 90% point in the proper
                cycle. Authenticated timestamping of the message, as
                occurs via the UDP transport nonce in ISA100.11a,
                provides a means of discarding process value messages
                that are delivered too late, thus converting those
                situations to ones of message loss. That is the desired
                way of handling late delivery, because the control loop
                is stable under message loss but not when the values are
                deliberately selectively delayed into the wrong delivery
                cycle. (Honeywell demonstrated years ago that it was
                possible to destablize most control loops with such
                deliberately jittered delivery.)

                

                -Tom

                =====

                On 2013.03.08 23:33, Thomas Watteyne wrote:
                

                  Michael,
                  


                  

                  
I agree that the term flow is almost as
                    overloaded as link or path. This is not a final term
                    and we will have to come up with a better term.
                    Suggestions?

                  


                  

                  
If I get your point correctly, you are suggesting
                    that 
                      there should be no packet priorities, only flows
                      priority. In a TSCH context, this would
                    translate into a slotframe per flow, where flow also
                    incorporates the notion of priority. Correct? This
                    is a very important discussion we started over the
                    phone earlier today, but which we will continue
                    Wednesday in Orlando. I hope you can be there.

                  


                  

                  
Thomas

                    

                    
On Fri, Mar 8, 2013 at 6:55
                      PM, Michael Richardson 
                        <mcr+ietf@sandelman.ca>
                      wrote:

                      

                        How can a flow have high
                          priority packets and low priority packets?

                        

                        Why are these two types of packets using the
                        same DODAG?

                      

                    

                  

                

                

                

                

                
_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch

              

              

              

_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch

            

          

        

      
      

      

      

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


    

    

  


--------------080705000205050608040400--

From svshah@cisco.com  Sun Mar 10 17:51:14 2013
Return-Path: 
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 6C67421F88ED for <6tsch@ietfa.amsl.com>; Sun, 10 Mar 2013 17:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.265
X-Spam-Level: 
X-Spam-Status: No, score=-11.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 dJMwOuJHdOTq for <6tsch@ietfa.amsl.com>; Sun, 10 Mar 2013 17:51:11 -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 61B8C21F88E6 for <6tsch@ietf.org>; Sun, 10 Mar 2013 17:51:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43216; q=dns/txt; s=iport; t=1362963071; x=1364172671; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=WThTOtNhehZStV+XFkSeRC941xpWw0q78qjuvlXn1sM=; b=SOR2JaU2nHnyHWM9prEGr4ricqskJqQRnJV4gfFb37LLZAyPJmuNXZiL fqpa/HM4erRe0CQHm06/+yjf9tCTE6/DQpj+/cHGYTsz/wuiRF42jvb9Z DkCoe9Z6nf0ZoOmOZXn5E4w+NPZjnoT744JeYAC7Sa/36kFyVT68Ti8nZ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAOQpPVGtJV2a/2dsb2JhbABDhAzAO4FMFnSCJQEBAQQBAQEXAVMEGQEIEQMBAgsCFAEGLgsUCQgCBAEJCQgBiAoMu2iNRAkQgQAgBhEBBoJZYQOnSoMKgXM1
X-IronPort-AV: E=Sophos;i="4.84,819,1355097600";  d="scan'208,217";a="185899942"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 11 Mar 2013 00:51:04 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2B0p4oU011676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 00:51:04 GMT
Received: from xmb-aln-x10.cisco.com ([169.254.5.82]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 19:51:04 -0500
From: "Shitanshu Shah (svshah)" 
To: Tom Phinney , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] priority and priority
Thread-Index: AQHOG89uote0gTOlJkW2KjLq2WdT9ZidEBIAgAA84QCAABGAAIAAp+kAgAAezYCAABskgIAAj72AgADuGQA=
Date: Mon, 11 Mar 2013 00:51:03 +0000
Message-ID: 
In-Reply-To: <513C2A79.3020807@cox.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [10.21.84.50]
Content-Type: multipart/alternative; boundary="_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151D041Fxmbalnx10ciscoc_"
MIME-Version: 1.0
Subject: Re: [6tsch] priority and priority
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 00:51:14 -0000

--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151D041Fxmbalnx10ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Tom,

If the above gives the impression that these systems are complex and their =
communications needs not easily ordered into a linear set, then I have succ=
eeded in providing some background

##svshah, My response is not highlighting it to be strict linear set priori=
ty service. Perhaps my earlier response did not do a good job. Infact Diffs=
erv code-points (as well any L2 code-points) and their PHB definition do no=
t define them a strict ordered priority service.

Thanks
Shitanshu

From: Tom Phinney >
Reply-To: Tom Phinney >
Date: Sunday, March 10, 2013 1:38 AM
To: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] priority and priority

Shitanshu et al,

I sense that I may be viewing related applications through very different l=
enses than the rest of you. The disconnect is undoubtedly mine, since I am =
not grounded in IETF terminology the way that  you all are.

https://tools.ietf.org/id/draft-phinney-roll-rpl-industrial-applicability-0=
2.txt provides much of the background for the following.

Automation of continuous processes often involves large physical plants wit=
h km of piping, hundreds to thousands of valves and thousands to tens of th=
ousands of sensors. Much of the high-value and critical equipment typically=
 is concentrated in areas of about 1 hectare (i.e., 100 m on a side), typic=
ally extending 10 m or more in the air. Other parts are spread over a large=
 area, with most equipment within 2-3 m of the ground. The largest plant I =
ever visited was 10k ha (100 square miles);  the area in which outdoor comm=
unication is required in these plants can be enormous.

At the other extreme, a pharmaceutical plant may contain many dozen chemica=
l reactors, each with associated piping and valving, each organized as a co=
lumn of equipment on a skid that can be moved and replaced as necessary. Su=
ch a structure is suitable for managing chemical or biological reactions th=
at only work at small scale, as well as for providing fine-grained traceabi=
lity of final product, which latter is required by the health agencies of m=
any governments.

>From an automation perspective these plants are more similar than dissimila=
r: each has a set of closed-loop control and monitoring functions that have=
 specific timeliness requirements, where the individual flows that represen=
t purpose-specific communications relationships can be ranked in terms of b=
oth criticality and their acceptable distribution of delivery delay.

In general, criticality varies inversely with
 1) the communication class (see 2.1.1 in the above document), and
 2) the reporting period. (Note that loop rate is the inverse of reporting =
period.)

A third contributing factor is the role of the specific loop in the plant; =
within a class at a given loop rate those components whose failure has a gr=
eater consequence tend to be higher on the scale.

This 3-component ranking does not lead immediately to a linear priority str=
ucture, because control communications is essentially deadline scheduled ra=
ther than prioritized. As noted in the earlier e-mail, delivery early or la=
te in a given reporting period makes no difference; it is only missed deliv=
ery deadlines that are consequential. Even then, the control strategies tha=
t have evolved during the last 50 years tolerate a few successive losses (g=
enerally <=3D 3) after which they mode-shift to a backup regime that emphas=
izes plant safety over product.

An example may help. Modern toothpaste is mixed in big batch reactors. It i=
ncludes various corrosive and toxic components, including fluoride. A break=
down in control of the mixing process, or of history collection due to lost=
 reports, may lead to tonnes of toxic waste (because governments require un=
interrupted history collection to monitor the contents and safety of such "=
medical" products). Although the industry has developed mechanisms to span =
and recover from brief to moderate communication outages in history collect=
ion, a failure of the process historian's database will trigger such a toxi=
c waste disposal problem for the plant manager.

Getting back to the prior discussion, publish-subscribe communications may =
be assigned to flows. When communications redundancy is employed, as it oft=
en is for the highest-ranked monitoring and control loops, the resulting (u=
sually two) assigned flows must be disjoint throughout the network, never c=
onverging to any point that would provide a common failure mode until they =
reach their final destination, which today is usually a fault-tolerant serv=
er farm.

Source-sink communications, which is used for stateless device events and s=
tateful process alarms -- the latter go into alarm, then later return to no=
rmal -- has much reduced timeliness constraints, particularly when there is=
 lots of other alarm traffic. There is usually a contractual commitment tha=
t the first process alarm that occurs in a period of relatively quiescent p=
lant operation will be reported within 5 s, often to 4 sigma to 6 sigma con=
fidence. On the other hand, the 70th alarm in a ten minute period has no re=
porting timeliness requirements; it simply should not be lost. As with hist=
orizing and control loops, the industry has developed mechanisms to retriev=
e process alarm status even when the reporting messages are lost, so per-me=
ssage loss is not a major issue. Application-layer-triggered retries push t=
hose initial alarms persistently; but once the system is flooded with alarm=
s the delivery requirements change. It is for that reason that WirelessHART=
 mandated that each 802.15.4 router have only a single alarm forwarding buf=
fer, causing alarm backlogs to build up at the originators (where intellige=
nt alarm reordering and aggregation can occur) rather than in intermediary =
router queues.

Client-server communications is used primarily to respond to human or progr=
ammatic requests for detailed status of remote devices. Periodic publish-su=
bscribe communications typically sends only a single float32 and a coded st=
atus byte; when that status byte indicates problems in the device or with t=
he process, a secondary retrieval of more detailed information from the dev=
ice is usually required. That communication typically requires timeliness s=
uitable to sustain human interaction; if it takes too long the operator wil=
l attempt to accelerate the process by demanding even more data.

Because the bandwidth available for such state retrieval is typically quite=
 low, the centralized side of the automation system typically caches the da=
ta from each such report, thereby being able to present rapid and relativel=
y reliable information to centralized automation programs that work with su=
ch data. For that same reason, much of the data that is reported by such cl=
ient-server communications is reported by exception (rather than as a bulky=
 record) when that is permitted.

If the above gives the impression that these systems are complex and their =
communications needs not easily ordered into a linear set, then I have succ=
eeded in providing some background. The most interesting aspects of these s=
ystems is that the plant owners have substantial incentives to improve thei=
r processes and increase anticipatory maintenance, both of which lead to gr=
eater revenue. The scale of the problems is large, but so are the potential=
 profits. It is not an accident that many of the world's most valuable corp=
orations have a significant portion of their profits generated by such plan=
ts. Thus they are more willing than most to try new technology, and to inve=
st in it heavily if it proves reliable and improves the bottom line.

Cheers,
-Tom
=3D=3D=3D=3D=3D



On 2013.03.09 22:04, Shitanshu Shah (svshah) wrote:

Hi Tom, All,

In general I agree with your assessment for need for packet priority.

If forwarding service required is similar to all packets for a given class,=
 packet priority is all what is required for such services. Like traffic cl=
asses in your example for deterministic class, alerts, server-client respon=
se etc..  Treating such class of traffic at the aggregate level per packet =
priority (eg. Based on certain L3 or L2 level code-points) is what is neede=
d for forwarding(queuing) service.

I also lack to understand, what is the definition of flow, is it micro-flow=
 that has been eluded before?
For micro-flows belonging to the same service class (eg. Belonging to alert=
 class), what kind of differentiation needed for different flows within tha=
t class? I would imagine that queuing is expensive and scarce resources in =
these systems as well just like it is for traditional Layer2 switches (at t=
he least in the hardware). Thus probably very expensive to imagine as many =
queues as many set of flows with different priority.

However, a sort of differentiation that can be imagined at flow level may b=
e for other parameters (but not queuing behavior). For example, limiting ra=
te of a flow that is fed in to the queuing system.excessive traffic to be d=
ropped or re-marked to lower priority code-point. Or during congestion drop=
 traffic from certain flows over others.

I understand RSVP provides a way to enable integrated queuing service. At t=
he same time, RSVP also has a way to enable reservation based on Diffserv. =
It is later that I am trying to highlight where packet priority is used for=
 the forwarding decision, and flow classification may be used to constrain =
other parameters like rate.

Taking deterministic class in particular,
As I am not so much familiar with Industrial Automation, what I am not clea=
r if for a given PAN, could there be different set of flows with different =
deterministic parameters? If there are then I can see some impact to queuin=
g discipline and packet priority itself may not be sufficient. But I am not=
 sure why there would be an application (PAN) with devices with different s=
et of deterministic flows. I can also see them causing conflicts when it co=
mes to channel reservation.

Regards,
Shitanshu


From: Tom Phinney >
Reply-To: Tom Phinney >
Date: Saturday, March 9, 2013 11:27 AM
To: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] priority and priority

Kris (et al),

Thank you for your reply and general concurrence.

In my post below I was objecting to the conclusion in the originally quoted=
 interchange, recolored in red at the end below, that flow priority suffice=
s. My example flow 2) is one in which packet priority makes sense WITHIN th=
e flow. Note also my text in blue below, highlighting a similar conclusion =
for use of flows 2) and/or 3) as backup channels for flow 1) when flow 1) b=
ecomes too unreliable.

My post below was an attempt to point out that queuing priority AND flow pr=
iority need not be disjoint approaches; in my opinion they can and should b=
oth exist concurrently in systems that deal with real-world problems, at le=
ast in the industrial and process automation markets. They each provide som=
e functionality that the other lacks, giving an overall system that is supe=
rior in its performance of critical functions to one that restricts itself =
to flow priority, or to queuing priority, but without supporting both. My p=
ost below was an attempt to sketch a common scenario in that market where t=
he two priority mechanisms interplay to provide a superior system.

Perhaps my concept of flow differs from those of the original two correspon=
dents. If so, I would appreciate instruction/correction. My scenario below =
was one where resources assigned to secondary flows would be used when the =
primary flow 1) fails. If others' notions of flow are not coupled to contra=
cts and resource allocation in forwarding DL and NL routers, potentially in=
cluding slot prioritization among concurrent slots, then what use is it?

-Tom
=3D=3D=3D=3D=3D
On 2013.03.09 10:36, Kris Pister wrote:
Tom - I agree with everything that you wrote in the email below except the =
first sentence.  Perhaps I'm missing something, but it seems to me that you=
r enumeration of various flows with different requirements fits quite well =
with the discussion fragment quoted at the end below.  Can you help me unde=
rstand the differences?

My bias is that we should have
{flow priority (equating to slotframe priority) OR link priority (TX, RX, u=
ni-, multi-)} AND {packet priority}.

ksjp

On 3/8/2013 11:36 PM, Tom Phinney wrote:
I don't know what real-world use this technology is being designed to suppo=
rt, but the discussion fragments quoted at the end below seem to me to be m=
oving away from reality.

In the industrial automation world where I spent most of my career, it make=
s sense to have different inbound flows for differing purposes. Most sensor=
 devices would have the following flows 1), 2) and 3):
1) a dedicated inbound flow per field device (mote) for periodic determinis=
tic control traffic, where the number of expected hops has to be small when=
 the loop rate is high;
2) a shared inbound flow for usually-infrequent alerts (i.e., device events=
 and process alarms), probably with at least 2-level packet queuing priorit=
y, perhaps using CSMA/CA to provide some slight statistical bias in channel=
 access priority based on packet priority;
3) a shared inbound flow for server-to-client responses, typically in respo=
nse to a program-initiated or operator-initiated action at an engineering w=
orkstation in a control room.

Every process actuator (i.e., mote that can directly manipulate the process=
) will also have another flow 4), analogous to 1) but in the outbound direc=
tion, from the control room to the field to transfer the computed actuator =
setting to the device. Such devices also have inbound flow 1) to transfer a=
ctuator status at the same periodic rate.

If communication problems are experienced on flow 1), it is desirable to be=
 able to use one or more of the other flows as a backup mechanism for inbou=
nd control traffic, whether full determinism can be maintained or not. Pack=
et queuing priority definitely makes sense here, so that such traffic can l=
eapfrog non-deterministic traffic in the output queue of the originating mo=
te and of any intermediary relaying motes. As mentioned in 2), it may also =
make sense to use CSMA/CA to provide some slight statistical bias in channe=
l access priority based on packet priority, at least for flows where the tr=
ansaction template has a non-null CSMA/CA sensing interval before the sched=
uled Data PDU transmission of the transaction.

The reason for priority on the alerts is that process alarms from class 1 -=
 2 devices, (or class 0 - 2 if class 0 uses wireless), would usually be con=
figured to be higher priority than those for classes 3 - 5. (Some class 3 d=
evices might also be assigned that higher alarm priority.) Where safety ala=
rms are concerned, such as the "man down" alarm that Herman Storey mentione=
d on Thursday's call, those alarms would tend to use another flow 5), simil=
ar to 2), with a very low expected rate but with dedicated slots to provide=
 a clear virtual channel (to the extent possible). The time constants for s=
uch alarms are long enough (seconds) compared to much of the flow 1) traffi=
c that the incremental cost of flow 5), which is so similar to flow 2), pro=
bably would not be very much, perhaps 2% of the total network capacity. It =
is tempting to just have a 3-way CSMA/CA interval for flow 2), but the real=
ity of the CSMA/CA priority assessment mechanism is that it is very weak, g=
iven physical modem delays, inter-mote timing skews and the old hidden-node=
 problem. Thus CSMA/CA prioritization does not seem reliable enough to trus=
t for safety purposes.

Of course a system will have other flows, many allocated on a demand basis =
in response to some occasional need, such as firmware download or captured =
waveform upload.

The basic timing of continuous control loops it that the total delay from s=
ensing the process to driving the actuator generally has to be less than tw=
ice the period of the loop. In such cases the needed control strategy is bo=
th relatively simple and relatively stable, However, if the total input-to-=
output delay exceeds twice the loop period, the control becomes much more d=
ifficult and less able to respond to fast transients. Jitter is a problem o=
nly when a process value message is delivered in the wrong cycle; it does n=
ot matter whether the delivery is at the 10% or 90% point in the proper cyc=
le. Authenticated timestamping of the message, as occurs via the UDP transp=
ort nonce in ISA100.11a, provides a means of discarding process value messa=
ges that are delivered too late, thus converting those situations to ones o=
f message loss. That is the desired way of handling late delivery, because =
the control loop is stable under message loss but not when the values are d=
eliberately selectively delayed into the wrong delivery cycle. (Honeywell d=
emonstrated years ago that it was possible to destablize most control loops=
 with such deliberately jittered delivery.)

-Tom
=3D=3D=3D=3D=3D
On 2013.03.08 23:33, Thomas Watteyne wrote:
Michael,

I agree that the term flow is almost as overloaded as link or path. This is=
 not a final term and we will have to come up with a better term. Suggestio=
ns?

If I get your point correctly, you are suggesting that there should be no p=
acket priorities, only flows priority. In a TSCH context, this would transl=
ate into a slotframe per flow, where flow also incorporates the notion of p=
riority. Correct? This is a very important discussion we started over the p=
hone earlier today, but which we will continue Wednesday in Orlando. I hope=
 you can be there.

Thomas

On Fri, Mar 8, 2013 at 6:55 PM, Michael Richardson > wrote:
How can a flow have high priority packets and low priority packets?

Why are these two types of packets using the same DODAG?



_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/=
6tsch



_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/=
6tsch

--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151D041Fxmbalnx10ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable












Hi Tom,







If the above gives the impression that these system=
s are complex and their communications needs not easily ordered into a line=
ar set, then I have succeeded in providing
 some background







##svshah, My response is not highlighting it to be strict linear set p=
riority service. Perhaps my earlier response did not do a good job. In=
fact Diffserv code-points (as well any L2 code-points) and their PHB defini=
tion do not define them a strict ordered
 priority service.







Thanks


Shitanshu









From: Tom Phinney <tom.phinney@cox.net>

Reply-To: Tom Phinney <tom.phinney@cox.net>

Date: Sunday, March 10, 2013 1:38 A=
M

To: "6tsch@ietf.org" <6ts=
ch@ietf.org>

Subject: Re: [6tsch] priority and p=
riority











Shitanshu et=
 al,



I sense that I may be viewing related applications through very different l=
enses than the rest of you. The disconnect is undoubtedly mine, since I am =
not grounded in IETF terminology the way that  you all are.



https://tools.ietf.org/id=
/draft-phinney-roll-rpl-industrial-applicability-02.txt provides much o=
f the background for the following.



Automation of continuous processes often involves large physical plants wit=
h km of piping, hundreds to thousands of valves and thousands to tens of th=
ousands of sensors. Much of the high-value and critical equipment typically=
 is concentrated in areas of about
 1 hectare (i.e., 100 m on a side), typically extending 10 m or more in the=
 air. Other parts are spread over a large area, with most equipment within =
2-3 m of the ground. The largest plant I ever visited was 10k ha (100 squar=
e miles);  the area in which outdoor
 communication is required in these plants can be enormous.



At the other extreme, a pharmaceutical plant may contain many dozen chemica=
l reactors, each with associated piping and valving, each organized as a co=
lumn of equipment on a skid that can be moved and replaced as necessary. Su=
ch a structure is suitable for managing
 chemical or biological reactions that only work at small scale, as well as=
 for providing fine-grained traceability of final product, which latter is =
required by the health agencies of many governments.



>From an automation perspective these plants are more similar than dissimila=
r: each has a set of closed-loop control and monitoring functions that have=
 specific timeliness requirements, where the individual flows that represen=
t purpose-specific communications
 relationships can be ranked in terms of both criticality and their accepta=
ble distribution of delivery delay.



In general, criticality varies inversely with

 1) the communication class (see 2.1.1 in the above document), and

 2) the reporting period. (Note that loop rate is the inverse o=
f reporting
period.) 



A third contributing factor is the role of the specific loop in the plant; =
within a class at a given loop rate those components whose failure has a gr=
eater consequence tend to be higher on the scale.



This 3-component ranking does not lead immediately to a linear priority str=
ucture, because control communications is essentially deadline scheduled ra=
ther than prioritized. As noted in the earlier e-mail, delivery early or la=
te in a given reporting period makes
 no difference; it is only missed delivery deadlines that are consequential=
. Even then, the control strategies that have evolved during the last 50 ye=
ars tolerate a few successive losses (generally <=3D 3) after which they=
 mode-shift to a backup regime that emphasizes
 plant safety over product.



An example may help. Modern toothpaste is mixed in big batch reactors. It i=
ncludes various corrosive and toxic components, including fluoride. A break=
down in control of the mixing process, or of history collection due to lost=
 reports, may lead to tonnes of
 toxic waste (because governments require uninterrupted history collection =
to monitor the contents and safety of such "medical" products). A=
lthough the industry has developed mechanisms to span and recover from brie=
f to moderate communication outages in history
 collection, a failure of the process historian's database will trigger suc=
h a toxic waste disposal problem for the plant manager.



Getting back to the prior discussion, publish-subscribe communications may =
be assigned to flows. When communications redundancy is employed, as it oft=
en is for the highest-ranked monitoring and control loops, the resulting (u=
sually two) assigned flows must
 be disjoint throughout the network, never converging to any point that wou=
ld provide a common failure mode until they reach their final destination, =
which today is usually a fault-tolerant server farm.



Source-sink communications, which is used for stateless device events and s=
tateful process alarms -- the latter go into alarm, then later return to no=
rmal -- has much reduced timeliness constraints, particularly when there is=
 lots of other alarm traffic. There
 is usually a contractual commitment that the first process alarm that occu=
rs in a period of relatively quiescent plant operation will be reported wit=
hin 5 s, often to 4 sigma to 6 sigma confidence. On the other hand, the 70t=
h alarm in a ten minute period has
 no reporting timeliness requirements; it simply should not be lost. As wit=
h historizing and control loops, the industry has developed mechanisms to r=
etrieve process alarm status even when the reporting messages are lost, so =
per-message loss is not a major
 issue. Application-layer-triggered retries push those initial alarms persi=
stently; but once the system is flooded with alarms the delivery requiremen=
ts change. It is for that reason that WirelessHART mandated that each 802.1=
5.4 router have only a single alarm
 forwarding buffer, causing alarm backlogs to build up at the originators (=
where intelligent alarm reordering and aggregation can occur) rather than i=
n intermediary router queues.



Client-server communications is used primarily to respond to human or progr=
ammatic requests for detailed status of remote devices. Periodic publish-su=
bscribe communications typically sends only a single float32 and a coded st=
atus byte; when that status byte
 indicates problems in the device or with the process, a secondary retrieva=
l of more detailed information from the device is usually required. That co=
mmunication typically requires timeliness suitable to sustain human interac=
tion; if it takes too long the operator
 will attempt to accelerate the process by demanding even more data.



Because the bandwidth available for such state retrieval is typically quite=
 low, the centralized side of the automation system typically caches the da=
ta from each such report, thereby being able to present rapid and relativel=
y reliable information to centralized
 automation programs that work with such data. For that same reason, much o=
f the data that is reported by such client-server communications is reporte=
d by exception (rather than as a bulky record) when that is permitted.



If the above gives the impression that these systems are complex and their =
communications needs not easily ordered into a linear set, then I have succ=
eeded in providing some background. The most interesting aspects of these s=
ystems is that the plant owners
 have substantial incentives to improve their processes and increase antici=
patory maintenance, both of which lead to greater revenue. The scale of the=
 problems is large, but so are the potential profits. It is not an accident=
 that many of the world's most valuable
 corporations have a significant portion of their profits generated by such=
 plants. Thus they are more willing than most to try new technology, and to=
 invest in it heavily if it proves reliable and improves the bottom line.


Cheers,

-Tom

=3D=3D=3D=3D=3D







On 2013.03.09 22:04, Shitanshu Shah (svshah) wrote:








Hi Tom, All,







In general I agree with your assessment for need for packet priority.<=
/div>






If forwarding service required is similar to all packets for a given c=
lass, packet priority is all what is required for such services. Like =
traffic classes in your example for deterministic class, alerts, server-cli=
ent response etc..  Treating such class
 of traffic at the aggregate level per packet priority (eg. Based on certai=
n L3 or L2 level code-points) is what is needed for forwarding(queuing) ser=
vice.







I also lack to understand, what is the definition of flow, is it micro=
-flow that has been eluded before?


For micro-flows belonging to the same service class (eg. Belonging to =
alert class), what kind of differentiation needed for different flows withi=
n that class? I would imagine that queuing is expensive and scarce resource=
s in these systems as well just
 like it is for traditional Layer2 switches (at the least in the hardware).=
 Thus probably very expensive to imagine as many queues as many set of flow=
s with different priority.







However, a sort of differentiation that can be imagined at flow level =
may be for other parameters (but not queuing behavior). For example, limiti=
ng rate of a flow that is fed in to the queuing system.excessive traffic to=
 be dropped or re-marked to lower
 priority code-point. Or during congestion drop traffic from certain flows =
over others.







I understand RSVP provides a way to enable integrated queuing service.=
 At the same time, RSVP also has a way to enable reservation based on Diffs=
erv. It is later that I am trying to highlight where packet priority is use=
d for the forwarding decision, and
 flow classification may be used to constrain other parameters like rate.






Taking deterministic class in particular,


As I am not so much familiar with Industrial Automation, what I am not=
 clear if for a given PAN, could there be different set of flows with diffe=
rent deterministic parameters? If there are then I can see some impact to q=
ueuing discipline and packet priority
 itself may not be sufficient. But I am not sure why there would be an appl=
ication (PAN) with devices with different set of deterministic flows. I can=
 also see them causing conflicts when it comes to channel reservation.






Regards,


Shitanshu














From: Tom Phinney <tom.phinney@cox.net>

Reply-To: Tom Phinney <tom.phinney@cox.ne=
t>

Date: Saturday, March 9, 2013 11:=
27 AM

To: "6tsch@ietf.org" <6tsch@ietf.org>

Subject: Re: [6tsch] priority and=
 priority











Kris (et al)=
,



Thank you for your reply and general concurrence.



In my post below I was objecting to the conclusion in the originally quoted=
 interchange,
recolored in red at the end below, that flow=
 priority suffices. My example flow 2) is one in which packet priority make=
s sense WITHIN the flow. Note also my text
in blue below, highlighting a similar conclu=
sion for use of flows 2) and/or 3) as backup channels for flow 1) when flow=
 1) becomes too unreliable.



My post below was an attempt to point out that queuing priority AND flow pr=
iority need not be disjoint approaches; in my opinion they can and should b=
oth exist concurrently in systems that deal with real-world problems, at le=
ast in the industrial and process
 automation markets. They each provide some functionality that the other la=
cks, giving an overall system that is superior in its performance of critic=
al functions to one that restricts itself to flow priority, or to queuing p=
riority, but without supporting
 both. My post below was an attempt to sketch a common scenario in that mar=
ket where the two priority mechanisms interplay to provide a superior syste=
m.



Perhaps my concept of flow differs from those of the original two correspon=
dents. If so, I would appreciate instruction/correction. My scenario below =
was one where resources assigned to secondary flows would be used when the =
primary flow 1) fails. If others'
 notions of flow are not coupled to contracts and resource allocation in fo=
rwarding DL and NL routers,
potentially including slot prioritization among=
 concurrent slots, then what use is it?



-Tom

=3D=3D=3D=3D=3D

On 2013.03.09 10:36, Kris Pister wrote:

T=
om - I agree with everything that you wrote in the email below except the f=
irst sentence.  Perhaps I'm missing something, but it seems to me that=
 your enumeration of various flows with different
 requirements fits quite well with the discussion fragment quoted at the en=
d below.  Can you help me understand the differences?



My bias is that we should have 

{flow priority (equating to slotframe priority) OR link priority (TX, RX, u=
ni-, multi-)} AND {packet priority}.



ksjp




On 3/8/2013 11:36 PM, Tom Phinney wrote:




I don't kno=
w what real-world use this technology is being designed to support, but the=
 discussion fragments quoted at the end below seem to me to be moving away =
from reality.



In the industrial automation world where I spent most of my career, it make=
s sense to have different inbound flows for differing purposes. Most sensor=
 devices would have the following flows 1), 2) and 3):

1) a dedicated inbound flow per field device (mote) for periodic determinis=
tic control traffic, where the number of expected hops has to be small when=
 the loop rate is high;

2) a shared inbound flow for usually-infrequent alerts (i.e., device events=
 and process alarms), probably with at least 2-level packet queuing priorit=
y, perhaps using CSMA/CA to provide some slight statistical bias in channel=
 access priority based on packet
 priority;

3) a shared inbound flow for server-to-client responses, typically in respo=
nse to a program-initiated or operator-initiated action at an engineering w=
orkstation in a control room.



Every process actuator (i.e., mote that can directly manipulate the process=
) will also have another flow 4), analogous to 1) but in the outbound direc=
tion, from the control room to the field to transfer the computed actuator =
setting to the device. Such devices
 also have inbound flow 1) to transfer actuator status at the same periodic=
 rate.



If communication problems are experienced on flow 1), it is desirable to be able to use one or more of the other flows as a ba=
ckup mechanism for inbound control traffic, whether full determinism=
 can be maintained or not.
Packet queuing priority definitely makes sense here=
, so that such traffic can leapfrog non-deterministic traffic in the output=
 queue of the originating mote and of any intermediary relaying motes. As mentioned in 2), it may also
 make sense to use CSMA/CA to provide some slight statistical bias in chann=
el access priority based on packet priority, at least for flows where the t=
ransaction template has a non-null CSMA/CA sensing interval before the sche=
duled Data PDU transmission of the
 transaction.



The reason for priority on the alerts is that process alarms from class 1 -=
 2 devices, (or class 0 - 2 if class 0 uses wireless), would usually be con=
figured to be higher priority than those for classes 3 - 5. (Some class 3 d=
evices might also be assigned that
 higher alarm priority.) Where safety alarms are concerned, such as the &qu=
ot;man down" alarm that Herman Storey mentioned on Thursday's call, th=
ose alarms would tend to use another flow 5), similar to 2), with a very lo=
w expected rate but with dedicated slots to
 provide a clear virtual channel (to the extent possible). The time constan=
ts for such alarms are long enough (seconds) compared to much of the flow 1=
) traffic that the incremental cost of flow 5), which is so similar to flow=
 2), probably would not be very
 much, perhaps 2% of the total network capacity. It is tempting to just hav=
e a 3-way CSMA/CA interval for flow 2), but the reality of the CSMA/CA prio=
rity assessment mechanism is that it is very weak, given physical modem del=
ays, inter-mote timing skews and
 the old hidden-node problem. Thus CSMA/CA prioritization does not seem rel=
iable enough to trust for safety purposes.



Of course a system will have other flows, many allocated on a demand basis =
in response to some occasional need, such as firmware download or captured =
waveform upload.



The basic timing of continuous control loops it that the total delay from s=
ensing the process to driving the actuator generally has to be less than tw=
ice the period of the loop. In such cases the needed control strategy is bo=
th relatively simple and relatively
 stable, However, if the total input-to-output delay exceeds twice the loop=
 period, the control becomes much more difficult and less able to respond t=
o fast transients. Jitter is a problem only when a process value message is=
 delivered in the wrong cycle; it
 does not matter whether the delivery is at the 10% or 90% point in the pro=
per cycle. Authenticated timestamping of the message, as occurs via the UDP=
 transport nonce in ISA100.11a, provides a means of discarding process valu=
e messages that are delivered too
 late, thus converting those situations to ones of message loss. That is th=
e desired way of handling late delivery, because the control loop is stable=
 under message loss but not when the values are deliberately selectively de=
layed into the wrong delivery cycle.
 (Honeywell demonstrated years ago that it was possible to destablize most =
control loops with such deliberately jittered delivery.)



-Tom

=3D=3D=3D=3D=3D

On 2013.03.08 23:33, Thomas Watteyne wrote:


Michael,






I agree that the term flow is almost as overloaded as link or path. Th=
is is not a final term and we will have to come up with a better term. Sugg=
estions?







If I get your point correctly, you are suggesting that 
there should be no packet priorities, only flows priority. In a TSCH=
 context, this would translate into a slotframe per flow, where flow also i=
ncorporates the notion of priority. Correct? This is a very important discu=
ssion we started over the phone
 earlier today, but which we will continue Wednesday in Orlando. I hope you=
 can be there.







Thomas




On Fri, Mar 8, 2013 at 6:55 PM, Michael Richards=
on 
<mcr+ietf@sandelman.ca> wrote:



How can a flow have high priority packets and low p=
riority packets?



Why are these two types of packets using the same DODAG?












 


_______________________________________________
6tsch mailing list
6tsch@ietf.org=
https://www.ietf.org/mailman/listinfo/6tsch







_______________________________________________
6tsch mailing list
6tsch@ietf.org=
https://www.ietf.org/mailman/listinfo/6tsch

















--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151D041Fxmbalnx10ciscoc_--

From svshah@cisco.com  Sun Mar 10 18:10:04 2013
Return-Path: 
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 1BF6D21F844C for <6tsch@ietfa.amsl.com>; Sun, 10 Mar 2013 18:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.098
X-Spam-Level: 
X-Spam-Status: No, score=-11.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 UmOL1Kywvz-b for <6tsch@ietfa.amsl.com>; Sun, 10 Mar 2013 18:10:02 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3728C21F86F8 for <6tsch@ietf.org>; Sun, 10 Mar 2013 18:10:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31369; q=dns/txt; s=iport; t=1362964201; x=1364173801; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=cK3nqGW+niAIFRaYKmZYBXbdc0bmkUraGr2jNZbFxEk=; b=La762rc9dhqmHAx0WYcLtezVZagGtlG4k2uljiLXZeQyY9hTv+Mjm78C EB9WgjR3tqHcp/NwZtpk9mbfQEEHMUgiVSI6UFRor0Zo4xjfygAAcMB9B bOv7L30BScfWLtyNz22MHUvYGAON3AM3Gt58w+erKt8PusvwHDh85bNr4 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAMgtPVGtJXG8/2dsb2JhbABDDoN9wDuBTBZ0giUBAQEDAQEBARdUCwUNAQgRAwECCxYHLgsUCQgCBAoEBQgBiAQGDLtvjUQJgRAgBgsHBoJZYQOnSoJLP4FzNQ
X-IronPort-AV: E=Sophos;i="4.84,819,1355097600";  d="scan'208,217";a="185901935"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 11 Mar 2013 01:10:00 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2B1A0TB019254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 01:10:00 GMT
Received: from xmb-aln-x10.cisco.com ([169.254.5.82]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 20:09:59 -0500
From: "Shitanshu Shah (svshah)" 
To: Kris Pister 
Thread-Topic: [6tsch] priority and priority
Thread-Index: AQHOG89uote0gTOlJkW2KjLq2WdT9ZidEBIAgAA84QCAABGAAIAAp+kAgAAezYCAABskgIABdsSAgAAMWgA=
Date: Mon, 11 Mar 2013 01:09:59 +0000
Message-ID: 
In-Reply-To: <513CEC45.9080209@eecs.berkeley.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [10.21.84.50]
Content-Type: multipart/alternative; boundary="_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151D0432xmbalnx10ciscoc_"
MIME-Version: 1.0
Cc: "6tsch@ietf.org" <6tsch@ietf.org>, Tom Phinney 
Subject: Re: [6tsch] priority and priority
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 01:10:04 -0000

--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151D0432xmbalnx10ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Kris,

> For example, light switches, burglar alarms, and thermostats have very di=
fferent deterministic requirements.

Interestingly enough all of them may co-exist in one WSN network. If they h=
ave different deterministic requirements, eg. hypothetically taking an exam=
ple timely delivery (I take deterministic =3D jitter sensitive) every 2 sec=
onds, 3 seconds and 5 seconds respectively. If they follow the same path, w=
hat would be an expectation when they conflict with each other for a fixed =
slot delivery? For example, light switches and burglar alarms may conflict =
at 6th second. Light switches and thermostats at 10th second. Or am I on so=
me tangent here? If I am completely off the track then feel free to ignore.=
 meeting with folks here at the IETF will make me straight.

btw, do control signals for light switches, thermostats etc. are jitter sen=
sitive (and so fall under deterministic service requirements?)

Thanks
Shitanshu


From: Kris Pister >
Date: Sunday, March 10, 2013 4:25 PM
To: Shitanshu Shah >
Cc: "6tsch@ietf.org" <6tsch@ietf.org>, Tom Phinney >
Subject: Re: [6tsch] priority and priority

Shitanshu -
> As I am not so much familiar with Industrial Automation, what I am not
> clear if for a given PAN, could there be different set of flows with diff=
erent
> deterministic parameters?
   I don't think that the things that Tom is writing about are specific to =
industrial automation.  Most WSN applications have similar kinds of flows. =
 Building automation, smart grid, smart home, etc. all have most if not all=
 of the various flows and requirements enumerated in rfc5637.

For example, light switches, burglar alarms, and thermostats have very diff=
erent deterministic requirements.

ksjp

On 3/9/2013 9:04 PM, Shitanshu Shah (svshah) wrote:

Hi Tom, All,

In general I agree with your assessment for need for packet priority.

If forwarding service required is similar to all packets for a given class,=
 packet priority is all what is required for such services. Like traffic cl=
asses in your example for deterministic class, alerts, server-client respon=
se etc..  Treating such class of traffic at the aggregate level per packet =
priority (eg. Based on certain L3 or L2 level code-points) is what is neede=
d for forwarding(queuing) service.

I also lack to understand, what is the definition of flow, is it micro-flow=
 that has been eluded before?
For micro-flows belonging to the same service class (eg. Belonging to alert=
 class), what kind of differentiation needed for different flows within tha=
t class? I would imagine that queuing is expensive and scarce resources in =
these systems as well just like it is for traditional Layer2 switches (at t=
he least in the hardware). Thus probably very expensive to imagine as many =
queues as many set of flows with different priority.

However, a sort of differentiation that can be imagined at flow level may b=
e for other parameters (but not queuing behavior). For example, limiting ra=
te of a flow that is fed in to the queuing system.excessive traffic to be d=
ropped or re-marked to lower priority code-point. Or during congestion drop=
 traffic from certain flows over others.

I understand RSVP provides a way to enable integrated queuing service. At t=
he same time, RSVP also has a way to enable reservation based on Diffserv. =
It is later that I am trying to highlight where packet priority is used for=
 the forwarding decision, and flow classification may be used to constrain =
other parameters like rate.

Taking deterministic class in particular,
As I am not so much familiar with Industrial Automation, what I am not clea=
r if for a given PAN, could there be different set of flows with different =
deterministic parameters? If there are then I can see some impact to queuin=
g discipline and packet priority itself may not be sufficient. But I am not=
 sure why there would be an application (PAN) with devices with different s=
et of deterministic flows. I can also see them causing conflicts when it co=
mes to channel reservation.

Regards,
Shitanshu


From: Tom Phinney >
Reply-To: Tom Phinney >
Date: Saturday, March 9, 2013 11:27 AM
To: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] priority and priority

Kris (et al),

Thank you for your reply and general concurrence.

In my post below I was objecting to the conclusion in the originally quoted=
 interchange, recolored in red at the end below, that flow priority suffice=
s. My example flow 2) is one in which packet priority makes sense WITHIN th=
e flow. Note also my text in blue below, highlighting a similar conclusion =
for use of flows 2) and/or 3) as backup channels for flow 1) when flow 1) b=
ecomes too unreliable.

My post below was an attempt to point out that queuing priority AND flow pr=
iority need not be disjoint approaches; in my opinion they can and should b=
oth exist concurrently in systems that deal with real-world problems, at le=
ast in the industrial and process automation markets. They each provide som=
e functionality that the other lacks, giving an overall system that is supe=
rior in its performance of critical functions to one that restricts itself =
to flow priority, or to queuing priority, but without supporting both. My p=
ost below was an attempt to sketch a common scenario in that market where t=
he two priority mechanisms interplay to provide a superior system.

Perhaps my concept of flow differs from those of the original two correspon=
dents. If so, I would appreciate instruction/correction. My scenario below =
was one where resources assigned to secondary flows would be used when the =
primary flow 1) fails. If others' notions of flow are not coupled to contra=
cts and resource allocation in forwarding DL and NL routers, potentially in=
cluding slot prioritization among concurrent slots, then what use is it?

-Tom
=3D=3D=3D=3D=3D
On 2013.03.09 10:36, Kris Pister wrote:
Tom - I agree with everything that you wrote in the email below except the =
first sentence.  Perhaps I'm missing something, but it seems to me that you=
r enumeration of various flows with different requirements fits quite well =
with the discussion fragment quoted at the end below.  Can you help me unde=
rstand the differences?

My bias is that we should have
{flow priority (equating to slotframe priority) OR link priority (TX, RX, u=
ni-, multi-)} AND {packet priority}.

ksjp

On 3/8/2013 11:36 PM, Tom Phinney wrote:
I don't know what real-world use this technology is being designed to suppo=
rt, but the discussion fragments quoted at the end below seem to me to be m=
oving away from reality.

In the industrial automation world where I spent most of my career, it make=
s sense to have different inbound flows for differing purposes. Most sensor=
 devices would have the following flows 1), 2) and 3):
1) a dedicated inbound flow per field device (mote) for periodic determinis=
tic control traffic, where the number of expected hops has to be small when=
 the loop rate is high;
2) a shared inbound flow for usually-infrequent alerts (i.e., device events=
 and process alarms), probably with at least 2-level packet queuing priorit=
y, perhaps using CSMA/CA to provide some slight statistical bias in channel=
 access priority based on packet priority;
3) a shared inbound flow for server-to-client responses, typically in respo=
nse to a program-initiated or operator-initiated action at an engineering w=
orkstation in a control room.

Every process actuator (i.e., mote that can directly manipulate the process=
) will also have another flow 4), analogous to 1) but in the outbound direc=
tion, from the control room to the field to transfer the computed actuator =
setting to the device. Such devices also have inbound flow 1) to transfer a=
ctuator status at the same periodic rate.

If communication problems are experienced on flow 1), it is desirable to be=
 able to use one or more of the other flows as a backup mechanism for inbou=
nd control traffic, whether full determinism can be maintained or not. Pack=
et queuing priority definitely makes sense here, so that such traffic can l=
eapfrog non-deterministic traffic in the output queue of the originating mo=
te and of any intermediary relaying motes. As mentioned in 2), it may also =
make sense to use CSMA/CA to provide some slight statistical bias in channe=
l access priority based on packet priority, at least for flows where the tr=
ansaction template has a non-null CSMA/CA sensing interval before the sched=
uled Data PDU transmission of the transaction.

The reason for priority on the alerts is that process alarms from class 1 -=
 2 devices, (or class 0 - 2 if class 0 uses wireless), would usually be con=
figured to be higher priority than those for classes 3 - 5. (Some class 3 d=
evices might also be assigned that higher alarm priority.) Where safety ala=
rms are concerned, such as the "man down" alarm that Herman Storey mentione=
d on Thursday's call, those alarms would tend to use another flow 5), simil=
ar to 2), with a very low expected rate but with dedicated slots to provide=
 a clear virtual channel (to the extent possible). The time constants for s=
uch alarms are long enough (seconds) compared to much of the flow 1) traffi=
c that the incremental cost of flow 5), which is so similar to flow 2), pro=
bably would not be very much, perhaps 2% of the total network capacity. It =
is tempting to just have a 3-way CSMA/CA interval for flow 2), but the real=
ity of the CSMA/CA priority assessment mechanism is that it is very weak, g=
iven physical modem delays, inter-mote timing skews and the old hidden-node=
 problem. Thus CSMA/CA prioritization does not seem reliable enough to trus=
t for safety purposes.

Of course a system will have other flows, many allocated on a demand basis =
in response to some occasional need, such as firmware download or captured =
waveform upload.

The basic timing of continuous control loops it that the total delay from s=
ensing the process to driving the actuator generally has to be less than tw=
ice the period of the loop. In such cases the needed control strategy is bo=
th relatively simple and relatively stable, However, if the total input-to-=
output delay exceeds twice the loop period, the control becomes much more d=
ifficult and less able to respond to fast transients. Jitter is a problem o=
nly when a process value message is delivered in the wrong cycle; it does n=
ot matter whether the delivery is at the 10% or 90% point in the proper cyc=
le. Authenticated timestamping of the message, as occurs via the UDP transp=
ort nonce in ISA100.11a, provides a means of discarding process value messa=
ges that are delivered too late, thus converting those situations to ones o=
f message loss. That is the desired way of handling late delivery, because =
the control loop is stable under message loss but not when the values are d=
eliberately selectively delayed into the wrong delivery cycle. (Honeywell d=
emonstrated years ago that it was possible to destablize most control loops=
 with such deliberately jittered delivery.)

-Tom
=3D=3D=3D=3D=3D
On 2013.03.08 23:33, Thomas Watteyne wrote:
Michael,

I agree that the term flow is almost as overloaded as link or path. This is=
 not a final term and we will have to come up with a better term. Suggestio=
ns?

If I get your point correctly, you are suggesting that there should be no p=
acket priorities, only flows priority. In a TSCH context, this would transl=
ate into a slotframe per flow, where flow also incorporates the notion of p=
riority. Correct? This is a very important discussion we started over the p=
hone earlier today, but which we will continue Wednesday in Orlando. I hope=
 you can be there.

Thomas

On Fri, Mar 8, 2013 at 6:55 PM, Michael Richardson > wrote:
How can a flow have high priority packets and low priority packets?

Why are these two types of packets using the same DODAG?



_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/=
6tsch



_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/=
6tsch



_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/=
6tsch


--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151D0432xmbalnx10ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <212EE6DB804CD341A3D9FA6FB822186A@cisco.com>
Content-Transfer-Encoding: quoted-printable












Hi Kris,







> For example, light switches, burglar alarms, and thermostats have=
 very different deterministic requirements.









Interestingly enough all of them may co-exist in one WSN network. If t=
hey have different deterministic requirements, eg. hypothetically taking an=
 example timely delivery (I take deterministic =3D jitter sensitive) every =
2 seconds, 3 seconds and 5 seconds
 respectively. If they follow the same path, what would be an expectation w=
hen they conflict with each other for a fixed slot delivery? For example, l=
ight switches and burglar alarms may conflict at 6th second. Light switches=
 and thermostats at 10th second.
 Or am I on some tangent here? If I am completely off the track then f=
eel free to ignore. meeting with folks here at the IETF will make me straig=
ht.







btw, do control signals for light switches, thermostats etc. are jitte=
r sensitive (and so fall under deterministic service requirements?)







Thanks


Shitanshu














From: Kris Pister <pister@eecs.berkeley.edu>

Date: Sunday, March 10, 2013 4:25 P=
M

To: Shitanshu Shah <svshah@cisco.com>

Cc: "6tsch@ietf.org" <6ts=
ch@ietf.org>, Tom Phinney <tom.phinney@cox.net>

Subject: Re: [6tsch] priority and p=
riority











Shitanshu - 

> As I am not so much familiar with Industrial Automation, what I am not=


> clear if for a given PAN, could there be different set of flows with d=
ifferent 

> deterministic parameters?

   I don't think that the things that Tom is writing about are sp=
ecific to industrial automation.  Most WSN applications have similar k=
inds of flows.  Building automation, smart grid, smart home, etc. all =
have most if not all of the various flows and requirements
 enumerated in rfc5637.



For example, light switches, burglar alarms, and thermostats have very diff=
erent deterministic requirements.



ksjp




On 3/9/2013 9:04 PM, Shitanshu Shah (svshah)=
 wrote:











Hi Tom, All,







In general I agree with your assessment for need for packet priority.<=
/div>






If forwarding service required is similar to all packets for a given c=
lass, packet priority is all what is required for such services. Like =
traffic classes in your example for deterministic class, alerts, server-cli=
ent response etc..  Treating such class
 of traffic at the aggregate level per packet priority (eg. Based on certai=
n L3 or L2 level code-points) is what is needed for forwarding(queuing) ser=
vice.







I also lack to understand, what is the definition of flow, is it micro=
-flow that has been eluded before?


For micro-flows belonging to the same service class (eg. Belonging to =
alert class), what kind of differentiation needed for different flows withi=
n that class? I would imagine that queuing is expensive and scarce resource=
s in these systems as well just
 like it is for traditional Layer2 switches (at the least in the hardware).=
 Thus probably very expensive to imagine as many queues as many set of flow=
s with different priority.







However, a sort of differentiation that can be imagined at flow level =
may be for other parameters (but not queuing behavior). For example, limiti=
ng rate of a flow that is fed in to the queuing system.excessive traffic to=
 be dropped or re-marked to lower
 priority code-point. Or during congestion drop traffic from certain flows =
over others.







I understand RSVP provides a way to enable integrated queuing service.=
 At the same time, RSVP also has a way to enable reservation based on Diffs=
erv. It is later that I am trying to highlight where packet priority is use=
d for the forwarding decision, and
 flow classification may be used to constrain other parameters like rate.






Taking deterministic class in particular,


As I am not so much familiar with Industrial Automation, what I am not=
 clear if for a given PAN, could there be different set of flows with diffe=
rent deterministic parameters? If there are then I can see some impact to q=
ueuing discipline and packet priority
 itself may not be sufficient. But I am not sure why there would be an appl=
ication (PAN) with devices with different set of deterministic flows. I can=
 also see them causing conflicts when it comes to channel reservation.






Regards,


Shitanshu














From: Tom Phinney <tom.phinney@cox.net&=
gt;

Reply-To: Tom Phinney <tom.phinney@cox.net<=
/a>>

Date: Saturday, March 9, 2013 11:27=
 AM

To: "6tsch@ietf.org" <6tsch@ietf.org>

Subject: Re: [6tsch] priority and p=
riority











Kris (et al)=
,



Thank you for your reply and general concurrence.



In my post below I was objecting to the conclusion in the originally quoted=
 interchange,
recolored in red at the end below, that flow=
 priority suffices. My example flow 2) is one in which packet priority make=
s sense WITHIN the flow. Note also my text
in blue below, highlighting a similar conclu=
sion for use of flows 2) and/or 3) as backup channels for flow 1) when flow=
 1) becomes too unreliable.



My post below was an attempt to point out that queuing priority AND flow pr=
iority need not be disjoint approaches; in my opinion they can and should b=
oth exist concurrently in systems that deal with real-world problems, at le=
ast in the industrial and process
 automation markets. They each provide some functionality that the other la=
cks, giving an overall system that is superior in its performance of critic=
al functions to one that restricts itself to flow priority, or to queuing p=
riority, but without supporting
 both. My post below was an attempt to sketch a common scenario in that mar=
ket where the two priority mechanisms interplay to provide a superior syste=
m.



Perhaps my concept of flow differs from those of the original two correspon=
dents. If so, I would appreciate instruction/correction. My scenario below =
was one where resources assigned to secondary flows would be used when the =
primary flow 1) fails. If others'
 notions of flow are not coupled to contracts and resource allocation in fo=
rwarding DL and NL routers,
potentially including slot prioritization among=
 concurrent slots, then what use is it?



-Tom

=3D=3D=3D=3D=3D

On 2013.03.09 10:36, Kris Pister wrote:

T=
om - I agree with everything that you wrote in the email below except the f=
irst sentence.  Perhaps I'm missing something, but it seems to me that=
 your enumeration of various flows with different
 requirements fits quite well with the discussion fragment quoted at the en=
d below.  Can you help me understand the differences?



My bias is that we should have 

{flow priority (equating to slotframe priority) OR link priority (TX, RX, u=
ni-, multi-)} AND {packet priority}.



ksjp




On 3/8/2013 11:36 PM, Tom Phinney wrote:




I don't kno=
w what real-world use this technology is being designed to support, but the=
 discussion fragments quoted at the end below seem to me to be moving away =
from reality.



In the industrial automation world where I spent most of my career, it make=
s sense to have different inbound flows for differing purposes. Most sensor=
 devices would have the following flows 1), 2) and 3):

1) a dedicated inbound flow per field device (mote) for periodic determinis=
tic control traffic, where the number of expected hops has to be small when=
 the loop rate is high;

2) a shared inbound flow for usually-infrequent alerts (i.e., device events=
 and process alarms), probably with at least 2-level packet queuing priorit=
y, perhaps using CSMA/CA to provide some slight statistical bias in channel=
 access priority based on packet
 priority;

3) a shared inbound flow for server-to-client responses, typically in respo=
nse to a program-initiated or operator-initiated action at an engineering w=
orkstation in a control room.



Every process actuator (i.e., mote that can directly manipulate the process=
) will also have another flow 4), analogous to 1) but in the outbound direc=
tion, from the control room to the field to transfer the computed actuator =
setting to the device. Such devices
 also have inbound flow 1) to transfer actuator status at the same periodic=
 rate.



If communication problems are experienced on flow 1), it is desirable to be able to use one or more of the other flows as a ba=
ckup mechanism for inbound control traffic, whether full determinism=
 can be maintained or not.
Packet queuing priority definitely makes sense here=
, so that such traffic can leapfrog non-deterministic traffic in the output=
 queue of the originating mote and of any intermediary relaying motes. As mentioned in 2), it may also
 make sense to use CSMA/CA to provide some slight statistical bias in chann=
el access priority based on packet priority, at least for flows where the t=
ransaction template has a non-null CSMA/CA sensing interval before the sche=
duled Data PDU transmission of the
 transaction.



The reason for priority on the alerts is that process alarms from class 1 -=
 2 devices, (or class 0 - 2 if class 0 uses wireless), would usually be con=
figured to be higher priority than those for classes 3 - 5. (Some class 3 d=
evices might also be assigned that
 higher alarm priority.) Where safety alarms are concerned, such as the &qu=
ot;man down" alarm that Herman Storey mentioned on Thursday's call, th=
ose alarms would tend to use another flow 5), similar to 2), with a very lo=
w expected rate but with dedicated slots to
 provide a clear virtual channel (to the extent possible). The time constan=
ts for such alarms are long enough (seconds) compared to much of the flow 1=
) traffic that the incremental cost of flow 5), which is so similar to flow=
 2), probably would not be very
 much, perhaps 2% of the total network capacity. It is tempting to just hav=
e a 3-way CSMA/CA interval for flow 2), but the reality of the CSMA/CA prio=
rity assessment mechanism is that it is very weak, given physical modem del=
ays, inter-mote timing skews and
 the old hidden-node problem. Thus CSMA/CA prioritization does not seem rel=
iable enough to trust for safety purposes.



Of course a system will have other flows, many allocated on a demand basis =
in response to some occasional need, such as firmware download or captured =
waveform upload.



The basic timing of continuous control loops it that the total delay from s=
ensing the process to driving the actuator generally has to be less than tw=
ice the period of the loop. In such cases the needed control strategy is bo=
th relatively simple and relatively
 stable, However, if the total input-to-output delay exceeds twice the loop=
 period, the control becomes much more difficult and less able to respond t=
o fast transients. Jitter is a problem only when a process value message is=
 delivered in the wrong cycle; it
 does not matter whether the delivery is at the 10% or 90% point in the pro=
per cycle. Authenticated timestamping of the message, as occurs via the UDP=
 transport nonce in ISA100.11a, provides a means of discarding process valu=
e messages that are delivered too
 late, thus converting those situations to ones of message loss. That is th=
e desired way of handling late delivery, because the control loop is stable=
 under message loss but not when the values are deliberately selectively de=
layed into the wrong delivery cycle.
 (Honeywell demonstrated years ago that it was possible to destablize most =
control loops with such deliberately jittered delivery.)



-Tom

=3D=3D=3D=3D=3D

On 2013.03.08 23:33, Thomas Watteyne wrote:


Michael,






I agree that the term flow is almost as overloaded as link or path. Th=
is is not a final term and we will have to come up with a better term. Sugg=
estions?







If I get your point correctly, you are suggesting that 
there should be no packet priorities, only flows priority. In a TSCH=
 context, this would translate into a slotframe per flow, where flow also i=
ncorporates the notion of priority. Correct? This is a very important discu=
ssion we started over the phone
 earlier today, but which we will continue Wednesday in Orlando. I hope you=
 can be there.







Thomas




On Fri, Mar 8, 2013 at 6:55 PM, Michael Richards=
on 
<mcr+ietf@sandelman.ca> wrote:



How can a flow have high priority packets and low p=
riority packets?



Why are these two types of packets using the same DODAG?












 


_______________________________________________
6tsch mailing list
6tsch@ietf.org=
https://www.ietf.org/mailman/listinfo/6tsch







_______________________________________________
6tsch mailing list
6tsch@ietf.org=
https://www.ietf.org/mailman/listinfo/6tsch










 


_______________________________________________
6tsch mailing list
6tsch@=
ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch












--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED151D0432xmbalnx10ciscoc_--

From maria-rita.palattella@uni.lu  Mon Mar 11 01:48:53 2013
Return-Path: 
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 1C0D321F882D for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 01:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 LrJEPJT8bS8A for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 01:48:52 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4387021F87F6 for <6tsch@ietf.org>; Mon, 11 Mar 2013 01:48:51 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,822,1355094000"; d="scan'208";a="22799133"
Received: from unknown (HELO Archer.uni.lux) ([10.21.2.1]) by hercules.uni.lu with ESMTP; 11 Mar 2013 09:48:50 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Archer.uni.lux ([fe80::1009:b1e7:2b72:f0b8%10]) with mapi id 14.01.0438.000; Mon, 11 Mar 2013 09:48:50 +0100
From: Maria Rita PALATTELLA 
To: Michael Richardson , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] DIOs/DAOs and broadcast channels on TSCH
Thread-Index: AQHOE9f971OPMS+fsEWJx/Qy5c1rNJiLufcwgBDmtQCAA5yEUA==
Date: Mon, 11 Mar 2013 08:48:50 +0000
Message-ID: 
References: <512C36F4.4000409@eecs.berkeley.edu>  <18297.1362795584@sandelman.ca>
In-Reply-To: <18297.1362795584@sandelman.ca>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.91.0.223]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 08:48:53 -0000

TWljaGFlbCwgdGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrcy4NClJpZ2h0LCBJIHNlZSB5b3VyIHBv
aW50LCBhbmQgSSBkbyBhZ3JlZS4gDQpXaGF0IGFib3V0IHNldHRpbmcgYSBicm9hZGNhc3QgY2hh
bm5lbCAgcGVyaW9kaWNhbGx5LCAgIHdoZW4gb24tYXZlcmFnZSB0aGVyZSBpcyBuZWVkIHRvIGV4
Y2hhbmdlIG11bHRpLWNhc3QgdHJhZmZpYz8NCk1hcmlhIFJpdGENCg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KRnJvbTogNnRzY2gtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOjZ0c2No
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsIFJpY2hhcmRzb24NClNlbnQ6
IFNhdHVyZGF5LCBNYXJjaCAwOSwgMjAxMyAzOjIwIEFNDQpUbzogNnRzY2hAaWV0Zi5vcmcNClN1
YmplY3Q6IFJlOiBbNnRzY2hdIERJT3MvREFPcyBhbmQgYnJvYWRjYXN0IGNoYW5uZWxzIG9uIFRT
Q0gNCg0KDQo+Pj4+PiAiTWFyaWEiID09IE1hcmlhIFJpdGEgUEFMQVRURUxMQSA8bWFyaWEtcml0
YS5wYWxhdHRlbGxhQHVuaS5sdT4gd3JpdGVzOg0KICAgIE1hcmlhPiAzKSB0cmFuc21pc3Npb24g
b2Ygc2lnbmFsaW5nIG1lc3NhZ2VzIGZvciBzZXR0aW5nIHVwIHRoZQ0KICAgIE1hcmlhPiBzY2hl
ZHVsZS4gTGV0J3MgYXNzdW1lIHRoZXJlIGlzIGEgc2NoZWR1bGVyIHRoYXQgYnVpbGRzIHRoZQ0K
ICAgIE1hcmlhPiBzY2hlZHVsZSBmb3IgdGhlIG5ldHdvcmsuIEluIG9yZGVyIHRvIGFzc2lnbiBz
b21lIGxpbmtzIHRvDQogICAgTWFyaWE+IGVhY2ggb2YgdGhlbSwgaXQgd2lsbCBuZWVkIHRvIGJy
b2FkY2FzdCB0aGUgaW5mb3JtYXRpb24NCiAgICBNYXJpYT4gcmVsYXRlZCB0byAoIHRpbWVPZmZz
ZXQsIENoYW5uZWxPZmZzZXQpLiBBcyBmb3IgdGhlDQogICAgTWFyaWE+IHN5bmNocm9uaXphdGlv
biwgaGF2aW5nIGEgYnJvYWRjYXN0IGNoYW5uZWwgZGVkaWNhdGVkIHRvIHRoZQ0KICAgIE1hcmlh
PiBzaWduYWxpbmcgd2lsbCBhbGxvdyB0byBzZXQgdXAgdGhlIHNjaGVkdWxlIGluIHNob3J0ZXIg
dGltZS4NCg0KICAgIE1hcmlhPiBNYXliZSwgYmVjYXVzZSB0aGVyZSBhcmUgMTYgYXZhaWxhYmxl
IGNoYW5uZWxzIGluDQogICAgTWFyaWE+IElFRUU4MDIuMTUuNC8xNS40ZSBQSFksIHVzaW5nIHNv
bWUgb2YgdGhlbSBhcyBicm9hZGNhc3QNCiAgICBNYXJpYT4gY2hhbm5lbHMgZm9yIHN5bmNocm9u
aXphdGlvbi9leGNoYW5nZSBvZiBjcm9zcy1sYXllciBpbmZvL3NldA0KICAgIE1hcmlhPiB1cCBv
ZiB0aGUgc2NoZWR1bGUgd291bGRuJ3QgYmUgYSBiaWcgcHJvYmxlbS4gSW4gbWFueQ0KICAgIE1h
cmlhPiBhcHBsaWNhdGlvbnMsIGEgc21hbGxlciBzZXQgb2YgY2hhbm5lbHMgKDwgMTYpIHdpbGwg
YmUgZW5vdWdoDQogICAgTWFyaWE+IGZvciBidWlsZGluZyBhIHJlbGlhYmxlIHNjaGVkdWxlLg0K
DQpBcmUgdGhlcmUgbXVsdGljYXN0cyB0aGF0IG5lZWQgdG8gZ28gb3V0IG90aGVyIHRoYW4gUlBM
IERJT3M/DQpUaG9zZSB3aWxsIGdvIG91dCBiYXNlZCB1cG9uIHRyaWNrbGUuLi4gaW4gYSBzdGFi
bGUgbmV0d29yaywgdGhlIERJT3Mgd2lsbCBiZSByYXJlIGNvbXBhcmVkIHRvIGFjdHVhbCB0cmFm
ZmljLi4uIGlmIHRoZSBuZXR3b3JrIGRhdGEgaXMgYWxzbyBzbyBsaWdodCBhcyB0byBiZSBhYmxl
IHRvIGVhc2lseSBhbGxvY2F0ZSBtYW55IGNoYW5uZWxzLCB0aGVuLi4uIHdoeSBkb2VzZCBub3Qg
bmVlZCA2dHNjaCBhdCBhbGwuLi4gdGhlIExMTiBzaG91bGQgaGF2ZSBsb3RzIG9mIGJhbmR3aWR0
aCB0byBnZXQgdGhlIGNvbnRyb2xzIHRocm91Z2guDQoNClNvIGl0IHNlZW1zIHRvIG1lIHRoYXQg
cmVhbGx5IHRha2luZyBhbnkgY2hhbm5lbHMgdXAgZm9yIGJyb2FkY2FzdCB3b3VsZCBiZSBhIGJh
ZCBpZGVhIGlmIHRoZXJlIGFyZSBvdGhlciBvcHRpb25zLg0KDQoNCi0tDQpNaWNoYWVsIFJpY2hh
cmRzb24NCi1vbiB0aGUgcm9hZC0NCg==

From maria-rita.palattella@uni.lu  Mon Mar 11 03:21:29 2013
Return-Path: 
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 7DA1B21F86E4 for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 03:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 6mudYibL7SRw for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 03:21:29 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9456821F8697 for <6tsch@ietf.org>; Mon, 11 Mar 2013 03:21:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,822,1355094000"; d="scan'208,217";a="22802552"
Received: from unknown (HELO REED.uni.lux) ([10.21.2.9]) by hercules.uni.lu with ESMTP; 11 Mar 2013 11:21:28 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by REED.uni.lux ([fe80::31bb:b7a3:7abb:813e%10]) with mapi id 14.01.0438.000; Mon, 11 Mar 2013 11:21:27 +0100
From: Maria Rita PALATTELLA 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: terminology-draft posted
Thread-Index: Ac4eQiidDbVeURWoT3SY2WtSZB4cow==
Date: Mon, 11 Mar 2013 10:21:26 +0000
Message-ID: 
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.91.0.223]
Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D18527343hoshiunilux_"
MIME-Version: 1.0
Subject: [6tsch] terminology-draft posted
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 10:21:29 -0000

--_000_F085911F642A6847987ADA23E611780D18527343hoshiunilux_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,


You can find version 00 of the 6tsch-terminology draft at  http://www.ietf.=
org/internet-drafts/draft-palattella-6tsch-terminology-00.txt .

Best Regards,

Maria Rita


--_000_F085911F642A6847987ADA23E611780D18527343hoshiunilux_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











All,


 


You can find ver=
sion 00 of the 6tsch-terminology draft at
 http://www.ietf.org/internet-drafts/draft-palat=
tella-6tsch-terminology-00.txt .<=
o:p>


 


Best Regards,<=
/o:p>


 


Maria Rita


 






--_000_F085911F642A6847987ADA23E611780D18527343hoshiunilux_--

From pister@eecs.berkeley.edu  Mon Mar 11 08:55:23 2013
Return-Path: 
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 65E4221F87CB for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 08:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 W84uom94Smqt for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 08:55:22 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id C8CA821F878F for <6tsch@ietf.org>; Mon, 11 Mar 2013 08:55:22 -0700 (PDT)
Received: from dhcp-32-89.eecs.berkeley.edu ([128.32.32.89]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1UF54K-0003Xn-EN for 6tsch@ietf.org; Mon, 11 Mar 2013 08:55:21 -0700
Message-ID: <513DFE69.9030908@eecs.berkeley.edu>
Date: Mon, 11 Mar 2013 08:55:21 -0700
From: Kris Pister 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: 6tsch@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060309020503080600010505"
Subject: Re: [6tsch] terminology-draft posted
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 15:55:23 -0000

This is a multi-part message in MIME format.
--------------060309020503080600010505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

That's very helpful.

A couple of nits:

cell - "a single element in the TSCH schedule" should be "a single 
element in a TSCH superframe".  Cells are not defined just by slot and 
channel offset, but also by superframe length.

SlotOffset - "in the TSCH schedule" should be "in a TSCH superframe"

ksjp

On 3/11/2013 3:21 AM, Maria Rita PALATTELLA wrote:
>
> All,
>
> You can find version 00 of the 6tsch-terminology draft at 
> http://www.ietf.org/internet-drafts/draft-palattella-6tsch-terminology-00.txt .
>
> Best Regards,
>
> Maria Rita
>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


--------------060309020503080600010505
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    That's very helpful.

    

    A couple of nits:

    

    cell - "a single element in the TSCH schedule" should be "a single
    element in a TSCH superframe".  Cells are not defined just by slot
    and channel offset, but also by superframe length.

    

    SlotOffset - "in the TSCH schedule" should be "in a TSCH superframe"

    

    ksjp

    

    
On 3/11/2013 3:21 AM, Maria Rita
      PALATTELLA wrote:

    

    

      
      
      
      

        
All,

        
 

        
You can
            find version 00 of the 6tsch-terminology draft at
           http://www.ietf.org/internet-drafts/draft-palattella-6tsch-terminology-00.txt .

        
 

        
Best
            Regards,

        
 

        
Maria Rita

        
 

      

      

      

      

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


    

    

  


--------------060309020503080600010505--

From qinwang@berkeley.edu  Mon Mar 11 09:19:11 2013
Return-Path: 
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 63A0721F8C00 for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 09:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.037
X-Spam-Level: 
X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=0.562,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 9han1yUDGd6E for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 09:19:10 -0700 (PDT)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1308321F8BE2 for <6tsch@ietf.org>; Mon, 11 Mar 2013 09:19:10 -0700 (PDT)
Received: from cm04ws.ist.berkeley.edu ([169.229.218.166] helo=calmail.berkeley.edu) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UF5RL-00037n-Hh for 6tsch@ietf.org; Mon, 11 Mar 2013 09:19:09 -0700
Received: from 207.239.114.206 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Mon, 11 Mar 2013 09:19:07 -0700
Message-ID: <296b61d18ba0a4fcba5b7362a8f96b49.squirrel@calmail.berkeley.edu>
In-Reply-To: 
References: 
Date: Mon, 11 Mar 2013 09:19:07 -0700
From: "Qin Wang" 
To: "6tsch@ietf.org" <6tsch@ietf.org>
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: [6tsch] 6tus draft
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 16:19:11 -0000

All,

6tus is available at: http://www.ietf.org/id/draft-wang-6tsch-6tus-00.txt

Qin


From pister@eecs.berkeley.edu  Mon Mar 11 09:20:50 2013
Return-Path: 
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 F20B021F8C78 for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 09:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level: 
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4]
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 6cw5PVmupuxd for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 09:20:48 -0700 (PDT)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 96B9121F8C69 for <6tsch@ietf.org>; Mon, 11 Mar 2013 09:20:47 -0700 (PDT)
Received: from dhcp-32-89.eecs.berkeley.edu ([128.32.32.89]) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1UF5Sv-0004Cd-HA for 6tsch@ietf.org; Mon, 11 Mar 2013 09:20:47 -0700
Message-ID: <513E045E.7040308@eecs.berkeley.edu>
Date: Mon, 11 Mar 2013 09:20:46 -0700
From: Kris Pister 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: 6tsch@ietf.org
References: <512C36F4.4000409@eecs.berkeley.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 16:20:50 -0000

Maria Rita -
  Does a single Aloha slot plus a trickle timer provide what we need for 
broadcast?  It seems like it should.

I was assuming that a DODAG root (PAN coordinator) would pick a frame 
length and slot parameters and start advertising a single Aloha slot in 
that frame.  Depending on the type of network, most traffic would 
quickly move off of this fixed, shared resource into dedicated 
appropriately-scheduled cells, leaving it free for "random" traffic, 
such as broadcast.

If I were (hypothetically) sending signaling messages from a PCE, I 
would not use a broadcast channel in most networks.  Rather, I would set 
up a dedicated "downstream" slotframe with one non-colliding multicast 
cell from each parent to its children.  That also creates a 
broadcast-capable MAC graph, but allows much faster propagation. In any 
case, whether it's Aloha or a non-colliding tree that provides the 
connectivity, I'd source route as far down as possible to minimize 
overhead traffic on all of the other nodes.

Also, I agree that using fewer than 16 channels is acceptable for 
building reliable schedules.  Somewhere around 3--5 channels gets you 
most of the multi-path resilience that you'll get with 16.  This is 
important for those who must blacklist due to customer constraints 
(typically irrational constraints, but...).  I just wanted to clarify 
that when you suggested "using some of them as broadcast channels" that 
you meant using dedicated channel offsets, not actual radio channels.  
In terms of available cell bandwidth, the impact is the same, but in 
terms of reliability the difference is huge.

ksjp

On 2/25/2013 11:55 PM, Maria Rita PALATTELLA wrote:
> Hello Xavi,
> from my point of view, having a TSCH broadcast channel could be useful in several situations:
>
>>>> a) ADV need broadcast channels in case they are used to synchronize the network. IEEE 802.15.4e provides the timekeeping flag to set that channels as used for synchronization and shared flag can make them broadcast.
>>>> b) Those networks that do not need ADV for synchronization then can use any TX link for ADV, this means that if it is not shared only the node listening on that link will get the ADV. However as this periodically occurs the ADV might eventually be listened  >>>in all channels.
> 1) synchronization (as you said in [a]): it will allow to have a faster set-up phase for synchronizing all the motes in the network. While, using  any TX link ([b]), even though this will hop from one channel to another, it will imply a longer set-up phase, because each mote will be able to synchronize at a different time (when it is in listen mode on the "right" channel).
>   
>>>> c)Some DAOs and all DIOs require a broadcast channel. Should the schedule provide that? in case of a), can the same link be used? How this link should be installed in the nodes?
> 2) transmission of RPL messages (DAOs and DIOs). If we want TSCH works with RPL, then we should reserve some slots of the schedule for exchanging information between L3 and L2. I am not sure we should use the same link used for synchronization, maybe it could be better to have 2 different ones, dedicated to different purposes. Anyway, this is something to check.
>
>>>> d)Is the scheduler of the network who should setup a broadcast channel independent of the broadcast channel set for ADV? can it be the same? Or in contrast, 6tus can configure the EB so it indicates a broadcast channel..
> 3) transmission of signaling messages for setting up the schedule. Let's  assume there is a scheduler that builds the schedule for the network. In order to assign some links to each of them, it  will need to broadcast the information related to ( timeOffset, ChannelOffset). As for the synchronization, having a broadcast channel dedicated to the signaling will allow to set up the schedule in shorter time.
>
> Maybe, because there are 16 available channels in  IEEE802.15.4/15.4e PHY, using some of them as broadcast channels for synchronization/exchange of cross-layer info/set up of the schedule wouldn't  be a big problem. In many applications, a smaller set of channels (< 16) will be enough for building a reliable schedule.
>
> 6tus, as adaptation layer, may have a key role in the configuration of such broadcast channels, but we will need to think  "how/when" it should take care of that.
>
> For now, let's see what other 6tus members think about!
>
> Maria Rita
>
>   
>
>
> -----Original Message-----
> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana
> Sent: Tuesday, February 26, 2013 5:16 AM
> To: 6tsch@ietf.org
> Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>
> Hi,
>
> I have a question that i want to discuss, the question is whether we need a broadcast channel in TSCH or not and what kind of support 6tus should provide. (the answer can be depends... but lets see some cases)
>
> a) ADV need broadcast channels in case they are used to synchronize the network. IEEE 802.15.4e provides the timekeeping flag to set that channels as used for synchronization and shared flag can make them broadcast.
> b) Those networks that do not need ADV for synchronization then can use any TX link for ADV, this means that if it is not shared only the node listening on that link will get the ADV. However as this periodically occurs the ADV might eventually be listened in all channels.
> c)Some DAOs and all DIOs require a broadcast channel. Should the schedule provide that? in case of a), can the same link be used? How this link should be installed in the nodes?
> d)Is the scheduler of the network who should setup a broadcast channel independent of the broadcast channel set for ADV? can it be the same? Or in contrast, 6tus can configure the EB so it indicates a broadcast channel..
> e)..
>
> I would like to know what is your opinion on that.
>
> cheers!
> Xavi
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


From pthubert@cisco.com  Mon Mar 11 09:42:09 2013
Return-Path: 
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 655B811E8169 for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 09:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.099
X-Spam-Level: 
X-Spam-Status: No, score=-11.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, 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 d06liUypM8dy for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 09:42:08 -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 BAF8B11E8163 for <6tsch@ietf.org>; Mon, 11 Mar 2013 09:42:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2600; q=dns/txt; s=iport; t=1363020128; x=1364229728; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=oPkea8R1wiHdyQKDFJWhEtPC21afnaZhzYxqduafR1Y=; b=N5D5nDtR1MyYN2++0hJkbb0t9K72K48XO5NWRHW+7QW9/hgkIO6rrJdi j2pEdWai353kTYJSWm6ltYTGXmiXKpMD7EcOswJsFuhCqlMZ0N5QWcByJ CSyo88Zjt/g4AZudczl4xfUa6sQsC8aOOwrG9aM0+lQ6H0M54WKgHS70Y 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAEEIPlGtJV2c/2dsb2JhbABDiCe8N2hzFm0HgikBAQEEIxFDDgQCAQgRAQMBAQMCBh0DAgICMBQBAgQBAQUDAgQTCAGICgyqbZInF4EjjDt/JhIGgicyYQOXc49XgwqCKA
X-IronPort-AV: E=Sophos;i="4.84,824,1355097600"; d="scan'208";a="186164250"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 11 Mar 2013 16:42:08 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2BGg8WB018384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Mon, 11 Mar 2013 16:42:08 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 11:42:08 -0500
From: "Pascal Thubert (pthubert)" 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: New Version Notification for draft-thubert-6tsch-architecture-00.txt
Thread-Index: AQHOHnbtgKDd4VNXb06WywbXFG5kZ5igsQjg
Date: Mon, 11 Mar 2013 16:42:06 +0000
Deferred-Delivery: Mon, 11 Mar 2013 16:41:00 +0000
Message-ID: 
References: <20130311163851.18986.84945.idtracker@ietfa.amsl.com>
In-Reply-To: <20130311163851.18986.84945.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.89.242]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [6tsch] FW: New Version Notification for draft-thubert-6tsch-architecture-00.txt
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 16:42:09 -0000

SGk6DQoNCldlIGp1c3QgcHVibGlzaGVkIHRoZSAwMCBkcmFmdCBvZiB0aGUgYXJjaGl0ZWN0dXJl
LiBUaGlzIGRvY3VtZW50IHdpbGwgYmVlZiB1cCBhcyB3ZSBtYWtlIGRlc2lnbiBkZWNpc2lvbnMs
IGVnIG9uIHRpbWUgc3luYywgYW5kIHByaW9yaXRpZXMuDQoNCkNoZWVycywNCg0KUGFzY2FsDQoN
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm
Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBsdW5kaSAxMSBt
YXJzIDIwMTMgMTc6MzkNClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpDYzogdHdhdHRl
eW5lQGxpbmVhci5jb207IHJvYmVydC5hc3NpbWl0aUBuaXZpcy5jb20NClN1YmplY3Q6IE5ldyBW
ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdGh1YmVydC02dHNjaC1hcmNoaXRlY3R1cmUt
MDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXRodWJlcnQtNnRzY2gtYXJj
aGl0ZWN0dXJlLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXNj
YWwgVGh1YmVydCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1l
OgkgZHJhZnQtdGh1YmVydC02dHNjaC1hcmNoaXRlY3R1cmUNClJldmlzaW9uOgkgMDANClRpdGxl
OgkJIEFuIEFyY2hpdGVjdHVyZSBmb3IgSVB2NiBvdmVyIFRpbWUgU3luY2hyb25pemVkIENoYW5u
ZWwgSG9wcGluZw0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDMtMTENCkdyb3VwOgkJIEluZGl2aWR1
YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMg0KVVJMOiAgICAgICAgICAgICBodHRw
Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10aHViZXJ0LTZ0c2NoLWFyY2hp
dGVjdHVyZS0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC10aHViZXJ0LTZ0c2NoLWFyY2hpdGVjdHVyZQ0KSHRtbGl6ZWQ6ICAgICAg
ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0LTZ0c2NoLWFyY2hpdGVj
dHVyZS0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBhbiBhcmNo
aXRlY3R1cmUgZm9yIGFuIElQdjYgbXVsdGlsaW5rIHN1Ym5ldA0KICAgdGhhdCBpcyBjb21wb3Nl
ZCBvZiBhIGhpZ2ggc3BlZWQgcG93ZXJlZCBiYWNrYm9uZSBhbmQgYSBudW1iZXIgb2YNCiAgIElF
RUU4MDIuMTUuNGUgVFNDSCB3aXJlbGVzcyBuZXR3b3JrcyBhdHRhY2hlZCBhbmQgc3luY2hyb25p
emVkIGJ5DQogICBCYWNrYm9uZSBSb3V0ZXJzLiAgUm91dGUgQ29tcHV0YXRpb24gbWF5IGJlIGFj
aGlldmVkIGluIGEgY2VudHJhbGl6ZWQNCiAgIGZhc2hpb24gYnkgYSBQYXRoIENvbXB1dGF0aW9u
IEVsZW1lbnQsIGluIGEgZGlzdHJpYnV0ZWQgZmFzaGlvbiB1c2luZw0KICAgdGhlIFJvdXRpbmcg
UHJvdG9jb2wgZm9yIExvdyBQb3dlciBhbmQgTG9zc3kgTmV0d29ya3MsIG9yIGluIGEgbWl4ZWQN
CiAgIG1vZGUuICBUaGUgQmFja2JvbmUgUm91dGVycyBwZXJmb3JtIHByb3h5IE5laWdoYm9yIGRp
c2NvdmVyeQ0KICAgb3BlcmF0aW9ucyBvdmVyIHRoZSBiYWNrYm9uZSBvbiBiZWhhbGYgb2YgdGhl
IHdpcmVsZXNzIGRldmljZSwgc28NCiAgIHRoZXkgY2FuIHNoYXJlIGEgc2FtZSBzdWJuZXQgYW5k
IGFwcGVhciB0byBiZSBjb25uZWN0ZWQgdG8gdGhlIHNhbWUNCiAgIGJhY2tib25lIGFzIGNsYXNz
aWNhbCBkZXZpY2VzLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVU
RiBTZWNyZXRhcmlhdA0KDQo=

From pister@eecs.berkeley.edu  Mon Mar 11 10:47:18 2013
Return-Path: 
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 3972211E80DE for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 10:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level: 
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 vMpJxfPRZO5s for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 10:47:16 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1814611E80CC for <6tsch@ietf.org>; Mon, 11 Mar 2013 10:47:16 -0700 (PDT)
Received: from dhcp-32-89.eecs.berkeley.edu ([128.32.32.89]) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1UF6oP-0002dh-LC; Mon, 11 Mar 2013 10:47:15 -0700
Message-ID: <513E1896.9000903@eecs.berkeley.edu>
Date: Mon, 11 Mar 2013 10:47:02 -0700
From: Kris Pister 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: "Shitanshu Shah (svshah)" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090800020709020808020108"
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] priority and priority
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 17:47:18 -0000

This is a multi-part message in MIME format.
--------------090800020709020808020108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Shitanshu - I think that you're on the right track.  Here's how I look 
at the WSN world:

For energy efficiency in WSN, we'd prefer to never transmit anything.  
Unfortunately for battery life, users set requirements on data reception 
rate, latency, and reliability.
The goal of WSN is to meet these L4 user QoS requirements via L3 routes 
on L2 waking schedules, while minimizing global power and traffic, 
subject to node-local power and energy constraints.
 From that perspective, *every* flow in the network is jitter sensitive 
and deterministic.  If not, then there are resources being wasted.  When 
I ask people about their latency and reliability requirements, I often 
hear "oh, I don't care much about latency and reliability", and I say 
"Great!  I'll give you one packet per month with 10% probability".

Once you boil the data flows down to a set of {rate, latency, 
reliability} tuples, then you can start to allocate L3 and L2 resources 
to achieve whatever level of safety margin is appropriate.  In a network 
with no scheduled cell collisions (one of many ways to do it) It's the 
shared safety margin in L2 provisioning where your questions about 
priorities get interesting.

ksjp

On 3/10/2013 6:09 PM, Shitanshu Shah (svshah) wrote:
>
> Hi Kris,
>
> > For example, light switches, burglar alarms, and thermostats have 
> very different deterministic requirements.
>
> Interestingly enough all of them may co-exist in one WSN network. If 
> they have different deterministic requirements, eg. hypothetically 
> taking an example timely delivery (I take deterministic = jitter 
> sensitive) every 2 seconds, 3 seconds and 5 seconds respectively. If 
> they follow the same path, what would be an expectation when they 
> conflict with each other for a fixed slot delivery? For example, light 
> switches and burglar alarms may conflict at 6th second. Light switches 
> and thermostats at 10th second. Or am I on some tangent here? If I am 
> completely off the track then feel free to ignore. meeting with folks 
> here at the IETF will make me straight.
>
> btw, do control signals for light switches, thermostats etc. are 
> jitter sensitive (and so fall under deterministic service requirements?)
>
> Thanks
> Shitanshu
>
>
> From: Kris Pister  >
> Date: Sunday, March 10, 2013 4:25 PM
> To: Shitanshu Shah >
> Cc: "6tsch@ietf.org " <6tsch@ietf.org 
> >, Tom Phinney  >
> Subject: Re: [6tsch] priority and priority
>
> Shitanshu -
> > As I am not so much familiar with Industrial Automation, what I am not
> > clear if for a given PAN, could there be different set of flows with 
> different
> > deterministic parameters?
>    I don't think that the things that Tom is writing about are 
> specific to industrial automation.  Most WSN applications have similar 
> kinds of flows.  Building automation, smart grid, smart home, etc. all 
> have most if not all of the various flows and requirements enumerated 
> in rfc5637.
>
> For example, light switches, burglar alarms, and thermostats have very 
> different deterministic requirements.
>
> ksjp
>
> On 3/9/2013 9:04 PM, Shitanshu Shah (svshah) wrote:
>>
>> Hi Tom, All,
>>
>> In general I agree with your assessment for need for packet priority.
>>
>> If forwarding service required is similar to all packets for a given 
>> class, packet priority is all what is required for such services. 
>> Like traffic classes in your example for deterministic class, alerts, 
>> server-client response etc..  Treating such class of traffic at the 
>> aggregate level per packet priority (eg. Based on certain L3 or L2 
>> level code-points) is what is needed for forwarding(queuing) service.
>>
>> I also lack to understand, what is the definition of flow, is it 
>> micro-flow that has been eluded before?
>> For micro-flows belonging to the same service class (eg. Belonging to 
>> alert class), what kind of differentiation needed for different flows 
>> within that class? I would imagine that queuing is expensive and 
>> scarce resources in these systems as well just like it is for 
>> traditional Layer2 switches (at the least in the hardware). Thus 
>> probably very expensive to imagine as many queues as many set of 
>> flows with different priority.
>>
>> However, a sort of differentiation that can be imagined at flow level 
>> may be for other parameters (but not queuing behavior). For example, 
>> limiting rate of a flow that is fed in to the queuing 
>> system.excessive traffic to be dropped or re-marked to lower priority 
>> code-point. Or during congestion drop traffic from certain flows over 
>> others.
>>
>> I understand RSVP provides a way to enable integrated queuing 
>> service. At the same time, RSVP also has a way to enable reservation 
>> based on Diffserv. It is later that I am trying to highlight where 
>> packet priority is used for the forwarding decision, and flow 
>> classification may be used to constrain other parameters like rate.
>>
>> Taking deterministic class in particular,
>> As I am not so much familiar with Industrial Automation, what I am 
>> not clear if for a given PAN, could there be different set of flows 
>> with different deterministic parameters? If there are then I can see 
>> some impact to queuing discipline and packet priority itself may not 
>> be sufficient. But I am not sure why there would be an application 
>> (PAN) with devices with different set of deterministic flows. I can 
>> also see them causing conflicts when it comes to channel reservation.
>>
>> Regards,
>> Shitanshu
>>
>>
>> From: Tom Phinney >
>> Reply-To: Tom Phinney >
>> Date: Saturday, March 9, 2013 11:27 AM
>> To: "6tsch@ietf.org " <6tsch@ietf.org 
>> >
>> Subject: Re: [6tsch] priority and priority
>>
>> Kris (et al),
>>
>> Thank you for your reply and general concurrence.
>>
>> In my post below I was objecting to the conclusion in the originally 
>> quoted interchange, recolored in red at the end below, that flow 
>> priority suffices. My example flow 2) is one in which packet priority 
>> makes sense WITHIN the flow. Note also my text in blue below, 
>> highlighting a similar conclusion for use of flows 2) and/or 3) as 
>> backup channels for flow 1) when flow 1) becomes too unreliable.
>>
>> My post below was an attempt to point out that queuing priority AND 
>> flow priority need not be disjoint approaches; in my opinion they can 
>> and should both exist concurrently in systems that deal with 
>> real-world problems, at least in the industrial and process 
>> automation markets. They each provide some functionality that the 
>> other lacks, giving an overall system that is superior in its 
>> performance of critical functions to one that restricts itself to 
>> flow priority, or to queuing priority, but without supporting both. 
>> My post below was an attempt to sketch a common scenario in that 
>> market where the two priority mechanisms interplay to provide a 
>> superior system.
>>
>> Perhaps my concept of flow differs from those of the original two 
>> correspondents. If so, I would appreciate instruction/correction. My 
>> scenario below was one where resources assigned to secondary flows 
>> would be used when the primary flow 1) fails. If others' notions of 
>> flow are not coupled to contracts and resource allocation in 
>> forwarding DL and NL routers, potentially including slot 
>> prioritization among concurrent slots, then what use is it?
>>
>> -Tom
>> =====
>> On 2013.03.09 10:36, Kris Pister wrote:
>>> Tom - I agree with everything that you wrote in the email below 
>>> except the first sentence.  Perhaps I'm missing something, but it 
>>> seems to me that your enumeration of various flows with different 
>>> requirements fits quite well with the discussion fragment quoted at 
>>> the end below. Can you help me understand the differences?
>>>
>>> My bias is that we should have
>>> {flow priority (equating to slotframe priority) OR link priority 
>>> (TX, RX, uni-, multi-)} AND {packet priority}.
>>>
>>> ksjp
>>>
>>> On 3/8/2013 11:36 PM, Tom Phinney wrote:
>>>> I don't know what real-world use this technology is being designed 
>>>> to support, but the discussion fragments quoted at the end below 
>>>> seem to me to be moving away from reality.
>>>>
>>>> In the industrial automation world where I spent most of my career, 
>>>> it makes sense to have different inbound flows for differing 
>>>> purposes. Most sensor devices would have the following flows 1), 2) 
>>>> and 3):
>>>> 1) a dedicated inbound flow per field device (mote) for periodic 
>>>> deterministic control traffic, where the number of expected hops 
>>>> has to be small when the loop rate is high;
>>>> 2) a shared inbound flow for usually-infrequent alerts (i.e., 
>>>> device events and process alarms), probably with at least 2-level 
>>>> packet queuing priority, perhaps using CSMA/CA to provide some 
>>>> slight statistical bias in channel access priority based on packet 
>>>> priority;
>>>> 3) a shared inbound flow for server-to-client responses, typically 
>>>> in response to a program-initiated or operator-initiated action at 
>>>> an engineering workstation in a control room.
>>>>
>>>> Every process actuator (i.e., mote that can directly manipulate the 
>>>> process) will also have another flow 4), analogous to 1) but in the 
>>>> outbound direction, from the control room to the field to transfer 
>>>> the computed actuator setting to the device. Such devices also have 
>>>> inbound flow 1) to transfer actuator status at the same periodic rate.
>>>>
>>>> If communication problems are experienced on flow 1), it is 
>>>> desirable to be able to use one or more of the other flows as a 
>>>> backup mechanism for inbound control traffic, whether full 
>>>> determinism can be maintained or not. Packet queuing priority 
>>>> definitely makes sense here, so that such traffic can leapfrog 
>>>> non-deterministic traffic in the output queue of the originating 
>>>> mote and of any intermediary relaying motes. As mentioned in 2), it 
>>>> may also make sense to use CSMA/CA to provide some slight 
>>>> statistical bias in channel access priority based on packet 
>>>> priority, at least for flows where the transaction template has a 
>>>> non-null CSMA/CA sensing interval before the scheduled Data PDU 
>>>> transmission of the transaction.
>>>>
>>>> The reason for priority on the alerts is that process alarms from 
>>>> class 1 - 2 devices, (or class 0 - 2 if class 0 uses wireless), 
>>>> would usually be configured to be higher priority than those for 
>>>> classes 3 - 5. (Some class 3 devices might also be assigned that 
>>>> higher alarm priority.) Where safety alarms are concerned, such as 
>>>> the "man down" alarm that Herman Storey mentioned on Thursday's 
>>>> call, those alarms would tend to use another flow 5), similar to 
>>>> 2), with a very low expected rate but with dedicated slots to 
>>>> provide a clear virtual channel (to the extent possible). The time 
>>>> constants for such alarms are long enough (seconds) compared to 
>>>> much of the flow 1) traffic that the incremental cost of flow 5), 
>>>> which is so similar to flow 2), probably would not be very much, 
>>>> perhaps 2% of the total network capacity. It is tempting to just 
>>>> have a 3-way CSMA/CA interval for flow 2), but the reality of the 
>>>> CSMA/CA priority assessment mechanism is that it is very weak, 
>>>> given physical modem delays, inter-mote timing skews and the old 
>>>> hidden-node problem. Thus CSMA/CA prioritization does not seem 
>>>> reliable enough to trust for safety purposes.
>>>>
>>>> Of course a system will have other flows, many allocated on a 
>>>> demand basis in response to some occasional need, such as firmware 
>>>> download or captured waveform upload.
>>>>
>>>> The basic timing of continuous control loops it that the total 
>>>> delay from sensing the process to driving the actuator generally 
>>>> has to be less than twice the period of the loop. In such cases the 
>>>> needed control strategy is both relatively simple and relatively 
>>>> stable, However, if the total input-to-output delay exceeds twice 
>>>> the loop period, the control becomes much more difficult and less 
>>>> able to respond to fast transients. Jitter is a problem only when a 
>>>> process value message is delivered in the wrong cycle; it does not 
>>>> matter whether the delivery is at the 10% or 90% point in the 
>>>> proper cycle. Authenticated timestamping of the message, as occurs 
>>>> via the UDP transport nonce in ISA100.11a, provides a means of 
>>>> discarding process value messages that are delivered too late, thus 
>>>> converting those situations to ones of message loss. That is the 
>>>> desired way of handling late delivery, because the control loop is 
>>>> stable under message loss but not when the values are deliberately 
>>>> selectively delayed into the wrong delivery cycle. (Honeywell 
>>>> demonstrated years ago that it was possible to destablize most 
>>>> control loops with such deliberately jittered delivery.)
>>>>
>>>> -Tom
>>>> =====
>>>> On 2013.03.08 23:33, Thomas Watteyne wrote:
>>>>> Michael,
>>>>>
>>>>> I agree that the term flow is almost as overloaded as link or 
>>>>> path. This is not a final term and we will have to come up with a 
>>>>> better term. Suggestions?
>>>>>
>>>>> If I get your point correctly, you are suggesting that there 
>>>>> should be no packet priorities, only flows priority. In a TSCH 
>>>>> context, this would translate into a slotframe per flow, where 
>>>>> flow also incorporates the notion of priority. Correct? This is a 
>>>>> very important discussion we started over the phone earlier today, 
>>>>> but which we will continue Wednesday in Orlando. I hope you can be 
>>>>> there.
>>>>>
>>>>> Thomas
>>>>>
>>>>> On Fri, Mar 8, 2013 at 6:55 PM, Michael Richardson 
>>>>> > wrote:
>>>>>
>>>>>     How can a flow have high priority packets and low priority
>>>>>     packets?
>>>>>
>>>>>     Why are these two types of packets using the same DODAG?
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 6tsch mailing list
>>>> 6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch
>


--------------090800020709020808020108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Shitanshu - I think that you're on the right track.  Here's how I
    look at the WSN world:

    

    For energy efficiency in WSN, we'd prefer to never transmit
    anything.  Unfortunately for battery life, users set requirements on
    data reception rate, latency, and reliability.

    The goal of WSN is to meet these L4 user QoS requirements via L3
    routes on L2 waking schedules, while minimizing global power and
    traffic, subject to node-local power and energy constraints.

    From that perspective, *every* flow in the network is jitter
    sensitive and deterministic.  If not, then there are resources being
    wasted.  When I ask people about their latency and reliability
    requirements, I often hear "oh, I don't care much about latency and
    reliability", and I say "Great!  I'll give you one packet per month
    with 10% probability".

    

    Once you boil the data flows down to a set of {rate, latency,
    reliability} tuples, then you can start to allocate L3 and L2
    resources to achieve whatever level of safety margin is
    appropriate.  In a network with no scheduled cell collisions (one of
    many ways to do it) It's the shared safety margin in L2 provisioning
    where your questions about priorities get interesting.

    

    ksjp

    

    
On 3/10/2013 6:09 PM, Shitanshu Shah
      (svshah) wrote:

    

    

      
      


      

      
Hi Kris,

      


      

      
> For example, light switches, burglar alarms, and
        thermostats have very different deterministic requirements.

      

      


      

      
Interestingly enough all of them may co-exist in one WSN
        network. If they have different deterministic requirements, eg.
        hypothetically taking an example timely delivery (I take
        deterministic = jitter sensitive) every 2 seconds, 3 seconds and
        5 seconds respectively. If they follow the same path, what would
        be an expectation when they conflict with each other for a fixed
        slot delivery? For example, light switches and burglar alarms
        may conflict at 6th second. Light switches and thermostats at
        10th second. Or am I on some tangent here? If I am completely
        off the track then feel free to ignore. meeting with folks here
        at the IETF will make me straight.

      


      

      
btw, do control signals for light switches, thermostats etc.
        are jitter sensitive (and so fall under deterministic service
        requirements?)

      


      

      
Thanks

      
Shitanshu

      


      

      


      

      
        

          From: Kris Pister <pister@eecs.berkeley.edu>

          Date: Sunday, March 10,
          2013 4:25 PM

          To: Shitanshu Shah <svshah@cisco.com>

          Cc: "6tsch@ietf.org"
          <6tsch@ietf.org>,
          Tom Phinney <tom.phinney@cox.net>

          Subject: Re: [6tsch]
          priority and priority

        

        


        

        

          
Shitanshu - 

            > As I am not so much familiar with Industrial
            Automation, what I am not

            > clear if for a given PAN, could there be different set
            of flows with different 

            > deterministic parameters?

               I don't think that the things that Tom is writing about
            are specific to industrial automation.  Most WSN
            applications have similar kinds of flows.  Building
            automation, smart grid, smart home, etc. all have most if
            not all of the various flows and requirements enumerated in
            rfc5637.

            

            For example, light switches, burglar alarms, and thermostats
            have very different deterministic requirements.

            

            ksjp

            

            
On 3/9/2013 9:04 PM, Shitanshu
              Shah (svshah) wrote:

            

            

              


              

              
Hi Tom, All,

              


              

              
In general I agree with your assessment for need for
                packet priority.

              


              

              
If forwarding service required is similar to all
                packets for a given class, packet priority is all what
                is required for such services. Like traffic classes in
                your example for deterministic class, alerts,
                server-client response etc..  Treating such class of
                traffic at the aggregate level per packet priority (eg.
                Based on certain L3 or L2 level code-points) is what is
                needed for forwarding(queuing) service.

              


              

              
I also lack to understand, what is the definition of
                flow, is it micro-flow that has been eluded before?

              
For micro-flows belonging to the same service class
                (eg. Belonging to alert class), what kind of
                differentiation needed for different flows within that
                class? I would imagine that queuing is expensive and
                scarce resources in these systems as well just like it
                is for traditional Layer2 switches (at the least in the
                hardware). Thus probably very expensive to imagine as
                many queues as many set of flows with different
                priority.

              


              

              
However, a sort of differentiation that can be
                imagined at flow level may be for other parameters (but
                not queuing behavior). For example, limiting rate of a
                flow that is fed in to the queuing system.excessive
                traffic to be dropped or re-marked to lower priority
                code-point. Or during congestion drop traffic from
                certain flows over others.

              


              

              
I understand RSVP provides a way to enable integrated
                queuing service. At the same time, RSVP also has a way
                to enable reservation based on Diffserv. It is later
                that I am trying to highlight where packet priority is
                used for the forwarding decision, and flow
                classification may be used to constrain other parameters
                like rate.

              


              

              
Taking deterministic class in particular,

              
As I am not so much familiar with Industrial
                Automation, what I am not clear if for a given PAN,
                could there be different set of flows with different
                deterministic parameters? If there are then I can see
                some impact to queuing discipline and packet priority
                itself may not be sufficient. But I am not sure why
                there would be an application (PAN) with devices with
                different set of deterministic flows. I can also see
                them causing conflicts when it comes to channel
                reservation.

              


              

              
Regards,

              
Shitanshu

              


              

              


              

              
                

                  From: Tom
                  Phinney <tom.phinney@cox.net>

                  Reply-To: Tom
                  Phinney <tom.phinney@cox.net>

                  Date: Saturday,
                  March 9, 2013 11:27 AM

                  To: "6tsch@ietf.org"
                  <6tsch@ietf.org>

                  Subject: Re:
                  [6tsch] priority and priority

                

                


                

                

                  
Kris (et al),

                      

                      Thank you for your reply and general concurrence.

                      

                      In my post below I was objecting to the conclusion
                      in the originally quoted interchange,
                      recolored in red at the end
                        below, that flow priority suffices. My
                      example flow 2) is one in which packet priority
                      makes sense WITHIN the flow. Note also my text
                      in blue below,
                      highlighting a similar conclusion for use of flows
                      2) and/or 3) as backup channels for flow 1) when
                      flow 1) becomes too unreliable.

                      

                      My post below was an attempt to point out that
                      queuing priority AND flow priority need not be
                      disjoint approaches; in my opinion they can and
                      should both exist concurrently in systems that
                      deal with real-world problems, at least in the
                      industrial and process automation markets. They
                      each provide some functionality that the other
                      lacks, giving an overall system that is superior
                      in its performance of critical functions to one
                      that restricts itself to flow priority, or to
                      queuing priority, but without supporting both. My
                      post below was an attempt to sketch a common
                      scenario in that market where the two priority
                      mechanisms interplay to provide a superior system.

                      

                      Perhaps my concept of flow differs from those of
                      the original two correspondents. If so, I would
                      appreciate instruction/correction. My scenario
                      below was one where resources assigned to
                      secondary flows would be used when the primary
                      flow 1) fails. If others' notions of flow are not
                      coupled to contracts and resource allocation in
                      forwarding DL and NL routers,
                    potentially including slot
                      prioritization among concurrent slots, then what use is it?

                      

                      -Tom

                      =====

                    On 2013.03.09 10:36, Kris Pister wrote:
                    
Tom - I agree with everything that you
                      wrote in the email below except the first
                      sentence.  Perhaps I'm missing something, but it
                      seems to me that your enumeration of various flows
                      with different requirements fits quite well with
                      the discussion fragment quoted at the end below. 
                      Can you help me understand the differences?

                      

                      My bias is that we should have 

                      {flow priority (equating to slotframe priority) OR
                      link priority (TX, RX, uni-, multi-)} AND {packet
                      priority}.

                      

                      ksjp

                      

                      
On 3/8/2013 11:36 PM,
                        Tom Phinney wrote:

                      

                      
I don't know what real-world use
                        this technology is being designed to support,
                        but the discussion fragments quoted at the end
                        below seem to me to be moving away from reality.

                        

                        In the industrial automation world where I spent
                        most of my career, it makes sense to have
                        different inbound flows for differing purposes.
                        Most sensor devices would have the following
                        flows 1), 2) and 3):

                        1) a dedicated inbound flow per field device
                        (mote) for periodic deterministic control
                        traffic, where the number of expected hops has
                        to be small when the loop rate is high;

                        2) a shared inbound flow for usually-infrequent
                        alerts (i.e., device events and process alarms),
                        probably with at least 2-level packet queuing
                        priority, perhaps using CSMA/CA to provide some
                        slight statistical bias in channel access
                        priority based on packet priority;

                        3) a shared inbound flow for server-to-client
                        responses, typically in response to a
                        program-initiated or operator-initiated action
                        at an engineering workstation in a control room.

                        

                        Every process actuator (i.e., mote that can
                        directly manipulate the process) will also have
                        another flow 4), analogous to 1) but in the
                        outbound direction, from the control room to the
                        field to transfer the computed actuator setting
                        to the device. Such devices also have inbound
                        flow 1) to transfer actuator status at the same
                        periodic rate.

                        

                        If communication problems are experienced on
                        flow 1), it is desirable
                          to be able to use one or more of the other
                          flows as a backup mechanism for inbound
                          control traffic, whether full
                        determinism can be maintained or not.
                        Packet queuing priority
                          definitely makes sense here, so that such
                          traffic can leapfrog non-deterministic traffic
                          in the output queue of the originating mote
                          and of any intermediary relaying motes.
                        As mentioned in 2), it may also make sense to
                        use CSMA/CA to provide some slight statistical
                        bias in channel access priority based on packet
                        priority, at least for flows where the
                        transaction template has a non-null CSMA/CA
                        sensing interval before the scheduled Data PDU
                        transmission of the transaction.

                        

                        The reason for priority on the alerts is that
                        process alarms from class 1 - 2 devices, (or
                        class 0 - 2 if class 0 uses wireless), would
                        usually be configured to be higher priority than
                        those for classes 3 - 5. (Some class 3 devices
                        might also be assigned that higher alarm
                        priority.) Where safety alarms are concerned,
                        such as the "man down" alarm that Herman Storey
                        mentioned on Thursday's call, those alarms would
                        tend to use another flow 5), similar to 2), with
                        a very low expected rate but with dedicated
                        slots to provide a clear virtual channel (to the
                        extent possible). The time constants for such
                        alarms are long enough (seconds) compared to
                        much of the flow 1) traffic that the incremental
                        cost of flow 5), which is so similar to flow 2),
                        probably would not be very much, perhaps 2% of
                        the total network capacity. It is tempting to
                        just have a 3-way CSMA/CA interval for flow 2),
                        but the reality of the CSMA/CA priority
                        assessment mechanism is that it is very weak,
                        given physical modem delays, inter-mote timing
                        skews and the old hidden-node problem. Thus
                        CSMA/CA prioritization does not seem reliable
                        enough to trust for safety purposes.

                        

                        Of course a system will have other flows, many
                        allocated on a demand basis in response to some
                        occasional need, such as firmware download or
                        captured waveform upload.

                        

                        The basic timing of continuous control loops it
                        that the total delay from sensing the process to
                        driving the actuator generally has to be less
                        than twice the period of the loop. In such cases
                        the needed control strategy is both relatively
                        simple and relatively stable, However, if the
                        total input-to-output delay exceeds twice the
                        loop period, the control becomes much more
                        difficult and less able to respond to fast
                        transients. Jitter is a problem only when a
                        process value message is delivered in the wrong
                        cycle; it does not matter whether the delivery
                        is at the 10% or 90% point in the proper cycle.
                        Authenticated timestamping of the message, as
                        occurs via the UDP transport nonce in
                        ISA100.11a, provides a means of discarding
                        process value messages that are delivered too
                        late, thus converting those situations to ones
                        of message loss. That is the desired way of
                        handling late delivery, because the control loop
                        is stable under message loss but not when the
                        values are deliberately selectively delayed into
                        the wrong delivery cycle. (Honeywell
                        demonstrated years ago that it was possible to
                        destablize most control loops with such
                        deliberately jittered delivery.)

                        

                        -Tom

                        =====

                        On 2013.03.08 23:33, Thomas Watteyne wrote:
                        

                          Michael,
                          


                          

                          
I agree that the term flow is almost as
                            overloaded as link or path. This is not a
                            final term and we will have to come up with
                            a better term. Suggestions?

                          


                          

                          
If I get your point correctly, you are
                            suggesting that 
                              there should be no packet priorities, only
                              flows priority. In a TSCH context,
                            this would translate into a slotframe per
                            flow, where flow also incorporates the
                            notion of priority. Correct? This is a very
                            important discussion we started over the
                            phone earlier today, but which we will
                            continue Wednesday in Orlando. I hope you
                            can be there.

                          


                          

                          
Thomas

                            

                            
On Fri, Mar 8, 2013
                              at 6:55 PM, Michael Richardson 
                                <mcr+ietf@sandelman.ca>
                              wrote:

                              

                                How can a flow
                                  have high priority packets and low
                                  priority packets?

                                

                                Why are these two types of packets using
                                the same DODAG?

                              

                            

                          

                        

                        

                        

                        

                        
_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch

                      

                      

                      

_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch

                    

                  

                

              

              

              

              
_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch

            

            

          

        

      
    

    

  


--------------090800020709020808020108--

From mcr@sandelman.ca  Mon Mar 11 12:43:17 2013
Return-Path: 
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 D4C1111E8225 for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 12:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Level: 
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311]
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 jdQ5iAkRSTQx for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 12:43:16 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0101D11E8224 for <6tsch@ietf.org>; Mon, 11 Mar 2013 12:43:15 -0700 (PDT)
Received: from sandelman.ca (unknown [130.129.20.151]) by relay.sandelman.ca (Postfix) with ESMTPS id 7F1FB22060 for <6tsch@ietf.org>; Mon, 11 Mar 2013 19:43:11 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AD9B8CA0BC for <6tsch@ietf.org>; Mon, 11 Mar 2013 15:43:10 -0400 (EDT)
From: Michael Richardson 
To: IETF 6TSCH <6tsch@ietf.org>
In-reply-to: 
References:  <19015.1362797728@sandelman.ca> 
Comments: In-reply-to Thomas Watteyne  message dated "Fri, 08 Mar 2013 22:33:22 -0800."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 11 Mar 2013 15:43:10 -0400
Message-ID: <32756.1363030990@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: [6tsch] what to call "flow" with different priorities
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 19:43:17 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Thomas" =3D=3D Thomas Watteyne  writes:
    Thomas> I agree that the term flow is almost as overloaded as link
    Thomas> or path. This is not a final term and we will have to come
    Thomas> up with a better term.  Suggestions?

I don't have a suggestion as to a term.
The thing that I do when I find out that all the normal terms are
overloaded is to either:=20=20=20
  a) use the same term from another language
  b) make up a new term, either nonsense or ideally a porte-manteau.

I believe that terminology is important and getting the right words in
place makes the discussion go much smoother.  Overloading words is
bad...  It's good that we talk about frames, fragments, packets and
segments with much clarity.

let me reply seperately for the other part, changing the subject line.

=2D-=20
Michael Richardson
=2Don the road-

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJRPjPOAAoJEKD0KQ7Gj3P2CvAH/0n1C4XlxMK9v8YIb4agyCZO
pezoi5b+kEH0Jz6PmzR8oXJ/GoIQMmhPT6qq/p5hNteFPyJc/oWc37jSq4Yk5499
xlJgHs3SFfv73+0hjrZwsqNLfKrei0EueM8M2NRabBVS1UVINV6Q62rVlirTH8Pf
avl7l7f2/BbOzXLNRkb0jaPTunfrMKSzIf0SC0WQlHCzKBaNfoOb0k1hwRf0Hia0
ZCQGwv9CQJnAm3PGpFMRuiS3yqH1+6GT5zY8oE8w2oMv7fzHamZpeVYKTYef7kCA
xVU2ZKOTPppjju/yZtSmNldQRnZ9DL2ZV9gpCW6605rBbrtDd5BPy8BRDEHHQ9s=
=tSQT
-----END PGP SIGNATURE-----
--=-=-=--

From pthubert@cisco.com  Mon Mar 11 12:48:45 2013
Return-Path: 
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 5339B21F8E0A for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 12:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.999
X-Spam-Level: 
X-Spam-Status: No, score=-10.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, 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 NhAnLyeG-9KA for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 12:48:44 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 515A721F8E08 for <6tsch@ietf.org>; Mon, 11 Mar 2013 12:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1236; q=dns/txt; s=iport; t=1363031324; x=1364240924; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=02vlzCpe5Hwotqt+LsnmyZcPzHSPqis7mEwsJN6bq5I=; b=bhUcJd9y/9P/vNNd0fJt2TmiCQ6ahXtHu3Z5KACegkjQHHp6vCVsRvpZ sru8Lwy3J+rWkXDQ4iLynb3zOo+I77CwBMX5KL7PU2TOybQne9tWxIAFj PqFNiLNkoSMdLHtcVtpjOV6YRlIdacOULcrW+zMe1sLx/0KjOXZ8y7W/2 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAMczPlGtJXG9/2dsb2JhbABDxGaBXxZ0gikBAQEEOksEAgEIEQQBAQsUCQcyFAkIAgQBEgiIC79Tjl0mEgaCWWEDp0qDCoIo
X-IronPort-AV: E=Sophos;i="4.84,825,1355097600"; d="scan'208";a="183249064"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 11 Mar 2013 19:48:40 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2BJmeU0012686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 19:48:40 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 14:48:40 -0500
From: "Pascal Thubert (pthubert)" 
To: Michael Richardson , IETF 6TSCH <6tsch@ietf.org>
Thread-Topic: [6tsch] what to call "flow" with different priorities
Thread-Index: AQHOHpC6xzYE+OaozkGj9WktvAp9IJig5TDw
Date: Mon, 11 Mar 2013 19:48:39 +0000
Deferred-Delivery: Mon, 11 Mar 2013 19:48:00 +0000
Message-ID: 
References:  <19015.1362797728@sandelman.ca>  <32756.1363030990@sandelman.ca>
In-Reply-To: <32756.1363030990@sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.89.242]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [6tsch] what to call "flow" with different priorities
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 19:48:45 -0000

I agree, flow is misleading.

We have the concept of a track. Why not say track priority?

Pascal


-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of M=
ichael Richardson
Sent: lundi 11 mars 2013 15:43
To: IETF 6TSCH
Subject: [6tsch] what to call "flow" with different priorities


>>>>> "Thomas" =3D=3D Thomas Watteyne  writes:
    Thomas> I agree that the term flow is almost as overloaded as link
    Thomas> or path. This is not a final term and we will have to come
    Thomas> up with a better term.  Suggestions?

I don't have a suggestion as to a term.
The thing that I do when I find out that all the normal terms are
overloaded is to either:  =20
  a) use the same term from another language
  b) make up a new term, either nonsense or ideally a porte-manteau.

I believe that terminology is important and getting the right words in plac=
e makes the discussion go much smoother.  Overloading words is bad...  It's=
 good that we talk about frames, fragments, packets and segments with much =
clarity.

let me reply seperately for the other part, changing the subject line.

--
Michael Richardson
-on the road-

From mcr@sandelman.ca  Mon Mar 11 13:49:06 2013
Return-Path: 
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 E6ECA21F9044 for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 13:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.455
X-Spam-Level: 
X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311]
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 MK-mS4lQZQaj for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 13:49:05 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFD221F90FC for <6tsch@ietf.org>; Mon, 11 Mar 2013 13:49:05 -0700 (PDT)
Received: from sandelman.ca (unknown [130.129.20.151]) by relay.sandelman.ca (Postfix) with ESMTPS id BA23122060 for <6tsch@ietf.org>; Mon, 11 Mar 2013 20:49:01 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2476ACA0BC for <6tsch@ietf.org>; Mon, 11 Mar 2013 16:49:01 -0400 (EDT)
From: Michael Richardson 
To: IETF 6TSCH <6tsch@ietf.org>
In-reply-to: 
References:  <19015.1362797728@sandelman.ca> 
Comments: In-reply-to Thomas Watteyne  message dated "Fri, 08 Mar 2013 22:33:22 -0800."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 11 Mar 2013 16:49:01 -0400
Message-ID: <1953.1363034941@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: [6tsch] how to handle different classes of traffic
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 20:49:06 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Thomas" =3D=3D Thomas Watteyne  writes:
    Thomas> If I get your point correctly, you are suggesting that there
    Thomas> should be no packet priorities, only flows priority. In a
    Thomas> TSCH context, this would translate into a slotframe per
    Thomas> flow, where flow also incorporates the notion of
    Thomas> priority. Correct? This is a very important discussion we
    Thomas> started over the phone earlier today, but which we will
    Thomas> continue Wednesday in Orlando. I hope you can be there.

I think that we need to start from goals, and talk about what methods
will be used to configure and/or provision them.  Let's not confuse
mechanism (DSCP, slotframes) from goals.

My understanding is that we wish to use a non-protected ("CAP" is what I
understand to be the 802.15.4 term) in order to bring up the network,
determine what the parent relationship could be, and then use that
control channel to bootstrap the rest of the system.  This will happen
with RPL creating an initial DODAG.

My further understanding is that we will then allocate/provision
slotframes for communication between adjacent nodes.  How big these
slotframes are is out of scope for the moment(%).

Once these slotframes are created, then they will be expressed upwards
to the RPL layer as links with specific ETXs, possibly using a to be
defined new set of (time) based metrics.  Based upon traffic constraints
expressed by the application(s), new DODAGs will be created using the
new (presumably lower latencies and higher bandwidths) adjacencies.

Now we have a problem: the various DODAGs may well interact poorly if
their total of their requirements exceed the resources available on that
slotframe.  If we make these as all hard reservation and we therefore do
not permit oversubscription, we are good.  If we loose a parent, then
each DODAG has to go and think (probably in a priority reservation
order), where to get an equivalent path via another parent.=20=20=20=20
The parent selection algorith will have seen a particular ETX, but that
may no longer be available after higher priority DODAGs have claimed
pieces of them.

We do not need in-band per-packet markings, at least for storing mode
DODAGs, as we will have the RPLinstanceID already marked in-band.=20=20

I don't think that one needs or wants a slotframe per DODAG (although it
could degenerate to that), nor do I think that this is useful, as fact
different packets (particularly downward ones!) go out actually in
different ways.=20

So we wind up with multiple queues (one per DODAG) per slotframe, which
are serviced by the slotframes in priority order.=20

(%)- now above I said that how big the slotframes would be decided out
of scope, but in fact, I get the impression that we actually want to
figure out the DODAG structure, and then once we know what adjacencies
are possible, that we then decide how big a slotframe to allocate.


=2D-=20
Michael Richardson
=2Don the road-



--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJRPkM8AAoJEKD0KQ7Gj3P2L2MH/0EsNGVOvWjvEQpLeaLSkVNW
gD9Wg29G25LknDoNP/MdiYVrEECPmuzkS6yyipVQpXyUwTDVFTtL70eATsbH3H8o
307FuXEajoSYh/94xAHWy6aUU7UTbfUVHt8LyR2azdjrZWS+cotOsX+4dbAJhhR1
b9NycjkyREWtgXFA2xIKhSmGyXAjwkl4rXyrVtxvViJoeUyEXQH8cJT07aWbJcfk
S2w7y2Z2Wri1KLoT2oVTZkDEfBv/vxUhCpHImeC1UtrJswgmWBpQbiZNX33ahBpN
2I4Vk7mi7EOdBpYnJ+IUDuh0rA44mKeFHyFuDwpqR+ffb3tybOoQthxHXwoifeU=
=Lw84
-----END PGP SIGNATURE-----
--=-=-=--

From pister@eecs.berkeley.edu  Mon Mar 11 14:11:57 2013
Return-Path: 
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 C835721F8E7E for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 14:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.399
X-Spam-Level: 
X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 uClncd5yaX+A for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 14:11:57 -0700 (PDT)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 55BFB21F8E76 for <6tsch@ietf.org>; Mon, 11 Mar 2013 14:11:57 -0700 (PDT)
Received: from dhcp-32-89.eecs.berkeley.edu ([128.32.32.89]) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1UFA0g-0006dL-JG for 6tsch@ietf.org; Mon, 11 Mar 2013 14:11:57 -0700
Message-ID: <513E489B.6070306@eecs.berkeley.edu>
Date: Mon, 11 Mar 2013 14:11:55 -0700
From: Kris Pister 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: 6tsch@ietf.org
References:  <19015.1362797728@sandelman.ca>  <1953.1363034941@sandelman.ca>
In-Reply-To: <1953.1363034941@sandelman.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [6tsch] how to handle different classes of traffic
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2013 21:11:57 -0000

On 3/11/2013 1:49 PM, Michael Richardson wrote:
> My understanding is that we wish to use a non-protected ("CAP" is what 
> I understand to be the 802.15.4 term)
Just to make sure we're on the same page:
CAP = "contention access period" has a specific meaning in 15.4. It's 
the CSMA period after a beacon in the original standard, also used by 
the DSME and LE MACs in 4e.  If CAP were not already defined for these 
15.4 modes, then using a slotted aloha (contention-based) mechanism for 
initial communication might reasonably be called CAP, but given that the 
term is already defined elsewhere we should avoid it here.

> the various DODAGs may well interact poorly if their total of their 
> requirements exceed the resources available on that slotframe.
Hmm.  I'm missing something.

> I don't think that one needs or wants a slotframe per DODAG (although 
> it could degenerate to that), nor do I think that this is useful, as 
> fact different packets (particularly downward ones!) go out actually 
> in different ways. 
Can you say more about this?  I was thinking that we want at least one 
slotframe per DODAG.

> (%)- now above I said that how big the slotframes would be decided out 
> of scope, but in fact, I get the impression that we actually want to 
> figure out the DODAG structure, and then once we know what adjacencies 
> are possible, that we then decide how big a slotframe to allocate.
That sounds good, and is something that gets done dynamically, yes?

ksjp

From salo@saloits.com  Mon Mar 11 18:00:58 2013
Return-Path: 
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 79C3B21F8EFD for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 18:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.307
X-Spam-Level: 
X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292]
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 wdYj2bHiq-RR for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 18:00:58 -0700 (PDT)
Received: from mail.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id B5CAD21F8EC6 for <6tsch@ietf.org>; Mon, 11 Mar 2013 18:00:57 -0700 (PDT)
Received: from [192.168.255.119] (thinkpad2.saloits.com [192.168.255.119]) by mail.saloits.com (8.14.4/8.14.3) with ESMTP id r2C10uQw029357; Mon, 11 Mar 2013 20:00:56 -0500
Message-ID: <513E7E46.4090305@saloits.com>
Date: Mon, 11 Mar 2013 20:00:54 -0500
From: "Timothy J. Salo" 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
CC: IETF 6TSCH <6tsch@ietf.org>
References:  <19015.1362797728@sandelman.ca>  <32756.1363030990@sandelman.ca>
In-Reply-To: <32756.1363030990@sandelman.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [6tsch] what to call "flow" with different priorities
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2013 01:00:58 -0000

> The thing that I do when I find out that all the normal terms are
> overloaded is to either:
>    a) use the same term from another language
>    b) make up a new term, either nonsense or ideally a porte-manteau.

Often, I will simply prepend an adjective to a word that is appropriate,
but overloaded.  For example, I might write something like "6tsch flow"
to indicate that I am referring to something that is similar to,
and yet distinct from, other uses of the term.  No, I not proposing that
the "6tsch flow" be used; I am merely suggesting that this approach be
considered.

In my view, this strategy has the advantage that the document often
reads well compared to, for example, the use of a lot of acronyms,
strings of characters that might resemble several words smushed
together, foreign words or phrases[1], or non-words.

I particularly like the use of qualified nouns that are suggestive of
their meaning when I am researching a specific topic.  Often, I will
read a page or two of a document, rather than the whole document from
front-to-back.  In these cases, I want to quickly determine whether
these particular pages are relevant to my search, without having to
penetrate document-specific terms, or terms or usage that are
unique to a narrow topic.

> I believe that terminology is important and getting the right words in
> place makes the discussion go much smoother.  Overloading words is
> bad...

I agree.  I also believe that writers should be kind to their readers.
In my view, this includes writing in English, and avoiding excessive use
of acronyms, odd character strings that are unique to the document, and
other non-words.

[1] quidquid Latine dictum sit, altum sonatur
     (Whatever is said in Latin sounds profound )

-tjs

From dominique.barthel@orange.com  Mon Mar 11 18:39:34 2013
Return-Path: 
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 C775B21F86AD for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 18:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
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 ZQEv978h8y+B for <6tsch@ietfa.amsl.com>; Mon, 11 Mar 2013 18:39:34 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 843EF21F868F for <6tsch@ietf.org>; Mon, 11 Mar 2013 18:39:33 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 04BC222C225; Tue, 12 Mar 2013 02:39:25 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DC29A35C045; Tue, 12 Mar 2013 02:39:24 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 02:39:24 +0100
From: 
To: Maria Rita PALATTELLA , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: terminology-draft posted
Thread-Index: Ac4eQiidDbVeURWoT3SY2WtSZB4cowAf/ncQ
Date: Tue, 12 Mar 2013 01:39:24 +0000
Message-ID: <548_1363052364_513E874C_548_14896_1_8F1D83ADCC1AC94186A867BEE9B7D91306D33C09@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_8F1D83ADCC1AC94186A867BEE9B7D91306D33C09PEXCVZYM13corpo_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.11.234230
Subject: Re: [6tsch] terminology-draft posted
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2013 01:39:34 -0000

--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D33C09PEXCVZYM13corpo_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks, Maria Rita, I found this draft very helpful to catch up with the 6t=
sch discussion (backlogged on my side).
Dominique

De : 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] De la part de M=
aria Rita PALATTELLA
Envoy=E9 : lundi 11 mars 2013 06:21
=C0 : 6tsch@ietf.org
Objet : [6tsch] terminology-draft posted

All,


You can find version 00 of the 6tsch-terminology draft at  http://www.ietf.=
org/internet-drafts/draft-palattella-6tsch-terminology-00.txt .

Best Regards,

Maria Rita


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D33C09PEXCVZYM13corpo_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Thanks,=
 Maria Rita, I found this draft very helpful to catch up with the 6tsch dis=
cussion (backlogged on my side).


Dominiq=
ue


&n=
bsp;






De : 6tsc=
h-bounces@ietf.org [mailto:6tsch-bounces@ietf.org]
De la part de Maria Rita PALATTELLA

Envoy=E9 : lundi 11 mars 2013 06:21

=C0 : 6tsch@ietf.org

Objet : [6tsch] terminology-draft posted






 


All,=



 


Y=
ou can find version 00 of the 6tsch-terminology draft at
 http://www.ietf.org/intern=
et-drafts/draft-palattella-6tsch-terminology-00.txt .


 


Best=
 Regards,


 


Mari=
a Rita


 




______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.




--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D33C09PEXCVZYM13corpo_--

From maria-rita.palattella@uni.lu  Tue Mar 12 00:34:18 2013
Return-Path: 
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 0DC2A21F8713 for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 00:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 MyjvHFLa7boh for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 00:34:16 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 42EE521F858B for <6tsch@ietf.org>; Tue, 12 Mar 2013 00:34:15 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,829,1355094000"; d="scan'208,217";a="22828786"
Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 12 Mar 2013 08:34:15 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.01.0438.000; Tue, 12 Mar 2013 08:34:14 +0100
From: Maria Rita PALATTELLA 
To: Kris Pister , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] terminology-draft posted
Thread-Index: Ac4eQiidDbVeURWoT3SY2WtSZB4cowAJktGAACK+9rA=
Date: Tue, 12 Mar 2013 07:34:14 +0000
Message-ID: 
References:  <513DFE69.9030908@eecs.berkeley.edu>
In-Reply-To: <513DFE69.9030908@eecs.berkeley.edu>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.91.0.81]
Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185274D6hoshiunilux_"
MIME-Version: 1.0
Subject: Re: [6tsch] terminology-draft posted
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2013 07:34:18 -0000

--_000_F085911F642A6847987ADA23E611780D185274D6hoshiunilux_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Kris, thanks for having gone through it already, and for providing some com=
ments/corrections.
First, I think we will talk about SLOTFRAME (as specified in 15.4e TSCH std=
. ) and not superframe. Do you agree with me?
Second, are the cells defined by slotframe ID or slotframe LENGTH (or both)=
?
Thanks for your help.
Maria Rita

From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of K=
ris Pister
Sent: Monday, March 11, 2013 4:55 PM
To: 6tsch@ietf.org
Subject: Re: [6tsch] terminology-draft posted

That's very helpful.

A couple of nits:

cell - "a single element in the TSCH schedule" should be "a single element =
in a TSCH superframe".  Cells are not defined just by slot and channel offs=
et, but also by superframe length.

SlotOffset - "in the TSCH schedule" should be "in a TSCH superframe"

ksjp
On 3/11/2013 3:21 AM, Maria Rita PALATTELLA wrote:
All,


You can find version 00 of the 6tsch-terminology draft at  http://www.ietf.=
org/internet-drafts/draft-palattella-6tsch-terminology-00.txt .

Best Regards,

Maria Rita





_______________________________________________

6tsch mailing list

6tsch@ietf.org

https://www.ietf.org/mailman/listinfo/6tsch


--_000_F085911F642A6847987ADA23E611780D185274D6hoshiunilux_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Kris, thanks for havin=
g gone through it already, and for providing some comments/corrections.


First, I think we will=
 talk about SLOTFRAME (as specified in 15.4e TSCH std. ) and not superframe=
. Do you agree with me?


Second, are the cells =
defined by slotframe ID or slotframe LENGTH (or both)?

Thanks for your help.<=
o:p>


Maria Rita<=
/span>


 






From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf=
.org]
On Behalf Of Kris Pister

Sent: Monday, March 11, 2013 4:55 PM

To: 6tsch@ietf.org

Subject: Re: [6tsch] terminology-draft posted






 


That's very helpful.<=
br>


A couple of nits:



cell - "a single element in the TSCH schedule" should be "a =
single element in a TSCH superframe".  Cells are not defined just=
 by slot and channel offset, but also by superframe length.



SlotOffset - "in the TSCH schedule" should be "in a TSCH sup=
erframe"



ksjp




On 3/11/2013 3:21 AM, Maria Rita PALATTELLA wrote:






All,


 <=
/o:p>


You can find ver=
sion 00 of the 6tsch-terminology draft at
 http://www.ietf.org/internet-drafts/draft-palat=
tella-6tsch-terminology-00.txt .<=
/span>


 <=
/o:p>


Best Regards,


 <=
/o:p>


Maria Rita


 











_______________________________________________


6tsch mailing list


6tsch@ietf.org


https://www.ie=
tf.org/mailman/listinfo/6tsch




 






--_000_F085911F642A6847987ADA23E611780D185274D6hoshiunilux_--

From maria-rita.palattella@uni.lu  Tue Mar 12 00:35:29 2013
Return-Path: 
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 0E6C921F87F5 for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 00:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 KpH-anRKqoP1 for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 00:35:26 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0A421F87B3 for <6tsch@ietf.org>; Tue, 12 Mar 2013 00:35:26 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,829,1355094000"; d="scan'208,217";a="22828811"
Received: from unknown (HELO Archer.uni.lux) ([10.21.2.1]) by hercules.uni.lu with ESMTP; 12 Mar 2013 08:35:16 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Archer.uni.lux ([fe80::1009:b1e7:2b72:f0b8%10]) with mapi id 14.01.0438.000; Tue, 12 Mar 2013 08:35:16 +0100
From: Maria Rita PALATTELLA 
To: "dominique.barthel@orange.com" , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: terminology-draft posted
Thread-Index: Ac4eQiidDbVeURWoT3SY2WtSZB4cowAf/ncQAAx81jA=
Date: Tue, 12 Mar 2013 07:35:15 +0000
Message-ID: 
References:  <548_1363052364_513E874C_548_14896_1_8F1D83ADCC1AC94186A867BEE9B7D91306D33C09@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <548_1363052364_513E874C_548_14896_1_8F1D83ADCC1AC94186A867BEE9B7D91306D33C09@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.91.0.81]
Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185274EEhoshiunilux_"
MIME-Version: 1.0
Subject: Re: [6tsch] terminology-draft posted
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2013 07:35:29 -0000

--_000_F085911F642A6847987ADA23E611780D185274EEhoshiunilux_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Glad to hear it helps!
Maria Rita

From: dominique.barthel@orange.com [mailto:dominique.barthel@orange.com]
Sent: Tuesday, March 12, 2013 2:39 AM
To: Maria Rita PALATTELLA; 6tsch@ietf.org
Subject: RE: terminology-draft posted

Thanks, Maria Rita, I found this draft very helpful to catch up with the 6t=
sch discussion (backlogged on my side).
Dominique

De : 6tsch-bounces@ietf.org [mailto:6tsch-bo=
unces@ietf.org] De la part de Maria Rita PALATTELLA
Envoy=E9 : lundi 11 mars 2013 06:21
=C0 : 6tsch@ietf.org
Objet : [6tsch] terminology-draft posted

All,


You can find version 00 of the 6tsch-terminology draft at  http://www.ietf.=
org/internet-drafts/draft-palattella-6tsch-terminology-00.txt .

Best Regards,

Maria Rita


___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,

France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.

As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.

Thank you.

--_000_F085911F642A6847987ADA23E611780D185274EEhoshiunilux_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Glad to hear it helps!=



Maria Rita<=
/span>


 






From: dominiqu=
e.barthel@orange.com [mailto:dominique.barthel@orange.com]


Sent: Tuesday, March 12, 2013 2:39 AM

To: Maria Rita PALATTELLA; 6tsch@ietf.org

Subject: RE: terminology-draft posted






 


Thanks, Maria Rita, I =
found this draft very helpful to catch up with the 6tsch discussion (backlo=
gged on my side).


Dominique


 






De :
6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org]
De la part de Maria Rita PALATTELLA

Envoy=E9 : lundi 11 mars 2013 06:21

=C0 : 6tsch@ietf.org

Objet : [6tsch] terminology-draft posted






 


All,


 


You can find ver=
sion 00 of the 6tsch-terminology draft at
 http://www.ietf.org/internet-drafts/draft-palat=
tella-6tsch-terminology-00.txt .<=
/span>


 


Best Regards,


 


Maria Rita


 


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,


France Telecom - Orange decline toute responsabilite=
 si ce message a ete altere, deforme ou falsifie. Merci.<=
/pre>

 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify 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.






--_000_F085911F642A6847987ADA23E611780D185274EEhoshiunilux_--

From maria-rita.palattella@uni.lu  Tue Mar 12 00:40:52 2013
Return-Path: 
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 0402821F8610 for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 00:40:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4]
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 b6gObCV6JD+X for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 00:40:51 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7018C21F85B1 for <6tsch@ietf.org>; Tue, 12 Mar 2013 00:40:50 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,829,1355094000"; d="scan'208";a="22828921"
Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 12 Mar 2013 08:40:50 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.01.0438.000; Tue, 12 Mar 2013 08:40:49 +0100
From: Maria Rita PALATTELLA 
To: Kris Pister , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] DIOs/DAOs and broadcast channels on TSCH
Thread-Index: AQHOE9f971OPMS+fsEWJx/Qy5c1rNJiLufcwgBT2WgCAARE8AA==
Date: Tue, 12 Mar 2013 07:40:49 +0000
Message-ID: 
References: <512C36F4.4000409@eecs.berkeley.edu>  <513E045E.7040308@eecs.berkeley.edu>
In-Reply-To: <513E045E.7040308@eecs.berkeley.edu>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.91.0.81]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2013 07:40:52 -0000

Kris, I see your points, and I think we are aligned.
Thanks for clarifying what I meant for broadcast channels, I was actually t=
alking about channel offsets.
Maria Rita

-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of K=
ris Pister
Sent: Monday, March 11, 2013 5:21 PM
To: 6tsch@ietf.org
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Maria Rita -
  Does a single Aloha slot plus a trickle timer provide what we need for br=
oadcast?  It seems like it should.

I was assuming that a DODAG root (PAN coordinator) would pick a frame lengt=
h and slot parameters and start advertising a single Aloha slot in that fra=
me.  Depending on the type of network, most traffic would quickly move off =
of this fixed, shared resource into dedicated appropriately-scheduled cells=
, leaving it free for "random" traffic, such as broadcast.

If I were (hypothetically) sending signaling messages from a PCE, I would n=
ot use a broadcast channel in most networks.  Rather, I would set up a dedi=
cated "downstream" slotframe with one non-colliding multicast cell from eac=
h parent to its children.  That also creates a broadcast-capable MAC graph,=
 but allows much faster propagation. In any case, whether it's Aloha or a n=
on-colliding tree that provides the connectivity, I'd source route as far d=
own as possible to minimize overhead traffic on all of the other nodes.

Also, I agree that using fewer than 16 channels is acceptable for building =
reliable schedules.  Somewhere around 3--5 channels gets you most of the mu=
lti-path resilience that you'll get with 16.  This is important for those w=
ho must blacklist due to customer constraints (typically irrational constra=
ints, but...).  I just wanted to clarify that when you suggested "using som=
e of them as broadcast channels" that you meant using dedicated channel off=
sets, not actual radio channels. =20
In terms of available cell bandwidth, the impact is the same, but in terms =
of reliability the difference is huge.

ksjp

On 2/25/2013 11:55 PM, Maria Rita PALATTELLA wrote:
> Hello Xavi,
> from my point of view, having a TSCH broadcast channel could be useful in=
 several situations:
>
>>>> a) ADV need broadcast channels in case they are used to synchronize th=
e network. IEEE 802.15.4e provides the timekeeping flag to set that channel=
s as used for synchronization and shared flag can make them broadcast.
>>>> b) Those networks that do not need ADV for synchronization then can us=
e any TX link for ADV, this means that if it is not shared only the node li=
stening on that link will get the ADV. However as this periodically occurs =
the ADV might eventually be listened  >>>in all channels.
> 1) synchronization (as you said in [a]): it will allow to have a faster s=
et-up phase for synchronizing all the motes in the network. While, using  a=
ny TX link ([b]), even though this will hop from one channel to another, it=
 will imply a longer set-up phase, because each mote will be able to synchr=
onize at a different time (when it is in listen mode on the "right" channel=
).
>  =20
>>>> c)Some DAOs and all DIOs require a broadcast channel. Should the sched=
ule provide that? in case of a), can the same link be used? How this link s=
hould be installed in the nodes?
> 2) transmission of RPL messages (DAOs and DIOs). If we want TSCH works wi=
th RPL, then we should reserve some slots of the schedule for exchanging in=
formation between L3 and L2. I am not sure we should use the same link used=
 for synchronization, maybe it could be better to have 2 different ones, de=
dicated to different purposes. Anyway, this is something to check.
>
>>>> d)Is the scheduler of the network who should setup a broadcast channel=
 independent of the broadcast channel set for ADV? can it be the same? Or i=
n contrast, 6tus can configure the EB so it indicates a broadcast channel..
> 3) transmission of signaling messages for setting up the schedule. Let's =
 assume there is a scheduler that builds the schedule for the network. In o=
rder to assign some links to each of them, it  will need to broadcast the i=
nformation related to ( timeOffset, ChannelOffset). As for the synchronizat=
ion, having a broadcast channel dedicated to the signaling will allow to se=
t up the schedule in shorter time.
>
> Maybe, because there are 16 available channels in  IEEE802.15.4/15.4e PHY=
, using some of them as broadcast channels for synchronization/exchange of =
cross-layer info/set up of the schedule wouldn't  be a big problem. In many=
 applications, a smaller set of channels (< 16) will be enough for building=
 a reliable schedule.
>
> 6tus, as adaptation layer, may have a key role in the configuration of su=
ch broadcast channels, but we will need to think  "how/when" it should take=
 care of that.
>
> For now, let's see what other 6tus members think about!
>
> Maria Rita
>
>  =20
>
>
> -----Original Message-----
> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf=20
> Of Xavier Vilajosana
> Sent: Tuesday, February 26, 2013 5:16 AM
> To: 6tsch@ietf.org
> Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH
>
> Hi,
>
> I have a question that i want to discuss, the question is whether we=20
> need a broadcast channel in TSCH or not and what kind of support 6tus=20
> should provide. (the answer can be depends... but lets see some cases)
>
> a) ADV need broadcast channels in case they are used to synchronize the n=
etwork. IEEE 802.15.4e provides the timekeeping flag to set that channels a=
s used for synchronization and shared flag can make them broadcast.
> b) Those networks that do not need ADV for synchronization then can use a=
ny TX link for ADV, this means that if it is not shared only the node liste=
ning on that link will get the ADV. However as this periodically occurs the=
 ADV might eventually be listened in all channels.
> c)Some DAOs and all DIOs require a broadcast channel. Should the schedule=
 provide that? in case of a), can the same link be used? How this link shou=
ld be installed in the nodes?
> d)Is the scheduler of the network who should setup a broadcast channel in=
dependent of the broadcast channel set for ADV? can it be the same? Or in c=
ontrast, 6tus can configure the EB so it indicates a broadcast channel..
> e)..
>
> I would like to know what is your opinion on that.
>
> cheers!
> Xavi
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch

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

From robert.assimiti@nivis.com  Tue Mar 12 04:05:55 2013
Return-Path: 
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 0220321F8962 for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 04:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 kUNp0y6SF7Rb for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 04:05:53 -0700 (PDT)
Received: from relay-S04-HUB004.domainlocalhost.com (relay-s04-hub004.domainlocalhost.com [74.115.207.103]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF1D21F8930 for <6tsch@ietf.org>; Tue, 12 Mar 2013 04:05:52 -0700 (PDT)
Received: from S04-MBX01-08.s04.local ([169.254.8.186]) by S04-HUB004.s04.local ([10.30.12.50]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 07:05:52 -0400
From: Robert Assimiti 
To: Maria Rita PALATTELLA , Kris Pister , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] terminology-draft posted
Thread-Index: Ac4eQiidDbVeURWoT3SY2WtSZB4cowAUDQaAACDKRgAAAbdf4A==
Date: Tue, 12 Mar 2013 11:05:51 +0000
Message-ID: <8CF9EAFF7636FC419FEE1042DC36C12FB6BE3A@S04-MBX01-08.s04.local>
References:  <513DFE69.9030908@eecs.berkeley.edu> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.30.12.155]
Content-Type: multipart/alternative; boundary="_000_8CF9EAFF7636FC419FEE1042DC36C12FB6BE3AS04MBX0108s04loca_"
MIME-Version: 1.0
Subject: Re: [6tsch] terminology-draft posted
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2013 11:05:55 -0000

--_000_8CF9EAFF7636FC419FEE1042DC36C12FB6BE3AS04MBX0108s04loca_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Maria,

Thank you for working on the terminology. This is and will prove to be very=
 helpful as we make more progress.

A few comments/suggestions:


Link - IEEE 802.15.4e uses links in order to assign various data transactio=
n types to a particular timeslot. I do realize that the term is way too loa=
ded, so maybe we can call it something else in the context of 6TSCH. I sugg=
est also including a definition of the link concept.



Cell - is this just terminology or are you actually trying to define a new =
IE that bundles as bunch of other IEs? If this is just terminology, I would=
 also add the slotframe_ID  and Hopping_Sequence_ID to the current  identif=
ier composed of slotOffset and channelOffest in order to uniquely identify =
the cell.

Robert Assimiti

From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of M=
aria Rita PALATTELLA
Sent: Tuesday, March 12, 2013 3:34 AM
To: Kris Pister; 6tsch@ietf.org
Subject: Re: [6tsch] terminology-draft posted

Kris, thanks for having gone through it already, and for providing some com=
ments/corrections.
First, I think we will talk about SLOTFRAME (as specified in 15.4e TSCH std=
. ) and not superframe. Do you agree with me?
Second, are the cells defined by slotframe ID or slotframe LENGTH (or both)=
?
Thanks for your help.
Maria Rita

From: 6tsch-bounces@ietf.org [mailto:6tsch-b=
ounces@ietf.org] On Behalf Of Kris Pister
Sent: Monday, March 11, 2013 4:55 PM
To: 6tsch@ietf.org
Subject: Re: [6tsch] terminology-draft posted

That's very helpful.

A couple of nits:

cell - "a single element in the TSCH schedule" should be "a single element =
in a TSCH superframe".  Cells are not defined just by slot and channel offs=
et, but also by superframe length.

SlotOffset - "in the TSCH schedule" should be "in a TSCH superframe"

ksjp
On 3/11/2013 3:21 AM, Maria Rita PALATTELLA wrote:
All,


You can find version 00 of the 6tsch-terminology draft at  http://www.ietf.=
org/internet-drafts/draft-palattella-6tsch-terminology-00.txt .

Best Regards,

Maria Rita




_______________________________________________

6tsch mailing list

6tsch@ietf.org

https://www.ietf.org/mailman/listinfo/6tsch


--_000_8CF9EAFF7636FC419FEE1042DC36C12FB6BE3AS04MBX0108s04loca_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Maria,




Thank you for working on the terminology. This is and will prove to be very=
 helpful as we make more progress.




A few comments/suggestions:


 


Link – IE=
EE 802.15.4e uses links in order to assign various data transaction types t=
o a particular timeslot. I do realize that the term is way too loaded, so m=
aybe we can call it something else in the
 context of 6TSCH. I suggest also including a definition of the link concep=
t.


 


Cell – is=
 this just terminology or are you actually trying to define a new IE that b=
undles as bunch of other IEs? If this is just terminology, I would also add=
 the slotframe_ID  and Hopping_Sequence_ID
 to the current  identifier composed of slotOffset and channelOffest i=
n order to uniquely identify the cell.


 




Robert Assimiti




 






From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf=
.org]
On Behalf Of Maria Rita PALATTELLA

Sent: Tuesday, March 12, 2013 3:34 AM

To: Kris Pister; 6tsch@ietf.org

Subject: Re: [6tsch] terminology-draft posted






 


Kris, thanks for havin=
g gone through it already, and for providing some comments/corrections.


First, I think we will=
 talk about SLOTFRAME (as specified in 15.4e TSCH std. ) and not superframe=
. Do you agree with me?


Second, are the cells =
defined by slotframe ID or slotframe LENGTH (or both)?

Thanks for your help.<=
o:p>


Maria Rita<=
/span>


 






From:
6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org]
On Behalf Of Kris Pister

Sent: Monday, March 11, 2013 4:55 PM

To: 6tsch@ietf.org

Subject: Re: [6tsch] terminology-draft posted






 


That's very helpful.<=
br>


A couple of nits:



cell - "a single element in the TSCH schedule" should be "a =
single element in a TSCH superframe".  Cells are not defined just=
 by slot and channel offset, but also by superframe length.



SlotOffset - "in the TSCH schedule" should be "in a TSCH sup=
erframe"



ksjp




On 3/11/2013 3:21 AM, Maria Rita PALATTELLA wrote:






All,


 <=
/o:p>


You can find ver=
sion 00 of the 6tsch-terminology draft at
 http://www.ietf.org/internet-drafts/draft-palat=
tella-6tsch-terminology-00.txt .<=
/span>


 <=
/o:p>


Best Regards,


 <=
/o:p>


Maria Rita


 









_______________________________________________


6tsch mailing list


6tsch@ietf.org


https://www.ie=
tf.org/mailman/listinfo/6tsch




 






--_000_8CF9EAFF7636FC419FEE1042DC36C12FB6BE3AS04MBX0108s04loca_--

From maria-rita.palattella@uni.lu  Tue Mar 12 04:13:30 2013
Return-Path: 
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 8986A21F88F7 for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 04:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.498
X-Spam-Level: 
X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 kWK+tk9paWdH for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 04:13:28 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 349FD21F88C0 for <6tsch@ietf.org>; Tue, 12 Mar 2013 04:13:25 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,830,1355094000"; d="scan'208,217";a="22836585"
Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 12 Mar 2013 12:13:24 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.01.0438.000; Tue, 12 Mar 2013 12:13:23 +0100
From: Maria Rita PALATTELLA 
To: Robert Assimiti , Kris Pister , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] terminology-draft posted
Thread-Index: Ac4eQiidDbVeURWoT3SY2WtSZB4cowAJktGAACK+9rAABW9PgAACMOSQ
Date: Tue, 12 Mar 2013 11:13:23 +0000
Message-ID: 
References:  <513DFE69.9030908@eecs.berkeley.edu>  <8CF9EAFF7636FC419FEE1042DC36C12FB6BE3A@S04-MBX01-08.s04.local>
In-Reply-To: <8CF9EAFF7636FC419FEE1042DC36C12FB6BE3A@S04-MBX01-08.s04.local>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.91.0.81]
Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185275F2hoshiunilux_"
MIME-Version: 1.0
Subject: Re: [6tsch] terminology-draft posted
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2013 11:13:30 -0000

--_000_F085911F642A6847987ADA23E611780D185275F2hoshiunilux_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Robert, many thanks for your comments/suggestions:

-        Link. I do agree to add a definition of Link in its general meanin=
g (i.e., single-hop connection). The IEEE802.15.4e link is replaced by cell=
 in the context of 6TSCH.

-        Cell. It is just terminology, and I do agree to add slotframe_ID a=
nd Hopping-Sequence_ID.


Best regards, Maria Rita


From: Robert Assimiti [mailto:robert.assimiti@nivis.com]
Sent: Tuesday, March 12, 2013 12:06 PM
To: Maria Rita PALATTELLA; Kris Pister; 6tsch@ietf.org
Subject: RE: [6tsch] terminology-draft posted

Maria,

Thank you for working on the terminology. This is and will prove to be very=
 helpful as we make more progress.

A few comments/suggestions:


Link - IEEE 802.15.4e uses links in order to assign various data transactio=
n types to a particular timeslot. I do realize that the term is way too loa=
ded, so maybe we can call it something else in the context of 6TSCH. I sugg=
est also including a definition of the link concept.



Cell - is this just terminology or are you actually trying to define a new =
IE that bundles as bunch of other IEs? If this is just terminology, I would=
 also add the slotframe_ID  and Hopping_Sequence_ID to the current  identif=
ier composed of slotOffset and channelOffest in order to uniquely identify =
the cell.

Robert Assimiti

From: 6tsch-bounces@ietf.org [mailto:6tsch-b=
ounces@ietf.org] On Behalf Of Maria Rita PALATTELLA
Sent: Tuesday, March 12, 2013 3:34 AM
To: Kris Pister; 6tsch@ietf.org
Subject: Re: [6tsch] terminology-draft posted

Kris, thanks for having gone through it already, and for providing some com=
ments/corrections.
First, I think we will talk about SLOTFRAME (as specified in 15.4e TSCH std=
. ) and not superframe. Do you agree with me?
Second, are the cells defined by slotframe ID or slotframe LENGTH (or both)=
?
Thanks for your help.
Maria Rita

From: 6tsch-bounces@ietf.org [mailto:6tsch-b=
ounces@ietf.org] On Behalf Of Kris Pister
Sent: Monday, March 11, 2013 4:55 PM
To: 6tsch@ietf.org
Subject: Re: [6tsch] terminology-draft posted

That's very helpful.

A couple of nits:

cell - "a single element in the TSCH schedule" should be "a single element =
in a TSCH superframe".  Cells are not defined just by slot and channel offs=
et, but also by superframe length.

SlotOffset - "in the TSCH schedule" should be "in a TSCH superframe"

ksjp
On 3/11/2013 3:21 AM, Maria Rita PALATTELLA wrote:
All,


You can find version 00 of the 6tsch-terminology draft at  http://www.ietf.=
org/internet-drafts/draft-palattella-6tsch-terminology-00.txt .

Best Regards,

Maria Rita



_______________________________________________

6tsch mailing list

6tsch@ietf.org

https://www.ietf.org/mailman/listinfo/6tsch


--_000_F085911F642A6847987ADA23E611780D185275F2hoshiunilux_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Robert, many thanks fo=
r your comments/suggestions:


-&nb=
sp;      
Link. I do agree to add a definition of Link =
in its general meaning (i.e., single-hop connection). The IEEE802.15.4e lin=
k is replaced by cell in the context
 of 6TSCH.


-&nb=
sp;      
Cell=
. It is just terminology, and I do agree =
to add slotframe_ID and Hopping-Sequence_ID.


 


Best regards, M=
aria Rita


 


 






From: Robert Assimiti [mailto:robert.assimiti@nivis.com=
]


Sent: Tuesday, March 12, 2013 12:06 PM

To: Maria Rita PALATTELLA; Kris Pister; 6tsch@ietf.org

Subject: RE: [6tsch] terminology-draft posted






 


Maria,




Thank you for working on the terminology. This is and will prove to be very=
 helpful as we make more progress.




A few comments/suggestions:


 


Link – IE=
EE 802.15.4e uses links in order to assign various data transaction types t=
o a particular timeslot. I do realize that the term is way too loaded, so m=
aybe we can call it something else in the
 context of 6TSCH. I suggest also including a definition of the link concep=
t.


 


Cell – is=
 this just terminology or are you actually trying to define a new IE that b=
undles as bunch of other IEs? If this is just terminology, I would also add=
 the slotframe_ID  and Hopping_Sequence_ID
 to the current  identifier composed of slotOffset and channelOffest i=
n order to uniquely identify the cell.


 




Robert Assimiti




 






From:
6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org]
On Behalf Of Maria Rita PALATTELLA

Sent: Tuesday, March 12, 2013 3:34 AM

To: Kris Pister; 6tsch@ietf.org

Subject: Re: [6tsch] terminology-draft posted






 


Kris, thanks for havin=
g gone through it already, and for providing some comments/corrections.


First, I think we will=
 talk about SLOTFRAME (as specified in 15.4e TSCH std. ) and not superframe=
. Do you agree with me?


Second, are the cells =
defined by slotframe ID or slotframe LENGTH (or both)?

Thanks for your help.<=
o:p>


Maria Rita<=
/span>


 






From:
6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org]
On Behalf Of Kris Pister

Sent: Monday, March 11, 2013 4:55 PM

To: 6tsch@ietf.org

Subject: Re: [6tsch] terminology-draft posted






 


That's very helpful.<=
br>


A couple of nits:



cell - "a single element in the TSCH schedule" should be "a =
single element in a TSCH superframe".  Cells are not defined just=
 by slot and channel offset, but also by superframe length.



SlotOffset - "in the TSCH schedule" should be "in a TSCH sup=
erframe"



ksjp




On 3/11/2013 3:21 AM, Maria Rita PALATTELLA wrote:






All,


 <=
/o:p>


You can find ver=
sion 00 of the 6tsch-terminology draft at
 http://www.ietf.org/internet-drafts/draft-palat=
tella-6tsch-terminology-00.txt .<=
/span>


 <=
/o:p>


Best Regards,


 <=
/o:p>


Maria Rita


 


=
 


_______________________________________________


6tsch mailing list


6tsch@ietf.org


https://www.ie=
tf.org/mailman/listinfo/6tsch




 






--_000_F085911F642A6847987ADA23E611780D185275F2hoshiunilux_--

From mcr@sandelman.ca  Tue Mar 12 08:55:46 2013
Return-Path: 
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 ED61911E80E7 for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 08:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.442
X-Spam-Level: 
X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311]
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 VpzU5Uuc8FiM for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 08:55:45 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACF921F8C08 for <6tsch@ietf.org>; Tue, 12 Mar 2013 08:55:45 -0700 (PDT)
Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id 81F3122060 for <6tsch@ietf.org>; Tue, 12 Mar 2013 15:55:44 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CC1FACA0BC for <6tsch@ietf.org>; Tue, 12 Mar 2013 11:55:42 -0400 (EDT)
From: Michael Richardson 
to: IETF 6TSCH <6tsch@ietf.org>
In-reply-to: <32756.1363030990@sandelman.ca>
References:  <19015.1362797728@sandelman.ca>  <32756.1363030990@sandelman.ca>
Comments: In-reply-to Michael Richardson  message dated "Mon, 11 Mar 2013 15:43:10 -0400."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 12 Mar 2013 11:55:42 -0400
Message-ID: <7329.1363103742@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [6tsch] what to call "flow" with different priorities
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2013 15:55:46 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Michael" =3D=3D Michael Richardson  writes:
    Michael> bad...  It's good that we talk about frames, fragments,
    Michael> packets and=20
    Michael> segments with much clarity.

BTW: Ralph has suggested that the things that 6lowPAN produces are "fraglet=
s"

=2D-=20
Michael Richardson
=2Don the road-

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJRP0/+AAoJEKD0KQ7Gj3P2ZsMH/2BOsAT121w7IE0LfFybjBnP
BMTDwIwUrfA/Ry7JNP62/vUdUbPhnWqZBAUZwnDrnnpjB/eFVbylDpWRc9mpuijr
R5pqH6wr3flsXRJcinD7XrpzpArY1YSC9iczr15FpEit+pFz+i5fPA28xsAoZj9+
YwOGdyaMqTbCxgnX9ahTtcWquMMlkuFilNKlpVMpAg9uyHb3APtDP54sxEfhg8YI
9KAqC5VhYfnr75Nbf3flUeoyUOqKk7fT+kD4gz9yFnCUhfzd35RHVGjABk0uozGR
76XNhR8NvXI186P8W5uizFJtM/u/EfLhjS0CwF0XPzS7rCx+BZgfctjaKjW0dh8=
=OIm4
-----END PGP SIGNATURE-----
--=-=-=--

From mcr@sandelman.ca  Tue Mar 12 11:33:53 2013
Return-Path: 
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 D5B3211E8121 for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 11:33:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311]
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 ilmda61YPPZQ for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 11:33:53 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 042C411E817C for <6tsch@ietf.org>; Tue, 12 Mar 2013 11:33:53 -0700 (PDT)
Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id 41B2B22064; Tue, 12 Mar 2013 18:33:52 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 640CECA0BC; Tue, 12 Mar 2013 12:05:56 -0400 (EDT)
From: Michael Richardson 
To: Kris Pister 
In-reply-to: <513E489B.6070306@eecs.berkeley.edu>
References:  <19015.1362797728@sandelman.ca>  <1953.1363034941@sandelman.ca> <513E489B.6070306@eecs.berkeley.edu>
Comments: In-reply-to Kris Pister  message dated "Mon, 11 Mar 2013 14:11:55 -0700."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 12 Mar 2013 12:05:56 -0400
Message-ID: <7841.1363104356@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] how to handle different classes of traffic
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2013 18:33:54 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Kris" =3D=3D Kris Pister  writes:
    >> My understanding is that we wish to use a non-protected ("CAP" is wh=
at I
    >> understand to be the 802.15.4 term)

    Kris> Just to make sure we're on the same page:
    Kris> CAP =3D "contention access period" has a specific meaning in
    Kris> 15.4. It's the=20
    Kris> CSMA period after a beacon in the original standard, also used
    Kris> by the DSME=20

yes, that's what I meant. I believe that 4e can still have a Contention
Access Period?

    Kris> and LE MACs in 4e.  If CAP were not already defined for these 15.=
4 modes,
    Kris> then using a slotted aloha (contention-based) mechanism for initi=
al
    Kris> communication might reasonably be called CAP, but given that
    Kris> the term is=20
    Kris> already defined elsewhere we should avoid it here.

So, does 4e define "sloted aloha"? I'm halfway through it that document.

    >> I don't think that one needs or wants a slotframe per DODAG (althoug=
h it
    >> could degenerate to that), nor do I think that this is useful, as fa=
ct
    >> different packets (particularly downward ones!) go out actually in
    >> different ways.

    Kris> Can you say more about this?  I was thinking that we want at
    Kris> least one=20
    Kris> slotframe per DODAG.

But, my understanding is that a slotframe is used to communicate from
mote A to mote B (at time T, on frequency l).

A node in the DODAG will in general have one or more parents, and one or
more children.   So at a minimum you need a slotframe for each adjacancy
that the DODAG has created.  If there are multiple applications using
the LLN, then you may have multiple DODAGs (with different parameters),
so if each DODAG needs a set of slotframes, then I think we may well
easily run out of slotframes.

That's why I think that each DODAG gets a reservation on one or more
slotframes.

    >> (%)- now above I said that how big the slotframes would be
    >> decided out of=20
    >> scope, but in fact, I get the impression that we actually want to fi=
gure
    >> out the DODAG structure, and then once we know what adjacencies are
    >> possible, that we then decide how big a slotframe to allocate.

    Kris> That sounds good, and is something that gets done dynamically,
    Kris> yes?=20

My impression is that the information goes up into a PCE, which crunches
a bunch of data, and produces a schedule.  That work doesn't happen
frequently, and in may in fact occur once only after the network is initial=
ly
provisioned.

=2D-=20
Michael Richardson
=2Don the road-



--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJRP1JeAAoJEKD0KQ7Gj3P2WuQH/38c/PHkf5ba43v86o3ELMtT
zuS0v4LlxIRsasq6hdUBujijAgdOWogIibRA7FX3EcAW9ivuKhMzsmZUgPsjGvh0
7CyEcO7OeRd4p9/gzJiB76d93DEjxThUeUc/HAEMpkqlmagZ/NrOP7TVYD9JhJ5D
pZtyI5Sw5wdqLZjbUXOp+qVd8cdrbXzimNmM4DJCN0k/+jwZqBwLLqOXBFosDY0B
DN5z3cH1djNQf715Q9U9JSAdMOb7BjYoNWE8Hm9nlk/+PmtcSWQpwG9dpyKfUQg4
mOmQUIr3FZyLulkH593F5jN5wPvoyJ1mxTd5l9gKgjYIQb4nr+7G4+atrmEi6lE=
=TYil
-----END PGP SIGNATURE-----
--=-=-=--

From tom.phinney@cox.net  Tue Mar 12 11:37:51 2013
Return-Path: 
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 EDC1311E8117 for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 11:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.881
X-Spam-Level: 
X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[AWL=0.260,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
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 e5yAF-plW16k for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 11:37:50 -0700 (PDT)
Received: from fed1rmfepo101.cox.net (fed1rmfepo101.cox.net [68.230.241.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0500311E8176 for <6tsch@ietf.org>; Tue, 12 Mar 2013 11:37:49 -0700 (PDT)
Received: from fed1rmimpo109 ([68.230.241.158]) by fed1rmfepo101.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130312183749.MIBN25001.fed1rmfepo101.cox.net@fed1rmimpo109> for <6tsch@ietf.org>; Tue, 12 Mar 2013 14:37:49 -0400
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo109 with cox id Aido1l00c3gAAro01idocf; Tue, 12 Mar 2013 14:37:49 -0400
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020202.513F75FD.0035,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=DJZRFVxb c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=48vgC7mUAAAA:8 a=w6kJWEZ72ddEXFE2q28A:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=lZB815dzVvQA:10 a=9dER5XXw_d4yz1sl:21 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <513F75FC.50700@cox.net>
Date: Tue, 12 Mar 2013 11:37:48 -0700
From: Tom Phinney 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: 6tsch@ietf.org
References: 	<19015.1362797728@sandelman.ca>		<32756.1363030990@sandelman.ca> <7329.1363103742@sandelman.ca>
In-Reply-To: <7329.1363103742@sandelman.ca>
X-Enigmail-Version: 1.1.1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [6tsch] fraglets
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney 
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2013 18:37:51 -0000



  
    
  
  
    My vote is for "fraglets" and "fragleting" and
      "fragletation". 

      

      Fragmentation is the IETF term for segmentation at the network
      layer, presumably distinguishing it from segmentation that occurs
      above the communication layers (e.g., in the application layer).
      Since the inverse of segmentation, which is recombination or
      reassembly, is already used both for OSI segmentation and IETF
      fragmentation, it might as well be used for 6LoWPAN fragletation
      as well.

      

      -Tom

      ====

    On 2013.03.12 08:55, Michael Richardson wrote:
    

      

      

        

          

            

              

                
"Michael" == Michael Richardson <mcr+ietf@sandelman.ca> writes:


              

            

          

        

      

      
    Michael> bad...  It's good that we talk about frames, fragments,
    Michael> packets and 
    Michael> segments with much clarity.

BTW: Ralph has suggested that the things that 6lowPAN produces are "fraglets"



      

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


    

  


From xvilajosana@eecs.berkeley.edu  Tue Mar 12 13:53:17 2013
Return-Path: 
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 1FA3311E8121 for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 13:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 AqVeIG6SYH5V for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 13:53:16 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC4F11E80E3 for <6tsch@ietf.org>; Tue, 12 Mar 2013 13:53:16 -0700 (PDT)
Received: from dhcp-13ea.meeting.ietf.org ([130.129.19.234]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UFWCA-0001fw-AE for 6tsch@ietf.org; Tue, 12 Mar 2013 13:53:16 -0700
Message-ID: <513F95B8.7000408@eecs.berkeley.edu>
Date: Tue, 12 Mar 2013 13:53:12 -0700
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: 6tsch@ietf.org
References:  <19015.1362797728@sandelman.ca>  <1953.1363034941@sandelman.ca> <513E489B.6070306@eecs.berkeley.edu> <7841.1363104356@sandelman.ca>
In-Reply-To: <7841.1363104356@sandelman.ca>
Content-Type: multipart/alternative; boundary="------------000503030205090300090601"
Subject: Re: [6tsch] how to handle different classes of traffic
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Mar 2013 20:53:17 -0000

This is a multi-part message in MIME format.
--------------000503030205090300090601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michael,

just to clarify.

a slotframe is a collection of slots (namely "A MAC-level abstraction that is internal to the node and contains a series of timeslots of equal length and priority."

What you refer to is a Cell "A single element in the TSCH schedule, identified by a  slotOffset and a channelOffset value)


>> But, my understanding is that a slotframe is used to communicate from
>> mote A to mote B (at time T, on frequency l).

>> A node in the DODAG will in general have one or more parents, and one or
>> more children.   So at a minimum you need a slotframe for each adjacancy
>> that the DODAG has created.  If there are multiple applications using
>> the LLN, then you may have multiple DODAGs (with different parameters),
>> so if each DODAG needs a set of slotframes, then I think we may well
>> easily run out of slotframes.

A node can have a scheduled cell to each of its parents (maybe only to those that you want to communicate to). If multiple DODAGs co-exists, and the routes they have use same parents, there is no need to have more cells on the schedule as long as the required bandwidth is met.

does make sense to you?

X


>> That's why I think that each DODAG gets a reservation on one or more
>> slotframes.






On 12/03/13 09:05, Michael Richardson wrote:
>>>>>> "Kris" == Kris Pister  writes:
>      >> My understanding is that we wish to use a non-protected ("CAP" is what I
>      >> understand to be the 802.15.4 term)
>
>      Kris> Just to make sure we're on the same page:
>      Kris> CAP = "contention access period" has a specific meaning in
>      Kris> 15.4. It's the
>      Kris> CSMA period after a beacon in the original standard, also used
>      Kris> by the DSME
>
> yes, that's what I meant. I believe that 4e can still have a Contention
> Access Period?
>
>      Kris> and LE MACs in 4e.  If CAP were not already defined for these 15.4 modes,
>      Kris> then using a slotted aloha (contention-based) mechanism for initial
>      Kris> communication might reasonably be called CAP, but given that
>      Kris> the term is
>      Kris> already defined elsewhere we should avoid it here.
>
> So, does 4e define "sloted aloha"? I'm halfway through it that document.
>
>      >> I don't think that one needs or wants a slotframe per DODAG (although it
>      >> could degenerate to that), nor do I think that this is useful, as fact
>      >> different packets (particularly downward ones!) go out actually in
>      >> different ways.
>
>      Kris> Can you say more about this?  I was thinking that we want at
>      Kris> least one
>      Kris> slotframe per DODAG.
>
> But, my understanding is that a slotframe is used to communicate from
> mote A to mote B (at time T, on frequency l).
>
> A node in the DODAG will in general have one or more parents, and one or
> more children.   So at a minimum you need a slotframe for each adjacancy
> that the DODAG has created.  If there are multiple applications using
> the LLN, then you may have multiple DODAGs (with different parameters),
> so if each DODAG needs a set of slotframes, then I think we may well
> easily run out of slotframes.
>
> That's why I think that each DODAG gets a reservation on one or more
> slotframes.
>
>      >> (%)- now above I said that how big the slotframes would be
>      >> decided out of
>      >> scope, but in fact, I get the impression that we actually want to figure
>      >> out the DODAG structure, and then once we know what adjacencies are
>      >> possible, that we then decide how big a slotframe to allocate.
>
>      Kris> That sounds good, and is something that gets done dynamically,
>      Kris> yes?
>
> My impression is that the information goes up into a PCE, which crunches
> a bunch of data, and produces a schedule.  That work doesn't happen
> frequently, and in may in fact occur once only after the network is initially
> provisioned.
>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


--------------000503030205090300090601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

      
Hi Michael,

just to clarify.

a slotframe is a collection of slots (namely "A MAC-level abstraction that is internal to the node and contains a series of timeslots of equal length and priority."

What you refer to is a Cell "A single element in the TSCH schedule, identified by a  slotOffset and a channelOffset value)


>> But, my understanding is that a slotframe is used to communicate from
>> mote A to mote B (at time T, on frequency l).

>> A node in the DODAG will in general have one or more parents, and one or
>> more children.   So at a minimum you need a slotframe for each adjacancy
>> that the DODAG has created.  If there are multiple applications using
>> the LLN, then you may have multiple DODAGs (with different parameters),
>> so if each DODAG needs a set of slotframes, then I think we may well
>> easily run out of slotframes.

A node can have a scheduled cell to each of its parents (maybe only to those that you want to communicate to). If multiple DODAGs co-exists, and the routes they have use same parents, there is no need to have more cells on the schedule as long as the required bandwidth is met.

does make sense to you?

X


>> That's why I think that each DODAG gets a reservation on one or more
>> slotframes.



      

      

      

      

      

      On 12/03/13 09:05, Michael Richardson wrote:

    

    

      

      

        

          

            

              

                
"Kris" == Kris Pister <pister@eecs.berkeley.edu> writes:


              

            

          

        

      

      
    >> My understanding is that we wish to use a non-protected ("CAP" is what I
    >> understand to be the 802.15.4 term)

    Kris> Just to make sure we're on the same page:
    Kris> CAP = "contention access period" has a specific meaning in
    Kris> 15.4. It's the 
    Kris> CSMA period after a beacon in the original standard, also used
    Kris> by the DSME 

yes, that's what I meant. I believe that 4e can still have a Contention
Access Period?

    Kris> and LE MACs in 4e.  If CAP were not already defined for these 15.4 modes,
    Kris> then using a slotted aloha (contention-based) mechanism for initial
    Kris> communication might reasonably be called CAP, but given that
    Kris> the term is 
    Kris> already defined elsewhere we should avoid it here.

So, does 4e define "sloted aloha"? I'm halfway through it that document.

    >> I don't think that one needs or wants a slotframe per DODAG (although it
    >> could degenerate to that), nor do I think that this is useful, as fact
    >> different packets (particularly downward ones!) go out actually in
    >> different ways.

    Kris> Can you say more about this?  I was thinking that we want at
    Kris> least one 
    Kris> slotframe per DODAG.

But, my understanding is that a slotframe is used to communicate from
mote A to mote B (at time T, on frequency l).

A node in the DODAG will in general have one or more parents, and one or
more children.   So at a minimum you need a slotframe for each adjacancy
that the DODAG has created.  If there are multiple applications using
the LLN, then you may have multiple DODAGs (with different parameters),
so if each DODAG needs a set of slotframes, then I think we may well
easily run out of slotframes.

That's why I think that each DODAG gets a reservation on one or more
slotframes.

    >> (%)- now above I said that how big the slotframes would be
    >> decided out of 
    >> scope, but in fact, I get the impression that we actually want to figure
    >> out the DODAG structure, and then once we know what adjacencies are
    >> possible, that we then decide how big a slotframe to allocate.

    Kris> That sounds good, and is something that gets done dynamically,
    Kris> yes? 

My impression is that the information goes up into a PCE, which crunches
a bunch of data, and produces a schedule.  That work doesn't happen
frequently, and in may in fact occur once only after the network is initially
provisioned.



      

      

      

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


    

    

  


--------------000503030205090300090601--

From twatteyne@gmail.com  Tue Mar 12 23:35:17 2013
Return-Path: 
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 027FD21F8C98 for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 23:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 jNayfequwhUN for <6tsch@ietfa.amsl.com>; Tue, 12 Mar 2013 23:35:16 -0700 (PDT)
Received: from mail-da0-x234.google.com (mail-da0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7282C21F8C97 for <6tsch@ietf.org>; Tue, 12 Mar 2013 23:35:16 -0700 (PDT)
Received: by mail-da0-f52.google.com with SMTP id f10so276082dak.11 for <6tsch@ietf.org>; Tue, 12 Mar 2013 23:35:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=JW+kKRVZ7OGvOSDFdeGDoN40A96rr7+0hqYkAeIMTQc=; b=V1I3D3vQv2bsGfoeLY8aEEwn8D7Usp7YwuxONDykm1VuGnzcbsSOVCOKPyDtw0tJiP bv8rDRko0Llq6CFaRQU5Qh2U7RLSaEx+u4M4aPpy29XcgRgf/DFWDsVWsBgHsvGmBNVC O3GWu68j6UI5vJGKFguwH8dE2lmExSwfjhSqJHREKVfruko9Wcd2l0qLa3vaucwgUhyk 72Eht1vdzcWDfAFnwddiqT53RWs01pOslpiipN8UNLkOaCni/QPauO8p2Mm4yvFiWYXK yROzuKrgWKF3q7S5e+KRpZanAMntG3MAQf0VImu+qg+dKZNSye+oQa1kzBq1on8FY32z FIAQ==
MIME-Version: 1.0
X-Received: by 10.68.117.104 with SMTP id kd8mr43812637pbb.1.1363156515885; Tue, 12 Mar 2013 23:35:15 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Tue, 12 Mar 2013 23:35:15 -0700 (PDT)
Date: Wed, 13 Mar 2013 02:35:15 -0400
X-Google-Sender-Auth: tc1158aQug73pclojJFZCQmyTro
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b072330e7cb4104d7c89b87
Subject: [6tsch] Tuesday meeting: minutes and slides
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Mar 2013 06:35:17 -0000

--047d7b072330e7cb4104d7c89b87
Content-Type: text/plain; charset=ISO-8859-1

All,

You will find the slides and minutes (thanks Xavi!) of the Tuesday meeting
at https://bitbucket.org/6tsch/ietf86-orlando/.

Thomas

--047d7b072330e7cb4104d7c89b87
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

All,

You will find the slides and minutes (thanks Xavi!)=
 of the Tuesday meeting at=A0https://bitbucket.org/6tsch/ietf86-orlando/.



Thomas




--047d7b072330e7cb4104d7c89b87--

From twatteyne@gmail.com  Wed Mar 13 00:15:24 2013
Return-Path: 
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 4C87921F8CD8 for <6tsch@ietfa.amsl.com>; Wed, 13 Mar 2013 00:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level: 
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[AWL=0.175,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 DGDawrBXriZq for <6tsch@ietfa.amsl.com>; Wed, 13 Mar 2013 00:15:23 -0700 (PDT)
Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id C1F0F21F8CD6 for <6tsch@ietf.org>; Wed, 13 Mar 2013 00:15:15 -0700 (PDT)
Received: by mail-pb0-f52.google.com with SMTP id ma3so719853pbc.39 for <6tsch@ietf.org>; Wed, 13 Mar 2013 00:15:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=Hh9HXztXMZ4nAoIAoNd2nzE0xRsSklyKJmBgL7dFknE=; b=hGX5vX1GTIu6niIgOBx/KVTP42Iqt9aJ/v9lFAV9ZZLVBQqjOADRvzpGg/P+5K7Uiv 3B8N8D3DvN3/E63dXvOCPARebKTsm5ZV68lITkk7rsBUB37N75jwb69Mn5+BfjY+XThl EoY9LR8QMagBaEXP7JCR/MMOyWs/EWJ+TflVX+Ka1J4icOdlNZQ8+GWitz8QQjZUZwxs vsGqc/whkaUXOp17T6mgU16wOK1UoOdVKOUZEuaIybOCdAhrA1BeYtnI6kqMkHMdJuIS zz/9HQ2H7YF9OYAcX5NwIffis1PO62IOkEn1+cSModhheSO7uHywsFInN57ex3Uir8nc 8Dhg==
MIME-Version: 1.0
X-Received: by 10.68.50.231 with SMTP id f7mr43623932pbo.221.1363158915197; Wed, 13 Mar 2013 00:15:15 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Wed, 13 Mar 2013 00:15:15 -0700 (PDT)
Date: Wed, 13 Mar 2013 03:15:15 -0400
X-Google-Sender-Auth: piBI_m190kc7-DhNuoQJ9u-IutQ
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=bcaec52e58bfea676f04d7c92a47
Subject: [6tsch] Wednesday meeting@IETF86: agenda and slides
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Mar 2013 07:15:24 -0000

--bcaec52e58bfea676f04d7c92a47
Content-Type: text/plain; charset=ISO-8859-1

All,

You will find the agenda, links to the drafts and slides for our Wednesday
meeting at https://bitbucket.org/6tsch/ietf86-orlando/.

Please note that this meeting will be in *Boca 2*, which is a different
room than the Tuesday meeting. It is scheduled *11.30am-1pm* Orlando time.

For those not in Orlando:
- follow the audio stream at
http://www.ietf.org/meeting/86/remote-participation.html (choose the *Boca 2
* stream).
- post questions using Jabber at 6tsch@conference.jabber.org.

Thomas

---

Wednesday meeting
Boca 2, 11.30-13.00+

Agenda:
   -Admin: [5min]
      - Slides online
      - Bitbucket repositories for drafts (code, issues)
   - Drafts: [55min]
      - draft-ietf-roll-rpl-industrial-applicability-00 [10min]
      - draft-palattella-6tsch-terminology-00 [5min]
      - draft-thubert-6tsch-architecture-00 [10min]
      - draft-watteyne-6tsch-tsch-lln-context-01 [10min]
      - draft-wang-6tsch-6tus-00 [20min]
   - Discussion: [30min]
      - Synchronization between BBRs
      - Slotframes, Cells and Priorities
      - Interaction between RPL and PCE

--bcaec52e58bfea676f04d7c92a47
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

All,

You will find the agenda, links to the drafts and s=
lides for our Wednesday meeting at=A0https://bitbucket.org/6tsch/ietf86-orla=
ndo/.




Please note that this meeting will be in Boca 2, whic=
h is a different room than the Tuesday meeting. It is scheduled 11.30am-=
1pm Orlando time.

For those not in Orlando:


- follow the audio stream at=A0http://www.ietf.org/meeting=
/86/remote-participation.html (choose the Boca 2 stream).
<=
div>
- post questions using Jabber at 6tsch@conference.jabber.org.



Thomas

---

Wednesday meeting
Boca 2, 11.30-13.00+<=
/div>



Agenda:
=A0 =A0-Admin: [5min]
=A0 =A0 =A0 - Slides online



=A0 =A0 =A0 - Bitbucket reposito=
ries for drafts (code, issues)
=A0 =A0- Drafts: [55min]
=A0 =A0 =A0 - draft-ietf-roll-rpl-industrial-applicability-=
00 [10min]



=A0 =A0 =A0 - draft-palattella-6=
tsch-terminology-00 [5min]
=A0 =A0 =A0 - draft-thubert-6tsch-architecture-00 [10min]
=A0 =A0 =A0 - draft-watteyne-6=
tsch-tsch-lln-context-01 [10min]



=A0 =A0 =A0 - draft-wang-6tsch-6=
tus-00 [20min]
=A0 =
=A0- Discussion: [30min]
=A0 =A0 =A0 - Synchronization between BBRs



=A0 =A0 =A0 - Slotframes, Cells =
and Priorities
=A0 =
=A0 =A0 - Interaction between RPL and PCE


--bcaec52e58bfea676f04d7c92a47--

From cabo@tzi.org  Wed Mar 13 09:31:59 2013
Return-Path: 
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 685A821F8CFB for <6tsch@ietfa.amsl.com>; Wed, 13 Mar 2013 09:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 bNurFU+Xgmeg for <6tsch@ietfa.amsl.com>; Wed, 13 Mar 2013 09:31:58 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 445A721F8D50 for <6tsch@ietf.org>; Wed, 13 Mar 2013 09:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2DGVqcs019631 for <6tsch@ietf.org>; Wed, 13 Mar 2013 17:31:52 +0100 (CET)
Received: from dhcp-9032.meeting.ietf.org (dhcp-9032.meeting.ietf.org [130.129.8.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C405637E3; Wed, 13 Mar 2013 17:31:51 +0100 (CET)
From: Carsten Bormann 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Mar 2013 12:31:49 -0400
To: IETF 6TSCH <6tsch@ietf.org>
Message-Id: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Subject: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Mar 2013 16:31:59 -0000

So, my take of the discussion we just had:

-- This is focused on the 6LoWPAN and the TSCH configuration within that
-- Packets will also need to make one IP hop outside the 6LoWPAN, let's =
call that the backbone
-- The backbone could be 802.1TSN style (~ Ethernet)
-- Setting the DSCP to ~ EF, doing the admission control for that, and =
possibly some 802.1TSN setup, is mostly all that we need in the backbone

That would simplify things by taking RSVP out of the picture and taking =
more of a diffserv approach.

Gr=FC=DFe, Carsten


From jeonggil.ko@gmail.com  Wed Mar 13 10:02:13 2013
Return-Path: 
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 757EC21F8CC7 for <6tsch@ietfa.amsl.com>; Wed, 13 Mar 2013 10:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Yi5xjUcNhQYh for <6tsch@ietfa.amsl.com>; Wed, 13 Mar 2013 10:02:11 -0700 (PDT)
Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8CB21F8CB8 for <6tsch@ietf.org>; Wed, 13 Mar 2013 10:02:11 -0700 (PDT)
Received: by mail-pb0-f53.google.com with SMTP id un1so1226159pbc.12 for <6tsch@ietf.org>; Wed, 13 Mar 2013 10:02:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=VYDivSV5HxeEAUbZAMPc33WFZhKhK6XBAu6//IO2Kys=; b=0l44weLdFkE8tQQPJztTzY0u4/Z0DxCnZi09O5gt3nfba3NGUnOB7Sx6v0MF+SZQtC QdDkc0mXk0jcanBpLMJE+O2GLat4gyUMoyWfy6CuTbC8dpQh35aVFi7uUmSlEoGE2BZr TCEm64er2c7r4b8K9M6C4+/+3GOuIZ6tHPdSMhLlkhlpFw630fQwJLC0d3wu8cMgZiE+ MjMntuLNQXwZsqlxXCIftvhfd/5kNJu7QaFnCdKgwdjT3zfSX9pzigN6l5pwC8UH6U98 QUwwv5cG58e8qXbQsQpkdNLKJhkmcNjxhi/4pluAyHJg49/HsbxGbEwIZPxrtQGwT3Vw Lxyg==
X-Received: by 10.68.33.98 with SMTP id q2mr47483287pbi.135.1363194130968; Wed, 13 Mar 2013 10:02:10 -0700 (PDT)
Received: from ?IPv6:2001:df8::16:b4bf:d28d:3a72:54fd? ([2001:df8:0:16:b4bf:d28d:3a72:54fd]) by mx.google.com with ESMTPS id b9sm30391714pba.6.2013.03.13.10.02.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Mar 2013 10:02:09 -0700 (PDT)
From: JeongGil Ko 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>
Date: Wed, 13 Mar 2013 13:02:06 -0400
To: IETF 6TSCH <6tsch@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Subject: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Mar 2013 17:02:13 -0000

Hi all,

I would like to start the discussion on what potential schemes can be =
used to reserve slot/bandwidth resources in an LLN on TSCH.=20

One scheme popping of the top of anyone's mind would be a simple form of =
RSVP but I think its meaningful to open up the discussions to many =
standardized schemes and perform a short survey on the pros and cons of =
each scheme.

Please start your discussions on this topic so we can start organizing =
the schemes.

Thanks!

-John


From twatteyne@gmail.com  Wed Mar 13 15:01:07 2013
Return-Path: 
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 5707B21F89CB for <6tsch@ietfa.amsl.com>; Wed, 13 Mar 2013 15:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.815
X-Spam-Level: 
X-Spam-Status: No, score=-2.815 tagged_above=-999 required=5 tests=[AWL=0.162,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 AWth3tcdBtI6 for <6tsch@ietfa.amsl.com>; Wed, 13 Mar 2013 15:01:06 -0700 (PDT)
Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9C27F21F845D for <6tsch@ietf.org>; Wed, 13 Mar 2013 15:01:06 -0700 (PDT)
Received: by mail-pb0-f54.google.com with SMTP id rr4so1439584pbb.41 for <6tsch@ietf.org>; Wed, 13 Mar 2013 15:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wPnnn39diaB2Ixx68qIW7cQdE2Jl48ZaWrFyIZYjPL0=; b=R2xxQ8p8iO9YaylwemYD8ufxA6sUBe+epHlDy+ANk6vyko9E2pLc9iUYkM9CXzsOFM Lqx8ME5qY30bBZ9N9hp3mueFZVcyewJTAnPGd+48xEixMuS6Wc3Bi7N8WNUuBW/NptuP c19cTKoVcprbmRhsbqiDte1ZQX5lEmIwVmCp5VTcun+pfcKR/4KYjnpSAaFeglof2YhE GWVRAvqR2skkf8QdrWP/2jBkUzaCFMK46ZHPoAxVHYDCivPGR0INZr04KZ5BXD1Sdr4F WEbKbdDBwiZIeXejf0SKSBQMBfH+XPOtnIm8TsNJn7kdWoOWLN8g3Q2FW5kNcRkzuPOh 3oWQ==
MIME-Version: 1.0
X-Received: by 10.68.248.74 with SMTP id yk10mr69923pbc.38.1363212066161; Wed, 13 Mar 2013 15:01:06 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Wed, 13 Mar 2013 15:01:06 -0700 (PDT)
In-Reply-To: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>
References: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>
Date: Wed, 13 Mar 2013 18:01:06 -0400
X-Google-Sender-Auth: dmwXEyeJdd1CojsrFx7EeyxtvD0
Message-ID: 
From: Thomas Watteyne 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=047d7b2e0a17f5bf8404d7d58a31
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Mar 2013 22:01:07 -0000

--047d7b2e0a17f5bf8404d7d58a31
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Carsten,

Thank you for the summary. I believe your statements are accurate: the only
thing 6TSCH is interested about is how to make the 6LoWPAN LLN work when
using IEEE802.15.4e at the MAC layer, using nothing but IEEE and IETF
standards.

The architecture we are targetting is shown in [1], i.e.:
- one or more LLNs, each connected to a backbone router (BBR)
- BBRs are connected through a backbone
- optionally a PCE sits on the backbone and drives the LLNs' TSCH schedules=
.
- when a packet goes from one LLN to another over the backbone, ideally, we
want the deterministic nature of the transmission to remain on the
backbone. So if there is some easy mapping between deterministic TSCH flows
and deterministic "backbone" flows (e.g. IEEE802.1TSN), that would be great=
.
- I agree that the obvious choice is to map DSCPs into TSCH flow priorities=
.

As for the term "RSVP", it might be a big word for our little group :) What
we are talking about it to use some distributed multi-hop resource
reservation protocol within the TSCH LLN to reserve TSCH cells.

I hope this makes sense,
Thomas


[1] http://tools.ietf.org/html/draft-thubert-6tsch-architecture-00#page-5

On Wed, Mar 13, 2013 at 12:31 PM, Carsten Bormann  wrote:

> So, my take of the discussion we just had:
>
> -- This is focused on the 6LoWPAN and the TSCH configuration within that
> -- Packets will also need to make one IP hop outside the 6LoWPAN, let's
> call that the backbone
> -- The backbone could be 802.1TSN style (~ Ethernet)
> -- Setting the DSCP to ~ EF, doing the admission control for that, and
> possibly some 802.1TSN setup, is mostly all that we need in the backbone
>
> That would simplify things by taking RSVP out of the picture and taking
> more of a diffserv approach.
>
> Gr=FC=DFe, Carsten
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>

--047d7b2e0a17f5bf8404d7d58a31
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Carsten,

Thank you for the summary. I believe your state=
ments are accurate: the only thing 6TSCH is interested about is how to make=
 the 6LoWPAN LLN work when using IEEE802.15.4e at the MAC layer, using noth=
ing but IEEE and IETF standards.



The architecture we are targetting is shown in [1], i.e=
.:
- one or more LLNs, each connected to a backbone router (BBR)<=
/div>
- BBRs are connected through a backbone
- optionally a =
PCE sits on the backbone and drives the LLNs' TSCH schedules.


- when a packet goes from one LLN to another over the backbone, ideall=
y, we want the deterministic nature of the transmission to remain on the ba=
ckbone. So if there is some easy mapping between deterministic TSCH flows a=
nd=A0deterministic=A0"backbone" flows (e.g. IEEE802.1TSN), that w=
ould be great.


- I agree that the obvious choice is to map DSCPs into TSCH flow prior=
ities.

As for the term "RSVP", it might =
be a big word for our little group :) What we are talking about it to use s=
ome distributed multi-hop resource reservation protocol within the TSCH LLN=
 to reserve TSCH cells.



I hope this makes sense,
Thomas

[1]=A0http://tools.ietf.org/html/draft-th=
ubert-6tsch-architecture-00#page-5



On Wed, Mar 13, 2013 at 12:31 PM, =
Carsten Bormann <cabo@tzi.org> wrote:

So, my take of the discussion we just had:



-- This is focused on the 6LoWPAN and the TSCH configuration within that
-- Packets will also need to make one IP hop outside the 6LoWPAN, let's=
 call that the backbone

-- The backbone could be 802.1TSN style (~ Ethernet)

-- Setting the DSCP to ~ EF, doing the admission control for that, and poss=
ibly some 802.1TSN setup, is mostly all that we need in the backbone



That would simplify things by taking RSVP out of the picture and taking mor=
e of a diffserv approach.



Gr=FC=DFe, Carsten



_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





--047d7b2e0a17f5bf8404d7d58a31--

From mcr@sandelman.ca  Wed Mar 13 20:53:26 2013
Return-Path: 
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 0420B21F8712 for <6tsch@ietfa.amsl.com>; Wed, 13 Mar 2013 20:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.288
X-Spam-Level: 
X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311]
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 wU26y4+E3lBf for <6tsch@ietfa.amsl.com>; Wed, 13 Mar 2013 20:53:25 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5B62721F85FC for <6tsch@ietf.org>; Wed, 13 Mar 2013 20:53:25 -0700 (PDT)
Received: from sandelman.ca (unknown [70.193.196.66]) by relay.sandelman.ca (Postfix) with ESMTPS id 8196822060; Thu, 14 Mar 2013 03:53:24 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D71D2CA0C8; Wed, 13 Mar 2013 22:52:34 -0400 (EDT)
From: Michael Richardson 
To: Xavier Vilajosana 
In-reply-to: <513F95B8.7000408@eecs.berkeley.edu>
References:  <19015.1362797728@sandelman.ca>  <1953.1363034941@sandelman.ca> <513E489B.6070306@eecs.berkeley.edu> <7841.1363104356@sandelman.ca> <513F95B8.7000408@eecs.berkeley.edu>
Comments: In-reply-to Xavier Vilajosana  message dated "Tue, 12 Mar 2013 13:53:12 -0700."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Wed, 13 Mar 2013 22:52:34 -0400
Message-ID: <6111.1363229554@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] how to handle different classes of traffic
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 03:53:26 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Xavier" =3D=3D Xavier Vilajosana  wri=
tes:

    Xavier> a slotframe is a collection of slots (namely "A MAC-level
    Xavier> abstraction that is internal to the node and contains a
    Xavier> series of timeslots of equal length and priority."

Do slotframes go to one destination or many?  (I'm not including
multicast here)

=2D-=20
Michael Richardson
=2Don the road-



--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJRQTtyAAoJEKD0KQ7Gj3P25owH/0uzBfxOGFseFHmrIRr99eeZ
2l6tdYHI/NI8QNGCR4syKWof4ES8nAvLxg45+K/VDPtLefKHiUZtSa7u2jZnoBXw
gFHve3CWcvoXjIEIxnao/RuXzgUGc5G86D+crKD++sjKSIc/aY8UmWc9V/6nTMVj
7B3KyzHyUkj8QzkLw3ghCktJSnH+G5vTGGruUuyWHUmWniOl7pQcvID+cRY7PIEq
OxJmY0xyE8Z9iGIh9sCUv3LOTp9JzRkzX1yu7Zwa+nnDU3m07+dvxVj6t4SsqhHd
FE4XMhnHvy6SbSRwgHDyP6jQpA+1fghYN9mxUCtKSKqLCh62y6bI70mKaTPSQOg=
=l0QY
-----END PGP SIGNATURE-----
--=-=-=--

From sakane@tanu.org  Thu Mar 14 04:31:55 2013
Return-Path: 
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 D2D6121F8FB2 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 04:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.723
X-Spam-Level: 
X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265]
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 JeD2pf5eTrca for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 04:31:55 -0700 (PDT)
Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by ietfa.amsl.com (Postfix) with ESMTP id 7094F21F8FC6 for <6tsch@ietf.org>; Thu, 14 Mar 2013 04:31:50 -0700 (PDT)
Received: from mactanu.local (dhcp-43d4.meeting.ietf.org [130.129.67.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id 0B37E16B17 for <6tsch@ietf.org>; Thu, 14 Mar 2013 20:31:48 +0900 (JST)
Message-ID: <5141B51E.3050603@tanu.org>
Date: Thu, 14 Mar 2013 20:31:42 +0900
From: Shoichi Sakane 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: IETF 6TSCH <6tsch@ietf.org>
References: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 11:31:55 -0000

Hi,

I am trying to understand the architecture accurately.  Let me ask one thing.

> The architecture we are targetting is shown in [1], i.e.:
> - optionally a PCE sits on the backbone and drives the LLNs' TSCH schedules.

If a PCE is option, who coordinates the LLNs' TSCH ? Is it by BBRs ?
Do you assume that each BBR negotiates something TSCH parameters with other in order to make a logical PCE on the BBRs ?

I guess a PCE is option only when a single LLN that doesn't need to exchange packets with other LLNs and the BBR has a function of PCE.  Correct ?

Shoichi

On 3/14/13 7:01 AM, Thomas Watteyne wrote:
> Carsten,
>
> Thank you for the summary. I believe your statements are accurate: the only thing 6TSCH is interested about is how to make the 6LoWPAN LLN work when using IEEE802.15.4e at the MAC layer, using nothing but IEEE and IETF standards.
>
> The architecture we are targetting is shown in [1], i.e.:
> - one or more LLNs, each connected to a backbone router (BBR)
> - BBRs are connected through a backbone
> - optionally a PCE sits on the backbone and drives the LLNs' TSCH schedules.
> - when a packet goes from one LLN to another over the backbone, ideally, we want the deterministic nature of the transmission to remain on the backbone. So if there is some easy mapping between deterministic TSCH flows and deterministic "backbone" flows (e.g. IEEE802.1TSN), that would be great.
> - I agree that the obvious choice is to map DSCPs into TSCH flow priorities.
>
> As for the term "RSVP", it might be a big word for our little group :) What we are talking about it to use some distributed multi-hop resource reservation protocol within the TSCH LLN to reserve TSCH cells.
>
> I hope this makes sense,
> Thomas
>
>
> [1] http://tools.ietf.org/html/draft-thubert-6tsch-architecture-00#page-5
>
> On Wed, Mar 13, 2013 at 12:31 PM, Carsten Bormann > wrote:
>
>     So, my take of the discussion we just had:
>
>     -- This is focused on the 6LoWPAN and the TSCH configuration within that
>     -- Packets will also need to make one IP hop outside the 6LoWPAN, let's call that the backbone
>     -- The backbone could be 802.1TSN style (~ Ethernet)
>     -- Setting the DSCP to ~ EF, doing the admission control for that, and possibly some 802.1TSN setup, is mostly all that we need in the backbone
>
>     That would simplify things by taking RSVP out of the picture and taking more of a diffserv approach.
>
>     Grüße, Carsten
>
>     _______________________________________________
>     6tsch mailing list
>     6tsch@ietf.org 
>     https://www.ietf.org/mailman/listinfo/6tsch
>
>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>

From paul.chilton@nxp.com  Thu Mar 14 05:02:33 2013
Return-Path: 
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 4681C21F8D35 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 05:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1]
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 1gS1NlU5IZaF for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 05:02:32 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 375D721F8AD8 for <6tsch@ietf.org>; Thu, 14 Mar 2013 05:02:28 -0700 (PDT)
Received: from mail17-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE011.bigfish.com (10.3.207.133) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Mar 2013 12:02:28 +0000
Received: from mail17-am1 (localhost [127.0.0.1])	by mail17-am1-R.bigfish.com (Postfix) with ESMTP id 2806E40008F; Thu, 14 Mar 2013 12:02:15 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.165; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0411HT003.eurprd04.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -31
X-BigFish: PS-31(zzbb2dI98dI9371Ic89bh542Iec9N1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h)
Received: from mail17-am1 (localhost.localdomain [127.0.0.1]) by mail17-am1 (MessageSwitch) id 1363262533160998_17259; Thu, 14 Mar 2013 12:02:13 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.253])	by mail17-am1.bigfish.com (Postfix) with ESMTP id 0C48A3603BE; Thu, 14 Mar 2013 12:02:13 +0000 (UTC)
Received: from AM2PRD0411HT003.eurprd04.prod.outlook.com (157.56.249.165) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Mar 2013 12:02:10 +0000
Received: from AM2PRD0411MB434.eurprd04.prod.outlook.com ([169.254.1.186]) by AM2PRD0411HT003.eurprd04.prod.outlook.com ([10.255.163.38]) with mapi id 14.16.0275.006; Thu, 14 Mar 2013 12:02:09 +0000
From: Paul Chilton 
To: IETF 6TSCH <6tsch@ietf.org>
Thread-Topic: [6tsch] Scope: 6LoWPAN + 1
Thread-Index: AQHOIKeNXp+oJ3AYbk21Fcrcq0RVeZilEQew
Date: Thu, 14 Mar 2013 12:02:08 +0000
Message-ID: <2FB32E34ED32C44A8D9BCC2E880875E326C0D4A3@AM2PRD0411MB434.eurprd04.prod.outlook.com>
References: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>  <5141B51E.3050603@tanu.org>
In-Reply-To: <5141B51E.3050603@tanu.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.129.70.222]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
Cc: Shoichi Sakane 
Subject: Re: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 12:02:33 -0000

Following on from this question:=20
Just to clarify - is the sense of the sentence that "there may or may not b=
e a PCE in the system" or that "the PCE must be present but can be placed o=
n the backbone or elsewhere"?

Am I correct in thinking that if there isn't a PCE in the system then there=
 will be no hard links allocated, and that all the links will be soft links=
, and the slot allocation will be performed by a decentralised scheme with =
the routing layer requesting bandwidth over a route between endpoints?

How will multicast traffic work without a PCE?  I am assuming that the syst=
em needs to allocate slots for the use of multicast groups within the lln -=
 is that correct?  If that is the case, then is it intended that the routin=
g layer can allocate multicast slots as well as dedicated soft links for DA=
G and p2p routes

Apologies if the terminology doesn't match whats in the terminology draft -=
 still thinking in 4e-land

Paul

-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of S=
hoichi Sakane
Sent: 14 March 2013 07:32
To: IETF 6TSCH
Subject: Re: [6tsch] Scope: 6LoWPAN + 1

Hi,

I am trying to understand the architecture accurately.  Let me ask one thin=
g.

> The architecture we are targetting is shown in [1], i.e.:
> - optionally a PCE sits on the backbone and drives the LLNs' TSCH schedul=
es.

If a PCE is option, who coordinates the LLNs' TSCH ? Is it by BBRs ?
Do you assume that each BBR negotiates something TSCH parameters with other=
 in order to make a logical PCE on the BBRs ?

I guess a PCE is option only when a single LLN that doesn't need to exchang=
e packets with other LLNs and the BBR has a function of PCE.  Correct ?

Shoichi

On 3/14/13 7:01 AM, Thomas Watteyne wrote:
> Carsten,
>
> Thank you for the summary. I believe your statements are accurate: the on=
ly thing 6TSCH is interested about is how to make the 6LoWPAN LLN work when=
 using IEEE802.15.4e at the MAC layer, using nothing but IEEE and IETF stan=
dards.
>
> The architecture we are targetting is shown in [1], i.e.:
> - one or more LLNs, each connected to a backbone router (BBR)
> - BBRs are connected through a backbone
> - optionally a PCE sits on the backbone and drives the LLNs' TSCH schedul=
es.
> - when a packet goes from one LLN to another over the backbone, ideally, =
we want the deterministic nature of the transmission to remain on the backb=
one. So if there is some easy mapping between deterministic TSCH flows and =
deterministic "backbone" flows (e.g. IEEE802.1TSN), that would be great.
> - I agree that the obvious choice is to map DSCPs into TSCH flow prioriti=
es.
>
> As for the term "RSVP", it might be a big word for our little group :) Wh=
at we are talking about it to use some distributed multi-hop resource reser=
vation protocol within the TSCH LLN to reserve TSCH cells.
>
> I hope this makes sense,
> Thomas
>
>
> [1] http://tools.ietf.org/html/draft-thubert-6tsch-architecture-00#page-5
>
> On Wed, Mar 13, 2013 at 12:31 PM, Carsten Bormann > wrote:
>
>     So, my take of the discussion we just had:
>
>     -- This is focused on the 6LoWPAN and the TSCH configuration within t=
hat
>     -- Packets will also need to make one IP hop outside the 6LoWPAN, let=
's call that the backbone
>     -- The backbone could be 802.1TSN style (~ Ethernet)
>     -- Setting the DSCP to ~ EF, doing the admission control for that, an=
d possibly some 802.1TSN setup, is mostly all that we need in the backbone
>
>     That would simplify things by taking RSVP out of the picture and taki=
ng more of a diffserv approach.
>
>     Gr=FC=DFe, Carsten
>
>     _______________________________________________
>     6tsch mailing list
>     6tsch@ietf.org 
>     https://www.ietf.org/mailman/listinfo/6tsch
>
>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch



From sakane@tanu.org  Thu Mar 14 05:39:21 2013
Return-Path: 
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 B572111E80F6 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 05:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.876
X-Spam-Level: *
X-Spam-Status: No, score=1.876 tagged_above=-999 required=5 tests=[HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265]
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 9udndZzZT2TH for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 05:39:21 -0700 (PDT)
Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by ietfa.amsl.com (Postfix) with ESMTP id 30DA811E80EE for <6tsch@ietf.org>; Thu, 14 Mar 2013 05:39:21 -0700 (PDT)
Received: from mactanu.local (dhcp-168c.meeting.ietf.org [130.129.22.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id A6B8E16E70 for <6tsch@ietf.org>; Thu, 14 Mar 2013 21:39:19 +0900 (JST)
Message-ID: <5141C4F5.8040202@tanu.org>
Date: Thu, 14 Mar 2013 21:39:17 +0900
From: Shoichi Sakane 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: IETF 6TSCH <6tsch@ietf.org>
References: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>  <5141B51E.3050603@tanu.org> <2FB32E34ED32C44A8D9BCC2E880875E326C0D4A3@AM2PRD0411MB434.eurprd04.prod.outlook.com>
In-Reply-To: <2FB32E34ED32C44A8D9BCC2E880875E326C0D4A3@AM2PRD0411MB434.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 12:39:21 -0000

On 3/14/13 9:02 PM, Paul Chilton wrote:
>>- optionally a PCE sits on the backbone and drives the LLNs' TSCH schedules.

Ah, maybe understood.  It doesn't say that existence of PCE is optional.  It says that it's optional to put PCE in the backbone.  It doesn't preclude to put it on BBR.  Correct ?

Shoichi

From xvilajosana@eecs.berkeley.edu  Thu Mar 14 07:55:08 2013
Return-Path: 
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 DF0941F0D11 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 07:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 jClFtAYcQZjz for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 07:55:07 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 03F8511E81AB for <6tsch@ietf.org>; Thu, 14 Mar 2013 07:55:07 -0700 (PDT)
Received: from c-67-188-198-243.hsd1.ca.comcast.net ([67.188.198.243] helo=[192.168.2.9]) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UG9Yd-0000sU-LQ; Thu, 14 Mar 2013 07:55:06 -0700
Message-ID: <5141E4C2.7040502@eecs.berkeley.edu>
Date: Thu, 14 Mar 2013 07:54:58 -0700
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Michael Richardson 
References:  <19015.1362797728@sandelman.ca>  <1953.1363034941@sandelman.ca> <513E489B.6070306@eecs.berkeley.edu> <7841.1363104356@sandelman.ca> <513F95B8.7000408@eecs.berkeley.edu> <6111.1363229554@sandelman.ca>
In-Reply-To: <6111.1363229554@sandelman.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] how to handle different classes of traffic
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 14:55:09 -0000

Hi Michael,

> Do slotframes go to one destination or many? (I'm not including 
> multicast here) 
If you look to a particular node, its slotframe can have several entries 
already allocated and pointing to one or more destinations (so 
destinations can be many and this many destinations for a particular 
node are its neighbors (1hop))

However, when you look at the slotframe from the point of view of the 
network (i.e overlapping all slotframes of all nodes in the network) you 
have a map of what it is happening in general to the network, the 
resulting slotframe (overlap of all nodes slotframe) can have some cells 
(the same one) that are allocated to different nodes that cannot heard 
each other and thus can transmit simultaneously. However this 
overlapping tends to be sparse as the slotframe size is big compared to 
the required traffic.
The allocation of the cells to the slotframe is done by a PCE or by a 
distributed approach at each node.

hope this is more clear now.

regards
Xavi

From qinwang@berkeley.edu  Thu Mar 14 09:27:45 2013
Return-Path: 
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 F3D1211E80F2 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 09:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 44RqDh+LRlUW for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 09:27:44 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0CC11E80B8 for <6tsch@ietf.org>; Thu, 14 Mar 2013 09:27:44 -0700 (PDT)
Received: from cm04ws.ist.berkeley.edu ([169.229.218.166] helo=calmail.berkeley.edu) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UGB0H-0003rJ-6B; Thu, 14 Mar 2013 09:27:43 -0700
Received: from 174.240.7.135 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Thu, 14 Mar 2013 09:27:42 -0700
Message-ID: <3f5fc7a67dd46651bb8b05da1720f86b.squirrel@calmail.berkeley.edu>
In-Reply-To: <5141C4F5.8040202@tanu.org>
References: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>  <5141B51E.3050603@tanu.org> <2FB32E34ED32C44A8D9BCC2E880875E326C0D4A3@AM2PRD0411MB434.eurprd04.prod.outlook.com> <5141C4F5.8040202@tanu.org>
Date: Thu, 14 Mar 2013 09:27:42 -0700
From: "Qin Wang" 
To: "Shoichi Sakane" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 16:27:45 -0000

Hi Shoichi and all,

My understanding is as follows.

(1) The networks which we are talking about could include one LLN or
multiple LLNs connected by backbone. PCE is a optional device in the
networks.

(2) If there is PCE, there may be different setting. For example, PCE is
in charge for reserving both multiple hop path (i.e. every next hop
neighbor) and cells; or PCE is just in charge for reserving the multiple
hop path and leaving cell reservation to local, and the distributed cell
reservation will meet the bandwidth requirement from multiple hop path
reservation. In the first case, hard cell reservation will be used.

(3)If there is no PCE, both multihop path and cells are reserved in local.
For example, RPL + soft cell reservation in 6tus.

Does it make sense?

Qin


> On 3/14/13 9:02 PM, Paul Chilton wrote:
>>>- optionally a PCE sits on the backbone and drives the LLNs' TSCH
>>> schedules.
>
> Ah, maybe understood.  It doesn't say that existence of PCE is optional.
> It says that it's optional to put PCE in the backbone.  It doesn't
> preclude to put it on BBR.  Correct ?
>
> Shoichi
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


From pister@eecs.berkeley.edu  Thu Mar 14 11:20:43 2013
Return-Path: 
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 D952C11E81E6 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 11:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 01hkyFzrJXNY for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 11:20:43 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1500C11E81A3 for <6tsch@ietf.org>; Thu, 14 Mar 2013 11:20:43 -0700 (PDT)
Received: from dhcp-32-89.eecs.berkeley.edu ([128.32.32.89]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1UGCld-0008IM-E6; Thu, 14 Mar 2013 11:20:42 -0700
Message-ID: <514214FC.9090304@eecs.berkeley.edu>
Date: Thu, 14 Mar 2013 11:20:44 -0700
From: Kris Pister 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Maria Rita PALATTELLA 
References:  <513DFE69.9030908@eecs.berkeley.edu> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090006000805040407060507"
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] terminology-draft posted
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 18:20:44 -0000

This is a multi-part message in MIME format.
--------------090006000805040407060507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 3/12/2013 12:34 AM, Maria Rita PALATTELLA wrote:
>
> Kris, thanks for having gone through it already, and for providing 
> some comments/corrections.
>
> First, I think we will talk about SLOTFRAME (as specified in 15.4e 
> TSCH std. ) and not superframe. Do you agree with me?
>
Yes - my mistake.

ksjp
>
> Second, are the cells defined by slotframe ID or slotframe LENGTH (or 
> both)?
>
> Thanks for your help.
>
> Maria Rita
>
> *From:*6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On 
> Behalf Of *Kris Pister
> *Sent:* Monday, March 11, 2013 4:55 PM
> *To:* 6tsch@ietf.org
> *Subject:* Re: [6tsch] terminology-draft posted
>
> That's very helpful.
>
> A couple of nits:
>
> cell - "a single element in the TSCH schedule" should be "a single 
> element in a TSCH superframe".  Cells are not defined just by slot and 
> channel offset, but also by superframe length.
>
> SlotOffset - "in the TSCH schedule" should be "in a TSCH superframe"
>
> ksjp
>
> On 3/11/2013 3:21 AM, Maria Rita PALATTELLA wrote:
>
>     All,
>
>     You can find version 00 of the 6tsch-terminology draft at
>     http://www.ietf.org/internet-drafts/draft-palattella-6tsch-terminology-00.txt .
>
>     Best Regards,
>
>     Maria Rita
>
>
>
>
>     _______________________________________________
>
>     6tsch mailing list
>
>     6tsch@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/6tsch
>


--------------090006000805040407060507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 3/12/2013 12:34 AM, Maria Rita
      PALATTELLA wrote:

    

    

      
      
      
      

        
Kris, thanks
            for having gone through it already, and for providing some
            comments/corrections.

        
First, I think
            we will talk about SLOTFRAME (as specified in 15.4e TSCH
            std. ) and not superframe. Do you agree with me?

      

    

    Yes - my mistake.

    

    ksjp

    

      

        

        
Second, are the
            cells defined by slotframe ID or slotframe LENGTH (or both)?

        
Thanks for your
            help.

        
Maria Rita

        
 

        

          

            
From:
                6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org]
                On Behalf Of Kris Pister

                Sent: Monday, March 11, 2013 4:55 PM

                To: 6tsch@ietf.org

                Subject: Re: [6tsch] terminology-draft posted

          

        

        
 

        
That's very
          helpful.

          

          A couple of nits:

          

          cell - "a single element in the TSCH schedule" should be "a
          single element in a TSCH superframe".  Cells are not defined
          just by slot and channel offset, but also by superframe
          length.

          

          SlotOffset - "in the TSCH schedule" should be "in a TSCH
          superframe"

          

          ksjp

        

          
On 3/11/2013 3:21 AM, Maria Rita
            PALATTELLA wrote:

        

        

          
All,

          
 

          
You can
              find version 00 of the 6tsch-terminology draft at
             http://www.ietf.org/internet-drafts/draft-palattella-6tsch-terminology-00.txt .

          
 

          
Best
              Regards,

          
 

          
Maria Rita

          
 

          


              

              

              

          
_______________________________________________

          
6tsch mailing list

          
6tsch@ietf.org

          
https://www.ietf.org/mailman/listinfo/6tsch

        

        
 

      

    

    

  


--------------090006000805040407060507--

From pthubert@cisco.com  Thu Mar 14 11:25:22 2013
Return-Path: 
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 0C4CE21F8ED4 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 11:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 P1Gp1N+NAKuf for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 11:25:21 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFAD21F8ED5 for <6tsch@ietf.org>; Thu, 14 Mar 2013 11:25:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1299; q=dns/txt; s=iport; t=1363285521; x=1364495121; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/VnHfpumCEPEhbZTcz2WqnPkY/Wi+qkffKjLE87DGds=; b=jT9u0XvZBscby12ct2G0H4FFTctCdr/o0LFm6GiXff9lpB07NNTCJjjr QRjN//qL5TCWwtUi/9BjjGNoqMtRA2T6u8WwTB0dhJK0bfz+7thJQYGjH nX5ttuWMKwrRR8TTT8K56W2u5V1lDGxRKjyNGo19OllALWsiV+DHZtlWW 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFANoUQlGtJXHA/2dsb2JhbABDDsR0gWUWdIIrAQEBBDo/DAQCAQgRBAEBCxQJBzIUCQgCBAENBQiIDMIOjmUmCwcGgllhA6dagks/gig
X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="187347817"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 14 Mar 2013 18:25:21 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2EIPLwE015588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 18:25:21 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 13:25:20 -0500
From: "Pascal Thubert (pthubert)" 
To: Michael Richardson , Xavier Vilajosana 
Thread-Topic: [6tsch] how to handle different classes of traffic
Thread-Index: AQHOIGd9pbqVtKa0EkKRoMmLbP7HmZilf9RA
Date: Thu, 14 Mar 2013 18:25:20 +0000
Deferred-Delivery: Thu, 14 Mar 2013 18:25:00 +0000
Message-ID: 
References:  <19015.1362797728@sandelman.ca>  <1953.1363034941@sandelman.ca> <513E489B.6070306@eecs.berkeley.edu> <7841.1363104356@sandelman.ca> <513F95B8.7000408@eecs.berkeley.edu> <6111.1363229554@sandelman.ca>
In-Reply-To: <6111.1363229554@sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.91.169]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] how to handle different classes of traffic
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 18:25:22 -0000

Hi Michael:

A particular cell in the slotframe may be reserved for a particular point t=
o point flow (e.g. a control loop). In that case, the cell is equivalent to=
 an MPLS label in that the sequence of cells is programmed (we call that a =
track) along the (multihop) path between Alice and Bob and only leads to Bo=
b. Other cells are used for QoS based traffic and thus the utilization depe=
nds on statistically muxed IP traffic between multiple pairs of endpoint th=
at is routed over the link between the sender and receiver routers on that =
cell.

Was that your question?

Pascal


-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of M=
ichael Richardson
Sent: mercredi 13 mars 2013 22:53
To: Xavier Vilajosana
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] how to handle different classes of traffic


>>>>> "Xavier" =3D=3D Xavier Vilajosana  wri=
tes:

    Xavier> a slotframe is a collection of slots (namely "A MAC-level
    Xavier> abstraction that is internal to the node and contains a
    Xavier> series of timeslots of equal length and priority."

Do slotframes go to one destination or many?  (I'm not including multicast =
here)

--
Michael Richardson
-on the road-



From pascal.thubert@gmail.com  Thu Mar 14 13:04:08 2013
Return-Path: 
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 9FEDB11E80D7 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 13:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 1BECfiocholf for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 13:04:07 -0700 (PDT)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8E55711E8158 for <6tsch@ietf.org>; Thu, 14 Mar 2013 13:04:07 -0700 (PDT)
Received: by mail-lb0-f169.google.com with SMTP id m4so2216783lbo.14 for <6tsch@ietf.org>; Thu, 14 Mar 2013 13:04:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RbeKccYc+s78CE2UvmwCsLmTO63QhBor//wKfpAq9Bw=; b=X8lxEsKufaEtI6kcVaKg2Q4Ihv35+mTGz6Q7aC85xpBYCuCC4Q3qa66A8CWmWA1HA/ ShZzbWGmrzSie6o0Aq7VPA2dRFpBpUmzZnCjLmFubG+D+7uJIktDwBCrn50lH/kw/NSm y17Ot/a+NxAmTBHlNPOgjmZ9mCT0N0JjYrvvorMCnk0f1sxHqQouMGQI/bRcZu7p0Ybn TcyUfAxAxbn8mh5pa5or8MGL/UJLpk6Q52MWFUsHBRYfr2P10AwEMmd7py4EIVSE0Vht NTgQvIyfOHIoETw1Vc00gorj7xEBIfcFDhoKGw90rzi0/sJO+0FqwxWaoHrPT38Xr8a0 mxfg==
MIME-Version: 1.0
X-Received: by 10.112.49.35 with SMTP id r3mr1631155lbn.95.1363291446503; Thu, 14 Mar 2013 13:04:06 -0700 (PDT)
Received: by 10.112.27.39 with HTTP; Thu, 14 Mar 2013 13:04:06 -0700 (PDT)
In-Reply-To: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>
Date: Thu, 14 Mar 2013 16:04:06 -0400
Message-ID: 
From: Pascal Thubert 
To: JeongGil Ko 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 20:04:08 -0000

'lo John,

I think that the contender is NSIS. We have to figure which is best
suited. We have to be able to express in a dense fashion the bandwidth
and teh jitter/latency budget that we have. At each hop, the
reservation message must trigger an operation at the 6TUS layer to
negotiate the cell(s) allocation with the next hop.

At the calls we discussed and agreed that this allocation should be
done in such a way that 6TUS should not know or care whether the
reservation is done between A and B along a RPL route, or controller
by the PCE. Also, we agreed that the PCE should only need to talk to A
in order to establish a cell between A and B, so as to limit the
expenses in control. We have to see how that maps into the pcep
model...

Cheers,

Pascal

2013/3/13 JeongGil Ko :
> Hi all,
>
> I would like to start the discussion on what potential schemes can be used to reserve slot/bandwidth resources in an LLN on TSCH.
>
> One scheme popping of the top of anyone's mind would be a simple form of RSVP but I think its meaningful to open up the discussions to many standardized schemes and perform a short survey on the pros and cons of each scheme.
>
> Please start your discussions on this topic so we can start organizing the schemes.
>
> Thanks!
>
> -John
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch



-- 
Pascal

From sakane@tanu.org  Thu Mar 14 13:46:58 2013
Return-Path: 
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 526F711E81B2 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 13:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.576
X-Spam-Level: 
X-Spam-Status: No, score=0.576 tagged_above=-999 required=5 tests=[AWL=1.299,  BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265]
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 z+P6K76p3keP for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 13:46:57 -0700 (PDT)
Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by ietfa.amsl.com (Postfix) with ESMTP id A6AD711E814D for <6tsch@ietf.org>; Thu, 14 Mar 2013 13:46:57 -0700 (PDT)
Received: from mactanu.local (dhcp-168c.meeting.ietf.org [130.129.22.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id A3AB116BA0 for <6tsch@ietf.org>; Fri, 15 Mar 2013 05:46:56 +0900 (JST)
Message-ID: <5142373D.9090501@tanu.org>
Date: Fri, 15 Mar 2013 05:46:53 +0900
From: Shoichi Sakane 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: IETF 6TSCH <6tsch@ietf.org>
References: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>  <5141B51E.3050603@tanu.org> <2FB32E34ED32C44A8D9BCC2E880875E326C0D4A3@AM2PRD0411MB434.eurprd04.prod.outlook.com> <5141C4F5.8040202@tanu.org> <3f5fc7a67dd46651bb8b05da1720f86b.squirrel@calmail.berkeley.edu>
In-Reply-To: <3f5fc7a67dd46651bb8b05da1720f86b.squirrel@calmail.berkeley.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 20:46:58 -0000

Hi Qin,

Very clear.  Thanks!

Shoichi

On 3/15/13 1:27 AM, Qin Wang wrote:
> Hi Shoichi and all,
>
> My understanding is as follows.
>
> (1) The networks which we are talking about could include one LLN or
> multiple LLNs connected by backbone. PCE is a optional device in the
> networks.
>
> (2) If there is PCE, there may be different setting. For example, PCE is
> in charge for reserving both multiple hop path (i.e. every next hop
> neighbor) and cells; or PCE is just in charge for reserving the multiple
> hop path and leaving cell reservation to local, and the distributed cell
> reservation will meet the bandwidth requirement from multiple hop path
> reservation. In the first case, hard cell reservation will be used.
>
> (3)If there is no PCE, both multihop path and cells are reserved in local.
> For example, RPL + soft cell reservation in 6tus.
>
> Does it make sense?
>
> Qin
>
>
>> On 3/14/13 9:02 PM, Paul Chilton wrote:
>>>> - optionally a PCE sits on the backbone and drives the LLNs' TSCH
>>>> schedules.
>>
>> Ah, maybe understood.  It doesn't say that existence of PCE is optional.
>> It says that it's optional to put PCE in the backbone.  It doesn't
>> preclude to put it on BBR.  Correct ?
>>
>> Shoichi
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>

From cabo@tzi.org  Thu Mar 14 14:02:03 2013
Return-Path: 
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 8A7C811E8210 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 14:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.85
X-Spam-Level: 
X-Spam-Status: No, score=-105.85 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 ylucp+vRNG5G for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 14:02:02 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 74BE511E820F for <6tsch@ietf.org>; Thu, 14 Mar 2013 14:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2EL1x4B001399; Thu, 14 Mar 2013 22:01:59 +0100 (CET)
Received: from dhcp-9032.meeting.ietf.org (dhcp-9032.meeting.ietf.org [130.129.8.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 33650376C; Thu, 14 Mar 2013 22:01:59 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Thu, 14 Mar 2013 17:01:56 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com> 
To: Pascal Thubert 
X-Mailer: Apple Mail (2.1499)
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 21:02:03 -0000

On Mar 14, 2013, at 16:04, Pascal Thubert  =
wrote:

> NSIS

http://nsis-ka.org says:

GIST: 32,858 LOC
NSIS: 67,193 LOC

Gr=FC=DFe, Carsten


From qinwang@berkeley.edu  Thu Mar 14 14:57:31 2013
Return-Path: 
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 C91A91F0D0F for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 14:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 82Ix6yP9LZJy for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 14:57:31 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFD11F0D09 for <6tsch@ietf.org>; Thu, 14 Mar 2013 14:57:31 -0700 (PDT)
Received: from cm03ws.ist.berkeley.edu ([169.229.218.165] helo=calmail.berkeley.edu) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UGG9P-0006VJ-5u; Thu, 14 Mar 2013 14:57:30 -0700
Received: from 136.152.37.197 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Thu, 14 Mar 2013 14:57:27 -0700
Message-ID: 
In-Reply-To: 
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>  
Date: Thu, 14 Mar 2013 14:57:27 -0700
From: "Qin Wang" 
To: "Carsten Bormann" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: Pascal Thubert , IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 21:57:31 -0000

Hi all,

This may be a silly question: why we investigate various resource
reservation protocols? Do we want to bind 6tus with some resource
reservation protocol, or try to figure out the mandatory functionality
6tus must provides by investigating those protocols?

Thanks
Qin


> On Mar 14, 2013, at 16:04, Pascal Thubert 
> wrote:
>
>> NSIS
>
> http://nsis-ka.org says:
>
> GIST: 32,858 LOC
> NSIS: 67,193 LOC
>
> Grüße, Carsten
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From xvilajosana@eecs.berkeley.edu  Thu Mar 14 15:02:08 2013
Return-Path: 
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 550A61F0D1E for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 15:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 E8FPi8rNDxvc for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 15:02:07 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id B5F991F0D1B for <6tsch@ietf.org>; Thu, 14 Mar 2013 15:02:07 -0700 (PDT)
Received: from c-67-188-198-243.hsd1.ca.comcast.net ([67.188.198.243] helo=[192.168.2.9]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UGGDu-0002IT-5O for 6tsch@ietf.org; Thu, 14 Mar 2013 15:02:07 -0700
Message-ID: <514248DA.6090403@eecs.berkeley.edu>
Date: Thu, 14 Mar 2013 15:02:02 -0700
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: 6tsch@ietf.org
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>   
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 22:02:08 -0000

Qin, I think that we need a protocol that is in charge of managing 
tracks, allocating bandwidth along the track,  monitor that the end to 
end bandwidth requirement is really accomplished, etc..

this is my point.. maybe others can add more reasons..

X

On 14/03/13 14:57, Qin Wang wrote:
> Hi all,
>
> This may be a silly question: why we investigate various resource
> reservation protocols? Do we want to bind 6tus with some resource
> reservation protocol, or try to figure out the mandatory functionality
> 6tus must provides by investigating those protocols?
>
> Thanks
> Qin
>
>
>> On Mar 14, 2013, at 16:04, Pascal Thubert 
>> wrote:
>>
>>> NSIS
>> http://nsis-ka.org says:
>>
>> GIST: 32,858 LOC
>> NSIS: 67,193 LOC
>>
>> Grüße, Carsten
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


From qinwang@berkeley.edu  Thu Mar 14 17:39:24 2013
Return-Path: 
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 6342911E810E for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 17:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 jf8ZRhS6RWo8 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 17:39:23 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id BC28611E80D9 for <6tsch@ietf.org>; Thu, 14 Mar 2013 17:39:23 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UGIg6-0001SH-KN for 6tsch@ietf.org; Thu, 14 Mar 2013 17:39:23 -0700
Received: from 136.152.37.197 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Thu, 14 Mar 2013 17:39:22 -0700
Message-ID: <90d5facfcd961deffd839ef420ec84c0.squirrel@calmail.berkeley.edu>
Date: Thu, 14 Mar 2013 17:39:22 -0700
From: "Qin Wang" 
To: "IETF 6TSCH" <6tsch@ietf.org>
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: [6tsch] attributes of data traffic flow
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 00:39:24 -0000

Hi all,

In the previous emails, there are several threads related with data
traffic flow or data flow. I think it is important to put them together
and see if there is missing pieces.

Attributes of data flow:

(1) Periodicity (T): a integer, T=0 means bursty,  T>0 means the timeslots
in one cycle.

(2) Bandwidth requirement: number of slots in one cycle if T>0; number of
frames in one burst if T=0.

(3) Jitters sensitivity : if the data flow is periodical (T >0), then it
reflects the deterministic requirement. if the data flow is bursty (T=0),
then it reflects the end-to-end latency requirement of the data flow.

(4)Reliability: e.g. one-hop Data Delivery Rate (PDR)

Anything else?

In addition, I think "priority of data flow" is function of these basic
attributes, maybe more. Make sense?

Qin




From twatteyne@gmail.com  Thu Mar 14 20:12:32 2013
Return-Path: 
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 05E6A11E81A8 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 20:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 lHQ6udhOoQEq for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 20:12:30 -0700 (PDT)
Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3D86011E819B for <6tsch@ietf.org>; Thu, 14 Mar 2013 20:12:30 -0700 (PDT)
Received: by mail-pb0-f52.google.com with SMTP id ma3so3174976pbc.39 for <6tsch@ietf.org>; Thu, 14 Mar 2013 20:12:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=revz/PuutFPAfboE4L8YgZkREGYwtoYOVmDv6SZwFk8=; b=Ujt/23JhGrxotxAM2lgHWBLsAE8xUXqL7vVKXf9XYbbbYKKs4NJfZHFBNEZEIJVf8Q 35LxSYPyrWH9xFmaMwgnuc+7HF1dvuVDUlXGT24xAzfvqrH34YYZaMdAjKdXKfRxtdLR M7ZYWF7/Q/Y71xcuRlXzTTJbBSTudjxoSVBwzRSNd14NqjQhMK2Hegq0VSkN5uUneAhy ty5khnw3dgD1/Hmqj+kkRAZU+MUGyjpyxJr53hYhKayY3NGmdsFoMo8FDSb6z4R/Y/h+ jDOEtIzhFnDvNUzcZHNIu3GFw5alD0joOCpHWTV447ZHGsJZfE0y9tMKxGzOHTcadl/W y7YA==
MIME-Version: 1.0
X-Received: by 10.68.227.202 with SMTP id sc10mr11811501pbc.109.1363317149858;  Thu, 14 Mar 2013 20:12:29 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Thu, 14 Mar 2013 20:12:29 -0700 (PDT)
Date: Thu, 14 Mar 2013 20:12:29 -0700
X-Google-Sender-Auth: liVVAe2TeWfe0FK0UEOWpaLM7Yw
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b2eda156f068604d7ee02c5
Subject: [6tsch] minutes IETF 86 Wednesday meeting
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 03:12:32 -0000

--047d7b2eda156f068604d7ee02c5
Content-Type: text/plain; charset=ISO-8859-1

All,

Thanks for Dominique and Xavi for taking notes at yesterday's 6TSCH
meeting. You'll find the at https://bitbucket.org/6tsch/ietf86-orlando/src.

For convenience, I also copy-pasted them below.

Thomas

---

Minutes 6TSCH Wednesday meeting
IETF 86 Orlando
03/13/2013 11.30-13.00 Boca 2

[slides available at https://bitbucket.org/6tsch/ietf86-orlando/src/]

Notes taken by:
- Dominique Barthel
- Xavi Vilajosana

(15 people in the room)

=== Introduction ===

[Thomas] Today is technical discussion.
6TSCH is not a WG, so no IETF home page, instead repositories at
https://bitbucket.org/6tsch/.
Agenda: presentationsof 6 drafts, followed by discussion on 4 on-going
topics.

=== draft-ietf-roll-rpl-industrial-applicability-00 ===

Draft Title: RPL Applicability in Industrial Networks
URL:
http://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability-00
Presented by: Pascal Thubert

Draft written for the ROLL working group, used as starting point
requirements for 6TSCH.
Same slides as presented at ROLL WG meeting.
We need a common draft to collect the goals. This can be in RPL industrial
context.
In 6TSCH, mixing paths computed on PCE and paths computed in a distributed
fashion by RPL. Not in this draft.
Today there is no definition yet of how to achieve deterministic tracks
that go beyond the wireless to the backbone.
Need another draft to explain how WirelessHART, ISA100.11a and 6TSCH
networks can co-exist.

Q: are we mixing RPL storing and non-storing modes?
A [Pascal]: No, 6TSCH will not be changing RPL.

=== draft-palattella-6tsch-terminology-00 ===

Draft Title: Terminology in IPv6 over Time Slotted Channel Hopping
URL: http://tools.ietf.org/html/draft-palattella-6tsch-terminology-00
Presented by: Thomas Watteyne

Draft was published yesterday.
Goal is to capture terminology, clarify name conflicts between IEEE and
IETF.
Some terms from 15.4e were colliding with IETF terms, e.g. link and path.
Next step is to capture new terms as they appear on the mailing list and in
the drafts.

[Pascal]: includes by reference terminology drafts by other groups (ROLL,
autoconf)

=== draft-thubert-6tsch-architecture-00 ===

Draft Title: An Architecture for IPv6 over Time Synchronized Channel Hopping
URL: http://tools.ietf.org/html/draft-thubert-6tsch-architecture-00
Presented by: Pascal Thubert

Draft was supposed to be written at ROLL but never was.
Goal: How to put together RPL/PANA/6LoWPAN/
E.g. tuning to use RPL, how we do DAD.
-00 published yesterday.
Scope of work is in the (current) draft.
The draft will progress as the group progresses.
Inside is the LLN, functionality of the BBR that connects the LLN and the
BB. Exchange between the wireless world and the PCE.
Needs help from PANA experts.

Q [Pascal]: we need help for the PANA section. Yoshihiro Ohba offered to
help with that.
A [Yoshihiro Ohba]: yes.

Will have to decide which protocol to use to reserve bandwith along
multi-hop paths, candidates are RSVP, NSIS.
Items on the "to discuss" list are the ones on the agenda for the second
part of this meeting.

=== draft-watteyne-6tsch-tsch-lln-context-01 ===

Draft Title: Using IEEE802.15.4e TSCH in an LLN context: Overview, Problem
Statement and Goals
URL: http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01
Presented by: Thomas Watteyne

Overview, problem statement and goals.
version -01 draft.
This draft states what TSCH does *not* do, hence what 6TSCH should provide
as a complement.
Appendix A contains highlights of TSCH, appendix B contains further
comments that are not explicit in the TSCH standard.
ToC and 2 appendix that deal with TSCH protocol highlights. Section 3
presents the problems.
Thomas delivers a 5min tutorial on TSCH.
15.4e is a MAC-only amendement, that runs in 15.4 radios. Enables
deterministic communications. Typically 10ms cell. Channel hopping
mitigates multipath. Inside the schedule all cells are empty and can be
allocated. Building the schedule is the challenge. It enables a clear
trade-off between BW, Latency, redundancy vs energy-consumption. The more
cell scheduled, the more energy consumption. Duty cycle is <1% if you don't
have a very full schedule.
Each cell does 1 out of 4 possible things: Sleep, transmit, receive, same
with no ACK
The IEEE802.15.4e TSCH standard describes the mechanics to execute a
schedule, not how one builds a schedule.
The draft describes nine problems to be solved. Thomas talks us through
four of them. Network formation. How to send EBs? Network maintenance: how
to select time source neighbors?  Resource management: how to deal with
links/cells, how to schedule cells? how to match the number of links to
bandwidth. Dataflow control: a queueing policy. how to deal with the
policies of packets and flows.
Next: align terminology with "terminology" draft, include goals.

Q (JeongGil Ko, ETRI, Korea): Looks like we want to do something like RSVP
for TSCH. How protocol-specific are we? Fine-tuning for RPL? Providing
general consideration on various possibilities?
A [Thomas]: we want to be generic but we want to cover all the possible
scenarios.
A [Pascal]: we assume we use RPL. We'll decide if we use RSVP or something
else. We'll explain how we use these.

Q [Carsten]: what does multi-hop mean? within a 6LoWPAN or though various
heterogeneous links.
A [Pascal]: multi-hop within 6LoWPAN. But also verify behavior
(determinism) across several networks, see presentation on 802.1Q on
Tuesday.

Q [Carsten]: more than setting DSCP?
A [Pascal]: yes. RSVP at layer 3. Not through the general Internet, only
through controlled backbone.

Q [Carsten]: what about patents in this landscape? Open implementation ever?
A [Pascal]: same techniques already deployed in ISA100.11a and
WirelessHART. Purpose is to do same but using open standards. Regarding
patents, we know those advertized by WirelessHART.
C [Carsten]: would be great if people did their IPR declaration.
Third-party or Dust themsleves.
A [Thomas]: open-source implementation exists.

Q [Mehdi Mani (ITRON, France)]: opinion on 6LoWPAN and RPL? What is missing
for TSCH networks?
A [Pascal]: 6LOWPAN HC is being used in TSCH networks. Regarding RPL,
question is if we need to define new OF, what bandwith info do we need to
provide OF with.

Q [Medhi]: I am afraid of adding too much layers that can introduce
inter-operability problems.
A [Pascal]: better understanding of various functions, clear layer is key
for viability.
A [Thomas]: The work can be done at l2 but by separating it into a new
layer (mac management layer) gives a more cleaner structure.

Q [Mehdi]: experience is extra layer is also burden to apply to new
technology.
A [JeongGil]: clear definition of interfaces is key in this work.

Q [Matthias Kovatsch]: are we limited to IEEE802.15.4e TSCH? Could this
work be extended to e.g. ContikiMAC?
A [Pascal,Thomas]: The primary focus of the group is IEEE802.15.4e TSCH.
This is an existing standard, and coming up with the glue to make it fit
under 6LoWPAN is relatively simple. Opening up to other MAC approaches
makes the work less well-defined. Feel free to keep an eye on  what is
being proposed and make sure that it could be applicable to other MACs.

=== draft-wang-6tsch-6tus-00 ===

Draft Title: 6tus Adaptation Layer Specification
URL: http://tools.ietf.org/html/draft-wang-6tsch-6tus-00
Presented by: Xavi Vilajosana

This draft describes interfaces to upper layers, discusses how to interact
with RPL or GMPLS.
Long draft, this presentation meant to help reading and understanding the
draft.
Draft should answer the problems described by Thomas.
Hard link is imposed by PCE, cannot be moved by 6tus. Soft link is a
bandwith requirement by upper layer, managed by 6tus. This work doesn't say
how this is managed, only defines the interfaces.
Using 6tus with PCE: could use RSVP, IS-IS
In distributed approach: upper layer requests bandwidth at each node, 6tus
instance in the node negociates with neighbor. CoAP is an option as a
distribution protocol, or RSVP or IS-IS.

C [Pascal]: open right now, but we want to have it defined as part of this
work.

In a distributed approach, nodes don't have a global view. May have hidden
terminal problem. The 6tus monitoring process observes whether link is not
up to the required performance, and re-negociates with neighbor to move it
in the TSHC schedule. Some 6tus "objective function" has to be defined.
Simple (default) behavior: could be to start with one link with each
neighbor.

C [Thomas]: don't be scared by our mentioning RSVP. We're talking only
inside the LLN. It's the concept of RSVP.

Xavi walks us through the current list of commands to the 6tus layer.
6tus uses packets to exchange control information between nodes. Makes use
of 3 new Information Elements in 15.4e EBs.

C [Thomas]: Communication between PCE and node? CoAP? other existing
protocol? Ask PCE group.
C [Pascal]: We could look at PCEP.

=== draft-thubert-6lowpan-backbone-router-03 ===

Draft Title: 6LoWPAN Backbone Router
URL: http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-03
Presented by: Pascal Thubert

We don't want to renumber when node moves from DODAG to the next. Single
subnet.
Pascal explains multiple roles of 6LBR. Walks through node registration
into the 6LoWPAN network.
Needs to differentiate two cases: real duplicate address (keep the oldest
one, reject the new one); node movement in the graph (accept the new one,
remove the old one). Differentiate cases based on device OUID (unique ID).
In summary: single IPv6 subnet (single prefix), capability for a node to
move between routers while keeping same IPv6 address, BBR server as proxy
ND.

Thomas closes the meeting.

Discussions items planned for this meeting will be discussed during the
phone meetings and on the mailing list.

--047d7b2eda156f068604d7ee02c5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

All,

Thanks for Dominique and Xavi for taking notes at y=
esterday's 6TSCH meeting. You'll find the at=A0https://bitbucket.org/6tsch/ietf86-o=
rlando/src.



For convenience, I also copy-pasted them below.

Thomas

---

<=
div>
Minutes 6TSCH Wednesday meet=
ing


IETF 86 Orlando
03/13/2013 11.30-13.00 Boca 2=





Notes taken by:
- Dominique Barthel
- Xavi Vilajosana



(15 people in the room)

=3D=3D=3D Introduction =3D=3D=3D



[Thomas] Today is technical discussion.<=
/div>
6TSCH is not a WG, so no IE=
TF home page, instead repositories at https://bitbucket.org/6tsch/.


Agenda: presentationsof 6 drafts=
, followed by discussion on 4 on-going topics.

=3D=3D=3D draft-ietf-roll-rpl-industrial-applicability-00 =3D=
=3D=3D



Draft Title: RPL Applicability in Industrial Ne=
tworks


Presented by: Pascal Thubert

<=
font face=3D"courier new, monospace">Draft written for the ROLL working gro=
up, used as starting point requirements for 6TSCH.


Same slides as presented at ROLL=
 WG meeting.
We need=
 a common draft to collect the goals. This can be in RPL industrial context=
.


In 6TSCH, mixing paths computed =
on PCE and paths computed in a distributed fashion by RPL. Not in this draf=
t.
Today there is no=
 definition yet of how to achieve deterministic tracks that go beyond the w=
ireless to the backbone.


Need another draft to explain ho=
w WirelessHART, ISA100.11a and 6TSCH networks can co-exist.

Q: are we mixing RPL storing and non-storing modes=
?


A [Pascal]: No, 6TSCH will not b=
e changing RPL.

=

=3D=3D=3D draft-pal=
attella-6tsch-terminology-00 =3D=3D=3D



Draft Title: Terminology in IPv6 over Time Slot=
ted Channel Hopping


Presented by: Thomas Watteyne

=
Draft was published yesterday.=



Goal is to capture terminology, =
clarify name conflicts between IEEE and IETF.
Some terms from 15.4e were colliding with IETF =
terms, e.g. link and path.


Next step is to capture new term=
s as they appear on the mailing list and in the drafts.

[Pascal]: includes by reference terminology drafts by =
other groups (ROLL, autoconf)



=3D=3D=3D draft-thubert-6tsch-architecture-00 =
=3D=3D=3D

Draft Title: An Architect=
ure for IPv6 over Time Synchronized Channel Hopping


Presented by: Pascal Thubert



Draft was supposed to be written at ROLL but ne=
ver was.
Goal: How t=
o put together RPL/PANA/6LoWPAN/


E.g. tuning to use RPL, how we d=
o DAD.
-00 published=
 yesterday.
Scope of=
 work is in the (current) draft.


The draft will progress as the g=
roup progresses.
Ins=
ide is the LLN, functionality of the BBR that connects the LLN and the BB. =
Exchange between the wireless world and the PCE.


Needs help from PANA experts.

=
Q [Pascal]: we need help for the PANA=
 section. Yoshihiro Ohba offered to help with that.


A [Yoshihiro Ohba]: yes.<=
/div>

Will have to decide which protocol to use =
to reserve bandwith along multi-hop paths, candidates are RSVP, NSIS.


Items on the "to discuss&qu=
ot; list are the ones on the agenda for the second part of this meeting.
=A0
<=
font face=3D"courier new, monospace">=3D=3D=3D draft-watteyne-6tsch-tsch-ll=
n-context-01 =3D=3D=3D



Draft Title: Using IEEE802.15.4e TSCH in an LLN=
 context: Overview, Problem Statement and Goals


Presented by: Thomas Watteyne

=
Overview, problem statement and goals=
.


version -01 draft.
<=
div>This draft states what TSCH does =
*not* do, hence what 6TSCH should provide as a complement.

Appendix A contains highlights of TSC=
H, appendix B contains further comments that are not explicit in the TSCH s=
tandard.
ToC and 2 a=
ppendix that deal with TSCH protocol highlights. Section 3 presents the pro=
blems.


Thomas delivers a 5min tutorial =
on TSCH.
15.4e is a =
MAC-only amendement, that runs in 15.4 radios. Enables deterministic commun=
ications. Typically 10ms cell. Channel hopping mitigates multipath. Inside =
the schedule all cells are empty and can be allocated. Building the schedul=
e is the challenge. It enables a clear trade-off between BW, Latency, redun=
dancy vs energy-consumption. The more cell scheduled, the more energy consu=
mption. Duty cycle is <1% if you don't have a very full schedule.


Each cell does 1 out of 4 possib=
le things: Sleep, transmit, receive, same with no ACK
The IEEE802.15.4e TSCH standard describes=
 the mechanics to execute a schedule, not how one builds a schedule.=



The draft describes nine problem=
s to be solved. Thomas talks us through four of them. Network formation. Ho=
w to send EBs? Network maintenance: how to select time source neighbors? =
=A0Resource management: how to deal with links/cells, how to schedule cells=
? how to match the number of links to bandwidth. Dataflow control: a queuei=
ng policy. how to deal with the policies of packets and flows.


Next: align terminology with &qu=
ot;terminology" draft, include goals.
=A0=A0
Q (JeongGil Ko, ETRI, Korea): Looks like we want to do something =
like RSVP for TSCH. How protocol-specific are we? Fine-tuning for RPL? Prov=
iding general consideration on various possibilities?


A [Thomas]: we want to be generi=
c but we want to cover all the possible scenarios.
A [Pascal]: we assume we use RPL. We'll =
decide if we use RSVP or something else. We'll explain how we use these=
.



Q [Carsten]: what does multi-hop mean? within a=
 6LoWPAN or though various heterogeneous links.
A [Pascal]: multi-hop within 6LoWPAN. But also =
verify behavior (determinism) across several networks, see presentation on =
802.1Q on Tuesday.



Q [Carsten]: more than setting DSCP?
A [Pascal]: yes. RSVP at layer=
 3. Not through the general Internet, only through controlled backbone.



Q [Carsten]: what about patents in this landsca=
pe? Open implementation ever?
A [Pascal]: same techniques already deployed in ISA100.11a and Wi=
relessHART. Purpose is to do same but using open standards. Regarding paten=
ts, we know those advertized by WirelessHART.


C [Carsten]: would be great if p=
eople did their IPR declaration. Third-party or Dust themsleves.
A [Thomas]: open-source implem=
entation exists.



Q [Mehdi Mani (ITRON, France)]: opinion on 6LoW=
PAN and RPL? What is missing for TSCH networks?
A [Pascal]: 6LOWPAN HC is being used in TSCH ne=
tworks. Regarding RPL, question is if we need to define new OF, what bandwi=
th info do we need to provide OF with.



Q [Medhi]: I am afraid of adding too much layer=
s that can introduce inter-operability problems.=A0
A [Pascal]: better understanding of various=
 functions, clear layer is key for viability.


A [Thomas]: The work can be done=
 at l2 but by separating it into a new layer (mac management layer) gives a=
 more cleaner structure.



Q [Mehdi]: experien=
ce is extra layer is also burden to apply to new technology.
A [JeongGil]: clear definition of =
interfaces is key in this work.



Q [Matthias Kovatsch]: are we limited to IEEE80=
2.15.4e TSCH? Could this work be extended to e.g. ContikiMAC?
<=
div>
A [Pascal,Thomas]: The primary focus =
of the group is IEEE802.15.4e TSCH. This is an existing standard, and comin=
g up with the glue to make it fit under 6LoWPAN is relatively simple. Openi=
ng up to other MAC approaches makes the work less well-defined. Feel free t=
o keep an eye on =A0what is being proposed and make sure that it could be a=
pplicable to other MACs.



=3D=3D=3D draft-wang-6tsch-6tus-00 =3D=3D=3D

=
Draft Title: 6tus Adaptation Layer Sp=
ecification


Pr=
esented by: Xavi Vilajosana



This draft describes interfaces to upper layers=
, discusses how to interact with RPL or GMPLS.
Long draft, this presentation meant to help rea=
ding and understanding the draft.


Draft should answer the problems=
 described by Thomas.
Using 6tus with PCE: could use R=
SVP, IS-IS
In distri=
buted approach: upper layer requests bandwidth at each node, 6tus instance =
in the node negociates with neighbor. CoAP is an option as a distribution p=
rotocol, or RSVP or IS-IS.



C [Pascal]: open right now, but we want to have=
 it defined as part of this work.



In a distributed ap=
proach, nodes don't have a global view. May have hidden terminal proble=
m. The 6tus monitoring process observes whether link is not up to the requi=
red performance, and re-negociates with neighbor to move it in the TSHC sch=
edule. Some 6tus "objective function" has to be defined.

Simple (default) behavior: could=
 be to start with one link with each neighbor.

C [Thomas]: don't be scared by our mentioning RSVP. We'=
;re talking only inside the LLN. It's the concept of RSVP.



Xavi walks us through the current list of comma=
nds to the 6tus layer.
6tus uses packets to exchange control information between nodes. Makes u=
se of 3 new Information Elements in 15.4e EBs.


=A0
C [Thomas]: Communication between PCE and node?=
 CoAP? other existing protocol? Ask PCE group.
C [Pascal]: We could look at PCEP.



=3D=3D=3D draft-thubert-6lowpan-backbone-router=
-03 =3D=3D=3D


Draft Title: 6LoWPAN Backbone Router<=
/font>


Presented by: Pascal Thubert

<=
font face=3D"courier new, monospace">We don't want to renumber when nod=
e moves from DODAG to the next. Single subnet.


Pascal explains multiple roles o=
f 6LBR. Walks through node registration into the 6LoWPAN network.
Needs to differentiate two ca=
ses: real duplicate address (keep the oldest one, reject the new one); node=
 movement in the graph (accept the new one, remove the old one). Differenti=
ate cases based on device OUID (unique ID).


In summary: single IPv6 subnet (=
single prefix), capability for a node to move between routers while keeping=
 same IPv6 address, BBR server as proxy ND.



Thomas closes the m=
eeting.

<=
/div>
Discussions items planned f=
or this meeting will be discussed during the phone meetings and on the mail=
ing list.




--047d7b2eda156f068604d7ee02c5--

From twatteyne@gmail.com  Thu Mar 14 20:30:20 2013
Return-Path: 
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 94B5021F8E08 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 20:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 hky08+c05PFv for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 20:30:19 -0700 (PDT)
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 50BD121F8E04 for <6tsch@ietf.org>; Thu, 14 Mar 2013 20:30:18 -0700 (PDT)
Received: by mail-pb0-f45.google.com with SMTP id ro8so3205029pbb.4 for <6tsch@ietf.org>; Thu, 14 Mar 2013 20:30:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=V9PCcPT7ElrQE6Rj/CYk9x2xR03s2MQk31wAmEP2LEo=; b=hcah7sZY7ucKw1ReoCMSzeKqFnSplzeCFQKnWt4zShWT0UQ6aiS36K582oPVX35NQF XHV20UHE+uZwyWaZitGYoPxiHa48LHs5DGXXpsbGAjJNvshKBjR+PEjvHs00l08zgwQm 3QXJZ0ZeRIghrQ+CYsx5dU+Yf0WiQZMlrgEN3VL1P4uaov7y+OXpceiFnSw6+naHGZBJ 3RcHb/5J6zHCySe0He57BaoxGjyrr7JvANDca74+7nbWNcZLTpcXlGkVuUPtMK6CxuvA BjSnDlqwPgKLeR4zNtj7Zb3HhhIiplOHFcrDiS0N6vrUgs+7zhD1xikQ3iPaeFA3XGow MZig==
MIME-Version: 1.0
X-Received: by 10.68.132.42 with SMTP id or10mr11885771pbb.127.1363318218688;  Thu, 14 Mar 2013 20:30:18 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Thu, 14 Mar 2013 20:30:18 -0700 (PDT)
Date: Thu, 14 Mar 2013 20:30:18 -0700
X-Google-Sender-Auth: jxLVAO5KIXOaaGV1LVHDve2puAE
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b10cbb1240fd804d7ee4251
Subject: [6tsch] reminder: no 6TSCH call this week
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 03:30:20 -0000

--047d7b10cbb1240fd804d7ee4251
Content-Type: text/plain; charset=ISO-8859-1

All,

Quick reminder: because of the IETF 86 meeting this week, this week 6TSCH
webex is cancelled.

Thomas

--047d7b10cbb1240fd804d7ee4251
Content-Type: text/html; charset=ISO-8859-1

All,

Quick reminder: because of the IETF 86 meeting this week, this week 6TSCH webex is cancelled.

Thomas


--047d7b10cbb1240fd804d7ee4251--

From jeonggil.ko@gmail.com  Thu Mar 14 20:33:28 2013
Return-Path: 
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 099C111E81C0 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 20:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 al7fXyyURrSD for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 20:33:27 -0700 (PDT)
Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6449811E81BF for <6tsch@ietf.org>; Thu, 14 Mar 2013 20:33:27 -0700 (PDT)
Received: by mail-pb0-f51.google.com with SMTP id un15so3166180pbc.24 for <6tsch@ietf.org>; Thu, 14 Mar 2013 20:33:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=L2bvNtSc/UTH24R6FfTqK7jPJSDMXZeJLq0aiomHJII=; b=RLwl4XMWD1/BDBBT3Y7jXLCiJdHjzFlfxn0JRdAsRfTurIHs+jq4Em6RaancOYDIKQ 8X/+127fFRe2634s6tZdwhZR567u8uifeig4fwy6CIXi+amaF3dfA51/mWA4v6f0Sztq cPpI9IAs7rvMuulyHK7K+Kz4g87qyXPAAtIEirs8mrq4i7g04ux0z+Chid/CHUmwPR7Y 8dM66Anp4Cs8P2ST6uBVgC4Gw3T6KiSICtJXgPgEV7QborxwXjemnESeKqS/ZzBYtDmF +rFjjPwNNsiY1BKGIGtau50ONRQOf/Bu7TLMOkTVR9nZg+dNyyiCFFuYRDh4mN+IfnLi /Quw==
X-Received: by 10.68.189.199 with SMTP id gk7mr11782483pbc.164.1363318407075;  Thu, 14 Mar 2013 20:33:27 -0700 (PDT)
Received: from 172.20.nate.com ([180.135.179.56]) by mx.google.com with ESMTPS id eg1sm6346245pbb.33.2013.03.14.20.33.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 20:33:25 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: JeongGil Ko 
In-Reply-To: <514248DA.6090403@eecs.berkeley.edu>
Date: Thu, 14 Mar 2013 23:33:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu>
To: Xavier Vilajosana 
X-Mailer: Apple Mail (2.1499)
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 03:33:28 -0000

Exactly my take on this issue. Its really not a matter of using the =
scheme directly (unless we really can, which can be nice) but taking the =
concepts and applying it to match our needs for bandwidth/slot =
allocation.

Thanks.

-John
=20
------
JeongGil Ko, Ph.D.
Researcher
Electronics and Telecommunications Research Institute (ETRI)
http://sites.google.com/site/jeonggilko/

On Mar 14, 2013, at 6:02 PM, Xavier Vilajosana =
 wrote:

> Qin, I think that we need a protocol that is in charge of managing =
tracks, allocating bandwidth along the track,  monitor that the end to =
end bandwidth requirement is really accomplished, etc..
>=20
> this is my point.. maybe others can add more reasons..
>=20
> X
>=20
> On 14/03/13 14:57, Qin Wang wrote:
>> Hi all,
>>=20
>> This may be a silly question: why we investigate various resource
>> reservation protocols? Do we want to bind 6tus with some resource
>> reservation protocol, or try to figure out the mandatory =
functionality
>> 6tus must provides by investigating those protocols?
>>=20
>> Thanks
>> Qin
>>=20
>>=20
>>> On Mar 14, 2013, at 16:04, Pascal Thubert 
>>> wrote:
>>>=20
>>>> NSIS
>>> http://nsis-ka.org says:
>>>=20
>>> GIST: 32,858 LOC
>>> NSIS: 67,193 LOC
>>>=20
>>> Gr=FC=DFe, Carsten
>>>=20
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>=20
>>=20
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>=20
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


From twatteyne@gmail.com  Thu Mar 14 22:55:36 2013
Return-Path: 
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 3F0AC21F8D04 for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 22:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.643
X-Spam-Level: 
X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666]
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 rui1PIQNj4bQ for <6tsch@ietfa.amsl.com>; Thu, 14 Mar 2013 22:55:35 -0700 (PDT)
Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 535BD21F8CF7 for <6tsch@ietf.org>; Thu, 14 Mar 2013 22:55:35 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id v10so152044pde.32 for <6tsch@ietf.org>; Thu, 14 Mar 2013 22:55:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=msltLJa4z7pCgg/mHeaA94rlK/d0gm28AA03Sd64ASo=; b=QBX50dGZmODSzMCpkaqvjVs/I8uUlsSmSKIlFt/PZ8wnXtONoFaiFnoofxjNah2icq +OzM0TIK4aamGBb8aF19kTBsPJvFRPl6mPlPr6J/QgRi29Hdjuwpwv+Fhzs7k5TGdb9N DQwf3oliTFDGPqsk2g8rl9ahaas0CuDQhmfF7uii1CWW/fRrlmbwY9znOApvRDDiL2jw HS1Ps/DozCwHsCHKUM02HpyDuG0P+tfOnHMRp/kk01yRQapLNlRCOYHlUK6IRsl+XCc9 gf6ElWuhB8SvvHnIYCtZWHgOmPaZ6Ct65m469Ax9Z89ZJznZFBvj9r/iK5z7jKXnD2S4 THrA==
MIME-Version: 1.0
X-Received: by 10.68.132.42 with SMTP id or10mr12735355pbb.127.1363326934885;  Thu, 14 Mar 2013 22:55:34 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Thu, 14 Mar 2013 22:55:34 -0700 (PDT)
In-Reply-To: <5142373D.9090501@tanu.org>
References: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>  <5141B51E.3050603@tanu.org> <2FB32E34ED32C44A8D9BCC2E880875E326C0D4A3@AM2PRD0411MB434.eurprd04.prod.outlook.com> <5141C4F5.8040202@tanu.org> <3f5fc7a67dd46651bb8b05da1720f86b.squirrel@calmail.berkeley.edu> <5142373D.9090501@tanu.org>
Date: Thu, 14 Mar 2013 22:55:34 -0700
X-Google-Sender-Auth: K6-71Eo5VbEqNs07VFXTy-QXxdA
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b10cbb1aaaddd04d7f04986
Subject: Re: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 05:55:36 -0000

--047d7b10cbb1aaaddd04d7f04986
Content-Type: text/plain; charset=ISO-8859-1

Shoichi, Paul,

I agree with Qin's description. I believe we should not close any doors,
and allow for different setups:
- one "standalone" LLN, or multiple LLNs connected over a backbone
- TSCH schedule built by a PCE, or in a distributed way, or a hybrid
approach.

Paul, in my mind a PCE reserves hard cells, and a distributed protocol soft
cells. The distinction is simply related to collisions: if you are certain
that the network schedule is collision-free (which we might assume from a
PCE), then schedule hard cells. If collisions are possible (e.g. between
two independent pairs of nodes), then schedule soft cells, since you need
6tus to monitor them and move one if needed. Of course, one could imagine a
hybrid approach, in which both hard and soft cells are present in the
network.

John has started to investigate protocols such as RSVP or NSIS to reserve
cells along a multi-hop path (a track) inside the LLN. In a setup where
only this protocol is used for scheduling, the PCE would not be present.

I hope this answers your question.

Thomas

On Thu, Mar 14, 2013 at 1:46 PM, Shoichi Sakane  wrote:

> Hi Qin,
>
> Very clear.  Thanks!
>
> Shoichi
>
>
> On 3/15/13 1:27 AM, Qin Wang wrote:
>
>> Hi Shoichi and all,
>>
>> My understanding is as follows.
>>
>> (1) The networks which we are talking about could include one LLN or
>> multiple LLNs connected by backbone. PCE is a optional device in the
>> networks.
>>
>> (2) If there is PCE, there may be different setting. For example, PCE is
>> in charge for reserving both multiple hop path (i.e. every next hop
>> neighbor) and cells; or PCE is just in charge for reserving the multiple
>> hop path and leaving cell reservation to local, and the distributed cell
>> reservation will meet the bandwidth requirement from multiple hop path
>> reservation. In the first case, hard cell reservation will be used.
>>
>> (3)If there is no PCE, both multihop path and cells are reserved in local.
>> For example, RPL + soft cell reservation in 6tus.
>>
>> Does it make sense?
>>
>> Qin
>>
>>
>>  On 3/14/13 9:02 PM, Paul Chilton wrote:
>>>
>>>> - optionally a PCE sits on the backbone and drives the LLNs' TSCH
>>>>> schedules.
>>>>>
>>>>
>>> Ah, maybe understood.  It doesn't say that existence of PCE is optional.
>>> It says that it's optional to put PCE in the backbone.  It doesn't
>>> preclude to put it on BBR.  Correct ?
>>>
>>> Shoichi
>>> ______________________________**_________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/**listinfo/6tsch
>>>
>>>
>> ______________________________**_________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/**listinfo/6tsch
>>
>>  ______________________________**_________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/**listinfo/6tsch
>

--047d7b10cbb1aaaddd04d7f04986
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Shoichi, Paul,

I agree with Qin's description. I bel=
ieve we should not close any doors, and allow for different setups:
- one "standalone" LLN, or multiple LLNs connected over a back=
bone



- TSCH schedule built by a PCE, or in a distributed way, or a hybrid a=
pproach.

Paul, in my mind a PCE reserves hard cell=
s, and a distributed protocol soft cells. The distinction is simply related=
 to collisions: if you are certain that the network schedule is collision-f=
ree (which we might assume from a PCE), then schedule hard cells. If collis=
ions are possible (e.g. between two independent pairs of nodes), then sched=
ule soft cells, since you need 6tus to monitor them and move one if needed.=
 Of course, one could imagine a hybrid=A0approach, in which both hard and s=
oft cells are present in the network.




John has started to investigate protocols such as RSVP =
or NSIS to reserve cells along a multi-hop path (a track) inside the LLN. I=
n a setup where only this protocol is used for scheduling, the PCE would no=
t be present.



I hope this answers your question.

=

Thomas

On Thu, Mar 14, 2013 a=
t 1:46 PM, Shoichi Sakane <sakane@tanu.org> wrote:



Hi Qin,



Very clear. =A0Thanks!



Shoichi




On 3/15/13 1:27 AM, Qin Wang wrote:



Hi Shoichi and all,



My understanding is as follows.



(1) The networks which we are talking about could include one LLN or

multiple LLNs connected by backbone. PCE is a optional device in the

networks.



(2) If there is PCE, there may be different setting. For example, PCE is
in charge for reserving both multiple hop path (i.e. every next hop

neighbor) and cells; or PCE is just in charge for reserving the multiple
hop path and leaving cell reservation to local, and the distributed cell
reservation will meet the bandwidth requirement from multiple hop path

reservation. In the first case, hard cell reservation will be used.



(3)If there is no PCE, both multihop path and cells are reserved in local.<=
br>
For example, RPL + soft cell reservation in 6tus.



Does it make sense?



Qin







On 3/14/13 9:02 PM, Paul Chilton wrote:



- optionally a PCE sits on the backbone and drives the LLNs' TSCH

schedules.





Ah, maybe understood. =A0It doesn't say that existence of PCE is option=
al.

It says that it's optional to put PCE in the backbone. =A0It doesn'=
t

preclude to put it on BBR. =A0Correct ?



Shoichi

_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch







_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





--047d7b10cbb1aaaddd04d7f04986--

From alfredo.grieco@gmail.com  Fri Mar 15 02:27:29 2013
Return-Path: 
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 781EE21F91AE for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 02:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level: 
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
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 ZJ8Ue8UGgeTQ for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 02:27:28 -0700 (PDT)
Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id E065921F91CD for <6tsch@ietf.org>; Fri, 15 Mar 2013 02:27:27 -0700 (PDT)
Received: by mail-ee0-f53.google.com with SMTP id e53so1434303eek.26 for <6tsch@ietf.org>; Fri, 15 Mar 2013 02:27:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=h4XKNjgP9Y287akTIT620TKKXBecf78LN0CBubR/gW8=; b=EO3E0pT3TnF7CKhxzU2w/JnjJQnTiYRwqWbTDMTGgmKUsNQt4A2WCqubTuus4ZayKj NbPMhYlFMcSj4LOPSJ5l0ltbuqLNy8I9dKINMKHaJEZTwsw4MxpV4yfxRtM20hbik4wE Mhu1MGQ8PCaNuomjc5FyFzzhpiBWAft8Fc9Yb4eAjvtm/92VoTLCAmce8qqg29Xzi/Kb rbaNaajK3yr7fU4O3oM499mYnnVtzXEEj9y89ej+Xx3qSR35Nd5De6Z86kuwpIvYfN3K eTVjChN5oW3yc5rQMMwj+zfsMN4YyCNsr6Rg/N8Zh0+HguK7Fs0Gq+spMT9iajyB01gA 8uhw==
X-Received: by 10.14.182.137 with SMTP id o9mr16233946eem.13.1363339646727; Fri, 15 Mar 2013 02:27:26 -0700 (PDT)
Received: from [192.168.1.42] (AAubervilliers-652-1-195-127.w86-218.abo.wanadoo.fr. [86.218.90.127]) by mx.google.com with ESMTPS id s3sm8739675eem.4.2013.03.15.02.27.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 02:27:25 -0700 (PDT)
References: <90d5facfcd961deffd839ef420ec84c0.squirrel@calmail.berkeley.edu>
Mime-Version: 1.0 (1.0)
In-Reply-To: <90d5facfcd961deffd839ef420ec84c0.squirrel@calmail.berkeley.edu>
Content-Type: multipart/alternative; boundary=Apple-Mail-0CBF1B96-0BC9-4152-B5E4-CBCB4EDE1E17
Content-Transfer-Encoding: 7bit
Message-Id: <19254A1F-7D2B-4138-9ABD-7D01D76B37AC@gmail.com>
X-Mailer: iPad Mail (10B146)
From: Grieco 
Date: Fri, 15 Mar 2013 10:27:24 +0100
To: Qin Wang 
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] attributes of data traffic flow
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 09:27:29 -0000

--Apple-Mail-0CBF1B96-0BC9-4152-B5E4-CBCB4EDE1E17
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi Qin, and all

Do you think it could be useful to specify the minimum, maximum, average, an=
d standard deviation of the bandwidth requirments for bursty flows ?

In this case, the PCE could have a clear picture of the bounds of the aggreg=
ated bandwidth demand of the network, thus improving the effectiveness of th=
e schedule it will build.

What do you think about ?

Cheers

Alfredo


--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672


On 15 Mar 2013, at 01:39, "Qin Wang"  wrote:

> Hi all,
>=20
> In the previous emails, there are several threads related with data
> traffic flow or data flow. I think it is important to put them together
> and see if there is missing pieces.
>=20
> Attributes of data flow:
>=20
> (1) Periodicity (T): a integer, T=3D0 means bursty,  T>0 means the timeslo=
ts
> in one cycle.
>=20
> (2) Bandwidth requirement: number of slots in one cycle if T>0; number of
> frames in one burst if T=3D0.
>=20
> (3) Jitters sensitivity : if the data flow is periodical (T >0), then it
> reflects the deterministic requirement. if the data flow is bursty (T=3D0)=
,
> then it reflects the end-to-end latency requirement of the data flow.
>=20
> (4)Reliability: e.g. one-hop Data Delivery Rate (PDR)
>=20
> Anything else?
>=20
> In addition, I think "priority of data flow" is function of these basic
> attributes, maybe more. Make sense?
>=20
> Qin
>=20
>=20
>=20
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch

--Apple-Mail-0CBF1B96-0BC9-4152-B5E4-CBCB4EDE1E17
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi Qin, and all

Do you think it could be useful to specify the minimum, maximum, average,=
 and standard deviation of the bandwidth requirments for bursty flows ?

In this case, the PCE could have a clear picture of the=
 bounds of the aggregated bandwidth demand of the network, thus improving th=
e effectiveness of the schedule it will build.

What=
 do you think about ?

Cheers

Alfredo


--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
Skype id: l.alfredo.grieco
Mobile: +39 3346715672


On 15 Mar 2013, at 01:39, "Qin Wang" <qinwang@berkeley.edu> wrote:

Hi all,

In the previous e=
mails, there are several threads related with data
traffic f=
low or data flow. I think it is important to put them together
and see if there is missing pieces.

Attr=
ibutes of data flow:

(1) Periodicity (T): a=
 integer, T=3D0 means bursty,  T>0 means the timeslots
in one cycle.

(2) Bandwidth requirement:=
 number of slots in one cycle if T>0; number of
frames in=
 one burst if T=3D0.

(3) Jitters sensitivit=
y : if the data flow is periodical (T >0), then it
reflec=
ts the deterministic requirement. if the data flow is bursty (T=3D0),=

then it reflects the end-to-end latency requirement of the data fl=
ow.

(4)Reliability: e.g. one-hop Data Deliv=
ery Rate (PDR)

Anything else?

In addition, I think "priority of data flow" is function=
 of these basic
attributes, maybe more. Make sense?
Qin



_______________________________________________6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch
=

--Apple-Mail-0CBF1B96-0BC9-4152-B5E4-CBCB4EDE1E17--

From qinwang@berkeley.edu  Fri Mar 15 10:11:51 2013
Return-Path: 
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 B638E21F87FF for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 10:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Ecl67sh4YhXG for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 10:11:50 -0700 (PDT)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8159021F87B1 for <6tsch@ietf.org>; Fri, 15 Mar 2013 10:11:49 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UGYAS-0000hA-GL; Fri, 15 Mar 2013 10:11:48 -0700
Received: from 136.152.38.37 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 15 Mar 2013 10:11:44 -0700
Message-ID: <3456ddc71ec69cdbcf5ac7eee86ff00b.squirrel@calmail.berkeley.edu>
In-Reply-To: <19254A1F-7D2B-4138-9ABD-7D01D76B37AC@gmail.com>
References: <90d5facfcd961deffd839ef420ec84c0.squirrel@calmail.berkeley.edu> <19254A1F-7D2B-4138-9ABD-7D01D76B37AC@gmail.com>
Date: Fri, 15 Mar 2013 10:11:44 -0700
From: "Qin Wang" 
To: "Grieco" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IETF 6TSCH <6tsch@ietf.org>, Qin Wang 
Subject: Re: [6tsch] attributes of data traffic flow
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 17:11:51 -0000

I agree!

Qin


> Hi Qin, and all
>
> Do you think it could be useful to specify the minimum, maximum, average,
> and standard deviation of the bandwidth requirments for bursty flows ?
>
> In this case, the PCE could have a clear picture of the bounds of the
> aggregated bandwidth demand of the network, thus improving the
> effectiveness of the schedule it will build.
>
> What do you think about ?
>
> Cheers
>
> Alfredo
>
>
> --
> Luigi Alfredo Grieco, PhD
> Assistant Professor
> Department of Electrical and Information Engineering
> Politecnico di Bari
> Via Orabona 4 - 70125 - Bari - Italy
> +39 080 5963 911
> telematics.poliba.it/grieco
> Skype id: l.alfredo.grieco
> Mobile: +39 3346715672
>
>
> On 15 Mar 2013, at 01:39, "Qin Wang"  wrote:
>
>> Hi all,
>>
>> In the previous emails, there are several threads related with data
>> traffic flow or data flow. I think it is important to put them together
>> and see if there is missing pieces.
>>
>> Attributes of data flow:
>>
>> (1) Periodicity (T): a integer, T=0 means bursty,  T>0 means the
>> timeslots
>> in one cycle.
>>
>> (2) Bandwidth requirement: number of slots in one cycle if T>0; number
>> of
>> frames in one burst if T=0.
>>
>> (3) Jitters sensitivity : if the data flow is periodical (T >0), then it
>> reflects the deterministic requirement. if the data flow is bursty
>> (T=0),
>> then it reflects the end-to-end latency requirement of the data flow.
>>
>> (4)Reliability: e.g. one-hop Data Delivery Rate (PDR)
>>
>> Anything else?
>>
>> In addition, I think "priority of data flow" is function of these basic
>> attributes, maybe more. Make sense?
>>
>> Qin
>>
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>



From qinwang@berkeley.edu  Fri Mar 15 10:42:43 2013
Return-Path: 
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 C7C6B21F89B2 for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 10:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 YjyHbPIE8GjZ for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 10:42:43 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3536121F89AF for <6tsch@ietf.org>; Fri, 15 Mar 2013 10:42:43 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UGYeL-00057H-Dh; Fri, 15 Mar 2013 10:42:41 -0700
Received: from 136.152.38.37 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 15 Mar 2013 10:42:37 -0700
Message-ID: <9fb6b483e3d071c247c0e3dac2b7692e.squirrel@calmail.berkeley.edu>
In-Reply-To: 
References: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>  <5141B51E.3050603@tanu.org> <2FB32E34ED32C44A8D9BCC2E880875E326C0D4A3@AM2PRD0411MB434.eurprd04.prod.outlook.com> <5141C4F5.8040202@tanu.org> <3f5fc7a67dd46651bb8b05da1720f86b.squirrel@calmail.berkeley.edu> <5142373D.9090501@tanu.org> 
Date: Fri, 15 Mar 2013 10:42:37 -0700
From: "Qin Wang" 
To: "Thomas Watteyne" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 17:42:43 -0000

Thomas,

I'm not very clear about the relationship between RSVP/NSIS and PCE. My
understanding is RSVP/NSIS is used to reserve resource along a multihop
path, basically by translating the feature of data flow and Qos
requirement into communication resource reservation. They could be
centralized or distributed, i.e. with or without PCE. Correct?

Qin


> Shoichi, Paul,
>
> I agree with Qin's description. I believe we should not close any doors,
> and allow for different setups:
> - one "standalone" LLN, or multiple LLNs connected over a backbone
> - TSCH schedule built by a PCE, or in a distributed way, or a hybrid
> approach.
>
> Paul, in my mind a PCE reserves hard cells, and a distributed protocol
> soft
> cells. The distinction is simply related to collisions: if you are certain
> that the network schedule is collision-free (which we might assume from a
> PCE), then schedule hard cells. If collisions are possible (e.g. between
> two independent pairs of nodes), then schedule soft cells, since you need
> 6tus to monitor them and move one if needed. Of course, one could imagine
> a
> hybrid approach, in which both hard and soft cells are present in the
> network.
>
> John has started to investigate protocols such as RSVP or NSIS to reserve
> cells along a multi-hop path (a track) inside the LLN. In a setup where
> only this protocol is used for scheduling, the PCE would not be present.
>
> I hope this answers your question.
>
> Thomas
>
> On Thu, Mar 14, 2013 at 1:46 PM, Shoichi Sakane  wrote:
>
>> Hi Qin,
>>
>> Very clear.  Thanks!
>>
>> Shoichi
>>
>>
>> On 3/15/13 1:27 AM, Qin Wang wrote:
>>
>>> Hi Shoichi and all,
>>>
>>> My understanding is as follows.
>>>
>>> (1) The networks which we are talking about could include one LLN or
>>> multiple LLNs connected by backbone. PCE is a optional device in the
>>> networks.
>>>
>>> (2) If there is PCE, there may be different setting. For example, PCE
>>> is
>>> in charge for reserving both multiple hop path (i.e. every next hop
>>> neighbor) and cells; or PCE is just in charge for reserving the
>>> multiple
>>> hop path and leaving cell reservation to local, and the distributed
>>> cell
>>> reservation will meet the bandwidth requirement from multiple hop path
>>> reservation. In the first case, hard cell reservation will be used.
>>>
>>> (3)If there is no PCE, both multihop path and cells are reserved in
>>> local.
>>> For example, RPL + soft cell reservation in 6tus.
>>>
>>> Does it make sense?
>>>
>>> Qin
>>>
>>>
>>>  On 3/14/13 9:02 PM, Paul Chilton wrote:
>>>>
>>>>> - optionally a PCE sits on the backbone and drives the LLNs' TSCH
>>>>>> schedules.
>>>>>>
>>>>>
>>>> Ah, maybe understood.  It doesn't say that existence of PCE is
>>>> optional.
>>>> It says that it's optional to put PCE in the backbone.  It doesn't
>>>> preclude to put it on BBR.  Correct ?
>>>>
>>>> Shoichi
>>>> ______________________________**_________________
>>>> 6tsch mailing list
>>>> 6tsch@ietf.org
>>>> https://www.ietf.org/mailman/**listinfo/6tsch
>>>>
>>>>
>>> ______________________________**_________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/**listinfo/6tsch
>>>
>>>  ______________________________**_________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/**listinfo/6tsch
>>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From pthubert@cisco.com  Fri Mar 15 11:19:16 2013
Return-Path: 
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 E884F21F8745 for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 11:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Vp76KI568oUM for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 11:19:16 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3112021F84A1 for <6tsch@ietf.org>; Fri, 15 Mar 2013 11:19:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2884; q=dns/txt; s=iport; t=1363371556; x=1364581156; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Pna2JRGHiZd+dhOBQ3v/dTYhgHXvIaftriRo9+M0sag=; b=RBLmrSmnaSbuPd9TGUpZK4LNkYEiWueEPNgkAx2jE23UbmGmJLamQPSU QMl7GKCcJqr0UiK0EUgXCmLvEHkBKtpCcJ8HJOTEuey5vP3GH4yoCN3DN HaPmosC1ffD3XpDLhx2XL10cnouhjioLcZ42i+UY7kNusaWROMk3moVXc E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFACVkQ1GtJV2b/2dsb2JhbABDDsUSgWcWdIIqAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCIgGBgzDTo5kJgsHBoJZYQOSXIUej2OCSz+CKA
X-IronPort-AV: E=Sophos;i="4.84,853,1355097600"; d="scan'208";a="185005021"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 15 Mar 2013 18:19:15 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2FIJFlJ023412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Mar 2013 18:19:15 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 13:19:15 -0500
From: "Pascal Thubert (pthubert)" 
To: Qin Wang , Grieco 
Thread-Topic: [6tsch] attributes of data traffic flow
Thread-Index: AQHOIaA/y+tgDd+ZSUu5iqHssPO1CZim/oEQ
Date: Fri, 15 Mar 2013 18:19:15 +0000
Deferred-Delivery: Fri, 15 Mar 2013 18:19:00 +0000
Message-ID: 
References: <90d5facfcd961deffd839ef420ec84c0.squirrel@calmail.berkeley.edu> <19254A1F-7D2B-4138-9ABD-7D01D76B37AC@gmail.com> <3456ddc71ec69cdbcf5ac7eee86ff00b.squirrel@calmail.berkeley.edu>
In-Reply-To: <3456ddc71ec69cdbcf5ac7eee86ff00b.squirrel@calmail.berkeley.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.83.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] attributes of data traffic flow
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 18:19:17 -0000

Just to give a perspective,=20

In frame relay, what a SLA provides for CIR is committed rate (guaranteed),=
 excess rate (discard eligible), and a burst size.

Rates can be used to allocate things similar to cells.  Burst can be mapped=
 into buffers to be reserved for a particular stream. As you see, the CIR e=
xpression is designed to be mapped easily by the switch into its operation.

Maybe it would be good to keep things simple for motes as well. Whatever we=
 feed it to, we need to be clear on what 6TUS does of it. Something simple.=
..

Cheers;=20

Pascal


-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Q=
in Wang
Sent: vendredi 15 mars 2013 13:12
To: Grieco
Cc: IETF 6TSCH; Qin Wang
Subject: Re: [6tsch] attributes of data traffic flow

I agree!

Qin


> Hi Qin, and all
>
> Do you think it could be useful to specify the minimum, maximum,=20
> average, and standard deviation of the bandwidth requirments for bursty f=
lows ?
>
> In this case, the PCE could have a clear picture of the bounds of the=20
> aggregated bandwidth demand of the network, thus improving the=20
> effectiveness of the schedule it will build.
>
> What do you think about ?
>
> Cheers
>
> Alfredo
>
>
> --
> Luigi Alfredo Grieco, PhD
> Assistant Professor
> Department of Electrical and Information Engineering Politecnico di=20
> Bari Via Orabona 4 - 70125 - Bari - Italy
> +39 080 5963 911
> telematics.poliba.it/grieco
> Skype id: l.alfredo.grieco
> Mobile: +39 3346715672
>
>
> On 15 Mar 2013, at 01:39, "Qin Wang"  wrote:
>
>> Hi all,
>>
>> In the previous emails, there are several threads related with data=20
>> traffic flow or data flow. I think it is important to put them=20
>> together and see if there is missing pieces.
>>
>> Attributes of data flow:
>>
>> (1) Periodicity (T): a integer, T=3D0 means bursty,  T>0 means the=20
>> timeslots in one cycle.
>>
>> (2) Bandwidth requirement: number of slots in one cycle if T>0;=20
>> number of frames in one burst if T=3D0.
>>
>> (3) Jitters sensitivity : if the data flow is periodical (T >0), then=20
>> it reflects the deterministic requirement. if the data flow is bursty=20
>> (T=3D0), then it reflects the end-to-end latency requirement of the=20
>> data flow.
>>
>> (4)Reliability: e.g. one-hop Data Delivery Rate (PDR)
>>
>> Anything else?
>>
>> In addition, I think "priority of data flow" is function of these=20
>> basic attributes, maybe more. Make sense?
>>
>> Qin
>>
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>


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

From xvilajosana@eecs.berkeley.edu  Fri Mar 15 11:58:25 2013
Return-Path: 
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 775E221F8A71 for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 11:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 LbXiB1X82maX for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 11:58:24 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id C6F1F21F8A47 for <6tsch@ietf.org>; Fri, 15 Mar 2013 11:58:24 -0700 (PDT)
Received: from dhcp-33-135.eecs.berkeley.edu ([128.32.33.135]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UGZpf-0007Qi-5S for 6tsch@ietf.org; Fri, 15 Mar 2013 11:58:24 -0700
Message-ID: <51436F4F.8060201@eecs.berkeley.edu>
Date: Fri, 15 Mar 2013 11:58:23 -0700
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: 6tsch@ietf.org
References: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>  <5141B51E.3050603@tanu.org> <2FB32E34ED32C44A8D9BCC2E880875E326C0D4A3@AM2PRD0411MB434.eurprd04.prod.outlook.com> <5141C4F5.8040202@tanu.org> <3f5fc7a67dd46651bb8b05da1720f86b.squirrel@calmail.berkeley.edu> <5142373D.9090501@tanu.org>  <9fb6b483e3d071c247c0e3dac2b7692e.squirrel@calmail.berkeley.edu>
In-Reply-To: <9fb6b483e3d071c247c0e3dac2b7692e.squirrel@calmail.berkeley.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 18:58:25 -0000

Hi Qin,
let me add something meanwhile :-)

your point is correct. RSVP/NSIS are used to setup and maintain 
multi-hop paths (tracks in our terminology) according to certain QoS 
requirements. If we think on MPLS/GMPLS, they use a Label Distribution 
Protocol to setup the label that define a path (or mapping between input 
cells an output cells in a particular node in the case of GMPLS), a 
Label Distribution protocol within the MPLS architecture is a generic 
concept that has different implementations, one of them is CR-LDP 
another is RSVP-TE that provides the semantics to carry QoS requirements 
and install labels along the path. For sure that NSIS has been thought 
on that direction although I am not so familiar with it.

What RSVP-TE/NSIS carry in the payload can be used to schedule the links 
along the track so they meet the required bandwidth, this information 
can be defined by a PCE and installed downstream by the RSVP-TE/NSIS 
protocol using the 6tus hardlink interface and some RSVP-TE object that 
can transport the information.

However, if the network does not use a PCE but a distributed approach 
(6tus soft-link approach), nothing prevents to RSVP to carry the actual 
bandwidth requirement and let 6tus install it at each hop along the 
track. So it seems very adequate to use any of these protocols to 
configure 6tus along a multi-hop path.

does this make sense to you?
X

On 15/03/13 10:42, Qin Wang wrote:
> Thomas,
>
> I'm not very clear about the relationship between RSVP/NSIS and PCE. My
> understanding is RSVP/NSIS is used to reserve resource along a multihop
> path, basically by translating the feature of data flow and Qos
> requirement into communication resource reservation. They could be
> centralized or distributed, i.e. with or without PCE. Correct?
>
> Qin
>
>
>> Shoichi, Paul,
>>
>> I agree with Qin's description. I believe we should not close any doors,
>> and allow for different setups:
>> - one "standalone" LLN, or multiple LLNs connected over a backbone
>> - TSCH schedule built by a PCE, or in a distributed way, or a hybrid
>> approach.
>>
>> Paul, in my mind a PCE reserves hard cells, and a distributed protocol
>> soft
>> cells. The distinction is simply related to collisions: if you are certain
>> that the network schedule is collision-free (which we might assume from a
>> PCE), then schedule hard cells. If collisions are possible (e.g. between
>> two independent pairs of nodes), then schedule soft cells, since you need
>> 6tus to monitor them and move one if needed. Of course, one could imagine
>> a
>> hybrid approach, in which both hard and soft cells are present in the
>> network.
>>
>> John has started to investigate protocols such as RSVP or NSIS to reserve
>> cells along a multi-hop path (a track) inside the LLN. In a setup where
>> only this protocol is used for scheduling, the PCE would not be present.
>>
>> I hope this answers your question.
>>
>> Thomas
>>
>> On Thu, Mar 14, 2013 at 1:46 PM, Shoichi Sakane  wrote:
>>
>>> Hi Qin,
>>>
>>> Very clear.  Thanks!
>>>
>>> Shoichi
>>>
>>>
>>> On 3/15/13 1:27 AM, Qin Wang wrote:
>>>
>>>> Hi Shoichi and all,
>>>>
>>>> My understanding is as follows.
>>>>
>>>> (1) The networks which we are talking about could include one LLN or
>>>> multiple LLNs connected by backbone. PCE is a optional device in the
>>>> networks.
>>>>
>>>> (2) If there is PCE, there may be different setting. For example, PCE
>>>> is
>>>> in charge for reserving both multiple hop path (i.e. every next hop
>>>> neighbor) and cells; or PCE is just in charge for reserving the
>>>> multiple
>>>> hop path and leaving cell reservation to local, and the distributed
>>>> cell
>>>> reservation will meet the bandwidth requirement from multiple hop path
>>>> reservation. In the first case, hard cell reservation will be used.
>>>>
>>>> (3)If there is no PCE, both multihop path and cells are reserved in
>>>> local.
>>>> For example, RPL + soft cell reservation in 6tus.
>>>>
>>>> Does it make sense?
>>>>
>>>> Qin
>>>>
>>>>
>>>>   On 3/14/13 9:02 PM, Paul Chilton wrote:
>>>>>> - optionally a PCE sits on the backbone and drives the LLNs' TSCH
>>>>>>> schedules.
>>>>>>>
>>>>> Ah, maybe understood.  It doesn't say that existence of PCE is
>>>>> optional.
>>>>> It says that it's optional to put PCE in the backbone.  It doesn't
>>>>> preclude to put it on BBR.  Correct ?
>>>>>
>>>>> Shoichi
>>>>> ______________________________**_________________
>>>>> 6tsch mailing list
>>>>> 6tsch@ietf.org
>>>>> https://www.ietf.org/mailman/**listinfo/6tsch
>>>>>
>>>>>
>>>> ______________________________**_________________
>>>> 6tsch mailing list
>>>> 6tsch@ietf.org
>>>> https://www.ietf.org/mailman/**listinfo/6tsch
>>>>
>>>>   ______________________________**_________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/**listinfo/6tsch
>>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


From qinwang@berkeley.edu  Fri Mar 15 15:04:19 2013
Return-Path: 
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 B340821F896B for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 15:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 zQJYbiPtzGDy for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 15:04:17 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id D9B5821F86B1 for <6tsch@ietf.org>; Fri, 15 Mar 2013 15:04:17 -0700 (PDT)
Received: from cm01ws.ist.berkeley.edu ([169.229.218.163] helo=calmail.berkeley.edu) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UGcjU-00030b-3c; Fri, 15 Mar 2013 15:04:17 -0700
Received: from 136.152.37.52 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 15 Mar 2013 15:04:12 -0700
Message-ID: 
In-Reply-To: <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>
Date: Fri, 15 Mar 2013 15:04:12 -0700
From: "Qin Wang" 
To: "JeongGil Ko" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: 6tsch@ietf.org, Xavier Vilajosana 
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 22:04:19 -0000

John and Xavi,

I agree that understanding more about upper layer protocols like RSVP and
NSIS is very helpful for designing 6tus. But, I want to make clearer about
my understanding on the relationship between 6tus and existing reservation
protocols like RSVP or NSIS.

(1) When we talk about reservation in the context of 6tus, we mainly focus
on  link resource (i.e. cell) reservation, which is required/ triggered by
upper layer. Even in the pure centralized approach, it may happen to
cross-layer reserve both L3 and L2 resource, but you still can separate
them logically.

(2) The upper layer requirement to 6tus may come from PCE carried by
protocol like CoAP, may come from the RSVP/NSIS entity inside nodes.

Thus, for 6tus, the question is what kind of function and interface should
be provided to support the upper layer, instead of which upper layer
protocol should be used.

How do you think?

Qin




> Exactly my take on this issue. Its really not a matter of using the scheme
> directly (unless we really can, which can be nice) but taking the concepts
> and applying it to match our needs for bandwidth/slot allocation.
>
> Thanks.
>
> -John
>
> ------
> JeongGil Ko, Ph.D.
> Researcher
> Electronics and Telecommunications Research Institute (ETRI)
> http://sites.google.com/site/jeonggilko/
>
> On Mar 14, 2013, at 6:02 PM, Xavier Vilajosana
>  wrote:
>
>> Qin, I think that we need a protocol that is in charge of managing
>> tracks, allocating bandwidth along the track,  monitor that the end to
>> end bandwidth requirement is really accomplished, etc..
>>
>> this is my point.. maybe others can add more reasons..
>>
>> X
>>
>> On 14/03/13 14:57, Qin Wang wrote:
>>> Hi all,
>>>
>>> This may be a silly question: why we investigate various resource
>>> reservation protocols? Do we want to bind 6tus with some resource
>>> reservation protocol, or try to figure out the mandatory functionality
>>> 6tus must provides by investigating those protocols?
>>>
>>> Thanks
>>> Qin
>>>
>>>
>>>> On Mar 14, 2013, at 16:04, Pascal Thubert 
>>>> wrote:
>>>>
>>>>> NSIS
>>>> http://nsis-ka.org says:
>>>>
>>>> GIST: 32,858 LOC
>>>> NSIS: 67,193 LOC
>>>>
>>>> Grüße, Carsten
>>>>
>>>> _______________________________________________
>>>> 6tsch mailing list
>>>> 6tsch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


From qinwang@berkeley.edu  Fri Mar 15 15:46:55 2013
Return-Path: 
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 144AE1F0D0D for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 15:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Ld6M5ZArA6nZ for <6tsch@ietfa.amsl.com>; Fri, 15 Mar 2013 15:46:54 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9931F0D05 for <6tsch@ietf.org>; Fri, 15 Mar 2013 15:46:54 -0700 (PDT)
Received: from cm01ws.ist.berkeley.edu ([169.229.218.163] helo=calmail.berkeley.edu) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UGdOm-0005ro-KB; Fri, 15 Mar 2013 15:46:54 -0700
Received: from 136.152.37.52 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 15 Mar 2013 15:46:52 -0700
Message-ID: <6726ac8924fd02f8542bb7fc34b140f7.squirrel@calmail.berkeley.edu>
In-Reply-To: 
References: <90d5facfcd961deffd839ef420ec84c0.squirrel@calmail.berkeley.edu> <19254A1F-7D2B-4138-9ABD-7D01D76B37AC@gmail.com> <3456ddc71ec69cdbcf5ac7eee86ff00b.squirrel@calmail.berkeley.edu> 
Date: Fri, 15 Mar 2013 15:46:52 -0700
From: "Qin Wang" 
To: "Pascal Thubert (pthubert)" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IETF 6TSCH <6tsch@ietf.org>, Grieco , Qin Wang 
Subject: Re: [6tsch] attributes of data traffic flow
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 22:46:55 -0000

Pascal,

Thanks for your input.

My motivation to raise the question is for the I-MUX and MUX in the data
convey model of 6tus. Right now, we only define the structure of the
model, but we leave the policy of controlling IMUX and MUX as open issues,
e.g. the rule to configure queues, how to dispatch data flows to queues,
which frame should be selected to feed TSCH.

Back one step, I'm not sure if 6tus should specify those policies or not.

Thought?

Qin


> Just to give a perspective,
>
> In frame relay, what a SLA provides for CIR is committed rate
> (guaranteed), excess rate (discard eligible), and a burst size.
>
> Rates can be used to allocate things similar to cells.  Burst can be
> mapped into buffers to be reserved for a particular stream. As you see,
> the CIR expression is designed to be mapped easily by the switch into its
> operation.
>
> Maybe it would be good to keep things simple for motes as well. Whatever
> we feed it to, we need to be clear on what 6TUS does of it. Something
> simple...
>
> Cheers;
>
> Pascal
>
>
> -----Original Message-----
> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of
> Qin Wang
> Sent: vendredi 15 mars 2013 13:12
> To: Grieco
> Cc: IETF 6TSCH; Qin Wang
> Subject: Re: [6tsch] attributes of data traffic flow
>
> I agree!
>
> Qin
>
>
>> Hi Qin, and all
>>
>> Do you think it could be useful to specify the minimum, maximum,
>> average, and standard deviation of the bandwidth requirments for bursty
>> flows ?
>>
>> In this case, the PCE could have a clear picture of the bounds of the
>> aggregated bandwidth demand of the network, thus improving the
>> effectiveness of the schedule it will build.
>>
>> What do you think about ?
>>
>> Cheers
>>
>> Alfredo
>>
>>
>> --
>> Luigi Alfredo Grieco, PhD
>> Assistant Professor
>> Department of Electrical and Information Engineering Politecnico di
>> Bari Via Orabona 4 - 70125 - Bari - Italy
>> +39 080 5963 911
>> telematics.poliba.it/grieco
>> Skype id: l.alfredo.grieco
>> Mobile: +39 3346715672
>>
>>
>> On 15 Mar 2013, at 01:39, "Qin Wang"  wrote:
>>
>>> Hi all,
>>>
>>> In the previous emails, there are several threads related with data
>>> traffic flow or data flow. I think it is important to put them
>>> together and see if there is missing pieces.
>>>
>>> Attributes of data flow:
>>>
>>> (1) Periodicity (T): a integer, T=0 means bursty,  T>0 means the
>>> timeslots in one cycle.
>>>
>>> (2) Bandwidth requirement: number of slots in one cycle if T>0;
>>> number of frames in one burst if T=0.
>>>
>>> (3) Jitters sensitivity : if the data flow is periodical (T >0), then
>>> it reflects the deterministic requirement. if the data flow is bursty
>>> (T=0), then it reflects the end-to-end latency requirement of the
>>> data flow.
>>>
>>> (4)Reliability: e.g. one-hop Data Delivery Rate (PDR)
>>>
>>> Anything else?
>>>
>>> In addition, I think "priority of data flow" is function of these
>>> basic attributes, maybe more. Make sense?
>>>
>>> Qin
>>>
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From pthubert@cisco.com  Sat Mar 16 03:58:05 2013
Return-Path: 
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 9063F21F8AE2 for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 03:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 hFYtvcLvNwa0 for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 03:58:04 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AC79A21F8ACE for <6tsch@ietf.org>; Sat, 16 Mar 2013 03:58:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6804; q=dns/txt; s=iport; t=1363431482; x=1364641082; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NgVVUvRRma5U/fT+QOdreOwXKKMfeliEMOr3usOKaHA=; b=X7WZjdU5YdeN+e72aueJSdugwcAgZ/QrLF2jjoIaLAMxBr4N+v8qnODX g/J3eib6/MRseRV72qWbgiML0DRqpUz2R9+rwmFgTveNNPQgmkKi0O6vM wvVXMC/qy8DlKhXvsFqEpB5CMDp+dLNqbta1h4LN40cDLKpW2Yvp2+EU+ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAH5ORFGtJV2d/2dsb2JhbABDDoggvH5wdxZ0gioBAQEDAQEBASAROgsFBwQCAQgRBAEBAQICBh0DAgICJQsUAQgIAgQBDQUIiAYGDLBwkiSBI41BFhALBwaCJzJhA5JehR+PY4JLP4Io
X-IronPort-AV: E=Sophos;i="4.84,856,1355097600"; d="scan'208";a="187970143"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 16 Mar 2013 10:58:02 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2GAw2v6022247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Mar 2013 10:58:02 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Sat, 16 Mar 2013 05:58:01 -0500
From: "Pascal Thubert (pthubert)" 
To: Qin Wang , "Tom Phinney  (tom.phinney@COX.NET)" 
Thread-Topic: [6tsch] attributes of data traffic flow
Thread-Index: AQHOIc7+aDY/Wm1CCUaYPbNpZOT7S5ioI6mA
Date: Sat, 16 Mar 2013 10:58:00 +0000
Deferred-Delivery: Sat, 16 Mar 2013 10:57:00 +0000
Message-ID: 
References: <90d5facfcd961deffd839ef420ec84c0.squirrel@calmail.berkeley.edu> <19254A1F-7D2B-4138-9ABD-7D01D76B37AC@gmail.com> <3456ddc71ec69cdbcf5ac7eee86ff00b.squirrel@calmail.berkeley.edu>  <6726ac8924fd02f8542bb7fc34b140f7.squirrel@calmail.berkeley.edu>
In-Reply-To: <6726ac8924fd02f8542bb7fc34b140f7.squirrel@calmail.berkeley.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.83.16]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: IETF 6TSCH <6tsch@ietf.org>, Grieco 
Subject: Re: [6tsch] attributes of data traffic flow
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Mar 2013 10:58:05 -0000

SGkgUWluOg0KDQpUaGlzIGlzIHJlYWxseSB3aGVyZSBJJ2QgdGhpbmsgVG9tIHdvdWxkIGJlIG9m
IHRoZSBncmVhdGVzdCBoZWxwIG9uIHlvdXIgZWZmb3J0Lg0KDQpTaW5jZSB3ZSBhcmUgZGVmaW5p
bmcgYSBsYXllciwgd2Ugc2hvdWxkIGRvY3VtZW50IHRoZSBpbi9vdXRzIGluIHRlcm1zIG9mIHNl
cnZpY2UgYWNjZXNzIHBvaW50cyBhbmQgcHJpbWl0aXZlcywgYXMgd2VsbCBhcyB0aGUgb2JzZXJ2
YWJsZSBvdXRjb21lcyBvZiB0cmlnZ2VyaW5nIHRob3NlIHNlcnZpY2VzLiANCg0KVGhlIGRpc2N1
c3Npb24gb2YgaG93IHRoaW5ncyBhcmUgZG9uZSBpbnNpZGUgaXMgb2YgZ3JlYXRlc3QgaW50ZXJl
c3QgYmV0d2VlbiBpbXBsZW1lbnRlcnMgYnV0IG1heSBub3QgZW5kIHVwIGluIHRoZSBzcGVjLiBJ
J20gcHVzaGluZyB0aGF0IGRpc2N1c3Npb24gYmVjYXVzZSBJIHdhbnQgdG8gbWFrZSBzdXJlIHRo
YXQgd2hhdCB3ZSByZXF1aXJlIGZyb20gdGhlIG9ic2VydmFibGUgc3RhbmRwb2ludCBpcyBlYXN5
IHRvIGltcGxlbWVudCBpbiB0aGUgaW5zaWRlLiBFdmVuIHRob3VnaCBpdCB3b3VsZCBiZSBuZWF0
IHRvIHByb3ZpZGUgYWxsIHNvcnRzIG9mIGV4cGVjdGVkIHN0YXRpY3RpY3Mgb24gYSBmbG93LCB0
aGUgNlRVUyBsYXllciBjYW5ub3QgZG8gbXVjaCBvZiBpdC4gDQoNClNvIHdoZW4gaXQgZ29lcyB0
byBob3cgd2UgZXhwcmVzcyB0aGUgdHJhY2sgbWV0cmljcyB0byB0aGUgNlRVUyBsYXllciwgSSdk
IHByb2JhYmx5IHN0YXJ0IGZyb20gd2hhdCB0aGUgNlRVUyBsYXllciBjYW4gZG8uIFRoYXQgaXMs
IGFsbG9jYXRlIGNlbGxzLCBhZGQvcmVtb3ZlIGNlbGxzIGR5bmFtaWNhbGx5LCBjb21wdXRlIGEg
bGF0ZW5jeSBiZXR3ZWVuIGluY29taW5nIGFuZCBvdXRnb2luZyBjZWxscywgYnVmZmVyIGEgYnVy
c3QgcGVuZGluZyBmb3J3YXJkaW5nLCB0aGF0IHNvcnQgb2YgdGhpbmcuIEZyb20gdGhlcmUsIHdl
IGNhbiBkZXJpdmUgdGhlIG1ldHJpY3MgYW5kIGNvbnN0cmFpbnRzIHRoYXQgNlRVUyBjYW4gbWFu
aXB1bGF0ZSBhbmQgZXhjaGFuZ2UgdGhhdCBvdmVyIFJTVlAgb3IgcGNlcC4NCg0KV2hlbiBpdCBj
b21lcyB0byB0aGUgUENFLCB5ZXMsIHdlIGNvdWxkIGRlc2NyaWJlIHRoZSBmbG93cyBpbiBtb3Jl
IGNvbXBsZXggYW5kIGFic3RyYWN0IGZhc2hpb24uIEJ1dCBpdCB3aWxsIGhhdmUgdG8gdHVybiB0
aGF0IGludG8gc29tZXRoaW5nIHRoYXQgNlRVUyBjYW4gZGlnZXN0LCB0aGF0IGlzIHRoZSBhYm92
ZS4NCg0KTWFrZXMgc2Vuc2U/DQoNClBhc2NhbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KRnJvbTogUWluIFdhbmcgW21haWx0bzpxaW53YW5nQGJlcmtlbGV5LmVkdV0gDQpTZW50OiB2
ZW5kcmVkaSAxNSBtYXJzIDIwMTMgMTg6NDcNClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQp
DQpDYzogUWluIFdhbmc7IEdyaWVjbzsgSUVURiA2VFNDSA0KU3ViamVjdDogUkU6IFs2dHNjaF0g
YXR0cmlidXRlcyBvZiBkYXRhIHRyYWZmaWMgZmxvdw0KDQpQYXNjYWwsDQoNClRoYW5rcyBmb3Ig
eW91ciBpbnB1dC4NCg0KTXkgbW90aXZhdGlvbiB0byByYWlzZSB0aGUgcXVlc3Rpb24gaXMgZm9y
IHRoZSBJLU1VWCBhbmQgTVVYIGluIHRoZSBkYXRhIGNvbnZleSBtb2RlbCBvZiA2dHVzLiBSaWdo
dCBub3csIHdlIG9ubHkgZGVmaW5lIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIG1vZGVsLCBidXQgd2Ug
bGVhdmUgdGhlIHBvbGljeSBvZiBjb250cm9sbGluZyBJTVVYIGFuZCBNVVggYXMgb3BlbiBpc3N1
ZXMsIGUuZy4gdGhlIHJ1bGUgdG8gY29uZmlndXJlIHF1ZXVlcywgaG93IHRvIGRpc3BhdGNoIGRh
dGEgZmxvd3MgdG8gcXVldWVzLCB3aGljaCBmcmFtZSBzaG91bGQgYmUgc2VsZWN0ZWQgdG8gZmVl
ZCBUU0NILg0KDQpCYWNrIG9uZSBzdGVwLCBJJ20gbm90IHN1cmUgaWYgNnR1cyBzaG91bGQgc3Bl
Y2lmeSB0aG9zZSBwb2xpY2llcyBvciBub3QuDQoNClRob3VnaHQ/DQoNClFpbg0KDQoNCj4gSnVz
dCB0byBnaXZlIGEgcGVyc3BlY3RpdmUsDQo+DQo+IEluIGZyYW1lIHJlbGF5LCB3aGF0IGEgU0xB
IHByb3ZpZGVzIGZvciBDSVIgaXMgY29tbWl0dGVkIHJhdGUgDQo+IChndWFyYW50ZWVkKSwgZXhj
ZXNzIHJhdGUgKGRpc2NhcmQgZWxpZ2libGUpLCBhbmQgYSBidXJzdCBzaXplLg0KPg0KPiBSYXRl
cyBjYW4gYmUgdXNlZCB0byBhbGxvY2F0ZSB0aGluZ3Mgc2ltaWxhciB0byBjZWxscy4gIEJ1cnN0
IGNhbiBiZSANCj4gbWFwcGVkIGludG8gYnVmZmVycyB0byBiZSByZXNlcnZlZCBmb3IgYSBwYXJ0
aWN1bGFyIHN0cmVhbS4gQXMgeW91IA0KPiBzZWUsIHRoZSBDSVIgZXhwcmVzc2lvbiBpcyBkZXNp
Z25lZCB0byBiZSBtYXBwZWQgZWFzaWx5IGJ5IHRoZSBzd2l0Y2ggDQo+IGludG8gaXRzIG9wZXJh
dGlvbi4NCj4NCj4gTWF5YmUgaXQgd291bGQgYmUgZ29vZCB0byBrZWVwIHRoaW5ncyBzaW1wbGUg
Zm9yIG1vdGVzIGFzIHdlbGwuIA0KPiBXaGF0ZXZlciB3ZSBmZWVkIGl0IHRvLCB3ZSBuZWVkIHRv
IGJlIGNsZWFyIG9uIHdoYXQgNlRVUyBkb2VzIG9mIGl0LiANCj4gU29tZXRoaW5nIHNpbXBsZS4u
Lg0KPg0KPiBDaGVlcnM7DQo+DQo+IFBhc2NhbA0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KPiBGcm9tOiA2dHNjaC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86NnRzY2gtYm91
bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIA0KPiBPZiBRaW4gV2FuZw0KPiBTZW50OiB2ZW5kcmVk
aSAxNSBtYXJzIDIwMTMgMTM6MTINCj4gVG86IEdyaWVjbw0KPiBDYzogSUVURiA2VFNDSDsgUWlu
IFdhbmcNCj4gU3ViamVjdDogUmU6IFs2dHNjaF0gYXR0cmlidXRlcyBvZiBkYXRhIHRyYWZmaWMg
Zmxvdw0KPg0KPiBJIGFncmVlIQ0KPg0KPiBRaW4NCj4NCj4NCj4+IEhpIFFpbiwgYW5kIGFsbA0K
Pj4NCj4+IERvIHlvdSB0aGluayBpdCBjb3VsZCBiZSB1c2VmdWwgdG8gc3BlY2lmeSB0aGUgbWlu
aW11bSwgbWF4aW11bSwgDQo+PiBhdmVyYWdlLCBhbmQgc3RhbmRhcmQgZGV2aWF0aW9uIG9mIHRo
ZSBiYW5kd2lkdGggcmVxdWlybWVudHMgZm9yIA0KPj4gYnVyc3R5IGZsb3dzID8NCj4+DQo+PiBJ
biB0aGlzIGNhc2UsIHRoZSBQQ0UgY291bGQgaGF2ZSBhIGNsZWFyIHBpY3R1cmUgb2YgdGhlIGJv
dW5kcyBvZiB0aGUgDQo+PiBhZ2dyZWdhdGVkIGJhbmR3aWR0aCBkZW1hbmQgb2YgdGhlIG5ldHdv
cmssIHRodXMgaW1wcm92aW5nIHRoZSANCj4+IGVmZmVjdGl2ZW5lc3Mgb2YgdGhlIHNjaGVkdWxl
IGl0IHdpbGwgYnVpbGQuDQo+Pg0KPj4gV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgPw0KPj4NCj4+
IENoZWVycw0KPj4NCj4+IEFsZnJlZG8NCj4+DQo+Pg0KPj4gLS0NCj4+IEx1aWdpIEFsZnJlZG8g
R3JpZWNvLCBQaEQNCj4+IEFzc2lzdGFudCBQcm9mZXNzb3INCj4+IERlcGFydG1lbnQgb2YgRWxl
Y3RyaWNhbCBhbmQgSW5mb3JtYXRpb24gRW5naW5lZXJpbmcgUG9saXRlY25pY28gZGkgDQo+PiBC
YXJpIFZpYSBPcmFib25hIDQgLSA3MDEyNSAtIEJhcmkgLSBJdGFseQ0KPj4gKzM5IDA4MCA1OTYz
IDkxMQ0KPj4gdGVsZW1hdGljcy5wb2xpYmEuaXQvZ3JpZWNvDQo+PiBTa3lwZSBpZDogbC5hbGZy
ZWRvLmdyaWVjbw0KPj4gTW9iaWxlOiArMzkgMzM0NjcxNTY3Mg0KPj4NCj4+DQo+PiBPbiAxNSBN
YXIgMjAxMywgYXQgMDE6MzksICJRaW4gV2FuZyIgPHFpbndhbmdAYmVya2VsZXkuZWR1PiB3cm90
ZToNCj4+DQo+Pj4gSGkgYWxsLA0KPj4+DQo+Pj4gSW4gdGhlIHByZXZpb3VzIGVtYWlscywgdGhl
cmUgYXJlIHNldmVyYWwgdGhyZWFkcyByZWxhdGVkIHdpdGggZGF0YSANCj4+PiB0cmFmZmljIGZs
b3cgb3IgZGF0YSBmbG93LiBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBwdXQgdGhlbSANCj4+
PiB0b2dldGhlciBhbmQgc2VlIGlmIHRoZXJlIGlzIG1pc3NpbmcgcGllY2VzLg0KPj4+DQo+Pj4g
QXR0cmlidXRlcyBvZiBkYXRhIGZsb3c6DQo+Pj4NCj4+PiAoMSkgUGVyaW9kaWNpdHkgKFQpOiBh
IGludGVnZXIsIFQ9MCBtZWFucyBidXJzdHksICBUPjAgbWVhbnMgdGhlIA0KPj4+IHRpbWVzbG90
cyBpbiBvbmUgY3ljbGUuDQo+Pj4NCj4+PiAoMikgQmFuZHdpZHRoIHJlcXVpcmVtZW50OiBudW1i
ZXIgb2Ygc2xvdHMgaW4gb25lIGN5Y2xlIGlmIFQ+MDsgDQo+Pj4gbnVtYmVyIG9mIGZyYW1lcyBp
biBvbmUgYnVyc3QgaWYgVD0wLg0KPj4+DQo+Pj4gKDMpIEppdHRlcnMgc2Vuc2l0aXZpdHkgOiBp
ZiB0aGUgZGF0YSBmbG93IGlzIHBlcmlvZGljYWwgKFQgPjApLCANCj4+PiB0aGVuIGl0IHJlZmxl
Y3RzIHRoZSBkZXRlcm1pbmlzdGljIHJlcXVpcmVtZW50LiBpZiB0aGUgZGF0YSBmbG93IGlzIA0K
Pj4+IGJ1cnN0eSAoVD0wKSwgdGhlbiBpdCByZWZsZWN0cyB0aGUgZW5kLXRvLWVuZCBsYXRlbmN5
IHJlcXVpcmVtZW50IG9mIA0KPj4+IHRoZSBkYXRhIGZsb3cuDQo+Pj4NCj4+PiAoNClSZWxpYWJp
bGl0eTogZS5nLiBvbmUtaG9wIERhdGEgRGVsaXZlcnkgUmF0ZSAoUERSKQ0KPj4+DQo+Pj4gQW55
dGhpbmcgZWxzZT8NCj4+Pg0KPj4+IEluIGFkZGl0aW9uLCBJIHRoaW5rICJwcmlvcml0eSBvZiBk
YXRhIGZsb3ciIGlzIGZ1bmN0aW9uIG9mIHRoZXNlIA0KPj4+IGJhc2ljIGF0dHJpYnV0ZXMsIG1h
eWJlIG1vcmUuIE1ha2Ugc2Vuc2U/DQo+Pj4NCj4+PiBRaW4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IDZ0c2No
IG1haWxpbmcgbGlzdA0KPj4+IDZ0c2NoQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby82dHNjaA0KPj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gNnRzY2ggbWFpbGluZyBsaXN0DQo+IDZ0
c2NoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRz
Y2gNCj4NCg0KDQo=

From pthubert@cisco.com  Sat Mar 16 04:06:05 2013
Return-Path: 
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 7FB7A21F8ACE for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 04:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 5DJwBPpod-iH for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 04:06:04 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 791A321F8AA0 for <6tsch@ietf.org>; Sat, 16 Mar 2013 04:06:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5740; q=dns/txt; s=iport; t=1363431964; x=1364641564; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ORJ9D8mRsjzJ77LqL3bjNPSwoYwC3m3Q+yiRNyLhGj8=; b=UPNvZF3eK/ZR5KqU0eLRSM9r2ptXEuTWcr7lxhUcps8zgwjl1iza5jJl D0r/ppZ/0AYjphTnrBg4iRkQavfQK7nwXz6eDJbkrzupat+HwJ5u/pSQp erodWWA0VtBTB7Ebplcu2zoXXveUq3o6ACSMnhjIf9X7ycEheSwVykeRl U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFAD9RRFGtJV2c/2dsb2JhbABDDoggu3WBCXB3FnSCKgEBAQMBAQEBIBEzBwQHBQcEAgEGAhEEAQEBAgIGHQMCAgIfBgsUAQgIAgQBDQUIh3oDCQYMlW+bA4g8DYlbgSOLKYIYFhALBwaCJzJhA5R+gn+KSYUagks/gig
X-IronPort-AV: E=Sophos;i="4.84,856,1355097600"; d="scan'208";a="188227053"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 16 Mar 2013 11:06:04 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2GB63Lw032013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Mar 2013 11:06:03 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Sat, 16 Mar 2013 06:05:53 -0500
From: "Pascal Thubert (pthubert)" 
To: Qin Wang , JeongGil Ko 
Thread-Topic: [6tsch] Schemes for resource allocation in the LLN for 6tus
Thread-Index: AQHOIckNpk1UL3O2oEa0pOrhD3eYrJioJmRA
Date: Sat, 16 Mar 2013 11:05:52 +0000
Deferred-Delivery: Sat, 16 Mar 2013 11:05:00 +0000
Message-ID: 
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.83.16]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "6tsch@ietf.org" <6tsch@ietf.org>, Xavier Vilajosana 
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Mar 2013 11:06:05 -0000

SGkgUWluOg0KDQpJIHRoaW5rIHdlIGFyZSBvbiB0aGUgc2FtZSBsaW5lLiBUaGUgc2VydmljZXMg
dGhhdCA2VFVTIHByb3Bvc2VzIGRvIG5vdCBkZXBlbmQgb24gd2hpY2ggcHJvdG9jb2wgdGhlIHJl
cXVlc3QgY2FtZSBpbiB0aHJvdWdoLg0KU2luY2Ugd2UgYXJlIGRlZmluaW5nIHRoZSBwcm90b2Nv
bCBleHRlbnNpb25zLCB3ZSdsbCBtYWtlIHN1cmUgdGhhdCB0aGUgbmV3IGluZm9ybWF0aW9uIGlz
IGRpcmVjdGx5IGRpZ2VzdGlibGUgYnkgdGhlIDZUVVMgbGF5ZXIuDQpUaGUgcHJvdG9jb2wgZXh0
ZW5zaW9ucyB3aWxsIGJlIHNlcGFyYXRlIHNwZWNzLCBhbmQgdGhlcmUgc2hvdWxkIGJlIGxpdHRs
ZSB0byBubyBkZXJlZmVyZW5jZSBiZXR3ZWVuIHRob3NlIHNwZWNzIGFuZCB5b3Vycy4NCg0KV2hh
dCdzIGltcG9ydGFudCB0byBtZSB0byBkaXNjdXNzIGlzIGhvdyB3ZSBlc3RhYmxpc2ggYSBidW5k
bGUgb2YgY2VsbHMgYmV0d2VlbiBBIGFuZCBCLg0KSU1ITywgaXQgd291bGQgYmUgYmVzdCBpZiB0
aGF0IGNhbiBiZSBhY2hpZXZlZCBieSB0cmlnZ2VyaW5nIGEgc2VydmljZSBpbiBBIC0gbm8gbmVl
ZCB0byB0cmlnZ2VyIEIgYXMgd2VsbC4NClRoYXQgd2F5LCB0aGUgdm9sdW1lIG9mIGV4Y2hhbmdl
cyBiZXR3ZWVuIFBDRSBhbmQgbm9kZXMgY2FuIGJlIGRldmlkZWQgYnkgMi4NCg0KVGhpcyB3b3Vs
ZCBtZWFuIHRoYXQgdGhlcmUgbXVzdCBiZSBhbiBleGNoYW5nZSBiZXR3ZWVuIDZUVVMgaW4gQSBh
bmQgNlRVUyBpbiBCLiANCldoaWNoICBhbHNvIHdvdWxkIG1lYW4gdGhhdCB0aGVyZSBpcyBhIHBy
b3RvY29sIHBhcnQgcmVsYXRlZCB0byA2VFVTLi4uDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IDZ0c2NoLWJvdW5jZXNAaWV0Zi5vcmcg
W21haWx0bzo2dHNjaC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUWluIFdhbmcNClNl
bnQ6IHZlbmRyZWRpIDE1IG1hcnMgMjAxMyAxODowNA0KVG86IEplb25nR2lsIEtvDQpDYzogNnRz
Y2hAaWV0Zi5vcmc7IFhhdmllciBWaWxham9zYW5hDQpTdWJqZWN0OiBSZTogWzZ0c2NoXSBTY2hl
bWVzIGZvciByZXNvdXJjZSBhbGxvY2F0aW9uIGluIHRoZSBMTE4gZm9yIDZ0dXMNCg0KSm9obiBh
bmQgWGF2aSwNCg0KSSBhZ3JlZSB0aGF0IHVuZGVyc3RhbmRpbmcgbW9yZSBhYm91dCB1cHBlciBs
YXllciBwcm90b2NvbHMgbGlrZSBSU1ZQIGFuZCBOU0lTIGlzIHZlcnkgaGVscGZ1bCBmb3IgZGVz
aWduaW5nIDZ0dXMuIEJ1dCwgSSB3YW50IHRvIG1ha2UgY2xlYXJlciBhYm91dCBteSB1bmRlcnN0
YW5kaW5nIG9uIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiA2dHVzIGFuZCBleGlzdGluZyByZXNl
cnZhdGlvbiBwcm90b2NvbHMgbGlrZSBSU1ZQIG9yIE5TSVMuDQoNCigxKSBXaGVuIHdlIHRhbGsg
YWJvdXQgcmVzZXJ2YXRpb24gaW4gdGhlIGNvbnRleHQgb2YgNnR1cywgd2UgbWFpbmx5IGZvY3Vz
IG9uICBsaW5rIHJlc291cmNlIChpLmUuIGNlbGwpIHJlc2VydmF0aW9uLCB3aGljaCBpcyByZXF1
aXJlZC8gdHJpZ2dlcmVkIGJ5IHVwcGVyIGxheWVyLiBFdmVuIGluIHRoZSBwdXJlIGNlbnRyYWxp
emVkIGFwcHJvYWNoLCBpdCBtYXkgaGFwcGVuIHRvIGNyb3NzLWxheWVyIHJlc2VydmUgYm90aCBM
MyBhbmQgTDIgcmVzb3VyY2UsIGJ1dCB5b3Ugc3RpbGwgY2FuIHNlcGFyYXRlIHRoZW0gbG9naWNh
bGx5Lg0KDQooMikgVGhlIHVwcGVyIGxheWVyIHJlcXVpcmVtZW50IHRvIDZ0dXMgbWF5IGNvbWUg
ZnJvbSBQQ0UgY2FycmllZCBieSBwcm90b2NvbCBsaWtlIENvQVAsIG1heSBjb21lIGZyb20gdGhl
IFJTVlAvTlNJUyBlbnRpdHkgaW5zaWRlIG5vZGVzLg0KDQpUaHVzLCBmb3IgNnR1cywgdGhlIHF1
ZXN0aW9uIGlzIHdoYXQga2luZCBvZiBmdW5jdGlvbiBhbmQgaW50ZXJmYWNlIHNob3VsZCBiZSBw
cm92aWRlZCB0byBzdXBwb3J0IHRoZSB1cHBlciBsYXllciwgaW5zdGVhZCBvZiB3aGljaCB1cHBl
ciBsYXllciBwcm90b2NvbCBzaG91bGQgYmUgdXNlZC4NCg0KSG93IGRvIHlvdSB0aGluaz8NCg0K
UWluDQoNCg0KDQoNCj4gRXhhY3RseSBteSB0YWtlIG9uIHRoaXMgaXNzdWUuIEl0cyByZWFsbHkg
bm90IGEgbWF0dGVyIG9mIHVzaW5nIHRoZSANCj4gc2NoZW1lIGRpcmVjdGx5ICh1bmxlc3Mgd2Ug
cmVhbGx5IGNhbiwgd2hpY2ggY2FuIGJlIG5pY2UpIGJ1dCB0YWtpbmcgDQo+IHRoZSBjb25jZXB0
cyBhbmQgYXBwbHlpbmcgaXQgdG8gbWF0Y2ggb3VyIG5lZWRzIGZvciBiYW5kd2lkdGgvc2xvdCBh
bGxvY2F0aW9uLg0KPg0KPiBUaGFua3MuDQo+DQo+IC1Kb2huDQo+DQo+IC0tLS0tLQ0KPiBKZW9u
Z0dpbCBLbywgUGguRC4NCj4gUmVzZWFyY2hlcg0KPiBFbGVjdHJvbmljcyBhbmQgVGVsZWNvbW11
bmljYXRpb25zIFJlc2VhcmNoIEluc3RpdHV0ZSAoRVRSSSkgDQo+IGh0dHA6Ly9zaXRlcy5nb29n
bGUuY29tL3NpdGUvamVvbmdnaWxrby8NCj4NCj4gT24gTWFyIDE0LCAyMDEzLCBhdCA2OjAyIFBN
LCBYYXZpZXIgVmlsYWpvc2FuYSANCj4gPHh2aWxham9zYW5hQGVlY3MuYmVya2VsZXkuZWR1PiB3
cm90ZToNCj4NCj4+IFFpbiwgSSB0aGluayB0aGF0IHdlIG5lZWQgYSBwcm90b2NvbCB0aGF0IGlz
IGluIGNoYXJnZSBvZiBtYW5hZ2luZyANCj4+IHRyYWNrcywgYWxsb2NhdGluZyBiYW5kd2lkdGgg
YWxvbmcgdGhlIHRyYWNrLCAgbW9uaXRvciB0aGF0IHRoZSBlbmQgDQo+PiB0byBlbmQgYmFuZHdp
ZHRoIHJlcXVpcmVtZW50IGlzIHJlYWxseSBhY2NvbXBsaXNoZWQsIGV0Yy4uDQo+Pg0KPj4gdGhp
cyBpcyBteSBwb2ludC4uIG1heWJlIG90aGVycyBjYW4gYWRkIG1vcmUgcmVhc29ucy4uDQo+Pg0K
Pj4gWA0KPj4NCj4+IE9uIDE0LzAzLzEzIDE0OjU3LCBRaW4gV2FuZyB3cm90ZToNCj4+PiBIaSBh
bGwsDQo+Pj4NCj4+PiBUaGlzIG1heSBiZSBhIHNpbGx5IHF1ZXN0aW9uOiB3aHkgd2UgaW52ZXN0
aWdhdGUgdmFyaW91cyByZXNvdXJjZSANCj4+PiByZXNlcnZhdGlvbiBwcm90b2NvbHM/IERvIHdl
IHdhbnQgdG8gYmluZCA2dHVzIHdpdGggc29tZSByZXNvdXJjZSANCj4+PiByZXNlcnZhdGlvbiBw
cm90b2NvbCwgb3IgdHJ5IHRvIGZpZ3VyZSBvdXQgdGhlIG1hbmRhdG9yeSANCj4+PiBmdW5jdGlv
bmFsaXR5IDZ0dXMgbXVzdCBwcm92aWRlcyBieSBpbnZlc3RpZ2F0aW5nIHRob3NlIHByb3RvY29s
cz8NCj4+Pg0KPj4+IFRoYW5rcw0KPj4+IFFpbg0KPj4+DQo+Pj4NCj4+Pj4gT24gTWFyIDE0LCAy
MDEzLCBhdCAxNjowNCwgUGFzY2FsIFRodWJlcnQgDQo+Pj4+IDxwYXNjYWwudGh1YmVydEBnbWFp
bC5jb20+DQo+Pj4+IHdyb3RlOg0KPj4+Pg0KPj4+Pj4gTlNJUw0KPj4+PiBodHRwOi8vbnNpcy1r
YS5vcmcgc2F5czoNCj4+Pj4NCj4+Pj4gR0lTVDogMzIsODU4IExPQw0KPj4+PiBOU0lTOiA2Nywx
OTMgTE9DDQo+Pj4+DQo+Pj4+IEdyw7zDn2UsIENhcnN0ZW4NCj4+Pj4NCj4+Pj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gNnRzY2ggbWFpbGlu
ZyBsaXN0DQo+Pj4+IDZ0c2NoQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vNnRzY2gNCj4+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gNnRzY2ggbWFpbGluZyBsaXN0DQo+Pj4g
NnRzY2hAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
LzZ0c2NoDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4+IDZ0c2NoIG1haWxpbmcgbGlzdA0KPj4gNnRzY2hAaWV0Zi5vcmcNCj4+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRzY2gNCj4NCj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gNnRzY2ggbWFpbGluZyBsaXN0
DQo+IDZ0c2NoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vNnRzY2gNCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCjZ0c2NoIG1haWxpbmcgbGlzdA0KNnRzY2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRzY2gNCg==

From pthubert@cisco.com  Sat Mar 16 04:22:35 2013
Return-Path: 
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 09DC821F8B18 for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 04:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 wbgihttQgfWy for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 04:22:34 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4F69521F8AF4 for <6tsch@ietf.org>; Sat, 16 Mar 2013 04:22:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1729; q=dns/txt; s=iport; t=1363432954; x=1364642554; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RAQ49ohkkOFKHbmmybMGGRpALeQOkgCl97gi2z6OTDs=; b=MYa7DUxesVVHe+uho/xeCePdJfRfl7vk60MuHFrMYXJshKXXis8RX2Dt KDTrVzdt1L6DvKARFr5/PqMYLFN95OALd2PoeWhbV5qig0VMkGvgDqbpd xjmzyKQJKS/wmSLQNltf4hIRwi3w1iL3fN+wNLyFKbw80u2j+v4Nvt0OB I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAI9VRFGtJV2d/2dsb2JhbABDxSyBZxZ0gioBAQEEAQEBaxcEAgEIDgMEAQELHQcnCxQJCAIEARIIiAwMwxAEjmQmEgaCWWEDiD+fIYMKgig
X-IronPort-AV: E=Sophos;i="4.84,856,1355097600"; d="scan'208";a="185193830"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 16 Mar 2013 11:22:18 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2GBMIsK002886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Mar 2013 11:22:18 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Sat, 16 Mar 2013 06:22:17 -0500
From: "Pascal Thubert (pthubert)" 
To: Carsten Bormann , IETF 6TSCH <6tsch@ietf.org>
Thread-Topic: [6tsch] Scope: 6LoWPAN + 1
Thread-Index: AQHOIAhSfPh5bGbEm0Sm4PqUfJNYM5ioLOWg
Date: Sat, 16 Mar 2013 11:22:16 +0000
Deferred-Delivery: Sat, 16 Mar 2013 11:21:00 +0000
Message-ID: 
References: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>
In-Reply-To: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.83.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Mar 2013 11:22:35 -0000

Hi Carsten:

As you figure, this looks like a yes for all your bullets but a no for RSVP=
. We need a reservation protocol inside the DODAG, that's for sure.
We might even end up reserving between one DODAG and another across the bac=
kbone, let's see what the charter discussion says about that.

In that case, the deterministic backbone would have to interpret the RSVP/P=
CEP extensions into an IEEE flow reservation across the switch fabric.
This is where we're interested in following what IEEE TSN does and how it i=
s done it from a reasonably safe distance.
The assumption is that they are operating on a time scale that is 2+ orders=
 of magnitude more precise than ours.=20
This assumptions makes the backbone step negligible in terms of jitter and =
latency as a first approximation.

Cheers,

Pascal


-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of C=
arsten Bormann
Sent: mercredi 13 mars 2013 12:32
To: IETF 6TSCH
Subject: [6tsch] Scope: 6LoWPAN + 1

So, my take of the discussion we just had:

-- This is focused on the 6LoWPAN and the TSCH configuration within that
-- Packets will also need to make one IP hop outside the 6LoWPAN, let's cal=
l that the backbone
-- The backbone could be 802.1TSN style (~ Ethernet)
-- Setting the DSCP to ~ EF, doing the admission control for that, and poss=
ibly some 802.1TSN setup, is mostly all that we need in the backbone

That would simplify things by taking RSVP out of the picture and taking mor=
e of a diffserv approach.

Gr=FC=DFe, Carsten

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

From qinwang@berkeley.edu  Sat Mar 16 16:19:43 2013
Return-Path: 
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 6020E21F863A for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 16:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4]
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 1512OAtrlDSL for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 16:19:42 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFC921F861F for <6tsch@ietf.org>; Sat, 16 Mar 2013 16:19:42 -0700 (PDT)
Received: from cm04ws.ist.berkeley.edu ([169.229.218.166] helo=calmail.berkeley.edu) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UH0O3-0000dQ-CB; Sat, 16 Mar 2013 16:19:41 -0700
Received: from 174.234.69.71 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Sat, 16 Mar 2013 16:19:39 -0700
Message-ID: <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu>
In-Reply-To: 
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>  
Date: Sat, 16 Mar 2013 16:19:39 -0700
From: "Qin Wang" 
To: "Pascal Thubert (pthubert)" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "6tsch@ietf.org" <6tsch@ietf.org>, JeongGil Ko , Qin Wang , Xavier Vilajosana 
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Mar 2013 23:19:43 -0000

Hi Pascal,

It is a very good idea to establish a bundle of cells between A and B by
just triggering 6tus in one side. We can design for different scenarios.

(1) PCE defines the track, i.e. the multihop path, the bandwidth of each
hop, and scheduling hard-cells to implement the multihop path. Assume
nodeA and nodeB are one-hop neighbors along the path. In this case, PCE
can send Create.hardcell command to 6tus layer in nodeA,and nodeA's 6tus
sends Create.hardcell command to nodeB' 6tus, then the hard cell is
reserved. This function is not in the current version of 6tus draft, but
we can add it in the next version easily.

(2)PCE defines the multihop path and the bandwidth of each hop, but not
schedules the cells to meet the path bandwidth. In this case, soft cell
reservation will be applied, which is always triggered in Transmitting
side, and negotiated by the 6tus layer of both sides.

(3)The cell reservation is triggered by upper layer, e.g. the RSVP/NSIS
entity in nodeA. Then soft cell reservation process in 6tus layer of nodeA
will by triggered, and the negotiation process is same as case (2).

In summary, by adding reserve hard cell procedure into version-00 of 6tus,
we can let the bundle reservation in every scenarios be triggered just in
one side.

How do you think?

Qin




> Hi Qin:
>
> I think we are on the same line. The services that 6TUS proposes do not
> depend on which protocol the request came in through.
> Since we are defining the protocol extensions, we'll make sure that the
> new information is directly digestible by the 6TUS layer.
> The protocol extensions will be separate specs, and there should be little
> to no dereference between those specs and yours.
>
> What's important to me to discuss is how we establish a bundle of cells
> between A and B.
> IMHO, it would be best if that can be achieved by triggering a service in
> A - no need to trigger B as well.
> That way, the volume of exchanges between PCE and nodes can be devided by
> 2.
>
> This would mean that there must be an exchange between 6TUS in A and 6TUS
> in B.
> Which  also would mean that there is a protocol part related to 6TUS...
>
> Cheers,
>
> Pascal
>
>
> -----Original Message-----
> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of
> Qin Wang
> Sent: vendredi 15 mars 2013 18:04
> To: JeongGil Ko
> Cc: 6tsch@ietf.org; Xavier Vilajosana
> Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
>
> John and Xavi,
>
> I agree that understanding more about upper layer protocols like RSVP and
> NSIS is very helpful for designing 6tus. But, I want to make clearer about
> my understanding on the relationship between 6tus and existing reservation
> protocols like RSVP or NSIS.
>
> (1) When we talk about reservation in the context of 6tus, we mainly focus
> on  link resource (i.e. cell) reservation, which is required/ triggered by
> upper layer. Even in the pure centralized approach, it may happen to
> cross-layer reserve both L3 and L2 resource, but you still can separate
> them logically.
>
> (2) The upper layer requirement to 6tus may come from PCE carried by
> protocol like CoAP, may come from the RSVP/NSIS entity inside nodes.
>
> Thus, for 6tus, the question is what kind of function and interface should
> be provided to support the upper layer, instead of which upper layer
> protocol should be used.
>
> How do you think?
>
> Qin
>
>
>
>
>> Exactly my take on this issue. Its really not a matter of using the
>> scheme directly (unless we really can, which can be nice) but taking
>> the concepts and applying it to match our needs for bandwidth/slot
>> allocation.
>>
>> Thanks.
>>
>> -John
>>
>> ------
>> JeongGil Ko, Ph.D.
>> Researcher
>> Electronics and Telecommunications Research Institute (ETRI)
>> http://sites.google.com/site/jeonggilko/
>>
>> On Mar 14, 2013, at 6:02 PM, Xavier Vilajosana
>>  wrote:
>>
>>> Qin, I think that we need a protocol that is in charge of managing
>>> tracks, allocating bandwidth along the track,  monitor that the end
>>> to end bandwidth requirement is really accomplished, etc..
>>>
>>> this is my point.. maybe others can add more reasons..
>>>
>>> X
>>>
>>> On 14/03/13 14:57, Qin Wang wrote:
>>>> Hi all,
>>>>
>>>> This may be a silly question: why we investigate various resource
>>>> reservation protocols? Do we want to bind 6tus with some resource
>>>> reservation protocol, or try to figure out the mandatory
>>>> functionality 6tus must provides by investigating those protocols?
>>>>
>>>> Thanks
>>>> Qin
>>>>
>>>>
>>>>> On Mar 14, 2013, at 16:04, Pascal Thubert
>>>>> 
>>>>> wrote:
>>>>>
>>>>>> NSIS
>>>>> http://nsis-ka.org says:
>>>>>
>>>>> GIST: 32,858 LOC
>>>>> NSIS: 67,193 LOC
>>>>>
>>>>> Grüße, Carsten
>>>>>
>>>>> _______________________________________________
>>>>> 6tsch mailing list
>>>>> 6tsch@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>>>
>>>>
>>>> _______________________________________________
>>>> 6tsch mailing list
>>>> 6tsch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From cabo@tzi.org  Sat Mar 16 17:45:57 2013
Return-Path: 
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 CFB1D21F8556 for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 17:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 3CO98iIA0PlL for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 17:45:55 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5D55C21F8555 for <6tsch@ietf.org>; Sat, 16 Mar 2013 17:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2H0jVcW019969; Sun, 17 Mar 2013 01:45:32 +0100 (CET)
Received: from [192.168.217.105] (p54893062.dip.t-dialin.net [84.137.48.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 614763ECB; Sun, 17 Mar 2013 01:45:31 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
X-Priority: 3 (Normal)
In-Reply-To: <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu>
Date: Sun, 17 Mar 2013 01:45:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu>
To: "Qin Wang" 
X-Mailer: Apple Mail (2.1503)
Cc: "Pascal Thubert \(pthubert\)" , "6tsch@ietf.org" <6tsch@ietf.org>, Xavier Vilajosana , JeongGil Ko 
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Mar 2013 00:45:57 -0000

On Mar 17, 2013, at 00:19, "Qin Wang"  wrote:

> scenarios

I think it is good to look at all these scenarios.
But please let's then select a small subset that we actually do.

I don't know how it is better to have half of your state set up by the =
god box ("PCE") and half of it by neighbors.  I can think of so many =
interesting race conditions here...

Simplify, simplify, simplify.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Sat Mar 16 18:25:40 2013
Return-Path: 
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 11D7421F8566 for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 18:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 3rrtqaLa4Un2 for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 18:25:39 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCE721F855C for <6tsch@ietf.org>; Sat, 16 Mar 2013 18:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2H1PVHo027081; Sun, 17 Mar 2013 02:25:31 +0100 (CET)
Received: from [192.168.217.105] (p54893062.dip.t-dialin.net [84.137.48.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3F1653ECC; Sun, 17 Mar 2013 02:25:31 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Sun, 17 Mar 2013 02:25:30 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <48CB6D5B-D34F-4719-A480-EC8FB8243DC3@tzi.org>
References: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org> 
To: "Pascal Thubert (pthubert)" 
X-Mailer: Apple Mail (2.1503)
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Mar 2013 01:25:40 -0000

On Mar 16, 2013, at 12:22, "Pascal Thubert (pthubert)" =
 wrote:

> The assumption is that they are operating on a time scale that is 2+ =
orders of magnitude more precise than ours.=20
> This assumptions makes the backbone step negligible in terms of jitter =
and latency as a first approximation.

Indeed.  As long as there is some minimum amount of admission control, =
setting an 802.1Q priority is likely to be sufficient on the Ethernet =
side of things (which is likely 400..4000 times as fast as the 6LoWPANs =
and never has MAC delays).  Practically speaking, that can be done from =
a DSCP.

Gr=FC=DFe, Carsten


From jeonggil.ko@gmail.com  Sat Mar 16 21:48:46 2013
Return-Path: 
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 7450621F84AB for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 21:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1]
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 tWj4uZsH6gsa for <6tsch@ietfa.amsl.com>; Sat, 16 Mar 2013 21:48:45 -0700 (PDT)
Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id BAA4C21F84A9 for <6tsch@ietf.org>; Sat, 16 Mar 2013 21:48:45 -0700 (PDT)
Received: by mail-pb0-f49.google.com with SMTP id xa12so5395999pbc.8 for <6tsch@ietf.org>; Sat, 16 Mar 2013 21:48:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=RRZIa0gqsdjGAndAgMqf1b4KQ/A8TjweT5i1/Qya8Uk=; b=GPN7FMUbQXsIeFZ+/Vf7jRAnPd7AYsH0MyRc6L8cqYXLR0ozcQl87WiEtEI0d/W+m0 +SW+K9Qwq7pke5qUy2rh+Yaqg59A+sCjNEs5OkY7cXszuXaOLNQMNntQSUELAcT60Cvy kUnhYL8mkay3dncjjM8slmiof0LaeQLMhIRva/pGx+njlq8U2Sg8pplDEquz82/rwB20 ai74VK2IHNJnV1bd/v8VZzWQY8+/HpfriuWScPJnJy+lgBxP+FXgvX+cUd7F/L2coKTa D9hJNMrnQk6ZDMlfgR67IGhCVxeAZOUx6oNW7EcToD3oxL1o9MDs3oAIF9r/NMxBfEH1 wPcg==
X-Received: by 10.66.11.133 with SMTP id q5mr4037440pab.150.1363495725470; Sat, 16 Mar 2013 21:48:45 -0700 (PDT)
Received: from [10.211.7.15] ([129.254.38.228]) by mx.google.com with ESMTPS id m18sm3152827pad.17.2013.03.16.21.48.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Mar 2013 21:48:44 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset=windows-1252
From: JeongGil Ko 
X-Priority: 3 (Normal)
In-Reply-To: <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu>
Date: Sun, 17 Mar 2013 13:48:40 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com>
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu>
To: Qin Wang 
X-Mailer: Apple Mail (2.1499)
Cc: "Pascal Thubert \(pthubert\)" , "6tsch@ietf.org" <6tsch@ietf.org>, Xavier Vilajosana 
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Mar 2013 04:48:46 -0000

Sorry for the delayed response. I was stuck on the plane for too long :)

I like the discussion that Qin is going for where we define the =
scenarios.  At the same time, as Carsten says we need to make sure =
overlapping scenarios of any sort are simplified and aggregated as much =
as possible.

Let me just try to put my 2 cents in-line...


On Mar 17, 2013, at 8:19 AM, Qin Wang  wrote:

> Hi Pascal,
>=20
> It is a very good idea to establish a bundle of cells between A and B =
by
> just triggering 6tus in one side. We can design for different =
scenarios.
>=20
> (1) PCE defines the track, i.e. the multihop path, the bandwidth of =
each
> hop, and scheduling hard-cells to implement the multihop path. Assume
> nodeA and nodeB are one-hop neighbors along the path. In this case, =
PCE
> can send Create.hardcell command to 6tus layer in nodeA,and nodeA's =
6tus
> sends Create.hardcell command to nodeB' 6tus, then the hard cell is
> reserved. This function is not in the current version of 6tus draft, =
but
> we can add it in the next version easily.
>=20
> (2)PCE defines the multihop path and the bandwidth of each hop, but =
not
> schedules the cells to meet the path bandwidth. In this case, soft =
cell
> reservation will be applied, which is always triggered in Transmitting
> side, and negotiated by the 6tus layer of both sides.
>=20
> (3)The cell reservation is triggered by upper layer, e.g. the =
RSVP/NSIS
> entity in nodeA. Then soft cell reservation process in 6tus layer of =
nodeA
> will by triggered, and the negotiation process is same as case (2).
>=20
> In summary, by adding reserve hard cell procedure into version-00 of =
6tus,
> we can let the bundle reservation in every scenarios be triggered just =
in
> one side.
>=20
> How do you think?
>=20

Great first start in defining the scenarios.

> Qin
>=20
>=20
>=20
>=20
>> Hi Qin:
>>=20
>> I think we are on the same line. The services that 6TUS proposes do =
not
>> depend on which protocol the request came in through.
>> Since we are defining the protocol extensions, we'll make sure that =
the
>> new information is directly digestible by the 6TUS layer.
>> The protocol extensions will be separate specs, and there should be =
little
>> to no dereference between those specs and yours.
>>=20
>> What's important to me to discuss is how we establish a bundle of =
cells
>> between A and B.
>> IMHO, it would be best if that can be achieved by triggering a =
service in
>> A - no need to trigger B as well.
>> That way, the volume of exchanges between PCE and nodes can be =
devided by
>> 2.
>>=20
>> This would mean that there must be an exchange between 6TUS in A and =
6TUS
>> in B.
>> Which  also would mean that there is a protocol part related to 6TUS=85=

>>=20

Fully agreed that this is needed. Being an independent layer, I don't =
see why not.


>> Cheers,
>>=20
>> Pascal
>>=20
>>=20
>> -----Original Message-----
>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On =
Behalf Of
>> Qin Wang
>> Sent: vendredi 15 mars 2013 18:04
>> To: JeongGil Ko
>> Cc: 6tsch@ietf.org; Xavier Vilajosana
>> Subject: Re: [6tsch] Schemes for resource allocation in the LLN for =
6tus
>>=20
>> John and Xavi,
>>=20
>> I agree that understanding more about upper layer protocols like RSVP =
and
>> NSIS is very helpful for designing 6tus. But, I want to make clearer =
about
>> my understanding on the relationship between 6tus and existing =
reservation
>> protocols like RSVP or NSIS.
>>=20
>> (1) When we talk about reservation in the context of 6tus, we mainly =
focus
>> on  link resource (i.e. cell) reservation, which is required/ =
triggered by
>> upper layer. Even in the pure centralized approach, it may happen to
>> cross-layer reserve both L3 and L2 resource, but you still can =
separate
>> them logically.
>>=20
>> (2) The upper layer requirement to 6tus may come from PCE carried by
>> protocol like CoAP, may come from the RSVP/NSIS entity inside nodes.
>>=20
>> Thus, for 6tus, the question is what kind of function and interface =
should
>> be provided to support the upper layer, instead of which upper layer
>> protocol should be used.
>>=20
>> How do you think?
>>=20

I agree with your arguments that the important thing is defining the =
functionalities. It seems like some of these efforts are on the way in =
the later emails. Me bringing in the term "RSVP" was not that I wanted =
to go an use RSVP in the way it is, but bring the (modified/customized) =
concept in for use in 6tus. As to what I read there may have been a =
misunderstanding between us but we are on the same line.=20

Thanks!

-John

>> Qin
>>=20
>>=20
>=20


From qinwang@berkeley.edu  Sun Mar 17 09:47:35 2013
Return-Path: 
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 DE54B21F8C05 for <6tsch@ietfa.amsl.com>; Sun, 17 Mar 2013 09:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.262
X-Spam-Level: 
X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4]
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 iM8Je7SFHeoT for <6tsch@ietfa.amsl.com>; Sun, 17 Mar 2013 09:47:34 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2821E21F8BF0 for <6tsch@ietf.org>; Sun, 17 Mar 2013 09:47:34 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UHGk7-0004zu-Fu; Sun, 17 Mar 2013 09:47:33 -0700
Received: from 174.234.66.249 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Sun, 17 Mar 2013 09:47:31 -0700
Message-ID: <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>
In-Reply-To: <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com>
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com>
Date: Sun, 17 Mar 2013 09:47:31 -0700
From: "Qin Wang" 
To: "JeongGil Ko" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "Pascal Thubert \(pthubert\)" , "6tsch@ietf.org" <6tsch@ietf.org>, Qin Wang , Xavier Vilajosana 
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Mar 2013 16:47:35 -0000

I fully agree with Carsten that Simple is very important. Let's
overlapping the following three scenarios, then we will find only two
groups of functions 6tus should provide.

(1) Hard cell reserve/remove, which supports the 1st scenario.
(2) Soft cell reserve/remove, which supports the 2nd and 3rd scenario.

Any more?

Qin


> Sorry for the delayed response. I was stuck on the plane for too long :)
>
> I like the discussion that Qin is going for where we define the scenarios.
>  At the same time, as Carsten says we need to make sure overlapping
> scenarios of any sort are simplified and aggregated as much as possible.
>
> Let me just try to put my 2 cents in-line...
>
>
> On Mar 17, 2013, at 8:19 AM, Qin Wang  wrote:
>
>> Hi Pascal,
>>
>> It is a very good idea to establish a bundle of cells between A and B by
>> just triggering 6tus in one side. We can design for different scenarios.
>>
>> (1) PCE defines the track, i.e. the multihop path, the bandwidth of each
>> hop, and scheduling hard-cells to implement the multihop path. Assume
>> nodeA and nodeB are one-hop neighbors along the path. In this case, PCE
>> can send Create.hardcell command to 6tus layer in nodeA,and nodeA's 6tus
>> sends Create.hardcell command to nodeB' 6tus, then the hard cell is
>> reserved. This function is not in the current version of 6tus draft, but
>> we can add it in the next version easily.
>>
>> (2)PCE defines the multihop path and the bandwidth of each hop, but not
>> schedules the cells to meet the path bandwidth. In this case, soft cell
>> reservation will be applied, which is always triggered in Transmitting
>> side, and negotiated by the 6tus layer of both sides.
>>
>> (3)The cell reservation is triggered by upper layer, e.g. the RSVP/NSIS
>> entity in nodeA. Then soft cell reservation process in 6tus layer of
>> nodeA
>> will by triggered, and the negotiation process is same as case (2).
>>
>> In summary, by adding reserve hard cell procedure into version-00 of
>> 6tus,
>> we can let the bundle reservation in every scenarios be triggered just
>> in
>> one side.
>>
>> How do you think?
>>
>
> Great first start in defining the scenarios.
>
>> Qin
>>
>>
>>
>>
>>> Hi Qin:
>>>
>>> I think we are on the same line. The services that 6TUS proposes do not
>>> depend on which protocol the request came in through.
>>> Since we are defining the protocol extensions, we'll make sure that the
>>> new information is directly digestible by the 6TUS layer.
>>> The protocol extensions will be separate specs, and there should be
>>> little
>>> to no dereference between those specs and yours.
>>>
>>> What's important to me to discuss is how we establish a bundle of cells
>>> between A and B.
>>> IMHO, it would be best if that can be achieved by triggering a service
>>> in
>>> A - no need to trigger B as well.
>>> That way, the volume of exchanges between PCE and nodes can be devided
>>> by
>>> 2.
>>>
>>> This would mean that there must be an exchange between 6TUS in A and
>>> 6TUS
>>> in B.
>>> Which  also would mean that there is a protocol part related to 6TUS…
>>>
>
> Fully agreed that this is needed. Being an independent layer, I don't see
> why not.
>
>
>>> Cheers,
>>>
>>> Pascal
>>>
>>>
>>> -----Original Message-----
>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf
>>> Of
>>> Qin Wang
>>> Sent: vendredi 15 mars 2013 18:04
>>> To: JeongGil Ko
>>> Cc: 6tsch@ietf.org; Xavier Vilajosana
>>> Subject: Re: [6tsch] Schemes for resource allocation in the LLN for
>>> 6tus
>>>
>>> John and Xavi,
>>>
>>> I agree that understanding more about upper layer protocols like RSVP
>>> and
>>> NSIS is very helpful for designing 6tus. But, I want to make clearer
>>> about
>>> my understanding on the relationship between 6tus and existing
>>> reservation
>>> protocols like RSVP or NSIS.
>>>
>>> (1) When we talk about reservation in the context of 6tus, we mainly
>>> focus
>>> on  link resource (i.e. cell) reservation, which is required/ triggered
>>> by
>>> upper layer. Even in the pure centralized approach, it may happen to
>>> cross-layer reserve both L3 and L2 resource, but you still can separate
>>> them logically.
>>>
>>> (2) The upper layer requirement to 6tus may come from PCE carried by
>>> protocol like CoAP, may come from the RSVP/NSIS entity inside nodes.
>>>
>>> Thus, for 6tus, the question is what kind of function and interface
>>> should
>>> be provided to support the upper layer, instead of which upper layer
>>> protocol should be used.
>>>
>>> How do you think?
>>>
>
> I agree with your arguments that the important thing is defining the
> functionalities. It seems like some of these efforts are on the way in the
> later emails. Me bringing in the term "RSVP" was not that I wanted to go
> an use RSVP in the way it is, but bring the (modified/customized) concept
> in for use in 6tus. As to what I read there may have been a
> misunderstanding between us but we are on the same line.
>
> Thanks!
>
> -John
>
>>> Qin
>>>
>>>
>>
>
>


From maria-rita.palattella@uni.lu  Mon Mar 18 02:06:48 2013
Return-Path: 
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 1A7A421F8910 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 02:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 E5t15CiV5vEj for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 02:06:47 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 92A8221F88EF for <6tsch@ietf.org>; Mon, 18 Mar 2013 02:06:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,863,1355094000"; d="scan'208";a="22960367"
Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 18 Mar 2013 10:06:44 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.01.0438.000; Mon, 18 Mar 2013 10:06:44 +0100
From: Maria Rita PALATTELLA 
To: Qin Wang , Shoichi Sakane 
Thread-Topic: [6tsch] Scope: 6LoWPAN + 1
Thread-Index: AQHOIAhL22DYje1qL0GttRwrD1kCe5ikG7EAgADiegCAAAiBAIAACmGAgAA/0gCABdi0kA==
Date: Mon, 18 Mar 2013 09:06:43 +0000
Message-ID: 
References: <4DB36021-7426-4360-89FC-5C48D9DD0607@tzi.org>  <5141B51E.3050603@tanu.org> <2FB32E34ED32C44A8D9BCC2E880875E326C0D4A3@AM2PRD0411MB434.eurprd04.prod.outlook.com> <5141C4F5.8040202@tanu.org> <3f5fc7a67dd46651bb8b05da1720f86b.squirrel@calmail.berkeley.edu>
In-Reply-To: <3f5fc7a67dd46651bb8b05da1720f86b.squirrel@calmail.berkeley.edu>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.91.0.70]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Scope: 6LoWPAN + 1
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 09:06:48 -0000

Hi Qin, and all,
Sorry for coming back to this discussion after some time, but I wanted to r=
aise and clarify a point.

Qin>>>(2) If there is PCE, there may be different setting. For example, PCE=
 is in charge for reserving both multiple hop path (i.e. every next hop
Qin>>>neighbor) and cells; or PCE is just in charge for reserving the multi=
ple hop path and leaving cell reservation to local, and the distributed cel=
l reservation will meet the bandwidth requirement from multiple hop path re=
servation. In the first case, hard Qin>>> cell  reservation will be used.

Qin >>>(3)If there is no PCE, both multi-hop path and cells are reserved in=
 local.
Qin>>For example, RPL + soft cell reservation in 6tus.

>From my point of view (and thinking about TASA implementation), the PCE sho=
uldn't be in charge for reserving the multiple hop path. But the routing pr=
otocol (i.e., RPL in our case) should take care of the next hop neighbor se=
lection.
When a centralized approach is adopted, the PCE will schedule the cells  (i=
.e., hard cells according to 6tus terminology).=20
While, when a distributed solution is used, 6tus will allocate the soft cel=
ls.

In the centralized scenario with the PCE, to avoid the exchange of many sig=
naling messages, for setting up the schedule, we may think (as Pascal was s=
uggesting during one of the last call) to use some hybrid solutions.
In other words, if PCE allocates (timeoffset1, channeloffset3, slotframe1, =
TX) to node A for transmitting to node B, then, node B could know locally f=
rom node A, (and not from the PCE), that the cell (timeoffset1, channeloffs=
et3, slotframe1, RX) has been reserved to it, for receiving from node A.
We may try to include some functionality in 6tus layer in order to manage s=
uch situation.
What do you think?

Maria Rita

---------------------------------------------------------------------------=
-------------------------------------
> On 3/14/13 9:02 PM, Paul Chilton wrote:
>>>- optionally a PCE sits on the backbone and drives the LLNs' TSCH =20
>>>schedules.
>
> Ah, maybe understood.  It doesn't say that existence of PCE is optional.
> It says that it's optional to put PCE in the backbone.  It doesn't=20
> preclude to put it on BBR.  Correct ?
>
> Shoichi
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>

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

From maria-rita.palattella@uni.lu  Mon Mar 18 02:21:54 2013
Return-Path: 
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 E904B21F87D1 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 02:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4]
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 woDB6f2dzb3X for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 02:21:54 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2F021F87BA for <6tsch@ietf.org>; Mon, 18 Mar 2013 02:21:53 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,863,1355094000"; d="scan'208";a="22960942"
Received: from unknown (HELO Archer.uni.lux) ([10.21.2.1]) by hercules.uni.lu with ESMTP; 18 Mar 2013 10:21:53 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Archer.uni.lux ([fe80::1009:b1e7:2b72:f0b8%10]) with mapi id 14.01.0438.000; Mon, 18 Mar 2013 10:21:53 +0100
From: Maria Rita PALATTELLA 
To: Qin Wang , JeongGil Ko 
Thread-Topic: [6tsch] Schemes for resource allocation in the LLN for 6tus
Thread-Index: AQHOIAyFR0xIuXMyq0+XDo4MtoNJEpiljU0AgAAQKACAAA+DgIAAAUgAgABcj4CAATZhAIAA2mUAgADNBICAAFvtAIAAyNiAgAEmDWA=
Date: Mon, 18 Mar 2013 09:21:52 +0000
Message-ID: 
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>
In-Reply-To: <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.91.0.70]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "Pascal Thubert \(pthubert\)" , "6tsch@ietf.org" <6tsch@ietf.org>, Xavier Vilajosana 
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 09:21:55 -0000

KzEgYWJvdXQga2VlcGluZyBzaW1wbGUgc29sdXRpb25zIQ0KDQpJdCBzaG91bGQgYmUgZ3JlYXQg
aWYgNnR1cyBjb3VsZCBpbmNsdWRlIHRoZSBmb2xsb3dpbmcgZnVuY3Rpb25hbGl0aWVzIQ0KTWFy
aWEgUml0YQ0KDQo+PiAoMSkgUENFIGRlZmluZXMgdGhlIHRyYWNrLCBpLmUuIHRoZSBtdWx0aWhv
cCBwYXRoLCB0aGUgYmFuZHdpZHRoIG9mIA0KPj4gZWFjaCBob3AsIGFuZCBzY2hlZHVsaW5nIGhh
cmQtY2VsbHMgdG8gaW1wbGVtZW50IHRoZSBtdWx0aWhvcCBwYXRoLiANCj4+IEFzc3VtZSBub2Rl
QSBhbmQgbm9kZUIgYXJlIG9uZS1ob3AgbmVpZ2hib3JzIGFsb25nIHRoZSBwYXRoLiBJbiB0aGlz
IA0KPj4gY2FzZSwgUENFIGNhbiBzZW5kIENyZWF0ZS5oYXJkY2VsbCBjb21tYW5kIHRvIDZ0dXMg
bGF5ZXIgaW4gbm9kZUEsYW5kIA0KPj4gbm9kZUEncyA2dHVzIHNlbmRzIENyZWF0ZS5oYXJkY2Vs
bCBjb21tYW5kIHRvIG5vZGVCJyA2dHVzLCB0aGVuIHRoZSANCj4+IGhhcmQgY2VsbCBpcyByZXNl
cnZlZC4gVGhpcyBmdW5jdGlvbiBpcyBub3QgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiANCj4+
IDZ0dXMgZHJhZnQsIGJ1dCB3ZSBjYW4gYWRkIGl0IGluIHRoZSBuZXh0IHZlcnNpb24gZWFzaWx5
Lg0KPj4NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gKDIpUENFIGRlZmlu
ZXMgdGhlIG11bHRpaG9wIHBhdGggYW5kIHRoZSBiYW5kd2lkdGggb2YgZWFjaCBob3AsIGJ1dCAN
Cj4+IG5vdCBzY2hlZHVsZXMgdGhlIGNlbGxzIHRvIG1lZXQgdGhlIHBhdGggYmFuZHdpZHRoLiBJ
biB0aGlzIGNhc2UsIA0KPj4gc29mdCBjZWxsIHJlc2VydmF0aW9uIHdpbGwgYmUgYXBwbGllZCwg
d2hpY2ggaXMgYWx3YXlzIHRyaWdnZXJlZCBpbiANCj4+IFRyYW5zbWl0dGluZyBzaWRlLCBhbmQg
bmVnb3RpYXRlZCBieSB0aGUgNnR1cyBsYXllciBvZiBib3RoIHNpZGVzLg0KPj4NCj4+ICgzKVRo
ZSBjZWxsIHJlc2VydmF0aW9uIGlzIHRyaWdnZXJlZCBieSB1cHBlciBsYXllciwgZS5nLiB0aGUg
DQo+PiBSU1ZQL05TSVMgZW50aXR5IGluIG5vZGVBLiBUaGVuIHNvZnQgY2VsbCByZXNlcnZhdGlv
biBwcm9jZXNzIGluIDZ0dXMgDQo+PiBsYXllciBvZiBub2RlQSB3aWxsIGJ5IHRyaWdnZXJlZCwg
YW5kIHRoZSBuZWdvdGlhdGlvbiBwcm9jZXNzIGlzIHNhbWUgDQo+PiBhcyBjYXNlICgyKS4NCj4+
DQo+PiBJbiBzdW1tYXJ5LCBieSBhZGRpbmcgcmVzZXJ2ZSBoYXJkIGNlbGwgcHJvY2VkdXJlIGlu
dG8gdmVyc2lvbi0wMCBvZiANCj4+IDZ0dXMsIHdlIGNhbiBsZXQgdGhlIGJ1bmRsZSByZXNlcnZh
dGlvbiBpbiBldmVyeSBzY2VuYXJpb3MgYmUgDQo+PiB0cmlnZ2VyZWQganVzdCBpbiBvbmUgc2lk
ZS4NCj4+DQo+PiBIb3cgZG8geW91IHRoaW5rPw0KPj4NCj4NCj4gR3JlYXQgZmlyc3Qgc3RhcnQg
aW4gZGVmaW5pbmcgdGhlIHNjZW5hcmlvcy4NCj4NCj4+IFFpbg0KPj4NCj4+DQo+Pg0KPj4NCj4+
PiBIaSBRaW46DQo+Pj4NCj4+PiBJIHRoaW5rIHdlIGFyZSBvbiB0aGUgc2FtZSBsaW5lLiBUaGUg
c2VydmljZXMgdGhhdCA2VFVTIHByb3Bvc2VzIGRvIA0KPj4+IG5vdCBkZXBlbmQgb24gd2hpY2gg
cHJvdG9jb2wgdGhlIHJlcXVlc3QgY2FtZSBpbiB0aHJvdWdoLg0KPj4+IFNpbmNlIHdlIGFyZSBk
ZWZpbmluZyB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9ucywgd2UnbGwgbWFrZSBzdXJlIHRoYXQgDQo+
Pj4gdGhlIG5ldyBpbmZvcm1hdGlvbiBpcyBkaXJlY3RseSBkaWdlc3RpYmxlIGJ5IHRoZSA2VFVT
IGxheWVyLg0KPj4+IFRoZSBwcm90b2NvbCBleHRlbnNpb25zIHdpbGwgYmUgc2VwYXJhdGUgc3Bl
Y3MsIGFuZCB0aGVyZSBzaG91bGQgYmUgDQo+Pj4gbGl0dGxlIHRvIG5vIGRlcmVmZXJlbmNlIGJl
dHdlZW4gdGhvc2Ugc3BlY3MgYW5kIHlvdXJzLg0KPj4+DQo+Pj4gV2hhdCdzIGltcG9ydGFudCB0
byBtZSB0byBkaXNjdXNzIGlzIGhvdyB3ZSBlc3RhYmxpc2ggYSBidW5kbGUgb2YgDQo+Pj4gY2Vs
bHMgYmV0d2VlbiBBIGFuZCBCLg0KPj4+IElNSE8sIGl0IHdvdWxkIGJlIGJlc3QgaWYgdGhhdCBj
YW4gYmUgYWNoaWV2ZWQgYnkgdHJpZ2dlcmluZyBhIA0KPj4+IHNlcnZpY2UgaW4gQSAtIG5vIG5l
ZWQgdG8gdHJpZ2dlciBCIGFzIHdlbGwuDQo+Pj4gVGhhdCB3YXksIHRoZSB2b2x1bWUgb2YgZXhj
aGFuZ2VzIGJldHdlZW4gUENFIGFuZCBub2RlcyBjYW4gYmUgDQo+Pj4gZGV2aWRlZCBieSAyLg0K
Pj4+DQo+Pj4gVGhpcyB3b3VsZCBtZWFuIHRoYXQgdGhlcmUgbXVzdCBiZSBhbiBleGNoYW5nZSBi
ZXR3ZWVuIDZUVVMgaW4gQSBhbmQgDQo+Pj4gNlRVUyBpbiBCLg0KPj4+IFdoaWNoICBhbHNvIHdv
dWxkIG1lYW4gdGhhdCB0aGVyZSBpcyBhIHByb3RvY29sIHBhcnQgcmVsYXRlZCB0byANCj4+PiA2
VFVT4oCmDQo+Pj4NCj4NCj4gRnVsbHkgYWdyZWVkIHRoYXQgdGhpcyBpcyBuZWVkZWQuIEJlaW5n
IGFuIGluZGVwZW5kZW50IGxheWVyLCBJIGRvbid0IA0KPiBzZWUgd2h5IG5vdC4NCj4NCj4NCj4+
PiBDaGVlcnMsDQo+Pj4NCj4+PiBQYXNjYWwNCj4+Pg0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiA2dHNjaC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86NnRz
Y2gtYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+Pj4gQmVoYWxmIE9mIFFpbiBXYW5nDQo+Pj4gU2Vu
dDogdmVuZHJlZGkgMTUgbWFycyAyMDEzIDE4OjA0DQo+Pj4gVG86IEplb25nR2lsIEtvDQo+Pj4g
Q2M6IDZ0c2NoQGlldGYub3JnOyBYYXZpZXIgVmlsYWpvc2FuYQ0KPj4+IFN1YmplY3Q6IFJlOiBb
NnRzY2hdIFNjaGVtZXMgZm9yIHJlc291cmNlIGFsbG9jYXRpb24gaW4gdGhlIExMTiBmb3IgDQo+
Pj4gNnR1cw0KPj4+DQo+Pj4gSm9obiBhbmQgWGF2aSwNCj4+Pg0KPj4+IEkgYWdyZWUgdGhhdCB1
bmRlcnN0YW5kaW5nIG1vcmUgYWJvdXQgdXBwZXIgbGF5ZXIgcHJvdG9jb2xzIGxpa2UgDQo+Pj4g
UlNWUCBhbmQgTlNJUyBpcyB2ZXJ5IGhlbHBmdWwgZm9yIGRlc2lnbmluZyA2dHVzLiBCdXQsIEkg
d2FudCB0byANCj4+PiBtYWtlIGNsZWFyZXIgYWJvdXQgbXkgdW5kZXJzdGFuZGluZyBvbiB0aGUg
cmVsYXRpb25zaGlwIGJldHdlZW4gNnR1cyANCj4+PiBhbmQgZXhpc3RpbmcgcmVzZXJ2YXRpb24g
cHJvdG9jb2xzIGxpa2UgUlNWUCBvciBOU0lTLg0KPj4+DQo+Pj4gKDEpIFdoZW4gd2UgdGFsayBh
Ym91dCByZXNlcnZhdGlvbiBpbiB0aGUgY29udGV4dCBvZiA2dHVzLCB3ZSBtYWlubHkgDQo+Pj4g
Zm9jdXMgb24gIGxpbmsgcmVzb3VyY2UgKGkuZS4gY2VsbCkgcmVzZXJ2YXRpb24sIHdoaWNoIGlz
IHJlcXVpcmVkLyANCj4+PiB0cmlnZ2VyZWQgYnkgdXBwZXIgbGF5ZXIuIEV2ZW4gaW4gdGhlIHB1
cmUgY2VudHJhbGl6ZWQgYXBwcm9hY2gsIGl0IA0KPj4+IG1heSBoYXBwZW4gdG8gY3Jvc3MtbGF5
ZXIgcmVzZXJ2ZSBib3RoIEwzIGFuZCBMMiByZXNvdXJjZSwgYnV0IHlvdSANCj4+PiBzdGlsbCBj
YW4gc2VwYXJhdGUgdGhlbSBsb2dpY2FsbHkuDQo+Pj4NCj4+PiAoMikgVGhlIHVwcGVyIGxheWVy
IHJlcXVpcmVtZW50IHRvIDZ0dXMgbWF5IGNvbWUgZnJvbSBQQ0UgY2FycmllZCBieSANCj4+PiBw
cm90b2NvbCBsaWtlIENvQVAsIG1heSBjb21lIGZyb20gdGhlIFJTVlAvTlNJUyBlbnRpdHkgaW5z
aWRlIG5vZGVzLg0KPj4+DQo+Pj4gVGh1cywgZm9yIDZ0dXMsIHRoZSBxdWVzdGlvbiBpcyB3aGF0
IGtpbmQgb2YgZnVuY3Rpb24gYW5kIGludGVyZmFjZSANCj4+PiBzaG91bGQgYmUgcHJvdmlkZWQg
dG8gc3VwcG9ydCB0aGUgdXBwZXIgbGF5ZXIsIGluc3RlYWQgb2Ygd2hpY2ggDQo+Pj4gdXBwZXIg
bGF5ZXIgcHJvdG9jb2wgc2hvdWxkIGJlIHVzZWQuDQo+Pj4NCj4+PiBIb3cgZG8geW91IHRoaW5r
Pw0KPj4+DQo+DQo+IEkgYWdyZWUgd2l0aCB5b3VyIGFyZ3VtZW50cyB0aGF0IHRoZSBpbXBvcnRh
bnQgdGhpbmcgaXMgZGVmaW5pbmcgdGhlIA0KPiBmdW5jdGlvbmFsaXRpZXMuIEl0IHNlZW1zIGxp
a2Ugc29tZSBvZiB0aGVzZSBlZmZvcnRzIGFyZSBvbiB0aGUgd2F5IGluIA0KPiB0aGUgbGF0ZXIg
ZW1haWxzLiBNZSBicmluZ2luZyBpbiB0aGUgdGVybSAiUlNWUCIgd2FzIG5vdCB0aGF0IEkgd2Fu
dGVkIA0KPiB0byBnbyBhbiB1c2UgUlNWUCBpbiB0aGUgd2F5IGl0IGlzLCBidXQgYnJpbmcgdGhl
IA0KPiAobW9kaWZpZWQvY3VzdG9taXplZCkgY29uY2VwdCBpbiBmb3IgdXNlIGluIDZ0dXMuIEFz
IHRvIHdoYXQgSSByZWFkIA0KPiB0aGVyZSBtYXkgaGF2ZSBiZWVuIGEgbWlzdW5kZXJzdGFuZGlu
ZyBiZXR3ZWVuIHVzIGJ1dCB3ZSBhcmUgb24gdGhlIHNhbWUgbGluZS4NCj4NCj4gVGhhbmtzIQ0K
Pg0KPiAtSm9obg0KPg0KPj4+IFFpbg0KPj4+DQo+Pj4NCj4+DQo+DQo+DQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo2dHNjaCBtYWlsaW5nIGxpc3QN
CjZ0c2NoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0
c2NoDQo=

From mcr@sandelman.ca  Mon Mar 18 06:18:49 2013
Return-Path: 
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 7744721F88A1 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 06:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.444
X-Spam-Level: 
X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.156,  BAYES_00=-2.599]
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 qB5GCUzZycyR for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 06:18:49 -0700 (PDT)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id DE7E621F889D for <6tsch@ietf.org>; Mon, 18 Mar 2013 06:18:48 -0700 (PDT)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 817D420168; Mon, 18 Mar 2013 09:27:01 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 3710763860; Mon, 18 Mar 2013 09:18:37 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 25F2C63827; Mon, 18 Mar 2013 09:18:37 -0400 (EDT)
From: Michael Richardson 
To: "Pascal Thubert (pthubert)" 
In-Reply-To: 
References:  <19015.1362797728@sandelman.ca>  <1953.1363034941@sandelman.ca> <513E489B.6070306@eecs.berkeley.edu> <7841.1363104356@sandelman.ca> <513F95B8.7000408@eecs.berkeley.edu> <6111.1363229554@sandelman.ca> 
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Cc: "6tsch@ietf.org" <6tsch@ietf.org>, Xavier Vilajosana 
Subject: Re: [6tsch] how to handle different classes of traffic
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 13:18:49 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "pthubert" =3D=3D pthubert   writes:
    pthubert> A particular cell in the slotframe may be reserved for a
    pthubert> particular point to point flow (e.g. a control loop). In
    pthubert> that case, the cell is equivalent to an MPLS label in that
    pthubert> the sequence of cells is programmed (we call that a track)
    pthubert> along the (multihop) path between Alice and Bob and only
    pthubert> leads to Bob. Other cells are used for QoS based traffic

Is this inherent in 6tsch, or is this the desired result of the PCE
calculation that would take into account layer-3 forwarding?

=2D-=20
Michael Richardson , Sandelman Software Works=20



--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQCVAwUAUUcULYqHRg3pndX9AQIs1gQAqII9NMvmxvWzbj7ESIEwt4qalGDXbVXO
pHkQOZPikhyf+RHYTUqxj1OPnFRXx3RaBw6tAUL/1Yl80QOR6OFilu5Ka7nHXcuu
AdnuLC/DxXD1XxojMolTfHXRBSRJbnmRWkCj6r8el//kcM5hYJtENrYTcw1gY7Gj
/+BbhAGGw/I=
=C3yx
-----END PGP SIGNATURE-----
--=-=-=--

From xvilajosana@eecs.berkeley.edu  Mon Mar 18 06:29:52 2013
Return-Path: 
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 3688821F8DD9 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 06:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4]
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 PHcS6S9PMKgp for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 06:29:51 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1B121F8D34 for <6tsch@ietf.org>; Mon, 18 Mar 2013 06:29:51 -0700 (PDT)
Received: from c-67-188-198-243.hsd1.ca.comcast.net ([67.188.198.243] helo=[192.168.2.9]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UHa8L-0003ju-4x; Mon, 18 Mar 2013 06:29:50 -0700
Message-ID: <514716C8.7070107@eecs.berkeley.edu>
Date: Mon, 18 Mar 2013 06:29:44 -0700
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Maria Rita PALATTELLA 
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "6tsch@ietf.org" <6tsch@ietf.org>, "Pascal Thubert \(pthubert\)" , JeongGil Ko , Qin Wang 
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 13:29:52 -0000

This is on the roadmap of the draft.

regards,
Xavi

On 18/03/13 02:21, Maria Rita PALATTELLA wrote:
> +1 about keeping simple solutions!
>
> It should be great if 6tus could include the following functionalities!
> Maria Rita
>
>>> (1) PCE defines the track, i.e. the multihop path, the bandwidth of
>>> each hop, and scheduling hard-cells to implement the multihop path.
>>> Assume nodeA and nodeB are one-hop neighbors along the path. In this
>>> case, PCE can send Create.hardcell command to 6tus layer in nodeA,and
>>> nodeA's 6tus sends Create.hardcell command to nodeB' 6tus, then the
>>> hard cell is reserved. This function is not in the current version of
>>> 6tus draft, but we can add it in the next version easily.
>>>
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------
>>> (2)PCE defines the multihop path and the bandwidth of each hop, but
>>> not schedules the cells to meet the path bandwidth. In this case,
>>> soft cell reservation will be applied, which is always triggered in
>>> Transmitting side, and negotiated by the 6tus layer of both sides.
>>>
>>> (3)The cell reservation is triggered by upper layer, e.g. the
>>> RSVP/NSIS entity in nodeA. Then soft cell reservation process in 6tus
>>> layer of nodeA will by triggered, and the negotiation process is same
>>> as case (2).
>>>
>>> In summary, by adding reserve hard cell procedure into version-00 of
>>> 6tus, we can let the bundle reservation in every scenarios be
>>> triggered just in one side.
>>>
>>> How do you think?
>>>
>> Great first start in defining the scenarios.
>>
>>> Qin
>>>
>>>
>>>
>>>
>>>> Hi Qin:
>>>>
>>>> I think we are on the same line. The services that 6TUS proposes do
>>>> not depend on which protocol the request came in through.
>>>> Since we are defining the protocol extensions, we'll make sure that
>>>> the new information is directly digestible by the 6TUS layer.
>>>> The protocol extensions will be separate specs, and there should be
>>>> little to no dereference between those specs and yours.
>>>>
>>>> What's important to me to discuss is how we establish a bundle of
>>>> cells between A and B.
>>>> IMHO, it would be best if that can be achieved by triggering a
>>>> service in A - no need to trigger B as well.
>>>> That way, the volume of exchanges between PCE and nodes can be
>>>> devided by 2.
>>>>
>>>> This would mean that there must be an exchange between 6TUS in A and
>>>> 6TUS in B.
>>>> Which  also would mean that there is a protocol part related to
>>>> 6TUS…
>>>>
>> Fully agreed that this is needed. Being an independent layer, I don't
>> see why not.
>>
>>
>>>> Cheers,
>>>>
>>>> Pascal
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On
>>>> Behalf Of Qin Wang
>>>> Sent: vendredi 15 mars 2013 18:04
>>>> To: JeongGil Ko
>>>> Cc: 6tsch@ietf.org; Xavier Vilajosana
>>>> Subject: Re: [6tsch] Schemes for resource allocation in the LLN for
>>>> 6tus
>>>>
>>>> John and Xavi,
>>>>
>>>> I agree that understanding more about upper layer protocols like
>>>> RSVP and NSIS is very helpful for designing 6tus. But, I want to
>>>> make clearer about my understanding on the relationship between 6tus
>>>> and existing reservation protocols like RSVP or NSIS.
>>>>
>>>> (1) When we talk about reservation in the context of 6tus, we mainly
>>>> focus on  link resource (i.e. cell) reservation, which is required/
>>>> triggered by upper layer. Even in the pure centralized approach, it
>>>> may happen to cross-layer reserve both L3 and L2 resource, but you
>>>> still can separate them logically.
>>>>
>>>> (2) The upper layer requirement to 6tus may come from PCE carried by
>>>> protocol like CoAP, may come from the RSVP/NSIS entity inside nodes.
>>>>
>>>> Thus, for 6tus, the question is what kind of function and interface
>>>> should be provided to support the upper layer, instead of which
>>>> upper layer protocol should be used.
>>>>
>>>> How do you think?
>>>>
>> I agree with your arguments that the important thing is defining the
>> functionalities. It seems like some of these efforts are on the way in
>> the later emails. Me bringing in the term "RSVP" was not that I wanted
>> to go an use RSVP in the way it is, but bring the
>> (modified/customized) concept in for use in 6tus. As to what I read
>> there may have been a misunderstanding between us but we are on the same line.
>>
>> Thanks!
>>
>> -John
>>
>>>> Qin
>>>>
>>>>
>>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


From pthubert@cisco.com  Mon Mar 18 07:29:09 2013
Return-Path: 
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 8F53821F8C23 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 07:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 5imHAVvpObl0 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 07:29:08 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BC99421F8BCD for <6tsch@ietf.org>; Mon, 18 Mar 2013 07:29:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1524; q=dns/txt; s=iport; t=1363616948; x=1364826548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4Oba49l9E8zKSauAqoOo05VvIFuDw6N+QhuhlrodEZ8=; b=iCZZjo3buHs7O5MUeNPse8R76lJHRYCjsbyGLRkQzMoUvncZPPsocGDH 0y8jVGd6+QO83VQrP9A24KkkOvQPbwJX+3/SuXL9iygHQprobL0Ocqqch G2Goq5FH+jtGWhiUoneSBSqzs5GDg8wmgpHH0Ccfj6+QtoZdKLXmj9pY6 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAFskR1GtJXHB/2dsb2JhbABDxR6BUhZ0giQBAQEEOj8MBAIBCBEEAQELCwkJBzIUCQgCBA4FCIgMwguOZAYgCwcGBIJVYQOnYIMKgig
X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="188618178"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 18 Mar 2013 14:29:08 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2IET8GE005185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 14:29:08 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 09:29:07 -0500
From: "Pascal Thubert (pthubert)" 
To: Michael Richardson 
Thread-Topic: [6tsch] how to handle different classes of traffic
Thread-Index: AQHOI9sf0BJD/iviQ0qekg1rGuC5xZirf/Ww
Date: Mon, 18 Mar 2013 14:29:07 +0000
Deferred-Delivery: Mon, 18 Mar 2013 14:28:00 +0000
Message-ID: 
References:  <19015.1362797728@sandelman.ca>  <1953.1363034941@sandelman.ca> <513E489B.6070306@eecs.berkeley.edu> <7841.1363104356@sandelman.ca> <513F95B8.7000408@eecs.berkeley.edu> <6111.1363229554@sandelman.ca>  <8848.1363612717@sandelman.ca>
In-Reply-To: <8848.1363612717@sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.92.130]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "6tsch@ietf.org" <6tsch@ietf.org>, Xavier Vilajosana 
Subject: Re: [6tsch] how to handle different classes of traffic
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 14:29:09 -0000

Hello Michael

At the end of the day it's more a matter of use cases than technology since=
 both centralized and distributed could do statistical mux.

In practice, though, it looks like it's the latter; for all I know, the PCE=
 related use cases only involve deterministic tracks such that each new flo=
w will get its own new track of newly allocated cells.

6TSCH adds RPL routing to scale a great many of less critical flows. This i=
s where we expect the traditional QoS with DSCPs, RED, etc...

Cheers,

Pascal


-----Original Message-----
From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael Richa=
rdson
Sent: lundi 18 mars 2013 14:19
To: Pascal Thubert (pthubert)
Cc: Xavier Vilajosana; 6tsch@ietf.org
Subject: Re: [6tsch] how to handle different classes of traffic


>>>>> "pthubert" =3D=3D pthubert   writes:
    pthubert> A particular cell in the slotframe may be reserved for a
    pthubert> particular point to point flow (e.g. a control loop). In
    pthubert> that case, the cell is equivalent to an MPLS label in that
    pthubert> the sequence of cells is programmed (we call that a track)
    pthubert> along the (multihop) path between Alice and Bob and only
    pthubert> leads to Bob. Other cells are used for QoS based traffic

Is this inherent in 6tsch, or is this the desired result of the PCE calcula=
tion that would take into account layer-3 forwarding?

--
Michael Richardson , Sandelman Software Works=20



From twatteyne@gmail.com  Mon Mar 18 09:12:57 2013
Return-Path: 
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 A4B4921F8DEE for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 09:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 A5d+nzkhwDFN for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 09:12:57 -0700 (PDT)
Received: from mail-da0-x234.google.com (mail-da0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 08C7321F8D45 for <6tsch@ietf.org>; Mon, 18 Mar 2013 09:12:57 -0700 (PDT)
Received: by mail-da0-f52.google.com with SMTP id f10so1431309dak.39 for <6tsch@ietf.org>; Mon, 18 Mar 2013 09:12:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=omKfxr/U6ZArNgrCQA6/koyjnFOyRcf6fWYBv4oLcQI=; b=yAQFTDNUpz+8rREv3RrHQhvqHpM3X62X6rAZX4wL/hvH8wlfiFeKfYJuTJACXwX3Rr XuSFFNAIt9+SvfUnt15DDwOJdm+HzC8dDbLuLQy3mD0gf6pG2Eu+6ZHUQoCBaR9xyTbw hzVGK5rQYQK3qLtbkL4vLO0zT5Qe3zUWqYx46uXs+fjtNJUKtRmPXY5nSBs9X9S71xan gQocPymam8DCN+OORaWxJwbL/dTvQ3264fXz1ZjXF5Xm9kT/+CnZ8Fhyr66hNKwwaPU+ hTEKXcDBDQ8H3wOXllQTYT31M/D5XmaVOIjFV/JdvKu2y9WyxI5BZecfrHVGG7LAOupW 4cGw==
MIME-Version: 1.0
X-Received: by 10.68.227.202 with SMTP id sc10mr33738419pbc.109.1363623176758;  Mon, 18 Mar 2013 09:12:56 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Mon, 18 Mar 2013 09:12:56 -0700 (PDT)
In-Reply-To: 
References:  <19015.1362797728@sandelman.ca>  <1953.1363034941@sandelman.ca> <513E489B.6070306@eecs.berkeley.edu> <7841.1363104356@sandelman.ca> <513F95B8.7000408@eecs.berkeley.edu> <6111.1363229554@sandelman.ca>  <8848.1363612717@sandelman.ca> 
Date: Mon, 18 Mar 2013 09:12:56 -0700
X-Google-Sender-Auth: FsihJHNtD6AY5Np47PxQ7T_lD9s
Message-ID: 
From: Thomas Watteyne 
To: "Pascal Thubert (pthubert)" 
Content-Type: multipart/alternative; boundary=047d7b2eda150eebaf04d835431a
Cc: Michael Richardson , "6tsch@ietf.org" <6tsch@ietf.org>, Xavier Vilajosana 
Subject: Re: [6tsch] how to handle different classes of traffic
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 16:12:57 -0000

--047d7b2eda150eebaf04d835431a
Content-Type: text/plain; charset=ISO-8859-1

Michael,
Just to quickly complement, TSCH does not include the concept of labeling
cells for label-based switching, this is something we're contemplating for
6TSCH.
Thomas

On Mon, Mar 18, 2013 at 7:29 AM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> Hello Michael
>
> At the end of the day it's more a matter of use cases than technology
> since both centralized and distributed could do statistical mux.
>
> In practice, though, it looks like it's the latter; for all I know, the
> PCE related use cases only involve deterministic tracks such that each new
> flow will get its own new track of newly allocated cells.
>
> 6TSCH adds RPL routing to scale a great many of less critical flows. This
> is where we expect the traditional QoS with DSCPs, RED, etc...
>
> Cheers,
>
> Pascal
>
>
> -----Original Message-----
> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael
> Richardson
> Sent: lundi 18 mars 2013 14:19
> To: Pascal Thubert (pthubert)
> Cc: Xavier Vilajosana; 6tsch@ietf.org
> Subject: Re: [6tsch] how to handle different classes of traffic
>
>
> >>>>> "pthubert" == pthubert   writes:
>     pthubert> A particular cell in the slotframe may be reserved for a
>     pthubert> particular point to point flow (e.g. a control loop). In
>     pthubert> that case, the cell is equivalent to an MPLS label in that
>     pthubert> the sequence of cells is programmed (we call that a track)
>     pthubert> along the (multihop) path between Alice and Bob and only
>     pthubert> leads to Bob. Other cells are used for QoS based traffic
>
> Is this inherent in 6tsch, or is this the desired result of the PCE
> calculation that would take into account layer-3 forwarding?
>
> --
> Michael Richardson , Sandelman Software Works
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>

--047d7b2eda150eebaf04d835431a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Michael,
Just to quickly complement, TSCH does not include the concept =
of labeling cells for label-based switching, this is something we're co=
ntemplating for 6TSCH.
Thomas


On Mon, Mar 18, 2013 at 7:29 AM, Pascal Thubert (pthubert) <pthubert@cisc=
o.com> wrote:

Hello Michael



At the end of the day it's more a matter of use cases than technology s=
ince both centralized and distributed could do statistical mux.



In practice, though, it looks like it's the latter; for all I know, the=
 PCE related use cases only involve deterministic tracks such that each new=
 flow will get its own new track of newly allocated cells.



6TSCH adds RPL routing to scale a great many of less critical flows. This i=
s where we expect the traditional QoS with DSCPs, RED, etc...



Cheers,



Pascal






-----Original Message-----

From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael =
Richardson

Sent: lundi 18 mars 2013 14:19

To: Pascal Thubert (pthubert)

Cc: Xavier Vilajosana; 6tsch@ietf.org=


Subject: Re: [6tsch] how to handle different classes of traffic






>>>>> "pt=
hubert" =3D=3D pthubert =A0<Pascal> writes:

=A0 =A0 pthubert> A particular cell in the slotframe may be reserved for=
 a

=A0 =A0 pthubert> particular point to point flow (e.g. a control loop). =
In

=A0 =A0 pthubert> that case, the cell is equivalent to an MPLS label in =
that

=A0 =A0 pthubert> the sequence of cells is programmed (we call that a tr=
ack)

=A0 =A0 pthubert> along the (multihop) path between Alice and Bob and on=
ly

=A0 =A0 pthubert> leads to Bob. Other cells are used for QoS based traff=
ic



Is this inherent in 6tsch, or is this the desired result of the PCE calcula=
tion that would take into account layer-3 forwarding?



--

Michael Richardson <mcr+IETF@=
sandelman.ca>, Sandelman Software Works






_______________________=
________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





--047d7b2eda150eebaf04d835431a--

From twatteyne@gmail.com  Mon Mar 18 09:28:53 2013
Return-Path: 
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 64C0F21F8A0B for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 09:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.032
X-Spam-Level: 
X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 kOVxWqJUKZdh for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 09:28:44 -0700 (PDT)
Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE4121F8FA4 for <6tsch@ietf.org>; Mon, 18 Mar 2013 09:26:32 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id r11so867222pdi.6 for <6tsch@ietf.org>; Mon, 18 Mar 2013 09:26:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=9VmlIu9Di9XlSPR8oesglfAxFe/5JQ9cGS9JM1r2B0Q=; b=Z0Psq8yqMnDyjnaC3ykdEIZklJ2Dd8fzPRGHFgP0oIv0HYcpA75uM1oN+oOn+WP8Jj dimUZLxPVTcyMn/V8uPqvolN1LDLzh5NqFMluI5BrcpIzo4xA7OUuNp4jV9hwBQJ2CS6 G3gngG7RrUiI5Bt/KPUkLXflCXKEp/m423lL5P8CDfgQTzZUDgi1jAFlNmJgEqIbGRFd Y0QA33O2dLzG5EGbz9XrSsn2MYvAejiiQf+KIDQVoD2MzRxyXx0Lf3ZfWDVTyIvJ8I/a MJmLIYxcanPYr6wP6/OjiXK2CgyAlNCxlU0I2dwE6UE/SGXNyjrD74SdvT5S9pQNF3Os KLnw==
MIME-Version: 1.0
X-Received: by 10.68.20.8 with SMTP id j8mr34560822pbe.15.1363623991920; Mon, 18 Mar 2013 09:26:31 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Mon, 18 Mar 2013 09:26:31 -0700 (PDT)
Date: Mon, 18 Mar 2013 09:26:31 -0700
X-Google-Sender-Auth: UV2yZw3dhWNGr5jwSHM5oREtozY
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=bcaec5215d9da54f4204d83573cf
Subject: [6tsch] Interaction between RPL and PCE
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 16:28:53 -0000

--bcaec5215d9da54f4204d83573cf
Content-Type: text/plain; charset=ISO-8859-1

[subject was: Scope: 6LoWPAN + 1]

Maria Rita,

I fully agree with Pascal's suggestion to have the PCE only talk to one of
the two sides on a on-hop link, and have 6tus be in charge to telling the
other side to reserve the same cell. I believe Qin has also acknowledged
this, and has agreed to put this mechanism into 6tus. This would probably
mean adding some option in the 6tus message format saying "this is not a
negociation for a soft cell, but an order for you to add this hard cell".

All,

I believe Maria Rita is touching a very important point we haven't had time
to discuss last week in Orlando, but which I believe is essential: how do
RPL and the PCE interact? The PCE can have complete knowledge of the
network topology and the network traffic, so besides L2 resource
allocation, it could also make routing decision, i.e. build the track it
believe is best fit.

draft-ietf-roll-rpl-industrial-applicability-00 also states similar ideas:
"The domain of applicability for the RPL protocol may include all phases
but the Normal Operation phase, where the bandwidth allocation and the *routes
are usually optimized by an external Path Computing Engine (PCE)*. [...]
Additionally, it could be envisioned to include RPL in the normal operation
provided that a new Objective Function is defined that actually interacts
with the PCE is order to establish the reference topology, in which case *RPL
operations would only apply to emergency repair actions*. when the
reference topology becomes unusable for some failure, and as long as the
problem persists."

This shot-circuits RPL.

The two use cases I can see are:
1. the PCE makes decisions without RPL's intervention. RPL runs in the
background for emergency repair actions only.
2. RPL sets up multi-hop routes which the PCE uses for building tracks.
That is, the PCE only performs L2 resource allocation.

Do we agree to use only use case 1? If we go for 2, how does the PCE get
information about RPL routes (especially in storing mode)?

Thomas

On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA <
maria-rita.palattella@uni.lu> wrote:

> Hi Qin, and all,
> Sorry for coming back to this discussion after some time, but I wanted to
> raise and clarify a point.
>
> Qin>>>(2) If there is PCE, there may be different setting. For example,
> PCE is in charge for reserving both multiple hop path (i.e. every next hop
> Qin>>>neighbor) and cells; or PCE is just in charge for reserving the
> multiple hop path and leaving cell reservation to local, and the
> distributed cell reservation will meet the bandwidth requirement from
> multiple hop path reservation. In the first case, hard Qin>>> cell
>  reservation will be used.
>
> Qin >>>(3)If there is no PCE, both multi-hop path and cells are reserved
> in local.
> Qin>>For example, RPL + soft cell reservation in 6tus.
>
> From my point of view (and thinking about TASA implementation), the PCE
> shouldn't be in charge for reserving the multiple hop path. But the routing
> protocol (i.e., RPL in our case) should take care of the next hop neighbor
> selection.
> When a centralized approach is adopted, the PCE will schedule the cells
>  (i.e., hard cells according to 6tus terminology).
> While, when a distributed solution is used, 6tus will allocate the soft
> cells.
>
> In the centralized scenario with the PCE, to avoid the exchange of many
> signaling messages, for setting up the schedule, we may think (as Pascal
> was suggesting during one of the last call) to use some hybrid solutions.
> In other words, if PCE allocates (timeoffset1, channeloffset3, slotframe1,
> TX) to node A for transmitting to node B, then, node B could know locally
> from node A, (and not from the PCE), that the cell (timeoffset1,
> channeloffset3, slotframe1, RX) has been reserved to it, for receiving from
> node A.
> We may try to include some functionality in 6tus layer in order to manage
> such situation.
> What do you think?
>
> Maria Rita
>
>
> ----------------------------------------------------------------------------------------------------------------
> > On 3/14/13 9:02 PM, Paul Chilton wrote:
> >>>- optionally a PCE sits on the backbone and drives the LLNs' TSCH
> >>>schedules.
> >
> > Ah, maybe understood.  It doesn't say that existence of PCE is optional.
> > It says that it's optional to put PCE in the backbone.  It doesn't
> > preclude to put it on BBR.  Correct ?
> >
> > Shoichi
> > _______________________________________________
> > 6tsch mailing list
> > 6tsch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tsch
> >
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>

--bcaec5215d9da54f4204d83573cf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


[subject was: Scope: 6LoWPAN + 1]

Maria Rita,
=

I fully agree with Pascal's suggestion to have the PCE o=
nly talk to one of the two sides on a on-hop link, and have 6tus be in char=
ge to telling the other side to reserve the same cell. I believe Qin has al=
so acknowledged this, and has agreed to put this mechanism into 6tus. This =
would probably mean adding some option in the 6tus message format saying &q=
uot;this is not a negociation for a soft cell, but an order for you to add =
this hard cell".



All,

I believe=A0Maria Rita is=
=A0touching a very important point we haven't had time to discuss last =
week in Orlando, but which I believe is essential: how do RPL and the PCE i=
nteract? The PCE can have complete knowledge of the network topology and th=
e network traffic, so besides L2 resource allocation, it could also make ro=
uting decision, i.e. build the track it believe is best fit.



draft-ietf-roll-rpl-industrial-applicability-00 al=
so states similar ideas:
"The domain of applicabi=
lity for the RPL protocol may include all phases but the Normal Operation p=
hase, where the bandwidth allocation and the routes are usually optimize=
d by an external Path Computing Engine (PCE). [...] Additionally, it co=
uld be envisioned to include RPL in the normal operation provided that a ne=
w Objective Function is defined that actually interacts with the PCE is ord=
er to establish the reference topology, in which case RPL operations wou=
ld only apply to emergency repair actions. when the reference topology =
becomes unusable for some failure, and as long as the problem persists.&quo=
t;



This shot-circuits=A0RPL.

The two use cases I can see are:
1. the PCE makes decisions wit=
hout RPL's intervention. RPL runs in the background for emergency repai=
r actions only.


2. RPL sets up multi-hop routes which the PCE uses for building tracks=
. That is, the PCE only performs L2 resource allocation.

Do we agree to use only use case 1? If we go for 2, how does the PCE=
 get information about RPL routes (especially in storing mode)?



Thomas

On Mon,=
 Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA <maria-rita.pal=
attella@uni.lu> wrote:


Hi Qin, and all,

Sorry for coming back to this discussion after some time, but I wanted to r=
aise and clarify a point.



Qin>>>(2) If there is PCE, there may be different setting. For exa=
mple, PCE is in charge for reserving both multiple hop path (i.e. every nex=
t hop

Qin>>>neighbor) and cells; or PCE is just in charge for reserving =
the multiple hop path and leaving cell reservation to local, and the distri=
buted cell reservation will meet the bandwidth requirement from multiple ho=
p path reservation. In the first case, hard Qin>>> cell =A0reserva=
tion will be used.




Qin >>>(3)If there is no PCE, both multi-hop path and cells are re=
served in local.

Qin>>For example, RPL + soft cell reservation in 6tus.



>From my point of view (and thinking about TASA implementation), the PCE sho=
uldn't be in charge for reserving the multiple hop path. But the routin=
g protocol (i.e., RPL in our case) should take care of the next hop neighbo=
r selection.


When a centralized approach is adopted, the PCE will schedule the cells =A0=
(i.e., hard cells according to 6tus terminology).

While, when a distributed solution is used, 6tus will allocate the soft cel=
ls.



In the centralized scenario with the PCE, to avoid the exchange of many sig=
naling messages, for setting up the schedule, we may think (as Pascal was s=
uggesting during one of the last call) to use some hybrid solutions.


In other words, if PCE allocates (timeoffset1, channeloffset3, slotframe1, =
TX) to node A for transmitting to node B, then, node B could know locally f=
rom node A, (and not from the PCE), that the cell (timeoffset1, channeloffs=
et3, slotframe1, RX) has been reserved to it, for receiving from node A.

We may try to include some functionality in 6tus layer in order to manage s=
uch situation.

What do you think?



Maria Rita



---------------------------------------------------------------------------=
-------------------------------------


> On 3/14/13 9:02 PM, Paul Chilt=
on wrote:

>>>- optionally a PCE sits on the backbone and drives the LLNs'=
; TSCH

>>>schedules.

>

> Ah, maybe understood. =A0It doesn't say that existence of PCE is o=
ptional.

> It says that it's optional to put PCE in the backbone. =A0It doesn=
't

> preclude to put it on BBR. =A0Correct ?

>

> Shoichi

> _______________________________________________

> 6tsch mailing list

> 6tsch@ietf.org

> https://www.ietf.org/mailman/listinfo/6tsch

>



_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





--bcaec5215d9da54f4204d83573cf--

From qinwang@berkeley.edu  Mon Mar 18 10:25:32 2013
Return-Path: 
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 DC6D921F8FF3 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 10:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.532
X-Spam-Level: 
X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 nRbYEVOngar7 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 10:25:23 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 39F3121F8FEA for <6tsch@ietf.org>; Mon, 18 Mar 2013 10:25:21 -0700 (PDT)
Received: from cm01ws.ist.berkeley.edu ([169.229.218.163] helo=calmail.berkeley.edu) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UHdoE-0007q4-CD; Mon, 18 Mar 2013 10:25:20 -0700
Received: from 174.240.9.146 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Mon, 18 Mar 2013 10:25:18 -0700
Message-ID: <1dc657302a100f67f8f678323686f351.squirrel@calmail.berkeley.edu>
Date: Mon, 18 Mar 2013 10:25:18 -0700
From: "Qin Wang" 
To: "Thomas Watteyne" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Interaction between RPL and PCE
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 17:25:32 -0000

Thomas,

I think for a data flow, there are three elements needed to be defined or
scheduled explicitly or implicitly:
(1) multihop path, i.e. who is the next hop neighbor
(2) bandwidth and Qos requirement
(3) cell set (i.e. bundle) to implement the bandwidth

In case-1, all of the three elements are determined by PCE, and RPL is
just a backup and works on slot-aloha cells. Correct?

In case2, element(1) is determined by RPL based on Rank, and element(3) is
determined by PCE. But, who will determine element(2)? by PCE or by some
entity like RSVP/NSIS or DSCP?

Qin



> [subject was: Scope: 6LoWPAN + 1]
>
> Maria Rita,
>
> I fully agree with Pascal's suggestion to have the PCE only talk to one of
> the two sides on a on-hop link, and have 6tus be in charge to telling the
> other side to reserve the same cell. I believe Qin has also acknowledged
> this, and has agreed to put this mechanism into 6tus. This would probably
> mean adding some option in the 6tus message format saying "this is not a
> negociation for a soft cell, but an order for you to add this hard cell".
>
> All,
>
> I believe Maria Rita is touching a very important point we haven't had
> time
> to discuss last week in Orlando, but which I believe is essential: how do
> RPL and the PCE interact? The PCE can have complete knowledge of the
> network topology and the network traffic, so besides L2 resource
> allocation, it could also make routing decision, i.e. build the track it
> believe is best fit.
>
> draft-ietf-roll-rpl-industrial-applicability-00 also states similar ideas:
> "The domain of applicability for the RPL protocol may include all phases
> but the Normal Operation phase, where the bandwidth allocation and the
> *routes
> are usually optimized by an external Path Computing Engine (PCE)*. [...]
> Additionally, it could be envisioned to include RPL in the normal
> operation
> provided that a new Objective Function is defined that actually interacts
> with the PCE is order to establish the reference topology, in which case
> *RPL
> operations would only apply to emergency repair actions*. when the
> reference topology becomes unusable for some failure, and as long as the
> problem persists."
>
> This shot-circuits RPL.
>
> The two use cases I can see are:
> 1. the PCE makes decisions without RPL's intervention. RPL runs in the
> background for emergency repair actions only.
> 2. RPL sets up multi-hop routes which the PCE uses for building tracks.
> That is, the PCE only performs L2 resource allocation.
>
> Do we agree to use only use case 1? If we go for 2, how does the PCE get
> information about RPL routes (especially in storing mode)?
>
> Thomas
>
> On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA <
> maria-rita.palattella@uni.lu> wrote:
>
>> Hi Qin, and all,
>> Sorry for coming back to this discussion after some time, but I wanted
>> to
>> raise and clarify a point.
>>
>> Qin>>>(2) If there is PCE, there may be different setting. For example,
>> PCE is in charge for reserving both multiple hop path (i.e. every next
>> hop
>> Qin>>>neighbor) and cells; or PCE is just in charge for reserving the
>> multiple hop path and leaving cell reservation to local, and the
>> distributed cell reservation will meet the bandwidth requirement from
>> multiple hop path reservation. In the first case, hard Qin>>> cell
>>  reservation will be used.
>>
>> Qin >>>(3)If there is no PCE, both multi-hop path and cells are reserved
>> in local.
>> Qin>>For example, RPL + soft cell reservation in 6tus.
>>
>> From my point of view (and thinking about TASA implementation), the PCE
>> shouldn't be in charge for reserving the multiple hop path. But the
>> routing
>> protocol (i.e., RPL in our case) should take care of the next hop
>> neighbor
>> selection.
>> When a centralized approach is adopted, the PCE will schedule the cells
>>  (i.e., hard cells according to 6tus terminology).
>> While, when a distributed solution is used, 6tus will allocate the soft
>> cells.
>>
>> In the centralized scenario with the PCE, to avoid the exchange of many
>> signaling messages, for setting up the schedule, we may think (as Pascal
>> was suggesting during one of the last call) to use some hybrid
>> solutions.
>> In other words, if PCE allocates (timeoffset1, channeloffset3,
>> slotframe1,
>> TX) to node A for transmitting to node B, then, node B could know
>> locally
>> from node A, (and not from the PCE), that the cell (timeoffset1,
>> channeloffset3, slotframe1, RX) has been reserved to it, for receiving
>> from
>> node A.
>> We may try to include some functionality in 6tus layer in order to
>> manage
>> such situation.
>> What do you think?
>>
>> Maria Rita
>>
>>
>> ----------------------------------------------------------------------------------------------------------------
>> > On 3/14/13 9:02 PM, Paul Chilton wrote:
>> >>>- optionally a PCE sits on the backbone and drives the LLNs' TSCH
>> >>>schedules.
>> >
>> > Ah, maybe understood.  It doesn't say that existence of PCE is
>> optional.
>> > It says that it's optional to put PCE in the backbone.  It doesn't
>> > preclude to put it on BBR.  Correct ?
>> >
>> > Shoichi
>> > _______________________________________________
>> > 6tsch mailing list
>> > 6tsch@ietf.org
>> > https://www.ietf.org/mailman/listinfo/6tsch
>> >
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From qinwang@berkeley.edu  Mon Mar 18 10:48:31 2013
Return-Path: 
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 0FEC421F903E for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 10:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.239
X-Spam-Level: 
X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4]
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 Be5T4cg1wYqJ for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 10:48:22 -0700 (PDT)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id F345D21F8D8E for <6tsch@ietf.org>; Mon, 18 Mar 2013 10:48:21 -0700 (PDT)
Received: from cm01ws.ist.berkeley.edu ([169.229.218.163] helo=calmail.berkeley.edu) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UHeAV-0008Ui-Gi; Mon, 18 Mar 2013 10:48:20 -0700
Received: from 174.240.9.146 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Mon, 18 Mar 2013 10:48:19 -0700
Message-ID: <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu>
In-Reply-To: 
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu> 
Date: Mon, 18 Mar 2013 10:48:19 -0700
From: "Qin Wang" 
To: "Grieco" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "6tsch@ietf.org" <6tsch@ietf.org>, "Pascal Thubert \(pthubert\)" , JeongGil Ko , Qin Wang , Xavier Vilajosana 
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 17:48:31 -0000

Alfredo,

Firstly, my understanding is Hard cell reservation can only be used by
PCE, i.e.  centralized schedule. Thus, mobile node will join in network
based on the cells broadcast in EB. And, after its registration, PCE will
assign some Hard cells to it.

secondly, regarding to high priority of the data flow from the mobile
node, DSCP may help, i.e. the packets from the mobile node can include
Priority.

How do you think?

Qin



> Hi Qin and all,
>
> Just to challenge the two groups of functions Qin is talking about, what
> if a certain number of mobile nodes need hard reservation ? In this case,
> mobile nodes transmit Real time data to be delivered within a given
> deadline but 6tus does not know in advance the rank (or the position
> within the topology) of such nodes.
>
> I mean that this kind of traffic has the top priority but nobody knows in
> advance the exact position of the nodes that is going to generate that
> data.
>
> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes, how ?
>
> Thanks a lot in advance for your attention
>
> Cheers
>
> Alfredo
>
> --
> Luigi Alfredo Grieco, PhD
> Assistant Professor
> Department of Electrical and Information Engineering
> Politecnico di Bari
> Via Orabona 4 - 70125 - Bari - Italy
> +39 080 5963 911
> telematics.poliba.it/grieco
> Skype id: l.alfredo.grieco
> Mobile: +39 3346715672
>
>
> On 17 Mar 2013, at 17:47, "Qin Wang"  wrote:
>
>>
>>
>> I fully agree with Carsten that Simple is very important. Let's
>> overlapping the following three scenarios, then we will find only two
>> groups of functions 6tus should provide.
>>
>> (1) Hard cell reserve/remove, which supports the 1st scenario.
>> (2) Soft cell reserve/remove, which supports the 2nd and 3rd scenario.
>>
>> Any more?
>>
>> Qin
>>
>>
>>> Sorry for the delayed response. I was stuck on the plane for too long
>>> :)
>>>
>>> I like the discussion that Qin is going for where we define the
>>> scenarios.
>>> At the same time, as Carsten says we need to make sure overlapping
>>> scenarios of any sort are simplified and aggregated as much as
>>> possible.
>>>
>>> Let me just try to put my 2 cents in-line...
>>>
>>>
>>> On Mar 17, 2013, at 8:19 AM, Qin Wang  wrote:
>>>
>>>> Hi Pascal,
>>>>
>>>> It is a very good idea to establish a bundle of cells between A and B
>>>> by
>>>> just triggering 6tus in one side. We can design for different
>>>> scenarios.
>>>>
>>>> (1) PCE defines the track, i.e. the multihop path, the bandwidth of
>>>> each
>>>> hop, and scheduling hard-cells to implement the multihop path. Assume
>>>> nodeA and nodeB are one-hop neighbors along the path. In this case,
>>>> PCE
>>>> can send Create.hardcell command to 6tus layer in nodeA,and nodeA's
>>>> 6tus
>>>> sends Create.hardcell command to nodeB' 6tus, then the hard cell is
>>>> reserved. This function is not in the current version of 6tus draft,
>>>> but
>>>> we can add it in the next version easily.
>>>>
>>>> (2)PCE defines the multihop path and the bandwidth of each hop, but
>>>> not
>>>> schedules the cells to meet the path bandwidth. In this case, soft
>>>> cell
>>>> reservation will be applied, which is always triggered in Transmitting
>>>> side, and negotiated by the 6tus layer of both sides.
>>>>
>>>> (3)The cell reservation is triggered by upper layer, e.g. the
>>>> RSVP/NSIS
>>>> entity in nodeA. Then soft cell reservation process in 6tus layer of
>>>> nodeA
>>>> will by triggered, and the negotiation process is same as case (2).
>>>>
>>>> In summary, by adding reserve hard cell procedure into version-00 of
>>>> 6tus,
>>>> we can let the bundle reservation in every scenarios be triggered just
>>>> in
>>>> one side.
>>>>
>>>> How do you think?
>>>>
>>>
>>> Great first start in defining the scenarios.
>>>
>>>> Qin
>>>>
>>>>
>>>>
>>>>
>>>>> Hi Qin:
>>>>>
>>>>> I think we are on the same line. The services that 6TUS proposes do
>>>>> not
>>>>> depend on which protocol the request came in through.
>>>>> Since we are defining the protocol extensions, we'll make sure that
>>>>> the
>>>>> new information is directly digestible by the 6TUS layer.
>>>>> The protocol extensions will be separate specs, and there should be
>>>>> little
>>>>> to no dereference between those specs and yours.
>>>>>
>>>>> What's important to me to discuss is how we establish a bundle of
>>>>> cells
>>>>> between A and B.
>>>>> IMHO, it would be best if that can be achieved by triggering a
>>>>> service
>>>>> in
>>>>> A - no need to trigger B as well.
>>>>> That way, the volume of exchanges between PCE and nodes can be
>>>>> devided
>>>>> by
>>>>> 2.
>>>>>
>>>>> This would mean that there must be an exchange between 6TUS in A and
>>>>> 6TUS
>>>>> in B.
>>>>> Which  also would mean that there is a protocol part related to 6TUS…
>>>>>
>>>
>>> Fully agreed that this is needed. Being an independent layer, I don't
>>> see
>>> why not.
>>>
>>>
>>>>> Cheers,
>>>>>
>>>>> Pascal
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On
>>>>> Behalf
>>>>> Of
>>>>> Qin Wang
>>>>> Sent: vendredi 15 mars 2013 18:04
>>>>> To: JeongGil Ko
>>>>> Cc: 6tsch@ietf.org; Xavier Vilajosana
>>>>> Subject: Re: [6tsch] Schemes for resource allocation in the LLN for
>>>>> 6tus
>>>>>
>>>>> John and Xavi,
>>>>>
>>>>> I agree that understanding more about upper layer protocols like RSVP
>>>>> and
>>>>> NSIS is very helpful for designing 6tus. But, I want to make clearer
>>>>> about
>>>>> my understanding on the relationship between 6tus and existing
>>>>> reservation
>>>>> protocols like RSVP or NSIS.
>>>>>
>>>>> (1) When we talk about reservation in the context of 6tus, we mainly
>>>>> focus
>>>>> on  link resource (i.e. cell) reservation, which is required/
>>>>> triggered
>>>>> by
>>>>> upper layer. Even in the pure centralized approach, it may happen to
>>>>> cross-layer reserve both L3 and L2 resource, but you still can
>>>>> separate
>>>>> them logically.
>>>>>
>>>>> (2) The upper layer requirement to 6tus may come from PCE carried by
>>>>> protocol like CoAP, may come from the RSVP/NSIS entity inside nodes.
>>>>>
>>>>> Thus, for 6tus, the question is what kind of function and interface
>>>>> should
>>>>> be provided to support the upper layer, instead of which upper layer
>>>>> protocol should be used.
>>>>>
>>>>> How do you think?
>>>>>
>>>
>>> I agree with your arguments that the important thing is defining the
>>> functionalities. It seems like some of these efforts are on the way in
>>> the
>>> later emails. Me bringing in the term "RSVP" was not that I wanted to
>>> go
>>> an use RSVP in the way it is, but bring the (modified/customized)
>>> concept
>>> in for use in 6tus. As to what I read there may have been a
>>> misunderstanding between us but we are on the same line.
>>>
>>> Thanks!
>>>
>>> -John
>>>
>>>>> Qin
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>



From maria-rita.palattella@uni.lu  Mon Mar 18 11:01:31 2013
Return-Path: 
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 5664221F8FC7 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 11:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 PHLSOB7+mR9v for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 11:01:23 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1389521F85C0 for <6tsch@ietf.org>; Mon, 18 Mar 2013 11:01:20 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,865,1355094000"; d="scan'208";a="22975699"
Received: from unknown (HELO REED.uni.lux) ([10.21.2.9]) by hercules.uni.lu with ESMTP; 18 Mar 2013 19:01:10 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by REED.uni.lux ([fe80::31bb:b7a3:7abb:813e%10]) with mapi id 14.01.0438.000; Mon, 18 Mar 2013 19:01:10 +0100
From: Maria Rita PALATTELLA 
To: Qin Wang , Thomas Watteyne 
Thread-Topic: [6tsch] Interaction between RPL and PCE
Thread-Index: AQHOI/2PosZB1DXd1ke7ye2UJSruIpiruQ8h
Date: Mon, 18 Mar 2013 18:01:08 +0000
Message-ID: 
References: <1dc657302a100f67f8f678323686f351.squirrel@calmail.berkeley.edu>
In-Reply-To: <1dc657302a100f67f8f678323686f351.squirrel@calmail.berkeley.edu>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.34.0.8]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Interaction between RPL and PCE
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 18:01:31 -0000

Thomas, I think we should consider both cases (1) and (2), and not focused =
on only 1.=0A=
=0A=
As Qin said, in case (2), the PCE takes care of the cells/bundle allocation=
, while RPL sets up the multi-hop path. Actually this is the approach used =
by TASA.=0A=
But we still need an interaction between PCE and RPL. And this gap should b=
e filled by 6tsch.=0A=
For instance, based on the topology built by RPL, every child node may have=
 more than 1 parent node.  Then, one issue could be how the PCE selects the=
 next-hop wihile allocating the cells?=0A=
This may be done, according to the bandwitdth and QoS specification, e.g., =
the congestion level of the nodes.  =0A=
In any case the PCE will have to schedule the cells in order to provide the=
 required QoS (i.e., latency, duty cycle, etc.)=0A=
Foe instace, in TASA, the PCE builts the schedule based on the traffic offe=
red by the nodes, minimizing the network duty cycle.=0A=
=0A=
Maria Rita=0A=
=0A=
________________________________________=0A=
From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Qin Wang=
 [qinwang@berkeley.edu]=0A=
Sent: Monday, March 18, 2013 6:25 PM=0A=
To: Thomas Watteyne=0A=
Cc: IETF 6TSCH=0A=
Subject: Re: [6tsch] Interaction between RPL and PCE=0A=
=0A=
Thomas,=0A=
=0A=
I think for a data flow, there are three elements needed to be defined or=
=0A=
scheduled explicitly or implicitly:=0A=
(1) multihop path, i.e. who is the next hop neighbor=0A=
(2) bandwidth and Qos requirement=0A=
(3) cell set (i.e. bundle) to implement the bandwidth=0A=
=0A=
In case-1, all of the three elements are determined by PCE, and RPL is=0A=
just a backup and works on slot-aloha cells. Correct?=0A=
=0A=
In case2, element(1) is determined by RPL based on Rank, and element(3) is=
=0A=
determined by PCE. But, who will determine element(2)? by PCE or by some=0A=
entity like RSVP/NSIS or DSCP?=0A=
=0A=
Qin=0A=
=0A=
=0A=
=0A=
> [subject was: Scope: 6LoWPAN + 1]=0A=
>=0A=
> Maria Rita,=0A=
>=0A=
> I fully agree with Pascal's suggestion to have the PCE only talk to one o=
f=0A=
> the two sides on a on-hop link, and have 6tus be in charge to telling the=
=0A=
> other side to reserve the same cell. I believe Qin has also acknowledged=
=0A=
> this, and has agreed to put this mechanism into 6tus. This would probably=
=0A=
> mean adding some option in the 6tus message format saying "this is not a=
=0A=
> negociation for a soft cell, but an order for you to add this hard cell".=
=0A=
>=0A=
> All,=0A=
>=0A=
> I believe Maria Rita is touching a very important point we haven't had=0A=
> time=0A=
> to discuss last week in Orlando, but which I believe is essential: how do=
=0A=
> RPL and the PCE interact? The PCE can have complete knowledge of the=0A=
> network topology and the network traffic, so besides L2 resource=0A=
> allocation, it could also make routing decision, i.e. build the track it=
=0A=
> believe is best fit.=0A=
>=0A=
> draft-ietf-roll-rpl-industrial-applicability-00 also states similar ideas=
:=0A=
> "The domain of applicability for the RPL protocol may include all phases=
=0A=
> but the Normal Operation phase, where the bandwidth allocation and the=0A=
> *routes=0A=
> are usually optimized by an external Path Computing Engine (PCE)*. [...]=
=0A=
> Additionally, it could be envisioned to include RPL in the normal=0A=
> operation=0A=
> provided that a new Objective Function is defined that actually interacts=
=0A=
> with the PCE is order to establish the reference topology, in which case=
=0A=
> *RPL=0A=
> operations would only apply to emergency repair actions*. when the=0A=
> reference topology becomes unusable for some failure, and as long as the=
=0A=
> problem persists."=0A=
>=0A=
> This shot-circuits RPL.=0A=
>=0A=
> The two use cases I can see are:=0A=
> 1. the PCE makes decisions without RPL's intervention. RPL runs in the=0A=
> background for emergency repair actions only.=0A=
> 2. RPL sets up multi-hop routes which the PCE uses for building tracks.=
=0A=
> That is, the PCE only performs L2 resource allocation.=0A=
>=0A=
> Do we agree to use only use case 1? If we go for 2, how does the PCE get=
=0A=
> information about RPL routes (especially in storing mode)?=0A=
>=0A=
> Thomas=0A=
>=0A=
> On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA <=0A=
> maria-rita.palattella@uni.lu> wrote:=0A=
>=0A=
>> Hi Qin, and all,=0A=
>> Sorry for coming back to this discussion after some time, but I wanted=
=0A=
>> to=0A=
>> raise and clarify a point.=0A=
>>=0A=
>> Qin>>>(2) If there is PCE, there may be different setting. For example,=
=0A=
>> PCE is in charge for reserving both multiple hop path (i.e. every next=
=0A=
>> hop=0A=
>> Qin>>>neighbor) and cells; or PCE is just in charge for reserving the=0A=
>> multiple hop path and leaving cell reservation to local, and the=0A=
>> distributed cell reservation will meet the bandwidth requirement from=0A=
>> multiple hop path reservation. In the first case, hard Qin>>> cell=0A=
>>  reservation will be used.=0A=
>>=0A=
>> Qin >>>(3)If there is no PCE, both multi-hop path and cells are reserved=
=0A=
>> in local.=0A=
>> Qin>>For example, RPL + soft cell reservation in 6tus.=0A=
>>=0A=
>> From my point of view (and thinking about TASA implementation), the PCE=
=0A=
>> shouldn't be in charge for reserving the multiple hop path. But the=0A=
>> routing=0A=
>> protocol (i.e., RPL in our case) should take care of the next hop=0A=
>> neighbor=0A=
>> selection.=0A=
>> When a centralized approach is adopted, the PCE will schedule the cells=
=0A=
>>  (i.e., hard cells according to 6tus terminology).=0A=
>> While, when a distributed solution is used, 6tus will allocate the soft=
=0A=
>> cells.=0A=
>>=0A=
>> In the centralized scenario with the PCE, to avoid the exchange of many=
=0A=
>> signaling messages, for setting up the schedule, we may think (as Pascal=
=0A=
>> was suggesting during one of the last call) to use some hybrid=0A=
>> solutions.=0A=
>> In other words, if PCE allocates (timeoffset1, channeloffset3,=0A=
>> slotframe1,=0A=
>> TX) to node A for transmitting to node B, then, node B could know=0A=
>> locally=0A=
>> from node A, (and not from the PCE), that the cell (timeoffset1,=0A=
>> channeloffset3, slotframe1, RX) has been reserved to it, for receiving=
=0A=
>> from=0A=
>> node A.=0A=
>> We may try to include some functionality in 6tus layer in order to=0A=
>> manage=0A=
>> such situation.=0A=
>> What do you think?=0A=
>>=0A=
>> Maria Rita=0A=
>>=0A=
>>=0A=
>> ------------------------------------------------------------------------=
----------------------------------------=0A=
>> > On 3/14/13 9:02 PM, Paul Chilton wrote:=0A=
>> >>>- optionally a PCE sits on the backbone and drives the LLNs' TSCH=0A=
>> >>>schedules.=0A=
>> >=0A=
>> > Ah, maybe understood.  It doesn't say that existence of PCE is=0A=
>> optional.=0A=
>> > It says that it's optional to put PCE in the backbone.  It doesn't=0A=
>> > preclude to put it on BBR.  Correct ?=0A=
>> >=0A=
>> > Shoichi=0A=
>> > _______________________________________________=0A=
>> > 6tsch mailing list=0A=
>> > 6tsch@ietf.org=0A=
>> > https://www.ietf.org/mailman/listinfo/6tsch=0A=
>> >=0A=
>>=0A=
>> _______________________________________________=0A=
>> 6tsch mailing list=0A=
>> 6tsch@ietf.org=0A=
>> https://www.ietf.org/mailman/listinfo/6tsch=0A=
>> _______________________________________________=0A=
>> 6tsch mailing list=0A=
>> 6tsch@ietf.org=0A=
>> https://www.ietf.org/mailman/listinfo/6tsch=0A=
>>=0A=
> _______________________________________________=0A=
> 6tsch mailing list=0A=
> 6tsch@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/6tsch=0A=
>=0A=
=0A=
=0A=
_______________________________________________=0A=
6tsch mailing list=0A=
6tsch@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/6tsch=0A=

From alfredo.grieco@gmail.com  Mon Mar 18 11:02:09 2013
Return-Path: 
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 6261521F8FF4 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 11:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.633
X-Spam-Level: **
X-Spam-Status: No, score=2.633 tagged_above=-999 required=5 tests=[AWL=3.724,  BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1]
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 Vm93khLHaDUE for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 11:02:00 -0700 (PDT)
Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2B39321F8FFC for <6tsch@ietf.org>; Mon, 18 Mar 2013 11:01:58 -0700 (PDT)
Received: by mail-ee0-f50.google.com with SMTP id e51so2816798eek.9 for <6tsch@ietf.org>; Mon, 18 Mar 2013 11:01:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=btYLy+yxSuuzlk457i+Jc686oETMVuMCk2nADit7BlU=; b=SwolhWSx0qRme7G2OM4qKhMC3rj7jWjox+uPfBUt987GevcwYMz9lJzz5GwwTehW63 9YTfhaOcEk9d+DfQGIeuOG4nPgsjG57thCiquOjsQgecOrPSpR52BBkAJE+ZodkWGhdp aBC2vZ+sdiTkDiqUXbfaVEOJnr94JOpP5Y3bUf0kUxu5YyPTvxpyEYTQeBGiATTssA3s CJAF+Sz59yOdk08hWG4o7qOA9VUByrkR7DPZfk332o+ISlt2zG45S5HSBCSwxGjxSOLx pmY51JdOQmYQ2z1enOGeWZA4xADgxlMTGtY9D/43tfhJWa5J9Y1HASg+tYWhnD5NSzQi ADng==
X-Received: by 10.14.173.196 with SMTP id v44mr51077043eel.29.1363629717267; Mon, 18 Mar 2013 11:01:57 -0700 (PDT)
Received: from GriecoPC ([2.195.150.80]) by mx.google.com with ESMTPS id q5sm28596882eeo.17.2013.03.18.11.01.54 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 Mar 2013 11:01:56 -0700 (PDT)
From: "Alfredo Grieco" 
To: "'Qin Wang'" 
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>  <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu>
In-Reply-To: <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu>
Date: Mon, 18 Mar 2013 19:01:51 +0100
Message-ID: <51475694.85d00e0a.2654.3c21@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac4kAMtQSussuSL1Rma/+kOW6JJjdwAAOxYQ
Content-Language: en-us
Cc: 6tsch@ietf.org, "'Pascal Thubert \(pthubert\)'" , 'JeongGil Ko' , 'Xavier Vilajosana' 
Subject: [6tsch] R:  Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 18:02:09 -0000

Hi Qin,

Your proposal is sound.=20

Just a final remark: if my understanding is correct, the PCE should =
build a schedule that spans across multiple links from mobile node M =
towards the sink S.=20

If a M moves after the schedule has been built, some pre-assigned =
resources along that path could get lost (which could be tolerated) =
because of the change of the topology.

Is it ok ?

Cheers and thanks for your answer

Alfredo

 =20

-----Messaggio originale-----
Da: Qin Wang [mailto:qinwang@berkeley.edu]=20
Inviato: Monday, March 18, 2013 6:48 PM
A: Grieco
Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); 6tsch@ietf.org; =
Xavier Vilajosana
Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus

Alfredo,

Firstly, my understanding is Hard cell reservation can only be used by =
PCE, i.e.  centralized schedule. Thus, mobile node will join in network =
based on the cells broadcast in EB. And, after its registration, PCE =
will assign some Hard cells to it.

secondly, regarding to high priority of the data flow from the mobile =
node, DSCP may help, i.e. the packets from the mobile node can include =
Priority.

How do you think?

Qin



> Hi Qin and all,
>
> Just to challenge the two groups of functions Qin is talking about,=20
> what if a certain number of mobile nodes need hard reservation ? In=20
> this case, mobile nodes transmit Real time data to be delivered within =

> a given deadline but 6tus does not know in advance the rank (or the=20
> position within the topology) of such nodes.
>
> I mean that this kind of traffic has the top priority but nobody knows =

> in advance the exact position of the nodes that is going to generate=20
> that data.
>
> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes, how =
?
>
> Thanks a lot in advance for your attention
>
> Cheers
>
> Alfredo
>
> --
> Luigi Alfredo Grieco, PhD
> Assistant Professor
> Department of Electrical and Information Engineering Politecnico di=20
> Bari Via Orabona 4 - 70125 - Bari - Italy
> +39 080 5963 911
> telematics.poliba.it/grieco
> Skype id: l.alfredo.grieco
> Mobile: +39 3346715672
>
>
> On 17 Mar 2013, at 17:47, "Qin Wang"  wrote:
>
>>
>>
>> I fully agree with Carsten that Simple is very important. Let's=20
>> overlapping the following three scenarios, then we will find only two =

>> groups of functions 6tus should provide.
>>
>> (1) Hard cell reserve/remove, which supports the 1st scenario.
>> (2) Soft cell reserve/remove, which supports the 2nd and 3rd =
scenario.
>>
>> Any more?
>>
>> Qin
>>
>>
>>> Sorry for the delayed response. I was stuck on the plane for too=20
>>> long
>>> :)
>>>
>>> I like the discussion that Qin is going for where we define the=20
>>> scenarios.
>>> At the same time, as Carsten says we need to make sure overlapping=20
>>> scenarios of any sort are simplified and aggregated as much as=20
>>> possible.
>>>
>>> Let me just try to put my 2 cents in-line...
>>>
>>>
>>> On Mar 17, 2013, at 8:19 AM, Qin Wang  wrote:
>>>
>>>> Hi Pascal,
>>>>
>>>> It is a very good idea to establish a bundle of cells between A and =

>>>> B by just triggering 6tus in one side. We can design for different=20
>>>> scenarios.
>>>>
>>>> (1) PCE defines the track, i.e. the multihop path, the bandwidth of =

>>>> each hop, and scheduling hard-cells to implement the multihop path. =

>>>> Assume nodeA and nodeB are one-hop neighbors along the path. In=20
>>>> this case, PCE can send Create.hardcell command to 6tus layer in=20
>>>> nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB'=20
>>>> 6tus, then the hard cell is reserved. This function is not in the=20
>>>> current version of 6tus draft, but we can add it in the next=20
>>>> version easily.
>>>>
>>>> (2)PCE defines the multihop path and the bandwidth of each hop, but =

>>>> not schedules the cells to meet the path bandwidth. In this case,=20
>>>> soft cell reservation will be applied, which is always triggered in =

>>>> Transmitting side, and negotiated by the 6tus layer of both sides.
>>>>
>>>> (3)The cell reservation is triggered by upper layer, e.g. the=20
>>>> RSVP/NSIS entity in nodeA. Then soft cell reservation process in=20
>>>> 6tus layer of nodeA will by triggered, and the negotiation process=20
>>>> is same as case (2).
>>>>
>>>> In summary, by adding reserve hard cell procedure into version-00=20
>>>> of 6tus, we can let the bundle reservation in every scenarios be=20
>>>> triggered just in one side.
>>>>
>>>> How do you think?
>>>>
>>>
>>> Great first start in defining the scenarios.
>>>
>>>> Qin
>>>>
>>>>
>>>>
>>>>
>>>>> Hi Qin:
>>>>>
>>>>> I think we are on the same line. The services that 6TUS proposes=20
>>>>> do not depend on which protocol the request came in through.
>>>>> Since we are defining the protocol extensions, we'll make sure=20
>>>>> that the new information is directly digestible by the 6TUS layer.
>>>>> The protocol extensions will be separate specs, and there should=20
>>>>> be little to no dereference between those specs and yours.
>>>>>
>>>>> What's important to me to discuss is how we establish a bundle of=20
>>>>> cells between A and B.
>>>>> IMHO, it would be best if that can be achieved by triggering a=20
>>>>> service in A - no need to trigger B as well.
>>>>> That way, the volume of exchanges between PCE and nodes can be=20
>>>>> devided by 2.
>>>>>
>>>>> This would mean that there must be an exchange between 6TUS in A=20
>>>>> and 6TUS in B.
>>>>> Which  also would mean that there is a protocol part related to=20
>>>>> 6TUS=E2=80=A6
>>>>>
>>>
>>> Fully agreed that this is needed. Being an independent layer, I=20
>>> don't see why not.
>>>
>>>
>>>>> Cheers,
>>>>>
>>>>> Pascal
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On=20
>>>>> Behalf Of Qin Wang
>>>>> Sent: vendredi 15 mars 2013 18:04
>>>>> To: JeongGil Ko
>>>>> Cc: 6tsch@ietf.org; Xavier Vilajosana
>>>>> Subject: Re: [6tsch] Schemes for resource allocation in the LLN=20
>>>>> for 6tus
>>>>>
>>>>> John and Xavi,
>>>>>
>>>>> I agree that understanding more about upper layer protocols like=20
>>>>> RSVP and NSIS is very helpful for designing 6tus. But, I want to=20
>>>>> make clearer about my understanding on the relationship between=20
>>>>> 6tus and existing reservation protocols like RSVP or NSIS.
>>>>>
>>>>> (1) When we talk about reservation in the context of 6tus, we=20
>>>>> mainly focus on  link resource (i.e. cell) reservation, which is=20
>>>>> required/ triggered by upper layer. Even in the pure centralized=20
>>>>> approach, it may happen to cross-layer reserve both L3 and L2=20
>>>>> resource, but you still can separate them logically.
>>>>>
>>>>> (2) The upper layer requirement to 6tus may come from PCE carried=20
>>>>> by protocol like CoAP, may come from the RSVP/NSIS entity inside =
nodes.
>>>>>
>>>>> Thus, for 6tus, the question is what kind of function and=20
>>>>> interface should be provided to support the upper layer, instead=20
>>>>> of which upper layer protocol should be used.
>>>>>
>>>>> How do you think?
>>>>>
>>>
>>> I agree with your arguments that the important thing is defining the =

>>> functionalities. It seems like some of these efforts are on the way=20
>>> in the later emails. Me bringing in the term "RSVP" was not that I=20
>>> wanted to go an use RSVP in the way it is, but bring the=20
>>> (modified/customized) concept in for use in 6tus. As to what I read=20
>>> there may have been a misunderstanding between us but we are on the=20
>>> same line.
>>>
>>> Thanks!
>>>
>>> -John
>>>
>>>>> Qin
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>



From twatteyne@gmail.com  Mon Mar 18 12:14:45 2013
Return-Path: 
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 9337B21F90B9 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 12:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level: 
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.458,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 9r8qxD4V45YU for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 12:14:35 -0700 (PDT)
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id C1B0621F8548 for <6tsch@ietf.org>; Mon, 18 Mar 2013 12:13:21 -0700 (PDT)
Received: by mail-pb0-f45.google.com with SMTP id ro8so6708990pbb.4 for <6tsch@ietf.org>; Mon, 18 Mar 2013 12:13:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=S2PVMgnWmqs8TrFDLG6oQChbvSACuCK2Q1kYAjM396c=; b=Eue7P473zT5QOtzByfZkpSMZV5C/qd5qqFhpI6Eev8PZtn0vVepaV/CtNSqPAwneJ7 qgYqBtpM8XN8tCar7ZI3LOh6ReBAqIliCaUTh1Cq/DPpwDygLdj23eKJOvD26wK9Cb+i q7oBBVR5Pih2bh1rD8zfJC6WuresFDHDcElkbWVvn1MfrFLvJdIvJurPG1dq+HnGwCUY xEUDAfs9npMJNMG/QOISEPoItSgHkV859SGKdk+oUpHW/wIXzt7hXmYsM/HFxaXixZs4 OPOnIsbEPLfVdw1hBPBEmpMtbHuf5R28SxX5GSx/vRVOLX2GGUAzsJX9AAudK365UfbG e0Nw==
MIME-Version: 1.0
X-Received: by 10.68.220.9 with SMTP id ps9mr34358105pbc.38.1363634001447; Mon, 18 Mar 2013 12:13:21 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Mon, 18 Mar 2013 12:13:21 -0700 (PDT)
In-Reply-To: <5147469d.83b80e0a.4663.2235@mx.google.com>
References:  <5147469d.83b80e0a.4663.2235@mx.google.com>
Date: Mon, 18 Mar 2013 12:13:21 -0700
X-Google-Sender-Auth: cb9SPrJR7uREOy9kEt7NDADVGoM
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b10cb914343b304d837c8e0
Subject: Re: [6tsch] Interaction between RPL and PCE
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 19:14:45 -0000

--047d7b10cb914343b304d837c8e0
Content-Type: text/plain; charset=ISO-8859-1

Alfredo,
I agree that this would be a very nice feature to have. Would you have an
idea of how to do this? I believe it's pretty hard to maintain a schedule
which guarantees hard constraints for motes jumping around inside the
topology. Are you thinking of some super-fast handover, or something elsa?
Thomas

On Mon, Mar 18, 2013 at 9:53 AM, Alfredo Grieco wrote:

> Hi all,****
>
> ** **
>
> Is it possible to handle mobile nodes having hard constraints for their
> packets ? This is not so rare in industrial scenarios where there are many
> machines that moves and at the same time need to transmit their data.****
>
> ** **
>
> In this case, the topology cannot be known in advance because the position
> of the machines depends on the events that happen within the system.****
>
> ** **
>
> Is it still possible to build a reasonable schedule for this scenario ?
> Can 6tus account also for mobile nodes ?****
>
> ** **
>
> Cheers****
>
> ** **
>
> Alfredo****
>
> ** **
>
> ** **
>
> *Da**:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *Per conto
> di *Thomas Watteyne
> *Inviato**:* Monday, March 18, 2013 5:27 PM
> *A:* IETF 6TSCH
> *Oggetto**:* [6tsch] Interaction between RPL and PCE****
>
> ** **
>
> [subject was: Scope: 6LoWPAN + 1]****
>
> ** **
>
> Maria Rita,****
>
> ** **
>
> I fully agree with Pascal's suggestion to have the PCE only talk to one of
> the two sides on a on-hop link, and have 6tus be in charge to telling the
> other side to reserve the same cell. I believe Qin has also acknowledged
> this, and has agreed to put this mechanism into 6tus. This would probably
> mean adding some option in the 6tus message format saying "this is not a
> negociation for a soft cell, but an order for you to add this hard cell".*
> ***
>
> ** **
>
> All,****
>
> ** **
>
> I believe Maria Rita is touching a very important point we haven't had
> time to discuss last week in Orlando, but which I believe is essential: how
> do RPL and the PCE interact? The PCE can have complete knowledge of the
> network topology and the network traffic, so besides L2 resource
> allocation, it could also make routing decision, i.e. build the track it
> believe is best fit.****
>
> ** **
>
> draft-ietf-roll-rpl-industrial-applicability-00 also states similar ideas:
> ****
>
> "The domain of applicability for the RPL protocol may include all phases
> but the Normal Operation phase, where the bandwidth allocation and the *routes
> are usually optimized by an external Path Computing Engine (PCE)*. [...]
> Additionally, it could be envisioned to include RPL in the normal operation
> provided that a new Objective Function is defined that actually interacts
> with the PCE is order to establish the reference topology, in which case *RPL
> operations would only apply to emergency repair actions*. when the
> reference topology becomes unusable for some failure, and as long as the
> problem persists."****
>
> ** **
>
> This shot-circuits RPL.****
>
> ** **
>
> The two use cases I can see are:****
>
> 1. the PCE makes decisions without RPL's intervention. RPL runs in the
> background for emergency repair actions only.****
>
> 2. RPL sets up multi-hop routes which the PCE uses for building tracks.
> That is, the PCE only performs L2 resource allocation.****
>
> ** **
>
> Do we agree to use only use case 1? If we go for 2, how does the PCE get
> information about RPL routes (especially in storing mode)?****
>
> ** **
>
> Thomas****
>
> ** **
>
> On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA <
> maria-rita.palattella@uni.lu> wrote:****
>
> Hi Qin, and all,
> Sorry for coming back to this discussion after some time, but I wanted to
> raise and clarify a point.
>
> Qin>>>(2) If there is PCE, there may be different setting. For example,
> PCE is in charge for reserving both multiple hop path (i.e. every next hop
> Qin>>>neighbor) and cells; or PCE is just in charge for reserving the
> multiple hop path and leaving cell reservation to local, and the
> distributed cell reservation will meet the bandwidth requirement from
> multiple hop path reservation. In the first case, hard Qin>>> cell
>  reservation will be used.
>
> Qin >>>(3)If there is no PCE, both multi-hop path and cells are reserved
> in local.
> Qin>>For example, RPL + soft cell reservation in 6tus.
>
> From my point of view (and thinking about TASA implementation), the PCE
> shouldn't be in charge for reserving the multiple hop path. But the routing
> protocol (i.e., RPL in our case) should take care of the next hop neighbor
> selection.
> When a centralized approach is adopted, the PCE will schedule the cells
>  (i.e., hard cells according to 6tus terminology).
> While, when a distributed solution is used, 6tus will allocate the soft
> cells.
>
> In the centralized scenario with the PCE, to avoid the exchange of many
> signaling messages, for setting up the schedule, we may think (as Pascal
> was suggesting during one of the last call) to use some hybrid solutions.
> In other words, if PCE allocates (timeoffset1, channeloffset3, slotframe1,
> TX) to node A for transmitting to node B, then, node B could know locally
> from node A, (and not from the PCE), that the cell (timeoffset1,
> channeloffset3, slotframe1, RX) has been reserved to it, for receiving from
> node A.
> We may try to include some functionality in 6tus layer in order to manage
> such situation.
> What do you think?
>
> Maria Rita
>
>
> ----------------------------------------------------------------------------------------------------------------
> ****
>
> > On 3/14/13 9:02 PM, Paul Chilton wrote:
> >>>- optionally a PCE sits on the backbone and drives the LLNs' TSCH
> >>>schedules.
> >
> > Ah, maybe understood.  It doesn't say that existence of PCE is optional.
> > It says that it's optional to put PCE in the backbone.  It doesn't
> > preclude to put it on BBR.  Correct ?
> >
> > Shoichi
> > _______________________________________________
> > 6tsch mailing list
> > 6tsch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tsch
> >
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

--047d7b10cb914343b304d837c8e0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Alfredo,
I agree that this would be a very nice feature to have. Would =
you have an idea of how to do this? I believe it's pretty hard to maint=
ain a schedule which guarantees hard constraints for motes jumping around i=
nside the topology. Are you thinking of some super-fast handover, or someth=
ing elsa?


Thomas

On Mon, Mar 18, 2013 a=
t 9:53 AM, Alfredo Grieco <alfredo.grieco@gmail.com> =
wrote:


Hi all,


=A0
<=
font color=3D"#1f497d" face=3D"Calibri">Is it po=
ssible to handle mobile nodes having hard constraints for their packets ? T=
his is not so rare in industrial scenarios where there are many machines th=
at moves and at the same time need to transmit their data.


=A0
<=
font color=3D"#1f497d" face=3D"Calibri">In this =
case, the topology cannot be known in advance because the position of the m=
achines depends on the events that happen within the system.<=
/span>


=A0
<=
font color=3D"#1f497d" face=3D"Calibri">Is it st=
ill possible to build a reasonable schedule for this scenario ? Can 6tus ac=
count also for mobile nodes ?


=A0
<=
font color=3D"#1f497d" face=3D"Calibri">Cheers


=A0
<=
font color=3D"#1f497d" face=3D"Calibri">Alfredo<=
u>


=A0
<=
font color=3D"#1f497d" face=3D"Calibri">=
=A0


Da=
:<=
span style=3D"font-size:10.0pt;font-family:"Segoe UI","sans-=
serif""> 6=
tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] Per conto di Thomas Watteyne
Inviato: Monday, March 18, 2013 5:27 PM
=
A: IETF 6TSCH
Oggetto: [6tsch] Interaction between RPL and PCE


=A0
[subject was: Scope: 6LoWPAN + 1]=



=A0
=

Maria Rita,


=A0
<=
p class=3D"MsoNormal">I fully agree with Pascal's suggestion to have th=
e PCE only talk to one of the two sides on a on-hop link, and have 6tus be =
in charge to telling the other side to reserve the same cell. I believe Qin=
 has also acknowledged this, and has agreed to put this mechanism into 6tus=
. This would probably mean adding some option in the 6tus message format sa=
ying "this is not a negociation for a soft cell, but an order for you =
to add this hard cell".


=A0
=

All,


=A0
=

I believe=A0Maria Rita is=A0touching a very imp=
ortant point we haven't had time to discuss last week in Orlando, but w=
hich I believe is essential: how do RPL and the PCE interact? The PCE can h=
ave complete knowledge of the network topology and the network traffic, so =
besides L2 resource allocation, it could also make routing decision, i.e. b=
uild the track it believe is best fit.


=A0
=

=
draft-ietf-roll-rpl-industrial-applicabili=
ty-00 also states similar ideas:


"The domain of applicabil=
ity for the RPL protocol may include all phases but the Normal Operation ph=
ase, where the bandwidth allocation and the routes are usually optimized by an external Path Computing Engine (PCE=
). [...] Additionally, it could be envisioned to include RPL in =
the normal operation provided that a new Objective Function is defined that=
 actually interacts with the PCE is order to establish the reference topolo=
gy, in which case RPL operations would =
only apply to emergency repair actions. when the reference topol=
ogy becomes unusable for some failure, and as long as the problem persists.=
"


=A0
=

This shot-circuits=A0RPL.


=A0
=

The two use cases I can see are:<=
/span>


1. the PCE makes decisions without RPL=
9;s intervention. RPL runs in the background for emergency repair actions o=
nly.


2. RPL sets up multi-hop routes which the=
 PCE uses for building tracks. That is, the PCE only performs L2 resource a=
llocation.


=A0
=

Do we agree to use only use case 1? If we go fo=
r 2, how does the PCE get information about RPL routes (especially in stori=
ng mode)?


=A0
=

Thomas


=A0
<=
p class=3D"MsoNormal">On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELL=
A <mar=
ia-rita.palattella@uni.lu> wrote:


Hi Qin, and all,
Sorry for coming back to this di=
scussion after some time, but I wanted to raise and clarify a point.
Qin>>>(2) If there is PCE, there may be different setting. For ex=
ample, PCE is in charge for reserving both multiple hop path (i.e. every ne=
xt hop

Qin>>>neighbor) and cells; or PCE is just in charge for reserving =
the multiple hop path and leaving cell reservation to local, and the distri=
buted cell reservation will meet the bandwidth requirement from multiple ho=
p path reservation. In the first case, hard Qin>>> cell =A0reserva=
tion will be used.


Qin >>>(3)If there is no PCE, both multi-hop path and cells ar=
e reserved in local.
Qin>>For example, RPL + soft cell reservation=
 in 6tus.

From my point of view (and thinking about TASA implementat=
ion), the PCE shouldn't be in charge for reserving the multiple hop pat=
h. But the routing protocol (i.e., RPL in our case) should take care of the=
 next hop neighbor selection.

When a centralized approach is adopted, the PCE will schedule the cells =A0=
(i.e., hard cells according to 6tus terminology).
While, when a distribu=
ted solution is used, 6tus will allocate the soft cells.

In the cent=
ralized scenario with the PCE, to avoid the exchange of many signaling mess=
ages, for setting up the schedule, we may think (as Pascal was suggesting d=
uring one of the last call) to use some hybrid solutions.

In other words, if PCE allocates (timeoffset1, channeloffset3, slotframe1, =
TX) to node A for transmitting to node B, then, node B could know locally f=
rom node A, (and not from the PCE), that the cell (timeoffset1, channeloffs=
et3, slotframe1, RX) has been reserved to it, for receiving from node A.
We may try to include some functionality in 6tus layer in order to manage s=
uch situation.
What do you think?

Maria Rita

-------------=
---------------------------------------------------------------------------=
------------------------


=
> On 3/14/13 9:02 PM, Paul Chilton wrot=
e:
>>>- optionally a PCE sits on the backbone and drives the LL=
Ns' TSCH

>>>schedules.
>
> Ah, maybe understood. =A0It doesn=
9;t say that existence of PCE is optional.
> It says that it's op=
tional to put PCE in the backbone. =A0It doesn't
> preclude to pu=
t it on BBR. =A0Correct ?

>
> Shoichi
> ______________________________________________=
_
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listin=
fo/6tsch

>

_______________________________________________
6tsch mailin=
g list
6tsch@ietf.or=
g
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
6tsch@ietf.org
http=
s://www.ietf.org/mailman/listinfo/6tsch


=A0



--047d7b10cb914343b304d837c8e0--

From twatteyne@gmail.com  Mon Mar 18 12:19:00 2013
Return-Path: 
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 7D3B621F8A7E for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 12:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 wLjDzQ-6S2dZ for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 12:18:51 -0700 (PDT)
Received: from mail-da0-x236.google.com (mail-da0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id F0BAE21F89A5 for <6tsch@ietf.org>; Mon, 18 Mar 2013 12:18:50 -0700 (PDT)
Received: by mail-da0-f54.google.com with SMTP id p1so1518997dad.13 for <6tsch@ietf.org>; Mon, 18 Mar 2013 12:18:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=/WDBv9VjPctcioZ2+5JYsZGA88UQfSvNBittVbFkPV8=; b=W5V7patjaXMN7G3nvDbeaPwuMYzydd1PtHVChX4Gw8btgF+wstGvejn08yR5VJp33C 3iTVY7TpVg0lWbXoQTD+Oa24kooe0rrH7AXLRK27SgdpFXUUUQCQje9KPn1TodQmk7oU BTHPoilyXjGQTOgwV3cisQu4VHkngzJWY1oerbHrel64MbeHdL0OmEtMB9wkp8OAoTSq QZZeu2ex6uNFhDbM6v95vF+SLVbeF9cgrJ/6StsU8PBUrWk8rPDrVSj0oRLxnoF8Wpq0 8fIs+ONdVghDwK3XmZcyB+Ph3+TeuLczU/5lX4vkjrFZ8mENJCYJXE5CBQqs+Xl0NpKV lI2w==
MIME-Version: 1.0
X-Received: by 10.68.20.8 with SMTP id j8mr35353109pbe.15.1363634330664; Mon, 18 Mar 2013 12:18:50 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Mon, 18 Mar 2013 12:18:50 -0700 (PDT)
In-Reply-To: <1dc657302a100f67f8f678323686f351.squirrel@calmail.berkeley.edu>
References: <1dc657302a100f67f8f678323686f351.squirrel@calmail.berkeley.edu>
Date: Mon, 18 Mar 2013 12:18:50 -0700
X-Google-Sender-Auth: B8484T2jlKc36dXW8KpEgXFF-yI
Message-ID: 
From: Thomas Watteyne 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=bcaec5215d9de204b804d837db47
Subject: Re: [6tsch] Interaction between RPL and PCE
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 19:19:00 -0000

--bcaec5215d9de204b804d837db47
Content-Type: text/plain; charset=ISO-8859-1

Qin,

Please see inline.

On Mon, Mar 18, 2013 at 10:25 AM, Qin Wang  wrote:

> Thomas,
>
> I think for a data flow, there are three elements needed to be defined or
> scheduled explicitly or implicitly:
> (1) multihop path, i.e. who is the next hop neighbor
> (2) bandwidth and Qos requirement
> (3) cell set (i.e. bundle) to implement the bandwidth
>
> In case-1, all of the three elements are determined by PCE, and RPL is
> just a backup and works on slot-aloha cells. Correct?
>

I believe that's correct. BTW, I'm not per se advocating for this solution,
but it seems to be the approach draft-ietf-roll-rpl-industrial-applicability
takes.


> In case2, element(1) is determined by RPL based on Rank, and element(3) is
> determined by PCE. But, who will determine element(2)? by PCE or by some
> entity like RSVP/NSIS or DSCP?
>
>
Agreed. It relatively straightforward for a PCE to compute a schedule and
distribute that into the network, but how does it figure out what the
requirements are from the nodes in the network. Could we reuse a "PCE
requirements" protocol out there?


> Qin
>
> > [subject was: Scope: 6LoWPAN + 1]
> >
> > Maria Rita,
> >
> > I fully agree with Pascal's suggestion to have the PCE only talk to one
> of
> > the two sides on a on-hop link, and have 6tus be in charge to telling the
> > other side to reserve the same cell. I believe Qin has also acknowledged
> > this, and has agreed to put this mechanism into 6tus. This would probably
> > mean adding some option in the 6tus message format saying "this is not a
> > negociation for a soft cell, but an order for you to add this hard cell".
> >
> > All,
> >
> > I believe Maria Rita is touching a very important point we haven't had
> > time
> > to discuss last week in Orlando, but which I believe is essential: how do
> > RPL and the PCE interact? The PCE can have complete knowledge of the
> > network topology and the network traffic, so besides L2 resource
> > allocation, it could also make routing decision, i.e. build the track it
> > believe is best fit.
> >
> > draft-ietf-roll-rpl-industrial-applicability-00 also states similar
> ideas:
> > "The domain of applicability for the RPL protocol may include all phases
> > but the Normal Operation phase, where the bandwidth allocation and the
> > *routes
> > are usually optimized by an external Path Computing Engine (PCE)*. [...]
> > Additionally, it could be envisioned to include RPL in the normal
> > operation
> > provided that a new Objective Function is defined that actually interacts
> > with the PCE is order to establish the reference topology, in which case
> > *RPL
> > operations would only apply to emergency repair actions*. when the
> > reference topology becomes unusable for some failure, and as long as the
> > problem persists."
> >
> > This shot-circuits RPL.
> >
> > The two use cases I can see are:
> > 1. the PCE makes decisions without RPL's intervention. RPL runs in the
> > background for emergency repair actions only.
> > 2. RPL sets up multi-hop routes which the PCE uses for building tracks.
> > That is, the PCE only performs L2 resource allocation.
> >
> > Do we agree to use only use case 1? If we go for 2, how does the PCE get
> > information about RPL routes (especially in storing mode)?
> >
> > Thomas
> >
> > On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA <
> > maria-rita.palattella@uni.lu> wrote:
> >
> >> Hi Qin, and all,
> >> Sorry for coming back to this discussion after some time, but I wanted
> >> to
> >> raise and clarify a point.
> >>
> >> Qin>>>(2) If there is PCE, there may be different setting. For example,
> >> PCE is in charge for reserving both multiple hop path (i.e. every next
> >> hop
> >> Qin>>>neighbor) and cells; or PCE is just in charge for reserving the
> >> multiple hop path and leaving cell reservation to local, and the
> >> distributed cell reservation will meet the bandwidth requirement from
> >> multiple hop path reservation. In the first case, hard Qin>>> cell
> >>  reservation will be used.
> >>
> >> Qin >>>(3)If there is no PCE, both multi-hop path and cells are reserved
> >> in local.
> >> Qin>>For example, RPL + soft cell reservation in 6tus.
> >>
> >> From my point of view (and thinking about TASA implementation), the PCE
> >> shouldn't be in charge for reserving the multiple hop path. But the
> >> routing
> >> protocol (i.e., RPL in our case) should take care of the next hop
> >> neighbor
> >> selection.
> >> When a centralized approach is adopted, the PCE will schedule the cells
> >>  (i.e., hard cells according to 6tus terminology).
> >> While, when a distributed solution is used, 6tus will allocate the soft
> >> cells.
> >>
> >> In the centralized scenario with the PCE, to avoid the exchange of many
> >> signaling messages, for setting up the schedule, we may think (as Pascal
> >> was suggesting during one of the last call) to use some hybrid
> >> solutions.
> >> In other words, if PCE allocates (timeoffset1, channeloffset3,
> >> slotframe1,
> >> TX) to node A for transmitting to node B, then, node B could know
> >> locally
> >> from node A, (and not from the PCE), that the cell (timeoffset1,
> >> channeloffset3, slotframe1, RX) has been reserved to it, for receiving
> >> from
> >> node A.
> >> We may try to include some functionality in 6tus layer in order to
> >> manage
> >> such situation.
> >> What do you think?
> >>
> >> Maria Rita
> >>
> >>
> >>
> ----------------------------------------------------------------------------------------------------------------
> >> > On 3/14/13 9:02 PM, Paul Chilton wrote:
> >> >>>- optionally a PCE sits on the backbone and drives the LLNs' TSCH
> >> >>>schedules.
> >> >
> >> > Ah, maybe understood.  It doesn't say that existence of PCE is
> >> optional.
> >> > It says that it's optional to put PCE in the backbone.  It doesn't
> >> > preclude to put it on BBR.  Correct ?
> >> >
> >> > Shoichi
> >> > _______________________________________________
> >> > 6tsch mailing list
> >> > 6tsch@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/6tsch
> >> >
> >>
> >> _______________________________________________
> >> 6tsch mailing list
> >> 6tsch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/6tsch
> >> _______________________________________________
> >> 6tsch mailing list
> >> 6tsch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/6tsch
> >>
> > _______________________________________________
> > 6tsch mailing list
> > 6tsch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tsch
> >
>
>
>

--bcaec5215d9de204b804d837db47
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Qin,

Please see inline.

On Mon, Mar 18, 2013 at 10:25 AM, Qin Wang <qinwang@berkeley.edu=
> wrote:


Thomas,



I think for a data flow, there are three elements needed to be defined or
scheduled explicitly or implicitly:

(1) multihop path, i.e. who is the next hop neighbor

(2) bandwidth and Qos requirement

(3) cell set (i.e. bundle) to implement the bandwidth



In case-1, all of the three elements are determined by PCE, and RPL is

just a backup and works on slot-aloha cells. Correct?
=

I believe that's correct. BTW, I'm not per se advoca=
ting for this solution, but it seems to be the approach=A0draft-ietf-roll-rpl-industrial-applicability takes.


=A0
In case2, element(1) is determ=
ined by RPL based on Rank, and element(3) is

determined by PCE. But, who will determine element(2)? by PCE or by some
entity like RSVP/NSIS or DSCP?



Agreed. It relatively straightforward =
for a PCE to compute a schedule and distribute that into the network, but h=
ow does it figure out what the requirements are from the nodes in the netwo=
rk. Could we reuse a "PCE requirements" protocol out there?


=A0

Qin



> [subject was: Scope: 6LoWPAN + 1]

>

> Maria Rita,

>

> I fully agree with Pascal's suggestion to have the PCE only talk t=
o one of

> the two sides on a on-hop link, and have 6tus be in charge to telling =
the

> other side to reserve the same cell. I believe Qin has also acknowledg=
ed

> this, and has agreed to put this mechanism into 6tus. This would proba=
bly

> mean adding some option in the 6tus message format saying "this i=
s not a

> negociation for a soft cell, but an order for you to add this hard cel=
l".

>

> All,

>

> I believe Maria Rita is touching a very important point we haven't=
 had

> time

> to discuss last week in Orlando, but which I believe is essential: how=
 do

> RPL and the PCE interact? The PCE can have complete knowledge of the
> network topology and the network traffic, so besides L2 resource

> allocation, it could also make routing decision, i.e. build the track =
it

> believe is best fit.

>

> draft-ietf-roll-rpl-industrial-applicability-00 also states similar id=
eas:

> "The domain of applicability for the RPL protocol may include all=
 phases

> but the Normal Operation phase, where the bandwidth allocation and the=



> *routes

> are usually optimized by an external Path Computing Engine (PCE)*. [..=
.]


> Additionally, it could be envisioned to include RPL =
in the normal

> operation

> provided that a new Objective Function is defined that actually intera=
cts

> with the PCE is order to establish the reference topology, in which ca=
se


> *RPL

> operations would only apply to emergency repair actions*. when the


> reference topology becomes unu=
sable for some failure, and as long as the

> problem persists."

>

> This shot-circuits RPL.

>

> The two use cases I can see are:

> 1. the PCE makes decisions without RPL's intervention. RPL runs in=
 the

> background for emergency repair actions only.

> 2. RPL sets up multi-hop routes which the PCE uses for building tracks=
.

> That is, the PCE only performs L2 resource allocation.

>

> Do we agree to use only use case 1? If we go for 2, how does the PCE g=
et

> information about RPL routes (especially in storing mode)?

>

> Thomas

>

> On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA <

> maria-rita.palattella@=
uni.lu> wrote:

>

>> Hi Qin, and all,

>> Sorry for coming back to this discussion after some time, but I wa=
nted

>> to

>> raise and clarify a point.

>>

>> Qin>>>(2) If there is PCE, there may be different setting=
. For example,

>> PCE is in charge for reserving both multiple hop path (i.e. every =
next

>> hop

>> Qin>>>neighbor) and cells; or PCE is just in charge for r=
eserving the

>> multiple hop path and leaving cell reservation to local, and the
>> distributed cell reservation will meet the bandwidth requirement f=
rom

>> multiple hop path reservation. In the first case, hard Qin>>=
> cell

>> =A0reservation will be used.

>>

>> Qin >>>(3)If there is no PCE, both multi-hop path and cel=
ls are reserved

>> in local.

>> Qin>>For example, RPL + soft cell reservation in 6tus.

>>

>> From my point of view (and thinking about TASA implementation), th=
e PCE

>> shouldn't be in charge for reserving the multiple hop path. Bu=
t the

>> routing

>> protocol (i.e., RPL in our case) should take care of the next hop<=
br>
>> neighbor

>> selection.

>> When a centralized approach is adopted, the PCE will schedule the =
cells

>> =A0(i.e., hard cells according to 6tus terminology).

>> While, when a distributed solution is used, 6tus will allocate the=
 soft

>> cells.

>>

>> In the centralized scenario with the PCE, to avoid the exchange of=
 many

>> signaling messages, for setting up the schedule, we may think (as =
Pascal

>> was suggesting during one of the last call) to use some hybrid

>> solutions.

>> In other words, if PCE allocates (timeoffset1, channeloffset3,

>> slotframe1,

>> TX) to node A for transmitting to node B, then, node B could know<=
br>
>> locally

>> from node A, (and not from the PCE), that the cell (timeoffset1,
>> channeloffset3, slotframe1, RX) has been reserved to it, for recei=
ving

>> from

>> node A.

>> We may try to include some functionality in 6tus layer in order to=


>> manage

>> such situation.

>> What do you think?

>>

>> Maria Rita

>>

>>

>> ------------------------------------------------------------------=
----------------------------------------------

>> > On 3/14/13 9:02 PM, Paul Chilton wrote:

>> >>>- optionally a PCE sits on the backbone and drives the=
 LLNs' TSCH

>> >>>schedules.

>> >

>> > Ah, maybe understood. =A0It doesn't say that existence of=
 PCE is

>> optional.

>> > It says that it's optional to put PCE in the backbone. =
=A0It doesn't

>> > preclude to put it on BBR. =A0Correct ?

>> >

>> > Shoichi

>> > _______________________________________________

>> > 6tsch mailing list

>> > 6tsch@ietf.org

>> > https://www.ietf.org/mailman/listinfo/6tsch

>> >

>>

>> _______________________________________________

>> 6tsch mailing list

>> 6tsch@ietf.org

>> https://www.ietf.org/mailman/listinfo/6tsch

>> _______________________________________________

>> 6tsch mailing list

>> 6tsch@ietf.org

>> https://www.ietf.org/mailman/listinfo/6tsch

>>

> _______________________________________________

> 6tsch mailing list

> 6tsch@ietf.org

> https://www.ietf.org/mailman/listinfo/6tsch

>









--bcaec5215d9de204b804d837db47--

From qinwang@berkeley.edu  Mon Mar 18 12:20:24 2013
Return-Path: 
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 83F5021F8C4F for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 12:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.217
X-Spam-Level: 
X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4]
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 duiL-tp+EcUi for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 12:20:13 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id C74B721F8B37 for <6tsch@ietf.org>; Mon, 18 Mar 2013 12:20:10 -0700 (PDT)
Received: from cm04ws.ist.berkeley.edu ([169.229.218.166] helo=calmail.berkeley.edu) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UHfbM-0003lv-5T; Mon, 18 Mar 2013 12:20:09 -0700
Received: from 174.240.9.213 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Mon, 18 Mar 2013 12:20:08 -0700
Message-ID: <1b952faca1b2846136ff23c6723eeb63.squirrel@calmail.berkeley.edu>
In-Reply-To: <51475694.85d00e0a.2654.3c21@mx.google.com>
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>  <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu> <51475694.85d00e0a.2654.3c21@mx.google.com>
Date: Mon, 18 Mar 2013 12:20:08 -0700
From: "Qin Wang" 
To: "Alfredo Grieco" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: 6tsch@ietf.org, "'Pascal Thubert \(pthubert\)'" , 'JeongGil Ko' , 'Qin Wang' , 'Xavier Vilajosana' 
Subject: Re: [6tsch] R: Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 19:20:24 -0000

Alfredo,

I think your remark is correct. So, if there is lots of mobility, I would
be prefer distributed approach, i.e. Soft Cell reservation locally + RPL +
DSCP for QoS.

Qin


> Hi Qin,
>
> Your proposal is sound.
>
> Just a final remark: if my understanding is correct, the PCE should build
> a schedule that spans across multiple links from mobile node M towards the
> sink S.
>
> If a M moves after the schedule has been built, some pre-assigned
> resources along that path could get lost (which could be tolerated)
> because of the change of the topology.
>
> Is it ok ?
>
> Cheers and thanks for your answer
>
> Alfredo
>
>
>
> -----Messaggio originale-----
> Da: Qin Wang [mailto:qinwang@berkeley.edu]
> Inviato: Monday, March 18, 2013 6:48 PM
> A: Grieco
> Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); 6tsch@ietf.org;
> Xavier Vilajosana
> Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
>
> Alfredo,
>
> Firstly, my understanding is Hard cell reservation can only be used by
> PCE, i.e.  centralized schedule. Thus, mobile node will join in network
> based on the cells broadcast in EB. And, after its registration, PCE will
> assign some Hard cells to it.
>
> secondly, regarding to high priority of the data flow from the mobile
> node, DSCP may help, i.e. the packets from the mobile node can include
> Priority.
>
> How do you think?
>
> Qin
>
>
>
>> Hi Qin and all,
>>
>> Just to challenge the two groups of functions Qin is talking about,
>> what if a certain number of mobile nodes need hard reservation ? In
>> this case, mobile nodes transmit Real time data to be delivered within
>> a given deadline but 6tus does not know in advance the rank (or the
>> position within the topology) of such nodes.
>>
>> I mean that this kind of traffic has the top priority but nobody knows
>> in advance the exact position of the nodes that is going to generate
>> that data.
>>
>> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes, how ?
>>
>> Thanks a lot in advance for your attention
>>
>> Cheers
>>
>> Alfredo
>>
>> --
>> Luigi Alfredo Grieco, PhD
>> Assistant Professor
>> Department of Electrical and Information Engineering Politecnico di
>> Bari Via Orabona 4 - 70125 - Bari - Italy
>> +39 080 5963 911
>> telematics.poliba.it/grieco
>> Skype id: l.alfredo.grieco
>> Mobile: +39 3346715672
>>
>>
>> On 17 Mar 2013, at 17:47, "Qin Wang"  wrote:
>>
>>>
>>>
>>> I fully agree with Carsten that Simple is very important. Let's
>>> overlapping the following three scenarios, then we will find only two
>>> groups of functions 6tus should provide.
>>>
>>> (1) Hard cell reserve/remove, which supports the 1st scenario.
>>> (2) Soft cell reserve/remove, which supports the 2nd and 3rd scenario.
>>>
>>> Any more?
>>>
>>> Qin
>>>
>>>
>>>> Sorry for the delayed response. I was stuck on the plane for too
>>>> long
>>>> :)
>>>>
>>>> I like the discussion that Qin is going for where we define the
>>>> scenarios.
>>>> At the same time, as Carsten says we need to make sure overlapping
>>>> scenarios of any sort are simplified and aggregated as much as
>>>> possible.
>>>>
>>>> Let me just try to put my 2 cents in-line...
>>>>
>>>>
>>>> On Mar 17, 2013, at 8:19 AM, Qin Wang  wrote:
>>>>
>>>>> Hi Pascal,
>>>>>
>>>>> It is a very good idea to establish a bundle of cells between A and
>>>>> B by just triggering 6tus in one side. We can design for different
>>>>> scenarios.
>>>>>
>>>>> (1) PCE defines the track, i.e. the multihop path, the bandwidth of
>>>>> each hop, and scheduling hard-cells to implement the multihop path.
>>>>> Assume nodeA and nodeB are one-hop neighbors along the path. In
>>>>> this case, PCE can send Create.hardcell command to 6tus layer in
>>>>> nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB'
>>>>> 6tus, then the hard cell is reserved. This function is not in the
>>>>> current version of 6tus draft, but we can add it in the next
>>>>> version easily.
>>>>>
>>>>> (2)PCE defines the multihop path and the bandwidth of each hop, but
>>>>> not schedules the cells to meet the path bandwidth. In this case,
>>>>> soft cell reservation will be applied, which is always triggered in
>>>>> Transmitting side, and negotiated by the 6tus layer of both sides.
>>>>>
>>>>> (3)The cell reservation is triggered by upper layer, e.g. the
>>>>> RSVP/NSIS entity in nodeA. Then soft cell reservation process in
>>>>> 6tus layer of nodeA will by triggered, and the negotiation process
>>>>> is same as case (2).
>>>>>
>>>>> In summary, by adding reserve hard cell procedure into version-00
>>>>> of 6tus, we can let the bundle reservation in every scenarios be
>>>>> triggered just in one side.
>>>>>
>>>>> How do you think?
>>>>>
>>>>
>>>> Great first start in defining the scenarios.
>>>>
>>>>> Qin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi Qin:
>>>>>>
>>>>>> I think we are on the same line. The services that 6TUS proposes
>>>>>> do not depend on which protocol the request came in through.
>>>>>> Since we are defining the protocol extensions, we'll make sure
>>>>>> that the new information is directly digestible by the 6TUS layer.
>>>>>> The protocol extensions will be separate specs, and there should
>>>>>> be little to no dereference between those specs and yours.
>>>>>>
>>>>>> What's important to me to discuss is how we establish a bundle of
>>>>>> cells between A and B.
>>>>>> IMHO, it would be best if that can be achieved by triggering a
>>>>>> service in A - no need to trigger B as well.
>>>>>> That way, the volume of exchanges between PCE and nodes can be
>>>>>> devided by 2.
>>>>>>
>>>>>> This would mean that there must be an exchange between 6TUS in A
>>>>>> and 6TUS in B.
>>>>>> Which  also would mean that there is a protocol part related to
>>>>>> 6TUS…
>>>>>>
>>>>
>>>> Fully agreed that this is needed. Being an independent layer, I
>>>> don't see why not.
>>>>
>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Pascal
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On
>>>>>> Behalf Of Qin Wang
>>>>>> Sent: vendredi 15 mars 2013 18:04
>>>>>> To: JeongGil Ko
>>>>>> Cc: 6tsch@ietf.org; Xavier Vilajosana
>>>>>> Subject: Re: [6tsch] Schemes for resource allocation in the LLN
>>>>>> for 6tus
>>>>>>
>>>>>> John and Xavi,
>>>>>>
>>>>>> I agree that understanding more about upper layer protocols like
>>>>>> RSVP and NSIS is very helpful for designing 6tus. But, I want to
>>>>>> make clearer about my understanding on the relationship between
>>>>>> 6tus and existing reservation protocols like RSVP or NSIS.
>>>>>>
>>>>>> (1) When we talk about reservation in the context of 6tus, we
>>>>>> mainly focus on  link resource (i.e. cell) reservation, which is
>>>>>> required/ triggered by upper layer. Even in the pure centralized
>>>>>> approach, it may happen to cross-layer reserve both L3 and L2
>>>>>> resource, but you still can separate them logically.
>>>>>>
>>>>>> (2) The upper layer requirement to 6tus may come from PCE carried
>>>>>> by protocol like CoAP, may come from the RSVP/NSIS entity inside
>>>>>> nodes.
>>>>>>
>>>>>> Thus, for 6tus, the question is what kind of function and
>>>>>> interface should be provided to support the upper layer, instead
>>>>>> of which upper layer protocol should be used.
>>>>>>
>>>>>> How do you think?
>>>>>>
>>>>
>>>> I agree with your arguments that the important thing is defining the
>>>> functionalities. It seems like some of these efforts are on the way
>>>> in the later emails. Me bringing in the term "RSVP" was not that I
>>>> wanted to go an use RSVP in the way it is, but bring the
>>>> (modified/customized) concept in for use in 6tus. As to what I read
>>>> there may have been a misunderstanding between us but we are on the
>>>> same line.
>>>>
>>>> Thanks!
>>>>
>>>> -John
>>>>
>>>>>> Qin
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
>
>



From xvilajosana@eecs.berkeley.edu  Mon Mar 18 12:41:07 2013
Return-Path: 
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 1306121F8F1C for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 12:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4]
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 ZHn1x0uPSGaq for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 12:40:53 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDB121F8CCF for <6tsch@ietf.org>; Mon, 18 Mar 2013 12:40:53 -0700 (PDT)
Received: from dhcp-33-135.eecs.berkeley.edu ([128.32.33.135]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UHfvN-0006OM-G4; Mon, 18 Mar 2013 12:40:52 -0700
Message-ID: <51476DC1.5070707@eecs.berkeley.edu>
Date: Mon, 18 Mar 2013 12:40:49 -0700
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Grieco 
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>  <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu> <51475694.85d00e0a.2654.3c21@mx.google.com> <1b952faca1b2846136ff23c6723eeb63.squirrel@calmail.berkeley.edu> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020808030203040809020500"
Cc: Thomas Watteyne , "Pascal Thubert \(pthubert\)" , "6tsch@ietf.org" <6tsch@ietf.org>, JeongGil Ko , Qin Wang 
Subject: Re: [6tsch] R: Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 19:41:07 -0000

This is a multi-part message in MIME format.
--------------020808030203040809020500
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Alfredo,

just one point on mobility.
TSCH networks may require certain time for a node to join, this depends 
on how the EBs are sent and what are the policies for the joining node 
on how to scan the different channels. Having said that, I think that 
the time required for a node to reserve some cells with its neighbour is 
extremely less than the joining time and hence if a mobile node can join 
the network for sure has time to schedule some links. So maybe this is 
not a big problem :-)

cheers!
Xavi




On 18/03/13 12:36, Grieco wrote:
> Hi Qin, Thomas, and all
>
> Perhaps the only way to cope with (a reasonable degree of) mobility is 
> to hardly assign a certain number of cells at each link to be used in 
> case a mobile node arrives with urgent data to transmit.
>
> Obviously this would slightly decrease the overall efficiency of the 
> system because such "guaranteed cells" could get unused in most of cases.
>
> If, on the other side, the mobile node is generating data which is not 
> that urgent, soft reservation could be used as well, which should 
> waste a smaller amount of resources.
>
> In this perspective, mobile nodes could be handled using either 
> functions 1 or 2, depending on the degree of mobility, the priority of 
> the data packets generated by mobile nodes, the desired duty cycle, 
> and so on.
>
> Cheers
>
> Alfredo
>
>
>
>
> -- 
> Luigi Alfredo Grieco, PhD
> Assistant Professor
> Department of Electrical and Information Engineering
> Politecnico di Bari
> Via Orabona 4 - 70125 - Bari - Italy
> +39 080 5963 911
> telematics.poliba.it/grieco 
> Skype id: l.alfredo.grieco
> Mobile: +39 3346715672
>
>
> On 18 Mar 2013, at 20:20, "Qin Wang"  > wrote:
>
>> Alfredo,
>>
>> I think your remark is correct. So, if there is lots of mobility, I would
>> be prefer distributed approach, i.e. Soft Cell reservation locally + 
>> RPL +
>> DSCP for QoS.
>>
>> Qin
>>
>>
>>> Hi Qin,
>>>
>>> Your proposal is sound.
>>>
>>> Just a final remark: if my understanding is correct, the PCE should 
>>> build
>>> a schedule that spans across multiple links from mobile node M 
>>> towards the
>>> sink S.
>>>
>>> If a M moves after the schedule has been built, some pre-assigned
>>> resources along that path could get lost (which could be tolerated)
>>> because of the change of the topology.
>>>
>>> Is it ok ?
>>>
>>> Cheers and thanks for your answer
>>>
>>> Alfredo
>>>
>>>
>>>
>>> -----Messaggio originale-----
>>> Da: Qin Wang [mailto:qinwang@berkeley.edu]
>>> Inviato: Monday, March 18, 2013 6:48 PM
>>> A: Grieco
>>> Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); 6tsch@ietf.org 
>>> ;
>>> Xavier Vilajosana
>>> Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
>>>
>>> Alfredo,
>>>
>>> Firstly, my understanding is Hard cell reservation can only be used by
>>> PCE, i.e.  centralized schedule. Thus, mobile node will join in network
>>> based on the cells broadcast in EB. And, after its registration, PCE 
>>> will
>>> assign some Hard cells to it.
>>>
>>> secondly, regarding to high priority of the data flow from the mobile
>>> node, DSCP may help, i.e. the packets from the mobile node can include
>>> Priority.
>>>
>>> How do you think?
>>>
>>> Qin
>>>
>>>
>>>
>>>> Hi Qin and all,
>>>>
>>>> Just to challenge the two groups of functions Qin is talking about,
>>>> what if a certain number of mobile nodes need hard reservation ? In
>>>> this case, mobile nodes transmit Real time data to be delivered within
>>>> a given deadline but 6tus does not know in advance the rank (or the
>>>> position within the topology) of such nodes.
>>>>
>>>> I mean that this kind of traffic has the top priority but nobody knows
>>>> in advance the exact position of the nodes that is going to generate
>>>> that data.
>>>>
>>>> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes, 
>>>> how ?
>>>>
>>>> Thanks a lot in advance for your attention
>>>>
>>>> Cheers
>>>>
>>>> Alfredo
>>>>
>>>> --
>>>> Luigi Alfredo Grieco, PhD
>>>> Assistant Professor
>>>> Department of Electrical and Information Engineering Politecnico di
>>>> Bari Via Orabona 4 - 70125 - Bari - Italy
>>>> +39 080 5963 911
>>>> telematics.poliba.it/grieco 
>>>> Skype id: l.alfredo.grieco
>>>> Mobile: +39 3346715672
>>>>
>>>>
>>>> On 17 Mar 2013, at 17:47, "Qin Wang" >>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> I fully agree with Carsten that Simple is very important. Let's
>>>>> overlapping the following three scenarios, then we will find only two
>>>>> groups of functions 6tus should provide.
>>>>>
>>>>> (1) Hard cell reserve/remove, which supports the 1st scenario.
>>>>> (2) Soft cell reserve/remove, which supports the 2nd and 3rd scenario.
>>>>>
>>>>> Any more?
>>>>>
>>>>> Qin
>>>>>
>>>>>
>>>>>> Sorry for the delayed response. I was stuck on the plane for too
>>>>>> long
>>>>>> :)
>>>>>>
>>>>>> I like the discussion that Qin is going for where we define the
>>>>>> scenarios.
>>>>>> At the same time, as Carsten says we need to make sure overlapping
>>>>>> scenarios of any sort are simplified and aggregated as much as
>>>>>> possible.
>>>>>>
>>>>>> Let me just try to put my 2 cents in-line...
>>>>>>
>>>>>>
>>>>>> On Mar 17, 2013, at 8:19 AM, Qin Wang >>>>> > wrote:
>>>>>>
>>>>>>> Hi Pascal,
>>>>>>>
>>>>>>> It is a very good idea to establish a bundle of cells between A and
>>>>>>> B by just triggering 6tus in one side. We can design for different
>>>>>>> scenarios.
>>>>>>>
>>>>>>> (1) PCE defines the track, i.e. the multihop path, the bandwidth of
>>>>>>> each hop, and scheduling hard-cells to implement the multihop path.
>>>>>>> Assume nodeA and nodeB are one-hop neighbors along the path. In
>>>>>>> this case, PCE can send Create.hardcell command to 6tus layer in
>>>>>>> nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB'
>>>>>>> 6tus, then the hard cell is reserved. This function is not in the
>>>>>>> current version of 6tus draft, but we can add it in the next
>>>>>>> version easily.
>>>>>>>
>>>>>>> (2)PCE defines the multihop path and the bandwidth of each hop, but
>>>>>>> not schedules the cells to meet the path bandwidth. In this case,
>>>>>>> soft cell reservation will be applied, which is always triggered in
>>>>>>> Transmitting side, and negotiated by the 6tus layer of both sides.
>>>>>>>
>>>>>>> (3)The cell reservation is triggered by upper layer, e.g. the
>>>>>>> RSVP/NSIS entity in nodeA. Then soft cell reservation process in
>>>>>>> 6tus layer of nodeA will by triggered, and the negotiation process
>>>>>>> is same as case (2).
>>>>>>>
>>>>>>> In summary, by adding reserve hard cell procedure into version-00
>>>>>>> of 6tus, we can let the bundle reservation in every scenarios be
>>>>>>> triggered just in one side.
>>>>>>>
>>>>>>> How do you think?
>>>>>>>
>>>>>>
>>>>>> Great first start in defining the scenarios.
>>>>>>
>>>>>>> Qin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Qin:
>>>>>>>>
>>>>>>>> I think we are on the same line. The services that 6TUS proposes
>>>>>>>> do not depend on which protocol the request came in through.
>>>>>>>> Since we are defining the protocol extensions, we'll make sure
>>>>>>>> that the new information is directly digestible by the 6TUS layer.
>>>>>>>> The protocol extensions will be separate specs, and there should
>>>>>>>> be little to no dereference between those specs and yours.
>>>>>>>>
>>>>>>>> What's important to me to discuss is how we establish a bundle of
>>>>>>>> cells between A and B.
>>>>>>>> IMHO, it would be best if that can be achieved by triggering a
>>>>>>>> service in A - no need to trigger B as well.
>>>>>>>> That way, the volume of exchanges between PCE and nodes can be
>>>>>>>> devided by 2.
>>>>>>>>
>>>>>>>> This would mean that there must be an exchange between 6TUS in A
>>>>>>>> and 6TUS in B.
>>>>>>>> Which  also would mean that there is a protocol part related to
>>>>>>>> 6TUS…
>>>>>>>>
>>>>>>
>>>>>> Fully agreed that this is needed. Being an independent layer, I
>>>>>> don't see why not.
>>>>>>
>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Pascal
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: 6tsch-bounces@ietf.org  
>>>>>>>> [mailto:6tsch-bounces@ietf.org] On
>>>>>>>> Behalf Of Qin Wang
>>>>>>>> Sent: vendredi 15 mars 2013 18:04
>>>>>>>> To: JeongGil Ko
>>>>>>>> Cc: 6tsch@ietf.org ; Xavier Vilajosana
>>>>>>>> Subject: Re: [6tsch] Schemes for resource allocation in the LLN
>>>>>>>> for 6tus
>>>>>>>>
>>>>>>>> John and Xavi,
>>>>>>>>
>>>>>>>> I agree that understanding more about upper layer protocols like
>>>>>>>> RSVP and NSIS is very helpful for designing 6tus. But, I want to
>>>>>>>> make clearer about my understanding on the relationship between
>>>>>>>> 6tus and existing reservation protocols like RSVP or NSIS.
>>>>>>>>
>>>>>>>> (1) When we talk about reservation in the context of 6tus, we
>>>>>>>> mainly focus on  link resource (i.e. cell) reservation, which is
>>>>>>>> required/ triggered by upper layer. Even in the pure centralized
>>>>>>>> approach, it may happen to cross-layer reserve both L3 and L2
>>>>>>>> resource, but you still can separate them logically.
>>>>>>>>
>>>>>>>> (2) The upper layer requirement to 6tus may come from PCE carried
>>>>>>>> by protocol like CoAP, may come from the RSVP/NSIS entity inside
>>>>>>>> nodes.
>>>>>>>>
>>>>>>>> Thus, for 6tus, the question is what kind of function and
>>>>>>>> interface should be provided to support the upper layer, instead
>>>>>>>> of which upper layer protocol should be used.
>>>>>>>>
>>>>>>>> How do you think?
>>>>>>>>
>>>>>>
>>>>>> I agree with your arguments that the important thing is defining the
>>>>>> functionalities. It seems like some of these efforts are on the way
>>>>>> in the later emails. Me bringing in the term "RSVP" was not that I
>>>>>> wanted to go an use RSVP in the way it is, but bring the
>>>>>> (modified/customized) concept in for use in 6tus. As to what I read
>>>>>> there may have been a misunderstanding between us but we are on the
>>>>>> same line.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> -John
>>>>>>
>>>>>>>> Qin
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 6tsch mailing list
>>>>> 6tsch@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>>
>>>
>>>
>>>
>>
>>


--------------020808030203040809020500
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Alfredo,

      

      just one point on mobility.

      TSCH networks may require certain time for a node to join, this
      depends on how the EBs are sent and what are the policies for the
      joining node on how to scan the different channels. Having said
      that, I think that the time required for a node to reserve some
      cells with its neighbour is extremely less than the joining time
      and hence if a mobile node can join the network for sure has time
      to schedule some links. So maybe this is not a big problem :-)

      

      cheers!

      Xavi

      

      

      

      

      On 18/03/13 12:36, Grieco wrote:

    

    

      
      
Hi Qin, Thomas, and all

      


      

      
Perhaps the only way to cope with (a reasonable degree of)
        mobility is to hardly assign a certain number of cells at each
        link to be used in case a mobile node arrives with urgent data
        to transmit.

      


      

      
Obviously this would slightly decrease the overall efficiency
        of the system because such "guaranteed cells" could get unused
        in most of cases.

      


      

      
If, on the other side, the mobile node is generating data
        which is not that urgent, soft reservation could be used as
        well, which should waste a smaller amount of resources.

      


      

      
In this perspective, mobile nodes could be handled using
        either functions 1 or 2, depending on the degree of mobility,
        the priority of the data packets generated by mobile nodes, the
        desired duty cycle, and so on.

      


      

      
Cheers

      


      

      
Alfredo

      


      

      


      

      


      

      


        --
        

          
Luigi
            Alfredo Grieco, PhD

          
Assistant
            Professor

          
Department
            of Electrical and Information Engineering

          
Politecnico
            di Bari

          
Via
            Orabona 4 - 70125 - Bari - Italy

          
+39 080
            5963 911

          
          
Skype id:
            l.alfredo.grieco

          
Mobile:
            +39 3346715672

        

        

          


          

        

      

      


        On 18 Mar 2013, at 20:20, "Qin Wang" <qinwang@berkeley.edu>
        wrote:

        

      

      

        
Alfredo,

          

          I think your remark is correct. So, if there is lots of
            mobility, I would

          be prefer distributed approach, i.e. Soft Cell
            reservation locally + RPL +

          DSCP for QoS.

          

          Qin

          

          

          
Hi Qin,

          

          


          

          
Your proposal is sound.

          

          


          

          
Just a final remark: if my
              understanding is correct, the PCE should build

          

          
a schedule that spans across
              multiple links from mobile node M towards the

          

          
sink S.

          

          


          

          
If a M moves after the schedule
              has been built, some pre-assigned

          

          
resources along that path could
              get lost (which could be tolerated)

          

          
because of the change of the
              topology.

          

          


          

          
Is it ok ?

          

          


          

          
Cheers and thanks for your
              answer

          

          


          

          
Alfredo

          

          


          

          


          

          


          

          
-----Messaggio originale-----

          

          
Da: Qin Wang [mailto:qinwang@berkeley.edu]

          

          
Inviato: Monday, March 18, 2013
              6:48 PM

          

          
A: Grieco

          

          
Cc: Qin Wang; JeongGil Ko;
              Pascal Thubert (pthubert); 6tsch@ietf.org;

          

          
Xavier Vilajosana

          

          
Oggetto: Re: [6tsch] Schemes for
              resource allocation in the LLN for 6tus

          

          


          

          
Alfredo,

          

          


          

          
Firstly, my understanding is
              Hard cell reservation can only be used by

          

          
PCE, i.e.  centralized schedule.
              Thus, mobile node will join in network

          

          
based on the cells broadcast in
              EB. And, after its registration, PCE will

          

          
assign some Hard cells to it.

          

          


          

          
secondly, regarding to high
              priority of the data flow from the mobile

          

          
node, DSCP may help, i.e. the
              packets from the mobile node can include

          

          
Priority.

          

          


          

          
How do you think?

          

          


          

          
Qin

          

          


          

          


          

          


          

          

            
Hi Qin and all,

            

          

          

            


            

          

          

            
Just to challenge the two
                groups of functions Qin is talking about,

            

          

          

            
what if a certain number of
                mobile nodes need hard reservation ? In

            

          

          

            
this case, mobile nodes
                transmit Real time data to be delivered within

            

          

          

            
a given deadline but 6tus does
                not know in advance the rank (or the

            

          

          

            
position within the topology)
                of such nodes.

            

          

          

            


            

          

          

            
I mean that this kind of
                traffic has the top priority but nobody knows

            

          

          

            
in advance the exact position
                of the nodes that is going to generate

            

          

          

            
that data.

            

          

          

            


            

          

          

            
Do we need a further case ? Or
                we can leverage on 1 or 2 ? If yes, how ?

            

          

          

            


            

          

          

            
Thanks a lot in advance for
                your attention

            

          

          

            


            

          

          

            
Cheers

            

          

          

            


            

          

          

            
Alfredo

            

          

          

            


            

          

          

            
--

            

          

          

            
Luigi Alfredo Grieco, PhD

            

          

          

            
Assistant Professor

            

          

          

            
Department of Electrical and
                Information Engineering Politecnico di

            

          

          

            
Bari Via Orabona 4 - 70125 -
                Bari - Italy

            

          

          

            
+39 080 5963 911

            

          

          

            
telematics.poliba.it/grieco

            

          

          

            
Skype id: l.alfredo.grieco

            

          

          

            
Mobile: +39 3346715672

            

          

          

            


            

          

          

            


            

          

          

            
On 17 Mar 2013, at 17:47, "Qin
                Wang" <qinwang@berkeley.edu>
                wrote:

            

          

          

            


            

          

          

            

              


              

            

          

          

            

              


              

            

          

          

            

              
I fully agree with Carsten
                  that Simple is very important. Let's

              

            

          

          

            

              
overlapping the following
                  three scenarios, then we will find only two

              

            

          

          

            

              
groups of functions 6tus
                  should provide.

              

            

          

          

            

              


              

            

          

          

            

              
(1) Hard cell
                  reserve/remove, which supports the 1st scenario.

              

            

          

          

            

              
(2) Soft cell
                  reserve/remove, which supports the 2nd and 3rd
                  scenario.

              

            

          

          

            

              


              

            

          

          

            

              
Any more?

              

            

          

          

            

              


              

            

          

          

            

              
Qin

              

            

          

          

            

              


              

            

          

          

            

              


              

            

          

          

            

              

                
Sorry for the delayed
                    response. I was stuck on the plane for too

                

              

            

          

          

            

              

                
long

                

              

            

          

          

            

              

                
:)

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
I like the discussion that
                    Qin is going for where we define the

                

              

            

          

          

            

              

                
scenarios.

                

              

            

          

          

            

              

                
At the same time, as
                    Carsten says we need to make sure overlapping

                

              

            

          

          

            

              

                
scenarios of any sort are
                    simplified and aggregated as much as

                

              

            

          

          

            

              

                
possible.

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
Let me just try to put my
                    2 cents in-line...

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
On Mar 17, 2013, at 8:19
                    AM, Qin Wang <qinwang@berkeley.edu>
                    wrote:

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                

                  
Hi Pascal,

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  
It is a very good idea
                      to establish a bundle of cells between A and

                  

                

              

            

          

          

            

              

                

                  
B by just triggering
                      6tus in one side. We can design for different

                  

                

              

            

          

          

            

              

                

                  
scenarios.

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  
(1) PCE defines the
                      track, i.e. the multihop path, the bandwidth of

                  

                

              

            

          

          

            

              

                

                  
each hop, and scheduling
                      hard-cells to implement the multihop path.

                  

                

              

            

          

          

            

              

                

                  
Assume nodeA and nodeB
                      are one-hop neighbors along the path. In

                  

                

              

            

          

          

            

              

                

                  
this case, PCE can send
                      Create.hardcell command to 6tus layer in

                  

                

              

            

          

          

            

              

                

                  
nodeA,and nodeA's 6tus
                      sends Create.hardcell command to nodeB'

                  

                

              

            

          

          

            

              

                

                  
6tus, then the hard cell
                      is reserved. This function is not in the

                  

                

              

            

          

          

            

              

                

                  
current version of 6tus
                      draft, but we can add it in the next

                  

                

              

            

          

          

            

              

                

                  
version easily.

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  
(2)PCE defines the
                      multihop path and the bandwidth of each hop, but

                  

                

              

            

          

          

            

              

                

                  
not schedules the cells
                      to meet the path bandwidth. In this case,

                  

                

              

            

          

          

            

              

                

                  
soft cell reservation
                      will be applied, which is always triggered in

                  

                

              

            

          

          

            

              

                

                  
Transmitting side, and
                      negotiated by the 6tus layer of both sides.

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  
(3)The cell reservation
                      is triggered by upper layer, e.g. the

                  

                

              

            

          

          

            

              

                

                  
RSVP/NSIS entity in
                      nodeA. Then soft cell reservation process in

                  

                

              

            

          

          

            

              

                

                  
6tus layer of nodeA will
                      by triggered, and the negotiation process

                  

                

              

            

          

          

            

              

                

                  
is same as case (2).

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  
In summary, by adding
                      reserve hard cell procedure into version-00

                  

                

              

            

          

          

            

              

                

                  
of 6tus, we can let the
                      bundle reservation in every scenarios be

                  

                

              

            

          

          

            

              

                

                  
triggered just in one
                      side.

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  
How do you think?

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
Great first start in
                    defining the scenarios.

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                

                  
Qin

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  

                    
Hi Qin:

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
I think we are on the
                        same line. The services that 6TUS proposes

                    

                  

                

              

            

          

          

            

              

                

                  

                    
do not depend on which
                        protocol the request came in through.

                    

                  

                

              

            

          

          

            

              

                

                  

                    
Since we are defining
                        the protocol extensions, we'll make sure

                    

                  

                

              

            

          

          

            

              

                

                  

                    
that the new
                        information is directly digestible by the 6TUS
                        layer.

                    

                  

                

              

            

          

          

            

              

                

                  

                    
The protocol
                        extensions will be separate specs, and there
                        should

                    

                  

                

              

            

          

          

            

              

                

                  

                    
be little to no
                        dereference between those specs and yours.

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
What's important to me
                        to discuss is how we establish a bundle of

                    

                  

                

              

            

          

          

            

              

                

                  

                    
cells between A and B.

                    

                  

                

              

            

          

          

            

              

                

                  

                    
IMHO, it would be best
                        if that can be achieved by triggering a

                    

                  

                

              

            

          

          

            

              

                

                  

                    
service in A - no need
                        to trigger B as well.

                    

                  

                

              

            

          

          

            

              

                

                  

                    
That way, the volume
                        of exchanges between PCE and nodes can be

                    

                  

                

              

            

          

          

            

              

                

                  

                    
devided by 2.

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
This would mean that
                        there must be an exchange between 6TUS in A

                    

                  

                

              

            

          

          

            

              

                

                  

                    
and 6TUS in B.

                    

                  

                

              

            

          

          

            

              

                

                  

                    
Which  also would mean
                        that there is a protocol part related to

                    

                  

                

              

            

          

          

            

              

                

                  

                    
6TUS…

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
Fully agreed that this is
                    needed. Being an independent layer, I

                

              

            

          

          

            

              

                
don't see why not.

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                

                  

                    
Cheers,

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
Pascal

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
-----Original
                        Message-----

                    

                  

                

              

            

          

          

            

              

                

                  

                    
From: 6tsch-bounces@ietf.org
                        [mailto:6tsch-bounces@ietf.org]
                        On

                    

                  

                

              

            

          

          

            

              

                

                  

                    
Behalf Of Qin Wang

                    

                  

                

              

            

          

          

            

              

                

                  

                    
Sent: vendredi 15 mars
                        2013 18:04

                    

                  

                

              

            

          

          

            

              

                

                  

                    
To: JeongGil Ko

                    

                  

                

              

            

          

          

            

              

                

                  

                    
Cc: 6tsch@ietf.org;
                        Xavier Vilajosana

                    

                  

                

              

            

          

          

            

              

                

                  

                    
Subject: Re: [6tsch]
                        Schemes for resource allocation in the LLN

                    

                  

                

              

            

          

          

            

              

                

                  

                    
for 6tus

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
John and Xavi,

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
I agree that
                        understanding more about upper layer protocols
                        like

                    

                  

                

              

            

          

          

            

              

                

                  

                    
RSVP and NSIS is very
                        helpful for designing 6tus. But, I want to

                    

                  

                

              

            

          

          

            

              

                

                  

                    
make clearer about my
                        understanding on the relationship between

                    

                  

                

              

            

          

          

            

              

                

                  

                    
6tus and existing
                        reservation protocols like RSVP or NSIS.

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
(1) When we talk about
                        reservation in the context of 6tus, we

                    

                  

                

              

            

          

          

            

              

                

                  

                    
mainly focus on  link
                        resource (i.e. cell) reservation, which is

                    

                  

                

              

            

          

          

            

              

                

                  

                    
required/ triggered by
                        upper layer. Even in the pure centralized

                    

                  

                

              

            

          

          

            

              

                

                  

                    
approach, it may
                        happen to cross-layer reserve both L3 and L2

                    

                  

                

              

            

          

          

            

              

                

                  

                    
resource, but you
                        still can separate them logically.

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
(2) The upper layer
                        requirement to 6tus may come from PCE carried

                    

                  

                

              

            

          

          

            

              

                

                  

                    
by protocol like CoAP,
                        may come from the RSVP/NSIS entity inside

                    

                  

                

              

            

          

          

            

              

                

                  

                    
nodes.

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
Thus, for 6tus, the
                        question is what kind of function and

                    

                  

                

              

            

          

          

            

              

                

                  

                    
interface should be
                        provided to support the upper layer, instead

                    

                  

                

              

            

          

          

            

              

                

                  

                    
of which upper layer
                        protocol should be used.

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
How do you think?

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
I agree with your
                    arguments that the important thing is defining the

                

              

            

          

          

            

              

                
functionalities. It seems
                    like some of these efforts are on the way

                

              

            

          

          

            

              

                
in the later emails. Me
                    bringing in the term "RSVP" was not that I

                

              

            

          

          

            

              

                
wanted to go an use RSVP
                    in the way it is, but bring the

                

              

            

          

          

            

              

                
(modified/customized)
                    concept in for use in 6tus. As to what I read

                

              

            

          

          

            

              

                
there may have been a
                    misunderstanding between us but we are on the

                

              

            

          

          

            

              

                
same line.

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
Thanks!

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
-John

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                

                  

                    
Qin

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                


                

              

            

          

          

            

              


              

            

          

          

            

              
_______________________________________________

              

            

          

          

            

              
6tsch mailing list

              

            

          

          

            

              
6tsch@ietf.org

              

            

          

          

            

              
https://www.ietf.org/mailman/listinfo/6tsch

              

            

          

          

            


            

          

          


          

          


          

          


          

          

          

        

      

    

    

  


--------------020808030203040809020500--

From twatteyne@gmail.com  Mon Mar 18 12:41:35 2013
Return-Path: 
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 B85E221F8F49 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 12:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, NO_RELAYS=-0.001]
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 TEO4NBO3b14U for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 12:41:26 -0700 (PDT)
Received: from mail-da0-x236.google.com (mail-da0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6E221F8CB9 for <6tsch@ietf.org>; Mon, 18 Mar 2013 12:41:26 -0700 (PDT)
Received: by mail-da0-f54.google.com with SMTP id p1so1521029dad.41 for <6tsch@ietf.org>; Mon, 18 Mar 2013 12:41:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=2O79yiMgW+QBLJC8Pg6084yijfPUinepCgtKEh0LJV4=; b=07FSuEjO2tvhzM0tZ+YcanQt6Z/MurNKuhsbMuwrunFIoma69e7Bb86MSriiFS97kD jVdC1CNUKJWAVGIrFSB6YP6YCqnn8UzLFgIn9jznD9yHaGhapwcS053Cq8KqwUb899zY M24O6Sh+o+hsX6g10+9kmsqRC+lqLYXBXdFhCOUTqw+DhtTQ6yU20eW27NyClJdde98f Dr9usyA4Hq0rkeAOIWZKr1yg0U+U2XBfTpkM20vEYB+xR8fvhgwM7/FCU62A4R8v07p6 C1M6QqJv3RHDmb1rOK3CYHqOq1co0NvSNWYmCNf8O9jszsTLuVtyiBodDCQsgUlJjLXr IiOw==
MIME-Version: 1.0
X-Received: by 10.68.132.42 with SMTP id or10mr34589897pbb.127.1363635685853;  Mon, 18 Mar 2013 12:41:25 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Mon, 18 Mar 2013 12:41:25 -0700 (PDT)
In-Reply-To: 
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>  <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu> <51475694.85d00e0a.2654.3c21@mx.google.com> <1b952faca1b2846136ff23c6723eeb63.squirrel@calmail.berkeley.edu> 
Date: Mon, 18 Mar 2013 12:41:25 -0700
X-Google-Sender-Auth: -qW5S6RE1aq2sibuPxoW_kem1Ew
Message-ID: 
From: Thomas Watteyne 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b10cbb1a89e2f04d8382cce
Subject: Re: [6tsch] R: Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 19:41:35 -0000

--047d7b10cbb1a89e2f04d8382cce
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Alfredo,

Cool idea! Where do you think this could be described? Architecture draft?
Or do you think this is worth another draft, possibly later on?

In any case, let's keep that idea is the backs of our minds.

Thomas

On Mon, Mar 18, 2013 at 12:36 PM, Grieco  wrote:

> Hi Qin, Thomas, and all
>
> Perhaps the only way to cope with (a reasonable degree of) mobility is to
> hardly assign a certain number of cells at each link to be used in case a
> mobile node arrives with urgent data to transmit.
>
> Obviously this would slightly decrease the overall efficiency of the
> system because such "guaranteed cells" could get unused in most of cases.
>
> If, on the other side, the mobile node is generating data which is not
> that urgent, soft reservation could be used as well, which should waste a
> smaller amount of resources.
>
> In this perspective, mobile nodes could be handled using either functions
> 1 or 2, depending on the degree of mobility, the priority of the data
> packets generated by mobile nodes, the desired duty cycle, and so on.
>
> Cheers
>
> Alfredo
>
>
>
>
> --
> Luigi Alfredo Grieco, PhD
> Assistant Professor
> Department of Electrical and Information Engineering
> Politecnico di Bari
> Via Orabona 4 - 70125 - Bari - Italy
> +39 080 5963 911
> telematics.poliba.it/grieco
> Skype id: l.alfredo.grieco
> Mobile: +39 3346715672
>
>
> On 18 Mar 2013, at 20:20, "Qin Wang"  wrote:
>
> Alfredo,
>
> I think your remark is correct. So, if there is lots of mobility, I would
> be prefer distributed approach, i.e. Soft Cell reservation locally + RPL =
+
> DSCP for QoS.
>
> Qin
>
>
> Hi Qin,
>
>
> Your proposal is sound.
>
>
> Just a final remark: if my understanding is correct, the PCE should build
>
> a schedule that spans across multiple links from mobile node M towards th=
e
>
> sink S.
>
>
> If a M moves after the schedule has been built, some pre-assigned
>
> resources along that path could get lost (which could be tolerated)
>
> because of the change of the topology.
>
>
> Is it ok ?
>
>
> Cheers and thanks for your answer
>
>
> Alfredo
>
>
>
>
> -----Messaggio originale-----
>
> Da: Qin Wang [mailto:qinwang@berkeley.edu ]
>
> Inviato: Monday, March 18, 2013 6:48 PM
>
> A: Grieco
>
> Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); 6tsch@ietf.org;
>
> Xavier Vilajosana
>
> Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus
>
>
> Alfredo,
>
>
> Firstly, my understanding is Hard cell reservation can only be used by
>
> PCE, i.e.  centralized schedule. Thus, mobile node will join in network
>
> based on the cells broadcast in EB. And, after its registration, PCE will
>
> assign some Hard cells to it.
>
>
> secondly, regarding to high priority of the data flow from the mobile
>
> node, DSCP may help, i.e. the packets from the mobile node can include
>
> Priority.
>
>
> How do you think?
>
>
> Qin
>
>
>
>
> Hi Qin and all,
>
>
> Just to challenge the two groups of functions Qin is talking about,
>
> what if a certain number of mobile nodes need hard reservation ? In
>
> this case, mobile nodes transmit Real time data to be delivered within
>
> a given deadline but 6tus does not know in advance the rank (or the
>
> position within the topology) of such nodes.
>
>
> I mean that this kind of traffic has the top priority but nobody knows
>
> in advance the exact position of the nodes that is going to generate
>
> that data.
>
>
> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes, how ?
>
>
> Thanks a lot in advance for your attention
>
>
> Cheers
>
>
> Alfredo
>
>
> --
>
> Luigi Alfredo Grieco, PhD
>
> Assistant Professor
>
> Department of Electrical and Information Engineering Politecnico di
>
> Bari Via Orabona 4 - 70125 - Bari - Italy
>
> +39 080 5963 911
>
> telematics.poliba.it/grieco
>
> Skype id: l.alfredo.grieco
>
> Mobile: +39 3346715672
>
>
>
> On 17 Mar 2013, at 17:47, "Qin Wang"  wrote:
>
>
>
>
> I fully agree with Carsten that Simple is very important. Let's
>
> overlapping the following three scenarios, then we will find only two
>
> groups of functions 6tus should provide.
>
>
> (1) Hard cell reserve/remove, which supports the 1st scenario.
>
> (2) Soft cell reserve/remove, which supports the 2nd and 3rd scenario.
>
>
> Any more?
>
>
> Qin
>
>
>
> Sorry for the delayed response. I was stuck on the plane for too
>
> long
>
> :)
>
>
> I like the discussion that Qin is going for where we define the
>
> scenarios.
>
> At the same time, as Carsten says we need to make sure overlapping
>
> scenarios of any sort are simplified and aggregated as much as
>
> possible.
>
>
> Let me just try to put my 2 cents in-line...
>
>
>
> On Mar 17, 2013, at 8:19 AM, Qin Wang  wrote:
>
>
> Hi Pascal,
>
>
> It is a very good idea to establish a bundle of cells between A and
>
> B by just triggering 6tus in one side. We can design for different
>
> scenarios.
>
>
> (1) PCE defines the track, i.e. the multihop path, the bandwidth of
>
> each hop, and scheduling hard-cells to implement the multihop path.
>
> Assume nodeA and nodeB are one-hop neighbors along the path. In
>
> this case, PCE can send Create.hardcell command to 6tus layer in
>
> nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB'
>
> 6tus, then the hard cell is reserved. This function is not in the
>
> current version of 6tus draft, but we can add it in the next
>
> version easily.
>
>
> (2)PCE defines the multihop path and the bandwidth of each hop, but
>
> not schedules the cells to meet the path bandwidth. In this case,
>
> soft cell reservation will be applied, which is always triggered in
>
> Transmitting side, and negotiated by the 6tus layer of both sides.
>
>
> (3)The cell reservation is triggered by upper layer, e.g. the
>
> RSVP/NSIS entity in nodeA. Then soft cell reservation process in
>
> 6tus layer of nodeA will by triggered, and the negotiation process
>
> is same as case (2).
>
>
> In summary, by adding reserve hard cell procedure into version-00
>
> of 6tus, we can let the bundle reservation in every scenarios be
>
> triggered just in one side.
>
>
> How do you think?
>
>
>
> Great first start in defining the scenarios.
>
>
> Qin
>
>
>
>
>
> Hi Qin:
>
>
> I think we are on the same line. The services that 6TUS proposes
>
> do not depend on which protocol the request came in through.
>
> Since we are defining the protocol extensions, we'll make sure
>
> that the new information is directly digestible by the 6TUS layer.
>
> The protocol extensions will be separate specs, and there should
>
> be little to no dereference between those specs and yours.
>
>
> What's important to me to discuss is how we establish a bundle of
>
> cells between A and B.
>
> IMHO, it would be best if that can be achieved by triggering a
>
> service in A - no need to trigger B as well.
>
> That way, the volume of exchanges between PCE and nodes can be
>
> devided by 2.
>
>
> This would mean that there must be an exchange between 6TUS in A
>
> and 6TUS in B.
>
> Which  also would mean that there is a protocol part related to
>
> 6TUS=85
>
>
>
> Fully agreed that this is needed. Being an independent layer, I
>
> don't see why not.
>
>
>
> Cheers,
>
>
> Pascal
>
>
>
> -----Original Message-----
>
> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org<6tsch-bounces=
@ietf.org>]
> On
>
> Behalf Of Qin Wang
>
> Sent: vendredi 15 mars 2013 18:04
>
> To: JeongGil Ko
>
> Cc: 6tsch@ietf.org; Xavier Vilajosana
>
> Subject: Re: [6tsch] Schemes for resource allocation in the LLN
>
> for 6tus
>
>
> John and Xavi,
>
>
> I agree that understanding more about upper layer protocols like
>
> RSVP and NSIS is very helpful for designing 6tus. But, I want to
>
> make clearer about my understanding on the relationship between
>
> 6tus and existing reservation protocols like RSVP or NSIS.
>
>
> (1) When we talk about reservation in the context of 6tus, we
>
> mainly focus on  link resource (i.e. cell) reservation, which is
>
> required/ triggered by upper layer. Even in the pure centralized
>
> approach, it may happen to cross-layer reserve both L3 and L2
>
> resource, but you still can separate them logically.
>
>
> (2) The upper layer requirement to 6tus may come from PCE carried
>
> by protocol like CoAP, may come from the RSVP/NSIS entity inside
>
> nodes.
>
>
> Thus, for 6tus, the question is what kind of function and
>
> interface should be provided to support the upper layer, instead
>
> of which upper layer protocol should be used.
>
>
> How do you think?
>
>
>
> I agree with your arguments that the important thing is defining the
>
> functionalities. It seems like some of these efforts are on the way
>
> in the later emails. Me bringing in the term "RSVP" was not that I
>
> wanted to go an use RSVP in the way it is, but bring the
>
> (modified/customized) concept in for use in 6tus. As to what I read
>
> there may have been a misunderstanding between us but we are on the
>
> same line.
>
>
> Thanks!
>
>
> -John
>
>
> Qin
>
>
>
>
>
>
>
> _______________________________________________
>
> 6tsch mailing list
>
> 6tsch@ietf.org
>
> https://www.ietf.org/mailman/listinfo/6tsch
>
>
>
>
>
>
>
>

--047d7b10cbb1a89e2f04d8382cce
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Alfredo,

Cool idea! Where do you think this could be des=
cribed? Architecture draft? Or do you think this is worth another draft, po=
ssibly later on?

In any case, let's keep that =
idea is the backs of our minds.



Thomas

On Mon, Mar 18=
, 2013 at 12:36 PM, Grieco <alfredo.grieco@gmail.com>=
 wrote:


Hi Qin, Thomas, and a=
ll

Perhaps the only way to cope with (a reasonable=
 degree of) mobility is to hardly assign a certain number of cells at each =
link to be used in case a mobile node arrives with urgent data to transmit.=




Obviously this would slightly decrease the overall effi=
ciency of the system because such "guaranteed cells" could get un=
used in most of cases.

If, on the other side, the =
mobile node is generating data which is not that urgent, soft reservation c=
ould be used as well, which should waste a smaller amount of resources.


In this perspective, mobile nodes could be handled usin=
g either functions 1 or 2, depending on the degree of mobility, the priorit=
y of the data packets generated by mobile nodes, the desired duty cycle, an=
d so on.



Cheers

Alfre=
do




--
Luigi Alfredo Grieco, PhD

Assistant Professor
Department of Ele=
ctrical and Information Engineering

Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy


Skype id: l.alf=
redo.grieco





On 18 Mar 2013, at 20:20, "Qin Wang" <qinwang@berkeley.edu> wrote:
Alfredo,
<=
/span>

I think your remark is correct. So, if there is lots of mobility, I w=
ould
be prefer distributed approach, i.e. Soft Cell reserva=
tion locally + RPL +
DSCP for QoS.
<=
br>
Qin


Hi Qin,
<=
/span>
Your proposal is sou=
nd.



Just a final remark: if my understanding is corre=
ct, the PCE should build
<=
span>a schedule that spans across multiple links from mobile node M towards=
 the


sink S.

If a M moves after the schedule has been built, some pre-as=
signed


resources along that path coul=
d get lost (which could be tolerated)
because of the change of the topology.



Is it ok ?

Cheers and than=
ks for your answer



Alfredo





-----Messaggio originale-----
Da: Qin Wang [mailto:qinwang@berkeley.edu]

Inviato: Monday, March 18, 201=
3 6:48 PM
A: Grieco<=
/span>
Cc: Qin Wang; JeongG=
il Ko; Pascal Thubert (pthubert); 6tsch@ietf.org;


Xavier Vilajosana
Oggetto: Re: [6tsch] Schemes for=
 resource allocation in the LLN for 6tus


Alfredo,

=

Firstly, my understanding is Hard cell rese=
rvation can only be used by


PCE, i.e. =A0centralized sched=
ule. Thus, mobile node will join in network
based on the cells broadcast in EB. And, after its =
registration, PCE will


assign some Hard cells to it.<=
/span>

secondly, regarding to high priority of=
 the data flow from the mobile


node, DSCP may help, i.e. the =
packets from the mobile node can include
Priority.


How do you th=
ink?

Qin




Hi Qin and all,



Just to challenge the two groups of functions Qin is talkin=
g about,


what if a certain number of mobile nodes need hard reservation ? I=
n

this case, mobile nodes transmit Real time data to be delivered withi=
n
a given deadline but 6tus does not know in advance the=
 rank (or the


position within the topology) of such nodes.



I mean that this kind of traffic has the top priority but nobody k=
nows

in advance the exact position of the nodes that is going to generate<=
/span>
that data.



Do we need a further ca=
se ? Or we can leverage on 1 or 2 ? If yes, how ?



Thanks a lot in advance for your attention



Cheers


Alfredo



--
<=
span>Luigi Alfredo Grieco, PhD


Assistant Professor
=

Depa=
rtment of Electrical and Information Engineering Politecnico di
<=
/blockquote>

Bari=
 Via Orabona 4 - 70125 - Bari - Italy
<=
blockquote type=3D"cite">
+39 080 59=
63 911


t=
elematics.poliba.it/grieco


Skype id: l.alfredo.grieco
Mobile: +39 3346715672






On 17 Mar 2013, at 17:47, "Qin Wang&qu=
ot; <qinwang@b=
erkeley.edu> wrote:







I fully agree with Carsten that Simple is very important. L=
et's


overlapping the following t=
hree scenarios, then we will find only two


groups of functions 6tus should provide.



(1) Hard cell reserve/remove, which supports the 1st scenar=
io.


(2) Soft cell reserve/remov=
e, which supports the 2nd and 3rd scenario.



=
Any more?



=


Qin
=




Sorry for the delayed response. I=
 was stuck on the plane for too


long


:)
<=
/blockquote>



I like the discussio=
n that Qin is going for where we define the


scenarios.


At the same time, as Carsten says we nee=
d to make sure overlapping


scenarios of any sort are simplified and=
 aggregated as much as


possible.



=
Let me just try to put my 2 cents in-line...



=




=


On Mar 17, 2013, at 8:19 AM, Qin Wang <qinwang@berkeley.edu> wrote:



=



Hi Pascal,


It is a=
 very good idea to establish a bundle of cells between A and


B by just triggering 6tu=
s in one side. We can design for different


scenarios.



=



(1) PCE defines the track, i.e. the multihop path, the bandwidt=
h of


each hop, and scheduling=
 hard-cells to implement the multihop path.


Assume nodeA and nodeB a=
re one-hop neighbors along the path. In


this case, PCE can send =
Create.hardcell command to 6tus layer in


nodeA,and nodeA's 6t=
us sends Create.hardcell command to nodeB'


6tus, then the hard cell=
 is reserved. This function is not in the


current version of 6tus =
draft, but we can add it in the next


version easily.



=



(2)PCE defines the multihop path and the bandwidth of each hop,=
 but


not schedules the cells =
to meet the path bandwidth. In this case,


soft cell reservation wi=
ll be applied, which is always triggered in


Transmitting side, and n=
egotiated by the 6tus layer of both sides.



=



(3)The cell reservation is triggered by upper laye=
r, e.g. the


RSVP/NSIS entity in node=
A. Then soft cell reservation process in


6tus layer of nodeA will=
 by triggered, and the negotiation process


is same as case (2).



=



In summary, by adding reserve hard cell procedure =
into version-00


of 6tus, we can let the =
bundle reservation in every scenarios be


triggered just in one si=
de.



=



How do you think?



=




=



Great first start in defining the scenarios=
.


Qin



=




=









Hi Qin:



=



I think we are=
 on the same line. The services that 6TUS proposes
<=
/blockquote>

do not depe=
nd on which protocol the request came in through.



Since we are defining the protocol extensions, we'll make sure


that the new information is directly digestible by the 6TUS layer.=



The protocol extensions will be separate specs, and there shoul=
d



be little to no dereference between those specs and yours.
=




=



What's important to me to discuss is how we establish a bundle=
 of


cells between A and B.


IMHO, it wo=
uld be best if that can be achieved by triggering a



service in A - no need to trigger B as well.
<=
/blockquote>


That way, the vol=
ume of exchanges between PCE and nodes can be


devided by 2.<=
/span>
=




=



This would mean that there must be an exchange bet=
ween 6TUS in A



and 6TUS in B.


Which =A0also would mean that there is a pr=
otocol part related to


6TUS=85



=




=
Fully agreed that this is needed. Being an independent layer, I


don't see why not.






=



Cheers,



=



Pascal
=




=




=



-----Original Message-----
=



From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] O=
n



Behalf Of Qin Wang
<=
/blockquote>


Sent: vendredi 15 mars 2013 18:04


To: JeongGil Ko
<=
/blockquote>


Cc: 6tsch@ietf.org; Xavier Vilajosana


Subject: Re=
: [6tsch] Schemes for resource allocation in the LLN



for 6tus



=



John and Xavi,



=



I agree that unde=
rstanding more about upper layer protocols like


RSVP and NSIS =
is very helpful for designing 6tus. But, I want to
<=
/blockquote>

make cleare=
r about my understanding on the relationship between



6tus and existing reservation protocols like RSVP or NSIS.
=




=



(1) When we talk about reservation in the context of 6tus, we


mainly focus on =A0link resource (i.e. cell) reservation, which=
 is



required/ triggered by upper layer. Even in the pure centralized


approach, it may happen to cross-layer reserve both L3 and L2


resource, but you still can separate them logically.
=







(2) The upper layer requirement to 6tus may come from PCE carried


by protocol like CoAP, may come from the RSVP/NSIS entity inside
<=
/blockquote>

nodes.



=



Thus, for 6tus, the question is what =
kind of function and



interface should be provided to support the upper layer, instead


of which upper layer protocol should be used.



=



How do you thi=
nk?



=






I agree with your=
 arguments that the important thing is defining the
=



functionalities. =
It seems like some of these efforts are on the way
<=
/blockquote>


in the later emai=
ls. Me bringing in the term "RSVP" was not that I


wanted to go an u=
se RSVP in the way it is, but bring the


(modified/customi=
zed) concept in for use in 6tus. As to what I read
<=
/blockquote>


there may have be=
en a misunderstanding between us but we are on the
<=
/blockquote>


same line.=



Thanks!





-John
<=
/blockquote>



Qin<=
br>







=




=




=



__________=
_____________________________________
<=
/blockquote>

6tsch mailing list
6tsch@ietf.o=
rg


https://www.ietf.org/mailman=
/listinfo/6tsch








=





--047d7b10cbb1a89e2f04d8382cce--

From qinwang@berkeley.edu  Mon Mar 18 12:41:49 2013
Return-Path: 
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 2A70221F8F49 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 12:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 29iCDNLdqWis for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 12:41:35 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 8921721F8F25 for <6tsch@ietf.org>; Mon, 18 Mar 2013 12:41:35 -0700 (PDT)
Received: from cm04ws.ist.berkeley.edu ([169.229.218.166] helo=calmail.berkeley.edu) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UHfw5-0003Sr-BM; Mon, 18 Mar 2013 12:41:35 -0700
Received: from 174.240.9.213 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Mon, 18 Mar 2013 12:41:33 -0700
Message-ID: <58bceb311aa216a92163ac964258ef19.squirrel@calmail.berkeley.edu>
In-Reply-To: 
References: <1dc657302a100f67f8f678323686f351.squirrel@calmail.berkeley.edu> 
Date: Mon, 18 Mar 2013 12:41:33 -0700
From: "Qin Wang" 
To: "Thomas Watteyne" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Interaction between RPL and PCE
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 19:41:49 -0000

Thomas,

I'm not very familiar with PCE protocol. According to my knowledge, there
are extensions of PCE protocol corresponding to different protocols like
GMPLS. So, maybe a extension of PCE for 6tus is needed, which computes the
track for given multihop path and bandwidth requirement, or the track for
given topology and end-to-end bandwidth requirement.

How do you think?

Qin



> Qin,
>
> Please see inline.
>
> On Mon, Mar 18, 2013 at 10:25 AM, Qin Wang  wrote:
>
>> Thomas,
>>
>> I think for a data flow, there are three elements needed to be defined
>> or
>> scheduled explicitly or implicitly:
>> (1) multihop path, i.e. who is the next hop neighbor
>> (2) bandwidth and Qos requirement
>> (3) cell set (i.e. bundle) to implement the bandwidth
>>
>> In case-1, all of the three elements are determined by PCE, and RPL is
>> just a backup and works on slot-aloha cells. Correct?
>>
>
> I believe that's correct. BTW, I'm not per se advocating for this
> solution,
> but it seems to be the approach
> draft-ietf-roll-rpl-industrial-applicability
> takes.
>
>
>> In case2, element(1) is determined by RPL based on Rank, and element(3)
>> is
>> determined by PCE. But, who will determine element(2)? by PCE or by some
>> entity like RSVP/NSIS or DSCP?
>>
>>
> Agreed. It relatively straightforward for a PCE to compute a schedule and
> distribute that into the network, but how does it figure out what the
> requirements are from the nodes in the network. Could we reuse a "PCE
> requirements" protocol out there?
>
>
>> Qin
>>
>> > [subject was: Scope: 6LoWPAN + 1]
>> >
>> > Maria Rita,
>> >
>> > I fully agree with Pascal's suggestion to have the PCE only talk to
>> one
>> of
>> > the two sides on a on-hop link, and have 6tus be in charge to telling
>> the
>> > other side to reserve the same cell. I believe Qin has also
>> acknowledged
>> > this, and has agreed to put this mechanism into 6tus. This would
>> probably
>> > mean adding some option in the 6tus message format saying "this is not
>> a
>> > negociation for a soft cell, but an order for you to add this hard
>> cell".
>> >
>> > All,
>> >
>> > I believe Maria Rita is touching a very important point we haven't had
>> > time
>> > to discuss last week in Orlando, but which I believe is essential: how
>> do
>> > RPL and the PCE interact? The PCE can have complete knowledge of the
>> > network topology and the network traffic, so besides L2 resource
>> > allocation, it could also make routing decision, i.e. build the track
>> it
>> > believe is best fit.
>> >
>> > draft-ietf-roll-rpl-industrial-applicability-00 also states similar
>> ideas:
>> > "The domain of applicability for the RPL protocol may include all
>> phases
>> > but the Normal Operation phase, where the bandwidth allocation and the
>> > *routes
>> > are usually optimized by an external Path Computing Engine (PCE)*.
>> [...]
>> > Additionally, it could be envisioned to include RPL in the normal
>> > operation
>> > provided that a new Objective Function is defined that actually
>> interacts
>> > with the PCE is order to establish the reference topology, in which
>> case
>> > *RPL
>> > operations would only apply to emergency repair actions*. when the
>> > reference topology becomes unusable for some failure, and as long as
>> the
>> > problem persists."
>> >
>> > This shot-circuits RPL.
>> >
>> > The two use cases I can see are:
>> > 1. the PCE makes decisions without RPL's intervention. RPL runs in the
>> > background for emergency repair actions only.
>> > 2. RPL sets up multi-hop routes which the PCE uses for building
>> tracks.
>> > That is, the PCE only performs L2 resource allocation.
>> >
>> > Do we agree to use only use case 1? If we go for 2, how does the PCE
>> get
>> > information about RPL routes (especially in storing mode)?
>> >
>> > Thomas
>> >
>> > On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA <
>> > maria-rita.palattella@uni.lu> wrote:
>> >
>> >> Hi Qin, and all,
>> >> Sorry for coming back to this discussion after some time, but I
>> wanted
>> >> to
>> >> raise and clarify a point.
>> >>
>> >> Qin>>>(2) If there is PCE, there may be different setting. For
>> example,
>> >> PCE is in charge for reserving both multiple hop path (i.e. every
>> next
>> >> hop
>> >> Qin>>>neighbor) and cells; or PCE is just in charge for reserving the
>> >> multiple hop path and leaving cell reservation to local, and the
>> >> distributed cell reservation will meet the bandwidth requirement from
>> >> multiple hop path reservation. In the first case, hard Qin>>> cell
>> >>  reservation will be used.
>> >>
>> >> Qin >>>(3)If there is no PCE, both multi-hop path and cells are
>> reserved
>> >> in local.
>> >> Qin>>For example, RPL + soft cell reservation in 6tus.
>> >>
>> >> From my point of view (and thinking about TASA implementation), the
>> PCE
>> >> shouldn't be in charge for reserving the multiple hop path. But the
>> >> routing
>> >> protocol (i.e., RPL in our case) should take care of the next hop
>> >> neighbor
>> >> selection.
>> >> When a centralized approach is adopted, the PCE will schedule the
>> cells
>> >>  (i.e., hard cells according to 6tus terminology).
>> >> While, when a distributed solution is used, 6tus will allocate the
>> soft
>> >> cells.
>> >>
>> >> In the centralized scenario with the PCE, to avoid the exchange of
>> many
>> >> signaling messages, for setting up the schedule, we may think (as
>> Pascal
>> >> was suggesting during one of the last call) to use some hybrid
>> >> solutions.
>> >> In other words, if PCE allocates (timeoffset1, channeloffset3,
>> >> slotframe1,
>> >> TX) to node A for transmitting to node B, then, node B could know
>> >> locally
>> >> from node A, (and not from the PCE), that the cell (timeoffset1,
>> >> channeloffset3, slotframe1, RX) has been reserved to it, for
>> receiving
>> >> from
>> >> node A.
>> >> We may try to include some functionality in 6tus layer in order to
>> >> manage
>> >> such situation.
>> >> What do you think?
>> >>
>> >> Maria Rita
>> >>
>> >>
>> >>
>> ----------------------------------------------------------------------------------------------------------------
>> >> > On 3/14/13 9:02 PM, Paul Chilton wrote:
>> >> >>>- optionally a PCE sits on the backbone and drives the LLNs' TSCH
>> >> >>>schedules.
>> >> >
>> >> > Ah, maybe understood.  It doesn't say that existence of PCE is
>> >> optional.
>> >> > It says that it's optional to put PCE in the backbone.  It doesn't
>> >> > preclude to put it on BBR.  Correct ?
>> >> >
>> >> > Shoichi
>> >> > _______________________________________________
>> >> > 6tsch mailing list
>> >> > 6tsch@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/6tsch
>> >> >
>> >>
>> >> _______________________________________________
>> >> 6tsch mailing list
>> >> 6tsch@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/6tsch
>> >> _______________________________________________
>> >> 6tsch mailing list
>> >> 6tsch@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/6tsch
>> >>
>> > _______________________________________________
>> > 6tsch mailing list
>> > 6tsch@ietf.org
>> > https://www.ietf.org/mailman/listinfo/6tsch
>> >
>>
>>
>>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From tom.phinney@cox.net  Mon Mar 18 13:06:41 2013
Return-Path: 
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 14ABC21F90DA for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 13:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.141
X-Spam-Level: 
X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
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 xpJJsMtbbmmF for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 13:06:40 -0700 (PDT)
Received: from fed1rmfepo203.cox.net (fed1rmfepo203.cox.net [68.230.241.148]) by ietfa.amsl.com (Postfix) with ESMTP id A835B21F8FA6 for <6tsch@ietf.org>; Mon, 18 Mar 2013 13:06:32 -0700 (PDT)
Received: from fed1rmimpo210 ([68.230.241.161]) by fed1rmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130318200632.RVME25233.fed1rmfepo203.cox.net@fed1rmimpo210> for <6tsch@ietf.org>; Mon, 18 Mar 2013 16:06:32 -0400
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo210 with cox id D86X1l00B3gAAro0186XJP; Mon, 18 Mar 2013 16:06:31 -0400
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020207.514773C7.019C,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=Q80MFfKa c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=6D3b9miqrD4A:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=_NqJobw5kD0A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=tnbVPDaUNVJhFK7gx6wA:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=lZB815dzVvQA:10 a=k1m8fNNHRW37jukf:21 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <514773C7.4050002@cox.net>
Date: Mon, 18 Mar 2013 13:06:31 -0700
From: Tom Phinney 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: 6tsch@ietf.org
References: <1dc657302a100f67f8f678323686f351.squirrel@calmail.berkeley.edu> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [6tsch] Interaction between RPL and PCE
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney 
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 20:06:41 -0000



  
    
  
  
    Re: it seems to be the approach draft-ietf-roll-rpl-industrial-applicability
      takes.

    

    The reason why centralized (i.e., PCE) computation was favored is
    that compute-intensive consideration of schedules, based on physical
    knowledge of the placement of all scheduled devices from the plant
    piping and instrumentation diagram (P&ID) database, when coupled
    with knowledge of the required periodic publication messaging (it's
    frequency, criticality and even PDU size), and potentially augmented
    by collected history of communications failure rates on specific
    routes, can lead to minimizing potential RF conflicts for the most
    critical messaging. Supercomputers were applied to optimizing such
    industrial processes as early as the 1980s, and to optimizing
    airline equipment use and routing as early as the late 1960s. There
    is nothing novel about large industrial users doing such centralized
    optimization to increase their profitability.

    

    Those of us who work in this industry have always thought that
    RF-equipped devices such as those using 802.15.4 might be able to
    use their radios for some form of localized site survey. This would
    be particularly the case for devices that are externally powered
    (such as those coupled to powered actuators) or environmentally
    recharged (e.g., from solar, or thermal potential differences, or
    vibration energy harvesting), where battery life is not an
    overriding concern. Use of the distributed network of field devices
    to assess RF problems and provide information that can assist in
    localizing the emission source causing the problems is a
    high-payback additional capability.

    

    In summary, a centralized high-compute-power PCE, driven from a
    large database that includes physical siting information as well as
    historical performance observations, should be able to statistically
    deconflict many tracks by construction. That's a capability that
    would be applied first to the most critical tracks, then the most
    frequently used tracks, then down the priority chain.

    

    There is less of an opportunity to improve aperiodically-used tracks
    via PCE precomputation, but that still seems worth doing to some
    extent.

    

    Relative to mobile, the only mobile equipment in large outdoor
    plants that would be involved in class 0 or class 1 traffic might be
    overhead traveling cranes. That's a case where it might make sense
    for a PCE to set up tracks to all but the last hop, with multiple
    field routers able to receive from the crane and forward one hop to
    merge into the precomputed track.

    

    All food for thought.

    

    -Tom

    ====

    On 2013.03.18 12:18, Thomas Watteyne wrote:
    
Qin,
      


      

      
Please see inline.

        

        
On Mon, Mar 18, 2013 at 10:25 AM, Qin
          Wang <qinwang@berkeley.edu>
          wrote:

          
Thomas,

            

            I think for a data flow, there are three elements needed to
            be defined or

            scheduled explicitly or implicitly:

            (1) multihop path, i.e. who is the next hop neighbor

            (2) bandwidth and Qos requirement

            (3) cell set (i.e. bundle) to implement the bandwidth

            

            In case-1, all of the three elements are determined by PCE,
            and RPL is

            just a backup and works on slot-aloha cells. Correct?

          

          


          

          
I believe that's correct. BTW, I'm not per se advocating
            for this solution, but it seems to be the approach draft-ietf-roll-rpl-industrial-applicability takes.

          
 

          
In case2, element(1) is determined by
            RPL based on Rank, and element(3) is

            determined by PCE. But, who will determine element(2)? by
            PCE or by some

            entity like RSVP/NSIS or DSCP?

            

          

          


          

          
Agreed. It relatively straightforward for a PCE to
            compute a schedule and distribute that into the network, but
            how does it figure out what the requirements are from the
            nodes in the network. Could we reuse a "PCE requirements"
            protocol out there?

          
 

          

            Qin
            

              

              > [subject was: Scope: 6LoWPAN + 1]

              >

              > Maria Rita,

              >

              > I fully agree with Pascal's suggestion to have the
              PCE only talk to one of

              > the two sides on a on-hop link, and have 6tus be in
              charge to telling the

              > other side to reserve the same cell. I believe Qin
              has also acknowledged

              > this, and has agreed to put this mechanism into 6tus.
              This would probably

              > mean adding some option in the 6tus message format
              saying "this is not a

              > negociation for a soft cell, but an order for you to
              add this hard cell".

              >

              > All,

              >

              > I believe Maria Rita is touching a very important
              point we haven't had

              > time

              > to discuss last week in Orlando, but which I believe
              is essential: how do

              > RPL and the PCE interact? The PCE can have complete
              knowledge of the

              > network topology and the network traffic, so besides
              L2 resource

              > allocation, it could also make routing decision, i.e.
              build the track it

              > believe is best fit.

              >

              > draft-ietf-roll-rpl-industrial-applicability-00 also
              states similar ideas:

              > "The domain of applicability for the RPL protocol may
              include all phases

              > but the Normal Operation phase, where the bandwidth
              allocation and the

            

            > *routes

            > are usually optimized by an external Path Computing
            Engine (PCE)*. [...]

            
> Additionally, it could be envisioned to
              include RPL in the normal

              > operation

              > provided that a new Objective Function is defined
              that actually interacts

              > with the PCE is order to establish the reference
              topology, in which case

            

            > *RPL

            > operations would only apply to emergency repair
            actions*. when the

            

              
> reference topology becomes unusable
                for some failure, and as long as the

                > problem persists."

                >

                > This shot-circuits RPL.

                >

                > The two use cases I can see are:

                > 1. the PCE makes decisions without RPL's
                intervention. RPL runs in the

                > background for emergency repair actions only.

                > 2. RPL sets up multi-hop routes which the PCE uses
                for building tracks.

                > That is, the PCE only performs L2 resource
                allocation.

                >

                > Do we agree to use only use case 1? If we go for 2,
                how does the PCE get

                > information about RPL routes (especially in storing
                mode)?

                >

                > Thomas

                >

                > On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita
                PALATTELLA <

                > maria-rita.palattella@uni.lu>
                wrote:

                >

                >> Hi Qin, and all,

                >> Sorry for coming back to this discussion after
                some time, but I wanted

                >> to

                >> raise and clarify a point.

                >>

                >> Qin>>>(2) If there is PCE, there may
                be different setting. For example,

                >> PCE is in charge for reserving both multiple
                hop path (i.e. every next

                >> hop

                >> Qin>>>neighbor) and cells; or PCE is
                just in charge for reserving the

                >> multiple hop path and leaving cell reservation
                to local, and the

                >> distributed cell reservation will meet the
                bandwidth requirement from

                >> multiple hop path reservation. In the first
                case, hard Qin>>> cell

                >>  reservation will be used.

                >>

                >> Qin >>>(3)If there is no PCE, both
                multi-hop path and cells are reserved

                >> in local.

                >> Qin>>For example, RPL + soft cell
                reservation in 6tus.

                >>

                >> From my point of view (and thinking about TASA
                implementation), the PCE

                >> shouldn't be in charge for reserving the
                multiple hop path. But the

                >> routing

                >> protocol (i.e., RPL in our case) should take
                care of the next hop

                >> neighbor

                >> selection.

                >> When a centralized approach is adopted, the PCE
                will schedule the cells

                >>  (i.e., hard cells according to 6tus
                terminology).

                >> While, when a distributed solution is used,
                6tus will allocate the soft

                >> cells.

                >>

                >> In the centralized scenario with the PCE, to
                avoid the exchange of many

                >> signaling messages, for setting up the
                schedule, we may think (as Pascal

                >> was suggesting during one of the last call) to
                use some hybrid

                >> solutions.

                >> In other words, if PCE allocates (timeoffset1,
                channeloffset3,

                >> slotframe1,

                >> TX) to node A for transmitting to node B, then,
                node B could know

                >> locally

                >> from node A, (and not from the PCE), that the
                cell (timeoffset1,

                >> channeloffset3, slotframe1, RX) has been
                reserved to it, for receiving

                >> from

                >> node A.

                >> We may try to include some functionality in
                6tus layer in order to

                >> manage

                >> such situation.

                >> What do you think?

                >>

                >> Maria Rita

                >>

                >>

                >>
----------------------------------------------------------------------------------------------------------------

                >> > On 3/14/13 9:02 PM, Paul Chilton wrote:

                >> >>>- optionally a PCE sits on the
                backbone and drives the LLNs' TSCH

                >> >>>schedules.

                >> >

                >> > Ah, maybe understood.  It doesn't say that
                existence of PCE is

                >> optional.

                >> > It says that it's optional to put PCE in
                the backbone.  It doesn't

                >> > preclude to put it on BBR.  Correct ?

                >> >

                >> > Shoichi

                >> >
                _______________________________________________

                >> > 6tsch mailing list

                >> > 6tsch@ietf.org

                >> > https://www.ietf.org/mailman/listinfo/6tsch

                >> >

                >>

                >> _______________________________________________

                >> 6tsch mailing list

                >> 6tsch@ietf.org

                >> https://www.ietf.org/mailman/listinfo/6tsch

                >> _______________________________________________

                >> 6tsch mailing list

                >> 6tsch@ietf.org

                >> https://www.ietf.org/mailman/listinfo/6tsch

                >>

                > _______________________________________________

                > 6tsch mailing list

                > 6tsch@ietf.org

                > https://www.ietf.org/mailman/listinfo/6tsch

                >

                

                

              

            

          

        

        

      

      

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


    

  


From twatteyne@gmail.com  Mon Mar 18 13:18:47 2013
Return-Path: 
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 BB49021F8AB8 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 13:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.877
X-Spam-Level: 
X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 XreyXYPXTvSb for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 13:18:46 -0700 (PDT)
Received: from mail-da0-x236.google.com (mail-da0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 23AFC21F8A64 for <6tsch@ietf.org>; Mon, 18 Mar 2013 13:18:46 -0700 (PDT)
Received: by mail-da0-f54.google.com with SMTP id p1so1546820dad.13 for <6tsch@ietf.org>; Mon, 18 Mar 2013 13:18:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=kOSoSbUJJ37o71956EIZYMw59ZGc6DEnjLEFXfXQf3w=; b=qn8y2JNh/6x07ExuQhCI2pT6uvTpyFjCEO/lzsnW7mefXNY8N+RUpJjZmw4yaBYiYN BHYXS4d11BVIY6nGxav+LbmVmvRK/DG6WCNgVGisz4zCGbUzLfezHqyo+Napzj2qkApL +NvkdLYRzaFYzg5fi4kqZe7CZjIEeAE5WKBvByDiYwFQFu4TreqQy60zR9aiJdCt79On T6h8kfDcZXf5zd7Zi/Q4OidNMiAN7CMdU7ycpDP9Z10u/wb1JwviANr8JTDZL8lPMqdX QRLaUUSW7LKX+tLejjxXOqU/g62mhaCdR0CptvZPHB7DzsJ8HORrJU4ZDWEu+m/6rMw3 dGng==
MIME-Version: 1.0
X-Received: by 10.68.11.169 with SMTP id r9mr35047091pbb.221.1363637925881; Mon, 18 Mar 2013 13:18:45 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Mon, 18 Mar 2013 13:18:45 -0700 (PDT)
In-Reply-To: <514773C7.4050002@cox.net>
References: <1dc657302a100f67f8f678323686f351.squirrel@calmail.berkeley.edu>  <514773C7.4050002@cox.net>
Date: Mon, 18 Mar 2013 13:18:45 -0700
X-Google-Sender-Auth: quebde8XQflD7PJVkAwp3MN6tNs
Message-ID: 
From: Thomas Watteyne 
To: 6tsch@ietf.org
Content-Type: multipart/alternative; boundary=bcaec5314b2d2caeaf04d838b2d5
Subject: Re: [6tsch] Interaction between RPL and PCE
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 20:18:47 -0000

--bcaec5314b2d2caeaf04d838b2d5
Content-Type: text/plain; charset=ISO-8859-1

Tom,

Thanks for your insights, this is extremely useful.

I have a specific question:
"when coupled with knowledge of the required periodic publication messaging
(it's frequency, criticality and even PDU size)"
What do you think is the most traditional way for the PCE to gather this
info?

Thomas

On Mon, Mar 18, 2013 at 1:06 PM, Tom Phinney  wrote:

> **
> Re: it seems to be the approach draft-ietf-roll-rpl-industrial-applicability
> takes.
>
> The reason why centralized (i.e., PCE) computation was favored is that
> compute-intensive consideration of schedules, based on physical knowledge
> of the placement of all scheduled devices from the plant piping and
> instrumentation diagram (P&ID) database, when coupled with knowledge of the
> required periodic publication messaging (it's frequency, criticality and
> even PDU size), and potentially augmented by collected history of
> communications failure rates on specific routes, can lead to minimizing
> potential RF conflicts for the most critical messaging. Supercomputers were
> applied to optimizing such industrial processes as early as the 1980s, and
> to optimizing airline equipment use and routing as early as the late 1960s.
> There is nothing novel about large industrial users doing such centralized
> optimization to increase their profitability.
>
> Those of us who work in this industry have always thought that RF-equipped
> devices such as those using 802.15.4 might be able to use their radios for
> some form of localized site survey. This would be particularly the case for
> devices that are externally powered (such as those coupled to powered
> actuators) or environmentally recharged (e.g., from solar, or thermal
> potential differences, or vibration energy harvesting), where battery life
> is not an overriding concern. Use of the distributed network of field
> devices to assess RF problems and provide information that can assist in
> localizing the emission source causing the problems is a high-payback
> additional capability.
>
> In summary, a centralized high-compute-power PCE, driven from a large
> database that includes physical siting information as well as historical
> performance observations, should be able to statistically deconflict many
> tracks by construction. That's a capability that would be applied first to
> the most critical tracks, then the most frequently used tracks, then down
> the priority chain.
>
> There is less of an opportunity to improve aperiodically-used tracks via
> PCE precomputation, but that still seems worth doing to some extent.
>
> Relative to mobile, the only mobile equipment in large outdoor plants that
> would be involved in class 0 or class 1 traffic might be overhead traveling
> cranes. That's a case where it might make sense for a PCE to set up tracks
> to all but the last hop, with multiple field routers able to receive from
> the crane and forward one hop to merge into the precomputed track.
>
> All food for thought.
>
> -Tom
> ====
>
> On 2013.03.18 12:18, Thomas Watteyne wrote:
>
> Qin,
>
>  Please see inline.
>
> On Mon, Mar 18, 2013 at 10:25 AM, Qin Wang  wrote:
>
>> Thomas,
>>
>> I think for a data flow, there are three elements needed to be defined or
>> scheduled explicitly or implicitly:
>> (1) multihop path, i.e. who is the next hop neighbor
>> (2) bandwidth and Qos requirement
>> (3) cell set (i.e. bundle) to implement the bandwidth
>>
>> In case-1, all of the three elements are determined by PCE, and RPL is
>> just a backup and works on slot-aloha cells. Correct?
>>
>
>  I believe that's correct. BTW, I'm not per se advocating for this
> solution, but it seems to be the approach draft-ietf-roll-rpl-industrial-applicability
> takes.
>
>
>> In case2, element(1) is determined by RPL based on Rank, and element(3) is
>> determined by PCE. But, who will determine element(2)? by PCE or by some
>> entity like RSVP/NSIS or DSCP?
>>
>>
>  Agreed. It relatively straightforward for a PCE to compute a schedule
> and distribute that into the network, but how does it figure out what the
> requirements are from the nodes in the network. Could we reuse a "PCE
> requirements" protocol out there?
>
>
>> Qin
>>
>> > [subject was: Scope: 6LoWPAN + 1]
>> >
>> > Maria Rita,
>> >
>> > I fully agree with Pascal's suggestion to have the PCE only talk to one
>> of
>> > the two sides on a on-hop link, and have 6tus be in charge to telling
>> the
>> > other side to reserve the same cell. I believe Qin has also acknowledged
>> > this, and has agreed to put this mechanism into 6tus. This would
>> probably
>> > mean adding some option in the 6tus message format saying "this is not a
>> > negociation for a soft cell, but an order for you to add this hard
>> cell".
>> >
>> > All,
>> >
>> > I believe Maria Rita is touching a very important point we haven't had
>> > time
>> > to discuss last week in Orlando, but which I believe is essential: how
>> do
>> > RPL and the PCE interact? The PCE can have complete knowledge of the
>> > network topology and the network traffic, so besides L2 resource
>> > allocation, it could also make routing decision, i.e. build the track it
>> > believe is best fit.
>> >
>> > draft-ietf-roll-rpl-industrial-applicability-00 also states similar
>> ideas:
>> > "The domain of applicability for the RPL protocol may include all phases
>> > but the Normal Operation phase, where the bandwidth allocation and the
>>  > *routes
>> > are usually optimized by an external Path Computing Engine (PCE)*. [...]
>> > Additionally, it could be envisioned to include RPL in the normal
>> > operation
>> > provided that a new Objective Function is defined that actually
>> interacts
>> > with the PCE is order to establish the reference topology, in which case
>>  > *RPL
>> > operations would only apply to emergency repair actions*. when the
>>  > reference topology becomes unusable for some failure, and as long as
>> the
>> > problem persists."
>> >
>> > This shot-circuits RPL.
>> >
>> > The two use cases I can see are:
>> > 1. the PCE makes decisions without RPL's intervention. RPL runs in the
>> > background for emergency repair actions only.
>> > 2. RPL sets up multi-hop routes which the PCE uses for building tracks.
>> > That is, the PCE only performs L2 resource allocation.
>> >
>> > Do we agree to use only use case 1? If we go for 2, how does the PCE get
>> > information about RPL routes (especially in storing mode)?
>> >
>> > Thomas
>> >
>> > On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA <
>> > maria-rita.palattella@uni.lu> wrote:
>> >
>> >> Hi Qin, and all,
>> >> Sorry for coming back to this discussion after some time, but I wanted
>> >> to
>> >> raise and clarify a point.
>> >>
>> >> Qin>>>(2) If there is PCE, there may be different setting. For example,
>> >> PCE is in charge for reserving both multiple hop path (i.e. every next
>> >> hop
>> >> Qin>>>neighbor) and cells; or PCE is just in charge for reserving the
>> >> multiple hop path and leaving cell reservation to local, and the
>> >> distributed cell reservation will meet the bandwidth requirement from
>> >> multiple hop path reservation. In the first case, hard Qin>>> cell
>> >>  reservation will be used.
>> >>
>> >> Qin >>>(3)If there is no PCE, both multi-hop path and cells are
>> reserved
>> >> in local.
>> >> Qin>>For example, RPL + soft cell reservation in 6tus.
>> >>
>> >> From my point of view (and thinking about TASA implementation), the PCE
>> >> shouldn't be in charge for reserving the multiple hop path. But the
>> >> routing
>> >> protocol (i.e., RPL in our case) should take care of the next hop
>> >> neighbor
>> >> selection.
>> >> When a centralized approach is adopted, the PCE will schedule the cells
>> >>  (i.e., hard cells according to 6tus terminology).
>> >> While, when a distributed solution is used, 6tus will allocate the soft
>> >> cells.
>> >>
>> >> In the centralized scenario with the PCE, to avoid the exchange of many
>> >> signaling messages, for setting up the schedule, we may think (as
>> Pascal
>> >> was suggesting during one of the last call) to use some hybrid
>> >> solutions.
>> >> In other words, if PCE allocates (timeoffset1, channeloffset3,
>> >> slotframe1,
>> >> TX) to node A for transmitting to node B, then, node B could know
>> >> locally
>> >> from node A, (and not from the PCE), that the cell (timeoffset1,
>> >> channeloffset3, slotframe1, RX) has been reserved to it, for receiving
>> >> from
>> >> node A.
>> >> We may try to include some functionality in 6tus layer in order to
>> >> manage
>> >> such situation.
>> >> What do you think?
>> >>
>> >> Maria Rita
>> >>
>> >>
>> >>
>> ----------------------------------------------------------------------------------------------------------------
>> >> > On 3/14/13 9:02 PM, Paul Chilton wrote:
>> >> >>>- optionally a PCE sits on the backbone and drives the LLNs' TSCH
>> >> >>>schedules.
>> >> >
>> >> > Ah, maybe understood.  It doesn't say that existence of PCE is
>> >> optional.
>> >> > It says that it's optional to put PCE in the backbone.  It doesn't
>> >> > preclude to put it on BBR.  Correct ?
>> >> >
>> >> > Shoichi
>> >> > _______________________________________________
>> >> > 6tsch mailing list
>> >> > 6tsch@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/6tsch
>> >> >
>> >>
>> >> _______________________________________________
>> >> 6tsch mailing list
>> >> 6tsch@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/6tsch
>> >> _______________________________________________
>> >> 6tsch mailing list
>> >> 6tsch@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/6tsch
>> >>
>> > _______________________________________________
>> > 6tsch mailing list
>> > 6tsch@ietf.org
>> > https://www.ietf.org/mailman/listinfo/6tsch
>> >
>>
>>
>>
>
> _______________________________________________
> 6tsch mailing list6tsch@ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

--bcaec5314b2d2caeaf04d838b2d5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Tom,

Thanks for your insights, this is extremely useful.=


I have a specific question:
"when =
coupled with knowledge of the required periodic publication messaging (it&#=
39;s frequency, criticality and even PDU size)"


What do you think is the most traditional way for the PCE to gather th=
is info?

Thomas

=
On Mon, Mar 18, 2013 at 1:06 PM, Tom Phinney <tom.phinney@cox.net&g=
t; wrote:




 =20
   =20
 =20
  

    Re: it seems to be the approach=A0draft-ietf-roll-rpl-=
industrial-applicability
      takes.

    

    The reason why centralized (i.e., PCE) computation was favored is
    that compute-intensive consideration of schedules, based on physical
    knowledge of the placement of all scheduled devices from the plant
    piping and instrumentation diagram (P&ID) database, when coupled
    with knowledge of the required periodic publication messaging (it's
    frequency, criticality and even PDU size), and potentially augmented
    by collected history of communications failure rates on specific
    routes, can lead to minimizing potential RF conflicts for the most
    critical messaging. Supercomputers were applied to optimizing such
    industrial processes as early as the 1980s, and to optimizing
    airline equipment use and routing as early as the late 1960s. There
    is nothing novel about large industrial users doing such centralized
    optimization to increase their profitability.

    

    Those of us who work in this industry have always thought that
    RF-equipped devices such as those using 802.15.4 might be able to
    use their radios for some form of localized site survey. This would
    be particularly the case for devices that are externally powered
    (such as those coupled to powered actuators) or environmentally
    recharged (e.g., from solar, or thermal potential differences, or
    vibration energy harvesting), where battery life is not an
    overriding concern. Use of the distributed network of field devices
    to assess RF problems and provide information that can assist in
    localizing the emission source causing the problems is a
    high-payback additional capability.

    

    In summary, a centralized high-compute-power PCE, driven from a
    large database that includes physical siting information as well as
    historical performance observations, should be able to statistically
    deconflict many tracks by construction. That's a capability that
    would be applied first to the most critical tracks, then the most
    frequently used tracks, then down the priority chain.

    

    There is less of an opportunity to improve aperiodically-used tracks
    via PCE precomputation, but that still seems worth doing to some
    extent.

    

    Relative to mobile, the only mobile equipment in large outdoor
    plants that would be involved in class 0 or class 1 traffic might be
    overhead traveling cranes. That's a case where it might make sense
    for a PCE to set up tracks to all but the last hop, with multiple
    field routers able to receive from the crane and forward one hop to
    merge into the precomputed track.

    

    All food for thought.

    

    -Tom

    =3D=3D=3D=3D


    On 2013.03.18 12:18, Thomas Watteyne wrote:
    
Qin,
      


      

      
Please see inline.

        

        
On Mon, Mar 18, 2013 at 10:25 AM, Qin
          Wang <qinwang@berkeley.edu>
          wrote:

          
Thomas,

            

            I think for a data flow, there are three elements needed to
            be defined or

            scheduled explicitly or implicitly:

            (1) multihop path, i.e. who is the next hop neighbor

            (2) bandwidth and Qos requirement

            (3) cell set (i.e. bundle) to implement the bandwidth

            

            In case-1, all of the three elements are determined by PCE,
            and RPL is

            just a backup and works on slot-aloha cells. Correct?

          

          


          

          
I believe that's correct. BTW, I'm not per se advoca=
ting
            for this solution, but it seems to be the approach=A0draft=
-ietf-roll-rpl-industrial-applicability takes.


          
=A0

          
In case2, eleme=
nt(1) is determined by
            RPL based on Rank, and element(3) is

            determined by PCE. But, who will determine element(2)? by
            PCE or by some

            entity like RSVP/NSIS or DSCP?

            

          

          


          

          
Agreed. It relatively straightforward for a PCE to
            compute a schedule and distribute that into the network, but
            how does it figure out what the requirements are from the
            nodes in the network. Could we reuse a "PCE requirements&q=
uot;
            protocol out there?

          
=A0

          

            Qin
            

              

              > [subject was: Scope: 6LoWPAN + 1]

              >

              > Maria Rita,

              >

              > I fully agree with Pascal's suggestion to have the
              PCE only talk to one of

              > the two sides on a on-hop link, and have 6tus be in
              charge to telling the

              > other side to reserve the same cell. I believe Qin
              has also acknowledged

              > this, and has agreed to put this mechanism into 6tus.
              This would probably

              > mean adding some option in the 6tus message format
              saying "this is not a

              > negociation for a soft cell, but an order for you to
              add this hard cell".

              >

              > All,

              >

              > I believe Maria Rita is touching a very important
              point we haven't had

              > time

              > to discuss last week in Orlando, but which I believe
              is essential: how do

              > RPL and the PCE interact? The PCE can have complete
              knowledge of the

              > network topology and the network traffic, so besides
              L2 resource

              > allocation, it could also make routing decision, i.e.
              build the track it

              > believe is best fit.

              >

              > draft-ietf-roll-rpl-industrial-applicability-00 also
              states similar ideas:

              > "The domain of applicability for the RPL protocol m=
ay
              include all phases

              > but the Normal Operation phase, where the bandwidth
              allocation and the

            

            > *routes

            > are usually optimized by an external Path Computing
            Engine (PCE)*. [...]

            
> Additionally, it could be envisioned to
              include RPL in the normal

              > operation

              > provided that a new Objective Function is defined
              that actually interacts

              > with the PCE is order to establish the reference
              topology, in which case

            

            > *RPL

            > operations would only apply to emergency repair
            actions*. when the

            

              
> reference topology becomes unusable
                for some failure, and as long as the

                > problem persists."

                >

                > This shot-circuits RPL.

                >

                > The two use cases I can see are:

                > 1. the PCE makes decisions without RPL's
                intervention. RPL runs in the

                > background for emergency repair actions only.

                > 2. RPL sets up multi-hop routes which the PCE uses
                for building tracks.

                > That is, the PCE only performs L2 resource
                allocation.

                >

                > Do we agree to use only use case 1? If we go for 2,
                how does the PCE get

                > information about RPL routes (especially in storing
                mode)?

                >

                > Thomas

                >

                > On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita
                PALATTELLA <

                > maria-rita.palattella@uni.lu>
                wrote:

                >

                >> Hi Qin, and all,

                >> Sorry for coming back to this discussion after
                some time, but I wanted

                >> to

                >> raise and clarify a point.

                >>

                >> Qin>>>(2) If there is PCE, there may
                be different setting. For example,

                >> PCE is in charge for reserving both multiple
                hop path (i.e. every next

                >> hop

                >> Qin>>>neighbor) and cells; or PCE is
                just in charge for reserving the

                >> multiple hop path and leaving cell reservation
                to local, and the

                >> distributed cell reservation will meet the
                bandwidth requirement from

                >> multiple hop path reservation. In the first
                case, hard Qin>>> cell

                >> =A0reservation will be used.

                >>

                >> Qin >>>(3)If there is no PCE, both
                multi-hop path and cells are reserved

                >> in local.

                >> Qin>>For example, RPL + soft cell
                reservation in 6tus.

                >>

                >> From my point of view (and thinking about TASA
                implementation), the PCE

                >> shouldn't be in charge for reserving the
                multiple hop path. But the

                >> routing

                >> protocol (i.e., RPL in our case) should take
                care of the next hop

                >> neighbor

                >> selection.

                >> When a centralized approach is adopted, the PCE
                will schedule the cells

                >> =A0(i.e., hard cells according to 6tus
                terminology).

                >> While, when a distributed solution is used,
                6tus will allocate the soft

                >> cells.

                >>

                >> In the centralized scenario with the PCE, to
                avoid the exchange of many

                >> signaling messages, for setting up the
                schedule, we may think (as Pascal

                >> was suggesting during one of the last call) to
                use some hybrid

                >> solutions.

                >> In other words, if PCE allocates (timeoffset1,
                channeloffset3,

                >> slotframe1,

                >> TX) to node A for transmitting to node B, then,
                node B could know

                >> locally

                >> from node A, (and not from the PCE), that the
                cell (timeoffset1,

                >> channeloffset3, slotframe1, RX) has been
                reserved to it, for receiving

                >> from

                >> node A.

                >> We may try to include some functionality in
                6tus layer in order to

                >> manage

                >> such situation.

                >> What do you think?

                >>

                >> Maria Rita

                >>

                >>

                >>
---------------------------------------------------------------------------=
-------------------------------------

                >> > On 3/14/13 9:02 PM, Paul Chilton wrote:

                >> >>>- optionally a PCE sits on the
                backbone and drives the LLNs' TSCH

                >> >>>schedules.

                >> >

                >> > Ah, maybe understood. =A0It doesn't say t=
hat
                existence of PCE is

                >> optional.

                >> > It says that it's optional to put PCE in
                the backbone. =A0It doesn't

                >> > preclude to put it on BBR. =A0Correct ?

                >> >

                >> > Shoichi

                >> >
                _______________________________________________

                >> > 6tsch mailing list

                >> > 6tsch@ietf.org

                >> > https://www.ietf.org/mailman/listinfo/6tsch

                >> >

                >>

                >> _______________________________________________
                >> 6tsch mailing list

                >> 6tsch@ietf.org

                >> https://www.ietf.org/mailman/listinfo/6tsch

                >> _______________________________________________
                >> 6tsch mailing list

                >> 6tsch@ietf.org

                >> https://www.ietf.org/mailman/listinfo/6tsch

                >>

                > _______________________________________________

                > 6tsch mailing list

                > 6t=
sch@ietf.org

                > https://www.ietf.org/mailman/listinfo/6tsch

                >

                

                

              

            

          

        

        

      

      

_______________________________________________
6tsch mailing list
6tsch@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/6tsch


    

  



_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





--bcaec5314b2d2caeaf04d838b2d5--

From tom.phinney@cox.net  Mon Mar 18 15:22:55 2013
Return-Path: 
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 8AFC721F8AC3 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 15:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.141
X-Spam-Level: 
X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
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 w8U8U96Z8tl1 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 15:22:54 -0700 (PDT)
Received: from fed1rmfepo103.cox.net (fed1rmfepo103.cox.net [68.230.241.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4E74821F8AA8 for <6tsch@ietf.org>; Mon, 18 Mar 2013 15:22:53 -0700 (PDT)
Received: from fed1rmimpo110 ([68.230.241.159]) by fed1rmfepo103.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130318222252.ZRWH30259.fed1rmfepo103.cox.net@fed1rmimpo110> for <6tsch@ietf.org>; Mon, 18 Mar 2013 18:22:52 -0400
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo110 with cox id DANr1l00j3gAAro01ANrSj; Mon, 18 Mar 2013 18:22:52 -0400
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020202.514793BC.00A0,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=AfVv6QrG c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=6D3b9miqrD4A:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=_NqJobw5kD0A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=G3t9GZesmGVy41otDn8A:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=4vB-4DCPJfMA:10 a=lZB815dzVvQA:10 a=d1tzyXb9sVL1Fmye:21 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <514793BB.2020806@cox.net>
Date: Mon, 18 Mar 2013 15:22:51 -0700
From: Tom Phinney 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: 6tsch@ietf.org
References: <1dc657302a100f67f8f678323686f351.squirrel@calmail.berkeley.edu>		<514773C7.4050002@cox.net> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [6tsch] Interaction between RPL and PCE
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney 
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 22:22:55 -0000



  
    
  
  
    In process automation plants, the information on each control loop,
    including its criticality, loop rate (e.g., 4 Hz, 1 Hz) or period
    (e.g., 5 s, 15 s, 30 s, 60 s, 5 m), phasing relative to other
    interacting control loops where such is relevant, and much more is
    part of a site database. The primary users of that database are the
    engineering workstations that control the process, most of which are
    typically found in control rooms inside blast-resistant buildings. 

    

    The primary key to that database is the device's "tag name", which
    is the alphanumeric name assigned to the particular process sensor
    or actuator device (e.g., T3E01, MF102, VA241, MC205 for temperature
    sensor 301, mass flow sensor 102, valve 241, motor controller 205).
    The P&ID (piping and instrumentation diagram) database is also
    accessible by tag name; it shows not only physical geolocation of
    devices but also their interconnections. Most of the P&ID
    database is irrelevant to communications; it contains information on
    things such as the materials of construction of the
    process-contacting parts of the equipment, diameters of connecting
    pipes (e.g., 60 cm), anticipated maximum pressures, site cameras
    that have a view of that equipment and coordinates to aim and zoom
    the cameras, diagrams and perhaps photos of the construction, etc.

    

    So, to answer your question about "the most traditional way to
    gather this info", there are traditional databases on a site where
    this information resides, and there are existing standard protocols
    such as OPC that can provide access to that information. However,
    OPC normally does not need access to the device geolocation, so that
    probably would need to be included in the engineering database
    (obtained from the P&ID database). 

    

    There is existing practice for doing RF surveys of specific site
    areas, usually with manual optimization of RF relays, but there is
    no real history of automating the process at the scale under
    discussion. Since site optimization of wireless via a PCE is not
    (yet) industry standard practice, there is no comparable experience
    to draw on here, so there will necessarily be innovation.

    

    -Tom

    ===

    On 2013.03.18 13:18, Thomas Watteyne wrote:
    
Tom,
      


      

      
Thanks for your insights, this is extremely useful.

      


      

      
I have a specific question:

      
"when coupled with knowledge of the required periodic
        publication messaging (it's frequency, criticality and even PDU
        size)"

      
What do you think is the most traditional way for the PCE to
        gather this info?

      


      

      
Thomas

        

        
On Mon, Mar 18, 2013 at 1:06 PM, Tom
          Phinney <tom.phinney@cox.net>
          wrote:

          

            
 Re: it seems to be
              the approach draft-ietf-roll-rpl-industrial-applicability
                takes.

              

              The reason why centralized (i.e., PCE) computation was
              favored is that compute-intensive consideration of
              schedules, based on physical knowledge of the placement of
              all scheduled devices from the plant piping and
              instrumentation diagram (P&ID) database, when coupled
              with knowledge of the required periodic publication
              messaging (it's frequency, criticality and even PDU size),
              and potentially augmented by collected history of
              communications failure rates on specific routes, can lead
              to minimizing potential RF conflicts for the most critical
              messaging. Supercomputers were applied to optimizing such
              industrial processes as early as the 1980s, and to
              optimizing airline equipment use and routing as early as
              the late 1960s. There is nothing novel about large
              industrial users doing such centralized optimization to
              increase their profitability.

              

              Those of us who work in this industry have always thought
              that RF-equipped devices such as those using 802.15.4
              might be able to use their radios for some form of
              localized site survey. This would be particularly the case
              for devices that are externally powered (such as those
              coupled to powered actuators) or environmentally recharged
              (e.g., from solar, or thermal potential differences, or
              vibration energy harvesting), where battery life is not an
              overriding concern. Use of the distributed network of
              field devices to assess RF problems and provide
              information that can assist in localizing the emission
              source causing the problems is a high-payback additional
              capability.

              

              In summary, a centralized high-compute-power PCE, driven
              from a large database that includes physical siting
              information as well as historical performance
              observations, should be able to statistically deconflict
              many tracks by construction. That's a capability that
              would be applied first to the most critical tracks, then
              the most frequently used tracks, then down the priority
              chain.

              

              There is less of an opportunity to improve
              aperiodically-used tracks via PCE precomputation, but that
              still seems worth doing to some extent.

              

              Relative to mobile, the only mobile equipment in large
              outdoor plants that would be involved in class 0 or class
              1 traffic might be overhead traveling cranes. That's a
              case where it might make sense for a PCE to set up tracks
              to all but the last hop, with multiple field routers able
              to receive from the crane and forward one hop to merge
              into the precomputed track.

              

              All food for thought.

              

              -Tom

              ====
              

                


                  On 2013.03.18 12:18, Thomas
                  Watteyne wrote:
                  
Qin,
                    


                    

                    
Please see inline.

                      

                      
On Mon, Mar 18, 2013 at
                        10:25 AM, Qin Wang <qinwang@berkeley.edu>
                        wrote:

                        
Thomas,

                          

                          I think for a data flow, there are three
                          elements needed to be defined or

                          scheduled explicitly or implicitly:

                          (1) multihop path, i.e. who is the next hop
                          neighbor

                          (2) bandwidth and Qos requirement

                          (3) cell set (i.e. bundle) to implement the
                          bandwidth

                          

                          In case-1, all of the three elements are
                          determined by PCE, and RPL is

                          just a backup and works on slot-aloha cells.
                          Correct?

                        

                        


                        

                        
I believe that's correct. BTW, I'm not per
                          se advocating for this solution, but it seems
                          to be the approach draft-ietf-roll-rpl-industrial-applicability
                            takes.

                        
 

                        
In
                          case2, element(1) is determined by RPL based
                          on Rank, and element(3) is

                          determined by PCE. But, who will determine
                          element(2)? by PCE or by some

                          entity like RSVP/NSIS or DSCP?

                          

                        

                        


                        

                        
Agreed. It relatively straightforward for a
                          PCE to compute a schedule and distribute that
                          into the network, but how does it figure out
                          what the requirements are from the nodes in
                          the network. Could we reuse a "PCE
                          requirements" protocol out there?

                        
 

                        
 Qin
                          
 

                            > [subject was: Scope: 6LoWPAN + 1]

                            >

                            > Maria Rita,

                            >

                            > I fully agree with Pascal's suggestion
                            to have the PCE only talk to one of

                            > the two sides on a on-hop link, and
                            have 6tus be in charge to telling the

                            > other side to reserve the same cell. I
                            believe Qin has also acknowledged

                            > this, and has agreed to put this
                            mechanism into 6tus. This would probably

                            > mean adding some option in the 6tus
                            message format saying "this is not a

                            > negociation for a soft cell, but an
                            order for you to add this hard cell".

                            >

                            > All,

                            >

                            > I believe Maria Rita is touching a very
                            important point we haven't had

                            > time

                            > to discuss last week in Orlando, but
                            which I believe is essential: how do

                            > RPL and the PCE interact? The PCE can
                            have complete knowledge of the

                            > network topology and the network
                            traffic, so besides L2 resource

                            > allocation, it could also make routing
                            decision, i.e. build the track it

                            > believe is best fit.

                            >

                            >
                            draft-ietf-roll-rpl-industrial-applicability-00
                            also states similar ideas:

                            > "The domain of applicability for the
                            RPL protocol may include all phases

                            > but the Normal Operation phase, where
                            the bandwidth allocation and the

                          

                          > *routes

                          > are usually optimized by an external Path
                          Computing Engine (PCE)*. [...]

                          
> Additionally, it could be envisioned
                            to include RPL in the normal

                            > operation

                            > provided that a new Objective Function
                            is defined that actually interacts

                            > with the PCE is order to establish the
                            reference topology, in which case

                          

                          > *RPL

                          > operations would only apply to emergency
                          repair actions*. when the

                          

                            
> reference topology becomes
                              unusable for some failure, and as long as
                              the

                              > problem persists."

                              >

                              > This shot-circuits RPL.

                              >

                              > The two use cases I can see are:

                              > 1. the PCE makes decisions without
                              RPL's intervention. RPL runs in the

                              > background for emergency repair
                              actions only.

                              > 2. RPL sets up multi-hop routes which
                              the PCE uses for building tracks.

                              > That is, the PCE only performs L2
                              resource allocation.

                              >

                              > Do we agree to use only use case 1?
                              If we go for 2, how does the PCE get

                              > information about RPL routes
                              (especially in storing mode)?

                              >

                              > Thomas

                              >

                              > On Mon, Mar 18, 2013 at 2:06 AM,
                              Maria Rita PALATTELLA <

                              > maria-rita.palattella@uni.lu>

                              wrote:

                              >

                              >> Hi Qin, and all,

                              >> Sorry for coming back to this
                              discussion after some time, but I wanted

                              >> to

                              >> raise and clarify a point.

                              >>

                              >> Qin>>>(2) If there is
                              PCE, there may be different setting. For
                              example,

                              >> PCE is in charge for reserving
                              both multiple hop path (i.e. every next

                              >> hop

                              >> Qin>>>neighbor) and
                              cells; or PCE is just in charge for
                              reserving the

                              >> multiple hop path and leaving
                              cell reservation to local, and the

                              >> distributed cell reservation will
                              meet the bandwidth requirement from

                              >> multiple hop path reservation. In
                              the first case, hard Qin>>> cell

                              >>  reservation will be used.

                              >>

                              >> Qin >>>(3)If there is no
                              PCE, both multi-hop path and cells are
                              reserved

                              >> in local.

                              >> Qin>>For example, RPL +
                              soft cell reservation in 6tus.

                              >>

                              >> From my point of view (and
                              thinking about TASA implementation), the
                              PCE

                              >> shouldn't be in charge for
                              reserving the multiple hop path. But the

                              >> routing

                              >> protocol (i.e., RPL in our case)
                              should take care of the next hop

                              >> neighbor

                              >> selection.

                              >> When a centralized approach is
                              adopted, the PCE will schedule the cells

                              >>  (i.e., hard cells according to
                              6tus terminology).

                              >> While, when a distributed
                              solution is used, 6tus will allocate the
                              soft

                              >> cells.

                              >>

                              >> In the centralized scenario with
                              the PCE, to avoid the exchange of many

                              >> signaling messages, for setting
                              up the schedule, we may think (as Pascal

                              >> was suggesting during one of the
                              last call) to use some hybrid

                              >> solutions.

                              >> In other words, if PCE allocates
                              (timeoffset1, channeloffset3,

                              >> slotframe1,

                              >> TX) to node A for transmitting to
                              node B, then, node B could know

                              >> locally

                              >> from node A, (and not from the
                              PCE), that the cell (timeoffset1,

                              >> channeloffset3, slotframe1, RX)
                              has been reserved to it, for receiving

                              >> from

                              >> node A.

                              >> We may try to include some
                              functionality in 6tus layer in order to

                              >> manage

                              >> such situation.

                              >> What do you think?

                              >>

                              >> Maria Rita

                              >>

                              >>

                              >>
----------------------------------------------------------------------------------------------------------------

                              >> > On 3/14/13 9:02 PM, Paul
                              Chilton wrote:

                              >> >>>- optionally a PCE
                              sits on the backbone and drives the LLNs'
                              TSCH

                              >> >>>schedules.

                              >> >

                              >> > Ah, maybe understood.  It
                              doesn't say that existence of PCE is

                              >> optional.

                              >> > It says that it's optional
                              to put PCE in the backbone.  It doesn't

                              >> > preclude to put it on BBR.
                               Correct ?

                              >> >

                              >> > Shoichi

                              >> >
                              _______________________________________________

                              >> > 6tsch mailing list

                              >> > 6tsch@ietf.org

                              >> > https://www.ietf.org/mailman/listinfo/6tsch

                              >> >

                              >>

                              >>
                              _______________________________________________

                              >> 6tsch mailing list

                              >> 6tsch@ietf.org

                              >> https://www.ietf.org/mailman/listinfo/6tsch

                              >>
                              _______________________________________________

                              >> 6tsch mailing list

                              >> 6tsch@ietf.org

                              >> https://www.ietf.org/mailman/listinfo/6tsch

                              >>

                              >
                              _______________________________________________

                              > 6tsch mailing list

                              > 6tsch@ietf.org

                              > https://www.ietf.org/mailman/listinfo/6tsch

                              >

                              

                              

                            

                          

                        

                      

                      

                    

                    

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


                  

                

              

            

            

            _______________________________________________

            6tsch mailing list

            6tsch@ietf.org

            https://www.ietf.org/mailman/listinfo/6tsch

            

          

        

        

      

      

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


    

  


From alfredo.grieco@gmail.com  Mon Mar 18 15:34:30 2013
Return-Path: 
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 D5CEA21F8AC3 for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 15:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.373
X-Spam-Level: **
X-Spam-Status: No, score=2.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RDNS_NONE=0.1]
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 1pQjNwBslNIV for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 15:34:30 -0700 (PDT)
Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 24DB121F88A0 for <6tsch@ietf.org>; Mon, 18 Mar 2013 15:34:29 -0700 (PDT)
Received: by mail-bk0-f46.google.com with SMTP id j5so2773672bkw.5 for <6tsch@ietf.org>; Mon, 18 Mar 2013 15:34:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=7Xui1vEzmM02spe+wagRBKypiWPBtSbJ6hG+ObilHK8=; b=PKaStDJGQu8OCJohbPR76WpejzPd2Ko4UGFkoEzOr1FYJvEAnyU1XgBD29JZMeiSa8 zr1vLzJ/lsJAfr7UR6NfIOyD3iPYTbFr4GkZWn0fWmnUUJ+3XgNxFxSaXJ9g4PG4488f my/CTieUm5iSNrAjxi2deRQNIDquZ5gA2+B3HX/afLeAENFwuuMz1ebIKeqfIzlq8lLz 4FLKodHVtGJtUX8ff6bnDMy7MZz6zsD3CWoo7FQ3F5xwEUGk6GmT0wbDUcLMXaJVBf+e 5ijaciS1dAZ2r+NOcUORM4YtfuDkAV4VXMODfXx0YJhKk2CfdMD8XJQr9LPL8gj9PdrW m1ew==
X-Received: by 10.205.33.3 with SMTP id sm3mr7784199bkb.64.1363646069201; Mon, 18 Mar 2013 15:34:29 -0700 (PDT)
Received: from [217.201.163.208] ([217.201.163.208]) by mx.google.com with ESMTPS id o2sm5894577bkv.3.2013.03.18.15.34.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 15:34:28 -0700 (PDT)
From: Grieco 
Content-Type: multipart/alternative; boundary=Apple-Mail-25FBA8A2-7C1D-4020-9DFE-FB06F39E6FDA
X-Mailer: iPad Mail (10B146)
Message-Id: 
Date: Mon, 18 Mar 2013 23:34:25 +0100
To: 6tsch@ietf.org
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: [6tsch] Test mail
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 22:34:31 -0000

--Apple-Mail-25FBA8A2-7C1D-4020-9DFE-FB06F39E6FDA
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

Please discard, it is just a test. Sorry

Alfredo

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672


--Apple-Mail-25FBA8A2-7C1D-4020-9DFE-FB06F39E6FDA
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Please discard, it is just a test. Sor=
ry

Alfredo

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
Skype id: l.alfredo.grieco
Mobile: +39 3346715672

=

--Apple-Mail-25FBA8A2-7C1D-4020-9DFE-FB06F39E6FDA--

From alfredo.grieco@gmail.com  Mon Mar 18 15:43:04 2013
Return-Path: 
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 4082C21F8A7E for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 15:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.673
X-Spam-Level: **
X-Spam-Status: No, score=2.673 tagged_above=-999 required=5 tests=[AWL=-0.300,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RDNS_NONE=0.1]
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 91m0yQCnFGej for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 15:43:02 -0700 (PDT)
Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5F75C21F8A3F for <6tsch@ietf.org>; Mon, 18 Mar 2013 15:42:57 -0700 (PDT)
Received: by mail-bk0-f52.google.com with SMTP id jk13so2713920bkc.25 for <6tsch@ietf.org>; Mon, 18 Mar 2013 15:42:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:references:from:content-type:x-mailer :in-reply-to:message-id:date:to:content-transfer-encoding :mime-version; bh=1RsDPG3m/WwmnZKKQOR0sChwZxrO+AKyC/o8kRgT8WQ=; b=rMTQo0YljVsoEufafWX3Uy5s2MaHO59o74m/DK3Uz9m6Prfd2+hKEW46+vbmH7PBM+ ZKy0GB3QjzhXW3S7Ue6PoUeD7ktOJYBrizLSTmjPCLhwlxaP6B8Z64piIL9lA2iImGGq oMuyt8MBYo5f76fBkrs9zpuJVK4b2M6D7x5liBg1Iw9Y7YxLtInqIZoLcGRk3RmV+zvK XcagvoFLiQJ9umzpCJw4OMNnohKlMeuSrT6fLxvQXkWRDo73NT7JOtqojg1AMKRHhiGS k7smOvY1ShS9kwEjjTb3w9Y49+EHj4ArqVsf9zEwKXm6KVttcl5u0yxN3VwWuYC6W3sQ iMbQ==
X-Received: by 10.205.32.208 with SMTP id sl16mr7909628bkb.27.1363646576352; Mon, 18 Mar 2013 15:42:56 -0700 (PDT)
Received: from [217.201.163.208] ([217.201.163.208]) by mx.google.com with ESMTPS id io13sm5899560bkc.15.2013.03.18.15.42.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 15:42:55 -0700 (PDT)
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>  <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu> <51475694.85d00e0a.2654.3c21@mx.google.com> <1b952faca1b2846136ff23c6723eeb63.squirrel@calmail.berkeley.edu>  <51476DC1.5070707@eecs.berkeley.edu>
From: Grieco 
Content-Type: multipart/alternative; boundary=Apple-Mail-99769A51-1A9F-4DBA-A3E4-5E91D45B7870
X-Mailer: iPad Mail (10B146)
In-Reply-To: <51476DC1.5070707@eecs.berkeley.edu>
Message-Id: 
Date: Mon, 18 Mar 2013 23:42:50 +0100
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: [6tsch] R: Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 22:43:04 -0000

--Apple-Mail-99769A51-1A9F-4DBA-A3E4-5E91D45B7870
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi Xavi, Thomas, all

The problem I am pointing out is not related only to the neighbourhood. As a=
 matter of fact, a node would like its data be received to the sink and not o=
nly at the next hop. If for each hop to travel, a data packet should gain a c=
ell through some request/answer handshake this would lead to high e2e delays=
 when the depth of the tree is high and would incur useless signalling.

If we think at TASA, to do an example, the schedule exactly rules the story o=
f each packet from its generating node to the sink. I was trying to figure o=
ut how to do the same in presence of some uncertainty on the network topolog=
y.

While solving this problem is something to be afforded in some scientific pa=
per, I believe that the functionalities of 6tus and the entire architecture w=
e are envisaging should be ready to welcome this new wave of algorithms.

In other terms, I am proposing to add a limited number of "reserved pipes" t=
o the sink that could be used to transport "only" urgent data from mobile no=
des.=20

Thomas, this could be added as general remark to the architecture or to the d=
raft you are editing. Of course, with more details, some primitive to the 6t=
us draft could be added or lead to a new draft on handling mobile 6tsch node=
s.

Cheers :-)


--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672


On 18 Mar 2013, at 20:40, Xavier Vilajosana  w=
rote:

> Hi Alfredo,
>=20
> just one point on mobility.
> TSCH networks may require certain time for a node to join, this depends on=
 how the EBs are sent and what are the policies for the joining node on how t=
o scan the different channels. Having said that, I think that the time requi=
red for a node to reserve some cells with its neighbour is extremely less th=
an the joining time and hence if a mobile node can join the network for sure=
 has time to schedule some links. So maybe this is not a big problem :-)
>=20
> cheers!
> Xavi
>=20
>=20
>=20
>=20
> On 18/03/13 12:36, Grieco wrote:
>> Hi Qin, Thomas, and all
>>=20
>> Perhaps the only way to cope with (a reasonable degree of) mobility is to=
 hardly assign a certain number of cells at each link to be used in case a m=
obile node arrives with urgent data to transmit.
>>=20
>> Obviously this would slightly decrease the overall efficiency of the syst=
em because such "guaranteed cells" could get unused in most of cases.
>>=20
>> If, on the other side, the mobile node is generating data which is not th=
at urgent, soft reservation could be used as well, which should waste a smal=
ler amount of resources.
>>=20
>> In this perspective, mobile nodes could be handled using either functions=
 1 or 2, depending on the degree of mobility, the priority of the data packe=
ts generated by mobile nodes, the desired duty cycle, and so on.
>>=20
>> Cheers
>>=20
>> Alfredo
>>=20
>>=20
>>=20
>>=20
>> --
>> Luigi Alfredo Grieco, PhD
>> Assistant Professor
>> Department of Electrical and Information Engineering
>> Politecnico di Bari
>> Via Orabona 4 - 70125 - Bari - Italy
>> +39 080 5963 911
>> telematics.poliba.it/grieco
>> Skype id: l.alfredo.grieco
>> Mobile: +39 3346715672
>>=20
>>=20
>> On 18 Mar 2013, at 20:20, "Qin Wang"  wrote:
>>=20
>>> Alfredo,
>>>=20
>>> I think your remark is correct. So, if there is lots of mobility, I woul=
d
>>> be prefer distributed approach, i.e. Soft Cell reservation locally + RPL=
 +
>>> DSCP for QoS.
>>>=20
>>> Qin
>>>=20
>>>=20
>>>> Hi Qin,
>>>> Your proposal is sound.
>>>> Just a final remark: if my understanding is correct, the PCE should bui=
ld
>>>> a schedule that spans across multiple links from mobile node M towards t=
he
>>>> sink S.
>>>> If a M moves after the schedule has been built, some pre-assigned
>>>> resources along that path could get lost (which could be tolerated)
>>>> because of the change of the topology.
>>>> Is it ok ?
>>>> Cheers and thanks for your answer
>>>> Alfredo
>>>> -----Messaggio originale-----
>>>> Da: Qin Wang [mailto:qinwang@berkeley.edu]
>>>> Inviato: Monday, March 18, 2013 6:48 PM
>>>> A: Grieco
>>>> Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); 6tsch@ietf.org;
>>>> Xavier Vilajosana
>>>> Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for 6tu=
s
>>>> Alfredo,
>>>> Firstly, my understanding is Hard cell reservation can only be used by
>>>> PCE, i.e.  centralized schedule. Thus, mobile node will join in network=

>>>> based on the cells broadcast in EB. And, after its registration, PCE wi=
ll
>>>> assign some Hard cells to it.
>>>> secondly, regarding to high priority of the data flow from the mobile
>>>> node, DSCP may help, i.e. the packets from the mobile node can include
>>>> Priority.
>>>> How do you think?
>>>> Qin
>>>>> Hi Qin and all,
>>>>> Just to challenge the two groups of functions Qin is talking about,
>>>>> what if a certain number of mobile nodes need hard reservation ? In
>>>>> this case, mobile nodes transmit Real time data to be delivered within=

>>>>> a given deadline but 6tus does not know in advance the rank (or the
>>>>> position within the topology) of such nodes.
>>>>> I mean that this kind of traffic has the top priority but nobody knows=

>>>>> in advance the exact position of the nodes that is going to generate
>>>>> that data.
>>>>> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes, how=
 ?
>>>>> Thanks a lot in advance for your attention
>>>>> Cheers
>>>>> Alfredo
>>>>> --
>>>>> Luigi Alfredo Grieco, PhD
>>>>> Assistant Professor
>>>>> Department of Electrical and Information Engineering Politecnico di
>>>>> Bari Via Orabona 4 - 70125 - Bari - Italy
>>>>> +39 080 5963 911
>>>>> telematics.poliba.it/grieco
>>>>> Skype id: l.alfredo.grieco
>>>>> Mobile: +39 3346715672
>>>>> On 17 Mar 2013, at 17:47, "Qin Wang"  wrote:
>>>>>> I fully agree with Carsten that Simple is very important. Let's
>>>>>> overlapping the following three scenarios, then we will find only two=

>>>>>> groups of functions 6tus should provide.
>>>>>> (1) Hard cell reserve/remove, which supports the 1st scenario.
>>>>>> (2) Soft cell reserve/remove, which supports the 2nd and 3rd scenario=
.
>>>>>> Any more?
>>>>>> Qin
>>>>>>> Sorry for the delayed response. I was stuck on the plane for too
>>>>>>> long
>>>>>>> :)
>>>>>>> I like the discussion that Qin is going for where we define the
>>>>>>> scenarios.
>>>>>>> At the same time, as Carsten says we need to make sure overlapping
>>>>>>> scenarios of any sort are simplified and aggregated as much as
>>>>>>> possible.
>>>>>>> Let me just try to put my 2 cents in-line...
>>>>>>> On Mar 17, 2013, at 8:19 AM, Qin Wang  wrote:
>>>>>>>> Hi Pascal,
>>>>>>>> It is a very good idea to establish a bundle of cells between A and=

>>>>>>>> B by just triggering 6tus in one side. We can design for different
>>>>>>>> scenarios.
>>>>>>>> (1) PCE defines the track, i.e. the multihop path, the bandwidth of=

>>>>>>>> each hop, and scheduling hard-cells to implement the multihop path.=

>>>>>>>> Assume nodeA and nodeB are one-hop neighbors along the path. In
>>>>>>>> this case, PCE can send Create.hardcell command to 6tus layer in
>>>>>>>> nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB'
>>>>>>>> 6tus, then the hard cell is reserved. This function is not in the
>>>>>>>> current version of 6tus draft, but we can add it in the next
>>>>>>>> version easily.
>>>>>>>> (2)PCE defines the multihop path and the bandwidth of each hop, but=

>>>>>>>> not schedules the cells to meet the path bandwidth. In this case,
>>>>>>>> soft cell reservation will be applied, which is always triggered in=

>>>>>>>> Transmitting side, and negotiated by the 6tus layer of both sides.
>>>>>>>> (3)The cell reservation is triggered by upper layer, e.g. the
>>>>>>>> RSVP/NSIS entity in nodeA. Then soft cell reservation process in
>>>>>>>> 6tus layer of nodeA will by triggered, and the negotiation process
>>>>>>>> is same as case (2).
>>>>>>>> In summary, by adding reserve hard cell procedure into version-00
>>>>>>>> of 6tus, we can let the bundle reservation in every scenarios be
>>>>>>>> triggered just in one side.
>>>>>>>> How do you think?
>>>>>>> Great first start in defining the scenarios.
>>>>>>>> Qin
>>>>>>>>> Hi Qin:
>>>>>>>>> I think we are on the same line. The services that 6TUS proposes
>>>>>>>>> do not depend on which protocol the request came in through.
>>>>>>>>> Since we are defining the protocol extensions, we'll make sure
>>>>>>>>> that the new information is directly digestible by the 6TUS layer.=

>>>>>>>>> The protocol extensions will be separate specs, and there should
>>>>>>>>> be little to no dereference between those specs and yours.
>>>>>>>>> What's important to me to discuss is how we establish a bundle of
>>>>>>>>> cells between A and B.
>>>>>>>>> IMHO, it would be best if that can be achieved by triggering a
>>>>>>>>> service in A - no need to trigger B as well.
>>>>>>>>> That way, the volume of exchanges between PCE and nodes can be
>>>>>>>>> devided by 2.
>>>>>>>>> This would mean that there must be an exchange between 6TUS in A
>>>>>>>>> and 6TUS in B.
>>>>>>>>> Which  also would mean that there is a protocol part related to
>>>>>>>>> 6TUS=E2=80=A6
>>>>>>> Fully agreed that this is needed. Being an independent layer, I
>>>>>>> don't see why not.
>>>>>>>>> Cheers,
>>>>>>>>> Pascal
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On
>>>>>>>>> Behalf Of Qin Wang
>>>>>>>>> Sent: vendredi 15 mars 2013 18:04
>>>>>>>>> To: JeongGil Ko
>>>>>>>>> Cc: 6tsch@ietf.org; Xavier Vilajosana
>>>>>>>>> Subject: Re: [6tsch] Schemes for resource allocation in the LLN
>>>>>>>>> for 6tus
>>>>>>>>> John and Xavi,
>>>>>>>>> I agree that understanding more about upper layer protocols like
>>>>>>>>> RSVP and NSIS is very helpful for designing 6tus. But, I want to
>>>>>>>>> make clearer about my understanding on the relationship between
>>>>>>>>> 6tus and existing reservation protocols like RSVP or NSIS.
>>>>>>>>> (1) When we talk about reservation in the context of 6tus, we
>>>>>>>>> mainly focus on  link resource (i.e. cell) reservation, which is
>>>>>>>>> required/ triggered by upper layer. Even in the pure centralized
>>>>>>>>> approach, it may happen to cross-layer reserve both L3 and L2
>>>>>>>>> resource, but you still can separate them logically.
>>>>>>>>> (2) The upper layer requirement to 6tus may come from PCE carried
>>>>>>>>> by protocol like CoAP, may come from the RSVP/NSIS entity inside
>>>>>>>>> nodes.
>>>>>>>>> Thus, for 6tus, the question is what kind of function and
>>>>>>>>> interface should be provided to support the upper layer, instead
>>>>>>>>> of which upper layer protocol should be used.
>>>>>>>>> How do you think?
>>>>>>> I agree with your arguments that the important thing is defining the=

>>>>>>> functionalities. It seems like some of these efforts are on the way
>>>>>>> in the later emails. Me bringing in the term "RSVP" was not that I
>>>>>>> wanted to go an use RSVP in the way it is, but bring the
>>>>>>> (modified/customized) concept in for use in 6tus. As to what I read
>>>>>>> there may have been a misunderstanding between us but we are on the
>>>>>>> same line.
>>>>>>> Thanks!
>>>>>>> -John
>>>>>>>>> Qin
>>>>>> _______________________________________________
>>>>>> 6tsch mailing list
>>>>>> 6tsch@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/6tsch
>=20

--Apple-Mail-99769A51-1A9F-4DBA-A3E4-5E91D45B7870
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



Hi Xavi, Thomas=
, all

The=
 problem I am pointing out is not related only to the neighbourhood. As a ma=
tter of fact, a node would like its data be received to the sink and not onl=
y at the next hop. If for each hop to travel, a data packet should gain a ce=
ll through some request/answer handshake this would lead to high e2e delays w=
hen the depth of the tree is high and would incur useless signalling.=


If we think at T=
ASA, to do an example, the schedule exactly rules the story of each packet f=
rom its generating node to the sink. I was trying to figure out how to do th=
e same in presence of some uncertainty on the network topology.
=


While solving this pr=
oblem is something to be afforded in some scientific paper, I believe that t=
he functionalities of 6tus and the entire architecture we are envisaging sho=
uld be ready to welcome this new wave of algorithms.

In other terms, I am proposing to a=
dd a limited number of "reserved pipes" to the sink that could be used to tr=
ansport "only" urgent data from mobile nodes. 

Thomas, this could be added as gen=
eral remark to the architecture or to the draft you are editing. Of course, w=
ith more details, some primitive to the 6tus draft could be added or lead to=
 a new draft on handling mobile 6tsch nodes.
=

Cheers :-)


=
--
L=
uigi Alfredo Grieco, PhD
=
Assistant Professor
Depar=
tment of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
Sk=
ype id: l.alfredo.grieco
=
Mobile: +39 3346715672


On 18 Mar 2013, at 20:40, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:

 =20
    
 =20
 =20
    
Hi Alfredo,

      

      just one point on mobility.

      TSCH networks may require certain time for a node to join, this
      depends on how the EBs are sent and what are the policies for the
      joining node on how to scan the different channels. Having said
      that, I think that the time required for a node to reserve some
      cells with its neighbour is extremely less than the joining time
      and hence if a mobile node can join the network for sure has time
      to schedule some links. So maybe this is not a big problem :-)

      

      cheers!

      Xavi

      

      

      

      

      On 18/03/13 12:36, Grieco wrote:

    

    

      
      
Hi Qin, Thomas, and all

      


      

      
Perhaps the only way to cope with (a reasonable degree of)
        mobility is to hardly assign a certain number of cells at each
        link to be used in case a mobile node arrives with urgent data
        to transmit.

      


      

      
Obviously this would slightly decrease the overall efficiency
        of the system because such "guaranteed cells" could get unused
        in most of cases.

      


      

      
If, on the other side, the mobile node is generating data
        which is not that urgent, soft reservation could be used as
        well, which should waste a smaller amount of resources.

      


      

      
In this perspective, mobile nodes could be handled using
        either functions 1 or 2, depending on the degree of mobility,
        the priority of the data packets generated by mobile nodes, the
        desired duty cycle, and so on.

      


      

      
Cheers

      


      

      
Alfredo

      


      

      


      

      


      

      


        --
        

          
Luigi
            Alfredo Grieco, PhD

          
Assistant
            Professor

          
Department
            of Electrical and Information Engineering

          
Politecnico
            di Bari

          
Via
            Orabona 4 - 70125 - Bari - Italy

          
+39 080
            5963 911

          
          
Skype id:
            l.alfredo.grieco

          
Mobile:
            +39 3346715672

        

        

          


          

        

      

      


        On 18 Mar 2013, at 20:20, "Qin Wang" <qinwang@berkeley.edu>
        wrote:

        

      

      

        
Alfredo,

          

          I think your remark is correct. So, if there is lots of
            mobility, I would

          be prefer distributed approach, i.e. Soft Cell
            reservation locally + RPL +

          DSCP for QoS.

          

          Qin

          

          

          
Hi Qin,

          

          


          

          
Your proposal is sound.
=

          

          


          

          
Just a final remark: if my
              understanding is correct, the PCE should build

          

          
a schedule that spans across
              multiple links from mobile node M towards the

          

          
sink S.

          

          


          

          
If a M moves after the schedule
              has been built, some pre-assigned

          

          
resources along that path could
              get lost (which could be tolerated)

          

          
because of the change of the
              topology.

          

          


          

          
Is it ok ?

          

          


          

          
Cheers and thanks for your
              answer

          

          


          

          
Alfredo

          

          


          

          


          

          


          

          
-----Messaggio originale-----

          

          
Da: Qin Wang [mailto:qinwang@berkeley.edu]=


          

          
Inviato: Monday, March 18, 2013
              6:48 PM

          

          
A: Grieco

          

          
Cc: Qin Wang; JeongGil Ko;
              Pascal Thubert (pthubert); 6tsch@ietf.org;

          

          
Xavier Vilajosana

          

          
Oggetto: Re: [6tsch] Schemes for
              resource allocation in the LLN for 6tus

          

          


          

          
Alfredo,

          

          


          

          
Firstly, my understanding is
              Hard cell reservation can only be used by

          

          
PCE, i.e.  centralized schedu=
le.
              Thus, mobile node will join in network

          

          
based on the cells broadcast in
              EB. And, after its registration, PCE will

          

          
assign some Hard cells to it.

          

          


          

          
secondly, regarding to high
              priority of the data flow from the mobile

          

          
node, DSCP may help, i.e. the
              packets from the mobile node can include

          

          
Priority.

          

          


          

          
How do you think?

          

          


          

          
Qin

          

          


          

          


          

          


          

          

            
Hi Qin and all,

            

          

          

            


            

          

          

            
Just to challenge the two
                groups of functions Qin is talking about,

            

          

          

            
what if a certain number of
                mobile nodes need hard reservation ? In

            

          

          

            
this case, mobile nodes
                transmit Real time data to be delivered within

            

          

          

            
a given deadline but 6tus does
                not know in advance the rank (or the

            

          

          

            
position within the topology)
                of such nodes.

            

          

          

            


            

          

          

            
I mean that this kind of
                traffic has the top priority but nobody knows

            

          

          

            
in advance the exact position
                of the nodes that is going to generate

            

          

          

            
that data.

            

          

          

            


            

          

          

            
Do we need a further case ? Or
                we can leverage on 1 or 2 ? If yes, how ?

            

          

          

            


            

          

          

            
Thanks a lot in advance for
                your attention

            

          

          

            


            

          

          

            
Cheers

            

          

          

            


            

          

          

            
Alfredo

            

          

          

            


            

          

          

            
--

            

          

          

            
Luigi Alfredo Grieco, PhD=


            

          

          

            
Assistant Professor

            

          

          

            
Department of Electrical and
                Information Engineering Politecnico di

            

          

          

            
Bari Via Orabona 4 - 70125 -
                Bari - Italy

            

          

          

            
+39 080 5963 911

            

          

          

            
telematics.poliba.it/grieco

            

          

          

            
Skype id: l.alfredo.grieco

            

          

          

            
Mobile: +39 3346715672
            

          

          

            


            

          

          

            


            

          

          

            
On 17 Mar 2013, at 17:47, "Qin
                Wang" <qinwang@berkeley.edu>
                wrote:

            

          

          

            


            

          

          

            

              


              

            

          

          

            

              


              

            

          

          

            

              
I fully agree with Carsten
                  that Simple is very important. Let's

              

            

          

          

            

              
overlapping the following
                  three scenarios, then we will find only two

              

            

          

          

            

              
groups of functions 6tus
                  should provide.

              

            

          

          

            

              


              

            

          

          

            

              
(1) Hard cell
                  reserve/remove, which supports the 1st scenario.
              

            

          

          

            

              
(2) Soft cell
                  reserve/remove, which supports the 2nd and 3rd
                  scenario.

              

            

          

          

            

              


              

            

          

          

            

              
Any more?

              

            

          

          

            

              


              

            

          

          

            

              
Qin

              

            

          

          

            

              


              

            

          

          

            

              


              

            

          

          

            

              

                
Sorry for the delayed
                    response. I was stuck on the plane for too

                

              

            

          

          

            

              

                
long

                

              

            

          

          

            

              

                
:)

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
I like the discussion that
                    Qin is going for where we define the

                

              

            

          

          

            

              

                
scenarios.

                

              

            

          

          

            

              

                
At the same time, as
                    Carsten says we need to make sure overlapping
=

                

              

            

          

          

            

              

                
scenarios of any sort are
                    simplified and aggregated as much as

                

              

            

          

          

            

              

                
possible.

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
Let me just try to put my
                    2 cents in-line...

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
On Mar 17, 2013, at 8:19
                    AM, Qin Wang <qinwang@berkeley.edu>
                    wrote:

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                

                  
Hi Pascal,

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  
It is a very good idea
                      to establish a bundle of cells between A and
                  

                

              

            

          

          

            

              

                

                  
B by just triggering
                      6tus in one side. We can design for different
                  

                

              

            

          

          

            

              

                

                  
scenarios.

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  
(1) PCE defines the
                      track, i.e. the multihop path, the bandwidth of=


                  

                

              

            

          

          

            

              

                

                  
each hop, and scheduling
                      hard-cells to implement the multihop path.

                  

                

              

            

          

          

            

              

                

                  
Assume nodeA and nodeB
                      are one-hop neighbors along the path. In

                  

                

              

            

          

          

            

              

                

                  
this case, PCE can send
                      Create.hardcell command to 6tus layer in

                  

                

              

            

          

          

            

              

                

                  
nodeA,and nodeA's 6tus
                      sends Create.hardcell command to nodeB'

                  

                

              

            

          

          

            

              

                

                  
6tus, then the hard cell
                      is reserved. This function is not in the

                  

                

              

            

          

          

            

              

                

                  
current version of 6tus
                      draft, but we can add it in the next

                  

                

              

            

          

          

            

              

                

                  
version easily.
=

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  
(2)PCE defines the
                      multihop path and the bandwidth of each hop, but

                  

                

              

            

          

          

            

              

                

                  
not schedules the cells
                      to meet the path bandwidth. In this case,

                  

                

              

            

          

          

            

              

                

                  
soft cell reservation
                      will be applied, which is always triggered in
                  

                

              

            

          

          

            

              

                

                  
Transmitting side, and
                      negotiated by the 6tus layer of both sides.
=

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  
(3)The cell reservation
                      is triggered by upper layer, e.g. the

                  

                

              

            

          

          

            

              

                

                  
RSVP/NSIS entity in
                      nodeA. Then soft cell reservation process in
                  

                

              

            

          

          

            

              

                

                  
6tus layer of nodeA will
                      by triggered, and the negotiation process

                  

                

              

            

          

          

            

              

                

                  
is same as case (2).

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  
In summary, by adding
                      reserve hard cell procedure into version-00
=

                  

                

              

            

          

          

            

              

                

                  
of 6tus, we can let the
                      bundle reservation in every scenarios be

                  

                

              

            

          

          

            

              

                

                  
triggered just in one
                      side.

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  
How do you think?
                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
Great first start in
                    defining the scenarios.

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                

                  
Qin

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                

                  

                    
Hi Qin:

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
I think we are on the
                        same line. The services that 6TUS proposes
                    

                  

                

              

            

          

          

            

              

                

                  

                    
do not depend on which
                        protocol the request came in through.

                    

                  

                

              

            

          

          

            

              

                

                  

                    
Since we are defining
                        the protocol extensions, we'll make sure

                    

                  

                

              

            

          

          

            

              

                

                  

                    
that the new
                        information is directly digestible by the 6TUS
                        layer.

                    

                  

                

              

            

          

          

            

              

                

                  

                    
The protocol
                        extensions will be separate specs, and there
                        should

                    

                  

                

              

            

          

          

            

              

                

                  

                    
be little to no
                        dereference between those specs and yours.
                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
What's important to me
                        to discuss is how we establish a bundle of
                    

                  

                

              

            

          

          

            

              

                

                  

                    
cells between A and B.

                    

                  

                

              

            

          

          

            

              

                

                  

                    
IMHO, it would be best
                        if that can be achieved by triggering a

                    

                  

                

              

            

          

          

            

              

                

                  

                    
service in A - no need
                        to trigger B as well.

                    

                  

                

              

            

          

          

            

              

                

                  

                    
That way, the volume
                        of exchanges between PCE and nodes can be
=

                    

                  

                

              

            

          

          

            

              

                

                  

                    
devided by 2.
=

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
This would mean that
                        there must be an exchange between 6TUS in A
                    

                  

                

              

            

          

          

            

              

                

                  

                    
and 6TUS in B.
                    

                  

                

              

            

          

          

            

              

                

                  

                    
Which  also would m=
ean
                        that there is a protocol part related to

                    

                  

                

              

            

          

          

            

              

                

                  

                    
6TUS=E2=80=A6
=

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
Fully agreed that this is
                    needed. Being an independent layer, I

                

              

            

          

          

            

              

                
don't see why not.
                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                

                  

                    
Cheers,

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
Pascal

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
-----Original
                        Message-----

                    

                  

                

              

            

          

          

            

              

                

                  

                    
From: 6tsch-bounces@ietf.org
                        [mailto:6tsch-bounces@ietf.org]
                        On

                    

                  

                

              

            

          

          

            

              

                

                  

                    
Behalf Of Qin Wang

                    

                  

                

              

            

          

          

            

              

                

                  

                    
Sent: vendredi 15 mars
                        2013 18:04

                    

                  

                

              

            

          

          

            

              

                

                  

                    
To: JeongGil Ko
                    

                  

                

              

            

          

          

            

              

                

                  

                    
Cc: 6tsch@ietf.org;
                        Xavier Vilajosana

                    

                  

                

              

            

          

          

            

              

                

                  

                    
Subject: Re: [6tsch]
                        Schemes for resource allocation in the LLN
                    

                  

                

              

            

          

          

            

              

                

                  

                    
for 6tus

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
John and Xavi,
                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
I agree that
                        understanding more about upper layer protocols
                        like

                    

                  

                

              

            

          

          

            

              

                

                  

                    
RSVP and NSIS is very
                        helpful for designing 6tus. But, I want to
                    

                  

                

              

            

          

          

            

              

                

                  

                    
make clearer about my
                        understanding on the relationship between
=

                    

                  

                

              

            

          

          

            

              

                

                  

                    
6tus and existing
                        reservation protocols like RSVP or NSIS.

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
(1) When we talk about
                        reservation in the context of 6tus, we

                    

                  

                

              

            

          

          

            

              

                

                  

                    
mainly focus on  li=
nk
                        resource (i.e. cell) reservation, which is
                    

                  

                

              

            

          

          

            

              

                

                  

                    
required/ triggered by
                        upper layer. Even in the pure centralized
=

                    

                  

                

              

            

          

          

            

              

                

                  

                    
approach, it may
                        happen to cross-layer reserve both L3 and L2<=
br>
                    

                  

                

              

            

          

          

            

              

                

                  

                    
resource, but you
                        still can separate them logically.

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
(2) The upper layer
                        requirement to 6tus may come from PCE carried=


                    

                  

                

              

            

          

          

            

              

                

                  

                    
by protocol like CoAP,
                        may come from the RSVP/NSIS entity inside
=

                    

                  

                

              

            

          

          

            

              

                

                  

                    
nodes.

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
Thus, for 6tus, the
                        question is what kind of function and

                    

                  

                

              

            

          

          

            

              

                

                  

                    
interface should be
                        provided to support the upper layer, instead<=
br>
                    

                  

                

              

            

          

          

            

              

                

                  

                    
of which upper layer
                        protocol should be used.

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    
How do you think?=


                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
I agree with your
                    arguments that the important thing is defining the

                

              

            

          

          

            

              

                
functionalities. It seems
                    like some of these efforts are on the way

                

              

            

          

          

            

              

                
in the later emails. Me
                    bringing in the term "RSVP" was not that I

                

              

            

          

          

            

              

                
wanted to go an use RSVP
                    in the way it is, but bring the

                

              

            

          

          

            

              

                
(modified/customized)
                    concept in for use in 6tus. As to what I read
=

                

              

            

          

          

            

              

                
there may have been a
                    misunderstanding between us but we are on the
=

                

              

            

          

          

            

              

                
same line.

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
Thanks!

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                
-John

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                

                  

                    
Qin

                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  

                    


                    

                  

                

              

            

          

          

            

              

                

                  


                  

                

              

            

          

          

            

              

                


                

              

            

          

          

            

              

                


                

              

            

          

          

            

              


              

            

          

          

            

              
______________________________=
_________________

              

            

          

          

            

              
6tsch mailing list

              

            

          

          

            

              
6tsch@ietf.org

              

            

          

          

            

              
https://www.ietf.org/mail=
man/listinfo/6tsch

              

            

          

          

            


            

          

          


          

          


          

          


          

          

          

        

      

    

    

 =20


=

--Apple-Mail-99769A51-1A9F-4DBA-A3E4-5E91D45B7870--

From qinwang@berkeley.edu  Mon Mar 18 17:09:51 2013
Return-Path: 
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 8E3B221F855A for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 17:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.207
X-Spam-Level: 
X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4]
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 uy56X1HOAPcz for <6tsch@ietfa.amsl.com>; Mon, 18 Mar 2013 17:09:50 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 27D1921F84F9 for <6tsch@ietf.org>; Mon, 18 Mar 2013 17:09:50 -0700 (PDT)
Received: from cm01ws.ist.berkeley.edu ([169.229.218.163] helo=calmail.berkeley.edu) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UHk7f-0001Vm-La; Mon, 18 Mar 2013 17:09:49 -0700
Received: from 64.134.233.81 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Mon, 18 Mar 2013 17:09:47 -0700
Message-ID: 
In-Reply-To: 
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>  <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu> <51475694.85d00e0a.2654.3c21@mx.google.com> <1b952faca1b2846136ff23c6723eeb63.squirrel@calmail.berkeley.edu>  <51476DC1.5070707@eecs.berkeley.edu> 
Date: Mon, 18 Mar 2013 17:09:47 -0700
From: "Qin Wang" 
To: "Grieco" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] R: Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 00:09:51 -0000

Alfredo,

I think there are two key features in your description: (1)data with high
priority, and (2)mobility. I would like to think the two feature
separately.

Regarding to the high priority, I think the QoS mechanism like DSCP can
handle it, no matter the data flow come from static node or moving node.

Regarding to the mobility, the 6tus can support to establish tracks for
specific purpose. Actually, the cell reservation request comes from upper
layer, 6tus do not know the reserved cells will be used by static nodes or
mobile nodes. In another word, upper layer can ask 6tus to reserve some
cells or tracks or pipes which specifically used for mobile node to send
data as you said.

Does it make sense?

Qin



>
> Hi Xavi, Thomas, all
>
> The problem I am pointing out is not related only to the neighbourhood. As
> a matter of fact, a node would like its data be received to the sink and
> not only at the next hop. If for each hop to travel, a data packet should
> gain a cell through some request/answer handshake this would lead to high
> e2e delays when the depth of the tree is high and would incur useless
> signalling.
>
> If we think at TASA, to do an example, the schedule exactly rules the
> story of each packet from its generating node to the sink. I was trying to
> figure out how to do the same in presence of some uncertainty on the
> network topology.
>
> While solving this problem is something to be afforded in some scientific
> paper, I believe that the functionalities of 6tus and the entire
> architecture we are envisaging should be ready to welcome this new wave of
> algorithms.
>
> In other terms, I am proposing to add a limited number of "reserved pipes"
> to the sink that could be used to transport "only" urgent data from mobile
> nodes.
>
> Thomas, this could be added as general remark to the architecture or to
> the draft you are editing. Of course, with more details, some primitive to
> the 6tus draft could be added or lead to a new draft on handling mobile
> 6tsch nodes.
>
> Cheers :-)
>
>
> --
> Luigi Alfredo Grieco, PhD
> Assistant Professor
> Department of Electrical and Information Engineering
> Politecnico di Bari
> Via Orabona 4 - 70125 - Bari - Italy
> +39 080 5963 911
> telematics.poliba.it/grieco
> Skype id: l.alfredo.grieco
> Mobile: +39 3346715672
>
>
> On 18 Mar 2013, at 20:40, Xavier Vilajosana
>  wrote:
>
>> Hi Alfredo,
>>
>> just one point on mobility.
>> TSCH networks may require certain time for a node to join, this depends
>> on how the EBs are sent and what are the policies for the joining node
>> on how to scan the different channels. Having said that, I think that
>> the time required for a node to reserve some cells with its neighbour is
>> extremely less than the joining time and hence if a mobile node can join
>> the network for sure has time to schedule some links. So maybe this is
>> not a big problem :-)
>>
>> cheers!
>> Xavi
>>
>>
>>
>>
>> On 18/03/13 12:36, Grieco wrote:
>>> Hi Qin, Thomas, and all
>>>
>>> Perhaps the only way to cope with (a reasonable degree of) mobility is
>>> to hardly assign a certain number of cells at each link to be used in
>>> case a mobile node arrives with urgent data to transmit.
>>>
>>> Obviously this would slightly decrease the overall efficiency of the
>>> system because such "guaranteed cells" could get unused in most of
>>> cases.
>>>
>>> If, on the other side, the mobile node is generating data which is not
>>> that urgent, soft reservation could be used as well, which should waste
>>> a smaller amount of resources.
>>>
>>> In this perspective, mobile nodes could be handled using either
>>> functions 1 or 2, depending on the degree of mobility, the priority of
>>> the data packets generated by mobile nodes, the desired duty cycle, and
>>> so on.
>>>
>>> Cheers
>>>
>>> Alfredo
>>>
>>>
>>>
>>>
>>> --
>>> Luigi Alfredo Grieco, PhD
>>> Assistant Professor
>>> Department of Electrical and Information Engineering
>>> Politecnico di Bari
>>> Via Orabona 4 - 70125 - Bari - Italy
>>> +39 080 5963 911
>>> telematics.poliba.it/grieco
>>> Skype id: l.alfredo.grieco
>>> Mobile: +39 3346715672
>>>
>>>
>>> On 18 Mar 2013, at 20:20, "Qin Wang"  wrote:
>>>
>>>> Alfredo,
>>>>
>>>> I think your remark is correct. So, if there is lots of mobility, I
>>>> would
>>>> be prefer distributed approach, i.e. Soft Cell reservation locally +
>>>> RPL +
>>>> DSCP for QoS.
>>>>
>>>> Qin
>>>>
>>>>
>>>>> Hi Qin,
>>>>> Your proposal is sound.
>>>>> Just a final remark: if my understanding is correct, the PCE should
>>>>> build
>>>>> a schedule that spans across multiple links from mobile node M
>>>>> towards the
>>>>> sink S.
>>>>> If a M moves after the schedule has been built, some pre-assigned
>>>>> resources along that path could get lost (which could be tolerated)
>>>>> because of the change of the topology.
>>>>> Is it ok ?
>>>>> Cheers and thanks for your answer
>>>>> Alfredo
>>>>> -----Messaggio originale-----
>>>>> Da: Qin Wang [mailto:qinwang@berkeley.edu]
>>>>> Inviato: Monday, March 18, 2013 6:48 PM
>>>>> A: Grieco
>>>>> Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); 6tsch@ietf.org;
>>>>> Xavier Vilajosana
>>>>> Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for
>>>>> 6tus
>>>>> Alfredo,
>>>>> Firstly, my understanding is Hard cell reservation can only be used
>>>>> by
>>>>> PCE, i.e.  centralized schedule. Thus, mobile node will join in
>>>>> network
>>>>> based on the cells broadcast in EB. And, after its registration, PCE
>>>>> will
>>>>> assign some Hard cells to it.
>>>>> secondly, regarding to high priority of the data flow from the mobile
>>>>> node, DSCP may help, i.e. the packets from the mobile node can
>>>>> include
>>>>> Priority.
>>>>> How do you think?
>>>>> Qin
>>>>>> Hi Qin and all,
>>>>>> Just to challenge the two groups of functions Qin is talking about,
>>>>>> what if a certain number of mobile nodes need hard reservation ? In
>>>>>> this case, mobile nodes transmit Real time data to be delivered
>>>>>> within
>>>>>> a given deadline but 6tus does not know in advance the rank (or the
>>>>>> position within the topology) of such nodes.
>>>>>> I mean that this kind of traffic has the top priority but nobody
>>>>>> knows
>>>>>> in advance the exact position of the nodes that is going to generate
>>>>>> that data.
>>>>>> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes,
>>>>>> how ?
>>>>>> Thanks a lot in advance for your attention
>>>>>> Cheers
>>>>>> Alfredo
>>>>>> --
>>>>>> Luigi Alfredo Grieco, PhD
>>>>>> Assistant Professor
>>>>>> Department of Electrical and Information Engineering Politecnico di
>>>>>> Bari Via Orabona 4 - 70125 - Bari - Italy
>>>>>> +39 080 5963 911
>>>>>> telematics.poliba.it/grieco
>>>>>> Skype id: l.alfredo.grieco
>>>>>> Mobile: +39 3346715672
>>>>>> On 17 Mar 2013, at 17:47, "Qin Wang"  wrote:
>>>>>>> I fully agree with Carsten that Simple is very important. Let's
>>>>>>> overlapping the following three scenarios, then we will find only
>>>>>>> two
>>>>>>> groups of functions 6tus should provide.
>>>>>>> (1) Hard cell reserve/remove, which supports the 1st scenario.
>>>>>>> (2) Soft cell reserve/remove, which supports the 2nd and 3rd
>>>>>>> scenario.
>>>>>>> Any more?
>>>>>>> Qin
>>>>>>>> Sorry for the delayed response. I was stuck on the plane for too
>>>>>>>> long
>>>>>>>> :)
>>>>>>>> I like the discussion that Qin is going for where we define the
>>>>>>>> scenarios.
>>>>>>>> At the same time, as Carsten says we need to make sure overlapping
>>>>>>>> scenarios of any sort are simplified and aggregated as much as
>>>>>>>> possible.
>>>>>>>> Let me just try to put my 2 cents in-line...
>>>>>>>> On Mar 17, 2013, at 8:19 AM, Qin Wang 
>>>>>>>> wrote:
>>>>>>>>> Hi Pascal,
>>>>>>>>> It is a very good idea to establish a bundle of cells between A
>>>>>>>>> and
>>>>>>>>> B by just triggering 6tus in one side. We can design for
>>>>>>>>> different
>>>>>>>>> scenarios.
>>>>>>>>> (1) PCE defines the track, i.e. the multihop path, the bandwidth
>>>>>>>>> of
>>>>>>>>> each hop, and scheduling hard-cells to implement the multihop
>>>>>>>>> path.
>>>>>>>>> Assume nodeA and nodeB are one-hop neighbors along the path. In
>>>>>>>>> this case, PCE can send Create.hardcell command to 6tus layer in
>>>>>>>>> nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB'
>>>>>>>>> 6tus, then the hard cell is reserved. This function is not in the
>>>>>>>>> current version of 6tus draft, but we can add it in the next
>>>>>>>>> version easily.
>>>>>>>>> (2)PCE defines the multihop path and the bandwidth of each hop,
>>>>>>>>> but
>>>>>>>>> not schedules the cells to meet the path bandwidth. In this case,
>>>>>>>>> soft cell reservation will be applied, which is always triggered
>>>>>>>>> in
>>>>>>>>> Transmitting side, and negotiated by the 6tus layer of both
>>>>>>>>> sides.
>>>>>>>>> (3)The cell reservation is triggered by upper layer, e.g. the
>>>>>>>>> RSVP/NSIS entity in nodeA. Then soft cell reservation process in
>>>>>>>>> 6tus layer of nodeA will by triggered, and the negotiation
>>>>>>>>> process
>>>>>>>>> is same as case (2).
>>>>>>>>> In summary, by adding reserve hard cell procedure into version-00
>>>>>>>>> of 6tus, we can let the bundle reservation in every scenarios be
>>>>>>>>> triggered just in one side.
>>>>>>>>> How do you think?
>>>>>>>> Great first start in defining the scenarios.
>>>>>>>>> Qin
>>>>>>>>>> Hi Qin:
>>>>>>>>>> I think we are on the same line. The services that 6TUS proposes
>>>>>>>>>> do not depend on which protocol the request came in through.
>>>>>>>>>> Since we are defining the protocol extensions, we'll make sure
>>>>>>>>>> that the new information is directly digestible by the 6TUS
>>>>>>>>>> layer.
>>>>>>>>>> The protocol extensions will be separate specs, and there should
>>>>>>>>>> be little to no dereference between those specs and yours.
>>>>>>>>>> What's important to me to discuss is how we establish a bundle
>>>>>>>>>> of
>>>>>>>>>> cells between A and B.
>>>>>>>>>> IMHO, it would be best if that can be achieved by triggering a
>>>>>>>>>> service in A - no need to trigger B as well.
>>>>>>>>>> That way, the volume of exchanges between PCE and nodes can be
>>>>>>>>>> devided by 2.
>>>>>>>>>> This would mean that there must be an exchange between 6TUS in A
>>>>>>>>>> and 6TUS in B.
>>>>>>>>>> Which  also would mean that there is a protocol part related to
>>>>>>>>>> 6TUS…
>>>>>>>> Fully agreed that this is needed. Being an independent layer, I
>>>>>>>> don't see why not.
>>>>>>>>>> Cheers,
>>>>>>>>>> Pascal
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On
>>>>>>>>>> Behalf Of Qin Wang
>>>>>>>>>> Sent: vendredi 15 mars 2013 18:04
>>>>>>>>>> To: JeongGil Ko
>>>>>>>>>> Cc: 6tsch@ietf.org; Xavier Vilajosana
>>>>>>>>>> Subject: Re: [6tsch] Schemes for resource allocation in the LLN
>>>>>>>>>> for 6tus
>>>>>>>>>> John and Xavi,
>>>>>>>>>> I agree that understanding more about upper layer protocols like
>>>>>>>>>> RSVP and NSIS is very helpful for designing 6tus. But, I want to
>>>>>>>>>> make clearer about my understanding on the relationship between
>>>>>>>>>> 6tus and existing reservation protocols like RSVP or NSIS.
>>>>>>>>>> (1) When we talk about reservation in the context of 6tus, we
>>>>>>>>>> mainly focus on  link resource (i.e. cell) reservation, which is
>>>>>>>>>> required/ triggered by upper layer. Even in the pure centralized
>>>>>>>>>> approach, it may happen to cross-layer reserve both L3 and L2
>>>>>>>>>> resource, but you still can separate them logically.
>>>>>>>>>> (2) The upper layer requirement to 6tus may come from PCE
>>>>>>>>>> carried
>>>>>>>>>> by protocol like CoAP, may come from the RSVP/NSIS entity inside
>>>>>>>>>> nodes.
>>>>>>>>>> Thus, for 6tus, the question is what kind of function and
>>>>>>>>>> interface should be provided to support the upper layer, instead
>>>>>>>>>> of which upper layer protocol should be used.
>>>>>>>>>> How do you think?
>>>>>>>> I agree with your arguments that the important thing is defining
>>>>>>>> the
>>>>>>>> functionalities. It seems like some of these efforts are on the
>>>>>>>> way
>>>>>>>> in the later emails. Me bringing in the term "RSVP" was not that I
>>>>>>>> wanted to go an use RSVP in the way it is, but bring the
>>>>>>>> (modified/customized) concept in for use in 6tus. As to what I
>>>>>>>> read
>>>>>>>> there may have been a misunderstanding between us but we are on
>>>>>>>> the
>>>>>>>> same line.
>>>>>>>> Thanks!
>>>>>>>> -John
>>>>>>>>>> Qin
>>>>>>> _______________________________________________
>>>>>>> 6tsch mailing list
>>>>>>> 6tsch@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


From alfredo.grieco@gmail.com  Tue Mar 19 01:58:16 2013
Return-Path: 
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 06B6821F888B for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 01:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.823
X-Spam-Level: **
X-Spam-Status: No, score=2.823 tagged_above=-999 required=5 tests=[AWL=-0.150,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RDNS_NONE=0.1]
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 v54AmE2pwYS1 for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 01:58:13 -0700 (PDT)
Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 96AA821F8887 for <6tsch@ietf.org>; Tue, 19 Mar 2013 01:58:12 -0700 (PDT)
Received: by mail-ea0-f176.google.com with SMTP id h10so102889eaj.21 for <6tsch@ietf.org>; Tue, 19 Mar 2013 01:58:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:references:from:content-type:x-mailer :in-reply-to:message-id:date:to:content-transfer-encoding :mime-version; bh=sWECMmSZ/VwXvx/Uamd3rusDKsTzk1EY4HzTVjaCgXY=; b=mzDxNJUi3ecWjHQ8R3t5V6uqX4lyVpwvM2bB3iRf2S8kC/UYomL3MIxayaevb5G1+V i7vhpaZpa2DFGHw+CWL+rIt9Lvxi0wTZmCefApAvc/0e132I0mh2+dsWRcdfTuzl7qqG 7d/K6IDYmjRz0MqnS/F4ouugfqOEsOKZLIuadxVfXhORPXAiaG7PpqAYJkSAak4Hc/aP JHpfW4OtWgmFmug9+xqij9sARs8+7HLPpt6c6jN1czUvmKfYPvb3/a65ATCB3HS9ckE1 OyK8/M9wCIIIiMcX7ZKxjahvyGBNUVPJ5G8cb0qaFkpSIBwUFEcNtHciDnRTVLRovocN EU1w==
X-Received: by 10.14.173.196 with SMTP id v44mr57936811eel.29.1363683491611; Tue, 19 Mar 2013 01:58:11 -0700 (PDT)
Received: from [217.201.208.16] ([217.201.208.16]) by mx.google.com with ESMTPS id 46sm31732857eea.3.2013.03.19.01.58.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Mar 2013 01:58:09 -0700 (PDT)
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>  <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu> <51475694.85d00e0a.2654.3c21@mx.google.com> <1b952faca1b2846136ff23c6723eeb63.squirrel@calmail.berkeley.edu>  <51476DC1.5070707@eecs.berkeley.edu>  
From: Grieco 
Content-Type: multipart/alternative; boundary=Apple-Mail-2625DAEA-93C5-4EDB-BA5D-1DF6BAFDD45C
X-Mailer: iPad Mail (10B146)
In-Reply-To: 
Message-Id: <775F44DA-D912-4B36-B241-E176FBD585F1@gmail.com>
Date: Tue, 19 Mar 2013 09:58:01 +0100
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: [6tsch] R: Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 08:58:16 -0000

--Apple-Mail-2625DAEA-93C5-4EDB-BA5D-1DF6BAFDD45C
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Qin,

It does work for me: thanks for the clarification

Cheers

Alfredo

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672


On 19 Mar 2013, at 01:09, "Qin Wang"  wrote:

> Alfredo,
>=20
> I think there are two key features in your description: (1)data with high
> priority, and (2)mobility. I would like to think the two feature
> separately.
>=20
> Regarding to the high priority, I think the QoS mechanism like DSCP can
> handle it, no matter the data flow come from static node or moving node.
>=20
> Regarding to the mobility, the 6tus can support to establish tracks for
> specific purpose. Actually, the cell reservation request comes from upper
> layer, 6tus do not know the reserved cells will be used by static nodes or=

> mobile nodes. In another word, upper layer can ask 6tus to reserve some
> cells or tracks or pipes which specifically used for mobile node to send
> data as you said.
>=20
> Does it make sense?
>=20
> Qin
>=20
>=20
>=20
>>=20
>> Hi Xavi, Thomas, all
>>=20
>> The problem I am pointing out is not related only to the neighbourhood. A=
s
>> a matter of fact, a node would like its data be received to the sink and
>> not only at the next hop. If for each hop to travel, a data packet should=

>> gain a cell through some request/answer handshake this would lead to high=

>> e2e delays when the depth of the tree is high and would incur useless
>> signalling.
>>=20
>> If we think at TASA, to do an example, the schedule exactly rules the
>> story of each packet from its generating node to the sink. I was trying t=
o
>> figure out how to do the same in presence of some uncertainty on the
>> network topology.
>>=20
>> While solving this problem is something to be afforded in some scientific=

>> paper, I believe that the functionalities of 6tus and the entire
>> architecture we are envisaging should be ready to welcome this new wave o=
f
>> algorithms.
>>=20
>> In other terms, I am proposing to add a limited number of "reserved pipes=
"
>> to the sink that could be used to transport "only" urgent data from mobil=
e
>> nodes.
>>=20
>> Thomas, this could be added as general remark to the architecture or to
>> the draft you are editing. Of course, with more details, some primitive t=
o
>> the 6tus draft could be added or lead to a new draft on handling mobile
>> 6tsch nodes.
>>=20
>> Cheers :-)
>>=20
>>=20
>> --
>> Luigi Alfredo Grieco, PhD
>> Assistant Professor
>> Department of Electrical and Information Engineering
>> Politecnico di Bari
>> Via Orabona 4 - 70125 - Bari - Italy
>> +39 080 5963 911
>> telematics.poliba.it/grieco
>> Skype id: l.alfredo.grieco
>> Mobile: +39 3346715672
>>=20
>>=20
>> On 18 Mar 2013, at 20:40, Xavier Vilajosana
>>  wrote:
>>=20
>>> Hi Alfredo,
>>>=20
>>> just one point on mobility.
>>> TSCH networks may require certain time for a node to join, this depends
>>> on how the EBs are sent and what are the policies for the joining node
>>> on how to scan the different channels. Having said that, I think that
>>> the time required for a node to reserve some cells with its neighbour is=

>>> extremely less than the joining time and hence if a mobile node can join=

>>> the network for sure has time to schedule some links. So maybe this is
>>> not a big problem :-)
>>>=20
>>> cheers!
>>> Xavi
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 18/03/13 12:36, Grieco wrote:
>>>> Hi Qin, Thomas, and all
>>>>=20
>>>> Perhaps the only way to cope with (a reasonable degree of) mobility is
>>>> to hardly assign a certain number of cells at each link to be used in
>>>> case a mobile node arrives with urgent data to transmit.
>>>>=20
>>>> Obviously this would slightly decrease the overall efficiency of the
>>>> system because such "guaranteed cells" could get unused in most of
>>>> cases.
>>>>=20
>>>> If, on the other side, the mobile node is generating data which is not
>>>> that urgent, soft reservation could be used as well, which should waste=

>>>> a smaller amount of resources.
>>>>=20
>>>> In this perspective, mobile nodes could be handled using either
>>>> functions 1 or 2, depending on the degree of mobility, the priority of
>>>> the data packets generated by mobile nodes, the desired duty cycle, and=

>>>> so on.
>>>>=20
>>>> Cheers
>>>>=20
>>>> Alfredo
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Luigi Alfredo Grieco, PhD
>>>> Assistant Professor
>>>> Department of Electrical and Information Engineering
>>>> Politecnico di Bari
>>>> Via Orabona 4 - 70125 - Bari - Italy
>>>> +39 080 5963 911
>>>> telematics.poliba.it/grieco
>>>> Skype id: l.alfredo.grieco
>>>> Mobile: +39 3346715672
>>>>=20
>>>>=20
>>>> On 18 Mar 2013, at 20:20, "Qin Wang"  wrote:
>>>>=20
>>>>> Alfredo,
>>>>>=20
>>>>> I think your remark is correct. So, if there is lots of mobility, I
>>>>> would
>>>>> be prefer distributed approach, i.e. Soft Cell reservation locally +
>>>>> RPL +
>>>>> DSCP for QoS.
>>>>>=20
>>>>> Qin
>>>>>=20
>>>>>=20
>>>>>> Hi Qin,
>>>>>> Your proposal is sound.
>>>>>> Just a final remark: if my understanding is correct, the PCE should
>>>>>> build
>>>>>> a schedule that spans across multiple links from mobile node M
>>>>>> towards the
>>>>>> sink S.
>>>>>> If a M moves after the schedule has been built, some pre-assigned
>>>>>> resources along that path could get lost (which could be tolerated)
>>>>>> because of the change of the topology.
>>>>>> Is it ok ?
>>>>>> Cheers and thanks for your answer
>>>>>> Alfredo
>>>>>> -----Messaggio originale-----
>>>>>> Da: Qin Wang [mailto:qinwang@berkeley.edu]
>>>>>> Inviato: Monday, March 18, 2013 6:48 PM
>>>>>> A: Grieco
>>>>>> Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); 6tsch@ietf.org;=

>>>>>> Xavier Vilajosana
>>>>>> Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for
>>>>>> 6tus
>>>>>> Alfredo,
>>>>>> Firstly, my understanding is Hard cell reservation can only be used
>>>>>> by
>>>>>> PCE, i.e.  centralized schedule. Thus, mobile node will join in
>>>>>> network
>>>>>> based on the cells broadcast in EB. And, after its registration, PCE
>>>>>> will
>>>>>> assign some Hard cells to it.
>>>>>> secondly, regarding to high priority of the data flow from the mobile=

>>>>>> node, DSCP may help, i.e. the packets from the mobile node can
>>>>>> include
>>>>>> Priority.
>>>>>> How do you think?
>>>>>> Qin
>>>>>>> Hi Qin and all,
>>>>>>> Just to challenge the two groups of functions Qin is talking about,
>>>>>>> what if a certain number of mobile nodes need hard reservation ? In
>>>>>>> this case, mobile nodes transmit Real time data to be delivered
>>>>>>> within
>>>>>>> a given deadline but 6tus does not know in advance the rank (or the
>>>>>>> position within the topology) of such nodes.
>>>>>>> I mean that this kind of traffic has the top priority but nobody
>>>>>>> knows
>>>>>>> in advance the exact position of the nodes that is going to generate=

>>>>>>> that data.
>>>>>>> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes,
>>>>>>> how ?
>>>>>>> Thanks a lot in advance for your attention
>>>>>>> Cheers
>>>>>>> Alfredo
>>>>>>> --
>>>>>>> Luigi Alfredo Grieco, PhD
>>>>>>> Assistant Professor
>>>>>>> Department of Electrical and Information Engineering Politecnico di
>>>>>>> Bari Via Orabona 4 - 70125 - Bari - Italy
>>>>>>> +39 080 5963 911
>>>>>>> telematics.poliba.it/grieco
>>>>>>> Skype id: l.alfredo.grieco
>>>>>>> Mobile: +39 3346715672
>>>>>>> On 17 Mar 2013, at 17:47, "Qin Wang"  wrote:
>>>>>>>> I fully agree with Carsten that Simple is very important. Let's
>>>>>>>> overlapping the following three scenarios, then we will find only
>>>>>>>> two
>>>>>>>> groups of functions 6tus should provide.
>>>>>>>> (1) Hard cell reserve/remove, which supports the 1st scenario.
>>>>>>>> (2) Soft cell reserve/remove, which supports the 2nd and 3rd
>>>>>>>> scenario.
>>>>>>>> Any more?
>>>>>>>> Qin
>>>>>>>>> Sorry for the delayed response. I was stuck on the plane for too
>>>>>>>>> long
>>>>>>>>> :)
>>>>>>>>> I like the discussion that Qin is going for where we define the
>>>>>>>>> scenarios.
>>>>>>>>> At the same time, as Carsten says we need to make sure overlapping=

>>>>>>>>> scenarios of any sort are simplified and aggregated as much as
>>>>>>>>> possible.
>>>>>>>>> Let me just try to put my 2 cents in-line...
>>>>>>>>> On Mar 17, 2013, at 8:19 AM, Qin Wang 
>>>>>>>>> wrote:
>>>>>>>>>> Hi Pascal,
>>>>>>>>>> It is a very good idea to establish a bundle of cells between A
>>>>>>>>>> and
>>>>>>>>>> B by just triggering 6tus in one side. We can design for
>>>>>>>>>> different
>>>>>>>>>> scenarios.
>>>>>>>>>> (1) PCE defines the track, i.e. the multihop path, the bandwidth
>>>>>>>>>> of
>>>>>>>>>> each hop, and scheduling hard-cells to implement the multihop
>>>>>>>>>> path.
>>>>>>>>>> Assume nodeA and nodeB are one-hop neighbors along the path. In
>>>>>>>>>> this case, PCE can send Create.hardcell command to 6tus layer in
>>>>>>>>>> nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB'
>>>>>>>>>> 6tus, then the hard cell is reserved. This function is not in the=

>>>>>>>>>> current version of 6tus draft, but we can add it in the next
>>>>>>>>>> version easily.
>>>>>>>>>> (2)PCE defines the multihop path and the bandwidth of each hop,
>>>>>>>>>> but
>>>>>>>>>> not schedules the cells to meet the path bandwidth. In this case,=

>>>>>>>>>> soft cell reservation will be applied, which is always triggered
>>>>>>>>>> in
>>>>>>>>>> Transmitting side, and negotiated by the 6tus layer of both
>>>>>>>>>> sides.
>>>>>>>>>> (3)The cell reservation is triggered by upper layer, e.g. the
>>>>>>>>>> RSVP/NSIS entity in nodeA. Then soft cell reservation process in
>>>>>>>>>> 6tus layer of nodeA will by triggered, and the negotiation
>>>>>>>>>> process
>>>>>>>>>> is same as case (2).
>>>>>>>>>> In summary, by adding reserve hard cell procedure into version-00=

>>>>>>>>>> of 6tus, we can let the bundle reservation in every scenarios be
>>>>>>>>>> triggered just in one side.
>>>>>>>>>> How do you think?
>>>>>>>>> Great first start in defining the scenarios.
>>>>>>>>>> Qin
>>>>>>>>>>> Hi Qin:
>>>>>>>>>>> I think we are on the same line. The services that 6TUS proposes=

>>>>>>>>>>> do not depend on which protocol the request came in through.
>>>>>>>>>>> Since we are defining the protocol extensions, we'll make sure
>>>>>>>>>>> that the new information is directly digestible by the 6TUS
>>>>>>>>>>> layer.
>>>>>>>>>>> The protocol extensions will be separate specs, and there should=

>>>>>>>>>>> be little to no dereference between those specs and yours.
>>>>>>>>>>> What's important to me to discuss is how we establish a bundle
>>>>>>>>>>> of
>>>>>>>>>>> cells between A and B.
>>>>>>>>>>> IMHO, it would be best if that can be achieved by triggering a
>>>>>>>>>>> service in A - no need to trigger B as well.
>>>>>>>>>>> That way, the volume of exchanges between PCE and nodes can be
>>>>>>>>>>> devided by 2.
>>>>>>>>>>> This would mean that there must be an exchange between 6TUS in A=

>>>>>>>>>>> and 6TUS in B.
>>>>>>>>>>> Which  also would mean that there is a protocol part related to
>>>>>>>>>>> 6TUS=E2=80=A6
>>>>>>>>> Fully agreed that this is needed. Being an independent layer, I
>>>>>>>>> don't see why not.
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Pascal
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On
>>>>>>>>>>> Behalf Of Qin Wang
>>>>>>>>>>> Sent: vendredi 15 mars 2013 18:04
>>>>>>>>>>> To: JeongGil Ko
>>>>>>>>>>> Cc: 6tsch@ietf.org; Xavier Vilajosana
>>>>>>>>>>> Subject: Re: [6tsch] Schemes for resource allocation in the LLN
>>>>>>>>>>> for 6tus
>>>>>>>>>>> John and Xavi,
>>>>>>>>>>> I agree that understanding more about upper layer protocols like=

>>>>>>>>>>> RSVP and NSIS is very helpful for designing 6tus. But, I want to=

>>>>>>>>>>> make clearer about my understanding on the relationship between
>>>>>>>>>>> 6tus and existing reservation protocols like RSVP or NSIS.
>>>>>>>>>>> (1) When we talk about reservation in the context of 6tus, we
>>>>>>>>>>> mainly focus on  link resource (i.e. cell) reservation, which is=

>>>>>>>>>>> required/ triggered by upper layer. Even in the pure centralized=

>>>>>>>>>>> approach, it may happen to cross-layer reserve both L3 and L2
>>>>>>>>>>> resource, but you still can separate them logically.
>>>>>>>>>>> (2) The upper layer requirement to 6tus may come from PCE
>>>>>>>>>>> carried
>>>>>>>>>>> by protocol like CoAP, may come from the RSVP/NSIS entity inside=

>>>>>>>>>>> nodes.
>>>>>>>>>>> Thus, for 6tus, the question is what kind of function and
>>>>>>>>>>> interface should be provided to support the upper layer, instead=

>>>>>>>>>>> of which upper layer protocol should be used.
>>>>>>>>>>> How do you think?
>>>>>>>>> I agree with your arguments that the important thing is defining
>>>>>>>>> the
>>>>>>>>> functionalities. It seems like some of these efforts are on the
>>>>>>>>> way
>>>>>>>>> in the later emails. Me bringing in the term "RSVP" was not that I=

>>>>>>>>> wanted to go an use RSVP in the way it is, but bring the
>>>>>>>>> (modified/customized) concept in for use in 6tus. As to what I
>>>>>>>>> read
>>>>>>>>> there may have been a misunderstanding between us but we are on
>>>>>>>>> the
>>>>>>>>> same line.
>>>>>>>>> Thanks!
>>>>>>>>> -John
>>>>>>>>>>> Qin
>>>>>>>> _______________________________________________
>>>>>>>> 6tsch mailing list
>>>>>>>> 6tsch@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>=20
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>=20
>=20

--Apple-Mail-2625DAEA-93C5-4EDB-BA5D-1DF6BAFDD45C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi Qin,

It do=
es work for me: thanks for the clarification

Cheers=


Alfredo

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
<=
div style=3D"font-family: Helvetica; font-size: medium; -webkit-tap-highligh=
t-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(17=
5, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0=
.230469); -webkit-text-size-adjust: auto; ">+39 080 5963 911
Skype id: l.alfredo.grieco
Mobile: +39 3346715672

<=
/div>

On 19 Mar 2013, at 01:09, "Qin Wang" <qinwang@berkeley.edu> wrote:

Alfredo,

I thi=
nk there are two key features in your description: (1)data with high<=
br>priority, and (2)mobility. I would like to think the two feature
separately.

Regarding to the h=
igh priority, I think the QoS mechanism like DSCP can
handle=
 it, no matter the data flow come from static node or moving node.
Regarding to the mobility, the 6tus can support to e=
stablish tracks for
specific purpose. Actually, the cell res=
ervation request comes from upper
layer, 6tus do not know th=
e reserved cells will be used by static nodes or
mobile node=
s. In another word, upper layer can ask 6tus to reserve some
cells or tracks or pipes which specifically used for mobile node to send
data as you said.

Does it mak=
e sense?

Qin




Hi Xavi, Thomas, all

The problem I am pointing out is not related only to t=
he neighbourhood. As
=
a matter of fact, a node would like its data be received to the sink and
not only at the next hop=
. If for each hop to travel, a data packet should
gain a cell through some request/answer handsha=
ke this would lead to high
=
e2e delays when the depth of the tree is high and would incur useless<=
/span>
signalling.

If we think at TASA, to do an example, the schedul=
e exactly rules the
s=
tory of each packet from its generating node to the sink. I was trying to
figure out how to do th=
e same in presence of some uncertainty on the
network topology.

While solving this problem is something to be afforded in some scientific<=
/span>
paper, I believe that=
 the functionalities of 6tus and the entire
architecture we are envisaging should be ready to wel=
come this new wave of
algorithms.
<=
br>
In other terms, I am proposi=
ng to add a limited number of "reserved pipes"
to the sink that could be used to transport "only"=
 urgent data from mobile
nodes.
Thomas, this could be added as=
 general remark to the architecture or to
the draft you are editing. Of course, with more details=
, some primitive to
t=
he 6tus draft could be added or lead to a new draft on handling mobile
6tsch nodes.

Cheers :-)

<=
br>
--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information E=
ngineering
Politecnic=
o di Bari
Via Orabona=
 4 - 70125 - Bari - Italy
<=
span>+39 080 5963 911
telematics.poliba.it/grieco<=
/a>
Skype id: l.alfre=
do.grieco
Mobile: +39=
 3346715672

On 18 Mar 2013, at 20:40, Xavier Vilajosana
<xvilajosana@eecs.berkeley.edu> wrote:

<=
blockquote type=3D"cite">
Hi Alfredo,<=
br>

just one point on mobility.
=
TSCH networks may require certain time for a node to join, this depends
on how the EBs are sent and what are the policies for the joini=
ng node
on how to scan the different channels. Having said=
 that, I think that
the time required for a node to reserv=
e some cells with its neighbour is
extremely less than the=
 joining time and hence if a mobile node can join
the netw=
ork for sure has time to schedule some links. So maybe this is
<=
span>not a big problem :-)

cheers!
Xavi




On 18/03/13 12:36, Grieco wrote:<=
br>
Hi Qin, Thomas, and all

Perhaps the only way to cope with (a reasonable degr=
ee of) mobility is
=
to hardly assign a certain number of cells at each link to be used in=

case a mobile node arrive=
s with urgent data to transmit.

Obvio=
usly this would slightly decrease the overall efficiency of the
system because such "guaranteed=
 cells" could get unused in most of
cases.
<=
span>
If, on the ot=
her side, the mobile node is generating data which is not
that urgent, soft reservation could b=
e used as well, which should waste
a smaller amount of resources.

In this perspective, mobile nodes could be handled using either
functions 1 or 2, dep=
ending on the degree of mobility, the priority of
<=
blockquote type=3D"cite">the data packets generated by mobile nodes, t=
he desired duty cycle, and
=

so on.

Cheers

=

Alfredo

<=
br>

=


--
Lui=
gi Alfredo Grieco, PhD
Assistant Professor
<=
span>Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy<=
/span>
<=
blockquote type=3D"cite">
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
=

Mobile: +39 3346715672=


<=
/blockquote>

On 18 Mar 2013, at 20:20, "Qin Wang" <qinwang@berkeley.edu> wrote:

Alfredo,
<=
/blockquote>

I think your remark is correct. So, if there is lots of mobilit=
y, I
would
be prefer distributed app=
roach, i.e. Soft Cell reservation locally +
RPL +=

DSCP for QoS.
=


Qin

=


<=
span>Hi Qin,
<=
/blockquote>
Your p=
roposal is sound.
Just a final remark: if my understanding is correct, the PCE should<=
br>
build
a schedule that spans across multiple=
 links from mobile node M
<=
/blockquote>
towards the
sink S.
If a M=
 moves after the schedule has been built, some pre-assigned
resources along that path could get l=
ost (which could be tolerated)
because of the change of the topology.
<=
/blockquote>
Is it ok ?
Cheers and thanks for your answer
Alfredo
=

-----Messaggio originale-----
=

Da: Qin Wang [mailto:qinwang@berkeley.edu]
Inviato: Monday, March 18, 2013 6:48 P=
M
A: Grieco
Cc: Qin Wang; JeongGil=
 Ko; Pascal Thubert (pthubert); 6tsch@ietf=
.org;
Xavier V=
ilajosana
Oggetto=
: Re: [6tsch] Schemes for resource allocation in the LLN for
6tus
=

Alfredo,
Firstly, my understanding is Hard cell reservation c=
an only be used
b=
y
PCE, i.e.  =
;centralized schedule. Thus, mobile node will join in
network
based on the cells broadcast in EB. And, after i=
ts registration, PCE
will
assign s=
ome Hard cells to it.
<=
span>secondly, regarding to high priority of the data flow from the mobile
=

node, DSCP may hel=
p, i.e. the packets from the mobile node can
include
Priority.
How do you think?
Qin
Hi Qin and all,
Just to chal=
lenge the two groups of functions Qin is talking about,
what if a certain number of mobile nodes need hard reservation ? In=

this case, mobile nodes transmit Real time data to be delivered=

=

within
a given deadline but 6tu=
s does not know in advance the rank (or the
position wi=
thin the topology) of such nodes.
I mean that this kin=
d of traffic has the top priority but nobody
knows
in advance the exact position of the nodes that is going to gen=
erate
that data.
<=
/blockquote>
Do we need a fu=
rther case ? Or we can leverage on 1 or 2 ? If yes,
<=
/blockquote>
how=
 ?
Thanks a lot in advance for your attention
Cheers
Alfredo
--
Luigi Alfredo Grieco, PhD
<=
/blockquote>
Assistant Profe=
ssor
Department of Electrical and Information Engineer=
ing Politecnico di
Bari Via Orabona 4 - 70125 - Bari - I=
taly
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
=

Mobile: +39 33=
46715672
<=
blockquote type=3D"cite">On 17 Mar 2013, at 17:47, "Qin Wang" <qinwang@berkeley.edu> wrote:
I fully agree with Carsten that S=
imple is very important. Let's
overlapping the following three scenarios, then we will find on=
ly
two
groups of functions 6tu=
s should provide.
(1) Hard cell reserve/remove, which supports the 1st scenario.
=

(2) Soft cell reserve/rem=
ove, which supports the 2nd and 3rd
scenario.
Any more?
=

Qin
Sorry for the delayed response. I was stuck on the pl=
ane for too
=

long
:)
I like the discussion that Qin is going for where we define the=

=

scenarios.
=

At the same time=
, as Carsten says we need to make sure overlapping
=

s=
cenarios of any sort are simplified and aggregated as much as
=

possible.
Let me just try to put my 2 cents in-=
line...
=

On Mar 17, 2013, at 8:19 AM, Qin Wang <qinwang@berkeley.edu>
wrote:
Hi Pascal,<=
/span>
<=
/blockquote>
It is a very g=
ood idea to establish a bundle of cells between A
<=
/blockquote>
and
B by just triggering 6tus in one side. We can de=
sign for
diffe=
rent
scenarios.<=
/span>
<=
/blockquote>
(1) PCE defin=
es the track, i.e. the multihop path, the bandwidth
<=
/blockquote>
of
each hop, and scheduling hard-cells to implemen=
t the multihop
path.
Assume node=
A and nodeB are one-hop neighbors along the path. In
=

this case, PCE can send Create.hardce=
ll command to 6tus layer in
nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB'<=
/span>
<=
/blockquote>
6tus, then th=
e hard cell is reserved. This function is not in the
=

current version of 6tus draft, but we=
 can add it in the next
<=
blockquote type=3D"cite">
version easily.
=

(2)PCE defines the multihop path and the bandwidth of each hop,=

=

but
not schedules the cel=
ls to meet the path bandwidth. In this case,
=

soft cell reservation will be applied, which=
 is always triggered
=

in
Tra=
nsmitting side, and negotiated by the 6tus layer of both
sides.
<=
blockquote type=3D"cite">
(3)The cell reservation is triggered by upp=
er layer, e.g. the
=
RSVP/NSIS entity in nodeA. Then soft cell reservation process in
=

6tus layer of node=
A will by triggered, and the negotiation
process
is same as case (2).
<=
blockquote type=3D"cite">In summary, by adding reserve hard cell proce=
dure into version-00
=

of 6tus, we can let the bundle reservation in every scenarios be
=

triggered just i=
n one side.
H=
ow do you think?
Great first start in d=
efining the scenarios.
Qin=

=

Hi Qin:
I think we are on the same li=
ne. The services that 6TUS proposes
=

do not depend o=
n which protocol the request came in through.
Since=
 we are defining the protocol extensions, we'll make sure
=

that the new information is directly digestible by the 6TUS
layer.
The protocol extensions will be=
 separate specs, and there should
=

be little to no d=
ereference between those specs and yours.
What's impo=
rtant to me to discuss is how we establish a bundle
<=
/blockquote>
of
<=
blockquote type=3D"cite">cells between A and B.
IMHO, it would be best if that can be achieved by triggering a
service in A - no need to trigger B as well.
=

That way, the volume of exchanges between PCE and nodes can be
devided by 2.
=

This would mean that th=
ere must be an exchange between 6TUS in A
and 6TUS in=
 B.
Which  also would mean that there is a pr=
otocol part related to
6TUS=E2=80=A6
<=
/blockquote>
Fully agreed that this is needed. Being=
 an independent layer, I
don't see why not.
Cheers,
Pascal
-----Original Messag=
e-----
<=
blockquote type=3D"cite">
From: 6tsch-bounces@ietf.org [m=
ailto:6tsch-bounces@ietf.org] On
<=
/blockquote>
Behalf Of Qin=
 Wang
=

Sent: vendredi 15 mars 2013 18:04
=

To: JeongGil Ko
Cc: 6tsch@ietf.org; Xavier Vilajosana
<=
span>Subject: Re: [6tsch] Schemes for resource allocation in the LLN<=
br>
for 6tus
John and Xavi,
=

I agree that understanding more about upper layer protocols like=

=

RSVP and NSIS is very helpful for designing 6tus.=
 But, I want to
make clearer about my understanding o=
n the relationship between
=

6tus and existing reser=
vation protocols like RSVP or NSIS.
=

(1) When we ta=
lk about reservation in the context of 6tus, we
mai=
nly focus on  link resource (i.e. cell) reservation, which is
required/ triggered by upper layer. Even in the pure centralize=
d
approach, it may happen to cross-layer reserve b=
oth L3 and L2
=

resource, but you still can separate t=
hem logically.
(2) The upper layer requirement to 6t=
us may come from PCE
carried
<=
span>by protocol like CoAP, may come from the RSVP/NSIS entity inside=

nodes.
Thus, for 6tus, the question is=
 what kind of function and
=

interface should be pro=
vided to support the upper layer, instead
of which up=
per layer protocol should be used.
<=
blockquote type=3D"cite">
How do you thin=
k?
I agree with your argum=
ents that the important thing is defining
the<=
br>
functionalities. It seems like some of these efforts are on the=

=

way
in the later emails. Me=
 bringing in the term "RSVP" was not that I
wanted to g=
o an use RSVP in the way it is, but bring the
(modif=
ied/customized) concept in for use in 6tus. As to what I
<=
span>read
=

there may have been a misunderstanding bet=
ween us but we are on
the
sam=
e line.
=

Thanks!
=

-John=

Qin<=
br>
_______________________________________________
6tsch mailing list
=

6tsch@ietf.org
<=
/blockquote>
https://w=
ww.ietf.org/mailman/listinfo/6tsch
<=
/blockquote>

______________________________________=
_________
6tsch maili=
ng list
6tsch@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/6tsch


=

--Apple-Mail-2625DAEA-93C5-4EDB-BA5D-1DF6BAFDD45C--

From twatteyne@gmail.com  Tue Mar 19 09:57:30 2013
Return-Path: 
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 4C1AD21F8F68 for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 09:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.309
X-Spam-Level: 
X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1]
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 cAH8XDjDW21P for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 09:57:28 -0700 (PDT)
Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id EF57F21F85DB for <6tsch@ietf.org>; Tue, 19 Mar 2013 09:57:27 -0700 (PDT)
Received: by mail-pb0-f48.google.com with SMTP id wy12so586131pbc.7 for <6tsch@ietf.org>; Tue, 19 Mar 2013 09:57:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Ls7FHhR/P++JcG7b/KO6rJkA4JBFuvfIQAhQacVCxaQ=; b=yXTsIAJh7T+B1lzOEUz9nuq8edlchSGZsXWMhLep+kVmBOUJ6u419YffYkIsIxGTgY 4PmbIyt6wk7nT0B9WffiXufC2BfeGFG8ONXHcgdx0RMKKLVUasiin47f4nrMve1taatK vroZeb/2c4ArJQCM29jmmrz3KFwhLcMvv7LG5+3vEd8PJi+Au+EzMhJnaXchAAm1GXtv CCAF8Vh4w6cbpgbaCBH9CuZox6WOWvu8T9DXWPQsM4m8cResKkdEugp8Jd+fo21WyIzp 5tUG7N2rfG9IawQwl1/PS2zJouihk61PnDXbItUTSgncCziXBWCZz7pCsHhYpnDQplAY UjTg==
MIME-Version: 1.0
X-Received: by 10.66.122.162 with SMTP id lt2mr4322331pab.168.1363712247712; Tue, 19 Mar 2013 09:57:27 -0700 (PDT)
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Tue, 19 Mar 2013 09:57:27 -0700 (PDT)
In-Reply-To: <775F44DA-D912-4B36-B241-E176FBD585F1@gmail.com>
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>  <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu> <51475694.85d00e0a.2654.3c21@mx.google.com> <1b952faca1b2846136ff23c6723eeb63.squirrel@calmail.berkeley.edu>  <51476DC1.5070707@eecs.berkeley.edu>  <775F44DA-D912-4B36-B241-E176FBD585F1@gmail.com>
Date: Tue, 19 Mar 2013 09:57:27 -0700
X-Google-Sender-Auth: _6jwNEG0FplPHZsy-6kIc-AsN2I
Message-ID: 
From: Thomas Watteyne 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7bf0e8a419d26f04d84a0077
Subject: Re: [6tsch] R: Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 16:57:30 -0000

--047d7bf0e8a419d26f04d84a0077
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Alfredo,

This is an interesting use case you bring up. Do you have a specific use
case/problem you are trying to solve?

I agree with Qin that it would be great if this were a schedule-only
decision, i.e. we change as little as possible in the mechanism (e.g.
6tus), but rather have the scheduling entity build an (otherwise normal)
schedule which allows for some motes to roam around.

Thomas

On Tue, Mar 19, 2013 at 1:58 AM, Grieco  wrote:

> Hi Qin,
>
> It does work for me: thanks for the clarification
>
> Cheers
>
> Alfredo
>
> --
> Luigi Alfredo Grieco, PhD
> Assistant Professor
> Department of Electrical and Information Engineering
> Politecnico di Bari
> Via Orabona 4 - 70125 - Bari - Italy
> +39 080 5963 911
> telematics.poliba.it/grieco
> Skype id: l.alfredo.grieco
> Mobile: +39 3346715672
>
>
> On 19 Mar 2013, at 01:09, "Qin Wang"  wrote:
>
> Alfredo,
>
> I think there are two key features in your description: (1)data with high
> priority, and (2)mobility. I would like to think the two feature
> separately.
>
> Regarding to the high priority, I think the QoS mechanism like DSCP can
> handle it, no matter the data flow come from static node or moving node.
>
> Regarding to the mobility, the 6tus can support to establish tracks for
> specific purpose. Actually, the cell reservation request comes from upper
> layer, 6tus do not know the reserved cells will be used by static nodes o=
r
> mobile nodes. In another word, upper layer can ask 6tus to reserve some
> cells or tracks or pipes which specifically used for mobile node to send
> data as you said.
>
> Does it make sense?
>
> Qin
>
>
>
>
> Hi Xavi, Thomas, all
>
>
> The problem I am pointing out is not related only to the neighbourhood. A=
s
>
> a matter of fact, a node would like its data be received to the sink and
>
> not only at the next hop. If for each hop to travel, a data packet should
>
> gain a cell through some request/answer handshake this would lead to high
>
> e2e delays when the depth of the tree is high and would incur useless
>
> signalling.
>
>
> If we think at TASA, to do an example, the schedule exactly rules the
>
> story of each packet from its generating node to the sink. I was trying t=
o
>
> figure out how to do the same in presence of some uncertainty on the
>
> network topology.
>
>
> While solving this problem is something to be afforded in some scientific
>
> paper, I believe that the functionalities of 6tus and the entire
>
> architecture we are envisaging should be ready to welcome this new wave o=
f
>
> algorithms.
>
>
> In other terms, I am proposing to add a limited number of "reserved pipes=
"
>
> to the sink that could be used to transport "only" urgent data from mobil=
e
>
> nodes.
>
>
> Thomas, this could be added as general remark to the architecture or to
>
> the draft you are editing. Of course, with more details, some primitive t=
o
>
> the 6tus draft could be added or lead to a new draft on handling mobile
>
> 6tsch nodes.
>
>
> Cheers :-)
>
>
>
> --
>
> Luigi Alfredo Grieco, PhD
>
> Assistant Professor
>
> Department of Electrical and Information Engineering
>
> Politecnico di Bari
>
> Via Orabona 4 - 70125 - Bari - Italy
>
> +39 080 5963 911
>
> telematics.poliba.it/grieco
>
> Skype id: l.alfredo.grieco
>
> Mobile: +39 3346715672
>
>
>
> On 18 Mar 2013, at 20:40, Xavier Vilajosana
>
>  wrote:
>
>
> Hi Alfredo,
>
>
> just one point on mobility.
>
> TSCH networks may require certain time for a node to join, this depends
>
> on how the EBs are sent and what are the policies for the joining node
>
> on how to scan the different channels. Having said that, I think that
>
> the time required for a node to reserve some cells with its neighbour is
>
> extremely less than the joining time and hence if a mobile node can join
>
> the network for sure has time to schedule some links. So maybe this is
>
> not a big problem :-)
>
>
> cheers!
>
> Xavi
>
>
>
>
>
> On 18/03/13 12:36, Grieco wrote:
>
> Hi Qin, Thomas, and all
>
>
> Perhaps the only way to cope with (a reasonable degree of) mobility is
>
> to hardly assign a certain number of cells at each link to be used in
>
> case a mobile node arrives with urgent data to transmit.
>
>
> Obviously this would slightly decrease the overall efficiency of the
>
> system because such "guaranteed cells" could get unused in most of
>
> cases.
>
>
> If, on the other side, the mobile node is generating data which is not
>
> that urgent, soft reservation could be used as well, which should waste
>
> a smaller amount of resources.
>
>
> In this perspective, mobile nodes could be handled using either
>
> functions 1 or 2, depending on the degree of mobility, the priority of
>
> the data packets generated by mobile nodes, the desired duty cycle, and
>
> so on.
>
>
> Cheers
>
>
> Alfredo
>
>
>
>
>
> --
>
> Luigi Alfredo Grieco, PhD
>
> Assistant Professor
>
> Department of Electrical and Information Engineering
>
> Politecnico di Bari
>
> Via Orabona 4 - 70125 - Bari - Italy
>
> +39 080 5963 911
>
> telematics.poliba.it/grieco
>
> Skype id: l.alfredo.grieco
>
> Mobile: +39 3346715672
>
>
>
> On 18 Mar 2013, at 20:20, "Qin Wang"  wrote:
>
>
> Alfredo,
>
>
> I think your remark is correct. So, if there is lots of mobility, I
>
> would
>
> be prefer distributed approach, i.e. Soft Cell reservation locally +
>
> RPL +
>
> DSCP for QoS.
>
>
> Qin
>
>
>
> Hi Qin,
>
> Your proposal is sound.
>
> Just a final remark: if my understanding is correct, the PCE should
>
> build
>
> a schedule that spans across multiple links from mobile node M
>
> towards the
>
> sink S.
>
> If a M moves after the schedule has been built, some pre-assigned
>
> resources along that path could get lost (which could be tolerated)
>
> because of the change of the topology.
>
> Is it ok ?
>
> Cheers and thanks for your answer
>
> Alfredo
>
> -----Messaggio originale-----
>
> Da: Qin Wang [mailto:qinwang@berkeley.edu ]
>
> Inviato: Monday, March 18, 2013 6:48 PM
>
> A: Grieco
>
> Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); 6tsch@ietf.org;
>
> Xavier Vilajosana
>
> Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for
>
> 6tus
>
> Alfredo,
>
> Firstly, my understanding is Hard cell reservation can only be used
>
> by
>
> PCE, i.e.  centralized schedule. Thus, mobile node will join in
>
> network
>
> based on the cells broadcast in EB. And, after its registration, PCE
>
> will
>
> assign some Hard cells to it.
>
> secondly, regarding to high priority of the data flow from the mobile
>
> node, DSCP may help, i.e. the packets from the mobile node can
>
> include
>
> Priority.
>
> How do you think?
>
> Qin
>
> Hi Qin and all,
>
> Just to challenge the two groups of functions Qin is talking about,
>
> what if a certain number of mobile nodes need hard reservation ? In
>
> this case, mobile nodes transmit Real time data to be delivered
>
> within
>
> a given deadline but 6tus does not know in advance the rank (or the
>
> position within the topology) of such nodes.
>
> I mean that this kind of traffic has the top priority but nobody
>
> knows
>
> in advance the exact position of the nodes that is going to generate
>
> that data.
>
> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes,
>
> how ?
>
> Thanks a lot in advance for your attention
>
> Cheers
>
> Alfredo
>
> --
>
> Luigi Alfredo Grieco, PhD
>
> Assistant Professor
>
> Department of Electrical and Information Engineering Politecnico di
>
> Bari Via Orabona 4 - 70125 - Bari - Italy
>
> +39 080 5963 911
>
> telematics.poliba.it/grieco
>
> Skype id: l.alfredo.grieco
>
> Mobile: +39 3346715672
>
> On 17 Mar 2013, at 17:47, "Qin Wang"  wrote:
>
> I fully agree with Carsten that Simple is very important. Let's
>
> overlapping the following three scenarios, then we will find only
>
> two
>
> groups of functions 6tus should provide.
>
> (1) Hard cell reserve/remove, which supports the 1st scenario.
>
> (2) Soft cell reserve/remove, which supports the 2nd and 3rd
>
> scenario.
>
> Any more?
>
> Qin
>
> Sorry for the delayed response. I was stuck on the plane for too
>
> long
>
> :)
>
> I like the discussion that Qin is going for where we define the
>
> scenarios.
>
> At the same time, as Carsten says we need to make sure overlapping
>
> scenarios of any sort are simplified and aggregated as much as
>
> possible.
>
> Let me just try to put my 2 cents in-line...
>
> On Mar 17, 2013, at 8:19 AM, Qin Wang 
>
> wrote:
>
> Hi Pascal,
>
> It is a very good idea to establish a bundle of cells between A
>
> and
>
> B by just triggering 6tus in one side. We can design for
>
> different
>
> scenarios.
>
> (1) PCE defines the track, i.e. the multihop path, the bandwidth
>
> of
>
> each hop, and scheduling hard-cells to implement the multihop
>
> path.
>
> Assume nodeA and nodeB are one-hop neighbors along the path. In
>
> this case, PCE can send Create.hardcell command to 6tus layer in
>
> nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB'
>
> 6tus, then the hard cell is reserved. This function is not in the
>
> current version of 6tus draft, but we can add it in the next
>
> version easily.
>
> (2)PCE defines the multihop path and the bandwidth of each hop,
>
> but
>
> not schedules the cells to meet the path bandwidth. In this case,
>
> soft cell reservation will be applied, which is always triggered
>
> in
>
> Transmitting side, and negotiated by the 6tus layer of both
>
> sides.
>
> (3)The cell reservation is triggered by upper layer, e.g. the
>
> RSVP/NSIS entity in nodeA. Then soft cell reservation process in
>
> 6tus layer of nodeA will by triggered, and the negotiation
>
> process
>
> is same as case (2).
>
> In summary, by adding reserve hard cell procedure into version-00
>
> of 6tus, we can let the bundle reservation in every scenarios be
>
> triggered just in one side.
>
> How do you think?
>
> Great first start in defining the scenarios.
>
> Qin
>
> Hi Qin:
>
> I think we are on the same line. The services that 6TUS proposes
>
> do not depend on which protocol the request came in through.
>
> Since we are defining the protocol extensions, we'll make sure
>
> that the new information is directly digestible by the 6TUS
>
> layer.
>
> The protocol extensions will be separate specs, and there should
>
> be little to no dereference between those specs and yours.
>
> What's important to me to discuss is how we establish a bundle
>
> of
>
> cells between A and B.
>
> IMHO, it would be best if that can be achieved by triggering a
>
> service in A - no need to trigger B as well.
>
> That way, the volume of exchanges between PCE and nodes can be
>
> devided by 2.
>
> This would mean that there must be an exchange between 6TUS in A
>
> and 6TUS in B.
>
> Which  also would mean that there is a protocol part related to
>
> 6TUS=85
>
> Fully agreed that this is needed. Being an independent layer, I
>
> don't see why not.
>
> Cheers,
>
> Pascal
>
> -----Original Message-----
>
> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org<6tsch-bounces=
@ietf.org>]
> On
>
> Behalf Of Qin Wang
>
> Sent: vendredi 15 mars 2013 18:04
>
> To: JeongGil Ko
>
> Cc: 6tsch@ietf.org; Xavier Vilajosana
>
> Subject: Re: [6tsch] Schemes for resource allocation in the LLN
>
> for 6tus
>
> John and Xavi,
>
> I agree that understanding more about upper layer protocols like
>
> RSVP and NSIS is very helpful for designing 6tus. But, I want to
>
> make clearer about my understanding on the relationship between
>
> 6tus and existing reservation protocols like RSVP or NSIS.
>
> (1) When we talk about reservation in the context of 6tus, we
>
> mainly focus on  link resource (i.e. cell) reservation, which is
>
> required/ triggered by upper layer. Even in the pure centralized
>
> approach, it may happen to cross-layer reserve both L3 and L2
>
> resource, but you still can separate them logically.
>
> (2) The upper layer requirement to 6tus may come from PCE
>
> carried
>
> by protocol like CoAP, may come from the RSVP/NSIS entity inside
>
> nodes.
>
> Thus, for 6tus, the question is what kind of function and
>
> interface should be provided to support the upper layer, instead
>
> of which upper layer protocol should be used.
>
> How do you think?
>
> I agree with your arguments that the important thing is defining
>
> the
>
> functionalities. It seems like some of these efforts are on the
>
> way
>
> in the later emails. Me bringing in the term "RSVP" was not that I
>
> wanted to go an use RSVP in the way it is, but bring the
>
> (modified/customized) concept in for use in 6tus. As to what I
>
> read
>
> there may have been a misunderstanding between us but we are on
>
> the
>
> same line.
>
> Thanks!
>
> -John
>
> Qin
>
> _______________________________________________
>
> 6tsch mailing list
>
> 6tsch@ietf.org
>
> https://www.ietf.org/mailman/listinfo/6tsch
>
>
> _______________________________________________
>
> 6tsch mailing list
>
> 6tsch@ietf.org
>
> https://www.ietf.org/mailman/listinfo/6tsch
>
>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

--047d7bf0e8a419d26f04d84a0077
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Alfredo,


This is an interesting use =
case you bring up. Do you have a specific use case/problem you are trying t=
o solve?




I agree with Qin that it would be great if this were a schedule-only decisi=
on, i.e. we change as little as possible in the mechanism (e.g. 6tus), but =
rather have the scheduling entity build an (otherwise normal) schedule whic=
h allows for some motes to roam around.




Thomas

On Tue, Mar 19, 2013 at 1:58 AM,=
 Grieco <alfredo.grieco@gmail.com> wrote:


Hi Qin,

It does work for me=
: thanks for the clarification

C=
heers

Alfredo

--

Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering

Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy


Skype id: l.alf=
redo.grieco





On 19 Mar 2013, at 01:09, "Qin Wang" <qinwang@berkeley.edu> wrote:
Alfredo,
<=
/span>

I think there are two key features in your description: (1)data with =
high
priority, and (2)mobility. I would like to think the t=
wo feature
separately.

Reg=
arding to the high priority, I think the QoS mechanism like DSCP can=


handle it, no matter the data flow come from static node or moving no=
de.

Regarding to the mobility, the 6tus ca=
n support to establish tracks for
specific purpose. Actuall=
y, the cell reservation request comes from upper

layer, 6tus do not know the reserved cells will be used by static nod=
es or
mobile nodes. In another word, upper layer can ask 6t=
us to reserve some
cells or tracks or pipes which specifica=
lly used for mobile node to send

data as you said.

Does it make sense=
?

Qin






Hi Xavi, Thomas, all

The problem I am pointing out is not related only to the ne=
ighbourhood. As


a matter of fact, a node would=
 like its data be received to the sink and
not only at the next hop. If for each hop to travel,=
 a data packet should


gain a cell through some reque=
st/answer handshake this would lead to high
e2e delays when the depth of the tree is high and w=
ould incur useless


signalling.

If we think at TASA, to do an example, the schedule exact=
ly rules the


story of each packet from its =
generating node to the sink. I was trying to
figure out how to do the same in presence of some =
uncertainty on the


network topology.

While solving this problem is something to be affor=
ded in some scientific


paper, I believe that the func=
tionalities of 6tus and the entire
architecture we are envisaging should be ready to welcome t=
his new wave of


algorithms.

In other terms, I am proposing to add a limited number of=
 "reserved pipes"


to the sink that could be used=
 to transport "only" urgent data from mobile
nodes.


Thomas, this =
could be added as general remark to the architecture or to
the draft you are editing. Of course=
, with more details, some primitive to


the 6tus draft could be added =
or lead to a new draft on handling mobile
6tsch nodes.


Cheers :-)



--
Luigi Alfre=
do Grieco, PhD
Assis=
tant Professor
Depar=
tment of Electrical and Information Engineering


Politecnico di Bari
=

Via Orabona 4 - 70125 - Bari -=
 Italy
+39 0=
80 5963 911


telematics.poliba.it/grieco
Skype id: l.alfredo.grieco


Mobile: +39 3346715672



On 18 Mar 201=
3, at 20:40, Xavier Vilajosana
<xvilajosana@eecs.berkeley.edu> wrote:



Hi Alfredo,
<=
/blockquote>



just one point on mobility.
TSCH networks may r=
equire certain time for a node to join, this depends


on how the EBs are sent and what are the policies for the joining =
node

on how to scan the different channels. Having said that, I think that=

the time required for a node to reserve some cells with=
 its neighbour is


extremely less than the joining time and hence if a mobile node ca=
n join

the network for sure has time to schedule some links. So maybe this i=
s
not a big problem :-)



cheers!

Xavi


<=
/blockquote>




On 18/03/13 12:36, Grieco wrote:
=

Hi Qin, Thomas, and all



Perhaps=
 the only way to cope with (a reasonable degree of) mobility is


to hardly assign a certain =
number of cells at each link to be used in


case a mobile node arrives with urgent data to transm=
it.



Obviously this would slightly dec=
rease the overall efficiency of the


system because such "g=
uaranteed cells" could get unused in most of


cases.



If, on the other side, the =
mobile node is generating data which is not


that urgent, soft reservation could be used as well, =
which should waste


a smaller amount =
of resources.



In this perspective, mobile=
 nodes could be handled using either


functions 1 or 2, depending on the degree of mobility, the priorit=
y of


the data packets =
generated by mobile nodes, the desired duty cycle, and


so on.
=




Cheers
=




Alfredo




=





--
Luigi Alfredo Grieco, PhD


Assistant Professor

Department of Electrical and Information Engineering
Politecnico di Bari


Via Orabona 4 - 70125 - Bari - Italy


+39 080 5963 911


telematics.poliba.it/grieco

Skype id: l.alfredo.grieco
Mobile: +39 3346715672



=



On 18 Mar =
2013, at 20:20, "Qin Wang" <qinwang@berkeley.edu> wrote:



=



Alfredo,

<=
/blockquote>

I=
 think your remark is correct. So, if there is lots of mobility, I


w=
ould


be prefer distributed approach, i.e. Soft Cell reservation locally=
 +


RPL +

DSCP for QoS.



Qin
=




=



Hi Qin,


Your proposal is sound.


Just a final remark: if my understanding is correc=
t, the PCE should


build


a schedule that spans across multiple links from m=
obile node M


towards the


sink S.


If a M moves after the schedule has been built, so=
me pre-assigned


resources along that pat=
h could get lost (which could be tolerated)


because of the change of=
 the topology.


Is it ok ?


Cheers and thanks for your answer


Alfredo


-----Messaggio originale-----<=
br>


Da: Qin Wang [mailto:qinwang@berkeley.edu]<=
br>

Inviato: Monday, March 1=
8, 2013 6:48 PM


A: Grieco


Cc: Qin Wang; JeongGil Ko; Pascal Thu=
bert (pthubert); 6tsch@=
ietf.org;


Xavier Vilajosana=



Oggetto: Re: [6tsch] Schemes for reso=
urce allocation in the LLN for


6tus


Alfredo,


Firstly, my understanding is Hard cell reservation can only be =
used


by


PCE, i.e. =A0centralized schedule. Thus, mobile no=
de will join in


network


based on the cells broadcast in EB. A=
nd, after its registration, PCE


will


assign some Hard cells to it.


secondly, regarding to high priority of the data f=
low from the mobile


node, DSCP may help, i.e=
. the packets from the mobile node can


include


Priority.


How do you think?


Qin


Hi Qin and all,


Just to challenge the two groups of f=
unctions Qin is talking about,



what if a certain number of mobile nodes need hard reservation ? In
<=
/blockquote>


this case, mobile nodes transmit Real time data to be delivered


within


a given deadline but 6tus does not know in advance=
 the rank (or the



position within the topology) of such nodes.
<=
/blockquote>


I mean that this =
kind of traffic has the top priority but nobody


knows


in advance the=
 exact position of the nodes that is going to generate


that data.<=
/span>



Do we need a further case ? Or we can leverage on 1 or 2 ? If yes,


how ?


Thanks a lot in advance for your attention
=



Cheers<=
br>


Alfredo


--


Luigi Alfredo Grieco, PhD
<=
/blockquote>

Assistant Professor



Department of Electrical and Information Engineering Politecnico di
<=
/blockquote>


Bari Via Orabona 4 - 70125 - Bari - Italy
<=
/blockquote>


+39 08=
0 5963 911



tele=
matics.poliba.it/grieco


Skype id: l.alfredo.grieco
=



Mobile: +39 =
3346715672



On 17 Mar 2013, at 17:47, "Qin Wang" <qinwang@berkeley.edu> wrote:=



I fully agree with Carst=
en that Simple is very important. Let's




overlapping the following three scenarios, =
then we will find only


two


groups of f=
unctions 6tus should provide.




(1) Hard cell reserve/remove, which support=
s the 1st scenario.


(2) Soft cell =
reserve/remove, which supports the 2nd and 3rd



scenario.


Any more?<=
br>


Qin
=



Sorry for the delayed response. I was=
 stuck on the plane for too




long


:)




I like the discussion that Qin is going for=
 where we define the


scenarios.




At the same time,=
 as Carsten says we need to make sure overlapping


scenarios of any sort are simplified and aggregated as much as




possible.


Let me just try to put my 2 cents in-=
line...




On Mar 17, 2013, at 8:19 AM, Qin Wang <qinwang@berkeley.edu>




wrote:
=



Hi Pascal,




It is a very good idea to establish a bundle of cells between A




and
=



B by just triggering 6tus in one side. We can design for=





different



scenarios.


(1) PCE define=
s the track, i.e. the multihop path, the bandwidth
<=
/blockquote>



of
<=
/blockquote>


each hop, a=
nd scheduling hard-cells to implement the multihop




path.



Assume nodeA and nodeB are one-hop neighbors along the path. In


this case, =
PCE can send Create.hardcell command to 6tus layer in




nodeA,and nodeA's 6tus sends Create.=
hardcell command to nodeB'




6tus, then the hard cell is reserved. This function is not in the<=
/span>
=





current version of 6tus draft, but we can a=
dd it in the next


version eas=
ily.




(2)PCE defines the multihop path and the=
 bandwidth of each hop,




but
=



not schedules the cells to meet the p=
ath bandwidth. In this case,




soft cell reservation will be applied, w=
hich is always triggered
<=
/blockquote>



in
<=
/blockquote>


Transmitting side, and negotiated by =
the 6tus layer of both




sides.



(3)The cell reservation is triggered by upper layer, e.g. the<=
br>


RSVP/NSIS entity in nodeA. Then soft =
cell reservation process in




6tus layer of nodeA will by triggered, a=
nd the negotiation




process


is same as case (2).




In summary, by adding reserve hard cell procedure into version-00<=
/span>
=





of 6tus, we can let the bundle reservation =
in every scenarios be


triggered just in one side.




How do you think?


Great first start in defining the scenarios.




Qin
=




Hi Qin:


I think we are on the same line. The =
services that 6TUS proposes




do not depend on which protocol the request came in through.




Since we are defining the protocol extensions, we'll make s=
ure




that the new information is directly digestible by the 6TUS




layer.<=
br>




The protocol exte=
nsions will be separate specs, and there should
<=
/blockquote>



be little to no dereference between those s=
pecs and yours.



What's important to me to discuss is how we establish a bundle


of




cells between A and B.




IMHO, it would be best if that can be ac=
hieved by triggering a




service in A - no need to trigger B as w=
ell.




That way, the volume of exchanges between PCE and nodes can be




devided by 2.


This would mean that there must be an exchange between 6TUS=
 in A




and 6TUS in B.




Which =A0also would mean that there is a=
 protocol part related to
=





6TUS=85


Fully agreed that this is needed. Being an independent laye=
r, I




don't see why not.


Cheers,




Pascal




-----Original Message-----
=





From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On




Behalf Of Qin Wang




Sent: vendredi 15 mars 2013 18:04=





To: JeongGil Ko
<=
/blockquote>


Cc: 6ts=
ch@ietf.org; Xavier Vilajosana




Subject: Re: [6tsch] Schemes for resource allocation in the LLN=





for 6tus




John and Xavi,




I agree that understanding more about upper=
 layer protocols like




RSVP and NSIS is very helpful for designing=
 6tus. But, I want to




make clearer about my understanding on the =
relationship between




6tus and existing reservation protocols lik=
e RSVP or NSIS.



(1) When we talk about reservation in the context of 6tus, we<=
br>


mainly focus on =A0link resource (i.e. cell) reservation, w=
hich is




required/ triggered by upper layer. Even in the pure centralize=
d




approach, it may happen to cross-layer reserve both L3 and L2




resource, but you still can separate them logically.
=





(2) The upper =
layer requirement to 6tus may come from PCE




carried




by protocol like CoAP, may come from the RS=
VP/NSIS entity inside




nodes.
=



Thus, for 6=
tus, the question is what kind of function and




interface should be provided to support the upper layer, instea=
d




of which upper layer protocol should be used.




How do you thi=
nk?



I agree with your arguments that the important thing is defining


the



functionalities. It seems like some of these efforts are on the


way



in the later emails. Me bringing in the term "RSVP" was not=
 that I


wanted to go an use RSVP in the way i=
t is, but bring the




(modified/customized) concept in for use in 6tus. As to what I


read




there may have been a misunderstanding between us but we are on


the




same line.


Thanks!




-John
<=
/blockquote>


Qin




___________________________________________=
____


6tsch mailing =
list


6tsch@ietf.org




https://www.ietf.org/mailman/listinfo/6tsch<=
/a>



_______________________________________________
<=
blockquote type=3D"cite">
6tsch mailing list
<=
span>6tsch@ietf.org=

https://www.ietf.org=
/mailman/listinfo/6tsch



=


_______________________=
________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





--047d7bf0e8a419d26f04d84a0077--

From pthubert@cisco.com  Tue Mar 19 12:08:39 2013
Return-Path: 
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 01D9121F8CCB for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 12:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pH75Yu4jsR9k for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 12:08:37 -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 9F29921F8B20 for <6tsch@ietf.org>; Tue, 19 Mar 2013 12:08:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12527; q=dns/txt; s=iport; t=1363720117; x=1364929717; h=from:to:subject:date:message-id:mime-version; bh=HortbgAtCgYyGz3IzzHZjkojX1WhfXNWG2orHofmF4E=; b=UwZTlRc0nzvN5KIg9zfwp+Vn/wgm29tABgRdgqzztg+iCmvUSaDHuxGx VbpbjZKrWbi3XE4lJ0b3NZSWR99J3bL9EbntpKqQvt8Pbr84KwPZ0R6RV re4bS270XWI2WjCfJWfHWQxVxUm+Z3r6qqUwVnqhCj39RKlo+bkxlJM10 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAHG2SFGtJXHA/2dsb2JhbABDhBPBCIFaFm0HgiYBBC1BHQEqViYBBBuIDKBtkRWQEYkBhVyDF2EDp2GDCoIo
X-IronPort-AV: E=Sophos;i="4.84,873,1355097600";  d="scan'208,217";a="189212182"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 19 Mar 2013 19:08:33 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2JJ8XWU018985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Tue, 19 Mar 2013 19:08:33 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 14:08:33 -0500
From: "Pascal Thubert (pthubert)" 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: focussing on charter: use cases
Thread-Index: Ac4k1OmP4544fW5MRUSgOucw3DT4aQ==
Date: Tue, 19 Mar 2013 19:08:32 +0000
Deferred-Delivery: Tue, 19 Mar 2013 19:07:00 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.104.2]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835CFF68Bxmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: [6tsch] focussing on charter: use cases
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 19:08:39 -0000

--_000_E045AECD98228444A58C61C200AE1BD835CFF68Bxmbrcdx01ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear ML:

The activity that we generate on the mailing list is a good indication we w=
ill be very successful as a WG. First thing first, though, we need to creat=
e the WG and need to focus a little bit on the necessary steps to get there=
.

We need to put together a rough charter, and convince an AD, probably Adria=
n from Routing Area or Ted from Internet Area, that we have real problems t=
o solve and that we, as a group, can provide valuable answers. The ADs agen=
das are very full all the time, but certainly peaks around the meeting time=
s. So we have about 2 week in front of us to prepare a solid case.

So I suggest we step back a minute from the details of time frames and prio=
rities and spend some energy on the use cases, the problems we are solving,=
 and the work we have to do to get there. I notice a cool discussion on mob=
ility and the particular case of a crane, well that's a use case. We alread=
y had centralized deterministic (hard slot) routes for command and control,=
 distributed deterministic (soft slots) and non deterministic QoS based flo=
ws. Do we have others cases?
Cheers,

Pascal



--_000_E045AECD98228444A58C61C200AE1BD835CFF68Bxmbrcdx01ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear ML:


 


The activity that we generate on the mailing list is=
 a good indication we will be very successful as a WG. First thing first, t=
hough, we need to create the WG and need to focus a little bit on the neces=
sary steps to get there.


 


We need to put together a rough charter, and convinc=
e an AD, probably Adrian from Routing Area or Ted from Internet Area, that =
we have real problems to solve and that we, as a group, can provide valuabl=
e answers. The ADs agendas are very
 full all the time, but certainly peaks around the meeting times. So we hav=
e about 2 week in front of us to prepare a solid case.


 


So I suggest we step back a minute from the details =
of time frames and priorities and spend some energy on the use cases, the p=
roblems we are solving, and the work we have to do to get there. I notice a=
 cool discussion on mobility and the
 particular case of a crane, well that’s a use case. We already had c=
entralized deterministic (hard slot) routes for command and control, distri=
buted deterministic (soft slots) and non deterministic QoS based flows. Do =
we have others cases?




Cheers,


 


Pascal


 


 






--_000_E045AECD98228444A58C61C200AE1BD835CFF68Bxmbrcdx01ciscoc_--

From alfredo.grieco@gmail.com  Tue Mar 19 12:30:34 2013
Return-Path: 
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 7E70821F87AB for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 12:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.873
X-Spam-Level: **
X-Spam-Status: No, score=2.873 tagged_above=-999 required=5 tests=[AWL=-0.100,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RDNS_NONE=0.1]
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 DDL7MViB2C6q for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 12:30:31 -0700 (PDT)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B26A121F8739 for <6tsch@ietf.org>; Tue, 19 Mar 2013 12:30:30 -0700 (PDT)
Received: by mail-we0-f179.google.com with SMTP id u3so721393wey.24 for <6tsch@ietf.org>; Tue, 19 Mar 2013 12:30:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:references:from:content-type:x-mailer :in-reply-to:message-id:date:to:content-transfer-encoding :mime-version; bh=N2gYH5txyxdtTPCKngqhky8DdYNlrD1bXLY5DessrZo=; b=kwYxiXmCj1F/lgIEax+ecPBqQwbOQj4WqLmXpwqn1kQQ/4ZFYXL2tM+IbXAn4M34Nr GBtI3oe3UeTMQU6+JaYO9br4cfjBd9fwPfvA5L44WJebvhj9cTDBBcJWWdGk3J8YxQ6t ub6UaBT3Qpg1bFinKcQRlIpezlyJUtjm/1PCxm1KA3crXUNBxonVszSPVx+MWKscEHq7 UfGcBMfOvQnnf24YEek2w67Ck95dfCNxCQBx6O7bNU4LzLP0md16bf+MkxETuXzow8by 6Ftto5iJO9SV4kHOnNKWDvFWDZ7OXRoyk22LSMJZGsigdgn454qlzI43RbhpNd4ZcH1E Cwfg==
X-Received: by 10.194.119.33 with SMTP id kr1mr5799986wjb.36.1363721429787; Tue, 19 Mar 2013 12:30:29 -0700 (PDT)
Received: from [217.201.208.16] ([217.201.208.16]) by mx.google.com with ESMTPS id ex15sm2607814wid.5.2013.03.19.12.29.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Mar 2013 12:30:28 -0700 (PDT)
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com>    <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>  <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu> <51475694.85d00e0a.2654.3c21@mx.google.com> <1b952faca1b2846136ff23c6723eeb63.squirrel@calmail.berkeley.edu>  <51476DC1.5070707@eecs.berkeley.edu>  <775F44DA-D912-4B36-B241-E176FBD585F1@gmail.com> 
From: Grieco 
Content-Type: multipart/alternative; boundary=Apple-Mail-FE4549D6-6C1E-48C9-BD53-3793272C8F95
X-Mailer: iPad Mail (10B146)
In-Reply-To: 
Message-Id: <299D7883-A8BB-4F88-9BDD-93E5EC9B4381@gmail.com>
Date: Tue, 19 Mar 2013 20:29:54 +0100
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: [6tsch] R: Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 19:30:34 -0000

--Apple-Mail-FE4549D6-6C1E-48C9-BD53-3793272C8F95
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thomas, Pascal,

If this can serve to point out some relevant target scenarios, use cases wit=
h some degree of mobility include:
- robotics applications
- assembly lines
- avionic systems
- radio localization and tracking=20
- advanced mechatronic systems

These are the main domains Telematics lab  is involved within several resear=
ch projects at Politecnico di Bari.

Cheers

Alfredo


On 19 Mar 2013, at 17:57, Thomas Watteyne  wrote=
:

> Alfredo,
>=20
> This is an interesting use case you bring up. Do you have a specific use c=
ase/problem you are trying to solve?
>=20
> I agree with Qin that it would be great if this were a schedule-only decis=
ion, i.e. we change as little as possible in the mechanism (e.g. 6tus), but r=
ather have the scheduling entity build an (otherwise normal) schedule which a=
llows for some motes to roam around.
>=20
> Thomas
>=20
> On Tue, Mar 19, 2013 at 1:58 AM, Grieco  wrote:
>> Hi Qin,
>>=20
>> It does work for me: thanks for the clarification
>>=20
>> Cheers
>>=20
>> Alfredo
>>=20
>> --
>> Luigi Alfredo Grieco, PhD
>> Assistant Professor
>> Department of Electrical and Information Engineering
>> Politecnico di Bari
>> Via Orabona 4 - 70125 - Bari - Italy
>> +39 080 5963 911
>> telematics.poliba.it/grieco
>> Skype id: l.alfredo.grieco
>> Mobile: +39 3346715672
>>=20
>>=20
>> On 19 Mar 2013, at 01:09, "Qin Wang"  wrote:
>>=20
>>> Alfredo,
>>>=20
>>> I think there are two key features in your description: (1)data with hig=
h
>>> priority, and (2)mobility. I would like to think the two feature
>>> separately.
>>>=20
>>> Regarding to the high priority, I think the QoS mechanism like DSCP can
>>> handle it, no matter the data flow come from static node or moving node.=

>>>=20
>>> Regarding to the mobility, the 6tus can support to establish tracks for
>>> specific purpose. Actually, the cell reservation request comes from uppe=
r
>>> layer, 6tus do not know the reserved cells will be used by static nodes o=
r
>>> mobile nodes. In another word, upper layer can ask 6tus to reserve some
>>> cells or tracks or pipes which specifically used for mobile node to send=

>>> data as you said.
>>>=20
>>> Does it make sense?
>>>=20
>>> Qin
>>>=20
>>>=20
>>>=20
>>>>=20
>>>> Hi Xavi, Thomas, all
>>>>=20
>>>> The problem I am pointing out is not related only to the neighbourhood.=
 As
>>>> a matter of fact, a node would like its data be received to the sink an=
d
>>>> not only at the next hop. If for each hop to travel, a data packet shou=
ld
>>>> gain a cell through some request/answer handshake this would lead to hi=
gh
>>>> e2e delays when the depth of the tree is high and would incur useless
>>>> signalling.
>>>>=20
>>>> If we think at TASA, to do an example, the schedule exactly rules the
>>>> story of each packet from its generating node to the sink. I was trying=
 to
>>>> figure out how to do the same in presence of some uncertainty on the
>>>> network topology.
>>>>=20
>>>> While solving this problem is something to be afforded in some scientif=
ic
>>>> paper, I believe that the functionalities of 6tus and the entire
>>>> architecture we are envisaging should be ready to welcome this new wave=
 of
>>>> algorithms.
>>>>=20
>>>> In other terms, I am proposing to add a limited number of "reserved pip=
es"
>>>> to the sink that could be used to transport "only" urgent data from mob=
ile
>>>> nodes.
>>>>=20
>>>> Thomas, this could be added as general remark to the architecture or to=

>>>> the draft you are editing. Of course, with more details, some primitive=
 to
>>>> the 6tus draft could be added or lead to a new draft on handling mobile=

>>>> 6tsch nodes.
>>>>=20
>>>> Cheers :-)
>>>>=20
>>>>=20
>>>> --
>>>> Luigi Alfredo Grieco, PhD
>>>> Assistant Professor
>>>> Department of Electrical and Information Engineering
>>>> Politecnico di Bari
>>>> Via Orabona 4 - 70125 - Bari - Italy
>>>> +39 080 5963 911
>>>> telematics.poliba.it/grieco
>>>> Skype id: l.alfredo.grieco
>>>> Mobile: +39 3346715672
>>>>=20
>>>>=20
>>>> On 18 Mar 2013, at 20:40, Xavier Vilajosana
>>>>  wrote:
>>>>=20
>>>>> Hi Alfredo,
>>>>>=20
>>>>> just one point on mobility.
>>>>> TSCH networks may require certain time for a node to join, this depend=
s
>>>>> on how the EBs are sent and what are the policies for the joining node=

>>>>> on how to scan the different channels. Having said that, I think that
>>>>> the time required for a node to reserve some cells with its neighbour i=
s
>>>>> extremely less than the joining time and hence if a mobile node can jo=
in
>>>>> the network for sure has time to schedule some links. So maybe this is=

>>>>> not a big problem :-)
>>>>>=20
>>>>> cheers!
>>>>> Xavi
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 18/03/13 12:36, Grieco wrote:
>>>>>> Hi Qin, Thomas, and all
>>>>>>=20
>>>>>> Perhaps the only way to cope with (a reasonable degree of) mobility i=
s
>>>>>> to hardly assign a certain number of cells at each link to be used in=

>>>>>> case a mobile node arrives with urgent data to transmit.
>>>>>>=20
>>>>>> Obviously this would slightly decrease the overall efficiency of the
>>>>>> system because such "guaranteed cells" could get unused in most of
>>>>>> cases.
>>>>>>=20
>>>>>> If, on the other side, the mobile node is generating data which is no=
t
>>>>>> that urgent, soft reservation could be used as well, which should was=
te
>>>>>> a smaller amount of resources.
>>>>>>=20
>>>>>> In this perspective, mobile nodes could be handled using either
>>>>>> functions 1 or 2, depending on the degree of mobility, the priority o=
f
>>>>>> the data packets generated by mobile nodes, the desired duty cycle, a=
nd
>>>>>> so on.
>>>>>>=20
>>>>>> Cheers
>>>>>>=20
>>>>>> Alfredo
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> Luigi Alfredo Grieco, PhD
>>>>>> Assistant Professor
>>>>>> Department of Electrical and Information Engineering
>>>>>> Politecnico di Bari
>>>>>> Via Orabona 4 - 70125 - Bari - Italy
>>>>>> +39 080 5963 911
>>>>>> telematics.poliba.it/grieco
>>>>>> Skype id: l.alfredo.grieco
>>>>>> Mobile: +39 3346715672
>>>>>>=20
>>>>>>=20
>>>>>> On 18 Mar 2013, at 20:20, "Qin Wang"  wrote:
>>>>>>=20
>>>>>>> Alfredo,
>>>>>>>=20
>>>>>>> I think your remark is correct. So, if there is lots of mobility, I
>>>>>>> would
>>>>>>> be prefer distributed approach, i.e. Soft Cell reservation locally +=

>>>>>>> RPL +
>>>>>>> DSCP for QoS.
>>>>>>>=20
>>>>>>> Qin
>>>>>>>=20
>>>>>>>=20
>>>>>>>> Hi Qin,
>>>>>>>> Your proposal is sound.
>>>>>>>> Just a final remark: if my understanding is correct, the PCE should=

>>>>>>>> build
>>>>>>>> a schedule that spans across multiple links from mobile node M
>>>>>>>> towards the
>>>>>>>> sink S.
>>>>>>>> If a M moves after the schedule has been built, some pre-assigned
>>>>>>>> resources along that path could get lost (which could be tolerated)=

>>>>>>>> because of the change of the topology.
>>>>>>>> Is it ok ?
>>>>>>>> Cheers and thanks for your answer
>>>>>>>> Alfredo
>>>>>>>> -----Messaggio originale-----
>>>>>>>> Da: Qin Wang [mailto:qinwang@berkeley.edu]
>>>>>>>> Inviato: Monday, March 18, 2013 6:48 PM
>>>>>>>> A: Grieco
>>>>>>>> Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); 6tsch@ietf.or=
g;
>>>>>>>> Xavier Vilajosana
>>>>>>>> Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for=

>>>>>>>> 6tus
>>>>>>>> Alfredo,
>>>>>>>> Firstly, my understanding is Hard cell reservation can only be used=

>>>>>>>> by
>>>>>>>> PCE, i.e.  centralized schedule. Thus, mobile node will join in
>>>>>>>> network
>>>>>>>> based on the cells broadcast in EB. And, after its registration, PC=
E
>>>>>>>> will
>>>>>>>> assign some Hard cells to it.
>>>>>>>> secondly, regarding to high priority of the data flow from the mobi=
le
>>>>>>>> node, DSCP may help, i.e. the packets from the mobile node can
>>>>>>>> include
>>>>>>>> Priority.
>>>>>>>> How do you think?
>>>>>>>> Qin
>>>>>>>>> Hi Qin and all,
>>>>>>>>> Just to challenge the two groups of functions Qin is talking about=
,
>>>>>>>>> what if a certain number of mobile nodes need hard reservation ? I=
n
>>>>>>>>> this case, mobile nodes transmit Real time data to be delivered
>>>>>>>>> within
>>>>>>>>> a given deadline but 6tus does not know in advance the rank (or th=
e
>>>>>>>>> position within the topology) of such nodes.
>>>>>>>>> I mean that this kind of traffic has the top priority but nobody
>>>>>>>>> knows
>>>>>>>>> in advance the exact position of the nodes that is going to genera=
te
>>>>>>>>> that data.
>>>>>>>>> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes,=

>>>>>>>>> how ?
>>>>>>>>> Thanks a lot in advance for your attention
>>>>>>>>> Cheers
>>>>>>>>> Alfredo
>>>>>>>>> --
>>>>>>>>> Luigi Alfredo Grieco, PhD
>>>>>>>>> Assistant Professor
>>>>>>>>> Department of Electrical and Information Engineering Politecnico d=
i
>>>>>>>>> Bari Via Orabona 4 - 70125 - Bari - Italy
>>>>>>>>> +39 080 5963 911
>>>>>>>>> telematics.poliba.it/grieco
>>>>>>>>> Skype id: l.alfredo.grieco
>>>>>>>>> Mobile: +39 3346715672
>>>>>>>>> On 17 Mar 2013, at 17:47, "Qin Wang"  wrote:=

>>>>>>>>>> I fully agree with Carsten that Simple is very important. Let's
>>>>>>>>>> overlapping the following three scenarios, then we will find only=

>>>>>>>>>> two
>>>>>>>>>> groups of functions 6tus should provide.
>>>>>>>>>> (1) Hard cell reserve/remove, which supports the 1st scenario.
>>>>>>>>>> (2) Soft cell reserve/remove, which supports the 2nd and 3rd
>>>>>>>>>> scenario.
>>>>>>>>>> Any more?
>>>>>>>>>> Qin
>>>>>>>>>>> Sorry for the delayed response. I was stuck on the plane for too=

>>>>>>>>>>> long
>>>>>>>>>>> :)
>>>>>>>>>>> I like the discussion that Qin is going for where we define the
>>>>>>>>>>> scenarios.
>>>>>>>>>>> At the same time, as Carsten says we need to make sure overlappi=
ng
>>>>>>>>>>> scenarios of any sort are simplified and aggregated as much as
>>>>>>>>>>> possible.
>>>>>>>>>>> Let me just try to put my 2 cents in-line...
>>>>>>>>>>> On Mar 17, 2013, at 8:19 AM, Qin Wang 
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Hi Pascal,
>>>>>>>>>>>> It is a very good idea to establish a bundle of cells between A=

>>>>>>>>>>>> and
>>>>>>>>>>>> B by just triggering 6tus in one side. We can design for
>>>>>>>>>>>> different
>>>>>>>>>>>> scenarios.
>>>>>>>>>>>> (1) PCE defines the track, i.e. the multihop path, the bandwidt=
h
>>>>>>>>>>>> of
>>>>>>>>>>>> each hop, and scheduling hard-cells to implement the multihop
>>>>>>>>>>>> path.
>>>>>>>>>>>> Assume nodeA and nodeB are one-hop neighbors along the path. In=

>>>>>>>>>>>> this case, PCE can send Create.hardcell command to 6tus layer i=
n
>>>>>>>>>>>> nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB'
>>>>>>>>>>>> 6tus, then the hard cell is reserved. This function is not in t=
he
>>>>>>>>>>>> current version of 6tus draft, but we can add it in the next
>>>>>>>>>>>> version easily.
>>>>>>>>>>>> (2)PCE defines the multihop path and the bandwidth of each hop,=

>>>>>>>>>>>> but
>>>>>>>>>>>> not schedules the cells to meet the path bandwidth. In this cas=
e,
>>>>>>>>>>>> soft cell reservation will be applied, which is always triggere=
d
>>>>>>>>>>>> in
>>>>>>>>>>>> Transmitting side, and negotiated by the 6tus layer of both
>>>>>>>>>>>> sides.
>>>>>>>>>>>> (3)The cell reservation is triggered by upper layer, e.g. the
>>>>>>>>>>>> RSVP/NSIS entity in nodeA. Then soft cell reservation process i=
n
>>>>>>>>>>>> 6tus layer of nodeA will by triggered, and the negotiation
>>>>>>>>>>>> process
>>>>>>>>>>>> is same as case (2).
>>>>>>>>>>>> In summary, by adding reserve hard cell procedure into version-=
00
>>>>>>>>>>>> of 6tus, we can let the bundle reservation in every scenarios b=
e
>>>>>>>>>>>> triggered just in one side.
>>>>>>>>>>>> How do you think?
>>>>>>>>>>> Great first start in defining the scenarios.
>>>>>>>>>>>> Qin
>>>>>>>>>>>>> Hi Qin:
>>>>>>>>>>>>> I think we are on the same line. The services that 6TUS propos=
es
>>>>>>>>>>>>> do not depend on which protocol the request came in through.
>>>>>>>>>>>>> Since we are defining the protocol extensions, we'll make sure=

>>>>>>>>>>>>> that the new information is directly digestible by the 6TUS
>>>>>>>>>>>>> layer.
>>>>>>>>>>>>> The protocol extensions will be separate specs, and there shou=
ld
>>>>>>>>>>>>> be little to no dereference between those specs and yours.
>>>>>>>>>>>>> What's important to me to discuss is how we establish a bundle=

>>>>>>>>>>>>> of
>>>>>>>>>>>>> cells between A and B.
>>>>>>>>>>>>> IMHO, it would be best if that can be achieved by triggering a=

>>>>>>>>>>>>> service in A - no need to trigger B as well.
>>>>>>>>>>>>> That way, the volume of exchanges between PCE and nodes can be=

>>>>>>>>>>>>> devided by 2.
>>>>>>>>>>>>> This would mean that there must be an exchange between 6TUS in=
 A
>>>>>>>>>>>>> and 6TUS in B.
>>>>>>>>>>>>> Which  also would mean that there is a protocol part related t=
o
>>>>>>>>>>>>> 6TUS=E2=80=A6
>>>>>>>>>>> Fully agreed that this is needed. Being an independent layer, I
>>>>>>>>>>> don't see why not.
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Pascal
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] O=
n
>>>>>>>>>>>>> Behalf Of Qin Wang
>>>>>>>>>>>>> Sent: vendredi 15 mars 2013 18:04
>>>>>>>>>>>>> To: JeongGil Ko
>>>>>>>>>>>>> Cc: 6tsch@ietf.org; Xavier Vilajosana
>>>>>>>>>>>>> Subject: Re: [6tsch] Schemes for resource allocation in the LL=
N
>>>>>>>>>>>>> for 6tus
>>>>>>>>>>>>> John and Xavi,
>>>>>>>>>>>>> I agree that understanding more about upper layer protocols li=
ke
>>>>>>>>>>>>> RSVP and NSIS is very helpful for designing 6tus. But, I want t=
o
>>>>>>>>>>>>> make clearer about my understanding on the relationship betwee=
n
>>>>>>>>>>>>> 6tus and existing reservation protocols like RSVP or NSIS.
>>>>>>>>>>>>> (1) When we talk about reservation in the context of 6tus, we
>>>>>>>>>>>>> mainly focus on  link resource (i.e. cell) reservation, which i=
s
>>>>>>>>>>>>> required/ triggered by upper layer. Even in the pure centraliz=
ed
>>>>>>>>>>>>> approach, it may happen to cross-layer reserve both L3 and L2
>>>>>>>>>>>>> resource, but you still can separate them logically.
>>>>>>>>>>>>> (2) The upper layer requirement to 6tus may come from PCE
>>>>>>>>>>>>> carried
>>>>>>>>>>>>> by protocol like CoAP, may come from the RSVP/NSIS entity insi=
de
>>>>>>>>>>>>> nodes.
>>>>>>>>>>>>> Thus, for 6tus, the question is what kind of function and
>>>>>>>>>>>>> interface should be provided to support the upper layer, inste=
ad
>>>>>>>>>>>>> of which upper layer protocol should be used.
>>>>>>>>>>>>> How do you think?
>>>>>>>>>>> I agree with your arguments that the important thing is defining=

>>>>>>>>>>> the
>>>>>>>>>>> functionalities. It seems like some of these efforts are on the
>>>>>>>>>>> way
>>>>>>>>>>> in the later emails. Me bringing in the term "RSVP" was not that=
 I
>>>>>>>>>>> wanted to go an use RSVP in the way it is, but bring the
>>>>>>>>>>> (modified/customized) concept in for use in 6tus. As to what I
>>>>>>>>>>> read
>>>>>>>>>>> there may have been a misunderstanding between us but we are on
>>>>>>>>>>> the
>>>>>>>>>>> same line.
>>>>>>>>>>> Thanks!
>>>>>>>>>>> -John
>>>>>>>>>>>>> Qin
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 6tsch mailing list
>>>>>>>>>> 6tsch@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>>>=20
>>>> _______________________________________________
>>>> 6tsch mailing list
>>>> 6tsch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>>=20
>>>=20
>>=20
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>=20
>=20
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch

--Apple-Mail-FE4549D6-6C1E-48C9-BD53-3793272C8F95
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Thomas, Pascal,

If this can serve to point out some relevant target scenarios, use cases w=
ith some degree of mobility include:
- robotics applications
=

- assembly lines
- avionic systems
- radio localiza=
tion and tracking 
- advanced mechatronic systems

These are the main domains Telematics lab  is involved within sev=
eral research projects at Politecnico di Bari.

Cheers

Alfredo

On 19 Mar 2013, at 17:57, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:

Alfredo,


This is an interesting use ca=
se you bring up. Do you have a specific use case/problem you are trying to s=
olve?




I agree with Qin that it would be great if this were a schedule-only decisio=
n, i.e. we change as little as possible in the mechanism (e.g. 6tus), but ra=
ther have the scheduling entity build an (otherwise normal) schedule which a=
llows for some motes to roam around.




Thomas

On Tue, Mar 19, 2013 at 1:58 AM, G=
rieco <alfredo.grieco@gmail.com> wrote:


Hi Qin,

It does work for me:=
 thanks for the clarification

Che=
ers

Alfredo

--

Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering

Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy


telematics.poliba.it/grieco
Skype id: l.alfred=
o.grieco





On 19 Mar 2013, at 01:09, "Qin Wang" <qinwang@berkeley.edu> wrote:

=

Alfredo,


I think there are two key features in your description: (1)data with h=
igh
priority, and (2)mobility. I would like to think the two=
 feature
separately.

Regard=
ing to the high priority, I think the QoS mechanism like DSCP can
=

handle it, no matter the data flow come from static node or moving nod=
e.

Regarding to the mobility, the 6tus can s=
upport to establish tracks for
specific purpose. Actually, t=
he cell reservation request comes from upper

layer, 6tus do not know the reserved cells will be used by static node=
s or
mobile nodes. In another word, upper layer can ask 6tus=
 to reserve some
cells or tracks or pipes which specifically=
 used for mobile node to send

data as you said.

Does it make sense?=


Qin






Hi Xavi, Thomas, all
=


The problem I am pointing out is not related only to the neighbo=
urhood. As


a matter of fact, a node would l=
ike its data be received to the sink and
not only at the next hop. If for each hop to travel, a da=
ta packet should


gain a cell through some reques=
t/answer handshake this would lead to high
e2e delays when the depth of the tree is high and woul=
d incur useless


signalling.

If we think at TASA, to do an example, the schedule exactly r=
ules the


story of each packet from its g=
enerating node to the sink. I was trying to
figure out how to do the same in presence of some unc=
ertainty on the


network topology.

While solving this problem is something to be afforded=
 in some scientific


paper, I believe that the funct=
ionalities of 6tus and the entire
architecture we are envisaging should be ready to welcome this n=
ew wave of


algorithms.

In other terms, I am proposing to add a limited number of "r=
eserved pipes"


to the sink that could be used t=
o transport "only" urgent data from mobile
nodes.


Thomas, this c=
ould be added as general remark to the architecture or to
the draft you are editing. Of course, w=
ith more details, some primitive to


the 6tus draft could be added o=
r lead to a new draft on handling mobile
6tsch nodes.


Cheers :-)

=



--
Luigi Alfred=
o Grieco, PhD
Assista=
nt Professor
Departme=
nt of Electrical and Information Engineering


Politecnico di Bari
<=
/blockquote>
Via Orabona 4 - 70125 - Bari - I=
taly
+39 080 5=
963 911


telematics.poliba.it/grieco
=

Skype id: l.alfredo.grieco


Mobile: +39 3346715672

=



On 18 Mar 2013=
, at 20:40, Xavier Vilajosana
<xvilajosana@eecs.berkeley.edu> wrote:



Hi Alfredo,
<=
span>


just one point on mobility.
TSCH networks may requ=
ire certain time for a node to join, this depends


on how the EBs are sent and what are the policies for the joining no=
de

on how to scan the different channels. Having said that, I think that<=
/span>
the time required for a node to reserve some cells with it=
s neighbour is


extremely less than the joining time and hence if a mobile node can j=
oin

the network for sure has time to schedule some links. So maybe this is=

not a big problem :-)



cheers!

Xavi







On 18/03/13 12:36, Grieco wrote:
<=
blockquote type=3D"cite">
Hi Qin, Thomas, and all



Perhaps the=
 only way to cope with (a reasonable degree of) mobility is


to hardly assign a certain nu=
mber of cells at each link to be used in


case a mobile node arrives with urgent data to transmit=
.



Obviously this would slightly decreas=
e the overall efficiency of the


system because such "guarante=
ed cells" could get unused in most of


cases.



If, on the other side, the mo=
bile node is generating data which is not


that urgent, soft reservation could be used as well, wh=
ich should waste


a smaller amount o=
f resources.



In this perspective, mobile n=
odes could be handled using either


functions 1 or 2, depending on the degree of mobility, the priority o=
f


the data packets g=
enerated by mobile nodes, the desired duty cycle, and


so on.
<=
/blockquote>



Cheers
<=
/blockquote>



Alfredo







<=
/blockquote>


--
Luigi Alfredo Grieco, PhD


Assistant Professor

Department of Electrical and Information Engineering
Politecnico di Bari


Via Orabona 4 - 70125 - Bari - Italy


+39 080 5963 911


telematics.poliba.it/grieco
=


Skype id: l.alfredo.grieco
Mobile: +39 3346715672





On 18 Mar 20=
13, at 20:20, "Qin Wang" <qinwang@berkeley.edu> wrote:





Alfredo,



I t=
hink your remark is correct. So, if there is lots of mobility, I
<=
/blockquote>

wou=
ld


be prefer distributed approach, i.e. Soft Cell reservation locally +=



RPL +
=


DSCP for QoS.

=


Qin
=







Hi Qin,


Your proposal is sound.


Just a final remark: if my understanding is correct, t=
he PCE should


build


a schedule that spans across multiple links from mobi=
le node M


towards the


sink S.


If a M moves after the schedule has been built, some p=
re-assigned


resources along that path c=
ould get lost (which could be tolerated)


because of the change of th=
e topology.


Is it ok ?


Cheers and thanks for your answer=



Alfredo


-----Messaggio originale-----
=



Da: Qin Wang [mailto:qinwang@berkeley.edu]


Inviato: Monday, March 18, 2=
013 6:48 PM


A: Grieco


Cc: Qin Wang; JeongGil Ko; Pascal Thuber=
t (pthubert); 6tsch@ietf=
.org;


Xavier Vilajosana


Oggetto: Re: [6tsch] Schemes for resourc=
e allocation in the LLN for


6tus


Alfredo,


Firstly, my understanding is Hard cell reservation can only be use=
d


by
<=
/blockquote>

PCE, i.e.  centralized schedule. Thus, mobile no=
de will join in


network


based on the cells broadcast in EB. And,=
 after its registration, PCE


will


assign some Hard cells to it.
=



secondly, regarding to high priority of the data flow=
 from the mobile


node, DSCP may help, i.e. t=
he packets from the mobile node can


include


Priority.


How do you think?


Qin
=



Hi Qin and all,
<=
/blockquote>

Just to challenge the two groups of func=
tions Qin is talking about,



what if a certain number of mobile nodes need hard reservation ? In


this case, mobile nodes transmit Real time data to be delivered


within


a given deadline but 6tus does not know in advance th=
e rank (or the



position within the topology) of such nodes.


I mean that this k=
ind of traffic has the top priority but nobody


knows
=



in advance the e=
xact position of the nodes that is going to generate
=



that data.



Do we need a further case ? Or we can leverage on 1 or 2 ? If yes,


how ?
=



Thanks a lot in advance for your attention


Cheers


Alfredo


--
<=
/blockquote>

Luigi Alfredo Grieco, PhD


A=
ssistant Professor



Department of Electrical and Information Engineering Politecnico di


Bari Via Orabona 4 - 70125 - Bari - Italy


+39 080 5=
963 911



telem=
atics.poliba.it/grieco
=



Skype id: l.alfredo.grieco


Mobile: +39 33467=
15672



On 17 Mar 2013, at 17:47, "Qin Wang" <qinwang@berkeley.edu> wrote:
<=
/blockquote>


I fully agree with Carsten t=
hat Simple is very important. Let's




overlapping the following three scenarios, t=
hen we will find only


two
=



groups of func=
tions 6tus should provide.




(1) Hard cell reserve/remove, which supports=
 the 1st scenario.


(2) Soft cell re=
serve/remove, which supports the 2nd and 3rd



scenario.


Any more?


Qin


Sorry for the delayed response. I was st=
uck on the plane for too




long
<=
/blockquote>


:)
<=
/blockquote>



I like the discussion that Qin is going for w=
here we define the


scenarios.




At the same time, a=
s Carsten says we need to make sure overlapping


s=
cenarios of any sort are simplified and aggregated as much as




possible.


Let me just try to put my 2 cents in-lin=
e...




On Mar 17, 2013, at 8:19 AM, Qin Wang <qinwang@berkeley.edu>




wrote:
<=
/blockquote>


Hi Pascal,




It is a very good idea to establish a bundle of cells between A




and


B by just triggering 6tus in one side. We can design for




different



scenarios.


(1) PCE defines t=
he track, i.e. the multihop path, the bandwidth




of


each hop, and s=
cheduling hard-cells to implement the multihop




path.
=




Assume nodeA and nodeB are one-hop neighbors along the path. In=



this case, PCE=
 can send Create.hardcell command to 6tus layer in




nodeA,and nodeA's 6tus sends Create.hardce=
ll command to nodeB'




6tus, then the hard cell is reserved. This function is not in the




current version of 6tus draft, but we can ad=
d it in the next


version easily=
.




(2)PCE defines the multihop path and the b=
andwidth of each hop,




but


not schedules the cells to meet the path=
 bandwidth. In this case,




soft cell reservation will be applied, whi=
ch is always triggered




in


Transmitting side, and negotiated by the=
 6tus layer of both




sides.



(3)The cell reservation is triggered by upper layer, e.g. the


RSVP/NSIS entity in nodeA. Then soft cel=
l reservation process in




6tus layer of nodeA will by triggered, and=
 the negotiation




process
=



is same as case (2).




In summary, by adding reserve hard cell procedure into version-00




of 6tus, we can let the bundle reservation i=
n every scenarios be


triggered just in one side.




How do you think?
<=
/blockquote>


Great first start in defining the scenarios.




Qin
=




Hi Qin:
=



I think we are on the same line. The ser=
vices that 6TUS proposes




do not depend on which protocol the request came in through.




Since we are defining the protocol extensions, we'll make sure




that the new information is directly digestible by the 6TUS=





layer.




The protocol exten=
sions will be separate specs, and there should




be little to no dereference between those sp=
ecs and yours.



What's important to me to discuss is how we establish a bundle<=
br>


of




cells between A and B.




IMHO, it would be best if that can be achi=
eved by triggering a




service in A - no need to trigger B as wel=
l.




That way, the volume of exchanges between PCE and nodes can be




devided by 2.


This would mean that there must be an exchange between 6TUS in A=





and 6TUS in B.




Which  also would mean that there is a=
 protocol part related to
<=
/blockquote>



6TUS=E2=80=A6


Fully agreed that this is needed. Being an independent layer, I<=
/span>




don't see why not.
=



Cheers,




Pascal




-----Original Message-----




From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On




Behalf Of Qin Wang




Sent: vendredi 15 mars 2013 18:04




To: JeongGil Ko


Cc: 6tsch@ie=
tf.org; Xavier Vilajosana




Subject: Re: [6tsch] Schemes for resource allocation in the LLN




for 6tus




John and Xavi,




I agree that understanding more about upper l=
ayer protocols like




RSVP and NSIS is very helpful for designing 6=
tus. But, I want to




make clearer about my understanding on the r=
elationship between




6tus and existing reservation protocols like=
 RSVP or NSIS.



(1) When we talk about reservation in the context of 6tus, we


mainly focus on  link resource (i.e. cell) reservation, whi=
ch is




required/ triggered by upper layer. Even in the pure centralized




approach, it may happen to cross-layer reserve both L3 and L2




resource, but you still can separate them logically.




(2) The upper la=
yer requirement to 6tus may come from PCE




carried




by protocol like CoAP, may come from the RSV=
P/NSIS entity inside




nodes.
<=
/blockquote>


Thus, for 6tus=
, the question is what kind of function and




interface should be provided to support the upper layer, instead




of which upper layer protocol should be used.




How do you think=
?



I agree with your arguments that the important thing is defining


the
=




functionalities. It seems like some of these efforts are on the=



way
=




in the later emails. Me bringing in the term "RSVP" was not that I


wanted to go an use RSVP in the way it i=
s, but bring the




(modified/customized) concept in for use in 6tus. As to what I


read




there may have been a misunderstanding between us but we are on


the




same line.


Thanks!




-John
=



Qin
=





____________________________________________=
___


6tsch mailing li=
st


6tsch@ietf.org




https://www.ietf.org/mailman/listinfo/6tsch



_______________________________________________

6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mai=
lman/listinfo/6tsch



<=
/span>

_________________________=
______________________

6tsch mailing list

6tsch@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/6tsch





____________________=
___________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mai=
lman/listinfo/6tsch
=

--Apple-Mail-FE4549D6-6C1E-48C9-BD53-3793272C8F95--

From xvilajosana@eecs.berkeley.edu  Tue Mar 19 12:37:44 2013
Return-Path: 
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 8401621F8BF4 for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 12:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.148
X-Spam-Level: 
X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4]
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 b+hnYSPddZR4 for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 12:37:37 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD3121F8D8E for <6tsch@ietf.org>; Tue, 19 Mar 2013 12:37:37 -0700 (PDT)
Received: from dhcp-33-135.eecs.berkeley.edu ([128.32.33.135]) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UI2Li-00073y-MN for 6tsch@ietf.org; Tue, 19 Mar 2013 12:37:37 -0700
Message-ID: <5148BE7A.4050409@eecs.berkeley.edu>
Date: Tue, 19 Mar 2013 12:37:30 -0700
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: 6tsch@ietf.org
References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com> <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com>   <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu>  <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu> <51475694.85d00e0a.2654.3c21@mx.google.com> <1b952faca1b2846136ff23c6723eeb63.squirrel@calmail.berkeley.edu>  <51476DC1.5070707@eecs.berkeley.edu>  <775F44DA-D912-4B36-B241-E176FBD585F1@gmail.com>  <299D7883-A8BB-4F88-9BDD-93E5EC9B4381@gma il.com>
In-Reply-To: <299D7883-A8BB-4F88-9BDD-93E5EC9B4381@gmail.com>
Content-Type: multipart/alternative; boundary="------------080905050005090404070101"
Subject: Re: [6tsch] R: Schemes for resource allocation in the LLN for 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 19:37:44 -0000

This is a multi-part message in MIME format.
--------------080905050005090404070101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Hi,

more uses cases that might benefit from 6tus:

-Smart cities/infrastructures/industries
     *(road,street) traffic control (requires increase of bw as more 
traffic in the road)
     *smart urban parking (requires redundancy of routes an 
over-provision as RF degrades with cars on top of the sensors)
     *building monitoring (requires redundancy as RF degrades when there 
are changes on the environment, doors, movement,etc..)
     *industrial automation (latency, robustnes->overprovision,etc...)
     *metering (can be bursty)

and for sure we can find several more use cases where 6tus might be 
*VERY* relevant.

regards,
Xavi

On 19/03/13 12:29, Grieco wrote:
> Thomas, Pascal,
>
> If this can serve to point out some relevant target scenarios, use 
> cases with some degree of mobility include:
> - robotics applications
> - assembly lines
> - avionic systems
> - radio localization and tracking
> - advanced mechatronic systems
>
> These are the main domains Telematics lab  is involved within several 
> research projects at Politecnico di Bari.
>
> Cheers
>
> Alfredo
>
>
> On 19 Mar 2013, at 17:57, Thomas Watteyne  > wrote:
>
>> Alfredo,
>>
>> This is an interesting use case you bring up. Do you have a specific 
>> use case/problem you are trying to solve?
>>
>> I agree with Qin that it would be great if this were a schedule-only 
>> decision, i.e. we change as little as possible in the mechanism (e.g. 
>> 6tus), but rather have the scheduling entity build an (otherwise 
>> normal) schedule which allows for some motes to roam around.
>>
>> Thomas
>>
>> On Tue, Mar 19, 2013 at 1:58 AM, Grieco > > wrote:
>>
>>     Hi Qin,
>>
>>     It does work for me: thanks for the clarification
>>
>>     Cheers
>>
>>     Alfredo
>>
>>     -- 
>>     Luigi Alfredo Grieco, PhD
>>     Assistant Professor
>>     Department of Electrical and Information Engineering
>>     Politecnico di Bari
>>     Via Orabona 4 - 70125 - Bari - Italy
>>     +39 080 5963 911 
>>     telematics.poliba.it/grieco 
>>     Skype id: l.alfredo.grieco
>>     Mobile: +39 3346715672 
>>
>>
>>     On 19 Mar 2013, at 01:09, "Qin Wang" >     > wrote:
>>
>>>     Alfredo,
>>>
>>>     I think there are two key features in your description: (1)data
>>>     with high
>>>     priority, and (2)mobility. I would like to think the two feature
>>>     separately.
>>>
>>>     Regarding to the high priority, I think the QoS mechanism like
>>>     DSCP can
>>>     handle it, no matter the data flow come from static node or
>>>     moving node.
>>>
>>>     Regarding to the mobility, the 6tus can support to establish
>>>     tracks for
>>>     specific purpose. Actually, the cell reservation request comes
>>>     from upper
>>>     layer, 6tus do not know the reserved cells will be used by
>>>     static nodes or
>>>     mobile nodes. In another word, upper layer can ask 6tus to
>>>     reserve some
>>>     cells or tracks or pipes which specifically used for mobile node
>>>     to send
>>>     data as you said.
>>>
>>>     Does it make sense?
>>>
>>>     Qin
>>>
>>>
>>>
>>>>
>>>>     Hi Xavi, Thomas, all
>>>>
>>>>     The problem I am pointing out is not related only to the
>>>>     neighbourhood. As
>>>>     a matter of fact, a node would like its data be received to the
>>>>     sink and
>>>>     not only at the next hop. If for each hop to travel, a data
>>>>     packet should
>>>>     gain a cell through some request/answer handshake this would
>>>>     lead to high
>>>>     e2e delays when the depth of the tree is high and would incur
>>>>     useless
>>>>     signalling.
>>>>
>>>>     If we think at TASA, to do an example, the schedule exactly
>>>>     rules the
>>>>     story of each packet from its generating node to the sink. I
>>>>     was trying to
>>>>     figure out how to do the same in presence of some uncertainty
>>>>     on the
>>>>     network topology.
>>>>
>>>>     While solving this problem is something to be afforded in some
>>>>     scientific
>>>>     paper, I believe that the functionalities of 6tus and the entire
>>>>     architecture we are envisaging should be ready to welcome this
>>>>     new wave of
>>>>     algorithms.
>>>>
>>>>     In other terms, I am proposing to add a limited number of
>>>>     "reserved pipes"
>>>>     to the sink that could be used to transport "only" urgent data
>>>>     from mobile
>>>>     nodes.
>>>>
>>>>     Thomas, this could be added as general remark to the
>>>>     architecture or to
>>>>     the draft you are editing. Of course, with more details, some
>>>>     primitive to
>>>>     the 6tus draft could be added or lead to a new draft on
>>>>     handling mobile
>>>>     6tsch nodes.
>>>>
>>>>     Cheers :-)
>>>>
>>>>
>>>>     --
>>>>     Luigi Alfredo Grieco, PhD
>>>>     Assistant Professor
>>>>     Department of Electrical and Information Engineering
>>>>     Politecnico di Bari
>>>>     Via Orabona 4 - 70125 - Bari - Italy
>>>>     +39 080 5963 911 
>>>>     telematics.poliba.it/grieco 
>>>>     Skype id: l.alfredo.grieco
>>>>     Mobile: +39 3346715672 
>>>>
>>>>
>>>>     On 18 Mar 2013, at 20:40, Xavier Vilajosana
>>>>     >>>     > wrote:
>>>>
>>>>>     Hi Alfredo,
>>>>>
>>>>>     just one point on mobility.
>>>>>     TSCH networks may require certain time for a node to join,
>>>>>     this depends
>>>>>     on how the EBs are sent and what are the policies for the
>>>>>     joining node
>>>>>     on how to scan the different channels. Having said that, I
>>>>>     think that
>>>>>     the time required for a node to reserve some cells with its
>>>>>     neighbour is
>>>>>     extremely less than the joining time and hence if a mobile
>>>>>     node can join
>>>>>     the network for sure has time to schedule some links. So maybe
>>>>>     this is
>>>>>     not a big problem :-)
>>>>>
>>>>>     cheers!
>>>>>     Xavi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     On 18/03/13 12:36, Grieco wrote:
>>>>>>     Hi Qin, Thomas, and all
>>>>>>
>>>>>>     Perhaps the only way to cope with (a reasonable degree of)
>>>>>>     mobility is
>>>>>>     to hardly assign a certain number of cells at each link to be
>>>>>>     used in
>>>>>>     case a mobile node arrives with urgent data to transmit.
>>>>>>
>>>>>>     Obviously this would slightly decrease the overall efficiency
>>>>>>     of the
>>>>>>     system because such "guaranteed cells" could get unused in
>>>>>>     most of
>>>>>>     cases.
>>>>>>
>>>>>>     If, on the other side, the mobile node is generating data
>>>>>>     which is not
>>>>>>     that urgent, soft reservation could be used as well, which
>>>>>>     should waste
>>>>>>     a smaller amount of resources.
>>>>>>
>>>>>>     In this perspective, mobile nodes could be handled using either
>>>>>>     functions 1 or 2, depending on the degree of mobility, the
>>>>>>     priority of
>>>>>>     the data packets generated by mobile nodes, the desired duty
>>>>>>     cycle, and
>>>>>>     so on.
>>>>>>
>>>>>>     Cheers
>>>>>>
>>>>>>     Alfredo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>     --
>>>>>>     Luigi Alfredo Grieco, PhD
>>>>>>     Assistant Professor
>>>>>>     Department of Electrical and Information Engineering
>>>>>>     Politecnico di Bari
>>>>>>     Via Orabona 4 - 70125 - Bari - Italy
>>>>>>     +39 080 5963 911 
>>>>>>     telematics.poliba.it/grieco 
>>>>>>     Skype id: l.alfredo.grieco
>>>>>>     Mobile: +39 3346715672 
>>>>>>
>>>>>>
>>>>>>     On 18 Mar 2013, at 20:20, "Qin Wang" >>>>>     > wrote:
>>>>>>
>>>>>>>     Alfredo,
>>>>>>>
>>>>>>>     I think your remark is correct. So, if there is lots of
>>>>>>>     mobility, I
>>>>>>>     would
>>>>>>>     be prefer distributed approach, i.e. Soft Cell reservation
>>>>>>>     locally +
>>>>>>>     RPL +
>>>>>>>     DSCP for QoS.
>>>>>>>
>>>>>>>     Qin
>>>>>>>
>>>>>>>
>>>>>>>>     Hi Qin,
>>>>>>>>     Your proposal is sound.
>>>>>>>>     Just a final remark: if my understanding is correct, the
>>>>>>>>     PCE should
>>>>>>>>     build
>>>>>>>>     a schedule that spans across multiple links from mobile node M
>>>>>>>>     towards the
>>>>>>>>     sink S.
>>>>>>>>     If a M moves after the schedule has been built, some
>>>>>>>>     pre-assigned
>>>>>>>>     resources along that path could get lost (which could be
>>>>>>>>     tolerated)
>>>>>>>>     because of the change of the topology.
>>>>>>>>     Is it ok ?
>>>>>>>>     Cheers and thanks for your answer
>>>>>>>>     Alfredo
>>>>>>>>     -----Messaggio originale-----
>>>>>>>>     Da: Qin Wang [mailto:qinwang@berkeley.edu]
>>>>>>>>     Inviato: Monday, March 18, 2013 6:48 PM
>>>>>>>>     A: Grieco
>>>>>>>>     Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert);
>>>>>>>>     6tsch@ietf.org ;
>>>>>>>>     Xavier Vilajosana
>>>>>>>>     Oggetto: Re: [6tsch] Schemes for resource allocation in the
>>>>>>>>     LLN for
>>>>>>>>     6tus
>>>>>>>>     Alfredo,
>>>>>>>>     Firstly, my understanding is Hard cell reservation can only
>>>>>>>>     be used
>>>>>>>>     by
>>>>>>>>     PCE, i.e.  centralized schedule. Thus, mobile node will join in
>>>>>>>>     network
>>>>>>>>     based on the cells broadcast in EB. And, after its
>>>>>>>>     registration, PCE
>>>>>>>>     will
>>>>>>>>     assign some Hard cells to it.
>>>>>>>>     secondly, regarding to high priority of the data flow from
>>>>>>>>     the mobile
>>>>>>>>     node, DSCP may help, i.e. the packets from the mobile node can
>>>>>>>>     include
>>>>>>>>     Priority.
>>>>>>>>     How do you think?
>>>>>>>>     Qin
>>>>>>>>>     Hi Qin and all,
>>>>>>>>>     Just to challenge the two groups of functions Qin is
>>>>>>>>>     talking about,
>>>>>>>>>     what if a certain number of mobile nodes need hard
>>>>>>>>>     reservation ? In
>>>>>>>>>     this case, mobile nodes transmit Real time data to be
>>>>>>>>>     delivered
>>>>>>>>>     within
>>>>>>>>>     a given deadline but 6tus does not know in advance the
>>>>>>>>>     rank (or the
>>>>>>>>>     position within the topology) of such nodes.
>>>>>>>>>     I mean that this kind of traffic has the top priority but
>>>>>>>>>     nobody
>>>>>>>>>     knows
>>>>>>>>>     in advance the exact position of the nodes that is going
>>>>>>>>>     to generate
>>>>>>>>>     that data.
>>>>>>>>>     Do we need a further case ? Or we can leverage on 1 or 2 ?
>>>>>>>>>     If yes,
>>>>>>>>>     how ?
>>>>>>>>>     Thanks a lot in advance for your attention
>>>>>>>>>     Cheers
>>>>>>>>>     Alfredo
>>>>>>>>>     --
>>>>>>>>>     Luigi Alfredo Grieco, PhD
>>>>>>>>>     Assistant Professor
>>>>>>>>>     Department of Electrical and Information Engineering
>>>>>>>>>     Politecnico di
>>>>>>>>>     Bari Via Orabona 4 - 70125 - Bari - Italy
>>>>>>>>>     +39 080 5963 911 
>>>>>>>>>     telematics.poliba.it/grieco
>>>>>>>>>     
>>>>>>>>>     Skype id: l.alfredo.grieco
>>>>>>>>>     Mobile: +39 3346715672 
>>>>>>>>>     On 17 Mar 2013, at 17:47, "Qin Wang" >>>>>>>>     > wrote:
>>>>>>>>>>     I fully agree with Carsten that Simple is very important.
>>>>>>>>>>     Let's
>>>>>>>>>>     overlapping the following three scenarios, then we will
>>>>>>>>>>     find only
>>>>>>>>>>     two
>>>>>>>>>>     groups of functions 6tus should provide.
>>>>>>>>>>     (1) Hard cell reserve/remove, which supports the 1st
>>>>>>>>>>     scenario.
>>>>>>>>>>     (2) Soft cell reserve/remove, which supports the 2nd and 3rd
>>>>>>>>>>     scenario.
>>>>>>>>>>     Any more?
>>>>>>>>>>     Qin
>>>>>>>>>>>     Sorry for the delayed response. I was stuck on the plane
>>>>>>>>>>>     for too
>>>>>>>>>>>     long
>>>>>>>>>>>     :)
>>>>>>>>>>>     I like the discussion that Qin is going for where we
>>>>>>>>>>>     define the
>>>>>>>>>>>     scenarios.
>>>>>>>>>>>     At the same time, as Carsten says we need to make sure
>>>>>>>>>>>     overlapping
>>>>>>>>>>>     scenarios of any sort are simplified and aggregated as
>>>>>>>>>>>     much as
>>>>>>>>>>>     possible.
>>>>>>>>>>>     Let me just try to put my 2 cents in-line...
>>>>>>>>>>>     On Mar 17, 2013, at 8:19 AM, Qin Wang
>>>>>>>>>>>     >
>>>>>>>>>>>     wrote:
>>>>>>>>>>>>     Hi Pascal,
>>>>>>>>>>>>     It is a very good idea to establish a bundle of cells
>>>>>>>>>>>>     between A
>>>>>>>>>>>>     and
>>>>>>>>>>>>     B by just triggering 6tus in one side. We can design for
>>>>>>>>>>>>     different
>>>>>>>>>>>>     scenarios.
>>>>>>>>>>>>     (1) PCE defines the track, i.e. the multihop path, the
>>>>>>>>>>>>     bandwidth
>>>>>>>>>>>>     of
>>>>>>>>>>>>     each hop, and scheduling hard-cells to implement the
>>>>>>>>>>>>     multihop
>>>>>>>>>>>>     path.
>>>>>>>>>>>>     Assume nodeA and nodeB are one-hop neighbors along the
>>>>>>>>>>>>     path. In
>>>>>>>>>>>>     this case, PCE can send Create.hardcell command to 6tus
>>>>>>>>>>>>     layer in
>>>>>>>>>>>>     nodeA,and nodeA's 6tus sends Create.hardcell command to
>>>>>>>>>>>>     nodeB'
>>>>>>>>>>>>     6tus, then the hard cell is reserved. This function is
>>>>>>>>>>>>     not in the
>>>>>>>>>>>>     current version of 6tus draft, but we can add it in the
>>>>>>>>>>>>     next
>>>>>>>>>>>>     version easily.
>>>>>>>>>>>>     (2)PCE defines the multihop path and the bandwidth of
>>>>>>>>>>>>     each hop,
>>>>>>>>>>>>     but
>>>>>>>>>>>>     not schedules the cells to meet the path bandwidth. In
>>>>>>>>>>>>     this case,
>>>>>>>>>>>>     soft cell reservation will be applied, which is always
>>>>>>>>>>>>     triggered
>>>>>>>>>>>>     in
>>>>>>>>>>>>     Transmitting side, and negotiated by the 6tus layer of both
>>>>>>>>>>>>     sides.
>>>>>>>>>>>>     (3)The cell reservation is triggered by upper layer,
>>>>>>>>>>>>     e.g. the
>>>>>>>>>>>>     RSVP/NSIS entity in nodeA. Then soft cell reservation
>>>>>>>>>>>>     process in
>>>>>>>>>>>>     6tus layer of nodeA will by triggered, and the negotiation
>>>>>>>>>>>>     process
>>>>>>>>>>>>     is same as case (2).
>>>>>>>>>>>>     In summary, by adding reserve hard cell procedure into
>>>>>>>>>>>>     version-00
>>>>>>>>>>>>     of 6tus, we can let the bundle reservation in every
>>>>>>>>>>>>     scenarios be
>>>>>>>>>>>>     triggered just in one side.
>>>>>>>>>>>>     How do you think?
>>>>>>>>>>>     Great first start in defining the scenarios.
>>>>>>>>>>>>     Qin
>>>>>>>>>>>>>     Hi Qin:
>>>>>>>>>>>>>     I think we are on the same line. The services that
>>>>>>>>>>>>>     6TUS proposes
>>>>>>>>>>>>>     do not depend on which protocol the request came in
>>>>>>>>>>>>>     through.
>>>>>>>>>>>>>     Since we are defining the protocol extensions, we'll
>>>>>>>>>>>>>     make sure
>>>>>>>>>>>>>     that the new information is directly digestible by the
>>>>>>>>>>>>>     6TUS
>>>>>>>>>>>>>     layer.
>>>>>>>>>>>>>     The protocol extensions will be separate specs, and
>>>>>>>>>>>>>     there should
>>>>>>>>>>>>>     be little to no dereference between those specs and yours.
>>>>>>>>>>>>>     What's important to me to discuss is how we establish
>>>>>>>>>>>>>     a bundle
>>>>>>>>>>>>>     of
>>>>>>>>>>>>>     cells between A and B.
>>>>>>>>>>>>>     IMHO, it would be best if that can be achieved by
>>>>>>>>>>>>>     triggering a
>>>>>>>>>>>>>     service in A - no need to trigger B as well.
>>>>>>>>>>>>>     That way, the volume of exchanges between PCE and
>>>>>>>>>>>>>     nodes can be
>>>>>>>>>>>>>     devided by 2.
>>>>>>>>>>>>>     This would mean that there must be an exchange between
>>>>>>>>>>>>>     6TUS in A
>>>>>>>>>>>>>     and 6TUS in B.
>>>>>>>>>>>>>     Which  also would mean that there is a protocol part
>>>>>>>>>>>>>     related to
>>>>>>>>>>>>>     6TUS...
>>>>>>>>>>>     Fully agreed that this is needed. Being an independent
>>>>>>>>>>>     layer, I
>>>>>>>>>>>     don't see why not.
>>>>>>>>>>>>>     Cheers,
>>>>>>>>>>>>>     Pascal
>>>>>>>>>>>>>     -----Original Message-----
>>>>>>>>>>>>>     From: 6tsch-bounces@ietf.org
>>>>>>>>>>>>>     
>>>>>>>>>>>>>     [mailto:6tsch-bounces@ietf.org] On
>>>>>>>>>>>>>     Behalf Of Qin Wang
>>>>>>>>>>>>>     Sent: vendredi 15 mars 2013 18:04
>>>>>>>>>>>>>     To: JeongGil Ko
>>>>>>>>>>>>>     Cc: 6tsch@ietf.org ; Xavier
>>>>>>>>>>>>>     Vilajosana
>>>>>>>>>>>>>     Subject: Re: [6tsch] Schemes for resource allocation
>>>>>>>>>>>>>     in the LLN
>>>>>>>>>>>>>     for 6tus
>>>>>>>>>>>>>     John and Xavi,
>>>>>>>>>>>>>     I agree that understanding more about upper layer
>>>>>>>>>>>>>     protocols like
>>>>>>>>>>>>>     RSVP and NSIS is very helpful for designing 6tus. But,
>>>>>>>>>>>>>     I want to
>>>>>>>>>>>>>     make clearer about my understanding on the
>>>>>>>>>>>>>     relationship between
>>>>>>>>>>>>>     6tus and existing reservation protocols like RSVP or NSIS.
>>>>>>>>>>>>>     (1) When we talk about reservation in the context of
>>>>>>>>>>>>>     6tus, we
>>>>>>>>>>>>>     mainly focus on  link resource (i.e. cell)
>>>>>>>>>>>>>     reservation, which is
>>>>>>>>>>>>>     required/ triggered by upper layer. Even in the pure
>>>>>>>>>>>>>     centralized
>>>>>>>>>>>>>     approach, it may happen to cross-layer reserve both L3
>>>>>>>>>>>>>     and L2
>>>>>>>>>>>>>     resource, but you still can separate them logically.
>>>>>>>>>>>>>     (2) The upper layer requirement to 6tus may come from PCE
>>>>>>>>>>>>>     carried
>>>>>>>>>>>>>     by protocol like CoAP, may come from the RSVP/NSIS
>>>>>>>>>>>>>     entity inside
>>>>>>>>>>>>>     nodes.
>>>>>>>>>>>>>     Thus, for 6tus, the question is what kind of function and
>>>>>>>>>>>>>     interface should be provided to support the upper
>>>>>>>>>>>>>     layer, instead
>>>>>>>>>>>>>     of which upper layer protocol should be used.
>>>>>>>>>>>>>     How do you think?
>>>>>>>>>>>     I agree with your arguments that the important thing is
>>>>>>>>>>>     defining
>>>>>>>>>>>     the
>>>>>>>>>>>     functionalities. It seems like some of these efforts are
>>>>>>>>>>>     on the
>>>>>>>>>>>     way
>>>>>>>>>>>     in the later emails. Me bringing in the term "RSVP" was
>>>>>>>>>>>     not that I
>>>>>>>>>>>     wanted to go an use RSVP in the way it is, but bring the
>>>>>>>>>>>     (modified/customized) concept in for use in 6tus. As to
>>>>>>>>>>>     what I
>>>>>>>>>>>     read
>>>>>>>>>>>     there may have been a misunderstanding between us but we
>>>>>>>>>>>     are on
>>>>>>>>>>>     the
>>>>>>>>>>>     same line.
>>>>>>>>>>>     Thanks!
>>>>>>>>>>>     -John
>>>>>>>>>>>>>     Qin
>>>>>>>>>>     _______________________________________________
>>>>>>>>>>     6tsch mailing list
>>>>>>>>>>     6tsch@ietf.org 
>>>>>>>>>>     https://www.ietf.org/mailman/listinfo/6tsch
>>>>>
>>>>     _______________________________________________
>>>>     6tsch mailing list
>>>>     6tsch@ietf.org 
>>>>     https://www.ietf.org/mailman/listinfo/6tsch
>>>>
>>>
>>
>>     _______________________________________________
>>     6tsch mailing list
>>     6tsch@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org 
>> https://www.ietf.org/mailman/listinfo/6tsch
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


--------------080905050005090404070101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    


      Hi,

      

      more uses cases that might benefit from 6tus:

      

      -Smart cities/infrastructures/industries 

          *(road,street) traffic control (requires increase of bw as
      more traffic in the road)

          *smart urban parking (requires redundancy of routes an
      over-provision as RF degrades with cars on top of the sensors)

          *building monitoring (requires redundancy as RF degrades when
      there are changes on the environment, doors, movement,etc..)

          *industrial automation (latency,
      robustnes->overprovision,etc...)

          *metering (can be bursty)

      

      and for sure we can find several more use cases where 6tus might
      be *VERY* relevant.

      

      regards,

      Xavi

      

      On 19/03/13 12:29, Grieco wrote:

    

    

      
      
Thomas, Pascal,

      


      

      
If this can serve to point out some relevant target
        scenarios, use cases with some degree of mobility include:

      
- robotics applications

      
- assembly lines

      
- avionic systems

      
- radio localization and tracking 

      
- advanced mechatronic systems

        

        

          
These are the main domains Telematics lab  is involved
            within several research projects at Politecnico di Bari.

        

      

      


      

      
Cheers

      


      

      
Alfredo

      


      

      


        On 19 Mar 2013, at 17:57, Thomas Watteyne <watteyne@eecs.berkeley.edu>
        wrote:

        

      

      

        
Alfredo,
          


          

          
This
            is an interesting use case you bring up. Do you have a
            specific use case/problem you are trying to solve?

          


          

          
I
            agree with Qin that it would be great if this were a
            schedule-only decision, i.e. we change as little as possible
            in the mechanism (e.g. 6tus), but rather have the scheduling
            entity build an (otherwise normal) schedule which allows for
            some motes to roam around.

          


          

          
Thomas

          

          
On Tue, Mar 19, 2013 at 1:58 AM,
            Grieco <alfredo.grieco@gmail.com>
            wrote:

            

              

                
Hi Qin,

                


                

                
It does work for me: thanks for the clarification

                

                  


                  

                  
Cheers

                  


                  

                  
Alfredo

                    

                    --
                    

                      

                        Luigi Alfredo Grieco, PhD

                      
Assistant
                        Professor

                      
Department
                        of Electrical and Information Engineering

                      

                        Politecnico di Bari

                      
Via
                        Orabona 4 - 70125 - Bari - Italy

                      
                      
                      
Skype
                        id: l.alfredo.grieco

                      
                    

                    

                      


                      

                    

                  

                

                

                  

                    

                      

                      On 19 Mar 2013, at 01:09, "Qin Wang" <qinwang@berkeley.edu>
                      wrote:

                      

                    

                    

                      
Alfredo,

                        

                        I think there are two key features in your
                          description: (1)data with high

                        priority, and (2)mobility. I would like to
                          think the two feature

                        separately.

                        

                        Regarding to the high priority, I think
                          the QoS mechanism like DSCP can

                        handle it, no matter the data flow come
                          from static node or moving node.

                        

                        Regarding to the mobility, the 6tus can
                          support to establish tracks for

                        specific purpose. Actually, the cell
                          reservation request comes from upper

                        layer, 6tus do not know the reserved cells
                          will be used by static nodes or

                        mobile nodes. In another word, upper layer
                          can ask 6tus to reserve some

                        cells or tracks or pipes which
                          specifically used for mobile node to send

                        data as you said.

                        

                        Does it make sense?

                        

                        Qin

                        

                        

                        

                        


                        

                        
Hi Xavi, Thomas,
                            all

                        

                        


                        

                        
The problem I am
                            pointing out is not related only to the
                            neighbourhood. As

                        

                        
a matter of fact,
                            a node would like its data be received to
                            the sink and

                        

                        
not only at the
                            next hop. If for each hop to travel, a data
                            packet should

                        

                        
gain a cell
                            through some request/answer handshake this
                            would lead to high

                        

                        
e2e delays when
                            the depth of the tree is high and would
                            incur useless

                        

                        
signalling.

                        

                        


                        

                        
If we think at
                            TASA, to do an example, the schedule exactly
                            rules the

                        

                        
story of each
                            packet from its generating node to the sink.
                            I was trying to

                        

                        
figure out how to
                            do the same in presence of some uncertainty
                            on the

                        

                        
network topology.

                        

                        


                        

                        
While solving this
                            problem is something to be afforded in some
                            scientific

                        

                        
paper, I believe
                            that the functionalities of 6tus and the
                            entire

                        

                        
architecture we
                            are envisaging should be ready to welcome
                            this new wave of

                        

                        
algorithms.

                        

                        


                        

                        
In other terms, I
                            am proposing to add a limited number of
                            "reserved pipes"

                        

                        
to the sink that
                            could be used to transport "only" urgent
                            data from mobile

                        

                        
nodes.

                        

                        

                          

                        

                        
Thomas, this could
                            be added as general remark to the
                            architecture or to

                        

                        
the draft you are
                            editing. Of course, with more details, some
                            primitive to

                        

                        
the 6tus draft
                            could be added or lead to a new draft on
                            handling mobile

                        

                        
6tsch nodes.

                        

                        

                          

                        

                        
Cheers :-)

                        

                        


                        

                        


                        

                        

                          --

                        

                        
Luigi Alfredo
                            Grieco, PhD

                        

                        
Assistant
                            Professor

                        

                        
Department of
                            Electrical and Information Engineering

                        

                        
Politecnico di
                            Bari

                        

                        
Via Orabona 4 -
                            70125 - Bari - Italy

                        

                        
+39
                              080 5963 911

                        

                        
telematics.poliba.it/grieco

                        

                        
Skype id:
                            l.alfredo.grieco

                        

                        
Mobile: +39
                              3346715672

                        

                        


                        

                        

                          

                        

                        
On 18 Mar 2013, at
                            20:40, Xavier Vilajosana

                        

                        
<xvilajosana@eecs.berkeley.edu>
                            wrote:

                        

                        


                        

                        

                          
Hi Alfredo,

                          

                        

                        

                          


                          

                        

                        

                          
just one point
                              on mobility.

                          

                        

                        

                          
TSCH networks
                              may require certain time for a node to
                              join, this depends

                          

                        

                        

                          
on how the EBs
                              are sent and what are the policies for the
                              joining node

                          

                        

                        

                          

                            on how to scan the different channels.
                              Having said that, I think that

                          

                        

                        

                          
the time
                              required for a node to reserve some cells
                              with its neighbour is

                          

                        

                        

                          
extremely less
                              than the joining time and hence if a
                              mobile node can join

                          

                        

                        

                          

                            the network for sure has time to
                              schedule some links. So maybe this is

                          

                        

                        

                          
not a big
                              problem :-)

                          

                        

                        

                          


                          

                        

                        

                          
cheers!

                          

                        

                        

                          

                            Xavi

                          

                        

                        

                          


                          

                        

                        

                          


                          

                        

                        

                          


                          

                        

                        

                          


                          

                        

                        

                          

                            On 18/03/13 12:36, Grieco wrote:

                          

                        

                        

                          

                            
Hi Qin,
                                Thomas, and all

                            

                          

                        

                        

                          

                            


                            

                          

                        

                        

                          

                            
Perhaps the
                                only way to cope with (a reasonable
                                degree of) mobility is

                            

                          

                        

                        

                          

                            
to hardly
                                assign a certain number of cells at each
                                link to be used in

                            

                          

                        

                        

                          

                            
case a mobile
                                node arrives with urgent data to
                                transmit.

                            

                          

                        

                        

                          

                            


                            

                          

                        

                        

                          

                            
Obviously this
                                would slightly decrease the overall
                                efficiency of the

                            

                          

                        

                        

                          

                            
system because
                                such "guaranteed cells" could get unused
                                in most of

                            

                          

                        

                        

                          

                            
cases.

                            

                          

                        

                        

                          

                            


                            

                          

                        

                        

                          

                            
If, on the
                                other side, the mobile node is
                                generating data which is not

                            

                          

                        

                        

                          

                            
that urgent,
                                soft reservation could be used as well,
                                which should waste

                            

                          

                        

                        

                          

                            
a smaller
                                amount of resources.

                            

                          

                        

                        

                          

                            


                            

                          

                        

                        

                          

                            
In this
                                perspective, mobile nodes could be
                                handled using either

                            

                          

                        

                        

                          

                            
functions 1 or
                                2, depending on the degree of mobility,
                                the priority of

                            

                          

                        

                        

                          

                            
the data
                                packets generated by mobile nodes, the
                                desired duty cycle, and

                            

                          

                        

                        

                          

                            
so on.

                            

                          

                        

                        

                          

                            


                            

                          

                        

                        

                          

                            
Cheers

                            

                          

                        

                        

                          

                            


                            

                          

                        

                        

                          

                            
Alfredo

                            

                          

                        

                        

                          

                            


                            

                          

                        

                        

                          

                            


                            

                          

                        

                        

                          

                            

                              

                            

                          

                        

                        

                          

                            


                            

                          

                        

                        

                          

                            
--

                            

                          

                        

                        

                          

                            
Luigi Alfredo
                                Grieco, PhD

                            

                          

                        

                        

                          

                            
Assistant
                                Professor

                            

                          

                        

                        

                          

                            

                              Department of Electrical and
                                Information Engineering

                            

                          

                        

                        

                          

                            
Politecnico di
                                Bari

                            

                          

                        

                        

                          

                            
Via Orabona 4
                                - 70125 - Bari - Italy

                            

                          

                        

                        

                          

                            
+39
                                  080 5963 911

                            

                          

                        

                        

                          

                            
telematics.poliba.it/grieco

                            

                          

                        

                        

                          

                            

                              Skype id: l.alfredo.grieco

                            

                          

                        

                        

                          

                            
Mobile: +39
                                  3346715672

                            

                          

                        

                        

                          

                            


                            

                          

                        

                        

                          

                            

                              

                            

                          

                        

                        

                          

                            
On 18 Mar
                                2013, at 20:20, "Qin Wang" <qinwang@berkeley.edu>
                                wrote:

                            

                          

                        

                        

                          

                            


                            

                          

                        

                        

                          

                            

                              
Alfredo,

                              

                            

                          

                        

                        

                          

                            

                              


                              

                            

                          

                        

                        

                          

                            

                              
I think your
                                  remark is correct. So, if there is
                                  lots of mobility, I

                              

                            

                          

                        

                        

                          

                            

                              
would

                              

                            

                          

                        

                        

                          

                            

                              
be prefer
                                  distributed approach, i.e. Soft Cell
                                  reservation locally +

                              

                            

                          

                        

                        

                          

                            

                              
RPL +

                              

                            

                          

                        

                        

                          

                            

                              

                                DSCP for QoS.

                              

                            

                          

                        

                        

                          

                            

                              


                              

                            

                          

                        

                        

                          

                            

                              
Qin

                              

                            

                          

                        

                        

                          

                            

                              


                              

                            

                          

                        

                        

                          

                            

                              


                              

                            

                          

                        

                        

                          

                            

                              

                                
Hi Qin,

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Your
                                    proposal is sound.

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Just a
                                    final remark: if my understanding is
                                    correct, the PCE should

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
build

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
a schedule
                                    that spans across multiple links
                                    from mobile node M

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
towards
                                    the

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
sink S.

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
If a M
                                    moves after the schedule has been
                                    built, some pre-assigned

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
resources
                                    along that path could get lost
                                    (which could be tolerated)

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
because of
                                    the change of the topology.

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Is it ok ?

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Cheers and
                                    thanks for your answer

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Alfredo

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
-----Messaggio
                                    originale-----

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Da: Qin
                                    Wang [mailto:qinwang@berkeley.edu]

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Inviato:
                                    Monday, March 18, 2013 6:48 PM

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
A: Grieco

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Cc: Qin
                                    Wang; JeongGil Ko; Pascal Thubert
                                    (pthubert); 6tsch@ietf.org;

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Xavier
                                    Vilajosana

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Oggetto:
                                    Re: [6tsch] Schemes for resource
                                    allocation in the LLN for

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
6tus

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Alfredo,

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Firstly,
                                    my understanding is Hard cell
                                    reservation can only be used

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
by

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
PCE, i.e.
                                     centralized schedule. Thus, mobile
                                    node will join in

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
network

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
based on
                                    the cells broadcast in EB. And,
                                    after its registration, PCE

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
will

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
assign
                                    some Hard cells to it.

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
secondly,
                                    regarding to high priority of the
                                    data flow from the mobile

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
node, DSCP
                                    may help, i.e. the packets from the
                                    mobile node can

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
include

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Priority.

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
How do you
                                    think?

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                
Qin

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
Hi Qin
                                      and all,

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
Just to
                                      challenge the two groups of
                                      functions Qin is talking about,

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    what if a certain number of
                                      mobile nodes need hard reservation
                                      ? In

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
this
                                      case, mobile nodes transmit Real
                                      time data to be delivered

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
within

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
a given
                                      deadline but 6tus does not know in
                                      advance the rank (or the

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    position within the topology)
                                      of such nodes.

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
I mean
                                      that this kind of traffic has the
                                      top priority but nobody

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
knows

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
in
                                      advance the exact position of the
                                      nodes that is going to generate

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
that
                                      data.

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    Do we need a further case ? Or
                                      we can leverage on 1 or 2 ? If
                                      yes,

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
how ?

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
Thanks a
                                      lot in advance for your attention

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
Cheers

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
Alfredo

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
--

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
Luigi
                                      Alfredo Grieco, PhD

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
Assistant
                                      Professor

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    Department of Electrical and
                                      Information Engineering
                                      Politecnico di

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
Bari Via
                                      Orabona 4 - 70125 - Bari - Italy

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
+39 080 5963 911

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    telematics.poliba.it/grieco

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
Skype
                                      id: l.alfredo.grieco

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  
Mobile:
                                      +39 3346715672

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    On 17 Mar 2013, at 17:47, "Qin
                                      Wang" <qinwang@berkeley.edu>
                                      wrote:

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    
I
                                        fully agree with Carsten that
                                        Simple is very important. Let's

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    
overlapping
                                        the following three scenarios,
                                        then we will find only

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    
two

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    
groups
                                        of functions 6tus should
                                        provide.

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    
(1)
                                        Hard cell reserve/remove, which
                                        supports the 1st scenario.

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    
(2)
                                        Soft cell reserve/remove, which
                                        supports the 2nd and 3rd

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      scenario.

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    
Any
                                        more?

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    
Qin

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
Sorry
                                          for the delayed response. I
                                          was stuck on the plane for too

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
long

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
:)

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
I
                                          like the discussion that Qin
                                          is going for where we define
                                          the

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
scenarios.

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
At
                                          the same time, as Carsten says
                                          we need to make sure
                                          overlapping

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
scenarios
                                          of any sort are simplified and
                                          aggregated as much as

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
possible.

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
Let
                                          me just try to put my 2 cents
                                          in-line...

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
On
                                          Mar 17, 2013, at 8:19 AM, Qin
                                          Wang <qinwang@berkeley.edu>

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
wrote:

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
Hi
                                            Pascal,

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
It
                                            is a very good idea to
                                            establish a bundle of cells
                                            between A

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
and

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
B
                                            by just triggering 6tus in
                                            one side. We can design for

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
different

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          scenarios.

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
(1)
                                            PCE defines the track, i.e.
                                            the multihop path, the
                                            bandwidth

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
of

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
each
                                            hop, and scheduling
                                            hard-cells to implement the
                                            multihop

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
path.

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          Assume nodeA and nodeB
                                            are one-hop neighbors along
                                            the path. In

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
this
                                            case, PCE can send
                                            Create.hardcell command to
                                            6tus layer in

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
nodeA,and
                                            nodeA's 6tus sends
                                            Create.hardcell command to
                                            nodeB'

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
6tus,
                                            then the hard cell is
                                            reserved. This function is
                                            not in the

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
current
                                            version of 6tus draft, but
                                            we can add it in the next

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
version
                                            easily.

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
(2)PCE
                                            defines the multihop path
                                            and the bandwidth of each
                                            hop,

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
but

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
not
                                            schedules the cells to meet
                                            the path bandwidth. In this
                                            case,

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
soft
                                            cell reservation will be
                                            applied, which is always
                                            triggered

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
in

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
Transmitting
                                            side, and negotiated by the
                                            6tus layer of both

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
sides.

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          (3)The cell reservation
                                            is triggered by upper layer,
                                            e.g. the

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
RSVP/NSIS
                                            entity in nodeA. Then soft
                                            cell reservation process in

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
6tus
                                            layer of nodeA will by
                                            triggered, and the
                                            negotiation

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
process

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
is
                                            same as case (2).

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
In
                                            summary, by adding reserve
                                            hard cell procedure into
                                            version-00

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
of
                                            6tus, we can let the bundle
                                            reservation in every
                                            scenarios be

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
triggered
                                            just in one side.

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
How
                                            do you think?

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
Great
                                          first start in defining the
                                          scenarios.

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
Qin

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            Hi Qin:

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
I
                                              think we are on the same
                                              line. The services that
                                              6TUS proposes

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
do
                                              not depend on which
                                              protocol the request came
                                              in through.

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
Since
                                              we are defining the
                                              protocol extensions, we'll
                                              make sure

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
that
                                              the new information is
                                              directly digestible by the
                                              6TUS

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
layer.

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
The
                                              protocol extensions will
                                              be separate specs, and
                                              there should

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
be
                                              little to no dereference
                                              between those specs and
                                              yours.

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            What's important to me
                                              to discuss is how we
                                              establish a bundle

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
of

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
cells
                                              between A and B.

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
IMHO,
                                              it would be best if that
                                              can be achieved by
                                              triggering a

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
service
                                              in A - no need to trigger
                                              B as well.

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
That
                                              way, the volume of
                                              exchanges between PCE and
                                              nodes can be

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
devided
                                              by 2.

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
This
                                              would mean that there must
                                              be an exchange between
                                              6TUS in A

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
and
                                              6TUS in B.

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
Which
                                               also would mean that
                                              there is a protocol part
                                              related to

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
6TUS…

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
Fully
                                          agreed that this is needed.
                                          Being an independent layer, I

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
don't
                                          see why not.

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
Cheers,

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
Pascal

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
-----Original
                                              Message-----

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
From:
                                              6tsch-bounces@ietf.org
                                              [mailto:6tsch-bounces@ietf.org]
                                              On

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
Behalf
                                              Of Qin Wang

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
Sent:
                                              vendredi 15 mars 2013
                                              18:04

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
To:
                                              JeongGil Ko

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
Cc:
                                              6tsch@ietf.org; Xavier
                                              Vilajosana

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
Subject:
                                              Re: [6tsch] Schemes for
                                              resource allocation in the
                                              LLN

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
for
                                              6tus

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
John
                                              and Xavi,

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
I
                                              agree that understanding
                                              more about upper layer
                                              protocols like

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
RSVP
                                              and NSIS is very helpful
                                              for designing 6tus. But, I
                                              want to

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
make
                                              clearer about my
                                              understanding on the
                                              relationship between

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
6tus
                                              and existing reservation
                                              protocols like RSVP or
                                              NSIS.

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            (1) When we talk about
                                              reservation in the context
                                              of 6tus, we

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
mainly
                                              focus on  link resource
                                              (i.e. cell) reservation,
                                              which is

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
required/
                                              triggered by upper layer.
                                              Even in the pure
                                              centralized

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
approach,
                                              it may happen to
                                              cross-layer reserve both
                                              L3 and L2

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
resource,
                                              but you still can separate
                                              them logically.

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
(2)
                                              The upper layer
                                              requirement to 6tus may
                                              come from PCE

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
carried

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
by
                                              protocol like CoAP, may
                                              come from the RSVP/NSIS
                                              entity inside

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
nodes.

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
Thus,
                                              for 6tus, the question is
                                              what kind of function and

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
interface
                                              should be provided to
                                              support the upper layer,
                                              instead

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
of
                                              which upper layer protocol
                                              should be used.

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
How
                                              do you think?

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        I agree with your
                                          arguments that the important
                                          thing is defining

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
the

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        functionalities. It seems
                                          like some of these efforts are
                                          on the

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
way

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        in the later emails. Me
                                          bringing in the term "RSVP"
                                          was not that I

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
wanted
                                          to go an use RSVP in the way
                                          it is, but bring the

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
(modified/customized)
                                          concept in for use in 6tus. As
                                          to what I

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
read

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
there
                                          may have been a
                                          misunderstanding between us
                                          but we are on

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
the

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
same
                                          line.

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
Thanks!

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      
-John

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
Qin

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    
_______________________________________________

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    
6tsch
                                        mailing list

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    
6tsch@ietf.org

                                    

                                  

                                

                              

                            

                          

                        

                        

                          

                            

                              

                                

                                  

                                    
https://www.ietf.org/mailman/listinfo/6tsch

                                    

                                  

                                

                              

                            

                          

                        

                        

                          


                          

                        

                        
_______________________________________________

                        

                        

                          6tsch mailing list

                        

                        
6tsch@ietf.org

                        

                        
https://www.ietf.org/mailman/listinfo/6tsch

                        

                        


                        

                        

                      

                    

                  

                

              

              

              _______________________________________________

              6tsch mailing list

              6tsch@ietf.org

              https://www.ietf.org/mailman/listinfo/6tsch

              

            

          

          

        

      

      

        
_______________________________________________

          6tsch mailing list

          6tsch@ietf.org

          https://www.ietf.org/mailman/listinfo/6tsch

        

      

      

      

      

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


    

    

  


--------------080905050005090404070101--

From twatteyne@gmail.com  Wed Mar 20 22:16:19 2013
Return-Path: 
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 0987E21F8F2F for <6tsch@ietfa.amsl.com>; Wed, 20 Mar 2013 22:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 RFEs-XuBLZi9 for <6tsch@ietfa.amsl.com>; Wed, 20 Mar 2013 22:16:18 -0700 (PDT)
Received: from mail-da0-x236.google.com (mail-da0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 036B021F8F0B for <6tsch@ietf.org>; Wed, 20 Mar 2013 22:16:17 -0700 (PDT)
Received: by mail-da0-f54.google.com with SMTP id p1so1418663dad.27 for <6tsch@ietf.org>; Wed, 20 Mar 2013 22:16:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=yXx68r8LGE2DJ/OzMY4eVFprJLxyDFzQynv1JXeXOhM=; b=PFaHcCVyYwCuKzDIL79G0g25x9ELb6vRLUHvqEeP3iW2DwxMhxDBSNC1kbnUHBMAM0 rbmUAMOMyiEQ6NaD/cjp4uGvKVn8vN5n6A64m6N/OUWTeGIzob+7tgwqp62a9ES7z8UO VpjiTDD8fQ/rB6IHsa1k+bpPU2fnwn63hzTSb33pm/4WUabaqv6O1kQrUwnPE7e4YHNe 7ymy+S+2aNleYR4TKvZ9gPRjas5SKo77igAVEhC5VvgxJ3dlUuYHZPbygg4aph/UTBKp 9QN0/oVZkI+1AlccHrriLnaVUtghlVJmZHtON2rU1EY6dhB3naVk8xQkIop3Zfadndx0 jQbA==
X-Received: by 10.66.163.69 with SMTP id yg5mr13072310pab.109.1363842977694; Wed, 20 Mar 2013 22:16:17 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Wed, 20 Mar 2013 22:15:56 -0700 (PDT)
In-Reply-To: 
References: 
From: Thomas Watteyne 
Date: Wed, 20 Mar 2013 22:15:56 -0700
X-Google-Sender-Auth: zgSdojehmQqPzuZhCHBYhIHTyHI
Message-ID: 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b6d8186370b0404d868706a
Subject: Re: [6tsch] focussing on charter: use cases
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 05:16:19 -0000

--047d7b6d8186370b0404d868706a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Pascal, all,

Absolutely agreed. I believe we have started exploring quite a bit, enough
to have a clear understanding of what we can achieve with this technology
as a WG. So let's spend some time on use cases and building a good case to
convince an AD.

We could start by listing what TSCH is "good at", and what makes it
different from other solutions. I see the following:
- reliability: 5 9's of end-to-end reliability are commonplace.
- low-power: aggressive radio duty cycling of the mote's radio yields much
longer lifetime in battery-powered devices.
- traffic engineering: the clear identification of resources allows for
flow independence and QoS.

Of course, from those points, industrial applications immediately come to
mind. Yet, we could take use cases from other areas. We could for example
take the ROLL requirement drafts as a skeleton (I'm paraphrasing some of
the points Xavi and Alfredo made).

- industrial automation. A 6TSCH network can allow for high reliability,
and deterministic behavior. Link over-provisioning can efficiently combat
the unreliable nature of wireless and provide a robust communication.
- building automation. A 6TSCH network can serve as an "umbrella" network
for a large number of sensing points in the building. These sensing points
can be owned and operated by different entities (e.g. HVAC and lighting).
The 6TSCH network allows for the different traffic flows to stay
independent from one another.
- because of a 6TSCH node is deeply duty cycle, remote sensing application
(e.g. agricultural applications) can rely on energy harvesting as power
source.
- A smart urban parking application can benefit from the reliabilty of
 6TSCH network since, even though the vehicle detection sensor may be
static, the constant movement of cars around the sensing points can cause
the wireless environment to quickly change.

Thomas

On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

>  Dear ML:****
>
> ** **
>
> The activity that we generate on the mailing list is a good indication we
> will be very successful as a WG. First thing first, though, we need to
> create the WG and need to focus a little bit on the necessary steps to ge=
t
> there.****
>
> ** **
>
> We need to put together a rough charter, and convince an AD, probably
> Adrian from Routing Area or Ted from Internet Area, that we have real
> problems to solve and that we, as a group, can provide valuable answers.
> The ADs agendas are very full all the time, but certainly peaks around th=
e
> meeting times. So we have about 2 week in front of us to prepare a solid
> case.****
>
> ** **
>
> So I suggest we step back a minute from the details of time frames and
> priorities and spend some energy on the use cases, the problems we are
> solving, and the work we have to do to get there. I notice a cool
> discussion on mobility and the particular case of a crane, well that=92s =
a
> use case. We already had centralized deterministic (hard slot) routes for
> command and control, distributed deterministic (soft slots) and non
> deterministic QoS based flows. Do we have others cases?****
>
> ****
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> ** **
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

--047d7b6d8186370b0404d868706a
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Pascal, all,

Absolutely agreed. I believe we have starte=
d exploring quite a bit, enough to have a clear understanding of what we ca=
n achieve with this technology as a WG. So let's spend some time on use=
 cases and building a good case to convince an AD.




We could start by listing what TSCH is "good at&qu=
ot;, and what makes it different from other solutions. I see the following:=

- reliability: 5 9's of end-to-end reliability are commonpla=
ce.



- low-power:=A0aggressive=A0radio duty cycling of the mote's radio=
 yields much longer lifetime in battery-powered devices.
- traffi=
c engineering: the clear identification of resources allows for flow indepe=
ndence and QoS.




Of course, from those points=
, industrial applications immediately come to mind. Yet, we could take use =
cases from other areas. We could for example take the ROLL requirement draf=
ts as a skeleton (I'm paraphrasing some of the points Xavi and Alfredo =
made). 




- industrial automation. A 6TSCH network can allow for high =
reliability, and=A0deterministic=A0behavior. Link over-provisioning can eff=
iciently combat the unreliable nature of wireless and provide a robust comm=
unication.=A0



- building automation. A 6TSCH network can serve=
 as an "umbrella" network for a large number of sensing points in=
 the building. These sensing points can be owned and operated by different =
entities (e.g. HVAC and lighting). The 6TSCH network allows for the differe=
nt traffic flows to stay independent from one another.



- because of a 6TSCH node is deeply duty cycle, =
remote sensing application (e.g. agricultural applications) can rely on ene=
rgy harvesting as power source.
- A smart u=
rban parking application can benefit from the reliabilty of =A06TSCH networ=
k since, even though the vehicle detection sensor may be static, the consta=
nt movement of cars around the sensing points can cause the wireless enviro=
nment to quickly change.




Thomas

On Tue, Ma=
r 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) <pthubert@cisco.com=
> wrote:














Dear ML:


=A0


The activity that we generate on the mailing list is=
 a good indication we will be very successful as a WG. First thing first, t=
hough, we need to create the WG and need to focus a little bit on the neces=
sary steps to get there.




=A0


We need to put together a rough charter, and convinc=
e an AD, probably Adrian from Routing Area or Ted from Internet Area, that =
we have real problems to solve and that we, as a group, can provide valuabl=
e answers. The ADs agendas are very
 full all the time, but certainly peaks around the meeting times. So we hav=
e about 2 week in front of us to prepare a solid case.


=A0


So I suggest we step back a minute from the details =
of time frames and priorities and spend some energy on the use cases, the p=
roblems we are solving, and the work we have to do to get there. I notice a=
 cool discussion on mobility and the
 particular case of a crane, well that=92s a use case. We already had centr=
alized deterministic (hard slot) routes for command and control, distribute=
d deterministic (soft slots) and non deterministic QoS based flows. Do we h=
ave others cases?






Cheers,


=A0


Pascal


=A0


=A0







_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





--047d7b6d8186370b0404d868706a--

From qinwang@berkeley.edu  Thu Mar 21 07:52:06 2013
Return-Path: 
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 12BD221F90BC for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 07:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.492
X-Spam-Level: 
X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 zCdZYrcNniAd for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 07:52:04 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id CB8D121F9083 for <6tsch@ietf.org>; Thu, 21 Mar 2013 07:52:04 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UIgqZ-0007sh-Js; Thu, 21 Mar 2013 07:52:04 -0700
Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Thu, 21 Mar 2013 07:52:03 -0700
Message-ID: <0684a7f8d22904729c69741e6e1e44fd.squirrel@calmail.berkeley.edu>
In-Reply-To: 
References:  
Date: Thu, 21 Mar 2013 07:52:03 -0700
From: "Qin Wang" 
To: "Thomas Watteyne" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] focussing on charter: use cases
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 14:52:06 -0000

Pascal and Thomas,

I agree it is very important to specify the use cases which 6tus will
support. Here is some comments and suggestions.

(1) Regarding to industry automation, I think it may be better to describe
Process Automation and Factory Automation separately.

(2) Other potential use cases:
   - Health care
   - Asset tracking and monitoring
   - Location based service

Qin



> Pascal, all,
>
> Absolutely agreed. I believe we have started exploring quite a bit, enough
> to have a clear understanding of what we can achieve with this technology
> as a WG. So let's spend some time on use cases and building a good case to
> convince an AD.
>
> We could start by listing what TSCH is "good at", and what makes it
> different from other solutions. I see the following:
> - reliability: 5 9's of end-to-end reliability are commonplace.
> - low-power: aggressive radio duty cycling of the mote's radio yields much
> longer lifetime in battery-powered devices.
> - traffic engineering: the clear identification of resources allows for
> flow independence and QoS.
>
> Of course, from those points, industrial applications immediately come to
> mind. Yet, we could take use cases from other areas. We could for example
> take the ROLL requirement drafts as a skeleton (I'm paraphrasing some of
> the points Xavi and Alfredo made).
>
> - industrial automation. A 6TSCH network can allow for high reliability,
> and deterministic behavior. Link over-provisioning can efficiently combat
> the unreliable nature of wireless and provide a robust communication.
> - building automation. A 6TSCH network can serve as an "umbrella" network
> for a large number of sensing points in the building. These sensing points
> can be owned and operated by different entities (e.g. HVAC and lighting).
> The 6TSCH network allows for the different traffic flows to stay
> independent from one another.
> - because of a 6TSCH node is deeply duty cycle, remote sensing application
> (e.g. agricultural applications) can rely on energy harvesting as power
> source.
> - A smart urban parking application can benefit from the reliabilty of
>  6TSCH network since, even though the vehicle detection sensor may be
> static, the constant movement of cars around the sensing points can cause
> the wireless environment to quickly change.
>
> Thomas
>
> On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) <
> pthubert@cisco.com> wrote:
>
>>  Dear ML:****
>>
>> ** **
>>
>> The activity that we generate on the mailing list is a good indication
>> we
>> will be very successful as a WG. First thing first, though, we need to
>> create the WG and need to focus a little bit on the necessary steps to
>> get
>> there.****
>>
>> ** **
>>
>> We need to put together a rough charter, and convince an AD, probably
>> Adrian from Routing Area or Ted from Internet Area, that we have real
>> problems to solve and that we, as a group, can provide valuable answers.
>> The ADs agendas are very full all the time, but certainly peaks around
>> the
>> meeting times. So we have about 2 week in front of us to prepare a solid
>> case.****
>>
>> ** **
>>
>> So I suggest we step back a minute from the details of time frames and
>> priorities and spend some energy on the use cases, the problems we are
>> solving, and the work we have to do to get there. I notice a cool
>> discussion on mobility and the particular case of a crane, well that’s a
>> use case. We already had centralized deterministic (hard slot) routes
>> for
>> command and control, distributed deterministic (soft slots) and non
>> deterministic QoS based flows. Do we have others cases?****
>>
>> ****
>>
>> Cheers,****
>>
>> ** **
>>
>> Pascal****
>>
>> ** **
>>
>> ** **
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


From marc.blanchet@viagenie.ca  Thu Mar 21 08:28:11 2013
Return-Path: 
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 32D2421F913E for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 08:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.498
X-Spam-Level: 
X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 NHNJBgfT-Cue for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 08:28:10 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E76A621F9142 for <6tsch@ietf.org>; Thu, 21 Mar 2013 08:28:08 -0700 (PDT)
Received: from h111.viagenie.ca (h111.viagenie.ca [206.123.31.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 29C7E403E9; Thu, 21 Mar 2013 11:28:08 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F308F7A3-3910-42B5-9851-E1A7DFF937D9"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Marc Blanchet 
In-Reply-To: 
Date: Thu, 21 Mar 2013 11:28:02 -0400
Message-Id: <962FC5C7-C2AF-4809-BAC9-00CFE71E90C5@viagenie.ca>
References:  
To: Thomas Watteyne 
X-Mailer: Apple Mail (2.1503)
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] focussing on charter: use cases
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 15:28:12 -0000

--Apple-Mail=_F308F7A3-3910-42B5-9851-E1A7DFF937D9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


Le 2013-03-21 =E0 01:15, Thomas Watteyne  a =
=E9crit :

> Pascal, all,
>=20
> Absolutely agreed. I believe we have started exploring quite a bit, =
enough to have a clear understanding of what we can achieve with this =
technology as a WG. So let's spend some time on use cases and building a =
good case to convince an AD.

A proposed charter should have at least the following:
a) problem statement/use cases
b) what needs to be done in IETF
c) some milestones

b) is as important as a) for an AD  (and c) too).

Marc.


>=20
> We could start by listing what TSCH is "good at", and what makes it =
different from other solutions. I see the following:
> - reliability: 5 9's of end-to-end reliability are commonplace.
> - low-power: aggressive radio duty cycling of the mote's radio yields =
much longer lifetime in battery-powered devices.
> - traffic engineering: the clear identification of resources allows =
for flow independence and QoS.
>=20
> Of course, from those points, industrial applications immediately come =
to mind. Yet, we could take use cases from other areas. We could for =
example take the ROLL requirement drafts as a skeleton (I'm paraphrasing =
some of the points Xavi and Alfredo made).
>=20
> - industrial automation. A 6TSCH network can allow for high =
reliability, and deterministic behavior. Link over-provisioning can =
efficiently combat the unreliable nature of wireless and provide a =
robust communication.=20
> - building automation. A 6TSCH network can serve as an "umbrella" =
network for a large number of sensing points in the building. These =
sensing points can be owned and operated by different entities (e.g. =
HVAC and lighting). The 6TSCH network allows for the different traffic =
flows to stay independent from one another.
> - because of a 6TSCH node is deeply duty cycle, remote sensing =
application (e.g. agricultural applications) can rely on energy =
harvesting as power source.
> - A smart urban parking application can benefit from the reliabilty of =
 6TSCH network since, even though the vehicle detection sensor may be =
static, the constant movement of cars around the sensing points can =
cause the wireless environment to quickly change.
>=20
> Thomas
>=20
> On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) =
 wrote:
> Dear ML:
>=20
> =20
>=20
> The activity that we generate on the mailing list is a good indication =
we will be very successful as a WG. First thing first, though, we need =
to create the WG and need to focus a little bit on the necessary steps =
to get there.
>=20
> =20
>=20
> We need to put together a rough charter, and convince an AD, probably =
Adrian from Routing Area or Ted from Internet Area, that we have real =
problems to solve and that we, as a group, can provide valuable answers. =
The ADs agendas are very full all the time, but certainly peaks around =
the meeting times. So we have about 2 week in front of us to prepare a =
solid case.
>=20
> =20
>=20
> So I suggest we step back a minute from the details of time frames and =
priorities and spend some energy on the use cases, the problems we are =
solving, and the work we have to do to get there. I notice a cool =
discussion on mobility and the particular case of a crane, well that=92s =
a use case. We already had centralized deterministic (hard slot) routes =
for command and control, distributed deterministic (soft slots) and non =
deterministic QoS based flows. Do we have others cases?
>=20
>=20
> Cheers,
>=20
> =20
>=20
> Pascal
>=20
> =20
>=20
> =20
>=20
>=20
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>=20
>=20
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


--Apple-Mail=_F308F7A3-3910-42B5-9851-E1A7DFF937D9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

watteyne@eecs.berkeley.edu&=
gt; a =E9crit :

Pascal, all,

Absolutely agreed. I =
believe we have started exploring quite a bit, enough to have a clear =
understanding of what we can achieve with this technology as a WG. So =
let's spend some time on use cases and building a good case to convince =
an AD.

A proposed charter should =
have at least the following:
a) problem statement/use =
cases
b) what needs to be done in IETF
c) some =
milestones

b) is as important as a) for an AD =
 (and c) =
too).

Marc.






We could start by listing what TSCH is "good at", =
and what makes it different from other solutions. I see the =
following:
- reliability: 5 9's of end-to-end reliability are =
commonplace.



- low-power: aggressive radio duty cycling of the mote's =
radio yields much longer lifetime in battery-powered =
devices.
- traffic engineering: the clear identification of =
resources allows for flow independence and QoS.




Of course, from those =
points, industrial applications immediately come to mind. Yet, we could =
take use cases from other areas. We could for example take the ROLL =
requirement drafts as a skeleton (I'm paraphrasing some of the points =
Xavi and Alfredo made). 




- industrial automation. A 6TSCH network can =
allow for high reliability, and deterministic behavior. Link =
over-provisioning can efficiently combat the unreliable nature of =
wireless and provide a robust communication. 



- building automation. A 6TSCH network can =
serve as an "umbrella" network for a large number of sensing points in =
the building. These sensing points can be owned and operated by =
different entities (e.g. HVAC and lighting). The 6TSCH network allows =
for the different traffic flows to stay independent from one =
another.



- because of a 6TSCH node is deeply duty =
cycle, remote sensing application (e.g. agricultural applications) can =
rely on energy harvesting as power source.
- A smart urban parking application can benefit =
from the reliabilty of  6TSCH network since, even though the =
vehicle detection sensor may be static, the constant movement of cars =
around the sensing points can cause the wireless environment to quickly =
change.




Thomas

On Tue, Mar =
19, 2013 at 12:08 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:












Dear ML:
 
The =
activity that we generate on the mailing list is a good indication we =
will be very successful as a WG. First thing first, though, we need to =
create the WG and need to focus a little bit on the necessary steps to =
get there.
 
We =
need to put together a rough charter, and convince an AD, probably =
Adrian from Routing Area or Ted from Internet Area, that we have real =
problems to solve and that we, as a group, can provide valuable answers. =
The ADs agendas are very
 full all the time, but certainly peaks around the meeting times. So we =
have about 2 week in front of us to prepare a solid =
case.
 
So I suggest we step back a minute from the details =
of time frames and priorities and spend some energy on the use cases, =
the problems we are solving, and the work we have to do to get there. I =
notice a cool discussion on mobility and the
 particular case of a crane, well that=92s a use case. We already had =
centralized deterministic (hard slot) routes for command and control, =
distributed deterministic (soft slots) and non deterministic QoS based =
flows. Do we have others cases?
Cheers,
 
Pascal
 
 







_______________________________________________

6tsch mailing list

6tsch@ietf.org

https://www.ietf.org/mailman/listinfo/6tsch




_______________________________________________
6tsch mailing =
list
6tsch@ietf.org
https://www.ietf.org/=
mailman/listinfo/6tsch

=

--Apple-Mail=_F308F7A3-3910-42B5-9851-E1A7DFF937D9--

From pthubert@cisco.com  Thu Mar 21 08:52:53 2013
Return-Path: 
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 18BC221F9129 for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 08:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 DG-yPv7tthjP for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 08:52:52 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD9521F9128 for <6tsch@ietf.org>; Thu, 21 Mar 2013 08:52:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7764; q=dns/txt; s=iport; t=1363881172; x=1365090772; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FAM0fD2MUYcjpsrPnjPI7SHlA1ui+ECtJNpopwMecQE=; b=daeL1LKARlXJVVRPQHZFKNaXilzfrif7GioEfnJuum9a7hmiThpFM0ze nO6quHS2OzWowgGPzMBt0wQTk7SS0dPFZvXMgN9GCZ+tSapNPS9SqsuHb /ovoSoC26yt4zLLoRBFXSe5b/eg57cNfwCbHpMg3KKQDHNO8QkL6YO+7M s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAAoqS1GtJV2c/2dsb2JhbABDDogRvRdrbRZ0giQBAQEDAQEBASAROgsFBwQCAQgRBAEBAQICBh0DAgICJQsUAQgIAgQBDQUIE4dzBgywTJI9BIEjjCgXfiYLBwaCJzJhA6dmgks/gig
X-IronPort-AV: E=Sophos;i="4.84,887,1355097600"; d="scan'208";a="190015534"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 21 Mar 2013 15:52:51 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2LFqpK4029741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 15:52:51 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 10:52:51 -0500
From: "Pascal Thubert (pthubert)" 
To: Qin Wang , Thomas Watteyne 
Thread-Topic: [6tsch] focussing on charter: use cases
Thread-Index: AQHOJkOrlF66vDjlP0Gzpg2SDIP3GpiwPG7Q
Date: Thu, 21 Mar 2013 15:52:50 +0000
Deferred-Delivery: Thu, 21 Mar 2013 15:52:00 +0000
Message-ID: 
References:   <0684a7f8d22904729c69741e6e1e44fd.squirrel@calmail.berkeley.edu>
In-Reply-To: <0684a7f8d22904729c69741e6e1e44fd.squirrel@calmail.berkeley.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.49.80.30]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] focussing on charter: use cases
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 15:52:53 -0000

SSBhZ3JlZSBRaW4uDQoNCkZhY3RvcnkgYXV0b21hdGlvbiBpcyBvdXQgb2Ygc2NvcGUuIFdlIGNh
biByZWZlciB0byBUb20ncyBhbmFseXNpcyB0byBzaG93IHRoYXQuDQpBbmQgeWVzLCBQcm9jZXNz
IGNvbnRyb2wgaXMgdGhlIHNvdXJjZSBvZiBtb3N0IG9mIG91ciB1c2UgY2FzZSwgYWdhaW4gcGVy
IFRvbSdzIGRyYWZ0IGluIFJPTEwuDQoNCkkgdGhpbmsgd2UgY2FuIGZpbmQgYSBudW1iZXIgb2Yg
dXNlIGNhc2VzIHRoYXQgbGV2ZXJhZ2UgdGhlIGNhcGFiaWxpdGllcyB0aGF0IFRob21hcyBwb2lu
dGVkIG91dCBpbiAqLWF1dG9tYXRpb24gKGFwYXJ0IGZyb20gZmFjdG9yeTogKSkgLCB3aGV0aGVy
IGl0IGlzIG9wZW4gb3IgY2xvc2VkIGxvb3AuDQotIGJ1aWxkaW5nIGF1dG9tYXRpb24uIFdlIGNh
biByZXBsYWNlIGEgbnVtYmVyIG9mIGV4aXN0aW5nIHByb3ByaWV0YXJ5IHRlY2hub2xvZ2llcyB3
aXRoIDZUU0NIIHRvIGNvbnRyb2wgdGhlIGJ1aWxkaW5nIGVuZXJneSBzcGVuZGluZy4NCi0gdmVo
aWN1bGFyIGF1dG9tYXRpb24uIFdlIGNhbiBzYXZlIGNvcHBlciBmb3IgbW9zdCBvZiB0aGUgbWFu
IHRvIG1hY2hpbmUgaW50ZXJmYWNlcywgd2hpY2ggdHJhbnNsYXRlcyBpbiBib3RoIGxvd2VyIHBy
aWNlIGFuZCBsb3dlciBnYXMgY29uc3VtcHRpb24uDQotIGNvbW1lcmNpYWwgYXV0b21hdGlvbi4g
QXMgeW91IHN1Z2dlc3QsIHdlIGNhbiBkbyBhc3NldCB0cmFja2luZyBvcGVyYXRpb25zIG9uIHRo
ZSBtb3ZlLCByZXBvcnQgdGVtcGVyYXR1cmUgb2YgZnJlZXplcnMuDQoNCkZvciBoZWFsdGggY2Fy
ZSwgSSdkIGFncmVlIGJ1dCB3ZSBoYXZlIHRvIGJlIHZlcnkgY2F1dGlvdXMgaW4gd2hhdCB3ZSBj
bGFpbS4gVGhlcmUgaXMgc28gbXVjaCByZWd1bGF0aW9uIGFyb3VuZCB0aGF0IHdlIGNhbm5vdCBj
b21taXQgdGhhdCB0aGUgdGVjaG5vbG9neSBpcyBnb29kIGVub3VnaCB0byByZXBsYWNlIGEgd2ly
ZSB3aGljaCBpcyBzb21ldGltZXMgaW1wb3NlZCBieSBsYXcsIGFjdHVhbGx5LiANCg0KQmFzaWNh
bGx5LCBJJ2Qgc2F5IHRoYXQgNlRTQ0ggY2FuIHBsYXkgbWFueSBwbGFjZXMgd2hlcmUgcGVvcGxl
IGV4cGVjdGVkIHppZ2JlZSBidXQgZGlkIG5vdCBmaW5kIGl0IHJlbGlhYmxlIGVub3VnaC4gDQoN
ClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiA2dHNjaC1ib3Vu
Y2VzQGlldGYub3JnIFttYWlsdG86NnRzY2gtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IFFpbiBXYW5nDQpTZW50OiBqZXVkaSAyMSBtYXJzIDIwMTMgMTU6NTINClRvOiBUaG9tYXMgV2F0
dGV5bmUNCkNjOiA2dHNjaEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFs2dHNjaF0gZm9jdXNzaW5n
IG9uIGNoYXJ0ZXI6IHVzZSBjYXNlcw0KDQpQYXNjYWwgYW5kIFRob21hcywNCg0KSSBhZ3JlZSBp
dCBpcyB2ZXJ5IGltcG9ydGFudCB0byBzcGVjaWZ5IHRoZSB1c2UgY2FzZXMgd2hpY2ggNnR1cyB3
aWxsIHN1cHBvcnQuIEhlcmUgaXMgc29tZSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuDQoNCigx
KSBSZWdhcmRpbmcgdG8gaW5kdXN0cnkgYXV0b21hdGlvbiwgSSB0aGluayBpdCBtYXkgYmUgYmV0
dGVyIHRvIGRlc2NyaWJlIFByb2Nlc3MgQXV0b21hdGlvbiBhbmQgRmFjdG9yeSBBdXRvbWF0aW9u
IHNlcGFyYXRlbHkuDQoNCigyKSBPdGhlciBwb3RlbnRpYWwgdXNlIGNhc2VzOg0KICAgLSBIZWFs
dGggY2FyZQ0KICAgLSBBc3NldCB0cmFja2luZyBhbmQgbW9uaXRvcmluZw0KICAgLSBMb2NhdGlv
biBiYXNlZCBzZXJ2aWNlDQoNClFpbg0KDQoNCg0KPiBQYXNjYWwsIGFsbCwNCj4NCj4gQWJzb2x1
dGVseSBhZ3JlZWQuIEkgYmVsaWV2ZSB3ZSBoYXZlIHN0YXJ0ZWQgZXhwbG9yaW5nIHF1aXRlIGEg
Yml0LCANCj4gZW5vdWdoIHRvIGhhdmUgYSBjbGVhciB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgd2Ug
Y2FuIGFjaGlldmUgd2l0aCB0aGlzIA0KPiB0ZWNobm9sb2d5IGFzIGEgV0cuIFNvIGxldCdzIHNw
ZW5kIHNvbWUgdGltZSBvbiB1c2UgY2FzZXMgYW5kIGJ1aWxkaW5nIA0KPiBhIGdvb2QgY2FzZSB0
byBjb252aW5jZSBhbiBBRC4NCj4NCj4gV2UgY291bGQgc3RhcnQgYnkgbGlzdGluZyB3aGF0IFRT
Q0ggaXMgImdvb2QgYXQiLCBhbmQgd2hhdCBtYWtlcyBpdCANCj4gZGlmZmVyZW50IGZyb20gb3Ro
ZXIgc29sdXRpb25zLiBJIHNlZSB0aGUgZm9sbG93aW5nOg0KPiAtIHJlbGlhYmlsaXR5OiA1IDkn
cyBvZiBlbmQtdG8tZW5kIHJlbGlhYmlsaXR5IGFyZSBjb21tb25wbGFjZS4NCj4gLSBsb3ctcG93
ZXI6IGFnZ3Jlc3NpdmUgcmFkaW8gZHV0eSBjeWNsaW5nIG9mIHRoZSBtb3RlJ3MgcmFkaW8geWll
bGRzIA0KPiBtdWNoIGxvbmdlciBsaWZldGltZSBpbiBiYXR0ZXJ5LXBvd2VyZWQgZGV2aWNlcy4N
Cj4gLSB0cmFmZmljIGVuZ2luZWVyaW5nOiB0aGUgY2xlYXIgaWRlbnRpZmljYXRpb24gb2YgcmVz
b3VyY2VzIGFsbG93cyANCj4gZm9yIGZsb3cgaW5kZXBlbmRlbmNlIGFuZCBRb1MuDQo+DQo+IE9m
IGNvdXJzZSwgZnJvbSB0aG9zZSBwb2ludHMsIGluZHVzdHJpYWwgYXBwbGljYXRpb25zIGltbWVk
aWF0ZWx5IGNvbWUgDQo+IHRvIG1pbmQuIFlldCwgd2UgY291bGQgdGFrZSB1c2UgY2FzZXMgZnJv
bSBvdGhlciBhcmVhcy4gV2UgY291bGQgZm9yIA0KPiBleGFtcGxlIHRha2UgdGhlIFJPTEwgcmVx
dWlyZW1lbnQgZHJhZnRzIGFzIGEgc2tlbGV0b24gKEknbSANCj4gcGFyYXBocmFzaW5nIHNvbWUg
b2YgdGhlIHBvaW50cyBYYXZpIGFuZCBBbGZyZWRvIG1hZGUpLg0KPg0KPiAtIGluZHVzdHJpYWwg
YXV0b21hdGlvbi4gQSA2VFNDSCBuZXR3b3JrIGNhbiBhbGxvdyBmb3IgaGlnaCANCj4gcmVsaWFi
aWxpdHksIGFuZCBkZXRlcm1pbmlzdGljIGJlaGF2aW9yLiBMaW5rIG92ZXItcHJvdmlzaW9uaW5n
IGNhbiANCj4gZWZmaWNpZW50bHkgY29tYmF0IHRoZSB1bnJlbGlhYmxlIG5hdHVyZSBvZiB3aXJl
bGVzcyBhbmQgcHJvdmlkZSBhIHJvYnVzdCBjb21tdW5pY2F0aW9uLg0KPiAtIGJ1aWxkaW5nIGF1
dG9tYXRpb24uIEEgNlRTQ0ggbmV0d29yayBjYW4gc2VydmUgYXMgYW4gInVtYnJlbGxhIiANCj4g
bmV0d29yayBmb3IgYSBsYXJnZSBudW1iZXIgb2Ygc2Vuc2luZyBwb2ludHMgaW4gdGhlIGJ1aWxk
aW5nLiBUaGVzZSANCj4gc2Vuc2luZyBwb2ludHMgY2FuIGJlIG93bmVkIGFuZCBvcGVyYXRlZCBi
eSBkaWZmZXJlbnQgZW50aXRpZXMgKGUuZy4gSFZBQyBhbmQgbGlnaHRpbmcpLg0KPiBUaGUgNlRT
Q0ggbmV0d29yayBhbGxvd3MgZm9yIHRoZSBkaWZmZXJlbnQgdHJhZmZpYyBmbG93cyB0byBzdGF5
IA0KPiBpbmRlcGVuZGVudCBmcm9tIG9uZSBhbm90aGVyLg0KPiAtIGJlY2F1c2Ugb2YgYSA2VFND
SCBub2RlIGlzIGRlZXBseSBkdXR5IGN5Y2xlLCByZW1vdGUgc2Vuc2luZyANCj4gYXBwbGljYXRp
b24gKGUuZy4gYWdyaWN1bHR1cmFsIGFwcGxpY2F0aW9ucykgY2FuIHJlbHkgb24gZW5lcmd5IA0K
PiBoYXJ2ZXN0aW5nIGFzIHBvd2VyIHNvdXJjZS4NCj4gLSBBIHNtYXJ0IHVyYmFuIHBhcmtpbmcg
YXBwbGljYXRpb24gY2FuIGJlbmVmaXQgZnJvbSB0aGUgcmVsaWFiaWx0eSBvZiAgDQo+IDZUU0NI
IG5ldHdvcmsgc2luY2UsIGV2ZW4gdGhvdWdoIHRoZSB2ZWhpY2xlIGRldGVjdGlvbiBzZW5zb3Ig
bWF5IGJlIA0KPiBzdGF0aWMsIHRoZSBjb25zdGFudCBtb3ZlbWVudCBvZiBjYXJzIGFyb3VuZCB0
aGUgc2Vuc2luZyBwb2ludHMgY2FuIA0KPiBjYXVzZSB0aGUgd2lyZWxlc3MgZW52aXJvbm1lbnQg
dG8gcXVpY2tseSBjaGFuZ2UuDQo+DQo+IFRob21hcw0KPg0KPiBPbiBUdWUsIE1hciAxOSwgMjAx
MyBhdCAxMjowOCBQTSwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8IA0KPiBwdGh1YmVydEBj
aXNjby5jb20+IHdyb3RlOg0KPg0KPj4gIERlYXIgTUw6KioqKg0KPj4NCj4+ICoqICoqDQo+Pg0K
Pj4gVGhlIGFjdGl2aXR5IHRoYXQgd2UgZ2VuZXJhdGUgb24gdGhlIG1haWxpbmcgbGlzdCBpcyBh
IGdvb2QgDQo+PiBpbmRpY2F0aW9uIHdlIHdpbGwgYmUgdmVyeSBzdWNjZXNzZnVsIGFzIGEgV0cu
IEZpcnN0IHRoaW5nIGZpcnN0LCANCj4+IHRob3VnaCwgd2UgbmVlZCB0byBjcmVhdGUgdGhlIFdH
IGFuZCBuZWVkIHRvIGZvY3VzIGEgbGl0dGxlIGJpdCBvbiANCj4+IHRoZSBuZWNlc3Nhcnkgc3Rl
cHMgdG8gZ2V0DQo+PiB0aGVyZS4qKioqDQo+Pg0KPj4gKiogKioNCj4+DQo+PiBXZSBuZWVkIHRv
IHB1dCB0b2dldGhlciBhIHJvdWdoIGNoYXJ0ZXIsIGFuZCBjb252aW5jZSBhbiBBRCwgcHJvYmFi
bHkgDQo+PiBBZHJpYW4gZnJvbSBSb3V0aW5nIEFyZWEgb3IgVGVkIGZyb20gSW50ZXJuZXQgQXJl
YSwgdGhhdCB3ZSBoYXZlIHJlYWwgDQo+PiBwcm9ibGVtcyB0byBzb2x2ZSBhbmQgdGhhdCB3ZSwg
YXMgYSBncm91cCwgY2FuIHByb3ZpZGUgdmFsdWFibGUgYW5zd2Vycy4NCj4+IFRoZSBBRHMgYWdl
bmRhcyBhcmUgdmVyeSBmdWxsIGFsbCB0aGUgdGltZSwgYnV0IGNlcnRhaW5seSBwZWFrcyANCj4+
IGFyb3VuZCB0aGUgbWVldGluZyB0aW1lcy4gU28gd2UgaGF2ZSBhYm91dCAyIHdlZWsgaW4gZnJv
bnQgb2YgdXMgdG8gDQo+PiBwcmVwYXJlIGEgc29saWQNCj4+IGNhc2UuKioqKg0KPj4NCj4+ICoq
ICoqDQo+Pg0KPj4gU28gSSBzdWdnZXN0IHdlIHN0ZXAgYmFjayBhIG1pbnV0ZSBmcm9tIHRoZSBk
ZXRhaWxzIG9mIHRpbWUgZnJhbWVzIA0KPj4gYW5kIHByaW9yaXRpZXMgYW5kIHNwZW5kIHNvbWUg
ZW5lcmd5IG9uIHRoZSB1c2UgY2FzZXMsIHRoZSBwcm9ibGVtcyANCj4+IHdlIGFyZSBzb2x2aW5n
LCBhbmQgdGhlIHdvcmsgd2UgaGF2ZSB0byBkbyB0byBnZXQgdGhlcmUuIEkgbm90aWNlIGEgDQo+
PiBjb29sIGRpc2N1c3Npb24gb24gbW9iaWxpdHkgYW5kIHRoZSBwYXJ0aWN1bGFyIGNhc2Ugb2Yg
YSBjcmFuZSwgd2VsbCANCj4+IHRoYXTigJlzIGEgdXNlIGNhc2UuIFdlIGFscmVhZHkgaGFkIGNl
bnRyYWxpemVkIGRldGVybWluaXN0aWMgKGhhcmQgDQo+PiBzbG90KSByb3V0ZXMgZm9yIGNvbW1h
bmQgYW5kIGNvbnRyb2wsIGRpc3RyaWJ1dGVkIGRldGVybWluaXN0aWMgKHNvZnQgDQo+PiBzbG90
cykgYW5kIG5vbiBkZXRlcm1pbmlzdGljIFFvUyBiYXNlZCBmbG93cy4gRG8gd2UgaGF2ZSBvdGhl
cnMgDQo+PiBjYXNlcz8qKioqDQo+Pg0KPj4gKioqKg0KPj4NCj4+IENoZWVycywqKioqDQo+Pg0K
Pj4gKiogKioNCj4+DQo+PiBQYXNjYWwqKioqDQo+Pg0KPj4gKiogKioNCj4+DQo+PiAqKiAqKg0K
Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
PiA2dHNjaCBtYWlsaW5nIGxpc3QNCj4+IDZ0c2NoQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0c2NoDQo+Pg0KPj4NCj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gNnRzY2ggbWFpbGluZyBsaXN0DQo+
IDZ0c2NoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
NnRzY2gNCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCjZ0c2NoIG1haWxpbmcgbGlzdA0KNnRzY2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vNnRzY2gNCg==

From pthubert@cisco.com  Thu Mar 21 09:55:56 2013
Return-Path: 
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 DA44F21F9132 for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 09:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hWAZUCY8oaxm for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 09:55:50 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E157F21F912B for <6tsch@ietf.org>; Thu, 21 Mar 2013 09:55:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44638; q=dns/txt; s=iport; t=1363884949; x=1365094549; h=from:to:subject:date:message-id:mime-version; bh=TJG+YYfDfwwH+VwHZIHRnJJujdfR6U1NdErsXU20Y4Y=; b=RdMUDVyVpJyOolVxCxw7g5taJTK77r6B3InIUEz8bxS5csGqDP0LQXTO xFWIfQI3zZuWONiu0Ld1436+Z0v5SLs6hqgtBo8ocklBjlZvp896+syq2 4YBlJE8B9GqqoLImiJitJWvCh3KswpksCZY4WlQR6qbTa2xTAB9WWjXQV E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAHg6S1GtJXG+/2dsb2JhbAApFwMOhAa/PYFtgV0WdIImAQQtKBEGChUBHA4KBAgBAwM5FBACAQEDARIIiAwMLrQOjjGJBIRNEQp0CxUBDAoSB4JHYQOIP49Ej2OBMYEIEj+BbAcXBhg
X-IronPort-AV: E=Sophos;i="4.84,887,1355097600";  d="scan'208,217";a="190080197"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 21 Mar 2013 16:55:48 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2LGtlTM009073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 16:55:47 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 11:55:47 -0500
From: "Pascal Thubert (pthubert)" 
To: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: Agenda for the call March 22nd, 2013
Thread-Index: Ac4mVLDC8NseT7odSWCtQiFRnyZntg==
Date: Thu, 21 Mar 2013 16:55:47 +0000
Deferred-Delivery: Thu, 21 Mar 2013 16:55:00 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.49.80.30]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835D015AAxmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: [6tsch] Agenda for the call March 22nd, 2013
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 16:55:56 -0000

--_000_E045AECD98228444A58C61C200AE1BD835D015AAxmbrcdx01ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all:

The focus for tomorrow will be to agree on use cases and derive a problem s=
tatement. Please keep in mind that the call will be recorded and the record=
 published.

We already have a list that we can review:

- Wireless Process Control (main source for us)
   * control loops (requires a global optimization of routes for jitter an =
latency - thus computed by a PCE  -, flow (over) provisioning, duocast, wit=
h static multipath hard slot allocation.
   * control loop plan B (requires self-healing -thus distributed- routing,=
)
   * supervisory flows (requires determinism up to the backbone
   * management (requires a separate topology - a RPL instance - that does =
not break)
   * alerts (bursty, unexpected, dynamic slot allocation, prioritization)
   * monitoring of lots of lesser importance stuff like corrosion (requires=
 low cost scalability - this distributed routing )
   * cranes that are mobile within a range (requires dynamicity on the last=
 hop(s) whre the mobility happens and may be deterministic up to that point=
)
   * large plants (requires thousands of devices- thus a backbone - within =
a subnet - to avoid renumbering)
   * non-production episodes (requires fast and autonomic behavior - again =
distributed routing)
   * coexistence with legacy devices (requires a common management above)

-Smart cities/infrastructures
    *(road,street) traffic control (requires increase of bw as more traffic=
 in the road)
    *smart urban parking (requires redundancy of routes an over-provision a=
s RF degrades with cars on top of the sensors)

    * green zones. Monitor moisture in gardens, trigger watering.

   * city lights monitoring. Requires marge scale meshes



- building automation.

  * requires redundancy as RF degrades when there are changes on the enviro=
nment, doors, moving metallic apparel, etc..)

  * can be long distance this many hops. Can use lower frequencies to gain =
range.



- vehicular automation.

   * We can save copper for most of the man to machine interfaces, which tr=
anslates in both lower price and lower gas consumption.



- commercial automation.

  *  asset tracking operations on the move (again mobility, and dynamics).

  *  monitoring e.g. temperature of freezers, intrusion sensors, ...


Please bring your own thoughts so we can converge at the call : )

As an appetizer, we can start with


  *   summary overview Orlando meeting (10 minutes)

     *   agendas two meetings
     *   4 drafts presented
     *   TODO: 6tus, add ability for a PCE to set hard cells on one side on=
ly (text already changed)
     *   TODO: typos
     *   TODO: terminology

Then the entr=E9e (40 minutes)


  *   charter use cases:

     *   review the list above
     *   validate the list of derived problems to be solved
     *   focus on what TSCH is good at: reliability, low-power consumption,=
 traffic engineering

for dessert

  *   open technical discussions

     *   synchronization between BBRs

        *   summarize and discuss proposal

     *   slotframes, cells and priorities

        *   summarize and discuss proposal

     *   interaction between RPL and PCE

        *   summarize current state of the discussion


Please let us know if you wish to add / amend stuff in the above : )

Cheers,

Pascal

PS, call info is as always:

Topic: 6TSCH Weekly
Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 206 802 913
Meeting Password: sixtus


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=
=3DNZTRkNDAwOTE1&RT=3DMiM0
2. Enter your name and email address.
3. Enter the meeting password: sixtus
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkN=
DAwOTE1&ORT=3DMiM0

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita=
s area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access =
Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
pthubert@cisco.com
33-49-723 2634

To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&LD=
=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&=
RT=3DMiM0






http://www.webex.com

CCP:+14085256800x206802913#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent to the recording, discuss your concerns =
with the meeting host prior to the start of the recording or do not join th=
e session. Please note that any such recordings may be subject to discovery=
 in the event of litigation.


--_000_E045AECD98228444A58C61C200AE1BD835D015AAxmbrcdx01ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear all:


 


The focus for tomorrow will be to agree on use cases=
 and derive a problem statement. Please keep in mind that the call will be =
recorded and the record published.


 


We already have a list that we can review:




- Wireless Process Control (main source for us)


   * control loops (requires a global opti=
mization of routes for jitter an latency – thus computed by a PCE&nbs=
p; -, flow (over) provisioning, duocast, with static multipath hard slot al=
location.



   * control loop plan B (requires se=
lf-healing -thus distributed- routing,)


   * supervisory flows (requires determini=
sm up to the backbone


   * management (requires a separate topol=
ogy – a RPL instance - that does not break)


   * alerts (bursty, unexpected, dynamic s=
lot allocation, prioritization)


   * monitoring of lots of lesser importan=
ce stuff like corrosion (requires low cost scalability – this distrib=
uted routing )


   * cranes that are mobile within a range=
 (requires dynamicity on the last hop(s) whre the mobility happens and may =
be deterministic up to that point)


   * large plants (requires thousands of d=
evices– thus a backbone – within a subnet – to avoid renu=
mbering)


   * non-production episodes (requires fas=
t and autonomic behavior – again distributed routing)


   * coexistence with legacy devices (requ=
ires a common management above)


 


-Smart cities/infrastructures 

    *(road,street) traffic control (requires increase of bw =
as more traffic in the road)

    *smart urban parking (requires redundancy of routes an o=
ver-provision as RF degrades with cars on top of the sensors)  &n=
bsp;



    * green zones. Monitor mo=
isture in gardens, trigger watering.


   * city lights monitoring. Requires m=
arge scale meshes


 


- building automation. 


  * requires redundancy as RF degrades =
when there are changes on the environment, doors, moving metallic apparel, =
etc..)


  * can be long distance this many hops. Can=
 use lower frequencies to gain range.


 


- vehicular automation. 


   * We can save copper for most o=
f the man to machine interfaces, which translates in both lower price and l=
ower gas consumption.


 


- commercial automation.


  *  asset tracking operations on the m=
ove (again mobility, and dynamics).


  *  monitoring e.g. temperature of fre=
ezers, intrusion sensors, …


 


 


Please bring your own thoughts so we can converge at=
 the call : )


 


As an appetizer, we can start with 


 


    

  • summary overview =
Orlando meeting (10 minutes)


    

      

    • agendas two meeti=
ngs
    • TODO: 6tus, add ability for a PCE to set hard cells on o=
ne side only (text already changed)
    • TODO: typos
    • TODO: terminology
    



 


Then the entr=E9e (40 minutes)


 


    

  • charter use cases=
:


    

      

    • review the list a=
bove
    • validate the list of derived problems to be solved
    • focus on what TSCH is g=
ood at: reliability, low-power consumption, traffic engineering<=
/li>
    



 


for dessert


    

  • open technical di=
scussions


    

      

    • synchronization =
between BBRs
    



    

      

        

      • summarize and dis=
cuss proposal
      

    



    

      

    • slotframes, cells=
 and priorities
    



    

      

        

      • summarize and dis=
cuss proposal
      

    



    

      

    • interaction betw=
een RPL and PCE
    



    

      

        

      • summarize curren=
t state of the discussion
      

    



 


 <=
/b>


Please let us know if you wish to add / amend stuff =
in the above : )


 


Cheers,


 


Pascal


 


PS, call info is as always:




Topic: 6TSCH Weekly 

Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014 
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) 

Meeting Number: 206 802 913 

Meeting Password: sixtus 





------------------------------------------------------- 

To join the online meeting (Now from mobile devices!) 

------------------------------------------------------- 

1. Go to 
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=
=3DNZTRkNDAwOTE1&RT=3DMiM0


2. Enter your name and email address. 

3. Enter the meeting password: sixtus 

4. Click "Join Now". 



To view in other time zones or languages, please click the link: 

https://cisco=
.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkNDAwOT=
E1&ORT=3DMiM0




---------------------------------------------------------------- 

ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes 

---------------------------------------------------------------- 



The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita=
s area and (866) 349-3520 for the RTP area.




Please dial the local access number for your area from the list below: 

- San Jose/Milpitas (408) area: 525-6800 

- RTP (919) area: 392-3330 



------------------------------------------------------- 

To join the teleconference only 

------------------------------------------------------- 

1. Dial into Cisco WebEx (view all Global Access Numbers at 

http://cisco.com/en/US/about/doing_business/conferen=
cing/index.html


2. Follow the prompts to enter the Meeting Number (listed above) or Access =
Code followed by the # sign.




San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 



US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 



India: +91.80.4350.1111 Germany: +49.619.6773.9002 



Japan: +81.3.5763.9394 China: +86.10.8515.5666 



------------------------------------------------------- 

For assistance 

------------------------------------------------------- 

1. Go to https://cisco.webex.com/ciscosales/mc


2. On the left navigation bar, click "Support". 



You can contact me at: 

pthubert@cisco.com 

33-49-723 2634 



To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:


https:=
//cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&=
amp;LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMu=
Egw1h2pXGIGSMyQEb&RT=3DMiM0














http://www.webex.com=
 



CCP:+14085256800x206802913# 



IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent
 to the recording, discuss your concerns with the meeting host prior to the=
 start of the recording or do not join the session. Please note that any su=
ch recordings may be subject to discovery in the event of litigation.



 






--_000_E045AECD98228444A58C61C200AE1BD835D015AAxmbrcdx01ciscoc_--

From maria-rita.palattella@uni.lu  Thu Mar 21 10:09:22 2013
Return-Path: 
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 5D5EB21F9125 for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 10:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.099,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 Nm3HbG6xzoiV for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 10:09:21 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB6F21F90C7 for <6tsch@ietf.org>; Thu, 21 Mar 2013 10:09:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,887,1355094000"; d="scan'208,217";a="23052956"
Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 21 Mar 2013 18:09:16 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.01.0438.000; Thu, 21 Mar 2013 18:09:15 +0100
From: Maria Rita PALATTELLA 
To: "Pascal Thubert (pthubert)" , Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: Agenda for the call March 22nd, 2013
Thread-Index: Ac4mVLDC8NseT7odSWCtQiFRnyZntgAAVkCN
Date: Thu, 21 Mar 2013 17:09:15 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.34.0.8]
Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D18535229hoshiunilux_"
MIME-Version: 1.0
Subject: Re: [6tsch] Agenda for the call March 22nd, 2013
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 17:09:22 -0000

--_000_F085911F642A6847987ADA23E611780D18535229hoshiunilux_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Pascal,
thanks for the great list about use cases that you have already prepared.

Here are some extra thoughts, that are in line with what we have already in=
 the list!
Use Cases: Domotic & Home Automation/ Monitoring & Security
- Energy and water use: energy and water supply consumption monitoring to o=
btain advice on how to save cost and resources.
- Intrusion Detection Systems: Detection of window and door openings and vi=
olations to prevent intruders.

Looking forward to tomorrow meeting.

Best Regards,
Maria Rita
________________________________
From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Pascal T=
hubert (pthubert) [pthubert@cisco.com]
Sent: Thursday, March 21, 2013 5:55 PM
To: Thomas Watteyne; 6tsch@ietf.org
Subject: [6tsch] Agenda for the call March 22nd, 2013

Dear all:

The focus for tomorrow will be to agree on use cases and derive a problem s=
tatement. Please keep in mind that the call will be recorded and the record=
 published.

We already have a list that we can review:

- Wireless Process Control (main source for us)
   * control loops (requires a global optimization of routes for jitter an =
latency =96 thus computed by a PCE  -, flow (over) provisioning, duocast, w=
ith static multipath hard slot allocation.
   * control loop plan B (requires self-healing -thus distributed- routing,=
)
   * supervisory flows (requires determinism up to the backbone
   * management (requires a separate topology =96 a RPL instance - that doe=
s not break)
   * alerts (bursty, unexpected, dynamic slot allocation, prioritization)
   * monitoring of lots of lesser importance stuff like corrosion (requires=
 low cost scalability =96 this distributed routing )
   * cranes that are mobile within a range (requires dynamicity on the last=
 hop(s) whre the mobility happens and may be deterministic up to that point=
)
   * large plants (requires thousands of devices=96 thus a backbone =96 wit=
hin a subnet =96 to avoid renumbering)
   * non-production episodes (requires fast and autonomic behavior =96 agai=
n distributed routing)
   * coexistence with legacy devices (requires a common management above)

-Smart cities/infrastructures
    *(road,street) traffic control (requires increase of bw as more traffic=
 in the road)
    *smart urban parking (requires redundancy of routes an over-provision a=
s RF degrades with cars on top of the sensors)

    * green zones. Monitor moisture in gardens, trigger watering.

   * city lights monitoring. Requires marge scale meshes



- building automation.

  * requires redundancy as RF degrades when there are changes on the enviro=
nment, doors, moving metallic apparel, etc..)

  * can be long distance this many hops. Can use lower frequencies to gain =
range.



- vehicular automation.

   * We can save copper for most of the man to machine interfaces, which tr=
anslates in both lower price and lower gas consumption.



- commercial automation.

  *  asset tracking operations on the move (again mobility, and dynamics).

  *  monitoring e.g. temperature of freezers, intrusion sensors, =85


Please bring your own thoughts so we can converge at the call : )

As an appetizer, we can start with


  *   summary overview Orlando meeting (10 minutes)

     *   agendas two meetings
     *   4 drafts presented
     *   TODO: 6tus, add ability for a PCE to set hard cells on one side on=
ly (text already changed)
     *   TODO: typos
     *   TODO: terminology

Then the entr=E9e (40 minutes)


  *   charter use cases:

     *   review the list above
     *   validate the list of derived problems to be solved
     *   focus on what TSCH is good at: reliability, low-power consumption,=
 traffic engineering

for dessert

  *   open technical discussions

     *   synchronization between BBRs

        *   summarize and discuss proposal

     *   slotframes, cells and priorities

        *   summarize and discuss proposal

     *   interaction between RPL and PCE

        *   summarize current state of the discussion


Please let us know if you wish to add / amend stuff in the above : )

Cheers,

Pascal

PS, call info is as always:

Topic: 6TSCH Weekly
Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 206 802 913
Meeting Password: sixtus


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=
=3DNZTRkNDAwOTE1&RT=3DMiM0
2. Enter your name and email address.
3. Enter the meeting password: sixtus
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkN=
DAwOTE1&ORT=3DMiM0

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita=
s area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access =
Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
pthubert@cisco.com
33-49-723 2634

To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&LD=
=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&=
RT=3DMiM0






http://www.webex.com

CCP:+14085256800x206802913#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent to the recording, discuss your concerns =
with the meeting host prior to the start of the recording or do not join th=
e session. Please note that any such recordings may be subject to discovery=
 in the event of litigation.


--_000_F085911F642A6847987ADA23E611780D18535229hoshiunilux_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable








Pascal,


thanks for the great list about use cases that you have already prepared.


Here are some extra thoughts, that are in line with what we have already in=
 the list!

Use Cases: Domotic & Home Automation/ Monitoring & Security

- Energy and water use: energy and water supply consumption monitoring to o=
btain advice on how to save cost and resources.

- Intrusion Detection Systems: Detection of window and door openings and vi=
olations to prevent intruders.



Looking forward to tomorrow meeting.



Best Regards,

Maria Rita




From: 6tsch-bounces@ietf.org [6tsch-bounc=
es@ietf.org] on behalf of Pascal Thubert (pthubert) [pthubert@cisco.com]
Sent: Thursday, March 21, 2013 5:55 PM

To: Thomas Watteyne; 6tsch@ietf.org

Subject: [6tsch] Agenda for the call March 22nd, 2013












Dear all:


 


The focus for tomorrow will be to agree on use cases=
 and derive a problem statement. Please keep in mind that the call will be =
recorded and the record published.


 


We already have a list that we can review:




- Wireless Process Control (main source for us)

   * control loops (requires a global opti=
mization of routes for jitter an latency =96 thus computed by a PCE  -=
, flow (over) provisioning, duocast, with static multipath hard slot alloca=
tion.



   * control loop plan B (requires se=
lf-healing -thus distributed- routing,)


   * supervisory flows (requires determini=
sm up to the backbone


   * management (requires a separate topol=
ogy =96 a RPL instance - that does not break)


   * alerts (bursty, unexpected, dynamic s=
lot allocation, prioritization)


   * monitoring of lots of lesser importan=
ce stuff like corrosion (requires low cost scalability =96 this distributed=
 routing )


   * cranes that are mobile within a range=
 (requires dynamicity on the last hop(s) whre the mobility happens and may =
be deterministic up to that point)


   * large plants (requires thousands of d=
evices=96 thus a backbone =96 within a subnet =96 to avoid renumbering)


   * non-production episodes (requires fas=
t and autonomic behavior =96 again distributed routing)


   * coexistence with legacy devices (requ=
ires a common management above)


 


-Smart cities/infrastructures 

    *(road,street) traffic control (requires increase of bw =
as more traffic in the road)

    *smart urban parking (requires redundancy of routes an o=
ver-provision as RF degrades with cars on top of the sensors)  &n=
bsp;



    * green zones. Monitor mo=
isture in gardens, trigger watering.


   * city lights monitoring. Requires m=
arge scale meshes


 


- building automation. 


  * requires redundancy as RF degrades =
when there are changes on the environment, doors, moving metallic apparel, =
etc..)


  * can be long distance this many hops. Can=
 use lower frequencies to gain range.


 


- vehicular automation. 


   * We can save copper for most o=
f the man to machine interfaces, which translates in both lower price and l=
ower gas consumption.


 


- commercial automation.


  *  asset tracking operations on the m=
ove (again mobility, and dynamics).


  *  monitoring e.g. temperature of fre=
ezers, intrusion sensors, =85


 


 


Please bring your own thoughts so we can converge at=
 the call : )


 


As an appetizer, we can start with 


 


    

  • summary overview Orlando meeting (10 min=
utes)


    

      

    • agendas two meetings
    • 4 drafts presented
    • TODO: 6tus, add ability for a PCE to set hard cells on one side only (te=
xt already changed)
    • TODO: typos
      • =

    • TODO: terminology
    



 


Then the entr=E9e (40 minutes)


 


    

  • charter use cases:


    

      

    • review the list above
    • validate the list of derived problems to be solved
    • focus on what TSCH is good at: reliabil=
ity, low-power consumption, traffic engineering
    



 


for dessert


    

  • open technical discussions


    

      

    • synchronization between BBRs
    



    

      

        

      • summarize and discuss proposal
      

    



    

      

    • slotframes, cells and priorities
      • 

    

      

        

          

        • summarize and discuss proposal
        

      

    











--_000_F085911F642A6847987ADA23E611780D18535229hoshiunilux_--

From Bogdan.Pavkovic@imag.fr  Thu Mar 21 16:14:11 2013
Return-Path: 
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 F1CC921F8F4A for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 16:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level: 
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 qBdOsX6rg9Gr for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 16:14:09 -0700 (PDT)
Received: from shiva.imag.fr (mx1.imag.fr [IPv6:2001:660:5301:6::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3884321F8E1C for <6tsch@ietf.org>; Thu, 21 Mar 2013 16:13:52 -0700 (PDT)
Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by shiva.imag.fr (8.13.8/8.13.8) with ESMTP id r2LNDdqX016837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Mar 2013 00:13:39 +0100
Received: from Thassos.local (109-93-238-162.dynamic.isp.telekom.rs [109.93.238.162]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id r2LNDdAp012397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Mar 2013 00:13:41 +0100
Message-ID: <514B951E.6030604@imag.fr>
Date: Fri, 22 Mar 2013 00:17:50 +0100
From: =?UTF-8?B?Qm9nZGFuIFBhdmtvdmnEhw==?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070302060009010106000401"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.imag.fr [129.88.30.5]); Fri, 22 Mar 2013 00:13:40 +0100 (CET)
X-IMAG-MailScanner-Information: Please contact MI2S MIM  for more information
X-MailScanner-ID: r2LNDdqX016837
X-IMAG-MailScanner: Found to be clean
X-IMAG-MailScanner-SpamCheck: 
X-IMAG-MailScanner-From: bogdan.pavkovic@imag.fr
MailScanner-NULL-Check: 1364512421.42255@tGb3rSLZnyOIwG5V3J3sWA
Cc: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] Agenda for the call March 22nd, 2013
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 23:14:11 -0000

This is a multi-part message in MIME format.
--------------070302060009010106000401
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Dear all,

I would also like to hop on this standardization train (to re-use the 
example with Boris).
Since Thomas introduced me to the activities of 6TSCH, I got exited 
about the possibility to work on this thematic.

I do not have a prior active standardization experience, but I would 
like to learn more.
Nevertheless, I am familiar with RPL and 802.15.4 (e).
In fact, for my thesis I was considering the scientific and practical 
challenges related to cohabitation of 802.15.4 and RPL.

I already had a chance to catch up on the abundant discussion on the 
mailing list,
and I will join you for tomorrow's call (menu).

Best regards,

Bogdan Pavković

https://sites.google.com/site/bogdanpavkovicpersonal/
http://drakkar.imag.fr/bogdan

phone: +381 62 184 2 898
Skype: pavkovic_bogdan

On 3/21/13 5:55 PM, Pascal Thubert (pthubert) wrote:
>
> Dear all:
>
> The focus for tomorrow will be to agree on use cases and derive a 
> problem statement. Please keep in mind that the call will be recorded 
> and the record published.
>
> We already have a list that we can review:
>
> - Wireless Process Control (main source for us)
>
>    * control loops (requires a global optimization of routes for 
> jitter an latency – thus computed by a PCE  -, flow (over) 
> provisioning, duocast, with static multipath hard slot allocation.
>
>    * control loop plan B (requires self-healing -thus distributed- 
> routing,)
>
>    * supervisory flows (requires determinism up to the backbone
>
>    * management (requires a separate topology – a RPL instance - that 
> does not break)
>
>    * alerts (bursty, unexpected, dynamic slot allocation, prioritization)
>
>    * monitoring of lots of lesser importance stuff like corrosion 
> (requires low cost scalability – this distributed routing )
>
>    * cranes that are mobile within a range (requires dynamicity on the 
> last hop(s) whre the mobility happens and may be deterministic up to 
> that point)
>
>    * large plants (requires thousands of devices– thus a backbone – 
> within a subnet – to avoid renumbering)
>
>    * non-production episodes (requires fast and autonomic behavior – 
> again distributed routing)
>
>    * coexistence with legacy devices (requires a common management above)
>
> -Smart cities/infrastructures
>     *(road,street) traffic control (requires increase of bw as more 
> traffic in the road)
>     *smart urban parking (requires redundancy of routes an 
> over-provision as RF degrades with cars on top of the sensors)
>
>     * green zones. Monitor moisture in gardens, trigger watering.
>
>    * city lights monitoring. Requires marge scale meshes
>
> - building automation.
>
>   * requires redundancy as RF degrades when there are changes on the 
> environment, doors, moving metallic apparel, etc..)
>
>   * can be long distance this many hops. Can use lower frequencies to 
> gain range.
>
> - vehicular automation.
>
>    * We can save copper for most of the man to machine interfaces, 
> which translates in both lower price and lower gas consumption.
>
> - commercial automation.
>
>   *  asset tracking operations on the move (again mobility, and dynamics).
>
>   *  monitoring e.g. temperature of freezers, intrusion sensors, …
>
> Please bring your own thoughts so we can converge at the call : )
>
> As an appetizer, we can start with
>
>   * summary overview Orlando meeting (10 minutes)
>
>       o agendas two meetings
>       o 4 drafts presented
>       o TODO: 6tus, add ability for a PCE to set hard cells on one
>         side only (text already changed)
>       o TODO: typos
>       o TODO: terminology
>
> Then the entrée (40 minutes)
>
>   * charter use cases:
>
>       o review the list above
>       o validate the list of derived problems to be solved
>       o focus on what TSCH is good at: reliability, low-power
>         consumption, traffic engineering
>
> for dessert
>
>   * open technical discussions
>
>       o synchronization between BBRs
>
>           + summarize and discuss proposal
>
>       o slotframes, cells and priorities
>
>           + summarize and discuss proposal
>
>       o interaction between RPL and PCE
>
>           + summarize current state of the discussion
>
> **
>
> Please let us know if you wish to add / amend stuff in the above : )
>
> Cheers,
>
> Pascal
>
> PS, call info is as always:
>
>
> Topic: 6TSCH Weekly
> Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014
> Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
> Meeting Number: 206 802 913
> Meeting Password: sixtus
>
>
> -------------------------------------------------------
> To join the online meeting (Now from mobile devices!)
> -------------------------------------------------------
> 1. Go to 
> https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&RT=MiM0 
>
> 2. Enter your name and email address.
> 3. Enter the meeting password: sixtus
> 4. Click "Join Now".
>
> To view in other time zones or languages, please click the link:
> https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&ORT=MiM0 
>
>
> ----------------------------------------------------------------
> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
> ----------------------------------------------------------------
>
> The affected toll free numbers are: (866) 432-9903 for the San 
> Jose/Milpitas area and (866) 349-3520 for the RTP area.
>
> Please dial the local access number for your area from the list below:
> - San Jose/Milpitas (408) area: 525-6800
> - RTP (919) area: 392-3330
>
> -------------------------------------------------------
> To join the teleconference only
> -------------------------------------------------------
> 1. Dial into Cisco WebEx (view all Global Access Numbers at
> http://cisco.com/en/US/about/doing_business/conferencing/index.html
> 2. Follow the prompts to enter the Meeting Number (listed above) or 
> Access Code followed by the # sign.
>
> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
>
> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
>
> India: +91.80.4350.1111 Germany: +49.619.6773.9002
>
> Japan: +81.3.5763.9394 China: +86.10.8515.5666
>
> -------------------------------------------------------
> For assistance
> -------------------------------------------------------
> 1. Go to https://cisco.webex.com/ciscosales/mc
> 2. On the left navigation bar, click "Support".
>
> You can contact me at:
> pthubert@cisco.com 
> 33-49-723 2634
>
> To add this meeting to your calendar program (for example Microsoft 
> Outlook), click this link:
> https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&RT=MiM0 
>
>
>
>
>
>
>
> http://www.webex.com
>
> CCP:+14085256800x206802913#
>
> IMPORTANT NOTICE: This WebEx service includes a feature that allows 
> audio and any documents and other materials exchanged or viewed during 
> the session to be recorded. By joining this session, you automatically 
> consent to such recordings. If you do not consent to the recording, 
> discuss your concerns with the meeting host prior to the start of the 
> recording or do not join the session. Please note that any such 
> recordings may be subject to discovery in the event of litigation.
>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


--------------070302060009010106000401
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Dear all,

      

      I would also like to hop on this standardization train (to re-use
      the example with Boris).

      Since Thomas introduced me to the activities of 6TSCH, I got
      exited about the possibility to work on this thematic.

      

      I do not have a prior active standardization experience, but I
      would like to learn more.

      Nevertheless, I am familiar with RPL and 802.15.4 (e).

      In fact, for my thesis I was considering the scientific and
      practical challenges related to cohabitation of 802.15.4 and RPL.

      

      I already had a chance to catch up on the abundant discussion on
      the mailing list,

      and I will join you for tomorrow's call (menu).

      

      Best regards,

      

      
Bogdan Pavković

https://sites.google.com/site/bogdanpavkovicpersonal/
http://drakkar.imag.fr/bogdan

phone: +381 62 184 2 898
Skype: pavkovic_bogdan

      On 3/21/13 5:55 PM, Pascal Thubert (pthubert) wrote:

    

    

      
      
      
      

        
Dear all:

        
 

        
The focus for tomorrow will be to agree on
          use cases and derive a problem statement. Please keep in mind
          that the call will be recorded and the record published.

        
 

        
We already have a list that we can review:

        

        
- Wireless Process Control (main source
          for us)

        
   * control loops (requires a global
          optimization of routes for jitter an latency – thus computed
          by a PCE  -, flow (over) provisioning, duocast, with static
          multipath hard slot allocation.
          

        
   * control loop plan B (requires
          self-healing -thus distributed- routing,)

        
   * supervisory flows (requires
          determinism up to the backbone

        
   * management (requires a separate
          topology – a RPL instance - that does not break)

        
   * alerts (bursty, unexpected, dynamic
          slot allocation, prioritization)

        
   * monitoring of lots of lesser
          importance stuff like corrosion (requires low cost scalability
          – this distributed routing )

        
   * cranes that are mobile within a range
          (requires dynamicity on the last hop(s) whre the mobility
          happens and may be deterministic up to that point)

        
   * large plants (requires thousands of
          devices– thus a backbone – within a subnet – to avoid
          renumbering)

        
   * non-production episodes (requires fast
          and autonomic behavior – again distributed routing)

        
   * coexistence with legacy devices
          (requires a common management above)

        
 

        
-Smart cities/infrastructures 

              *(road,street) traffic control (requires increase of bw as
          more traffic in the road)

              *smart urban parking (requires redundancy of routes an
          over-provision as RF degrades with cars on top of the
          sensors)   
          

        
    * green zones. Monitor moisture in
          gardens, trigger watering.

        
   * city lights monitoring. Requires
          marge scale meshes

        
 

        
- building automation. 

        
  * requires redundancy as RF degrades
          when there are changes on the environment, doors, moving
          metallic apparel, etc..)

        
  * can be long distance this many hops.
          Can use lower frequencies to gain range.

        
 

        
- vehicular automation. 

        
   * We can save copper for most of the
          man to machine interfaces, which translates in both lower
          price and lower gas consumption.

        
 

        
- commercial automation.

        
  *  asset tracking operations on the
          move (again mobility, and dynamics).

        
  *  monitoring e.g. temperature of
          freezers, intrusion sensors, …

        
 

        
 

        
Please bring your own thoughts so we can
          converge at the call : )

        
 

        
As an appetizer, we can start with 

        
 

        
    
          
  • summary
            overview Orlando meeting (10 minutes)
    • 
        

        
    
          
      
            
    • agendas
              two meetings
      • 
            
    • 4
              drafts presented
      • 
            
    • TODO:
              6tus, add ability for a PCE to set hard cells on one side
              only (text already changed)
      • 
            
    • TODO:
              typos
      • 
            
    • TODO:
              terminology
      • 
          
    
        

        
 

        
Then the entrée (40 minutes)

        
 

        
    
          
  • charter
            use cases:
    • 
        

        
    
          
      
            
    • review
              the list above
      • 
            
    • validate
              the list of derived problems to be solved
      • 
            
    • focus
              on what TSCH is good at: reliability, low-power
              consumption, traffic engineering
      • 
          
    
        

        
 

        
for dessert

        
    
          
  • open
            technical discussions
    • 
        

        
    
          
      
            
    • synchronization
              between BBRs
      • 
          
    
        

        
    
          
      
            
        
              
      • summarize
                and discuss proposal
        • 
            
      
          
    
        

        
    
          
      
            
    • slotframes,
              cells and priorities
      • 
          
    
        

        
    
          
      
            
        
              
      • summarize
                and discuss proposal
        • 
            
      
          
    
        

        
    
          
      
            
    • interaction
              between RPL and PCE
      • 
          
    
        

        
    
          
      
            
        
              
      • summarize
                current state of the discussion
        • 
            
      
          
    
        

        
 

        
 

        
Please let us know if you wish to add /
          amend stuff in the above : )

        
 

        
Cheers,

        
 

        
Pascal

        
 

        
PS, call info is as always:

        


            Topic: 6TSCH Weekly 

            Date: Every Friday, from Friday, March 8, 2013 to Friday,
            March 7, 2014 

            Time: 8:00 am, Pacific Standard Time (San Francisco,
            GMT-08:00) 

            Meeting Number: 206 802 913 

            Meeting Password: sixtus 

            

            

            ------------------------------------------------------- 

            To join the online meeting (Now from mobile devices!) 

            ------------------------------------------------------- 

            1. Go to 
https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&RT=MiM0
            

            2. Enter your name and email address. 

            3. Enter the meeting password: sixtus 

            4. Click "Join Now". 

            

            To view in other time zones or languages, please click the
            link: 

            https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&ORT=MiM0
            

            

            ----------------------------------------------------------------
            

            ALERT:Toll-Free Dial Restrictions for (408) and (919) Area
            Codes 

            ----------------------------------------------------------------
            

            

            The affected toll free numbers are: (866) 432-9903 for the
            San Jose/Milpitas area and (866) 349-3520 for the RTP area.
            

            

            Please dial the local access number for your area from the
            list below: 

            - San Jose/Milpitas (408) area: 525-6800 

            - RTP (919) area: 392-3330 

            

            ------------------------------------------------------- 

            To join the teleconference only 

            ------------------------------------------------------- 

            1. Dial into Cisco WebEx (view all Global Access Numbers at
            

            http://cisco.com/en/US/about/doing_business/conferencing/index.html
            

            2. Follow the prompts to enter the Meeting Number (listed
            above) or Access Code followed by the # sign.
            

            

            San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 

            

            US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
            

            

            India: +91.80.4350.1111 Germany: +49.619.6773.9002 

            

            Japan: +81.3.5763.9394 China: +86.10.8515.5666 

            

            ------------------------------------------------------- 

            For assistance 

            ------------------------------------------------------- 

            1. Go to https://cisco.webex.com/ciscosales/mc
            

            2. On the left navigation bar, click "Support". 

            

            You can contact me at: 

            pthubert@cisco.com
            

            33-49-723 2634 

            

            To add this meeting to your calendar program (for example
            Microsoft Outlook), click this link:
            

            https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&RT=MiM0
            

            

            

            

            

            

            

            http://www.webex.com 

            

            CCP:+14085256800x206802913# 

            

            IMPORTANT NOTICE: This WebEx service includes a feature that
            allows audio and any documents and other materials exchanged
            or viewed during the session to be recorded. By joining this
            session, you automatically consent to such recordings. If
            you do not consent to the recording, discuss your concerns
            with the meeting host prior to the start of the recording or
            do not join the session. Please note that any such
            recordings may be subject to discovery in the event of
            litigation.
          

        
 

      

      

      

      

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


    

    

  


--------------070302060009010106000401--

From pthubert@cisco.com  Fri Mar 22 01:07:36 2013
Return-Path: 
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 6041021F8959; Fri, 22 Mar 2013 01:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=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 vf1ctLGhyXS2; Fri, 22 Mar 2013 01:07:35 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8AC21F8936; Fri, 22 Mar 2013 01:07:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10033; q=dns/txt; s=iport; t=1363939655; x=1365149255; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=/+CAb+VsB1rffRMx1WwjJZnJCXDfE2E0TGvw35o1YvI=; b=KpigstES2LO2Ffcf9nYunQPsKxqw/QQunp7JAlO/i45w2WveO5bObLQE gqMyaWn91fKp72RmEPX3HHodopLRd3wNl6wiw1jD4rvh8VXmk9BAbjGhq D7Y6mii6kIlq62ly0wFZXmpN/4rvdPKCbPFbIad+trPA4JN33SsKiZnbm Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAIgQTFGtJV2c/2dsb2JhbABDDsVngV4WdIIkAQEBAwEBAQFrCwUHBgEZBAEBAQodLgsUCQkBBAENBQgTh3MGDMFWEwSNSYEYJgsNgllhA4g/il+USYJLP4Io
X-IronPort-AV: E=Sophos;i="4.84,891,1355097600"; d="scan'208";a="190340602"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 22 Mar 2013 08:07:34 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2M87YK8021292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 08:07:34 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 03:07:33 -0500
From: "Pascal Thubert (pthubert)" 
To: Qin Wang , Thomas Watteyne 
Thread-Topic: Interaction between NME and PCE
Thread-Index: Ac4m1AAaAig2JGZERcC75DTjyWBvYA==
Date: Fri, 22 Mar 2013 08:07:33 +0000
Deferred-Delivery: Fri, 22 Mar 2013 08:06:00 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.85.19]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "coman@ietf.org" , IETF 6TSCH <6tsch@ietf.org>
Subject: [6tsch] Interaction between NME and PCE
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 08:07:36 -0000

Hello Qin;

There is potentially some duplication between what a 6TSCH node would excha=
nge with a network management entity  (NME) and with a path computation ent=
ity (PCE). Basically, the information we want to report about peering, neig=
hbors, cell and track utilization can be useful on both sides.

And we may even have a use case where the track is entered manually =E0 la =
MPLS TP as opposed to TE, thus coming from NME though, fingers crossed, I'v=
e not seen that one yet. In that case, the track information could be impos=
ed on the 6TSCH node by either NME and PCE, and there could potentially be =
a conflict between those tracks.=20

If we pick the direct path way of enhancing existing standards:=20
1)  Network Management will have its own mechanisms, based on the work at t=
he COMAN ML.
2)  Path Computation will have its own mechanisms, probably a PCEP enhancem=
ent.
Yet:
3)  We do not want to report a lot of information twice from the 6TSCH node=
s, once for NME and once for PCE.
4)  We want the conflicts between manual (NME) and automatic (PCE) routes t=
o be sorted between those two before the device sees any of it.=20

So certainly, PCEP seems to be a most promising venue for centralized route=
 computation. For all I know, PCEP in a classical PCE allocates lambdas in =
DWDM, so why wouldn't we enhance it to allocate cells and tracks in 6TSCH?=
=20

But if we pick PCEP between the node and the PCE for all the PCE related ex=
changes, then we probably want the NME to interact with the PCE to dig the =
related information, and we have to document how that happens. At the same =
time, we have to document how things work when there is no PCE. Looks like =
the PCE would act as a proxy or something.

It makes sense to me that the network management information may be digged =
from a gateway anyway for all sorts on non-IP world compatibility. Cc'ing C=
OMAP=20

Pascal


-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Q=
in Wang
Sent: lundi 18 mars 2013 20:42
To: Thomas Watteyne
Cc: IETF 6TSCH
Subject: Re: [6tsch] Interaction between RPL and PCE

Thomas,

I'm not very familiar with PCE protocol. According to my knowledge, there a=
re extensions of PCE protocol corresponding to different protocols like GMP=
LS. So, maybe a extension of PCE for 6tus is needed, which computes the tra=
ck for given multihop path and bandwidth requirement, or the track for give=
n topology and end-to-end bandwidth requirement.

How do you think?

Qin



> Qin,
>
> Please see inline.
>
> On Mon, Mar 18, 2013 at 10:25 AM, Qin Wang  wrote:
>
>> Thomas,
>>
>> I think for a data flow, there are three elements needed to be=20
>> defined or scheduled explicitly or implicitly:
>> (1) multihop path, i.e. who is the next hop neighbor
>> (2) bandwidth and Qos requirement
>> (3) cell set (i.e. bundle) to implement the bandwidth
>>
>> In case-1, all of the three elements are determined by PCE, and RPL=20
>> is just a backup and works on slot-aloha cells. Correct?
>>
>
> I believe that's correct. BTW, I'm not per se advocating for this=20
> solution, but it seems to be the approach=20
> draft-ietf-roll-rpl-industrial-applicability
> takes.
>
>
>> In case2, element(1) is determined by RPL based on Rank, and=20
>> element(3) is determined by PCE. But, who will determine element(2)?=20
>> by PCE or by some entity like RSVP/NSIS or DSCP?
>>
>>
> Agreed. It relatively straightforward for a PCE to compute a schedule=20
> and distribute that into the network, but how does it figure out what=20
> the requirements are from the nodes in the network. Could we reuse a=20
> "PCE requirements" protocol out there?
>
>
>> Qin
>>
>> > [subject was: Scope: 6LoWPAN + 1]
>> >
>> > Maria Rita,
>> >
>> > I fully agree with Pascal's suggestion to have the PCE only talk to
>> one
>> of
>> > the two sides on a on-hop link, and have 6tus be in charge to=20
>> > telling
>> the
>> > other side to reserve the same cell. I believe Qin has also
>> acknowledged
>> > this, and has agreed to put this mechanism into 6tus. This would
>> probably
>> > mean adding some option in the 6tus message format saying "this is=20
>> > not
>> a
>> > negociation for a soft cell, but an order for you to add this hard
>> cell".
>> >
>> > All,
>> >
>> > I believe Maria Rita is touching a very important point we haven't=20
>> > had time to discuss last week in Orlando, but which I believe is=20
>> > essential: how
>> do
>> > RPL and the PCE interact? The PCE can have complete knowledge of=20
>> > the network topology and the network traffic, so besides L2=20
>> > resource allocation, it could also make routing decision, i.e.=20
>> > build the track
>> it
>> > believe is best fit.
>> >
>> > draft-ietf-roll-rpl-industrial-applicability-00 also states similar
>> ideas:
>> > "The domain of applicability for the RPL protocol may include all
>> phases
>> > but the Normal Operation phase, where the bandwidth allocation and=20
>> > the *routes are usually optimized by an external Path Computing=20
>> > Engine (PCE)*.
>> [...]
>> > Additionally, it could be envisioned to include RPL in the normal=20
>> > operation provided that a new Objective Function is defined that=20
>> > actually
>> interacts
>> > with the PCE is order to establish the reference topology, in which
>> case
>> > *RPL
>> > operations would only apply to emergency repair actions*. when the=20
>> > reference topology becomes unusable for some failure, and as long=20
>> > as
>> the
>> > problem persists."
>> >
>> > This shot-circuits RPL.
>> >
>> > The two use cases I can see are:
>> > 1. the PCE makes decisions without RPL's intervention. RPL runs in=20
>> > the background for emergency repair actions only.
>> > 2. RPL sets up multi-hop routes which the PCE uses for building
>> tracks.
>> > That is, the PCE only performs L2 resource allocation.
>> >
>> > Do we agree to use only use case 1? If we go for 2, how does the=20
>> > PCE
>> get
>> > information about RPL routes (especially in storing mode)?
>> >
>> > Thomas
>> >
>> > On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA <=20
>> > maria-rita.palattella@uni.lu> wrote:
>> >
>> >> Hi Qin, and all,
>> >> Sorry for coming back to this discussion after some time, but I
>> wanted
>> >> to
>> >> raise and clarify a point.
>> >>
>> >> Qin>>>(2) If there is PCE, there may be different setting. For
>> example,
>> >> PCE is in charge for reserving both multiple hop path (i.e. every
>> next
>> >> hop
>> >> Qin>>>neighbor) and cells; or PCE is just in charge for reserving=20
>> >> Qin>>>the
>> >> multiple hop path and leaving cell reservation to local, and the=20
>> >> distributed cell reservation will meet the bandwidth requirement=20
>> >> from multiple hop path reservation. In the first case, hard Qin>>>=20
>> >> cell  reservation will be used.
>> >>
>> >> Qin >>>(3)If there is no PCE, both multi-hop path and cells are
>> reserved
>> >> in local.
>> >> Qin>>For example, RPL + soft cell reservation in 6tus.
>> >>
>> >> From my point of view (and thinking about TASA implementation),=20
>> >> the
>> PCE
>> >> shouldn't be in charge for reserving the multiple hop path. But=20
>> >> the routing protocol (i.e., RPL in our case) should take care of=20
>> >> the next hop neighbor selection.
>> >> When a centralized approach is adopted, the PCE will schedule the
>> cells
>> >>  (i.e., hard cells according to 6tus terminology).
>> >> While, when a distributed solution is used, 6tus will allocate the
>> soft
>> >> cells.
>> >>
>> >> In the centralized scenario with the PCE, to avoid the exchange of
>> many
>> >> signaling messages, for setting up the schedule, we may think (as
>> Pascal
>> >> was suggesting during one of the last call) to use some hybrid=20
>> >> solutions.
>> >> In other words, if PCE allocates (timeoffset1, channeloffset3,=20
>> >> slotframe1,
>> >> TX) to node A for transmitting to node B, then, node B could know=20
>> >> locally from node A, (and not from the PCE), that the cell=20
>> >> (timeoffset1, channeloffset3, slotframe1, RX) has been reserved to=20
>> >> it, for
>> receiving
>> >> from
>> >> node A.
>> >> We may try to include some functionality in 6tus layer in order to=20
>> >> manage such situation.
>> >> What do you think?
>> >>
>> >> Maria Rita
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> -------------------------------------------
>> >> > On 3/14/13 9:02 PM, Paul Chilton wrote:
>> >> >>>- optionally a PCE sits on the backbone and drives the LLNs'=20
>> >> >>>TSCH schedules.
>> >> >
>> >> > Ah, maybe understood.  It doesn't say that existence of PCE is
>> >> optional.
>> >> > It says that it's optional to put PCE in the backbone.  It=20
>> >> > doesn't preclude to put it on BBR.  Correct ?
>> >> >
>> >> > Shoichi
>> >> > _______________________________________________
>> >> > 6tsch mailing list
>> >> > 6tsch@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/6tsch
>> >> >
>> >>
>> >> _______________________________________________
>> >> 6tsch mailing list
>> >> 6tsch@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/6tsch
>> >> _______________________________________________
>> >> 6tsch mailing list
>> >> 6tsch@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/6tsch
>> >>
>> > _______________________________________________
>> > 6tsch mailing list
>> > 6tsch@ietf.org
>> > https://www.ietf.org/mailman/listinfo/6tsch
>> >
>>
>>
>>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


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

From qinwang@berkeley.edu  Fri Mar 22 06:50:13 2013
Return-Path: 
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 A7B9221F8AC1; Fri, 22 Mar 2013 06:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.199
X-Spam-Level: 
X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
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 ZtZF+sVJDbRK; Fri, 22 Mar 2013 06:50:12 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF2721F8A47; Fri, 22 Mar 2013 06:50:12 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ2ME-00015t-Ei; Fri, 22 Mar 2013 06:50:12 -0700
Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 06:50:10 -0700
Message-ID: <923b8183e356e136c19df594200bf6f8.squirrel@calmail.berkeley.edu>
In-Reply-To: 
References: 
Date: Fri, 22 Mar 2013 06:50:10 -0700
From: "Qin Wang" 
To: "Pascal Thubert (pthubert)" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: Thomas Watteyne , "coman@ietf.org" , IETF 6TSCH <6tsch@ietf.org>, Qin Wang 
Subject: Re: [6tsch] Interaction between NME and PCE
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 13:50:13 -0000

Hi Pascal,

Thank you for your comments.

Just a quick question. By NME, do you refer to Common Network Management
(CNM) in the draft-thubert-6tsch-architecture-00? If yes, my understanding
is that only one of them should be enabled in a network setting. In
another word, it should not be the case that both of them compute TSCH
schedule (i.e. tracks) at one time. Correct? I wonder why we need to
consider both of them functioning at same time in terms of track
computation. Maybe I missed something.

Qin


> Hello Qin;
>
> There is potentially some duplication between what a 6TSCH node would
> exchange with a network management entity  (NME) and with a path
> computation entity (PCE). Basically, the information we want to report
> about peering, neighbors, cell and track utilization can be useful on both
> sides.
>
> And we may even have a use case where the track is entered manually à la
> MPLS TP as opposed to TE, thus coming from NME though, fingers crossed,
> I've not seen that one yet. In that case, the track information could be
> imposed on the 6TSCH node by either NME and PCE, and there could
> potentially be a conflict between those tracks.
>
> If we pick the direct path way of enhancing existing standards:
> 1)  Network Management will have its own mechanisms, based on the work at
> the COMAN ML.
> 2)  Path Computation will have its own mechanisms, probably a PCEP
> enhancement.
> Yet:
> 3)  We do not want to report a lot of information twice from the 6TSCH
> nodes, once for NME and once for PCE.
> 4)  We want the conflicts between manual (NME) and automatic (PCE) routes
> to be sorted between those two before the device sees any of it.
>
> So certainly, PCEP seems to be a most promising venue for centralized
> route computation. For all I know, PCEP in a classical PCE allocates
> lambdas in DWDM, so why wouldn't we enhance it to allocate cells and
> tracks in 6TSCH?
>
> But if we pick PCEP between the node and the PCE for all the PCE related
> exchanges, then we probably want the NME to interact with the PCE to dig
> the related information, and we have to document how that happens. At the
> same time, we have to document how things work when there is no PCE. Looks
> like the PCE would act as a proxy or something.
>
> It makes sense to me that the network management information may be digged
> from a gateway anyway for all sorts on non-IP world compatibility. Cc'ing
> COMAP
>
> Pascal
>
>
> -----Original Message-----
> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of
> Qin Wang
> Sent: lundi 18 mars 2013 20:42
> To: Thomas Watteyne
> Cc: IETF 6TSCH
> Subject: Re: [6tsch] Interaction between RPL and PCE
>
> Thomas,
>
> I'm not very familiar with PCE protocol. According to my knowledge, there
> are extensions of PCE protocol corresponding to different protocols like
> GMPLS. So, maybe a extension of PCE for 6tus is needed, which computes the
> track for given multihop path and bandwidth requirement, or the track for
> given topology and end-to-end bandwidth requirement.
>
> How do you think?
>
> Qin
>
>
>
>> Qin,
>>
>> Please see inline.
>>
>> On Mon, Mar 18, 2013 at 10:25 AM, Qin Wang  wrote:
>>
>>> Thomas,
>>>
>>> I think for a data flow, there are three elements needed to be
>>> defined or scheduled explicitly or implicitly:
>>> (1) multihop path, i.e. who is the next hop neighbor
>>> (2) bandwidth and Qos requirement
>>> (3) cell set (i.e. bundle) to implement the bandwidth
>>>
>>> In case-1, all of the three elements are determined by PCE, and RPL
>>> is just a backup and works on slot-aloha cells. Correct?
>>>
>>
>> I believe that's correct. BTW, I'm not per se advocating for this
>> solution, but it seems to be the approach
>> draft-ietf-roll-rpl-industrial-applicability
>> takes.
>>
>>
>>> In case2, element(1) is determined by RPL based on Rank, and
>>> element(3) is determined by PCE. But, who will determine element(2)?
>>> by PCE or by some entity like RSVP/NSIS or DSCP?
>>>
>>>
>> Agreed. It relatively straightforward for a PCE to compute a schedule
>> and distribute that into the network, but how does it figure out what
>> the requirements are from the nodes in the network. Could we reuse a
>> "PCE requirements" protocol out there?
>>
>>
>>> Qin
>>>
>>> > [subject was: Scope: 6LoWPAN + 1]
>>> >
>>> > Maria Rita,
>>> >
>>> > I fully agree with Pascal's suggestion to have the PCE only talk to
>>> one
>>> of
>>> > the two sides on a on-hop link, and have 6tus be in charge to
>>> > telling
>>> the
>>> > other side to reserve the same cell. I believe Qin has also
>>> acknowledged
>>> > this, and has agreed to put this mechanism into 6tus. This would
>>> probably
>>> > mean adding some option in the 6tus message format saying "this is
>>> > not
>>> a
>>> > negociation for a soft cell, but an order for you to add this hard
>>> cell".
>>> >
>>> > All,
>>> >
>>> > I believe Maria Rita is touching a very important point we haven't
>>> > had time to discuss last week in Orlando, but which I believe is
>>> > essential: how
>>> do
>>> > RPL and the PCE interact? The PCE can have complete knowledge of
>>> > the network topology and the network traffic, so besides L2
>>> > resource allocation, it could also make routing decision, i.e.
>>> > build the track
>>> it
>>> > believe is best fit.
>>> >
>>> > draft-ietf-roll-rpl-industrial-applicability-00 also states similar
>>> ideas:
>>> > "The domain of applicability for the RPL protocol may include all
>>> phases
>>> > but the Normal Operation phase, where the bandwidth allocation and
>>> > the *routes are usually optimized by an external Path Computing
>>> > Engine (PCE)*.
>>> [...]
>>> > Additionally, it could be envisioned to include RPL in the normal
>>> > operation provided that a new Objective Function is defined that
>>> > actually
>>> interacts
>>> > with the PCE is order to establish the reference topology, in which
>>> case
>>> > *RPL
>>> > operations would only apply to emergency repair actions*. when the
>>> > reference topology becomes unusable for some failure, and as long
>>> > as
>>> the
>>> > problem persists."
>>> >
>>> > This shot-circuits RPL.
>>> >
>>> > The two use cases I can see are:
>>> > 1. the PCE makes decisions without RPL's intervention. RPL runs in
>>> > the background for emergency repair actions only.
>>> > 2. RPL sets up multi-hop routes which the PCE uses for building
>>> tracks.
>>> > That is, the PCE only performs L2 resource allocation.
>>> >
>>> > Do we agree to use only use case 1? If we go for 2, how does the
>>> > PCE
>>> get
>>> > information about RPL routes (especially in storing mode)?
>>> >
>>> > Thomas
>>> >
>>> > On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA <
>>> > maria-rita.palattella@uni.lu> wrote:
>>> >
>>> >> Hi Qin, and all,
>>> >> Sorry for coming back to this discussion after some time, but I
>>> wanted
>>> >> to
>>> >> raise and clarify a point.
>>> >>
>>> >> Qin>>>(2) If there is PCE, there may be different setting. For
>>> example,
>>> >> PCE is in charge for reserving both multiple hop path (i.e. every
>>> next
>>> >> hop
>>> >> Qin>>>neighbor) and cells; or PCE is just in charge for reserving
>>> >> Qin>>>the
>>> >> multiple hop path and leaving cell reservation to local, and the
>>> >> distributed cell reservation will meet the bandwidth requirement
>>> >> from multiple hop path reservation. In the first case, hard Qin>>>
>>> >> cell  reservation will be used.
>>> >>
>>> >> Qin >>>(3)If there is no PCE, both multi-hop path and cells are
>>> reserved
>>> >> in local.
>>> >> Qin>>For example, RPL + soft cell reservation in 6tus.
>>> >>
>>> >> From my point of view (and thinking about TASA implementation),
>>> >> the
>>> PCE
>>> >> shouldn't be in charge for reserving the multiple hop path. But
>>> >> the routing protocol (i.e., RPL in our case) should take care of
>>> >> the next hop neighbor selection.
>>> >> When a centralized approach is adopted, the PCE will schedule the
>>> cells
>>> >>  (i.e., hard cells according to 6tus terminology).
>>> >> While, when a distributed solution is used, 6tus will allocate the
>>> soft
>>> >> cells.
>>> >>
>>> >> In the centralized scenario with the PCE, to avoid the exchange of
>>> many
>>> >> signaling messages, for setting up the schedule, we may think (as
>>> Pascal
>>> >> was suggesting during one of the last call) to use some hybrid
>>> >> solutions.
>>> >> In other words, if PCE allocates (timeoffset1, channeloffset3,
>>> >> slotframe1,
>>> >> TX) to node A for transmitting to node B, then, node B could know
>>> >> locally from node A, (and not from the PCE), that the cell
>>> >> (timeoffset1, channeloffset3, slotframe1, RX) has been reserved to
>>> >> it, for
>>> receiving
>>> >> from
>>> >> node A.
>>> >> We may try to include some functionality in 6tus layer in order to
>>> >> manage such situation.
>>> >> What do you think?
>>> >>
>>> >> Maria Rita
>>> >>
>>> >>
>>> >>
>>> ---------------------------------------------------------------------
>>> -------------------------------------------
>>> >> > On 3/14/13 9:02 PM, Paul Chilton wrote:
>>> >> >>>- optionally a PCE sits on the backbone and drives the LLNs'
>>> >> >>>TSCH schedules.
>>> >> >
>>> >> > Ah, maybe understood.  It doesn't say that existence of PCE is
>>> >> optional.
>>> >> > It says that it's optional to put PCE in the backbone.  It
>>> >> > doesn't preclude to put it on BBR.  Correct ?
>>> >> >
>>> >> > Shoichi
>>> >> > _______________________________________________
>>> >> > 6tsch mailing list
>>> >> > 6tsch@ietf.org
>>> >> > https://www.ietf.org/mailman/listinfo/6tsch
>>> >> >
>>> >>
>>> >> _______________________________________________
>>> >> 6tsch mailing list
>>> >> 6tsch@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/6tsch
>>> >> _______________________________________________
>>> >> 6tsch mailing list
>>> >> 6tsch@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/6tsch
>>> >>
>>> > _______________________________________________
>>> > 6tsch mailing list
>>> > 6tsch@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/6tsch
>>> >
>>>
>>>
>>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


From pthubert@cisco.com  Fri Mar 22 07:26:17 2013
Return-Path: 
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 2117121F85CE; Fri, 22 Mar 2013 07:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level: 
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_23=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 mqh5yibOBr62; Fri, 22 Mar 2013 07:26:15 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 490AB21F85BC; Fri, 22 Mar 2013 07:26:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16450; q=dns/txt; s=iport; t=1363962375; x=1365171975; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=A53zmXCZplOta3wNpb/gcTI0Pqh0yY1kHfGa5xfJrCQ=; b=i18C56w2oCZtr+R8DshwPbYrYFoNkSORYIqzCUqm8rYO6h+i+X4Ag5BX JGYE3s5uYiReWkDLcwY8x+bnx93aGX2XSxq96QFdTqexx790M26tnd7xO GBPnQ/Rs2jnramjBxbTUgoODOgu2csqb0mQnohTfugktgXtL3KMZ5Ec68 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAARpTFGtJV2d/2dsb2JhbABDDogdvSRzcBZ0giQBAQEDAQEBASAROgsFBwQCAQgRAQMBAQECAgYdAwICAiULFAECBggBAQQOBQgTh3MGDLABkikEgSOMJoEYJgsHBoInMmEDkx6USoJLP4Io
X-IronPort-AV: E=Sophos;i="4.84,891,1355097600"; d="scan'208";a="190408866"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 22 Mar 2013 14:26:14 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2MEQEIO019904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 14:26:14 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 09:26:14 -0500
From: "Pascal Thubert (pthubert)" 
To: Qin Wang 
Thread-Topic: Interaction between NME and PCE
Thread-Index: Ac4m1AAaAig2JGZERcC75DTjyWBvYAAWhQEAAAnM52A=
Date: Fri, 22 Mar 2013 14:26:13 +0000
Deferred-Delivery: Fri, 22 Mar 2013 14:25:00 +0000
Message-ID: 
References:  <923b8183e356e136c19df594200bf6f8.squirrel@calmail.berkeley.edu>
In-Reply-To: <923b8183e356e136c19df594200bf6f8.squirrel@calmail.berkeley.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.85.19]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Thomas Watteyne , "coman@ietf.org" , IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Interaction between NME and PCE
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 14:26:17 -0000

SGVsbG8gUWluOg0KDQpJIHVzZSBOTUUgYXMgdGhlIGNvbW1vbiBuYW1lIGZvciB0aGUgTmV0d29y
ayBNYW5hZ2VtZW50IEVudGl0eS4gQ05NIGlzIG1vcmUgc3BlY2lmaWMsIGl0IGlzIGEgcGFydGlj
dWxhciBncm91cCwgV0cyMCBhdCBJU0ExMDAgKHRodXMgSVNBMTAwLjIwKS4NCklTQTEwMC4yMCBD
Tk0gd2lsbCBkZWZpbmUgYW4gYWJzdHJhY3QgbWFuYWdlciBvZiBtYW5hZ2Vycy4gQSBDTk0gRW50
aXR5IHNob3VsZCBiZSBhYmxlIHRvIHRhbGsgaW4gYSB1bmlmaWVkIGZhc2hpb24gdG8gTk1FcyBm
cm9tIGRpZmZlcmVudCBvcmlnaW5zLCBsaWtlIElTQTEwMC4xMWEsIFdJQVBBIG9yIHdpSEFSVCAo
b3IgQ09NQU4pLiBUaGUgaWRlYSBiZWluZyB0aGF0IHRoZSBhZG1pbiBjYW4gZG8gdGhpbmdzIG9u
Y2UgYXQgdGhlIENOTSBsZXZlbCBhbmQgdGhlbiBnZXQgdGhlIGV4ZWN1dGlvbiBkaXN0cmlidXRl
ZCB0aHJvdWdoIHRoZSBtb3JlIHNwZWNpZmljIE5NRXMgZm9yIHRoZSBwYXJ0aWN1bGFyIG5ldHdv
cmtzIHRoYXQgdGhleSBjYW4gaGFuZGxlLiANCg0KTXkgZ29hbCB3aXRoIENOTSB3b3VsZCBiZSB0
aGF0IHRoZSBDTk0gZm9ybWF0cyB0cmFuc2xhdGUgZWFzaWx5IG9mIG5vdCBuYXRpdmVseSBpbnRv
IHRoZSBDT01BTiBmb3JtYXRzLg0KDQpOb3csIGFzIEkgc2FpZCwgd2UgZG8gbm90IGhhdmUgYSB1
c2UgY2FzZSByaWdodCBub3cgZm9yIGEgbWFudWFsIHRyYWNrIGVuZm9yY2VtZW50ICjDoCBsYSBN
UExTLVRQKSBmcm9tIHRoZSBuZXR3b3JrIG1hbmFnZW1lbnQgY29uc29sZS4NCkhvcGVmdWxseSB0
aGlzIHdpbGwgbmV2ZXIgY29tZS4gQnV0IGlmIGl0IGRvZXMsIEknbSBzYXlpbmcgdGhhdCB0aGUg
Y29sbGlzaW9ucyBzaG91bGQgYmUgc29ydGVkIG91dCBieSBkaXJlY3QgY29tbXVuaWNhdGlvbiBi
ZXR3ZWVuIE5NQSBhbmQgUENFLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRaW4gV2FuZyBbbWFpbHRvOnFpbndhbmdAYmVya2VsZXku
ZWR1XSANClNlbnQ6IHZlbmRyZWRpIDIyIG1hcnMgMjAxMyAxNDo1MA0KVG86IFBhc2NhbCBUaHVi
ZXJ0IChwdGh1YmVydCkNCkNjOiBRaW4gV2FuZzsgVGhvbWFzIFdhdHRleW5lOyBJRVRGIDZUU0NI
OyBjb21hbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IEludGVyYWN0aW9uIGJldHdlZW4gTk1FIGFu
ZCBQQ0UNCg0KSGkgUGFzY2FsLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuDQoNCkp1
c3QgYSBxdWljayBxdWVzdGlvbi4gQnkgTk1FLCBkbyB5b3UgcmVmZXIgdG8gQ29tbW9uIE5ldHdv
cmsgTWFuYWdlbWVudA0KKENOTSkgaW4gdGhlIGRyYWZ0LXRodWJlcnQtNnRzY2gtYXJjaGl0ZWN0
dXJlLTAwPyBJZiB5ZXMsIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBvbmx5IG9uZSBvZiB0aGVt
IHNob3VsZCBiZSBlbmFibGVkIGluIGEgbmV0d29yayBzZXR0aW5nLiBJbiBhbm90aGVyIHdvcmQs
IGl0IHNob3VsZCBub3QgYmUgdGhlIGNhc2UgdGhhdCBib3RoIG9mIHRoZW0gY29tcHV0ZSBUU0NI
IHNjaGVkdWxlIChpLmUuIHRyYWNrcykgYXQgb25lIHRpbWUuIENvcnJlY3Q/IEkgd29uZGVyIHdo
eSB3ZSBuZWVkIHRvIGNvbnNpZGVyIGJvdGggb2YgdGhlbSBmdW5jdGlvbmluZyBhdCBzYW1lIHRp
bWUgaW4gdGVybXMgb2YgdHJhY2sgY29tcHV0YXRpb24uIE1heWJlIEkgbWlzc2VkIHNvbWV0aGlu
Zy4NCg0KUWluDQoNCg0KPiBIZWxsbyBRaW47DQo+DQo+IFRoZXJlIGlzIHBvdGVudGlhbGx5IHNv
bWUgZHVwbGljYXRpb24gYmV0d2VlbiB3aGF0IGEgNlRTQ0ggbm9kZSB3b3VsZCANCj4gZXhjaGFu
Z2Ugd2l0aCBhIG5ldHdvcmsgbWFuYWdlbWVudCBlbnRpdHkgIChOTUUpIGFuZCB3aXRoIGEgcGF0
aCANCj4gY29tcHV0YXRpb24gZW50aXR5IChQQ0UpLiBCYXNpY2FsbHksIHRoZSBpbmZvcm1hdGlv
biB3ZSB3YW50IHRvIHJlcG9ydCANCj4gYWJvdXQgcGVlcmluZywgbmVpZ2hib3JzLCBjZWxsIGFu
ZCB0cmFjayB1dGlsaXphdGlvbiBjYW4gYmUgdXNlZnVsIG9uIA0KPiBib3RoIHNpZGVzLg0KPg0K
PiBBbmQgd2UgbWF5IGV2ZW4gaGF2ZSBhIHVzZSBjYXNlIHdoZXJlIHRoZSB0cmFjayBpcyBlbnRl
cmVkIG1hbnVhbGx5IMOgIA0KPiBsYSBNUExTIFRQIGFzIG9wcG9zZWQgdG8gVEUsIHRodXMgY29t
aW5nIGZyb20gTk1FIHRob3VnaCwgZmluZ2VycyANCj4gY3Jvc3NlZCwgSSd2ZSBub3Qgc2VlbiB0
aGF0IG9uZSB5ZXQuIEluIHRoYXQgY2FzZSwgdGhlIHRyYWNrIA0KPiBpbmZvcm1hdGlvbiBjb3Vs
ZCBiZSBpbXBvc2VkIG9uIHRoZSA2VFNDSCBub2RlIGJ5IGVpdGhlciBOTUUgYW5kIFBDRSwgDQo+
IGFuZCB0aGVyZSBjb3VsZCBwb3RlbnRpYWxseSBiZSBhIGNvbmZsaWN0IGJldHdlZW4gdGhvc2Ug
dHJhY2tzLg0KPg0KPiBJZiB3ZSBwaWNrIHRoZSBkaXJlY3QgcGF0aCB3YXkgb2YgZW5oYW5jaW5n
IGV4aXN0aW5nIHN0YW5kYXJkczoNCj4gMSkgIE5ldHdvcmsgTWFuYWdlbWVudCB3aWxsIGhhdmUg
aXRzIG93biBtZWNoYW5pc21zLCBiYXNlZCBvbiB0aGUgd29yayANCj4gYXQgdGhlIENPTUFOIE1M
Lg0KPiAyKSAgUGF0aCBDb21wdXRhdGlvbiB3aWxsIGhhdmUgaXRzIG93biBtZWNoYW5pc21zLCBw
cm9iYWJseSBhIFBDRVAgDQo+IGVuaGFuY2VtZW50Lg0KPiBZZXQ6DQo+IDMpICBXZSBkbyBub3Qg
d2FudCB0byByZXBvcnQgYSBsb3Qgb2YgaW5mb3JtYXRpb24gdHdpY2UgZnJvbSB0aGUgNlRTQ0gg
DQo+IG5vZGVzLCBvbmNlIGZvciBOTUUgYW5kIG9uY2UgZm9yIFBDRS4NCj4gNCkgIFdlIHdhbnQg
dGhlIGNvbmZsaWN0cyBiZXR3ZWVuIG1hbnVhbCAoTk1FKSBhbmQgYXV0b21hdGljIChQQ0UpIA0K
PiByb3V0ZXMgdG8gYmUgc29ydGVkIGJldHdlZW4gdGhvc2UgdHdvIGJlZm9yZSB0aGUgZGV2aWNl
IHNlZXMgYW55IG9mIGl0Lg0KPg0KPiBTbyBjZXJ0YWlubHksIFBDRVAgc2VlbXMgdG8gYmUgYSBt
b3N0IHByb21pc2luZyB2ZW51ZSBmb3IgY2VudHJhbGl6ZWQgDQo+IHJvdXRlIGNvbXB1dGF0aW9u
LiBGb3IgYWxsIEkga25vdywgUENFUCBpbiBhIGNsYXNzaWNhbCBQQ0UgYWxsb2NhdGVzIA0KPiBs
YW1iZGFzIGluIERXRE0sIHNvIHdoeSB3b3VsZG4ndCB3ZSBlbmhhbmNlIGl0IHRvIGFsbG9jYXRl
IGNlbGxzIGFuZCANCj4gdHJhY2tzIGluIDZUU0NIPw0KPg0KPiBCdXQgaWYgd2UgcGljayBQQ0VQ
IGJldHdlZW4gdGhlIG5vZGUgYW5kIHRoZSBQQ0UgZm9yIGFsbCB0aGUgUENFIA0KPiByZWxhdGVk
IGV4Y2hhbmdlcywgdGhlbiB3ZSBwcm9iYWJseSB3YW50IHRoZSBOTUUgdG8gaW50ZXJhY3Qgd2l0
aCB0aGUgDQo+IFBDRSB0byBkaWcgdGhlIHJlbGF0ZWQgaW5mb3JtYXRpb24sIGFuZCB3ZSBoYXZl
IHRvIGRvY3VtZW50IGhvdyB0aGF0IA0KPiBoYXBwZW5zLiBBdCB0aGUgc2FtZSB0aW1lLCB3ZSBo
YXZlIHRvIGRvY3VtZW50IGhvdyB0aGluZ3Mgd29yayB3aGVuIA0KPiB0aGVyZSBpcyBubyBQQ0Uu
IExvb2tzIGxpa2UgdGhlIFBDRSB3b3VsZCBhY3QgYXMgYSBwcm94eSBvciBzb21ldGhpbmcuDQo+
DQo+IEl0IG1ha2VzIHNlbnNlIHRvIG1lIHRoYXQgdGhlIG5ldHdvcmsgbWFuYWdlbWVudCBpbmZv
cm1hdGlvbiBtYXkgYmUgDQo+IGRpZ2dlZCBmcm9tIGEgZ2F0ZXdheSBhbnl3YXkgZm9yIGFsbCBz
b3J0cyBvbiBub24tSVAgd29ybGQgDQo+IGNvbXBhdGliaWxpdHkuIENjJ2luZyBDT01BUA0KPg0K
PiBQYXNjYWwNCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogNnRz
Y2gtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOjZ0c2NoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiANCj4gT2YgUWluIFdhbmcNCj4gU2VudDogbHVuZGkgMTggbWFycyAyMDEzIDIwOjQyDQo+
IFRvOiBUaG9tYXMgV2F0dGV5bmUNCj4gQ2M6IElFVEYgNlRTQ0gNCj4gU3ViamVjdDogUmU6IFs2
dHNjaF0gSW50ZXJhY3Rpb24gYmV0d2VlbiBSUEwgYW5kIFBDRQ0KPg0KPiBUaG9tYXMsDQo+DQo+
IEknbSBub3QgdmVyeSBmYW1pbGlhciB3aXRoIFBDRSBwcm90b2NvbC4gQWNjb3JkaW5nIHRvIG15
IGtub3dsZWRnZSwgDQo+IHRoZXJlIGFyZSBleHRlbnNpb25zIG9mIFBDRSBwcm90b2NvbCBjb3Jy
ZXNwb25kaW5nIHRvIGRpZmZlcmVudCANCj4gcHJvdG9jb2xzIGxpa2UgR01QTFMuIFNvLCBtYXli
ZSBhIGV4dGVuc2lvbiBvZiBQQ0UgZm9yIDZ0dXMgaXMgbmVlZGVkLCANCj4gd2hpY2ggY29tcHV0
ZXMgdGhlIHRyYWNrIGZvciBnaXZlbiBtdWx0aWhvcCBwYXRoIGFuZCBiYW5kd2lkdGggDQo+IHJl
cXVpcmVtZW50LCBvciB0aGUgdHJhY2sgZm9yIGdpdmVuIHRvcG9sb2d5IGFuZCBlbmQtdG8tZW5k
IGJhbmR3aWR0aCByZXF1aXJlbWVudC4NCj4NCj4gSG93IGRvIHlvdSB0aGluaz8NCj4NCj4gUWlu
DQo+DQo+DQo+DQo+PiBRaW4sDQo+Pg0KPj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+Pg0KPj4gT24g
TW9uLCBNYXIgMTgsIDIwMTMgYXQgMTA6MjUgQU0sIFFpbiBXYW5nIDxxaW53YW5nQGJlcmtlbGV5
LmVkdT4gd3JvdGU6DQo+Pg0KPj4+IFRob21hcywNCj4+Pg0KPj4+IEkgdGhpbmsgZm9yIGEgZGF0
YSBmbG93LCB0aGVyZSBhcmUgdGhyZWUgZWxlbWVudHMgbmVlZGVkIHRvIGJlIA0KPj4+IGRlZmlu
ZWQgb3Igc2NoZWR1bGVkIGV4cGxpY2l0bHkgb3IgaW1wbGljaXRseToNCj4+PiAoMSkgbXVsdGlo
b3AgcGF0aCwgaS5lLiB3aG8gaXMgdGhlIG5leHQgaG9wIG5laWdoYm9yDQo+Pj4gKDIpIGJhbmR3
aWR0aCBhbmQgUW9zIHJlcXVpcmVtZW50DQo+Pj4gKDMpIGNlbGwgc2V0IChpLmUuIGJ1bmRsZSkg
dG8gaW1wbGVtZW50IHRoZSBiYW5kd2lkdGgNCj4+Pg0KPj4+IEluIGNhc2UtMSwgYWxsIG9mIHRo
ZSB0aHJlZSBlbGVtZW50cyBhcmUgZGV0ZXJtaW5lZCBieSBQQ0UsIGFuZCBSUEwgDQo+Pj4gaXMg
anVzdCBhIGJhY2t1cCBhbmQgd29ya3Mgb24gc2xvdC1hbG9oYSBjZWxscy4gQ29ycmVjdD8NCj4+
Pg0KPj4NCj4+IEkgYmVsaWV2ZSB0aGF0J3MgY29ycmVjdC4gQlRXLCBJJ20gbm90IHBlciBzZSBh
ZHZvY2F0aW5nIGZvciB0aGlzIA0KPj4gc29sdXRpb24sIGJ1dCBpdCBzZWVtcyB0byBiZSB0aGUg
YXBwcm9hY2ggDQo+PiBkcmFmdC1pZXRmLXJvbGwtcnBsLWluZHVzdHJpYWwtYXBwbGljYWJpbGl0
eQ0KPj4gdGFrZXMuDQo+Pg0KPj4NCj4+PiBJbiBjYXNlMiwgZWxlbWVudCgxKSBpcyBkZXRlcm1p
bmVkIGJ5IFJQTCBiYXNlZCBvbiBSYW5rLCBhbmQNCj4+PiBlbGVtZW50KDMpIGlzIGRldGVybWlu
ZWQgYnkgUENFLiBCdXQsIHdobyB3aWxsIGRldGVybWluZSBlbGVtZW50KDIpPw0KPj4+IGJ5IFBD
RSBvciBieSBzb21lIGVudGl0eSBsaWtlIFJTVlAvTlNJUyBvciBEU0NQPw0KPj4+DQo+Pj4NCj4+
IEFncmVlZC4gSXQgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQgZm9yIGEgUENFIHRvIGNvbXB1
dGUgYSBzY2hlZHVsZSANCj4+IGFuZCBkaXN0cmlidXRlIHRoYXQgaW50byB0aGUgbmV0d29yaywg
YnV0IGhvdyBkb2VzIGl0IGZpZ3VyZSBvdXQgd2hhdCANCj4+IHRoZSByZXF1aXJlbWVudHMgYXJl
IGZyb20gdGhlIG5vZGVzIGluIHRoZSBuZXR3b3JrLiBDb3VsZCB3ZSByZXVzZSBhIA0KPj4gIlBD
RSByZXF1aXJlbWVudHMiIHByb3RvY29sIG91dCB0aGVyZT8NCj4+DQo+Pg0KPj4+IFFpbg0KPj4+
DQo+Pj4gPiBbc3ViamVjdCB3YXM6IFNjb3BlOiA2TG9XUEFOICsgMV0NCj4+PiA+DQo+Pj4gPiBN
YXJpYSBSaXRhLA0KPj4+ID4NCj4+PiA+IEkgZnVsbHkgYWdyZWUgd2l0aCBQYXNjYWwncyBzdWdn
ZXN0aW9uIHRvIGhhdmUgdGhlIFBDRSBvbmx5IHRhbGsgDQo+Pj4gPiB0bw0KPj4+IG9uZQ0KPj4+
IG9mDQo+Pj4gPiB0aGUgdHdvIHNpZGVzIG9uIGEgb24taG9wIGxpbmssIGFuZCBoYXZlIDZ0dXMg
YmUgaW4gY2hhcmdlIHRvIA0KPj4+ID4gdGVsbGluZw0KPj4+IHRoZQ0KPj4+ID4gb3RoZXIgc2lk
ZSB0byByZXNlcnZlIHRoZSBzYW1lIGNlbGwuIEkgYmVsaWV2ZSBRaW4gaGFzIGFsc28NCj4+PiBh
Y2tub3dsZWRnZWQNCj4+PiA+IHRoaXMsIGFuZCBoYXMgYWdyZWVkIHRvIHB1dCB0aGlzIG1lY2hh
bmlzbSBpbnRvIDZ0dXMuIFRoaXMgd291bGQNCj4+PiBwcm9iYWJseQ0KPj4+ID4gbWVhbiBhZGRp
bmcgc29tZSBvcHRpb24gaW4gdGhlIDZ0dXMgbWVzc2FnZSBmb3JtYXQgc2F5aW5nICJ0aGlzIGlz
IA0KPj4+ID4gbm90DQo+Pj4gYQ0KPj4+ID4gbmVnb2NpYXRpb24gZm9yIGEgc29mdCBjZWxsLCBi
dXQgYW4gb3JkZXIgZm9yIHlvdSB0byBhZGQgdGhpcyBoYXJkDQo+Pj4gY2VsbCIuDQo+Pj4gPg0K
Pj4+ID4gQWxsLA0KPj4+ID4NCj4+PiA+IEkgYmVsaWV2ZSBNYXJpYSBSaXRhIGlzIHRvdWNoaW5n
IGEgdmVyeSBpbXBvcnRhbnQgcG9pbnQgd2UgaGF2ZW4ndCANCj4+PiA+IGhhZCB0aW1lIHRvIGRp
c2N1c3MgbGFzdCB3ZWVrIGluIE9ybGFuZG8sIGJ1dCB3aGljaCBJIGJlbGlldmUgaXMNCj4+PiA+
IGVzc2VudGlhbDogaG93DQo+Pj4gZG8NCj4+PiA+IFJQTCBhbmQgdGhlIFBDRSBpbnRlcmFjdD8g
VGhlIFBDRSBjYW4gaGF2ZSBjb21wbGV0ZSBrbm93bGVkZ2Ugb2YgDQo+Pj4gPiB0aGUgbmV0d29y
ayB0b3BvbG9neSBhbmQgdGhlIG5ldHdvcmsgdHJhZmZpYywgc28gYmVzaWRlcyBMMiANCj4+PiA+
IHJlc291cmNlIGFsbG9jYXRpb24sIGl0IGNvdWxkIGFsc28gbWFrZSByb3V0aW5nIGRlY2lzaW9u
LCBpLmUuDQo+Pj4gPiBidWlsZCB0aGUgdHJhY2sNCj4+PiBpdA0KPj4+ID4gYmVsaWV2ZSBpcyBi
ZXN0IGZpdC4NCj4+PiA+DQo+Pj4gPiBkcmFmdC1pZXRmLXJvbGwtcnBsLWluZHVzdHJpYWwtYXBw
bGljYWJpbGl0eS0wMCBhbHNvIHN0YXRlcyANCj4+PiA+IHNpbWlsYXINCj4+PiBpZGVhczoNCj4+
PiA+ICJUaGUgZG9tYWluIG9mIGFwcGxpY2FiaWxpdHkgZm9yIHRoZSBSUEwgcHJvdG9jb2wgbWF5
IGluY2x1ZGUgYWxsDQo+Pj4gcGhhc2VzDQo+Pj4gPiBidXQgdGhlIE5vcm1hbCBPcGVyYXRpb24g
cGhhc2UsIHdoZXJlIHRoZSBiYW5kd2lkdGggYWxsb2NhdGlvbiBhbmQgDQo+Pj4gPiB0aGUgKnJv
dXRlcyBhcmUgdXN1YWxseSBvcHRpbWl6ZWQgYnkgYW4gZXh0ZXJuYWwgUGF0aCBDb21wdXRpbmcg
DQo+Pj4gPiBFbmdpbmUgKFBDRSkqLg0KPj4+IFsuLi5dDQo+Pj4gPiBBZGRpdGlvbmFsbHksIGl0
IGNvdWxkIGJlIGVudmlzaW9uZWQgdG8gaW5jbHVkZSBSUEwgaW4gdGhlIG5vcm1hbCANCj4+PiA+
IG9wZXJhdGlvbiBwcm92aWRlZCB0aGF0IGEgbmV3IE9iamVjdGl2ZSBGdW5jdGlvbiBpcyBkZWZp
bmVkIHRoYXQgDQo+Pj4gPiBhY3R1YWxseQ0KPj4+IGludGVyYWN0cw0KPj4+ID4gd2l0aCB0aGUg
UENFIGlzIG9yZGVyIHRvIGVzdGFibGlzaCB0aGUgcmVmZXJlbmNlIHRvcG9sb2d5LCBpbiANCj4+
PiA+IHdoaWNoDQo+Pj4gY2FzZQ0KPj4+ID4gKlJQTA0KPj4+ID4gb3BlcmF0aW9ucyB3b3VsZCBv
bmx5IGFwcGx5IHRvIGVtZXJnZW5jeSByZXBhaXIgYWN0aW9ucyouIHdoZW4gdGhlIA0KPj4+ID4g
cmVmZXJlbmNlIHRvcG9sb2d5IGJlY29tZXMgdW51c2FibGUgZm9yIHNvbWUgZmFpbHVyZSwgYW5k
IGFzIGxvbmcgDQo+Pj4gPiBhcw0KPj4+IHRoZQ0KPj4+ID4gcHJvYmxlbSBwZXJzaXN0cy4iDQo+
Pj4gPg0KPj4+ID4gVGhpcyBzaG90LWNpcmN1aXRzIFJQTC4NCj4+PiA+DQo+Pj4gPiBUaGUgdHdv
IHVzZSBjYXNlcyBJIGNhbiBzZWUgYXJlOg0KPj4+ID4gMS4gdGhlIFBDRSBtYWtlcyBkZWNpc2lv
bnMgd2l0aG91dCBSUEwncyBpbnRlcnZlbnRpb24uIFJQTCBydW5zIGluIA0KPj4+ID4gdGhlIGJh
Y2tncm91bmQgZm9yIGVtZXJnZW5jeSByZXBhaXIgYWN0aW9ucyBvbmx5Lg0KPj4+ID4gMi4gUlBM
IHNldHMgdXAgbXVsdGktaG9wIHJvdXRlcyB3aGljaCB0aGUgUENFIHVzZXMgZm9yIGJ1aWxkaW5n
DQo+Pj4gdHJhY2tzLg0KPj4+ID4gVGhhdCBpcywgdGhlIFBDRSBvbmx5IHBlcmZvcm1zIEwyIHJl
c291cmNlIGFsbG9jYXRpb24uDQo+Pj4gPg0KPj4+ID4gRG8gd2UgYWdyZWUgdG8gdXNlIG9ubHkg
dXNlIGNhc2UgMT8gSWYgd2UgZ28gZm9yIDIsIGhvdyBkb2VzIHRoZSANCj4+PiA+IFBDRQ0KPj4+
IGdldA0KPj4+ID4gaW5mb3JtYXRpb24gYWJvdXQgUlBMIHJvdXRlcyAoZXNwZWNpYWxseSBpbiBz
dG9yaW5nIG1vZGUpPw0KPj4+ID4NCj4+PiA+IFRob21hcw0KPj4+ID4NCj4+PiA+IE9uIE1vbiwg
TWFyIDE4LCAyMDEzIGF0IDI6MDYgQU0sIE1hcmlhIFJpdGEgUEFMQVRURUxMQSA8IA0KPj4+ID4g
bWFyaWEtcml0YS5wYWxhdHRlbGxhQHVuaS5sdT4gd3JvdGU6DQo+Pj4gPg0KPj4+ID4+IEhpIFFp
biwgYW5kIGFsbCwNCj4+PiA+PiBTb3JyeSBmb3IgY29taW5nIGJhY2sgdG8gdGhpcyBkaXNjdXNz
aW9uIGFmdGVyIHNvbWUgdGltZSwgYnV0IEkNCj4+PiB3YW50ZWQNCj4+PiA+PiB0bw0KPj4+ID4+
IHJhaXNlIGFuZCBjbGFyaWZ5IGEgcG9pbnQuDQo+Pj4gPj4NCj4+PiA+PiBRaW4+Pj4oMikgSWYg
dGhlcmUgaXMgUENFLCB0aGVyZSBtYXkgYmUgZGlmZmVyZW50IHNldHRpbmcuIEZvcg0KPj4+IGV4
YW1wbGUsDQo+Pj4gPj4gUENFIGlzIGluIGNoYXJnZSBmb3IgcmVzZXJ2aW5nIGJvdGggbXVsdGlw
bGUgaG9wIHBhdGggKGkuZS4gZXZlcnkNCj4+PiBuZXh0DQo+Pj4gPj4gaG9wDQo+Pj4gPj4gUWlu
Pj4+bmVpZ2hib3IpIGFuZCBjZWxsczsgb3IgUENFIGlzIGp1c3QgaW4gY2hhcmdlIGZvciByZXNl
cnZpbmcgDQo+Pj4gPj4gUWluPj4+dGhlDQo+Pj4gPj4gbXVsdGlwbGUgaG9wIHBhdGggYW5kIGxl
YXZpbmcgY2VsbCByZXNlcnZhdGlvbiB0byBsb2NhbCwgYW5kIHRoZSANCj4+PiA+PiBkaXN0cmli
dXRlZCBjZWxsIHJlc2VydmF0aW9uIHdpbGwgbWVldCB0aGUgYmFuZHdpZHRoIHJlcXVpcmVtZW50
IA0KPj4+ID4+IGZyb20gbXVsdGlwbGUgaG9wIHBhdGggcmVzZXJ2YXRpb24uIEluIHRoZSBmaXJz
dCBjYXNlLCBoYXJkIA0KPj4+ID4+IFFpbj4+PiBjZWxsICByZXNlcnZhdGlvbiB3aWxsIGJlIHVz
ZWQuDQo+Pj4gPj4NCj4+PiA+PiBRaW4gPj4+KDMpSWYgdGhlcmUgaXMgbm8gUENFLCBib3RoIG11
bHRpLWhvcCBwYXRoIGFuZCBjZWxscyBhcmUNCj4+PiByZXNlcnZlZA0KPj4+ID4+IGluIGxvY2Fs
Lg0KPj4+ID4+IFFpbj4+Rm9yIGV4YW1wbGUsIFJQTCArIHNvZnQgY2VsbCByZXNlcnZhdGlvbiBp
biA2dHVzLg0KPj4+ID4+DQo+Pj4gPj4gRnJvbSBteSBwb2ludCBvZiB2aWV3IChhbmQgdGhpbmtp
bmcgYWJvdXQgVEFTQSBpbXBsZW1lbnRhdGlvbiksIA0KPj4+ID4+IHRoZQ0KPj4+IFBDRQ0KPj4+
ID4+IHNob3VsZG4ndCBiZSBpbiBjaGFyZ2UgZm9yIHJlc2VydmluZyB0aGUgbXVsdGlwbGUgaG9w
IHBhdGguIEJ1dCANCj4+PiA+PiB0aGUgcm91dGluZyBwcm90b2NvbCAoaS5lLiwgUlBMIGluIG91
ciBjYXNlKSBzaG91bGQgdGFrZSBjYXJlIG9mIA0KPj4+ID4+IHRoZSBuZXh0IGhvcCBuZWlnaGJv
ciBzZWxlY3Rpb24uDQo+Pj4gPj4gV2hlbiBhIGNlbnRyYWxpemVkIGFwcHJvYWNoIGlzIGFkb3B0
ZWQsIHRoZSBQQ0Ugd2lsbCBzY2hlZHVsZSB0aGUNCj4+PiBjZWxscw0KPj4+ID4+ICAoaS5lLiwg
aGFyZCBjZWxscyBhY2NvcmRpbmcgdG8gNnR1cyB0ZXJtaW5vbG9neSkuDQo+Pj4gPj4gV2hpbGUs
IHdoZW4gYSBkaXN0cmlidXRlZCBzb2x1dGlvbiBpcyB1c2VkLCA2dHVzIHdpbGwgYWxsb2NhdGUg
DQo+Pj4gPj4gdGhlDQo+Pj4gc29mdA0KPj4+ID4+IGNlbGxzLg0KPj4+ID4+DQo+Pj4gPj4gSW4g
dGhlIGNlbnRyYWxpemVkIHNjZW5hcmlvIHdpdGggdGhlIFBDRSwgdG8gYXZvaWQgdGhlIGV4Y2hh
bmdlIA0KPj4+ID4+IG9mDQo+Pj4gbWFueQ0KPj4+ID4+IHNpZ25hbGluZyBtZXNzYWdlcywgZm9y
IHNldHRpbmcgdXAgdGhlIHNjaGVkdWxlLCB3ZSBtYXkgdGhpbmsgKGFzDQo+Pj4gUGFzY2FsDQo+
Pj4gPj4gd2FzIHN1Z2dlc3RpbmcgZHVyaW5nIG9uZSBvZiB0aGUgbGFzdCBjYWxsKSB0byB1c2Ug
c29tZSBoeWJyaWQgDQo+Pj4gPj4gc29sdXRpb25zLg0KPj4+ID4+IEluIG90aGVyIHdvcmRzLCBp
ZiBQQ0UgYWxsb2NhdGVzICh0aW1lb2Zmc2V0MSwgY2hhbm5lbG9mZnNldDMsIA0KPj4+ID4+IHNs
b3RmcmFtZTEsDQo+Pj4gPj4gVFgpIHRvIG5vZGUgQSBmb3IgdHJhbnNtaXR0aW5nIHRvIG5vZGUg
QiwgdGhlbiwgbm9kZSBCIGNvdWxkIGtub3cgDQo+Pj4gPj4gbG9jYWxseSBmcm9tIG5vZGUgQSwg
KGFuZCBub3QgZnJvbSB0aGUgUENFKSwgdGhhdCB0aGUgY2VsbCANCj4+PiA+PiAodGltZW9mZnNl
dDEsIGNoYW5uZWxvZmZzZXQzLCBzbG90ZnJhbWUxLCBSWCkgaGFzIGJlZW4gcmVzZXJ2ZWQgDQo+
Pj4gPj4gdG8gaXQsIGZvcg0KPj4+IHJlY2VpdmluZw0KPj4+ID4+IGZyb20NCj4+PiA+PiBub2Rl
IEEuDQo+Pj4gPj4gV2UgbWF5IHRyeSB0byBpbmNsdWRlIHNvbWUgZnVuY3Rpb25hbGl0eSBpbiA2
dHVzIGxheWVyIGluIG9yZGVyIA0KPj4+ID4+IHRvIG1hbmFnZSBzdWNoIHNpdHVhdGlvbi4NCj4+
PiA+PiBXaGF0IGRvIHlvdSB0aGluaz8NCj4+PiA+Pg0KPj4+ID4+IE1hcmlhIFJpdGENCj4+PiA+
Pg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IC0NCj4+PiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gPj4gPiBPbiAzLzE0LzEzIDk6
MDIgUE0sIFBhdWwgQ2hpbHRvbiB3cm90ZToNCj4+PiA+PiA+Pj4tIG9wdGlvbmFsbHkgYSBQQ0Ug
c2l0cyBvbiB0aGUgYmFja2JvbmUgYW5kIGRyaXZlcyB0aGUgTExOcycNCj4+PiA+PiA+Pj5UU0NI
IHNjaGVkdWxlcy4NCj4+PiA+PiA+DQo+Pj4gPj4gPiBBaCwgbWF5YmUgdW5kZXJzdG9vZC4gIEl0
IGRvZXNuJ3Qgc2F5IHRoYXQgZXhpc3RlbmNlIG9mIFBDRSBpcw0KPj4+ID4+IG9wdGlvbmFsLg0K
Pj4+ID4+ID4gSXQgc2F5cyB0aGF0IGl0J3Mgb3B0aW9uYWwgdG8gcHV0IFBDRSBpbiB0aGUgYmFj
a2JvbmUuICBJdCANCj4+PiA+PiA+IGRvZXNuJ3QgcHJlY2x1ZGUgdG8gcHV0IGl0IG9uIEJCUi4g
IENvcnJlY3QgPw0KPj4+ID4+ID4NCj4+PiA+PiA+IFNob2ljaGkNCj4+PiA+PiA+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gPj4gPiA2dHNjaCBt
YWlsaW5nIGxpc3QNCj4+PiA+PiA+IDZ0c2NoQGlldGYub3JnDQo+Pj4gPj4gPiBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0c2NoDQo+Pj4gPj4gPg0KPj4+ID4+DQo+Pj4g
Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+
PiA2dHNjaCBtYWlsaW5nIGxpc3QNCj4+PiA+PiA2dHNjaEBpZXRmLm9yZw0KPj4+ID4+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRzY2gNCj4+PiA+PiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4+IDZ0c2NoIG1haWxp
bmcgbGlzdA0KPj4+ID4+IDZ0c2NoQGlldGYub3JnDQo+Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby82dHNjaA0KPj4+ID4+DQo+Pj4gPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4gNnRzY2ggbWFpbGluZyBsaXN0
DQo+Pj4gPiA2dHNjaEBpZXRmLm9yZw0KPj4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby82dHNjaA0KPj4+ID4NCj4+Pg0KPj4+DQo+Pj4NCj4+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA2dHNjaCBtYWlsaW5nIGxpc3QN
Cj4+IDZ0c2NoQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvLzZ0c2NoDQo+Pg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiA2dHNjaCBtYWlsaW5nIGxpc3QNCj4gNnRzY2hAaWV0Zi5vcmcNCj4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dHNjaA0KPg0KDQo=

From xvilajosana@eecs.berkeley.edu  Fri Mar 22 09:27:33 2013
Return-Path: 
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 3B5C721F8BA1 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 09:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ToNSvmI7q+FG for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 09:27:32 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id BDD2821F8A7E for <6tsch@ietf.org>; Fri, 22 Mar 2013 09:27:32 -0700 (PDT)
Received: from c-67-188-198-243.hsd1.ca.comcast.net ([67.188.198.243] helo=[192.168.2.4]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UJ4oQ-000757-CE for 6tsch@ietf.org; Fri, 22 Mar 2013 09:27:27 -0700
Message-ID: <514C866A.6070105@eecs.berkeley.edu>
Date: Fri, 22 Mar 2013 09:27:22 -0700
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [6tsch] workers use case
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 16:27:33 -0000

As regards to the workers case introduced today I want to point out that 
there is a potential impact on the energy consumption of the network 
depending on what solution is chosen.

+ if we relay on RPL to route packets from moving workers, this means 
that RPL control is fast enough so workers can position the worker in 
the routing topology, this means that DIO activity is fast incrementing 
the the energy consumption of the network.
+ if we relay on over-provisioned cells at each potential node that 
might be in contact with a worker, we suffer from idle-listening most of 
the times.

the key aspect is to find the crossing point between these 2 scenarios 
so the energy consumption is not compromised too much.

Another aspect to take into account is EBs periodicity as mobile nodes 
need to keep joining to new parents as they move. The period of EBs then 
is also compromised by mobility.

just two things to be considered.
regards,
Xavi

From xvilajosana@eecs.berkeley.edu  Fri Mar 22 09:29:20 2013
Return-Path: 
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 D266021F8E79 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 09:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level: 
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 eFnDwRd-Hewa for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 09:29:20 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6339F21F8BA1 for <6tsch@ietf.org>; Fri, 22 Mar 2013 09:29:20 -0700 (PDT)
Received: from c-67-188-198-243.hsd1.ca.comcast.net ([67.188.198.243] helo=[192.168.2.4]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UJ4pp-0007y1-Ed for 6tsch@ietf.org; Fri, 22 Mar 2013 09:28:55 -0700
Message-ID: <514C86C1.9000202@eecs.berkeley.edu>
Date: Fri, 22 Mar 2013 09:28:49 -0700
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 16:29:20 -0000

 From the discussion today I've detected the need to blacklist channels. 
Does 6tus need to provide a command to do that? Specially if 
blacklisting is dynamic, 6tus needs to reallocate softlinks from that 
channels that have been blacklisted.

regards,
X

From qinwang@berkeley.edu  Fri Mar 22 09:54:35 2013
Return-Path: 
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 A9F6E21F8DCF for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 09:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.486
X-Spam-Level: 
X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 vyVTo2rjeOdj for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 09:54:35 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 34B2021F8C7D for <6tsch@ietf.org>; Fri, 22 Mar 2013 09:54:35 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ5Eg-0003PJ-DQ; Fri, 22 Mar 2013 09:54:35 -0700
Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 09:54:34 -0700
Message-ID: <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu>
In-Reply-To: <514C86C1.9000202@eecs.berkeley.edu>
References: <514C86C1.9000202@eecs.berkeley.edu>
Date: Fri, 22 Mar 2013 09:54:34 -0700
From: "Qin Wang" 
To: "Xavier Vilajosana" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 16:54:35 -0000

Xavi and all,

When we talk about blacklist, the assumption is the blacklist is LLN wide,
or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100,
blacklist seems LLN wide.

Qin


>  From the discussion today I've detected the need to blacklist channels.
> Does 6tus need to provide a command to do that? Specially if
> blacklisting is dynamic, 6tus needs to reallocate softlinks from that
> channels that have been blacklisted.
>
> regards,
> X
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From twatteyne@gmail.com  Fri Mar 22 10:00:09 2013
Return-Path: 
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 3A1FE21F8E6B for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 ksIzg9i38WjF for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:00:08 -0700 (PDT)
Received: from mail-da0-x232.google.com (mail-da0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6856621F87D9 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:00:08 -0700 (PDT)
Received: by mail-da0-f50.google.com with SMTP id t1so856690dae.9 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:00:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=LHq8KvTXrzCLe0j7xzrTgvT/ERMpGKPqzVnT3UnOMGo=; b=aNFPtjiq8rR7BHUqs77iewcU94PBZVYxOFMsuXf9ssXd0u5P1uaMDe3rGSoe0dEqYz O8NV0bWPTDBWkV0N6FgGBeu+FL1NF3wqSI2g72FI4eDg30/ogAAlla9aecyrp0MlcDQa hpJ//8BiqADlWxGal0/mg64u7Mciue6GZOEHySV54TyhDGsJH6cgW15dYENdBYoqimfO m96GPxgweNeU5u5dw6W3AjjA7eoXHXB6LQ2195eIFAUYmIWts7StLH5Ekusi2HbQR6gp smCNngCe2waPYViTWr0Js1U0HIyI9xT4ITiExUvluTOVgoJqTcy80cVZSLxpT3MSpM+K BkOw==
X-Received: by 10.68.248.66 with SMTP id yk2mr3775600pbc.38.1363971608098; Fri, 22 Mar 2013 10:00:08 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Fri, 22 Mar 2013 09:59:47 -0700 (PDT)
In-Reply-To: <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu>
References: <514C86C1.9000202@eecs.berkeley.edu> <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu>
From: Thomas Watteyne 
Date: Fri, 22 Mar 2013 09:59:47 -0700
X-Google-Sender-Auth: sJy5stQHXP95dvisPhdMoSeQifE
Message-ID: 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b33919f2f3fcd04d8866347
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 17:00:09 -0000

--047d7b33919f2f3fcd04d8866347
Content-Type: text/plain; charset=ISO-8859-1

IEEE802.15.4e supports blacklisting of one of more frequencies for the
whole network, as per
http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7
.
We could add a command in 6tus to drive that, but I would keep the
blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide.
Thomas

On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang  wrote:

> Xavi and all,
>
> When we talk about blacklist, the assumption is the blacklist is LLN wide,
> or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100,
> blacklist seems LLN wide.
>
> Qin
>
>
> >  From the discussion today I've detected the need to blacklist channels.
> > Does 6tus need to provide a command to do that? Specially if
> > blacklisting is dynamic, 6tus needs to reallocate softlinks from that
> > channels that have been blacklisted.
> >
> > regards,
> > X
> > _______________________________________________
> > 6tsch mailing list
> > 6tsch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tsch
> >
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>  
>

--047d7b33919f2f3fcd04d8866347
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

IEEE802.15.4e supports blacklisting of one of more frequencies for the whol=
e network, as per=A0http://tools.ietf.org/html/draft-watt=
eyne-6tsch-tsch-lln-context-01#appendix-A.7.


We could add a command in 6tus to drive that, but I would keep the blacklis=
ting behavior of IEEE802.15.4e, i.e. LLN-wide.
Thomas
On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang <=
qinwang@berkeley.edu> wrote:




Xavi and all,



When we talk about blacklist, the assumption is the blacklist is LLN wide,<=
br>
or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100,
blacklist seems LLN wide.



Qin






> =A0From the discussion today I've detected the need to blacklist c=
hannels.

> Does 6tus need to provide a command to do that? Specially if

> blacklisting is dynamic, 6tus needs to reallocate softlinks from that<=
br>
> channels that have been blacklisted.

>

> regards,

> X

> _______________________________________________

> 6tsch mailing list

> 6tsch@ietf.org=


> https://www.ietf.org/mailman/listinfo/6tsch

>





_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch





--047d7b33919f2f3fcd04d8866347--

From maria-rita.palattella@uni.lu  Fri Mar 22 10:07:21 2013
Return-Path: 
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 B60BA21F858A for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.523
X-Spam-Level: 
X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 11dPLMY8EhUR for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:07:20 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id C9F6D21F85B0 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:07:19 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,893,1355094000"; d="scan'208,217";a="23077899"
Received: from unknown (HELO REED.uni.lux) ([10.21.2.9]) by hercules.uni.lu with ESMTP; 22 Mar 2013 18:07:19 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by REED.uni.lux ([fe80::31bb:b7a3:7abb:813e%10]) with mapi id 14.01.0438.000; Fri, 22 Mar 2013 18:07:18 +0100
From: Maria Rita PALATTELLA 
To: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] blacklisting support on 6tus
Thread-Index: AQHOJxpqQp7UqivFCkSTT1SuiNmYwZix3OMAgAABdYCAABIMCw==
Date: Fri, 22 Mar 2013 17:07:18 +0000
Message-ID: 
References: <514C86C1.9000202@eecs.berkeley.edu> <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu>, 
In-Reply-To: 
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.34.0.8]
Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185356FBhoshiunilux_"
MIME-Version: 1.0
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 17:07:21 -0000

--_000_F085911F642A6847987ADA23E611780D185356FBhoshiunilux_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Xavi, all,
6tus allocates soft/hard cells, that are function of the channelOffset.
The number of available channelOffset is equal to the number of available P=
HY channels.
The blacklist affects the PHY channel (i.e., frequency) that is actually us=
ed for the transmission.
Thus, in case of balcklisting, if the number of available channels (i.e., t=
he size of the blacklist doesn't change), then 6tus will not need to reallo=
cate the soft cells.
The channel offset will be translated in a different PHY channel, based on =
the list of available frequencies.
Only if the size of the blacklist changes, then, 6tus will need to realloca=
te soft cells.
In any case, 6tus may needs to provide a command for knowing abut the black=
list and thus, the set of available channels.
Does this make sense to you?
Maria Rita

________________________________
From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Thomas W=
atteyne [watteyne@eecs.berkeley.edu]
Sent: Friday, March 22, 2013 5:59 PM
To: 6tsch@ietf.org
Subject: Re: [6tsch] blacklisting support on 6tus

IEEE802.15.4e supports blacklisting of one of more frequencies for the whol=
e network, as per http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-=
context-01#appendix-A.7.
We could add a command in 6tus to drive that, but I would keep the blacklis=
ting behavior of IEEE802.15.4e, i.e. LLN-wide.
Thomas

On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang > wrote:
Xavi and all,

When we talk about blacklist, the assumption is the blacklist is LLN wide,
or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100,
blacklist seems LLN wide.

Qin


>  From the discussion today I've detected the need to blacklist channels.
> Does 6tus need to provide a command to do that? Specially if
> blacklisting is dynamic, 6tus needs to reallocate softlinks from that
> channels that have been blacklisted.
>
> regards,
> X
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


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


--_000_F085911F642A6847987ADA23E611780D185356FBhoshiunilux_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Xavi, all,


6tus allocates soft/hard cells, that are function of the channelOffset.

The number of available channelOffset is equal to the number of available P=
HY channels.

The blacklist affects the PHY channel (i.e., frequency) that is actually us=
ed for the transmission. 


Thus, in case of balcklisting, if the number of available channels (i.e., t=
he size of the blacklist doesn't change), then 6tus will not need to reallo=
cate the soft cells.

The channel offset will be translated in a different PHY channel, based on =
the list of available frequencies.

Only if the size of the blacklist changes, then, 6tus will need to realloca=
te soft cells.

In any case, 6tus may needs to provide a command for knowing abut the black=
list and thus, the set of available channels.

Does this make sense to you?

Maria Rita






From: 6tsch-bounces@ietf.org [6tsch-bounc=
es@ietf.org] on behalf of Thomas Watteyne [watteyne@eecs.berkeley.edu]

Sent: Friday, March 22, 2013 5:59 PM

To: 6tsch@ietf.org

Subject: Re: [6tsch] blacklisting support on 6tus








IEEE802.15.4e supports blacklisting of one of more frequencies for the=
 whole network, as per http://tool=
s.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7.

We could add a command in 6tus to drive that, but I would keep the bla=
cklisting behavior of IEEE802.15.4e, i.e. LLN-wide.


Thomas





On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang 
<qinwang@berke=
ley.edu> wrote:



Xavi and all,



When we talk about blacklist, the assumption is the blacklist is LLN wide,<=
br>
or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100,
blacklist seems LLN wide.



Qin









>  From the discussion today I've detected the need to blacklist ch=
annels.

> Does 6tus need to provide a command to do that? Specially if

> blacklisting is dynamic, 6tus needs to reallocate softlinks from that<=
br>
> channels that have been blacklisted.

>

> regards,

> X

> _______________________________________________

> 6tsch mailing list

> 6tsch@ietf.org=


> https://www.ietf.org/mailman/listinfo/6tsch

>





_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch

<=
/a>


















--_000_F085911F642A6847987ADA23E611780D185356FBhoshiunilux_--

From pthubert@cisco.com  Fri Mar 22 10:07:54 2013
Return-Path: 
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 D71E621F8B20 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.513
X-Spam-Level: 
X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 aa-irGT1RXB0 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:07:54 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4A35321F85B4 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:07:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=914; q=dns/txt; s=iport; t=1363972074; x=1365181674; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cUJPmBi+NjDRf7DMgAH/vjlWjfhdP/gTBsaKyA9JUPA=; b=jZawyByRWLggy61AlEhg5XXTgHRqv6HIkidU7V6dpa/8ypjqhetgDu1L exHPH2tslHnc3S/06VLehShqIA/0qK46uEoiId8MZ/jr7DoBXvr45yk4V 2vWvmK0TkoDzdbcVSIc9czi3l3XWEp58U1xEymNVokwoHRX4TE+V/TjfW Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoYFAE2PTFGtJV2c/2dsb2JhbABDDodYvW6BZRZ0giQBAQEEAQEBNzQXBAIBCA4DBAEBCxQJBycLFAkIAgQBEgiIDAzCJQSOYTgGgllhA6dogks/gig
X-IronPort-AV: E=Sophos;i="4.84,893,1355097600";  d="scan'208,223";a="187477756"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 22 Mar 2013 17:07:54 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2MH7rCd009663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 17:07:53 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 12:07:53 -0500
From: "Pascal Thubert (pthubert)" 
To: Xavier Vilajosana , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] blacklisting support on 6tus
Thread-Index: AQHOJxpyQp7UqivFCkSTT1SuiNmYwZix8GhA
Date: Fri, 22 Mar 2013 17:07:53 +0000
Deferred-Delivery: Fri, 22 Mar 2013 17:07:00 +0000
Message-ID: 
References: <514C86C1.9000202@eecs.berkeley.edu>
In-Reply-To: <514C86C1.9000202@eecs.berkeley.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.85.19]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 17:07:54 -0000

Hello Xavi.

There is an interface to the network management and blacklist and whitelist=
 are typical methods.
I'm unsure how deep we want to go in that sort of things in the 6TUS draft.
Certainly we cannot cover everything and we want to be extensible.

Cheers,=20

Pascal


-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of X=
avier Vilajosana
Sent: vendredi 22 mars 2013 17:29
To: 6tsch@ietf.org
Subject: [6tsch] blacklisting support on 6tus

 From the discussion today I've detected the need to blacklist channels.=20
Does 6tus need to provide a command to do that? Specially if blacklisting i=
s dynamic, 6tus needs to reallocate softlinks from that channels that have =
been blacklisted.

regards,
X
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch

From xvilajosana@eecs.berkeley.edu  Fri Mar 22 10:21:42 2013
Return-Path: 
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 C3F8121F8E58 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.399
X-Spam-Level: 
X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 VPzkhdURocx4 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:21:42 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA9621F8CF9 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:21:42 -0700 (PDT)
Received: from dhcp-33-135.eecs.berkeley.edu ([128.32.33.135]) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UJ5ev-0001hH-Jz; Fri, 22 Mar 2013 10:21:42 -0700
Message-ID: <514C9325.7070507@eecs.berkeley.edu>
Date: Fri, 22 Mar 2013 10:21:41 -0700
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" 
References: <514C86C1.9000202@eecs.berkeley.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 17:21:42 -0000

Hi all,

I agree, my only concern is that if 6tus layer provides commands to the 
management entity, blacklisting commands might be there for completeness.

regards,
Xavi
On 22/03/13 10:07, Pascal Thubert (pthubert) wrote:
> Hello Xavi.
>
> There is an interface to the network management and blacklist and whitelist are typical methods.
> I'm unsure how deep we want to go in that sort of things in the 6TUS draft.
> Certainly we cannot cover everything and we want to be extensible.
>
> Cheers,
>
> Pascal
>
>
> -----Original Message-----
> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana
> Sent: vendredi 22 mars 2013 17:29
> To: 6tsch@ietf.org
> Subject: [6tsch] blacklisting support on 6tus
>
>   From the discussion today I've detected the need to blacklist channels.
> Does 6tus need to provide a command to do that? Specially if blacklisting is dynamic, 6tus needs to reallocate softlinks from that channels that have been blacklisted.
>
> regards,
> X
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


From qinwang@berkeley.edu  Fri Mar 22 10:52:50 2013
Return-Path: 
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 3F7CD21F8444 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.493
X-Spam-Level: 
X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 76uAp0zgVb2M for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:52:49 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id C62D921F84B9 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:52:33 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ68k-0008Qt-C2; Fri, 22 Mar 2013 10:52:32 -0700
Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 10:52:30 -0700
Message-ID: 
In-Reply-To: <514C9325.7070507@eecs.berkeley.edu>
References: <514C86C1.9000202@eecs.berkeley.edu>  <514C9325.7070507@eecs.berkeley.edu>
Date: Fri, 22 Mar 2013 10:52:30 -0700
From: "Qin Wang" 
To: "Xavier Vilajosana" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "Pascal Thubert \(pthubert\)" , "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 17:52:50 -0000

Xavi and all,

If we agree that the blacklist is LLN wide, then the Channel Hopping IE
(defined by IEEE802.15.4e, instead of by 6tus) in EB will propagate the
validate physical channels. That means it is unnecessary for 6tus to
provide commands to set/get physical channels in blacklist.

Does it make sense?

Qin



> Hi all,
>
> I agree, my only concern is that if 6tus layer provides commands to the
> management entity, blacklisting commands might be there for completeness.
>
> regards,
> Xavi
> On 22/03/13 10:07, Pascal Thubert (pthubert) wrote:
>> Hello Xavi.
>>
>> There is an interface to the network management and blacklist and
>> whitelist are typical methods.
>> I'm unsure how deep we want to go in that sort of things in the 6TUS
>> draft.
>> Certainly we cannot cover everything and we want to be extensible.
>>
>> Cheers,
>>
>> Pascal
>>
>>
>> -----Original Message-----
>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf
>> Of Xavier Vilajosana
>> Sent: vendredi 22 mars 2013 17:29
>> To: 6tsch@ietf.org
>> Subject: [6tsch] blacklisting support on 6tus
>>
>>   From the discussion today I've detected the need to blacklist
>> channels.
>> Does 6tus need to provide a command to do that? Specially if
>> blacklisting is dynamic, 6tus needs to reallocate softlinks from that
>> channels that have been blacklisted.
>>
>> regards,
>> X
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>



From xvilajosana@eecs.berkeley.edu  Fri Mar 22 10:56:20 2013
Return-Path: 
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 2E80021F85A4 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 4XfKNaJ63Wom for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:56:19 -0700 (PDT)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id A2D9821F8444 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:56:19 -0700 (PDT)
Received: from dhcp-33-135.eecs.berkeley.edu ([128.32.33.135]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UJ6CQ-0003QK-7B; Fri, 22 Mar 2013 10:56:19 -0700
Message-ID: <514C9B41.9060403@eecs.berkeley.edu>
Date: Fri, 22 Mar 2013 10:56:17 -0700
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Qin Wang 
References: <514C86C1.9000202@eecs.berkeley.edu>  <514C9325.7070507@eecs.berkeley.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Pascal Thubert \(pthubert\)" , "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 17:56:20 -0000

so who tells to the mac layer what channels need to be blacklisted?

does the mac layer decide by itself?

X

On 22/03/13 10:52, Qin Wang wrote:
> Xavi and all,
>
> If we agree that the blacklist is LLN wide, then the Channel Hopping IE
> (defined by IEEE802.15.4e, instead of by 6tus) in EB will propagate the
> validate physical channels. That means it is unnecessary for 6tus to
> provide commands to set/get physical channels in blacklist.
>
> Does it make sense?
>
> Qin
>
>
>
>> Hi all,
>>
>> I agree, my only concern is that if 6tus layer provides commands to the
>> management entity, blacklisting commands might be there for completeness.
>>
>> regards,
>> Xavi
>> On 22/03/13 10:07, Pascal Thubert (pthubert) wrote:
>>> Hello Xavi.
>>>
>>> There is an interface to the network management and blacklist and
>>> whitelist are typical methods.
>>> I'm unsure how deep we want to go in that sort of things in the 6TUS
>>> draft.
>>> Certainly we cannot cover everything and we want to be extensible.
>>>
>>> Cheers,
>>>
>>> Pascal
>>>
>>>
>>> -----Original Message-----
>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf
>>> Of Xavier Vilajosana
>>> Sent: vendredi 22 mars 2013 17:29
>>> To: 6tsch@ietf.org
>>> Subject: [6tsch] blacklisting support on 6tus
>>>
>>>    From the discussion today I've detected the need to blacklist
>>> channels.
>>> Does 6tus need to provide a command to do that? Specially if
>>> blacklisting is dynamic, 6tus needs to reallocate softlinks from that
>>> channels that have been blacklisted.
>>>
>>> regards,
>>> X
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>


From qinwang@berkeley.edu  Fri Mar 22 11:11:30 2013
Return-Path: 
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 7577921F8FA3 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 11:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 IFxJswU0M848 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 11:11:29 -0700 (PDT)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id DF95821F8B45 for <6tsch@ietf.org>; Fri, 22 Mar 2013 11:11:29 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ6R6-0000Jy-Gj; Fri, 22 Mar 2013 11:11:29 -0700
Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 11:11:28 -0700
Message-ID: 
In-Reply-To: <514C9B41.9060403@eecs.berkeley.edu>
References: <514C86C1.9000202@eecs.berkeley.edu>  <514C9325.7070507@eecs.berkeley.edu>  <514C9B41.9060403@eecs.berkeley.edu>
Date: Fri, 22 Mar 2013 11:11:28 -0700
From: "Qin Wang" 
To: "Xavier Vilajosana" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "Pascal Thubert \(pthubert\)" , "6tsch@ietf.org" <6tsch@ietf.org>, Qin Wang 
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 18:11:30 -0000

At the beginning, the PIB of TSCH WPAN coordinator is configured,
including channel hopping attributes. Then, for a new joining node, after
it receives EB, the channel hopping IE should be given to MAC layer, i.e.
TSCH, and TSCH will be in charge to set its channel hopping related
attributes in PIB.

Make sense?

Qin



> so who tells to the mac layer what channels need to be blacklisted?
>
> does the mac layer decide by itself?
>
> X
>
> On 22/03/13 10:52, Qin Wang wrote:
>> Xavi and all,
>>
>> If we agree that the blacklist is LLN wide, then the Channel Hopping IE
>> (defined by IEEE802.15.4e, instead of by 6tus) in EB will propagate the
>> validate physical channels. That means it is unnecessary for 6tus to
>> provide commands to set/get physical channels in blacklist.
>>
>> Does it make sense?
>>
>> Qin
>>
>>
>>
>>> Hi all,
>>>
>>> I agree, my only concern is that if 6tus layer provides commands to the
>>> management entity, blacklisting commands might be there for
>>> completeness.
>>>
>>> regards,
>>> Xavi
>>> On 22/03/13 10:07, Pascal Thubert (pthubert) wrote:
>>>> Hello Xavi.
>>>>
>>>> There is an interface to the network management and blacklist and
>>>> whitelist are typical methods.
>>>> I'm unsure how deep we want to go in that sort of things in the 6TUS
>>>> draft.
>>>> Certainly we cannot cover everything and we want to be extensible.
>>>>
>>>> Cheers,
>>>>
>>>> Pascal
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf
>>>> Of Xavier Vilajosana
>>>> Sent: vendredi 22 mars 2013 17:29
>>>> To: 6tsch@ietf.org
>>>> Subject: [6tsch] blacklisting support on 6tus
>>>>
>>>>    From the discussion today I've detected the need to blacklist
>>>> channels.
>>>> Does 6tus need to provide a command to do that? Specially if
>>>> blacklisting is dynamic, 6tus needs to reallocate softlinks from that
>>>> channels that have been blacklisted.
>>>>
>>>> regards,
>>>> X
>>>> _______________________________________________
>>>> 6tsch mailing list
>>>> 6tsch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>
>>
>
>



From qinwang@berkeley.edu  Fri Mar 22 11:44:26 2013
Return-Path: 
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 04A9D21F8FD1 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 11:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.504
X-Spam-Level: 
X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 4d68nX1OrTfC for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 11:44:25 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 62D6F21F8F81 for <6tsch@ietf.org>; Fri, 22 Mar 2013 11:44:25 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ6ww-0005Rs-DG; Fri, 22 Mar 2013 11:44:23 -0700
Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 11:44:22 -0700
Message-ID: <42dbecb254249a1c138266265c0f501a.squirrel@calmail.berkeley.edu>
In-Reply-To: 
References: <514C86C1.9000202@eecs.berkeley.edu>  <514C9325.7070507@eecs.berkeley.edu>  <514C9B41.9060403@eecs.berkeley.edu> 
Date: Fri, 22 Mar 2013 11:44:22 -0700
From: "Qin Wang" 
To: "Qin Wang" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "6tsch@ietf.org" <6tsch@ietf.org>, "Pascal Thubert \(pthubert\)" , Qin Wang , Xavier Vilajosana 
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 18:44:26 -0000

+ More.

During a network running, TSCH WPAN coordinator can change its blacklist
according to the link quality report from nodes in the network. And,
still, the new blacklist and other information about channel hopping is
carried in channel hopping IE and propagated to the entire LLN.

Qin


>
> At the beginning, the PIB of TSCH WPAN coordinator is configured,
> including channel hopping attributes. Then, for a new joining node, after
> it receives EB, the channel hopping IE should be given to MAC layer, i.e.
> TSCH, and TSCH will be in charge to set its channel hopping related
> attributes in PIB.
>
> Make sense?
>
> Qin
>
>
>
>> so who tells to the mac layer what channels need to be blacklisted?
>>
>> does the mac layer decide by itself?
>>
>> X
>>
>> On 22/03/13 10:52, Qin Wang wrote:
>>> Xavi and all,
>>>
>>> If we agree that the blacklist is LLN wide, then the Channel Hopping IE
>>> (defined by IEEE802.15.4e, instead of by 6tus) in EB will propagate the
>>> validate physical channels. That means it is unnecessary for 6tus to
>>> provide commands to set/get physical channels in blacklist.
>>>
>>> Does it make sense?
>>>
>>> Qin
>>>
>>>
>>>
>>>> Hi all,
>>>>
>>>> I agree, my only concern is that if 6tus layer provides commands to
>>>> the
>>>> management entity, blacklisting commands might be there for
>>>> completeness.
>>>>
>>>> regards,
>>>> Xavi
>>>> On 22/03/13 10:07, Pascal Thubert (pthubert) wrote:
>>>>> Hello Xavi.
>>>>>
>>>>> There is an interface to the network management and blacklist and
>>>>> whitelist are typical methods.
>>>>> I'm unsure how deep we want to go in that sort of things in the 6TUS
>>>>> draft.
>>>>> Certainly we cannot cover everything and we want to be extensible.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Pascal
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On
>>>>> Behalf
>>>>> Of Xavier Vilajosana
>>>>> Sent: vendredi 22 mars 2013 17:29
>>>>> To: 6tsch@ietf.org
>>>>> Subject: [6tsch] blacklisting support on 6tus
>>>>>
>>>>>    From the discussion today I've detected the need to blacklist
>>>>> channels.
>>>>> Does 6tus need to provide a command to do that? Specially if
>>>>> blacklisting is dynamic, 6tus needs to reallocate softlinks from that
>>>>> channels that have been blacklisted.
>>>>>
>>>>> regards,
>>>>> X
>>>>> _______________________________________________
>>>>> 6tsch mailing list
>>>>> 6tsch@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>> _______________________________________________
>>>> 6tsch mailing list
>>>> 6tsch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>>
>>>
>>
>>
>
>
>



From qinwang@berkeley.edu  Fri Mar 22 12:33:42 2013
Return-Path: 
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 6AE4421F8F2D for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 12:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.509
X-Spam-Level: 
X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ZTyK5CK5vnu3 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 12:33:41 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id AC1CE21F8F29 for <6tsch@ietf.org>; Fri, 22 Mar 2013 12:33:41 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ7fl-0001Qt-AX; Fri, 22 Mar 2013 12:30:46 -0700
Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 12:30:41 -0700
Message-ID: <08f77e98659a73fe682f732f142688a9.squirrel@calmail.berkeley.edu>
In-Reply-To: 
References: <514C86C1.9000202@eecs.berkeley.edu> <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu>,  
Date: Fri, 22 Mar 2013 12:30:41 -0700
From: "Qin Wang" 
To: "Maria Rita PALATTELLA" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 19:33:42 -0000

Hi Maria Rita,

I guess you mean that PCE needs to know the set of channels. I agree with
it. However, I think PCE has same knowledge as TSCH coordinator. The
blacklist is formed by TSCH coordinator without effort of 6tus by
definition of IEEE802.15.4e, thus, PCE should know the set of channels
without 6tus help.

I'm not sure how PCE get information from TSCH coordinator. But I think
the information should not provided by 6tus.

Does it make sense?

Qin


> Xavi, all,
> 6tus allocates soft/hard cells, that are function of the channelOffset.
> The number of available channelOffset is equal to the number of available
> PHY channels.
> The blacklist affects the PHY channel (i.e., frequency) that is actually
> used for the transmission.
> Thus, in case of balcklisting, if the number of available channels (i.e.,
> the size of the blacklist doesn't change), then 6tus will not need to
> reallocate the soft cells.
> The channel offset will be translated in a different PHY channel, based on
> the list of available frequencies.
> Only if the size of the blacklist changes, then, 6tus will need to
> reallocate soft cells.
> In any case, 6tus may needs to provide a command for knowing abut the
> blacklist and thus, the set of available channels.
> Does this make sense to you?
> Maria Rita
>
> ________________________________
> From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Thomas
> Watteyne [watteyne@eecs.berkeley.edu]
> Sent: Friday, March 22, 2013 5:59 PM
> To: 6tsch@ietf.org
> Subject: Re: [6tsch] blacklisting support on 6tus
>
> IEEE802.15.4e supports blacklisting of one of more frequencies for the
> whole network, as per
> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7.
> We could add a command in 6tus to drive that, but I would keep the
> blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide.
> Thomas
>
> On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang
> > wrote:
> Xavi and all,
>
> When we talk about blacklist, the assumption is the blacklist is LLN wide,
> or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100,
> blacklist seems LLN wide.
>
> Qin
>
>
>>  From the discussion today I've detected the need to blacklist channels.
>> Does 6tus need to provide a command to do that? Specially if
>> blacklisting is dynamic, 6tus needs to reallocate softlinks from that
>> channels that have been blacklisted.
>>
>> regards,
>> X
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
> 
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


From qinwang@berkeley.edu  Fri Mar 22 12:34:38 2013
Return-Path: 
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 E949321F8FD3 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 12:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.509
X-Spam-Level: 
X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 vDZ5SHO1p8iu for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 12:34:38 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id C434921F8FA7 for <6tsch@ietf.org>; Fri, 22 Mar 2013 12:34:38 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ7g7-0001hs-CH; Fri, 22 Mar 2013 12:31:10 -0700
Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 12:31:03 -0700
Message-ID: 
In-Reply-To: 
References: <514C86C1.9000202@eecs.berkeley.edu> <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu>,  
Date: Fri, 22 Mar 2013 12:31:03 -0700
From: "Qin Wang" 
To: "Maria Rita PALATTELLA" 
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 19:34:39 -0000

Hi Maria Rita,

I guess you mean that PCE needs to know the set of channels. I agree with
it. However, I think PCE has same knowledge as TSCH coordinator. The
blacklist is formed by TSCH coordinator without effort of 6tus by
definition of IEEE802.15.4e, thus, PCE should know the set of channels
without 6tus help.

I'm not sure how PCE get information from TSCH coordinator. But I think
the information should not provided by 6tus.

Does it make sense?

Qin


> Xavi, all,
> 6tus allocates soft/hard cells, that are function of the channelOffset.
> The number of available channelOffset is equal to the number of available
> PHY channels.
> The blacklist affects the PHY channel (i.e., frequency) that is actually
> used for the transmission.
> Thus, in case of balcklisting, if the number of available channels (i.e.,
> the size of the blacklist doesn't change), then 6tus will not need to
> reallocate the soft cells.
> The channel offset will be translated in a different PHY channel, based on
> the list of available frequencies.
> Only if the size of the blacklist changes, then, 6tus will need to
> reallocate soft cells.
> In any case, 6tus may needs to provide a command for knowing abut the
> blacklist and thus, the set of available channels.
> Does this make sense to you?
> Maria Rita
>
> ________________________________
> From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Thomas
> Watteyne [watteyne@eecs.berkeley.edu]
> Sent: Friday, March 22, 2013 5:59 PM
> To: 6tsch@ietf.org
> Subject: Re: [6tsch] blacklisting support on 6tus
>
> IEEE802.15.4e supports blacklisting of one of more frequencies for the
> whole network, as per
> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7.
> We could add a command in 6tus to drive that, but I would keep the
> blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide.
> Thomas
>
> On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang
> > wrote:
> Xavi and all,
>
> When we talk about blacklist, the assumption is the blacklist is LLN wide,
> or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100,
> blacklist seems LLN wide.
>
> Qin
>
>
>>  From the discussion today I've detected the need to blacklist channels.
>> Does 6tus need to provide a command to do that? Specially if
>> blacklisting is dynamic, 6tus needs to reallocate softlinks from that
>> channels that have been blacklisted.
>>
>> regards,
>> X
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
> 
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


From maria-rita.palattella@uni.lu  Fri Mar 22 13:19:20 2013
Return-Path: 
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 8FF5F21F925B for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 13:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.539
X-Spam-Level: 
X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Gz34uFxJhIkM for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 13:19:19 -0700 (PDT)
Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4A36F21F90B3 for <6tsch@ietf.org>; Fri, 22 Mar 2013 13:19:19 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,893,1355094000"; d="scan'208";a="23079998"
Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 22 Mar 2013 21:19:18 +0100
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.01.0438.000; Fri, 22 Mar 2013 21:19:18 +0100
From: Maria Rita PALATTELLA 
To: Qin Wang 
Thread-Topic: [6tsch] blacklisting support on 6tus
Thread-Index: AQHOJxpqQp7UqivFCkSTT1SuiNmYwZix3OMAgAABdYCAABIMC4AAGDiAgAAbUSM=
Date: Fri, 22 Mar 2013 20:19:17 +0000
Message-ID: 
References: <514C86C1.9000202@eecs.berkeley.edu> <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu>,  , 
In-Reply-To: 
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.34.0.8]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 20:19:20 -0000

Hi Qin,=0A=
yes, this is what I meant. From my point of view, 6tus shoudn't have much t=
o do related to the blacklisting.=0A=
Once the TSCH coordinator has selected the set of channels to be used in th=
e TSCH-LLN,  the PCE should collect such information (-- how is something s=
till to be defined--).=0A=
Then, the PCE knows how many channels (and  channel offsets) are available =
for building the schedule (i.e., allocates the cells). =0A=
Maria Rita=0A=
________________________________________=0A=
From: Qin Wang [qinwang@berkeley.edu]=0A=
Sent: Friday, March 22, 2013 8:31 PM=0A=
To: Maria Rita PALATTELLA=0A=
Cc: Thomas Watteyne; 6tsch@ietf.org=0A=
Subject: Re: [6tsch] blacklisting support on 6tus=0A=
=0A=
Hi Maria Rita,=0A=
=0A=
I guess you mean that PCE needs to know the set of channels. I agree with=
=0A=
it. However, I think PCE has same knowledge as TSCH coordinator. The=0A=
blacklist is formed by TSCH coordinator without effort of 6tus by=0A=
definition of IEEE802.15.4e, thus, PCE should know the set of channels=0A=
without 6tus help.=0A=
=0A=
I'm not sure how PCE get information from TSCH coordinator. But I think=0A=
the information should not provided by 6tus.=0A=
=0A=
Does it make sense?=0A=
=0A=
Qin=0A=
=0A=
=0A=
> Xavi, all,=0A=
> 6tus allocates soft/hard cells, that are function of the channelOffset.=
=0A=
> The number of available channelOffset is equal to the number of available=
=0A=
> PHY channels.=0A=
> The blacklist affects the PHY channel (i.e., frequency) that is actually=
=0A=
> used for the transmission.=0A=
> Thus, in case of balcklisting, if the number of available channels (i.e.,=
=0A=
> the size of the blacklist doesn't change), then 6tus will not need to=0A=
> reallocate the soft cells.=0A=
> The channel offset will be translated in a different PHY channel, based o=
n=0A=
> the list of available frequencies.=0A=
> Only if the size of the blacklist changes, then, 6tus will need to=0A=
> reallocate soft cells.=0A=
> In any case, 6tus may needs to provide a command for knowing abut the=0A=
> blacklist and thus, the set of available channels.=0A=
> Does this make sense to you?=0A=
> Maria Rita=0A=
>=0A=
> ________________________________=0A=
> From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Thomas=
=0A=
> Watteyne [watteyne@eecs.berkeley.edu]=0A=
> Sent: Friday, March 22, 2013 5:59 PM=0A=
> To: 6tsch@ietf.org=0A=
> Subject: Re: [6tsch] blacklisting support on 6tus=0A=
>=0A=
> IEEE802.15.4e supports blacklisting of one of more frequencies for the=0A=
> whole network, as per=0A=
> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appen=
dix-A.7.=0A=
> We could add a command in 6tus to drive that, but I would keep the=0A=
> blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide.=0A=
> Thomas=0A=
>=0A=
> On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang=0A=
> > wrote:=0A=
> Xavi and all,=0A=
>=0A=
> When we talk about blacklist, the assumption is the blacklist is LLN wide=
,=0A=
> or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100,=
=0A=
> blacklist seems LLN wide.=0A=
>=0A=
> Qin=0A=
>=0A=
>=0A=
>>  From the discussion today I've detected the need to blacklist channels.=
=0A=
>> Does 6tus need to provide a command to do that? Specially if=0A=
>> blacklisting is dynamic, 6tus needs to reallocate softlinks from that=0A=
>> channels that have been blacklisted.=0A=
>>=0A=
>> regards,=0A=
>> X=0A=
>> _______________________________________________=0A=
>> 6tsch mailing list=0A=
>> 6tsch@ietf.org=0A=
>> https://www.ietf.org/mailman/listinfo/6tsch=0A=
>>=0A=
>=0A=
>=0A=
> _______________________________________________=0A=
> 6tsch mailing list=0A=
> 6tsch@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/6tsch=0A=
> =0A=
> _______________________________________________=0A=
> 6tsch mailing list=0A=
> 6tsch@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/6tsch=0A=
>=0A=
=0A=

From twatteyne@gmail.com  Fri Mar 22 23:32:32 2013
Return-Path: 
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 594A521F843E for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 23:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Level: 
X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 1i--tfjjSvX2 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 23:32:31 -0700 (PDT)
Received: from mail-da0-x22f.google.com (mail-da0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 685B421F843C for <6tsch@ietf.org>; Fri, 22 Mar 2013 23:32:31 -0700 (PDT)
Received: by mail-da0-f47.google.com with SMTP id s35so2523719dak.6 for <6tsch@ietf.org>; Fri, 22 Mar 2013 23:32:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=jbpEmWYFkdM+l2GOGWhVF2/tWwoWrbhpoGHv0/ex7FI=; b=gpRmv+SZp1uipDxZgXromkKTBa1FtYGkRUoLK9cZKT3BCenCCyW9pDCZQ0niAA1RRM 9yTpnegmX3mjeoHGAIHXf95lnDrOStZU7d5NXII5R360S3e5vzX9uJDA4Gm7ZQ0h1Bpl F6oTAawEkbPLuUKI5IB5M9eop/RvcvWcMAHwW0RYSQz98XnbZXcByAd7gGciViOXaNlG n+xGg4Q9jjBe6F2EQCZv4dwAJOO8ZYCuVfguowTPdWG9UEoye7bJJxsGwupmFKJ53we4 s+pI/vUbZpB+Gi8Y0CH9eFWURVQsxE8Ult/4sFNKoCMq2KDO/U5CrXq4KDiW9uReUfa7 lBKA==
X-Received: by 10.66.233.9 with SMTP id ts9mr2743521pac.15.1364020351143; Fri, 22 Mar 2013 23:32:31 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Fri, 22 Mar 2013 23:32:11 -0700 (PDT)
In-Reply-To: 
References: <514C86C1.9000202@eecs.berkeley.edu> <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu>    
From: Thomas Watteyne 
Date: Fri, 22 Mar 2013 23:32:11 -0700
X-Google-Sender-Auth: -iO70NJ1R9sYj1depKV3Ux6xFLA
Message-ID: 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b111c537f173304d891bcc8
Subject: Re: [6tsch] blacklisting support on 6tus
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2013 06:32:32 -0000

--047d7b111c537f173304d891bcc8
Content-Type: text/plain; charset=ISO-8859-1

+1

I agree that 6tus should not have to care about channel blacklist. Thanks
for clarifying that.

On Fri, Mar 22, 2013 at 1:19 PM, Maria Rita PALATTELLA <
maria-rita.palattella@uni.lu> wrote:

> Hi Qin,
> yes, this is what I meant. From my point of view, 6tus shoudn't have much
> to do related to the blacklisting.
> Once the TSCH coordinator has selected the set of channels to be used in
> the TSCH-LLN,  the PCE should collect such information (-- how is something
> still to be defined--).
> Then, the PCE knows how many channels (and  channel offsets) are available
> for building the schedule (i.e., allocates the cells).
> Maria Rita
> ________________________________________
> From: Qin Wang [qinwang@berkeley.edu]
> Sent: Friday, March 22, 2013 8:31 PM
> To: Maria Rita PALATTELLA
> Cc: Thomas Watteyne; 6tsch@ietf.org
> Subject: Re: [6tsch] blacklisting support on 6tus
>
> Hi Maria Rita,
>
> I guess you mean that PCE needs to know the set of channels. I agree with
> it. However, I think PCE has same knowledge as TSCH coordinator. The
> blacklist is formed by TSCH coordinator without effort of 6tus by
> definition of IEEE802.15.4e, thus, PCE should know the set of channels
> without 6tus help.
>
> I'm not sure how PCE get information from TSCH coordinator. But I think
> the information should not provided by 6tus.
>
> Does it make sense?
>
> Qin
>
>
> > Xavi, all,
> > 6tus allocates soft/hard cells, that are function of the channelOffset.
> > The number of available channelOffset is equal to the number of available
> > PHY channels.
> > The blacklist affects the PHY channel (i.e., frequency) that is actually
> > used for the transmission.
> > Thus, in case of balcklisting, if the number of available channels (i.e.,
> > the size of the blacklist doesn't change), then 6tus will not need to
> > reallocate the soft cells.
> > The channel offset will be translated in a different PHY channel, based
> on
> > the list of available frequencies.
> > Only if the size of the blacklist changes, then, 6tus will need to
> > reallocate soft cells.
> > In any case, 6tus may needs to provide a command for knowing abut the
> > blacklist and thus, the set of available channels.
> > Does this make sense to you?
> > Maria Rita
> >
> > ________________________________
> > From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of
> Thomas
> > Watteyne [watteyne@eecs.berkeley.edu]
> > Sent: Friday, March 22, 2013 5:59 PM
> > To: 6tsch@ietf.org
> > Subject: Re: [6tsch] blacklisting support on 6tus
> >
> > IEEE802.15.4e supports blacklisting of one of more frequencies for the
> > whole network, as per
> >
> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7
> .
> > We could add a command in 6tus to drive that, but I would keep the
> > blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide.
> > Thomas
> >
> > On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang
> > > wrote:
> > Xavi and all,
> >
> > When we talk about blacklist, the assumption is the blacklist is LLN
> wide,
> > or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100,
> > blacklist seems LLN wide.
> >
> > Qin
> >
> >
> >>  From the discussion today I've detected the need to blacklist channels.
> >> Does 6tus need to provide a command to do that? Specially if
> >> blacklisting is dynamic, 6tus needs to reallocate softlinks from that
> >> channels that have been blacklisted.
> >>
> >> regards,
> >> X
> >> _______________________________________________
> >> 6tsch mailing list
> >> 6tsch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/6tsch
> >>
> >
> >
> > _______________________________________________
> > 6tsch mailing list
> > 6tsch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tsch
> > 
> > _______________________________________________
> > 6tsch mailing list
> > 6tsch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tsch
> >
>
>

--047d7b111c537f173304d891bcc8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1

I agree that 6tus should not have to care about chann=
el blacklist. Thanks for clarifying that.

On Fri, Mar 22, 2013 at 1:19 PM, Maria Rita PALATTELLA &=
lt;maria-=
rita.palattella@uni.lu> wrote:



Hi Qin,

yes, this is what I meant. From my point of view, 6tus shoudn't have mu=
ch to do related to the blacklisting.

Once the TSCH coordinator has selected the set of channels to be used in th=
e TSCH-LLN, =A0the PCE should collect such information (-- how is something=
 still to be defined--).

Then, the PCE knows how many channels (and =A0channel offsets) are availabl=
e for building the schedule (i.e., allocates the cells).

Maria Rita

________________________________________

From: Qin Wang [qinwang@berkeley.ed=
u]

Sent: Friday, March 22, 2013 8:31 PM

To: Maria Rita PALATTELLA

Cc: Thomas Watteyne; 6tsch@ietf.org

Subject: Re: [6tsch] blacklisting s=
upport on 6tus



Hi Maria Rita,



I guess you mean that PCE needs to know the set of channels. I agree with
it. However, I think PCE has same knowledge as TSCH coordinator. The

blacklist is formed by TSCH coordinator without effort of 6tus by

definition of IEEE802.15.4e, thus, PCE should know the set of channels

without 6tus help.



I'm not sure how PCE get information from TSCH coordinator. But I think=


the information should not provided by 6tus.



Does it make sense?



Qin





> Xavi, all,

> 6tus allocates soft/hard cells, that are function of the channelOffset=
.

> The number of available channelOffset is equal to the number of availa=
ble

> PHY channels.

> The blacklist affects the PHY channel (i.e., frequency) that is actual=
ly

> used for the transmission.

> Thus, in case of balcklisting, if the number of available channels (i.=
e.,

> the size of the blacklist doesn't change), then 6tus will not need=
 to

> reallocate the soft cells.

> The channel offset will be translated in a different PHY channel, base=
d on

> the list of available frequencies.

> Only if the size of the blacklist changes, then, 6tus will need to

> reallocate soft cells.

> In any case, 6tus may needs to provide a command for knowing abut the<=
br>
> blacklist and thus, the set of available channels.

> Does this make sense to you?

> Maria Rita

>

> ________________________________

> From: 6tsch-bounces@ietf.org=
 [6tsch-bounces@ietf.org]=
 on behalf of Thomas

> Watteyne [watteyne@eecs.=
berkeley.edu]

> Sent: Friday, March 22, 2013 5:59 PM

> To: 6tsch@ietf.org

> Subject: Re: [6tsch] blacklisting support on 6tus

>

> IEEE802.15.4e supports blacklisting of one of more frequencies for the=


> whole network, as per

> http://tools.ietf.org/html/draft-w=
atteyne-6tsch-tsch-lln-context-01#appendix-A.7.

> We could add a command in 6tus to drive that, but I would keep the

> blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide.

> Thomas

>

> On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang

> <qinwang@berkeley.edu&l=
t;mailto:qinwang@berkeley.edu&g=
t;> wrote:

> Xavi and all,

>

> When we talk about blacklist, the assumption is the blacklist is LLN w=
ide,

> or inside of a subnet, or just pair of nodes? In WirelessHart and ISA1=
00,

> blacklist seems LLN wide.

>

> Qin

>

>

>> =A0From the discussion today I've detected the need to blackli=
st channels.

>> Does 6tus need to provide a command to do that? Specially if

>> blacklisting is dynamic, 6tus needs to reallocate softlinks from t=
hat

>> channels that have been blacklisted.

>>

>> regards,

>> X

>> _______________________________________________

>> 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

> <https://www.ietf.org/mailman/listinfo/6tsch>

> _______________________________________________

> 6tsch mailing list

> 6tsch@ietf.org

> https://www.ietf.org/mailman/listinfo/6tsch

>







--047d7b111c537f173304d891bcc8--

From twatteyne@gmail.com  Sat Mar 23 00:53:28 2013
Return-Path: 
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 DD38921F88C1 for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 00:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=0.355,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 HNc6ehJ6Ds6X for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 00:53:27 -0700 (PDT)
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id D27EE21F88BC for <6tsch@ietf.org>; Sat, 23 Mar 2013 00:53:26 -0700 (PDT)
Received: by mail-pa0-f43.google.com with SMTP id rl6so277467pac.30 for <6tsch@ietf.org>; Sat, 23 Mar 2013 00:53:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=aqpmWmI16mgWFhebf3EHOMthLnOG7wyRUafcrpOY7Zg=; b=Y9dlZPTXZi+RlOYsJ+/s6iks7hYyio4nKWPdo8F7uTpyytrOdQbjL8xUR+7IpFh6LA r9t4q/fIte2RFFAWKWma19LhnfShpPbIF9kto5csCOjo3uPJwwUI8bX6x3zmFVev8nnT a0zoRkxLCzCM7xu34zy+1Hy7HQbUfbpVMHrlbbVwg8BZAcbBqYRx/jbe8pxCc7KBoMac 72Yek0pbBCBdyz7xbE5Bf/CIa2oLBYGu7TcdUIAIHVP6elScz5fdr/GK3FAd/72GMmaH IaaBpfW6pxL8iBVA72ejQ5H5sh4QZHhzxzTFxliDDVBMhaN1NNSGBkgwZJ2exe/Qtfmj 10RA==
X-Received: by 10.66.233.9 with SMTP id ts9mr2962379pac.15.1364025206579; Sat, 23 Mar 2013 00:53:26 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.68.227.71 with HTTP; Sat, 23 Mar 2013 00:53:06 -0700 (PDT)
From: Thomas Watteyne 
Date: Sat, 23 Mar 2013 00:53:06 -0700
X-Google-Sender-Auth: zbgyoCFTk366NO_6MnYYkwIbob0
Message-ID: 
To: IETF 6TSCH <6tsch@ietf.org>
Content-Type: multipart/mixed; boundary=047d7b111c53e7265904d892dd1e
Subject: [6tsch] minutes WebEx 22 March 2013
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2013 07:53:29 -0000

--047d7b111c53e7265904d892dd1e
Content-Type: multipart/alternative; boundary=047d7b111c53e7265504d892dd1c

--047d7b111c53e7265504d892dd1c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

All,

Please find the minutes of today's meeting below. Attached are the slides
presented.

*Note: I understand that some of us have missed the call today because of
the switch to summer time in the PST area. Apologies for not sending a
clear reminder yesterday, will do next week. As an early reminder: it will
be the same next week (3/29), i.e. call will be at 4pm CET. The week after
that (4/5), we will be back to normal (5pm CET), since the CET region will
have switched to summer time.*

Thomas

---

*** Timestamps in PDT ***

Present:
- Bogdan Pavkovic
- Maria Rita Palattella
- Pascal Thubert
- Qin Wang
- Raghuram Sudhaakar
- Thomas Watteyne
- Tina Tsou
- Tom Phinney
- Xavi Vilajosana

Webex recording (audio+slides,streaming):
-
https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D66940742&r=
Key=3D711b58d40cd574d9[54min]

Attached slides:
- 6tsch_use_cases_call03222013.pptx: slides shared during the call and
edited live by Pascal

Agenda:
- Summary overview Orlando meeting [10min]
    . overview two meetings
    . 4 drafts presented
    . TODOs:
        . 6tus draft, add ability for a PCE to set hard cells on one side
only (text already changed)
        . typos
        . match terminology draft
- Charter use cases [40min]
    . review the following list
        . Wireless Process Control (main source for us)
           . control loops (requires a global optimization of routes for
jitter and latency =96 thus computed by a PCE -, flow (over) provisioning,
duocast, with static multipath hard slot allocation.
           . control loop plan B (requires self-healing -thus distributed-
routing,)
           . supervisory flows (requires determinism up to the backbone
           . management (requires a separate topology =96 a RPL instance -
that does not break)
           . alerts (bursty, unexpected, dynamic slot allocation,
prioritization)
           . monitoring of lots of lesser importance stuff like corrosion
(requires low cost scalability =96 this distributed routing )
           . cranes that are mobile within a range (requires dynamicity on
the last hop(s) whre the mobility happens and may be deterministic up to
that point)
           . large plants (requires thousands of devices=96 thus a backbone=
 =96
within a subnet =96 to avoid renumbering)
           . non-production episodes (requires fast and autonomic behavior
=96 again distributed routing)
           . coexistence with legacy devices (requires a common management
above)
        - Smart cities/infrastructures
            .(road,street) traffic control (requires increase of bw as more
traffic in the road)
            .smart urban parking (requires redundancy of routes an
over-provision as RF degrades with cars on top of the sensors)
            . green zones. Monitor moisture in gardens, trigger watering.
            . city lights monitoring. Requires marge scale meshes
        - building automation.
           . requires redundancy as RF degrades when there are changes on
the environment, doors, moving metallic apparel, etc..)
           . can be long distance this many hops. Can use lower frequencies
to gain range.
        - vehicular automation.
           . We can save copper for most of the man to machine interfaces,
which translates in both lower price and lower gas consumption.
        - commercial automation.
          .  asset tracking operations on the move (again mobility, and
dynamics).
          .  monitoring e.g. temperature of freezers, intrusion sensors,
    . validate the list of derived problems to be solved
    . focus on what TSCH is good at: reliability, low-power consumption,
traffic engineering
- Open technical discussions [time permitting]
    . synchronization between BBRs
        . summarize and discuss proposal
    . slotframes, cells and priorities
        . summarize and discuss proposal
    . interaction between RPL and PCE
        . summarize current state of the discussion

Minutes:
- [08.05] Meeting starts
- [08.05] Overview IETF 86 Orlando
    . 2 6TSCH information meetings
        . Tuesday: administrative and general information.
            . Adoption of draft-ietf-roll-rpl-industrial-applicability-00
as starting point for 6TSCH requirements
            . Many non-6TSCH people discovered the group.
            . Positive feedback.
        . Wednesday: technical discussion,
            . 4 6TSCH drafts presented
            . 2 non-6TSCH drafts presented
    . all information, including full minutes and slides are at
https://bitbucket.org/6tsch/ietf86-orlando/
- [08.15] Discussion on charter use cases
    . Pascal shares slides from [6tsch_use_cases_call03222013.pptx]
    . Goal: discuss the different use cases scenarios
    <<< Below is only a list of the points discussed. Refer to the attached
slides for contents. >>>
    . Duocast
        . [Tom] duocast applies only to single hop.
        . [Pascal] Edits slide.
    . Supervisory flows
        . [Pascal] Do we want the flow to be deterministic to a supervisor
which sits in the backbone? This implies matching the LLN schedule to some
backbone link-layer schedule?
        . [Tom] BB has orders of magnitude more bandwidth than LLN. Will
never be constrained. We don't need to have determinism in the BB.
        . [Thomas] We could consider this isssue out-of-scope for 6TSCH.
        . [Pascal] Edits slide.
    . Management topology
        . [Pascal] do we want to separate the management traffic from data
traffic to ensure availability?
        . [All] Agreed/
        . [Pascal] Adds open issues: OF and root selection to slide.
    . Alerts
        . [Pascal] Proposal: allow for burst of traffic to generate some
on-demand ("on-the-fly") distributed reservation?
        . [Thomas] Potentially complicates things. Why not consider a burty
traffic as a problem for the scheduling entity to taken care of.
        . [Pascal] Edits slide.
    . Support for lesser important "background" traffic.
        . [Pascal] Allow for traffic to flow along RPL routes, using soft
cell allocation, possibly alongside PCE-allocated hard cells.
        . [Thomas] Agreed since probably relatively easy to do (hard cell
have priority over soft cells, if hard cell is installed at same
timeslot/channeloffset as soft cell, soft cell needs to move). Yet, this
might bring complexity, so let's separate PCE/distributed approaches.
    . Mobility
        . [Pascal] Presents idea from Alfredo, whereby data from a mobile
crane would travel over a RPL "half-track" before reaching PCE "half-track"=
.
        . [Thomas] Not is favor of mixing distributed and centralized
routing in a track.
        . [Thomas,Tom] What we understood from Alfredo's proposal was to
have same cells scheduled at several potential neighbors of the node
mounted on the crane.
        . [Tom] Agreed.
        . [Pascal] Agreed.
        . [Pascal] Marks issue as "no goal".
        . [Tom] Mobility case makes sense, e.g. for large container cranes
traveling along a track. Two cranes can pick up each side of a large
object. One can imagine automated communication (now human operators with
radio).
        . [Tom] Second example is pivoting crane.
        . [Pascal] Splits mobile case if "crane" and "mobile" worker.
        . [Tom] Mobile worker does not require deterministic schedules.
    . Large plants
        . [Pascal] Concept of multiple BBRs interconnected by BB to allow
nodes from different LLNs to be in same IPv6 prefix. Useful?
        . [Raghuram] In some cases, we want to know exactly where a node
is, having the same prefix might remove that information.
        . [Thomas] System can be built so that a network operator can know
to which BBR a node is attached, yet all nodes still in same prefix.
        . [Pascal] Edits slide to indicate same prefix not always needed,
isolation somtimes wanted.
        . [Thomas] Wants to stress that we also want to support a case
where one big LLN with multiple BBRs.
        . [Pascal] Agreed, text encompasses this case.
    . Non-production phases
        . [Pascal] RPL can be needed as backup or for recovery.
        . [Thomas] Very well explained in
draft-ietf-roll-rpl-industrial-applicability-00. Agreed.
    . Coexistence
        . [Pascal] Do we need a common management entity which could know
about the different schedules of different LLNs (possible covering
IEEE802.15.4e TSCH, WHART and ISA1000) to facilitate coexistence?
        . [Thomas] Such fine-grained (at cell level) coexistance management
not needed. Several network in same radio space work fine. Coarse-grained
can be easily implemented. E.g. blacklisting some frequency on which a
single-channel network runs, and which does not support a different network=
.
    <<< Time's up, we don't go through additional slides >>>
- [09.00] What's next?
    . for the coming week:
        . finalize the list of use cases, with slideset as a base, on the M=
L
        . start working on extra items (per Marc Blanchet's suggestion):
            . what needs to be done in IETF
            . milestones and deliverables.
    . at next meeting: finalize discussion on use cases, and move on to two
points above.
- [09.05] Meeting ends

--047d7b111c53e7265504d892dd1c
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

All,

Please find the minutes of today's meeting belo=
w. Attached are the slides presented.

Note: I u=
nderstand that some of us have missed the call today because of the switch =
to summer time in the PST area.=A0Apologies=A0for not sending a clear remin=
der yesterday, will do next week. As an early reminder: it will be the same=
 next week (3/29), i.e. call will be at 4pm CET. The week after that (4/5),=
 we will be back to normal (5pm CET), since the CET region will have switch=
ed to summer time.




Thomas

---

*** Timestamps in PDT ***<=
/font>



Present:
- Bogdan Pavkovic
- Maria Rita Palattella
- Pascal Thubert



- Qin Wang
- Raghuram Sudhaakar
- Thomas Watteyne
- Tina Tsou



- Tom Phinney
<=
font face=3D"courier new, monospace">- Xavi Vilajosana

Webex recording (audio+slides,streaming):



- https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=
=3DMC&rID=3D66940742&rKey=3D711b58d40cd574d9 [54min]



Attached slides:
- 6tsch_use_cases_call03222013.pptx: slides shared=
 during the call and edited live by Pascal




Agenda:
- Summary overview Orlando meeting [10min]

=A0 =A0 . overview two meetings


=A0 =A0 . 4 drafts presented
=A0 =A0 . TODOs:=

=A0 =A0 =A0 =A0 . 6tus dra=
ft, add ability for a PCE to set hard cells on one side only (text already =
changed)



=A0 =A0 =A0 =A0 . typos
=A0 =A0 =A0 =A0 . match term=
inology draft
- Char=
ter use cases [40min]



=A0 =A0 . review the following l=
ist
=A0 =A0 =A0 =A0 =
. Wireless Process Control (main source for us)
=A0 =A0 =A0 =A0 =A0 =A0. control loops (require=
s a global optimization of routes for jitter and latency =96 thus computed =
by a PCE -, flow (over) provisioning, duocast, with static multipath hard s=
lot allocation.



=A0 =A0 =A0 =A0 =A0 =A0. control=
 loop plan B (requires self-healing -thus distributed- routing,)
=A0 =A0 =A0 =A0 =A0 =A0. super=
visory flows (requires determinism up to the backbone



=A0 =A0 =A0 =A0 =A0 =A0. managem=
ent (requires a separate topology =96 a RPL instance - that does not break)=

=A0 =A0 =A0 =A0 =A0=
 =A0. alerts (bursty, unexpected, dynamic slot allocation, prioritization)<=
/font>



=A0 =A0 =A0 =A0 =A0 =A0. monitor=
ing of lots of lesser importance stuff like corrosion (requires low cost sc=
alability =96 this distributed routing )
=A0 =A0 =A0 =A0 =A0 =A0. cranes that are mobile within=
 a range (requires dynamicity on the last hop(s) whre the mobility happens =
and may be deterministic up to that point)



=A0 =A0 =A0 =A0 =A0 =A0. large p=
lants (requires thousands of devices=96 thus a backbone =96 within a subnet=
 =96 to avoid renumbering)
=A0 =A0 =A0 =A0 =A0 =A0. non-production episodes (requires fast and =
autonomic behavior =96 again distributed routing)



=A0 =A0 =A0 =A0 =A0 =A0. coexist=
ence with legacy devices (requires a common management above)
<=
div>=A0 =A0 =A0 =A0 - Smart cities/in=
frastructures=A0



=A0 =A0 =A0 =A0 =A0 =A0 .(road,s=
treet) traffic control (requires increase of bw as more traffic in the road=
)
=A0 =A0 =A0 =A0 =
=A0 =A0 .smart urban parking (requires redundancy of routes an over-provisi=
on as RF degrades with cars on top of the sensors) =A0=A0



=A0 =A0 =A0 =A0 =A0 =A0 . green =
zones. Monitor moisture in gardens, trigger watering.
=A0 =A0 =A0 =A0 =A0 =A0 . city lights mon=
itoring. Requires marge scale meshes



=A0 =A0 =A0 =A0 - building autom=
ation.
=A0 =A0 =A0 =
=A0 =A0 =A0. requires redundancy as RF degrades when there are changes on t=
he environment, doors, moving metallic apparel, etc..)



=A0 =A0 =A0 =A0 =A0 =A0. can be =
long distance this many hops. Can use lower frequencies to gain range.
=A0 =A0 =A0 =A0 - vehicu=
lar automation.



=A0 =A0 =A0 =A0 =A0 =A0. We can =
save copper for most of the man to machine interfaces, which translates in =
both lower price and lower gas consumption.
=A0 =A0 =A0 =A0 - commercial automation.


=A0 =A0 =A0 =A0 =A0 . =A0asset t=
racking operations on the move (again mobility, and dynamics).
=

=A0 =A0 =A0 =A0 =A0 . =A0monitor=
ing e.g. temperature of freezers, intrusion sensors,



=A0 =A0 . validate the list of d=
erived problems to be solved
=A0 =A0 . focus on what TSCH is good at: reliability, low-power co=
nsumption, traffic engineering



- Open technical discussions [ti=
me permitting]
=A0 =
=A0 . synchronization between BBRs
=A0 =A0 =A0 =A0 . summarize and discuss proposal


=A0 =A0 . slotframes, cells and =
priorities
=A0 =A0 =
=A0 =A0 . summarize and discuss proposal
=A0 =A0 . interaction between RPL and PCE



=A0 =A0 =A0 =A0 . summarize curr=
ent state of the discussion

Minutes=
:



- [08.05] Meeting starts<=
/div>
- [08.05] Overview IETF 86 =
Orlando
=A0 =A0 . 2 =
6TSCH information meetings



=A0 =A0 =A0 =A0 . Tuesday: admin=
istrative and general information.
=A0 =A0 =A0 =A0 =A0 =A0 . Adoption of draft-ietf-roll-rpl-in=
dustrial-applicability-00 as starting point for 6TSCH requirements


=A0 =A0 =A0 =A0 =A0 =A0 . Many n=
on-6TSCH people discovered the group.
=A0 =A0 =A0 =A0 =A0 =A0 . Positive feedback.
=

=A0 =A0 =A0 =A0 . Wednesday: tec=
hnical discussion,



=A0 =A0 =A0 =A0 =A0 =A0 . 4 6TSC=
H drafts presented
=
=A0 =A0 =A0 =A0 =A0 =A0 . 2 non-6TSCH drafts presented
=A0 =A0 . all information, including ful=
l minutes and slides are at https://bitbucket.org/6tsch/ietf86-orlando/



- [08.15] Discussion on charter =
use cases
=A0 =A0 . =
Pascal shares slides from [6tsch_use_cases_call03222013.pptx]
<=
div>

=A0 =A0 . Goal: discuss the different=
 use cases scenarios
=A0 =A0 <<< Below is only a list of the points discussed. Refer t=
o the attached slides for contents. >>>



=A0 =A0 . Duocast
=A0 =A0 =A0 =A0 . [Tom] duocast ap=
plies only to single hop.
=A0 =A0 =A0 =A0 . [Pascal] Edits slide.



=A0 =A0 . Supervisory flows
=A0 =A0 =A0 =A0 . [Pasca=
l] Do we want the flow to be deterministic to a supervisor which sits in th=
e backbone? This implies matching the LLN schedule to some backbone link-la=
yer schedule?



=A0 =A0 =A0 =A0 . [Tom] BB has o=
rders of magnitude more bandwidth than LLN. Will never be constrained. We d=
on't need to have determinism in the BB.
=A0 =A0 =A0 =A0 . [Thomas] We could consider this =
isssue out-of-scope for 6TSCH.



=A0 =A0 =A0 =A0 . [Pascal] Edits=
 slide.
=A0 =A0 . Ma=
nagement topology
=
=A0 =A0 =A0 =A0 . [Pascal] do we want to separate the management traffic fr=
om data traffic to ensure availability?



=A0 =A0 =A0 =A0 . [All] Agreed/<=
/font>
=A0 =A0 =A0 =A0 . [P=
ascal] Adds open issues: OF and root selection to slide.
<=
font face=3D"courier new, monospace">=A0 =A0 . Alerts



=A0 =A0 =A0 =A0 . [Pascal] Propo=
sal: allow for burst of traffic to generate some on-demand ("on-the-fl=
y") distributed reservation?
=A0 =A0 =A0 =A0 . [Thomas] Potentially complicates things. Wh=
y not consider a burty traffic as a problem for the scheduling entity to ta=
ken care of.



=A0 =A0 =A0 =A0 . [Pascal] Edits=
 slide.
=A0 =A0 . Su=
pport for lesser important "background" traffic.
=A0 =A0 =A0 =A0 . [Pascal] Allow for=
 traffic to flow along RPL routes, using soft cell allocation, possibly alo=
ngside PCE-allocated hard cells.



=A0 =A0 =A0 =A0 . [Thomas] Agree=
d since probably relatively easy to do (hard cell have priority over soft c=
ells, if hard cell is installed at same timeslot/channeloffset as soft cell=
, soft cell needs to move). Yet, this might bring complexity, so let's =
separate PCE/distributed approaches.



=A0 =A0 . Mobility
<=
div>=A0 =A0 =A0 =A0 . [Pascal] Presen=
ts idea from Alfredo, whereby data from a mobile crane would travel over a =
RPL "half-track" before reaching PCE "half-track".



=A0 =A0 =A0 =A0 . [Thomas] Not i=
s favor of mixing distributed and centralized routing in a track.
=A0 =A0 =A0 =A0 . [Thomas,Tom=
] What we understood from Alfredo's proposal was to have same cells sch=
eduled at several potential neighbors of the node mounted on the crane.



=A0 =A0 =A0 =A0 . [Tom] Agreed.<=
/font>
=A0 =A0 =A0 =A0 . [P=
ascal] Agreed.
=A0 =
=A0 =A0 =A0 . [Pascal] Marks issue as "no goal".



=A0 =A0 =A0 =A0 . [Tom] Mobility=
 case makes sense, e.g. for large container cranes traveling along a track.=
 Two cranes can pick up each side of a large object. One can imagine automa=
ted communication (now human operators with radio).



=A0 =A0 =A0 =A0 . [Tom] Second e=
xample is pivoting crane.
=A0 =A0 =A0 =A0 . [Pascal] Splits mobile case if "crane" an=
d "mobile" worker.



=A0 =A0 =A0 =A0 . [Tom] Mobile w=
orker does not require deterministic schedules.
=A0 =A0 . Large plants
=A0 =A0 =A0 =A0 . [Pascal] Concept of multip=
le BBRs interconnected by BB to allow nodes from different LLNs to be in sa=
me IPv6 prefix. Useful?



=A0 =A0 =A0 =A0 . [Raghuram] In =
some cases, we want to know exactly where a node is, having the same prefix=
 might remove that information.
=A0 =A0 =A0 =A0 . [Thomas] System can be built so that a networ=
k operator can know to which BBR a node is attached, yet all nodes still in=
 same prefix.



=A0 =A0 =A0 =A0 . [Pascal] Edits=
 slide to indicate same prefix not always needed, isolation somtimes wanted=
.
=A0 =A0 =A0 =A0 . =
[Thomas] Wants to stress that we also want to support a case where one big =
LLN with multiple BBRs.



=A0 =A0 =A0 =A0 . [Pascal] Agree=
d, text encompasses this case.
=A0 =A0 . Non-production phases
=A0 =A0 =A0 =A0 . [Pascal] RPL can be needed as back=
up or for recovery.



=A0 =A0 =A0 =A0 . [Thomas] Very =
well explained in draft-ietf-roll-rpl-industrial-applicability-00. Agreed.<=
/font>
=A0 =A0 . Coexistenc=
e



=A0 =A0 =A0 =A0 . [Pascal] Do we=
 need a common management entity which could know about the different sched=
ules of different LLNs (possible covering IEEE802.15.4e TSCH, WHART and ISA=
1000) to facilitate coexistence?



=A0 =A0 =A0 =A0 . [Thomas] Such =
fine-grained (at cell level) coexistance management not needed. Several net=
work in same radio space work fine. Coarse-grained can be easily implemente=
d. E.g. blacklisting some frequency on which a single-channel network runs,=
 and which does not support a different network.



=A0 =A0 <<< Time's =
up, we don't go through additional slides >>>
- [09.00] What's next?


=A0 =A0 . for the coming week:=

=A0 =A0 =A0 =A0 . finalize=
 the list of use cases, with slideset as a base, on the ML
=A0 =A0 =A0 =A0 . start working on e=
xtra items (per Marc Blanchet's suggestion):



=A0 =A0 =A0 =A0 =A0 =A0 . what n=
eeds to be done in IETF
=A0 =A0 =A0 =A0 =A0 =A0 . milestones and deliverables.
=A0 =A0 . at next meeting: finalize =
discussion on use cases, and move on to two points above.



- [09.05] Meeting ends


--047d7b111c53e7265504d892dd1c--
--047d7b111c53e7265904d892dd1e
Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; 
	name="6tsch_use_cases_call03222013.pptx"
Content-Disposition: attachment; 
	filename="6tsch_use_cases_call03222013.pptx"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hemggsen0

UEsDBBQABgAIAAAAIQBi+1zGJgIAANQPAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE
l91u2jAUx+8r7R0i307EtNu6tiL0Yh9XW1tp7QO4yQG8ObZlG1bevidOiABZJTRYuSFKgs/5+Xz4
/DO5fSlFsgJjuZIZOU/HJAGZq4LLeUaeHn+OrkhiHZMFE0pCRtZgye30w9nkca3BJrha2owsnNM3
lNp8ASWzqdIg8c1MmZI5vDVzqln+j82BXozHlzRX0oF0I1fZINPJPQIYXkDywIy7YyX6oVo7agU+
tPXlS4oWSfKtXlp5zwjTWvCcOWSnK1ns+R2p2YznUKh8WaK3VBuwePV/L0XqjX+sjNJuBJfDEfxi
a7V0TSTqm69RaGrbnaISYLoamuk3sw5rua6Y+uY8ClNtu1OcGppPUTiOIfg8CEHVdQ9GaXtq763h
TjEIVGucePTroDinXD+mOOfeEUxNB8Xp5E7V0xBcnLqGO80gh0MVqP/tHwJvptOeAx0TZ/9HVEKA
Kc65usv0HWZsKVzy4wVlS62U/mqY76kRXlYCx79ARRFYY0DYvTUHFEyjmlJc6WWLXXBtN9kLeHhb
Ih3QOtv66NSFvmO7ZFxuNvGm9Auku38HbKNsZOBuukNMqCL9FKOYsd7BgaqOCihGGgcjGMehTWrI
dyWFHXsW8MetBZx8kG6ZfndWhkpL+5UQKpVx70S9r1ZaqGZsxJHqnXLVEMQR5ocIVhz+R5F+reFD
BH6+BkrjeqDKaE+RXBk4nmEzDqrVgbOD+m/y6SsAAAD//wMAUEsDBBQABgAIAAAAIQBo+HShBQEA
AOICAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLbSgMxEIbvBd8hzH032yoi0mxvROidyPoAYzK7
G90cSKbSvr2h4GFhLYK9nNM/X/LPerN3o3inlG3wCpZVDYK8Dsb6XsFz+7C4BZEZvcExeFJwoAyb
5vJi/UQjchnKg41ZFBWfFQzM8U7KrAdymKsQyZdKF5JDLmHqZUT9hj3JVV3fyPRTA5qJptgaBWlr
rkC0h1g2/0dbOmI0yCh1SLSIqZAltuUtosXUEyswQT+WdD52VIUa5DzQ6rxAPOzci0c7zqB81arX
SP1vQMu/A4Wus5rug9458jxjgpx2fDPFyDImymXsaPupH7o+JxDtmbwhc9o0jPGTSE4us/kAAAD/
/wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMu
eG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+D
eFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQ
yRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxz
wWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAY1wjtMEAAAA3AQAAIAAA
AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxzhI/BasMwEETvhfyD2HskO4dSimVfQiCQ
U3E+YJHWtogtCa0S6r+vjjYEepwd5s1O0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0FufgScNK
DF17+Gh+aMZcQjy5yKJQPGuYco7fSrGZaEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7Y4qr1ZCu
tgbRr7E0/88Ow+AMnYN5LuTzmwrFs7N0wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2DwAA//8DAFBL
AwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU0LnhtbC5y
ZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8
hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1p
xFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihr
kHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQv
c2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZt
sE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nA
XELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7P
Dm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAI
AAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHOEj8EK
wjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfB
Ot9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETz
wI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI
8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMv
X3JlbHMvc2xpZGU2LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17
c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQ
PGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5
juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1
Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNy54bWwucmVsc4SPwQrCMBBE74L/
EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306r
HQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYq
zRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9z
mw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9z
bGlkZTgueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3m
zU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul
2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWD
s3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAp3Qv2U8BAAB3
BwAAHwAIAXBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAC81d1OgzAUB/B7E9+B9F5K2admsBtjsgsTo/MBOjh8RGibtk55exs2
kS3L8abZDUkPcPrLn7as1t9tE+xBm1qKhLAwIgGITOa1KBPyvn26W5LAWC5y3kgBCenAkHV6e7N6
hYZb95KpamUC10WYhFTWqgdKTVZBy00oFQh3p5C65dYNdUkVzz54CTSOojnV4x4kPekZbPKE6E3u
5t92ys38f29ZFHUGjzL7bEHYC1NQ09Q5uIZcl2AT0g/NoboInZTQywg28amwfNfAm+0al+VgGRUx
iVcIEkeMIRY+00AQcwzBYp8K61bsaGX0Q9pfGYbwakCSQBHMZxA94pkbC/pvcY6Kx+1yeAJlzb2z
zkBHygz7QMxrOPsavl60VKN9O5QwxexKUUwxBHNnu7+jVGkwZ1EMJUwx9YlAdswEQ9xfCbH8RdCT
32X6AwAA//8DAFBLAwQUAAYACAAAACEAqnnZeXcCAAB1DQAAFAAAAHBwdC9wcmVzZW50YXRpb24u
eG1s7JdRjtowEIbfK/UOkV8rNiSEJESEldoKaSUqocIewJsMEK3jRLahsKfv2DHgElXaA+Qtzu/5
PfMxdsz8+Vwz7wRCVg3PSfA0Jh7woikrvs/J63Y5SoknFeUlZQ2HnFxAkufF1y/zNmsFSOCKKgz1
0IbLjObkoFSb+b4sDlBT+dS0wFHbNaKmCodi75eC/kH7mvnheBz7Na04sfHiM/HNblcV8LMpjjUu
35kIYCYPeahaeXVrP+PmVvFvSpKeYHN8k6CWDVcS6ZAFli1Z+YtKBeKlXEn18MarypyEQZRE6SSO
kJ3I9BucGxB/Mff/E+5avZSdyTR2okMdbYJvsms+6cuJEx315ZkjT3tyjG1wyzzuy4EjJ305dOS0
L08ceablDosLYfPhFeeczIIoGo8xmeKSkzidpmagLi12oiwEAI/OtnbeKJA27DZTh109DMASdvTI
1BbOaqMuDBZzmuG79VrYp99r4TGqmx/46HVjsnOnsBMLWpxTU7HKCWZG2R43DiMe2mzp2+bjuiIW
qZiZAnTFv4t33UDorSpuhxh9wKVwL6yPvFBdg5nFdBYSnQIsmHjvIPTexN2CDUgz2bCqXFaMmYHe
Z/CDCe9EcTV17vrsYZZZ1dPcdrRAdt9qPmJKF0czoA8C0E4o5INQyDsOzBB/N5pZHtoIH8M7mmia
6IQHPgaK5TO58+nacuBzYhqK5RPd+QSTJIiHBtK7SlOxgKYOoDRMzfEwnECaigUU3wGFYYoNNBxB
2EGaigWUOICSaDKc0ebDpalYQOkdkKaD94/hkD4xTcUCmjmA4mkyHNKmgzQVc5PtXzHxeuv+y1j8
BQAA//8DAFBLAwQUAAYACAAAACEAn3IMql0CAABXBQAAFQAAAHBwdC9zbGlkZXMvc2xpZGUxLnht
bKxUbW/aMBD+Pmn/wfLnhZAQKI0IVUPLNKkvaNAfYBxDojm2ZZsUNO2/7+LE7ba2UqX1S2Kf7x7f
89z5ZhfHmqOGaVNJkeFoMMSICSqLSuwz/LBZBlOMjCWiIFwKluETM/hi/vnTTKWGFwiihUlJhktr
VRqGhpasJmYgFRNwtpO6Jha2eh8WmjwCas3DeDichDWpBO7j9Xvi5W5XUXYl6aFmwnYgmnFiIXNT
Vsp4NPUeNKWZARgX/VdKc2BG17xo/0ZtNGPtSjRftVqrlXbHd81Ko6oAvTASpAZZcNgf9G5uK8AN
FuE/4XuPRNLjTtfzGUmBGzpmGMQ/tV8IIik7WkQ7I3220vL+FV9aXr/iHfoLIIOnS1tWHaOXdGJP
Z1NZzlD0xKpzJRB6I+kPg4QEni39jh69azxYy7mFVyWyJwXKUKsdWu/anTtJfIgBWZ1e9pjL4tRy
38LfGUnKjV3bE2dOE8icpIAPH6gAJ22TMhE8rDEqKm2dTMjUdsEZgXbulbTzW6JpieJYFF9QPIxG
M5DGQmV6MCaKFdHk+5uYLU2Swu2QuM8Slp2Sb+s58nquD1vrJI0/QlJz2HaSQg9Cg/gqfIC0/yOE
08O/F2jeGwMKK9fGB11l+Geen0/ixTQP8ihZBsnV+VlwuZyMg+V4lCSLfHq5GF3/whATJSnVzD3N
b37EgPHFs64rqqWROzugsg67+RAq+ci0kpUbEdHwzzkDzxQ1hGd4NI3PJlESjV05IHFI19XWpw0m
PwMo17dE3Teu62C0WaYXzqRgmPXt/+zSigCz4zcAAAD//wMAUEsDBBQABgAIAAAAIQDk2A9+fAMA
AAkJAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTgueG1stFbbbts4EH1fYP+B0EPfHPmWNFFjF7ETbwv0
EsTpBzAUFQvLG0hKsVD03/eQkuLGySJJi9qAJZMzR3PODGd0+n4rBam5daVWs2R0MEwIV0znpbqd
Jd+uV4PjhDhPVU6FVnyWNNwl7+d//3VqMidyAm/lMjpLNt6bLE0d23BJ3YE2XGGv0FZSj7/2Ns0t
vQOqFOl4ODxKJS1V0vnbl/jroigZP9esklz5FsRyQT0id5vSuB7NvATNWO4AE70fhDQHM7YWebg6
c205D3eq/seatbm0cftLfWlJmUOvhCgqIUuSdhudWfyrYIabdM/9tkei2bawcn5KM3Aj21kC8Zvw
Cyea8a0nrF1ku1W2+fqELdtcPGGd9g9ABPcPDaxaRo/pjHs616UXnIzuWbWmFK6fNPvXEaXBM9Bv
6bEvdQ8WOAd4syG+MVDGB6jOrt2MevT2DppGsfx2ofMmEL/BNS7STDi/9o3gURCETTOA4wfyCxoq
tLCD1VVC8tL6qBFx0i8Fp6jlTkY//6AlJ7TyGqWIWjmFLB5Z6bC4yi+ppVf3kFwNvq1/ggwUaYaH
I+4+SNy2Kv6/lpNey6VWHpVGLgVlfKNFzi0Z/56yZY666MV/jahBPIUzeQY1itKTArGtGRXI08n4
cIj6E2pt2BXPKxa0wlOG+MT09YkJGM/mZV9Ewi0OeQw5qH+upfYl20vFXm73MWIR+Dl5Q6V5R2JW
A482qyn5rFXptUWL6Sxeh/5U5aw5q2zpmwdIbTHEinhUjvshPwV6obi9bcgDzGeBOu7ow+SOelRQ
5XiGTh2hdquuMkY0hKEjVtKEDBK5k8Vrom88+i6heY1eSrC90XcE647WHG7OkwCG3qgry7g72Ivy
5vkUQZ7O6uFJfYk0H5W3VZhEv6bOOfc8li1ZN85z6TKyW9IFwfjJQTcwzLW2JAwplIuLK3Wpu1kS
9MB4qMOhLUNEOLF/Uok2t22bifq+RuXfaV+xi/UTDuPmk0NfNHHwoOxnyffF4uRovDxeDBaj6Wow
PT95OzhbHR0OVoeT6XS5OD5bTi5+JPAZTTNmeWyvH/uXAiw+GsSyZFY7XfgDpmXaTvTU6DtujYbU
GOqj4c9vBhispKZilkzehu/4ZHLYjRKEGztyHza49FObCfuZmq911BIvIzguy7hkkOwgM0x3JkEE
TPv/AAAA//8DAFBLAwQUAAYACAAAACEAwpCwgtECAACYBgAAFQAAAHBwdC9zbGlkZXMvc2xpZGU2
LnhtbLRV3W7TMBi9R+IdLF/Tpu26bouaTmtHEdLYKrqJa89xmwjHtmw3a4V4F56FJ+PESTbKNjRA
5CI/9vcdf+f4+Mv4dFtIUgrrcq0S2u/2KBGK6zRX64TeXM87x5Q4z1TKpFYioTvh6Onk9auxiZ1M
CbKVi1lCM+9NHEWOZ6JgrquNUJhbaVswj0+7jlLL7oBayGjQ642iguWKNvn2Jfl6tcq5ONd8Uwjl
axArJPOo3GW5cS2aeQmascIBJmTvlTQBM76UafV05toKUb2p8p01S7OwYfqyXFiSp9CLEsUKyEKj
ZqIJC58KYXiJfklft0gs3q5sMRmzGNzINqEQf1fdkcRisfWE14P8YZRnV0/E8uztE9FRuwAquF+0
YlUzekxn0NK5zr0UpH/Pqg5lSL3Q/LMjSoNnRb+mxy/LFqziXMGbjPidgTK+gmri6smgRxvvoGkQ
y2+nOt1VxG/xDIMsls4v/U6KIAjKZjHAcYP8klUOFapzs6Qkza0PGhFX+JkUDF5uZPSTUmQ530hm
yRiKeGxIC/N7rLCon7CN1zAxXLaXDhAUBC5t4XitlX1e34NW35lWHu4jC8m4yLRMhSWDf1M7T+GV
dkP+v9CNON+/7YnSCvtH+/NJ/N3GcKaIY6UgXBsDAdFsSKGdJ3pFfCZIgXmv8eBZrgTJIbldQW/3
htzBETCoZcqhgQiHSXKrfUakvgOSseg0BE2v+V4zh0WU2xSm8kF3j3NthOAGHFqVLphlH58VALo9
55xgoLbh4PRfOHjVhD6wsXlCv0ynJ6PB7HjamfaH887w/OSoczYfHXbmhwfD4Wx6fDY7ePuVIqc/
jLkVwbPv2x6NwUd9sci51U6vfJfrIqobbGQqCYyGXOix/d7PjRp9jpRMJnRw1Ds8GVVXc7JRbjgM
bdng0jZRLu0HZq7KcHLxb8AuzMKQwd+gkgOhDyGVCGi+PwAAAP//AwBQSwMEFAAGAAgAAAAhANpQ
bDoZAwAAKAgAABUAAABwcHQvc2xpZGVzL3NsaWRlNS54bWy0VVtu2zAQ/C/QOyz0VyC2bMd2EyF2
EDt1USBNgjwOwFBriyhFsiTt2Ch6l56lJ+uSkpLmBSQu+mFZonZHO8Ph7sHhupSwQuuEVqOk2+4k
gIrrXKjFKLm+mrX2EnCeqZxJrXCUbNAlh+P37w5M5mQOlK1cxkZJ4b3J0tTxAkvm2tqgondzbUvm
6dEu0tyyW0ItZdrrdIZpyYRK6nz7mnw9nwuOx5ovS1S+ArEomafKXSGMa9DMa9CMRUcwMftBSWNi
xi9lHv6dubKI4U6tPltzac5tfH26OrcgctIrAcVKkiVJ6xd1WHxUFEY36aP0RYPEsvXcluMDlhE3
WI8SEn8TrpTEMlx74NUiv1/lxdkzsbz49Ex02nyAKrj7aGBVMXpKp9fQuRJeInTvWFWhjFJPNP/m
QGniGehX9PjpqgELnAO8KcBvDCnjA1QdV72MejTxjjSNYvn1ROebQPyG/uMiy6Tzl34jMQpCZbOM
wOlC8ksWHIqqdX2ZQC6sjxqBK/1UIiMv1zL68c1SyOBnYEuvyY7klwOSxtPO1Hio8nNm2cWLsIEm
y6gAqr0plG4rJV/Wc7fRc6qVJ7fBuWQcCy1ztND7N3VFTt5oNuD/Cxt3wI9//3ok3Rb7YfH7UtDx
g7dB1RVYzJfUjRTfAHsrBKClVhNFC/t/MduqAshxYVlOBG4LVOALtAiMfrwgT9KyjovUR1fCahW6
1Q7kWlu3A6VeBSeW6JmUggMzhjLlDqDn7faHB/VUjou228r3nKntJL5BoGa/oFMVOj9HoigclExt
oNDGtWFKyEsXom7JyPOwoTQ0BFH3GhbU2MEGJR6w2YpC+xHE6w9qLdvrE56e7HjAmwFA3fjEUcsw
sS8vrRglPyaT/WFvujdpTbr9Wat/vP+xdTQbDlqzwW6/P53sHU13P/1MKKfbz7jF2Hm+NDOTFp/M
qVJwq52e+zbXZVoNvNQEkY0WceZ1O38PTpo7sGKSLN3pD3qDYW8wqDstlRubVVM2cWmGGpf2KzNn
q3hyaVZ7tNO4ZMiZodFR6H1IEIGG4R8AAAD//wMAUEsDBBQABgAIAAAAIQCe7PFD3gIAAJ4GAAAV
AAAAcHB0L3NsaWRlcy9zbGlkZTcueG1svFVRThsxEP2v1DuM/NVKJJuEAGGVBJEAVSUKUQMHMN5J
1sJrW7YTklaVepR+9SA9Sk/SWW8WSoGWqlJ/dr3jmfG855m3/YNVoWCJzkujB6zdbDFALUwm9XzA
Li9OGj0GPnCdcWU0DtgaPTsYvnzRt6lXGVC09ikfsDwEmyaJFzkW3DeNRU17M+MKHujTzZPM8RvK
Wqik02rtJgWXmm3i3XPizWwmBR4ZsShQhyqJQ8UDVe5zaX2dzT4nm3XoKU2MvlfSkJCJqcrKt7cX
DrFc6eUbZ6d24uL22XLiQGbEFwPNC6KFJZuNjVv81ORGi+SX8HmdiaermSuGfZ4SNlgNGJG/Lp8U
xFNcBRCVUdxZRX7+iK/Ijx/xTuoDqILbQ0tUFaKHcDo1nAsZFEL7FlXlyin01IhrD9oQzhJ+BU+c
LetkJeYyvc0hrC0xE8pUG79qM/JR+3viNJIVViOTrUvgV/SORp4qH6ZhrTASQmXzlJLTg+hXvOxQ
1I3LKYNMunDHURgKUxTohOQK+CIY6kFqkj7xEeg6YhJ6Uj4qpT6XlhUxT9OzXdMzNjpQ88BEcYG5
URk66PwbWTKjq675/G88ce8xQHBcXNNoAk2tq+YJjIaQIxRmifCKz2lYaX0llQzrLSA5gGxNnS+F
f918hNdI7nMv69sXuJfij3HgizBWyEmwNrMShoXRMhhXovi7ZLG1whCb8yYELCIDC4dgZjCj4f9A
0rgFUge3KCUSSDS8KU3fP3+9d1DVUBvgqLMJd/z97/r0qQ6MjVjrDonAqaemtVEOFk4O2MfRaH+3
M+6NGqN296TRPdrfaxye7O40Tna2u93xqHc43j7+xCim3U2Fw3ihb2upJuMDeaRrdMabWWjS3CSV
zibW3KCzhpCT1LZbP+s1yR0suRqwPdrodTp7sfepbqo2zlRdNZlqKRXKveP2fBnnl/4QAd04mixd
2UZF7lxKDkiCfwAAAP//AwBQSwMEFAAGAAgAAAAhANqq2QIyBQAATRAAABUAAABwcHQvc2xpZGVz
L3NsaWRlMy54bWy0V11uGzcQfi/QOxD75ABRZCmyLAuWg9iJiwKOY9QJ+jzijiTCXHJLciWrRYHc
oXfowXKSfuRqk8hZp4nivGhXXHI48803f8fPbgstluy8smaS9Z7sZ4KNtLky80n29s15Z5QJH8jk
pK3hSbZmnz07+fmn43LsdS5w2vgxTbJFCOW42/VywQX5J7Zkg28z6woK+Ovm3dzRClIL3e3v7w+7
BSmTbc67rzlvZzMl+YWVVcEm1EIcawrQ3C9U6Rtp5ddIKx17iEmnt1Q6gWXyWufx6cs3jjm+meUv
rrwur1z6fLm8ckLlwCsThgrAknU3Hzbb0l+DbXjp3jk+byTR+HbmipNjGsM2cTvJAP46/uIQjfk2
CFkvyo+rcvG6Za9cvGzZ3W0ugAYfLo1W1RZ9bk6/MeeNCppF74NV9VbC0Qsrb7wwFnZG82vz5OWy
ERZtjuLLhQjrEsiEKGqzr/6Y8Gj2e2CawAq3pzZfR8OneKZFGmsfrsNacwIEatMYwvED+DVFhrLp
vL3ORK5cSBgJX4QzzQQub2AMJ78r0IS9F1fOyvg8syY4q8XeMRAKcFAj9n9kswNR4fKWOyREfqO0
FimP7ohgk1+Ro9/uNTfCT2MAA0wbAPFae/h+Pz9t/ByRQBSIK02SF1bn7ET/+7yucnC2IcY9Do84
36H+YHh4MBgk/vf6w9Hh8E4UjPr9o+E+AiTGwsHR/mB4MEysaiQls2vuNUg0VIrXGfu8CnamQg1Z
zbH44Wsp5v+cZEhc0OCLZCusUcE6JDpxx5ntzG0Rm8geTuxMaBu8iE+wFp5RRWkdcrFkpOQKaUCr
GxbSOmdj+hZ7jv+oQHaPgyus+yC8JE1TpVVYi/fv/hFhoTwM8MGpaRU431nJtiBwtgow/LHwdoar
o/bPdr5gg8J2SNRkT4xvYvZubLQA2qardGQAlC/JmOgsckxiL9aRR2KlwgLYGiYnUPmEVE5WGn8K
G4sNQKTwvXbhPoiDZzhdp4wgAZXmvLPgNiv3jBVzSxoeKeJFWgvD8HrOgV2hDIigpECVBlusQ9FP
9VBMOayYjdiA1PlRTni1AcC6G9B7j/JcRYBJ67UonV2qROtEJAH/5OukagNbOuUfidzCkcaGNtO8
itGyqAoyW+H4cEQCL+C0EuUIsbp1xzcwdEP2jwEcFrby4F4K/5yX6Hx8Hb+VB1N2vaeNI1OSN1P0
do9FUemgSjByZ/FfqJDTqfM7y22plYkKPfFDdL24uHxQVXcVtqFFdHzMSSlJ+GpqONTJ3ApaWvXA
SZxNVUw5VrDH4hJRRXpFa4+kh1JDHjSJuSSoAkGnvK37b7yJFSKA8+1UgS72nhamJU3D2ocLS2NN
Bykkr2RK2d/pAS5hag6LP0bojFBeY3Ug9BXGFsijU17QUiGZRofRHAPOVqndlMdthB7OYmn5Fvkc
09vuAbwhXF0AeU5yjVKRks8nlhOKRYE+RyCp0pzjNLZ7FLZENk3tEjSTlpxn9D5L1rjqBuhjYsPK
nlygaLP2IqYuHWsYCjjaGRQB1FTH79/9i7w/RyKjHEUuknNu7YNQ8/M+O/WdzZiIme3CY6Io0/RW
OTXJ/jo9PRr2z0anndPe4LwzeHF02Hl+PjzonB88HQzOTkfPz56+/DvDmd5gLFHlIl9/bSZrLH42
zYJqaPjQYj2BH7r1WNwt7YpdaVWajHv7n47XmE7FkvQkG4z6o8FRDz1sDLWkY/NMWmOpmXyldq+o
fL1MTSsGerQLZ2mpBLD16U+2RAwwMf8HAAD//wMAUEsDBBQABgAIAAAAIQDct4MggQQAABsPAAAV
AAAAcHB0L3NsaWRlcy9zbGlkZTIueG1s1FddbuM2EH4v0DsM9JQAVmwnzp8QJ4i9ybZAdmPEWfSZ
pmiLDUWyJOXYWxTYO/QCe5Y9Sk/SISVlE8eLREn60BdLJjmjme+bGc4cnSxyAXNmLFeyH3W3OhEw
SVXK5awffbo+jw8isI7IlAglWT9aMhudHP/805FOrEgBpaVNSD/KnNNJu21pxnJit5RmEvemyuTE
4V8za6eG3KLWXLS3O529dk64jCp58xx5NZ1yyt4pWuRMulKJYYI4tNxmXNtam36ONm2YRTVB+oFJ
x+gZHYvUP62+Noz5Nzl/b/RYj0zY/jgfGeAp4hWBJDnCErWrjepY+CvxGL60V8RntSaSLKYmPz4i
CfoGi36E4C/9LwqRhC0c0HKRfl+l2eWaszQ7W3O6XX8ALbj7qPeq9OixO9u1O9fcCQbdO6/KowRF
LxS9sSAV+undL92jH+e1Mu+zV68zcEuNyDivqjpXbgY86vMWMQ1gucVApUvv+ASfYZEkwrqxWwoW
AEGzSYLK8QfhF8RHKJPxp3EEKTcuYAQ2d0PBCMZyBaM7/o1jmDBrYWQU9c+hks4oAUcIkEN+Kq1M
piNiyNUPlXtnSYJmoAe1ufha4vljVHdqVP13MeZgJAhlmRIpM7D9Oox5ihFS09AEXg+jxOw8LZya
cgdTtG1MiUDG9vd3OxiJQo41vWJpQX2G9SPMWlwuMSgp8jrehKFVJp4gOUSDO6YVjUIpbWHDsD8K
ZNoCgZlQEyJAacdz/jnkOKgpGFU43MeiBL9z5xB9IjGOkBO6hH++/A0uKyxQlWs8l8JkiapWYuQJ
y4AZrGWBDx9ao+FZM/nKs29fIW7BVKhb2FBYnDdBGzXnvkZjBW01NWpNTqSFosR62g1Y1InZnikN
G83Mrd1dl3XdXz43VLbGTCQobeptRcE6m3pvYdNmMEqqEE4voKPi+Ja7zN+sjlPIC+G4JriQEZOC
FcoBEQIp8qm39RCBsgSFOvSiclinTTN2Kqt9roHG2guDexlnmZjGGSMC4YA4ZFHKrTN84hMprpFq
9sV1BLbganSxuaLn+XX75aDZQjODGajM8iEbT1JQAeeT2TYUXYfABgbeTBGRwF29W4HjiRJV2ZMy
rH85l9zmUGhwCosfewP7JoTeTLBTxBbhv+ap8uTb12YArEM1J5LMmO8rG0JQ2XD/8rFMYxfhGGKq
lVCz8mohPnKBS99LUwYxwk0cpArvI4nZ/noXJoaRmy24PD9pYb6hSkxKFq7uk9b/iAnsQIxrmig1
C5PCWLdsQSHZQqPzLH2Lu1LJOMWhpvFNVFm1Us1beJdzZbirGpPXM/9ydh/3saGdrYcenEAuLDbI
OswiheH96M/B4HBve3gwiAfd3nnce3e4H5+e7+3G57s7vd5wcHA63Dn7K0KZbi+hGJL+Avu1nhNx
8dFslnNqlFVTt4WNV7sc8tpa3TKjFQ9zXrdzf1jEWQvmRPSjg92dve1Ob++wGi7Q2tCZ11ajK/Uc
R4X5QPTlPJRGHE+x9A3DksYLC2nyR78f8Rjg/PcvAAAA//8DAFBLAwQUAAYACAAAACEAA1zFyagD
AAB+CgAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbMRW224bNxB9L9B/IPYpASKtJCu+CJYCS4mK
ArkYlvMBNJfaJbJLskPq1qL/km/Jl/WQq3WytVJHboHagLTicobnnBnOzOWrbVWytSSnjB4n/W4v
YVILkymdj5OPt/POecKc5zrjpdFynOykS15Nfv7p0o5cmTFYazfi46Tw3o7S1IlCVtx1jZUa75aG
Ku7xk/I0I76B16pMB73eaVpxpZO9Pf2IvVkulZCvjVhVUvvaCcmSeyB3hbKu8WZ/xJsl6eAmWrcg
TcBMLMosfDt7S1KGJ73+hezCXlN8/X59TUxl0CthmleQJUn3L/bb4k+NbXhI/2aeN574aLukanLJ
R+DGtuME4u/CJ4z4SG49E/Wi+Loqig8H9orizYHdaXMAENwfGljVjB7SGTR0bpUvJevfs6q3cpi+
NeKTY9qAZ6Bf0xPv142zwDm4twXzOwtlfHC131e/jHo0+x00jWL57dRku0D8Dt9xkY9K5xd+V8oo
CGDzEZzjA/KXPGSo1J2Pi4RlinzUiLnKz0rJkct7Gf1kUXHy7BJqeASjcfHPfuKBfiKUV9KlSi+J
O08r4VfIm7YveAQykGoY4LGW+PtCnzRCz4z2SEN2XXIhC1Nmktjg38muMiRNE5ljFA+KaFzYq5U3
S+VZqRdW3MgMrOvi0MNfjGQTo2Dxn4To2XHRYZJQMiLHEFQyPHuB8Ejpj/Ozj/Jz5omH6sIEwkGm
ZM9I/rZSIdRKC5LcSWaW7bA3efT9VGyDvNs8CRvjjlWG5D1EpZkv5LFYDlyLoFoLUp3IMZsfJ3fA
oXv6PVvRHdfMcvqEDvGN+oTsQ+vRYhf0J7PyCAl2GnSsjiWzVqFvBY1aTB6H347Nzfw4833esEzm
xDNA2ihfMMHJMaDxxga0IUpoMc6Qe/7lc/hvgzxG7v2BXz4fh/NQNcxxTXQbyaNy7Y//HROA67J3
RitvCGmpXKiHuCMs55SB6wukqcpzFLEN95IQzG4L8f/EGWV89zTKpcoLH25gpBz4sJumNCDdc4RY
cLTKSrpCugNcH/aF2B6auQJN/q1DW7Kx3a9IjZM/ptOL08HsfNqZ9ofzzvD1xVnnan76sjN/eTIc
zqbnV7OTN38msOkPR6E4her8azOKYfHB+FMpQcaZpe8KU6X1HJVas5FkjYqjVL/37TyGcYateTlO
Li4GZyenZ+d11Y8YY6drUINKMyqJkt5x+2Ed+zMmQER/FpcsREP+hK1ftwQNMGL9BQAA//8DAFBL
AwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVM
YXlvdXQyLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePs
MG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPc
KcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1Qo
Hp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3
AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxzhI/BCsIw
EETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8
r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2
pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H
1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91
dHMvX3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOW
ZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vm
QiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L
83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYA
CAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ1
LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1r
GsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZ
hki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3Km
VLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAA
AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxzhI/BCsIwEETvgv8Q
9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62
IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFp
zoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277
AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3Jl
bHMvc2xpZGVMYXlvdXQxMC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtsk
ZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLi
wUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6
Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAh
ANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwu
cmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK7
4DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhd
SBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrK
GqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQv
c2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQ
kaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4
Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9osp
TlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//
AwBQSwMEFAAGAAgAAAAhACXzlI8HCAAA8i8AACEAAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFz
dGVyMS54bWzsWl1u40YSfg+wdyC4jwuNxH9SGDmwJDMZwJkYsXOAFtmyuKZIptly7AQB5g65wd5i
d99ylDlJqqqbFGVLMzIsA7ZhwJDJ7mKxur76l95/e7PMjWsu6qwsRqb1bmAavEjKNCsuR+bPF3Ev
NI1asiJleVnwkXnLa/Pbo398874a1nn6A6slFwbwKOohG5kLKathv18nC75k9buy4gXszUuxZBJu
xWU/FexX4L3M+/Zg4PeXLCtM/bzY5/lyPs8SPi2T1ZIXUjERPGcS5K8XWVU33Kp9uFWC18CGnt4Q
6QjOl5znKf6fXarPn/jcyNIb0NJgYJlH79mQzsknuTCuWT4yZ5eW2T9638dHgFhf4cN1dSE4x6vi
+jtRnVdnAm+Sj9dnAngCS9Mo2BL0iwxoQ5PRbQFkivHG45cNJza8mYslSgTqMUBCQPEWP+EhNuQ3
0kjUYrJeTRY/bqFNFidbqPvNC+Bo7UvxVOpE949jN8e5yGTOjbOcJXxR5inYCqmITqgeAy1Wp2Vy
VRtFCWdGVaijgnIaxnh+fFW1MORtBVqSyFbTqU2QrGjpa9JvI3SrFdcLwOhINXbg+k64qZ/QtiMf
91FLluU6A7hBWdaMKlHL73i5NPBiZAqeSDIEdn1aS0XakBD6SpBqKG/GZXqLYMzgP2AOHgfPL0rx
m2nkH4p6ZEaW68K7Jd2QpKYhujuzjR2ZT0owOXiCFQnwGZmJFCRLAd52vJLlPNMSqVfiy/Nansvb
nJNZAHhsCGqFDxAoZ+jwvOj9fA4Ov5STnDMICNqE5NEkz5IrQ5YGTzNpaL8nGCA8AEvUkiRdEUte
pGdMsJ/ucNYqIt00OgHklCHtNienNSe05a412QjQY60JFWRq136MUVlgPWhgpN7G6zasyvVsL/Kd
529VaBYPMiTwOCO/Jouk4z/SsFB7ZFf1hmGBkZHZqo/mlRQxHmDL5zwpi9TI+TXP92BPNvYA9heL
TOzPnYzhAdzjciXkYm/hXWWNe8MRZ/Ot3CGNHNSl3calp0xuJghSyGNdOpUQxX6DCMvyuXZtgpHS
BCaTB+YL3/Hg745r25bjtAnD8T3L9p6/Z2/kC3LVJitQhrjOLXRlll9C9M9NXEv5HOM4qtPC8IZr
dZlnaZzlOd1gubcug+SNqo5kVkhVGAXeOpW2NRMliw4f8G31JtqAWIKCqGudtvBd5PnzPKWq6fcw
iOOTgRP1/GBy0nOnx3Ev8pxpLzqx3GlsRUE8mf4BSZWKhhQsTWZLHmeXK8F/XKnU/fXkB2KQnuSR
07dtKDktZx01QBQU67DO4TXOEZcl1tfdjEcO/Vj3mEOtQID+smIC3qBdRCUmrKT2dRHHst2mptru
I2HkvWofacqu5+clh7VJv7HJc/B8bnxcLWd3LJOC32MtE5pKYL3NOMnwHxS/fc9zvmycrz2Aq47g
+ZlmG8CDeGpPXW/SC8cnEMB9N+4dn0R2Lzx2w3jsRKHvDtoAXqPlFWAdGHEfErc/f/rvPz9/+t8B
ojY1K00vD0UqtH3Yf2C5uhLZyPx9PI58exKOe2MLzuJOo6B3HPteL/Yc152Mw+OJc/IHHKCy3GEi
OE0ePqR6AgKL96YWyywRZV3O5bukXPbV+KNflb9yUZWQYDEdDbpjFBghqKTrDCzfgg/qckFukJHK
nkZqWGomHEkufmCVAfMLyPkSZhGQwkdmegVXs0sb16ChlzdwlV7BFUsSGJoAhb5oVmBfrbQ0TrMC
HZzaggPqi2bFa1Yg66ktv1mBmLPIs+IKlIL/TGNe5t+rheYKCy4aRZ2y23IlP6QaEYgjzQqVCrbl
Bm7o+G4EbfUQRy7iQ6pnEbtood5b0+pOcyct6Krlq0vYnbSgn5ZW5/OdtKC5llZH2J20UFS3tP49
zWzowQNtt7TBV2gBh5aWzGlD45t8gw5t9BW+MFts+VpUXH+B8QZwzZCoowoNvLyhEUeNZkHzCbrF
iKFLSl3bYt42IDJesNk5VLY0fkG8pZqqcHZajAVYHuCK08VC3wLJAkYlMMI8WxUJzHD0JLBKxjjx
w2lWcpboupeOBHUtrOnd2eojjFGpnOxEZZj8AN8rLnAEu2+JDUyQdbcQJ0Gp2p3DwG1k/mv5714u
EQSoUNmdDc7URlLf2Uhq3NhVjm9qFUadMDy5p+IlE6cj03HtCA+WFRC2QVW9ZqHpLp5a/6BKNY65
g0FcQmeCTYFS07HIWG4aVSaTRcyWWQ7zPwd8KVkwUXMQXPd9s9UEVmh5ZH7+9B+lvw6Oqtp4ChyL
XTgWvR04Fr0v4kjuYGOrp7AKACuMdy1WduhB2wYhWXeCLxurP+9hZYdP5XMHxAoB0qHLWWPVzKY7
YNkhNVmvA6z7jmU/WYA8IFiIkAbL7YClh8KvFawtnoVB90my2QHBQoQ0WN4aLHvgBWRq6zD4ijzr
r//fj4IvASsESGPld7DyLJeC3qvEalt5geXMs3csREiDFXTAigKLEu4bWF8am+9V0x8wCiJCGqxw
DZYq0zeKwVcUBV+sZyFCGqyoA1YY+jTkfPOs5+RZiBCN2zr9cTUs5YKLtluGzvFMQap7yO6PMNoW
XJM00wvVrj1JY9bpZFWwfpGdbPMrn8P3Qi9NP9u7x2bS9aafHQ2bE+APeZ5i8vHSDGh7k2SFdki1
3JsF7ehMqFp6syBIWTu6gcBVo9I3C9pRgUNFR3OINwXtqHp9L3gL0jTEbyvNbnEJX+6uvwjDL62b
3+of/Q0AAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRz
L19yZWxzL3NsaWRlTGF5b3V0MTEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk
2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZC
I+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvz
f3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAI
AAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDcu
eG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/Wsa
xZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmG
SL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZU
sJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAA
cHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHOEj8EKwjAQRO+C/xD2
btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYg
OKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnO
gPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsB
AAD//wMAUEsDBBQABgAIAAAAIQCslGfmpAQAACARAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk
ZUxheW91dDEueG1szFjbbuM2EH0v0H8g1GdF9yviLHxTUSCbBHX2AxiJtoWlLqVor91igf2t9nP2
SzpDibaTTbFpYRR+sSlqODwzZ4ac0fW7XcXJlomubOqR4VzZBmF13hRlvRoZHx4zMzZIJ2ldUN7U
bGTsWWe8u/nxh+s27XhxS/fNRhLQUXcpHRlrKdvUsrp8zSraXTUtq+HdshEVlfAoVlYh6CfQXXHL
te3QqmhZG8N68Zb1zXJZ5mzW5JuK1bJXIhinEvB367LttLb2LdpawTpQo1Y/hyT3LVgrS8mZQZSY
2MKEY9yA5fmCF6SmFUw8ogRZ8LJg6lXXPgrGUKje/izaRfsg1Iq77YMgZYEahpWGNbwYxNRjDWIw
sF4sX2lNNN0tRXVzTVNwBNmNDOBrj7+wiKZsJ0neT+bH2Xx9/4psvp6/Im3pDQDBYVOguu0t+tYc
V5vTO8I5WNWLUlh62+QfO1I3YCea35uX3221MrQZ1bdr0ns9l0JpG0T798olekmn3KqxHpwRxkFs
9x5xHc/23eC5X6Iocn0UQO84fmTbvcSp1b3qNpW7SVPs0atP8K9YoSnv5ELuOVPeBp/QFJDDD3DL
KWYMq80PC8iYSk45o5BRAzPyZsrL/CORDWFFKcl72kkmiFTR06HKawAhgflBJauLByrory80o/No
CjuDOzRCGPb8/DNLnmZpsXnq93TPQVS3eeqJgsiGsNPcvp0wx4uccGDMi+MQzoTnjIVAl6JUMRYF
Lkr3TugTQRnfx4/2x6uMIU18yx0IHFJRcasyp6wLyH41pHwFbEHkQRaDgs0dnHaK5YItgQSc7BrI
8qzkXD3gEcemXJAt5XBQ7PBkAAbLWvYzUWAfoKrzEIUVeyd6gEutH4YDPtQDQ/cI1Q8i9Ay5PLwI
csDrHfEmjq/S7PLwIsgBr3/EewjDywOMKAfAwQng2I1VWlweYEQ5AA6PgF03hsy9yBBGlAPg6ARw
5HsXmnOIcgAcHwEj2gtNOkQ5AE5OAIdBpM7+y4thRKmOan3fI/ozXPdwX/5fN76vb/wZlYw8cJqz
dcMLqDm8c9z8hYQi53cosSlfwr2kbv/+YsbKVXkPBwvlSKxPVAF1rFlevaOPVdUS6msslv+Ioyyb
215ihtF0bvqzcWYmgTczk7njzzInibLp7LMx1I0FmCrLimXlaiPY/UYayNv3i7MeHJZfnuW60FM4
3rEaAyio5bz1WKDZyZoG68BTfvxz8LOEQkYR9NuGCthBc/SdEg0YeDNH5/VIqD2iWilyt6meXvhF
1fLQe+nG4T+1FtCzgupXXaMqYtVlnC98o2zmzvxgasaTOYRv6GfmeJ64Zjz242ziJTHUt4fw7bCJ
rAHdv43ar1/+/Onrl7/OELOqmtYNLHSTtx20JK3qKzeihHycTJLQncYTc+KALf4sicxxFgZmFni+
P53E46k3/wwGtI6f5oKpxvqXYmjwYfKbprwqc9F0zVJe5U1l9d291TafmGgbqKUxGe3TrwQjwxjq
6ySxHT/29KkDaFVXpFGDKdimI/yci/e0vd/CmU5T+C4B+QC1OEy18CUCm4lnIugD/WXj5m8AAAD/
/wMAUEsDBBQABgAIAAAAIQBpol8hHgEAAMcHAAAsAAAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9z
bGlkZU1hc3RlcjEueG1sLnJlbHPE1d1qwyAUB/D7wd5Bzv1ikrbpBzW9GYPCrkb3ABJPPliionYs
bz8pDBIojkLAm4CK5/z4K+Z4+hl68o3GdkoyyJIUCMpKiU42DD4vby87INZxKXivJDIY0cKpfH46
fmDPnd9k205b4qtIy6B1Th8otVWLA7eJ0ij9Sq3MwJ0fmoZqXn3xBmmepgU10xpQzmqSs2BgzsL3
v4zad/6/tqrrrsJXVV0HlO5OC2r7TuA7H9XV+bLcNOgYJMl03k4Hu8Tzgd6XrWLKViHZNqZsG5Jl
+ZI0568Zzg7yNkNv3yzkWJTx6K3KQ7JsyYAelQUzK2LKimBmcUMLpraJmdommJp/6+M9rVkasq1j
0tYh2T6mbP8no7Pfb/kLAAD//wMAUEsDBBQABgAIAAAAIQCkvLrJTQMAANUIAAAhAAAAcHB0L3Ns
aWRlTGF5b3V0cy9zbGlkZUxheW91dDYueG1srFbbbts4EH1fYP+B4D4rsi6+SIhd2JJVLJAmwTr9
AJaiY6EUyZK0a++iQH9r93P6JTukpCSbZoEU9YstDYeHc87McHT55thydGDaNFLMcXQxwogJKutG
3M/x+7sqmGFkLBE14VKwOT4xg98sfv3lUuWG11fkJPcWAYYwOZnjnbUqD0NDd6wl5kIqJmBtK3VL
LLzq+7DW5DNgtzyMR6NJ2JJG4H6/fs1+ud02lJWS7lsmbAeiGScW4je7RpkBTb0GTWlmAMbv/m9I
9qSArW0sZzeCnzDyrvoAxggvgD3d8BoJ0oLhznkh7+ZWjLrTjLkncXir1Ubdar/h+nCrUVM7gH4j
DvuF3s2/CnCDh/DZ9vsBieTHrW4XlyQHLdBxjiFlJ/cLm0jOjhbRzkgfrXR384Iv3a1f8A6HAyCC
h0Mdq47R93TigU6nQ/TAqnMlsPVK0o8GCQk8Hf2OHr0+DGCOs4NXO/RE+N6vW/R6DP4GNPVi2eNK
1idH/AP8eyPJubEbe+LMCwJhkxzA4Qfk58TVNRPB+w3UdWsLzgjUfS+eXRS8oR+RlYjVjUXviLFM
I18F0AUAeQnqWEhOD8lEfUs0+eMZsuNHcjgZgh4ihMdOwv8XMhmELIll6JYTynaS1xBBfA5NawuU
/4S2IHyLoRChSiJP3EvrEvBTGm+hH1x1/zWbVtV6lGTBZFqsg7RcVkE2TsogW0dpWUXZtCrKL7hP
dA1UbdOyqrnfa3azt/h1qeoKwCUjCeMY7oEoecwNhOJQzpuddMhOJaWriqf5Sc6Rn63VXYI+7YmG
E4YcDf1yhj44ryLjQZENb2qGrvfth2e6pOfQBeYMQL8oje+LM5fvtCrjMh0XwWy1hvKdpFWwXGdx
MFums2qVZLNJOnooX+OYC4juR6v229e/f/v29Z8z1Ky/WIaJA9f/lYELSvlBsNcN9ONqlU3iYrYK
VhFwSctsGiyryTioxkmaFqvZskjWX4CAitKcauaH4e91P5TB+N0gbRuqpZFbe0FlG3YTOVTyM9NK
Nn4oR6Onk32OMToQPsdJFo8m2Wg69v0CgUO4/tYZwgaTm6sufsr1O6JuDnAtkRw+JqAhCm9S8PnQ
D5BHFyfC8Dmy+BcAAP//AwBQSwMEFAAGAAgAAAAhAOX8egjkBQAAUhwAACEAAABwcHQvc2xpZGVM
YXlvdXRzL3NsaWRlTGF5b3V0NS54bWzsWdtu20YQfS/QfyDYZ0XinRQsB9aFRQHHNmrlA9bkymJD
cllyJdstAuS32s/Jl3RmyJWoWywrfghQv0jUang417PD2bP3j1mqLXlZJSIf6Ma7nq7xPBJxkt8P
9I/TsOPrWiVZHrNU5HygP/FKf3/+809nRb9K40v2JBZSA4y86rOBPpey6He7VTTnGaveiYLn8N9M
lBmT8LO878YlewDsLO2avZ7bzViS68395TH3i9ksifhYRIuM57IGKXnKJOhfzZOiUmjFMWhFySuA
obs3VZJPBVgrH8T0cfogru/+0DUSLpewbOjnYH90m8ZazjJYGImsYGVSiZz+qYppyTnK5Mtfy+K2
uCnphqvlTaklMQI0N+rd5o9GjH7mIAYX3a3b7xUS6z/Oyuz8jPXBG9rjQIegPeEn3MT6/FFqUb0Y
rVej+fUe2Wg+2SPdVQ8ADVYPhXgXtUW75pjKnGkiU64ZK6tqUQa3XoroU6XlAuxE82vzoqulAkOb
Eb6Ya43rEaqRq/8kfyj5CnxKzpKPQxE/oeF38E2LrJ9W8lY+pRACuF6mBgWA9WM++712bWsZrG2L
g5GsD6rABwQrZVgHPO98vIU6yOQo5QzqpHG1PB+lSfRJk0LjcSK1D6ySvNQkeaFCBc4AXUIoG0ie
xzesZKDEBjJ6g/XhyWCisgcua4cfdru1cjvG/CZlEZ+LNAYNzNeIAPpTh3SFXFIBOxAI9NZWStqO
BwVOeWk4lmMYFqq0zk67Z/cMH8gFc9S1As8lncENNRCZX6eE8oiKsMbyaC6ALe5qyHb0mmBrGSsv
qS6SPIYCx0t8+t3iCliMFKlzQav+GuimjZreKTNbuUGXJmRPA6isOgq1t4uKUKgHqGmtUQPDJg2O
QTX8XVSEalDtNapheYaLwkfBkuSmCxCrgXVasL7pkw6nwiJWA+uuYU3TBxW+Q1vEamC9FqxnW5SH
p2qLWA2sv4ZFzONDtse3iNXABi1Y1/G+K2SIRVzSrgliNHwIZN2KuujppzMcEg4RXLXBcKewmK1Y
bCRyCbW6QWTEGrDVqo3ihVsJVvecpbOGxmqKwW2V3IQX7f0EA3KYxkzDs33P+QaNWYFjQHGgxDE8
RjTUDtTOTrVmpxqyJQCXikzaTIYltJJVAiCrKKIlS0yyklUCIKvqvi2LWbmSVQIgq4r5oKwSAFlV
oQdllQDIqrI7KKsEQFbV0kFZJQCydYGoToD8SyS5su3HqCBqBuBDFS3tvy9oS255JPJYS/mSp3sK
dBue6uIF8NN5Uh6P3uz8RzNOKBalnB+tvF1X5PHwyWwvOvQmr9qdOYrXptvdGWl8OqnV/XHdnSHB
/blgJbSdDceRt6lVPprjXNvpmaAudGKHejXDA+Z769UG+luvBv3yW6820K3/Y6/mKk7b16tRa3Q6
re1SGfHkyVR2qF9bU9lbv4Y+3+x/3vq1AzOdb77xbDdUb/0ajtDqt8Ft3/yo/ZqnuG3MJN94CXWx
wzyd2Op+LZYwQNx8HTXqd6qD76P01O3pFyyuB5b0g97vZzCLxsny374XhpOeFXRcbzTp2OOLsBM4
1rgTTAx7HBqBF47Gn/VmyBqDqTLJeJjcL0p+vZA6oj8/FoAXE3q0PLe6pglTeMNav2aAKojyut00
TArrUXsoBM5Y29NO7zXiM5PQQe/uQcYzo8+XxOh1PRIoj9ymScy1q0V2t+UXmkR8b97CKQ9A73XN
M+OUl7hmlb5eODbHtjPq+MMJpK9rh52LSWB2/AvbD4dW4Lt2b5W+FVqeg3YvzdqvX/755euXf18h
Z2lOrU57YI+4rGDcX9AhzKJMoB6Hw8A1R/6wMzTAFnsceJ2L0HU6oWPZ9mjoX4ysyWcwoDDsflRy
Oor6LW6OxGBx5xgrS6JSVGIm30Ui69bnYd1CPPCyEAkdiRm99rnaQNe1JYPJn+M5jm2bPvVpoDdo
SycOSmtYwiMtorq0/MCK6yWQOOvDSR5U3IiWCji7g7ii6FoEfaDOAs//AwAA//8DAFBLAwQUAAYA
CAAAACEASYbMqoUEAACDEgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ0LnhtbOxY
227jNhB9L9B/INRnRdbVshB7EV9UFMgmwTr7AYxEx+pSokrSjr3FAvtb7efsl3RIiY7jOGu7yWNe
bIk6HM6cuXDI8w+rkqIl4aJgVd9yzzoWIlXG8qK671ufb1M7tpCQuMoxZRXpW2sirA+DX385rxNB
80u8ZguJQEYlEty35lLWieOIbE5KLM5YTSr4NmO8xBJe+b2Tc/wAskvqeJ1O5JS4qKx2Pj9mPpvN
ioyMWbYoSSUbIZxQLEF/MS9qYaTVx0irOREgRs9+qpJc12CtfGDXd39aSOP4EkZcawCmZ1OaowqX
MHD7wNCIVRLE6E+ivuWEKFC1/J3X0/qG6xlXyxuOilxJaGdaTvuhhenXCmDw4OxMvzeScLKa8XJw
jhNgAq36FjhsrX5hEk7ISqKsGcweR7P59R5sNp/sQTtmAdBgsyj4um4sem6OZ8y5LSQlyN1Y1UAx
TL1k2ReBKgZ2KvMb87KrpRGmbFbi6zlqaVeiWlzzUfNh8AI41WTJ1ZDla2X4HfzrQZxQIadyTYkm
BNTGCQiHH6CfYhXVpLI/TyGqSzmiBEPUt+TJwYgW2RckGSJ5IdFHLCThSGq7hBJ5DuxIcE4rklT5
Deb4045kZR9OYGVQ2mgIjw2FLxPpGyLbaEI3FGdkzmgOSnivo1V8hWzAdGZBBEJ4GB+8wK2iayfK
grAL+apDzY06HfWs+TUBF3T8GMYtpMIuCL2wF/nagUaSJqBxs+Fkr9fU2nRJXZ02OMnJTNGr9Pfi
ZlHgdgsAj94ebLCNNQDA+nuwnW2sAQA2eI51n+hgAIAND2ENALDRIawBALZ7CGsAgI0PYQ0AsL1D
2AaguG7TSTlGZxPMRCBhkzavzC4VQTq5xJPsajJod0kduCck9JRkrMoRJUtCjxCvs+wE8bfzgh8v
XSfECdJTtuByfrTyQZORR7sjLWZ7pcMu8qZ1LfhZXdOcwH5qNoMTt4uduqb9p7cKVWn0w/aesa+u
RUH8XthgR3gvbMl7Yds0Qu+F7YiGLTSFbYwledKt6VL8/6ta0wTnEnrUnb5NO+jlAndKUzyDE4w6
jvwdd9N00vF7dtQdTexgfJHavdAf272JG4xTt9dNR+NvVtuZ52CqLEqSFvcLTq4X6swDW9pOB/y8
t4bc0v2iHPiO58GxzfUf92NQRUl5220nMt5JGVNt/HY3Haqt8rX+mUneOOivBeawgumtDzTXp/jo
bRnpGkamtMgJulqUdzu8RG/BC1wLgOi91BzYn0+hZhO+3XTsjYNwZMfDCYRvFKT2xaTn2fFFEKdD
vxdHQWcTvkJZXoF2p0btj+///Pbj+79vELO6sJgrAmh+LwWcKGt9cl/wAvJxOOxF3ige2kMXbAnG
va59kUahnYZ+EIyG8cXIn3wDA2o3SDJO9N3FH3l7hwKDz+49yiLjTLCZPMtY6TQXKE7NHgivWaHv
UNzO9kVM37LQEkODH3aDbhgHYazCAvQGbc2/1hqG1EWITiXKP+L6egltF07g6gfyYaSHarjsaWZn
jxDFgbk8GvwHAAD//wMAUEsDBBQABgAIAAAAIQA4BPKI9wQAAHURAAAhAAAAcHB0L3NsaWRlTGF5
b3V0cy9zbGlkZUxheW91dDMueG1szFjbbuM2EH0v0H8Q1GfHulkXI84ivqhdIJsEdfYDGImOhaUu
pWiv3WKB/a32c/ZLeoaSbCebYt0kCPJiS+Rw5syZGXKo03ebXBhrLuusLEamfWKZBi+SMs2Ku5H5
8SbuhaZRK1akTJQFH5lbXpvvzn7+6bQa1iK9YNtypQzoKOohG5lLpaphv18nS56z+qSseIG5RSlz
pvAq7/qpZJ+hOxd9x7L8fs6ywmzXy2PWl4tFlvBpmaxyXqhGieSCKeCvl1lVd9qqY7RVktdQo1ff
h6S2FbytefIbZ6lpaEG5xpBtnsH3ZC5So2A5BuY8IeMGCXKpZ+vqRnJOcsX6V1nNq2upF12ur6WR
paSkXWz224lWTL8WEMND/8Hyu04TG24WMj87ZUOwYWxGJoK2pV8sYkO+UUbSDCb70WR59Yhsspw9
It3vDADBzijiXTUefe+O07lzkynBDXvnVSPKsPSiTD7VRlHCT3K/cS+5XHfKyGdSXy2NhnpFqlq5
ZlLz0cnXmtMO6I6JwHFc29V0eJ7lR9YDUoIgcDwMGkSN7fqOFQy0kU4TjDSqq6HajMt0S5Te4h+R
Y0WyLJGlilawoajVXG0F4ozntbCByGDiDmUkkAVsmPLF7xiq/xyZMAmbtzrwCQMDTIjWbLsS4b6v
EWSzISjBD5QIRvXIi97HOeoxVxPBGQy13qmziciST4YqDZ5myvjAasWloSlE9QIjaVfahlbJi/Sa
SUbwDjVTVNgQlsFC570mhCLz3+EH300p3FDuXQuW8GUpUAyGQ06iWro4PykTiH0TZYOc7hLnSQnh
RJYfIDl08LoquZ8QA8uyw6CNTFNkxyTEbaPzsYTImbzQBZoVKXYaeqSY3q4usZ1qJAdpgi2xma5L
kaVxJgTJ6t2UT4Q01kwg+za0BSGcWaGakQCwdSYgeDthHcoDPZhrLOmJXdbp1HUodRuk3iAACtB9
BFw7fEW4hJHcBnJ3DzeyUebHwvVfES5hbOF6e7i2G9iE4jh6yTOdAK+QDQSyxTs4wBs6IQX57eEl
kC1ef4/XcULQ+xbxEsgWb3CAN/Dc48vtNfOBQLZ4wz1eAnt8vb0mXgLZ4o0O8PqD4G3WG4FsduKD
LkKf+YQem9zucNduPb0HoINOtwD1vR7gKee8153zU6b4vXNeH6rPPedThdYGzdKSiUV33jfHGjXC
mi56mGvmmjZNdxddp9L1afpU7c5i/aJ5XaBjp977rzCI45nlRj0/mMx63vQ87kUDd9qLZrY3je0o
iCfTL2bbhqZwVWU5j7O7leRXK2VSlv04HACpTaszt+84uKfY7p5/QCEtL9uFDbroxGVJ3d9hH+ZR
g/Lc+CyUbAL0x4pJWOhi9IOmTFs+MkYvy4jfMTJHN8WNy1V++4AX3fs/lxfcg6H6UWp0/4sO8iXT
N4inztQbTHrheIb09b24dz6LnF547oXx2I1C37N26VuT5wXQ/d+s/fb171++ff3nBXJWN9DdfRi7
0UWNi0ilr6krmaEex+PIdybhuDe24Ys3jYLeeewPevHA9bzJODyfuLMvcKCyvWEiub6sv0/bjwYY
/O6in2eJLOtyoU6SMu83Xwz6VfmZy6pE00zFaB1+eRiZZtNIO2HkWjgyvG7bAVx9Gepgwxe6+eta
EvIDq67WenvGxw4UBFp0DFX4vIGcJ9G9CJHQfS45+xcAAP//AwBQSwMEFAAGAAgAAAAhAHAWmgfA
AwAAsgsAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWysVttu2zgQfS+w/0Bo
nxVZF9uSELuwJWtRIE2CdfoBDEVF2lKilqRdu0WB/lb3c/olO6SktLksYK/9IlvUzOHMmeHhXL7d
1QxtqZAVb2aWezGyEG0Iz6vmYWZ9uMvs0EJS4SbHjDd0Zu2ptN7Of3tz2caS5Vd4zzcKAUYjYzyz
SqXa2HEkKWmN5QVvaQPfCi5qrOBVPDi5wJ8Au2aONxpNnBpXjdX7i0P8eVFUhKacbGraqA5EUIYV
xC/LqpUDWnsIWiuoBBjj/TQktW8hW37/l4WMkdjCq2vNIW+yZjlqcA0Ld5ViFAE7KOGNAiRjINs7
Qak2bbZ/iHbd3grjd729FajKNU7vbzn9h97MvDZgBn+cZ+4PAxKOd4Wo55c4BjLQbmZBzfb6CU44
pjuFSLdIfq6S8uYVW1KuXrF2hg0ggsdNodxtl9HLdLwhnY4O9zGrzhSD6xUnHyVqOOSp0+/SI9fb
AUznrOHbEnXMK81sb9d9NHwM9hI4NWSp3ZLne534PfyaRRwzqdZqz6ghBMLGMYDDA+hnWDc2bewP
a2jsWiWMYmj8njw1T1hFPiLFEc0rhd5jqahAJhg4BgB5CewoKE4PSZv8Fgv85zNknR+OYWcIeogQ
/nYU/jeR/kBk303olmFCS85yCMI7jdYqh6YYmD8Do1AAxLbskboTGdZtawiWTxjuWDRUwmPY0qRx
RFHXlHA4o4xuKTsA3jB9BPxdWYnD0X1dxyPQM74Rqjw4+OBY+Kp4FR2U5Ky9HQy9nWJFnzS2IQRk
dVCD/6UXuYLj/Bk0H7PCApHVzW4OtZENLS4n6UcBkq+V+0s4zbLVyI/syTRZ2UG6yOxo7Kd2tHKD
NHOjaZakX61exHJIVVU1zaqHjaA3G309QOWficVLGerETQuN73geXHKu/7NtIRSNct7qjIfqZJxr
xftVeExHnVqfQomuQH9vsIAdhhqdUZHOy8hkYGTNqpyi6019/4yX8WmC3N1zMEQB9KvUGBk6c/tO
s9RLg3Fih8sVtO8kyOzFKvLscBGE2dKPwkkwemxfqTNvILpju/bHt++///j2zxl61lyawzQFd8SV
hMu3NUPORlRwHpfLaOIl4dJeupBLkEZTe5FNxnY29oMgWYaLxF99hQRaN4iJoGbSe5f3EycsvpgS
64oILnmhLgivnW7cdFr+iYqWV2bidEe/jq0zy0JbDPegGwah70Wua84LBA7hGtUZwoYlPTrq+AkT
73F7swVZwjFMynAgErPUwmysh4cnJpqEYdae/wsAAP//AwBQSwMEFAAGAAgAAAAhAJVbP8ViBQAA
3hIAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54bWzMWN1y4jYUvu9M30HjXjsg
/9sT2Ak/7nQmm2QK+wDCFsFd23JlQaCdndnXah9nn6RHskWAsAskuegNGPHp0/k/x7r+sC5ytKK8
zljZM/BV10C0TFialY8949M0NgMD1YKUKclZSXvGhtbGh/7PP11XUZ2nt2TDlgIBR1lHpGcshKii
TqdOFrQg9RWraAn/zRkviICf/LGTcvIE3EXesbpdr1OQrDTa/fyc/Ww+zxI6YsmyoKVoSDjNiQD5
60VW1ZqtOoet4rQGGrV7XySxqUBbNvtjujaQgvEVLGCjD5onkzxFJSlgYchKAQzoKRMLNCSVlENh
6mrKKZXocvUrrybVA1db71YPHGWppGopjE77RwtTP0uAwUPnYPujZiLRes6L/jWJwCJo3TPAcRv5
CZtIRNcCJc1i8ryaLO6PYJPF+Ai6ow8ACbaHgs+rRqOX6lhanWkmcorwVqsGSmDrLUs+16hkoKdU
v1EvuVtpMqmzpK8WqDG/kFQtrvlT2UPja2VTLejWEo7rQ2wpc1i+3XUPbGJ3u4GNbQNJy2DsWS1i
V+OGuYrEesDSjbToDL7BcaRMFgwCddbYOa/FRGxycDOJ8lWOQSBE8kfIpByCgEQpnf8OS/VfPQNE
AplmWvEtHnwMzzs8YGESgR3gA7bmRCYiLc1PE0jEQgxzSoC+1Un0h3mWfEaCIZpmAn0ktaAcKbtB
2oJkkl2oMxQlLdMHwokUapdZuoJEcDLYV+sMj423v+9zMOJ+FjzkJKELlqcghPW2CMhSiF8dJOc7
33Z9VzpUJsMx77sYY0A03ncD18YQCo36TUIptZs41JbQ3lepteuq1uUHnrZl9DWUOwB4tNp43Y2K
YBerAYC1j2CdXawGANY5gpXRtpVBAwDrnsJqAGC9U1gNAKx/CqsBgA1OYTUAsOEpbAM4lkOwEwHD
NlnemFOypqqUqvdyqskblTzwoY9UgXtBGk9owsoU5XRF8zPoVW5dQD9dZPx8dpUQF7DHbMmh+50r
vCMD8xL6bH6UHdrcu1YzR1ezqXT1bilTBoG2r1vVq5qZ7CBQwqEVLEg+N2AGgAKnHKmamiw56mGi
Il4WX7n0o+6GHdvFTZ4/t/y99uZ4Ie56by5wqCD8Vo0YWZnCtCMfpWiz5R0MhcqbOzUN79Up2RMl
FjJRlreWSvfos/j26ulBjWz5QuzIU9FZfHu18aCOtnzY9rF3LmH4g1qr+QIrkKX+LAH3+A7qcctn
WQGI9xq+g5qt+XxHta3L5Tuo6y2fJDvbIXv6HtR+zee5/uv88f/oD5DZeppQA4Ycc78/V7m6Eo2I
oHuVSNXOt1aiVLyoQ7iZFuTbxtFCBDn+rMHReUhVATW7zuHlSL7g/B34cTzu2qHp+cOx6YxuYjN0
7ZEZjrEzinHox8PRF6Od9VNQVWQFjbPHJaf3S6EqzOkRGGqKOlr07Y5lwQshtp8bKIgia8/79glP
eydmTE7bu53Clb3trf6ZC9446M8l4XBC2yvwiWn4Eh+9r0V8bZFJnqUU3S2L2YFdvPewC1w4APVR
05zoo5eYZhu+fjyyRo47NIPBGMLXc2LzZhxaZnDjBPHADgPP6W7Dt5aalyCdjLdLovbb139++fb1
33eIWVVY9KUDjDC3Nbz4VeouYMkzyMfBIPSsYTAwBxh0cUahb97EnmvGru04w0FwM7THX0CBCjtR
wqm6FfktbW9nYPHFjUqRJZzVbC6uElZ0mquZTsWeKK9Ypm5ncHf3iqdnGGhFYCK3PLeLXSvsqnwB
wUFcNf5osWFJXrKoXMr5R1Ldr9QUAbdKkBBDtVTBPRI4VkKfIdII+l6q/x8AAAD//wMAUEsDBBQA
BgAIAAAAIQCH9Z3HGAMAAIMHAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcueG1s
rFVtbptAEP1fqXdA298E82EbkO3IgKkqpYlVJwfYwGKjwO52d+3arSLlWu1xcpIOCyRpkkqp6j82
DDOz896bnZmc7uvK2BEhS0anyD4ZIIPQjOUlXU/R1WVq+siQCtMcV4ySKToQiU5n799NeCir/Awf
2FYZkIPKEE/RRikeWpbMNqTG8oRxQuFbwUSNFbyKtZUL/A1y15XlDAYjq8YlRV28eEs8K4oyIwnL
tjWhqk0iSIUV1C83JZd9Nv6WbFwQCWl09J8lqQMHtNcVpjfI0G5iBwYbzQB5tqpyg+IaDJH2aIyS
XwpCmie6+yj4ii+F9j3fLYVR5k1sF4Os7kPnpl8puMGD9Sx83WfC4b4Q9WyCQ6DA2E8RKHVofiEI
h2SvjKw1Zo/WbHPxim+2WbzibfUHQAUPhzaoWkQv4Tg9nAQrYiwrnJENq3IiDPsBYBuFIcsZy26k
QRlAbphokWbnuz5vA785iW+MlvpcQeN9BxFxVSDgD8DZGqxmqHHWD328BLo1j2ofsfzQcHIN/9qI
w0qqlTpURHMFiHBYgIKNKD/8cZouBm5gjsbxwvSSeWoGQzcxg4XtJakdjNM4uUV9UQBVlTVJy/VW
kIutgnbAoQCBoQ3gwhBqXq2g7lrFFcFwoTp52uJwqGau5TjQtbY7AcIVgNClaAlpvsQCf3mWrGEK
h1AzwO2xwWOry9/VcXt1UsYUaPJUH+cY+hRKtAJ93WIBJ/Qa9dq2gv6XRuSojHg9I6uqzIlxvq2v
n/HiHoMXmIqQ+lVqNO+akeO17zhNnMQbxqYfLaB9R15qzheBY/pzz08jN/BH3uChfWWDnEJ1/9q1
93c/P9zf/TpCz+rW7QclTK0zCZeA6/m1FSXcxygKRk7sR2ZkAxYvCcbmPB0NzXToel4c+fPYXdwC
AG57YSaIHt2f8m6FgPHF2K/LTDDJCnWSsdpq94fF2TciOCv1CrEHT/fQFCFjh6spcseDwB2Nxm7Q
jSsoV1/DvmzA0myCpv6sEp8xv9jBWMIhrD64ELE2cVh23bB7dGlI6Jfn7DcAAAD//wMAUEsDBBQA
BgAIAAAAIQD+I2hr1gMAAOgLAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEwLnht
bKxWUY/aOBB+P+n+g5V7zoZAgCRaqCAhp5O2u6uD3rvrmMWqE+dsk0JPlfq37n5Of8mNHbzd3VIJ
urwE4ow/z3wz83mu3+wqjloqFRP1xAuveh6iNRElqx8m3rtV4cceUhrXJeaiphNvT5X3ZvrrL9dN
qnh5g/diqxFg1CrFE2+jdZMGgSIbWmF1JRpaw7e1kBXW8CofglLij4Bd8aDf642CCrPaO+yXp+wX
6zUjNBdkW9FadyCScqzBf7VhjXJozSlojaQKYOzu5y7pfQPRAjF6tfOQtZMtrITeFEInS16iGlew
sGKaUwQEob/AmBHM0YrutDVTzUpSajbU7e+yWTb30u6+be8lYqVBO6B4weHDwcy+1mAGf4IX2x8c
Ek53a1lNr3EKrKDdxIPk7c0TNuEUnECkWyTfVsnm7ogt2SyOWAfuAPDg8VDIe9NF9H04fRdOR0r4
GFVnimHrjSAfFKoFxGnC78Ijt60DMzEb+GaDuhRow+/Brvto+XD2Cji1ZOndXJR7E/h7+LWLOOVK
L/WeU0sIuI1TAIcH0M+xqXBa+++WUOGVzjjF0AEH8vQ044x8QFogWjKN3mKlqUTWGegHgLwGdjQk
5wBJ6/IeS/znC2QTH07hZHDaeQh/Owp/TOTAEfmsptA9x4RuBC/Blf4lyDVUeUhIBk3QVbsHdQlF
4zJzDuNGRgCFYuO08e4Y/5AuxFv+SPQr82GK3KZDPctHx7klHh7uSBvUGSWwpERAX3PaUn4CvM3I
GfCrDZOnow86Rk/mqxBbqTcnOx+dC8/WR9FBdy7aCZHrhBxr+qwBLCEgxU47fkpdSg3N/wmuCszX
rvStBFiRMVL0KrVZwzVhdP6feFwUi94g8UfjbOFH+azwk+Eg95NFGOVFmIyLLP/sHSSvhFA1q2jB
HraS3m3NZXKKaHVSaGRpEPT7cDeGg29lC64YlMtmZ+iyUwhh9PGpQNmKem1+1lp2Cfp7iyWc4HL0
M/r0A0W6LCMjx8iSs5Ki2231/gUvw0sIN8xeAH2UGitDFy7fcZH382iY+fF8AeU7igp/tkj6fjyL
4mI+SOJR1HssX2Uir8G7c6v265d/f/v65b8L1Ky9Yt3sBXfEjYKrurEj0VYy6Mf5PBn1s3juz0OI
JcqTsT8rRkO/GA6iKJvHs2yw+AwBNGGUEkntgPhHeRhUYfG74bJiRAol1vqKiCroptSgER+pbASz
g2rYezrtTjwPtRjuwVESxuNRLx6bsgC/wVv3a72GJTNtGvcJl29xc9eCKuEU5mvoh8wuNTBRd7uf
mBgO3IQ+/R8AAP//AwBQSwMEFAAGAAgAAAAhAPuvLPAeBQAATRIAACEAAABwcHQvc2xpZGVMYXlv
dXRzL3NsaWRlTGF5b3V0OS54bWysWNtu4zYQfS/QfyDUZ8XW/YLYi/iiokA2CersBzASHQurWyna
G2+xwP5W+zn7JZ2hRNtKnMbx6iWx6eHhXM8MefnhKc/IhvE6LYuRZlwMNcKKuEzS4nGkfbqPdF8j
taBFQrOyYCNty2rtw/jXXy6rsM6Sa7ot14IARlGHdKSthKjCwaCOVyyn9UVZsQJ+W5Y8pwK+8sdB
wukXwM6zgTkcuoOcpoXW7uen7C+XyzRmszJe56wQDQhnGRWgf71Kq1qhVaegVZzVACN3d1US2wqs
rdL4/kkjUoxvYMHQxmB5vMgSUtAcFu7SWKw5I19SsSJTWqEeUqau7jljKF1sfufVorrjcuvN5o6T
NEGoFkIbtD+0YvJrAWLwYfBs+6NCouHTkufjSxqCR8jTSIPAbfEvbKIhexIkbhbj/Wq8uj0iG6/m
R6QH6gDQYHcoxLxqLHppjqnMuU9Fxoixs6oRpbD1uow/16QowU40vzEvvtkoMLQZ4asVadwvEKqV
a36U/lDytfSpUnTnCcMLTNOHvAXLbR+ybPjMK47tuzYsEvSN47qe5ctDFBIc0kBXoXialMkWXfoA
/yFytIhXJWTqA+6gYVaLhdhmEGf4vMkM0IjQ7BFKKYMsoGHCln/CUv11pEG+w5EPyvKdPAS5iwMu
piE4Av7A1oxiJbJC/7SASszFNGMU4FuTxHiapfFnIkrCklSQj7QWjBPpOKhb0AzRhTxDQrIiuaOc
olKHyBgLGsLJYLuyWboB4/F60C0VdFUGdxmN2arMElDCRBdBsagAn5UCUIEalAvkskqY8xLBNUzP
c5qgqero5IFtGJgspybCq9HPKb+W1ZgWCVALfsRQPqxvgD/lroOcsCAp2hPb7EFZ+GhiIjVQtuOh
FDkFz9xb0IK0eNYeLzBsmfwn4aFkkxuAhyAtnr3HMyzPwBI7TUEsgh0gorSAzgGgD9V7HiCitIDu
HhDYABQ8S0NEaQG9A0DPlpE7w2REaQH9PSCinR6Ujg8RpQUMDgBdxzszKIhynJP65Q5bccc91uMh
cViYIT9LHMjXQJhAvCuaLVsOkZQke4i0EZvrQpqrGF+1gKPNxLGgVTS9Yt9iOyTiD6G1NIcopP9p
JpINjnWQd3GI0alR7EBtOpzJIUaHkxCkxTuTQ4xOuvbAIUHPFNLB64FBOng9EEgHrwf+6OD1QB8d
vNfZAxKJQBPZjS4yrc6fcJA05IBTdyacc6YYRzHRjArWYSK7DyZKxAseMpomiPxzlIgk/6k5TM2e
HbqQX+SkuIS7CN4n/va9KJoPrUB3velct2dXkR441kwP5oY9i4zAi6azb1o7WidgqkhzFqWPcH25
XQsNq/ztcEAU5dFibA1ME+5fhrX3P6iCKP32CVdFJypLnG0PO4Uc6H62UywFbwL015pyOEHNm28M
nO+JUb8e8ZRHFlmaMHKzzh+e+cXtI2/hfg/QR13zRh99j2t26etFM3NmO1Pdn8whfV070q/mgan7
V7YfTawA72y79K3R8gK0e2/W/vj+z28/vv/bQ87Kxq7u+MBG1zVcsyp59V7zFOpxMglcc+pP9IkB
ttizwNOvItfRI8ey7enEv5pa829gQGXYYcyZfIT4I2kfQ2DxxQNGnsa8rMuluIjLfNC8hAyq8gvj
VZnKxxBjePiiMtI0sqHAuJYZDC3DcQJZL6A4qCuvekptWMI3DTl1ZfwjrW43kp7hEQcKYiqXKni2
gcCi6F4EnaCegcb/AQAA//8DAFBLAwQUAAYACAAAACEARfArzSMEAADJDAAAIgAAAHBwdC9zbGlk
ZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWy0V9tu4zYQfS/QfyDUZ0XW/YLYC99UFMgmQe3tO1ei
Y2IpUaVor73FAvtb7efsl3RIiU7iuKjdpC+yJQ0PZ86ZGY6u3+0qhrZEtJTXQ8u9GliI1AUvaf0w
tD4sczuxUCtxXWLGazK09qS13o1+/OG6yVpW3uA930gEGHWb4aG1lrLJHKct1qTC7RVvSA3vVlxU
WMKteHBKgT8DdsUcbzCInArT2urXi3PW89WKFmTGi01FatmBCMKwBP/bNW1ag9acg9YI0gKMXv3c
JblvIFogRi6pZGRcl8udhbS92MIb1xoBBcWClajGFTz4DUxpgRnS9ggYQ0uyk9qsbZaCELWg3v4s
mkVzL/Tq2+29QLRUaD2K5fQvejN9W4MZ/HGOlj8YJJztVqIaXeMM2EG7oQUi7tUVFuEMnEBF97B4
fFqs707YFuv5CWvHbAAeHDYF/ZsuopfheCacI1LcQ3jdGgwYN7z41KKaQ8CKhy7O4nZrUFXwap9m
jTpNpNLDQlxQUK6TqF/VmWqazOpWU238PxAURV4aDDqavDiI/OQ5V94gjPV7xViYhG7ohXoTgwSb
dNBNJncTXu4V0x/hFwRVSTO0CFbBd7CslQu5Z0TrAazhDEKCCxgzrAqN1PaHBRRaJaeMYCjEXjs5
mjJafEKSI1JSid7jVhKBNAVQlgB5DeJIyI0ektTlPRb41yNkxSrOYGfw2/irQ1DM/rOO/ksdVTbd
M1yQNWcluOKpCKEQjGD/SVJF3JGiUBaQsyYfzlc2CGNoLDr/TwkbDdw0Ue//L2Eh3xDbsoOCrxRa
0a11bp8J3YmpFYWL2VKzdUFuLUjBoU0xsiXsDHgt9QXwyzUV56P7XamczVfON0Kuz3Y+uBSerk6i
Qz990xILTInNsCTPKksT8trKKiV0lS9wFGK2svqa0r1Fd0nVWfWfp+1S17NpEqap6c71so2t4PhT
59cfSZzn84Gf2lE8ndvBbJzbaejP7HTuBrPcTeN8Ovtq9R28hFAlrUhOHzaC3G3UIXlON4RE137I
ke94Hpz9rv+YtuCKQnlbdUKjTs65arxPO5/OqNfqs5KiE+j3DRawg9HoXxrfJRq9LSORYWTBaEnQ
7ab6eMSLPihfywvMlgB9khrdht44feN85s2CcGonkzmkbxTk9nieenYyDpJ84qdJFAwO6duqyGvw
7tKs/f7tz5++f/vrDXJWn91mpoQz4qaFGaDRo95GUKjHySSNvGkysScuxBLM0tge51Fo56EfBNNJ
Mp76868QQOMGWSGIHoB/KftBHB6+GJ4rWgje8pW8KnjldFO40/DPRDSc6kHcHTyd5oeWhbYYzkEf
zuMojv3EtB1wV3cd4zbEosZoPUUw8R43d1toSziDDwgoiKl+1MAnA+S8Mn00USSYT5DR3wAAAP//
AwBQSwMEFAAGAAgAAAAhALl/7nOWBgAAsBsAABQAAABwcHQvdGhlbWUvdGhlbWUxLnhtbOxZT2/b
NhS/D9h3IHRvYyd2Ggd1itixm61NG8Ruhx5piZZYU6JA0kl9G9rjgAHDumGXAbvtMGwr0AK7dJ8m
W4etA/oV9khKshjLSNIG27DFh0Qif3z/3+Mjdf3Go5ihQyIk5Unbq1+teYgkPg9oEra9e8P+lQ0P
SYWTADOekLY3I9K7sfX+e9fxpopITBCsT+QmbnuRUunmyor0YRjLqzwlCcyNuYixglcRrgQCHwHd
mK2s1mrrKzGmiYcSHAPZu+Mx9QkaapLeVk68x+A1UVIP+EwMNGnirDDYYFLXCDmTXSbQIWZtD/gE
/GhIHikPMSwVTLS9mvl5K1vXV/BmtoipJWtL6/rml63LFgSTVcNThKOCab3faF3bKegbAFOLuF6v
1+3VC3oGgH0fNLWylGk2+hv1Tk6zBLKPi7S7tWat4eJL9NcWZG51Op1mK5PFEjUg+9hYwG/U1hvb
qw7egCy+uYBvdLa73XUHb0AWv76A719rrTdcvAFFjCaTBbR2aL+fUS8gY852K+EbAN+oZfA5CqKh
iC7NYswTtSzWYvyQiz4ANJBhRROkZikZYx+iuIsZHQmqGeBNgkszdsiXC0OaF5K+oKlqex+mGDJi
Tu/Ny+/fvHyO3rx8dvz4xfHjn46fPDl+/KOl5SzcxUlYXvj628/+/Ppj9Mfzb14//aIaL8v4X3/4
5JefP68GQgbNJXr15bPfXjx79dWnv3/3tAK+LfCoDB/SmEh0hxyhAx6DbsYwruRkJM63YhhhWl6x
nYQSJ1hzqaDfU5GDvjPDDFfgOsS14H0BFaQKeHP60BF4EImpylzuaHYrih3gHuesw0WlFW5pXiUz
D6dJWM1cTMu4A4wPq3h3ceL4tzdNoXTSKpLdiDhi7jOcKByShCik5/iEkAp7PaDUsese9QWXfKzQ
A4o6mFaaZEhHTjTNF+3SGPwyqxIQ/O3YZu8+6nBWpfUOOXSRkBWYVQg/JMwx4008VTiuIjnEMSsb
/DZWUZWQg5nwy7ieVODpkDCOegGRsmrNXQH6lpx+C6pHtdv32Cx2kULRSRXN25jzMnKHT7oRjtMq
7IAmURn7gZxAiGK0z1UVfI+7GaLfwQ84Weru+5Q47j69GtyjoSPSPED0zFRU+PIm4U78DmZsjIkp
NVDXnXId0+Sydp+5dm8LWpk8uycq9jLcyTrd5SKg//4yvYOnyT6BzFjcqy6r9GWV9v7zVXpZPl98
bZ6XY6jUuneyTbdpweOlHfiYMjZQM0ZuS9OES9iEgj4M6nXm9EmKE1kawaPOZGDg4EKBzRokuPqI
qmgQ4RQa+LqniYQyIx1KlHIJB0czXElb4+EQoOyxs6kPJLZySKz2eGCH1/Rwfu4oyBipQnO4zRmt
aQJnZbZ2LSMKur0Ns7oW6szc6kY0UxQdboXK2sTmgA4mL1SDwcKa0N0g6InAyutw/tes4eCDGQm0
3a2PcrcYL1yki2SEA5L5SOu96KO6cVIeKwuKaD1sMOhD5ClWK3FrabLvwO0sTiqzayxhl3vvXbyU
R/DcS0DtZDqypJycLEFHba/VXG16yMdp2xvDmRke4xS8LnVDiVkIF0++EjbsT01mk+Vzb7Zyxdwk
qMM1iLX7gsJOHUiFVDtYRjY0zFQWAizRnKz8q00w60UpUFGNzibF2gYEwz8mBdjRdS0Zj4mvys4u
jWjb2deslPKpImIQBUdoxKbiAIP7daiCPgGVcPVhKoJ+gXs6bW0z5RbnLOnKt2MGZ8cxSyOclVud
onkmW7gpSIUM5q0kHuhWKbtR7vyqmJS/IFXKYfw/U0XvJ3ANsRZoD/hwTSww0pnS9rhQEYcqlEbU
7wtoHEztgGiBu16YhqCCy2rzX5BD/d/mnKVh0hpOk+qAhkhQ2I9UJAjZh7Jkou8UYvVs77IkWUbI
RFRJXJlasUfkkLChroHrem/3UAShbqpJVgYM7mT8ue9ZBo1C3eSU882pZMXea3Pg7+58bDKDUm4d
Ng1Nbv9CxKI9mO+qdr1Znu+9ZUX0xLzNauRZAcxKW0ErS/u3FOGcW62tWAsarzZz4cCLixrDYNEQ
pXCZhPQf2P+o8Jn98qE31CE/gNqK4EOGJgZhA1F9xTYeSBdIOziCxskO2mDSpKxps9ZJWy3frC+4
0y34njC2luws/j6nsYvmzGXn5OJFGjuzsGNrO7bU1ODZkykKQ+P8IGMcYz6Zlb9q8dFDcPQOfD+Y
MiVNMME3K4Ghhx6YPIDktxzN0q2/AAAA//8DAFBLAwQKAAAAAAAAACEA5JRimAAYAAAAGAAAFwAA
AGRvY1Byb3BzL3RodW1ibmFpbC5qcGVn/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/
2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQH/wAARCADAAQADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQF
BgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS
0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4
eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi
4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl
8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImK
kpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP0
9fb3+Pn6/9oADAMBAAIRAxEAPwD+/iiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKK/Pv8AYU/brH7Yll8YbTxR8MbX4KeNfhV4uuRb+Ev+FhQfEFfFXwb1bxB4z8L/
AA6+M8Gqr4T8FvpGn+NPEPw0+Jvhy78N3elXE/h3xH8P/EViNZ1qwWw1e+z9rTVWVCU4wqRweIx7
5/3cPquExGBw1eSqz5aTqwq5jhpLDKbxNSh9ZxVOjPDYLG1sPlOtSp1KNGdSEauIlKNGk5L2lRxV
5OMF7zhFuEJVLckalWjSlJVK9GM/0Eor87P2O/8AgoHoX7UPh79qnx74t8G6B8D/AIX/ALOfxJl0
vRPiN4h+J1nqvhvx98CtS+E3gz43+Cf2g9dv9X8KeCNO+GWgeKfhn430rxbcaJqWpeIrPw9obpqF
94tnjeZLX6l+Hf7TH7OHxf8Ah9L8W/hN+0D8Efih8KoNdj8LTfE34d/FbwJ42+H0Piaa/wBN0uHw
5L4z8Na9qfhyPXZdT1nSNOj0h9SGoSX+q6bZrbm4vrWOV88PZzquSjTp4ajjK0pPk9hhq6i6VbEK
Vnh4yclB+3VNwq3ozUasZQXXicPXwlSFPFUqlCdWrKhRVWLh7etGjHEunQbtGvL6tOniY+yc+bD1
KdeN6U4zft1FfMmr/tsfsaeH/hHpfx/179rf9mTRPgPrnia78FaJ8bNX+PXwr034R6x4ysLnV7K+
8JaX8SL3xXD4N1DxNZ3nh/X7S70G01mbVbe50PV4JrRJdNvUg8v8fftyfCP4R/Gq60z4v/Gb4A/C
v9nKT9nfwB8XNF+M3xF+InhnwP4a1TxD4++IPiXwxolna/ETxP4t03wLfaHr2iaRZX/hy3tIzfap
cTTXVpqV5aSRW8WNXF0KNbA0Kk1GWY4ueBw83b2X1mOTZjn0KVWq2o054nLssxNTCxk+bETdGFJS
9rFk1aVSjGu6sJ05YelGtOjOLjXlS/tfB5FVqU6Mkpzhhcyx1HD4uUVy4aSqqq4ypyifddFee/EP
xT4u0X4far4l+FXge3+Lni+W003/AIQzwmnjHRfBmh6/e63fWNjY6lrfjjUodTttB8FaTFfjxH4r
13RtD8ZeJbbwnp2q3PgrwL4/8Vf2J4O135T+G37UHx+8Wab+0J4D8TfszeErH9qP4Dap8PrAfC34
fftBx+NPg/400z4uaRZap4D8ZWHx18b/AAj+EHiXRvCWlA+Iv+FpR6h8C5fHHhiz8FeIp/h/4G+L
d7e+DNM8W9EmoScJtU5qTgoVGqc5zTinTpxnyurUipOcqdJTnGlSxFaUVSw2InSUYqbwKVbCx/tH
FSweE9pi8LSU60aKxDdR1K0FhqDot1I4rEujhZxp1+WtL2Fb2f3dRXxp8B/2ovE/irU/jX4E/aV8
B/Dv9n34o/AjxD8OdN8WQ+FfjXL8V/hBrWh/GDSLO/8AhprvhH4p+L/hj8B9eubvW9Xk1LwZqHhz
xP8AC7wnqtl4u0o2ekf8JHpOsaBrWqes+Df2nv2aviN4Q+I3xB+Hv7Q3wN8d+Afg9f8AiLSvi343
8G/FrwD4o8IfC3U/CGmDWvFum/EbxLomv32i+CL/AML6ORq3iKz8TXumXGiaYRf6lHbWp82s/rGH
5pRWIw8pU6DxFSMK9KbpUYyjCpUqqM26So1Jxo4hVOWWHxF8PXVOvGVNRQvilF4ZSr+0xM8FT9nG
U3UxcKlWlLDU0k3Ot7SjViqcU5SdObimk2e5UV8IfAv9tPwf+0Z+1F49+HXwV+IfwX+Mn7P2ifsy
fB74x+Efit8IvFul/EOz17xn40+Mv7RXww8aaOnjrwn4q1zwVqmi6Avwd0i1h0/TLGLVdK8Qv4ig
1bVLoNa6fpf0p8Z/FHxh8LeFLab4F/Cbw98YPiFqutWmk2GieNvijF8HPh5oVk1pf6hqHibx94+t
PBfxR8W6VoMEOnf2PYw+AvhJ8T/E194q1rw5aXPhzS/Ckvibxr4UuE1Uo0sQlJU60sVCF4yUm8Jm
GKy2q3G11F4nB1nCXwypclW6jLTqq4OrRxk8DOVFV6eHwGJk3XowpKnmOT4LPcOvbVZ06ftHgcfh
+am5KaxLlhoqdZKMvW6K/NW1/b58X3Xw00GxHwL0GL9rXxP+014z/Y+0P4CSfGSb/hV2ofGvwH4d
8S/EXxFq0X7QKfCxtaX4OWnwb8J6x8WD4zk+BaePTocK+HP+FRjxww8M1oaL+3N8TLb4V/Hq88af
sifEfVP2mf2evifofwj8Rfs6/ALxPZfFvR/HviDx1oPhTxh8OfGPwx+M3jvw78CtFPwc1fwj410z
UfGXxN+LfhP4QWPw91Xw38RND1TTNQk8NaLeeLsauKoUcKsbUqcuFqYPCY/CV1GcqeZ4PH0sDWwO
IyZwjJ53TxdPMsFLDf2Qsa63tmqalKlWVPnoReImqdJwb9tiKFSdScKNHDVMJjsxy3GPG160qdHA
UsHmGU5jg8ZXxtShRwmIwlSniKlKXKpfo1RXxb8L/wBpL4x/Hj9jL4CftKfBr4CeFNU+J/x6+GHw
w+I1l8IvH3xul8E+AvAv/Ce+GbHxTq9l4w+M2jfCnx34in0rwzbT3GkWmreEPgh4o1bxDr0mjxv4
W0TQ73V9f8Pdb+yN+0Rrv7SXw58VeJPF3w70/wCGXjb4d/F/4pfBDxzoHhrx9a/Ff4f3XjD4T+J7
nwxr2rfDT4nQeG/BN1438GXN5A9rDqOueA/AXijSdestf8KeKfBugeIPD2o2a9+Iw1bC47H5ZXUK
eOyx4pYzDe2oynCOCxeEwOLq0XCpKGLw+HxmOweHq4nCSr4eNXE0YureaIqN0aWFrVYzpwxmJjg6
PPTnGccXPDY3GQwuJpOKq4LETwuW46tGjjIUKko4WqlFyjZ/UtFFFYDCiiigAooooAKKKKACiiig
AooooAKKKKACiiigAr8Ab/8AYc/az0T4W/s32Pwu8JaT4Z8d/EWD48fsi/tlXEnjvwv4b1zwd+yL
8avjN8QPirbfGLw34r0R/EDeJviN8JrVtQ0/4TeFdJk1C4stX+P3ia7uP+EeNrruq6X+/wBRXPPC
0KmLwmMqw9rLCwxVH2Mm1RxGFx9OGHzHCV+TkrKjj8B9Yy3EuhWoV/qeNxSoVqNeVKvRzVPlxCxU
KlanWhhK+GpunVlT9lUni8vzHCY6Dg4y+u5VmmU5dmmWzlKVGjj8HQrVqFeMFA/HrxP+zl+0j8Of
DX/BSA/AP4b6Npt18SvjR+zN4i/Z602wg+DGt6pe/C34Xfs9fss/DfxnqXwg8L/E7U2+EegfGHwS
vw18c2nwDsfj7a6J8MrX4reGPBGteNbOb4cNLe3fjvh/9jj9pDxz8AP24dD+LHgv4o/EbW/2pviD
+zP4jsdD/akv/wBiO4+Lni/wh4JHww8O+P8Aw98Z9L/ZM8H/AA//AGaEuNG0Dwdq+mQaXYXvxCGv
+BYPD9rc+O9c1G7fwX4V/eeis8RgqWLw9WhiJVqk6sIx+tTqyliabjQjh5VKc5XpqrVjHnrVHSlK
pUbk3ZRjHvq4ypP6iqUKWDp4DDYbC0aODi8PSlRwWCwOAwkKsYyblDD0cBSlSpRcaMK051I0k40P
Y/nv+1D4P+LHg/8AaK/Zi/ab+GnwO8bftK+GfhD4E+PPwp1z4IfC/wAQfBTwv448Paj8YE+F+oeG
/jP4O/4X58Tfgx8NbyXwnY/C7XvhnrVi/wARtE8RQeGvizfXOgWGs2kGtWDavgf4HazfftX6L8eP
EXwP8LeBtJi/Yn0D4SaVCs3gTWrz4e+I9d+Jur+L/G/wp0y60Zhcw6e2nReF28R3OgWaeCNevNH0
9LfUtW/suzkj+86KrEYWOKll861So5ZXUzieDcVRpyjTz3KOIsnzGhWqQoxq4qnUpcT5niYTxU62
Ip144ShGv/ZmGhl75pTk6VWjBqjTrUcDSqxpRjBSeW5rlWbYSstG4VadXKMNhn7NwpzwtTEc9N4q
VPFUvzK+Cml/tV/sm/8ABKj4LeE/Bf7Osvxk/a1+Cv7MXw08B6H+ztbfEP4XeELPUfH/AId8PaL4
Ut/D178QtX8XaV8NrDw34VjiF7qt5p3imSO70PRriy8NyX2p3Gnwy+U/AbWf2r/gd+y1+0b4t8K/
sH/tI/EL9tPXbxPiprsvx88d/sJ/DZv2sPjt4yitPDMknh+9+DP7X/xr8LfC74V/CDw3ofhrw34c
8H+OfFWlan4c+D/hjwr4W0LxL8T/AB3H4g8Saj+xdFdNfnxVXM8RiKtatis1oSoYjGTrVPrlOFTE
fWsRLD4tSWIpVMXiFCtjJ+0k8VWoYOvW56+X4Cphuqti1Xr068sJhIxp5jVzJ4anTqQwtSpV0jQn
RVWyw2HpSxGHw8KTp1aVDGYqHtpOpGUPwx8L/s+/F/4rfsXftE/Bv4i/sm/He0+Nnxq8e/DH4jfH
jxt+07cfsTxad+1B4q1f4ieB2+IFvoXhT4B/tUftE+HfC3wz+HPww8EWHgHwh8NviFqtr/ZHwr0f
wf4Rg8Q/FLxSninxFqfon7Xv7Jvxw+I/xl/aS8Z/Df4d6Rr/AIN1/wDZz/YG/sTw3Nrvg/QLH45e
Lf2TP2vPjV8dfG37P+oC81exn0qLxp8Nda0rwHpuseN7ax+Gu74giy1LVDpVl4nXTf2KoqYxlRzC
lmOEqTwM6McDGnhMLGjHLUstwmIwuAhLLalKrg6mGwkq1LFUMvqUZZbTxGBwEY4P6ph3hZzhcXPD
YfHYd06OKjmCgq08ZSjXqRks6yrPcRUpyfLFVcdi8ppUcbUnGcq2FxOMpJwnUpVaH4tQeIfjr8Mf
2if2lP28tT/Ym1z4eXHxc/Z5/ZQ+APw2+DXif4ifBh/jr8WvjN4Z+PPxp0OPS/iLefArW/jd4F8N
s2i/FLwjd+H/ABNaeP8A4laJpXw40xtX8aax4Ci0LxFonhf7j/bf+IP7Vfw/+Bdzdfsc/AvVfjf8
a/EviLQfCVrbaZrXwisz8LfDetyTJ4o+MEnh/wCM3xd+BnhP4k3fgPTIpLvw/wDDIfEzwi/jfxPc
aLpGpeJPDXh2XWvEOl/YVFc1PBQp4Kngfa4j2NPF4qtaE6dDnwuNzbEZ1i8JKdClTxFN4rE4/MMJ
XxeFr4fE08uqYSOAngczwtTNsXM8TUqY+pmFXlq1qmFwWGdKpTovDU5ZblGEyTA4inRp0qblVw+E
wGDqyhip4nD4nF0pVMXRr0a9bDz/ABF0r4DfEjQfhF+xz8R/hn+x7+0xo3jf9iH9p/xb8Vtf+Dnx
r+IX7G0n7Rn7USfGf4P/ABc+GHxt+MEHjT4X/tHeKP2dLr4j+KPFPx/134uatD45+Jnwlttc17wp
4l0LTdM8J6PqPhOC8+l/hwn7QHgfRP2rf2mvFH7MXxP1zxv+0B488EXfgb9lPwN4p/Z1l+NvhPwF
4S+HPhL4X2DePvFfi39oPw1+zlN4yn1Ww8T+N9fs/Cnxz1bQtM8HT6FpGial4m8WQahZXH6R0V1Y
+EcyiqeKjD2dOjUw+DpUaVHD0cvo16eHpV6WCpUacKdKnVVLFctOcakMLHMsbRwUcNhoYChgcKcp
0qmGqQm1LD0/ZTco06ksXCOJxuMpfWqtSE69SrSxOOqVfrEKtLEV3TpQxdXEU1UhV/GT9n/wt8Ud
M/4JlfA39nj9pL/gl78Q/jJN8L/Anwi+CXxZ/Zj+IviL9g/x/L8RrHwL4K0Rm+JPgPSfEf7SXiP4
AeM/COlePNK0oQaT8Vvib8KvGltBp9/4n0vwxeahpWhaT4g+oP8Agn18HfiF8IPAfxah8T+Btf8A
gf8ADnxv8ZtS8Yfs9/st+I/F/hfxlefst/BxfA3gPwtZfCaxm8AeJPGvwz8HaDceMfDPjDx94d+F
Pwp8a+LPhh8K9E8aWPgnwRq0Wj6TFpGl/fdFdtXG16+OzjMavs5YjO1WWL/dQUIe3xmX4+rLDxUV
KE3isvhONWcqlWnTxOLw1KcMLWVGFYmrWxTpe1rT5KeLq450lGk6dTE1YYuk6jVSnN0ZRpYyVJSw
ssPKdOlSjWlVTre2KKKK5CAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigD/2QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAUEsDBBQABgAIAAAAIQDSD1WHtQEAAHYDAAARAAAAcHB0L3ZpZXdQcm9wcy54
bWyMU8tu2zAQvBfoPxC8J3q4kV3BcoCi6CmHAHZ6Z0haJsAXuLQj++u7pKzYbnLIjfuanZmVlo+D
0eQgAyhnO1rdl5RIy51Qtu/oy+bP3YISiMwKpp2VHT1KoI+r79+Wvj0o+fYcCAJYaFlHdzH6tiiA
76RhcO+8tFjbumBYxDD0hQjsDYGNLuqybArDlKXn+fCVebfdKi5/O7430sYRJEjNIpKHnfIwofmv
oPkgAWHy9C0lzSD+RXUdBS02u715tUzplKErFG6TpByifPQu/mJhjThoj2GDMuokRW7EBdEFKZ7k
NhI4ob8PTV3SIoFMtY3zufTzR9PkUnG7IPWCVkKm9c8hhXytxVU0PskBSXCmkUSVl0MKVkvWwkDw
tHM8pMBamZdg9vgxi6vPU751QfXKkqGjd1VZU3LEx6yeN4k99vELgX6P7J4gJmr5TXAWjcUbuHCi
xDvoaF2N6qaWMblYTJIvIAn8SmDidCvfuihhI4d8orMjFzb/ya5G1Yn1pPkqlcBHm64F4z+Aaidm
70qx+ZPVfVBi7RnH75pwdGs+m8/wyIjBEeQ9Gl07jDf8BwAA//8DAFBLAwQUAAYACAAAACEA2wkD
RFUBAACdAgAAEQAAAHBwdC9wcmVzUHJvcHMueG1stJHLasMwEEX3hf6D0V7Rw44Tm9jBjl0odNFF
+wHClhOB9UBSHqX03yuctCR0k013Mwz3zrkzq/VJjtGBWye0KgCZYRBx1eleqG0B3t+e4BJEzjPV
s1ErXoAP7sC6fHxYmdxY7rjyzAfpq42CkXI5K8DOe5Mj5Lodl8zNtOEqzAZtJfOhtVvUW3YMC+SI
KMYpkkwocNHbe/R6GETHG93tZQA4m1g+TiRuJ4z7cTP3uF3nuEEqQ0h+8i/OX6pob0UBPttFummz
pIIpjjcwIQmFddbWMG1IvMCY4IouvkDQkCTvheuY7Z8l2/K2F75hnl2ihvEfPCk6q50e/KzTEp1z
IqOP3BotpqgEX9+rACA6sLEAGKByhSbeW9gmJhVOaQUX2bKCSUwzWNVNA+u6Ws7TlOI5wb+wfGD7
0U+wjRH/wUnpDemZeLpwKK8/8WrLbwAAAP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAAABMA
AABwcHQvdGFibGVTdHlsZXMueG1sDMxJDoIwGEDhvYl3aP59LUNRJBTCICt36gEqlCHpQGijEuPd
Zfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA1nHdcWm0YLAKC3m236U8cU95c6sUV+vQpmib
cAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h705UkgecdieKTBtSJnsE3qoIgorTAp8vliGlIA1x6
NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAwQUAAYACAAAACEACt4NM3ECAACkBQAAEAAIAWRvY1By
b3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcVMlu2zAQvRfo
PxA6pUBjeQmM1KAZFA4CF6gbA1aS84QaWUQpUiBpJ+7XdyRZXmq3QeqLZ3ma5c1w+M1rodkanVfW
jKNepxsxNNKmyizH0UNyd3kdMR/ApKCtwXG0QR/diI8f+NzZEl1Q6BmFMH4c5SGUozj2MscCfIfc
hjyZdQUEUt0ytlmmJN5auSrQhLjf7Q5jfA1oUkwvy13AqIk4Wof/DZpaWdXnH5NNSQULntgAOlEF
iuGAx3uNP1mXetEfDnnciPxrWWolIRAhYqaks95mgd3XpbO5fUE3t8oEHh8CiQ701FP92V3dsrg3
l146RMMWuX1hF1ejwScenwHyOThYOihzLwZdguxVvtAqRS+uebyV+A8byECwRuBTlaZotl4yH+l8
NptoVdb4VuQLCRonxI/IQHuk0DsDnyJUs5+Dcl7wdRitUQbrmFe/aPpXEXsGjxWr42gNToEJxG4F
a5Ra1qUPTiS0BhSbfI1ei4ewQ1ldiV4NIOGfwCZW3S1LVNDo35GCWKRyTlJUxqZNyn1MQJPiPqOR
hDN8fDnkoy6tYaOpcrszJ0TsKJmBkznr9036mfW7PdrMnavitInypBxSm57RRsvqf2JNcFaz96Ev
JH1G+7eLu8+wKKg7JlX1mGNlMgc0v5UMK9rp81meV0pXa8JgFSw9b3orZyOvMVdypcG9BZS2KNBJ
Bfot5NQW+BfM0Rz/mNzEFiWYjZgoLy1bbHzAwrNvCY9bD/+uzE//UCb2FgK2T+PYyBc5OEzpgrX+
vYFP6VU4XQWZ5GCWmLaYU0d1ZB6boyt6/U6XfvU9aW3VmWjPq/gNAAD//wMAUEsDBBQABgAIAAAA
IQCyI7NsfwEAALsCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAACMkktP4zAUhfdI/AfLqxmJ1HnwkpUaCRCrqYRERozYGfvSWJM4ln2h9N+P
nbShaFiwi3PO/XTuseur974jb+CDGeySFoucErBq0Maul/R3c5ddUhJQWi27wcKSbiHQK3F8VCvH
1eDh3g8OPBoIJJJs4MotaYvoOGNBtdDLsIgOG8WXwfcS49GvmZPqr1wDK/P8nPWAUkuULAEzNxPp
DqnVjHSvvhsBWjHooAeLgRWLgn14EXwfvhwYlQNnb3Dr4k67uIdsrSZxdr8HMxs3m81iU40xYv6C
/Vn9ehhXzYxNXSmgotaKo8EOxEp61ZKytPqElHlR1WyWkkl5kDh4cS+Dkh1p2tfn2Cf54XD6+jn6
965UeycDruINvRjQ11vRtEMsmTxKRNhaqNn/ljTl4c2kSxZFPlrmcwwxFjMlAU3iqnwqZq88Vje3
zR0VKX6WV1lZNsUpP7vgxdlTivdpPq0+/eh3Ib9DrJr8nFenvDwk7gFiTPz5uYl/AAAA//8DAFBL
AQItABQABgAIAAAAIQBi+1zGJgIAANQPAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl
c10ueG1sUEsBAi0AFAAGAAgAAAAhAGj4dKEFAQAA4gIAAAsAAAAAAAAAAAAAAAAAXwQAAF9yZWxz
Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAlQcAAHBwdC9z
bGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACAA
AAAAAAAAAAAAAAAAkggAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxzUEsBAi0AFAAG
AAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAkQkAAHBwdC9zbGlkZXMvX3JlbHMvc2xp
ZGU0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAjgoA
AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAA
NwEAACAAAAAAAAAAAAAAAAAAiwsAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1LnhtbC5yZWxzUEsB
Ai0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAiAwAAHBwdC9zbGlkZXMvX3Jl
bHMvc2xpZGU2LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAA
AAAAhQ0AAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU3LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1
Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAgg4AAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU4LnhtbC5y
ZWxzUEsBAi0AFAAGAAgAAAAhAKd0L9lPAQAAdwcAAB8AAAAAAAAAAAAAAAAAfw8AAHBwdC9fcmVs
cy9wcmVzZW50YXRpb24ueG1sLnJlbHNQSwECLQAUAAYACAAAACEAqnnZeXcCAAB1DQAAFAAAAAAA
AAAAAAAAAAATEgAAcHB0L3ByZXNlbnRhdGlvbi54bWxQSwECLQAUAAYACAAAACEAn3IMql0CAABX
BQAAFQAAAAAAAAAAAAAAAAC8FAAAcHB0L3NsaWRlcy9zbGlkZTEueG1sUEsBAi0AFAAGAAgAAAAh
AOTYD358AwAACQkAABUAAAAAAAAAAAAAAAAATBcAAHBwdC9zbGlkZXMvc2xpZGU4LnhtbFBLAQIt
ABQABgAIAAAAIQDCkLCC0QIAAJgGAAAVAAAAAAAAAAAAAAAAAPsaAABwcHQvc2xpZGVzL3NsaWRl
Ni54bWxQSwECLQAUAAYACAAAACEA2lBsOhkDAAAoCAAAFQAAAAAAAAAAAAAAAAD/HQAAcHB0L3Ns
aWRlcy9zbGlkZTUueG1sUEsBAi0AFAAGAAgAAAAhAJ7s8UPeAgAAngYAABUAAAAAAAAAAAAAAAAA
SyEAAHBwdC9zbGlkZXMvc2xpZGU3LnhtbFBLAQItABQABgAIAAAAIQDaqtkCMgUAAE0QAAAVAAAA
AAAAAAAAAAAAAFwkAABwcHQvc2xpZGVzL3NsaWRlMy54bWxQSwECLQAUAAYACAAAACEA3LeDIIEE
AAAbDwAAFQAAAAAAAAAAAAAAAADBKQAAcHB0L3NsaWRlcy9zbGlkZTIueG1sUEsBAi0AFAAGAAgA
AAAhAANcxcmoAwAAfgoAABUAAAAAAAAAAAAAAAAAdS4AAHBwdC9zbGlkZXMvc2xpZGU0LnhtbFBL
AQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAFAyAABwcHQvc2xpZGVMYXlv
dXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcB
AAAsAAAAAAAAAAAAAAAAAFgzAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0My54
bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAGA0AABwcHQv
c2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV
0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAGg1AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRl
TGF5b3V0NS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAA
AHA2AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ni54bWwucmVsc1BLAQItABQA
BgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAAAAAAAAAAAAAAHg3AABwcHQvc2xpZGVMYXlvdXRzL19y
ZWxzL3NsaWRlTGF5b3V0MTAueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAA
AAAAAAAAAAAAAACBOAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDgueG1sLnJl
bHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAACJOQAAcHB0L3NsaWRl
TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDkueG1sLnJlbHNQSwECLQAUAAYACAAAACEAJfOUjwcI
AADyLwAAIQAAAAAAAAAAAAAAAACROgAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s
UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAA10IAAHBwdC9zbGlkZUxh
eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAA
ADcBAAAsAAAAAAAAAAAAAAAAAOBDAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0
Ny54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAOhEAABw
cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwucmVsc1BLAQItABQABgAIAAAA
IQCslGfmpAQAACARAAAhAAAAAAAAAAAAAAAAAPBFAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5
b3V0MS54bWxQSwECLQAUAAYACAAAACEAaaJfIR4BAADHBwAALAAAAAAAAAAAAAAAAADTSgAAcHB0
L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA
pLy6yU0DAADVCAAAIQAAAAAAAAAAAAAAAAA7TAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91
dDYueG1sUEsBAi0AFAAGAAgAAAAhAOX8egjkBQAAUhwAACEAAAAAAAAAAAAAAAAAx08AAHBwdC9z
bGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQBJhsyqhQQAAIMSAAAh
AAAAAAAAAAAAAAAAAOpVAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWxQSwECLQAU
AAYACAAAACEAOATyiPcEAAB1EQAAIQAAAAAAAAAAAAAAAACuWgAAcHB0L3NsaWRlTGF5b3V0cy9z
bGlkZUxheW91dDMueG1sUEsBAi0AFAAGAAgAAAAhAHAWmgfAAwAAsgsAACEAAAAAAAAAAAAAAAAA
5F8AAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnhtbFBLAQItABQABgAIAAAAIQCVWz/F
YgUAAN4SAAAhAAAAAAAAAAAAAAAAAONjAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54
bWxQSwECLQAUAAYACAAAACEAh/WdxxgDAACDBwAAIQAAAAAAAAAAAAAAAACEaQAAcHB0L3NsaWRl
TGF5b3V0cy9zbGlkZUxheW91dDcueG1sUEsBAi0AFAAGAAgAAAAhAP4jaGvWAwAA6AsAACIAAAAA
AAAAAAAAAAAA22wAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWxQSwECLQAUAAYA
CAAAACEA+68s8B4FAABNEgAAIQAAAAAAAAAAAAAAAADxcAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk
ZUxheW91dDkueG1sUEsBAi0AFAAGAAgAAAAhAEXwK80jBAAAyQwAACIAAAAAAAAAAAAAAAAATnYA
AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWxQSwECLQAUAAYACAAAACEAuX/uc5YG
AACwGwAAFAAAAAAAAAAAAAAAAACxegAAcHB0L3RoZW1lL3RoZW1lMS54bWxQSwECLQAKAAAAAAAA
ACEA5JRimAAYAAAAGAAAFwAAAAAAAAAAAAAAAAB5gQAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWdQ
SwECLQAUAAYACAAAACEA0g9Vh7UBAAB2AwAAEQAAAAAAAAAAAAAAAACumQAAcHB0L3ZpZXdQcm9w
cy54bWxQSwECLQAUAAYACAAAACEA2wkDRFUBAACdAgAAEQAAAAAAAAAAAAAAAACSmwAAcHB0L3By
ZXNQcm9wcy54bWxQSwECLQAUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAAAAAAAAAAAAAAAWnQAA
cHB0L3RhYmxlU3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQAK3g0zcQIAAKQFAAAQAAAAAAAAAAAA
AAAAAPOdAABkb2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgAAAAhALIjs2x/AQAAuwIAABEAAAAA
AAAAAAAAAAAAmqEAAGRvY1Byb3BzL2NvcmUueG1sUEsFBgAAAAAzADMARA8AAFCkAAAAAA==
--047d7b111c53e7265904d892dd1e--

From dominique.barthel@orange.com  Sat Mar 23 08:08:51 2013
Return-Path: 
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 73BAD21F8895 for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 08:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
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 G9WW3ObqkubC for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 08:08:46 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A96C021F882F for <6tsch@ietf.org>; Sat, 23 Mar 2013 08:08:45 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 45D6A18C3AF; Sat, 23 Mar 2013 16:08:44 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2CB1927C046; Sat, 23 Mar 2013 16:08:44 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Sat, 23 Mar 2013 16:08:43 +0100
From: 
To: "Pascal Thubert (pthubert)" , Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: Agenda for the call March 22nd, 2013
Thread-Index: Ac4mVLDC8NseT7odSWCtQiFRnyZntgAeipSw
Date: Sat, 23 Mar 2013 15:08:42 +0000
Message-ID: <1570_1364051324_514DC57C_1570_16957_1_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDA@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.3]
Content-Type: multipart/alternative; boundary="_000_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDAPEXCVZYM13corpo_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.23.140316
Subject: Re: [6tsch] Agenda for the call March 22nd, 2013
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2013 15:08:51 -0000

--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDAPEXCVZYM13corpo_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Pascal, Wavi, Thomas, all,

Sorry I won't be able to attend the call, on the road again.
Some comments, though:
  *(road,street) traffic control (requires increase of bw as more traffic i=
n the road)
Why does traffic control require more bandwidth as traffic increases? Aren'=
t we reporting data such as number of cars as opposed to each passing car o=
ne by one?
    *smart urban parking (requires redundancy of routes an over-provision a=
s RF degrades with cars on top of the sensors)
How is this a highlight of TSCH?

    * green zones. Monitor moisture in gardens, trigger watering.

   * city lights monitoring. Requires marge scale meshes
Again, this doesn't say why TSCH is required or better than anything else, =
hence is not a selling point.
Xavi, I think you were the one to put these scenarios forward, in another e=
mail thead. Can you please comment?
Thanks

Dominique

De : 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] De la part de P=
ascal Thubert (pthubert)
Envoy=E9 : jeudi 21 mars 2013 17:56
=C0 : Thomas Watteyne; 6tsch@ietf.org
Objet : [6tsch] Agenda for the call March 22nd, 2013

Dear all:

The focus for tomorrow will be to agree on use cases and derive a problem s=
tatement. Please keep in mind that the call will be recorded and the record=
 published.

We already have a list that we can review:


- Wireless Process Control (main source for us)
   * control loops (requires a global optimization of routes for jitter an =
latency - thus computed by a PCE  -, flow (over) provisioning, duocast, wit=
h static multipath hard slot allocation.
   * control loop plan B (requires self-healing -thus distributed- routing,)
   * supervisory flows (requires determinism up to the backbone
   * management (requires a separate topology - a RPL instance - that does =
not break)
   * alerts (bursty, unexpected, dynamic slot allocation, prioritization)
   * monitoring of lots of lesser importance stuff like corrosion (requires=
 low cost scalability - this distributed routing )
   * cranes that are mobile within a range (requires dynamicity on the last=
 hop(s) whre the mobility happens and may be deterministic up to that point)
   * large plants (requires thousands of devices- thus a backbone - within =
a subnet - to avoid renumbering)
   * non-production episodes (requires fast and autonomic behavior - again =
distributed routing)
   * coexistence with legacy devices (requires a common management above)

-Smart cities/infrastructures
    *(road,street) traffic control (requires increase of bw as more traffic=
 in the road)
    *smart urban parking (requires redundancy of routes an over-provision a=
s RF degrades with cars on top of the sensors)

    * green zones. Monitor moisture in gardens, trigger watering.

   * city lights monitoring. Requires marge scale meshes



- building automation.

  * requires redundancy as RF degrades when there are changes on the enviro=
nment, doors, moving metallic apparel, etc..)

  * can be long distance this many hops. Can use lower frequencies to gain =
range.



- vehicular automation.

   * We can save copper for most of the man to machine interfaces, which tr=
anslates in both lower price and lower gas consumption.



- commercial automation.

  *  asset tracking operations on the move (again mobility, and dynamics).

  *  monitoring e.g. temperature of freezers, intrusion sensors, ...


Please bring your own thoughts so we can converge at the call : )

As an appetizer, we can start with


  *   summary overview Orlando meeting (10 minutes)

     *   agendas two meetings
     *   4 drafts presented
     *   TODO: 6tus, add ability for a PCE to set hard cells on one side on=
ly (text already changed)
     *   TODO: typos
     *   TODO: terminology

Then the entr=E9e (40 minutes)


  *   charter use cases:

     *   review the list above
     *   validate the list of derived problems to be solved
     *   focus on what TSCH is good at: reliability, low-power consumption,=
 traffic engineering

for dessert

  *   open technical discussions

     *   synchronization between BBRs

        *   summarize and discuss proposal

     *   slotframes, cells and priorities

        *   summarize and discuss proposal

     *   interaction between RPL and PCE

        *   summarize current state of the discussion


Please let us know if you wish to add / amend stuff in the above : )

Cheers,

Pascal

PS, call info is as always:

Topic: 6TSCH Weekly
Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 206 802 913
Meeting Password: sixtus


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=
=3DNZTRkNDAwOTE1&RT=3DMiM0
2. Enter your name and email address.
3. Enter the meeting password: sixtus
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkN=
DAwOTE1&ORT=3DMiM0

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita=
s area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access =
Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
pthubert@cisco.com
33-49-723 2634

To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&LD=
=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&=
RT=3DMiM0






http://www.webex.com

CCP:+14085256800x206802913#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent to the recording, discuss your concerns =
with the meeting host prior to the start of the recording or do not join th=
e session. Please note that any such recordings may be subject to discovery=
 in the event of litigation.


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDAPEXCVZYM13corpo_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello P=
ascal, Wavi, Thomas, all,


&n=
bsp;


Sorry I=
 won’t be able to attend the call, on the road again.


Some co=
mments, though:


  *(road,street) traffic c=
ontrol (requires increase of bw as more traffic in the road)


Why doe=
s traffic control require more bandwidth as traffic increases? Aren’t=
 we reporting data such as number of cars as opposed to each passing car on=
e by one?


    *smart urban=
 parking (requires redundancy of routes an over-provision as RF degrades wi=
th cars on top of the sensors)   



How is =
this a highlight of TSCH?


    * gr=
een zones. Monitor moisture in gardens, trigger watering.=



   * city lights m=
onitoring. Requires marge scale meshes


Again, =
this doesn’t say why TSCH is required or better than anything else, h=
ence is not a selling point.


Xavi, I=
 think you were the one to put these scenarios forward, in another email th=
ead. Can you please comment?


Thanks =



&n=
bsp;


Dominique


 






De : 6tsc=
h-bounces@ietf.org [mailto:6tsch-bounces@ietf.org]
De la part de Pascal Thubert (pthubert)

Envoy=E9 : jeudi 21 mars 2013 17:56

=C0 : Thomas Watteyne; 6tsch@ietf.org

Objet : [6tsch] Agenda for the call March 22nd, 2013=







 


Dear all:


 


The focus for tomorrow will be =
to agree on use cases and derive a problem statement. Please keep in mind t=
hat the call will be recorded and the record published.

 


We already have a list that we =
can review:


 


- Wireless Process Control (=
main source for us)


   * control loops (r=
equires a global optimization of routes for jitter an latency – thus =
computed by a PCE  -, flow (over) provisioning, duocast, with static m=
ultipath hard slot allocation.



   * control loo=
p plan B (requires self-healing -thus distributed- routing,)


   * supervisory flow=
s (requires determinism up to the backbone


   * management (requ=
ires a separate topology – a RPL instance - that does not break)=



   * alerts (bursty, =
unexpected, dynamic slot allocation, prioritization)


   * monitoring of lo=
ts of lesser importance stuff like corrosion (requires low cost scalability=
 – this distributed routing )


   * cranes that are =
mobile within a range (requires dynamicity on the last hop(s) whre the mobi=
lity happens and may be deterministic up to that point)

   * large plants (re=
quires thousands of devices– thus a backbone – within a subnet =
– to avoid renumbering)


   * non-production e=
pisodes (requires fast and autonomic behavior – again distributed rou=
ting)


   * coexistence with=
 legacy devices (requires a common management above)


 


-Smart cities/infrastructures <=
br>
    *(road,street) traffic control (requires increase of bw =
as more traffic in the road)

    *smart urban parking (requires redundancy of routes an o=
ver-provision as RF degrades with cars on top of the sensors)  &n=
bsp;



    * gr=
een zones. Monitor moisture in gardens, trigger watering.=



   * city lights m=
onitoring. Requires marge scale meshes


 


- building automation. =



  * requires redun=
dancy as RF degrades when there are changes on the environment, doors, movi=
ng metallic apparel, etc..)


  * can be long distanc=
e this many hops. Can use lower frequencies to gain range.


 


- vehicular automation. 


   * We can s=
ave copper for most of the man to machine interfaces, which translates in b=
oth lower price and lower gas consumption.


 


- commercial automation.


  *  asset trackin=
g operations on the move (again mobility, and dynamics).<=
/p>

  *  monitoring e.=
g. temperature of freezers, intrusion sensors, …


 


 


Please bring your own thoughts =
so we can converge at the call : )


 


As an appetizer, we can start w=
ith 


 


    

  • summary overview Orlando meeting (10 minutes)
    • 

      

        

      • agendas two meetings
      • 4 drafts presented<=
/o:p>
      • =
TODO: 6tus, add ability for a PCE to set hard cells on=
 one side only (text already changed)
      • TODO: typos=

      • TODO: terminology
      

    

     
    

    Then the entr=E9e (40 minutes)<=
o:p>
    

     
    

      

    • charter use cases:
    

      

        

      • review the list above
      • validate the list of de=
rived problems to be solved
      • focus on what TSCH is=
 good at: reliability, low-power consumption, traffic engineering
      

    

     
    

    for dessert

      

    • open technical discussions
    

      

        

      • synchronization between BBRs
      

    

      

        

          

        • summarize and discuss proposal
        

      

    

      

        

      • slotframes, cells and priorities
      

    

      

        

          

        • summarize and discuss proposal
        

      

    

      

        

      • interaction between RPL and PCE
      

    

      

        

          

        • summarize current state of the discussion
        

      

    

     
    

     =
;
    

    Please let us know if you wish =
to add / amend stuff in the above : )
    

     
    

    Cheers,
    

     
    

    Pascal
    

     
    

    PS, call info is as always:
    


    
Topic: 6TSCH Weekly 
    
Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014 
    
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) 
    
Meeting Number: 206 802 913 
    
Meeting Password: sixtus 
    

    

    
------------------------------------------------------- 
    
To join the online meeting (Now from mobile devices!) 
    
    --------------------------------------------=
-----------

    
1. Go to     https://cisco.webex.com/cisco=
sales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkNDAwOTE1&RT=3DMiM0=


    
2.     Enter your name and email address.

    
3. Enter the meeting password: sixtus 
    
4. Click "Join Now". 
    

    
To view in other time zones or languages, please click the link: 
    
https://cisco=
.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkNDAwOT=
E1&ORT=3DMiM0

    

    
---------------------------------------------------------------- 
    
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes 
    
---------------------------------------------------------------- 
    

    
The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita=
s area and (866) 349-3520 for the RTP area.

    

    
Please dial the local access number for your area from the list below: 
    
- San Jose/Milpitas (408) area: 525-6800 
    
- RTP (919) area: 392-3330 
    

    
------------------------------------------------------- 
    
To join the teleconference only 
    
------------------------------------------------------- 
    
1. Dial into Cisco WebEx (view all Global Access Numbers at 
    
http://cisco.com/en/US/about/doing_business/conferen=
cing/index.html

    
2. Follow the prompts to enter the Meeting Number (listed above) or Access =
Code followed by the # sign.

    

    
San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 
    

    
US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 
    

    
India: +91.80.4350.1111 Germany: +49.619.6773.9002 
    

    
Japan: +81.3.5763.9394 China: +86.10.8515.5666 
    

    
------------------------------------------------------- 
    
For assistance 
    
------------------------------------------------------- 
    
1. Go to https://cisco.webex.com/ciscosales/mc

    
2. On the left navigation bar, click "Support". 
    

    
You can contact me at: 
    
pthubert@cisco.com 
    
33-49-723 2634 
    

    
To add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:

    
https:=
//cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&=
amp;LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMu=
Egw1h2pXGIGSMyQEb&RT=3DMiM0

    

    

    

    

    

    

    
http://www.webex.com=
 
    

    
CCP:+14085256800x206802913# 
    

    
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent
 to the recording, discuss your concerns with the meeting host prior to the=
 start of the recording or do not join the session. Please note that any su=
ch recordings may be subject to discovery in the event of litigation.

    

     
    



______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.




--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDAPEXCVZYM13corpo_--

From dominique.barthel@orange.com  Sat Mar 23 08:14:01 2013
Return-Path: 
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 2BD9421F8960 for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 08:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
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 5jrKdB9z45yF for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 08:13:57 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8432321F8951 for <6tsch@ietf.org>; Sat, 23 Mar 2013 08:13:56 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7224618C399; Sat, 23 Mar 2013 16:13:55 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 547DD4C017; Sat, 23 Mar 2013 16:13:55 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Sat, 23 Mar 2013 16:13:55 +0100
From: 
To: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] focussing on charter: use cases
Thread-Index: Ac4k1OmP4544fW5MRUSgOucw3DT4aQBFd8gAADhOmBA=
Date: Sat, 23 Mar 2013 15:13:54 +0000
Message-ID: <6194_1364051635_514DC6B3_6194_19669_1_8F1D83ADCC1AC94186A867BEE9B7D91306D39033@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References:  
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.3]
Content-Type: multipart/alternative; boundary="_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39033PEXCVZYM13corpo_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.23.140316
Subject: Re: [6tsch] focussing on charter: use cases
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2013 15:14:01 -0000

--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39033PEXCVZYM13corpo_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Thomas, all,

Regarding your point
- because of a 6TSCH node is deeply duty cycle, remote sensing application =
(e.g. agricultural applications) can rely on energy harvesting as power sou=
rce.
I still need to be convinced that 6tsch allows for a lower power consumptio=
n than preamble sampling on very low traffic. Therefore I don't think we sh=
ould say
"6tsch is lower power therefore makes possible new applications therefore w=
e should standardize 6tsch". This is overly simplistic.
Other arguments that were stated, such as determinism, which is mandated by=
 industry automation, is a much better seller.

To add another one, as I stated in an earlier phone conference, I believe T=
SCH is of interest to build mutualized sensor networks that can support sev=
eral end customers or services. This is because one can allocate bandwidth =
to each supported service independently of the others (under some limits). =
This can be modeled beforehand, a decision can be made to admit the new cus=
tomer/service or not, and the network can be managed to allocate temporary =
extra resources to maintain QoS while a technician is sent to the field to =
investigate such things as node failure or severe interference. Granted, se=
veral node resources such as energy and memory are still shared between cus=
tomers/services but TSCH allows to model and manage these much better than =
other wireless link layers.
Such a mutualized managed network is much more likely to be profitable and =
makes a better use of spectrum than independent, overlaid networks fighting=
 for the same wireless medium.
To a company intending to deploy, operate and manage a sensor network infra=
structure, TSCH is good starting point.

Comments?

Dominique

De : 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] De la part de T=
homas Watteyne
Envoy=E9 : jeudi 21 mars 2013 06:16
=C0 : 6tsch@ietf.org
Objet : Re: [6tsch] focussing on charter: use cases

Pascal, all,

Absolutely agreed. I believe we have started exploring quite a bit, enough =
to have a clear understanding of what we can achieve with this technology a=
s a WG. So let's spend some time on use cases and building a good case to c=
onvince an AD.

We could start by listing what TSCH is "good at", and what makes it differe=
nt from other solutions. I see the following:
- reliability: 5 9's of end-to-end reliability are commonplace.
- low-power: aggressive radio duty cycling of the mote's radio yields much =
longer lifetime in battery-powered devices.
- traffic engineering: the clear identification of resources allows for flo=
w independence and QoS.

Of course, from those points, industrial applications immediately come to m=
ind. Yet, we could take use cases from other areas. We could for example ta=
ke the ROLL requirement drafts as a skeleton (I'm paraphrasing some of the =
points Xavi and Alfredo made).

- industrial automation. A 6TSCH network can allow for high reliability, an=
d deterministic behavior. Link over-provisioning can efficiently combat the=
 unreliable nature of wireless and provide a robust communication.
- building automation. A 6TSCH network can serve as an "umbrella" network f=
or a large number of sensing points in the building. These sensing points c=
an be owned and operated by different entities (e.g. HVAC and lighting). Th=
e 6TSCH network allows for the different traffic flows to stay independent =
from one another.
- because of a 6TSCH node is deeply duty cycle, remote sensing application =
(e.g. agricultural applications) can rely on energy harvesting as power sou=
rce.
- A smart urban parking application can benefit from the reliabilty of  6TS=
CH network since, even though the vehicle detection sensor may be static, t=
he constant movement of cars around the sensing points can cause the wirele=
ss environment to quickly change.

Thomas

On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) > wrote:
Dear ML:

The activity that we generate on the mailing list is a good indication we w=
ill be very successful as a WG. First thing first, though, we need to creat=
e the WG and need to focus a little bit on the necessary steps to get there.

We need to put together a rough charter, and convince an AD, probably Adria=
n from Routing Area or Ted from Internet Area, that we have real problems t=
o solve and that we, as a group, can provide valuable answers. The ADs agen=
das are very full all the time, but certainly peaks around the meeting time=
s. So we have about 2 week in front of us to prepare a solid case.

So I suggest we step back a minute from the details of time frames and prio=
rities and spend some energy on the use cases, the problems we are solving,=
 and the work we have to do to get there. I notice a cool discussion on mob=
ility and the particular case of a crane, well that's a use case. We alread=
y had centralized deterministic (hard slot) routes for command and control,=
 distributed deterministic (soft slots) and non deterministic QoS based flo=
ws. Do we have others cases?
Cheers,

Pascal



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


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39033PEXCVZYM13corpo_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Thomas, all,


 <=
/p>

Regarding your point=



- because of a 6TSCH node is de=
eply duty cycle, remote sensing application (e.g. agricultural applications=
) can rely on energy harvesting as power source.


I still ne=
ed to be convinced that 6tsch allows for a lower power consumption than pre=
amble sampling on very low traffic. Therefore I don’t think
 we should say


“6ts=
ch is lower power therefore makes possible new applications therefore we sh=
ould standardize 6tsch”. This is overly simplistic.=



Other argu=
ments that were stated, such as determinism, which is mandated by industry =
automation, is a much better seller.


 =
;


To add ano=
ther one, as I stated in an earlier phone conference, I believe TSCH is of =
interest to build mutualized sensor networks that can support
 several end customers or services. This is because one can allocate bandwi=
dth to each supported service independently of the others (under some limit=
s). This can be modeled beforehand, a decision can be made to admit the new=
 customer/service or not, and the
 network can be managed to allocate temporary extra resources to maintain Q=
oS while a technician is sent to the field to investigate such things as no=
de failure or severe interference. Granted, several node resources such as =
energy and memory are still shared
 between customers/services but TSCH allows to model and manage these much =
better than other wireless link layers.


Such a mut=
ualized managed network is much more likely to be profitable and makes a be=
tter use of spectrum than independent, overlaid networks fighting
 for the same wireless medium.


To a compa=
ny intending to deploy, operate and manage a sensor network infrastructure,=
 TSCH is good starting point.


 =
;


Comments?<=
o:p>


 =
;


Dominique<=
o:p>


 =
;




De : 6tsc=
h-bounces@ietf.org [mailto:6tsch-bounces@ietf.org]
De la part de Thomas Watteyne

Envoy=E9 : jeudi 21 mars 2013 06:16

=C0 : 6tsch@ietf.org

Objet : Re: [6tsch] focussing on charter: use cases<=
/span>




 


Pascal, all,




 






Absolutely agreed. I believe we have started explori=
ng quite a bit, enough to have a clear understanding of what we can achieve=
 with this technology as a WG. So let's spend some time on use cases and bu=
ilding a good case to convince an
 AD.






 






We could start by listing what TSCH is "good at=
", and what makes it different from other solutions. I see the followi=
ng:






- reliability: 5 9's of end-to-end reliability are c=
ommonplace.






- low-power: aggressive radio duty cycling=
 of the mote's radio yields much longer lifetime in battery-powered devices=
.






- traffic engineering: the clear identification of r=
esources allows for flow independence and QoS.






 








Of course, from those points, industrial application=
s immediately come to mind. Yet, we could take use cases from other areas. =
We could for example take the ROLL requirement drafts as a skeleton (I'm pa=
raphrasing some of the points Xavi
 and Alfredo made). 






 






- industrial automation. A =
6TSCH network can allow for high reliability, and deterministic b=
ehavior. Link over-provisioning can efficiently combat the unreliable
 nature of wireless and provide a robust communication. 






- building automation. A 6TSCH network can serve as =
an "umbrella" network for a large number of sensing points in the=
 building. These sensing points can be owned and operated by different enti=
ties (e.g. HVAC and lighting). The 6TSCH network
 allows for the different traffic flows to stay independent from one anothe=
r.






- because of a 6TSCH node is deeply duty cycle, remo=
te sensing application (e.g. agricultural applications) can rely on energy =
harvesting as power source.






- A smart urban parking application can benefit from=
 the reliabilty of  6TSCH network since, even though the vehicle detec=
tion sensor may be static, the constant movement of cars around the sensing=
 points can cause the wireless environment
 to quickly change.






 






Thomas






 






On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pt=
hubert) <pthuber=
t@cisco.com> wrote:






Dear ML:


 


The activity that we generate on the mailing =
list is a good indication we will be very successful as a WG. First thing f=
irst, though, we need to create the WG
 and need to focus a little bit on the necessary steps to get there.


 


We need to put together a rough charter, and =
convince an AD, probably Adrian from Routing Area or Ted from Internet Area=
, that we have real problems to solve
 and that we, as a group, can provide valuable answers. The ADs agendas are=
 very full all the time, but certainly peaks around the meeting times. So w=
e have about 2 week in front of us to prepare a solid case.


 


So I suggest we step back a minute from the d=
etails of time frames and priorities and spend some energy on the use cases=
, the problems we are solving, and the
 work we have to do to get there. I notice a cool discussion on mobility an=
d the particular case of a crane, well that’s a use case. We already =
had centralized deterministic (hard slot) routes for command and control, d=
istributed deterministic (soft slots)
 and non deterministic QoS based flows. Do we have others cases?=



Cheers,


 


Pascal


 


 








_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch




 






______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.




--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39033PEXCVZYM13corpo_--

From xvilajosana@eecs.berkeley.edu  Sat Mar 23 08:32:23 2013
Return-Path: 
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 BCC2021F84B5 for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 08:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.539
X-Spam-Level: 
X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.059,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 X82ehVuAeDIJ for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 08:32:18 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4859421F8B13 for <6tsch@ietf.org>; Sat, 23 Mar 2013 08:32:18 -0700 (PDT)
Received: from c-67-188-198-243.hsd1.ca.comcast.net ([67.188.198.243] helo=[192.168.2.7]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UJQQW-0003Tt-5z for 6tsch@ietf.org; Sat, 23 Mar 2013 08:32:17 -0700
Message-ID: <514DCAF8.7050003@eecs.berkeley.edu>
Date: Sat, 23 Mar 2013 08:32:08 -0700
From: Xavier Vilajosana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: 6tsch@ietf.org
References:  <1570_1364051324_514DC57C_1570_16957_1_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDA@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <1570_1364051324_514DC57C_1570_16957_1_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDA@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------090202020002080509010801"
Subject: Re: [6tsch] Agenda for the call March 22nd, 2013
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2013 15:32:24 -0000

This is a multi-part message in MIME format.
--------------090202020002080509010801
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

see inline

On 23/03/13 08:08, dominique.barthel@orange.com wrote:
>
> Hello Pascal, Wavi, Thomas, all,
>
> Sorry I won't be able to attend the call, on the road again.
>
> Some comments, though:
>
>   *(road,street) traffic control (requires increase of bw as more 
> traffic in the road)
>
> Why does traffic control require more bandwidth as traffic increases? 
> Aren't we reporting data such as number of cars as opposed to each 
> passing car one by one?
>
traffic control not only counts cars, the most advanced systems classify 
cars according to the number of axes and even type of car. Note that 
some operators are paid according to the type of car (truck, 
motorbike,car). This requires in some systems to send more information 
which is send at each reading. There are several companies that do that 
and use TSCH networks.
>
>     *smart urban parking (requires redundancy of routes an 
> over-provision as RF degrades with cars on top of the sensors)
>
> How is this a highlight of TSCH?
>
Well, the first thing is that one of the companies with more smart 
parkings installed uses TSCH networks. 6tsch can over-provision 
bandwidth on different tracks, the tracks are not defined by 6tus but 
6tus deals with provisioning more bandwidth if the QoS is not meet. I 
guess also that 6tus may detect that if over-provisioning on a track up 
to a certain limit (eg required is 6cells, 6tus overprovisions 60cells 
because there is a high packet drop and 6 is not met although 60cells 
are given), the RPL should be told about that no?
>
>     * green zones. Monitor moisture in gardens, trigger watering.
>
>    * city lights monitoring. Requires marge scale meshes
>

I haven't proposed them but I can figure out that this scenarios might 
benefit from TSCH if the density of the deployments is high enough and 
the sampling rate requirement is significant.
>
> Again, this doesn't say why TSCH is required or better than anything 
> else, hence is not a selling point.
>
> Xavi, I think you were the one to put these scenarios forward, in 
> another email thead. Can you please comment?
>
> Thanks
>
> Dominique
>
> *De :*6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *De la 
> part de* Pascal Thubert (pthubert)
> *Envoyé :* jeudi 21 mars 2013 17:56
> *À :* Thomas Watteyne; 6tsch@ietf.org
> *Objet :* [6tsch] Agenda for the call March 22nd, 2013
>
> Dear all:
>
> The focus for tomorrow will be to agree on use cases and derive a 
> problem statement. Please keep in mind that the call will be recorded 
> and the record published.
>
> We already have a list that we can review:
>
> - Wireless Process Control (main source for us)
>
>    * control loops (requires a global optimization of routes for 
> jitter an latency -- thus computed by a PCE  -, flow (over) 
> provisioning, duocast, with static multipath hard slot allocation.
>
>    * control loop plan B (requires self-healing -thus distributed- 
> routing,)
>
>    * supervisory flows (requires determinism up to the backbone
>
>    * management (requires a separate topology -- a RPL instance - that 
> does not break)
>
>    * alerts (bursty, unexpected, dynamic slot allocation, prioritization)
>
>    * monitoring of lots of lesser importance stuff like corrosion 
> (requires low cost scalability -- this distributed routing )
>
>    * cranes that are mobile within a range (requires dynamicity on the 
> last hop(s) whre the mobility happens and may be deterministic up to 
> that point)
>
>    * large plants (requires thousands of devices-- thus a backbone -- 
> within a subnet -- to avoid renumbering)
>
>    * non-production episodes (requires fast and autonomic behavior -- 
> again distributed routing)
>
>    * coexistence with legacy devices (requires a common management above)
>
> -Smart cities/infrastructures
>     *(road,street) traffic control (requires increase of bw as more 
> traffic in the road)
>     *smart urban parking (requires redundancy of routes an 
> over-provision as RF degrades with cars on top of the sensors)
>
>     * green zones. Monitor moisture in gardens, trigger watering.
>
>    * city lights monitoring. Requires marge scale meshes
>
> - building automation.
>
>   * requires redundancy as RF degrades when there are changes on the 
> environment, doors, moving metallic apparel, etc..)
>
>   * can be long distance this many hops. Can use lower frequencies to 
> gain range.
>
> - vehicular automation.
>
>    * We can save copper for most of the man to machine interfaces, 
> which translates in both lower price and lower gas consumption.
>
> - commercial automation.
>
>   *  asset tracking operations on the move (again mobility, and dynamics).
>
>   *  monitoring e.g. temperature of freezers, intrusion sensors, ...
>
> Please bring your own thoughts so we can converge at the call : )
>
> As an appetizer, we can start with
>
>   * summary overview Orlando meeting (10 minutes)
>
>       o agendas two meetings
>       o 4 drafts presented
>       o TODO: 6tus, add ability for a PCE to set hard cells on one
>         side only (text already changed)
>       o TODO: typos
>       o TODO: terminology
>
> Then the entrée (40 minutes)
>
>   * charter use cases:
>
>       o review the list above
>       o validate the list of derived problems to be solved
>       o focus on what TSCH is good at: reliability, low-power
>         consumption, traffic engineering
>
> for dessert
>
>   * open technical discussions
>
>       o synchronization between BBRs
>
>           + summarize and discuss proposal
>
>       o slotframes, cells and priorities
>
>           + summarize and discuss proposal
>
>       o interaction between RPL and PCE
>
>           + summarize current state of the discussion
>
> **
>
> Please let us know if you wish to add / amend stuff in the above : )
>
> Cheers,
>
> Pascal
>
> PS, call info is as always:
>
>
> Topic: 6TSCH Weekly
> Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014
> Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
> Meeting Number: 206 802 913
> Meeting Password: sixtus
>
>
> -------------------------------------------------------
> To join the online meeting (Now from mobile devices!)
> -------------------------------------------------------
> 1. Go to 
> https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&RT=MiM0
> 2. Enter your name and email address.
> 3. Enter the meeting password: sixtus
> 4. Click "Join Now".
>
> To view in other time zones or languages, please click the link:
> https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&ORT=MiM0 
>
>
> ----------------------------------------------------------------
> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
> ----------------------------------------------------------------
>
> The affected toll free numbers are: (866) 432-9903 for the San 
> Jose/Milpitas area and (866) 349-3520 for the RTP area.
>
> Please dial the local access number for your area from the list below:
> - San Jose/Milpitas (408) area: 525-6800
> - RTP (919) area: 392-3330
>
> -------------------------------------------------------
> To join the teleconference only
> -------------------------------------------------------
> 1. Dial into Cisco WebEx (view all Global Access Numbers at
> http://cisco.com/en/US/about/doing_business/conferencing/index.html
> 2. Follow the prompts to enter the Meeting Number (listed above) or 
> Access Code followed by the # sign.
>
> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
>
> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
>
> India: +91.80.4350.1111 Germany: +49.619.6773.9002
>
> Japan: +81.3.5763.9394 China: +86.10.8515.5666
>
> -------------------------------------------------------
> For assistance
> -------------------------------------------------------
> 1. Go to https://cisco.webex.com/ciscosales/mc
> 2. On the left navigation bar, click "Support".
>
> You can contact me at:
> pthubert@cisco.com 
> 33-49-723 2634
>
> To add this meeting to your calendar program (for example Microsoft 
> Outlook), click this link:
> https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&RT=MiM0 
>
>
>
>
>
>
>
> http://www.webex.com
>
> CCP:+14085256800x206802913#
>
> IMPORTANT NOTICE: This WebEx service includes a feature that allows 
> audio and any documents and other materials exchanged or viewed during 
> the session to be recorded. By joining this session, you automatically 
> consent to such recordings. If you do not consent to the recording, 
> discuss your concerns with the meeting host prior to the start of the 
> recording or do not join the session. Please note that any such 
> recordings may be subject to discovery in the event of litigation.
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


--------------090202020002080509010801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
see inline

      

      On 23/03/13 08:08, dominique.barthel@orange.com wrote:

    

    

      
      
      
      

        
Hello
            Pascal, Wavi, Thomas, all,

        
 

        
Sorry
            I won’t be able to attend the call, on the road again.

        
Some
            comments, though:

        
  *(road,street) traffic
            control (requires increase of bw as more traffic in the
            road)

        
Why
            does traffic control require more bandwidth as traffic
            increases? Aren’t we reporting data such as number of cars
            as opposed to each passing car one by one?

      

    

    traffic control not only counts cars, the most
      advanced systems classify cars according to the number of axes and
      even type of car. Note that some operators are paid according to
      the type of car (truck, motorbike,car). This requires in some
      systems to send more information which is send at each reading.
      There are several companies that do that and use TSCH networks.

    

      

        

        
    *smart urban parking
            (requires redundancy of routes an over-provision as RF
            degrades with cars on top of the sensors)   
            

        
How
            is this a highlight of TSCH?

      

    

    Well, the first thing is that one of the
      companies with more smart parkings installed uses TSCH networks.
      6tsch can over-provision bandwidth on different tracks, the tracks
      are not defined by 6tus but 6tus deals with provisioning more
      bandwidth if the QoS is not meet. I guess also that 6tus may
      detect that if over-provisioning on a track up to a certain limit
      (eg required is 6cells, 6tus overprovisions 60cells because there
      is a high packet drop and 6 is not met although 60cells are
      given), the RPL should be told about that no? 

    

      

        

        
    * green zones.
            Monitor moisture in gardens, trigger watering.

        
   * city lights
            monitoring. Requires marge scale meshes

      

    

    

      I haven't proposed them but I can figure out that this scenarios
      might benefit from TSCH if the density of the deployments is high
      enough and the sampling rate requirement is significant.

    

      

        

        
Again,
            this doesn’t say why TSCH is required or better than
            anything else, hence is not a selling point.

        
Xavi,
            I think you were the one to put these scenarios forward, in
            another email thead. Can you please comment?

        
Thanks
            

        
 

        
Dominique

        
 

        

          

            
De :
                6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org]
                De la part de Pascal Thubert (pthubert)

                Envoyé : jeudi 21 mars 2013 17:56

                À : Thomas Watteyne; 6tsch@ietf.org

                Objet : [6tsch] Agenda for the call March 22nd,
                2013

          

        

        
 

        
Dear all:

        
 

        
The focus for tomorrow
            will be to agree on use cases and derive a problem
            statement. Please keep in mind that the call will be
            recorded and the record published.

        
 

        
We already have a list
            that we can review:

        
 

        
- Wireless Process
            Control (main source for us)

        
   * control loops
            (requires a global optimization of routes for jitter an
            latency – thus computed by a PCE  -, flow (over)
            provisioning, duocast, with static multipath hard slot
            allocation.
            

        
   * control loop plan B
            (requires self-healing -thus distributed- routing,)

        
   * supervisory flows
            (requires determinism up to the backbone

        
   * management
            (requires a separate topology – a RPL instance - that does
            not break)

        
   * alerts (bursty,
            unexpected, dynamic slot allocation, prioritization)

        
   * monitoring of lots
            of lesser importance stuff like corrosion (requires low cost
            scalability – this distributed routing )

        
   * cranes that are
            mobile within a range (requires dynamicity on the last
            hop(s) whre the mobility happens and may be deterministic up
            to that point)

        
   * large plants
            (requires thousands of devices– thus a backbone – within a
            subnet – to avoid renumbering)

        
   * non-production
            episodes (requires fast and autonomic behavior – again
            distributed routing)

        
   * coexistence with
            legacy devices (requires a common management above)

        
 

        
-Smart
            cities/infrastructures 

                *(road,street) traffic control (requires increase of bw
            as more traffic in the road)

                *smart urban parking (requires redundancy of routes an
            over-provision as RF degrades with cars on top of the
            sensors)   
            

        
    * green zones.
            Monitor moisture in gardens, trigger watering.

        
   * city lights
            monitoring. Requires marge scale meshes

        
 

        
- building
            automation. 

        
  * requires
            redundancy as RF degrades when there are changes on the
            environment, doors, moving metallic apparel, etc..)

        
  * can be long
            distance this many hops. Can use lower frequencies to gain
            range.

        
 

        
- vehicular
            automation. 

        
   * We can save
            copper for most of the man to machine interfaces, which
            translates in both lower price and lower gas consumption.

        
 

        
- commercial
            automation.

        
  *  asset tracking
            operations on the move (again mobility, and dynamics).

        
  *  monitoring e.g.
            temperature of freezers, intrusion sensors, …

        
 

        
 

        
Please bring your own
            thoughts so we can converge at the call : )

        
 

        
As an appetizer, we can
            start with 

        
 

        
    
          
  • summary overview Orlando meeting (10 minutes)
    • 
        

        
    
          
      
            
    • agendas two meetings
      • 
            
    • 4 drafts presented
      • 
            
    • TODO: 6tus, add ability for a PCE to set
                hard cells on one side only (text already changed)
      • 
            
    • TODO: typos
      • 
            
    • TODO: terminology
      • 
          
    
        

        
 

        
Then the entrée (40
            minutes)

        
 

        
    
          
  • charter use cases:
    • 
        

        
    
          
      
            
    • review the list above
      • 
            
    • validate the list of derived problems to be
                solved
      • 
            
    • focus on what TSCH is good at: reliability,
                low-power consumption, traffic engineering
      • 
          
    
        

        
 

        
for dessert

        
    
          
  • open technical discussions
    • 
        

        
    
          
      
            
    • synchronization between BBRs
      • 
          
    
        

        
    
          
      
            
        
              
      • summarize and discuss proposal
        • 
            
      
          
    
        

        
    
          
      
            
    • slotframes, cells and priorities
      • 
          
    
        

        
    
          
      
            
        
              
      • summarize and discuss proposal
        • 
            
      
          
    
        

        
    
          
      
            
    • interaction between RPL and PCE
      • 
          
    
        

        
    
          
      
            
        
              
      • summarize current state of the discussion
        • 
            
      
          
    
        

        
 

        
 

        
Please let us know if
            you wish to add / amend stuff in the above : )

        
 

        
Cheers,

        
 

        
Pascal

        
 

        
PS, call info is as
            always:

        


            Topic: 6TSCH Weekly 

            Date: Every Friday, from Friday, March 8, 2013 to Friday,
            March 7, 2014 

            Time: 8:00 am, Pacific Standard Time (San Francisco,
            GMT-08:00) 

            Meeting Number: 206 802 913 

            Meeting Password: sixtus 

            

            

            ------------------------------------------------------- 

            To join the online meeting (Now from mobile devices!) 

          -------------------------------------------------------
            

            1. Go to https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&RT=MiM0
            

            2. Enter your name and email address.
            

            3. Enter the meeting password: sixtus 

            4. Click "Join Now". 

            

            To view in other time zones or languages, please click the
            link: 

            https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&ORT=MiM0
            

            

            ----------------------------------------------------------------
            

            ALERT:Toll-Free Dial Restrictions for (408) and (919) Area
            Codes 

            ----------------------------------------------------------------
            

            

            The affected toll free numbers are: (866) 432-9903 for the
            San Jose/Milpitas area and (866) 349-3520 for the RTP area.
            

            

            Please dial the local access number for your area from the
            list below: 

            - San Jose/Milpitas (408) area: 525-6800 

            - RTP (919) area: 392-3330 

            

            ------------------------------------------------------- 

            To join the teleconference only 

            ------------------------------------------------------- 

            1. Dial into Cisco WebEx (view all Global Access Numbers at
            

            http://cisco.com/en/US/about/doing_business/conferencing/index.html
            

            2. Follow the prompts to enter the Meeting Number (listed
            above) or Access Code followed by the # sign.
            

            

            San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 

            

            US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
            

            

            India: +91.80.4350.1111 Germany: +49.619.6773.9002 

            

            Japan: +81.3.5763.9394 China: +86.10.8515.5666 

            

            ------------------------------------------------------- 

            For assistance 

            ------------------------------------------------------- 

            1. Go to https://cisco.webex.com/ciscosales/mc
            

            2. On the left navigation bar, click "Support". 

            

            You can contact me at: 

            pthubert@cisco.com
            

            33-49-723 2634 

            

            To add this meeting to your calendar program (for example
            Microsoft Outlook), click this link:
            

            https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&RT=MiM0
            

            

            

            

            

            

            

            http://www.webex.com 

            

            CCP:+14085256800x206802913# 

            

            IMPORTANT NOTICE: This WebEx service includes a feature that
            allows audio and any documents and other materials exchanged
            or viewed during the session to be recorded. By joining this
            session, you automatically consent to such recordings. If
            you do not consent to the recording, discuss your concerns
            with the meeting host prior to the start of the recording or
            do not join the session. Please note that any such
            recordings may be subject to discovery in the event of
            litigation.
          

        
 

      

      
_________________________________________________________________________________________________________________________

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.


      

      

      

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


    

    

  


--------------090202020002080509010801--

From twatteyne@gmail.com  Mon Mar 25 09:33:12 2013
Return-Path: 
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 78DEB21F8930 for <6tsch@ietfa.amsl.com>; Mon, 25 Mar 2013 09:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 0lfB5uEZlJvJ for <6tsch@ietfa.amsl.com>; Mon, 25 Mar 2013 09:33:10 -0700 (PDT)
Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 583CA21F88FC for <6tsch@ietf.org>; Mon, 25 Mar 2013 09:33:10 -0700 (PDT)
Received: by mail-pb0-f52.google.com with SMTP id ma3so4271606pbc.39 for <6tsch@ietf.org>; Mon, 25 Mar 2013 09:32:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=Wcd5821bUNxqk4TejUImK6dNQRVCDFqTnB/INaVQLmg=; b=ZojGu6ngaLOSw4k+d+hgb+9GzX0VSsFRxzwKr/XTRSTwZmdlyXLJhgk00YtNeh3rNY CaoYT1Vc5Ik6gcMBTaUo/qJ5+K1Fxqq2tOvHaEp0o5mWparwr1/GK8YgJzppNucjDnMV 0d4Lp0JYDl6gIHcH7sX7XoapUffI3lYu0eP+oDyuZaEJWh/Blkae74+myrzS1DK97/Ti UqbIoUpEOns/iV5xJ70Xnii/btR14LFU8dDdJ66/1AXmHUz7CuBtK0zMmi+wJf1J2TB3 BTW6rn9BjKYoWmrNYhvzkSvyvmyT/4SWlNSEQIYx32cs1oxpz2Nd21V01u6knOYK5L3+ ZYsg==
X-Received: by 10.66.122.167 with SMTP id lt7mr9096952pab.168.1364229176639; Mon, 25 Mar 2013 09:32:56 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.68.123.71 with HTTP; Mon, 25 Mar 2013 09:32:36 -0700 (PDT)
In-Reply-To: <6194_1364051635_514DC6B3_6194_19669_1_8F1D83ADCC1AC94186A867BEE9B7D91306D39033@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References:   <6194_1364051635_514DC6B3_6194_19669_1_8F1D83ADCC1AC94186A867BEE9B7D91306D39033@PEXCVZYM13.corporate.adroot.infra.ftgroup>
From: Thomas Watteyne 
Date: Mon, 25 Mar 2013 09:32:36 -0700
X-Google-Sender-Auth: gtIPLseA8hcjjgXuaK6viyK1Bb4
Message-ID: 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7bf0e6f8774df704d8c25b8c
Subject: Re: [6tsch] focussing on charter: use cases
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2013 16:33:12 -0000

--047d7bf0e6f8774df704d8c25b8c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Dominique,

Thanks for your comments. We certainly do not want to be overly simplistic.
When identifying use cases, I believe we should focus on what makes TSCH
different, and articulate the use cases around those. As you point out,
traffic differentiation is certainly very high on that list.

An immediate use case is that of an entity operating an "umbrella" network
on which different types of traffic flow, possibly coming from customers of
this entity. When a new customer asks to be granted access to the network,
the network operator can predict with pretty good granularity the the
impact this new traffic on the remaining bandwidth of the network, and on
the power consumption of individual motes, which allows the operator to
grant/deny, and probably charge differently.

Does this use case match what you were thinking?

Thomas

On Sat, Mar 23, 2013 at 8:13 AM,  wrote:

>  Hello Thomas, all,****
>
> ** **
>
> Regarding your point****
>
> - because of a 6TSCH node is deeply duty cycle, remote sensing applicatio=
n
> (e.g. agricultural applications) can rely on energy harvesting as power
> source.****
>
> I still need to be convinced that 6tsch allows for a lower power
> consumption than preamble sampling on very low traffic. Therefore I don=
=92t
> think we should say****
>
> =936tsch is lower power therefore makes possible new applications therefo=
re
> we should standardize 6tsch=94. This is overly simplistic.****
>
> Other arguments that were stated, such as determinism, which is mandated
> by industry automation, is a much better seller.****
>
> ** **
>
> To add another one, as I stated in an earlier phone conference, I believe
> TSCH is of interest to build mutualized sensor networks that can support
> several end customers or services. This is because one can allocate
> bandwidth to each supported service independently of the others (under so=
me
> limits). This can be modeled beforehand, a decision can be made to admit
> the new customer/service or not, and the network can be managed to alloca=
te
> temporary extra resources to maintain QoS while a technician is sent to t=
he
> field to investigate such things as node failure or severe interference.
> Granted, several node resources such as energy and memory are still share=
d
> between customers/services but TSCH allows to model and manage these much
> better than other wireless link layers.****
>
> Such a mutualized managed network is much more likely to be profitable an=
d
> makes a better use of spectrum than independent, overlaid networks fighti=
ng
> for the same wireless medium.****
>
> To a company intending to deploy, operate and manage a sensor network
> infrastructure, TSCH is good starting point.****
>
> ** **
>
> Comments?****
>
> ** **
>
> Dominique****
>
> ** **
>
> *De :* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *De la part
> de* Thomas Watteyne
> *Envoy=E9 :* jeudi 21 mars 2013 06:16
> *=C0 :* 6tsch@ietf.org
> *Objet :* Re: [6tsch] focussing on charter: use cases****
>
> ** **
>
> Pascal, all,****
>
> ** **
>
> Absolutely agreed. I believe we have started exploring quite a bit, enoug=
h
> to have a clear understanding of what we can achieve with this technology
> as a WG. So let's spend some time on use cases and building a good case t=
o
> convince an AD.****
>
> ** **
>
> We could start by listing what TSCH is "good at", and what makes it
> different from other solutions. I see the following:****
>
> - reliability: 5 9's of end-to-end reliability are commonplace.****
>
> - low-power: aggressive radio duty cycling of the mote's radio yields muc=
h
> longer lifetime in battery-powered devices.****
>
> - traffic engineering: the clear identification of resources allows for
> flow independence and QoS.****
>
> ** **
>
> Of course, from those points, industrial applications immediately come to
> mind. Yet, we could take use cases from other areas. We could for example
> take the ROLL requirement drafts as a skeleton (I'm paraphrasing some of
> the points Xavi and Alfredo made). ****
>
> ** **
>
> - industrial automation. A 6TSCH network can allow for high reliability,
> and deterministic behavior. Link over-provisioning can efficiently combat
> the unreliable nature of wireless and provide a robust communication. ***=
*
>
> - building automation. A 6TSCH network can serve as an "umbrella" network
> for a large number of sensing points in the building. These sensing point=
s
> can be owned and operated by different entities (e.g. HVAC and lighting).
> The 6TSCH network allows for the different traffic flows to stay
> independent from one another.****
>
> - because of a 6TSCH node is deeply duty cycle, remote sensing applicatio=
n
> (e.g. agricultural applications) can rely on energy harvesting as power
> source.****
>
> - A smart urban parking application can benefit from the reliabilty of
>  6TSCH network since, even though the vehicle detection sensor may be
> static, the constant movement of cars around the sensing points can cause
> the wireless environment to quickly change.****
>
> ** **
>
> Thomas****
>
> ** **
>
> On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) <
> pthubert@cisco.com> wrote:****
>
> Dear ML:****
>
>  ****
>
> The activity that we generate on the mailing list is a good indication we
> will be very successful as a WG. First thing first, though, we need to
> create the WG and need to focus a little bit on the necessary steps to ge=
t
> there.****
>
>  ****
>
> We need to put together a rough charter, and convince an AD, probably
> Adrian from Routing Area or Ted from Internet Area, that we have real
> problems to solve and that we, as a group, can provide valuable answers.
> The ADs agendas are very full all the time, but certainly peaks around th=
e
> meeting times. So we have about 2 week in front of us to prepare a solid
> case.****
>
>  ****
>
> So I suggest we step back a minute from the details of time frames and
> priorities and spend some energy on the use cases, the problems we are
> solving, and the work we have to do to get there. I notice a cool
> discussion on mobility and the particular case of a crane, well that=92s =
a
> use case. We already had centralized deterministic (hard slot) routes for
> command and control, distributed deterministic (soft slots) and non
> deterministic QoS based flows. Do we have others cases?****
>
> Cheers,****
>
>  ****
>
> Pascal****
>
>  ****
>
>  ****
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu 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 i=
nformation 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 de=
lete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messa=
ges that have been modified, changed or falsified.
> Thank you.
>
>

--047d7bf0e6f8774df704d8c25b8c
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Dominique,

Thanks for your comments. We certainly do not=
 want to be overly simplistic. When identifying use cases, I believe we sho=
uld focus on what makes TSCH different, and articulate the use cases around=
 those. As you point out, traffic differentiation is certainly very high on=
 that list.




An immediate use case is that of an entity operating an=
 "umbrella" network on which different types of traffic flow, pos=
sibly coming from customers of this entity. When a new customer asks to be =
granted access to the network, the network operator can predict with pretty=
 good granularity the the impact this new traffic on the remaining bandwidt=
h of the network, and on the power consumption of individual motes, which a=
llows the operator to grant/deny, and probably charge differently.




Does this use case match what you were thinking?
<=
div>
Thomas

On Sat, =
Mar 23, 2013 at 8:13 AM,  <dominique.barthel@orange.com>=
 wrote:














Hello Thomas, all,=



=A0<=
/p>

Regarding your point


- because of a 6TSCH node is de=
eply duty cycle, remote sensing application (e.g. agricultural applications=
) can rely on energy harvesting as power source.




I st=
ill need to be convinced that 6tsch allows for a lower power consumption th=
an preamble sampling on very low traffic. Therefore I don=92t think
 we should say


=936tsch i=
s lower power therefore makes possible new applications therefore we should=
 standardize 6tsch=94. This is overly simplistic.




Other argu=
ments that were stated, such as determinism, which is mandated by industry =
automation, is a much better seller.




=A0=



To add ano=
ther one, as I stated in an earlier phone conference, I believe TSCH is of =
interest to build mutualized sensor networks that can support
 several end customers or services. This is because one can allocate bandwi=
dth to each supported service independently of the others (under some limit=
s). This can be modeled beforehand, a decision can be made to admit the new=
 customer/service or not, and the
 network can be managed to allocate temporary extra resources to maintain Q=
oS while a technician is sent to the field to investigate such things as no=
de failure or severe interference. Granted, several node resources such as =
energy and memory are still shared
 between customers/services but TSCH allows to model and manage these much =
better than other wireless link layers.


Such a mut=
ualized managed network is much more likely to be profitable and makes a be=
tter use of spectrum than independent, overlaid networks fighting
 for the same wireless medium.


To a compa=
ny intending to deploy, operate and manage a sensor network infrastructure,=
 TSCH is good starting point.




=A0=



Comments?<=
u>


=A0=



Dominique<=
u>


=A0=





De=A0: 6tsch-bounces@ietf.org=
 [mailto:6t=
sch-bounces@ietf.org]
De la part de Thomas Watteyne

Envoy=E9=A0: jeudi 21 mars 2013 06:16

=C0=A0: 6tsch@ie=
tf.org

Objet=A0: Re: [6tsch] focussing on charter: use cases<=
/span>




=A0


Pascal, all,




=A0






Absolutely agreed. I believe we have started explori=
ng quite a bit, enough to have a clear understanding of what we can achieve=
 with this technology as a WG. So let's spend some time on use cases an=
d building a good case to convince an
 AD.






=A0






We could start by listing what TSCH is "good at=
", and what makes it different from other solutions. I see the followi=
ng:






- reliability: 5 9's of end-to-end reliability a=
re commonplace.






- low-power:=A0aggressive=A0radio duty cycling of th=
e mote's radio yields much longer lifetime in battery-powered devices.<=
u>






- traffic engineering: the clear identification of r=
esources allows for flow independence and QoS.






=A0








Of course, from those points, industrial application=
s immediately come to mind. Yet, we could take use cases from other areas. =
We could for example take the ROLL requirement drafts as a skeleton (I'=
m paraphrasing some of the points Xavi
 and Alfredo made). 






=A0






- industrial automation. A =
6TSCH network can allow for high reliability, and=A0deterministic=A0behavio=
r. Link over-provisioning can efficiently combat the unreliable
 nature of wireless and provide a robust communication.=A0=







- building automation. A 6TSCH network can serve as =
an "umbrella" network for a large number of sensing points in the=
 building. These sensing points can be owned and operated by different enti=
ties (e.g. HVAC and lighting). The 6TSCH network
 allows for the different traffic flows to stay independent from one anothe=
r.






- because of a 6TSCH node is deeply duty cycle, remo=
te sensing application (e.g. agricultural applications) can rely on energy =
harvesting as power source.






- A smart urban parking application can benefit from=
 the reliabilty of =A06TSCH network since, even though the vehicle detectio=
n sensor may be static, the constant movement of cars around the sensing po=
ints can cause the wireless environment
 to quickly change.






=A0






Thomas






=A0






On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pt=
hubert) <pthuber=
t@cisco.com> wrote:






Dear ML:

=A0


The activity that we generate o=
n the mailing list is a good indication we will be very successful as a WG.=
 First thing first, though, we need to create the WG
 and need to focus a little bit on the necessary steps to get there.=



=A0


We need to put together a rough=
 charter, and convince an AD, probably Adrian from Routing Area or Ted from=
 Internet Area, that we have real problems to solve
 and that we, as a group, can provide valuable answers. The ADs agendas are=
 very full all the time, but certainly peaks around the meeting times. So w=
e have about 2 week in front of us to prepare a solid case.




=A0


So I suggest we step back a min=
ute from the details of time frames and priorities and spend some energy on=
 the use cases, the problems we are solving, and the
 work we have to do to get there. I notice a cool discussion on mobility an=
d the particular case of a crane, well that=92s a use case. We already had =
centralized deterministic (hard slot) routes for command and control, distr=
ibuted deterministic (soft slots)
 and non deterministic QoS based flows. Do we have others cases?<=
/u>


Cheers,

=A0<=
/u>


Pascal<=
u>


=A0<=
/u>


=A0<=
/u>








_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch




=A0






______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 message=
s electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.







--047d7bf0e6f8774df704d8c25b8c--

From dominique.barthel@orange.com  Mon Mar 25 09:36:26 2013
Return-Path: 
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 2EC3621F9075 for <6tsch@ietfa.amsl.com>; Mon, 25 Mar 2013 09:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
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 NOPEi0qEKR2g for <6tsch@ietfa.amsl.com>; Mon, 25 Mar 2013 09:36:21 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5A20721F9037 for <6tsch@ietf.org>; Mon, 25 Mar 2013 09:36:20 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id AE3CD2DC154; Mon, 25 Mar 2013 17:36:19 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8F8AB23808F; Mon, 25 Mar 2013 17:36:19 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 25 Mar 2013 17:36:19 +0100
From: 
To: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: [6tsch] focussing on charter: use cases
Thread-Index: AQHOKXZb4544fW5MRUSgOucw3DT4aZi2mrvw
Date: Mon, 25 Mar 2013 16:36:18 +0000
Message-ID: <15579_1364229379_51507D03_15579_186_1_8F1D83ADCC1AC94186A867BEE9B7D91306D39889@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References:   <6194_1364051635_514DC6B3_6194_19669_1_8F1D83ADCC1AC94186A867BEE9B7D91306D39033@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.3]
Content-Type: multipart/alternative; boundary="_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39889PEXCVZYM13corpo_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421
Subject: Re: [6tsch] focussing on charter: use cases
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2013 16:36:26 -0000

--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39889PEXCVZYM13corpo_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Thomas,

This is exactly what I had in mind, thanks!

Dominique


De : 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] De la part de T=
homas Watteyne
Envoy=E9 : lundi 25 mars 2013 17:33
=C0 : 6tsch@ietf.org
Objet : Re: [6tsch] focussing on charter: use cases

Dominique,

Thanks for your comments. We certainly do not want to be overly simplistic.=
 When identifying use cases, I believe we should focus on what makes TSCH d=
ifferent, and articulate the use cases around those. As you point out, traf=
fic differentiation is certainly very high on that list.

An immediate use case is that of an entity operating an "umbrella" network =
on which different types of traffic flow, possibly coming from customers of=
 this entity. When a new customer asks to be granted access to the network,=
 the network operator can predict with pretty good granularity the the impa=
ct this new traffic on the remaining bandwidth of the network, and on the p=
ower consumption of individual motes, which allows the operator to grant/de=
ny, and probably charge differently.

Does this use case match what you were thinking?

Thomas

On Sat, Mar 23, 2013 at 8:13 AM, > wrote:
Hello Thomas, all,

Regarding your point
- because of a 6TSCH node is deeply duty cycle, remote sensing application =
(e.g. agricultural applications) can rely on energy harvesting as power sou=
rce.
I still need to be convinced that 6tsch allows for a lower power consumptio=
n than preamble sampling on very low traffic. Therefore I don't think we sh=
ould say
"6tsch is lower power therefore makes possible new applications therefore w=
e should standardize 6tsch". This is overly simplistic.
Other arguments that were stated, such as determinism, which is mandated by=
 industry automation, is a much better seller.

To add another one, as I stated in an earlier phone conference, I believe T=
SCH is of interest to build mutualized sensor networks that can support sev=
eral end customers or services. This is because one can allocate bandwidth =
to each supported service independently of the others (under some limits). =
This can be modeled beforehand, a decision can be made to admit the new cus=
tomer/service or not, and the network can be managed to allocate temporary =
extra resources to maintain QoS while a technician is sent to the field to =
investigate such things as node failure or severe interference. Granted, se=
veral node resources such as energy and memory are still shared between cus=
tomers/services but TSCH allows to model and manage these much better than =
other wireless link layers.
Such a mutualized managed network is much more likely to be profitable and =
makes a better use of spectrum than independent, overlaid networks fighting=
 for the same wireless medium.
To a company intending to deploy, operate and manage a sensor network infra=
structure, TSCH is good starting point.

Comments?

Dominique

De : 6tsch-bounces@ietf.org [mailto:6tsch-bo=
unces@ietf.org] De la part de Thomas Watteyne
Envoy=E9 : jeudi 21 mars 2013 06:16
=C0 : 6tsch@ietf.org
Objet : Re: [6tsch] focussing on charter: use cases

Pascal, all,

Absolutely agreed. I believe we have started exploring quite a bit, enough =
to have a clear understanding of what we can achieve with this technology a=
s a WG. So let's spend some time on use cases and building a good case to c=
onvince an AD.

We could start by listing what TSCH is "good at", and what makes it differe=
nt from other solutions. I see the following:
- reliability: 5 9's of end-to-end reliability are commonplace.
- low-power: aggressive radio duty cycling of the mote's radio yields much =
longer lifetime in battery-powered devices.
- traffic engineering: the clear identification of resources allows for flo=
w independence and QoS.

Of course, from those points, industrial applications immediately come to m=
ind. Yet, we could take use cases from other areas. We could for example ta=
ke the ROLL requirement drafts as a skeleton (I'm paraphrasing some of the =
points Xavi and Alfredo made).

- industrial automation. A 6TSCH network can allow for high reliability, an=
d deterministic behavior. Link over-provisioning can efficiently combat the=
 unreliable nature of wireless and provide a robust communication.
- building automation. A 6TSCH network can serve as an "umbrella" network f=
or a large number of sensing points in the building. These sensing points c=
an be owned and operated by different entities (e.g. HVAC and lighting). Th=
e 6TSCH network allows for the different traffic flows to stay independent =
from one another.
- because of a 6TSCH node is deeply duty cycle, remote sensing application =
(e.g. agricultural applications) can rely on energy harvesting as power sou=
rce.
- A smart urban parking application can benefit from the reliabilty of  6TS=
CH network since, even though the vehicle detection sensor may be static, t=
he constant movement of cars around the sensing points can cause the wirele=
ss environment to quickly change.

Thomas

On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) > wrote:
Dear ML:

The activity that we generate on the mailing list is a good indication we w=
ill be very successful as a WG. First thing first, though, we need to creat=
e the WG and need to focus a little bit on the necessary steps to get there.

We need to put together a rough charter, and convince an AD, probably Adria=
n from Routing Area or Ted from Internet Area, that we have real problems t=
o solve and that we, as a group, can provide valuable answers. The ADs agen=
das are very full all the time, but certainly peaks around the meeting time=
s. So we have about 2 week in front of us to prepare a solid case.

So I suggest we step back a minute from the details of time frames and prio=
rities and spend some energy on the use cases, the problems we are solving,=
 and the work we have to do to get there. I notice a cool discussion on mob=
ility and the particular case of a crane, well that's a use case. We alread=
y had centralized deterministic (hard slot) routes for command and control,=
 distributed deterministic (soft slots) and non deterministic QoS based flo=
ws. Do we have others cases?
Cheers,

Pascal



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


___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,

France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.

As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.

Thank you.


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39889PEXCVZYM13corpo_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Thomas,


 <=
/p>

This is ex=
actly what I had in mind, thanks!


 =
;


Dominique<=
o:p>


 =
;


 =
;




De : 6tsc=
h-bounces@ietf.org [mailto:6tsch-bounces@ietf.org]
De la part de Thomas Watteyne

Envoy=E9 : lundi 25 mars 2013 17:33

=C0 : 6tsch@ietf.org

Objet : Re: [6tsch] focussing on charter: use cases<=
/span>




 


Dominique,




 






Thanks for your comments. We certainly do not want t=
o be overly simplistic. When identifying use cases, I believe we should foc=
us on what makes TSCH different, and articulate the use cases around those.=
 As you point out, traffic differentiation
 is certainly very high on that list.






 






An immediate use case is that of an entity operating=
 an "umbrella" network on which different types of traffic flow, =
possibly coming from customers of this entity. When a new customer asks to =
be granted access to the network, the network
 operator can predict with pretty good granularity the the impact this new =
traffic on the remaining bandwidth of the network, and on the power consump=
tion of individual motes, which allows the operator to grant/deny, and prob=
ably charge differently.






 






Does this use case match what you were thinking?






 






Thomas






 




On Sat, Mar 23, 2013 at 8:13 AM, <dominique.barthel@orange=
.com> wrote:






Hello Thomas, all,


 


Regarding your point<=
/p>



- because of a 6TSCH node is deeply duty cycl=
e, remote sensing application (e.g. agricultural applications) can rely on =
energy harvesting as power source.




I still need to be convi=
nced that 6tsch allows for a lower power consumption than preamble
 sampling on very low traffic. Therefore I don’t think we should say<=
/span>


“6tsch is lower po=
wer therefore makes possible new applications therefore we should
 standardize 6tsch”. This is overly simplistic.


Other arguments that wer=
e stated, such as determinism, which is mandated by industry
 automation, is a much better seller.


 =



To add another one, as I=
 stated in an earlier phone conference, I believe TSCH is of
 interest to build mutualized sensor networks that can support several end =
customers or services. This is because one can allocate bandwidth to each s=
upported service independently of the others (under some limits). This can =
be modeled beforehand, a decision
 can be made to admit the new customer/service or not, and the network can =
be managed to allocate temporary extra resources to maintain QoS while a te=
chnician is sent to the field to investigate such things as node failure or=
 severe interference. Granted, several
 node resources such as energy and memory are still shared between customer=
s/services but TSCH allows to model and manage these much better than other=
 wireless link layers.


Such a mutualized manage=
d network is much more likely to be profitable and makes a better
 use of spectrum than independent, overlaid networks fighting for the same =
wireless medium.


To a company intending t=
o deploy, operate and manage a sensor network infrastructure,
 TSCH is good starting point.


 =



Comments?


 =



Dominique


 =





De :
6tsch-bounces@i=
etf.org [mailto:6tsch-bounces@ietf.org]
De la part de Thomas Watteyne

Envoy=E9 : jeudi 21 mars 2013 06:16

=C0 : 6tsch=
@ietf.org

Objet : Re: [6tsch] focussing on charter: use cases=









 


Pascal, all,




 






Absolutely agreed. I believe we have started exploring quite a bit=
, enough to have a clear understanding of what we can achieve with this tec=
hnology as a WG. So let's spend some
 time on use cases and building a good case to convince an AD.





 






We could start by listing what TSCH is "good at", and wh=
at makes it different from other solutions. I see the following:=







- reliability: 5 9's of end-to-end reliability are commonplace.






- low-power: aggressive radio duty cycling of the mote's=
 radio yields much longer lifetime in battery-powered devices.





- traffic engineering: the clear identification of resources allow=
s for flow independence and QoS.






 








Of course, from those points, industrial applications immediately =
come to mind. Yet, we could take use cases from other areas. We could for e=
xample take the ROLL requirement drafts
 as a skeleton (I'm paraphrasing some of the points Xavi and Alfredo made).=
 







 






- industrial automation. A 6TSCH network =
can allow for high reliability, and deterministic behavior.
 Link over-provisioning can efficiently combat the unreliable nature of wir=
eless and provide a robust communication. 






- building automation. A 6TSCH network can serve as an "umbre=
lla" network for a large number of sensing points in the building. The=
se sensing points can be owned and operated by
 different entities (e.g. HVAC and lighting). The 6TSCH network allows for =
the different traffic flows to stay independent from one another.






- because of a 6TSCH node is deeply duty cycle, remote sensing app=
lication (e.g. agricultural applications) can rely on energy harvesting as =
power source.






- A smart urban parking application can benefit from the reliabilt=
y of  6TSCH network since, even though the vehicle detection sensor ma=
y be static, the constant movement of cars
 around the sensing points can cause the wireless environment to quickly ch=
ange.






 






Thomas






 






On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:






Dear ML:


 


The activity that we generate on the mailing =
list is a good indication we will be very successful as a WG. First thing f=
irst, though, we need to create the WG
 and need to focus a little bit on the necessary steps to get there.=



 


We need to put together a rough charter, and =
convince an AD, probably Adrian from Routing Area or Ted from Internet Area=
, that we have real problems to solve
 and that we, as a group, can provide valuable answers. The ADs agendas are=
 very full all the time, but certainly peaks around the meeting times. So w=
e have about 2 week in front of us to prepare a solid case.


 


So I suggest we step back a minute from the d=
etails of time frames and priorities and spend some energy on the use cases=
, the problems we are solving, and the
 work we have to do to get there. I notice a cool discussion on mobility an=
d the particular case of a crane, well that’s a use case. We already =
had centralized deterministic (hard slot) routes for command and control, d=
istributed deterministic (soft slots)
 and non deterministic QoS based flows. Do we have others cases?


Cheers,


 


Pascal


 


 








_______________________________________________

6tsch mailing list

6tsch@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/6tsch




 










______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


France Telecom - Orange decline toute responsabilite si ce message a e=
te altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 me=
ssages that have been modified, changed or falsified.


Thank you.






 






______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.




--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39889PEXCVZYM13corpo_--

From pthubert@cisco.com  Wed Mar 27 11:15:52 2013
Return-Path: 
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 7F80521F918D for <6tsch@ietfa.amsl.com>; Wed, 27 Mar 2013 11:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 QFDa+-Caehtg for <6tsch@ietfa.amsl.com>; Wed, 27 Mar 2013 11:15:51 -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 51E5B21F910D for <6tsch@ietf.org>; Wed, 27 Mar 2013 11:15:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3328; q=dns/txt; s=iport; t=1364408150; x=1365617750; h=from:to:subject:date:message-id:mime-version; bh=PjmQsWp3bizmy3LpwiZ3B7KYUpPiW5Mec14XIwY7hTQ=; b=VjU9bF1dLnaSI5JikZVwEUE4baldwQoMFWCU/MgXUts9VkPZwW/+e1GR 3DsA4MbCH4QKQyUUaEVzhnc65s5HJXwQc1eI6wtGWBijX8hWqY0cgvEVz XPBEo7j+T9gcGUFYrm96lYuX1dx6ZiH6apzcdYrXRM7gbOeYjJJCs2AQZ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFABA3U1GtJXHB/2dsb2JhbABDgkN3wEd/Fm0HgiEBBB0QXgEMHlYmAQQbiAyeAKELiQWFYoMXYQOnboMLgig
X-IronPort-AV: E=Sophos;i="4.84,920,1355097600";  d="scan'208,217";a="192168654"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 27 Mar 2013 18:15:49 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2RIFmEl025356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Wed, 27 Mar 2013 18:15:48 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 27 Mar 2013 13:15:48 -0500
From: "Pascal Thubert (pthubert)" 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: no Call this week
Thread-Index: Ac4rFsgdWQIb6V+BSPGkf9KkoDHNPQ==
Date: Wed, 27 Mar 2013 18:15:47 +0000
Deferred-Delivery: Wed, 27 Mar 2013 18:14:00 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.98.126]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835D05FD4xmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: [6tsch] no Call this week
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Mar 2013 18:15:52 -0000

--_000_E045AECD98228444A58C61C200AE1BD835D05FD4xmbrcdx01ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear ML:

I got feedback that many would be taking the long week end off.
So let us cancel the call for this week and start fresh next week.
In the meantime, let's start a thread on problem statement from which we'll=
 derive a gap analysis

Cheers;

Pascal

--_000_E045AECD98228444A58C61C200AE1BD835D05FD4xmbrcdx01ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear ML:


 


I got feedback that many would be taking the long we=
ek end off.


So let us cancel the call for this week and start fr=
esh next week.


In the meantime, let’s start a thread on probl=
em statement from which we’ll derive a gap analysis


 


Cheers;


 


Pascal






--_000_E045AECD98228444A58C61C200AE1BD835D05FD4xmbrcdx01ciscoc_--

From sensys@cfpmail.info  Thu Mar 28 11:45:27 2013
Return-Path: 
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 385D021F8B64 for <6tsch@ietfa.amsl.com>; Thu, 28 Mar 2013 11:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.377
X-Spam-Level: 
X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 8YO2-hymSh3v for <6tsch@ietfa.amsl.com>; Thu, 28 Mar 2013 11:45:27 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C703721F88F5 for <6tsch@ietf.org>; Thu, 28 Mar 2013 11:45:23 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id hr11so7963145vcb.17 for <6tsch@ietf.org>; Thu, 28 Mar 2013 11:45:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=1cGxO+NOdSqN2mVI/6ycen3750miX2etmvUG1y7hMfc=; b=QM/pwH8iFY/Mfhr6gSolGgOWa8CAOx+rs5icDB5L0owFvBYo5jT7VmuX3S1z1WzJmN OUo8S3r37hSVvQvSdrrQis5cS0fOuJoWr3We6NpxZhyFUEuHnoKqgNdM2NCeyNb5s7Tz eQFww7/BDHhB9dFTt3wi42GbjUqYTtqSJrOvE4I0Ca1mMtTdyXpd5Dtbi7W0QhgkUwwh B+G74tJUTKt3gtjbkMhHVCYh4PIH85mrNOfQ9ysjhy3YJaW9GnkJRkLBJRaUnikz7+fu EJgiS9fplRxdelNTVqN117xZsQjm1RTxoRyFGABq/hDHf9t9zXIB9r3C55n/wWIUQhes KWKg==
MIME-Version: 1.0
X-Received: by 10.220.142.71 with SMTP id p7mr27993441vcu.3.1364496323008; Thu, 28 Mar 2013 11:45:23 -0700 (PDT)
Received: by 10.52.160.104 with HTTP; Thu, 28 Mar 2013 11:45:22 -0700 (PDT)
X-Originating-IP: [71.195.166.116]
In-Reply-To: 
References: 
Date: Thu, 28 Mar 2013 11:45:22 -0700
Message-ID: 
From: "SenSys'13 Publicity" 
To: 6tsch@ietf.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkmUmHq6xidRs8V6MTT3uw8nRSHDtyVLQUmAHJRYb9Jt0irl7vGkB+nTncA0oIwSVSLO/2K
Subject: [6tsch] CFP: SenSys 2013 -- The 11th ACM Conference on Embedded Networked Sensor Systems
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2013 18:45:27 -0000

[Apologies in advance for any cross-postings]

Dear colleagues.

There are only 2 DAYS! remaining for abstract registration.

***************************************************************************=
************************
Call For Papers
SenSys 2013---The 11th ACM Conference on Embedded Networked Sensor Systems

November 11-15, 2013
Rome, Italy
***************************************************************************=
*************************
Sensing systems are changing the way computers interact with the
physical world -- and are driving a host of new issues in computer
system design, implementation, and performance.

SenSys 2013 is the premier venue to discuss system issues raised by
emerging trends in sensing systems =96 broadly defined to include mobile
sensing, body sensing, Kinect, camera networks, RFID, and many others.

We solicit technical papers describing original ideas, ground breaking
results and/or quantified system experiences involving sensor systems.
 The conference values papers that take a broad systems perspective
rather than a narrow focus on individual components.  Of particular
interest are technical contributions that enable new and compelling
sensing applications.

Topics of interest include, but are not limited to, the following:
* Experience with real-world applications
* Innovative sensing applications (e.g., mobile healthcare,
transportation, buildings)
* New models of sensor usage (e.g., mobile sensing, body sensing, RFIDs, ro=
bots)
* Sensor data quality, integrity, and trustworthiness
* Challenges for =93Big Sensor Data=94
* Sensor data storage, retrieval, processing and management
* Data reduction, inference, and signal processing
* Fault-tolerance and reliability
* Provable correctness and performance guarantees
* Support for integrated sensing, actuation and control
* Wireless communication systems and protocols
* Energy management and energy harvesting
* Resource management and OS support
* Programming paradigms for sensing systems
* Security and privacy in sensor networks
* Time and location estimation and management

Detailed submission instructions can be found at
http://sensys.acm.org/2013/submissions/

Key Dates
These are hard deadlines: No extensions will be granted.
* Paper Registration: March 30, 2013, 11:59 pm EST.
* Paper Submission Deadline: April 6, 2013, 11:59 pm EST.
* Notification of Paper Acceptance: July 15, 2013.

General Chair
Chiara Petrioli (University of Rome 'La Sapienza')

Program Chairs
Landon Cox (Duke University)
Kamin Whitehouse (University of Virginia)

Poster Chair
Chenyang Lu (Washington University in St. Louis)
Luca Mottola (Politecnico di Milano and Swedish Institute of Computer Scien=
ce)

Demo Chairs
Emiliano Miliuzzo (AT&T Labs)
Amy Murphy (FBK)

Local Arrangements Chairs
Francesca Cuomo, Gaia Maselli, Andrea Vitaletti (University of Rome
'La Sapienza')

Finance Chair
Rasit Eskicioglu (University of Manitoba)

Publicity Chairs
Stefano Basagni (Northeastern University)
Alberto Cerpa (University of California, Merced)
Salil Kanhere (University of New South Wales)
Mike Chieh-Jan Liang (Microsoft Research Asia)

Publicaton Chair
Wendi Heizelman (University of Rochester)

Workshop Chairs
Luca Benini (ETHZ & University of Bologna)
Deepak Ganesan (UMASS Amherst)

Industrial Liaison Chairs
Jie Liu (Microsoft Research)
Adam Wolisz (Technische Universitat Berlin)

N2Women Chair
Niki Trigoni (University of Oxford)

Doctoral Colloquium Chair
Cecilia Mascolo (University of Cambridge)

Student Travel Award Chair
Pedro Marron (University of Duisburg-Essen)
Radu Stoleru (Texas A&M University)

Web Site Chair
David Boyle (Imperial College London)

Technical Program Committee
Yuvraj Agarwal (University of California, San Diego)
Jan Beutel (Swiss Federal Institute of Technology, Zurich)
Geoffrey Challen (University at Buffalo)
Tanzeem Choudhary (Cornell University)
David Chu (Microsoft Research, Redmond)
Deborah Estrin (Cornell Tech)
Wen Hu (CSIRO, Australia)
Fred Jiang (Intel Labs, China)
Nic Lane (Microsoft Research, Asia)
Jie Liu (Microsoft Research, Redmond)
Pedro Jose Marron (University of Duisburg Essen)
Cecilia Mascolo (University of Cambridge)
Luca Mottola (Politecnico di Milano and Swedish Institute of Computer Scien=
ce)
Lama Nachman (Intel Labs)
Gian Pietro Picco (University of Trento)
Raj Rajkumar (Carnegie Mellon University)
Anthony Rowe (Carnegie Mellon University)
Romit Roy Choudhury (Duke University)
Silvia Santini (Technische Universitat Darmstadt)
Mahadev Satyanarayanan (Carnegie Mellon University)
Thomas Schmid (University of Utah)
Junehwa Song (Korean Advanced Institute of Science and Technology)
Niki Trigoni (University of Oxford)
Lin Zhong (Rice University)

From pthubert@cisco.com  Fri Mar 29 10:00:31 2013
Return-Path: 
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 AD9F321F9317 for <6tsch@ietfa.amsl.com>; Fri, 29 Mar 2013 10:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6lYwmfA4TwVQ for <6tsch@ietfa.amsl.com>; Fri, 29 Mar 2013 10:00:30 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 55B6921F92B5 for <6tsch@ietf.org>; Fri, 29 Mar 2013 10:00:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42138; q=dns/txt; s=iport; t=1364576429; x=1365786029; h=from:to:subject:date:message-id:mime-version; bh=BgGRixnLWoIWFIuexehx2iUmzjK1bYUqtu4I4m4lgvM=; b=WjFhjKmiZGyaB4NHUWDaMbcDiJgrpVePQYzeOKJwFjOY7OzSdLnTlCkD bTXfjS9U3RyyqYUcnlRBPtqao1tpVjnZyTMFLKJoR4j1KLiQNfuqXA5fC tfd+hcVDCm0Ki25NZfhHLx4EUDLJJq+fJsNXvBUK08wBaatBWnJYWA1pK M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFALzHVVGtJV2a/2dsb2JhbABDgkN3vyiBChZ0giEBBC1eASoWAT8mAQQbiAyfA6EBiQ2FaYMXYQOndoMLgig
X-IronPort-AV: E=Sophos;i="4.87,374,1363132800";  d="scan'208,217";a="193012269"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 29 Mar 2013 17:00:21 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2TH0JFT016926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Fri, 29 Mar 2013 17:00:19 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Fri, 29 Mar 2013 12:00:19 -0500
From: "Pascal Thubert (pthubert)" 
To: "6tsch@ietf.org" <6tsch@ietf.org>
Thread-Topic: Problem Statement
Thread-Index: Ac4snqmG4qAbAH7VRrO/jcsMdbDAqQ==
Date: Fri, 29 Mar 2013 17:00:18 +0000
Deferred-Delivery: Fri, 29 Mar 2013 16:59:00 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.93.37]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835D07C7Dxmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: [6tsch] Problem Statement
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: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2013 17:00:31 -0000

--_000_E045AECD98228444A58C61C200AE1BD835D07C7Dxmbrcdx01ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi :

Please find a list I xrefed from the use cases we discussed at the call and=
 over the ML; , what did I miss?
Please fire at will...

P1: Optimized Multipath hard tracks
*       From
-      wireless process control; low rate control loops
-      Smart cities; WSN service provider
-      Vehicular; control IHM
*       Optimized =3D> PCE
*       Allocation may be handled by a tier
*       6TUS must apply the required slots and move existing if needed

P2: Distributed Routing, soft tracks
< unsure which use cases?>
*       =3D> RSVP or similar

P3 : Distributed Routing (best effort)
*        From
-      Industrial; non production phases
-      Industrial, Smart cities, home; monitoring
-      Commercial; asset tracking
-      Home, Commercial; security
*       Distributed =3D> RPL

P4: Mobility (best effort)
*       From
-      Industrial; mobile worker
-      Commercial; asset tracking
*       Distributed =3D> RPL

P5: Dynamic slot allocation
*       From
-      Industrial; alerts
-      Smart cities; Road/Street control
-      Smart cities; Smart Urban Parking
*       6TUS must adapt to bursts
*       Need to be faster than transport reaction

P6: Backbone
*       From
-      Industrial; large plant
*       Renumbering is not an option
*       One IPv6 subnet incorp. WSNs and backbone
*       Need to mark the packet for Diffserv

P7: Large/Deep Mesh
*       From
-      Smart cities; city lights monitoring
-      Building automation;
*       RPL / distributed
*       Need different PHYs to get range

P8: Coexistence with legacy
*       From
-      industrial (ISA100.11a, wiHART...)
*       Maybe achieved well enough by TSCH MAC already
*       May be achieved by channel white/black list
*       No goal: sync various networks and W/B list at the granularity of t=
he slot

Cheers,

Pascal





--_000_E045AECD98228444A58C61C200AE1BD835D07C7Dxmbrcdx01ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi :


 


Please find a list I xrefed from the use cases we di=
scussed at the call and over the ML; , what did I miss?


Please fire at will…


 


P1: Optimized Multipath hard tracks



•      
From



–     
wireless process control; low rate control l=
oops



–     
Smart cities; WSN service =
provider



–     
Vehicular; control IHM 



•      
Optimized =3D> PCE



•      
Allocation may be handled by a tier



•      
6TUS must apply the required slots and move =
existing if needed


 


P2: Distributed Routing, soft trac=
ks


< unsure which use cases?>



•      
=3D> RSVP or similar


 


P3 : Distributed Routing (best effort)



•      
 From



–     
Industrial; non production=
 phases



–     
Industrial, Smart cities, =
home; monitoring



–     
Commercial; asset tracking=




–     
Home, Commercial; security=




•      
Distributed =3D> RPL


 


P4: Mobility (best effort)



•      
From



–     
Industrial; mobile worker<=
/span>



–     
Commercial; asset tracking=




•      
Distributed =3D> RPL


 


P5: Dynamic slot allocation



•      
From



–     
Industrial; alerts<=
o:p>



–     
Smart cities; Road/Street =
control



–     
Smart cities; Smart Urban =
Parking 




•      
6TUS must adapt to bursts<=
/span>



•      
Need to be faster than transport reaction


 


P6: Backbone



•      
From



–     
Industrial; large plant



•      
Renumbering is not an opti=
on



•      
One IPv6 subnet incorp. WSNs and backbone



•      
Need to mark the packet for Diffserv


 


P7: Large/Deep Mesh



•      
From



–     
Smart cities; city lights =
monitoring



–     
Building automation;



•      
RPL / distributed



•      
Need different PHYs to get range<=
/p>

 


P8: Coexistence with legacy



•      
From



–     
industrial (ISA100.11a, wiHART…)<=
/o:p>



•      
Maybe achieved well enough by TSCH MAC alrea=
dy



•      
May be achieved by channel white/black list<=
o:p>



•      
No goal: sync various networks and W/B list =
at the granularity of the slot


 


Cheers,


 


Pascal


 


 


 


 






--_000_E045AECD98228444A58C61C200AE1BD835D07C7Dxmbrcdx01ciscoc_--