Xavi - sorry I've been neglecting 6TiSCH lately. You don't need DSN to match packet and ACK - they use the same ASN so link-layer security will make sure packet matches ACK.
Otherwise +1 On Tue, Sep 8, 2015 at 11:38 PM, Xavier Vilajosana < [email protected]> wrote: > Hi Pascal, All, > > thanks. I addressed your comments. > > As a note about this: > > > >>>>>> > > I had second thoughts about the > > Number of available frequencies | 16 > > > > Shouldn’t we allow a given configuration to blacklist / whitelist some ? > > >>>>>>>> > > > I would prefer to let it as is, i.e we say we have 16 available > frequencies, but we do not restrict to use all of them or a subset. We just > say that 16 are available. > > Another important point that is missing is related to this comment pointed > out by Jose Angel Miranda. > > >>>>>>>>>>>>>>>>> > > The last topic has to do with the periodic beacon addressing format. > Following the standard ieee802.15.4e-2012, point 5.1.6.2 “Reception and > rejection”: “…If a destination PAN identifier is included in the frame, it > shall match *macPANId *or shall be the broadcast PAN identifier…” > > Having a not associated mote, which does not have macPanId yet, would not > be able to filter correctly the periodic beacon transmitted by a > (PAN)Coordinator, which follows draft-ietf-6tisch-minimal-11. > > > We propose the use of the next combination for a periodic beacon in a TSCH > network (following table 2a in [IEEE802154-2012]): > > - Sequence Number: Not Present (not necessary). > > - Destination PANID: Not Present. > > - Destination Address: Not Present. > > - Source PANID: Present. > > - Source Address: Present (Short mode). > > >>>>>>>>>>>>>>>>>> > > My proposal here is something in the middle. (We want Sequence Numbers to > match packet and ack). We want long addresses to avoid a Short->Long address > mapping service in minimal. > > The PAN ID Compression bit in a BEACON frame MUST indicate that the Source > PAN ID is "Present" and the Destination PAN ID is "Not Present". The source > and destination address fields MUST be filled with an extended address (64 > bit) and this be indicated in the corresponding Frame Control field. > > Note also that the first sentence of this section enforces the following: > > "The IEEE802.15.4 header of all frames MUST include the Sequence Number > field, the Source Address field and the Destination Address field. Frame > Version field MUST be set to 0b10 (Frame Version 2)." > > > Please provide your input on this topic (specially those having running code > and networks already deployed). > > Regards, > > Xavi > > > > > > 2015-09-07 9:11 GMT+02:00 Pascal Thubert (pthubert) <[email protected]>: > >> Hello Xavi: >> >> >> >> I like this text since it makes the normative text mostly independent on >> IEEE specs and their evolution. >> >> >> >> There seems to be an agreement in Prague that the best direction to sort >> the issues with -2011 would be to align to the next revision so that >> everybody is ready for 802.15.4-2015. I’ve been wondering how and where to >> reflect that, like a few words in the annex with the IE examples. Any >> suggestion? >> >> >> >> >> >> Some quick notes: >> >> >> >> >> >> >> >> The packet formats are specific for the [IEEE802154-2012] >> >> revision and MAY vary in future releases of the IEEE standard. >> >> >> >> >> >> I’d suggest to lowercase that MAY, this text is not normative. On the >> side, I’d also lowercase the text in the introduction, in particular the >> MUST. >> >> >> >> >> >> >> >> >> >> I had second thoughts about the >> >> Number of available frequencies | 16 >> >> >> >> Shouldn’t we allow a given configuration to blacklist / whitelist some ? >> >> >> >> >> >> >> >> >> >> >> >> Looking at section 4, I’d rather indicate what the goal is as opposed to >> how it is encoded and then indicate how it is encoded in the current IEEE >> specs. e.g: >> >> >> >> >> >> the PAN ID Compression bit MUST be set to 0b0. According to the >> >> Table 2a in [IEEE802154-2012], this translates into the >> >> Destination PAN ID field being "Present" and the Source PAN ID >> >> field being "Not Present". >> >> >> >> This text has an expectation on encoding that may change. Suggestion is >> to change to: >> >> >> >> the PAN ID Compression MUST indicate that the >> >> Destination PAN ID field is "Present" and the Source PAN ID >> >> field is "Not Present". With [IEEE802154-2012] and according to >> >> Table 2a, this is accomplished by setting the PAN ID Compression >> >> bit to 0b0. >> >> >> >> >> >> >> >> Unicast frames sent to a unicast MAC destination address request an >> >> acknowledgment. >> >> >> >> Somehow this sentence was truncated? >> >> >> >> >> >> One RECOMMENDED way to achieve this in an >> >> interoperable fashion is to set Sp to 2*ETX. >> >> >> >> Just a reminder that we discussed in Prague that we should use (3*ETX -2) >> so that an ETX of A would result in MINIMUM_STEP_OF_RANK of 1 >> >> >> >> >> >> >> >> >> >> All the best, >> >> >> >> Pascal >> >> >> >> *From:* 6tisch [mailto:[email protected]] *On Behalf Of *Xavier >> Vilajosana >> *Sent:* lundi 7 septembre 2015 05:30 >> *To:* [email protected] >> *Cc:* Robert Cragie <[email protected]>; José Ángel Miranda < >> [email protected]>; Jonathan Simon <[email protected]>; Pat Kinney < >> [email protected]> >> *Subject:* Re: [6tisch] comments on 15.4 header fields in minimal >> >> >> >> Dear all, >> >> >> >> after the last WG webex meeting on Friday we decided to finalize this >> discussion and come out with a proposal on the IEEE802.15.4 specific header >> fields and what minimal should say about that. >> >> >> >> the threads where this is being discussed are: >> >> https://mailarchive.ietf.org/arch/msg/6tisch/2pXzQH7n_6EjvVo05QlOXnzSG3c >> >> >> >> and >> >> https://mailarchive.ietf.org/arch/msg/6tisch/9GslRkNZYLECdIWwwU0QqD-XlEI >> >> >> >> >> >> My proposal is to find a text for minimal that does not restrict the >> implementation to any version of 15.4 but instead indicates that the (PANID >> Compression bit) is used according to the underlying 15.4 version >> implemented. >> >> >> >> here a proposal: >> >> >> >> "The IEEE802.15.4 header of all frames MUST include the Sequence Number >> field, the Source Address field and the Destination Address field and only >> the Destination PANID. Frame Version field MUST be set to 0b10 (Frame >> Version 2). >> >> When using DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types the source and >> destination address fields MUST be filled with an extended address (64 bit) >> and this be indicated in the corresponding Frame Control field. The >> Destination PANID MUST be present, the Source PANID MUST be elided and the >> PANID Compression bit MUST be set or clear according to the specific >> IEEE802.15.4 implementation. " >> >> >> >> As per Jose (Kirale) email there are several cases where this >> implementation would require a special handling of packets when running in >> minimal compliant mode. Although this might work, maybe is time to also >> make things simple and not force another set of IF cases to support that >> mode. >> >> >> >> Finally, note that this is for minimal, which is a fallback mode of >> operation or used for initial interop testing. This means that this mode of >> operation is not the one that will be running in most of the networks all >> the time but instead will be switched on when something fails or the >> network initializes. >> >> >> >> regards, >> Xavi >> >> >> >> 2015-07-27 11:00 GMT+02:00 Robert Cragie <[email protected]>: >> >> For some reason, it was deemed necessary to change PAN ID compression in >> 802.15.4-2012 for frame version 2 but there is an issue with the case where: >> >> >> >> * both addresses are present >> >> * either or both is a short address >> >> * PAN ID compression is set to 1 >> >> >> >> In this case the inferred PAN ID is 0xffff but it is not possible to >> distinguish an identical short address which may be allocated in different >> PANs. So I believe the decision was to keep the original format for PAN ID >> compression where either or both are short addresses but to change the >> behaviour if both addresses are extended addresses. I have already pointed >> out that this is a significant change from frame version 0/1 and changes >> the meaning for PAN ID compression. See the analysis document I sent out >> earlier. >> >> >> >> I don't actually see how 802.15.4e-2012 Table 2a can actually be used as >> it is erroneous as described above. I would be interested to know if anyone >> is doing it this way, especially using PAN ID compression set to 1. >> >> >> >> Robert >> >> >> >> On 27 July 2015 at 05:52, Xavier Vilajosana < >> [email protected]> wrote: >> >> Hi, >> >> >> >> we discussed this concern at the IETF meeting. In minimal we wanted to >> support what is already standardized (15.4e-2012) but it seems that if we >> make things align to 2012 then we won't be compatible with 2015. If we try >> to make the text less specific aiming to have people use the table they >> want we loose some how the sense of minimal as different people >> implementing it will have different configurations (specially PIDC bits >> set). >> >> >> >> So, what do we do? >> >> >> >> >> >> >> >> 2015-07-26 2:50 GMT+02:00 Jonathan Simon <[email protected]>: >> >> I noticed I said 15.4-2012 in my previous email. I meant 15.4e-21012 in >> case it wasn't clear. >> >> >> >> >> >> On Sat, Jul 25, 2015 at 11:39 AM, Robert Cragie < >> [email protected]> wrote: >> >> I too have some concerns with the way the PAN ID compression is used for >> frame version 2. Please see attached analysis regarding PAN ID compression. >> >> >> >> Robert >> >> >> >> On 24 July 2015 at 21:00, Jonathan Simon <[email protected]> wrote: >> >> Pat - I’m noticing some differences between the proposed table and the >> one in 15.4-2012. >> >> >> >> In 15.4-2012, the last 2 rows of table 2a are >> >> >> >> SRC addr DST addr SRC PAN DST PAN PIDC >> >> Present Present Not Present Present 0 (row 12) >> >> Present Present Not Present Not Present 1 (row 13) >> >> >> >> In the proposed table, rows 12-14 correspond to the 2012 row 12 case >> >> >> >> SRC addr DST addr SRC PAN DST PAN PIDC >> Extended Short Not Present Present 1 >> Short Extended Not Present Present 1 >> Short Short Not Present Present 1 >> >> >> >> So the PIDC bit is inverted from the previous version for some address >> sizes, but for both extended addresses (new table row 7), you keep the >> original sense: >> >> >> >> SRC addr DST addr SRC PAN DST PAN PIDC >> Extended Extended Not Present Present 1 >> >> >> >> This breaks backward compatibility for older applications that weren’t >> considering address size. >> >> >> >> There is no row in the new table that corresponds to 2012 row 13 for >> mixed or short addresses. This breaks our existing IP product >> implementation. >> >> >> >> -- >> Jonathan >> >> >> >> On Jul 21, 2015, at 11:26 PM, Pat Kinney < >> [email protected]> wrote: >> >> >> >> As per our 6tisch meeting yesterday concerning the PAN ID compression bit >> table, I have attached an IEEE 802.15 document showing the changes to the >> latest revision draft. This document will act as guidance to the Technical >> Editor to modify the revision draft. In summary, it was agreed that frames >> of version numbers “0” or “1" should revert to the instructions stated in >> IEEE 802.15.4-2011. For frame version “2", new text will be inserted into >> the revision declaring the rules in a non-ambiguous fashion. >> >> >> >> I would ask those interested in setting the header bits to read this >> document and respond with critiques or questions. >> >> >> >> Thanks, Pat >> >> >> >> Pat Kinney >> >> *Kinney Consulting LLC* >> >> IEEE 802.15 WG vice chair, TG chair >> >> ISA100.11a WG chair >> >> O: +1.847.960.3715 >> >> [email protected] >> >> >> >> <15-15-0561-03-0mag-yet-another-document-explaining-pan-id-compression >> (1).docx> >> >> >> >> On 21, Jul2015, at 12:46, Xavier Vilajosana < >> [email protected]> wrote: >> >> >> >> Hi, >> >> >> >> From the discussion today, the section mandating the use of certain 2012 >> specific configuration needs to be changed so we can be independent to the >> evolution of the 15.4 spec. >> >> >> >> The current text is: >> >> >> >> The IEEE802.15.4 header of all frames MUST include the Sequence Number >> field, the Source Address field and the Destination Address field. >> >> In the Frame Control Field, this translates to: >> >> >> >> the Frame Version field MUST be set to 0b10 (Frame Version 2) >> >> >> >> the Sequence Number Suppression bit MUST be set to 0b0 >> >> >> >> the Source Addressing Mode MUST set to 0b11 (long address) >> >> >> >> the Destination Addressing Mode MUST set to 0b11 (long address) except >> for the broadcast address for which Destination Addressing Mode SHOULD set >> to 0b10 (short address). The use of long addresses is a REQUIRED as no >> association procedure is defined in this document. >> >> >> >> the PAN ID Compression bit MUST be set to 0b0. According to the Table 2a >> in IEEE802154-2012 this translates into the Destination PAN ID field being >> "Present" and the Source PAN ID field being "Not Present". >> >> >> >> I propose the following text which I think is aligned with what has been >> commented during the discussion. >> >> >> >> >> >> The IEEE802.15.4 header of all frames MUST include the Sequence Number >> field, the Source Address field and the Destination Address field and only >> the Destination PANID. Source and destination address fields MUST be filled >> with an extended address (64 bit) and this be indicated in the >> corresponding Frame Control field. In case of a destination broadcast >> address, the address field MUST be filled by a short addresses (16bit). The >> Destination PANID MUST be present and the Source PANID MUST be elided. >> >> >> >> >> >> Would that work? >> >> >> >> regards, >> >> Xavi >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> >> >> >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> >> >> >> >> > > -- -- Jonathan Simon Director of Systems Engineering Linear Technology, Dust Networks product group 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 (510) 400-2936 (510) 489-3799 FAX [email protected]
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
