Pat, I believe Robert considers the case in which the frame has only: - header IEs - NO payload IEs - NO payload
In that case, we don't see a Termination IE for the header IEs, right? Thomas On Fri, Jun 19, 2015 at 4:42 PM, Pat Kinney < [email protected]> wrote: > No, even if there are no Header IEs, the header IE termination is required > if there are Payload IEs > > 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 9:36, Robert Cragie <[email protected]> > wrote: > > 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 > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
