Hi,
On 07/25/2016 02:48 AM, Aaron Sowry wrote:
> Hi,
>
>>> "If the PAN identifiers are identical, the intra-PAN subfield of the
>>> frame control field shall be set to 1, and the source PAN identifier
>>> shall be omitted from the transmitted frame."
>>>
>>
>> Yes, the question is here if this is valid or not.
>
> To me it's quite clear given the phrasing quoted above, since the term
> "shall" has a concrete definition[1] in this context:
>
> "The word 'shall' indicates mandatory requirements strictly to be
> followed in order to conform to the standard and from which no
> deviation is permitted ('shall' equals 'is required to')."
>
> Ergo, any packet which has identical SRC/DST PANs in its frame must be
> invalid, right?
>
Oh yes, then it's invalid. I agree. :-)
We should really start some rework of the frame parsing stuff.
>> About the intra-pan check, everybody outside (conitki/RIOT-OS) does
>> intra-pan communication, but I heard that it's possible to change
>> destination pan. So we should do intra-pan communication by default but
>> having some option to change destination pan. Maybe _per_ interface or
>> neighbour, etc?
>
> I'm also unsure about this. My understanding is that the main (only?)
> purpose of the PAN ID is to reduce MAC overhead by allowing usage of
> the shorter 16-bit addresses, since these addresses should be unique
> within a PAN. Perhaps all intra-pan traffic should really be using
> short addresses? I don't think this is required by the spec but it
> kind of makes sense. I'm not really sure of the details of handling
> intER-pan traffic, I will need to do some research.
>
You has always the pan given with the short address, in intra-pan and
non intra-pan communication. There is no lack of non uniqueness.
What I see for pan communication is [0].
1. A destination PAN identifier is included in the frame, and it
MUST match the PAN ID of the link in question.
I thought this always stands for my link pan-id should be the
destination pan id. But it also could mean that we need to answer on the
destination pan id where the link comes from. E.g. save it as neighbour
attribute in ndisc. I am not sure :-/
- Alex
[0] https://tools.ietf.org/html/rfc4944#section-3
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
