Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Mar 2018 19:22:37 +0100

Hi Kevin,

Kevin wrote recently:
> Dear IETF ipwave working group,
> 
> 
> 
> My name is Kevin Smith, I am the technical editor for IEEE Std 1609.3
> and a few others in the 1609 family of standards. I have some 
> concerns regarding ipwave's interoperability with 1609 WAVE, and a 
> question regarding the need or purpose for ipwave.

Generally speaking, the purpose of ipwave WG is set in the Charter.
(https://datatracker.ietf.org/wg/ipwave/about/)

> 1.       If ipwave is intended to be interoperable with 1609 WAVE, 
> then ipwave must specify the use of EtherType Protocol Discrimination
> (EPD) in the LLC sublayer header, i.e., EPD is mandatory.

We should interoperate to a maximum.

I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add the
following paragraph:

> The IPv6 packet transmitted on 802.11-OCB MUST be immediately 
> preceded by a Logical Link Control (LLC) header and an 802.11 header.
> In the LLC header, and in accordance with the EtherType Protocol
> Discrimination (EPD), the value of the Type field MUST be set to
> 0x86DD (IPv6).  In the 802.11 header, the value of the Subtype 
> sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS 
> Data'); the value of the Traffic Identifier (TID) sub-field of the 
> QoS Control field of the 802.11 header MUST be set to binary 001 
> (i.e. User Priority 'Background', QoS Access Category 'AC_BK').
> 
> In the Ethernet II header, the value of the Type field MUST be set
> to 0x86DD (IPv6).

Do you agree with this text?

> I note that ipwave mentions EPD, but also SNAP and does not specify 
> which method to use.

I propose we remove this phrase:
> Other alternative views of layering are EtherType Protocol 
> Discrimination (EPD), see Appendix E, and SNAP see [RFC1042].

Do you agree?

> Moreover ipwave discusses an abstract "Ethernet Adaptation Layer"
> but does not specify a header format, and this further confuses the 
> question for deployers - what should we implement?

The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) is
not so abstract, because it is widely implemented. This layer does
conversion between headers: at reception from the network it transforms
a .11/LLC header into an EthernetII header; reversely, at sending it
transforms an EthernetII header into a .11/LLC header. This is shown in
Figure 1.

The EAL does not intend to specify a header format. The header formats
involved are the IEEE 802.11, LLC and EthernetII. The fields in these
headers are specified by IEEE.

> 2.       It is not clear that ipwave provides any functionality that
>  1609 WAVE does not already provide.

Well, 1609 WAVE does not specify the conversion between .11/LLC headers
and EthernetII headers, right?

1609 WAVE does not specify the MTU size for IPv6, right?

1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData
(not just .11 Data), and BACKGROUND, right?

1609 WAVE does not recommend in particular RFC8064 to form semantically
opaque Interface Identifiers, right?

(and a few others).

> 1609 WAVE includes a number of mechanisms that enable IPv6 networks
> to be configured. In addition to the WSA/WRA mechanism, 1609.3 allows
> any IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor
> Discovery for IP Version 6 (IPv6) (which is listed as a normative
> reference in 1609.3). Helpful would be some example use-cases that
> illustrate problems to be solved, and how ipwave will solve those
> problems (i.e., that 1609 WAVE does not already solve).

There is a draft that describes some use-cases of IPv6 in vehicular
networks: draft-ietf-ipwave-vehicular-networking-02

I think some parts of 1609 WAVE, in particular WRA, are not used in
Europe. Whereas this IPv6-over-OCB draft is used the same wherever
Internet is present (Europe, America, Continents).

> My concern is that the IETF ipwave document may cause significant 
> confusion among deployers, and possibly lead to a lack of 
> interoperability. Thank you for the opportunity to comment, I look 
> forward to the discussion.

I would like to help with clarification. Let us discuss this.

Alex

> Best regards,
> Kevin