Pat - just one point below. Robert
On 19 June 2015 at 15:22, Pat Kinney <[email protected]> wrote: > I have been reading these emails on IE Headers with great interest. In > the IEEE 802.15 maintenance standing committee we often have long > discussions on how IEs should be used and as a result have started an > interest group on an IEEE 802.15.4 guide. As part of that effort I have > created an IE Table guide, 15-15-0090-06 > <https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx>, > https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx. > If you wish to review it, this is a publicly available document. > > But to the points raised: > - "there is no need to add a termination header IE” - this is incorrect, > the IE termination header IE is required to be transmitted before the > payload IEs. > <RCC>Surely if there are only header IEs, no payload IEs *and no MAC payload*, there is no need for a termination header IE after the header IEs?</RCC> > - “header IEs and Payload IEs have a different type within the first > 2-byte descriptor” - this is incorrect, currently there is no overlap but > we will need these extra IDs in the future. > - "If Header IEs are not present and Payload IEs are present, after having > read the MAC Header the next byte to read will be Payload IEs and together > with identification of the IE type ( Payload IEs type 1 ) you already have > a way to know that what you have are Payload IEs, thus you do not have to > add a termination Header IE before” This is incorrect > > I have included an example of an Enhanced Beacon in the IE Table Guide. > Please let me know if you believe I have made a mistake and why you believe > it is a mistake. > > 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] > > > On 19, Jun2015, at 6:47, José Ángel Miranda <[email protected]> wrote: > > Hi, > > Ok, after having read your answers I would like to clarify some points: > > - Following the current standard*, IEs payload are NOT encrypted.* > - Within an Enhanced Beacon, the MAC payload conforms IEs payload + Beacon > Payload. > - The inclusion of IEs within the frame is indicated via FCF( bit 9 ). > > These assumptions are correct and based on the current standard ( > 802.15.4e - 2012 ), in which the minimal is based. > Therefore, when receiving a frame, specifically a beacon, there is no need > to add a termination Header IE before the Payload IEs due to the following > reasons: > - When having received the beacon, you can check whether it has > Information Elements or not by just checking the FCF. > - Header IEs and Payload IEs have different type within the first 2 byte > descriptor ( Header IEs have type 0 and Payload IEs have type 1 ). > - If Header IEs are not present and Payload IEs are present, after having > read the MAC Header the next byte to read will be Payload IEs and together > with identification of the IE type ( Payload IEs type 1 ) you already have > a way to know that what you have are Payload IEs, thus you do not have to > add a termination Header IE before. > > In case of following other standard rather than the current one ( may be > the next rev. ), when having the Payload IEs encrypted (* this is NOT as > specified in the current standard* ), there would be one condition where > the termination Header IE is strictly required: > - You would have the IE list present bit set within the FCF and at time to > decrypt the frame you need to know, in order to operate properly the > incoming security procedure, what is 'c data' and 'a data', therefore you > need to add a termination Header IE in order to: avoid possible confusion > with the non-formatted encrypted payload and know where the MAC Header > ends. > > Taking into account these points, the beacon showed within the minimal > draft should be modified ( omitting the termination Header IE ). > > Cheers, > Jose. > > > 2015-06-18 0:58 GMT+02:00 Tero Kivinen <[email protected]>: > >> Rene Struik writes: >> > According to the 15.4e spec, the value of the IE List Present field >> > in the FCF signals whether or not IEs are included in the frame (see >> > Clause 5.2.11.5b). >> >> This is true. >> >> > Header and Payload IEs can be distinguished via the Type field (bit >> > 15: set to zero if Header IE; set to one otherwise) and are >> > self-contained TLV data objects (see Clauses 5.2.4.2 and 5.2.4.3). >> >> This is not. Nothing in the 802.15.4e says that there cannot be long >> format for header IEs, or that you cannot have short format for >> payload IEs. On the other hand the section 5.2.2.6.17 says: >> >> 5.2.2.6.17 IEs field >> >> The IEs field is variable in length and is present if the IEs >> Present field is set to one. The format of IEs is specified in >> 5.2.4. It contains Header IEs, followed by Payload IEs. Each >> type of IE list is terminated as required per 5.2.4.22. >> >> I.e. both IE lists are terminated as required per 5.2.4.22. The >> 5.2.4.22 says: >> >> 5.2.4.22 IE List Termination IE >> >> The Header IE list is terminated with an IE List Termination >> IE (ID = 0x7e or 0x7f) that has a content length of zero. >> Explicit termination is required after a Header IE if there is >> one or more Payload IEs (0x7e), or MAC payload (0x7f), >> following the Header IE list. If an unformatted payload >> follows the Payload IE list, then the payload IE list is >> terminated with a list termination IE (ID = 0xf) that has a >> content length of zero. Otherwise the terminator may be >> omitted. >> >> I.e. no header termination IE is needed if there is nothing coming >> after it. The 0x7e is needed if there is Payload IEs after Header IEs, >> and 0x7f is needed if there is no Payload IEs, but there is payload >> after it. >> >> > Note that IEs should only be processed at receipt after successful >> incoming >> > frame security processing (i.e., IEs can be assumed to be available in >> the >> > clear for this discussion). >> >> Actually this is not specified in the 802.15.4e... Also several of >> those IEs are processed by MAC, and even if the frame is accepted from >> node A with data payload, that does not mean that all IEs in that >> frame is something that will be accepted. >> >> In the 802.15.4rev there is new security tables similar to the Frame >> security tables for IEs, to specify whether they are accepted or >> ignored by the MAC. >> -- >> [email protected] >> > > _______________________________________________ > 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
