Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFBA1A1B28 for <6tisch@ietfa.amsl.com>; Mon, 18 Jan 2016 14:50:18 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkJbaL45lx_8 for <6tisch@ietfa.amsl.com>; Mon, 18 Jan 2016 14:50:16 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5781A1B27 for <6tisch@ietf.org>; Mon, 18 Jan 2016 14:50:15 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id a85so551004243ykb.1 for <6tisch@ietf.org>; Mon, 18 Jan 2016 14:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8u1DZ9NGSzvkwKHxD1RZhBgafALN8m3E/bIvQZhkD/0=; b=Chui0KauTiNtXsOEAPcI6DK3LiFPQCW6pIAFW6F010Mbye7OZCQnT8hz5jMvFRetZP sF8t3q/Uc9B0Vhq6ikIqtSN5D9y+kk/dzo5wfnv1AaQ4e3+Z//taX2k5hjNG5VSUPHFh S07iJhkok1/s+wjIrOvm9GtVv7SqyQQg62WVjuLbN+Gv+UMe012C5DXPDHwXTI9+PICv k2ndvIg4W8ecTiF6Gv2V+7UAtiCmFbN95eLJ1v2o05qPC2tKU/wW7BTiR6tbr/uz3fxw BZA3FAD7m+9ROVSrLzR3KoF3scWzBt9j9+6Jj0N7jHamXiDgrrUTxm7kU62wtg0m7ORm LjLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8u1DZ9NGSzvkwKHxD1RZhBgafALN8m3E/bIvQZhkD/0=; b=erZxlhfxpghCZNNrZwFbl9XJLFzTbcmaWtNuC0vNRPN5A6mk5l87IRqt+YK0ZopS3B 4NfcJRwu72nydtOV+NOspRdLQO7WRLdFQndIIqLhuWRZ1D3E4ShpwKFTXuQEW6+9iDHg jzIAijqqhOc7p3yH7JI/SHQReB0136wtzJxcJxQq0KdvoAxs3GjBVCDtlNwUP0djjbFb uO8df+ET7xgRu6Jga9JO9G16PDi7tQmF/aL2hSpu/N9eYRLTFScpE5ytaKlgNrQGjr22 Y+7ZfOOItkfPy7TnUc7OHnIFLyCei1V3pKIm94vJvbWvIseZiwYattUZpcdI6YgMm5oN qgEw== X-Gm-Message-State: ALoCoQnA0Kj4Oce4YwC8AqCaq5dDPnQiUovl3HCjnTPl11o/QvQPCa4zNL7fEyllB3YKjEVxyix91n4yUE7HubsFHBtFnnbVOA== MIME-Version: 1.0 X-Received: by 10.37.89.135 with SMTP id n129mr6373013ybb.102.1453157415191; Mon, 18 Jan 2016 14:50:15 -0800 (PST) Received: by 10.37.201.5 with HTTP; Mon, 18 Jan 2016 14:50:15 -0800 (PST) In-Reply-To: <6181EE71-BC3A-4465-854F-1418FC6FFA35@kinneyconsultingllc.com> References: <86A12C46-388F-4099-9347-C7EAEF123E4B@kinneyconsultingllc.com> <645244049.3673071.1452546283479.JavaMail.yahoo@mail.yahoo.com> <6181EE71-BC3A-4465-854F-1418FC6FFA35@kinneyconsultingllc.com> Date: Mon, 18 Jan 2016 23:50:15 +0100 Message-ID: From: Tengfei Chang To: "pat.kinney@kinneyconsultingllc.com" Content-Type: multipart/alternative; boundary=001a1140fd5a89164b0529a393af Archived-At: Cc: thejaswi Chandrashekhar , Palattella Maria Rita <6tisch@ietf.org>, Plugtests Subject: Re: [6tisch] Typeof sixtop subIE:short or long X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 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" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 22:50:19 -0000 --001a1140fd5a89164b0529a393af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Pat, thanks for the clarifying this! If so, I would like to suggest we use the option that omitting the terminator to make it easier for the plugtest. The format of 6P will be : *Bits: 0-10* *11-14* *15* *16-23* *24-27* *28-31* *32-39* *octets* Payload IE Content Length Group ID Type (0b1) Sub-type ID Ver Code SFID Other field Payload IE Payload IE Content Does everyone agree with it? Please let me know if you have any suggestion on it. Thanks! Tengfei On Mon, Jan 18, 2016 at 8:40 PM, pat.kinney@kinneyconsultingllc.com < pat.kinney@kinneyconsultingllc.com> wrote: > As per 802.15.4-2015, the only time the Payload Termination IE is require= d > is when both the Payload IE and Data Payload are present. Given that the= re > is no payload following the 6P payload IE, the terminator may be omitted. > > Pat > > > > On 18, Jan2016, at 13:19, Tengfei Chang wrote: > > Hi all, > > Sorry to ask question again on the recommends document! I still have a > question about why the payload IE is terminated by a termination IE? > > According to the IEEE802.15.4e-2012 on section 5.2.4.22. > > > *5.2.4.22 IE List Termination IE* > *......* > * If an unformatted payload follows the Payload IE list, then the payload > IE list is terminated with a list termination IE (ID =3D 0xf) that has a > content length of zero. Otherwise the terminator may be omitted* > > Since there is no payload following the 6P payload IE, the terminator > may be omitted. Is there specific reason why we don't do that? > Let me know if this is already discussed somewhere so I can refer to. > Thanks! > > Regard, > Tengfei > > > On Sun, Jan 17, 2016 at 8:50 PM, Tengfei Chang > wrote: > >> Thanks all for the comments! Then we will use the recommended format >> (second one) on the plugtest! >> >> Tengfei >> >> On Mon, Jan 11, 2016 at 10:04 PM, Qin Wang wrote= : >> >>> I think both of the two format are fine. But, if IEEE802.15 recommends >>> the second one, I think we should choose the second. >>> >>> Thanks >>> Qin >>> >>> >>> On Monday, January 11, 2016 11:17 AM, " >>> pat.kinney@kinneyconsultingllc.com" >>> wrote: >>> >>> >>> Thank you for the figures, I agree on both, especially the second one. >>> The advantages of the recommended approach are: one octet shorter for c= ase >>> of single subtype ID and 256 available subtype ID addresses for any len= gth. >>> >>> Sincerely, Pat >>> >>> On 11, Jan2016, at 9:19, Tengfei Chang wrote: >>> >>> Hi Pat, all, >>> >>> I would like to make sure whether this format will be the right format >>> for the plugtest and everyone will agree. The attached is the document >>> 15-15-0939-02. >>> >>> There are two options for the format we will use in the plugtest: >>> >>> 1. we use what defined in >>> https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-04, which >>> use the format defined in >>> IEEE802.15.4e-2012, section 5.2.4.3 (page 81). If we decide to use this >>> one, we need short/ long type of the subIE. >>> >>> >>> *Bits: 0-10* >>> *11-14* >>> *15* >>> *Octets: 2* >>> *32-35* >>> *36-39* >>> *40-47* >>> *Octets* >>> *Bits: 0-10* >>> *11-14* >>> *15* >>> Payload IE Content Length >>> Group ID >>> Type (0b1) >>> Length >>> Sub-type ID >>> Type >>> Ver >>> Code >>> SFID >>> other field >>> Length >>> (0x00) >>> Group ID (0xf) >>> Type (0b1) >>> Payload IE >>> Payload IE Content >>> Payload Termination IE >>> >>> >>> 2. we use what define in document 15-15-0939-02, which use the format >>> defined in last page of the document: >>> For example the 6P command defined in sublayer draft: >>> >>> the payload will be: >>> >>> *Bits: 0-10* >>> *11-14* >>> *15* >>> *16-23* >>> *24-27* >>> *28-31* >>> *32-39* >>> *octets* >>> *Bits: 0-10* >>> *11-14* >>> *15* >>> Payload IE Content Length >>> Group ID >>> Type (0b1) >>> Sub-type ID >>> Ver >>> Code >>> SFID >>> other field >>> Length >>> (0x00) >>> Group ID (0xf) >>> Type (0b1) >>> Payload IE >>> Payload IE Content >>> Payload Termination IE >>> >>> Do we agree on the second one? >>> >>> Tengfei >>> >>> On Fri, Jan 8, 2016 at 5:56 PM, Tengfei Chang >>> wrote: >>> >>> I see. Thanks a lot Pat for the information! I found the document you >>> mentioned. I will update the format in the Golden Images. >>> >>> Have a good day! >>> Tengfei >>> >>> On Fri, Jan 8, 2016 at 5:25 PM, pat.kinney@kinneyconsultingllc.com < >>> pat.kinney@kinneyconsultingllc.com> wrote: >>> >>> Tengfei; >>> >>> The IEEE 802.15 IG 6T recommended a format for sub-IEs in document >>> 15-15-0939-02 sent to this reflector on 30 November 2015. The followin= g is >>> an excerpt from that document: >>> "Accordingly, the IEEE 802.15 IG 6T recommends that the IETF use an >>> alternate scheme that restricts each Payload IE to only one sub-type ID= and >>> content, i.e. no nesting. The advantages of this recommended scheme is >>> that it eliminates one octet from the total Payload IE, it allows a ful= l >>> 256 sub-type IDs, and each sub-type length can be up to 2046 octets.=E2= =80=9D >>> Therefore, if 6tisch adopts the above recommendation, there would be no >>> long or short types. >>> >>> Pat >>> >>> Pat Kinney >>> *Kinney Consulting LLC* >>> IEEE 802.15 WG vice chair, SC chair >>> ISA100 co-chair, ISA100.20 chair >>> O: +1.847.960.3715 >>> pat.kinney@kinneyconsultingllc.com >>> >>> On 8, Jan2016, at 10:14, Tengfei Chang wrote: >>> >>> Hello all, >>> >>> As I mentioned on the Call, the 6top sublayer draft seems didn't defin= e >>> the type of subIE used by 6P command ,long or short type? Let me know = if I >>> missed it from the draft! Thanks you! >>> >>> Regard, >>> Tengfei >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> <15-15-0939-02-0000-IETF_6tisch_IE_Information.docx> >>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >>> >> > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --001a1140fd5a89164b0529a393af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Pat, thanks for the clarifying this!

