IETF Logo Mail Archive

Re: [ipwave] ND an link-layer acks - text

Dorothy Stanley <dstanley1389@gmail.com> Wed, 05 December 2018 20:41 UTC

Return-Path: <dstanley1389@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09E5130E7E for <its@ietfa.amsl.com>; Wed, 5 Dec 2018 12:41:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRm_8_nQOZXb for <its@ietfa.amsl.com>; Wed, 5 Dec 2018 12:41:51 -0800 (PST)
Received: from mail-it1-x142.google.com (mail-it1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64795130E6F for <its@ietf.org>; Wed, 5 Dec 2018 12:41:51 -0800 (PST)
Received: by mail-it1-x142.google.com with SMTP id g85so23563368ita.3 for <its@ietf.org>; Wed, 05 Dec 2018 12:41:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yKPho51oeicdny6Nl6wui0RU/KysuGniYsE5sKGh9XI=; b=cOUTWmNI6QINZ4lFWWl7I5hk5tNmCTCUm8QJff81DsTkmo2Wy6D2SS90gZBIWQy8bk YMwgZe96MJeXoF9Aqo1UypS0ZkY9DubutmBxKxfibidNbETdx9A1nwDfGhKpehFdcjZM PXIE29otQBR+DPxgj0EgeVogD/ZSh1jhh+rxxot7XPgTQuh4mH4k6OqFYFWrF4gv/kTy ORqxX8PWHPVZ6s+MNXAxgH0t6DMIm3qt9Joo1CHpZOn6uafx4T1G8RC5EGNwBQpEg/T9 p8dGDHM0wf5LUpkfOV4wFCCCAZ1BVlCJQA30iLyhPeBWdMUTzKIWOUD4qewraWescLJc eMwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yKPho51oeicdny6Nl6wui0RU/KysuGniYsE5sKGh9XI=; b=umjFQUGbsh7e+WxXrTyKruWBYCy9mfI2t2gE4zEg5Qil//qqDc+yak5Oj+ZZDYbMrb UXPNIg3EKp9pchYOygLB5s2ttEKgH1yIrPeCy2tQWrp9wxVljEDu7QhEt61dSTPOcFH4 +mK0Tk8O+PxDDyoniuXC8aoYDjAnCevMYg5s8lAXYmFiybQVEotwSueSRcGINH/VdsY7 gA372FI9slFet8TJtLRDhSK1nTB+MzE7yQwhs4Z2drtRMrV2kwjbd2+gupSzXpCuHDvV ZZVscLyrAg/GowWJnTRrvccXRWUF5DXXMw24Wfo3OF+jEWb86Icn0YXMk9p1mxdZObAl YmGA==
X-Gm-Message-State: AA+aEWZ+61RV+Kdl1K1LbgZPgBBQD3tD0EEBkKWfqsWtB4BZJB0Kcdk+ 0K0co28vduhSkINXb1zhoe9TM99Qvga1C4TsYug=
X-Google-Smtp-Source: AFSGD/UjZht5a0tm5rvKcaGFUUCkZYLkn0Ybd2jXIEhpfUIcyc5jAtgjL/xRkC+m8IBWaaxjD1TlEMCP7esxmxyiryM=
X-Received: by 2002:a24:4545:: with SMTP id y66mr15760888ita.174.1544042510456; Wed, 05 Dec 2018 12:41:50 -0800 (PST)
MIME-Version: 1.0
References: <154265051210.5320.13285322581737635986.idtracker@ietfa.amsl.com> <22d298c1-cae2-4d11-e2a6-1aa515276fba@gmail.com> <CAGRfTMkHLD3sPtGgEgRjfG98Z6bB38ArzxRAn8wExV_mEOpr=A@mail.gmail.com> <c73941c7-ec34-6c84-89eb-ac1460e32508@gmail.com> <CAP6QOWQs6tt1uaehJEw79h9J79asmJC8oadecj3nDEY00FKspA@mail.gmail.com> <016001d48c3f$a0d37d30$e27a7790$@eurecom.fr> <2ee187bd-52c1-b9a0-c15c-b999dc8af335@gmail.com> <CAGRfTMk+Kcj62hTJ4f8m-=YnXYYRUkcFcF_NYEFTzxz4u=z+2w@mail.gmail.com> <ab01233d-ee7a-11a4-b848-b130aa89d734@gmail.com>
In-Reply-To: <ab01233d-ee7a-11a4-b848-b130aa89d734@gmail.com>
From: Dorothy Stanley <dstanley1389@gmail.com>
Date: Wed, 05 Dec 2018 12:41:38 -0800
Message-ID: <CAGRfTMnrLYB8GAaZhLTA78A7DkAti7vY6kohvunOW9BpHgr9CA@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: jerome.haerri@eurecom.fr, John Kenney <jkenney@us.toyota-itc.com>, lorenzo=40google.com@dmarc.ietf.org, nordmark@sonic.net, its@ietf.org, brian.e.carpenter@gmail.com
Content-Type: multipart/alternative; boundary="0000000000005a9a5d057c4c690c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/jVs2crPlXGG1bGKZYsWk3et2-5I>
Subject: Re: [ipwave] ND an link-layer acks - text
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Dec 2018 20:41:55 -0000

Alexandre,

I am fine with the proposed new text.

Dorothy

----------------------
Dorothy Stanley
IEEE 802.11 WG Chair, dstanley@ieee.org
Hewlett Packard Enterprise
dorothy.stanley@hpe.com <dstanley@arubanetworks.com>
dstanley1389@gmail.com
+1 630-363-1389 <630-363-1389>


On Wed, Dec 5, 2018 at 7:13 AM Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

> Hello Dorothy,
>
> I thus suggest the following text.  Do you agree with this text?
>
> NEW:
>  > The Neighbor Discovery protocol (ND) [RFC4861] is used over
>  > 802.11-OCB links.
>
> OLD:
> > The Neighbor Discovery protocol (ND) [RFC4861] is used over
> > 802.11-OCB links.  Due to lack of link-layer acknowledgements in
> > 802.11-OCB for both unicast and multicast, we can expect higher
> > unicast loss than for 802.11 BSS.  The ND retransmissions are
> > supposed to handle loss of unicast and/or multicast just as it does
> > for other link types.
>
> Alex
>
>
>
>
>
> -------------------------ignore-------------------------------------------
> Because:
> Yous suggest one might mention DSRC apps rarely rely on Acks: I think
> it's hard to talk about DSRC applications in a network-layer document;
> but I tend to agree with you about the presence of Acks in OCB
> implementations, some times (not always); for the broadcast/multicast
> term: I find the term ambiguous: IPv6 does not know about 'broadcast' at
> all (and that's an IPv6-over-WiFi matter, not OCB in particular).
>
>
> Le 05/12/2018 à 15:24, Dorothy Stanley a écrit :
> > Hello Alexandre,
> >
> > The sentence " Due to lack of association operations in 802.11-OCB,
> > we can expect higher packet loss than for 802.11 BSS."
> >
> > is not correct.  The lack of acknowledgements for broadcast/multicast
> >  traffic is the same in OCB and BSS operation. The presence of
> > acknowledgements for unicast trafic is the same in OCB and BSS
> > operation. The lack of asssociation operation is irrelevant.
> >
> > If the intent is to say that unacknowledged broadcast traffic is
> > heavily used in DSRC applications, then just say that.
> >
> > I suggest deleting the current sentence.
> >
> > Dorothy
> >
> > ---------------------- Dorothy Stanley IEEE 802.11 WG Chair,
> > dstanley@ieee.org <mailto:dstanley@ieee.org> Hewlett Packard
> > Enterprise dorothy.stanley@hpe.com
> > <mailto:dstanley@arubanetworks.com> dstanley1389@gmail.com
> > <mailto:dstanley1389@gmail.com> +1 630-363-1389 <tel:630-363-1389>
> >
> >
> >
> > On Wed, Dec 5, 2018 at 2:52 AM Alexandre Petrescu
> > <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
> > wrote:
> >
> > John, Jérôme :  you seem to be agreeing.
> >
> > So, how about this text proposal?
> >
> > NEW:
> >> The Neighbor Discovery protocol (ND) [RFC4861] is used over
> >> 802.11-OCB links.  Due to lack of association operations in
> >> 802.11-OCB, we can expect higher packet loss than for 802.11 BSS.
> >> The ND retransmissions are supposed to handle loss of IP unicast
> >> and/or IP multicast just as it does for other link types.
> >
> > (remark 'lack of association operations' instead of 'lack of
> > link-layer acks')
> >
> > OLD:
> >> The Neighbor Discovery protocol (ND) [RFC4861] is used over
> >> 802.11-OCB links.  Due to lack of link-layer acknowledgements in
> >> 802.11-OCB for both unicast and multicast, we can expect higher
> >> unicast loss than for 802.11 BSS.  The ND retransmissions are
> >> supposed to handle loss of unicast and/or multicast just as it
> >> does for other link types.
> > I will not modify this text until I dont have agreements and from
> > you and from a representative of 6MAN WG.  It's a text that has been
> > crafted in fine detail.
> >
> > Alex
> >
> > Le 05/12/2018 à 03:09, Jérôme Härri a écrit :
> >> Hi All,
> >>
> >> I support John’s comment. ITS-G5/DSRC/OCB can fully do unicast
> >> with acks. It is the application that chose not to use this but
> >> rather broadcast. And even considering broadcast, I do not think we
> >> have higher packet losses. Just that we do not retransmit, as it
> >> is broadcast. Maybe we should mention reduced ‘application-layer
> >> reliability’ so something in that direction..
> >>
> >>
> >> BR,
> >>
> >> Jérôme
> >>
> >> *From:*its [mailto:its-bounces@ietf.org
> > <mailto:its-bounces@ietf.org>] *On Behalf Of *John Kenney
> >> *Sent:* Tuesday 04 December 2018 16:38 *To:* Alexandre Petrescu
> >> *Cc:* its; Dorothy Stanley *Subject:* Re: [ipwave] Fwd: New
> >> Version Notification for
> >> draft-ietf-ipwave-ipv6-over-80211ocb-31.txt
> >>
> >> Hi,
> >>
> >> Caveat: I know nothing about Neighbor Discovery protocol.
> >>
> >> I see this in the proposed new text:
> >>
> >> Due to lack of link-layer acknowledgements in 802.11-OCB, we can
> >> expect higher packet loss than for 802.11 BSS.
> >>
> >> I don't understand why it is expected that OCB has a lack of
> >> link-layer acknowledgments.  OCB uses link layer acks the same way
> >> as 802.11 BSS uses them.   If I send a unicast 802.11 packet
> >> outside the context of a BSS, I expect an 802.11 ACK. If I don't
> >> get the 802.11 ACK, I go through exponential backoff and
> >> retransmit.  Just like normal 802.11.  Maybe I'm missing
> >> something.
> >>
> >> Best Regards,
> >>
> >> John
> >>
> >> On Tue, Dec 4, 2018 at 7:11 AM Alexandre Petrescu
> >> <alexandre.petrescu@gmail.com
> > <mailto:alexandre.petrescu@gmail.com>
> > <mailto:alexandre.petrescu@gmail.com
> > <mailto:alexandre.petrescu@gmail.com>>>
> >> wrote:
> >>
> >>
> >>
> >> Le 04/12/2018 à 16:04, Dorothy Stanley a écrit :
> >>> Hello Alexandre, all,
> >>>
> >>> I am sharing the following information from John Kenny (
> >>> jkenney@us.toyota-itc.com <mailto:jkenney@us.toyota-itc.com>
> > <mailto:jkenney@us.toyota-itc.com
> > <mailto:jkenney@us.toyota-itc.com>>
> >> <mailto:jkenney@us.toyota-itc.com
> >> <mailto:jkenney@us.toyota-itc.com>
> >> <mailto:jkenney@us.toyota-itc.com
> > <mailto:jkenney@us.toyota-itc.com>>>), who is
> >>> actively involved in 802.11p implementation and deployments:
> >>> "OCB can use unicast in the same way as other flavors of 802.11
> >>> ( individually addressed 802.11 MAC PDU that is ACKed using
> >>> 802.11 procedures ). I find this is a common misunderstanding
> >>> (indeed, I am in a meeting right now where this very point came
> >>> up about 20 minutes ago). Probably the confusion is partly due to
> >>> the fact that a great deal of DSRC attention is focused on the
> >>> broadcast Basic Safety Message. Some people think that DSRC is
> >>> only BSMs, or only broadcast messages. But, there are some
> >>> important unicast applications as well."
> >>>
> >>> Thus a change is needed in 4.7, either delete the second
> >>> sentence or modify to reflect that unicast is acknowledged.
> >>
> >> I propose
> >>
> >> NEW:
> >>> The Neighbor Discovery protocol (ND) [RFC4861] is used over
> >>> 802.11-OCB links.  Due to lack of link-layer acknowledgements in
> >>> 802.11-OCB, we can expect higher packet loss than for 802.11
> >>> BSS. The ND retransmissions are supposed to handle loss of IP
> >>> unicast and/or IP multicast just as it does for other link
> >>> types.
> >>
> >> (remark disappeared 'unicast' and 'multicast' from 2nd phrase, and
> >> added 'IP' in front of unicast and multicast in 3rd phrase).
> >>
> >> OLD:
> >>> The Neighbor Discovery protocol (ND) [RFC4861] is used over
> >>> 802.11-OCB links.  Due to lack of link-layer acknowledgements in
> >>> 802.11-OCB for both unicast and multicast, we can expect higher
> >>> unicast loss than for 802.11 BSS.  The ND retransmissions are
> >>> supposed to handle loss of unicast and/or multicast just as it
> >>> does for other link types.
> >>
> >> Would this be agreed by John Kenney.
> >>
> >> Alex
> >>
> >>>
> >>> Thanks,
> >>>
> >>> Dorothy
> >>>
> >>> ---------------------- Dorothy Stanley IEEE 802.11 WG Chair,
> >>> dstanley@ieee.org <mailto:dstanley@ieee.org>
> > <mailto:dstanley@ieee.org <mailto:dstanley@ieee.org>>
> >> <mailto:dstanley@ieee.org <mailto:dstanley@ieee.org>
> > <mailto:dstanley@ieee.org <mailto:dstanley@ieee.org>>> Hewlett
> >> Packard
> >>> Enterprise dorothy.stanley@hpe.com
> > <mailto:dorothy.stanley@hpe.com> <mailto:dorothy.stanley@hpe.com
> > <mailto:dorothy.stanley@hpe.com>>
> >>> <mailto:dstanley@arubanetworks.com
> > <mailto:dstanley@arubanetworks.com>
> >> <mailto:dstanley@arubanetworks.com
> > <mailto:dstanley@arubanetworks.com>>> dstanley1389@gmail.com
> > <mailto:dstanley1389@gmail.com>
> >> <mailto:dstanley1389@gmail.com <mailto:dstanley1389@gmail.com>>
> >>> <mailto:dstanley1389@gmail.com <mailto:dstanley1389@gmail.com>
> > <mailto:dstanley1389@gmail.com <mailto:dstanley1389@gmail.com>>>
> >> +1 630-363-1389 <tel:630-363-1389>
> >>>
> >>>
> >>>
> >>> On Mon, Nov 19, 2018 at 10:07 AM Alexandre Petrescu
> >>> <alexandre.petrescu@gmail.com
> >>> <mailto:alexandre.petrescu@gmail.com>
> >> <mailto:alexandre.petrescu@gmail.com
> > <mailto:alexandre.petrescu@gmail.com>>
> >> <mailto:alexandre.petrescu@gmail.com
> > <mailto:alexandre.petrescu@gmail.com>
> >> <mailto:alexandre.petrescu@gmail.com
> > <mailto:alexandre.petrescu@gmail.com>>>>
> >>> wrote:
> >>>
> >>> Hi IPWAVErs,
> >>>
> >>> Following the discussion during presentation of the IPv6/OCB
> >>> slides by Nabil during IPWAVE WG meeting, I have updated the
> >>> IPv6/OCB draft.
> >>>
> >>> This is the ChangeLog:
> >>>
> >>> - filled in the section titled "Pseudonym Handling"; - removed a
> >>> 'MAY NOT' phrase about possibility of having other prefix than
> >>> the LL on the link between cars; - shortened and improved the
> >>> paragraph about Mobile IPv6, now with DNAv6; - improved the ND
> >>> text about ND retransmissions with relationship to packet loss;
> >>> - changed the title of an appendix from 'EPD' to 'Protocol
> >>> Layering'; - improved the 'Aspects introduced by OCB' appendix
> >>> with a few phrases about the channel use and references.
> >>>
> >>> This fixes all issues about ND and pseudonym handling.
> >>>
> >>> Alex
> >>>
> >>> -------- Message transféré -------- Sujet : New Version
> >>> Notification for draft-ietf-ipwave-ipv6-over-80211ocb-31.txt
> >>> Date : Mon, 19 Nov 2018 10:01:52 -0800 De :
> >>> internet-drafts@ietf.org
> > <mailto:internet-drafts@ietf.org>
> >> <mailto:internet-drafts@ietf.org
> >> <mailto:internet-drafts@ietf.org>>
> >>> <mailto:internet-drafts@ietf.org
> >>> <mailto:internet-drafts@ietf.org>
> >> <mailto:internet-drafts@ietf.org
> > <mailto:internet-drafts@ietf.org>>> Pour : Jerome Haerri
> >>> <Jerome.Haerri@eurecom.fr <mailto:Jerome.Haerri@eurecom.fr>
> > <mailto:Jerome.Haerri@eurecom.fr <mailto:Jerome.Haerri@eurecom.fr>>
> >> <mailto:Jerome.Haerri@eurecom.fr <mailto:Jerome.Haerri@eurecom.fr>
> >> <mailto:Jerome.Haerri@eurecom.
> >> <mailto:Jerome.Haerri@eurecom.>.fr>>>,
> >>> ipwave-chairs@ietf.org <mailto:ipwave-chairs@ietf.org>
> > <mailto:ipwave-chairs@ietf.org <mailto:ipwave-chairs@ietf.org>>
> >> <mailto:ipwave-chairs@ietf.org <mailto:ipwave-chairs@ietf.org>
> > <mailto:ipwave-chairs@ietf.org <mailto:ipwave-chairs@ietf.org>>>,
> >> Jerome Haerri
> >>> <jerome.haerri@eurecom.fr <mailto:jerome.haerri@eurecom.fr>
> > <mailto:jerome.haerri@eurecom.fr <mailto:jerome.haerri@eurecom.fr>>
> >> <mailto:jerome.haerri@eurecom.fr <mailto:jerome.haerri@eurecom.fr>
> >> <mailto:jerome.haerri@eurecom.
> >> <mailto:jerome.haerri@eurecom.>.fr>>>,
> >>> Alexandre Petrescu <Alexandre.Petrescu@cea.fr
> > <mailto:Alexandre.Petrescu@cea.fr>
> >> <mailto:Alexandre.Petrescu@cea.fr
> >> <mailto:Alexandre.Petrescu@cea.fr>>
> >>> <mailto:Alexandre.Petrescu@cea.fr
> >>> <mailto:Alexandre.Petrescu@cea.fr>
> >> <mailto:Alexandre.Petrescu@cea.fr
> > <mailto:Alexandre.Petrescu@cea.fr>>>>, Alexandre Petrescu
> >>> <alexandre.petrescu@cea.fr <mailto:alexandre.petrescu@cea.fr>
> > <mailto:alexandre.petrescu@cea.fr
> > <mailto:alexandre.petrescu@cea.fr>>
> >> <mailto:alexandre.petrescu@cea.fr
> >> <mailto:alexandre.petrescu@cea.fr>
> >> <mailto:alexandre.petrescu@cea.fr
> > <mailto:alexandre.petrescu@cea.fr>>>>, Nabil
> >>> Benamar <n.benamar@est.umi.ac.ma
> > <mailto:n.benamar@est.umi.ac.ma> <mailto:n.benamar@est.umi.ac.ma
> > <mailto:n.benamar@est.umi.ac.ma>>
> >> <mailto:n.benamar@est.umi.ac.ma <mailto:n.benamar@est.umi.ac.ma>
> > <mailto:n.benamar@est.umi.ac.ma <mailto:n.benamar@est.umi.ac.ma>>>>,
> >>> Thierry Ernst <thierry.ernst@yogoko.fr
> > <mailto:thierry.ernst@yogoko.fr>
> >> <mailto:thierry.ernst@yogoko.fr <mailto:thierry.ernst@yogoko.fr>>
> >>> <mailto:thierry.ernst@yogoko.fr <mailto:thierry.ernst@yogoko.fr>
> >> <mailto:thierry.ernst@yogoko.fr
> > <mailto:thierry.ernst@yogoko.fr>>>>, Jong-Hyouk Lee
> >>> <jonghyouk@smu.ac.kr <mailto:jonghyouk@smu.ac.kr>
> > <mailto:jonghyouk@smu.ac.kr <mailto:jonghyouk@smu.ac.kr>>
> >> <mailto:jonghyouk@smu.ac.kr <mailto:jonghyouk@smu.ac.kr>
> > <mailto:jonghyouk@smu.ac.kr <mailto:jonghyouk@smu.ac.kr>>>>
> >>>
> >>>
> >>> A new version of I-D,
> >>> draft-ietf-ipwave-ipv6-over-80211ocb-31.txt has been successfully
> >>> submitted by Alexandre Petrescu and posted to the IETF
> >>> repository.
> >>>
> >>> Name:           draft-ietf-ipwave-ipv6-over-80211ocb Revision:
> >>> 31 Title:          Transmission of IPv6 Packets over IEEE 802.11
> >>> Networks operating in mode Outside the Context of a Basic
> >>> Service Set (IPv6-over-80211-OCB) Document date:  2018-11-19
> >>> Group: ipwave Pages: 41 URL:
> >>>
> >>
> >
> https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-31.txt
> >
> >
> >
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >> Status:
> >>>
> >>
> > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
> >
> >
> >
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >> Htmlized:
> >>> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-31
> >
> >>>
> >
> >>>
> >>>
> >> Htmlized:
> >>>
> >>
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
> >
> >
> >
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >> Diff:
> >>>
> >>
> >
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-31
> >
> >
> >
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >> Abstract: In order to transmit IPv6 packets on IEEE 802.11
> >> networks
> >>> running outside the context of a basic service set (OCB, earlier
> >>> "802.11p") there is a need to define a few parameters such as
> >>> the supported Maximum Transmission Unit size on the 802.11-OCB
> >>> link, the header format preceding the IPv6 header, the Type value
> >>> within it, and others.  This document describes these parameters
> >>> for IPv6 and IEEE 802.11-OCB networks; it portrays the layering
> >>> of IPv6 on 802.11-OCB similarly to other known 802.11 and
> >>> Ethernet layers - by using an Ethernet Adaptation Layer.
> >>>
> >>>
> >>>
> >>>
> >>> Please note that it may take a couple of minutes from the time
> >>> of submission until the htmlized version and diff are available
> >>> at tools.ietf.org <http://tools.ietf.org>
> >>> <http://tools.ietf.org>
> > <http://tools.ietf.org>.
> >>>
> >>> The IETF Secretariat
> >>>
> >>> _______________________________________________ its mailing list
> >>> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
> > <mailto:its@ietf.org>> <mailto:its@ietf.org <mailto:its@ietf.org>
> >> <mailto:its@ietf.org <mailto:its@ietf.org>>>
> >>> https://www.ietf.org/mailman/listinfo/its
> >>>
> >>
> >> _______________________________________________ its mailing list
> >> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
> > <mailto:its@ietf.org>>
> >> https://www.ietf.org/mailman/listinfo/its
> >>
> >>
> >> --
> >>
> >> John Kenney
> >>
> >> Director and Principal Researcher
> >>
> >> Toyota InfoTechnology Center, USA
> >>
> >> 465 Bernardo Avenue
> >>
> >> Mountain View, CA 94043
> >>
> >> Tel: 650-694-4160. Mobile: 650-224-6644
> >>
> >
> > _______________________________________________ its mailing list
> > its@ietf.org <mailto:its@ietf.org>
> > https://www.ietf.org/mailman/listinfo/its
> >
>

v2.23.0 | Report a Bug | By Email