Re: [STDS-802-11-TGBC] EBCS DL reception/filtering/delivery to upper layers
Hello Jouni,
Thanks for the comments.
IP header contains not only addresses but also other information, such as fragmentation and QoS information.
Regeneration of IP header at the receiver means that .11 layer modifies IP header and .11 spec describes how to fill the IP header.
I think carrying MSDU in EBCS Data frame is better.
HLP info in ANQP resp and EBCS Info is expected to be used to notify to applications for preparing socket.
The description of the usage will be added later.
I have a question about the last comment.
Does this mean that we should define another Data plane stack for EBCS?
Best Regards,
---
Hitoshi MORIOKA
SRC Software Inc.
hmorioka@xxxxxxxxxxxx
> 2021/07/17 0:29、Jouni Malinen <jkmalinen@xxxxxxxxx>のメール:
>
> To continue the discussion in the chat at the end of the TGbc slot
> today.. I missed who commented there just before I left the meeting,
> but the comment was saying something about the EBCS receiver having to
> get the HLP payload details (which I'd assume was referring to
> destination IP address and UDP port or something like that). I don't
> think that this is really needed.
>
> The ANQP information about the EBCS DL stream contains an optional
> field for indicating the Content Address, so it is correct that this
> information could be provided over ANQP. The Content Address is
> apparently also included in the EBCS Info framer. However, the current
> draft does not seem to describe any specific use for this information.
>
> Every EBCS Data frame includes the Content ID value which is also
> included in the ANQP element. In other words, the EBCS receiver can
> identify the stream to which each such frame belongs to regardless of
> what IP address/UDP port is used in the HLP packet. In other words, I
> don't really see need for the EBCS receiver to be able to fetch the
> Content Address. In fact, this is also behind my earlier expectation
> of the not-really-yet-defined HLP packet being just application data
> since there seemed to be no need for including the IP header or UDP
> header in all these frames since they could be easily mapped to a
> specific stream based on the Content ID value. The EBCS receiver would
> not need EBCS Data frames to contain MSDUs; it could simply deliver
> the received payload to the appropriate upper layer component based on
> the Content ID (instead of going through the normal interface for
> non-EBCS Data frames).
>
> We've mostly discussing the DS/AP side of the EBCS DL transmission and
> like I've noted in the discussion, I have concerns over the security
> of some of the proposed designs there where EBCS and non-EBCS data is
> mixed together. Similar concerns extend to the EBCS DL reception side.
> I do not really like the concept of EBCS Data frames which are not
> encrypted getting delivered to upper layers just like non-EBCS Data
> frames which are encrypted. That's why I would see a parallel
> interface for delivering received EBCS DL stream as a more appropriate
> design.
>
> - Jouni
>
> ________________________________________________________________________
> To unsubscribe from the STDS-802-11-TGBC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1