If so, I would like to suggest we use the option that omitting the termina= tor to make it easier for the plugtest. The format of 6P will be :

Bits: 0-10

 11-14

 15

 16-23

 24-27

 28-31

 32-39

 octets

Payload IE Content Length

 Group ID

 Type (0b1)

 Sub-type ID

Ver

 Code

SFID

 Other field

Payload IE

Payload IE Content

Does everyone agree with it? Please let me k= now if you have any suggestion on it. Thanks!

Teng= fei


On Mon, Jan 18, 2016 at 8:40 PM, pat.kinney@kinneyconsultingllc.com <pat.kinney@kinneyconsultingllc.com> wrote:
As per 802.= 15.4-2015, the only time the Payload Termination IE is required is when bot= h the Payload IE and Data Payload are present.=C2=A0 Given that there is no= payload following the 6P payload IE, the terminator may=C2=A0be omitted.

Pat
<= /font>


On 18, Jan2016, at 13:19, Tengfei Chang <tengfei.chang@gmail.com&= gt; wrote:

Hi all,

Sorry = to ask question again on the recommends document! I still have a question a= bout why the payload IE is terminated by a termination IE?

According to the IEEE802.15.4e-2012 on section 5.2.4.22.

5.2.4.22 IE List Terminat= ion IE
......
=C2=A0If an unformatted payload foll= ows the Payload IE list,=C2=A0then the payload IE list is terminated with a= list termination IE (ID =3D 0xf) that has a content length of zero. Otherwise the terminator may be omitted

= Since there is no payload following the 6P payload IE, the terminator may= =C2=A0be omitted. Is there specific reason why we don't do that?
Le= t me know if this is already discussed somewhere so I can refer to. Thanks!=

Regard,
Tengfei


On Sun, Jan 17, 2016 at 8:50 PM, Tengfei= Chang <tengfei.chang@gmail.com> wrote:
Thanks all for the comments! Then we w= ill use the recommended format (second one) on the plugtest!

Tengfei

On Mon, Jan 11= , 2016 at 10:04 PM, Qin Wang <qinwang6top@yahoo.com> wro= te:
I think both of the two format are fine. But, if IEEE802.15 recommen= ds the second one, I think we should choose the second.

Thanks
Qin

On Monday, January 11, 2016 11:17 AM, "pat.kinney@kinne= yconsultingllc.com" <pat.kinney@kinneyconsultingllc.com> wr= ote:


Thank you for the figures, I= agree on both, especially the second one.=C2=A0 The advantages of the reco= mmended approach are: one octet shorter for case of single subtype ID and 2= 56 available subtype ID addresses for any length.

Sincerely, Pat

On 11, = Jan2016, at 9:19, Tengfei Chang <tengfei.chang@gmail.c= om> wrote:

= Hi Pat, all,

I would l= ike to make sure whether this format will be the right format for the plugt= est and everyone will agree. The attached is the document 15-15-0939-02.

There are two options for the format we will use in the pl= ugtest:

1. we use what defined in=C2=A0https://tools.ietf.org/html/draft-wang-6ti= sch-6top-sublayer-04, which use the format defined in=C2=A0
IEEE802.15.4e-2012, section 5.2.4.3 (page 81). If= we decide to use this one, we need short/ long type of the subIE.


=
Bits: 0-10
11-14
15
Octets: 2
32-35
36-39
40-47
Octets
= 		<= div>Bits: 0-10
1= 1-14
15
Payload IE Content = Length
Group ID
Type (0b1)<= /div>
Length
Sub-typ= e ID
<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:Cambria,serif;col= or:windowtext">Type
Ver
=
Code
SFID
other field
Length=C2=A0
(0x00)
Group ID (0xf)
Type (0b1)
Payload IE
Payload IE Content
Payload Termination IE


2. we use wh= at define in document 15-15-0939-02, which use the format defined in last p= age of the document:
For example the 6= P command defined in sublayer draft:
<= br clear=3D"none">
the payload will be= :

Payload IE Content Length
Type (0b1)
Bits: 0-10
11-14
= 15
16-23
24-27
28-31<= /span>
32-39
octets
Bits: 0-10<= /div>
11-14
15
Group ID
= Type (0b1)
Sub-type = ID
Ver
Code
SFID
other field
Length= =C2=A0
(0x00)
Group ID (0xf)
Payload IE
Payload IE Content<= /span>
Payload Termination IE
<= /font>

Do we agree on the second one?

Ten= gfei

On Fri, = Jan 8, 2016 at 5:56 PM, Tengfei Chang <tengfei.chang@gmail.com> wrote:
I see. Thanks a lot Pat for the information! I= found the document you mentioned. I will update the format in the Golden I= mages.=C2=A0

Have a good day!
=
Tengfei

Tengfei;

T= he=C2=A0IEEE 802.15 IG 6T=C2=A0recommended a format for sub-IEs in document= 15-15-0939-02 sent to this reflector on 30 November 2015.=C2=A0 The follow= ing is an excerpt from that document:
"Accordingly= , the IEEE 802.15 IG 6T recommends that the IETF use an alternate scheme that= restricts each Payload IE to only one sub-type ID and content, i.e. no nesting.=C2=A0= The advantages of this recommended scheme is that it eliminates one octet from the total Payload IE, it allows a full 256 sub-type IDs, and each sub-type length can be up to 2046 octets.=E2=80=9D
Therefore, if 6tisch ad= opts the above recommendation, there would be no long or short types.
=

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, SC chair
IS= A100 co-chair, ISA100.20 chair

On= 8, Jan2016, at 10:14, Tengfei Chang <tengfei.chang@gm= ail.com> wrote:

<= div dir=3D"ltr">Hello all,=C2=A0

As I men= tioned on the Call, the 6top sublayer draft seems didn't =C2=A0define t= he type of subIE used by 6P command ,long or short type?=C2=A0 Let me know = if I missed it from the draft! Thanks you! =C2=A0

Regard,=C2=A0
Tengfei
_______________________________________________
6tisch ma= iling list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6ti= sch








<15-15-0939-02-0000-IETF_6tisch_IE_Information.docx>


__________= _____________________________________
6tisch mailing list=
6tisch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/6tisch




_______________________________________________
6tisch mailing list
<= a href=3D"mailto:6tisch@ietf.org" target=3D"_blank">6tisch@ietf.org
= = https://www.ietf.org/mailman/listinfo/6tisch

<= /div>
--001a1140fd5a89164b0529a393af--