From nobody Fri Feb 1 08:14:38 2019 Return-Path: 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 79405130F41 for ; Fri, 1 Feb 2019 08:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2q5E8yMwNBxL for ; Fri, 1 Feb 2019 08:14:32 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785D7130F33 for ; Fri, 1 Feb 2019 08:14:32 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x11GEUGX006086 for ; Fri, 1 Feb 2019 17:14:30 +0100 Received: from nephilia.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 50B941C41E8 for ; Fri, 1 Feb 2019 17:14:30 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by nephilia.intra.cea.fr (Postfix) with ESMTP id 468B61C4085 for ; Fri, 1 Feb 2019 17:14:30 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x11GESGp003362 for ; Fri, 1 Feb 2019 17:14:29 +0100 References: <20190201155542.3429434C@mailrelay2.iso.org> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <20190201155542.3429434C@mailrelay2.iso.org> Message-ID: <1b10d23c-2676-c000-e6b0-8ded9c1c86b3@gmail.com> Date: Fri, 1 Feb 2019 17:14:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <20190201155542.3429434C@mailrelay2.iso.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: [ipwave] Fwd: Calll for comments on AI standards, due 2019-03-07 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 16:14:37 -0000 Intelligent Transport Systems ISO TC 204 is considering Artificial Intelligence -------- Message transféré -------- Sujet : Calll for comments on AI standards, due 2019-03-07 Date : Fri, 1 Feb 2019 15:55:42 +0000 De : Adrian Guan Répondre à : Adrian Guan Pour : isodocument@163.com, sten@ds.dk, virendra@bis.org.in, usm@tse.org.tr, titis.bsn@gmail.com, dewi.nurlatifah@bsn.go.id, ecommittee.helpdesk@bsigroup.com, extranetbn@afnor.org, isosd@scc.ca, vedran.vesenjak@hzn.hr, standards@nsai.ie, psqcaballot@gm.extra.cea.fr Dear TC204 members, I am passing along below note from Artificial Intelligence Ad Hoc Working Group Convenor Mr. Dean Zabrieszach to request a call for comments on the standards that ISO/TC 204 will seek to develop on AI. Please submit your comments directly to Dean at Dean.Zabrieszach@hmitechnologies.com.au by 7 March 2019. -- "For the next meeting of the Ad Hoc Working Group on AI in Florida, I would like to focus on developing a program of standards to be considered. By way of background, the purpose of the Ad Hoc was originally articulated as follows: ISO/TC 204 resolves to create a new “AI (Artificial Intelligence) ad hoc group” focused on “The impact of AI on ITS and the identification of standards that ISO/TC 204 will seek to develop”. Therefore, I would like to invite all HoD’s, Convenors and Experts to submit to me their thoughts, comments, suggestions on standards to be developed by such a group if it were to be made a permanent WG. A call for submissions is expected to be sent back to me by 7 March 2019. Kind Regards, Dean" --- Thanks, Adrian From nobody Fri Feb 1 13:29:37 2019 Return-Path: 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 AA6FF130EC7 for ; Fri, 1 Feb 2019 13:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 mJ-Ij6cjE1Zv for ; Fri, 1 Feb 2019 13:29:32 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 B91A3130EC2 for ; Fri, 1 Feb 2019 13:29:32 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id 32so7242764ota.12 for ; Fri, 01 Feb 2019 13:29:32 -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=Vne/U3SaDNUPhC12WEc6DtMTwRuORJkMAB1sGSrzv00=; b=V/6r3MRcK97hsOYj2FvlrPh9uUTe09f5CLJkXzW/oEvj+lKYk5cPxjFfqny4zo+chJ b4eNZ0MaifF1JHRUPyAtu8pTxOdM0g77bj2MT2VQQxPLy0pRhVWFmnAUR4ed+l+1SnJP mdNJA7LgrPUkEQUoeLPPJAoNPYjQ4EpwVBiP3TyMKsbRQlZaIEZQ7KoeOB+C5MHPpE23 L9i8p4f4gCxjVSovpCQf7zLihkiavBdIJG9OcRfoCJEwLbhocDdTR9B/IzU2nw3dIS0L h0GA1hxOJ/O/N2JyNu+OuCtvZtJVtcOf+HB4u1Yi7Rcpy93m2Lr2cqTJMOSoKp3y2uMi yjUQ== 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=Vne/U3SaDNUPhC12WEc6DtMTwRuORJkMAB1sGSrzv00=; b=nHgMgM8mbdyRyrUcEWQXRJiRKJ9KOeqZio9rlGcgC1B+tFCc38bX9usBAuGQpUJ2NH 7BgqZTqw8vjwcMfR36LfRQudRmTZMSs+bAJfBP6y59FjxUqdjKa6u9VHScDjxtbG6wec ysB8+skrIMzLFgKjIjJ7foWy8zVQFxHWb64cHagXs3RYSjJv6XFZw3cEf37T5gyTG+W2 Emi5JDGGKdlyNaEmUwtbEIquATvjweLMjCzsghH8AYBZ4jcEmayzbcRsC8V6fKCJkW6i NSo2BjSusryn+FAxTyAEYnPY+ue2ZEEL3+8DAaueP2ONhZydWccdxX3WiK8GFg/1fkAM 3UbQ== X-Gm-Message-State: AJcUukdeabFHiDiMK7fbTkLmabvSm927BWCLmdC9yBTfDGZayfK5WEr8 8na4XVXRv/9JMVBO4AC/WzxfHdBOj5+4yK/YLoIqAA== X-Google-Smtp-Source: ALg8bN5pBG1pwWWUJxgzM641DAlRFMXS35o2H1G2jPAw8LaC/g6zZkEH8E0MCczffmgSYohbIkg2ObKxkJ8pBJGNJxE= X-Received: by 2002:a9d:7c8c:: with SMTP id q12mr32106276otn.166.1549056572115; Fri, 01 Feb 2019 13:29:32 -0800 (PST) MIME-Version: 1.0 References: <20190201155542.3429434C@mailrelay2.iso.org> <1b10d23c-2676-c000-e6b0-8ded9c1c86b3@gmail.com> In-Reply-To: <1b10d23c-2676-c000-e6b0-8ded9c1c86b3@gmail.com> From: Abdussalam Baryun Date: Fri, 1 Feb 2019 23:29:17 +0200 Message-ID: To: Alexandre Petrescu Cc: "its@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b7cf810580dbd62a" Archived-At: Subject: Re: [ipwave] Fwd: Calll for comments on AI standards, due 2019-03-07 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 21:29:36 -0000 --000000000000b7cf810580dbd62a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think our WG will need to get informed from time to time of this CITS, they collaborate without IETF IPWAVE WG input. I don't recommend IETF participants to input individually to ISO/TC 204, it is better if we work together and discuss together what we want to submit as our list-comments/meeting-comments. IMHO we may need some one/organiser to collaborate so that we follow up with things happening outside IETF that may affect us in future. The system architecture they support/suggest is doing both IP and non-IP networks in ITS, the system becomes complicated. Our WG work authorises only work with IPv6 systems, so our applications are for IP networks. AB On Fri, Feb 1, 2019 at 6:14 PM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Intelligent Transport Systems ISO TC 204 is considering Artificial > Intelligence > > > -------- Message transf=C3=A9r=C3=A9 -------- > Sujet : Calll for comments on AI standards, due 2019-03-07 > Date : Fri, 1 Feb 2019 15:55:42 +0000 > De : Adrian Guan > R=C3=A9pondre =C3=A0 : Adrian Guan > Pour : isodocument@163.com, sten@ds.dk, virendra@bis.org.in, > usm@tse.org.tr, titis.bsn@gmail.com, dewi.nurlatifah@bsn.go.id, > ecommittee.helpdesk@bsigroup.com, extranetbn@afnor.org, isosd@scc.ca, > vedran.vesenjak@hzn.hr, standards@nsai.ie, psqcaballot@gm.extra.cea.fr > > Dear TC204 members, > > I am passing along below note from Artificial Intelligence Ad Hoc > Working Group Convenor Mr. Dean Zabrieszach to request a call for > comments on the standards that ISO/TC 204 will seek to develop on AI. > Please submit your comments directly to Dean at > Dean.Zabrieszach@hmitechnologies.com.au by 7 March 2019. > > -- > "For the next meeting of the Ad Hoc Working Group on AI in Florida, I > would like to focus on developing a program of standards to be > considered. By way of background, the purpose of the Ad Hoc was > originally articulated as follows: > > ISO/TC 204 resolves to create a new =E2=80=9CAI (Artificial Intelligence)= ad hoc > group=E2=80=9D focused on =E2=80=9CThe impact of AI on ITS and the identi= fication of > standards that ISO/TC 204 will seek to develop=E2=80=9D. > > Therefore, I would like to invite all HoD=E2=80=99s, Convenors and Expert= s to > submit to me their thoughts, comments, suggestions on standards to be > developed by such a group if it were to be made a permanent WG. > > A call for submissions is expected to be sent back to me by 7 March 2019. > > Kind Regards, > > Dean" > --- > > Thanks, > Adrian > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --000000000000b7cf810580dbd62a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think our WG will need to get informed from time to= time of this CITS, they collaborate without IETF IPWAVE WG input. I don= 9;t recommend IETF participants to input individually to ISO/TC 204, it is = better if we work together and discuss together what we want to submit as o= ur list-comments/meeting-comments.

IMHO we may nee= d some one/organiser =C2=A0to collaborate so that we follow up with things = happening outside IETF that may affect us in future. The system architectur= e they support/suggest is doing both IP and non-IP=C2=A0networks in ITS, th= e system becomes complicated. Our WG work authorises only work with IPv6 sy= stems, so our applications are for IP networks.

AB=

On Fri, Feb 1, 2019 at 6:14 PM Alexandre Petrescu <alexandre.petrescu@gmail.com> w= rote:
Intelligent Transport Systems ISO TC 204 is= considering Artificial
Intelligence


-------- Message transf=C3=A9r=C3=A9 --------
Sujet=C2=A0: Calll for comments on AI standards, due 2019-03-07
Date=C2=A0: Fri, 1 Feb 2019 15:55:42 +0000
De=C2=A0: Adrian Guan <livelinkisotc@iso.org>
R=C3=A9pondre =C3=A0=C2=A0: Adrian Guan <adrian.guan@sae.org>
Pour=C2=A0: isodoc= ument@163.com, sten@ds.= dk, virendra@b= is.org.in,
usm@tse.org.tr, titis.bsn@gmail.com, dewi.nur= latifah@bsn.go.id,
ecomm= ittee.helpdesk@bsigroup.com, extranetbn@afnor.org, isosd@scc.ca,
vedran.vesenjak= @hzn.hr, standar= ds@nsai.ie, psqcaballot@gm.extra.cea.fr

Dear TC204 members,

I am passing along below note from Artificial Intelligence Ad Hoc
Working Group Convenor Mr. Dean Zabrieszach to request a call for
comments on the standards that ISO/TC 204 will seek to develop on AI.
Please submit your comments directly to Dean at
Dean.Zabrieszach@hmitechnologies.com.au by 7 March 2019.

--
"For the next meeting of the Ad Hoc Working Group on AI in Florida, I =
would like to focus on developing a program of standards to be
considered. By way of background, the purpose of the Ad Hoc was
originally articulated as follows:

ISO/TC 204 resolves to create a new =E2=80=9CAI (Artificial Intelligence) a= d hoc
group=E2=80=9D focused on =E2=80=9CThe impact of AI on ITS and the identifi= cation of
standards that ISO/TC 204 will seek to develop=E2=80=9D.

Therefore, I would like to invite all HoD=E2=80=99s, Convenors and Experts = to
submit to me their thoughts, comments, suggestions on standards to be
developed by such a group if it were to be made a permanent WG.

A call for submissions is expected to be sent back to me by 7 March 2019.
Kind Regards,

Dean"
---

Thanks,
Adrian


_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
--000000000000b7cf810580dbd62a-- From nobody Mon Feb 4 11:03:07 2019 Return-Path: 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 D3CC3130EEC; Mon, 4 Feb 2019 11:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tcs.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 cMnIMrC5wlxT; Mon, 4 Feb 2019 11:02:54 -0800 (PST) Received: from indelg02.tcs.com (indelg02.tcs.com [203.200.109.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9DDF130EE7; Mon, 4 Feb 2019 11:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcs.com; i=@tcs.com; q=dns/txt; s=default2048; t=1549306973; x=1580842973; h=mime-version:in-reply-to:references:subject:from:to:cc: message-id:date; bh=TZBihX7tfJsYFPz0dfJSH8vk8lNyl4YbOYPsupw3PGo=; b=FrlJn6b18x+4lEH84LpU7bOweKmz+uWyqQd6E5tSnLTSxAA+2pYE+B94 eyifS4PyltPHasXP80rK8n8lewDwuKjYjOPmI1H3Bzr/ALvCj7woY0MFo FCdW7l0X+VEGXCEPcpN2o4h9WqJAQINurVVbHW3BGSnbqZsFZzqeXTaV/ S/L9Fn3sRgZ3oMO/4AUTb2xSJeqXokn9AdbSuxgmleM6aBB16uYs57Q5l AwMgWUqVPH3jm+v/grbNPozjztWAymab20H1WuanSHK9Cm1HoNKesbKcU ro+32+FmYT1AjoNqc0wsduZ5738VGmXm+Izv5vJsfW7Mjk53sV6+m74xa Q==; IronPort-PHdr: =?us-ascii?q?9a23=3AV9U2ThcGYzhKeV7v2KLVqh+klGMj4u6mDksu8p?= =?us-ascii?q?Mizoh2WeGdxc26YhCN2/xhgRfzUJnB7Loc0qyK6/CmATRIyK3CmUhKSIZLWR?= =?us-ascii?q?4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBx?= =?us-ascii?q?rwKxd+KPjrFY7OlcS30P2594HObwlSizexfbB/IA+qoQnNq8IbnZZsJqEtxx?= =?us-ascii?q?XTv3BGYf5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM3?= =?us-ascii?q?0u683wqRbDVwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xy?= =?us-ascii?q?mp4rx1QxH0ligIKz858HnWisNuiqJbvAmhrAF7z4LNfY2ZKOZycqbbcNgHR2?= =?us-ascii?q?ROQ9xRWjRODYy/dYUADeQBM/tYoYfjpFUAoxywChW3Cez11jNFnGX73akm3+?= =?us-ascii?q?g8FwzNwQwuH8gJsHTRtNj4KLwdUeC0zKnK1zrDae5d1Cr96IfSbhAhveuDUq?= =?us-ascii?q?5wccXL00kuFwPEgU+NooHiJTyazeQNs2mZ7+V6U+KjkXUoqwFrrTiz2scjkJ?= =?us-ascii?q?XGhoIPxVDe9SR4wJw6KMakSEFnet6oCodftyafN4ZvRM4pXm9muCE/yrIcuJ?= =?us-ascii?q?67ejAHyJU5yB7DZfyLaY+I4gjsVOqJPTd3mGlldKijiBa19EitzPD3WMqs0F?= =?us-ascii?q?tSsyZIkMfAumoQ2xHQ8MSLVPVw8l2u1DuJygvd8PtLIVoumqreM5Mhx7kwmY?= =?us-ascii?q?cNvknbBS/2nVn2jLeRdkU55uik8+Tnbavipp+bL4J6iRnwPKE3lMK5HOo1Lg?= =?us-ascii?q?4AUWad9+qm07Pt41H0TKhSgv03lKnWrozaKNwGqqO7HQNZyJsv5hWlAzu43t?= =?us-ascii?q?kUh3YKIEpAeB2djojpP1/OIOr/Dfe6m1mjiixkx/DHPr3jGJrNKGLPn6zhfb?= =?us-ascii?q?ln905c1BA8wsxf551OELEAIPLyVVXqudzEEhA5KBa4zPrgCNV4zo8eQ36AAr?= =?us-ascii?q?eFMKPOtl+F/vggI+2Sa44aojn9LeUq5+TwgnMjgV8SY7Wp3YEJZ3CjAvtmPl?= =?us-ascii?q?6UYXXpgtgbEGcKuhAyQ/DtiF2HSTRTfWq9X7og5jEnD4KrFZvMRoe3gLOfxy?= =?us-ascii?q?q7H4NZZnxIClyWFnfobYqEUe8WaC2OOs9hjiAEVb+5Ro8gyRGurxT3y7t5Ie?= =?us-ascii?q?rI9C0Ur5Xj1MJ65+fLjxE96SR0D9iB02GKV2x7gnkHSCQx3K1kvUx8y1aD3b?= =?us-ascii?q?J/g/xCGtwAr89OB00RPITH0+F8Q/r1QAfIeNHDAAKtS9+hKS0jT5Q22dBYJw?= =?us-ascii?q?43MtGvnhnF0zCnS4cYi6aGH5cpuOqI1nz8N897x2zLkrEsk0MrWcBSHWKjj6?= =?us-ascii?q?97sQPUAtiavV+ekvODf6Qd3ifLvE2DxHaStUpYWRRhQKyNCXkVZkrUpNK/7E?= =?us-ascii?q?PLU6OnArQuKBpQwOaeIbAMYdrs2wYVDMz/McjTNjri01y7AgyFk/bVNNLn?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AJAADFiVhc/wQXEqxkGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYFVgRWBKjuFJ4Y7jgKJJ45oFIFnJQEMhEcCg0I0CQ0?= =?us-ascii?q?BAwEBAgEBAgGBCAyCOikBgmYBAQEBAgEBAWwLBQsFBg0BAwMBAigHIQYfCQg?= =?us-ascii?q?GAQoIEQqDBwGBaQMNF6oMAQEBgh6EMwIOQUCCRA2CHoxid36DJVAugldHAQE?= =?us-ascii?q?CAQEWgRQBCwYCAT6DFgSCJgKJf4cwhWOLExozBwKCNIR+h02DVIFshUGLF4o?= =?us-ascii?q?jhS+BJoxNgR1xcFCCbAmGAYUUhUdqAYt4gk0BAQ?= X-IPAS-Result: =?us-ascii?q?A2AJAADFiVhc/wQXEqxkGwEBAQEDAQEBBwMBAQGBUQYBA?= =?us-ascii?q?QELAYFVgRWBKjuFJ4Y7jgKJJ45oFIFnJQEMhEcCg0I0CQ0BAwEBAgEBAgGBC?= =?us-ascii?q?AyCOikBgmYBAQEBAgEBAWwLBQsFBg0BAwMBAigHIQYfCQgGAQoIEQqDBwGBa?= =?us-ascii?q?QMNF6oMAQEBgh6EMwIOQUCCRA2CHoxid36DJVAugldHAQECAQEWgRQBCwYCA?= =?us-ascii?q?T6DFgSCJgKJf4cwhWOLExozBwKCNIR+h02DVIFshUGLF4ojhS+BJoxNgR1xc?= =?us-ascii?q?FCCbAmGAYUUhUdqAYt4gk0BAQ?= X-IronPort-AV: E=Sophos; i="5.56,560,1539628200"; d="scan'208,217"; a="34473637" MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <08d7924f-55c5-f89a-c2f6-cccb3fa4d071@gmail.com> <3c66d20e-2db2-7e15-6080-ce3646f848f6@gmail.com> From: Abhijan Bhattacharyya To: "Carsten Bormann" , "Alexandre Petrescu" Cc: its@ietf.org, "core@ietf.org" Message-ID: Date: Tue, 5 Feb 2019 00:30:42 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1FP10HF213 April 26, 2018 X-MIMETrack: Serialize by http on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 02/05/2019 00:30:42, Serialize complete at 02/05/2019 00:30:42, Itemize by http on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 02/05/2019 00:30:42, Serialize by Router on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 02/05/2019 00:32:40, Serialize complete at 02/05/2019 00:32:40 Content-Type: multipart/alternative; boundary="=_alternative 00686F1D65258397_=" Archived-At: Subject: Re: [ipwave] Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 19:02:58 -0000 --=_alternative 00686F1D65258397_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you Carsten for your comments. No one can speak about CoAP better tha= n you! Alex, I have uploaded a new version of the draft. The links are given at the end = of this mail. I have indeed tried to address your concern in respect to mak= ing the draft more "IPv6-relevant". As Carsten rightly pointed out that the proposal works at the application l= ayer and is built on the foundation of CoAP, so it is Layer-3 agnostic. Als= o, as we all know, CoAP is designed for IPv6. However, implementation on IPv6 may influence the process of determining th= e maximum size of information segments. So, a new subsection has been added= as part of the design guidelines. The small addition reads as below: 6.3. Determining the segment size Size of the information segment in a CoAP message should be limited by t= he least possible MTU for the end-to-end channel. This is to ensure that there is= no undesired conversation state at the lower layers of the protocol stack d= ue to uncontrolled fragmentation leading to undesired explosion of traffic in = the network. For IPV6 network, the MTU can be determined using Path MTU Disc= overy (PMTUD) [RFC8201] which bestows the responsibility of determining the pa= th MTU on the end-points itself. The size of the segment should be guided by the recommendations as speci= fied in Section 4.6 of [RFC7252]. I hope this will now satisfy the criterion of finding IPv6 in the draft. Looping in CoRE list as well to announce the new version to the WG where th= is draft originates. Thank you. URL: https://www.ietf.org/internet-drafts/draft-bhattacharyya-co= re-a-realist-01.txt Status: https://datatracker.ietf.org/doc/draft-bhattacharyya-core-a= -realist/ Htmlized: https://tools.ietf.org/html/draft-bhattacharyya-core-a-real= ist-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-bhattacharyya-c= ore-a-realist Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-bhattacharyya-cor= e-a-realist-01 With Best Regards Abhijan Bhattacharyya Consultant / Scientist, {Internet Protocols | 5G | Standardization}, = TCS Research, Tata Consultancy Services Building 1B,Ecospace Plot - IIF/12 ,New Town, Rajarhat, Kolkata - 700160,West Bengal India Ph:- +91 33 66884691 Cell:- +919830468972 | +918583875003 Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----"its" wrote: ----- To: "Alexandre Petrescu" From: "Carsten Bormann" = Sent by: "its" = Date: 01/31/2019 06:12PM Cc: "Abhijan Bhattacharyya" , "Michael Richa= rdson" , its@ietf.org Subject: Re: [ipwave] Adaptive RESTful Real-time Live Streaming for Things = (A-REaLiST)' "External email. Open with Caution" > If TCP's state machine was a bottleneck, has one tried to use UDP > instead? I think that is indeed one of the advantages CoAP brings go the table here. > Does CoAP work on Ethernet? CoAP was designed to be able to run on UDP, which is on IP which in turn wo= rks very well on Ethernet. > Does CoAP work in an end-to-end manner or does it need protocol > conversion gateways? I works end-to-end (as long as your network doesn’t break UDP). > I want to ask you: please use IPv6 for CoAP and RESTful. CoAP was designed to work well over IPv6 (but works as well over IPv4). > Then I searched for the keyword ‘IPv6' in the draft. > […] > If you add ‘IPv6' considerations to it, then I will comment on it. For a CoAP application such as A-REaLiST, IPv6 makes little difference (bey= ond being able to assign addresses to both ends in the first place), so I d= on’t know there is a lot to say. Gr=FC=DFe, Carsten _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 00686F1D65258397_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you Carsten for your comments. No one can speak about CoA= P better than you!

Alex,
I have uploaded= a new version of the draft. The links are given at the end of this mail. I= have indeed tried to address your concern in respect to making the draft m= ore "IPv6-relevant".

As Carsten rightly pointed ou= t that the proposal works at the application layer and is built on the foun= dation of CoAP, so it is Layer-3 agnostic. Also, as we all know, CoAP is de= signed for IPv6.
However, implementation on IPv6 may influence th= e process of determining the maximum size of information segments. So, a ne= w subsection has been added as part of the design guidelines. The small add= ition reads as below:

<Quote>
6.3. Determining t= he segment size Size of the information segment in a CoAP message should be limited by t= he least possible MTU for the end-to-end channel. This is to ensure that there is= no undesired conversation state at the lower layers of the protocol stack d= ue to uncontrolled fragmentation leading to undesired explosion of traffic in = the network. For IPV6 network, the MTU can be determined using Path MTU Disc= overy (PMTUD) [RFC8201] which bestows the responsibility of determining the pa= th MTU on the end-points itself. The size of the segment should be guided by the recommendations as speci= fied in Section 4.6 of [RFC7252].
</Quote>

<= font size=3D"2">I hope this will now satisfy the criterion of finding IPv6 = in the draft.

Looping in CoRE list as well to announce the new version to the= WG where this draft originates.

Thank you.



With Best Regards<= br> Abhijan Bhattacharyya
Consultant / Scientist,
{Internet Protocols | 5G | Standardization},
TCS Research,
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- +91 33 66884691
Cell:- +919830468972 | +918583875003
Mailto: = abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________


-----"its" <its-bounces@ietf.org> wro= te: -----
alexandre.petrescu@gmail.com>
From: "Carste= n Bormann"
Sent by: "its"
Date:= 01/31/2019 06:12PM
Cc: "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.co= m>, "Michael Richardson" <mcr@sandelman.ca>, its@ietf.org
Subject: Re: [ipwave] Adaptive RESTful = Real-time Live Streaming for Things (A-REaLiST)'

"External email. Open with Cautio= n"

> If TCP's state machine was a bottleneck, has one tried to us= e UDP
> instead?

I think that is indeed one of the advantages = CoAP brings go the table here.

> Does CoAP work on Ethernet?
<= br>CoAP was designed to be able to run on UDP, which is on IP which in turn= works very well on Ethernet.

> Does CoAP work in an end-to-end m= anner or does it need protocol
> conversion gateways?

I works = end-to-end (as long as your network doesn’t break UDP).

> I= want to ask you: please use IPv6 for CoAP and RESTful.

CoAP was des= igned to work well over IPv6 (but works as well over IPv4).

> The= n I searched for the keyword ‘IPv6' in the draft.
> […]> If you add ‘IPv6' considerations to it, then I will comment on= it.

For a CoAP application such as A-REaLiST, IPv6 makes little dif= ference (beyond being able to assign addresses to both ends in the first pl= ace), so I don’t know there is a lot to say.

Gr=FC=DFe, Carste= n

_______________________________________________
its mailing lis= t
its@ietf.org
= https://www.ietf.org/= mailman/listinfo/its

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D= =3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 00686F1D65258397_=-- From nobody Mon Feb 4 17:25:55 2019 Return-Path: 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 9196112F19D for ; Mon, 4 Feb 2019 17:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.041 X-Spam-Level: X-Spam-Status: No, score=-19.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FILL_THIS_FORM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_FILL_THIS_FORM_LOAN=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 RtuHyz2GC3PE for ; Mon, 4 Feb 2019 17:25:43 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D55126C7E for ; Mon, 4 Feb 2019 17:25:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=179435; q=dns/txt; s=iport; t=1549329943; x=1550539543; h=from:to:cc:subject:date:message-id:mime-version; bh=zSjvfNfg9+T1xuuJJBC0uGOTY3jnX44K9sDmJGRf2jc=; b=M6Et2SbI/5aYMFN7mqEmsM1jGugmGFRdlaA/khr1F7FnsFKoyu5nq8JN UStInXbjsw5EwAMyh4ysVA7Q1Tss8bNHOHu3z5MMMLosnCjm4uqnRgjNM cPO47NCTIfZqXOkT4EFZNuLnbHaroHnt29PhKSoxxH2yMzhhZVf+qgwAo c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAABO5Vhc/4sNJK1KEAEGAxkBAQE?= =?us-ascii?q?BAQEBAQEBAQEHAQEBAQEBgWWBDgFHBSlngQMnCpQWg3GDCYgrjnyBZwMIAQE?= =?us-ascii?q?jB4EsIYJ1gyIiOBIBAwEBAgEBAm0cAQuFawEMQQgBAQEGDgQBGiYBKAYRFxA?= =?us-ascii?q?EDgUWBQSCOEyBHUwDFQ81qUACgjczgk6CdoJKDYIeBS+JRYJIF4FAP4EQAYI?= =?us-ascii?q?UARE3NYJXRwIBAoEXBgUBCAEHAQoBAwYCGhsLG4UZAolaDRIWhgAcAYRwAoF?= =?us-ascii?q?0iwQCDRozCQKBcYU/g2GDLz2BEYIqGYFsJiyEb4dmgXyBNYogA4EMgyp5gSa?= =?us-ascii?q?IDYJTAhEUgSc2IWVdDAhwFTuCbAmGa4EVgxWFPgFBMQEwi3kBDhcEgQSBHwE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.56,560,1539648000"; d="scan'208,217";a="510822584" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2019 01:25:35 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x151PYSt024598 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Feb 2019 01:25:34 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 4 Feb 2019 19:25:33 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Mon, 4 Feb 2019 19:25:34 -0600 From: "Sri Gundavelli (sgundave)" To: "its@ietf.org" CC: "Mr. Jaehoon Paul Jeong" Thread-Topic: Review of draft-ietf-ipwave-vehicular-networking-07 Thread-Index: AQHUvPGwYJx6mcxUnUiYx0K4/Z43Ug== Date: Tue, 5 Feb 2019 01:25:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.53] Content-Type: multipart/alternative; boundary="_000_D87E26092E68EBsgundaveciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: [ipwave] Review of draft-ietf-ipwave-vehicular-networking-07 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 01:25:54 -0000 --_000_D87E26092E68EBsgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hey Paul, Attached is my review. Please see some inline comments. In my opinion, the= document has thin line separating the problem description from the solutio= n description. In many places, the focus is more on the solution before exp= laining what the problem is. I think you have an opportunity here to great= ly simplify the document and keep it to the point. I hate to push you towar= ds another revision, but in the current form this won=92t pass IESG, IMO. T= he Gods in IESG will send it back to the WG. I really think you can cut dow= n the text by 50% to 60%. As they say, =93some times, less is more" :-) = Hope this helps. Cheers! Sri -- IPWAVE Working Group J. Jeong, Ed. Internet-Draft Sungkyunkwan University Intended status: Informational November 4, 2018 Expires: May 8, 2019 IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases draft-ietf-ipwave-vehicular-networking-07 Abstract This document discusses the problem statement and use cases on IP- based vehicular networks, which are considered a key component of Intelligent Transportation Systems (ITS). [Sri] What is Key component of ITS? Usecases? You may want to reword "This document discusses the problem statement and use cases on IP- based vehicular networks for building Intelligent Transportation Systems= (ITS). The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to- infrastructure (V2I), and vehicle-to-everything (V2X) communications. First, this document surveys use cases using V2V, V2I, and V2X networking. Second, it analyzes proposed protocols for IP-based vehicular networking and highlights the limitations and difficulties found on those protocols. Third, it presents a problem exploration for key aspects in IP-based vehicular networking, such as IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy. For each key aspect, this document discusses a problem statement to evaluate the gap between the state-of-the-art techniques and requirements in IP-based vehicular networking. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 8, 2019. Jeong Expires May 8, 2019 [Page 1] Internet-Draft IPWAVE Problem Statement November 2018 Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Analysis for Existing Protocols . . . . . . . . . . . . . . . 8 4.1. Existing Protocols for Vehicular Networking . . . . . . . 8 4.1.1. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . 8 4.1.2. IP Address Autoconfiguration . . . . . . . . . . . . 8 4.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.4. Mobility Management . . . . . . . . . . . . . . . . . 9 4.1.5. DNS Naming Service . . . . . . . . . . . . . . . . . 9 4.1.6. Service Discovery . . . . . . . . . . . . . . . . . . 9 4.1.7. Security and Privacy . . . . . . . . . . . . . . . . 10 4.2. General Problems . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Vehicular Network Architecture . . . . . . . . . . . 11 4.2.2. Latency . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 16 4.2.4. Pseudonym Handling . . . . . . . . . . . . . . . . . 16 5. Problem Exploration . . . . . . . . . . . . . . . . . . . . . 17 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 17 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 17 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 18 5.1.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 18 5.1.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 19 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Informative References . . . . . . . . . . . . . . . . . . . 21 Appendix A. Relevant Topics to IPWAVE Working Group . . . . . . 29 Jeong Expires May 8, 2019 [Page 2] Internet-Draft IPWAVE Problem Statement November 2018 A.1. Vehicle Identity Management . . . . . . . . . . . . . . . 29 A.2. Multihop V2X . . . . . . . . . . . . . . . . . . . . . . 29 A.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29 A.4. DNS Naming Services and Service Discovery . . . . . . . . 30 A.5. IPv6 over Cellular Networks . . . . . . . . . . . . . . . 30 A.5.1. Cellular V2X (C-V2X) Using 4G-LTE . . . . . . . . . . 30 A.5.2. Cellular V2X (C-V2X) Using 5G . . . . . . . . . . . . 31 Appendix B. Changes from draft-ietf-ipwave-vehicular- networking-06 . . . . . . . . . . . . . . . . . . . 31 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 31 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction Vehicular networking studies have mainly focused on driving safety, driving efficiency, and entertainment in road networks. [Sri] Rephrase, =93focused on driving safety, driving efficiency, and enter= tainment in road networks." To perhaps, =93focussed on improving safety, efficiency and enabling entert= ainment in vehicular networks=94 The Federal Communications Commission (FCC) in the US allocated wireless channels for Dedicated Short-Range Communications (DSRC) [DSRC], service in the Intelligent Transportation Systems (ITS) Radio Service in the 5.850 - 5.925 GHz band (5.9 GHz band). DSRC-based wireless communications can support vehicle-to-vehicle (V2V), vehicle-to- infrastructure (V2I), and vehicle-to-everything (V2X) networking. Also, the European Union (EU) passed a decision to allocate radio spectrum for safety-related and non-safety-related applications of ITS with the frequency band of 5.875 - 5.905 GHz, which is called Commission Decision 2008/671/EC [EU-2008-671-EC]. For direct inter-vehicular wireless connectivity, IEEE has amended WiFi standard 802.11 to enable driving safety services based on the DSRC in terms of standards for the Wireless Access in Vehicular Environments (WAVE) system. L1 and L2 issues are addressed in IEEE [Sri] Expand L1, L2 802.11p [IEEE-802.11p] for the PHY and MAC of the DSRC, while IEEE 1609.2 [WAVE-1609.2] covers security aspects, IEEE 1609.3 [WAVE-1609.3] defines related services at network and transport layers, and IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel operation. Note that IEEE 802.11p has been published as IEEE 802.11 Outside the Context of a Basic Service Set (OCB) called IEEE 802.11-OCB [IEEE-802.11-OCB] in 2012. [Sri] You may want to say, 802.11p was a separate standard, but was later e= nrolled into the base 802.11 standard, IEEE 802.11-2012 Along with these WAVE standards, IPv6 [RFC8200] and Mobile IP protocols (e.g., MIPv4 [RFC5944] and MIPv6 [RFC6275]) can be applied (or easily modified) to vehicular networks. [Sri] Since, you mentioned MIP4, MIP6, it will be incomplete if you don=92t= include PMIPv6 [RFC5213 and RFC5844]. Also, to be consistent with my other= comments, please refer to them in the context of a problem. State the prob= lem, say =93mobility management=94, explain the requirement and refer to ex= isting IETF art, for addressing that problem. In Europe, ETSI has standardized a GeoNetworking (GN) protocol [ETSI-GeoNetworking] and a protocol adaptation sub-layer from GeoNetworking to IPv6 [ETSI-GeoNetwork-IP]. Note that a GN protocol is useful to route an event or notification message to vehicles around a geographic position, such as an acciendent area in a roadway. In addition, ISO Jeong Expires May 8, 2019 [Page 3] Internet-Draft IPWAVE Problem Statement November 2018 has approved a standard specifying the IPv6 network protocols and services to be used for Communications Access for Land Mobiles (CALM) [ISO-ITS-IPv6]. [Sri] This is great information, but curious how it toes back to this docum= ent? Use of IP ? This document discusses problem statements and use cases related to IP-based vehicular networking for Intelligent Transportation Systems (ITS), which is denoted as IP Wireless Access in Vehicular Environments (IPWAVE). First, it surveys the use cases for using V2V, V2I, and V2X networking in the ITS. Second, for literature review, it analyzes proposed protocols for IP-based vehicular networking and highlights the limitations and difficulties found on those protocols. Third, for problem statement, it presents a problem exploration with key aspects in IPWAVE, such as IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy. For each key aspect of the problem statement, it analyzes the gap between the state-of-the-art techniques and the requirements in IP-based vehicular networking. It also discusses potential topics relevant to IPWAVE Working Group (WG), such as Vehicle Identities Management, Multihop V2X Communications, Multicast, DNS Naming Services, Service Discovery, and IPv6 over Cellular Networks. Therefore, with the problem statement, this document will open a door to develop key protocols for IPWAVE that will be essential to IP-based vehicular networks. 2. Terminology This document uses the following definitions: o WAVE: Acronym for "Wireless Access in Vehicular Environments" [WAVE-1609.0]. o DMM: Acronym for "Distributed Mobility Management" [RFC7333][RFC7429]. o Road-Side Unit (RSU): A node that has physical communication devices (e.g., DSRC, Visible Light Communication, 802.15.4, LTE- V2X, etc.) for wireless communications with vehicles and is also connected to the Internet as a router or switch for packet forwarding. An RSU is typically deployed on the road infrastructure, either at an intersection or in a road segment, but may also be located in car parking area. [Sri] I would think DSRC and C-V2X are the only wireless systems currently = defined for Vehicular Communications, or at least the term RSU is used only= by these systems. So, I am not sure if we should mention 802.15.4 or Visib= le Light Communications. Also, if you look at the OBU definition below, is = there a OBU with visible light interface, so both the ends have to support = the same scheme. o On-Board Unit (OBU): A node that has a DSRC device for wireless communications with other OBUs and RSUs, and may be connected to in-vehicle devices or networks. An OBU is mounted on a vehicle. It is assumed that a radio navigation receiver (e.g., Global Positioning System (GPS)) is included in a vehicle with an OBU for efficient navigation. Jeong Expires May 8, 2019 [Page 4] Internet-Draft IPWAVE Problem Statement November 2018 o Vehicle Detection Loop (or Loop Detector): An inductive device used for detecting vehicles passing or arriving at a certain point, for instance approaching a traffic light or in motorway traffic. The relatively crude nature of the loop's structure means that only metal masses above a certain size are capable of triggering the detection. o Mobility Anchor (MA): A node that maintains IP addresses and mobility information of vehicles in a road network to support the address autoconfiguration and mobility management of them. It has end-to-end connections with RSUs under its control. It maintains a DAD table having the IP addresses of the vehicles moving within the communication coverage of its RSUs. [Sri] The last sentence is pointing to a solution. MA may or may not mainta= in a DAD table. It may maintain a binding table like MIPv6 HA, or PMIPv6 LM= A o Vehicular Cloud: A cloud infrastructure for vehicular networks, having compute nodes, storage nodes, and network nodes. o Traffic Control Center (TCC): A node that maintains road infrastructure information (e.g., RSUs, traffic signals, and loop detectors), vehicular traffic statistics (e.g., average vehicle speed and vehicle inter-arrival time per road segment), and vehicle information (e.g., a vehicle's identifier, position, direction, speed, and trajectory as a navigation path). TCC is included in a vehicular cloud for vehicular networks. 3. Use Cases This section provides use cases of V2V, V2I, and V2X networking. The use cases of the V2X networking exclude the ones of the V2V and V2I networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- Device (V2D). 3.1. V2V The use cases of V2V networking discussed in this section include o Context-aware navigation for driving safety and collision avoidance; o Cooperative adaptive cruise control in an urban roadway; o Platooning in a highway; o Cooperative environment sensing. These four techniques will be important elements for self-driving Vehicles. [Sri] I am not convinced if this is a complete list, or how these items mad= e it here. 3GPP has identified some use-cases, I wonder what is the delta b= etween the two Jeong Expires May 8, 2019 [Page 5] Internet-Draft IPWAVE Problem Statement November 2018 Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers to drive safely by letting the drivers recognize dangerous obstacles and situations. That is, CASD navigator displays obstables or neighboring vehicles relevant to possible collisions in real-time through V2V networking. CASD provides vehicles with a class-based automatic safety action plan, which considers three situations, such as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe and safe situations. This action plan can be performed among vehicles through V2V networking. Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps vehicles to adapt their speed autonomously through V2V communication among vehicles according to the mobility of their predecessor and successor vehicles in an urban roadway or a highway. CACC can help adjacent vehicles to efficiently adjust their speed in a cascade way through V2V networking. Platooning [Truck-Platooning] allows a series of vehicles (e.g., trucks) to move together with a very short inter-distance. Trucks can use V2V communication in addition to forward sensors in order to maintain constant clearance between two consecutive vehicles at very short gaps (from 3 meters to 10 meters). This platooning can maximize the throughput of vehicular traffic in a highway and reduce the gas consumption because the leading vehicle can help the following vehicles to experience less air resistance. Cooperative-environment-sensing use cases suggest that vehicles can share environmental information from various vehicle-mounted sensors, such as radars, LiDARs and cameras with other vehicles and pedestrians. [Automotive-Sensing] introduces a millimeter-wave vehicular communication for massive automotive sensing. Data generated by those sensors can be substantially large, and these data shall be routed to different destinations. In addition, from the perspective of driverless vehicles, it is expected that driverless vehicles can be mixed with driver-operated vehicles. Through cooperative environment sensing, driver-operated vehicles can use environmental information sensed by driverless vehicles for better interaction with the context. 3.2. V2I The use cases of V2I networking discussed in this section include o Navigation service; o Energy-efficient speed recommendation service; o Accident notification service. Jeong Expires May 8, 2019 [Page 6] Internet-Draft IPWAVE Problem Statement November 2018 A navigation service, such as the Self-Adaptive Interactive Navigation Tool (called SAINT) [SAINT], using V2I networking interacts with TCC for the large-scale/long-range road traffic optimization and can guide individual vehicles for appropriate navigation paths in real time. The enhanced SAINT (called SAINT+) [SAINTplus] can give the fast moving paths for emergency vehicles (e.g., ambulance and fire engine) toward accident spots while providing other vehicles with efficient detour paths. [Sri] Is this a requirement, or a description of some deployed service? A TCC can recommend an energy-efficient speed to a vehicle driving in different traffic environments. [Fuel-Efficient] studies fuel- efficient route and speed plans for platooned trucks. The emergency communication between accident vehicles (or emergency vehicles) and TCC can be performed via either RSU or 4G-LTE networks. The First Responder Network Authority (FirstNet) [FirstNet] is provided by the US government to establish, operate, and maintain an interoperable public safety broadband network for safety and security network services, such as emergency calls. The construction of the nationwide FirstNet network requires each state in the US to have a Radio Access Network (RAN) that will connect to FirstNet's network core. The current RAN is mainly constructed by 4G-LTE for the communication between a vehicle and an infrastructure node (i.e., V2I) [FirstNet-Report], but it is expected that DSRC-based vehicular networks [DSRC] will be available for V2I and V2V in near future. 3.3. V2X The use case of V2X networking discussed in this section is pedestrian protection service. A pedestrian protection service, such as Safety-Aware Navigation Application (called SANA) [SANA], using V2I2P networking can reduce the collision of a vehicle and a pedestrian carrying a smartphone equipped with the access technology with an RSU (e.g., WiFi). Vehicles and pedestrians can also communicate with each other via an RSU that delivers scheduling information for wireless communication in order to save the smartphones' battery through sleeping mode. For Vehicle-to-Pedestrian (V2P), a vehicle and a pedestrian's smartphone can directly communicate with each other via V2X without the relaying of an RSU as in a V2V scenario such that the pedestrian's smartphone is regarded as a vehicle with a wireless media interface to be able to communicate with another vehicle. In Vehicle-to-Device (V2D), a device can be a mobile node such as bicycle and motorcycle, and can communicate directly with a vehicle for collision avoidance. Jeong Expires May 8, 2019 [Page 7] Internet-Draft IPWAVE Problem Statement November 2018 4. Analysis for Existing Protocols 4.1. Existing Protocols for Vehicular Networking We describe some currently existing protocols and proposed solutions with respect to the following aspects that are relevant and essential for vehicular networking: o IPv6 over 802.11-OCB; o IP address autoconfiguration; o Routing; [Sri] Is Routing a protocol? Are these protocols, or services ? o Mobility management; o DNS naming service; o Service discovery; o Security and privacy. 4.1.1. IPv6 over 802.11-OCB For IPv6 packets transporting over IEEE 802.11-OCB, [IPv6-over-802.11-OCB] specifies several details, such as Maximum Transmission Unit (MTU), frame format, link-local address, address mapping for unicast and multicast, stateless autoconfiguration, and subnet structure. Especially, an Ethernet Adaptation (EA) layer is in charge of transforming some parameters between IEEE 802.11 MAC layer and IPv6 network layer, which is located between IEEE 802.11-OCB's logical link control layer and IPv6 network layer. [Sri] But, what is the point from the point of view of this spec? 4.1.2. IP Address Autoconfiguration For IP address autoconfiguration, Fazio et al. proposed a vehicular address configuration (VAC) scheme using DHCP where elected leader- vehicles provide unique identifiers for IP address configurations in vehicles [Address-Autoconf]. Kato et al. proposed an IPv6 address assignment scheme using lane and position information [Address-Assignment]. Baldessari et al. proposed an IPv6 scalable address autoconfiguration scheme called GeoSAC for vehicular networks [GeoSAC]. Wetterwald et al. conducted for heterogeneous vehicular networks (i.e., employing multiple access technologies) a comprehensive study of the cross-layer identities management, which constitutes a fundamental element of the ITS architecture [Identity-Management]. [Sri] The focus of the document should be on the problem statement. We have= departed from that and now we are talking solutions. I see this problem th= rough out this spec. Jeong Expires May 8, 2019 [Page 8] Internet-Draft IPWAVE Problem Statement November 2018 4.1.3. Routing For routing, Tsukada et al. presented a work that aims at combining IPv6 networking and a Car-to-Car Network routing protocol (called C2CNet) proposed by the Car2Car Communication Consortium (C2C-CC), which is an architecture using a geographic routing protocol [VANET-Geo-Routing]. Abrougui et al. presented a gateway discovery scheme for VANET, called Location-Aided Gateway Advertisement and Discovery (LAGAD) mechanism [LAGAD]. [Sri] Again, the focus of the document should be on problem statement, not = on solutions 4.1.4. Mobility Management For mobility management, Chen et al. tackled the= issue of network fragmentation in VANET environments [IP-Passing-Protocol]= by proposing a protocol that can postpone the time to release IP addresses= to the DHCP server and select a faster way to get the vehicle's new IP add= ress, when the vehicle density is low or the speeds of vehicles are highly = variable. Nguyen et al. proposed a hybrid centralized-distributed mobility = management called H-DMM to support highly mobile vehicles [H-DMM]. [NEMO-LM= S] proposed an architecture to enable IP mobility for moving networks using= a network-based mobility scheme based on PMIPv6. Chen et al. proposed a ne= twork mobility protocol to reduce handoff delay and maintain Internet conne= ctivity to moving vehicles in a highway [NEMO-VANET]. Lee et al. proposed P= -NEMO, which is a PMIPv6-based IP mobility management scheme to maintain th= e Internet connectivity at the vehicle as a mobile network, and provides a = make-before-break mechanism when vehicles switch to a new access network [P= MIP-NEMO-Analysis]. Peng et al. proposed a novel mobility management scheme= for integration of VANET and fixed IP networks [VNET-MM]. Nguyen et al. ex= tended their previous works on a vehicular adapted DMM considering a Softwa= re-Defined Networking (SDN) architecture [SDN-DMM]. [Sri] The focus of the document should on the problem statement, not on sol= utions. This platter of requirements are discrete and not connecting back t= o a larger architecture. 4.1.5. DNS Naming Service For DNS naming service, Multicast DNS (mDNS) [RFC= 6762] allows devices in one-hop communication range to resolve each other's= DNS name into the corresponding IP address in multicast. DNS Name Autoconf= iguration (DNSNA) [ID-DNSNA] proposes a DNS naming service for Internet-of-= Things (IoT) devices in a large-scale network. [Sri] Sure, but our goal is to talk about the problems when using this in v= ehicular context. I don=92t see that discussion 4.1.6. Service Discovery To discover instances of a demanded service in vehicular networks, DNS-based Service Discovery (DNS-SD) [RFC6763] with either DNSNA [ID-DNSNA] or mDNS [RFC6762] provides vehicles with service discovery by using standard DNS queries. Vehicular ND [ID-Vehicular-ND] Jeong Expires May 8, 2019 [Page 9] Internet-Draft IPWAVE Problem Statement November 2018 proposes an extension of IPv6 ND for the prefix and service discovery with new ND options [ID-VND-Discovery]. Note that a DNS query for service discovery is unicasted in DNSNA, but it is multicasted in both mDNS and Vehicular ND. [Sri] We have now departed to from PS world, to Solution world. 4.1.7. Security and Privacy For security and privacy, Fernandez et al. proposed a secure vehicular IPv6 communication scheme using Internet Key Exchange version 2 (IKEv2) and Internet Protocol Security (IPsec) [Securing-VCOMM]. Moustafa et al. proposed a security scheme providing authentication, authorization, and accounting (AAA) services in vehicular networks [VNET-AAA]. [Sri] I do not know if Fernandez et all, covered the problem description, b= ut we should first talk about the problem before we talk about solution 4.2. General Problems This section describes a possible vehicular network architecture for V2V, V2I, and V2X communications. Then it analyzes the limitations of the current protocols for vehicular networking. Jeong Expires May 8, 2019 [Page 10] Internet-Draft IPWAVE Problem Statement November 2018 Traffic Control Center in Vehicular Cloud *-----------------------------------------* * * * +----------------+ * * | Mobility Anchor| * * +----------------+ * * ^ * * | * *--------------------v--------------------* ^ ^ ^ | | | +------------------ | -------------|-------------+ +------------------+ | v v | | v | | +--------+ Ethernet +--------+ | | +--------+ | | | RSU1 |<----------->| RSU2 |<---------->| RSU3 | | | +--------+ +--------+ | | +--------+ | | ^ ^ ^ | | ^ | | : : : | | : | | V2I : : V2I V2I : | | V2I : | | v v v | | v | | +--------+ +--------+ +--------+ | | +--------+ | | |Vehicle1|=3D=3D=3D> |Vehicle2|=3D=3D=3D> |Vehicle3|=3D=3D=3D>| | = |Vehicle4|=3D=3D=3D>| | | |<....>| |<....>| | | | | | | | +--------+ V2V +--------+ V2V +--------+ | | +--------+ | | | | | +-------------------------------------------------+ +------------------+ Subnet1 Subnet2 <----> Wired Link <....> Wireless Link =3D=3D=3D> Moving Direction Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 4.2.1. Vehicular Network Architecture Figure 1 shows a possible architecture for V2I and V2V networking in a road network. It is assumed that RSUs as routers and vehicles with OBU have wireless media interfaces (e.g., IEEE 802.11-OCB, LTE Uu and Device-to-Device (D2D) (also known as PC5 [TS-23.285-3GPP]), Bluetooth, and Light Fidelity (Li-Fi)) for V2I and V2V communication. Also, it is assumed that such the wireless media interfaces are autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to support both V2V and V2I networking. Three RSUs (RSU1, RSU2, and RSU3) are deployed in the road network and are connected to a Vehicular Cloud through the Internet. A Traffic Control Center (TCC) is connected to the Vehicular Cloud for the management of RSUs and vehicles in the road network. A Mobility Anchor (MA) is located in the TCC as its key component for the mobility management of vehicles. Two vehicles (Vehicle1 and Vehicle2) are wirelessly connected to Jeong Expires May 8, 2019 [Page 11] Internet-Draft IPWAVE Problem Statement November 2018 RSU1, and one vehicle (Vehicle3) is wirelessly connected to RSU2. The wireless networks of RSU1 and RSU2 belong to a multi-link subnet (denoted as Subnet1) with the same network prefix. Thus, these three vehicles are within the same subnet. On the other hand, another vehicle (Vehicle4) is wireless connected to RSU4, belonging to another subnet (denoted as Subnet2). That is, the first three vehicles (i.e., Vehicle1, Vehicle2, and Vehicle3) and the last vehicle (i.e., Vehicle4) are located in the two different subnets. Vehicle1 can communicate with Vehicle2 via V2V communication, and Vehicle2 can communicate with Vehicle3 via V2V communication because they are within the same subnet along their IPv6 addresses, which are based on the same prefix. On the other hand, Vehicle3 can communicate with Vehicle4 via RSU2 and RSU3 employing V2I (i.e., V2I2V) communication because they are within the two different subnets along with their IPv6 addresses, which are based on the two different prefixes. In vehicular networks, unidirectional links exist and must be considered for wireless communications. Also, in the vehicular networks, control plane must be separated from data plane for efficient mobility management and data forwarding using Software- Defined Networking (SDN) [SDN-DMM]. ID/Pseudonym change for privacy requires a lightweight DAD. IP tunneling over the wireless link should be avoided for performance efficiency. The mobility information of a mobile (e.g., vehicle-mounted) device through a GPS receiver in its vehicle, such as trajectory, position, speed, and direction, can be used by the mobile device and infrastructure nodes (e.g., TCC and RSU) for the accommodation of mobility-aware proactive protocols. Vehicles can use the TCC as their Home Network having a home agent for mobility management as in MIPv6 [RFC6275] and Proxy Mobile IPv6 (PMIPv6) [RFC5213], so the TCC maintains the mobility information of vehicles for location management. Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for I2V and V2I networking [VIP-WAVE]. The standard WAVE does not support both seamless communications for Internet services and multi- hop communications between a vehicle and an infrastructure node (e.g., RSU), either. To overcome these limitations of the standard WAVE, VIP-WAVE enhances the standard WAVE by the following three schemes: (i) an efficient mechanism for the IPv6 address assignment and DAD, (ii) on-demand IP mobility based on PMIPv6 [RFC5213], and (iii) one-hop and two-hop communications for I2V and V2I networking. Baccelli et al. provided an analysis of the operation of IPv6 as it has been described by the IEEE WAVE standards 1609 [IPv6-WAVE]. This analysis confirms that the use of the standard IPv6 protocol stack in WAVE is not sufficient. It recommends that the IPv6 addressing Jeong Expires May 8, 2019 [Page 12] Internet-Draft IPWAVE Problem Statement November 2018 assignment should follow considerations for ad-hoc link models, defined in [RFC5889] for nodes' mobility and link variability. Petrescu et al. proposed the joint IP networking and radio architecture for V2V and V2I communication in [Joint-IP-Networking]. The proposed architecture considers an IP topology in a similar way as a radio link topology, in the sense that an IP subnet would correspond to the range of 1-hop vehicular communication. This architecture defines three types of vehicles: Leaf Vehicle, Range Extending Vehicle, and Internet Vehicle. +----------------+ (*)<........>(*) +----->| Vehicular Cloud| 2001:DB8:1:1::/64 | | | +----------------+ +------------------------------+ +---------------------------------+ | v | | v v | | .-------. .------. .-------. | | .-------. .------. .-------. | | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | | ._______. .______. ._______. | | ._______. .______. ._______. | | ^ ^ ^ | | ^ ^ ^ | | | | | | | | | | | | v v v | | v v v | | ---------------------------- | | ------------------------------- | | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | | | | | | | | v | | v | | .-------. .-------. | | .-------. .-------. .-------. | | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | | ._______. ._______. | | ._______. ._______. ._______. | | ^ ^ | | ^ ^ ^ | | | | | | | | | | | v v | | v v v | | ---------------------------- | | ------------------------------- | | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | +______________________________+ +_________________________________+ Vehicle1 (Moving Network1) RSU1 (Fixed Network1) <----> Wired Link <....> Wireless Link (*) Antenna Figure 2: Internetworking between Vehicle Network and RSU Network 4.2.1.1. V2I-based Internetworking This section discusses the internetworking between a vehicle's moving network and an RSU's fixed network via V2I communication. As shown in Figure 2, the vehicle's moving network and the RSU's fixed network are self-contained networks having multiple subnets and Jeong Expires May 8, 2019 [Page 13] Internet-Draft IPWAVE Problem Statement November 2018 having an edge router for the communication with another vehicle or RSU. The method of prefix assignment for each subnet inside the vehicle's mobile network and the RSU's fixed network is out of scope for this document. Internetworking between two internal networks via V2I communication requires an exchange of network prefix and other parameters through a prefix discovery mechanism, such as ND-based prefix discovery [ID-VND-Discovery]. For the ND-based prefix discovery, network prefixs and parameters should be registered into a vehicle's router and an RSU router with an external network interface in advance. The network parameter discovery collects networking information for an IP communication between a vehicle and an RSU or between two neighboring vehicles, such as link layer, MAC layer, and IP layer information. The link layer information includes wireless link layer parameters, such as wireless media (e.g., IEEE 802.11-OCB, LTE Uu and D2D, Bluetooth, and LiFi) and a transmission power level. Note that LiFi is a technology for light-based wireless communication between devices in order to transmit both data and position. The MAC layer information includes the MAC address of an external network interface for the internetworking with another vehicle or RSU. The IP layer information includes the IP address and prefix of an external network interface for the internetworking with another vehicle or RSU. [Sri] Why bring LiFi? We started with 802.11OCB, IPv6 for 802.11OCB and now= we have entered LiFi space? Why? Once the network parameter discovery and prefix exchange operations have been performed, packets can be transmitted between the vehicle's moving network and the RSU's fixed network. DNS services should be supported to enable name resolution for hosts or servers residing either in the vehicle's moving network or the RSU's fixed network. It is assumed that the DNS names of in-vehicle devices and their service names are registered into a DNS server (i.e., recursive DNS server called RDNSS) in a vehicle or an RSU, as shown in Figure 2. For service discovery, those DNS names and service names can be advertised to neighboring vehicles through either DNS-based service discovery mechanisms [RFC6762][RFC6763][ID-DNSNA] and ND-based service discovery [ID-Vehicular-ND][ID-VND-Discovery]. For the ND- based service discovery, service names should be registered into a vehicle's router and an RSU router with an external network interface in advance. Refer to Section 4.1.5 and Section 4.1.6 for detailed information. For these DNS services, an RDNSS within each internal network of a vehicle or RSU can be used for the hosts or servers. Figure 2 shows internetworking between the vehicle's moving network and the RSU's fixed network. There exists an internal network (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and Host2), and the two routers (Router1 and Router2). There exists another internal network (Fixed Network1) inside RSU1. RSU1 has the DNS Server (RDNSS2), one host Jeong Expires May 8, 2019 [Page 14] Internet-Draft IPWAVE Problem Statement November 2018 (Host3), the two routers (Router3 and Router4), and the collection of servers (Server1 to ServerN) for various services in the road networks, such as the emergency notification and navigation. Vehicle1's Router1 (called mobile router) and RSU1's Router3 (called fixed router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for I2V networking. (*)<..........>(*) 2001:DB8:1:1::/64 | | +------------------------------+ +---------------------------------+ | v | | v | | .-------. .------. .-------. | | .-------. .------. .-------. | | | Host1 | |RDNSS1| |Router1| | | |Router5| |RDNSS3| | Host4 | | | ._______. .______. ._______. | | ._______. .______. ._______. | | ^ ^ ^ | | ^ ^ ^ | | | | | | | | | | | | v v v | | v v v | | ---------------------------- | | ------------------------------- | | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | | | | | | | | v | | v | | .-------. .-------. | | .-------. .-------. | | | Host2 | |Router2| | | |Router6| | Host5 | | | ._______. ._______. | | ._______. ._______. | | ^ ^ | | ^ ^ | | | | | | | | | | v v | | v v | | ---------------------------- | | ------------------------------- | | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | +______________________________+ +_________________________________+ Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) <----> Wired Link <....> Wireless Link (*) Antenna Figure 3: Internetworking between Two Vehicle Networks 4.2.1.2. V2V-based Internetworking This section discusses the internetworking between the moving networks of two neighboring vehicles via V2V communication. Figure 3 shows internetworking between the moving networks of two neighboring vehicles. There exists an internal network (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and Host2), and the two routers (Router1 and Router2). There exists another internal network (Moving Network2) inside Vehicle2. Vehicle2 has the DNS Server (RDNSS3), the two hosts (Host4 and Host5), and the two routers (Router5 and Router6). Jeong Expires May 8, 2019 [Page 15] Internet-Draft IPWAVE Problem Statement November 2018 Vehicle1's Router1 (called mobile router) and Vehicle2's Router5 (called mobile router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for V2V networking. The differences between IPWAVE (including Vehicular Ad Hoc Networks (VANET)) and Mobile Ad Hoc Networks (MANET) are as follows: o IPWAVE is not power-constrained operation; o Traffic can be sourced or sinked outside of IPWAVE; o IPWAVE shall support both distributed and centralized operations; o No "sleep" period operation is required for energy saving. [Sri] Why is this discussion needed? Why talk about AdHoc networks? 4.2.2. Latency The communication delay (i.e., latency) between two vehicular nodes (vehicle and RSU) should be bounded to a certain threshold. For IP- based safety applications (e.g., context-aware navigation, adaptive cruise control, and platooning) in vehicular network, this bounded data delivery is critical. The real implementations for such applications are not available, so the feasibility of IP-based safety applications is not tested yet. [Sri] This is a good requirement. This is the right tone. You may want to q= ualify further and put some additional latency considerations, goals based = on the use-cases. 4.2.3. Security Strong security measures shall protect vehicles roaming in road networks from the attacks of malicious nodes, which are controlled by hackers. For safety applications, the cooperation among vehicles is assumed. Malicious nodes may disseminate wrong driving information (e.g., location, speed, and direction) to make driving be unsafe. Sybil attack, which tries to illude a vehicle with multiple false identities, disturbs a vehicle in taking a safe maneuver. Applications on IP-based vehicular networking, which are resilient to such a sybil attack, are not developed and tested yet. [Sri] Please translate this to a specific requirement. We want security fo= r sure and everywhere, not just in vehicular networks. What is new and what= s the new requirement? Identity? Please explain 4.2.4. Pseudonym Handling For the protection of drivers' privacy, pseudonym for a vehicle's network interface should be used, with the help of which the interface's identifier can be changed periodically. Such a pseudonym affects an IPv6 address based on the network interface's identifier, and a transport-layer (e.g., TCP) session with an IPv6 address pair. The pseudonym handling is not implemented and tested yet for applications on IP-based vehicular networking. [Sri] This is about MAC address? Jeong Expires May 8, 2019 [Page 16] Internet-Draft IPWAVE Problem Statement= November 2018 5. Problem Exploration This section discusses key topics for= IPWAVE WG, such as neighbor discovery, mobility management, and security &= privacy. 5.1. Neighbor Discovery Neighbor Discovery (ND) [RFC4861] is a co= re part of the IPv6 protocol suite. This section discusses the need for mod= ifying ND for use with vehicular networking (e.g., V2V, V2I, and V2X). The = vehicles are moving fast within the communication coverage of a vehicular n= ode (e.g., vehicle and RSU). The external wireless link between two vehicul= ar nodes can be used for vehicular networking, as shown in Figure 2 and Fig= ure 3. ND time-related parameters such as router lifetime and Neighbor Adve= rtisement (NA) interval should be adjusted for high-speed vehicles and vehi= cle density. As vehicles move faster, the NA interval should decrease for t= he NA messages to reach the neighboring vehicles promptly. Also, as vehicle= density is higher, the NA interval should increase for the NA messages to = reduce collision probability with other NA messages. 5.1.1. Link Model IPv6= protocols work under certain assumptions for the link model that do not ne= cessarily hold in a vehicular wireless link [VIP-WAVE]. For instance, some = IPv6 protocols assume symmetry in the connectivity among neighboring interf= aces. However, interference and different levels of transmission power may = cause unidirectional links to appear in vehicular wireless links. As a resu= lt, a new vehicular link model is required for the vehicular wireless link.= There is a relationship between a link and prefix, besides the different s= copes that are expected from the link-local and global types of IPv6 addres= ses. In an IPv6 link, it is assumed that all interfaces which are configure= d with the same subnet prefix and with on-link bit set can communicate with= each other on an IP link or extended IP links via ND proxy. Note that a su= bnet prefix can be used by spanning multiple links as a multi-link subnet [= RFC6775]. Also, note that IPv6 Stateless Address Autoconfiguration can be p= erformed in the multiple links where each of them is not assigned with a un= ique subnet prefix, that is, all of them are configured with the same subne= t prefix [RFC4861][RFC4862]. A vehicular link model needs to consider a mul= ti-hop VANET over a multi-link subnet. Such a VANET is usually a multi-link= subnet consisting of multiple vehicles interconnected by wireless communic= ation range. Such a subnet has a highly dynamic topology over time due to n= ode mobility. Jeong Expires May 8, 2019 [Page 17] Internet-Draft IPWAVE Pro= blem Statement November 2018 Thus, IPv6 ND should be extended into a Vehicu= lar Neighbor Discovey (VND) [ID-Vehicular-ND] to support the concept of an = IPv6 link corresponding to an IPv6 prefix even in a multi-link subnet consi= sting of multiple vehicles and RSUs that are interconnected with wireless c= ommunication range in IP-based vehicular networks. 5.1.2. MAC Address Pseud= onym In the ETSI standards, for the sake of security and privacy, an ITS st= ation (e.g., vehicle) can use pseudonyms for its network interface identiti= es (e.g., MAC address) and the corresponding IPv6 addresses [Identity-Manag= ement]. Whenever the network interface identifier changes, the IPv6 address= based on the network interface identifier should be updated. For the conti= nuity of an end-to-end (E2E) transport-layer (e.g., TCP, UDP, and SCTP) ses= sion, with a mobility management scheme (e.g., MIPv6 and PMIPv6), the new I= P address for the transport-layer session should be notified to an appropri= ate end point, and the packets of the session should be forwarded to their = destinations with the changed network interface identifier and IPv6 address= . 5.1.3. Prefix Dissemination/Exchange A vehicle and an RSU can have their = internal network, as shown in Figure 2 and Figure 3. In this case, nodes in= within the internal networks of two vehicular nodes (e.g., vehicle and RSU= ) want to communicate with each other. For this communication on the wirele= ss link, the network prefix dissemination or exchange is required. It is as= sumed that a vehicular node has an external network interface and its inter= nal network. The legacy IPv6 ND [RFC4861] needs to be extended to a vehicul= ar ND (VND) [ID-Vehicular-ND] for the communication between the internal-ne= twork nodes (e.g., an in-vehicle device in a vehicle and a server in an RSU= ) of vehicular nodes by letting each of them know the other side's prefix w= ith a new ND option [ID-VND-Discovery]. Thus, this ND extension for routing= functionality can reduce control traffic for routing in vehicular networks= without an additional vehicular ad hoc routing protocol [VANET-Geo-Routing= ]. 5.1.4. Routing For multihop V2V communications in a multi-link subnet (a= s a connected VANET), a vehicular ad hoc routing protocol (e.g., geographic= routing) may be required to support both unicast and multicast in the link= s of the subnet with the same IPv6 prefix [VANET-Geo-Routing]. Instead of t= he vehicular ad hoc routing protocol, Vehicular ND along with a prefix disc= overy option can be used to let vehicles exchange their prefixes in a multi= hop fashion Jeong Expires May 8, 2019 [Page 18] Internet-Draft IPWAVE Probl= em Statement November 2018 [ID-Vehicular-ND][ID-VND-Discovery]. With the ex= changed prefixes, they can compute their routing table (or IPv6 ND's neighb= or cache) for the multi-link subnet with a distance-vector algorithm [Intro= -to-Algorithms]. Also, an efficient, rapid DAD should be supported to preve= nt or reduce IPv6 address conflicts in the multi- link subnet by using a DA= D optimization [ID-Vehicular-ND][RFC6775] or an IPv6 geographic-routing-bas= ed address autoconfiguration [GeoSAC]. 5.2. Mobility Management The seamles= s connectivity and timely data exchange between two end points requires an = efficient mobility management including location management and handover. M= ost of vehicles are equipped with a GPS receiver as part of a dedicated nav= igation system or a corresponding smartphone App. In the case where the pro= vided location information is precise enough, well-known temporary degradat= ions in precision may occur due to system configuration or the adverse loca= l environment. This precision is improved thanks to assistance by the RSUs = or a cellular system with this navigation system. With this GPS navigator, = an efficient mobility management is possible by vehicles periodically repor= ting their current position and trajectory (i.e., navigation path) to RSUs = and a Mobility Anchor (MA) in TCC. The RSUs and MA can predict the future p= ositions of the vehicles with their mobility information (i.e., the current= position, speed, direction, and trajectory) for the efficient mobility man= agement (e.g., proactive handover). For a better proactive handover, link-l= ayer parameters, such as the signal strength of a link-layer frame (e.g., R= eceived Channel Power Indicator (RCPI) [VIP-WAVE]), can be used to determin= e the moment of a handover between RSUs along with mobility information [ID= -Vehicular-ND]. With the prediction of the vehicle mobility, MA can support= RSUs to perform DAD, data packet routing, horizontal handover (i.e., hando= ver in wireless links using a homogeneous radio technology), and vertical h= andover (i.e., handover in wireless links using heterogeneous radio technol= ogies) in a proactive manner. Even though a vehicle moves into the wireless= link under another RSU belonging to a different subnet, the RSU can proact= ively perform the DAD for the sake of the vehicle, reducing IPv6 control tr= affic overhead in the wireless link [ID-Vehicular-ND]. Therefore, with a pr= oactive handover and a multihop DAD in vehicular networks [ID-Vehicular-ND]= , RSUs can efficiently forward data packets from the wired network (or the = wireless network) to a moving destination vehicle along its trajectory alon= g with the MA. Thus, a moving vehicle can communicate with its correspondin= g vehicle in the vehicular network or a host/server in the Internet along i= ts trajectory. Jeong Expires May 8, 2019 [Page 19] Internet-Draft IPWAVE Pr= oblem Statement November 2018 5.3. Security and Privacy Security and privac= y are paramount in the V2I, V2V, and V2X networking in vehicular networks. = Only authorized vehicles should be allowed to use vehicular networking. Als= o, in-vehicle devices and mobile devices in a vehicle need to communicate w= ith other in-vehicle devices and mobile devices in another vehicle, and oth= er servers in an RSU in a secure way. A Vehicle Identification Number (VIN)= and a user certificate along with in-vehicle device's identifier generatio= n can be used to efficiently authenticate a vehicle or a user through a roa= d infrastructure node (e.g., RSU) connected to an authentication server in = TCC. Also, Transport Layer Security (TLS) certificates can be used for secu= re E2E vehicle communications. For secure V2I communication, a secure chann= el between a mobile router in a vehicle and a fixed router in an RSU should= be established, as shown in Figure 2. Also, for secure V2V communication, = a secure channel between a mobile router in a vehicle and a mobile router i= n another vehicle should be established, as shown in Figure 3. To prevent a= n adversary from tracking a vehicle with its MAC address or IPv6 address, M= AC address pseudonym should be provided to the vehicle; that is, each vehic= le should periodically update its MAC address and the corresponding IPv6 ad= dress as suggested in [RFC4086][RFC4941]. Such an update of the MAC and IPv= 6 addresses should not interrupt the E2E communications between two vehicul= ar nodes (e.g., vehicle and RSU) in terms of transport layer for a long- li= ving higher-layer session. However, if this pseudonym is performed without = strong E2E confidentiality, there will be no privacy benefit from changing = MAC and IP addresses, because an adversary can see the change of the MAC an= d IP addresses and track the vehicle with those addresses. 6. Security Cons= iderations This document discussed security and privacy for IP-based vehicu= lar networking. The security and privacy for key components in IP-based veh= icular networking, such as neighbor discovery and mobility management, need= to be analyzed in depth. Jeong Expires May 8, 2019 [Page 20] Internet-Draf= t IPWAVE Problem Statement November 2018 7. Informative References [Address= -Assignment] Kato, T., Kadowaki, K., Koita, T., and K. Sato, "Routing and A= ddress Assignment using Lane/Position Information in a Vehicular Ad-hoc Net= work", IEEE Asia-Pacific Services Computing Conference, December 2008. [Add= ress-Autoconf] Fazio, M., Palazzi, C., Das, S., and M. Gerla, "Automatic IP= Address Configuration in VANETs", ACM International Workshop on Vehicular = Inter-Networking, September 2016. [Automotive-Sensing] Choi, J., Va, V., Go= nzalez-Prelcic, N., Daniels, R., R. Bhat, C., and R. W. Heath, "Millimeter-= Wave Vehicular Communication to Support Massive Automotive Sensing", IEEE C= ommunications Magazine, December 2016. [Broadcast-Storm] Wisitpongphan, N.,= K. Tonguz, O., S. Parikh, J., Mudalige, P., Bai, F., and V. Sadekar, "Broa= dcast Storm Mitigation Techniques in Vehicular Ad Hoc Networks", IEEE Wirel= ess Communications, December 2007. [CA-Cruise-Control] California Partners = for Advanced Transportation Technology (PATH), "Cooperative Adaptive Cruise= Control", [Online] Available: http://www.path.berkeley.edu/research/automa= ted-and- connected-vehicles/cooperative-adaptive-cruise-control, 2017. [CAS= D] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A Framework of Context-A= wareness Safety Driving in Vehicular Networks", International Workshop on D= evice Centric Cloud (DC2), March 2016. [DSRC] ASTM International, "Standard= Specification for Telecommunications and Information Exchange Between Road= side and Vehicle Systems - 5 GHz Band Dedicated Short Range Communications = (DSRC) Medium Access Control (MAC) and Physical Layer (PHY) Specifications"= , ASTM E2213-03(2010), October 2010. Jeong Expires May 8, 2019 [Page 21] In= ternet-Draft IPWAVE Problem Statement November 2018 [ETSI-GeoNetwork-IP] ET= SI Technical Committee Intelligent Transport Systems, "Intelligent Transpor= t Systems (ITS); Vehicular Communications; GeoNetworking; Part 6: Internet = Integration; Sub-part 1: Transmission of IPv6 Packets over GeoNetworking Pr= otocols", ETSI EN 302 636-6-1, October 2013. [ETSI-GeoNetworking] ETSI Tech= nical Committee Intelligent Transport Systems, "Intelligent Transport Syste= ms (ITS); Vehicular Communications; GeoNetworking; Part 4: Geographical add= ressing and forwarding for point-to-point and point-to- multipoint communic= ations; Sub-part 1: Media-Independent Functionality", ETSI EN 302 636-4-1, = May 2014. [EU-2008-671-EC] European Union, "Commission Decision of 5 August= 2008 on the Harmonised Use of Radio Spectrum in the 5875 - 5905 MHz Freque= ncy Band for Safety-related Applications of Intelligent Transport Systems (= ITS)", EU 2008/671/EC, August 2008. [FirstNet] U.S. National Telecommunicat= ions and Information Administration (NTIA), "First Responder Network Author= ity (FirstNet)", [Online] Available: https://www.firstnet.gov/, 2012. [Firs= tNet-Report] First Responder Network Authority, "FY 2017: ANNUAL REPORT TO = CONGRESS, Advancing Public Safety Broadband Communications", FirstNet FY 20= 17, December 2017. [Fuel-Efficient] van de Hoef, S., H. Johansson, K., and = D. V. Dimarogonas, "Fuel-Efficient En Route Formation of Truck Platoons", I= EEE Transactions on Intelligent Transportation Systems, January 2018. [GeoS= AC] Baldessari, R., Bernardos, C., and M. Calderon, "GeoSAC - Scalable Addr= ess Autoconfiguration for VANET Using Geographic Networking Concepts", IEEE= International Symposium on Personal, Indoor and Mobile Radio Communication= s, September 2008. Jeong Expires May 8, 2019 [Page 22] Internet-Draft IPWAV= E Problem Statement November 2018 [H-DMM] Nguyen, T. and C. Bonnet, "A Hybr= id Centralized- Distributed Mobility Management for Supporting Highly Mobil= e Users", IEEE International Conference on Communications, June 2015. [ID-D= NSNA] Jeong, J., Ed., Lee, S., and J. Park, "DNS Name Autoconfiguration for= Internet of Things Devices", draft- jeong-ipwave-iot-dns-autoconf-04 (work= in progress), October 2018. [ID-Vehicular-ND] Xiang, Zhong., Jeong, J., Ed= ., and Y. Shen, "IPv6 Neighbor Discovery for IP-Based Vehicular Networks", = draft-xiang- ipwave-vehicular-neighbor-discovery-00 (work in progress), Nov= ember 2018. [ID-VND-Discovery] Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J.,= and J. Lee, "IPv6 Neighbor Discovery for Prefix and Service Discovery in V= ehicular Networks", draft-jeong-ipwave-vehicular- neighbor-discovery-04 (wo= rk in progress), October 2018. [Identity-Management] Wetterwald, M., Hrizi,= F., and P. Cataldi, "Cross-layer Identities Management in ITS Stations", T= he 10th International Conference on ITS Telecommunications, November 2010. = [IEEE-802.11-OCB] IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium = Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802= .11-2016, December 2016. [IEEE-802.11p] IEEE 802.11 Working Group, "Part 11= : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifi= cations - Amendment 6: Wireless Access in Vehicular Environments", IEEE Std= 802.11p-2010, June 2010. [Intro-to-Algorithms] H. Cormen, T., E. Leiserson= , C., L. Rivest, R., and C. Stein, "Introduction to Algorithms, 3rd ed.", T= he MIT Press, July 2009. Jeong Expires May 8, 2019 [Page 23] Internet-Draft= IPWAVE Problem Statement November 2018 [IP-Passing-Protocol] Chen, Y., Hsu= , C., and W. Yi, "An IP Passing Protocol for Vehicular Ad Hoc Networks with= Network Fragmentation", Elsevier Computers & Mathematics with Applications= , January 2012. [IPv6-over-802.11-OCB] Petrescu, A., Benamar, N., Haerri, J= ., Lee, J., and T. Ernst, "Transmission of IPv6 Packets over IEEE 802.11 Ne= tworks operating in mode Outside the Context of a Basic Service Set (IPv6-o= ver-80211-OCB)", draft-ietf-ipwave- ipv6-over-80211ocb-30 (work in progress= ), September 2018. [IPv6-WAVE] Baccelli, E., Clausen, T., and R. Wakikawa, = "IPv6 Operation for WAVE - Wireless Access in Vehicular Environments", IEEE= Vehicular Networking Conference, December 2010. [ISO-ITS-IPv6] ISO/TC 204,= "Intelligent Transport Systems - Communications Access for Land Mobiles (C= ALM) - IPv6 Networking", ISO 21210:2012, June 2012. [Joint-IP-Networking] P= etrescu, A., Boc, M., and C. Ibars, "Joint IP Networking and Radio Architec= ture for Vehicular Networks", 11th International Conference on ITS Telecomm= unications, August 2011. [LAGAD] Abrougui, K., Boukerche, A., and R. Pazzi,= "Location-Aided Gateway Advertisement and Discovery Protocol for VANets", = IEEE Transactions on Vehicular Technology, Vol. 59, No. 8, October 2010. [M= ulticast-802] Perkins, C., Stanley, D., Kumari, W., and JC. Zuniga, "Multic= ast Considerations over IEEE 802 Wireless Media", draft-perkins-intarea-mul= ticast-ieee802-03 (work in progress), July 2017. [Multicast-Alert] Camara, = D., Bonnet, C., Nikaein, N., and M. Wetterwald, "Multicast and Virtual Road= Side Units for Multi Technology Alert Messages Dissemination", IEEE 8th In= ternational Conference on Mobile Ad-Hoc and Sensor Systems, October 2011. J= eong Expires May 8, 2019 [Page 24] Internet-Draft IPWAVE Problem Statement = November 2018 [NEMO-LMS] Soto, I., Bernardos, C., Calderon, M., Banchs, A.,= and A. Azcorra, "NEMO-Enabled Localized Mobility Support for Internet Acce= ss in Automotive Scenarios", IEEE Communications Magazine, May 2009. [NEMO-= VANET] Chen, Y., Hsu, C., and C. Cheng, "Network Mobility Protocol for Vehi= cular Ad Hoc Networks", Wiley International Journal of Communication System= s, November 2014. [PMIP-NEMO-Analysis] Lee, J., Ernst, T., and N. Chilamkur= ti, "Performance Analysis of PMIPv6-Based Network Mobility for Intelligent = Transportation Systems", IEEE Transactions on Vehicular Technology, January= 2012. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomnes= s Requirements for Security", RFC 4086, June 2005. [RFC4861] Narten, T., No= rdmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version= 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., an= d T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, Septembe= r 2007. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensi= ons for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2= 007. [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, = K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5889] Bac= celli, E. and M. Townsley, "IP Addressing Model in Ad Hoc Networks", RFC 58= 89, September 2010. [RFC5944] Perkins, C., Ed., "IP Mobility Support in IPv= 4, Revised", RFC 5944, November 2010. [RFC6275] Perkins, C., Ed., Johnson, = D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [RFC6762= ] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013. J= eong Expires May 8, 2019 [Page 25] Internet-Draft IPWAVE Problem Statement = November 2018 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Di= scovery", RFC 6763, February 2013. [RFC6775] Shelby, Z., Chakrabarti, S., N= ordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over= Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November = 2012. [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, = "Requirements for Distributed Mobility Management", RFC 7333, August 2014. = [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. Bernardos, "Di= stributed Mobility Management: Current Practices and Gap Analysis", RFC 742= 9, January 2015. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, V= ersion 6 (IPv6) Specification", RFC 8200, July 2017. [SAINT] Jeong, J., Jeo= ng, H., Lee, E., Oh, T., and D. Du, "SAINT: Self-Adaptive Interactive Navig= ation Tool for Cloud-Based Vehicular Traffic Optimization", IEEE Transactio= ns on Vehicular Technology, Vol. 65, No. 6, June 2016. [SAINTplus] Shen, Y.= , Lee, J., Jeong, H., Jeong, J., Lee, E., and D. Du, "SAINT+: Self-Adaptive= Interactive Navigation Tool+ for Emergency Service Delivery Optimization",= IEEE Transactions on Intelligent Transportation Systems, June 2017. [SANA]= Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation Application for Ped= estrian Protection in Vehicular Networks", Springer Lecture Notes in Comput= er Science (LNCS), Vol. 9502, December 2015. [SDN-DMM] Nguyen, T., Bonnet, = C., and J. Harri, "SDN-based Distributed Mobility Management for 5G Network= s", IEEE Wireless Communications and Networking Conference, April 2016. [Se= curing-VCOMM] Fernandez, P., Santa, J., Bernal, F., and A. Skarmeta, "Secur= ing Vehicular IPv6 Communications", IEEE Transactions on Dependable and Sec= ure Computing, January 2016. Jeong Expires May 8, 2019 [Page 26] Internet-D= raft IPWAVE Problem Statement November 2018 [TR-22.886-3GPP] 3GPP, "Study o= n Enhancement of 3GPP Support for 5G V2X Services", 3GPP TS 22.886, June 20= 18. [Truck-Platooning] California Partners for Advanced Transportation Tech= nology (PATH), "Automated Truck Platooning", [Online] Available: http://www= .path.berkeley.edu/research/automated-and- connected-vehicles/truck-platoon= ing, 2017. [TS-23.285-3GPP] 3GPP, "Architecture Enhancements for V2X Servic= es", 3GPP TS 23.285, June 2018. [VANET-Geo-Routing] Tsukada, M., Jemaa, I.,= Menouar, H., Zhang, W., Goleva, M., and T. Ernst, "Experimental Evaluation= for IPv6 over VANET Geographic Routing", IEEE International Wireless Commu= nications and Mobile Computing Conference, June 2010. [VIP-WAVE] Cespedes, = S., Lu, N., and X. Shen, "VIP-WAVE: On the Feasibility of IP Communications= in 802.11p Vehicular Networks", IEEE Transactions on Intelligent Transport= ation Systems, vol. 14, no. 1, March 2013. [VMaSC-LTE] Ucar, S., Ergen, S.,= and O. Ozkasap, "Multihop-Cluster- Based IEEE 802.11p and LTE Hybrid Archi= tecture for VANET Safety Message Dissemination", IEEE Transactions on Vehic= ular Technology, April 2016. [VNET-AAA] Moustafa, H., Bourdon, G., and Y. G= ourhant, "Providing Authentication and Access Control in Vehicular Network = Environment", IFIP TC-11 International Information Security Conference, May= 2006. [VNET-MM] Peng, Y. and J. Chang, "A Novel Mobility Management Scheme= for Integration of Vehicular Ad Hoc Networks and Fixed IP Networks", Sprin= ger Mobile Networks and Applications, February 2010. [WAVE-1609.0] IEEE 160= 9 Working Group, "IEEE Guide for Wireless Access in Vehicular Environments = (WAVE) - Architecture", IEEE Std 1609.0-2013, March 2014. Jeong Expires May= 8, 2019 [Page 27] Internet-Draft IPWAVE Problem Statement November 2018 [W= AVE-1609.2] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in = Vehicular Environments - Security Services for Applications and Management = Messages", IEEE Std 1609.2-2016, March 2016. [WAVE-1609.3] IEEE 1609 Workin= g Group, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE= ) - Networking Services", IEEE Std 1609.3-2016, April 2016. [WAVE-1609.4] I= EEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Env= ironments (WAVE) - Multi-Channel Operation", IEEE Std 1609.4-2016, March 20= 16. Jeong Expires May 8, 2019 [Page 28] Internet-Draft IPWAVE Problem State= ment November 2018 Appendix A. Relevant Topics to IPWAVE Working Group This= section discusses topics relevant to IPWAVE WG: (i) vehicle identity manag= ement; (ii) multihop V2X; (iii) multicast; (iv) DNS naming services and ser= vice discovery; (v) IPv6 over cellular networks. A.1. Vehicle Identity Mana= gement A vehicle can have multiple network interfaces using different acces= s network technologies [Identity-Management]. These multiple network interf= aces mean multiple identities. To identify a vehicle with multiple indentie= s, a Vehicle Identification Number (VIN) can be used as a globally unique v= ehicle identifier. To support the seamless connectivity over the multiple i= dentities, a cross-layer network architecture is required with vertical han= dover functionality [Identity-Management]. Also, an AAA service for multipl= e identities should be provided to vehicles in an efficient way to allow ho= rizontal handover as well as vertical handover; note that AAA stands for Au= thentication, Authorization, and Accounting. A.2. Multihop V2X Multihop pac= ket forwarding among vehicles in 802.11-OCB mode shows an unfavorable perfo= rmance due to the common known broadcast-storm problem [Broadcast-Storm]. T= his broadcast-storm problem can be mitigated by the coordination (or schedu= ling) of a cluster head in a connected VANET or an RSU in an intersection a= rea, where the cluster head can work as a coodinator for the access to wire= less channels. A.3. Multicast IP multicast in vehicular network environment= s is especially useful for various services. For instance, an automobile ma= nufacturer can multicast a particular group/class/type of vehicles for serv= ice notification. As another example, a vehicle or an RSU can disseminate a= lert messages in a particular area [Multicast-Alert]. In general IEEE 802 w= ireless media, some performance issues about multicast are found in [Multic= ast-802]. Since several procedures and functions based on IPv6 use multicas= t for control-plane messages, such as Neighbor Discovery (ND) and Service D= iscovery, [Multicast-802] describes that the ND process may fail due to unr= eliable wireless link, causing failure of the DAD process. Also, the Router= Advertisement messages can be lost in multicasting. Jeong Expires May 8, 2= 019 [Page 29] Internet-Draft IPWAVE Problem Statement November 2018 A.4. DN= S Naming Services and Service Discovery When two vehicular nodes communicat= e with each other using the DNS name of the partner node, DNS naming servic= e (i.e., DNS name resolution) is required. As shown in Figure 2 and Figure = 3, a recursive DNS server (RDNSS) within an internal network can perform su= ch DNS name resolution for the sake of other vehicular nodes. A service dis= covery service is required for an application in a vehicular node to search= for another application or server in another vehicular node, which resides= in either the same internal network or the other internal network. In V2I = or V2V networking, as shown in Figure 2 and Figure 3, such a service discov= ery service can be provided by either DNS-based Service Discovery (DNS-SD) = [RFC6763] with mDNS [RFC6762] or the vehicular ND with a new option for ser= vice discovery [ID-Vehicular-ND][ID-VND-Discovery]. A.5. IPv6 over Cellular= Networks Recently, 3GPP has announced a set of new technical specification= s, such as Release 14 (3GPP-R14), which proposes an architecture enhancemen= ts for V2X services using the modified sidelink interface that originally i= s designed for the LTE-D2D communications. 3GPP-R14 specifies that the V2X = services only support IPv6 implementation. 3GPP is also investigating and d= iscussing the evolved V2X services in the next generation cellular networks= , i.e., 5G new radio (5G-NR), for advanced V2X communications and automated= vehicles' applications. A.5.1. Cellular V2X (C-V2X) Using 4G-LTE Before 3G= PP-R14, some researchers have studied the potential usage of C-V2X communic= ations. For example, [VMaSC-LTE] explores a multihop cluster-based hybrid a= rchitecture using both DSRC and LTE for safety message dissemination. Most = of the research considers a short message service for safety instead of IP = datagram forwarding. In other C-V2X research, the standard IPv6 is assumed.= The 3GPP technical specification [TS-23.285-3GPP] states that both IP base= d and non-IP based V2X messages are supported, and only IPv6 is supported f= or IP based messages. Moreover, [TS-23.285-3GPP] instructs that a UE autoco= nfigures a link-local IPv6 address by following [RFC4862], but without send= ing Neighbor Solicitation and Neighbor Advertisement messages for DAD. This= is because a unique prefix is allocated to each node by the 3GPP network, = so the IPv6 addresses cannot be duplicate. Jeong Expires May 8, 2019 [Page = 30] Internet-Draft IPWAVE Problem Statement November 2018 A.5.2. Cellular V= 2X (C-V2X) Using 5G The emerging services, functions, and applications, whi= ch are developped in automotive industry, demand reliable and efficient com= munication infrastructure for road networks. Correspondingly, the support o= f enhanced V2X (eV2X)-based services by future converged and interoperable = 5G systems is required. The 3GPP Technical Report [TR-22.886-3GPP] is study= ing new use cases and the corresponding service requirements for V2X (inclu= ding V2V and V2I) using 5G in both infrastructure mode and the sidelink var= iations in the future. Appendix B. Changes from draft-ietf-ipwave-vehicular= -networking-06 The following changes are made from draft-ietf-ipwave-vehicu= lar- networking-06: o In Figure 1, a vehicular network architecture is modi= fied to show a vehicular link model in a multi-link subnet with vehicular w= ireless links. o In Section 5.1, a Vehicular Neighbor Discovery (VND) [ID-V= ehicular-ND] is introduced along with a vehicular link model in a multi-lin= k subnet. In such a subnet, the description of MAC Address Pseudonym, Prefi= x Dissemination/Exchange, and Routing is clarified. o In Section 5.2, a pro= active handover is introduced for an efficient mobility management with the= cooperation among vehicles, RSUs, and MA along with link-layer parameters,= such as Received Channel Power Indicator (RCPI). Appendix C. Acknowledgmen= ts This work was supported by Basic Science Research Program through the Na= tional Research Foundation of Korea (NRF) funded by the Ministry of Educati= on (2017R1D1A1B03035885). This work was supported in part by Global Researc= h Laboratory Program through the NRF funded by the Ministry of Science and = ICT (MSIT) (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MS= IT (18-EE-01). This work was supported in part by the French research proje= ct DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded by= the European Commission I (636537-H2020). Jeong Expires May 8, 2019 [Page = 31] Internet-Draft IPWAVE Problem Statement November 2018 Appendix D. Contr= ibutors This document is a group work of IPWAVE working group, greatly bene= fiting from inputs and texts by Rex Buddenberg (Naval Postgraduate School),= Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest University of Technology an= d Economics), Jose Santa Lozanoi (Universidad of Murcia), Richard Roy (MIT)= , Francois Simon (Pilot), Sri Gundavelli (Cisco), Erik Nordmark, and Dirk v= on Hugo (Deutsche Telekom). The authors sincerely appreciate their contribu= tions. The following are co-authors of this document: Nabil Benamar Departm= ent of Computer Sciences High School of Technology of Meknes Moulay Ismail = University Morocco Phone: +212 6 70 83 22 36 EMail: benamar73@gmail.com San= dra Cespedes NIC Chile Research Labs Universidad de Chile Av. Blanco Encala= da 1975 Santiago Chile Phone: +56 2 29784093 EMail: scespede@niclabs.cl Jer= ome Haerri Communication Systems Department EURECOM Sophia-Antipolis France= Phone: +33 4 93 00 81 34 EMail: jerome.haerri@eurecom.fr Dapeng Liu Alibab= a Beijing, Beijing 100022 China Jeong Expires May 8, 2019 [Page 32] Interne= t-Draft IPWAVE Problem Statement November 2018 Phone: +86 13911788933 EMail= : max.ldp@alibaba-inc.com Tae (Tom) Oh Department of Information Sciences a= nd Technologies Rochester Institute of Technology One Lomb Memorial Drive R= ochester, NY 14623-5603 USA Phone: +1 585 475 7642 EMail: Tom.Oh@rit.edu Ch= arles E. Perkins Futurewei Inc. 2330 Central Expressway Santa Clara, CA 950= 50 USA Phone: +1 408 330 4586 EMail: charliep@computer.org Alexandre Petres= cu CEA, LIST CEA Saclay Gif-sur-Yvette, Ile-de-France 91190 France Phone: += 33169089223 EMail: Alexandre.Petrescu@cea.fr Yiwen Chris Shen Department of= Computer Science & Engineering Sungkyunkwan University 2066 Seobu-Ro, Jang= an-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4106 Fax= : +82 31 290 7996 EMail: chrisshen@skku.edu URI: http://iotlab.skku.edu/peo= ple-chris-shen.php Jeong Expires May 8, 2019 [Page 33] Internet-Draft IPWAV= E Problem Statement November 2018 Michelle Wetterwald FBConsulting 21, Rout= e de Luxembourg Wasserbillig, Luxembourg L-6633 Luxembourg EMail: Michelle.= Wetterwald@gmail.com Author's Address Jaehoon Paul Jeong (editor) Departmen= t of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeon= ggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Fax: +82 31 290 7996 = EMail: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.= php Jeong Expires May 8, 2019 [Page 34] --_000_D87E26092E68EBsgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable 
Hey Paul,

Attached is my review. =
 Please see some inline comments. In my opinion, the document has thin line=
 separating the problem description from the solution description. In many =
places, the focus is more on the solution before explaining what the proble=
m is.  I think you have an opportunity here to greatly simplify the do=
cument and keep it to the point. I hate to push you towards another re=
vision, but in the current form this won=92t pass IESG, IMO. The Gods in IE=
SG will send it back to the WG. I really think you can cut down the text by=
 50% to 60%. As they say,  =93some times,  less is more" :-)  Hope thi=
s helps.

Cheers!
Sri





--
IPWAVE Working Group                                       J. Jeong, Ed.
Internet-Draft                                   Sungkyunkwan University
Intended status: Informational                          November 4, 2018
Expires: May 8, 2019


IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement
                             and Use Cases
               draft-ietf-ipwave-vehicular-networking-07

Abstract

   This document discusses the problem statement and use cases on IP-
   based vehicular networks, which are considered a key component of
   Intelligent Transportation Systems (ITS).  
[Sri] Wha=
t is Key component of ITS? Usecases? You may want to reword




"This document discusses the problem statement and use cas=
es on IP-
   based vehicular networks for building Intelligent Transportation Systems (ITS).  




The main scenarios of
   vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-
   infrastructure (V2I), and vehicle-to-everything (V2X) communications.
   First, this document surveys use cases using V2V, V2I, and V2X
   networking.  Second, it analyzes proposed protocols for IP-based
   vehicular networking and highlights the limitations and difficulties
   found on those protocols.  Third, it presents a problem exploration
   for key aspects in IP-based vehicular networking, such as IPv6
   Neighbor Discovery, Mobility Management, and Security & Privacy.  Fo=
r
   each key aspect, this document discusses a problem statement to
   evaluate the gap between the state-of-the-art techniques and
   requirements in IP-based vehicular networking.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 8, 2019.








Jeong                      Expires May 8, 2019                  [Page 1]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  V2V . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  V2I . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  V2X . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Analysis for Existing Protocols . . . . . . . . . . . . . . .   8
     4.1.  Existing Protocols for Vehicular Networking . . . . . . .   8
       4.1.1.  IPv6 over 802.11-OCB  . . . . . . . . . . . . . . . .   8
       4.1.2.  IP Address Autoconfiguration  . . . . . . . . . . . .   8
       4.1.3.  Routing . . . . . . . . . . . . . . . . . . . . . . .   9
       4.1.4.  Mobility Management . . . . . . . . . . . . . . . . .   9
       4.1.5.  DNS Naming Service  . . . . . . . . . . . . . . . . .   9
       4.1.6.  Service Discovery . . . . . . . . . . . . . . . . . .   9
       4.1.7.  Security and Privacy  . . . . . . . . . . . . . . . .  10
     4.2.  General Problems  . . . . . . . . . . . . . . . . . . . .  10
       4.2.1.  Vehicular Network Architecture  . . . . . . . . . . .  11
       4.2.2.  Latency . . . . . . . . . . . . . . . . . . . . . . .  16
       4.2.3.  Security  . . . . . . . . . . . . . . . . . . . . . .  16
       4.2.4.  Pseudonym Handling  . . . . . . . . . . . . . . . . .  16
   5.  Problem Exploration . . . . . . . . . . . . . . . . . . . . .  17
     5.1.  Neighbor Discovery  . . . . . . . . . . . . . . . . . . .  17
       5.1.1.  Link Model  . . . . . . . . . . . . . . . . . . . . .  17
       5.1.2.  MAC Address Pseudonym . . . . . . . . . . . . . . . .  18
       5.1.3.  Prefix Dissemination/Exchange . . . . . . . . . . . .  18
       5.1.4.  Routing . . . . . . . . . . . . . . . . . . . . . . .  18
     5.2.  Mobility Management . . . . . . . . . . . . . . . . . . .  19
     5.3.  Security and Privacy  . . . . . . . . . . . . . . . . . .  20
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  21
   Appendix A.  Relevant Topics to IPWAVE Working Group  . . . . . .  29



Jeong                      Expires May 8, 2019                  [Page 2]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


     A.1.  Vehicle Identity Management . . . . . . . . . . . . . . .  29
     A.2.  Multihop V2X  . . . . . . . . . . . . . . . . . . . . . .  29
     A.3.  Multicast . . . . . . . . . . . . . . . . . . . . . . . .  29
     A.4.  DNS Naming Services and Service Discovery . . . . . . . .  30
     A.5.  IPv6 over Cellular Networks . . . . . . . . . . . . . . .  30
       A.5.1.  Cellular V2X (C-V2X) Using 4G-LTE . . . . . . . . . .  30
       A.5.2.  Cellular V2X (C-V2X) Using 5G . . . . . . . . . . . .  31
   Appendix B.  Changes from draft-ietf-ipwave-vehicular-
                networking-06  . . . . . . . . . . . . . . . . . . .  31
   Appendix C.  Acknowledgments  . . . . . . . . . . . . . . . . . .  31
   Appendix D.  Contributors . . . . . . . . . . . . . . . . . . . .  32
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  34

1.  Introduction

   Vehicular networking studies have mainly focused on driving safety,
   driving efficiency, and entertainment in road networks.  


[Sri] Rep=
hrase, =93focused on driving safety, driving efficiency, and entertainment =
in road networks." 


To perhap=
s, =93focussed on improving safety, efficiency and enabling entertainment i=
n vehicular networks=94


The Federal
   Communications Commission (FCC) in the US allocated wireless channels
   for Dedicated Short-Range Communications (DSRC) [DSRC], service in
   the Intelligent Transportation Systems (ITS) Radio Service in the
   5.850 - 5.925 GHz band (5.9 GHz band).  DSRC-based wireless
   communications can support vehicle-to-vehicle (V2V), vehicle-to-
   infrastructure (V2I), and vehicle-to-everything (V2X) networking.
   Also, the European Union (EU) passed a decision to allocate radio
   spectrum for safety-related and non-safety-related applications of
   ITS with the frequency band of 5.875 - 5.905 GHz, which is called
   Commission Decision 2008/671/EC [EU-2008-671-EC].

   For direct inter-vehicular wireless connectivity, IEEE has amended
   WiFi standard 802.11 to enable driving safety services based on the
   DSRC in terms of standards for the Wireless Access in Vehicular
   Environments (WAVE) system.  L1 and L2 issues are addressed in IEEE

[Sri] Exp=
and L1, L2





   802.11p [IEEE-802.11p] for the PHY and MAC of the DSRC, while IEEE
   1609.2 [WAVE-1609.2] covers security aspects, IEEE 1609.3
   [WAVE-1609.3] defines related services at network and transport
   layers, and IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel
   operation.  Note that IEEE 802.11p has been published as IEEE 802.11
   Outside the Context of a Basic Service Set (OCB) called IEEE
   802.11-OCB [IEEE-802.11-OCB] in 2012.


[Sri] You may want to say, 802.11p was a separate standard, but was=
 later enrolled into the base 802.11 standard, IEEE 802.11-2012<=
/pre>

   Along with these WAVE standards, IPv6 [RFC8200] and Mobile IP
   protocols (e.g., MIPv4 [RFC5944] and MIPv6 [RFC6275]) can be applied
   (or easily modified) to vehicular networks.  





[Sri] Since, you mentioned MIP4, MIP6, it will=
 be incomplete if you don=92t include PMIPv6 [RFC5213 and RFC5844]. Also, t=
o be consistent with my other comments, please=
 refer to them in the context of a problem. State the problem, say =
=93mobility management=94, explain the req=
uirement and refer to existing IETF art, for addressing that problem. <=
/font>





In Europe, ETSI has
   standardized a GeoNetworking (GN) protocol [ETSI-GeoNetworking] and a
   protocol adaptation sub-layer from GeoNetworking to IPv6
   [ETSI-GeoNetwork-IP].  Note that a GN protocol is useful to route an
   event or notification message to vehicles around a geographic
   position, such as an acciendent area in a roadway.  In addition, ISO



Jeong                      Expires May 8, 2019                  [Page 3]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   has approved a standard specifying the IPv6 network protocols and
   services to be used for Communications Access for Land Mobiles (CALM)
   [ISO-ITS-IPv6].



[Sri] Thi=
s is great information, but curious how it toes back to this document? Use =
of IP ?





   This document discusses problem statements and use cases related to
   IP-based vehicular networking for Intelligent Transportation Systems
   (ITS), which is denoted as IP Wireless Access in Vehicular
   Environments (IPWAVE).  First, it surveys the use cases for using
   V2V, V2I, and V2X networking in the ITS.  Second, for literature
   review, it analyzes proposed protocols for IP-based vehicular
   networking and highlights the limitations and difficulties found on
   those protocols.  Third, for problem statement, it presents a problem
   exploration with key aspects in IPWAVE, such as IPv6 Neighbor
   Discovery, Mobility Management, and Security & Privacy.  For each ke=
y
   aspect of the problem statement, it analyzes the gap between the
   state-of-the-art techniques and the requirements in IP-based
   vehicular networking.  It also discusses potential topics relevant to
   IPWAVE Working Group (WG), such as Vehicle Identities Management,
   Multihop V2X Communications, Multicast, DNS Naming Services, Service
   Discovery, and IPv6 over Cellular Networks.  Therefore, with the
   problem statement, this document will open a door to develop key
   protocols for IPWAVE that will be essential to IP-based vehicular
   networks.

2.  Terminology

   This document uses the following definitions:

   o  WAVE: Acronym for "Wireless Access in Vehicular Environments&quo=
t;
      [WAVE-1609.0].

   o  DMM: Acronym for "Distributed Mobility Management"
      [RFC7333][RFC7429].

   o  Road-Side Unit (RSU): A node that has physical communication
      devices (e.g., DSRC, Visible Light Communication, 802.15.4, LTE-
      V2X, etc.) for wireless communications with vehicles and is also
      connected to the Internet as a router or switch for packet
      forwarding.  An RSU is typically deployed on the road
      infrastructure, either at an intersection or in a road segment,
      but may also be located in car parking area.


[Sri] I w=
ould think DSRC and C-V2X are the only wireless systems currently defined f=
or Vehicular Communications, or at least the term RSU is used only by these=
 systems. So, I am not sure if we should mention 802.15.4 or Visible Light =
Communications. Also, if you look at the OBU definition below, is there a O=
BU with visible light interface, so both the ends have to support the same =
scheme.






   o  On-Board Unit (OBU): A node that has a DSRC device for wireless
      communications with other OBUs and RSUs, and may be connected to
      in-vehicle devices or networks.  An OBU is mounted on a vehicle.
      It is assumed that a radio navigation receiver (e.g., Global
      Positioning System (GPS)) is included in a vehicle with an OBU for
      efficient navigation.



Jeong                      Expires May 8, 2019                  [Page 4]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   o  Vehicle Detection Loop (or Loop Detector): An inductive device
      used for detecting vehicles passing or arriving at a certain
      point, for instance approaching a traffic light or in motorway
      traffic.  The relatively crude nature of the loop's structure
      means that only metal masses above a certain size are capable of
      triggering the detection.

   o  Mobility Anchor (MA): A node that maintains IP addresses and
      mobility information of vehicles in a road network to support the
      address autoconfiguration and mobility management of them.  It has
      end-to-end connections with RSUs under its control.  It maintains
      a DAD table having the IP addresses of the vehicles moving within
      the communication coverage of its RSUs.


[Sri] The=
 last sentence is pointing to a solution. MA may or may not maintain a DAD =
table. It may maintain a binding table like MIPv6 HA, or PMIPv6 LMA<=
/b>






   o  Vehicular Cloud: A cloud infrastructure for vehicular networks,
      having compute nodes, storage nodes, and network nodes.

   o  Traffic Control Center (TCC): A node that maintains road
      infrastructure information (e.g., RSUs, traffic signals, and loop
      detectors), vehicular traffic statistics (e.g., average vehicle
      speed and vehicle inter-arrival time per road segment), and
      vehicle information (e.g., a vehicle's identifier, position,
      direction, speed, and trajectory as a navigation path).  TCC is
      included in a vehicular cloud for vehicular networks.

3.  Use Cases

   This section provides use cases of V2V, V2I, and V2X networking.  The
   use cases of the V2X networking exclude the ones of the V2V and V2I
   networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to-
   Device (V2D).

3.1.  V2V

   The use cases of V2V networking discussed in this section include

   o  Context-aware navigation for driving safety and collision
      avoidance;

   o  Cooperative adaptive cruise control in an urban roadway;

   o  Platooning in a highway;

   o  Cooperative environment sensing.

   These four techniques will be important elements for self-driving
   Vehicles.





[Sri] I a=
m not convinced if this is a complete list, or how these items made it here=
. 3GPP has identified some use-cases, I wonder what is the delta between th=
e two









Jeong                      Expires May 8, 2019                  [Page 5]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers
   to drive safely by letting the drivers recognize dangerous obstacles
   and situations.  That is, CASD navigator displays obstables or
   neighboring vehicles relevant to possible collisions in real-time
   through V2V networking.  CASD provides vehicles with a class-based
   automatic safety action plan, which considers three situations, such
   as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe and safe
   situations.  This action plan can be performed among vehicles through
   V2V networking.

   Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps
   vehicles to adapt their speed autonomously through V2V communication
   among vehicles according to the mobility of their predecessor and
   successor vehicles in an urban roadway or a highway.  CACC can help
   adjacent vehicles to efficiently adjust their speed in a cascade way
   through V2V networking.

   Platooning [Truck-Platooning] allows a series of vehicles (e.g.,
   trucks) to move together with a very short inter-distance.  Trucks
   can use V2V communication in addition to forward sensors in order to
   maintain constant clearance between two consecutive vehicles at very
   short gaps (from 3 meters to 10 meters).  This platooning can
   maximize the throughput of vehicular traffic in a highway and reduce
   the gas consumption because the leading vehicle can help the
   following vehicles to experience less air resistance.

   Cooperative-environment-sensing use cases suggest that vehicles can
   share environmental information from various vehicle-mounted sensors,
   such as radars, LiDARs and cameras with other vehicles and
   pedestrians.  [Automotive-Sensing] introduces a millimeter-wave
   vehicular communication for massive automotive sensing.  Data
   generated by those sensors can be substantially large, and these data
   shall be routed to different destinations.  In addition, from the
   perspective of driverless vehicles, it is expected that driverless
   vehicles can be mixed with driver-operated vehicles.  Through
   cooperative environment sensing, driver-operated vehicles can use
   environmental information sensed by driverless vehicles for better
   interaction with the context.

3.2.  V2I

   The use cases of V2I networking discussed in this section include

   o  Navigation service;

   o  Energy-efficient speed recommendation service;

   o  Accident notification service.



Jeong                      Expires May 8, 2019                  [Page 6]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   A navigation service, such as the Self-Adaptive Interactive
   Navigation Tool (called SAINT) [SAINT], using V2I networking
   interacts with TCC for the large-scale/long-range road traffic
   optimization and can guide individual vehicles for appropriate
   navigation paths in real time.  The enhanced SAINT (called SAINT+)
   [SAINTplus] can give the fast moving paths for emergency vehicles
   (e.g., ambulance and fire engine) toward accident spots while
   providing other vehicles with efficient detour paths.


[Sri] Is =
this a requirement, or a description of some deployed service? <=
/pre>





   A TCC can recommend an energy-efficient speed to a vehicle driving in
   different traffic environments.  [Fuel-Efficient] studies fuel-
   efficient route and speed plans for platooned trucks.

   The emergency communication between accident vehicles (or emergency
   vehicles) and TCC can be performed via either RSU or 4G-LTE networks.
   The First Responder Network Authority (FirstNet) [FirstNet] is
   provided by the US government to establish, operate, and maintain an
   interoperable public safety broadband network for safety and security
   network services, such as emergency calls.  The construction of the
   nationwide FirstNet network requires each state in the US to have a
   Radio Access Network (RAN) that will connect to FirstNet's network
   core.  The current RAN is mainly constructed by 4G-LTE for the
   communication between a vehicle and an infrastructure node (i.e.,
   V2I) [FirstNet-Report], but it is expected that DSRC-based vehicular
   networks [DSRC] will be available for V2I and V2V in near future.

3.3.  V2X

   The use case of V2X networking discussed in this section is
   pedestrian protection service.

   A pedestrian protection service, such as Safety-Aware Navigation
   Application (called SANA) [SANA], using V2I2P networking can reduce
   the collision of a vehicle and a pedestrian carrying a smartphone
   equipped with the access technology with an RSU (e.g., WiFi).
   Vehicles and pedestrians can also communicate with each other via an
   RSU that delivers scheduling information for wireless communication
   in order to save the smartphones' battery through sleeping mode.

   For Vehicle-to-Pedestrian (V2P), a vehicle and a pedestrian's
   smartphone can directly communicate with each other via V2X without
   the relaying of an RSU as in a V2V scenario such that the
   pedestrian's smartphone is regarded as a vehicle with a wireless
   media interface to be able to communicate with another vehicle.  In
   Vehicle-to-Device (V2D), a device can be a mobile node such as
   bicycle and motorcycle, and can communicate directly with a vehicle
   for collision avoidance.




Jeong                      Expires May 8, 2019                  [Page 7]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


4.  Analysis for Existing Protocols

4.1.  Existing Protocols for Vehicular Networking

   We describe some currently existing protocols=
 and proposed solutions
   with respect to the following aspects that are relevant and essential
   for vehicular networking:

   o  IPv6 over 802.11-OCB;

   o  IP address autoconfiguration;

   o  Routing;





[Sri] Is =
Routing a protocol?  Are these protocols, or services ?

   o  Mobility management;

   o  DNS naming service;

   o  Service discovery;

   o  Security and privacy.






4.1.1.  IPv6 over 802.11-OCB

   For IPv6 packets transporting over IEEE 802.11-OCB,
   [IPv6-over-802.11-OCB] specifies several details, such as Maximum
   Transmission Unit (MTU), frame format, link-local address, address
   mapping for unicast and multicast, stateless autoconfiguration, and
   subnet structure.  Especially, an Ethernet Adaptation (EA) layer is
   in charge of transforming some parameters between IEEE 802.11 MAC
   layer and IPv6 network layer, which is located between IEEE
   802.11-OCB's logical link control layer and IPv6 network layer.





[Sri] But=
, what is the point from the point of view of this spec? 



4.1.2.  IP Address Autoconfiguration

   For IP address autoconfiguration, Fazio et al. proposed a vehicular
   address configuration (VAC) scheme using DHCP where elected leader-
   vehicles provide unique identifiers for IP address configurations in
   vehicles [Address-Autoconf].  Kato et al. proposed an IPv6 address
   assignment scheme using lane and position information
   [Address-Assignment].  Baldessari et al. proposed an IPv6 scalable
   address autoconfiguration scheme called GeoSAC for vehicular networks
   [GeoSAC].  Wetterwald et al. conducted for heterogeneous vehicular
   networks (i.e., employing multiple access technologies) a
   comprehensive study of the cross-layer identities management, which
   constitutes a fundamental element of the ITS architecture
   [Identity-Management].




[Sri] The=
 focus of the document should be on the problem statement. We have departed=
 from that and now we are talking solutions. I see this problem through out=
 this spec.





Jeong                      Expires May 8, 2019                  [Page 8]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


4.1.3.  Routing

   For routing, Tsukada et al. presented a work that aims at combining
   IPv6 networking and a Car-to-Car Network routing protocol (called
   C2CNet) proposed by the Car2Car Communication Consortium (C2C-CC),
   which is an architecture using a geographic routing protocol
   [VANET-Geo-Routing].  Abrougui et al. presented a gateway discovery
   scheme for VANET, called Location-Aided Gateway Advertisement and
   Discovery (LAGAD) mechanism [LAGAD].



<=
/font>


[Sri] Again, the focus of the docum=
ent should be on problem statement, not on solutions


4.1.4.  Mobility Management

   For mobility management, Chen et al. tackled the issue of network
   fragmentation in VANET environments [IP-Passing-Protocol] by
   proposing a protocol that can postpone the time to release IP
   addresses to the DHCP server and select a faster way to get the
   vehicle's new IP address, when the vehicle density is low or the
   speeds of vehicles are highly variable.  Nguyen et al. proposed a
   hybrid centralized-distributed mobility management called H-DMM to
   support highly mobile vehicles [H-DMM].  [NEMO-LMS] proposed an
   architecture to enable IP mobility for moving networks using a
   network-based mobility scheme based on PMIPv6.  Chen et al. proposed
   a network mobility protocol to reduce handoff delay and maintain
   Internet connectivity to moving vehicles in a highway [NEMO-VANET].
   Lee et al. proposed P-NEMO, which is a PMIPv6-based IP mobility
   management scheme to maintain the Internet connectivity at the
   vehicle as a mobile network, and provides a make-before-break
   mechanism when vehicles switch to a new access network
   [PMIP-NEMO-Analysis].  Peng et al. proposed a novel mobility
   management scheme for integration of VANET and fixed IP networks
   [VNET-MM].  Nguyen et al. extended their previous works on a
   vehicular adapted DMM considering a Software-Defined Networking (SDN)
   architecture [SDN-DMM].





[Sri] The focus of the document sho=
uld on the problem statement, not on solutions. This platter of requirement=
s are discrete and not connecting back to a larger architecture. 


4.1.5.  DNS Naming Service

   For DNS naming service, Multicast DNS (mDNS) [RFC6762] allows devices
   in one-hop communication range to resolve each other's DNS name into
   the corresponding IP address in multicast.  DNS Name
   Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming service
   for Internet-of-Things (IoT) devices in a large-scale network.





[Sri] Sure, but our goal is to talk about the problems when using =
this in vehicular context. I don=92t see that discussion =










4.1.6.  Service Discovery

   To discover instances of a demanded service in vehicular networks,
   DNS-based Service Discovery (DNS-SD) [RFC6763] with either DNSNA
   [ID-DNSNA] or mDNS [RFC6762] provides vehicles with service discovery
   by using standard DNS queries.  Vehicular ND [ID-Vehicular-ND]



Jeong                      Expires May 8, 2019                  [Page 9]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   proposes an extension of IPv6 ND for the prefix and service discovery
   with new ND options [ID-VND-Discovery].  Note that a DNS query for
   service discovery is unicasted in DNSNA, but it is multicasted in
   both mDNS and Vehicular ND.





[Sri] We have now departed to from PS world, to Solution worl=
d. 



4.1.7.  Security and Privacy

   For security and privacy, Fernandez et al. proposed a secure
   vehicular IPv6 communication scheme using Internet Key Exchange
   version 2 (IKEv2) and Internet Protocol Security (IPsec)
   [Securing-VCOMM].  Moustafa et al. proposed a security scheme
   providing authentication, authorization, and accounting (AAA)
   services in vehicular networks [VNET-AAA].


[Sri] I do not know if Fernandez et all, covered the problem =
description, but we should first talk about the problem before we talk abou=
t solution 



4.2.  General Problems

   This section describes a possible vehicular network architecture for
   V2V, V2I, and V2X communications.  Then it analyzes the limitations
   of the current protocols for vehicular networking.
































Jeong                      Expires May 8, 2019                 [Page 10]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


                     Traffic Control Center in Vehicular Cloud
                    *-----------------------------------------*
                   *                                           *
                  *             +----------------+              *
                 *              | Mobility Anchor|               *
                 *              +----------------+               *
                  *                      ^                      *
                   *                     |                     *
                    *--------------------v--------------------*
                    ^               ^                        ^
                    |               |                        |
+------------------ |  -------------|-------------+ +----------=
--------+
|                   v               v             | |        v         |
|           +--------+  Ethernet   +--------+     | |    &#=
43;--------+    |
|           |  RSU1  |<----------->|  RSU2  |<---------->|  RSU=
3  |    |
|           +--------+             +--------+     | |    &#=
43;--------+    |
|           ^        ^                  ^         | |        ^         |
|           :        :                  :         | |        :         |
|       V2I :        : V2I          V2I :         | |    V2I :         |
|           v        v                  v         | |        v         |
|   +--------+      +--------+      +--------+    |=
 |    +--------+    |
|   |Vehicle1|=3D=3D=3D>  |Vehicle2|=3D=3D=3D>  |Vehicle3|=3D=3D=3D&g=
t;| |    |Vehicle4|=3D=3D=3D>|
|   |        |<....>|        |<....>|        |    | |    |     =
   |    |
|   +--------+ V2V  +--------+ V2V  +--------+    |=
 |    +--------+    |
|                                                 | |                  |
+-------------------------------------------------+ +----------=
--------+
                      Subnet1                              Subnet2

   <----> Wired Link   <....> Wireless Link   =3D=3D=3D> Mov=
ing Direction

   Figure 1: A Vehicular Network Architecture for V2I and V2V Networking

4.2.1.  Vehicular Network Architecture

   Figure 1 shows a possible architecture for V2I and V2V networking in
   a road network.  It is assumed that RSUs as routers and vehicles with
   OBU have wireless media interfaces (e.g., IEEE 802.11-OCB, LTE Uu and
   Device-to-Device (D2D) (also known as PC5 [TS-23.285-3GPP]),
   Bluetooth, and Light Fidelity (Li-Fi)) for V2I and V2V communication.
   Also, it is assumed that such the wireless media interfaces are
   autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to
   support both V2V and V2I networking.  Three RSUs (RSU1, RSU2, and
   RSU3) are deployed in the road network and are connected to a
   Vehicular Cloud through the Internet.  A Traffic Control Center (TCC)
   is connected to the Vehicular Cloud for the management of RSUs and
   vehicles in the road network.  A Mobility Anchor (MA) is located in
   the TCC as its key component for the mobility management of vehicles.
   Two vehicles (Vehicle1 and Vehicle2) are wirelessly connected to



Jeong                      Expires May 8, 2019                 [Page 11]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   RSU1, and one vehicle (Vehicle3) is wirelessly connected to RSU2.
   The wireless networks of RSU1 and RSU2 belong to a multi-link subnet
   (denoted as Subnet1) with the same network prefix.  Thus, these three
   vehicles are within the same subnet.  On the other hand, another
   vehicle (Vehicle4) is wireless connected to RSU4, belonging to
   another subnet (denoted as Subnet2).  That is, the first three
   vehicles (i.e., Vehicle1, Vehicle2, and Vehicle3) and the last
   vehicle (i.e., Vehicle4) are located in the two different subnets.
   Vehicle1 can communicate with Vehicle2 via V2V communication, and
   Vehicle2 can communicate with Vehicle3 via V2V communication because
   they are within the same subnet along their IPv6 addresses, which are
   based on the same prefix.  On the other hand, Vehicle3 can
   communicate with Vehicle4 via RSU2 and RSU3 employing V2I (i.e.,
   V2I2V) communication because they are within the two different
   subnets along with their IPv6 addresses, which are based on the two
   different prefixes.

   In vehicular networks, unidirectional links exist and must be
   considered for wireless communications.  Also, in the vehicular
   networks, control plane must be separated from data plane for
   efficient mobility management and data forwarding using Software-
   Defined Networking (SDN) [SDN-DMM].  ID/Pseudonym change for privacy
   requires a lightweight DAD.  IP tunneling over the wireless link
   should be avoided for performance efficiency.  The mobility
   information of a mobile (e.g., vehicle-mounted) device through a GPS
   receiver in its vehicle, such as trajectory, position, speed, and
   direction, can be used by the mobile device and infrastructure nodes
   (e.g., TCC and RSU) for the accommodation of mobility-aware proactive
   protocols.  Vehicles can use the TCC as their Home Network having a
   home agent for mobility management as in MIPv6 [RFC6275] and Proxy
   Mobile IPv6 (PMIPv6) [RFC5213], so the TCC maintains the mobility
   information of vehicles for location management.

   Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for
   I2V and V2I networking [VIP-WAVE].  The standard WAVE does not
   support both seamless communications for Internet services and multi-
   hop communications between a vehicle and an infrastructure node
   (e.g., RSU), either.  To overcome these limitations of the standard
   WAVE, VIP-WAVE enhances the standard WAVE by the following three
   schemes: (i) an efficient mechanism for the IPv6 address assignment
   and DAD, (ii) on-demand IP mobility based on PMIPv6 [RFC5213], and
   (iii) one-hop and two-hop communications for I2V and V2I networking.

   Baccelli et al. provided an analysis of the operation of IPv6 as it
   has been described by the IEEE WAVE standards 1609 [IPv6-WAVE].  This
   analysis confirms that the use of the standard IPv6 protocol stack in
   WAVE is not sufficient.  It recommends that the IPv6 addressing




Jeong                      Expires May 8, 2019                 [Page 12]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   assignment should follow considerations for ad-hoc link models,
   defined in [RFC5889] for nodes' mobility and link variability.

   Petrescu et al. proposed the joint IP networking and radio
   architecture for V2V and V2I communication in [Joint-IP-Networking].
   The proposed architecture considers an IP topology in a similar way
   as a radio link topology, in the sense that an IP subnet would
   correspond to the range of 1-hop vehicular communication.  This
   architecture defines three types of vehicles: Leaf Vehicle, Range
   Extending Vehicle, and Internet Vehicle.

                                                    +----------------&#=
43;
                           (*)<........>(*)  +----->| Vehicula=
r Cloud|
          2001:DB8:1:1::/64 |            |   |      +----------------&#=
43;
   +------------------------------+  +-------------------------=
--------+
   |                        v     |  |   v   v                         |
   | .-------. .------. .-------. |  | .-------. .------. .-------.    |
   | | Host1 | |RDNSS1| |Router1| |  | |Router3| |RDNSS2| | Host3 |    |
   | ._______. .______. ._______. |  | ._______. .______. ._______.    |
   |     ^        ^         ^     |  |     ^         ^        ^        |
   |     |        |         |     |  |     |         |        |        |
   |     v        v         v     |  |     v         v        v        |
   | ---------------------------- |  | ------------------------------- |
   | 2001:DB8:10:1::/64 ^         |  |     ^ 2001:DB8:20:1::/64        |
   |                    |         |  |     |                           |
   |                    v         |  |     v                           |
   | .-------.      .-------.     |  | .-------. .-------.   .-------. |
   | | Host2 |      |Router2|     |  | |Router4| |Server1|...|ServerN| |
   | ._______.      ._______.     |  | ._______. ._______.   ._______. |
   |     ^              ^         |  |     ^         ^           ^     |
   |     |              |         |  |     |         |           |     |
   |     v              v         |  |     v         v           v     |
   | ---------------------------- |  | ------------------------------- |
   |  2001:DB8:10:2::/64          |  |       2001:DB8:20:2::/64        |
   +______________________________+  +_________________________=
________+
      Vehicle1 (Moving Network1)            RSU1 (Fixed Network1)

      <----> Wired Link   <....> Wireless Link   (*) Antenna

     Figure 2: Internetworking between Vehicle Network and RSU Network

4.2.1.1.  V2I-based Internetworking

   This section discusses the internetworking between a vehicle's moving
   network and an RSU's fixed network via V2I communication.

   As shown in Figure 2, the vehicle's moving network and the RSU's
   fixed network are self-contained networks having multiple subnets and



Jeong                      Expires May 8, 2019                 [Page 13]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   having an edge router for the communication with another vehicle or
   RSU.  The method of prefix assignment for each subnet inside the
   vehicle's mobile network and the RSU's fixed network is out of scope
   for this document.  Internetworking between two internal networks via
   V2I communication requires an exchange of network prefix and other
   parameters through a prefix discovery mechanism, such as ND-based
   prefix discovery [ID-VND-Discovery].  For the ND-based prefix
   discovery, network prefixs and parameters should be registered into a
   vehicle's router and an RSU router with an external network interface
   in advance.

   The network parameter discovery collects networking information for
   an IP communication between a vehicle and an RSU or between two
   neighboring vehicles, such as link layer, MAC layer, and IP layer
   information.  The link layer information includes wireless link layer
   parameters, such as wireless media (e.g., IEEE 802.11-OCB, LTE Uu and
   D2D, Bluetooth, and LiFi) and a transmission power level.  Note that
   LiFi is a technology for light-based wireless communication between
   devices in order to transmit both data and position.  The MAC layer
   information includes the MAC address of an external network interface
   for the internetworking with another vehicle or RSU.  The IP layer
   information includes the IP address and prefix of an external network
   interface for the internetworking with another vehicle or RSU.





[Sri] Why bring LiFi? We started with 802.11OCB=
, IPv6 for 802.11OCB and now we have entered LiFi space? Why?


   Once the network parameter discovery and prefix exchange operations
   have been performed, packets can be transmitted between the vehicle's
   moving network and the RSU's fixed network.  DNS services should be
   supported to enable name resolution for hosts or servers residing
   either in the vehicle's moving network or the RSU's fixed network.
   It is assumed that the DNS names of in-vehicle devices and their
   service names are registered into a DNS server (i.e., recursive DNS
   server called RDNSS) in a vehicle or an RSU, as shown in Figure 2.
   For service discovery, those DNS names and service names can be
   advertised to neighboring vehicles through either DNS-based service
   discovery mechanisms [RFC6762][RFC6763][ID-DNSNA] and ND-based
   service discovery [ID-Vehicular-ND][ID-VND-Discovery].  For the ND-
   based service discovery, service names should be registered into a
   vehicle's router and an RSU router with an external network interface
   in advance.  Refer to Section 4.1.5 and Section 4.1.6 for detailed
   information.  For these DNS services, an RDNSS within each internal
   network of a vehicle or RSU can be used for the hosts or servers.

   Figure 2 shows internetworking between the vehicle's moving network
   and the RSU's fixed network.  There exists an internal network
   (Moving Network1) inside Vehicle1.  Vehicle1 has the DNS Server
   (RDNSS1), the two hosts (Host1 and Host2), and the two routers
   (Router1 and Router2).  There exists another internal network (Fixed
   Network1) inside RSU1.  RSU1 has the DNS Server (RDNSS2), one host



Jeong                      Expires May 8, 2019                 [Page 14]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   (Host3), the two routers (Router3 and Router4), and the collection of
   servers (Server1 to ServerN) for various services in the road
   networks, such as the emergency notification and navigation.
   Vehicle1's Router1 (called mobile router) and RSU1's Router3 (called
   fixed router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC)
   for I2V networking.

                           (*)<..........>(*)
          2001:DB8:1:1::/64 |              |
   +------------------------------+  +-------------------------=
--------+
   |                        v     |  |     v                           |
   | .-------. .------. .-------. |  | .-------. .------. .-------.    |
   | | Host1 | |RDNSS1| |Router1| |  | |Router5| |RDNSS3| | Host4 |    |
   | ._______. .______. ._______. |  | ._______. .______. ._______.    |
   |     ^        ^         ^     |  |     ^         ^        ^        |
   |     |        |         |     |  |     |         |        |        |
   |     v        v         v     |  |     v         v        v        |
   | ---------------------------- |  | ------------------------------- |
   | 2001:DB8:10:1::/64 ^         |  |     ^ 2001:DB8:30:1::/64        |
   |                    |         |  |     |                           |
   |                    v         |  |     v                           |
   | .-------.      .-------.     |  | .-------.      .-------.        |
   | | Host2 |      |Router2|     |  | |Router6|      | Host5 |        |
   | ._______.      ._______.     |  | ._______.      ._______.        |
   |     ^              ^         |  |     ^              ^            |
   |     |              |         |  |     |              |            |
   |     v              v         |  |     v              v            |
   | ---------------------------- |  | ------------------------------- |
   |  2001:DB8:10:2::/64          |  |       2001:DB8:30:2::/64        |
   +______________________________+  +_________________________=
________+
      Vehicle1 (Moving Network1)        Vehicle2 (Moving Network2)

      <----> Wired Link   <....> Wireless Link   (*) Antenna

          Figure 3: Internetworking between Two Vehicle Networks

4.2.1.2.  V2V-based Internetworking

   This section discusses the internetworking between the moving
   networks of two neighboring vehicles via V2V communication.

   Figure 3 shows internetworking between the moving networks of two
   neighboring vehicles.  There exists an internal network (Moving
   Network1) inside Vehicle1.  Vehicle1 has the DNS Server (RDNSS1), the
   two hosts (Host1 and Host2), and the two routers (Router1 and
   Router2).  There exists another internal network (Moving Network2)
   inside Vehicle2.  Vehicle2 has the DNS Server (RDNSS3), the two hosts
   (Host4 and Host5), and the two routers (Router5 and Router6).



Jeong                      Expires May 8, 2019                 [Page 15]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   Vehicle1's Router1 (called mobile router) and Vehicle2's Router5
   (called mobile router) use 2001:DB8:1:1::/64 for an external link
   (e.g., DSRC) for V2V networking.

   The differences between IPWAVE (including Vehicular Ad Hoc Networks
   (VANET)) and Mobile Ad Hoc Networks (MANET) are as follows:

   o  IPWAVE is not power-constrained operation;

   o  Traffic can be sourced or sinked outside of IPWAVE;

   o  IPWAVE shall support both distributed and centralized operations;

   o  No "sleep" period operation is required for energy saving.



[Sri] Why is this discussion needed? Why talk abou=
t AdHoc networks? 








4.2.2.  Latency

   The communication delay (i.e., latency) between two vehicular nodes
   (vehicle and RSU) should be bounded to a certain threshold.  For IP-
   based safety applications (e.g., context-aware navigation, adaptive
   cruise control, and platooning) in vehicular network, this bounded
   data delivery is critical.  The real implementations for such
   applications are not available, so the feasibility of IP-based safety
   applications is not tested yet.





[Sri] This is a good requirement. This is the r=
ight tone. You may want to qualify further and put some additional latency =
considerations, goals based on the use-cases. 






4.2.3.  Security

   Strong security measures shall protect vehicles roaming in road
   networks from the attacks of malicious nodes, which are controlled by
   hackers.  For safety applications, the cooperation among vehicles is
   assumed.  Malicious nodes may disseminate wrong driving information
   (e.g., location, speed, and direction) to make driving be unsafe.
   Sybil attack, which tries to illude a vehicle with multiple false
   identities, disturbs a vehicle in taking a safe maneuver.
   Applications on IP-based vehicular networking, which are resilient to
   such a sybil attack, are not developed and tested yet.


[Sri] Please translate this to a specific  requ=
irement. We want security for sure and everywhere, not just in vehicular ne=
tworks. What is new and whats the new requirement? Identity? Please explain=







4.2.4.  Pseudonym Handling

   For the protection of drivers' privacy, pseudonym for a vehicle's
   network interface should be used, with the help of which the
   interface's identifier can be changed periodically.  Such a pseudonym
   affects an IPv6 address based on the network interface's identifier,
   and a transport-layer (e.g., TCP) session with an IPv6 address pair.
   The pseudonym handling is not implemented and tested yet for
   applications on IP-based vehicular networking.



[Sri] This is about MAC address? 





Jeong                      Expires May 8, 2019                 [Page 16]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


5.  Problem Exploration

   This section discusses key topics for IPWAVE WG, such as neighbor
   discovery, mobility management, and security & privacy.

5.1.  Neighbor Discovery

   Neighbor Discovery (ND) [RFC4861] is a core part of the IPv6 protocol
   suite.  This section discusses the need for modifying ND for use with
   vehicular networking (e.g., V2V, V2I, and V2X).  The vehicles are
   moving fast within the communication coverage of a vehicular node
   (e.g., vehicle and RSU).  The external wireless link between two
   vehicular nodes can be used for vehicular networking, as shown in
   Figure 2 and Figure 3.

   ND time-related parameters such as router lifetime and Neighbor
   Advertisement (NA) interval should be adjusted for high-speed
   vehicles and vehicle density.  As vehicles move faster, the NA
   interval should decrease for the NA messages to reach the neighboring
   vehicles promptly.  Also, as vehicle density is higher, the NA
   interval should increase for the NA messages to reduce collision
   probability with other NA messages.

5.1.1.  Link Model

   IPv6 protocols work under certain assumptions for the link model that
   do not necessarily hold in a vehicular wireless link [VIP-WAVE].  For
   instance, some IPv6 protocols assume symmetry in the connectivity
   among neighboring interfaces.  However, interference and different
   levels of transmission power may cause unidirectional links to appear
   in vehicular wireless links.  As a result, a new vehicular link model
   is required for the vehicular wireless link.

   There is a relationship between a link and prefix, besides the
   different scopes that are expected from the link-local and global
   types of IPv6 addresses.  In an IPv6 link, it is assumed that all
   interfaces which are configured with the same subnet prefix and with
   on-link bit set can communicate with each other on an IP link or
   extended IP links via ND proxy.  Note that a subnet prefix can be
   used by spanning multiple links as a multi-link subnet [RFC6775].
   Also, note that IPv6 Stateless Address Autoconfiguration can be
   performed in the multiple links where each of them is not assigned
   with a unique subnet prefix, that is, all of them are configured with
   the same subnet prefix [RFC4861][RFC4862].  A vehicular link model
   needs to consider a multi-hop VANET over a multi-link subnet.  Such a
   VANET is usually a multi-link subnet consisting of multiple vehicles
   interconnected by wireless communication range.  Such a subnet has a
   highly dynamic topology over time due to node mobility.



Jeong                      Expires May 8, 2019                 [Page 17]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   Thus, IPv6 ND should be extended into a Vehicular Neighbor Discovey
   (VND) [ID-Vehicular-ND] to support the concept of an IPv6 link
   corresponding to an IPv6 prefix even in a multi-link subnet
   consisting of multiple vehicles and RSUs that are interconnected with
   wireless communication range in IP-based vehicular networks.

5.1.2.  MAC Address Pseudonym

   In the ETSI standards, for the sake of security and privacy, an ITS
   station (e.g., vehicle) can use pseudonyms for its network interface
   identities (e.g., MAC address) and the corresponding IPv6 addresses
   [Identity-Management].  Whenever the network interface identifier
   changes, the IPv6 address based on the network interface identifier
   should be updated.  For the continuity of an end-to-end (E2E)
   transport-layer (e.g., TCP, UDP, and SCTP) session, with a mobility
   management scheme (e.g., MIPv6 and PMIPv6), the new IP address for
   the transport-layer session should be notified to an appropriate end
   point, and the packets of the session should be forwarded to their
   destinations with the changed network interface identifier and IPv6
   address.

5.1.3.  Prefix Dissemination/Exchange

   A vehicle and an RSU can have their internal network, as shown in
   Figure 2 and Figure 3.  In this case, nodes in within the internal
   networks of two vehicular nodes (e.g., vehicle and RSU) want to
   communicate with each other.  For this communication on the wireless
   link, the network prefix dissemination or exchange is required.  It
   is assumed that a vehicular node has an external network interface
   and its internal network.  The legacy IPv6 ND [RFC4861] needs to be
   extended to a vehicular ND (VND) [ID-Vehicular-ND] for the
   communication between the internal-network nodes (e.g., an in-vehicle
   device in a vehicle and a server in an RSU) of vehicular nodes by
   letting each of them know the other side's prefix with a new ND
   option [ID-VND-Discovery].  Thus, this ND extension for routing
   functionality can reduce control traffic for routing in vehicular
   networks without an additional vehicular ad hoc routing protocol
   [VANET-Geo-Routing].

5.1.4.  Routing

   For multihop V2V communications in a multi-link subnet (as a
   connected VANET), a vehicular ad hoc routing protocol (e.g.,
   geographic routing) may be required to support both unicast and
   multicast in the links of the subnet with the same IPv6 prefix
   [VANET-Geo-Routing].  Instead of the vehicular ad hoc routing
   protocol, Vehicular ND along with a prefix discovery option can be
   used to let vehicles exchange their prefixes in a multihop fashion



Jeong                      Expires May 8, 2019                 [Page 18]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [ID-Vehicular-ND][ID-VND-Discovery].  With the exchanged prefixes,
   they can compute their routing table (or IPv6 ND's neighbor cache)
   for the multi-link subnet with a distance-vector algorithm
   [Intro-to-Algorithms].  Also, an efficient, rapid DAD should be
   supported to prevent or reduce IPv6 address conflicts in the multi-
   link subnet by using a DAD optimization [ID-Vehicular-ND][RFC6775] or
   an IPv6 geographic-routing-based address autoconfiguration [GeoSAC].

5.2.  Mobility Management

   The seamless connectivity and timely data exchange between two end
   points requires an efficient mobility management including location
   management and handover.  Most of vehicles are equipped with a GPS
   receiver as part of a dedicated navigation system or a corresponding
   smartphone App.  In the case where the provided location information
   is precise enough, well-known temporary degradations in precision may
   occur due to system configuration or the adverse local environment.
   This precision is improved thanks to assistance by the RSUs or a
   cellular system with this navigation system.  With this GPS
   navigator, an efficient mobility management is possible by vehicles
   periodically reporting their current position and trajectory (i.e.,
   navigation path) to RSUs and a Mobility Anchor (MA) in TCC.  The RSUs
   and MA can predict the future positions of the vehicles with their
   mobility information (i.e., the current position, speed, direction,
   and trajectory) for the efficient mobility management (e.g.,
   proactive handover).  For a better proactive handover, link-layer
   parameters, such as the signal strength of a link-layer frame (e.g.,
   Received Channel Power Indicator (RCPI) [VIP-WAVE]), can be used to
   determine the moment of a handover between RSUs along with mobility
   information [ID-Vehicular-ND].

   With the prediction of the vehicle mobility, MA can support RSUs to
   perform DAD, data packet routing, horizontal handover (i.e., handover
   in wireless links using a homogeneous radio technology), and vertical
   handover (i.e., handover in wireless links using heterogeneous radio
   technologies) in a proactive manner.  Even though a vehicle moves
   into the wireless link under another RSU belonging to a different
   subnet, the RSU can proactively perform the DAD for the sake of the
   vehicle, reducing IPv6 control traffic overhead in the wireless link
   [ID-Vehicular-ND].

   Therefore, with a proactive handover and a multihop DAD in vehicular
   networks [ID-Vehicular-ND], RSUs can efficiently forward data packets
   from the wired network (or the wireless network) to a moving
   destination vehicle along its trajectory along with the MA.  Thus, a
   moving vehicle can communicate with its corresponding vehicle in the
   vehicular network or a host/server in the Internet along its
   trajectory.



Jeong                      Expires May 8, 2019                 [Page 19]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


5.3.  Security and Privacy

   Security and privacy are paramount in the V2I, V2V, and V2X
   networking in vehicular networks.  Only authorized vehicles should be
   allowed to use vehicular networking.  Also, in-vehicle devices and
   mobile devices in a vehicle need to communicate with other in-vehicle
   devices and mobile devices in another vehicle, and other servers in
   an RSU in a secure way.

   A Vehicle Identification Number (VIN) and a user certificate along
   with in-vehicle device's identifier generation can be used to
   efficiently authenticate a vehicle or a user through a road
   infrastructure node (e.g., RSU) connected to an authentication server
   in TCC.  Also, Transport Layer Security (TLS) certificates can be
   used for secure E2E vehicle communications.

   For secure V2I communication, a secure channel between a mobile
   router in a vehicle and a fixed router in an RSU should be
   established, as shown in Figure 2.  Also, for secure V2V
   communication, a secure channel between a mobile router in a vehicle
   and a mobile router in another vehicle should be established, as
   shown in Figure 3.

   To prevent an adversary from tracking a vehicle with its MAC address
   or IPv6 address, MAC address pseudonym should be provided to the
   vehicle; that is, each vehicle should periodically update its MAC
   address and the corresponding IPv6 address as suggested in
   [RFC4086][RFC4941].  Such an update of the MAC and IPv6 addresses
   should not interrupt the E2E communications between two vehicular
   nodes (e.g., vehicle and RSU) in terms of transport layer for a long-
   living higher-layer session.  However, if this pseudonym is performed
   without strong E2E confidentiality, there will be no privacy benefit
   from changing MAC and IP addresses, because an adversary can see the
   change of the MAC and IP addresses and track the vehicle with those
   addresses.

6.  Security Considerations

   This document discussed security and privacy for IP-based vehicular
   networking.

   The security and privacy for key components in IP-based vehicular
   networking, such as neighbor discovery and mobility management, need
   to be analyzed in depth.







Jeong                      Expires May 8, 2019                 [Page 20]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


7.  Informative References

   [Address-Assignment]
              Kato, T., Kadowaki, K., Koita, T., and K. Sato, "Routing
              and Address Assignment using Lane/Position Information in
              a Vehicular Ad-hoc Network", IEEE Asia-Pacific Services
              Computing Conference, December 2008.

   [Address-Autoconf]
              Fazio, M., Palazzi, C., Das, S., and M. Gerla, "Automati=
c
              IP Address Configuration in VANETs", ACM International
              Workshop on Vehicular Inter-Networking, September 2016.

   [Automotive-Sensing]
              Choi, J., Va, V., Gonzalez-Prelcic, N., Daniels, R., R.
              Bhat, C., and R. W. Heath, "Millimeter-Wave Vehicular
              Communication to Support Massive Automotive Sensing",
              IEEE Communications Magazine, December 2016.

   [Broadcast-Storm]
              Wisitpongphan, N., K. Tonguz, O., S. Parikh, J., Mudalige,
              P., Bai, F., and V. Sadekar, "Broadcast Storm Mitigation
              Techniques in Vehicular Ad Hoc Networks", IEEE Wireless
              Communications, December 2007.

   [CA-Cruise-Control]
              California Partners for Advanced Transportation Technology
              (PATH), "Cooperative Adaptive Cruise Control", [Onl=
ine]
              Available:
              http://www.path.berkeley.edu/research/automated-and-
              connected-vehicles/cooperative-adaptive-cruise-control,
              2017.

   [CASD]     Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A
              Framework of Context-Awareness Safety Driving in Vehicular
              Networks", International Workshop on Device Centric Clou=
d
              (DC2), March 2016.

   [DSRC]     ASTM International, "Standard Specification for
              Telecommunications and Information Exchange Between
              Roadside and Vehicle Systems - 5 GHz Band Dedicated Short
              Range Communications (DSRC) Medium Access Control (MAC)
              and Physical Layer (PHY) Specifications",
              ASTM E2213-03(2010), October 2010.







Jeong                      Expires May 8, 2019                 [Page 21]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [ETSI-GeoNetwork-IP]
              ETSI Technical Committee Intelligent Transport Systems,
              "Intelligent Transport Systems (ITS); Vehicular
              Communications; GeoNetworking; Part 6: Internet
              Integration; Sub-part 1: Transmission of IPv6 Packets over
              GeoNetworking Protocols", ETSI EN 302 636-6-1, October
              2013.

   [ETSI-GeoNetworking]
              ETSI Technical Committee Intelligent Transport Systems,
              "Intelligent Transport Systems (ITS); Vehicular
              Communications; GeoNetworking; Part 4: Geographical
              addressing and forwarding for point-to-point and point-to-
              multipoint communications; Sub-part 1: Media-Independent
              Functionality", ETSI EN 302 636-4-1, May 2014.

   [EU-2008-671-EC]
              European Union, "Commission Decision of 5 August 2008 on
              the Harmonised Use of Radio Spectrum in the 5875 - 5905
              MHz Frequency Band for Safety-related Applications of
              Intelligent Transport Systems (ITS)", EU 2008/671/EC,
              August 2008.

   [FirstNet]
              U.S. National Telecommunications and Information
              Administration (NTIA), "First Responder Network Authorit=
y
              (FirstNet)", [Online]
              Available: https://www.firstnet.gov/, 2012.

   [FirstNet-Report]
              First Responder Network Authority, "FY 2017: ANNUAL REPO=
RT
              TO CONGRESS, Advancing Public Safety Broadband
              Communications", FirstNet FY 2017, December 2017.

   [Fuel-Efficient]
              van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas,
              "Fuel-Efficient En Route Formation of Truck Platoons&quo=
t;,
              IEEE Transactions on Intelligent Transportation Systems,
              January 2018.

   [GeoSAC]   Baldessari, R., Bernardos, C., and M. Calderon, "GeoSAC =
-
              Scalable Address Autoconfiguration for VANET Using
              Geographic Networking Concepts", IEEE International
              Symposium on Personal, Indoor and Mobile Radio
              Communications, September 2008.






Jeong                      Expires May 8, 2019                 [Page 22]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [H-DMM]    Nguyen, T. and C. Bonnet, "A Hybrid Centralized-
              Distributed Mobility Management for Supporting Highly
              Mobile Users", IEEE International Conference on
              Communications, June 2015.

   [ID-DNSNA]
              Jeong, J., Ed., Lee, S., and J. Park, "DNS Name
              Autoconfiguration for Internet of Things Devices", draft=
-
              jeong-ipwave-iot-dns-autoconf-04 (work in progress),
              October 2018.

   [ID-Vehicular-ND]
              Xiang, Zhong., Jeong, J., Ed., and Y. Shen, "IPv6 Neighb=
or
              Discovery for IP-Based Vehicular Networks", draft-xiang-
              ipwave-vehicular-neighbor-discovery-00 (work in progress),
              November 2018.

   [ID-VND-Discovery]
              Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and J. Lee,
              "IPv6 Neighbor Discovery for Prefix and Service Discover=
y
              in Vehicular Networks", draft-jeong-ipwave-vehicular-
              neighbor-discovery-04 (work in progress), October 2018.

   [Identity-Management]
              Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer
              Identities Management in ITS Stations", The 10th
              International Conference on ITS Telecommunications,
              November 2010.

   [IEEE-802.11-OCB]
              IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium
              Access Control (MAC) and Physical Layer (PHY)
              Specifications", IEEE Std 802.11-2016, December 2016.

   [IEEE-802.11p]
              IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium
              Access Control (MAC) and Physical Layer (PHY)
              Specifications - Amendment 6: Wireless Access in Vehicular
              Environments", IEEE Std 802.11p-2010, June 2010.

   [Intro-to-Algorithms]
              H. Cormen, T., E. Leiserson, C., L. Rivest, R., and C.
              Stein, "Introduction to Algorithms, 3rd ed.", The
              MIT Press, July 2009.







Jeong                      Expires May 8, 2019                 [Page 23]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [IP-Passing-Protocol]
              Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol fo=
r
              Vehicular Ad Hoc Networks with Network Fragmentation",
              Elsevier Computers & Mathematics with Applications,
              January 2012.

   [IPv6-over-802.11-OCB]
              Petrescu, A., Benamar, N., Haerri, J., Lee, J., and T.
              Ernst, "Transmission of IPv6 Packets over IEEE 802.11
              Networks operating in mode Outside the Context of a Basic
              Service Set (IPv6-over-80211-OCB)", draft-ietf-ipwave-
              ipv6-over-80211ocb-30 (work in progress), September 2018.

   [IPv6-WAVE]
              Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6
              Operation for WAVE - Wireless Access in Vehicular
              Environments", IEEE Vehicular Networking Conference,
              December 2010.

   [ISO-ITS-IPv6]
              ISO/TC 204, "Intelligent Transport Systems -
              Communications Access for Land Mobiles (CALM) - IPv6
              Networking", ISO 21210:2012, June 2012.

   [Joint-IP-Networking]
              Petrescu, A., Boc, M., and C. Ibars, "Joint IP Networkin=
g
              and Radio Architecture for Vehicular Networks",
              11th International Conference on ITS Telecommunications,
              August 2011.

   [LAGAD]    Abrougui, K., Boukerche, A., and R. Pazzi, "Location-Aid=
ed
              Gateway Advertisement and Discovery Protocol for VANets"=
,
              IEEE Transactions on Vehicular Technology, Vol. 59, No. 8,
              October 2010.

   [Multicast-802]
              Perkins, C., Stanley, D., Kumari, W., and JC. Zuniga,
              "Multicast Considerations over IEEE 802 Wireless Media&q=
uot;,
              draft-perkins-intarea-multicast-ieee802-03 (work in
              progress), July 2017.

   [Multicast-Alert]
              Camara, D., Bonnet, C., Nikaein, N., and M. Wetterwald,
              "Multicast and Virtual Road Side Units for Multi
              Technology Alert Messages Dissemination", IEEE 8th
              International Conference on Mobile Ad-Hoc and Sensor
              Systems, October 2011.




Jeong                      Expires May 8, 2019                 [Page 24]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [NEMO-LMS]
              Soto, I., Bernardos, C., Calderon, M., Banchs, A., and A.
              Azcorra, "NEMO-Enabled Localized Mobility Support for
              Internet Access in Automotive Scenarios",
              IEEE Communications Magazine, May 2009.

   [NEMO-VANET]
              Chen, Y., Hsu, C., and C. Cheng, "Network Mobility
              Protocol for Vehicular Ad Hoc Networks",
              Wiley International Journal of Communication Systems,
              November 2014.

   [PMIP-NEMO-Analysis]
              Lee, J., Ernst, T., and N. Chilamkurti, "Performance
              Analysis of PMIPv6-Based Network Mobility for Intelligent
              Transportation Systems", IEEE Transactions on Vehicular
              Technology, January 2012.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", RFC 4086, J=
une
              2005.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4=
861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, August 2008.

   [RFC5889]  Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
              Hoc Networks", RFC 5889, September 2010.

   [RFC5944]  Perkins, C., Ed., "IP Mobility Support in IPv4, Revised&=
quot;,
              RFC 5944, November 2010.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, July 2011.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC =
6762,
              February 2013.



Jeong                      Expires May 8, 2019                 [Page 25]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, February 2013.

   [RFC6775]  Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
              "Neighbor Discovery Optimization for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
              November 2012.

   [RFC7333]  Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
              "Requirements for Distributed Mobility Management",
              RFC 7333, August 2014.

   [RFC7429]  Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ.
              Bernardos, "Distributed Mobility Management: Current
              Practices and Gap Analysis", RFC 7429, January 2015.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 8200, July 2017.

   [SAINT]    Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT=
:
              Self-Adaptive Interactive Navigation Tool for Cloud-Based
              Vehicular Traffic Optimization", IEEE Transactions on
              Vehicular Technology, Vol. 65, No. 6, June 2016.

   [SAINTplus]
              Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D.
              Du, "SAINT+: Self-Adaptive Interactive Navigation To=
ol+
              for Emergency Service Delivery Optimization",
              IEEE Transactions on Intelligent Transportation Systems,
              June 2017.

   [SANA]     Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation
              Application for Pedestrian Protection in Vehicular
              Networks", Springer Lecture Notes in Computer Science
              (LNCS), Vol. 9502, December 2015.

   [SDN-DMM]  Nguyen, T., Bonnet, C., and J. Harri, "SDN-based
              Distributed Mobility Management for 5G Networks",
              IEEE Wireless Communications and Networking Conference,
              April 2016.

   [Securing-VCOMM]
              Fernandez, P., Santa, J., Bernal, F., and A. Skarmeta,
              "Securing Vehicular IPv6 Communications",
              IEEE Transactions on Dependable and Secure Computing,
              January 2016.





Jeong                      Expires May 8, 2019                 [Page 26]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [TR-22.886-3GPP]
              3GPP, "Study on Enhancement of 3GPP Support for 5G V2X
              Services", 3GPP TS 22.886, June 2018.

   [Truck-Platooning]
              California Partners for Advanced Transportation Technology
              (PATH), "Automated Truck Platooning", [Online] Avai=
lable:
              http://www.path.berkeley.edu/research/automated-and-
              connected-vehicles/truck-platooning, 2017.

   [TS-23.285-3GPP]
              3GPP, "Architecture Enhancements for V2X Services",=
 3GPP
              TS 23.285, June 2018.

   [VANET-Geo-Routing]
              Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Goleva,
              M., and T. Ernst, "Experimental Evaluation for IPv6 over
              VANET Geographic Routing", IEEE International Wireless
              Communications and Mobile Computing Conference, June 2010.

   [VIP-WAVE]
              Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the
              Feasibility of IP Communications in 802.11p Vehicular
              Networks", IEEE Transactions on Intelligent Transportati=
on
              Systems, vol. 14, no. 1, March 2013.

   [VMaSC-LTE]
              Ucar, S., Ergen, S., and O. Ozkasap, "Multihop-Cluster-
              Based IEEE 802.11p and LTE Hybrid Architecture for VANET
              Safety Message Dissemination", IEEE Transactions on
              Vehicular Technology, April 2016.

   [VNET-AAA]
              Moustafa, H., Bourdon, G., and Y. Gourhant, "Providing
              Authentication and Access Control in Vehicular Network
              Environment", IFIP TC-11 International Information
              Security Conference, May 2006.

   [VNET-MM]  Peng, Y. and J. Chang, "A Novel Mobility Management Sche=
me
              for Integration of Vehicular Ad Hoc Networks and Fixed IP
              Networks", Springer Mobile Networks and Applications,
              February 2010.

   [WAVE-1609.0]
              IEEE 1609 Working Group, "IEEE Guide for Wireless Access
              in Vehicular Environments (WAVE) - Architecture", IEEE S=
td
              1609.0-2013, March 2014.




Jeong                      Expires May 8, 2019                 [Page 27]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [WAVE-1609.2]
              IEEE 1609 Working Group, "IEEE Standard for Wireless
              Access in Vehicular Environments - Security Services for
              Applications and Management Messages", IEEE Std
              1609.2-2016, March 2016.

   [WAVE-1609.3]
              IEEE 1609 Working Group, "IEEE Standard for Wireless
              Access in Vehicular Environments (WAVE) - Networking
              Services", IEEE Std 1609.3-2016, April 2016.

   [WAVE-1609.4]
              IEEE 1609 Working Group, "IEEE Standard for Wireless
              Access in Vehicular Environments (WAVE) - Multi-Channel
              Operation", IEEE Std 1609.4-2016, March 2016.




































Jeong                      Expires May 8, 2019                 [Page 28]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


Appendix A.  Relevant Topics to IPWAVE Working Group

   This section discusses topics relevant to IPWAVE WG: (i) vehicle
   identity management; (ii) multihop V2X; (iii) multicast; (iv) DNS
   naming services and service discovery; (v) IPv6 over cellular
   networks.

A.1.  Vehicle Identity Management

   A vehicle can have multiple network interfaces using different access
   network technologies [Identity-Management].  These multiple network
   interfaces mean multiple identities.  To identify a vehicle with
   multiple indenties, a Vehicle Identification Number (VIN) can be used
   as a globally unique vehicle identifier.

   To support the seamless connectivity over the multiple identities, a
   cross-layer network architecture is required with vertical handover
   functionality [Identity-Management].  Also, an AAA service for
   multiple identities should be provided to vehicles in an efficient
   way to allow horizontal handover as well as vertical handover; note
   that AAA stands for Authentication, Authorization, and Accounting.

A.2.  Multihop V2X

   Multihop packet forwarding among vehicles in 802.11-OCB mode shows an
   unfavorable performance due to the common known broadcast-storm
   problem [Broadcast-Storm].  This broadcast-storm problem can be
   mitigated by the coordination (or scheduling) of a cluster head in a
   connected VANET or an RSU in an intersection area, where the cluster
   head can work as a coodinator for the access to wireless channels.

A.3.  Multicast

   IP multicast in vehicular network environments is especially useful
   for various services.  For instance, an automobile manufacturer can
   multicast a particular group/class/type of vehicles for service
   notification.  As another example, a vehicle or an RSU can
   disseminate alert messages in a particular area [Multicast-Alert].

   In general IEEE 802 wireless media, some performance issues about
   multicast are found in [Multicast-802].  Since several procedures and
   functions based on IPv6 use multicast for control-plane messages,
   such as Neighbor Discovery (ND) and Service Discovery,
   [Multicast-802] describes that the ND process may fail due to
   unreliable wireless link, causing failure of the DAD process.  Also,
   the Router Advertisement messages can be lost in multicasting.





Jeong                      Expires May 8, 2019                 [Page 29]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


A.4.  DNS Naming Services and Service Discovery

   When two vehicular nodes communicate with each other using the DNS
   name of the partner node, DNS naming service (i.e., DNS name
   resolution) is required.  As shown in Figure 2 and Figure 3, a
   recursive DNS server (RDNSS) within an internal network can perform
   such DNS name resolution for the sake of other vehicular nodes.

   A service discovery service is required for an application in a
   vehicular node to search for another application or server in another
   vehicular node, which resides in either the same internal network or
   the other internal network.  In V2I or V2V networking, as shown in
   Figure 2 and Figure 3, such a service discovery service can be
   provided by either DNS-based Service Discovery (DNS-SD) [RFC6763]
   with mDNS [RFC6762] or the vehicular ND with a new option for service
   discovery [ID-Vehicular-ND][ID-VND-Discovery].

A.5.  IPv6 over Cellular Networks

   Recently, 3GPP has announced a set of new technical specifications,
   such as Release 14 (3GPP-R14), which proposes an architecture
   enhancements for V2X services using the modified sidelink interface
   that originally is designed for the LTE-D2D communications. 3GPP-R14
   specifies that the V2X services only support IPv6 implementation.
   3GPP is also investigating and discussing the evolved V2X services in
   the next generation cellular networks, i.e., 5G new radio (5G-NR),
   for advanced V2X communications and automated vehicles' applications.

A.5.1.  Cellular V2X (C-V2X) Using 4G-LTE

   Before 3GPP-R14, some researchers have studied the potential usage of
   C-V2X communications.  For example, [VMaSC-LTE] explores a multihop
   cluster-based hybrid architecture using both DSRC and LTE for safety
   message dissemination.  Most of the research considers a short
   message service for safety instead of IP datagram forwarding.  In
   other C-V2X research, the standard IPv6 is assumed.

   The 3GPP technical specification [TS-23.285-3GPP] states that both IP
   based and non-IP based V2X messages are supported, and only IPv6 is
   supported for IP based messages.  Moreover, [TS-23.285-3GPP]
   instructs that a UE autoconfigures a link-local IPv6 address by
   following [RFC4862], but without sending Neighbor Solicitation and
   Neighbor Advertisement messages for DAD.  This is because a unique
   prefix is allocated to each node by the 3GPP network, so the IPv6
   addresses cannot be duplicate.






Jeong                      Expires May 8, 2019                 [Page 30]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


A.5.2.  Cellular V2X (C-V2X) Using 5G

   The emerging services, functions, and applications, which are
   developped in automotive industry, demand reliable and efficient
   communication infrastructure for road networks.  Correspondingly, the
   support of enhanced V2X (eV2X)-based services by future converged and
   interoperable 5G systems is required.  The 3GPP Technical Report
   [TR-22.886-3GPP] is studying new use cases and the corresponding
   service requirements for V2X (including V2V and V2I) using 5G in both
   infrastructure mode and the sidelink variations in the future.

Appendix B.  Changes from draft-ietf-ipwave-vehicular-networking-06

   The following changes are made from draft-ietf-ipwave-vehicular-
   networking-06:

   o  In Figure 1, a vehicular network architecture is modified to show
      a vehicular link model in a multi-link subnet with vehicular
      wireless links.

   o  In Section 5.1, a Vehicular Neighbor Discovery (VND)
      [ID-Vehicular-ND] is introduced along with a vehicular link model
      in a multi-link subnet.  In such a subnet, the description of MAC
      Address Pseudonym, Prefix Dissemination/Exchange, and Routing is
      clarified.

   o  In Section 5.2, a proactive handover is introduced for an
      efficient mobility management with the cooperation among vehicles,
      RSUs, and MA along with link-layer parameters, such as Received
      Channel Power Indicator (RCPI).

Appendix C.  Acknowledgments

   This work was supported by Basic Science Research Program through the
   National Research Foundation of Korea (NRF) funded by the Ministry of
   Education (2017R1D1A1B03035885).

   This work was supported in part by Global Research Laboratory Program
   through the NRF funded by the Ministry of Science and ICT (MSIT)
   (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT
   (18-EE-01).

   This work was supported in part by the French research project
   DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded
   by the European Commission I (636537-H2020).






Jeong                      Expires May 8, 2019                 [Page 31]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


Appendix D.  Contributors

   This document is a group work of IPWAVE working group, greatly
   benefiting from inputs and texts by Rex Buddenberg (Naval
   Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest
   University of Technology and Economics), Jose Santa Lozanoi
   (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot),
   Sri Gundavelli (Cisco), Erik Nordmark, and Dirk von Hugo (Deutsche
   Telekom).  The authors sincerely appreciate their contributions.

   The following are co-authors of this document:

   Nabil Benamar
   Department of Computer Sciences
   High School of Technology of Meknes
   Moulay Ismail University
   Morocco

   Phone: +212 6 70 83 22 36
   EMail: benamar73@gmail.com


   Sandra Cespedes
   NIC Chile Research Labs
   Universidad de Chile
   Av.  Blanco Encalada 1975
   Santiago
   Chile


   Phone: +56 2 29784093
   EMail: scespede@niclabs.cl


   Jerome Haerri
   Communication Systems Department
   EURECOM
   Sophia-Antipolis
   France

   Phone: +33 4 93 00 81 34
   EMail: jerome.haerri@eurecom.fr


   Dapeng Liu
   Alibaba
   Beijing, Beijing 100022
   China



Jeong                      Expires May 8, 2019                 [Page 32]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   Phone: +86 13911788933
   EMail: max.ldp@alibaba-inc.com


   Tae (Tom) Oh
   Department of Information Sciences and Technologies
   Rochester Institute of Technology
   One Lomb Memorial Drive
   Rochester, NY 14623-5603
   USA

   Phone: +1 585 475 7642
   EMail: Tom.Oh@rit.edu


   Charles E.  Perkins
   Futurewei Inc.
   2330 Central Expressway
   Santa Clara, CA 95050
   USA

   Phone: +1 408 330 4586
   EMail: charliep@computer.org


   Alexandre Petrescu
   CEA, LIST
   CEA Saclay
   Gif-sur-Yvette, Ile-de-France 91190
   France

   Phone: +33169089223
   EMail: Alexandre.Petrescu@cea.fr


   Yiwen Chris Shen
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do 16419
   Republic of Korea

   Phone: +82 31 299 4106
   Fax: +82 31 290 7996
   EMail: chrisshen@skku.edu
   URI: http://iotlab.skku.edu/people-chris-shen.php





Jeong                      Expires May 8, 2019                 [Page 33]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   Michelle Wetterwald
   FBConsulting
   21, Route de Luxembourg
   Wasserbillig, Luxembourg L-6633
   Luxembourg

   EMail: Michelle.Wetterwald@gmail.com


Author's Address

   Jaehoon Paul Jeong (editor)
   Department of Software
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 31 299 4957
   Fax:   +82 31 290 7996
   EMail: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php





























Jeong                      Expires May 8, 2019                 [Page 34]





--_000_D87E26092E68EBsgundaveciscocom_--


From nobody Mon Feb  4 23:28:08 2019
Return-Path: 
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 6CA0D130E09 for ; Mon,  4 Feb 2019 23:28:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
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 AvLhKbvOkp39 for ; Mon,  4 Feb 2019 23:27:55 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 AEEAD130DEC for ; Mon,  4 Feb 2019 23:27:54 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id z18so1687263wrh.2 for ; Mon, 04 Feb 2019 23:27:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hfqiPP9j+1sqZmnYzQtZXhpAGP0YANfX3jyWA/CQmr0=; b=DIJU6n3NEhU6ZFwY2YJy7eUdHT+/BL/+F5NYOZ58aa2TZQmnGljHD8MjLIVFktazIx xLyZgykPD44m2bO603MVhGPGzcGJbXndoUVjxJvJlvUpkTsqVeHiGzK/HwqcWJM+Z8Tq 4ZucHkRryBtQbTGRzj/etgHeYJ9kfHxnYYrmOvHF2B55Zs9fwvNTO9U/ap019xVcPCRs tFSVVjszscvnbHr2J/lizLwojNiYy5qz0ugJoEP1nVZ5bJq7WVTYVYYD0ndjVzvOOMqQ 14XIpwjSRaUaP/25tEWivmCb0bFcTWobDiGT6rkCZlxtlWdmsU7S9Z2Sx6KFvau8g5IV 6OLw==
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=hfqiPP9j+1sqZmnYzQtZXhpAGP0YANfX3jyWA/CQmr0=; b=sIQeEKu2bGpT42Lc8BQpzqKAQruSHHmk3iVcSY2zv6sIqtK94g22V5mH3QmH4jzyHg X/7Bu+z08lQ6S1pweY8NIO4Nq3NbMe2c8gh6N1NrtkatKi2HOn4SO8SOQBIFOEft04ox NlXjvH9/nWjT08wNX9TyUVi/hPo78BMiBZHpKeoaRX0oJGrK9iFLQHT/eBGTfkDL6y1V /m5RYAcGYTSkGo+eOLi5K88cjebi/1JGKDO1VDbEl7+dcc28vBr2jliFrT1HO6M2WJvo lbxT+Ile+TSZl0wwlNuYqWeujZ2UUjkscALyzApixNIkJ5/snrEphFZfK1/LLyqn+mNG KqsA==
X-Gm-Message-State: AHQUAuZ7SW8kGFGpfUH+sy79vBsKisTmdLbgqNaRnXoO4iONW1SJ+Gjz JxZX4L5FHhaOSqhX9Dg49VVXtL4WTB3Y43RoJ+OaTA==
X-Google-Smtp-Source: AHgI3Ibg9/KryOhRHkZuetRm4cEK3obFAux0aj+heb09b1cEPV0T4GMHCYeehz3YqvrG9CHL/pHmSTvpxzaDW00A5G0=
X-Received: by 2002:a5d:6850:: with SMTP id o16mr2488858wrw.123.1549351672129;  Mon, 04 Feb 2019 23:27:52 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: CARLOS JESUS BERNARDOS CANO 
Date: Tue, 5 Feb 2019 08:27:35 +0100
Message-ID: 
To: "Sri Gundavelli (sgundave)" 
Cc: "its@ietf.org" , "Mr. Jaehoon Paul Jeong" 
Content-Type: multipart/alternative; boundary="0000000000000ce7460581208c08"
Archived-At: 
Subject: Re: [ipwave] Review of draft-ietf-ipwave-vehicular-networking-07
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Feb 2019 07:28:06 -0000

--0000000000000ce7460581208c08
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Sri for the review.

Authors, please revise accordingly.

Thanks,

Carlos

On Tue, Feb 5, 2019 at 2:26 AM Sri Gundavelli (sgundave) 
wrote:

> Hey Paul,
>
> Attached is my review.  Please see some inline comments. In my opinion, t=
he document has thin line separating the problem description from the solut=
ion description. In many places, the focus is more on the solution before e=
xplaining what the problem is.  I think you have an opportunity here to gre=
atly simplify the document and keep it to the point. I hate to push you tow=
ards another revision, but in the current form this won=E2=80=99t pass IESG=
, IMO. The Gods in IESG will send it back to the WG. I really think you can=
 cut down the text by 50% to 60%. As they say,  =E2=80=9Csome times,  less =
is more" :-)  Hope this helps.
>
> Cheers!
> Sri
>
>
>
>
>
> --
> IPWAVE Working Group                                       J. Jeong, Ed.
> Internet-Draft                                   Sungkyunkwan University
> Intended status: Informational                          November 4, 2018
> Expires: May 8, 2019
>
>
> IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement
>                              and Use Cases
>                draft-ietf-ipwave-vehicular-networking-07
>
> Abstract
>
>    This document discusses the problem statement and use cases on IP-
>    based vehicular networks, which are considered a key component of
>    Intelligent Transportation Systems (ITS).
>
> *[Sri] What is Key component of ITS? Usecases? You may want to reword*
>
>
> "This document discusses the problem statement and use cases on IP-
>    based vehicular networks for building Intelligent Transportation Syste=
ms (ITS).
>
>
> The main scenarios of
>    vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-
>    infrastructure (V2I), and vehicle-to-everything (V2X) communications.
>    First, this document surveys use cases using V2V, V2I, and V2X
>    networking.  Second, it analyzes proposed protocols for IP-based
>    vehicular networking and highlights the limitations and difficulties
>    found on those protocols.  Third, it presents a problem exploration
>    for key aspects in IP-based vehicular networking, such as IPv6
>    Neighbor Discovery, Mobility Management, and Security & Privacy.  For
>    each key aspect, this document discusses a problem statement to
>    evaluate the gap between the state-of-the-art techniques and
>    requirements in IP-based vehicular networking.
>
> Status of This Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at https://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on May 8, 2019.
>
>
>
>
>
>
>
>
> Jeong                      Expires May 8, 2019                  [Page 1]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
> Copyright Notice
>
>    Copyright (c) 2018 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (https://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
>
> Table of Contents
>
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
>    2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
>    3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
>      3.1.  V2V . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
>      3.2.  V2I . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
>      3.3.  V2X . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
>    4.  Analysis for Existing Protocols . . . . . . . . . . . . . . .   8
>      4.1.  Existing Protocols for Vehicular Networking . . . . . . .   8
>        4.1.1.  IPv6 over 802.11-OCB  . . . . . . . . . . . . . . . .   8
>        4.1.2.  IP Address Autoconfiguration  . . . . . . . . . . . .   8
>        4.1.3.  Routing . . . . . . . . . . . . . . . . . . . . . . .   9
>        4.1.4.  Mobility Management . . . . . . . . . . . . . . . . .   9
>        4.1.5.  DNS Naming Service  . . . . . . . . . . . . . . . . .   9
>        4.1.6.  Service Discovery . . . . . . . . . . . . . . . . . .   9
>        4.1.7.  Security and Privacy  . . . . . . . . . . . . . . . .  10
>      4.2.  General Problems  . . . . . . . . . . . . . . . . . . . .  10
>        4.2.1.  Vehicular Network Architecture  . . . . . . . . . . .  11
>        4.2.2.  Latency . . . . . . . . . . . . . . . . . . . . . . .  16
>        4.2.3.  Security  . . . . . . . . . . . . . . . . . . . . . .  16
>        4.2.4.  Pseudonym Handling  . . . . . . . . . . . . . . . . .  16
>    5.  Problem Exploration . . . . . . . . . . . . . . . . . . . . .  17
>      5.1.  Neighbor Discovery  . . . . . . . . . . . . . . . . . . .  17
>        5.1.1.  Link Model  . . . . . . . . . . . . . . . . . . . . .  17
>        5.1.2.  MAC Address Pseudonym . . . . . . . . . . . . . . . .  18
>        5.1.3.  Prefix Dissemination/Exchange . . . . . . . . . . . .  18
>        5.1.4.  Routing . . . . . . . . . . . . . . . . . . . . . . .  18
>      5.2.  Mobility Management . . . . . . . . . . . . . . . . . . .  19
>      5.3.  Security and Privacy  . . . . . . . . . . . . . . . . . .  20
>    6.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
>    7.  Informative References  . . . . . . . . . . . . . . . . . . .  21
>    Appendix A.  Relevant Topics to IPWAVE Working Group  . . . . . .  29
>
>
>
> Jeong                      Expires May 8, 2019                  [Page 2]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
>      A.1.  Vehicle Identity Management . . . . . . . . . . . . . . .  29
>      A.2.  Multihop V2X  . . . . . . . . . . . . . . . . . . . . . .  29
>      A.3.  Multicast . . . . . . . . . . . . . . . . . . . . . . . .  29
>      A.4.  DNS Naming Services and Service Discovery . . . . . . . .  30
>      A.5.  IPv6 over Cellular Networks . . . . . . . . . . . . . . .  30
>        A.5.1.  Cellular V2X (C-V2X) Using 4G-LTE . . . . . . . . . .  30
>        A.5.2.  Cellular V2X (C-V2X) Using 5G . . . . . . . . . . . .  31
>    Appendix B.  Changes from draft-ietf-ipwave-vehicular-
>                 networking-06  . . . . . . . . . . . . . . . . . . .  31
>    Appendix C.  Acknowledgments  . . . . . . . . . . . . . . . . . .  31
>    Appendix D.  Contributors . . . . . . . . . . . . . . . . . . . .  32
>    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  34
>
> 1.  Introduction
>
>    Vehicular networking studies have mainly focused on driving safety,
>    driving efficiency, and entertainment in road networks.
>
> *[Sri] Rephrase, =E2=80=9Cfocused on driving safety, driving efficiency, =
and entertainment in road networks." *
>
> *To perhaps, =E2=80=9Cfocussed on improving safety, efficiency and enabli=
ng entertainment in vehicular networks=E2=80=9D*
>
> The Federal
>    Communications Commission (FCC) in the US allocated wireless channels
>    for Dedicated Short-Range Communications (DSRC) [DSRC], service in
>    the Intelligent Transportation Systems (ITS) Radio Service in the
>    5.850 - 5.925 GHz band (5.9 GHz band).  DSRC-based wireless
>    communications can support vehicle-to-vehicle (V2V), vehicle-to-
>    infrastructure (V2I), and vehicle-to-everything (V2X) networking.
>    Also, the European Union (EU) passed a decision to allocate radio
>    spectrum for safety-related and non-safety-related applications of
>    ITS with the frequency band of 5.875 - 5.905 GHz, which is called
>    Commission Decision 2008/671/EC [EU-2008-671-EC].
>
>    For direct inter-vehicular wireless connectivity, IEEE has amended
>    WiFi standard 802.11 to enable driving safety services based on the
>    DSRC in terms of standards for the Wireless Access in Vehicular
>    Environments (WAVE) system.  L1 and L2 issues are addressed in IEEE
>
> *[Sri] Expand L1, L2*
>
>
>    802.11p [IEEE-802.11p] for the PHY and MAC of the DSRC, while IEEE
>    1609.2 [WAVE-1609.2] covers security aspects, IEEE 1609.3
>    [WAVE-1609.3] defines related services at network and transport
>    layers, and IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel
>    operation.  Note that IEEE 802.11p has been published as IEEE 802.11
>    Outside the Context of a Basic Service Set (OCB) called IEEE
>    802.11-OCB [IEEE-802.11-OCB] in 2012.
>
> *[Sri] You may want to say, 802.11p was a separate standard, but was late=
r enrolled into the base 802.11 standard, IEEE 802.11-2012*
>
>    Along with these WAVE standards, IPv6 [RFC8200] and Mobile IP
>    protocols (e.g., MIPv4 [RFC5944] and MIPv6 [RFC6275]) can be applied
>    (or easily modified) to vehicular networks.
>
>
> *[Sri] Since, you mentioned MIP4, MIP6, it will be incomplete if you don=
=E2=80=99t include PMIPv6 [RFC5213 and RFC5844]. Also, to be consistent wit=
h my other comments, please refer to them in the context of a problem. Stat=
e the problem, say =E2=80=9Cmobility **management=E2=80=9D, explain the req=
uirement and refer to existing IETF art, for addressing that problem. *
>
>
> In Europe, ETSI has
>    standardized a GeoNetworking (GN) protocol [ETSI-GeoNetworking] and a
>    protocol adaptation sub-layer from GeoNetworking to IPv6
>    [ETSI-GeoNetwork-IP].  Note that a GN protocol is useful to route an
>    event or notification message to vehicles around a geographic
>    position, such as an acciendent area in a roadway.  In addition, ISO
>
>
>
> Jeong                      Expires May 8, 2019                  [Page 3]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
>    has approved a standard specifying the IPv6 network protocols and
>    services to be used for Communications Access for Land Mobiles (CALM)
>    [ISO-ITS-IPv6].
>
> *[Sri] This is great information, but curious how it toes back to this do=
cument? Use of IP ?*
>
>
>    This document discusses problem statements and use cases related to
>    IP-based vehicular networking for Intelligent Transportation Systems
>    (ITS), which is denoted as IP Wireless Access in Vehicular
>    Environments (IPWAVE).  First, it surveys the use cases for using
>    V2V, V2I, and V2X networking in the ITS.  Second, for literature
>    review, it analyzes proposed protocols for IP-based vehicular
>    networking and highlights the limitations and difficulties found on
>    those protocols.  Third, for problem statement, it presents a problem
>    exploration with key aspects in IPWAVE, such as IPv6 Neighbor
>    Discovery, Mobility Management, and Security & Privacy.  For each key
>    aspect of the problem statement, it analyzes the gap between the
>    state-of-the-art techniques and the requirements in IP-based
>    vehicular networking.  It also discusses potential topics relevant to
>    IPWAVE Working Group (WG), such as Vehicle Identities Management,
>    Multihop V2X Communications, Multicast, DNS Naming Services, Service
>    Discovery, and IPv6 over Cellular Networks.  Therefore, with the
>    problem statement, this document will open a door to develop key
>    protocols for IPWAVE that will be essential to IP-based vehicular
>    networks.
>
> 2.  Terminology
>
>    This document uses the following definitions:
>
>    o  WAVE: Acronym for "Wireless Access in Vehicular Environments"
>       [WAVE-1609.0].
>
>    o  DMM: Acronym for "Distributed Mobility Management"
>       [RFC7333][RFC7429].
>
>    o  Road-Side Unit (RSU): A node that has physical communication
>       devices (e.g., DSRC, Visible Light Communication, 802.15.4, LTE-
>       V2X, etc.) for wireless communications with vehicles and is also
>       connected to the Internet as a router or switch for packet
>       forwarding.  An RSU is typically deployed on the road
>       infrastructure, either at an intersection or in a road segment,
>       but may also be located in car parking area.
>
> *[Sri] I would think DSRC and C-V2X are the only wireless systems current=
ly defined for Vehicular Communications, or at least the term RSU is used o=
nly by these systems. So, I am not sure if we should mention 802.15.4 or Vi=
sible Light Communications. Also, if you look at the OBU definition below, =
is there a OBU with visible light interface, so both the ends have to suppo=
rt the same scheme.*
>
>
>    o  On-Board Unit (OBU): A node that has a DSRC device for wireless
>       communications with other OBUs and RSUs, and may be connected to
>       in-vehicle devices or networks.  An OBU is mounted on a vehicle.
>       It is assumed that a radio navigation receiver (e.g., Global
>       Positioning System (GPS)) is included in a vehicle with an OBU for
>       efficient navigation.
>
>
>
> Jeong                      Expires May 8, 2019                  [Page 4]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
>    o  Vehicle Detection Loop (or Loop Detector): An inductive device
>       used for detecting vehicles passing or arriving at a certain
>       point, for instance approaching a traffic light or in motorway
>       traffic.  The relatively crude nature of the loop's structure
>       means that only metal masses above a certain size are capable of
>       triggering the detection.
>
>    o  Mobility Anchor (MA): A node that maintains IP addresses and
>       mobility information of vehicles in a road network to support the
>       address autoconfiguration and mobility management of them.  It has
>       end-to-end connections with RSUs under its control.  It maintains
>       a DAD table having the IP addresses of the vehicles moving within
>       the communication coverage of its RSUs.
>
> *[Sri] The last sentence is pointing to a solution. MA may or may not mai=
ntain a DAD table. It may maintain a binding table like MIPv6 HA, or PMIPv6=
 LMA*
>
>
>    o  Vehicular Cloud: A cloud infrastructure for vehicular networks,
>       having compute nodes, storage nodes, and network nodes.
>
>    o  Traffic Control Center (TCC): A node that maintains road
>       infrastructure information (e.g., RSUs, traffic signals, and loop
>       detectors), vehicular traffic statistics (e.g., average vehicle
>       speed and vehicle inter-arrival time per road segment), and
>       vehicle information (e.g., a vehicle's identifier, position,
>       direction, speed, and trajectory as a navigation path).  TCC is
>       included in a vehicular cloud for vehicular networks.
>
> 3.  Use Cases
>
>    This section provides use cases of V2V, V2I, and V2X networking.  The
>    use cases of the V2X networking exclude the ones of the V2V and V2I
>    networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to-
>    Device (V2D).
>
> 3.1.  V2V
>
>    The use cases of V2V networking discussed in this section include
>
>    o  Context-aware navigation for driving safety and collision
>       avoidance;
>
>    o  Cooperative adaptive cruise control in an urban roadway;
>
>    o  Platooning in a highway;
>
>    o  Cooperative environment sensing.
>
>    These four techniques will be important elements for self-driving
>    Vehicles.
>
>
> *[Sri] I am not convinced if this is a complete list, or how these items =
made it here.. 3GPP has identified some use-cases, I wonder what is the del=
ta between the two*
>
>
>
>
> Jeong                      Expires May 8, 2019                  [Page 5]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
>    Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers
>    to drive safely by letting the drivers recognize dangerous obstacles
>    and situations.  That is, CASD navigator displays obstables or
>    neighboring vehicles relevant to possible collisions in real-time
>    through V2V networking.  CASD provides vehicles with a class-based
>    automatic safety action plan, which considers three situations, such
>    as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe and safe
>    situations.  This action plan can be performed among vehicles through
>    V2V networking.
>
>    Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps
>    vehicles to adapt their speed autonomously through V2V communication
>    among vehicles according to the mobility of their predecessor and
>    successor vehicles in an urban roadway or a highway.  CACC can help
>    adjacent vehicles to efficiently adjust their speed in a cascade way
>    through V2V networking.
>
>    Platooning [Truck-Platooning] allows a series of vehicles (e.g.,
>    trucks) to move together with a very short inter-distance.  Trucks
>    can use V2V communication in addition to forward sensors in order to
>    maintain constant clearance between two consecutive vehicles at very
>    short gaps (from 3 meters to 10 meters).  This platooning can
>    maximize the throughput of vehicular traffic in a highway and reduce
>    the gas consumption because the leading vehicle can help the
>    following vehicles to experience less air resistance.
>
>    Cooperative-environment-sensing use cases suggest that vehicles can
>    share environmental information from various vehicle-mounted sensors,
>    such as radars, LiDARs and cameras with other vehicles and
>    pedestrians.  [Automotive-Sensing] introduces a millimeter-wave
>    vehicular communication for massive automotive sensing.  Data
>    generated by those sensors can be substantially large, and these data
>    shall be routed to different destinations.  In addition, from the
>    perspective of driverless vehicles, it is expected that driverless
>    vehicles can be mixed with driver-operated vehicles.  Through
>    cooperative environment sensing, driver-operated vehicles can use
>    environmental information sensed by driverless vehicles for better
>    interaction with the context.
>
> 3.2.  V2I
>
>    The use cases of V2I networking discussed in this section include
>
>    o  Navigation service;
>
>    o  Energy-efficient speed recommendation service;
>
>    o  Accident notification service.
>
>
>
> Jeong                      Expires May 8, 2019                  [Page 6]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
>    A navigation service, such as the Self-Adaptive Interactive
>    Navigation Tool (called SAINT) [SAINT], using V2I networking
>    interacts with TCC for the large-scale/long-range road traffic
>    optimization and can guide individual vehicles for appropriate
>    navigation paths in real time.  The enhanced SAINT (called SAINT+)
>    [SAINTplus] can give the fast moving paths for emergency vehicles
>    (e.g., ambulance and fire engine) toward accident spots while
>    providing other vehicles with efficient detour paths.
>
> *[Sri] Is this a requirement, or a description of some deployed service? =
*
>
>
>    A TCC can recommend an energy-efficient speed to a vehicle driving in
>    different traffic environments.  [Fuel-Efficient] studies fuel-
>    efficient route and speed plans for platooned trucks.
>
>    The emergency communication between accident vehicles (or emergency
>    vehicles) and TCC can be performed via either RSU or 4G-LTE networks.
>    The First Responder Network Authority (FirstNet) [FirstNet] is
>    provided by the US government to establish, operate, and maintain an
>    interoperable public safety broadband network for safety and security
>    network services, such as emergency calls.  The construction of the
>    nationwide FirstNet network requires each state in the US to have a
>    Radio Access Network (RAN) that will connect to FirstNet's network
>    core.  The current RAN is mainly constructed by 4G-LTE for the
>    communication between a vehicle and an infrastructure node (i.e.,
>    V2I) [FirstNet-Report], but it is expected that DSRC-based vehicular
>    networks [DSRC] will be available for V2I and V2V in near future.
>
> 3.3.  V2X
>
>    The use case of V2X networking discussed in this section is
>    pedestrian protection service.
>
>    A pedestrian protection service, such as Safety-Aware Navigation
>    Application (called SANA) [SANA], using V2I2P networking can reduce
>    the collision of a vehicle and a pedestrian carrying a smartphone
>    equipped with the access technology with an RSU (e.g., WiFi).
>    Vehicles and pedestrians can also communicate with each other via an
>    RSU that delivers scheduling information for wireless communication
>    in order to save the smartphones' battery through sleeping mode.
>
>    For Vehicle-to-Pedestrian (V2P), a vehicle and a pedestrian's
>    smartphone can directly communicate with each other via V2X without
>    the relaying of an RSU as in a V2V scenario such that the
>    pedestrian's smartphone is regarded as a vehicle with a wireless
>    media interface to be able to communicate with another vehicle.  In
>    Vehicle-to-Device (V2D), a device can be a mobile node such as
>    bicycle and motorcycle, and can communicate directly with a vehicle
>    for collision avoidance.
>
>
>
>
> Jeong                      Expires May 8, 2019                  [Page 7]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
> 4.  Analysis for Existing Protocols
>
> 4.1.  Existing Protocols for Vehicular Networking
>
>    *We describe some currently existing protocols* and proposed solutions
>    with respect to the following aspects that are relevant and essential
>    for vehicular networking:
>
>    o  IPv6 over 802.11-OCB;
>
>    o  IP address autoconfiguration;
>
>    o  Routing;
>
>
> *[Sri] Is Routing a protocol?  Are these protocols, or services ?*
>
>    o  Mobility management;
>
>    o  DNS naming service;
>
>    o  Service discovery;
>
>    o  Security and privacy.
>
>
> 4.1.1.  IPv6 over 802.11-OCB
>
>    For IPv6 packets transporting over IEEE 802.11-OCB,
>    [IPv6-over-802.11-OCB] specifies several details, such as Maximum
>    Transmission Unit (MTU), frame format, link-local address, address
>    mapping for unicast and multicast, stateless autoconfiguration, and
>    subnet structure.  Especially, an Ethernet Adaptation (EA) layer is
>    in charge of transforming some parameters between IEEE 802.11 MAC
>    layer and IPv6 network layer, which is located between IEEE
>    802.11-OCB's logical link control layer and IPv6 network layer.
>
>
> *[Sri] But, what is the point from the point of view of this spec? *
>
> 4.1.2.  IP Address Autoconfiguration
>
>    For IP address autoconfiguration, Fazio et al. proposed a vehicular
>    address configuration (VAC) scheme using DHCP where elected leader-
>    vehicles provide unique identifiers for IP address configurations in
>    vehicles [Address-Autoconf].  Kato et al. proposed an IPv6 address
>    assignment scheme using lane and position information
>    [Address-Assignment].  Baldessari et al. proposed an IPv6 scalable
>    address autoconfiguration scheme called GeoSAC for vehicular networks
>    [GeoSAC].  Wetterwald et al. conducted for heterogeneous vehicular
>    networks (i.e., employing multiple access technologies) a
>    comprehensive study of the cross-layer identities management, which
>    constitutes a fundamental element of the ITS architecture
>    [Identity-Management].
>
>
> *[Sri] The focus of the document should be on the problem statement. We h=
ave departed from that and now we are talking solutions. I see this problem=
 through out this spec.*
>
>
>
> Jeong                      Expires May 8, 2019                  [Page 8]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
> 4.1.3.  Routing
>
>    For routing, Tsukada et al. presented a work that aims at combining
>    IPv6 networking and a Car-to-Car Network routing protocol (called
>    C2CNet) proposed by the Car2Car Communication Consortium (C2C-CC),
>    which is an architecture using a geographic routing protocol
>    [VANET-Geo-Routing].  Abrougui et al. presented a gateway discovery
>    scheme for VANET, called Location-Aided Gateway Advertisement and
>    Discovery (LAGAD) mechanism [LAGAD].
>
>
> *[Sri] Again, the focus of the document should be on problem statement, n=
ot on solutions*
>
> 4.1.4. Mobility Management For mobility management, Chen et al. tackled
> the issue of network fragmentation in VANET environments
> [IP-Passing-Protocol] by proposing a protocol that can postpone the time =
to
> release IP addresses to the DHCP server and select a faster way to get th=
e
> vehicle's new IP address, when the vehicle density is low or the speeds o=
f
> vehicles are highly variable. Nguyen et al. proposed a hybrid
> centralized-distributed mobility management called H-DMM to support highl=
y
> mobile vehicles [H-DMM]. [NEMO-LMS] proposed an architecture to enable IP
> mobility for moving networks using a network-based mobility scheme based =
on
> PMIPv6. Chen et al. proposed a network mobility protocol to reduce handof=
f
> delay and maintain Internet connectivity to moving vehicles in a highway
> [NEMO-VANET]. Lee et al. proposed P-NEMO, which is a PMIPv6-based IP
> mobility management scheme to maintain the Internet connectivity at the
> vehicle as a mobile network, and provides a make-before-break mechanism
> when vehicles switch to a new access network [PMIP-NEMO-Analysis]. Peng e=
t
> al. proposed a novel mobility management scheme for integration of VANET
> and fixed IP networks [VNET-MM]. Nguyen et al. extended their previous
> works on a vehicular adapted DMM considering a Software-Defined Networkin=
g
> (SDN) architecture [SDN-DMM].
>
>
> *[Sri] The focus of the document should on the problem statement, not on =
solutions. This platter of requirements are discrete and not connecting bac=
k to a larger architecture. *
>
> 4.1.5. DNS Naming Service For DNS naming service, Multicast DNS (mDNS)
> [RFC6762] allows devices in one-hop communication range to resolve each
> other's DNS name into the corresponding IP address in multicast. DNS Name
> Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming service for
> Internet-of-Things (IoT) devices in a large-scale network.
>
>
> *[Sri] Sure, but our goal is to talk about the problems when using this i=
n vehicular context. I don=E2=80=99t see that discussion *
>
>
> 4.1.6.  Service Discovery
>
>    To discover instances of a demanded service in vehicular networks,
>    DNS-based Service Discovery (DNS-SD) [RFC6763] with either DNSNA
>    [ID-DNSNA] or mDNS [RFC6762] provides vehicles with service discovery
>    by using standard DNS queries.  Vehicular ND [ID-Vehicular-ND]
>
>
>
> Jeong                      Expires May 8, 2019                  [Page 9]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
>    proposes an extension of IPv6 ND for the prefix and service discovery
>    with new ND options [ID-VND-Discovery].  Note that a DNS query for
>    service discovery is unicasted in DNSNA, but it is multicasted in
>    both mDNS and Vehicular ND.
>
>
> *[Sri] We have now departed to from PS world, to Solution world. *
>
>
> 4.1.7.  Security and Privacy
>
>    For security and privacy, Fernandez et al. proposed a secure
>    vehicular IPv6 communication scheme using Internet Key Exchange
>    version 2 (IKEv2) and Internet Protocol Security (IPsec)
>    [Securing-VCOMM].  Moustafa et al. proposed a security scheme
>    providing authentication, authorization, and accounting (AAA)
>    services in vehicular networks [VNET-AAA].
>
> *[Sri] I do not know if Fernandez et all, covered the problem description=
, but we should first talk about the problem before we talk about solution =
*
>
> 4.2.  General Problems
>
>    This section describes a possible vehicular network architecture for
>    V2V, V2I, and V2X communications.  Then it analyzes the limitations
>    of the current protocols for vehicular networking.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Jeong                      Expires May 8, 2019                 [Page 10]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
>                      Traffic Control Center in Vehicular Cloud
>                     *-----------------------------------------*
>                    *                                           *
>                   *             +----------------+              *
>                  *              | Mobility Anchor|               *
>                  *              +----------------+               *
>                   *                      ^                      *
>                    *                     |                     *
>                     *--------------------v--------------------*
>                     ^               ^                        ^
>                     |               |                        |
> +------------------ |  -------------|-------------+ +------------------+
> |                   v               v             | |        v         |
> |           +--------+  Ethernet   +--------+     | |    +--------+    |
> |           |  RSU1  |<----------->|  RSU2  |<---------->|  RSU3  |    |
> |           +--------+             +--------+     | |    +--------+    |
> |           ^        ^                  ^         | |        ^         |
> |           :        :                  :         | |        :         |
> |       V2I :        : V2I          V2I :         | |    V2I :         |
> |           v        v                  v         | |        v         |
> |   +--------+      +--------+      +--------+    | |    +--------+    |
> |   |Vehicle1|=3D=3D=3D>  |Vehicle2|=3D=3D=3D>  |Vehicle3|=3D=3D=3D>| |  =
  |Vehicle4|=3D=3D=3D>|
> |   |        |<....>|        |<....>|        |    | |    |        |    |
> |   +--------+ V2V  +--------+ V2V  +--------+    | |    +--------+    |
> |                                                 | |                  |
> +-------------------------------------------------+ +------------------+
>                       Subnet1                              Subnet2
>
>    <----> Wired Link   <....> Wireless Link   =3D=3D=3D> Moving Direction
>
>    Figure 1: A Vehicular Network Architecture for V2I and V2V Networking
>
> 4.2.1.  Vehicular Network Architecture
>
>    Figure 1 shows a possible architecture for V2I and V2V networking in
>    a road network.  It is assumed that RSUs as routers and vehicles with
>    OBU have wireless media interfaces (e.g., IEEE 802.11-OCB, LTE Uu and
>    Device-to-Device (D2D) (also known as PC5 [TS-23.285-3GPP]),
>    Bluetooth, and Light Fidelity (Li-Fi)) for V2I and V2V communication.
>    Also, it is assumed that such the wireless media interfaces are
>    autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to
>    support both V2V and V2I networking.  Three RSUs (RSU1, RSU2, and
>    RSU3) are deployed in the road network and are connected to a
>    Vehicular Cloud through the Internet.  A Traffic Control Center (TCC)
>    is connected to the Vehicular Cloud for the management of RSUs and
>    vehicles in the road network.  A Mobility Anchor (MA) is located in
>    the TCC as its key component for the mobility management of vehicles.
>    Two vehicles (Vehicle1 and Vehicle2) are wirelessly connected to
>
>
>
> Jeong                      Expires May 8, 2019                 [Page 11]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
>    RSU1, and one vehicle (Vehicle3) is wirelessly connected to RSU2.
>    The wireless networks of RSU1 and RSU2 belong to a multi-link subnet
>    (denoted as Subnet1) with the same network prefix.  Thus, these three
>    vehicles are within the same subnet.  On the other hand, another
>    vehicle (Vehicle4) is wireless connected to RSU4, belonging to
>    another subnet (denoted as Subnet2).  That is, the first three
>    vehicles (i.e., Vehicle1, Vehicle2, and Vehicle3) and the last
>    vehicle (i.e., Vehicle4) are located in the two different subnets.
>    Vehicle1 can communicate with Vehicle2 via V2V communication, and
>    Vehicle2 can communicate with Vehicle3 via V2V communication because
>    they are within the same subnet along their IPv6 addresses, which are
>    based on the same prefix.  On the other hand, Vehicle3 can
>    communicate with Vehicle4 via RSU2 and RSU3 employing V2I (i.e.,
>    V2I2V) communication because they are within the two different
>    subnets along with their IPv6 addresses, which are based on the two
>    different prefixes.
>
>    In vehicular networks, unidirectional links exist and must be
>    considered for wireless communications.  Also, in the vehicular
>    networks, control plane must be separated from data plane for
>    efficient mobility management and data forwarding using Software-
>    Defined Networking (SDN) [SDN-DMM].  ID/Pseudonym change for privacy
>    requires a lightweight DAD.  IP tunneling over the wireless link
>    should be avoided for performance efficiency.  The mobility
>    information of a mobile (e.g., vehicle-mounted) device through a GPS
>    receiver in its vehicle, such as trajectory, position, speed, and
>    direction, can be used by the mobile device and infrastructure nodes
>    (e.g., TCC and RSU) for the accommodation of mobility-aware proactive
>    protocols.  Vehicles can use the TCC as their Home Network having a
>    home agent for mobility management as in MIPv6 [RFC6275] and Proxy
>    Mobile IPv6 (PMIPv6) [RFC5213], so the TCC maintains the mobility
>    information of vehicles for location management.
>
>    Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for
>    I2V and V2I networking [VIP-WAVE].  The standard WAVE does not
>    support both seamless communications for Internet services and multi-
>    hop communications between a vehicle and an infrastructure node
>    (e.g., RSU), either.  To overcome these limitations of the standard
>    WAVE, VIP-WAVE enhances the standard WAVE by the following three
>    schemes: (i) an efficient mechanism for the IPv6 address assignment
>    and DAD, (ii) on-demand IP mobility based on PMIPv6 [RFC5213], and
>    (iii) one-hop and two-hop communications for I2V and V2I networking.
>
>    Baccelli et al. provided an analysis of the operation of IPv6 as it
>    has been described by the IEEE WAVE standards 1609 [IPv6-WAVE].  This
>    analysis confirms that the use of the standard IPv6 protocol stack in
>    WAVE is not sufficient.  It recommends that the IPv6 addressing
>
>
>
>
> Jeong                      Expires May 8, 2019                 [Page 12]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
>    assignment should follow considerations for ad-hoc link models,
>    defined in [RFC5889] for nodes' mobility and link variability.
>
>    Petrescu et al. proposed the joint IP networking and radio
>    architecture for V2V and V2I communication in [Joint-IP-Networking].
>    The proposed architecture considers an IP topology in a similar way
>    as a radio link topology, in the sense that an IP subnet would
>    correspond to the range of 1-hop vehicular communication.  This
>    architecture defines three types of vehicles: Leaf Vehicle, Range
>    Extending Vehicle, and Internet Vehicle.
>
>                                                     +----------------+
>                            (*)<........>(*)  +----->| Vehicular Cloud|
>           2001:DB8:1:1::/64 |            |   |      +----------------+
>    +------------------------------+  +---------------------------------+
>    |                        v     |  |   v   v                         |
>    | .-------. .------. .-------. |  | .-------. .------. .-------.    |
>    | | Host1 | |RDNSS1| |Router1| |  | |Router3| |RDNSS2| | Host3 |    |
>    | ._______. .______. ._______. |  | ._______. .______. ._______.    |
>    |     ^        ^         ^     |  |     ^         ^        ^        |
>    |     |        |         |     |  |     |         |        |        |
>    |     v        v         v     |  |     v         v        v        |
>    | ---------------------------- |  | ------------------------------- |
>    | 2001:DB8:10:1::/64 ^         |  |     ^ 2001:DB8:20:1::/64        |
>    |                    |         |  |     |                           |
>    |                    v         |  |     v                           |
>    | .-------.      .-------.     |  | .-------. .-------.   .-------. |
>    | | Host2 |      |Router2|     |  | |Router4| |Server1|...|ServerN| |
>    | ._______.      ._______.     |  | ._______. ._______.   ._______. |
>    |     ^              ^         |  |     ^         ^           ^     |
>    |     |              |         |  |     |         |           |     |
>    |     v              v         |  |     v         v           v     |
>    | ---------------------------- |  | ------------------------------- |
>    |  2001:DB8:10:2::/64          |  |       2001:DB8:20:2::/64        |
>    +______________________________+  +_________________________________+
>       Vehicle1 (Moving Network1)            RSU1 (Fixed Network1)
>
>       <----> Wired Link   <....> Wireless Link   (*) Antenna
>
>      Figure 2: Internetworking between Vehicle Network and RSU Network
>
> 4.2.1.1.  V2I-based Internetworking
>
>    This section discusses the internetworking between a vehicle's moving
>    network and an RSU's fixed network via V2I communication.
>
>    As shown in Figure 2, the vehicle's moving network and the RSU's
>    fixed network are self-contained networks having multiple subnets and
>
>
>
> Jeong                      Expires May 8, 2019                 [Page 13]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
>    having an edge router for the communication with another vehicle or
>    RSU.  The method of prefix assignment for each subnet inside the
>    vehicle's mobile network and the RSU's fixed network is out of scope
>    for this document.  Internetworking between two internal networks via
>    V2I communication requires an exchange of network prefix and other
>    parameters through a prefix discovery mechanism, such as ND-based
>    prefix discovery [ID-VND-Discovery].  For the ND-based prefix
>    discovery, network prefixs and parameters should be registered into a
>    vehicle's router and an RSU router with an external network interface
>    in advance.
>
>    The network parameter discovery collects networking information for
>    an IP communication between a vehicle and an RSU or between two
>    neighboring vehicles, such as link layer, MAC layer, and IP layer
>    information.  The link layer information includes wireless link layer
>    parameters, such as wireless media (e.g., IEEE 802.11-OCB, LTE Uu and
>    D2D, Bluetooth, and LiFi) and a transmission power level.  Note that
>    LiFi is a technology for light-based wireless communication between
>    devices in order to transmit both data and position.  The MAC layer
>    information includes the MAC address of an external network interface
>    for the internetworking with another vehicle or RSU.  The IP layer
>    information includes the IP address and prefix of an external network
>    interface for the internetworking with another vehicle or RSU.
>
>
> *[Sri] Why bring LiFi? We started with 802.11OCB, IPv6 for 802.11OCB and =
now we have entered LiFi space? Why?*
>
>    Once the network parameter discovery and prefix exchange operations
>    have been performed, packets can be transmitted between the vehicle's
>    moving network and the RSU's fixed network.  DNS services should be
>    supported to enable name resolution for hosts or servers residing
>    either in the vehicle's moving network or the RSU's fixed network.
>    It is assumed that the DNS names of in-vehicle devices and their
>    service names are registered into a DNS server (i.e., recursive DNS
>    server called RDNSS) in a vehicle or an RSU, as shown in Figure 2.
>    For service discovery, those DNS names and service names can be
>    advertised to neighboring vehicles through either DNS-based service
>    discovery mechanisms [RFC6762][RFC6763][ID-DNSNA] and ND-based
>    service discovery [ID-Vehicular-ND][ID-VND-Discovery].  For the ND-
>    based service discovery, service names should be registered into a
>    vehicle's router and an RSU router with an external network interface
>    in advance.  Refer to Section 4.1.5 and Section 4.1.6 for detailed
>    information.  For these DNS services, an RDNSS within each internal
>    network of a vehicle or RSU can be used for the hosts or servers.
>
>    Figure 2 shows internetworking between the vehicle's moving network
>    and the RSU's fixed network.  There exists an internal network
>    (Moving Network1) inside Vehicle1.  Vehicle1 has the DNS Server
>    (RDNSS1), the two hosts (Host1 and Host2), and the two routers
>    (Router1 and Router2).  There exists another internal network (Fixed
>    Network1) inside RSU1.  RSU1 has the DNS Server (RDNSS2), one host
>
>
>
> Jeong                      Expires May 8, 2019                 [Page 14]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
>    (Host3), the two routers (Router3 and Router4), and the collection of
>    servers (Server1 to ServerN) for various services in the road
>    networks, such as the emergency notification and navigation.
>    Vehicle1's Router1 (called mobile router) and RSU1's Router3 (called
>    fixed router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC)
>    for I2V networking.
>
>                            (*)<..........>(*)
>           2001:DB8:1:1::/64 |              |
>    +------------------------------+  +---------------------------------+
>    |                        v     |  |     v                           |
>    | .-------. .------. .-------. |  | .-------. .------. .-------.    |
>    | | Host1 | |RDNSS1| |Router1| |  | |Router5| |RDNSS3| | Host4 |    |
>    | ._______. .______. ._______. |  | ._______. .______. ._______.    |
>    |     ^        ^         ^     |  |     ^         ^        ^        |
>    |     |        |         |     |  |     |         |        |        |
>    |     v        v         v     |  |     v         v        v        |
>    | ---------------------------- |  | ------------------------------- |
>    | 2001:DB8:10:1::/64 ^         |  |     ^ 2001:DB8:30:1::/64        |
>    |                    |         |  |     |                           |
>    |                    v         |  |     v                           |
>    | .-------.      .-------.     |  | .-------.      .-------.        |
>    | | Host2 |      |Router2|     |  | |Router6|      | Host5 |        |
>    | ._______.      ._______.     |  | ._______.      ._______.        |
>    |     ^              ^         |  |     ^              ^            |
>    |     |              |         |  |     |              |            |
>    |     v              v         |  |     v              v            |
>    | ---------------------------- |  | ------------------------------- |
>    |  2001:DB8:10:2::/64          |  |       2001:DB8:30:2::/64        |
>    +______________________________+  +_________________________________+
>       Vehicle1 (Moving Network1)        Vehicle2 (Moving Network2)
>
>       <----> Wired Link   <....> Wireless Link   (*) Antenna
>
>           Figure 3: Internetworking between Two Vehicle Networks
>
> 4.2.1.2.  V2V-based Internetworking
>
>    This section discusses the internetworking between the moving
>    networks of two neighboring vehicles via V2V communication.
>
>    Figure 3 shows internetworking between the moving networks of two
>    neighboring vehicles.  There exists an internal network (Moving
>    Network1) inside Vehicle1.  Vehicle1 has the DNS Server (RDNSS1), the
>    two hosts (Host1 and Host2), and the two routers (Router1 and
>    Router2).  There exists another internal network (Moving Network2)
>    inside Vehicle2.  Vehicle2 has the DNS Server (RDNSS3), the two hosts
>    (Host4 and Host5), and the two routers (Router5 and Router6).
>
>
>
> Jeong                      Expires May 8, 2019                 [Page 15]
> =0C
> Internet-Draft          IPWAVE Problem Statement           November 2018
>
>
>    Vehicle1's Router1 (called mobile router) and Vehicle2's Router5
>    (called mobile router) use 2001:DB8:1:1::/64 for an external link
>    (e.g., DSRC) for V2V networking.
>
>    The differences between IPWAVE (including Vehicular Ad Hoc Networks
>    (VANET)) and Mobile Ad Hoc Networks (MANET) are as follows:
>
>    o  IPWAVE is not power-constrained operation;
>
>    o  Traffic can be sourced or sinked outside of IPWAVE;
>
>    o  IPWAVE shall support both distributed and centralized operations;
>
>    o  No "sleep" period operation is required for energy saving.
>
> [Sri] Why is this discussion needed? Why talk about AdHoc networks?
>
>
>
> 4.2.2.  Latency
>
>    The communication delay (i.e., latency) between two vehicular nodes
>    (vehicle and RSU) should be bounded to a certain threshold.  For IP-
>    based safety applications (e.g., context-aware navigation, adaptive
>    cruise control, and platooning) in vehicular network, this bounded
>    data delivery is critical.  The real implementations for such
>    applications are not available, so the feasibility of IP-based safety
>    applications is not tested yet.
>
>
> *[Sri] This is a good requirement. This is the right tone. You may want t=
o qualify further and put some additional latency considerations, goals bas=
ed on the use-cases. *
>
>
> 4.2.3.  Security
>
>    Strong security measures shall protect vehicles roaming in road
>    networks from the attacks of malicious nodes, which are controlled by
>    hackers.  For safety applications, the cooperation among vehicles is
>    assumed.  Malicious nodes may disseminate wrong driving information
>    (e.g., location, speed, and direction) to make driving be unsafe.
>    Sybil attack, which tries to illude a vehicle with multiple false
>    identities, disturbs a vehicle in taking a safe maneuver.
>    Applications on IP-based vehicular networking, which are resilient to
>    such a sybil attack, are not developed and tested yet.
>
> *[Sri] Please translate this to a specific  requirement. We want security=
 for sure and everywhere, not just in vehicular networks. What is new and w=
hats the new requirement? Identity? Please explain*
>
>
> 4.2.4.  Pseudonym Handling
>
>    For the protection of drivers' privacy, pseudonym for a vehicle's
>    network interface should be used, with the help of which the
>    interface's identifier can be changed periodically.  Such a pseudonym
>    affects an IPv6 address based on the network interface's identifier,
>    and a transport-layer (e.g., TCP) session with an IPv6 address pair.
>    The pseudonym handling is not implemented and tested yet for
>    applications on IP-based vehicular networking.
>
> *[Sri] This is about MAC address? *
>
> Jeong Expires May 8, 2019 [Page 16] Internet-Draft IPWAVE Problem
> Statement November 2018 5. Problem Exploration This section discusses key
> topics for IPWAVE WG, such as neighbor discovery, mobility management, an=
d
> security & privacy. 5.1. Neighbor Discovery Neighbor Discovery (ND)
> [RFC4861] is a core part of the IPv6 protocol suite. This section discuss=
es
> the need for modifying ND for use with vehicular networking (e.g., V2V,
> V2I, and V2X). The vehicles are moving fast within the communication
> coverage of a vehicular node (e.g., vehicle and RSU). The external wirele=
ss
> link between two vehicular nodes can be used for vehicular networking, as
> shown in Figure 2 and Figure 3. ND time-related parameters such as router
> lifetime and Neighbor Advertisement (NA) interval should be adjusted for
> high-speed vehicles and vehicle density. As vehicles move faster, the NA
> interval should decrease for the NA messages to reach the neighboring
> vehicles promptly. Also, as vehicle density is higher, the NA interval
> should increase for the NA messages to reduce collision probability with
> other NA messages. 5.1.1. Link Model IPv6 protocols work under certain
> assumptions for the link model that do not necessarily hold in a vehicula=
r
> wireless link [VIP-WAVE]. For instance, some IPv6 protocols assume symmet=
ry
> in the connectivity among neighboring interfaces. However, interference a=
nd
> different levels of transmission power may cause unidirectional links to
> appear in vehicular wireless links. As a result, a new vehicular link mod=
el
> is required for the vehicular wireless link. There is a relationship
> between a link and prefix, besides the different scopes that are expected
> from the link-local and global types of IPv6 addresses. In an IPv6 link, =
it
> is assumed that all interfaces which are configured with the same subnet
> prefix and with on-link bit set can communicate with each other on an IP
> link or extended IP links via ND proxy. Note that a subnet prefix can be
> used by spanning multiple links as a multi-link subnet [RFC6775]. Also,
> note that IPv6 Stateless Address Autoconfiguration can be performed in th=
e
> multiple links where each of them is not assigned with a unique subnet
> prefix, that is, all of them are configured with the same subnet prefix
> [RFC4861][RFC4862]. A vehicular link model needs to consider a multi-hop
> VANET over a multi-link subnet. Such a VANET is usually a multi-link subn=
et
> consisting of multiple vehicles interconnected by wireless communication
> range. Such a subnet has a highly dynamic topology over time due to node
> mobility. Jeong Expires May 8, 2019 [Page 17] Internet-Draft IPWAVE Probl=
em
> Statement November 2018 Thus, IPv6 ND should be extended into a Vehicular
> Neighbor Discovey (VND) [ID-Vehicular-ND] to support the concept of an IP=
v6
> link corresponding to an IPv6 prefix even in a multi-link subnet consisti=
ng
> of multiple vehicles and RSUs that are interconnected with wireless
> communication range in IP-based vehicular networks. 5.1.2. MAC Address
> Pseudonym In the ETSI standards, for the sake of security and privacy, an
> ITS station (e.g., vehicle) can use pseudonyms for its network interface
> identities (e.g., MAC address) and the corresponding IPv6 addresses
> [Identity-Management]. Whenever the network interface identifier changes,
> the IPv6 address based on the network interface identifier should be
> updated. For the continuity of an end-to-end (E2E) transport-layer (e.g.,
> TCP, UDP, and SCTP) session, with a mobility management scheme (e.g., MIP=
v6
> and PMIPv6), the new IP address for the transport-layer session should be
> notified to an appropriate end point, and the packets of the session shou=
ld
> be forwarded to their destinations with the changed network interface
> identifier and IPv6 address. 5.1.3. Prefix Dissemination/Exchange A vehic=
le
> and an RSU can have their internal network, as shown in Figure 2 and Figu=
re
> 3. In this case, nodes in within the internal networks of two vehicular
> nodes (e.g., vehicle and RSU) want to communicate with each other. For th=
is
> communication on the wireless link, the network prefix dissemination or
> exchange is required. It is assumed that a vehicular node has an external
> network interface and its internal network. The legacy IPv6 ND [RFC4861]
> needs to be extended to a vehicular ND (VND) [ID-Vehicular-ND] for the
> communication between the internal-network nodes (e.g., an in-vehicle
> device in a vehicle and a server in an RSU) of vehicular nodes by letting
> each of them know the other side's prefix with a new ND option
> [ID-VND-Discovery]. Thus, this ND extension for routing functionality can
> reduce control traffic for routing in vehicular networks without an
> additional vehicular ad hoc routing protocol [VANET-Geo-Routing]. 5.1.4.
> Routing For multihop V2V communications in a multi-link subnet (as a
> connected VANET), a vehicular ad hoc routing protocol (e.g., geographic
> routing) may be required to support both unicast and multicast in the lin=
ks
> of the subnet with the same IPv6 prefix [VANET-Geo-Routing]. Instead of t=
he
> vehicular ad hoc routing protocol, Vehicular ND along with a prefix
> discovery option can be used to let vehicles exchange their prefixes in a
> multihop fashion Jeong Expires May 8, 2019 [Page 18] Internet-Draft IPWAV=
E
> Problem Statement November 2018 [ID-Vehicular-ND][ID-VND-Discovery]. With
> the exchanged prefixes, they can compute their routing table (or IPv6 ND'=
s
> neighbor cache) for the multi-link subnet with a distance-vector algorith=
m
> [Intro-to-Algorithms]. Also, an efficient, rapid DAD should be supported =
to
> prevent or reduce IPv6 address conflicts in the multi- link subnet by usi=
ng
> a DAD optimization [ID-Vehicular-ND][RFC6775] or an IPv6
> geographic-routing-based address autoconfiguration [GeoSAC]. 5.2. Mobilit=
y
> Management The seamless connectivity and timely data exchange between two
> end points requires an efficient mobility management including location
> management and handover. Most of vehicles are equipped with a GPS receive=
r
> as part of a dedicated navigation system or a corresponding smartphone Ap=
p.
> In the case where the provided location information is precise enough,
> well-known temporary degradations in precision may occur due to system
> configuration or the adverse local environment. This precision is improve=
d
> thanks to assistance by the RSUs or a cellular system with this navigatio=
n
> system. With this GPS navigator, an efficient mobility management is
> possible by vehicles periodically reporting their current position and
> trajectory (i.e., navigation path) to RSUs and a Mobility Anchor (MA) in
> TCC. The RSUs and MA can predict the future positions of the vehicles wit=
h
> their mobility information (i.e., the current position, speed, direction,
> and trajectory) for the efficient mobility management (e.g., proactive
> handover). For a better proactive handover, link-layer parameters, such a=
s
> the signal strength of a link-layer frame (e.g., Received Channel Power
> Indicator (RCPI) [VIP-WAVE]), can be used to determine the moment of a
> handover between RSUs along with mobility information [ID-Vehicular-ND].
> With the prediction of the vehicle mobility, MA can support RSUs to perfo=
rm
> DAD, data packet routing, horizontal handover (i.e., handover in wireless
> links using a homogeneous radio technology), and vertical handover (i.e.,
> handover in wireless links using heterogeneous radio technologies) in a
> proactive manner. Even though a vehicle moves into the wireless link unde=
r
> another RSU belonging to a different subnet, the RSU can proactively
> perform the DAD for the sake of the vehicle, reducing IPv6 control traffi=
c
> overhead in the wireless link [ID-Vehicular-ND]. Therefore, with a
> proactive handover and a multihop DAD in vehicular networks
> [ID-Vehicular-ND], RSUs can efficiently forward data packets from the wir=
ed
> network (or the wireless network) to a moving destination vehicle along i=
ts
> trajectory along with the MA. Thus, a moving vehicle can communicate with
> its corresponding vehicle in the vehicular network or a host/server in th=
e
> Internet along its trajectory. Jeong Expires May 8, 2019 [Page 19]
> Internet-Draft IPWAVE Problem Statement November 2018 5.3. Security and
> Privacy Security and privacy are paramount in the V2I, V2V, and V2X
> networking in vehicular networks. Only authorized vehicles should be
> allowed to use vehicular networking. Also, in-vehicle devices and mobile
> devices in a vehicle need to communicate with other in-vehicle devices an=
d
> mobile devices in another vehicle, and other servers in an RSU in a secur=
e
> way. A Vehicle Identification Number (VIN) and a user certificate along
> with in-vehicle device's identifier generation can be used to efficiently
> authenticate a vehicle or a user through a road infrastructure node (e.g.=
,
> RSU) connected to an authentication server in TCC. Also, Transport Layer
> Security (TLS) certificates can be used for secure E2E vehicle
> communications. For secure V2I communication, a secure channel between a
> mobile router in a vehicle and a fixed router in an RSU should be
> established, as shown in Figure 2. Also, for secure V2V communication, a
> secure channel between a mobile router in a vehicle and a mobile router i=
n
> another vehicle should be established, as shown in Figure 3. To prevent a=
n
> adversary from tracking a vehicle with its MAC address or IPv6 address, M=
AC
> address pseudonym should be provided to the vehicle; that is, each vehicl=
e
> should periodically update its MAC address and the corresponding IPv6
> address as suggested in [RFC4086][RFC4941]. Such an update of the MAC and
> IPv6 addresses should not interrupt the E2E communications between two
> vehicular nodes (e.g., vehicle and RSU) in terms of transport layer for a
> long- living higher-layer session. However, if this pseudonym is performe=
d
> without strong E2E confidentiality, there will be no privacy benefit from
> changing MAC and IP addresses, because an adversary can see the change of
> the MAC and IP addresses and track the vehicle with those addresses. 6.
> Security Considerations This document discussed security and privacy for
> IP-based vehicular networking. The security and privacy for key component=
s
> in IP-based vehicular networking, such as neighbor discovery and mobility
> management, need to be analyzed in depth. Jeong Expires May 8, 2019 [Page
> 20] Internet-Draft IPWAVE Problem Statement November 2018 7. Informative
> References [Address-Assignment] Kato, T., Kadowaki, K., Koita, T., and K.
> Sato, "Routing and Address Assignment using Lane/Position Information in =
a
> Vehicular Ad-hoc Network", IEEE Asia-Pacific Services Computing Conferenc=
e,
> December 2008. [Address-Autoconf] Fazio, M., Palazzi, C., Das, S., and M.
> Gerla, "Automatic IP Address Configuration in VANETs", ACM International
> Workshop on Vehicular Inter-Networking, September 2016.
> [Automotive-Sensing] Choi, J., Va, V., Gonzalez-Prelcic, N., Daniels, R.,
> R. Bhat, C., and R. W. Heath, "Millimeter-Wave Vehicular Communication to
> Support Massive Automotive Sensing", IEEE Communications Magazine, Decemb=
er
> 2016. [Broadcast-Storm] Wisitpongphan, N., K. Tonguz, O., S. Parikh, J.,
> Mudalige, P., Bai, F., and V. Sadekar, "Broadcast Storm Mitigation
> Techniques in Vehicular Ad Hoc Networks", IEEE Wireless Communications,
> December 2007. [CA-Cruise-Control] California Partners for Advanced
> Transportation Technology (PATH), "Cooperative Adaptive Cruise Control",
> [Online] Available: http://www.path.berkeley.edu/research/automated-and-
> connected-vehicles/cooperative-adaptive-cruise-control, 2017. [CASD] Shen=
,
> Y., Jeong, J., Oh, T., and S. Son, "CASD: A Framework of Context-Awarenes=
s
> Safety Driving in Vehicular Networks", International Workshop on Device
> Centric Cloud (DC2), March 2016. [DSRC] ASTM International, "Standard
> Specification for Telecommunications and Information Exchange Between
> Roadside and Vehicle Systems - 5 GHz Band Dedicated Short Range
> Communications (DSRC) Medium Access Control (MAC) and Physical Layer (PHY=
)
> Specifications", ASTM E2213-03(2010), October 2010. Jeong Expires May 8,
> 2019 [Page 21] Internet-Draft IPWAVE Problem Statement November 2018
> [ETSI-GeoNetwork-IP] ETSI Technical Committee Intelligent Transport
> Systems, "Intelligent Transport Systems (ITS); Vehicular Communications;
> GeoNetworking; Part 6: Internet Integration; Sub-part 1: Transmission of
> IPv6 Packets over GeoNetworking Protocols", ETSI EN 302 636-6-1, October
> 2013. [ETSI-GeoNetworking] ETSI Technical Committee Intelligent Transport
> Systems, "Intelligent Transport Systems (ITS); Vehicular Communications;
> GeoNetworking; Part 4: Geographical addressing and forwarding for
> point-to-point and point-to- multipoint communications; Sub-part 1:
> Media-Independent Functionality", ETSI EN 302 636-4-1, May 2014.
> [EU-2008-671-EC] European Union, "Commission Decision of 5 August 2008 on
> the Harmonised Use of Radio Spectrum in the 5875 - 5905 MHz Frequency Ban=
d
> for Safety-related Applications of Intelligent Transport Systems (ITS)", =
EU
> 2008/671/EC, August 2008. [FirstNet] U.S. National Telecommunications and
> Information Administration (NTIA), "First Responder Network Authority
> (FirstNet)", [Online] Available: https://www.firstnet.gov/, 2012.
> [FirstNet-Report] First Responder Network Authority, "FY 2017: ANNUAL
> REPORT TO CONGRESS, Advancing Public Safety Broadband Communications",
> FirstNet FY 2017, December 2017. [Fuel-Efficient] van de Hoef, S., H.
> Johansson, K., and D. V. Dimarogonas, "Fuel-Efficient En Route Formation =
of
> Truck Platoons", IEEE Transactions on Intelligent Transportation Systems,
> January 2018. [GeoSAC] Baldessari, R., Bernardos, C., and M. Calderon,
> "GeoSAC - Scalable Address Autoconfiguration for VANET Using Geographic
> Networking Concepts", IEEE International Symposium on Personal, Indoor an=
d
> Mobile Radio Communications, September 2008. Jeong Expires May 8, 2019
> [Page 22] Internet-Draft IPWAVE Problem Statement November 2018 [H-DMM]
> Nguyen, T. and C. Bonnet, "A Hybrid Centralized- Distributed Mobility
> Management for Supporting Highly Mobile Users", IEEE International
> Conference on Communications, June 2015. [ID-DNSNA] Jeong, J., Ed., Lee,
> S., and J. Park, "DNS Name Autoconfiguration for Internet of Things
> Devices", draft- jeong-ipwave-iot-dns-autoconf-04 (work in progress),
> October 2018. [ID-Vehicular-ND] Xiang, Zhong., Jeong, J., Ed., and Y. She=
n,
> "IPv6 Neighbor Discovery for IP-Based Vehicular Networks", draft-xiang-
> ipwave-vehicular-neighbor-discovery-00 (work in progress), November 2018.
> [ID-VND-Discovery] Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and J. Le=
e,
> "IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular
> Networks", draft-jeong-ipwave-vehicular- neighbor-discovery-04 (work in
> progress), October 2018. [Identity-Management] Wetterwald, M., Hrizi, F.,
> and P. Cataldi, "Cross-layer Identities Management in ITS Stations", The
> 10th International Conference on ITS Telecommunications, November 2010.
> [IEEE-802.11-OCB] IEEE 802.11 Working Group, "Part 11: Wireless LAN Mediu=
m
> Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std
> 802.11-2016, December 2016. [IEEE-802.11p] IEEE 802.11 Working Group, "Pa=
rt
> 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
> Specifications - Amendment 6: Wireless Access in Vehicular Environments",
> IEEE Std 802.11p-2010, June 2010. [Intro-to-Algorithms] H. Cormen, T., E.
> Leiserson, C., L. Rivest, R., and C. Stein, "Introduction to Algorithms,
> 3rd ed.", The MIT Press, July 2009. Jeong Expires May 8, 2019 [Page 23]
> Internet-Draft IPWAVE Problem Statement November 2018 [IP-Passing-Protoco=
l]
> Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol for Vehicular Ad Ho=
c
> Networks with Network Fragmentation", Elsevier Computers & Mathematics wi=
th
> Applications, January 2012. [IPv6-over-802.11-OCB] Petrescu, A., Benamar,
> N., Haerri, J., Lee, J., and T. Ernst, "Transmission of IPv6 Packets over
> IEEE 802.11 Networks operating in mode Outside the Context of a Basic
> Service Set (IPv6-over-80211-OCB)", draft-ietf-ipwave-
> ipv6-over-80211ocb-30 (work in progress), September 2018. [IPv6-WAVE]
> Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6 Operation for WAVE -
> Wireless Access in Vehicular Environments", IEEE Vehicular Networking
> Conference, December 2010. [ISO-ITS-IPv6] ISO/TC 204, "Intelligent
> Transport Systems - Communications Access for Land Mobiles (CALM) - IPv6
> Networking", ISO 21210:2012, June 2012. [Joint-IP-Networking] Petrescu, A=
.,
> Boc, M., and C. Ibars, "Joint IP Networking and Radio Architecture for
> Vehicular Networks", 11th International Conference on ITS
> Telecommunications, August 2011. [LAGAD] Abrougui, K., Boukerche, A., and
> R. Pazzi, "Location-Aided Gateway Advertisement and Discovery Protocol fo=
r
> VANets", IEEE Transactions on Vehicular Technology, Vol. 59, No. 8, Octob=
er
> 2010. [Multicast-802] Perkins, C., Stanley, D., Kumari, W., and JC. Zunig=
a,
> "Multicast Considerations over IEEE 802 Wireless Media",
> draft-perkins-intarea-multicast-ieee802-03 (work in progress), July 2017.
> [Multicast-Alert] Camara, D., Bonnet, C., Nikaein, N., and M. Wetterwald,
> "Multicast and Virtual Road Side Units for Multi Technology Alert Message=
s
> Dissemination", IEEE 8th International Conference on Mobile Ad-Hoc and
> Sensor Systems, October 2011. Jeong Expires May 8, 2019 [Page 24]
> Internet-Draft IPWAVE Problem Statement November 2018 [NEMO-LMS] Soto, I.=
,
> Bernardos, C., Calderon, M., Banchs, A., and A. Azcorra, "NEMO-Enabled
> Localized Mobility Support for Internet Access in Automotive Scenarios",
> IEEE Communications Magazine, May 2009. [NEMO-VANET] Chen, Y., Hsu, C., a=
nd
> C. Cheng, "Network Mobility Protocol for Vehicular Ad Hoc Networks", Wile=
y
> International Journal of Communication Systems, November 2014.
> [PMIP-NEMO-Analysis] Lee, J., Ernst, T., and N. Chilamkurti, "Performance
> Analysis of PMIPv6-Based Network Mobility for Intelligent Transportation
> Systems", IEEE Transactions on Vehicular Technology, January 2012.
> [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness
> Requirements for Security", RFC 4086, June 2005. [RFC4861] Narten, T.,
> Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP
> Version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narte=
n,
> T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862,
> September 2007. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Priva=
cy
> Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941,
> September 2007. [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.=
,
> Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
> [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad Hoc
> Networks", RFC 5889, September 2010. [RFC5944] Perkins, C., Ed., "IP
> Mobility Support in IPv4, Revised", RFC 5944, November 2010. [RFC6275]
> Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6",
> RFC 6275, July 2011. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast
> DNS", RFC 6762, February 2013. Jeong Expires May 8, 2019 [Page 25]
> Internet-Draft IPWAVE Problem Statement November 2018 [RFC6763] Cheshire,
> S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 201=
3.
> [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
> "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Persona=
l
> Area Networks (6LoWPANs)", RFC 6775, November 2012. [RFC7333] Chan, H.,
> Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for
> Distributed Mobility Management", RFC 7333, August 2014. [RFC7429] Liu, D=
.,
> Zuniga, JC., Seite, P., Chan, H., and CJ. Bernardos, "Distributed Mobilit=
y
> Management: Current Practices and Gap Analysis", RFC 7429, January 2015.
> [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
> Specification", RFC 8200, July 2017. [SAINT] Jeong, J., Jeong, H., Lee, E=
.,
> Oh, T., and D. Du, "SAINT: Self-Adaptive Interactive Navigation Tool for
> Cloud-Based Vehicular Traffic Optimization", IEEE Transactions on Vehicul=
ar
> Technology, Vol. 65, No. 6, June 2016. [SAINTplus] Shen, Y., Lee, J.,
> Jeong, H., Jeong, J., Lee, E., and D. Du, "SAINT+: Self-Adaptive
> Interactive Navigation Tool+ for Emergency Service Delivery Optimization"=
,
> IEEE Transactions on Intelligent Transportation Systems, June 2017. [SANA=
]
> Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation Application for
> Pedestrian Protection in Vehicular Networks", Springer Lecture Notes in
> Computer Science (LNCS), Vol. 9502, December 2015. [SDN-DMM] Nguyen, T.,
> Bonnet, C., and J. Harri, "SDN-based Distributed Mobility Management for =
5G
> Networks", IEEE Wireless Communications and Networking Conference, April
> 2016. [Securing-VCOMM] Fernandez, P., Santa, J., Bernal, F., and A.
> Skarmeta, "Securing Vehicular IPv6 Communications", IEEE Transactions on
> Dependable and Secure Computing, January 2016. Jeong Expires May 8, 2019
> [Page 26] Internet-Draft IPWAVE Problem Statement November 2018
> [TR-22.886-3GPP] 3GPP, "Study on Enhancement of 3GPP Support for 5G V2X
> Services", 3GPP TS 22.886, June 2018. [Truck-Platooning] California
> Partners for Advanced Transportation Technology (PATH), "Automated Truck
> Platooning", [Online] Available:
> http://www.path.berkeley.edu/research/automated-and-
> connected-vehicles/truck-platooning, 2017. [TS-23.285-3GPP] 3GPP,
> "Architecture Enhancements for V2X Services", 3GPP TS 23.285, June 2018.
> [VANET-Geo-Routing] Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Golev=
a,
> M., and T. Ernst, "Experimental Evaluation for IPv6 over VANET Geographic
> Routing", IEEE International Wireless Communications and Mobile Computing
> Conference, June 2010. [VIP-WAVE] Cespedes, S., Lu, N., and X. Shen,
> "VIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular
> Networks", IEEE Transactions on Intelligent Transportation Systems, vol.
> 14, no. 1, March 2013. [VMaSC-LTE] Ucar, S., Ergen, S., and O. Ozkasap,
> "Multihop-Cluster- Based IEEE 802.11p and LTE Hybrid Architecture for VAN=
ET
> Safety Message Dissemination", IEEE Transactions on Vehicular Technology,
> April 2016. [VNET-AAA] Moustafa, H., Bourdon, G., and Y. Gourhant,
> "Providing Authentication and Access Control in Vehicular Network
> Environment", IFIP TC-11 International Information Security Conference, M=
ay
> 2006. [VNET-MM] Peng, Y. and J. Chang, "A Novel Mobility Management Schem=
e
> for Integration of Vehicular Ad Hoc Networks and Fixed IP Networks",
> Springer Mobile Networks and Applications, February 2010. [WAVE-1609.0]
> IEEE 1609 Working Group, "IEEE Guide for Wireless Access in Vehicular
> Environments (WAVE) - Architecture", IEEE Std 1609.0-2013, March 2014.
> Jeong Expires May 8, 2019 [Page 27] Internet-Draft IPWAVE Problem Stateme=
nt
> November 2018 [WAVE-1609.2] IEEE 1609 Working Group, "IEEE Standard for
> Wireless Access in Vehicular Environments - Security Services for
> Applications and Management Messages", IEEE Std 1609.2-2016, March 2016.
> [WAVE-1609.3] IEEE 1609 Working Group, "IEEE Standard for Wireless Access
> in Vehicular Environments (WAVE) - Networking Services", IEEE Std
> 1609.3-2016, April 2016. [WAVE-1609.4] IEEE 1609 Working Group, "IEEE
> Standard for Wireless Access in Vehicular Environments (WAVE) -
> Multi-Channel Operation", IEEE Std 1609.4-2016, March 2016. Jeong Expires
> May 8, 2019 [Page 28] Internet-Draft IPWAVE Problem Statement November 20=
18
> Appendix A. Relevant Topics to IPWAVE Working Group This section discusse=
s
> topics relevant to IPWAVE WG: (i) vehicle identity management; (ii)
> multihop V2X; (iii) multicast; (iv) DNS naming services and service
> discovery; (v) IPv6 over cellular networks. A.1. Vehicle Identity
> Management A vehicle can have multiple network interfaces using different
> access network technologies [Identity-Management]. These multiple network
> interfaces mean multiple identities. To identify a vehicle with multiple
> indenties, a Vehicle Identification Number (VIN) can be used as a globall=
y
> unique vehicle identifier. To support the seamless connectivity over the
> multiple identities, a cross-layer network architecture is required with
> vertical handover functionality [Identity-Management]. Also, an AAA servi=
ce
> for multiple identities should be provided to vehicles in an efficient wa=
y
> to allow horizontal handover as well as vertical handover; note that AAA
> stands for Authentication, Authorization, and Accounting. A.2. Multihop V=
2X
> Multihop packet forwarding among vehicles in 802.11-OCB mode shows an
> unfavorable performance due to the common known broadcast-storm problem
> [Broadcast-Storm]. This broadcast-storm problem can be mitigated by the
> coordination (or scheduling) of a cluster head in a connected VANET or an
> RSU in an intersection area, where the cluster head can work as a
> coodinator for the access to wireless channels. A.3. Multicast IP multica=
st
> in vehicular network environments is especially useful for various
> services. For instance, an automobile manufacturer can multicast a
> particular group/class/type of vehicles for service notification. As
> another example, a vehicle or an RSU can disseminate alert messages in a
> particular area [Multicast-Alert]. In general IEEE 802 wireless media, so=
me
> performance issues about multicast are found in [Multicast-802]. Since
> several procedures and functions based on IPv6 use multicast for
> control-plane messages, such as Neighbor Discovery (ND) and Service
> Discovery, [Multicast-802] describes that the ND process may fail due to
> unreliable wireless link, causing failure of the DAD process. Also, the
> Router Advertisement messages can be lost in multicasting. Jeong Expires
> May 8, 2019 [Page 29] Internet-Draft IPWAVE Problem Statement November 20=
18
> A.4. DNS Naming Services and Service Discovery When two vehicular nodes
> communicate with each other using the DNS name of the partner node, DNS
> naming service (i.e., DNS name resolution) is required. As shown in Figur=
e
> 2 and Figure 3, a recursive DNS server (RDNSS) within an internal network
> can perform such DNS name resolution for the sake of other vehicular node=
s.
> A service discovery service is required for an application in a vehicular
> node to search for another application or server in another vehicular nod=
e,
> which resides in either the same internal network or the other internal
> network. In V2I or V2V networking, as shown in Figure 2 and Figure 3, suc=
h
> a service discovery service can be provided by either DNS-based Service
> Discovery (DNS-SD) [RFC6763] with mDNS [RFC6762] or the vehicular ND with=
 a
> new option for service discovery [ID-Vehicular-ND][ID-VND-Discovery]. A.5=
.
> IPv6 over Cellular Networks Recently, 3GPP has announced a set of new
> technical specifications, such as Release 14 (3GPP-R14), which proposes a=
n
> architecture enhancements for V2X services using the modified sidelink
> interface that originally is designed for the LTE-D2D communications.
> 3GPP-R14 specifies that the V2X services only support IPv6 implementation=
.
> 3GPP is also investigating and discussing the evolved V2X services in the
> next generation cellular networks, i.e., 5G new radio (5G-NR), for advanc=
ed
> V2X communications and automated vehicles' applications. A.5.1. Cellular
> V2X (C-V2X) Using 4G-LTE Before 3GPP-R14, some researchers have studied t=
he
> potential usage of C-V2X communications. For example, [VMaSC-LTE] explore=
s
> a multihop cluster-based hybrid architecture using both DSRC and LTE for
> safety message dissemination. Most of the research considers a short
> message service for safety instead of IP datagram forwarding. In other
> C-V2X research, the standard IPv6 is assumed. The 3GPP technical
> specification [TS-23.285-3GPP] states that both IP based and non-IP based
> V2X messages are supported, and only IPv6 is supported for IP based
> messages. Moreover, [TS-23.285-3GPP] instructs that a UE autoconfigures a
> link-local IPv6 address by following [RFC4862], but without sending
> Neighbor Solicitation and Neighbor Advertisement messages for DAD. This i=
s
> because a unique prefix is allocated to each node by the 3GPP network, so
> the IPv6 addresses cannot be duplicate. Jeong Expires May 8, 2019 [Page 3=
0]
> Internet-Draft IPWAVE Problem Statement November 2018 A.5.2. Cellular V2X
> (C-V2X) Using 5G The emerging services, functions, and applications, whic=
h
> are developped in automotive industry, demand reliable and efficient
> communication infrastructure for road networks. Correspondingly, the
> support of enhanced V2X (eV2X)-based services by future converged and
> interoperable 5G systems is required. The 3GPP Technical Report
> [TR-22.886-3GPP] is studying new use cases and the corresponding service
> requirements for V2X (including V2V and V2I) using 5G in both
> infrastructure mode and the sidelink variations in the future. Appendix B=
.
> Changes from draft-ietf-ipwave-vehicular-networking-06 The following
> changes are made from draft-ietf-ipwave-vehicular- networking-06: o In
> Figure 1, a vehicular network architecture is modified to show a vehicula=
r
> link model in a multi-link subnet with vehicular wireless links. o In
> Section 5.1, a Vehicular Neighbor Discovery (VND) [ID-Vehicular-ND] is
> introduced along with a vehicular link model in a multi-link subnet. In
> such a subnet, the description of MAC Address Pseudonym, Prefix
> Dissemination/Exchange, and Routing is clarified. o In Section 5.2, a
> proactive handover is introduced for an efficient mobility management wit=
h
> the cooperation among vehicles, RSUs, and MA along with link-layer
> parameters, such as Received Channel Power Indicator (RCPI). Appendix C.
> Acknowledgments This work was supported by Basic Science Research Program
> through the National Research Foundation of Korea (NRF) funded by the
> Ministry of Education (2017R1D1A1B03035885). This work was supported in
> part by Global Research Laboratory Program through the NRF funded by the
> Ministry of Science and ICT (MSIT) (NRF-2013K1A1A2A02078326) and by the
> DGIST R&D Program of the MSIT (18-EE-01). This work was supported in part
> by the French research project DataTweet (ANR-13-INFR-0008) and in part b=
y
> the HIGHTS project funded by the European Commission I (636537-H2020).
> Jeong Expires May 8, 2019 [Page 31] Internet-Draft IPWAVE Problem Stateme=
nt
> November 2018 Appendix D. Contributors This document is a group work of
> IPWAVE working group, greatly benefiting from inputs and texts by Rex
> Buddenberg (Naval Postgraduate School), Thierry Ernst (YoGoKo), Bokor
> Laszlo (Budapest University of Technology and Economics), Jose Santa
> Lozanoi (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot=
),
> Sri Gundavelli (Cisco), Erik Nordmark, and Dirk von Hugo (Deutsche
> Telekom). The authors sincerely appreciate their contributions. The
> following are co-authors of this document: Nabil Benamar Department of
> Computer Sciences High School of Technology of Meknes Moulay Ismail
> University Morocco Phone: +212 6 70 83 22 36 EMail: benamar73@gmail.com
> Sandra Cespedes NIC Chile Research Labs Universidad de Chile Av. Blanco
> Encalada 1975 Santiago Chile Phone: +56 2 29784093 EMail:
> scespede@niclabs.cl Jerome Haerri Communication Systems Department
> EURECOM Sophia-Antipolis France Phone: +33 4 93 00 81 34 EMail:
> jerome.haerri@eurecom.fr Dapeng Liu Alibaba Beijing, Beijing 100022 China
> Jeong Expires May 8, 2019 [Page 32] Internet-Draft IPWAVE Problem Stateme=
nt
> November 2018 Phone: +86 13911788933 EMail: max.ldp@alibaba-inc.com Tae
> (Tom) Oh Department of Information Sciences and Technologies Rochester
> Institute of Technology One Lomb Memorial Drive Rochester, NY 14623-5603
> USA Phone: +1 585 475 7642 EMail: Tom.Oh@rit.edu Charles E. Perkins
> Futurewei Inc. 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +=
1
> 408 330 4586 EMail: charliep@computer.org Alexandre Petrescu CEA, LIST
> CEA Saclay Gif-sur-Yvette, Ile-de-France 91190 France Phone: +33169089223
> EMail: Alexandre.Petrescu@cea.fr Yiwen Chris Shen Department of Computer
> Science & Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu
> Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4106 Fax: +8=
2
> 31 290 7996 EMail: chrisshen@skku.edu URI:
> http://iotlab.skku.edu/people-chris-shen.php Jeong Expires May 8, 2019
> [Page 33] Internet-Draft IPWAVE Problem Statement November 2018 Michelle
> Wetterwald FBConsulting 21, Route de Luxembourg Wasserbillig, Luxembourg
> L-6633 Luxembourg EMail: Michelle.Wetterwald@gmail.com Author's Address
> Jaehoon Paul Jeong (editor) Department of Software Sungkyunkwan Universit=
y
> 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone=
:
> +82 31 299 4957 Fax: +82 31 290 7996 EMail: pauljeong@skku.edu URI:
> http://iotlab.skku.edu/people-jaehoon-jeong.php Jeong Expires May 8, 2019
> [Page 34]
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>

--0000000000000ce7460581208c08
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Sri for the review.

Authors, ple=
ase revise accordingly.

Thanks,

Carlos

On Tue, Feb 5, 2019 at 2:26 AM Sri Gundavelli (sgundave)=
 <sgundave@cisco.com> wrote=
:







Hey Paul,

Attached is my review.  Please s=
ee some inline comments. In my opinion, the document has thin line separati=
ng the problem description from the solution description. In many places, t=
he focus is more on the solution before explaining what the problem is.=C2=
=A0 I think you have an opportunity here to greatly simplify the document a=
nd keep it to the point.=C2=A0I hate to push you towards another revision, =
but in the current form this won=E2=80=99t pass IESG, IMO. The Gods in IESG=
 will send it back to the WG. I really think you can cut down the text by 5=
0% to 60%. As they say,  =E2=80=9Csome times,  less is more" :-)  Hope=
 this helps.

Cheers!
Sri

<=
/div>




--
IPWAVE Working Group                                       J. Jeong, Ed.
Internet-Draft                                   Sungkyunkwan University
Intended status: Informational                          November 4, 2018
Expires: May 8, 2019


IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement
                             and Use Cases
               draft-ietf-ipwave-vehicular-networking-07

Abstract

   This document discusses the problem statement and use cases on IP-
   based vehicular networks, which are considered a key component of
   Intelligent Transportation Systems (ITS). =C2=A0


[Sri] What is Key co=
mponent of ITS? Usecases? You may want to reword





"This document discusses the problem statement and use cases on IP-
   based vehicular networks for building Intelligent Transportation Systems (ITS). =C2=A0





The main scenarios of
   vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-
   infrastructure (V2I), and vehicle-to-everything (V2X) communications.
   First, this document surveys use cases using V2V, V2I, and V2X
   networking.  Second, it analyzes proposed protocols for IP-based
   vehicular networking and highlights the limitations and difficulties
   found on those protocols.  Third, it presents a problem exploration
   for key aspects in IP-based vehicular networking, such as IPv6
   Neighbor Discovery, Mobility Management, and Security & Privacy.  Fo=
r
   each key aspect, this document discusses a problem statement to
   evaluate the gap between the state-of-the-art techniques and
   requirements in IP-based vehicular networking.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 8, 2019.








Jeong                      Expires May 8, 2019                  [Page 1]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (htt=
ps://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  V2V . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  V2I . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  V2X . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Analysis for Existing Protocols . . . . . . . . . . . . . . .   8
     4.1.  Existing Protocols for Vehicular Networking . . . . . . .   8
       4.1.1.  IPv6 over 802.11-OCB  . . . . . . . . . . . . . . . .   8
       4.1.2.  IP Address Autoconfiguration  . . . . . . . . . . . .   8
       4.1.3.  Routing . . . . . . . . . . . . . . . . . . . . . . .   9
       4.1.4.  Mobility Management . . . . . . . . . . . . . . . . .   9
       4.1.5.  DNS Naming Service  . . . . . . . . . . . . . . . . .   9
       4.1.6.  Service Discovery . . . . . . . . . . . . . . . . . .   9
       4.1.7.  Security and Privacy  . . . . . . . . . . . . . . . .  10
     4.2.  General Problems  . . . . . . . . . . . . . . . . . . . .  10
       4.2.1.  Vehicular Network Architecture  . . . . . . . . . . .  11
       4.2.2.  Latency . . . . . . . . . . . . . . . . . . . . . . .  16
       4.2.3.  Security  . . . . . . . . . . . . . . . . . . . . . .  16
       4.2.4.  Pseudonym Handling  . . . . . . . . . . . . . . . . .  16
   5.  Problem Exploration . . . . . . . . . . . . . . . . . . . . .  17
     5.1.  Neighbor Discovery  . . . . . . . . . . . . . . . . . . .  17
       5.1.1.  Link Model  . . . . . . . . . . . . . . . . . . . . .  17
       5.1.2.  MAC Address Pseudonym . . . . . . . . . . . . . . . .  18
       5.1.3.  Prefix Dissemination/Exchange . . . . . . . . . . . .  18
       5.1.4.  Routing . . . . . . . . . . . . . . . . . . . . . . .  18
     5.2.  Mobility Management . . . . . . . . . . . . . . . . . . .  19
     5.3.  Security and Privacy  . . . . . . . . . . . . . . . . . .  20
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  21
   Appendix A.  Relevant Topics to IPWAVE Working Group  . . . . . .  29



Jeong                      Expires May 8, 2019                  [Page 2]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


     A.1.  Vehicle Identity Management . . . . . . . . . . . . . . .  29
     A.2.  Multihop V2X  . . . . . . . . . . . . . . . . . . . . . .  29
     A.3.  Multicast . . . . . . . . . . . . . . . . . . . . . . . .  29
     A.4.  DNS Naming Services and Service Discovery . . . . . . . .  30
     A.5.  IPv6 over Cellular Networks . . . . . . . . . . . . . . .  30
       A.5.1.  Cellular V2X (C-V2X) Using 4G-LTE . . . . . . . . . .  30
       A.5.2.  Cellular V2X (C-V2X) Using 5G . . . . . . . . . . . .  31
   Appendix B.  Changes from draft-ietf-ipwave-vehicular-
                networking-06  . . . . . . . . . . . . . . . . . . .  31
   Appendix C.  Acknowledgments  . . . . . . . . . . . . . . . . . .  31
   Appendix D.  Contributors . . . . . . . . . . . . . . . . . . . .  32
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  3=
4

1.  Introduction

   Vehicular networking studies have mainly focused on driving safety,
   driving efficiency, and entertainment in road networks. =C2=A0


[Sri] Rephrase, =E2=
=80=9Cfocused on driving safety, driving efficiency, and entertainment in r=
oad networks." 


To perhaps, =E2=80=
=9Cfocussed on improving safety, efficiency and enabling entertainment in v=
ehicular networks=E2=80=9D


The Federal
   Communications Commission (FCC) in the US allocated wireless channels
   for Dedicated Short-Range Communications (DSRC) [DSRC], service in
   the Intelligent Transportation Systems (ITS) Radio Service in the
   5.850 - 5.925 GHz band (5.9 GHz band).  DSRC-based wireless
   communications can support vehicle-to-vehicle (V2V), vehicle-to-
   infrastructure (V2I), and vehicle-to-everything (V2X) networking.
   Also, the European Union (EU) passed a decision to allocate radio
   spectrum for safety-related and non-safety-related applications of
   ITS with the frequency band of 5.875 - 5.905 GHz, which is called
   Commission Decision 2008/671/EC [EU-2008-671-EC].

   For direct inter-vehicular wireless connectivity, IEEE has amended
   WiFi standard 802.11 to enable driving safety services based on the
   DSRC in terms of standards for the Wireless Access in Vehicular
   Environments (WAVE) system.  L1 and L2 issues are addressed in IEEE

[Sri] Expand L1, L2<=
/font>





   802.11p [IEEE-802.11p] for the PHY and MAC of the DSRC, while IEEE
   1609.2 [WAVE-1609.2] covers security aspects, IEEE 1609.3
   [WAVE-1609.3] defines related services at network and transport
   layers, and IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel
   operation.  Note that IEEE 802.11p has been published as IEEE 802.11
   Outside the Context of a Basic Service Set (OCB) called IEEE
   802.11-OCB [IEEE-802.11-OCB] in 2012.


[Sr=
i] You may want to say, 802.11p was a separate standard, but was later enro=
lled into the base 802.11 standard, IEEE 802.11-2012


   Along with these WAVE standards, IPv6 [RFC8200] and Mobile IP
   protocols (e.g., MIPv4 [RFC5944] and MIPv6 [RFC6275]) can be applied
   (or easily modified) to vehicular networks. =C2=A0





[Sri] Since, you mentioned MIP4, MIP6, it will be =
incomplete if you don=E2=80=99t include PMIPv6 [RFC5213 and RFC5844]. Also,=
 to be consistent with my other comments, please r=
efer to them in the context of a problem. State the problem, say =E2=
=80=9Cmobility management=E2=80=9D, explai=
n the requirement and refer to existing IETF art, for addressing that probl=
em. 





In Europe, ETSI has
   standardized a GeoNetworking (GN) protocol [ETSI-GeoNetworking] and a
   protocol adaptation sub-layer from GeoNetworking to IPv6
   [ETSI-GeoNetwork-IP].  Note that a GN protocol is useful to route an
   event or notification message to vehicles around a geographic
   position, such as an acciendent area in a roadway.  In addition, ISO



Jeong                      Expires May 8, 2019                  [Page 3]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   has approved a standard specifying the IPv6 network protocols and
   services to be used for Communications Access for Land Mobiles (CALM)
   [ISO-ITS-IPv6].



[Sri] This is great =
information, but curious how it toes back to this document? Use of IP ?





   This document discusses problem statements and use cases related to
   IP-based vehicular networking for Intelligent Transportation Systems
   (ITS), which is denoted as IP Wireless Access in Vehicular
   Environments (IPWAVE).  First, it surveys the use cases for using
   V2V, V2I, and V2X networking in the ITS.  Second, for literature
   review, it analyzes proposed protocols for IP-based vehicular
   networking and highlights the limitations and difficulties found on
   those protocols.  Third, for problem statement, it presents a problem
   exploration with key aspects in IPWAVE, such as IPv6 Neighbor
   Discovery, Mobility Management, and Security & Privacy.  For each ke=
y
   aspect of the problem statement, it analyzes the gap between the
   state-of-the-art techniques and the requirements in IP-based
   vehicular networking.  It also discusses potential topics relevant to
   IPWAVE Working Group (WG), such as Vehicle Identities Management,
   Multihop V2X Communications, Multicast, DNS Naming Services, Service
   Discovery, and IPv6 over Cellular Networks.  Therefore, with the
   problem statement, this document will open a door to develop key
   protocols for IPWAVE that will be essential to IP-based vehicular
   networks.

2.  Terminology

   This document uses the following definitions:

   o  WAVE: Acronym for "Wireless Access in Vehicular Environments&quo=
t;
      [WAVE-1609.0].

   o  DMM: Acronym for "Distributed Mobility Management"
      [RFC7333][RFC7429].

   o  Road-Side Unit (RSU): A node that has physical communication
      devices (e.g., DSRC, Visible Light Communication, 802.15.4, LTE-
      V2X, etc.) for wireless communications with vehicles and is also
      connected to the Internet as a router or switch for packet
      forwarding.  An RSU is typically deployed on the road
      infrastructure, either at an intersection or in a road segment,
      but may also be located in car parking area.


[Sri] I would think =
DSRC and C-V2X are the only wireless systems currently defined for Vehicula=
r Communications, or at least the term RSU is used only by these systems. S=
o, I am not sure if we should mention 802.15.4 or Visible Light Communicati=
ons. Also, if you look at the OBU definition below, is there a OBU with vis=
ible light interface, so both the ends have to support the same scheme.=






   o  On-Board Unit (OBU): A node that has a DSRC device for wireless
      communications with other OBUs and RSUs, and may be connected to
      in-vehicle devices or networks.  An OBU is mounted on a vehicle.
      It is assumed that a radio navigation receiver (e.g., Global
      Positioning System (GPS)) is included in a vehicle with an OBU for
      efficient navigation.



Jeong                      Expires May 8, 2019                  [Page 4]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   o  Vehicle Detection Loop (or Loop Detector): An inductive device
      used for detecting vehicles passing or arriving at a certain
      point, for instance approaching a traffic light or in motorway
      traffic.  The relatively crude nature of the loop's structure
      means that only metal masses above a certain size are capable of
      triggering the detection.

   o  Mobility Anchor (MA): A node that maintains IP addresses and
      mobility information of vehicles in a road network to support the
      address autoconfiguration and mobility management of them.  It has
      end-to-end connections with RSUs under its control.  It maintains
      a DAD table having the IP addresses of the vehicles moving within
      the communication coverage of its RSUs.


[Sri] The last sente=
nce is pointing to a solution. MA may or may not maintain a DAD table. It m=
ay maintain a binding table like MIPv6 HA, or PMIPv6 LMA





   o  Vehicular Cloud: A cloud infrastructure for vehicular networks,
      having compute nodes, storage nodes, and network nodes.

   o  Traffic Control Center (TCC): A node that maintains road
      infrastructure information (e.g., RSUs, traffic signals, and loop
      detectors), vehicular traffic statistics (e.g., average vehicle
      speed and vehicle inter-arrival time per road segment), and
      vehicle information (e.g., a vehicle's identifier, position,
      direction, speed, and trajectory as a navigation path).  TCC is
      included in a vehicular cloud for vehicular networks.

3.  Use Cases

   This section provides use cases of V2V, V2I, and V2X networking.  The
   use cases of the V2X networking exclude the ones of the V2V and V2I
   networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to-
   Device (V2D).

3.1.  V2V

   The use cases of V2V networking discussed in this section include

   o  Context-aware navigation for driving safety and collision
      avoidance;

   o  Cooperative adaptive cruise control in an urban roadway;

   o  Platooning in a highway;

   o  Cooperative environment sensing.

   These four techniques will be important elements for self-driving
   Vehicles.





[Sri] I am not convi=
nced if this is a complete list, or how these items made it here.. 3GPP has=
 identified some use-cases, I wonder what is the delta between the two






Jeong                      Expires May 8, 2019                  [Page 5]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers
   to drive safely by letting the drivers recognize dangerous obstacles
   and situations.  That is, CASD navigator displays obstables or
   neighboring vehicles relevant to possible collisions in real-time
   through V2V networking.  CASD provides vehicles with a class-based
   automatic safety action plan, which considers three situations, such
   as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe and safe
   situations.  This action plan can be performed among vehicles through
   V2V networking.

   Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps
   vehicles to adapt their speed autonomously through V2V communication
   among vehicles according to the mobility of their predecessor and
   successor vehicles in an urban roadway or a highway.  CACC can help
   adjacent vehicles to efficiently adjust their speed in a cascade way
   through V2V networking.

   Platooning [Truck-Platooning] allows a series of vehicles (e.g.,
   trucks) to move together with a very short inter-distance.  Trucks
   can use V2V communication in addition to forward sensors in order to
   maintain constant clearance between two consecutive vehicles at very
   short gaps (from 3 meters to 10 meters).  This platooning can
   maximize the throughput of vehicular traffic in a highway and reduce
   the gas consumption because the leading vehicle can help the
   following vehicles to experience less air resistance.

   Cooperative-environment-sensing use cases suggest that vehicles can
   share environmental information from various vehicle-mounted sensors,
   such as radars, LiDARs and cameras with other vehicles and
   pedestrians.  [Automotive-Sensing] introduces a millimeter-wave
   vehicular communication for massive automotive sensing.  Data
   generated by those sensors can be substantially large, and these data
   shall be routed to different destinations.  In addition, from the
   perspective of driverless vehicles, it is expected that driverless
   vehicles can be mixed with driver-operated vehicles.  Through
   cooperative environment sensing, driver-operated vehicles can use
   environmental information sensed by driverless vehicles for better
   interaction with the context.

3.2.  V2I

   The use cases of V2I networking discussed in this section include

   o  Navigation service;

   o  Energy-efficient speed recommendation service;

   o  Accident notification service.



Jeong                      Expires May 8, 2019                  [Page 6]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   A navigation service, such as the Self-Adaptive Interactive
   Navigation Tool (called SAINT) [SAINT], using V2I networking
   interacts with TCC for the large-scale/long-range road traffic
   optimization and can guide individual vehicles for appropriate
   navigation paths in real time.  The enhanced SAINT (called SAINT+)
   [SAINTplus] can give the fast moving paths for emergency vehicles
   (e.g., ambulance and fire engine) toward accident spots while
   providing other vehicles with efficient detour paths.


[Sri] Is this a requ=
irement, or a description of some deployed service? 





   A TCC can recommend an energy-efficient speed to a vehicle driving in
   different traffic environments.  [Fuel-Efficient] studies fuel-
   efficient route and speed plans for platooned trucks.

   The emergency communication between accident vehicles (or emergency
   vehicles) and TCC can be performed via either RSU or 4G-LTE networks.
   The First Responder Network Authority (FirstNet) [FirstNet] is
   provided by the US government to establish, operate, and maintain an
   interoperable public safety broadband network for safety and security
   network services, such as emergency calls.  The construction of the
   nationwide FirstNet network requires each state in the US to have a
   Radio Access Network (RAN) that will connect to FirstNet's network
   core.  The current RAN is mainly constructed by 4G-LTE for the
   communication between a vehicle and an infrastructure node (i.e.,
   V2I) [FirstNet-Report], but it is expected that DSRC-based vehicular
   networks [DSRC] will be available for V2I and V2V in near future.

3.3.  V2X

   The use case of V2X networking discussed in this section is
   pedestrian protection service.

   A pedestrian protection service, such as Safety-Aware Navigation
   Application (called SANA) [SANA], using V2I2P networking can reduce
   the collision of a vehicle and a pedestrian carrying a smartphone
   equipped with the access technology with an RSU (e.g., WiFi).
   Vehicles and pedestrians can also communicate with each other via an
   RSU that delivers scheduling information for wireless communication
   in order to save the smartphones' battery through sleeping mode.

   For Vehicle-to-Pedestrian (V2P), a vehicle and a pedestrian's
   smartphone can directly communicate with each other via V2X without
   the relaying of an RSU as in a V2V scenario such that the
   pedestrian's smartphone is regarded as a vehicle with a wireless
   media interface to be able to communicate with another vehicle.  In
   Vehicle-to-Device (V2D), a device can be a mobile node such as
   bicycle and motorcycle, and can communicate directly with a vehicle
   for collision avoidance.




Jeong                      Expires May 8, 2019                  [Page 7]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


4.  Analysis for Existing Protocols

4.1.  Existing Protocols for Vehicular Networking

   We describe some currently existing protocols=
 and proposed solutions
   with respect to the following aspects that are relevant and essential
   for vehicular networking:

   o  IPv6 over 802.11-OCB;

   o  IP address autoconfiguration;

   o  Routing;





[Sri] Is Routing a p=
rotocol?  Are these protocols, or services ?

   o  Mobility management;

   o  DNS naming service;

   o  Service discovery;

   o  Security and privacy.





4.1.1.  IPv6 over 802.11-OCB

   For IPv6 packets transporting over IEEE 802.11-OCB,
   [IPv6-over-802.11-OCB] specifies several details, such as Maximum
   Transmission Unit (MTU), frame format, link-local address, address
   mapping for unicast and multicast, stateless autoconfiguration, and
   subnet structure.  Especially, an Ethernet Adaptation (EA) layer is
   in charge of transforming some parameters between IEEE 802.11 MAC
   layer and IPv6 network layer, which is located between IEEE
   802.11-OCB's logical link control layer and IPv6 network layer.




[Sri] But, what is t=
he point from the point of view of this spec? 


4.1.2.  IP Address Autoconfiguration

   For IP address autoconfiguration, Fazio et al. proposed a vehicular
   address configuration (VAC) scheme using DHCP where elected leader-
   vehicles provide unique identifiers for IP address configurations in
   vehicles [Address-Autoconf].  Kato et al. proposed an IPv6 address
   assignment scheme using lane and position information
   [Address-Assignment].  Baldessari et al. proposed an IPv6 scalable
   address autoconfiguration scheme called GeoSAC for vehicular networks
   [GeoSAC].  Wetterwald et al. conducted for heterogeneous vehicular
   networks (i.e., employing multiple access technologies) a
   comprehensive study of the cross-layer identities management, which
   constitutes a fundamental element of the ITS architecture
   [Identity-Management].




[Sri] The focus of t=
he document should be on the problem statement. We have departed from that =
and now we are talking solutions. I see this problem through out this spec.=






Jeong                      Expires May 8, 2019                  [Page 8]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


4.1.3.  Routing

   For routing, Tsukada et al. presented a work that aims at combining
   IPv6 networking and a Car-to-Car Network routing protocol (called
   C2CNet) proposed by the Car2Car Communication Consortium (C2C-CC),
   which is an architecture using a geographic routing protocol
   [VANET-Geo-Routing].  Abrougui et al. presented a gateway discovery
   scheme for VANET, called Location-Aided Gateway Advertisement and
   Discovery (LAGAD) mechanism [LAGAD].





[Sri] Again, the focus of the document should be =
on problem statement, not on solutions


4.1.4.  Mobility Management

   For mobility management, Chen et al. tackled the issue of network
   fragmentation in VANET environments [IP-Passing-Protocol] by
   proposing a protocol that can postpone the time to release IP
   addresses to the DHCP server and select a faster way to get the
   vehicle's new IP address, when the vehicle density is low or the
   speeds of vehicles are highly variable.  Nguyen et al. proposed a
   hybrid centralized-distributed mobility management called H-DMM to
   support highly mobile vehicles [H-DMM].  [NEMO-LMS] proposed an
   architecture to enable IP mobility for moving networks using a
   network-based mobility scheme based on PMIPv6.  Chen et al. proposed
   a network mobility protocol to reduce handoff delay and maintain
   Internet connectivity to moving vehicles in a highway [NEMO-VANET].
   Lee et al. proposed P-NEMO, which is a PMIPv6-based IP mobility
   management scheme to maintain the Internet connectivity at the
   vehicle as a mobile network, and provides a make-before-break
   mechanism when vehicles switch to a new access network
   [PMIP-NEMO-Analysis].  Peng et al. proposed a novel mobility
   management scheme for integration of VANET and fixed IP networks
   [VNET-MM].  Nguyen et al. extended their previous works on a
   vehicular adapted DMM considering a Software-Defined Networking (SDN)
   architecture [SDN-DMM].





[Sri] The focus of the document should on the pro=
blem statement, not on solutions. This platter of requirements are discrete=
 and not connecting back to a larger architecture. 


4.1.5.  DNS Naming Service

   For DNS naming service, Multicast DNS (mDNS) [RFC6762] allows devices
   in one-hop communication range to resolve each other's DNS name into
   the corresponding IP address in multicast.  DNS Name
   Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming service
   for Internet-of-Things (IoT) devices in a large-scale network.





=
[Sri] Sure, but our goal is to talk about the problems when using this in v=
ehicular context. I don=E2=80=99t see that discussion 







4.1.6.  Service Discovery

   To discover instances of a demanded service in vehicular networks,
   DNS-based Service Discovery (DNS-SD) [RFC6763] with either DNSNA
   [ID-DNSNA] or mDNS [RFC6762] provides vehicles with service discovery
   by using standard DNS queries.  Vehicular ND [ID-Vehicular-ND]



Jeong                      Expires May 8, 2019                  [Page 9]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   proposes an extension of IPv6 ND for the prefix and service discovery
   with new ND options [ID-VND-Discovery].  Note that a DNS query for
   service discovery is unicasted in DNSNA, but it is multicasted in
   both mDNS and Vehicular ND.





[Sri] We have now departed to from PS world, to Solution world. 

<=
/b>


4.1.7.  Security and Privacy

   For security and privacy, Fernandez et al. proposed a secure
   vehicular IPv6 communication scheme using Internet Key Exchange
   version 2 (IKEv2) and Internet Protocol Security (IPsec)
   [Securing-VCOMM].  Moustafa et al. proposed a security scheme
   providing authentication, authorization, and accounting (AAA)
   services in vehicular networks [VNET-AAA].


[Sri] I do not know if Fernandez et all, covered the problem descrip=
tion, but we should first talk about the problem before we talk about solut=
ion 


4.2.  General Problems

   This section describes a possible vehicular network architecture for
   V2V, V2I, and V2X communications.  Then it analyzes the limitations
   of the current protocols for vehicular networking.
































Jeong                      Expires May 8, 2019                 [Page 10]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


                     Traffic Control Center in Vehicular Cloud
                    *-----------------------------------------*
                   *                                           *
                  *             +----------------+              *
                 *              | Mobility Anchor|               *
                 *              +----------------+               *
                  *                      ^                      *
                   *                     |                     *
                    *--------------------v--------------------*
                    ^               ^                        ^
                    |               |                        |
+------------------ |  -------------|-------------+ +------------------+
|                   v               v             | |        v         |
|           +--------+  Ethernet   +--------+     | |    +--------+    |
|           |  RSU1  |<----------->|  RSU2  |<---------->|  RSU=
3  |    |
|           +--------+             +--------+     | |    +--------+    |
|           ^        ^                  ^         | |        ^         |
|           :        :                  :         | |        :         |
|       V2I :        : V2I          V2I :         | |    V2I :         |
|           v        v                  v         | |        v         |
|   +--------+      +--------+      +--------+    | |    +--------+    |
|   |Vehicle1|=3D=3D=3D>  |Vehicle2|=3D=3D=3D>  |Vehicle3|=3D=3D=3D&g=
t;| |    |Vehicle4|=3D=3D=3D>|
|   |        |<....>|        |<....>|        |    | |    |     =
   |    |
|   +--------+ V2V  +--------+ V2V  +--------+    | |    +--------+    |
|                                                 | |                  |
+-------------------------------------------------+ +------------------+
                      Subnet1                              Subnet2

   <----> Wired Link   <....> Wireless Link   =3D=3D=3D> Mov=
ing Direction

   Figure 1: A Vehicular Network Architecture for V2I and V2V Networking

4.2.1.  Vehicular Network Architecture

   Figure 1 shows a possible architecture for V2I and V2V networking in
   a road network.  It is assumed that RSUs as routers and vehicles with
   OBU have wireless media interfaces (e.g., IEEE 802.11-OCB, LTE Uu and
   Device-to-Device (D2D) (also known as PC5 [TS-23.285-3GPP]),
   Bluetooth, and Light Fidelity (Li-Fi)) for V2I and V2V communication.
   Also, it is assumed that such the wireless media interfaces are
   autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to
   support both V2V and V2I networking.  Three RSUs (RSU1, RSU2, and
   RSU3) are deployed in the road network and are connected to a
   Vehicular Cloud through the Internet.  A Traffic Control Center (TCC)
   is connected to the Vehicular Cloud for the management of RSUs and
   vehicles in the road network.  A Mobility Anchor (MA) is located in
   the TCC as its key component for the mobility management of vehicles.
   Two vehicles (Vehicle1 and Vehicle2) are wirelessly connected to



Jeong                      Expires May 8, 2019                 [Page 11]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   RSU1, and one vehicle (Vehicle3) is wirelessly connected to RSU2.
   The wireless networks of RSU1 and RSU2 belong to a multi-link subnet
   (denoted as Subnet1) with the same network prefix.  Thus, these three
   vehicles are within the same subnet.  On the other hand, another
   vehicle (Vehicle4) is wireless connected to RSU4, belonging to
   another subnet (denoted as Subnet2).  That is, the first three
   vehicles (i.e., Vehicle1, Vehicle2, and Vehicle3) and the last
   vehicle (i.e., Vehicle4) are located in the two different subnets.
   Vehicle1 can communicate with Vehicle2 via V2V communication, and
   Vehicle2 can communicate with Vehicle3 via V2V communication because
   they are within the same subnet along their IPv6 addresses, which are
   based on the same prefix.  On the other hand, Vehicle3 can
   communicate with Vehicle4 via RSU2 and RSU3 employing V2I (i.e.,
   V2I2V) communication because they are within the two different
   subnets along with their IPv6 addresses, which are based on the two
   different prefixes.

   In vehicular networks, unidirectional links exist and must be
   considered for wireless communications.  Also, in the vehicular
   networks, control plane must be separated from data plane for
   efficient mobility management and data forwarding using Software-
   Defined Networking (SDN) [SDN-DMM].  ID/Pseudonym change for privacy
   requires a lightweight DAD.  IP tunneling over the wireless link
   should be avoided for performance efficiency.  The mobility
   information of a mobile (e.g., vehicle-mounted) device through a GPS
   receiver in its vehicle, such as trajectory, position, speed, and
   direction, can be used by the mobile device and infrastructure nodes
   (e.g., TCC and RSU) for the accommodation of mobility-aware proactive
   protocols.  Vehicles can use the TCC as their Home Network having a
   home agent for mobility management as in MIPv6 [RFC6275] and Proxy
   Mobile IPv6 (PMIPv6) [RFC5213], so the TCC maintains the mobility
   information of vehicles for location management.

   Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for
   I2V and V2I networking [VIP-WAVE].  The standard WAVE does not
   support both seamless communications for Internet services and multi-
   hop communications between a vehicle and an infrastructure node
   (e.g., RSU), either.  To overcome these limitations of the standard
   WAVE, VIP-WAVE enhances the standard WAVE by the following three
   schemes: (i) an efficient mechanism for the IPv6 address assignment
   and DAD, (ii) on-demand IP mobility based on PMIPv6 [RFC5213], and
   (iii) one-hop and two-hop communications for I2V and V2I networking.

   Baccelli et al. provided an analysis of the operation of IPv6 as it
   has been described by the IEEE WAVE standards 1609 [IPv6-WAVE].  This
   analysis confirms that the use of the standard IPv6 protocol stack in
   WAVE is not sufficient.  It recommends that the IPv6 addressing




Jeong                      Expires May 8, 2019                 [Page 12]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   assignment should follow considerations for ad-hoc link models,
   defined in [RFC5889] for nodes' mobility and link variability.

   Petrescu et al. proposed the joint IP networking and radio
   architecture for V2V and V2I communication in [Joint-IP-Networking].
   The proposed architecture considers an IP topology in a similar way
   as a radio link topology, in the sense that an IP subnet would
   correspond to the range of 1-hop vehicular communication.  This
   architecture defines three types of vehicles: Leaf Vehicle, Range
   Extending Vehicle, and Internet Vehicle.

                                                    +----------------+
                           (*)<........>(*)  +----->| Vehicular Cl=
oud|
          2001:DB8:1:1::/64 |            |   |      +----------------+
   +------------------------------+  +---------------------------------+
   |                        v     |  |   v   v                         |
   | .-------. .------. .-------. |  | .-------. .------. .-------.    |
   | | Host1 | |RDNSS1| |Router1| |  | |Router3| |RDNSS2| | Host3 |    |
   | ._______. .______. ._______. |  | ._______. .______. ._______.    |
   |     ^        ^         ^     |  |     ^         ^        ^        |
   |     |        |         |     |  |     |         |        |        |
   |     v        v         v     |  |     v         v        v        |
   | ---------------------------- |  | ------------------------------- |
   | 2001:DB8:10:1::/64 ^         |  |     ^ 2001:DB8:20:1::/64        |
   |                    |         |  |     |                           |
   |                    v         |  |     v                           |
   | .-------.      .-------.     |  | .-------. .-------.   .-------. |
   | | Host2 |      |Router2|     |  | |Router4| |Server1|...|ServerN| |
   | ._______.      ._______.     |  | ._______. ._______.   ._______. |
   |     ^              ^         |  |     ^         ^           ^     |
   |     |              |         |  |     |         |           |     |
   |     v              v         |  |     v         v           v     |
   | ---------------------------- |  | ------------------------------- |
   |  2001:DB8:10:2::/64          |  |       2001:DB8:20:2::/64        |
   +______________________________+  +_________________________________+
      Vehicle1 (Moving Network1)            RSU1 (Fixed Network1)

      <----> Wired Link   <....> Wireless Link   (*) Antenna

     Figure 2: Internetworking between Vehicle Network and RSU Network

4.2.1.1.  V2I-based Internetworking

   This section discusses the internetworking between a vehicle's movin=
g
   network and an RSU's fixed network via V2I communication.

   As shown in Figure 2, the vehicle's moving network and the RSU's
   fixed network are self-contained networks having multiple subnets and



Jeong                      Expires May 8, 2019                 [Page 13]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   having an edge router for the communication with another vehicle or
   RSU.  The method of prefix assignment for each subnet inside the
   vehicle's mobile network and the RSU's fixed network is out of s=
cope
   for this document.  Internetworking between two internal networks via
   V2I communication requires an exchange of network prefix and other
   parameters through a prefix discovery mechanism, such as ND-based
   prefix discovery [ID-VND-Discovery].  For the ND-based prefix
   discovery, network prefixs and parameters should be registered into a
   vehicle's router and an RSU router with an external network interfac=
e
   in advance.

   The network parameter discovery collects networking information for
   an IP communication between a vehicle and an RSU or between two
   neighboring vehicles, such as link layer, MAC layer, and IP layer
   information.  The link layer information includes wireless link layer
   parameters, such as wireless media (e.g., IEEE 802.11-OCB, LTE Uu and
   D2D, Bluetooth, and LiFi) and a transmission power level.  Note that
   LiFi is a technology for light-based wireless communication between
   devices in order to transmit both data and position.  The MAC layer
   information includes the MAC address of an external network interface
   for the internetworking with another vehicle or RSU.  The IP layer
   information includes the IP address and prefix of an external network
   interface for the internetworking with another vehicle or RSU.





[Sri] Why bring LiFi? We started with 802.11OCB, IPv=
6 for 802.11OCB and now we have entered LiFi space? Why?


   Once the network parameter discovery and prefix exchange operations
   have been performed, packets can be transmitted between the vehicle'=
s
   moving network and the RSU's fixed network.  DNS services should be
   supported to enable name resolution for hosts or servers residing
   either in the vehicle's moving network or the RSU's fixed networ=
k.
   It is assumed that the DNS names of in-vehicle devices and their
   service names are registered into a DNS server (i.e., recursive DNS
   server called RDNSS) in a vehicle or an RSU, as shown in Figure 2.
   For service discovery, those DNS names and service names can be
   advertised to neighboring vehicles through either DNS-based service
   discovery mechanisms [RFC6762][RFC6763][ID-DNSNA] and ND-based
   service discovery [ID-Vehicular-ND][ID-VND-Discovery].  For the ND-
   based service discovery, service names should be registered into a
   vehicle's router and an RSU router with an external network interfac=
e
   in advance.  Refer to Section 4.1.5 and Section 4.1.6 for detailed
   information.  For these DNS services, an RDNSS within each internal
   network of a vehicle or RSU can be used for the hosts or servers.

   Figure 2 shows internetworking between the vehicle's moving network
   and the RSU's fixed network.  There exists an internal network
   (Moving Network1) inside Vehicle1.  Vehicle1 has the DNS Server
   (RDNSS1), the two hosts (Host1 and Host2), and the two routers
   (Router1 and Router2).  There exists another internal network (Fixed
   Network1) inside RSU1.  RSU1 has the DNS Server (RDNSS2), one host



Jeong                      Expires May 8, 2019                 [Page 14]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   (Host3), the two routers (Router3 and Router4), and the collection of
   servers (Server1 to ServerN) for various services in the road
   networks, such as the emergency notification and navigation.
   Vehicle1's Router1 (called mobile router) and RSU1's Router3 (ca=
lled
   fixed router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC)
   for I2V networking.

                           (*)<..........>(*)
          2001:DB8:1:1::/64 |              |
   +------------------------------+  +---------------------------------+
   |                        v     |  |     v                           |
   | .-------. .------. .-------. |  | .-------. .------. .-------.    |
   | | Host1 | |RDNSS1| |Router1| |  | |Router5| |RDNSS3| | Host4 |    |
   | ._______. .______. ._______. |  | ._______. .______. ._______.    |
   |     ^        ^         ^     |  |     ^         ^        ^        |
   |     |        |         |     |  |     |         |        |        |
   |     v        v         v     |  |     v         v        v        |
   | ---------------------------- |  | ------------------------------- |
   | 2001:DB8:10:1::/64 ^         |  |     ^ 2001:DB8:30:1::/64        |
   |                    |         |  |     |                           |
   |                    v         |  |     v                           |
   | .-------.      .-------.     |  | .-------.      .-------.        |
   | | Host2 |      |Router2|     |  | |Router6|      | Host5 |        |
   | ._______.      ._______.     |  | ._______.      ._______.        |
   |     ^              ^         |  |     ^              ^            |
   |     |              |         |  |     |              |            |
   |     v              v         |  |     v              v            |
   | ---------------------------- |  | ------------------------------- |
   |  2001:DB8:10:2::/64          |  |       2001:DB8:30:2::/64        |
   +______________________________+  +_________________________________+
      Vehicle1 (Moving Network1)        Vehicle2 (Moving Network2)

      <----> Wired Link   <....> Wireless Link   (*) Antenna

          Figure 3: Internetworking between Two Vehicle Networks

4.2.1.2.  V2V-based Internetworking

   This section discusses the internetworking between the moving
   networks of two neighboring vehicles via V2V communication.

   Figure 3 shows internetworking between the moving networks of two
   neighboring vehicles.  There exists an internal network (Moving
   Network1) inside Vehicle1.  Vehicle1 has the DNS Server (RDNSS1), the
   two hosts (Host1 and Host2), and the two routers (Router1 and
   Router2).  There exists another internal network (Moving Network2)
   inside Vehicle2.  Vehicle2 has the DNS Server (RDNSS3), the two hosts
   (Host4 and Host5), and the two routers (Router5 and Router6).



Jeong                      Expires May 8, 2019                 [Page 15]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   Vehicle1's Router1 (called mobile router) and Vehicle2's Router5
   (called mobile router) use 2001:DB8:1:1::/64 for an external link
   (e.g., DSRC) for V2V networking.

   The differences between IPWAVE (including Vehicular Ad Hoc Networks
   (VANET)) and Mobile Ad Hoc Networks (MANET) are as follows:

   o  IPWAVE is not power-constrained operation;

   o  Traffic can be sourced or sinked outside of IPWAVE;

   o  IPWAVE shall support both distributed and centralized operations;

   o  No "sleep" period operation is required for energy saving.



[Sri] Why is this discussion needed? Why talk about AdH=
oc networks? 








4.2.2.  Latency

   The communication delay (i.e., latency) between two vehicular nodes
   (vehicle and RSU) should be bounded to a certain threshold.  For IP-
   based safety applications (e.g., context-aware navigation, adaptive
   cruise control, and platooning) in vehicular network, this bounded
   data delivery is critical.  The real implementations for such
   applications are not available, so the feasibility of IP-based safety
   applications is not tested yet.





[Sri] This is a good requirement. This is the right =
tone. You may want to qualify further and put some additional latency consi=
derations, goals based on the use-cases. 





4.2.3.  Security

   Strong security measures shall protect vehicles roaming in road
   networks from the attacks of malicious nodes, which are controlled by
   hackers.  For safety applications, the cooperation among vehicles is
   assumed.  Malicious nodes may disseminate wrong driving information
   (e.g., location, speed, and direction) to make driving be unsafe.
   Sybil attack, which tries to illude a vehicle with multiple false
   identities, disturbs a vehicle in taking a safe maneuver.
   Applications on IP-based vehicular networking, which are resilient to
   such a sybil attack, are not developed and tested yet.


[Sri] Please translate this to a specific  requireme=
nt. We want security for sure and everywhere, not just in vehicular network=
s. What is new and whats the new requirement? Identity? Please explain<=
/font>





4.2.4.  Pseudonym Handling

   For the protection of drivers' privacy, pseudonym for a vehicle'=
s
   network interface should be used, with the help of which the
   interface's identifier can be changed periodically.  Such a pseudony=
m
   affects an IPv6 address based on the network interface's identifier,
   and a transport-layer (e.g., TCP) session with an IPv6 address pair.
   The pseudonym handling is not implemented and tested yet for
   applications on IP-based vehicular networking.



[Sri] This is about MAC address? 




Jeong                      Expires May 8, 2019                 [Page 16]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


5.  Problem Exploration

   This section discusses key topics for IPWAVE WG, such as neighbor
   discovery, mobility management, and security & privacy.

5.1.  Neighbor Discovery

   Neighbor Discovery (ND) [RFC4861] is a core part of the IPv6 protocol
   suite.  This section discusses the need for modifying ND for use with
   vehicular networking (e.g., V2V, V2I, and V2X).  The vehicles are
   moving fast within the communication coverage of a vehicular node
   (e.g., vehicle and RSU).  The external wireless link between two
   vehicular nodes can be used for vehicular networking, as shown in
   Figure 2 and Figure 3.

   ND time-related parameters such as router lifetime and Neighbor
   Advertisement (NA) interval should be adjusted for high-speed
   vehicles and vehicle density.  As vehicles move faster, the NA
   interval should decrease for the NA messages to reach the neighboring
   vehicles promptly.  Also, as vehicle density is higher, the NA
   interval should increase for the NA messages to reduce collision
   probability with other NA messages.

5.1.1.  Link Model

   IPv6 protocols work under certain assumptions for the link model that
   do not necessarily hold in a vehicular wireless link [VIP-WAVE].  For
   instance, some IPv6 protocols assume symmetry in the connectivity
   among neighboring interfaces.  However, interference and different
   levels of transmission power may cause unidirectional links to appear
   in vehicular wireless links.  As a result, a new vehicular link model
   is required for the vehicular wireless link.

   There is a relationship between a link and prefix, besides the
   different scopes that are expected from the link-local and global
   types of IPv6 addresses.  In an IPv6 link, it is assumed that all
   interfaces which are configured with the same subnet prefix and with
   on-link bit set can communicate with each other on an IP link or
   extended IP links via ND proxy.  Note that a subnet prefix can be
   used by spanning multiple links as a multi-link subnet [RFC6775].
   Also, note that IPv6 Stateless Address Autoconfiguration can be
   performed in the multiple links where each of them is not assigned
   with a unique subnet prefix, that is, all of them are configured with
   the same subnet prefix [RFC4861][RFC4862].  A vehicular link model
   needs to consider a multi-hop VANET over a multi-link subnet.  Such a
   VANET is usually a multi-link subnet consisting of multiple vehicles
   interconnected by wireless communication range.  Such a subnet has a
   highly dynamic topology over time due to node mobility.



Jeong                      Expires May 8, 2019                 [Page 17]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   Thus, IPv6 ND should be extended into a Vehicular Neighbor Discovey
   (VND) [ID-Vehicular-ND] to support the concept of an IPv6 link
   corresponding to an IPv6 prefix even in a multi-link subnet
   consisting of multiple vehicles and RSUs that are interconnected with
   wireless communication range in IP-based vehicular networks.

5.1.2.  MAC Address Pseudonym

   In the ETSI standards, for the sake of security and privacy, an ITS
   station (e.g., vehicle) can use pseudonyms for its network interface
   identities (e.g., MAC address) and the corresponding IPv6 addresses
   [Identity-Management].  Whenever the network interface identifier
   changes, the IPv6 address based on the network interface identifier
   should be updated.  For the continuity of an end-to-end (E2E)
   transport-layer (e.g., TCP, UDP, and SCTP) session, with a mobility
   management scheme (e.g., MIPv6 and PMIPv6), the new IP address for
   the transport-layer session should be notified to an appropriate end
   point, and the packets of the session should be forwarded to their
   destinations with the changed network interface identifier and IPv6
   address.

5.1.3.  Prefix Dissemination/Exchange

   A vehicle and an RSU can have their internal network, as shown in
   Figure 2 and Figure 3.  In this case, nodes in within the internal
   networks of two vehicular nodes (e.g., vehicle and RSU) want to
   communicate with each other.  For this communication on the wireless
   link, the network prefix dissemination or exchange is required.  It
   is assumed that a vehicular node has an external network interface
   and its internal network.  The legacy IPv6 ND [RFC4861] needs to be
   extended to a vehicular ND (VND) [ID-Vehicular-ND] for the
   communication between the internal-network nodes (e.g., an in-vehicle
   device in a vehicle and a server in an RSU) of vehicular nodes by
   letting each of them know the other side's prefix with a new ND
   option [ID-VND-Discovery].  Thus, this ND extension for routing
   functionality can reduce control traffic for routing in vehicular
   networks without an additional vehicular ad hoc routing protocol
   [VANET-Geo-Routing].

5.1.4.  Routing

   For multihop V2V communications in a multi-link subnet (as a
   connected VANET), a vehicular ad hoc routing protocol (e.g.,
   geographic routing) may be required to support both unicast and
   multicast in the links of the subnet with the same IPv6 prefix
   [VANET-Geo-Routing].  Instead of the vehicular ad hoc routing
   protocol, Vehicular ND along with a prefix discovery option can be
   used to let vehicles exchange their prefixes in a multihop fashion



Jeong                      Expires May 8, 2019                 [Page 18]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [ID-Vehicular-ND][ID-VND-Discovery].  With the exchanged prefixes,
   they can compute their routing table (or IPv6 ND's neighbor cache)
   for the multi-link subnet with a distance-vector algorithm
   [Intro-to-Algorithms].  Also, an efficient, rapid DAD should be
   supported to prevent or reduce IPv6 address conflicts in the multi-
   link subnet by using a DAD optimization [ID-Vehicular-ND][RFC6775] or
   an IPv6 geographic-routing-based address autoconfiguration [GeoSAC].

5.2.  Mobility Management

   The seamless connectivity and timely data exchange between two end
   points requires an efficient mobility management including location
   management and handover.  Most of vehicles are equipped with a GPS
   receiver as part of a dedicated navigation system or a corresponding
   smartphone App.  In the case where the provided location information
   is precise enough, well-known temporary degradations in precision may
   occur due to system configuration or the adverse local environment.
   This precision is improved thanks to assistance by the RSUs or a
   cellular system with this navigation system.  With this GPS
   navigator, an efficient mobility management is possible by vehicles
   periodically reporting their current position and trajectory (i.e.,
   navigation path) to RSUs and a Mobility Anchor (MA) in TCC.  The RSUs
   and MA can predict the future positions of the vehicles with their
   mobility information (i.e., the current position, speed, direction,
   and trajectory) for the efficient mobility management (e.g.,
   proactive handover).  For a better proactive handover, link-layer
   parameters, such as the signal strength of a link-layer frame (e.g.,
   Received Channel Power Indicator (RCPI) [VIP-WAVE]), can be used to
   determine the moment of a handover between RSUs along with mobility
   information [ID-Vehicular-ND].

   With the prediction of the vehicle mobility, MA can support RSUs to
   perform DAD, data packet routing, horizontal handover (i.e., handover
   in wireless links using a homogeneous radio technology), and vertical
   handover (i.e., handover in wireless links using heterogeneous radio
   technologies) in a proactive manner.  Even though a vehicle moves
   into the wireless link under another RSU belonging to a different
   subnet, the RSU can proactively perform the DAD for the sake of the
   vehicle, reducing IPv6 control traffic overhead in the wireless link
   [ID-Vehicular-ND].

   Therefore, with a proactive handover and a multihop DAD in vehicular
   networks [ID-Vehicular-ND], RSUs can efficiently forward data packets
   from the wired network (or the wireless network) to a moving
   destination vehicle along its trajectory along with the MA.  Thus, a
   moving vehicle can communicate with its corresponding vehicle in the
   vehicular network or a host/server in the Internet along its
   trajectory.



Jeong                      Expires May 8, 2019                 [Page 19]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


5.3.  Security and Privacy

   Security and privacy are paramount in the V2I, V2V, and V2X
   networking in vehicular networks.  Only authorized vehicles should be
   allowed to use vehicular networking.  Also, in-vehicle devices and
   mobile devices in a vehicle need to communicate with other in-vehicle
   devices and mobile devices in another vehicle, and other servers in
   an RSU in a secure way.

   A Vehicle Identification Number (VIN) and a user certificate along
   with in-vehicle device's identifier generation can be used to
   efficiently authenticate a vehicle or a user through a road
   infrastructure node (e.g., RSU) connected to an authentication server
   in TCC.  Also, Transport Layer Security (TLS) certificates can be
   used for secure E2E vehicle communications.

   For secure V2I communication, a secure channel between a mobile
   router in a vehicle and a fixed router in an RSU should be
   established, as shown in Figure 2.  Also, for secure V2V
   communication, a secure channel between a mobile router in a vehicle
   and a mobile router in another vehicle should be established, as
   shown in Figure 3.

   To prevent an adversary from tracking a vehicle with its MAC address
   or IPv6 address, MAC address pseudonym should be provided to the
   vehicle; that is, each vehicle should periodically update its MAC
   address and the corresponding IPv6 address as suggested in
   [RFC4086][RFC4941].  Such an update of the MAC and IPv6 addresses
   should not interrupt the E2E communications between two vehicular
   nodes (e.g., vehicle and RSU) in terms of transport layer for a long-
   living higher-layer session.  However, if this pseudonym is performed
   without strong E2E confidentiality, there will be no privacy benefit
   from changing MAC and IP addresses, because an adversary can see the
   change of the MAC and IP addresses and track the vehicle with those
   addresses.

6.  Security Considerations

   This document discussed security and privacy for IP-based vehicular
   networking.

   The security and privacy for key components in IP-based vehicular
   networking, such as neighbor discovery and mobility management, need
   to be analyzed in depth.







Jeong                      Expires May 8, 2019                 [Page 20]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


7.  Informative References

   [Address-Assignment]
              Kato, T., Kadowaki, K., Koita, T., and K. Sato, "Routing
              and Address Assignment using Lane/Position Information in
              a Vehicular Ad-hoc Network", IEEE Asia-Pacific Services
              Computing Conference, December 2008.

   [Address-Autoconf]
              Fazio, M., Palazzi, C., Das, S., and M. Gerla, "Automati=
c
              IP Address Configuration in VANETs", ACM International
              Workshop on Vehicular Inter-Networking, September 2016.

   [Automotive-Sensing]
              Choi, J., Va, V., Gonzalez-Prelcic, N., Daniels, R., R.
              Bhat, C., and R. W. Heath, "Millimeter-Wave Vehicular
              Communication to Support Massive Automotive Sensing",
              IEEE Communications Magazine, December 2016.

   [Broadcast-Storm]
              Wisitpongphan, N., K. Tonguz, O., S. Parikh, J., Mudalige,
              P., Bai, F., and V. Sadekar, "Broadcast Storm Mitigation
              Techniques in Vehicular Ad Hoc Networks", IEEE Wireless
              Communications, December 2007.

   [CA-Cruise-Control]
              California Partners for Advanced Transportation Technology
              (PATH), "Cooperative Adaptive Cruise Control", [Onl=
ine]
              Available:
              http://www.path.berkeley.edu/research/automated-and-<=
/a>
              connected-vehicles/cooperative-adaptive-cruise-control,
              2017.

   [CASD]     Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A
              Framework of Context-Awareness Safety Driving in Vehicular
              Networks", International Workshop on Device Centric Clou=
d
              (DC2), March 2016.

   [DSRC]     ASTM International, "Standard Specification for
              Telecommunications and Information Exchange Between
              Roadside and Vehicle Systems - 5 GHz Band Dedicated Short
              Range Communications (DSRC) Medium Access Control (MAC)
              and Physical Layer (PHY) Specifications",
              ASTM E2213-03(2010), October 2010.







Jeong                      Expires May 8, 2019                 [Page 21]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [ETSI-GeoNetwork-IP]
              ETSI Technical Committee Intelligent Transport Systems,
              "Intelligent Transport Systems (ITS); Vehicular
              Communications; GeoNetworking; Part 6: Internet
              Integration; Sub-part 1: Transmission of IPv6 Packets over
              GeoNetworking Protocols", ETSI EN 302 636-6-1, October
              2013.

   [ETSI-GeoNetworking]
              ETSI Technical Committee Intelligent Transport Systems,
              "Intelligent Transport Systems (ITS); Vehicular
              Communications; GeoNetworking; Part 4: Geographical
              addressing and forwarding for point-to-point and point-to-
              multipoint communications; Sub-part 1: Media-Independent
              Functionality", ETSI EN 302 636-4-1, May 2014.

   [EU-2008-671-EC]
              European Union, "Commission Decision of 5 August 2008 on
              the Harmonised Use of Radio Spectrum in the 5875 - 5905
              MHz Frequency Band for Safety-related Applications of
              Intelligent Transport Systems (ITS)", EU 2008/671/EC,
              August 2008.

   [FirstNet]
              U.S. National Telecommunications and Information
              Administration (NTIA), "First Responder Network Authorit=
y
              (FirstNet)", [Online]
              Available: https://www.firstnet.gov/, 2012.

   [FirstNet-Report]
              First Responder Network Authority, "FY 2017: ANNUAL REPO=
RT
              TO CONGRESS, Advancing Public Safety Broadband
              Communications", FirstNet FY 2017, December 2017.

   [Fuel-Efficient]
              van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas,
              "Fuel-Efficient En Route Formation of Truck Platoons&quo=
t;,
              IEEE Transactions on Intelligent Transportation Systems,
              January 2018.

   [GeoSAC]   Baldessari, R., Bernardos, C., and M. Calderon, "GeoSAC =
-
              Scalable Address Autoconfiguration for VANET Using
              Geographic Networking Concepts", IEEE International
              Symposium on Personal, Indoor and Mobile Radio
              Communications, September 2008.






Jeong                      Expires May 8, 2019                 [Page 22]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [H-DMM]    Nguyen, T. and C. Bonnet, "A Hybrid Centralized-
              Distributed Mobility Management for Supporting Highly
              Mobile Users", IEEE International Conference on
              Communications, June 2015.

   [ID-DNSNA]
              Jeong, J., Ed., Lee, S., and J. Park, "DNS Name
              Autoconfiguration for Internet of Things Devices", draft=
-
              jeong-ipwave-iot-dns-autoconf-04 (work in progress),
              October 2018.

   [ID-Vehicular-ND]
              Xiang, Zhong., Jeong, J., Ed., and Y. Shen, "IPv6 Neighb=
or
              Discovery for IP-Based Vehicular Networks", draft-xiang-
              ipwave-vehicular-neighbor-discovery-00 (work in progress),
              November 2018.

   [ID-VND-Discovery]
              Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and J. Lee,
              "IPv6 Neighbor Discovery for Prefix and Service Discover=
y
              in Vehicular Networks", draft-jeong-ipwave-vehicular-
              neighbor-discovery-04 (work in progress), October 2018.

   [Identity-Management]
              Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer
              Identities Management in ITS Stations", The 10th
              International Conference on ITS Telecommunications,
              November 2010.

   [IEEE-802.11-OCB]
              IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium
              Access Control (MAC) and Physical Layer (PHY)
              Specifications", IEEE Std 802.11-2016, December 2016.

   [IEEE-802.11p]
              IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium
              Access Control (MAC) and Physical Layer (PHY)
              Specifications - Amendment 6: Wireless Access in Vehicular
              Environments", IEEE Std 802.11p-2010, June 2010.

   [Intro-to-Algorithms]
              H. Cormen, T., E. Leiserson, C., L. Rivest, R., and C.
              Stein, "Introduction to Algorithms, 3rd ed.", The
              MIT Press, July 2009.







Jeong                      Expires May 8, 2019                 [Page 23]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [IP-Passing-Protocol]
              Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol fo=
r
              Vehicular Ad Hoc Networks with Network Fragmentation",
              Elsevier Computers & Mathematics with Applications,
              January 2012.

   [IPv6-over-802.11-OCB]
              Petrescu, A., Benamar, N., Haerri, J., Lee, J., and T.
              Ernst, "Transmission of IPv6 Packets over IEEE 802.11
              Networks operating in mode Outside the Context of a Basic
              Service Set (IPv6-over-80211-OCB)", draft-ietf-ipwave-
              ipv6-over-80211ocb-30 (work in progress), September 2018.

   [IPv6-WAVE]
              Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6
              Operation for WAVE - Wireless Access in Vehicular
              Environments", IEEE Vehicular Networking Conference,
              December 2010.

   [ISO-ITS-IPv6]
              ISO/TC 204, "Intelligent Transport Systems -
              Communications Access for Land Mobiles (CALM) - IPv6
              Networking", ISO 21210:2012, June 2012.

   [Joint-IP-Networking]
              Petrescu, A., Boc, M., and C. Ibars, "Joint IP Networkin=
g
              and Radio Architecture for Vehicular Networks",
              11th International Conference on ITS Telecommunications,
              August 2011.

   [LAGAD]    Abrougui, K., Boukerche, A., and R. Pazzi, "Location-Aid=
ed
              Gateway Advertisement and Discovery Protocol for VANets"=
,
              IEEE Transactions on Vehicular Technology, Vol. 59, No. 8,
              October 2010.

   [Multicast-802]
              Perkins, C., Stanley, D., Kumari, W., and JC. Zuniga,
              "Multicast Considerations over IEEE 802 Wireless Media&q=
uot;,
              draft-perkins-intarea-multicast-ieee802-03 (work in
              progress), July 2017.

   [Multicast-Alert]
              Camara, D., Bonnet, C., Nikaein, N., and M. Wetterwald,
              "Multicast and Virtual Road Side Units for Multi
              Technology Alert Messages Dissemination", IEEE 8th
              International Conference on Mobile Ad-Hoc and Sensor
              Systems, October 2011.




Jeong                      Expires May 8, 2019                 [Page 24]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [NEMO-LMS]
              Soto, I., Bernardos, C., Calderon, M., Banchs, A., and A.
              Azcorra, "NEMO-Enabled Localized Mobility Support for
              Internet Access in Automotive Scenarios",
              IEEE Communications Magazine, May 2009.

   [NEMO-VANET]
              Chen, Y., Hsu, C., and C. Cheng, "Network Mobility
              Protocol for Vehicular Ad Hoc Networks",
              Wiley International Journal of Communication Systems,
              November 2014.

   [PMIP-NEMO-Analysis]
              Lee, J., Ernst, T., and N. Chilamkurti, "Performance
              Analysis of PMIPv6-Based Network Mobility for Intelligent
              Transportation Systems", IEEE Transactions on Vehicular
              Technology, January 2012.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", RFC 4086, J=
une
              2005.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4=
861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, August 2008.

   [RFC5889]  Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
              Hoc Networks", RFC 5889, September 2010.

   [RFC5944]  Perkins, C., Ed., "IP Mobility Support in IPv4, Revised&=
quot;,
              RFC 5944, November 2010.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, July 2011.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC =
6762,
              February 2013.



Jeong                      Expires May 8, 2019                 [Page 25]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, February 2013.

   [RFC6775]  Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
              "Neighbor Discovery Optimization for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
              November 2012.

   [RFC7333]  Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
              "Requirements for Distributed Mobility Management",
              RFC 7333, August 2014.

   [RFC7429]  Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ.
              Bernardos, "Distributed Mobility Management: Current
              Practices and Gap Analysis", RFC 7429, January 2015.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 8200, July 2017.

   [SAINT]    Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT=
:
              Self-Adaptive Interactive Navigation Tool for Cloud-Based
              Vehicular Traffic Optimization", IEEE Transactions on
              Vehicular Technology, Vol. 65, No. 6, June 2016.

   [SAINTplus]
              Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D.
              Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+
              for Emergency Service Delivery Optimization",
              IEEE Transactions on Intelligent Transportation Systems,
              June 2017.

   [SANA]     Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation
              Application for Pedestrian Protection in Vehicular
              Networks", Springer Lecture Notes in Computer Science
              (LNCS), Vol. 9502, December 2015.

   [SDN-DMM]  Nguyen, T., Bonnet, C., and J. Harri, "SDN-based
              Distributed Mobility Management for 5G Networks",
              IEEE Wireless Communications and Networking Conference,
              April 2016.

   [Securing-VCOMM]
              Fernandez, P., Santa, J., Bernal, F., and A. Skarmeta,
              "Securing Vehicular IPv6 Communications",
              IEEE Transactions on Dependable and Secure Computing,
              January 2016.





Jeong                      Expires May 8, 2019                 [Page 26]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [TR-22.886-3GPP]
              3GPP, "Study on Enhancement of 3GPP Support for 5G V2X
              Services", 3GPP TS 22.886, June 2018.

   [Truck-Platooning]
              California Partners for Advanced Transportation Technology
              (PATH), "Automated Truck Platooning", [Online] Avai=
lable:
              http://www.path.berkeley.edu/research/automated-and-<=
/a>
              connected-vehicles/truck-platooning, 2017.

   [TS-23.285-3GPP]
              3GPP, "Architecture Enhancements for V2X Services",=
 3GPP
              TS 23.285, June 2018.

   [VANET-Geo-Routing]
              Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Goleva,
              M., and T. Ernst, "Experimental Evaluation for IPv6 over
              VANET Geographic Routing", IEEE International Wireless
              Communications and Mobile Computing Conference, June 2010.

   [VIP-WAVE]
              Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the
              Feasibility of IP Communications in 802.11p Vehicular
              Networks", IEEE Transactions on Intelligent Transportati=
on
              Systems, vol. 14, no. 1, March 2013.

   [VMaSC-LTE]
              Ucar, S., Ergen, S., and O. Ozkasap, "Multihop-Cluster-
              Based IEEE 802.11p and LTE Hybrid Architecture for VANET
              Safety Message Dissemination", IEEE Transactions on
              Vehicular Technology, April 2016.

   [VNET-AAA]
              Moustafa, H., Bourdon, G., and Y. Gourhant, "Providing
              Authentication and Access Control in Vehicular Network
              Environment", IFIP TC-11 International Information
              Security Conference, May 2006.

   [VNET-MM]  Peng, Y. and J. Chang, "A Novel Mobility Management Sche=
me
              for Integration of Vehicular Ad Hoc Networks and Fixed IP
              Networks", Springer Mobile Networks and Applications,
              February 2010.

   [WAVE-1609.0]
              IEEE 1609 Working Group, "IEEE Guide for Wireless Access
              in Vehicular Environments (WAVE) - Architecture", IEEE S=
td
              1609.0-2013, March 2014.




Jeong                      Expires May 8, 2019                 [Page 27]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   [WAVE-1609.2]
              IEEE 1609 Working Group, "IEEE Standard for Wireless
              Access in Vehicular Environments - Security Services for
              Applications and Management Messages", IEEE Std
              1609.2-2016, March 2016.

   [WAVE-1609.3]
              IEEE 1609 Working Group, "IEEE Standard for Wireless
              Access in Vehicular Environments (WAVE) - Networking
              Services", IEEE Std 1609.3-2016, April 2016.

   [WAVE-1609.4]
              IEEE 1609 Working Group, "IEEE Standard for Wireless
              Access in Vehicular Environments (WAVE) - Multi-Channel
              Operation", IEEE Std 1609.4-2016, March 2016.




































Jeong                      Expires May 8, 2019                 [Page 28]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


Appendix A.  Relevant Topics to IPWAVE Working Group

   This section discusses topics relevant to IPWAVE WG: (i) vehicle
   identity management; (ii) multihop V2X; (iii) multicast; (iv) DNS
   naming services and service discovery; (v) IPv6 over cellular
   networks.

A.1.  Vehicle Identity Management

   A vehicle can have multiple network interfaces using different access
   network technologies [Identity-Management].  These multiple network
   interfaces mean multiple identities.  To identify a vehicle with
   multiple indenties, a Vehicle Identification Number (VIN) can be used
   as a globally unique vehicle identifier.

   To support the seamless connectivity over the multiple identities, a
   cross-layer network architecture is required with vertical handover
   functionality [Identity-Management].  Also, an AAA service for
   multiple identities should be provided to vehicles in an efficient
   way to allow horizontal handover as well as vertical handover; note
   that AAA stands for Authentication, Authorization, and Accounting.

A.2.  Multihop V2X

   Multihop packet forwarding among vehicles in 802.11-OCB mode shows an
   unfavorable performance due to the common known broadcast-storm
   problem [Broadcast-Storm].  This broadcast-storm problem can be
   mitigated by the coordination (or scheduling) of a cluster head in a
   connected VANET or an RSU in an intersection area, where the cluster
   head can work as a coodinator for the access to wireless channels.

A.3.  Multicast

   IP multicast in vehicular network environments is especially useful
   for various services.  For instance, an automobile manufacturer can
   multicast a particular group/class/type of vehicles for service
   notification.  As another example, a vehicle or an RSU can
   disseminate alert messages in a particular area [Multicast-Alert].

   In general IEEE 802 wireless media, some performance issues about
   multicast are found in [Multicast-802].  Since several procedures and
   functions based on IPv6 use multicast for control-plane messages,
   such as Neighbor Discovery (ND) and Service Discovery,
   [Multicast-802] describes that the ND process may fail due to
   unreliable wireless link, causing failure of the DAD process.  Also,
   the Router Advertisement messages can be lost in multicasting.





Jeong                      Expires May 8, 2019                 [Page 29]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


A.4.  DNS Naming Services and Service Discovery

   When two vehicular nodes communicate with each other using the DNS
   name of the partner node, DNS naming service (i.e., DNS name
   resolution) is required.  As shown in Figure 2 and Figure 3, a
   recursive DNS server (RDNSS) within an internal network can perform
   such DNS name resolution for the sake of other vehicular nodes.

   A service discovery service is required for an application in a
   vehicular node to search for another application or server in another
   vehicular node, which resides in either the same internal network or
   the other internal network.  In V2I or V2V networking, as shown in
   Figure 2 and Figure 3, such a service discovery service can be
   provided by either DNS-based Service Discovery (DNS-SD) [RFC6763]
   with mDNS [RFC6762] or the vehicular ND with a new option for service
   discovery [ID-Vehicular-ND][ID-VND-Discovery].

A.5.  IPv6 over Cellular Networks

   Recently, 3GPP has announced a set of new technical specifications,
   such as Release 14 (3GPP-R14), which proposes an architecture
   enhancements for V2X services using the modified sidelink interface
   that originally is designed for the LTE-D2D communications. 3GPP-R14
   specifies that the V2X services only support IPv6 implementation.
   3GPP is also investigating and discussing the evolved V2X services in
   the next generation cellular networks, i.e., 5G new radio (5G-NR),
   for advanced V2X communications and automated vehicles' applications=
.

A.5.1.  Cellular V2X (C-V2X) Using 4G-LTE

   Before 3GPP-R14, some researchers have studied the potential usage of
   C-V2X communications.  For example, [VMaSC-LTE] explores a multihop
   cluster-based hybrid architecture using both DSRC and LTE for safety
   message dissemination.  Most of the research considers a short
   message service for safety instead of IP datagram forwarding.  In
   other C-V2X research, the standard IPv6 is assumed.

   The 3GPP technical specification [TS-23.285-3GPP] states that both IP
   based and non-IP based V2X messages are supported, and only IPv6 is
   supported for IP based messages.  Moreover, [TS-23.285-3GPP]
   instructs that a UE autoconfigures a link-local IPv6 address by
   following [RFC4862], but without sending Neighbor Solicitation and
   Neighbor Advertisement messages for DAD.  This is because a unique
   prefix is allocated to each node by the 3GPP network, so the IPv6
   addresses cannot be duplicate.






Jeong                      Expires May 8, 2019                 [Page 30]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


A.5.2.  Cellular V2X (C-V2X) Using 5G

   The emerging services, functions, and applications, which are
   developped in automotive industry, demand reliable and efficient
   communication infrastructure for road networks.  Correspondingly, the
   support of enhanced V2X (eV2X)-based services by future converged and
   interoperable 5G systems is required.  The 3GPP Technical Report
   [TR-22.886-3GPP] is studying new use cases and the corresponding
   service requirements for V2X (including V2V and V2I) using 5G in both
   infrastructure mode and the sidelink variations in the future.

Appendix B.  Changes from draft-ietf-ipwave-vehicular-networking-06

   The following changes are made from draft-ietf-ipwave-vehicular-
   networking-06:

   o  In Figure 1, a vehicular network architecture is modified to show
      a vehicular link model in a multi-link subnet with vehicular
      wireless links.

   o  In Section 5.1, a Vehicular Neighbor Discovery (VND)
      [ID-Vehicular-ND] is introduced along with a vehicular link model
      in a multi-link subnet.  In such a subnet, the description of MAC
      Address Pseudonym, Prefix Dissemination/Exchange, and Routing is
      clarified.

   o  In Section 5.2, a proactive handover is introduced for an
      efficient mobility management with the cooperation among vehicles,
      RSUs, and MA along with link-layer parameters, such as Received
      Channel Power Indicator (RCPI).

Appendix C.  Acknowledgments

   This work was supported by Basic Science Research Program through the
   National Research Foundation of Korea (NRF) funded by the Ministry of
   Education (2017R1D1A1B03035885).

   This work was supported in part by Global Research Laboratory Program
   through the NRF funded by the Ministry of Science and ICT (MSIT)
   (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT
   (18-EE-01).

   This work was supported in part by the French research project
   DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded
   by the European Commission I (636537-H2020).






Jeong                      Expires May 8, 2019                 [Page 31]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


Appendix D.  Contributors

   This document is a group work of IPWAVE working group, greatly
   benefiting from inputs and texts by Rex Buddenberg (Naval
   Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest
   University of Technology and Economics), Jose Santa Lozanoi
   (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot),
   Sri Gundavelli (Cisco), Erik Nordmark, and Dirk von Hugo (Deutsche
   Telekom).  The authors sincerely appreciate their contributions.

   The following are co-authors of this document:

   Nabil Benamar
   Department of Computer Sciences
   High School of Technology of Meknes
   Moulay Ismail University
   Morocco

   Phone: +212 6 70 83 22 36
   EMail: benamar7=
3@gmail.com


   Sandra Cespedes
   NIC Chile Research Labs
   Universidad de Chile
   Av.  Blanco Encalada 1975
   Santiago
   Chile


   Phone: +56 2 29784093
   EMail: scespede=
@niclabs.cl


   Jerome Haerri
   Communication Systems Department
   EURECOM
   Sophia-Antipolis
   France

   Phone: +33 4 93 00 81 34
   EMail: jer=
ome.haerri@eurecom.fr


   Dapeng Liu
   Alibaba
   Beijing, Beijing 100022
   China



Jeong                      Expires May 8, 2019                 [Page 32]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   Phone: +86 13911788933
   EMail: max.=
ldp@alibaba-inc.com


   Tae (Tom) Oh
   Department of Information Sciences and Technologies
   Rochester Institute of Technology
   One Lomb Memorial Drive
   Rochester, NY 14623-5603
   USA

   Phone: +1 585 475 7642
   EMail: Tom.Oh@rit.ed=
u


   Charles E.  Perkins
   Futurewei Inc.
   2330 Central Expressway
   Santa Clara, CA 95050
   USA

   Phone: +1 408 330 4586
   EMail: charli=
ep@computer.org


   Alexandre Petrescu
   CEA, LIST
   CEA Saclay
   Gif-sur-Yvette, Ile-de-France 91190
   France

   Phone: +33169089223
   EMail: Al=
exandre.Petrescu@cea.fr


   Yiwen Chris Shen
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do 16419
   Republic of Korea

   Phone: +82 31 299 4106
   Fax: +82 31 290 7996
   EMail: chrisshen=
@skku.edu
   URI: http://iotlab.skku.edu/people-chris-shen.php





Jeong                      Expires May 8, 2019                 [Page 33]
=0C
Internet-Draft          IPWAVE Problem Statement           November 2018


   Michelle Wetterwald
   FBConsulting
   21, Route de Luxembourg
   Wasserbillig, Luxembourg L-6633
   Luxembourg

   EMail: Michelle.Wetterwald@gmail.com


Author's Address

   Jaehoon Paul Jeong (editor)
   Department of Software
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 31 299 4957
   Fax:   +82 31 290 7996
   EMail: pauljeong=
@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php





























Jeong                      Expires May 8, 2019                 [Page 34]





_______________________________________________

its mailing list

its@ietf.org

https://www.ietf.org/mailman/listinfo/its




--0000000000000ce7460581208c08--


From nobody Tue Feb  5 07:46:39 2019
Return-Path: 
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 80099131124; Tue,  5 Feb 2019 07:46:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 cfT49sZnn9S7; Tue,  5 Feb 2019 07:46:33 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 117861310F6; Tue,  5 Feb 2019 07:46:33 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id y8so4171784wmi.4; Tue, 05 Feb 2019 07:46:32 -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=pOZJd6r2LU7ujdq3qen5UemVs5QnXfxNlTwDXki0k6Y=; b=mW2Tj3RoPGPaCzQluZUXu4WC3Zp+UWNd95xO/5f0m4sApUNQFcPh4tQMPTffq1Eg4B fOgZWxzPQ8QXC8eiKA2vDeH5V6+IaAf+1y60njux0ZE/soNLuv8IqYQ2YhiYnruZ3lSf s8ZSqVNrjOjmwCwyGtT95cMKDwj0SkS375Dc/7gflNemkKXccAY6WrSi6dDsN0Kb59Bu ve/ZT/LGU6VV5aSZkzTOxBh4GFgr/HV3Uj7xXdX4eRjvPFrQCVmkRQteTJRgTYabj6+R xGVcgrR22dysoZnYRf94lBSmD+pCLJTtb8yuCXm6KGfZJ/pc0WBRpEyfFwNJm+XFVHcv gISg==
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=pOZJd6r2LU7ujdq3qen5UemVs5QnXfxNlTwDXki0k6Y=; b=U/z+WUI4jVuMO2DCYGcdm7vvaI52k9qcF+cvSk9Q39vZtc6PjjKpLACWrhXedInnYs /G1IIp9sZXPQAmqC2/Nek3AJvDxirEmGfhp49tDfyxedOKwleE/ctvtrNCtGUfKBdgLm KJ5nTcOEIdBQw7c6X7vEZGNzdkiqSH1me/a5tiCQ0Zr6/bvQ1HK1AEyt3Dogacaeud5r wDq1ZA+W+/GmmyLm2uaitKY0BLcvI83YMnaeTmhBxZVfqlD61tOBT4pjWarI3MP74hMO ewX1DkzUUg/oNXg3H+RhOBR1uVnZvbNJza/AKcIboxuG/iGAejOt1dRgQkKQlEia52ti NRYA==
X-Gm-Message-State: AHQUAuYRiHURzqNRRFcqYfXBM0KzeKalyoAcFrVWk0zYxLWt+y+tDzPB CdQxcYgR2CeZEm88aCpJ5JoL3LkPQWL8/E+ivd4=
X-Google-Smtp-Source: AHgI3Ib49oH0DBXtpHVl7s1gU4IvoleWmfBsYr+K/zgnzGvzacSCYezNvmQkWvLO1vLwaNdaR3+vwTc5A3cj7iYzxWA=
X-Received: by 2002:a1c:7409:: with SMTP id p9mr4405463wmc.136.1549381591153;  Tue, 05 Feb 2019 07:46:31 -0800 (PST)
MIME-Version: 1.0
References:   <12ee3e17-fcb6-cf9d-425b-5eb3bd0130bb@earthlink.net> <09a8ba4a-dc3b-1f96-96af-7923f950a909@earthlink.net>  
In-Reply-To: 
From: "Mr. Jaehoon Paul Jeong" 
Date: Wed, 6 Feb 2019 00:46:19 +0900
Message-ID: 
To: CARLOS JESUS BERNARDOS CANO , Sri Gundavelli ,  "Charles E. Perkins" 
Cc: Jung-Soo Park , Jaehoon Jeong , its@ietf.org, ipwave-chairs@ietf.org, skku_iotlab_seminar@gmail.com
Content-Type: multipart/alternative; boundary="0000000000005cc4ac05812783fb"
Archived-At: 
Subject: Re: [ipwave] Request for IPWAVE PS Document Review
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Feb 2019 15:46:38 -0000

--0000000000005cc4ac05812783fb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Carlos,
we authors will address Charlie's and Sri's comments and questions.

Charlie and Sri,
Thanks for your sincere help.

Best Regards,
Paul

2019=EB=85=84 2=EC=9B=94 5=EC=9D=BC (=ED=99=94) =EC=98=A4=ED=9B=84 4:28, CA=
RLOS JESUS BERNARDOS CANO =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=
=84=B1:

> Thanks Charlie!
>
> Authors, please revise considering this review.
>
> Thanks,
>
> Carlos
>
>
> On Tue, Feb 5, 2019 at 2:18 AM Charlie Perkins <
> charles.perkins@earthlink.net> wrote:
>
>> Hello Paul and all,
>>
>> Attached, please find a file with my comments embedded.  I also include
>> the output of rfcdiff, highlighting the differences between revision ...=
-07
>> and the text with my comments, so that you can easily find them.
>>
>> I would like to suggest that the authorship as shown at the bottom of
>> each page should be "Jeong, Ed." instead of simply "Jeong".  This change=
 to
>> the text is not visible in the rfcdiff output.
>>
>> I will transcribe some of the larger issues into a follow-up email to th=
e
>> WG mailing list, unless you think that would be counterproductive.
>>
>> I hope these comments are helpful.  If you have questions or want
>> clarifications, please do not hesitate to contact me.
>>
>> Regards,
>> Charlie P.
>> On 2/4/2019 2:13 PM, Charlie Perkins wrote:
>>
>> Hello folks,
>>
>> I had very bad connectivity during my vacation, from which I returned
>> yesterday.
>>
>> I hope to send editorial comments later today.
>>
>> I thought about a good way to reorganize the material in the document,
>> which I will submit to the mailing list.  I hope this is not asking too
>> much.
>>
>> Regards,
>> Charlie P.
>> On 1/21/2019 9:53 PM, Charlie Perkins wrote:
>>
>> Hello folks,
>>
>> I reviewed the Problem Statement document.  There is a lot of interestin=
g
>> material in the document, but it needs to be sharpened up a lot and
>> possibly reorganized a little bit.  Unfortunately, I don't have an outli=
ne
>> to suggest for how to shuffle the text, but some of the points below cou=
ld
>> be considered symptoms that have led me to suggest it.
>>
>> - The citations in section 4.1 seem to be somewhat arbitrary and would b=
e
>> more instructive if there were a few more points of contrast drawn betwe=
en
>> the examples.  Section 4.1.3 is short but still seems arbitrary and
>> random.  Other sections are even more so.  It would be nice to somehow
>> relate the various examples so that the overall effect might be more
>> coherent.
>>
>> - The architectural figures displayed in section 4.2 seem very verbose
>> and not terribly different from one another.  It seems that every /64 ha=
s a
>> DNS, and a router.  The distinctions are buried in a lot of words and it=
's
>> hard to get to the point.  I think there are too many places where the
>> candidate wireless technologies are listed together, without providing a=
ny
>> significant extra insight into the architectural relationships of the
>> entities.
>>
>> - In section 5.1, it is recommended that the NA interval decrease and
>> increase.  Maybe a couple of concrete examples would be helpful, given
>> known vehicle densities and speeds.
>>
>> - In section 5.2, it should be mentioned that having roadmaps allows a
>> terrific increase in predictability of vehicle mobility.
>>
>> - Appendix A was a welcome change to the previous parts of the document.
>> It has a lot of interesting information, succinctly presented.  I though=
t
>> maybe it should be moved into the main body of the text, perhaps as a ne=
w
>> section preceding the current "Security Considerations".
>>
>> I have a number of smaller editorial suggestions that I will provide
>> under separate email.
>>
>> Bottom line: I think the document is well along the way, but needs
>> careful focus and some re-emphasis of the component parts.
>>
>> Thank you very much for your continued effort on this document.
>>
>> Regards,
>> Charlie P.
>>
>>
>> From: "Mr. Jaehoon Paul Jeong" 
>> Date: Tuesday, January 8, 2019 at 7:59 AM
>> To: Charlie Perkins , Sri Gundavelli <
>> sgundave@cisco.com>, Jung-Soo Park 
>> Cc: "its@ietf.org" , "Mr. Jaehoon Paul Jeong" <
>> jaehoon.paul@gmail.com>
>> Subject: Request for IPWAVE PS Document Review
>>
>> Hi Charlie, Sri, and Jung-Soo,
>> As you agreed last IETF-103 meeting, could you give me your review on
>> the IPWAVE PS Document by January 15, 2019 in EST?
>> https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-07
>>
>> We need to move forward with this document and the IPWAVE rechartering..
>>
>> Thanks for your volunteer help.
>>
>> Best Regards,
>> Paul
>> --
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>> Mr. Jaehoon (Paul) Jeong, Ph.D.
>> Associate Professor
>> Department of Software
>> Sungkyunkwan University
>> Office: +82-31-299-4957
>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
>> 
>>
>> _______________________________________________
>> its mailing listits@ietf.orghttps://www.ietf.org/mailman/listinfo/its
>>
>>

--0000000000005cc4ac05812783fb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Carlos,
we authors will address Charl=
ie's and Sri's comments and questions.

<=
/div>
Charlie and Sri,
Thanks for y=
our sincere help.

Best R=
egards,
Paul

2019=EB=85=84 2=EC=9B=94 5=EC=9D=
=BC (=ED=99=94) =EC=98=A4=ED=9B=84 4:28, CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>=EB=8B=98=EC=9D=B4 =
=EC=9E=91=EC=84=B1:
Thanks Charlie!

Authors, please revise considering thi=
s review.

Thanks,

Carlos<=
/div>


On Tue, Feb 5, 2019 at 2:18 AM Charlie Perkins <charles.perkins@earthlink.net> wrote:

 =20
   =20
 =20
  

    
Hello Paul and all,

    
Attached, please find a file with my comments embedded.=C2=A0 I also
      include the output of rfcdiff, highlighting the differences
      between revision ...-07 and the text with my comments, so that you
      can easily find them.

    
I would like to suggest that the authorship as shown at the
      bottom of each page should be "Jeong, Ed." instead of simpl=
y
      "Jeong".=C2=A0 This change to the text is not visible in th=
e rfcdiff
      output.

    
I will transcribe some of the larger issues into a follow-up
      email to the WG mailing list, unless you think that would be
      counterproductive.

    
I hope these comments are helpful.=C2=A0 If you have questions or wa=
nt
      clarifications, please do not hesitate to contact me.

    
Regards,

      Charlie P.

    

    
On 2/4/2019 2:13 PM, Charlie Perkins
      wrote:

    

    

     =20
      
Hello folks,

      
I had very bad connectivity during my vacation, from which I
        returned yesterday.

      
I hope to send editorial comments later today.

      
I thought about a good way to reorganize the material in the
        document, which I will submit to the mailing list.=C2=A0 I hope thi=
s
        is not asking too much.

      
Regards,

        Charlie P.

      

      
On 1/21/2019 9:53 PM, Charlie Perkins
        wrote:

      

      

       =20
        
Hello folks,

        
I reviewed the Problem Statement document.=C2=A0 There is a lot =
of
          interesting material in the document, but it needs to be
          sharpened up a lot and possibly reorganized a little bit.=C2=A0
          Unfortunately, I don't have an outline to suggest for how to
          shuffle the text, but some of the points below could be
          considered symptoms that have led me to suggest it.

        
- The citations in section 4.1 seem to be somewhat arbitrary
          and would be more instructive if there were a few more points
          of contrast drawn between the examples.=C2=A0 Section 4.1.3 is
          short but still seems arbitrary and random.=C2=A0 Other sections
          are even more so.=C2=A0 It would be nice to somehow relate the
          various examples so that the overall effect might be more
          coherent.

        
- The architectural figures displayed in section 4.2 seem
          very verbose and not terribly different from one another.=C2=A0 I=
t
          seems that every /64 has a DNS, and a router.=C2=A0 The
          distinctions are buried in a lot of words and it's hard to ge=
t
          to the point.=C2=A0 I think there are too many places where the
          candidate wireless technologies are listed together, without
          providing any significant extra insight into the architectural
          relationships of the entities.

        
- In section 5.1, it is recommended that the NA interval
          decrease and increase.=C2=A0 Maybe a couple of concrete examples
          would be helpful, given known vehicle densities and speeds.

        

        
- In section 5.2, it should be mentioned that having roadmaps
          allows a terrific increase in predictability of vehicle
          mobility.

        
- Appendix A was a welcome change to the previous parts of
          the document.=C2=A0 It has a lot of interesting information,
          succinctly presented.=C2=A0 I thought maybe it should be moved in=
to
          the main body of the text, perhaps as a new section preceding
          the current "Security Considerations".

        
I have a number of smaller editorial suggestions that I will
          provide under separate email.

        
Bottom line: I think the document is well along the way, but
          needs careful focus and some re-emphasis of the component
          parts.

        
Thank you very much for your continued effort on this
          document.

        
Regards,

          Charlie P.

        

        


        

        

            
 From: "Mr. Jaehoon Paul
              Jeong" <jaehoon.paul@gmail.com>

              Date: Tuesday,
              January 8, 2019 at 7:59 AM

              To: Charlie Perkins
              <Charlie.Perkins@huawei.com>,
              Sri Gundavelli <sgundave@cisco.com>,
              Jung-Soo Park <pjs@etri.re.kr>

              Cc: "its@ietf.org&=
quot;
              <its@ietf.org>,
              "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail=
.com>

              Subject: Request
              for IPWAVE PS Document Review

            

            


            

            

              

                

                  
Hi Charlie, Sri, and Jung-Soo,
                    
As you agreed last IETF-103 meeting, could you
                      give me your review on=C2=A0

                    
the IPWAVE PS Document by January 15, 2019 in
                      EST?

                    
                    


                    

                    
We need to move forward with this document and
                      the IPWAVE rechartering..

                    


                    

                    
Thanks for your volunteer help.

                    


                    

                    
Best Regards,

                    
Paul

                      -- 

                      

                        

                          

                            

                              

                                

                                  

                                    
=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

                                      Mr. Jaehoon (Paul) Jeong, Ph.D.

                                      Associate Professor

                                      Department of Software

                                      Sungkyunkwan University

                                      Office: +82-31-299-4957

                                      Email: jaehoon.paul@gmail.com=
,=C2=A0pauljeong@skku.edu

                                      Personal Homepage: 
http://iotlab.skku.edu/people-jaehoon-jeong.php

                                    

                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

           

          

          
_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


        

      

    

  







--0000000000005cc4ac05812783fb--


From nobody Tue Feb  5 12:37:33 2019
Return-Path: 
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 0DC43131251; Tue,  5 Feb 2019 12:37:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tcs.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 dVzVZPWvLToi; Tue,  5 Feb 2019 12:37:22 -0800 (PST)
Received: from indelg02.tcs.com (indelg02.tcs.com [203.200.109.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F76213123A; Tue,  5 Feb 2019 12:37:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcs.com; i=@tcs.com; q=dns/txt; s=default2048; t=1549399041; x=1580935041; h=mime-version:in-reply-to:references:subject:from:to: message-id:date; bh=QZXjkR5pSGVA7FUsVnGecEasha1IweJhlTA5PVDvJjk=; b=LwT8nS+3gLyBUlQ5BLAsmxj0QC0Mml+ZitvsdqSU8R3rpFuDyJUctiJH V+pzlW+bv7PgFUAU9VWCSi6WJZQDXiXvn72PdQL/8KIOYQzra1Z2z73wU 7lO/kkTFINnNUxKmLuAxvgIBU3PpTFGY/e5s/U2Vuz0C/yR9A0GYdfnfC BsvvcsKSGdQXmycPVi6sqklFlPj+GjfxOY95F2np5ue89tHLesoZS1gi9 TPz/PoibAuJoHLY4IkB3rCgBW26e7dx/fQI346gz/zp5pX5lzBIELj+wa f8q7vN4ZwBCQsVjz7bDpNdTIGJK+hGNv4Fdr1gxiS7+fc/6oVEBYG9gDb A==;
IronPort-PHdr: =?us-ascii?q?9a23=3AehVMWRDhtPlhX3ICvCRDUyQJP3N1i/DPJgcQr6?= =?us-ascii?q?AfoPdwSPT8psbcNUDSrc9gkEXOFd2Cra4c26yO6+jJYi8p2d65qncMcZhBBV?= =?us-ascii?q?cuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx?= =?us-ascii?q?7xKRR6JvjvGo7Vks+7y/2+94fcbglUhzexe69+IAmrpgjNq8cahpdvJLwswR?= =?us-ascii?q?XTuHtIfOpWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3?= =?us-ascii?q?sp683xtBnMVhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Xy?= =?us-ascii?q?mp4aV2Rx/ykCoIOD02/nvVhcx+kaxVoAyvqR9xzYDTfI6YL+Bxcr/HcN4AQW?= =?us-ascii?q?pNQttdWipcCY28dYsPCO8BMP5Eoobmp1sOrBm+ChOqBOjy1zJIhmX53bEm0+?= =?us-ascii?q?s7DQ7G3BYvH8gOsXXUttr+KaAfXvquw6nIzDXDbelZ2THn5IfTchAuu+2MXa?= =?us-ascii?q?5qfsXNyUkgDRnFj1WQqIP/JD6VyvgCs3OB4+V8UuKvjncqpgdsqTahwccsj5?= =?us-ascii?q?PGhoMTyl3c9CV23po1JdOiRE58e96kH4Nctz2GOIttWM8tX2ZouCM8x7Ybup?= =?us-ascii?q?C7ZDAHxIklyhLBcfCLbouF7gj9WOufOzt1i3Roc6+liRmo60iv0Oj8W9Gx0F?= =?us-ascii?q?ZNsyVKjMHBtmsI1xzP8siHTeZ9/lu51TaPyQ/T7uZELFg3m6TDLpAv27g+mI?= =?us-ascii?q?cPvErFECH4nl/4gqiIeEg45+Sk8+XnYrP4qZ+AL4J4lwPzPro0lsCiAuk0KB?= =?us-ascii?q?YCUmaB9emzzLHj+Ff2QLROjv04iKnZt5XaKNwBqaGiAw9V04Qj5Ay5Dzu8y9?= =?us-ascii?q?sYnWMILE5ZeB2dk4fpO0vBIOr4DPa/mVuhiytryOzdPrH7HprNKX3DnK/7fb?= =?us-ascii?q?lh805c1BYzzddH6p1IDbEBOuz8V1TwtNPGEh85PRa4w+H9CNVyzokeQ36AAr?= =?us-ascii?q?eFMKPOtl+F/uMvI/WXZIIOuTbyNeQl5/D0gX8+g18dcvrh4ZxCInu/BPlOIk?= =?us-ascii?q?iFbzzrmNhLWTMBuRAzZO3nlFPEViRcMTL6Xr4nzjA2FIzgCp3MFa63h7nU9S?= =?us-ascii?q?27H59fYChsClmQDX7jd4yeSuYFIHabKM9gkDUCE7KhQpM93BquvRXr2rNPMu?= =?us-ascii?q?HPvCYfsMSwh5BO++TPmERqpnRPBMOH3jTVQg=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AjAABl8llc/wQXEqxlHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgQ1NgRCBKowdjgOYEBSBZzKER4M2NAkNAQMBAQIBAQIBgQg?= =?us-ascii?q?Mgjoigm4BAwMOVxIXBg0EAQIBAh4KTQMEAggGAQkBCBEKgwcBghCrUQEBAYI?= =?us-ascii?q?ehDMCDkFAhHKMZGgPfoQjgx4BAQIBARaBDwUBEgE/gxaCKgKKA4YvgQSFZQa?= =?us-ascii?q?LXQcCgjWFAYsigWxShHGLGIdFgmWFMY14gR1xcC+DDQmDNgEIgkKFFIVHagG?= =?us-ascii?q?MO4I+AQE?=
X-IPAS-Result: =?us-ascii?q?A2AjAABl8llc/wQXEqxlHAEBAQQBAQcEAQGBUQcBAQsBg?= =?us-ascii?q?Q1NgRCBKowdjgOYEBSBZzKER4M2NAkNAQMBAQIBAQIBgQgMgjoigm4BAwMOV?= =?us-ascii?q?xIXBg0EAQIBAh4KTQMEAggGAQkBCBEKgwcBghCrUQEBAYIehDMCDkFAhHKMZ?= =?us-ascii?q?GgPfoQjgx4BAQIBARaBDwUBEgE/gxaCKgKKA4YvgQSFZQaLXQcCgjWFAYsig?= =?us-ascii?q?WxShHGLGIdFgmWFMY14gR1xcC+DDQmDNgEIgkKFFIVHagGMO4I+AQE?=
X-IronPort-AV: E=Sophos; i="5.58,336,1544466600"; d="scan'208,217"; a="34636526"
MIME-Version: 1.0
Sensitivity: 
Importance: Normal
X-Priority: 3 (Normal)
In-Reply-To: 
References: 
From: Abhijan Bhattacharyya 
To: "core@ietf.org" , its@ietf.org
Message-ID: 
Date: Wed, 6 Feb 2019 02:07:09 +0530
X-Mailer: Lotus Domino Web Server Release 9.0.1FP10HF213   April 26, 2018
X-MIMETrack: Serialize by http on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 02/06/2019 02:07:09, Serialize complete at 02/06/2019 02:07:10, Itemize by http on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 02/06/2019 02:07:10, Serialize by Router on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 02/06/2019 02:07:11, Serialize complete at 02/06/2019 02:07:11
Content-Type: multipart/alternative; boundary="=_alternative 0071440C65258398_="
Archived-At: 
Subject: [ipwave] Fw: New Version Notification for draft-bhattacharyya-core-a-realist-02.txt
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Feb 2019 20:37:26 -0000

--=_alternative 0071440C65258398_=
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear CoRE and IPWAVE,
We submitted a quick version 2 of A-REaLiST draft.
The major changes from 00 to 02 (through 01) are as below:

1) In Section 4, a note has been provided  on the interpretation of Stream_=
id sub-field at the consumer end-point.
2) Section 6.3 has been introduced (in version 01 itself) to provide a guid=
ance on how information segment sizes can be determined for the end-to-end =
channel for IPv6 backbone.
3) Version 01 had some formatting issues and incorrect ToC. That has been f=
ixed.

Looking forward to comments from stakeholders in both the lists.

Thank you. =


With Best Regards
Abhijan Bhattacharyya
Consultant / Scientist,
{Internet Protocols | 5G | Standardization}, =

TCS Research,
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- +91 33 66884691
Cell:- +919830468972 | +918583875003
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.	IT Services
Business Solutions
Consulting
____________________________________________


-----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 02/06/2019 01:56AM -----
To: "Abhijan Bhattacharyya" , "Suvrat Agrawa=
l" , "Arpan Pal" , "Hemant Rath" , "Balamurali Purushothaman" 
From: internet-drafts@ietf.org
Date: 02/06/2019 01:55AM
Subject: New Version Notification for draft-bhattacharyya-core-a-realist-02=
.txt

"External email. Open with Caution"

A new version of I-D, draft-bhattacharyya-core-a-realist-02.txt
has been successfully submitted by Abhijan Bhattacharyya and posted to the
IETF repository.

Name:	draft-bhattacharyya-core-a-realist
Revision:	02
Title:	Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)
Document date:	2019-02-06
Group:	Individual Submission
Pages:	18
URL:            https://www.ietf.org/internet-drafts/draft-bhattacharyya-co=
re-a-realist-02.txt
Status:         https://datatracker.ietf.org/doc/draft-bhattacharyya-core-a=
-realist/
Htmlized:       https://tools.ietf.org/html/draft-bhattacharyya-core-a-real=
ist-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-bhattacharyya-c=
ore-a-realist
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-bhattacharyya-cor=
e-a-realist-02

Abstract:
   This draft presents extensions to Constrained Application Protocol
   (CoAP) to enable RESTful Real-time Live Streaming for improving the
   Quality of Experience (QoE) for delay-sensitive Internet of Things
   (IoT) applications. The overall architecture is termed "Adaptive
   RESTful Real-time Live Streaming for Things (A-REaLiST)". It is
   particularly designed for applications which rely on real-time
   augmented vision through live First Person View (FPV) feed from
   constrained remote agents like Unmanned Aerial Vehicle (UAV), etc.
   These extensions provide the necessary hooks to help solution
   designers ensure low-latency transfer of streams and, for contents
   like video, a quick recovery from freeze and corruption without
   incurring undue lag. A-REaLiST is an attempt to provide an
   integrated approach to maintain the balance amongst QoE, resource-
   efficiency and loss resilience. It provides the necessary hooks to
   optimize system performance by leveraging contextual intelligence
   inferred from instantaneous information segments in flight. These
   extensions equip CoAP with a standard for efficient RESTful
   streaming for Internet of Things (IoT) contrary to HTTP-streaming in
   conventional Internet.

                                                                           =
       =



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.

The IETF Secretariat

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain =

confidential or privileged information. If you are =

not the intended recipient, any dissemination, use, =

review, distribution, printing or copying of the =

information contained in this e-mail message =

and/or attachments to it are strictly prohibited. If =

you have received this communication in error, =

please notify us by reply e-mail or telephone and =

immediately and permanently delete the message =

and any attachments. Thank you



--=_alternative 0071440C65258398_=
Content-ID: <>
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Dear CoRE and IPWAVE,
We submitted a quick version 2 =
of A-REaLiST draft.
The major changes from 00 to 02 (through 01) =
are as below:

1) In Section 4, a note =
has been provided  on the interpretation of Stream_id sub-field at the=
 consumer end-point.
2)=
 Section 6.3 has been introduced (in version 01 itself) to provide a guidan=
ce on how information segment sizes can be determined for the end-to-end ch=
annel for IPv6 backbone.

Looking forward to comments from =
stakeholders in both the lists.

Thank you=
. 

With Best Regards

Abhijan Bhattacharyya

Consultant / Scientist,

{Internet Protocols | 5G | Standardization}, 

TCS Research,

Tata Consultancy Services

Building 1B,Ecospace

Plot -  IIF/12 ,New Town, Rajarhat,

Kolkata - 700160,West Bengal

India

Ph:- +91 33 66884691

Cell:- +919830468972 | +918583875003

Mailto: =
abhijan.bhattacharyya@tcs.com

Website: http://www.tcs.com

____________________________________________

Experience certainty.	IT Services

			Business Solutions

			Consulting

____________________________________________




-----Forwarded by Abhijan Bhat=
tacharyya/KOL/TCS on 02/06/2019 01:56AM -----
To: "Abhijan Bhattachar=
yya" <abhijan.bhattacharyya@tcs.com>, "Suvrat Agrawal" <suvrat.a@tcs.com>, "Arpan Pa=
l" <arpan.pal@tcs=
.com>, "Hemant Rath" <hemant.rath@tcs.com>, "Balamurali Purushothaman" <<=
a href=3D"mailto:balamurali.p@tcs.com" target=3D"_blank">balamurali.p@tcs.c=
om>
From: internet-drafts@ietf.org
Date: 02/06/2019 01:55AM
Subject:=
 New Version Notification for draft-bhattacharyya-core-a-realist-02.txt
=

"External =
email. Open with Caution"

A new version of I-D, draft-bhattacharyya-=
core-a-realist-02.txt
has been successfully submitted by Abhijan Bhattac=
haryya and posted to the
IETF repository.

Name:		draft-bhattachar=
yya-core-a-realist
Revision:	02
Title:		Adaptive RESTful Real-time Li=
ve Streaming for Things (A-REaLiST)
Document date:	2019-02-06
Group:	=
	Individual Submission
Pages:		18
URL:         &n=
bsp;  https://www.ietf.org/internet-drafts/draft-bhatt=
acharyya-core-a-realist-02.txt
Status:         <=
a href=3D"https://datatracker.ietf.org/doc/draft-bhattacharyya-core-a-reali=
st/">https://datatracker.ietf.org/doc/draft-bhattacharyya-core-a-realist/
Htmlized:       https://tools.ietf.org/html/draft-b=
hattacharyya-core-a-realist-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-bhattacharyya-core-a-realis=
t
Diff:           https://www.ie=
tf.org/rfcdiff?url2=3Ddraft-bhattacharyya-core-a-realist-02

Abst=
ract:
   This draft presents extensions to Constrained Applica=
tion Protocol
   (CoAP) to enable RESTful Real-time Live Strea=
ming for improving the
   Quality of Experience (QoE) for dela=
y-sensitive Internet of Things
   (IoT) applications. The over=
all architecture is termed "Adaptive
   RESTful Real-time Live=
 Streaming for Things (A-REaLiST)". It is
   particularly desi=
gned for applications which rely on real-time
   augmented vis=
ion through live First Person View (FPV) feed from
   constrai=
ned remote agents like Unmanned Aerial Vehicle (UAV), etc.
   =
These extensions provide the necessary hooks to help solution
 &nbs=
p; designers ensure low-latency transfer of streams and, for contents
&n=
bsp;  like video, a quick recovery from freeze and corruption without<=
br>   incurring undue lag. A-REaLiST is an attempt to provide an<=
br>   integrated approach to maintain the balance amongst QoE, re=
source-
   efficiency and loss resilience. It provides the nec=
essary hooks to
   optimize system performance by leveraging c=
ontextual intelligence
   inferred from instantaneous informat=
ion segments in flight. These
   extensions equip CoAP with a =
standard for efficient RESTful
   streaming for Internet of Th=
ings (IoT) contrary to HTTP-streaming in
   conventional Inter=
net.

                 &=
nbsp;                    =
                     &nbs=
p;                     &n=
bsp;


Please note that it may take a couple of minutes from the t=
ime of submission
until the htmlized version and diff are available at t=
ools.ietf.org.

The IETF Secretariat

=

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D

Notice: The information contained in this e-mail

message and/or attachments to it may contain 

confidential or privileged information. If you are 

not the intended recipient, any dissemination, use, 

review, distribution, printing or copying of the 

information contained in this e-mail message 

and/or attachments to it are strictly prohibited. If 

you have received this communication in error, 

please notify us by reply e-mail or telephone and 

immediately and permanently delete the message 

and any attachments. Thank you




--=_alternative 0071440C65258398_=--


From nobody Wed Feb  6 08:15:39 2019
Return-Path: 
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 33FA112F1A6; Wed,  6 Feb 2019 08:15:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.642
X-Spam-Level: 
X-Spam-Status: No, score=-14.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Np20GzDvP36a; Wed,  6 Feb 2019 08:15:34 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906A312F1A2; Wed,  6 Feb 2019 08:15:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24090; q=dns/txt; s=iport; t=1549469733; x=1550679333; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BYT1xtG7e2x+DcA7BBwI2KXSsG2f6JA8fZNmGwmf/bo=; b=Z2pjFkURamV42QdDXfce9VoT05+P16x2GD579aeyrd1AEcbbV4DRi7Fy WUEQ3VM5x8GOZbz4B8xEaqqHfDLNmZqOPnegDFhu/pRYZm8B3KSjsq6Uf WuIAEbcE/JnnHEa9i3U0Dti4mBtCA+/Ty6EoRIF4i6shTS1JSJz6lCi0F 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAADQBltc/5NdJa1LGhkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVIDAQEBAQELAYENdmeBAycKg3mUBYINiSeIeYVvFIF?= =?us-ascii?q?nCwEBGAEKgVSBPoE3AheDAyI1CA0BAwEBAgEBAm0cDIVKAQEBAQMBAWwEAQY?= =?us-ascii?q?OAgIBBgIRAwECKAUCAhQLBgsUCQgCBAENBQkSgwiBHUwDFQ81kHWbWQaBMR+?= =?us-ascii?q?EFAKDWg2CHgWMPheBQD+DdS6BKBkBfBlHAQEBAoEqAQESARwaCQwMgkuCOyI?= =?us-ascii?q?Cii2Fa4USgXiLMzMJAoc1h1GDOxmBbFKEc4sdQolqhDp6gSiKawIRFIEnDRQ?= =?us-ascii?q?CNGVxcBU7gmwJgW88hECEKoU/QTEBjDuBH4EfAQE?=
X-IronPort-AV: E=Sophos;i="5.58,340,1544486400";  d="scan'208,217";a="516688262"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2019 16:15:32 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x16GFWMY030245 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Feb 2019 16:15:32 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 6 Feb 2019 10:15:30 -0600
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Wed, 6 Feb 2019 10:15:31 -0600
From: "Sri Gundavelli (sgundave)" 
To: "Mr. Jaehoon Paul Jeong" , "CARLOS JESUS BERNARDOS CANO" , "Charles E. Perkins" 
CC: Jung-Soo Park , "its@ietf.org" , "ipwave-chairs@ietf.org" , "skku_iotlab_seminar@gmail.com" 
Thread-Topic: [ipwave] Request for IPWAVE PS Document Review
Thread-Index: AQHUvNbWrDbOnumC8EeLM1zs0I8RNw==
Date: Wed, 6 Feb 2019 16:15:31 +0000
Message-ID: 
References:   <12ee3e17-fcb6-cf9d-425b-5eb3bd0130bb@earthlink.net> <09a8ba4a-dc3b-1f96-96af-7923f950a909@earthlink.net>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.188.53]
Content-Type: multipart/alternative; boundary="_000_D88047E22E6AB2sgundaveciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: 
Subject: Re: [ipwave] Request for IPWAVE PS Document Review
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2019 16:15:37 -0000

--_000_D88047E22E6AB2sgundaveciscocom_
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: base64

SGkgUGF1bCwNCg0KWW91IG1heSBhbHNvIHdhbnQgdG8gbG8gYXQgb3RoZXIgUFMgZG9jdW1lbnRz
LCBzdWNoIGFzIFJGQyA0ODMwIG9uIGhvdyB0byBjYXB0dXJlIHRoZSBwcm9ibGVtIHN0YXRlbWVu
dCB3aXRob3V0IGdldHRpbmcgaW50byBzb2x1dGlvbiBzcGFjZS4NCg0KU3JpDQoNCg0KRnJvbTog
Ik1yLiBKYWVob29uIFBhdWwgSmVvbmciIDxqYWVob29uLnBhdWxAZ21haWwuY29tPG1haWx0bzpq
YWVob29uLnBhdWxAZ21haWwuY29tPj4NCkRhdGU6IFR1ZXNkYXksIEZlYnJ1YXJ5IDUsIDIwMTkg
YXQgNzo0NiBBTQ0KVG86IENBUkxPUyBKRVNVUyBCRVJOQVJET1MgQ0FOTyA8Y2piY0BpdC51YzNt
LmVzPG1haWx0bzpjamJjQGl0LnVjM20uZXM+PiwgU3JpIEd1bmRhdmVsbGkgPHNndW5kYXZlQGNp
c2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4sICJDaGFybGVzIEUuIFBlcmtpbnMi
IDxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldDxtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVh
cnRobGluay5uZXQ+Pg0KQ2M6IEp1bmctU29vIFBhcmsgPHBqc0BldHJpLnJlLmtyPG1haWx0bzpw
anNAZXRyaS5yZS5rcj4+LCBKYWVob29uIEplb25nIDxqYWVob29uLnBhdWxAZ21haWwuY29tPG1h
aWx0bzpqYWVob29uLnBhdWxAZ21haWwuY29tPj4sICJpdHNAaWV0Zi5vcmc8bWFpbHRvOml0c0Bp
ZXRmLm9yZz4iIDxpdHNAaWV0Zi5vcmc8bWFpbHRvOml0c0BpZXRmLm9yZz4+LCAiaXB3YXZlLWNo
YWlyc0BpZXRmLm9yZzxtYWlsdG86aXB3YXZlLWNoYWlyc0BpZXRmLm9yZz4iIDxpcHdhdmUtY2hh
aXJzQGlldGYub3JnPG1haWx0bzppcHdhdmUtY2hhaXJzQGlldGYub3JnPj4sICJza2t1X2lvdGxh
Yl9zZW1pbmFyQGdtYWlsLmNvbTxtYWlsdG86c2trdV9pb3RsYWJfc2VtaW5hckBnbWFpbC5jb20+
IiA8c2trdV9pb3RsYWJfc2VtaW5hckBnbWFpbC5jb208bWFpbHRvOnNra3VfaW90bGFiX3NlbWlu
YXJAZ21haWwuY29tPj4NClN1YmplY3Q6IFJlOiBbaXB3YXZlXSBSZXF1ZXN0IGZvciBJUFdBVkUg
UFMgRG9jdW1lbnQgUmV2aWV3DQoNCkhpIENhcmxvcywNCndlIGF1dGhvcnMgd2lsbCBhZGRyZXNz
IENoYXJsaWUncyBhbmQgU3JpJ3MgY29tbWVudHMgYW5kIHF1ZXN0aW9ucy4NCg0KQ2hhcmxpZSBh
bmQgU3JpLA0KVGhhbmtzIGZvciB5b3VyIHNpbmNlcmUgaGVscC4NCg0KQmVzdCBSZWdhcmRzLA0K
UGF1bA0KDQoyMDE5s+IgMr/5IDXAzyAoyK0pIL/AyMQgNDoyOCwgQ0FSTE9TIEpFU1VTIEJFUk5B
UkRPUyBDQU5PIDxjamJjQGl0LnVjM20uZXM8bWFpbHRvOmNqYmNAaXQudWMzbS5lcz4+tNTAzCDA
27y6Og0KVGhhbmtzIENoYXJsaWUhDQoNCkF1dGhvcnMsIHBsZWFzZSByZXZpc2UgY29uc2lkZXJp
bmcgdGhpcyByZXZpZXcuDQoNClRoYW5rcywNCg0KQ2FybG9zDQoNCg0KT24gVHVlLCBGZWIgNSwg
MjAxOSBhdCAyOjE4IEFNIENoYXJsaWUgUGVya2lucyA8Y2hhcmxlcy5wZXJraW5zQGVhcnRobGlu
ay5uZXQ8bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pj4gd3JvdGU6DQoNCkhl
bGxvIFBhdWwgYW5kIGFsbCwNCg0KQXR0YWNoZWQsIHBsZWFzZSBmaW5kIGEgZmlsZSB3aXRoIG15
IGNvbW1lbnRzIGVtYmVkZGVkLiAgSSBhbHNvIGluY2x1ZGUgdGhlIG91dHB1dCBvZiByZmNkaWZm
LCBoaWdobGlnaHRpbmcgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gcmV2aXNpb24gLi4uLTA3IGFu
ZCB0aGUgdGV4dCB3aXRoIG15IGNvbW1lbnRzLCBzbyB0aGF0IHlvdSBjYW4gZWFzaWx5IGZpbmQg
dGhlbS4NCg0KSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgdGhhdCB0aGUgYXV0aG9yc2hpcCBhcyBz
aG93biBhdCB0aGUgYm90dG9tIG9mIGVhY2ggcGFnZSBzaG91bGQgYmUgIkplb25nLCBFZC4iIGlu
c3RlYWQgb2Ygc2ltcGx5ICJKZW9uZyIuICBUaGlzIGNoYW5nZSB0byB0aGUgdGV4dCBpcyBub3Qg
dmlzaWJsZSBpbiB0aGUgcmZjZGlmZiBvdXRwdXQuDQoNCkkgd2lsbCB0cmFuc2NyaWJlIHNvbWUg
b2YgdGhlIGxhcmdlciBpc3N1ZXMgaW50byBhIGZvbGxvdy11cCBlbWFpbCB0byB0aGUgV0cgbWFp
bGluZyBsaXN0LCB1bmxlc3MgeW91IHRoaW5rIHRoYXQgd291bGQgYmUgY291bnRlcnByb2R1Y3Rp
dmUuDQoNCkkgaG9wZSB0aGVzZSBjb21tZW50cyBhcmUgaGVscGZ1bC4gIElmIHlvdSBoYXZlIHF1
ZXN0aW9ucyBvciB3YW50IGNsYXJpZmljYXRpb25zLCBwbGVhc2UgZG8gbm90IGhlc2l0YXRlIHRv
IGNvbnRhY3QgbWUuDQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCk9uIDIvNC8yMDE5IDI6MTMg
UE0sIENoYXJsaWUgUGVya2lucyB3cm90ZToNCg0KSGVsbG8gZm9sa3MsDQoNCkkgaGFkIHZlcnkg
YmFkIGNvbm5lY3Rpdml0eSBkdXJpbmcgbXkgdmFjYXRpb24sIGZyb20gd2hpY2ggSSByZXR1cm5l
ZCB5ZXN0ZXJkYXkuDQoNCkkgaG9wZSB0byBzZW5kIGVkaXRvcmlhbCBjb21tZW50cyBsYXRlciB0
b2RheS4NCg0KSSB0aG91Z2h0IGFib3V0IGEgZ29vZCB3YXkgdG8gcmVvcmdhbml6ZSB0aGUgbWF0
ZXJpYWwgaW4gdGhlIGRvY3VtZW50LCB3aGljaCBJIHdpbGwgc3VibWl0IHRvIHRoZSBtYWlsaW5n
IGxpc3QuICBJIGhvcGUgdGhpcyBpcyBub3QgYXNraW5nIHRvbyBtdWNoLg0KDQpSZWdhcmRzLA0K
Q2hhcmxpZSBQLg0KDQpPbiAxLzIxLzIwMTkgOTo1MyBQTSwgQ2hhcmxpZSBQZXJraW5zIHdyb3Rl
Og0KDQpIZWxsbyBmb2xrcywNCg0KSSByZXZpZXdlZCB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQgZG9j
dW1lbnQuICBUaGVyZSBpcyBhIGxvdCBvZiBpbnRlcmVzdGluZyBtYXRlcmlhbCBpbiB0aGUgZG9j
dW1lbnQsIGJ1dCBpdCBuZWVkcyB0byBiZSBzaGFycGVuZWQgdXAgYSBsb3QgYW5kIHBvc3NpYmx5
IHJlb3JnYW5pemVkIGEgbGl0dGxlIGJpdC4gIFVuZm9ydHVuYXRlbHksIEkgZG9uJ3QgaGF2ZSBh
biBvdXRsaW5lIHRvIHN1Z2dlc3QgZm9yIGhvdyB0byBzaHVmZmxlIHRoZSB0ZXh0LCBidXQgc29t
ZSBvZiB0aGUgcG9pbnRzIGJlbG93IGNvdWxkIGJlIGNvbnNpZGVyZWQgc3ltcHRvbXMgdGhhdCBo
YXZlIGxlZCBtZSB0byBzdWdnZXN0IGl0Lg0KDQotIFRoZSBjaXRhdGlvbnMgaW4gc2VjdGlvbiA0
LjEgc2VlbSB0byBiZSBzb21ld2hhdCBhcmJpdHJhcnkgYW5kIHdvdWxkIGJlIG1vcmUgaW5zdHJ1
Y3RpdmUgaWYgdGhlcmUgd2VyZSBhIGZldyBtb3JlIHBvaW50cyBvZiBjb250cmFzdCBkcmF3biBi
ZXR3ZWVuIHRoZSBleGFtcGxlcy4gIFNlY3Rpb24gNC4xLjMgaXMgc2hvcnQgYnV0IHN0aWxsIHNl
ZW1zIGFyYml0cmFyeSBhbmQgcmFuZG9tLiAgT3RoZXIgc2VjdGlvbnMgYXJlIGV2ZW4gbW9yZSBz
by4gIEl0IHdvdWxkIGJlIG5pY2UgdG8gc29tZWhvdyByZWxhdGUgdGhlIHZhcmlvdXMgZXhhbXBs
ZXMgc28gdGhhdCB0aGUgb3ZlcmFsbCBlZmZlY3QgbWlnaHQgYmUgbW9yZSBjb2hlcmVudC4NCg0K
LSBUaGUgYXJjaGl0ZWN0dXJhbCBmaWd1cmVzIGRpc3BsYXllZCBpbiBzZWN0aW9uIDQuMiBzZWVt
IHZlcnkgdmVyYm9zZSBhbmQgbm90IHRlcnJpYmx5IGRpZmZlcmVudCBmcm9tIG9uZSBhbm90aGVy
LiAgSXQgc2VlbXMgdGhhdCBldmVyeSAvNjQgaGFzIGEgRE5TLCBhbmQgYSByb3V0ZXIuICBUaGUg
ZGlzdGluY3Rpb25zIGFyZSBidXJpZWQgaW4gYSBsb3Qgb2Ygd29yZHMgYW5kIGl0J3MgaGFyZCB0
byBnZXQgdG8gdGhlIHBvaW50LiAgSSB0aGluayB0aGVyZSBhcmUgdG9vIG1hbnkgcGxhY2VzIHdo
ZXJlIHRoZSBjYW5kaWRhdGUgd2lyZWxlc3MgdGVjaG5vbG9naWVzIGFyZSBsaXN0ZWQgdG9nZXRo
ZXIsIHdpdGhvdXQgcHJvdmlkaW5nIGFueSBzaWduaWZpY2FudCBleHRyYSBpbnNpZ2h0IGludG8g
dGhlIGFyY2hpdGVjdHVyYWwgcmVsYXRpb25zaGlwcyBvZiB0aGUgZW50aXRpZXMuDQoNCi0gSW4g
c2VjdGlvbiA1LjEsIGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlIE5BIGludGVydmFsIGRlY3Jl
YXNlIGFuZCBpbmNyZWFzZS4gIE1heWJlIGEgY291cGxlIG9mIGNvbmNyZXRlIGV4YW1wbGVzIHdv
dWxkIGJlIGhlbHBmdWwsIGdpdmVuIGtub3duIHZlaGljbGUgZGVuc2l0aWVzIGFuZCBzcGVlZHMu
DQoNCi0gSW4gc2VjdGlvbiA1LjIsIGl0IHNob3VsZCBiZSBtZW50aW9uZWQgdGhhdCBoYXZpbmcg
cm9hZG1hcHMgYWxsb3dzIGEgdGVycmlmaWMgaW5jcmVhc2UgaW4gcHJlZGljdGFiaWxpdHkgb2Yg
dmVoaWNsZSBtb2JpbGl0eS4NCg0KLSBBcHBlbmRpeCBBIHdhcyBhIHdlbGNvbWUgY2hhbmdlIHRv
IHRoZSBwcmV2aW91cyBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQuICBJdCBoYXMgYSBsb3Qgb2YgaW50
ZXJlc3RpbmcgaW5mb3JtYXRpb24sIHN1Y2NpbmN0bHkgcHJlc2VudGVkLiAgSSB0aG91Z2h0IG1h
eWJlIGl0IHNob3VsZCBiZSBtb3ZlZCBpbnRvIHRoZSBtYWluIGJvZHkgb2YgdGhlIHRleHQsIHBl
cmhhcHMgYXMgYSBuZXcgc2VjdGlvbiBwcmVjZWRpbmcgdGhlIGN1cnJlbnQgIlNlY3VyaXR5IENv
bnNpZGVyYXRpb25zIi4NCg0KSSBoYXZlIGEgbnVtYmVyIG9mIHNtYWxsZXIgZWRpdG9yaWFsIHN1
Z2dlc3Rpb25zIHRoYXQgSSB3aWxsIHByb3ZpZGUgdW5kZXIgc2VwYXJhdGUgZW1haWwuDQoNCkJv
dHRvbSBsaW5lOiBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyB3ZWxsIGFsb25nIHRoZSB3YXksIGJ1
dCBuZWVkcyBjYXJlZnVsIGZvY3VzIGFuZCBzb21lIHJlLWVtcGhhc2lzIG9mIHRoZSBjb21wb25l
bnQgcGFydHMuDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29udGludWVkIGVmZm9y
dCBvbiB0aGlzIGRvY3VtZW50Lg0KDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoNCkZyb206ICJN
ci4gSmFlaG9vbiBQYXVsIEplb25nIiA8amFlaG9vbi5wYXVsQGdtYWlsLmNvbTxtYWlsdG86amFl
aG9vbi5wYXVsQGdtYWlsLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBKYW51YXJ5IDgsIDIwMTkgYXQg
Nzo1OSBBTQ0KVG86IENoYXJsaWUgUGVya2lucyA8Q2hhcmxpZS5QZXJraW5zQGh1YXdlaS5jb208
bWFpbHRvOkNoYXJsaWUuUGVya2luc0BodWF3ZWkuY29tPj4sIFNyaSBHdW5kYXZlbGxpIDxzZ3Vu
ZGF2ZUBjaXNjby5jb208bWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbT4+LCBKdW5nLVNvbyBQYXJr
IDxwanNAZXRyaS5yZS5rcjxtYWlsdG86cGpzQGV0cmkucmUua3I+Pg0KQ2M6ICJpdHNAaWV0Zi5v
cmc8bWFpbHRvOml0c0BpZXRmLm9yZz4iIDxpdHNAaWV0Zi5vcmc8bWFpbHRvOml0c0BpZXRmLm9y
Zz4+LCAiTXIuIEphZWhvb24gUGF1bCBKZW9uZyIgPGphZWhvb24ucGF1bEBnbWFpbC5jb208bWFp
bHRvOmphZWhvb24ucGF1bEBnbWFpbC5jb20+Pg0KU3ViamVjdDogUmVxdWVzdCBmb3IgSVBXQVZF
IFBTIERvY3VtZW50IFJldmlldw0KDQpIaSBDaGFybGllLCBTcmksIGFuZCBKdW5nLVNvbywNCkFz
IHlvdSBhZ3JlZWQgbGFzdCBJRVRGLTEwMyBtZWV0aW5nLCBjb3VsZCB5b3UgZ2l2ZSBtZSB5b3Vy
IHJldmlldyBvbg0KdGhlIElQV0FWRSBQUyBEb2N1bWVudCBieSBKYW51YXJ5IDE1LCAyMDE5IGlu
IEVTVD8NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwd2F2ZS12ZWhp
Y3VsYXItbmV0d29ya2luZy0wNw0KDQpXZSBuZWVkIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRoaXMg
ZG9jdW1lbnQgYW5kIHRoZSBJUFdBVkUgcmVjaGFydGVyaW5nLi4NCg0KVGhhbmtzIGZvciB5b3Vy
IHZvbHVudGVlciBoZWxwLg0KDQpCZXN0IFJlZ2FyZHMsDQpQYXVsDQotLQ0KPT09PT09PT09PT09
PT09PT09PT09PT09PT09DQpNci4gSmFlaG9vbiAoUGF1bCkgSmVvbmcsIFBoLkQuDQpBc3NvY2lh
dGUgUHJvZmVzc29yDQpEZXBhcnRtZW50IG9mIFNvZnR3YXJlDQpTdW5na3l1bmt3YW4gVW5pdmVy
c2l0eQ0KT2ZmaWNlOiArODItMzEtMjk5LTQ5NTcNCkVtYWlsOiBqYWVob29uLnBhdWxAZ21haWwu
Y29tPG1haWx0bzpqYWVob29uLnBhdWxAZ21haWwuY29tPiwgcGF1bGplb25nQHNra3UuZWR1PG1h
aWx0bzpwYXVsamVvbmdAc2trdS5lZHU+DQpQZXJzb25hbCBIb21lcGFnZTogaHR0cDovL2lvdGxh
Yi5za2t1LmVkdS9wZW9wbGUtamFlaG9vbi1qZW9uZy5waHA8aHR0cDovL2Nwc2xhYi5za2t1LmVk
dS9wZW9wbGUtamFlaG9vbi1qZW9uZy5waHA+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCml0cyBtYWlsaW5nIGxpc3QNCml0c0BpZXRmLm9yZzxt
YWlsdG86aXRzQGlldGYub3JnPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
aXRzDQo=

--_000_D88047E22E6AB2sgundaveciscocom_
Content-Type: text/html; charset="euc-kr"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13
cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFm
dGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZv
bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2PkhpIFBhdWwsPC9kaXY+DQo8
ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Zb3UgbWF5IGFsc28gd2FudCB0byBsbyBhdCBvdGhlciBQ
UyBkb2N1bWVudHMsIHN1Y2ggYXMgUkZDIDQ4MzAgb24gaG93IHRvIGNhcHR1cmUgdGhlIHByb2Js
ZW0gc3RhdGVtZW50IHdpdGhvdXQgZ2V0dGluZyBpbnRvIHNvbHV0aW9uIHNwYWNlLjwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U3JpPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0
eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0
OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBt
ZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJ
TkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdI
VDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp
Z2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtNci4gSmFlaG9vbiBQYXVsIEplb25nJnF1b3Q7
ICZsdDs8YSBocmVmPSJtYWlsdG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbSI+amFlaG9vbi5wYXVs
QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRh
dGU6IDwvc3Bhbj5UdWVzZGF5LCBGZWJydWFyeSA1LCAyMDE5IGF0IDc6NDYgQU08YnI+DQo8c3Bh
biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5DQVJMT1MgSkVTVVMgQkVSTkFS
RE9TIENBTk8gJmx0OzxhIGhyZWY9Im1haWx0bzpjamJjQGl0LnVjM20uZXMiPmNqYmNAaXQudWMz
bS5lczwvYT4mZ3Q7LCBTcmkgR3VuZGF2ZWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNndW5kYXZl
QGNpc2NvLmNvbSI+c2d1bmRhdmVAY2lzY28uY29tPC9hPiZndDssICZxdW90O0NoYXJsZXMgRS4g
UGVya2lucyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxp
bmsubmV0Ij5jaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+SnVuZy1Tb28gUGFyayAmbHQ7PGEg
aHJlZj0ibWFpbHRvOnBqc0BldHJpLnJlLmtyIj5wanNAZXRyaS5yZS5rcjwvYT4mZ3Q7LCBKYWVo
b29uIEplb25nICZsdDs8YSBocmVmPSJtYWlsdG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbSI+amFl
aG9vbi5wYXVsQGdtYWlsLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aXRzQGll
dGYub3JnIj5pdHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aXRzQGll
dGYub3JnIj5pdHNAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86aXB3
YXZlLWNoYWlyc0BpZXRmLm9yZyI+aXB3YXZlLWNoYWlyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0
OzxhIGhyZWY9Im1haWx0bzppcHdhdmUtY2hhaXJzQGlldGYub3JnIj5pcHdhdmUtY2hhaXJzQGll
dGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpza2t1X2lvdGxhYl9zZW1pbmFy
QGdtYWlsLmNvbSI+c2trdV9pb3RsYWJfc2VtaW5hckBnbWFpbC5jb208L2E+JnF1b3Q7ICZsdDs8
YSBocmVmPSJtYWlsdG86c2trdV9pb3RsYWJfc2VtaW5hckBnbWFpbC5jb20iPnNra3VfaW90bGFi
X3NlbWluYXJAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6
Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbaXB3YXZlXSBSZXF1ZXN0IGZvciBJUFdBVkUgUFMg
RG9jdW1lbnQgUmV2aWV3PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2IGRpcj0iYXV0byI+SGkgQ2FybG9zLA0KPGRpdiBkaXI9ImF1dG8iPndlIGF1dGhv
cnMgd2lsbCBhZGRyZXNzIENoYXJsaWUncyBhbmQgU3JpJ3MgY29tbWVudHMgYW5kIHF1ZXN0aW9u
cy48L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5D
aGFybGllIGFuZCBTcmksPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+VGhhbmtzIGZvciB5b3VyIHNp
bmNlcmUgaGVscC48L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGly
PSJhdXRvIj5CZXN0IFJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+UGF1bDwvZGl2Pg0K
PC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBj
bGFzcz0iZ21haWxfYXR0ciI+MjAxObPiIDK/+SA1wM8gKMitKSC/wMjEIDQ6MjgsIENBUkxPUyBK
RVNVUyBCRVJOQVJET1MgQ0FOTyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNqYmNAaXQudWMzbS5lcyI+
Y2piY0BpdC51YzNtLmVzPC9hPiZndDu01MDMIMDbvLo6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVm
dDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPlRoYW5r
cyBDaGFybGllIQ0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QXV0aG9ycywgcGxlYXNlIHJldmlz
ZSBjb25zaWRlcmluZyB0aGlzIHJldmlldy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2
PlRoYW5rcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNhcmxvczwvZGl2Pg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0K
PGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFR1ZSwgRmViIDUsIDIwMTkgYXQg
MjoxOCBBTSBDaGFybGllIFBlcmtpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpjaGFybGVzLnBlcmtp
bnNAZWFydGhsaW5rLm5ldCIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+Y2hhcmxl
cy5wZXJraW5zQGVhcnRobGluay5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhl
eDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4
Ij4NCjxkaXYgYmdjb2xvcj0iI0ZGRkZGRiI+DQo8cD5IZWxsbyBQYXVsIGFuZCBhbGwsPC9wPg0K
PHA+QXR0YWNoZWQsIHBsZWFzZSBmaW5kIGEgZmlsZSB3aXRoIG15IGNvbW1lbnRzIGVtYmVkZGVk
LiZuYnNwOyBJIGFsc28gaW5jbHVkZSB0aGUgb3V0cHV0IG9mIHJmY2RpZmYsIGhpZ2hsaWdodGlu
ZyB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiByZXZpc2lvbiAuLi4tMDcgYW5kIHRoZSB0ZXh0IHdp
dGggbXkgY29tbWVudHMsIHNvIHRoYXQgeW91IGNhbiBlYXNpbHkgZmluZCB0aGVtLjwvcD4NCjxw
Pkkgd291bGQgbGlrZSB0byBzdWdnZXN0IHRoYXQgdGhlIGF1dGhvcnNoaXAgYXMgc2hvd24gYXQg
dGhlIGJvdHRvbSBvZiBlYWNoIHBhZ2Ugc2hvdWxkIGJlICZxdW90O0plb25nLCBFZC4mcXVvdDsg
aW5zdGVhZCBvZiBzaW1wbHkgJnF1b3Q7SmVvbmcmcXVvdDsuJm5ic3A7IFRoaXMgY2hhbmdlIHRv
IHRoZSB0ZXh0IGlzIG5vdCB2aXNpYmxlIGluIHRoZSByZmNkaWZmIG91dHB1dC48L3A+DQo8cD5J
IHdpbGwgdHJhbnNjcmliZSBzb21lIG9mIHRoZSBsYXJnZXIgaXNzdWVzIGludG8gYSBmb2xsb3ct
dXAgZW1haWwgdG8gdGhlIFdHIG1haWxpbmcgbGlzdCwgdW5sZXNzIHlvdSB0aGluayB0aGF0IHdv
dWxkIGJlIGNvdW50ZXJwcm9kdWN0aXZlLjwvcD4NCjxwPkkgaG9wZSB0aGVzZSBjb21tZW50cyBh
cmUgaGVscGZ1bC4mbmJzcDsgSWYgeW91IGhhdmUgcXVlc3Rpb25zIG9yIHdhbnQgY2xhcmlmaWNh
dGlvbnMsIHBsZWFzZSBkbyBub3QgaGVzaXRhdGUgdG8gY29udGFjdCBtZS48L3A+DQo8cD5SZWdh
cmRzLDxicj4NCkNoYXJsaWUgUC48YnI+DQo8L3A+DQo8ZGl2IGNsYXNzPSJtXy04NzkzMjMyMTY4
MTgwMzg4MjY2Z21haWwtbV8tNDg1NzY3Nzk5MDIxNDIxOTI4NG1vei1jaXRlLXByZWZpeCI+T24g
Mi80LzIwMTkgMjoxMyBQTSwgQ2hhcmxpZSBQZXJraW5zIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cD5IZWxsbyBmb2xrcyw8L3A+DQo8cD5JIGhhZCB2ZXJ5
IGJhZCBjb25uZWN0aXZpdHkgZHVyaW5nIG15IHZhY2F0aW9uLCBmcm9tIHdoaWNoIEkgcmV0dXJu
ZWQgeWVzdGVyZGF5LjwvcD4NCjxwPkkgaG9wZSB0byBzZW5kIGVkaXRvcmlhbCBjb21tZW50cyBs
YXRlciB0b2RheS48L3A+DQo8cD5JIHRob3VnaHQgYWJvdXQgYSBnb29kIHdheSB0byByZW9yZ2Fu
aXplIHRoZSBtYXRlcmlhbCBpbiB0aGUgZG9jdW1lbnQsIHdoaWNoIEkgd2lsbCBzdWJtaXQgdG8g
dGhlIG1haWxpbmcgbGlzdC4mbmJzcDsgSSBob3BlIHRoaXMgaXMgbm90IGFza2luZyB0b28gbXVj
aC48L3A+DQo8cD5SZWdhcmRzLDxicj4NCkNoYXJsaWUgUC48YnI+DQo8L3A+DQo8ZGl2IGNsYXNz
PSJtXy04NzkzMjMyMTY4MTgwMzg4MjY2Z21haWwtbV8tNDg1NzY3Nzk5MDIxNDIxOTI4NG1vei1j
aXRlLXByZWZpeCI+T24gMS8yMS8yMDE5IDk6NTMgUE0sIENoYXJsaWUgUGVya2lucyB3cm90ZTo8
YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHA+SGVsbG8gZm9sa3MsPC9w
Pg0KPHA+SSByZXZpZXdlZCB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQgZG9jdW1lbnQuJm5ic3A7IFRo
ZXJlIGlzIGEgbG90IG9mIGludGVyZXN0aW5nIG1hdGVyaWFsIGluIHRoZSBkb2N1bWVudCwgYnV0
IGl0IG5lZWRzIHRvIGJlIHNoYXJwZW5lZCB1cCBhIGxvdCBhbmQgcG9zc2libHkgcmVvcmdhbml6
ZWQgYSBsaXR0bGUgYml0LiZuYnNwOyBVbmZvcnR1bmF0ZWx5LCBJIGRvbid0IGhhdmUgYW4gb3V0
bGluZSB0byBzdWdnZXN0IGZvciBob3cgdG8gc2h1ZmZsZSB0aGUgdGV4dCwNCiBidXQgc29tZSBv
ZiB0aGUgcG9pbnRzIGJlbG93IGNvdWxkIGJlIGNvbnNpZGVyZWQgc3ltcHRvbXMgdGhhdCBoYXZl
IGxlZCBtZSB0byBzdWdnZXN0IGl0LjwvcD4NCjxwPi0gVGhlIGNpdGF0aW9ucyBpbiBzZWN0aW9u
IDQuMSBzZWVtIHRvIGJlIHNvbWV3aGF0IGFyYml0cmFyeSBhbmQgd291bGQgYmUgbW9yZSBpbnN0
cnVjdGl2ZSBpZiB0aGVyZSB3ZXJlIGEgZmV3IG1vcmUgcG9pbnRzIG9mIGNvbnRyYXN0IGRyYXdu
IGJldHdlZW4gdGhlIGV4YW1wbGVzLiZuYnNwOyBTZWN0aW9uIDQuMS4zIGlzIHNob3J0IGJ1dCBz
dGlsbCBzZWVtcyBhcmJpdHJhcnkgYW5kIHJhbmRvbS4mbmJzcDsgT3RoZXIgc2VjdGlvbnMgYXJl
IGV2ZW4gbW9yZQ0KIHNvLiZuYnNwOyBJdCB3b3VsZCBiZSBuaWNlIHRvIHNvbWVob3cgcmVsYXRl
IHRoZSB2YXJpb3VzIGV4YW1wbGVzIHNvIHRoYXQgdGhlIG92ZXJhbGwgZWZmZWN0IG1pZ2h0IGJl
IG1vcmUgY29oZXJlbnQuPC9wPg0KPHA+LSBUaGUgYXJjaGl0ZWN0dXJhbCBmaWd1cmVzIGRpc3Bs
YXllZCBpbiBzZWN0aW9uIDQuMiBzZWVtIHZlcnkgdmVyYm9zZSBhbmQgbm90IHRlcnJpYmx5IGRp
ZmZlcmVudCBmcm9tIG9uZSBhbm90aGVyLiZuYnNwOyBJdCBzZWVtcyB0aGF0IGV2ZXJ5IC82NCBo
YXMgYSBETlMsIGFuZCBhIHJvdXRlci4mbmJzcDsgVGhlIGRpc3RpbmN0aW9ucyBhcmUgYnVyaWVk
IGluIGEgbG90IG9mIHdvcmRzIGFuZCBpdCdzIGhhcmQgdG8gZ2V0IHRvIHRoZSBwb2ludC4mbmJz
cDsgSSB0aGluaw0KIHRoZXJlIGFyZSB0b28gbWFueSBwbGFjZXMgd2hlcmUgdGhlIGNhbmRpZGF0
ZSB3aXJlbGVzcyB0ZWNobm9sb2dpZXMgYXJlIGxpc3RlZCB0b2dldGhlciwgd2l0aG91dCBwcm92
aWRpbmcgYW55IHNpZ25pZmljYW50IGV4dHJhIGluc2lnaHQgaW50byB0aGUgYXJjaGl0ZWN0dXJh
bCByZWxhdGlvbnNoaXBzIG9mIHRoZSBlbnRpdGllcy48L3A+DQo8cD4tIEluIHNlY3Rpb24gNS4x
LCBpdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBOQSBpbnRlcnZhbCBkZWNyZWFzZSBhbmQgaW5j
cmVhc2UuJm5ic3A7IE1heWJlIGEgY291cGxlIG9mIGNvbmNyZXRlIGV4YW1wbGVzIHdvdWxkIGJl
IGhlbHBmdWwsIGdpdmVuIGtub3duIHZlaGljbGUgZGVuc2l0aWVzIGFuZCBzcGVlZHMuPGJyPg0K
PC9wPg0KPHA+LSBJbiBzZWN0aW9uIDUuMiwgaXQgc2hvdWxkIGJlIG1lbnRpb25lZCB0aGF0IGhh
dmluZyByb2FkbWFwcyBhbGxvd3MgYSB0ZXJyaWZpYyBpbmNyZWFzZSBpbiBwcmVkaWN0YWJpbGl0
eSBvZiB2ZWhpY2xlIG1vYmlsaXR5LjwvcD4NCjxwPi0gQXBwZW5kaXggQSB3YXMgYSB3ZWxjb21l
IGNoYW5nZSB0byB0aGUgcHJldmlvdXMgcGFydHMgb2YgdGhlIGRvY3VtZW50LiZuYnNwOyBJdCBo
YXMgYSBsb3Qgb2YgaW50ZXJlc3RpbmcgaW5mb3JtYXRpb24sIHN1Y2NpbmN0bHkgcHJlc2VudGVk
LiZuYnNwOyBJIHRob3VnaHQgbWF5YmUgaXQgc2hvdWxkIGJlIG1vdmVkIGludG8gdGhlIG1haW4g
Ym9keSBvZiB0aGUgdGV4dCwgcGVyaGFwcyBhcyBhIG5ldyBzZWN0aW9uIHByZWNlZGluZyB0aGUg
Y3VycmVudCAmcXVvdDtTZWN1cml0eQ0KIENvbnNpZGVyYXRpb25zJnF1b3Q7LjwvcD4NCjxwPkkg
aGF2ZSBhIG51bWJlciBvZiBzbWFsbGVyIGVkaXRvcmlhbCBzdWdnZXN0aW9ucyB0aGF0IEkgd2ls
bCBwcm92aWRlIHVuZGVyIHNlcGFyYXRlIGVtYWlsLjwvcD4NCjxwPkJvdHRvbSBsaW5lOiBJIHRo
aW5rIHRoZSBkb2N1bWVudCBpcyB3ZWxsIGFsb25nIHRoZSB3YXksIGJ1dCBuZWVkcyBjYXJlZnVs
IGZvY3VzIGFuZCBzb21lIHJlLWVtcGhhc2lzIG9mIHRoZSBjb21wb25lbnQgcGFydHMuPC9wPg0K
PHA+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb250aW51ZWQgZWZmb3J0IG9uIHRoaXMg
ZG9jdW1lbnQuPC9wPg0KPHA+UmVnYXJkcyw8YnI+DQpDaGFybGllIFAuPGJyPg0KPC9wPg0KPHA+
PGJyPg0KPC9wPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4gaWQ9Im1fLTg3OTMyMzIx
NjgxODAzODgyNjZnbWFpbC1tXy00ODU3Njc3OTkwMjE0MjE5Mjg0T0xLX1NSQ19CT0RZX1NFQ1RJ
T04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTFwdDt0ZXh0
LWFsaWduOmxlZnQ7Y29sb3I6YmxhY2s7Ym9yZGVyLXdpZHRoOjFwdCBtZWRpdW0gbWVkaXVtO2Jv
cmRlci1zdHlsZTpzb2xpZCBub25lIG5vbmU7Ym9yZGVyLWJvdHRvbS1jb2xvcjppbml0aWFsO2Jv
cmRlci1sZWZ0LWNvbG9yOmluaXRpYWw7cGFkZGluZzozcHQgMGluIDBpbjtib3JkZXItdG9wLWNv
bG9yOnJnYigxODEsMTk2LDIyMyk7Ym9yZGVyLXJpZ2h0LWNvbG9yOmluaXRpYWwiPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtNci4gSmFlaG9vbiBQ
YXVsIEplb25nJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86amFlaG9vbi5wYXVsQGdtYWlsLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+amFlaG9vbi5wYXVsQGdtYWlsLmNv
bTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bh
bj5UdWVzZGF5LCBKYW51YXJ5IDgsIDIwMTkgYXQgNzo1OSBBTTxicj4NCjxzcGFuIHN0eWxlPSJm
b250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkNoYXJsaWUgUGVya2lucyAmbHQ7PGEgaHJlZj0i
bWFpbHRvOkNoYXJsaWUuUGVya2luc0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJu
b3JlZmVycmVyIj5DaGFybGllLlBlcmtpbnNAaHVhd2VpLmNvbTwvYT4mZ3Q7LCBTcmkgR3VuZGF2
ZWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh
bmsiIHJlbD0ibm9yZWZlcnJlciI+c2d1bmRhdmVAY2lzY28uY29tPC9hPiZndDssDQogSnVuZy1T
b28gUGFyayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBqc0BldHJpLnJlLmtyIiB0YXJnZXQ9Il9ibGFu
ayIgcmVsPSJub3JlZmVycmVyIj5wanNAZXRyaS5yZS5rcjwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5
bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOml0
c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+aXRzQGlldGYub3Jn
PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOml0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiIHJlbD0ibm9yZWZlcnJlciI+aXRzQGlldGYub3JnPC9hPiZndDssICZxdW90O01yLiBKYWVo
b29uIFBhdWwgSmVvbmcmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqYWVob29uLnBhdWxAZ21h
aWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5qYWVob29uLnBhdWxAZ21h
aWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVj
dDogPC9zcGFuPlJlcXVlc3QgZm9yIElQV0FWRSBQUyBEb2N1bWVudCBSZXZpZXc8YnI+DQo8L2Rp
dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRp
diBkaXI9Imx0ciI+SGkgQ2hhcmxpZSwgU3JpLCBhbmQgSnVuZy1Tb28sDQo8ZGl2PkFzIHlvdSBh
Z3JlZWQgbGFzdCBJRVRGLTEwMyBtZWV0aW5nLCBjb3VsZCB5b3UgZ2l2ZSBtZSB5b3VyIHJldmll
dyBvbiZuYnNwOzwvZGl2Pg0KPGRpdj50aGUgSVBXQVZFIFBTIERvY3VtZW50IGJ5IEphbnVhcnkg
MTUsIDIwMTkgaW4gRVNUPzwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHdhdmUtdmVoaWN1bGFyLW5ldHdvcmtpbmctMDciIHRhcmdl
dD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1pZXRmLWlwd2F2ZS12ZWhpY3VsYXItbmV0d29ya2luZy0wNzwvYT48YnI+DQo8L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldlIG5lZWQgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhp
cyBkb2N1bWVudCBhbmQgdGhlIElQV0FWRSByZWNoYXJ0ZXJpbmcuLjwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+VGhhbmtzIGZvciB5b3VyIHZvbHVudGVlciBoZWxwLjwvZGl2Pg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxkaXY+QmVzdCBSZWdhcmRzLDwvZGl2Pg0KPGRpdj5QYXVsPGJyPg0K
LS0gPGJyPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9Im1fLTg3OTMyMzIxNjgxODAzODgyNjZnbWFp
bC1tXy00ODU3Njc3OTkwMjE0MjE5Mjg0Z21haWxfc2lnbmF0dXJlIj4NCjxkaXYgZGlyPSJsdHIi
Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4N
CjxkaXYgZGlyPSJsdHIiPj09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCk1yLiBKYWVo
b29uIChQYXVsKSBKZW9uZywgUGguRC48YnI+DQpBc3NvY2lhdGUgUHJvZmVzc29yPGJyPg0KRGVw
YXJ0bWVudCBvZiBTb2Z0d2FyZTxicj4NClN1bmdreXVua3dhbiBVbml2ZXJzaXR5PGJyPg0KT2Zm
aWNlOiAmIzQzOzgyLTMxLTI5OS00OTU3PGJyPg0KRW1haWw6IDxhIGhyZWY9Im1haWx0bzpqYWVo
b29uLnBhdWxAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5qYWVo
b29uLnBhdWxAZ21haWwuY29tPC9hPiwmbmJzcDs8YSBocmVmPSJtYWlsdG86cGF1bGplb25nQHNr
a3UuZWR1IiBzdHlsZT0iZm9udC1zaXplOjEyLjhweCIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9y
ZWZlcnJlciI+cGF1bGplb25nQHNra3UuZWR1PC9hPjxicj4NClBlcnNvbmFsIEhvbWVwYWdlOiA8
YSBocmVmPSJodHRwOi8vY3BzbGFiLnNra3UuZWR1L3Blb3BsZS1qYWVob29uLWplb25nLnBocCIg
dGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+DQpodHRwOi8vaW90bGFiLnNra3UuZWR1
L3Blb3BsZS1qYWVob29uLWplb25nLnBocDwvYT48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48YnI+DQo8ZmllbGRzZXQgY2xhc3M9Im1f
LTg3OTMyMzIxNjgxODAzODgyNjZnbWFpbC1tXy00ODU3Njc3OTkwMjE0MjE5Mjg0bWltZUF0dGFj
aG1lbnRIZWFkZXIiPg0KPC9maWVsZHNldD4NCjxwcmUgY2xhc3M9Im1fLTg3OTMyMzIxNjgxODAz
ODgyNjZnbWFpbC1tXy00ODU3Njc3OTkwMjE0MjE5Mjg0bW96LXF1b3RlLXByZSI+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCml0cyBtYWlsaW5nIGxpc3QN
CjxhIGNsYXNzPSJtXy04NzkzMjMyMTY4MTgwMzg4MjY2Z21haWwtbV8tNDg1NzY3Nzk5MDIxNDIx
OTI4NG1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOml0c0BpZXRmLm9yZyIg
dGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+aXRzQGlldGYub3JnPC9hPjxhIGNsYXNz
PSJtXy04NzkzMjMyMTY4MTgwMzg4MjY2Z21haWwtbV8tNDg1NzY3Nzk5MDIxNDIxOTI4NG1vei10
eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9pdHMiIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzPC9hPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9i
bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4N
CjwvaHRtbD4NCg==

--_000_D88047E22E6AB2sgundaveciscocom_--


From nobody Wed Feb  6 19:02:58 2019
Return-Path: 
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 729B9131001; Wed,  6 Feb 2019 19:02:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 DAPr_wxsmOpR; Wed,  6 Feb 2019 19:02:54 -0800 (PST)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 249ED128BCC; Wed,  6 Feb 2019 19:02:54 -0800 (PST)
Received: by mail-wr1-x433.google.com with SMTP id z15so7824316wrn.1; Wed, 06 Feb 2019 19:02:54 -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=pUC9852+kfFPnt6sJq9Fp1sq1ojI/3BLVJ9nz/1uze8=; b=omanuQ5LmamkiJqYZgxjwRtnbc1VAjdF/6yWoLAXShf687Jqaio+7yIn4LeQ9OVK19 WZMEnUQufusLqv4XiB8Uhl20XHLaiGqzP3O1ZigTZIw8N2CQ/FEAJ9TMch8OJDbvo161 lB7oZ0qF99jSPcDm9d0yfoCKyy1o1q0hqeUwRJoLVL7XQnHGONRnu8O8cfK6LWpAB2gC 9visJ/UMaNZABb1q8k6qNqw38j7MS4pBEXWOgst17TU3PIMJ5ZNr+q6yvCXJPitjURW+ pjjQbFVAA9xnMZENQ3Yig1yOyy53+aksMYsDC424a4anKF25586avZlW9V5IC7T0YQad FNaw==
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=pUC9852+kfFPnt6sJq9Fp1sq1ojI/3BLVJ9nz/1uze8=; b=PZu+yT8FPR16Upv7QN6NoIENm32IxpO2N3pDPsQcmmRoblTSQaUnFs3K1lGFchT2j2 edmgWK7yvSERd/fna7NBSAqPSLtPu9BJxmstrwN5BUQzea1vYvweFJearWDzQ1Ezyy2W IyuH39zwtHt+CXZFoUZq4KR6ksZuppf1XteUhOwIYz1y8jcM/es0Z8fwC6i4xZa5dGeY KadTVj4CJI6ZO2YrjMF9mEPNAIUNmZqiKoYaV5eDN52QDPwZgwsCWl8BTi3me2rdpNSg 2WHU7i2xEaEnqDh1nS//aCJC9eHW2vUvpb+r/nyAJQlgheYDexO6Pdef+9o973/oW76K ZLKA==
X-Gm-Message-State: AHQUAuYPYpnek4Vusd2rITY+kWaf8N39T03sY3kvdqC1Ld8BUwvNXQ2M Jxp8MqRuieMXWRL48L3qk9R3+0qQppHrZ5+2jkE=
X-Google-Smtp-Source: AHgI3Ia5XSXFsVpvpF4u+Z27v2I5GUgDwMmZ9kmHpLogqeD16MhHJzOXeHnWajqN1XaFUSl/Tn/SBUYkQcuGRAePUFY=
X-Received: by 2002:adf:9083:: with SMTP id i3mr10101342wri.124.1549508572466;  Wed, 06 Feb 2019 19:02:52 -0800 (PST)
MIME-Version: 1.0
References:   <12ee3e17-fcb6-cf9d-425b-5eb3bd0130bb@earthlink.net> <09a8ba4a-dc3b-1f96-96af-7923f950a909@earthlink.net>    
In-Reply-To: 
From: "Mr. Jaehoon Paul Jeong" 
Date: Thu, 7 Feb 2019 12:05:24 +0900
Message-ID: 
To: "Sri Gundavelli (sgundave)" 
Cc: CARLOS JESUS BERNARDOS CANO , "Charles E. Perkins" ,  Jung-Soo Park , "its@ietf.org" ,  "ipwave-chairs@ietf.org" ,  "skku_iotlab_seminar@gmail.com" 
Content-Type: multipart/alternative; boundary="00000000000009d3d80581451483"
Archived-At: 
Subject: Re: [ipwave] Request for IPWAVE PS Document Review
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2019 03:02:57 -0000

--00000000000009d3d80581451483
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Sri,
Sure, I will look at other PS documents including RFC 4830.

Thanks.

Best Regards,
Paul

On Thu, Feb 7, 2019 at 1:15 AM Sri Gundavelli (sgundave) 
wrote:

> Hi Paul,
>
> You may also want to lo at other PS documents, such as RFC 4830 on how to
> capture the problem statement without getting into solution space.
>
> Sri
>
>
> From: "Mr. Jaehoon Paul Jeong" 
> Date: Tuesday, February 5, 2019 at 7:46 AM
> To: CARLOS JESUS BERNARDOS CANO , Sri Gundavelli <
> sgundave@cisco.com>, "Charles E. Perkins" 
> Cc: Jung-Soo Park , Jaehoon Jeong ,
> "its@ietf.org" , "ipwave-chairs@ietf.org" <
> ipwave-chairs@ietf.org>, "skku_iotlab_seminar@gmail.com" <
> skku_iotlab_seminar@gmail.com>
> Subject: Re: [ipwave] Request for IPWAVE PS Document Review
>
> Hi Carlos,
> we authors will address Charlie's and Sri's comments and questions.
>
> Charlie and Sri,
> Thanks for your sincere help.
>
> Best Regards,
> Paul
>
> 2019=EB=85=84 2=EC=9B=94 5=EC=9D=BC (=ED=99=94) =EC=98=A4=ED=9B=84 4:28, =
CARLOS JESUS BERNARDOS CANO =EB=8B=98=EC=9D=B4
> =EC=9E=91=EC=84=B1:
>
>> Thanks Charlie!
>>
>> Authors, please revise considering this review.
>>
>> Thanks,
>>
>> Carlos
>>
>>
>> On Tue, Feb 5, 2019 at 2:18 AM Charlie Perkins <
>> charles.perkins@earthlink.net> wrote:
>>
>>> Hello Paul and all,
>>>
>>> Attached, please find a file with my comments embedded.  I also include
>>> the output of rfcdiff, highlighting the differences between revision ..=
.-07
>>> and the text with my comments, so that you can easily find them.
>>>
>>> I would like to suggest that the authorship as shown at the bottom of
>>> each page should be "Jeong, Ed." instead of simply "Jeong".  This chang=
e to
>>> the text is not visible in the rfcdiff output.
>>>
>>> I will transcribe some of the larger issues into a follow-up email to
>>> the WG mailing list, unless you think that would be counterproductive.
>>>
>>> I hope these comments are helpful.  If you have questions or want
>>> clarifications, please do not hesitate to contact me.
>>>
>>> Regards,
>>> Charlie P.
>>> On 2/4/2019 2:13 PM, Charlie Perkins wrote:
>>>
>>> Hello folks,
>>>
>>> I had very bad connectivity during my vacation, from which I returned
>>> yesterday.
>>>
>>> I hope to send editorial comments later today.
>>>
>>> I thought about a good way to reorganize the material in the document,
>>> which I will submit to the mailing list.  I hope this is not asking too
>>> much.
>>>
>>> Regards,
>>> Charlie P.
>>> On 1/21/2019 9:53 PM, Charlie Perkins wrote:
>>>
>>> Hello folks,
>>>
>>> I reviewed the Problem Statement document.  There is a lot of
>>> interesting material in the document, but it needs to be sharpened up a=
 lot
>>> and possibly reorganized a little bit.  Unfortunately, I don't have an
>>> outline to suggest for how to shuffle the text, but some of the points
>>> below could be considered symptoms that have led me to suggest it.
>>>
>>> - The citations in section 4.1 seem to be somewhat arbitrary and would
>>> be more instructive if there were a few more points of contrast drawn
>>> between the examples.  Section 4.1.3 is short but still seems arbitrary=
 and
>>> random.  Other sections are even more so.  It would be nice to somehow
>>> relate the various examples so that the overall effect might be more
>>> coherent.
>>>
>>> - The architectural figures displayed in section 4.2 seem very verbose
>>> and not terribly different from one another.  It seems that every /64 h=
as a
>>> DNS, and a router.  The distinctions are buried in a lot of words and i=
t's
>>> hard to get to the point.  I think there are too many places where the
>>> candidate wireless technologies are listed together, without providing =
any
>>> significant extra insight into the architectural relationships of the
>>> entities.
>>>
>>> - In section 5.1, it is recommended that the NA interval decrease and
>>> increase.  Maybe a couple of concrete examples would be helpful, given
>>> known vehicle densities and speeds.
>>>
>>> - In section 5.2, it should be mentioned that having roadmaps allows a
>>> terrific increase in predictability of vehicle mobility.
>>>
>>> - Appendix A was a welcome change to the previous parts of the
>>> document.  It has a lot of interesting information, succinctly presente=
d.
>>> I thought maybe it should be moved into the main body of the text, perh=
aps
>>> as a new section preceding the current "Security Considerations".
>>>
>>> I have a number of smaller editorial suggestions that I will provide
>>> under separate email.
>>>
>>> Bottom line: I think the document is well along the way, but needs
>>> careful focus and some re-emphasis of the component parts.
>>>
>>> Thank you very much for your continued effort on this document.
>>>
>>> Regards,
>>> Charlie P.
>>>
>>>
>>> From: "Mr. Jaehoon Paul Jeong" 
>>> Date: Tuesday, January 8, 2019 at 7:59 AM
>>> To: Charlie Perkins , Sri Gundavelli <
>>> sgundave@cisco.com>, Jung-Soo Park 
>>> Cc: "its@ietf.org" , "Mr. Jaehoon Paul Jeong" <
>>> jaehoon.paul@gmail.com>
>>> Subject: Request for IPWAVE PS Document Review
>>>
>>> Hi Charlie, Sri, and Jung-Soo,
>>> As you agreed last IETF-103 meeting, could you give me your review on
>>> the IPWAVE PS Document by January 15, 2019 in EST?
>>> https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-07
>>>
>>> We need to move forward with this document and the IPWAVE rechartering.=
.
>>>
>>> Thanks for your volunteer help.
>>>
>>> Best Regards,
>>> Paul
>>> --
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>>> Mr. Jaehoon (Paul) Jeong, Ph.D.
>>> Associate Professor
>>> Department of Software
>>> Sungkyunkwan University
>>> Office: +82-31-299-4957
>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
>>> 
>>>
>>> _______________________________________________
>>> its mailing listits@ietf.orghttps://www.ietf.org/mailman/listinfo/its
>>>
>>>

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php


--00000000000009d3d80581451483
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Sri,
Sure, I will look at other PS documents includ=
ing RFC 4830.

Thanks.

Bes=
t Regards,
Paul

On Thu, Feb 7, 2019 at 1:15 AM Sri Gundavell=
i (sgundave) <sgundave@cisco.com> wrote:







Hi Paul,







You may also want to lo at other PS documents, such as RFC 4830 on how=
 to capture the problem statement without getting into solution space.






Sri














From: "Mr. Jaehoon Paul Jeong&=
quot; <jaeho=
on.paul@gmail.com>

Date: Tuesday, February 5, 2019 at =
7:46 AM

To: CARLOS JESUS BERNARDOS CANO <=
;cjbc@it.uc3m.es&g=
t;, Sri Gundavelli <sgundave@cisco.com>, "Charles E. Perkins" <charles.perkins=
@earthlink.net>

Cc: Jung-Soo Park <pjs@etri.re.kr>, Jaehoon Jeon=
g <jaehoon.p=
aul@gmail.com>, "its@ietf.org" <its@ietf.org>,
 "ipwave-c=
hairs@ietf.org" <ipwave-chairs@ietf.org>, "skku_iotlab_seminar@gmail.com" <skku_iotlab_seminar@gmail.com>

Subject: Re: [ipwave] Request for I=
PWAVE PS Document Review













Hi Carlos,

we authors will address Charlie's and Sri's comme=
nts and questions.







Charlie and Sri,


Thanks for your sincere help.







Best Regards,


Paul








2019=EB=85=84 2=EC=9B=94 5=EC=9D=BC (=
=ED=99=94) =EC=98=A4=ED=9B=84 4:28, CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>=EB=8B=
=98=EC=9D=B4 =EC=9E=91=EC=84=B1:






Thanks Charlie!






Authors, please revise considering this review.







Thanks,







Carlos













On Tue, Feb 5, 2019 at 2:18 AM Charli=
e Perkins <charles.perkins@earthlink.net> wrote:








Hello Paul and all,


Attached, please find a file with my comments embedded.=C2=A0 I also inc=
lude the output of rfcdiff, highlighting the differences between revision .=
..-07 and the text with my comments, so that you can easily find them.


I would like to suggest that the authorship as shown at the bottom of ea=
ch page should be "Jeong, Ed." instead of simply "Jeong"=
;.=C2=A0 This change to the text is not visible in the rfcdiff output.


I will transcribe some of the larger issues into a follow-up email to th=
e WG mailing list, unless you think that would be counterproductive.


I hope these comments are helpful.=C2=A0 If you have questions or want c=
larifications, please do not hesitate to contact me.


Regards,

Charlie P.




On 2/4/2019 2:13 PM, Charlie Perkins wrote=
:






Hello folks,


I had very bad connectivity during my vacation, from which I returned ye=
sterday.


I hope to send editorial comments later today.


I thought about a good way to reorganize the material in the document, w=
hich I will submit to the mailing list.=C2=A0 I hope this is not asking too=
 much.


Regards,

Charlie P.




On 1/21/2019 9:53 PM, Charlie Perkins wrot=
e:






Hello folks,


I reviewed the Problem Statement document.=C2=A0 There is a lot of inter=
esting material in the document, but it needs to be sharpened up a lot and =
possibly reorganized a little bit.=C2=A0 Unfortunately, I don't have an=
 outline to suggest for how to shuffle the text,
 but some of the points below could be considered symptoms that have led me=
 to suggest it.


- The citations in section 4.1 seem to be somewhat arbitrary and would b=
e more instructive if there were a few more points of contrast drawn betwee=
n the examples.=C2=A0 Section 4.1.3 is short but still seems arbitrary and =
random.=C2=A0 Other sections are even more
 so.=C2=A0 It would be nice to somehow relate the various examples so that =
the overall effect might be more coherent.


- The architectural figures displayed in section 4.2 seem very verbose a=
nd not terribly different from one another.=C2=A0 It seems that every /64 h=
as a DNS, and a router.=C2=A0 The distinctions are buried in a lot of words=
 and it's hard to get to the point.=C2=A0 I think
 there are too many places where the candidate wireless technologies are li=
sted together, without providing any significant extra insight into the arc=
hitectural relationships of the entities.


- In section 5.1, it is recommended that the NA interval decrease and in=
crease.=C2=A0 Maybe a couple of concrete examples would be helpful, given k=
nown vehicle densities and speeds.




- In section 5.2, it should be mentioned that having roadmaps allows a t=
errific increase in predictability of vehicle mobility.


- Appendix A was a welcome change to the previous parts of the document.=
=C2=A0 It has a lot of interesting information, succinctly presented.=C2=A0=
 I thought maybe it should be moved into the main body of the text, perhaps=
 as a new section preceding the current "Security
 Considerations".


I have a number of smaller editorial suggestions that I will provide und=
er separate email.


Bottom line: I think the document is well along the way, but needs caref=
ul focus and some re-emphasis of the component parts.


Thank you very much for your continued effort on this document.


Regards,

Charlie P.












From: "Mr. Jaehoon Paul Jeong&=
quot; <jaehoon.paul@gmail.com>

Date: Tuesday, January 8, 2019 at 7=
:59 AM

To: Charlie Perkins <Cha=
rlie.Perkins@huawei.com>, Sri Gundavelli <sgundave@cisco.com&=
gt;,
 Jung-Soo Park <pjs@etri.re.kr>

Cc: "its@ietf.org" <its@ietf.o=
rg>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.c=
om>

Subject: Request for IPWAVE PS Docu=
ment Review















Hi Charlie, Sri, and Jung-Soo,

As you agreed last IETF-103 meeting, could you give me your review on=
=C2=A0


the IPWAVE PS Document by January 15, 2019 in EST?








We need to move forward with this document and the IPWAVE rechartering=
..







Thanks for your volunteer help.







Best Regards,


Paul

-- 
















=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D

Mr. Jaehoon (Paul) Jeong, Ph.D.

Associate Professor

Department of Software

Sungkyunkwan University

Office: +82-31-299-4957

Email: jaehoon.paul@gmail.com,=C2=A0pau=
ljeong@skku.edu

Personal Homepage: 
http://iotlab.skku.edu/people-jaehoon-jeong.php


































____________________________________________=
___
its mailing list
its@ietf.orghttps://www.ietf.org/mailman/listinfo/its




























-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.=
D.
Associate Professor
Department of Software
Sungkyunkwan Univers=
ity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeon=
g@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaeho=
on-jeong.php


--00000000000009d3d80581451483--


From nobody Fri Feb  8 07:37:26 2019
Return-Path: 
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 1598E1200D7; Fri,  8 Feb 2019 07:37:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 R8iguCnhfhnJ; Fri,  8 Feb 2019 07:37:14 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB811228B7; Fri,  8 Feb 2019 07:37:13 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x18FbAI9118983; Fri, 8 Feb 2019 16:37:10 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A8963204E2C; Fri,  8 Feb 2019 16:37:10 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 950DD204E19; Fri,  8 Feb 2019 16:37:10 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x18FbAfk006181; Fri, 8 Feb 2019 16:37:10 +0100
To: Abhijan Bhattacharyya , Carsten Bormann 
Cc: its@ietf.org, "core@ietf.org" 
References:  <08d7924f-55c5-f89a-c2f6-cccb3fa4d071@gmail.com>   <3c66d20e-2db2-7e15-6080-ce3646f848f6@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <603fbed4-0a32-456e-7883-28dbbc9f8ca4@gmail.com>
Date: Fri, 8 Feb 2019 16:37:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [ipwave] Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)'
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Feb 2019 15:37:17 -0000

Le 04/02/2019  20:00, Abhijan Bhattacharyya a crit:
> Thank you Carsten for your comments. No one can speak about CoAP better 
> than you!
> 
> Alex,
> I have uploaded a new version of the draft. The links are given at the 
> end of this mail. I have indeed tried to address your concern in respect 
> to making the draft more "IPv6-relevant".
> 
> As Carsten rightly pointed out that the proposal works at the 
> application layer and is built on the foundation of CoAP, so it is 
> Layer-3 agnostic. Also, as we all know, CoAP is designed for IPv6.
> However, implementation on IPv6 may influence the process of determining 
> the maximum size of information segments. So, a new subsection has been 
> added as part of the design guidelines. The small addition reads as below:
> 
> 
> 
> 6.3. Determining the segment size
> 
>     Size of the information segment in a CoAP message should be limited by the least
>     possible MTU for the end-to-end channel. This is to ensure that there is no
>     undesired conversation state at the lower layers of the protocol stack due to
>     uncontrolled fragmentation leading to undesired explosion of traffic in the
>     network. For IPV6 network, the MTU can be determined using Path MTU Discovery
>     (PMTUD) [RFC8201] which bestows the responsibility of determining the path MTU on
>     the end-points itself.
> 
>     The size of the segment should be guided by the recommendations as specified in
>     Section 4.6 of [RFC7252].
> 
> 
> 
> I hope this will now satisfy the criterion of finding IPv6 in the draft.

Thank you very much for this valuable action.

It is very worth taking into consideration.

 From an implementation standpoint, I would like to learn whether some 
prototype features RESTful Real-time Live Streaming on IPv6, or not on IPv6.

Alex

> 
> Looping in CoRE list as well to announce the new version to the WG where 
> this draft originates.
> 
> Thank you.
> 
> URL: 
> https://www.ietf.org/internet-drafts/draft-bhattacharyya-core-a-realist-01.txt
> Status: https://datatracker.ietf.org/doc/draft-bhattacharyya-core-a-realist/
> Htmlized: https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-01
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-bhattacharyya-core-a-realist
> Diff: 
> https://www.ietf.org/rfcdiff?url2=draft-bhattacharyya-core-a-realist-01
> 
> 
> With Best Regards
> Abhijan Bhattacharyya
> Consultant / Scientist,
> {Internet Protocols | 5G | Standardization},
> TCS Research,
> Tata Consultancy Services
> Building 1B,Ecospace
> Plot - IIF/12 ,New Town, Rajarhat,
> Kolkata - 700160,West Bengal
> India
> Ph:- +91 33 66884691
> Cell:- +919830468972 | +918583875003
> Mailto: abhijan.bhattacharyya@tcs.com 
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty. IT Services
> Business Solutions
> Consulting
> ____________________________________________
> 
> 
> -----"its" > wrote: -----
> To: "Alexandre Petrescu"  >
> From: "Carsten Bormann"
> Sent by: "its"
> Date: 01/31/2019 06:12PM
> Cc: "Abhijan Bhattacharyya"  >, "Michael Richardson" 
> >, its@ietf.org 
> 
> Subject: Re: [ipwave] Adaptive RESTful Real-time Live Streaming for 
> Things (A-REaLiST)'
> 
> "External email. Open with Caution"
> 
>  > If TCP's state machine was a bottleneck, has one tried to use UDP
>  > instead?
> 
> I think that is indeed one of the advantages CoAP brings go the table here.
> 
>  > Does CoAP work on Ethernet?
> 
> CoAP was designed to be able to run on UDP, which is on IP which in turn 
> works very well on Ethernet.
> 
>  > Does CoAP work in an end-to-end manner or does it need protocol
>  > conversion gateways?
> 
> I works end-to-end (as long as your network doesnt break UDP).
> 
>  > I want to ask you: please use IPv6 for CoAP and RESTful.
> 
> CoAP was designed to work well over IPv6 (but works as well over IPv4).
> 
>  > Then I searched for the keyword IPv6' in the draft.
>  > []
>  > If you add IPv6' considerations to it, then I will comment on it.
> 
> For a CoAP application such as A-REaLiST, IPv6 makes little difference 
> (beyond being able to assign addresses to both ends in the first place), 
> so I dont know there is a lot to say.
> 
> Gre, Carsten
> 
> _______________________________________________
> its mailing list
> its@ietf.org 
> https://www.ietf.org/mailman/listinfo/its
> 
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
> 


From nobody Wed Feb 13 22:29:43 2019
Return-Path: 
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 C57E9130F23; Wed, 13 Feb 2019 22:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tcs.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 lW9kc6Jcihq6; Wed, 13 Feb 2019 22:29:30 -0800 (PST)
Received: from indelg02.tcs.com (indelg02.tcs.com [203.200.109.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC6A128766; Wed, 13 Feb 2019 22:29:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcs.com; i=@tcs.com; q=dns/txt; s=default2048; t=1550125766; x=1581661766; h=in-reply-to:references:to:cc:mime-version:subject: message-id:from:date; bh=zqs69v3m1kRKMatJ5/6Jk27HzNmBWtlLETo5HPe5gcg=; b=Y7i8GbLN+l1rT/tOEhLUcEBIQglgVEu+aYf3l9/+XOmYSaLy4daa/fOy jnHUQY0uUlyqbGyCQXEuzBxarAxXiP5izNFzuEsiJt4hi40NlHunogkUF in/uwtLbd3snFAmxv5JS6ewFHVp9kgWs1ALdQzGUCtAu8ZwxUi7QEk4Hb apa3WSfGcCHC5cF2RBH6MF/CwOOt7DziQCraCpWuO7diF4Jq/Plvfw8nH 36G38dbmM4pnN8Egf3ofM4CdzjuvwYq/+U7+LD8o8L2RfTGhKaoktZBuz 6Z7SasaVwiknNSBKnF7Zvxn73ij8UlYM75sjo9IloSB1KDT0P7w3Da7aE Q==;
IronPort-PHdr: =?us-ascii?q?9a23=3AbKF3zRNlwmW/PObhwBEl6mtUPXoX/o7sNwtQ0K?= =?us-ascii?q?IMzox0K/zzpcbcNUDSrc9gkEXOFd2Cra4c26yO6+jJYi8p2d65qncMcZhBBV?= =?us-ascii?q?cuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx?= =?us-ascii?q?7xKRR6JvjvGo7Vks+7y/2+94fcbglUhzexe69+IAmrpgjNq8cahpdvJLwswR?= =?us-ascii?q?XTuHtIfOpWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3?= =?us-ascii?q?sp683xtBnMVhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Qi?= =?us-ascii?q?qp4bt1RxD0iScHLz85/3/Risxsl6JQvRatqwViz4LIfI2ZMfxzdb7fc9wHX2?= =?us-ascii?q?pMRsReVyJfDIyzcoUBCOkPM+ZWoYbhvFYBtweyCBO2Ce711jNFhHn71rA63e?= =?us-ascii?q?Q7FgHG2RQtEs4Vv3TUrdX1Nr0dUeaox6TVzTXMde9W2Svn54fUchAuu+uMXL?= =?us-ascii?q?JwcMXL1EIiEBnKgU6QqYzkPTOazOINv3KA4OpgT+2vl3InpBttrTiv3MgskI?= =?us-ascii?q?nIh4IPxV3f6SV23J01KcekR058ZN6pCZ1dvDyUOYtxR8MtWWBouCAix70Hp5?= =?us-ascii?q?G7YCYKxI4gxx7FZPyLa5SI7Q74VOqLPTh4g3dldbSijBix6Uit0vDwW8uq3F?= =?us-ascii?q?pQsyZIkcPAum4D2hDJ5cWKTOZ28F271jaVzQ/T7/lJIUUzlaXGNZEs2qUwlp?= =?us-ascii?q?8PsUTbGS/2hVn2gLeWdko6/uio7PzqbLb+qJGZLoF6jBzwP7golMKxB+o2KA?= =?us-ascii?q?8AUXaH9OihzLHj/Ev5T6tWjvAuj6XUso7WKd4GqqO6GQNZzIgu5wywAju+1d?= =?us-ascii?q?QXh3gHLFZLeBKdiIjpPknDL+rjAve/glSski1kx/bcMrL6ApXCNGTDkKv7cr?= =?us-ascii?q?lh605T0hAzzNBf5p1OEbwBPO78WlTruNPECR85NhS4w/z7B9VlyoMeRWWPD7?= =?us-ascii?q?eDP6PWr1CJ6fggI++Ra48PpjnxMeAl6ODyjX8jh1AdZrWm3YYMZXC3G/RpOU?= =?us-ascii?q?SZYX72jtgdFmcKuxI0TPb2h12aTT5Te3GyUrog6TE8EoKpE5zORoGzj7yd0i?= =?us-ascii?q?e3BJpWZnpJClqUC3fna52EW+sQaCKVOsJhkyAEVaO4R4A60hGuqQn6xKZ5Ie?= =?us-ascii?q?rP4SAYtIzs1MR75+HJkhEy7zN0BdyH026RV2F0gn8IRzgu0aB+vUx90UyO0a?= =?us-ascii?q?lmjPxEG9xf/fRJUh01NZTE1ex1F8jyWh7dfteOUFupXs+pDio2Tt8q398PYk?= =?us-ascii?q?d9F8+ljhDZ0Cr5S4MSwvaiAJEk+6TQxXW5H8th0Xvd37Rrxw0vRsZfPGuqnK?= =?us-ascii?q?M57wXPHYPSmFixmKOjdKBa1ynIojSt122L6WhSUA9yWKONd3AWelffptTw/F?= =?us-ascii?q?LTRvf6AL4nMwlIz4iIKqJWdtTijVxcVebqEMjVeCS6nGLmVkXA/a+FcIe/Iz?= =?us-ascii?q?ZV5y7aEkVR1llLpXs=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ADAAAZBWVc/wQXEqxjGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBVIEVgSqEBogajgODQYVpjmkUgWclAQyERwI?= =?us-ascii?q?Xg2Q0CQ0BAwEBAgEBAgGBCAyCOikBgmYBAQECAQEBASFLCwULCQIHBgQDAQI?= =?us-ascii?q?oAwICAh8GHwkIBgsIG4MFAYFaAw0XjXSabwEBAW+BL4QvAQMCAgxBQYJKDYI?= =?us-ascii?q?eiyeBPnd+JoJ/SQcuglciJQEBAQEBARaBCwkBCwYCATUJDIJdLQSCJgKJZyK?= =?us-ascii?q?HOYVziygaMwcCgjeFA4chPoNUgW4phSqLMY97gSuMbIEdcXBQgmwJhgGFFIV?= =?us-ascii?q?HagGNK4JNAQE?=
X-IPAS-Result: =?us-ascii?q?A2ADAAAZBWVc/wQXEqxjGgEBAQEBAgEBAQEHAgEBAQGBU?= =?us-ascii?q?QUBAQEBCwGBVIEVgSqEBogajgODQYVpjmkUgWclAQyERwIXg2Q0CQ0BAwEBA?= =?us-ascii?q?gEBAgGBCAyCOikBgmYBAQECAQEBASFLCwULCQIHBgQDAQIoAwICAh8GHwkIB?= =?us-ascii?q?gsIG4MFAYFaAw0XjXSabwEBAW+BL4QvAQMCAgxBQYJKDYIeiyeBPnd+JoJ/S?= =?us-ascii?q?QcuglciJQEBAQEBARaBCwkBCwYCATUJDIJdLQSCJgKJZyKHOYVziygaMwcCg?= =?us-ascii?q?jeFA4chPoNUgW4phSqLMY97gSuMbIEdcXBQgmwJhgGFFIVHagGNK4JNAQE?=
X-IronPort-AV: E=Sophos;i="5.58,367,1544466600"; d="scan'208";a="35666697"
X-DISCLAIMER: FALSE
In-Reply-To: <603fbed4-0a32-456e-7883-28dbbc9f8ca4@gmail.com>
References:  <08d7924f-55c5-f89a-c2f6-cccb3fa4d071@gmail.com>   <3c66d20e-2db2-7e15-6080-ce3646f848f6@gmail.com>  <603fbed4-0a32-456e-7883-28dbbc9f8ca4@gmail.com>
To: "Alexandre Petrescu" 
Cc: "Carsten Bormann" , "core@ietf.org" , its@ietf.org, "its" 
MIME-Version: 1.0
X-KeepSent: 48461931:293710BC-652583A1:0022701A; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
Message-ID: 
From: Abhijan Bhattacharyya 
Date: Thu, 14 Feb 2019 11:59:13 +0530
X-MIMETrack: Serialize by Router on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 02/14/2019 11:59:17, Serialize complete at 02/14/2019 11:59:17
Content-Type: multipart/alternative; boundary="=_alternative 0023A23F652583A1_="
Archived-At: 
Subject: Re: [ipwave] Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)'
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2019 06:29:34 -0000

This is a multipart message in MIME format.
--=_alternative 0023A23F652583A1_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

SGkgQWxleCwNCg0KPiBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGlzIHZhbHVhYmxlIGFjdGlv
bi4NCk15IHBsZWFzdXJlLiANCg0KDQo+IEl0IGlzIHZlcnkgd29ydGggdGFraW5nIGludG8gY29u
c2lkZXJhdGlvbi4NCg0KVGhhbmtzIGZvciB5b3UgaGVscCBpbiBpbXByb3ZlbWVudCBvZiB0aGUg
Y29udGVudHMgb2YgdGhlIHByb3Bvc2l0aW9uLg0KIA0KPiAgRnJvbSBhbiBpbXBsZW1lbnRhdGlv
biBzdGFuZHBvaW50LCBJIHdvdWxkIGxpa2UgdG8gbGVhcm4gd2hldGhlciBzb21lIA0KPiBwcm90
b3R5cGUgZmVhdHVyZXMgUkVTVGZ1bCBSZWFsLXRpbWUgTGl2ZSBTdHJlYW1pbmcgb24gSVB2Niwg
b3Igbm90IG9uIA0KSVB2Ni4NCj4gDQoNCldlIG1hZGUgYSBQb0Mgb2YgdGhlIGNvbmNlcHQgYW5k
IHRoZSBleHBlcmltZW50YXRpb24gYW5kIG91dGNvbWVzIGFyZSANCnByZXNlbnRlZCBpbiBQYWdl
cyA3OC04MCBvZiANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0
ZXJpYWxzL3NsaWRlcy0xMDMtY29yZS1jb25zb2xpZGF0ZWQtc2xpZGVzLTA3LnBkZg0KLg0KQnV0
IHdlIHVzZWQgSVB2NCBwaXBlLiBXaGlsZSBpdCBpcyB3b3J0aCB0byBkbyBhbiBleHBlcmltZW50
IG9uIGhvdyBJUHY2IA0KaW1wcm92ZXMgdGhlIHBlcmZvcm1hbmNlIChpdCBjYW4gb25seSBpbXBy
b3ZlIEkgYmVsaWV2ZSkuIEJ1dCBvdGhlcndpc2UgDQp0aGVyZSBzaG91bGQgbm90IGJlIG11Y2gg
b2YgYW4gaW1wYWN0IGhpZ2hlciB1cCBieSBhIGNoYW5nZSBpbiB0aGUgbmV0d29yayANCmxheWVy
IGJlY2F1c2UgQ29BUCBpcyBkZXNpZ25lZCB3aXRoIDZMb3dQQU4gcGlwZSBpbiBjb25zaWRlcmF0
aW9uIGFzIA0KYWxyZWFkeSBlbXBoYXNpc2VkIGJ5IENhcnN0ZW4uIA0KDQpNYXkgYmUgd2UgY2Fu
IGRpc2N1c3MgYXQgbGVuZ3RoIGlmIHdlIGdldCBhbiBvcHBvcnR1bml0eSB0byBwcmVzZW50IHRo
aXMgDQppbiBhIHBoeXNpY2FsIG1lZXRpbmcuDQoNClRoYW5rIHlvdS4NCg0KV2l0aCBCZXN0IFJl
Z2FyZHMNCkFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KQ29uc3VsdGFudCAvIFNjaWVudGlzdCwNCntJ
bnRlcm5ldCBQcm90b2NvbHMgfCA1RyB8IFN0YW5kYXJkaXphdGlvbn0sIA0KVENTIFJlc2VhcmNo
LA0KVGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlcw0KQnVpbGRpbmcgMUIsRWNvc3BhY2UNClBsb3Qg
LSAgSUlGLzEyICxOZXcgVG93biwgUmFqYXJoYXQsDQpLb2xrYXRhIC0gNzAwMTYwLFdlc3QgQmVu
Z2FsDQpJbmRpYQ0KUGg6LSArOTEgMzMgNjY4ODQ2OTENCkNlbGw6LSArOTE5ODMwNDY4OTcyIHwg
KzkxODU4Mzg3NTAwMw0KTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbQ0KV2Vi
c2l0ZTogaHR0cDovL3d3dy50Y3MuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICAgSVQgU2VydmljZXMNCiAgICAg
ICAgICAgICAgICAgICAgICAgIEJ1c2luZXNzIFNvbHV0aW9ucw0KICAgICAgICAgICAgICAgICAg
ICAgICAgQ29uc3VsdGluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCg0KDQoiaXRzIiA8aXRzLWJvdW5jZXNAaWV0Zi5vcmc+IHdyb3RlIG9uIDAyLzA4LzIw
MTkgMDk6MDc6MTAgUE06DQoNCj4gRnJvbTogIkFsZXhhbmRyZSBQZXRyZXNjdSIgPGFsZXhhbmRy
ZS5wZXRyZXNjdUBnbWFpbC5jb20+DQo+IFRvOiAiQWJoaWphbiBCaGF0dGFjaGFyeXlhIiA8YWJo
aWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+LCANCj4gIkNhcnN0ZW4gQm9ybWFubiIgPGNhYm9A
dHppLm9yZz4NCj4gQ2M6ICJjb3JlQGlldGYub3JnIiA8Y29yZUBpZXRmLm9yZz4sIGl0c0BpZXRm
Lm9yZw0KPiBEYXRlOiAwMi8wOC8yMDE5IDA5OjA4IFBNDQo+IFN1YmplY3Q6IFJlOiBbaXB3YXZl
XSBBZGFwdGl2ZSBSRVNUZnVsIFJlYWwtdGltZSBMaXZlIFN0cmVhbWluZyBmb3IgDQo+IFRoaW5n
cyAoQS1SRWFMaVNUKScNCj4gU2VudCBieTogIml0cyIgPGl0cy1ib3VuY2VzQGlldGYub3JnPg0K
PiANCj4gIkV4dGVybmFsIGVtYWlsLiBPcGVuIHdpdGggQ2F1dGlvbiINCj4gDQo+IA0KPiBMZSAw
NC8wMi8yMDE5IMOgIDIwOjAwLCBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgYSDDqWNyaXQgOg0KPiA+
IFRoYW5rIHlvdSBDYXJzdGVuIGZvciB5b3VyIGNvbW1lbnRzLiBObyBvbmUgY2FuIHNwZWFrIGFi
b3V0IENvQVAgDQpiZXR0ZXIgDQo+ID4gdGhhbiB5b3UhDQo+ID4gDQo+ID4gQWxleCwNCj4gPiBJ
IGhhdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIFRoZSBsaW5rcyBhcmUg
Z2l2ZW4gYXQgdGhlIA0KDQo+ID4gZW5kIG9mIHRoaXMgbWFpbC4gSSBoYXZlIGluZGVlZCB0cmll
ZCB0byBhZGRyZXNzIHlvdXIgY29uY2VybiBpbiANCnJlc3BlY3QgDQo+ID4gdG8gbWFraW5nIHRo
ZSBkcmFmdCBtb3JlICJJUHY2LXJlbGV2YW50Ii4NCj4gPiANCj4gPiBBcyBDYXJzdGVuIHJpZ2h0
bHkgcG9pbnRlZCBvdXQgdGhhdCB0aGUgcHJvcG9zYWwgd29ya3MgYXQgdGhlIA0KPiA+IGFwcGxp
Y2F0aW9uIGxheWVyIGFuZCBpcyBidWlsdCBvbiB0aGUgZm91bmRhdGlvbiBvZiBDb0FQLCBzbyBp
dCBpcyANCj4gPiBMYXllci0zIGFnbm9zdGljLiBBbHNvLCBhcyB3ZSBhbGwga25vdywgQ29BUCBp
cyBkZXNpZ25lZCBmb3IgSVB2Ni4NCj4gPiBIb3dldmVyLCBpbXBsZW1lbnRhdGlvbiBvbiBJUHY2
IG1heSBpbmZsdWVuY2UgdGhlIHByb2Nlc3Mgb2YgDQpkZXRlcm1pbmluZyANCj4gPiB0aGUgbWF4
aW11bSBzaXplIG9mIGluZm9ybWF0aW9uIHNlZ21lbnRzLiBTbywgYSBuZXcgc3Vic2VjdGlvbiBo
YXMgDQpiZWVuIA0KPiA+IGFkZGVkIGFzIHBhcnQgb2YgdGhlIGRlc2lnbiBndWlkZWxpbmVzLiBU
aGUgc21hbGwgYWRkaXRpb24gcmVhZHMgYXMgDQpiZWxvdzoNCj4gPiANCj4gPiA8UXVvdGU+DQo+
ID4gDQo+ID4gNi4zLiBEZXRlcm1pbmluZyB0aGUgc2VnbWVudCBzaXplDQo+ID4gDQo+ID4gICAg
IFNpemUgb2YgdGhlIGluZm9ybWF0aW9uIHNlZ21lbnQgaW4gYSBDb0FQIG1lc3NhZ2Ugc2hvdWxk
IGJlIA0KPiBsaW1pdGVkIGJ5IHRoZSBsZWFzdA0KPiA+ICAgICBwb3NzaWJsZSBNVFUgZm9yIHRo
ZSBlbmQtdG8tZW5kIGNoYW5uZWwuIFRoaXMgaXMgdG8gZW5zdXJlIA0KPiB0aGF0IHRoZXJlIGlz
IG5vDQo+ID4gICAgIHVuZGVzaXJlZCBjb252ZXJzYXRpb24gc3RhdGUgYXQgdGhlIGxvd2VyIGxh
eWVycyBvZiB0aGUgDQo+IHByb3RvY29sIHN0YWNrIGR1ZSB0bw0KPiA+ICAgICB1bmNvbnRyb2xs
ZWQgZnJhZ21lbnRhdGlvbiBsZWFkaW5nIHRvIHVuZGVzaXJlZCBleHBsb3Npb24gb2YgDQo+IHRy
YWZmaWMgaW4gdGhlDQo+ID4gICAgIG5ldHdvcmsuIEZvciBJUFY2IG5ldHdvcmssIHRoZSBNVFUg
Y2FuIGJlIGRldGVybWluZWQgdXNpbmcgDQo+IFBhdGggTVRVIERpc2NvdmVyeQ0KPiA+ICAgICAo
UE1UVUQpIFtSRkM4MjAxXSB3aGljaCBiZXN0b3dzIHRoZSByZXNwb25zaWJpbGl0eSBvZiANCj4g
ZGV0ZXJtaW5pbmcgdGhlIHBhdGggTVRVIG9uDQo+ID4gICAgIHRoZSBlbmQtcG9pbnRzIGl0c2Vs
Zi4NCj4gPiANCj4gPiAgICAgVGhlIHNpemUgb2YgdGhlIHNlZ21lbnQgc2hvdWxkIGJlIGd1aWRl
ZCBieSB0aGUgDQo+IHJlY29tbWVuZGF0aW9ucyBhcyBzcGVjaWZpZWQgaW4NCj4gPiAgICAgU2Vj
dGlvbiA0LjYgb2YgW1JGQzcyNTJdLg0KPiA+IA0KPiA+IDwvUXVvdGU+DQo+ID4gDQo+ID4gSSBo
b3BlIHRoaXMgd2lsbCBub3cgc2F0aXNmeSB0aGUgY3JpdGVyaW9uIG9mIGZpbmRpbmcgSVB2NiBp
biB0aGUgDQpkcmFmdC4NCj4gDQo+IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoaXMgdmFsdWFi
bGUgYWN0aW9uLg0KPiANCj4gSXQgaXMgdmVyeSB3b3J0aCB0YWtpbmcgaW50byBjb25zaWRlcmF0
aW9uLg0KPiANCj4gIEZyb20gYW4gaW1wbGVtZW50YXRpb24gc3RhbmRwb2ludCwgSSB3b3VsZCBs
aWtlIHRvIGxlYXJuIHdoZXRoZXIgc29tZSANCj4gcHJvdG90eXBlIGZlYXR1cmVzIFJFU1RmdWwg
UmVhbC10aW1lIExpdmUgU3RyZWFtaW5nIG9uIElQdjYsIG9yIG5vdCBvbiANCklQdjYuDQo+IA0K
PiBBbGV4DQo+IA0KPiA+IA0KPiA+IExvb3BpbmcgaW4gQ29SRSBsaXN0IGFzIHdlbGwgdG8gYW5u
b3VuY2UgdGhlIG5ldyB2ZXJzaW9uIHRvIHRoZSBXRyANCndoZXJlIA0KPiA+IHRoaXMgZHJhZnQg
b3JpZ2luYXRlcy4NCj4gPiANCj4gPiBUaGFuayB5b3UuDQo+ID4gDQo+ID4gVVJMOiANCj4gPiBo
dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmhhdHRhY2hhcnl5YS1j
b3JlLWEtDQo+IHJlYWxpc3QtMDEudHh0DQo+ID4gU3RhdHVzOiANCmh0dHBzOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJoYXR0YWNoYXJ5eWEtY29yZS1hLXJlYWxpc3QvDQo+ID4g
SHRtbGl6ZWQ6IA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJoYXR0YWNoYXJ5
eWEtY29yZS1hLXJlYWxpc3QtMDENCj4gPiBIdG1saXplZDogDQo+ID4gDQpodHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWJoYXR0YWNoYXJ5eWEtY29yZS1hLXJlYWxp
c3QNCj4gPiBEaWZmOiANCj4gPiANCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k
cmFmdC1iaGF0dGFjaGFyeXlhLWNvcmUtYS1yZWFsaXN0LTAxDQo+ID4gDQo+ID4gDQo+ID4gV2l0
aCBCZXN0IFJlZ2FyZHMNCj4gPiBBYmhpamFuIEJoYXR0YWNoYXJ5eWENCj4gPiBDb25zdWx0YW50
IC8gU2NpZW50aXN0LA0KPiA+IHtJbnRlcm5ldCBQcm90b2NvbHMgfCA1RyB8IFN0YW5kYXJkaXph
dGlvbn0sDQo+ID4gVENTIFJlc2VhcmNoLA0KPiA+IFRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXMN
Cj4gPiBCdWlsZGluZyAxQixFY29zcGFjZQ0KPiA+IFBsb3QgLSAgSUlGLzEyICxOZXcgVG93biwg
UmFqYXJoYXQsDQo+ID4gS29sa2F0YSAtIDcwMDE2MCxXZXN0IEJlbmdhbA0KPiA+IEluZGlhDQo+
ID4gUGg6LSArOTEgMzMgNjY4ODQ2OTENCj4gPiBDZWxsOi0gKzkxOTgzMDQ2ODk3MiB8ICs5MTg1
ODM4NzUwMDMNCj4gPiBNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tIDwNCm1h
aWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbT4NCj4gPiBXZWJzaXRlOiBodHRwOi8v
d3d3LnRjcy5jb20NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiA+IEV4cGVyaWVuY2UgY2VydGFpbnR5LiBJVCBTZXJ2aWNlcw0KPiA+IEJ1c2luZXNz
IFNvbHV0aW9ucw0KPiA+IENvbnN1bHRpbmcNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPiA+IA0KPiA+IA0KPiA+IC0tLS0tIml0cyIgPGl0cy1ib3Vu
Y2VzQGlldGYub3JnIDxtYWlsdG86aXRzLWJvdW5jZXNAaWV0Zi5vcmc+PiB3cm90ZTogDQotLS0t
LQ0KPiA+IFRvOiAiQWxleGFuZHJlIFBldHJlc2N1IiA8YWxleGFuZHJlLnBldHJlc2N1QGdtYWls
LmNvbSANCj4gPiA8bWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+Pg0KPiA+IEZy
b206ICJDYXJzdGVuIEJvcm1hbm4iDQo+ID4gU2VudCBieTogIml0cyINCj4gPiBEYXRlOiAwMS8z
MS8yMDE5IDA2OjEyUE0NCj4gPiBDYzogIkFiaGlqYW4gQmhhdHRhY2hhcnl5YSIgPGFiaGlqYW4u
YmhhdHRhY2hhcnl5YUB0Y3MuY29tIA0KPiA+IDxtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlh
QHRjcy5jb20+PiwgIk1pY2hhZWwgUmljaGFyZHNvbiIgDQo+ID4gPG1jckBzYW5kZWxtYW4uY2Eg
PG1haWx0bzptY3JAc2FuZGVsbWFuLmNhPj4sIGl0c0BpZXRmLm9yZyANCj4gPiA8bWFpbHRvOml0
c0BpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBSZTogW2lwd2F2ZV0gQWRhcHRpdmUgUkVTVGZ1bCBS
ZWFsLXRpbWUgTGl2ZSBTdHJlYW1pbmcgZm9yIA0KPiA+IFRoaW5ncyAoQS1SRWFMaVNUKScNCj4g
PiANCj4gPiAiRXh0ZXJuYWwgZW1haWwuIE9wZW4gd2l0aCBDYXV0aW9uIg0KPiA+IA0KPiA+ICA+
IElmIFRDUCdzIHN0YXRlIG1hY2hpbmUgd2FzIGEgYm90dGxlbmVjaywgaGFzIG9uZSB0cmllZCB0
byB1c2UgVURQDQo+ID4gID4gaW5zdGVhZD8NCj4gPiANCj4gPiBJIHRoaW5rIHRoYXQgaXMgaW5k
ZWVkIG9uZSBvZiB0aGUgYWR2YW50YWdlcyBDb0FQIGJyaW5ncyBnbyB0aGUgdGFibGUgDQpoZXJl
Lg0KPiA+IA0KPiA+ICA+IERvZXMgQ29BUCB3b3JrIG9uIEV0aGVybmV0Pw0KPiA+IA0KPiA+IENv
QVAgd2FzIGRlc2lnbmVkIHRvIGJlIGFibGUgdG8gcnVuIG9uIFVEUCwgd2hpY2ggaXMgb24gSVAg
d2hpY2ggaW4gDQp0dXJuIA0KPiA+IHdvcmtzIHZlcnkgd2VsbCBvbiBFdGhlcm5ldC4NCj4gPiAN
Cj4gPiAgPiBEb2VzIENvQVAgd29yayBpbiBhbiBlbmQtdG8tZW5kIG1hbm5lciBvciBkb2VzIGl0
IG5lZWQgcHJvdG9jb2wNCj4gPiAgPiBjb252ZXJzaW9uIGdhdGV3YXlzPw0KPiA+IA0KPiA+IEkg
d29ya3MgZW5kLXRvLWVuZCAoYXMgbG9uZyBhcyB5b3VyIG5ldHdvcmsgZG9lc27igJl0IGJyZWFr
IFVEUCkuDQo+ID4gDQo+ID4gID4gSSB3YW50IHRvIGFzayB5b3U6IHBsZWFzZSB1c2UgSVB2NiBm
b3IgQ29BUCBhbmQgUkVTVGZ1bC4NCj4gPiANCj4gPiBDb0FQIHdhcyBkZXNpZ25lZCB0byB3b3Jr
IHdlbGwgb3ZlciBJUHY2IChidXQgd29ya3MgYXMgd2VsbCBvdmVyIA0KSVB2NCkuDQo+ID4gDQo+
ID4gID4gVGhlbiBJIHNlYXJjaGVkIGZvciB0aGUga2V5d29yZCDigJhJUHY2JyBpbiB0aGUgZHJh
ZnQuDQo+ID4gID4gW+KApl0NCj4gPiAgPiBJZiB5b3UgYWRkIOKAmElQdjYnIGNvbnNpZGVyYXRp
b25zIHRvIGl0LCB0aGVuIEkgd2lsbCBjb21tZW50IG9uIGl0Lg0KPiA+IA0KPiA+IEZvciBhIENv
QVAgYXBwbGljYXRpb24gc3VjaCBhcyBBLVJFYUxpU1QsIElQdjYgbWFrZXMgbGl0dGxlIGRpZmZl
cmVuY2UgDQoNCj4gPiAoYmV5b25kIGJlaW5nIGFibGUgdG8gYXNzaWduIGFkZHJlc3NlcyB0byBi
b3RoIGVuZHMgaW4gdGhlIGZpcnN0IA0KcGxhY2UpLCANCj4gPiBzbyBJIGRvbuKAmXQga25vdyB0
aGVyZSBpcyBhIGxvdCB0byBzYXkuDQo+ID4gDQo+ID4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiA+IA0K
PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g
aXRzIG1haWxpbmcgbGlzdA0KPiA+IGl0c0BpZXRmLm9yZyA8bWFpbHRvOml0c0BpZXRmLm9yZz4N
Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPiA+IA0KPiA+
ID09PT09LS0tLS09PT09PS0tLS0tPT09PT0NCj4gPiBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj
b250YWluZWQgaW4gdGhpcyBlLW1haWwNCj4gPiBtZXNzYWdlIGFuZC9vciBhdHRhY2htZW50cyB0
byBpdCBtYXkgY29udGFpbg0KPiA+IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0
aW9uLiBJZiB5b3UgYXJlDQo+ID4gbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNz
ZW1pbmF0aW9uLCB1c2UsDQo+ID4gcmV2aWV3LCBkaXN0cmlidXRpb24sIHByaW50aW5nIG9yIGNv
cHlpbmcgb2YgdGhlDQo+ID4gaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1l
c3NhZ2UNCj4gPiBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0
ZWQuIElmDQo+ID4geW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y
LA0KPiA+IHBsZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgZS1tYWlsIG9yIHRlbGVwaG9uZSBhbmQN
Cj4gPiBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlDQo+ID4g
YW5kIGFueSBhdHRhY2htZW50cy4gVGhhbmsgeW91DQo+ID4gDQo+IA0KPiBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBpdHMgbWFpbGluZyBsaXN0DQo+
IGl0c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0
cw0KPiANCg0K
--=_alternative 0023A23F652583A1_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFsZXgsPC9mb250Pg0KPGJyPg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGlzIHZhbHVh
YmxlIGFjdGlvbi48YnI+DQpNeSBwbGVhc3VyZS4gPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEl0IGlzIHZlcnkgd29ydGggdGFraW5nIGludG8gY29u
c2lkZXJhdGlvbi48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlRoYW5r
cyBmb3IgeW91IGhlbHAgaW4gaW1wcm92ZW1lbnQgb2YgdGhlIGNvbnRlbnRzDQpvZiB0aGUgcHJv
cG9zaXRpb24uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDs8YnI+DQom
Z3Q7ICZuYnNwO0Zyb20gYW4gaW1wbGVtZW50YXRpb24gc3RhbmRwb2ludCwgSSB3b3VsZCBsaWtl
IHRvIGxlYXJuIHdoZXRoZXINCnNvbWUgPGJyPg0KJmd0OyBwcm90b3R5cGUgZmVhdHVyZXMgUkVT
VGZ1bCBSZWFsLXRpbWUgTGl2ZSBTdHJlYW1pbmcgb24gSVB2Niwgb3Igbm90DQpvbiBJUHY2Ljxi
cj4NCiZndDsgPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt
c2VyaWYiPldlIG1hZGUgYSBQb0Mgb2YgdGhlIGNvbmNlcHQgYW5kIHRoZQ0KZXhwZXJpbWVudGF0
aW9uIGFuZCBvdXRjb21lcyBhcmUgcHJlc2VudGVkIGluIFBhZ2VzIDc4LTgwIG9mIDwvZm9udD48
YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAzL21hdGVyaWFs
cy9zbGlkZXMtMTAzLWNvcmUtY29uc29saWRhdGVkLXNsaWRlcy0wNy5wZGYiPjxmb250IHNpemU9
MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvbWVldGluZy8xMDMvbWF0ZXJpYWxzL3NsaWRlcy0xMDMtY29yZS1jb25zb2xpZGF0ZWQtc2xp
ZGVzLTA3LnBkZjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi48L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJ1dCB3ZSB1c2VkIElQdjQg
cGlwZS4gV2hpbGUgaXQgaXMgd29ydGgNCnRvIGRvIGFuIGV4cGVyaW1lbnQgb24gaG93IElQdjYg
aW1wcm92ZXMgdGhlIHBlcmZvcm1hbmNlIChpdCBjYW4gb25seSBpbXByb3ZlDQpJIGJlbGlldmUp
LiBCdXQgb3RoZXJ3aXNlIHRoZXJlIHNob3VsZCBub3QgYmUgbXVjaCBvZiBhbiBpbXBhY3QgaGln
aGVyDQp1cCBieSBhIGNoYW5nZSBpbiB0aGUgbmV0d29yayBsYXllciBiZWNhdXNlIENvQVAgaXMg
ZGVzaWduZWQgd2l0aCA2TG93UEFODQpwaXBlIGluIGNvbnNpZGVyYXRpb24gYXMgYWxyZWFkeSBl
bXBoYXNpc2VkIGJ5IENhcnN0ZW4uIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj
ZT0ic2Fucy1zZXJpZiI+TWF5IGJlIHdlIGNhbiBkaXNjdXNzIGF0IGxlbmd0aCBpZiB3ZQ0KZ2V0
IGFuIG9wcG9ydHVuaXR5IHRvIHByZXNlbnQgdGhpcyBpbiBhIHBoeXNpY2FsIG1lZXRpbmcuPC9m
b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFuayB5b3Uu
PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XaXRoIEJl
c3QgUmVnYXJkczxicj4NCkFiaGlqYW4gQmhhdHRhY2hhcnl5YTxicj4NCkNvbnN1bHRhbnQgLyBT
Y2llbnRpc3QsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj57SW50
ZXJuZXQgUHJvdG9jb2xzIHwgNUcgfCBTdGFuZGFyZGl6YXRpb259LA0KPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UQ1MgUmVzZWFyY2gsPGJyPg0KVGF0YSBDb25z
dWx0YW5jeSBTZXJ2aWNlczxicj4NCkJ1aWxkaW5nIDFCLEVjb3NwYWNlPGJyPg0KUGxvdCAtICZu
YnNwO0lJRi8xMiAsTmV3IFRvd24sIFJhamFyaGF0LDxicj4NCktvbGthdGEgLSA3MDAxNjAsV2Vz
dCBCZW5nYWw8YnI+DQpJbmRpYTxicj4NClBoOi0gKzkxIDMzIDY2ODg0NjkxPGJyPg0KQ2VsbDot
ICs5MTk4MzA0Njg5NzIgfCArOTE4NTgzODc1MDAzPGJyPg0KTWFpbHRvOiBhYmhpamFuLmJoYXR0
YWNoYXJ5eWFAdGNzLmNvbTxicj4NCldlYnNpdGU6IDwvZm9udD48YSBocmVmPWh0dHA6Ly93d3cu
dGNzLmNvbS8+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly93d3cudGNzLmNv
bTwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRXhwZXJpZW5jZSBjZXJ0
YWludHkuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPGJyPg0KICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtDb25zdWx0aW5nPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp
emU9Mj4mcXVvdDtpdHMmcXVvdDsgJmx0O2l0cy1ib3VuY2VzQGlldGYub3JnJmd0OyB3cm90ZQ0K
b24gMDIvMDgvMjAxOSAwOTowNzoxMCBQTTo8YnI+DQo8YnI+DQomZ3Q7IEZyb206ICZxdW90O0Fs
ZXhhbmRyZSBQZXRyZXNjdSZxdW90OyAmbHQ7YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbSZn
dDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVG86ICZxdW90O0FiaGlq
YW4gQmhhdHRhY2hhcnl5YSZxdW90OyAmbHQ7YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20m
Z3Q7LA0KPGJyPg0KJmd0OyAmcXVvdDtDYXJzdGVuIEJvcm1hbm4mcXVvdDsgJmx0O2NhYm9AdHpp
Lm9yZyZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQ2M6ICZxdW90
O2NvcmVAaWV0Zi5vcmcmcXVvdDsgJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7LA0KaXRzQGlldGYub3Jn
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERhdGU6IDAyLzA4LzIwMTkg
MDk6MDggUE08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU3ViamVjdDog
UmU6IFtpcHdhdmVdIEFkYXB0aXZlIFJFU1RmdWwgUmVhbC10aW1lDQpMaXZlIFN0cmVhbWluZyBm
b3IgPGJyPg0KJmd0OyBUaGluZ3MgKEEtUkVhTGlTVCknPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm
b250IHNpemU9Mj4mZ3Q7IFNlbnQgYnk6ICZxdW90O2l0cyZxdW90OyAmbHQ7aXRzLWJvdW5jZXNA
aWV0Zi5vcmcmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4N
CiZndDsgJnF1b3Q7RXh0ZXJuYWwgZW1haWwuIE9wZW4gd2l0aCBDYXV0aW9uJnF1b3Q7PGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTGUgMDQvMDIvMjAxOSDDoCAyMDowMCwgQWJoaWph
biBCaGF0dGFjaGFyeXlhIGEgw6ljcml0Jm5ic3A7Ojxicj4NCiZndDsgJmd0OyBUaGFuayB5b3Ug
Q2Fyc3RlbiBmb3IgeW91ciBjb21tZW50cy4gTm8gb25lIGNhbiBzcGVhayBhYm91dCBDb0FQDQpi
ZXR0ZXIgPGJyPg0KJmd0OyAmZ3Q7IHRoYW4geW91ITxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgQWxleCw8YnI+DQomZ3Q7ICZndDsgSSBoYXZlIHVwbG9hZGVkIGEgbmV3IHZlcnNpb24g
b2YgdGhlIGRyYWZ0LiBUaGUgbGlua3MgYXJlIGdpdmVuDQphdCB0aGUgPGJyPg0KJmd0OyAmZ3Q7
IGVuZCBvZiB0aGlzIG1haWwuIEkgaGF2ZSBpbmRlZWQgdHJpZWQgdG8gYWRkcmVzcyB5b3VyIGNv
bmNlcm4NCmluIHJlc3BlY3QgPGJyPg0KJmd0OyAmZ3Q7IHRvIG1ha2luZyB0aGUgZHJhZnQgbW9y
ZSAmcXVvdDtJUHY2LXJlbGV2YW50JnF1b3Q7Ljxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgQXMgQ2Fyc3RlbiByaWdodGx5IHBvaW50ZWQgb3V0IHRoYXQgdGhlIHByb3Bvc2FsIHdvcmtz
IGF0IHRoZQ0KPGJyPg0KJmd0OyAmZ3Q7IGFwcGxpY2F0aW9uIGxheWVyIGFuZCBpcyBidWlsdCBv
biB0aGUgZm91bmRhdGlvbiBvZiBDb0FQLCBzbw0KaXQgaXMgPGJyPg0KJmd0OyAmZ3Q7IExheWVy
LTMgYWdub3N0aWMuIEFsc28sIGFzIHdlIGFsbCBrbm93LCBDb0FQIGlzIGRlc2lnbmVkIGZvcg0K
SVB2Ni48YnI+DQomZ3Q7ICZndDsgSG93ZXZlciwgaW1wbGVtZW50YXRpb24gb24gSVB2NiBtYXkg
aW5mbHVlbmNlIHRoZSBwcm9jZXNzIG9mDQpkZXRlcm1pbmluZyA8YnI+DQomZ3Q7ICZndDsgdGhl
IG1heGltdW0gc2l6ZSBvZiBpbmZvcm1hdGlvbiBzZWdtZW50cy4gU28sIGEgbmV3IHN1YnNlY3Rp
b24NCmhhcyBiZWVuIDxicj4NCiZndDsgJmd0OyBhZGRlZCBhcyBwYXJ0IG9mIHRoZSBkZXNpZ24g
Z3VpZGVsaW5lcy4gVGhlIHNtYWxsIGFkZGl0aW9uIHJlYWRzDQphcyBiZWxvdzo8YnI+DQomZ3Q7
ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZsdDtRdW90ZSZndDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7IDYuMy4gRGV0ZXJtaW5pbmcgdGhlIHNlZ21lbnQgc2l6ZTxicj4NCiZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBTaXplIG9mIHRoZSBpbmZvcm1hdGlvbiBz
ZWdtZW50IGluIGEgQ29BUCBtZXNzYWdlDQpzaG91bGQgYmUgPGJyPg0KJmd0OyBsaW1pdGVkIGJ5
IHRoZSBsZWFzdDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IHBvc3NpYmxlIE1UVSBmb3Ig
dGhlIGVuZC10by1lbmQgY2hhbm5lbC4gVGhpcyBpcw0KdG8gZW5zdXJlIDxicj4NCiZndDsgdGhh
dCB0aGVyZSBpcyBubzxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IHVuZGVzaXJlZCBjb252
ZXJzYXRpb24gc3RhdGUgYXQgdGhlIGxvd2VyIGxheWVycw0Kb2YgdGhlIDxicj4NCiZndDsgcHJv
dG9jb2wgc3RhY2sgZHVlIHRvPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgdW5jb250cm9s
bGVkIGZyYWdtZW50YXRpb24gbGVhZGluZyB0byB1bmRlc2lyZWQNCmV4cGxvc2lvbiBvZiA8YnI+
DQomZ3Q7IHRyYWZmaWMgaW4gdGhlPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgbmV0d29y
ay4gRm9yIElQVjYgbmV0d29yaywgdGhlIE1UVSBjYW4gYmUgZGV0ZXJtaW5lZA0KdXNpbmcgPGJy
Pg0KJmd0OyBQYXRoIE1UVSBEaXNjb3Zlcnk8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAo
UE1UVUQpIFtSRkM4MjAxXSB3aGljaCBiZXN0b3dzIHRoZSByZXNwb25zaWJpbGl0eQ0Kb2YgPGJy
Pg0KJmd0OyBkZXRlcm1pbmluZyB0aGUgcGF0aCBNVFUgb248YnI+DQomZ3Q7ICZndDsgJm5ic3A7
ICZuYnNwOyB0aGUgZW5kLXBvaW50cyBpdHNlbGYuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyAmbmJzcDsgJm5ic3A7IFRoZSBzaXplIG9mIHRoZSBzZWdtZW50IHNob3VsZCBiZSBndWlk
ZWQgYnkgdGhlDQo8YnI+DQomZ3Q7IHJlY29tbWVuZGF0aW9ucyBhcyBzcGVjaWZpZWQgaW48YnI+
DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBTZWN0aW9uIDQuNiBvZiBbUkZDNzI1Ml0uPGJyPg0K
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbHQ7L1F1b3RlJmd0Ozxicj4NCiZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgSSBob3BlIHRoaXMgd2lsbCBub3cgc2F0aXNmeSB0aGUgY3JpdGVyaW9u
IG9mIGZpbmRpbmcgSVB2NiBpbg0KdGhlIGRyYWZ0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFu
ayB5b3UgdmVyeSBtdWNoIGZvciB0aGlzIHZhbHVhYmxlIGFjdGlvbi48YnI+DQomZ3Q7IDxicj4N
CiZndDsgSXQgaXMgdmVyeSB3b3J0aCB0YWtpbmcgaW50byBjb25zaWRlcmF0aW9uLjxicj4NCiZn
dDsgPGJyPg0KJmd0OyAmbmJzcDtGcm9tIGFuIGltcGxlbWVudGF0aW9uIHN0YW5kcG9pbnQsIEkg
d291bGQgbGlrZSB0byBsZWFybiB3aGV0aGVyDQpzb21lIDxicj4NCiZndDsgcHJvdG90eXBlIGZl
YXR1cmVzIFJFU1RmdWwgUmVhbC10aW1lIExpdmUgU3RyZWFtaW5nIG9uIElQdjYsIG9yIG5vdA0K
b24gSVB2Ni48YnI+DQomZ3Q7IDxicj4NCiZndDsgQWxleDxicj4NCiZndDsgPGJyPg0KJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyBMb29waW5nIGluIENvUkUgbGlzdCBhcyB3ZWxsIHRvIGFubm91
bmNlIHRoZSBuZXcgdmVyc2lvbiB0byB0aGUNCldHIHdoZXJlIDxicj4NCiZndDsgJmd0OyB0aGlz
IGRyYWZ0IG9yaWdpbmF0ZXMuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGFuayB5
b3UuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBVUkw6IDxicj4NCiZndDsgJmd0OyA8
L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv
ZHJhZnQtYmhhdHRhY2hhcnl5YS1jb3JlLWEtIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3
LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iaGF0dGFjaGFyeXlhLWNvcmUtYS08L2Zv
bnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IHJlYWxpc3QtMDEudHh0PGJy
Pg0KJmd0OyAmZ3Q7IFN0YXR1czogPC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmhhdHRhY2hhcnl5YS1jb3JlLWEtcmVhbGlzdC8iPjx0
dD48Zm9udCBzaXplPTI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmhh
dHRhY2hhcnl5YS1jb3JlLWEtcmVhbGlzdC88L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9
Mj48YnI+DQomZ3Q7ICZndDsgSHRtbGl6ZWQ6IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaGF0dGFjaGFyeXlhLWNvcmUtYS1yZWFsaXN0LTAx
Ij48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaGF0
dGFjaGFyeXlhLWNvcmUtYS1yZWFsaXN0LTAxPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXpl
PTI+PGJyPg0KJmd0OyAmZ3Q7IEh0bWxpemVkOiA8YnI+DQomZ3Q7ICZndDsgPC9mb250PjwvdHQ+
PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1iaGF0
dGFjaGFyeXlhLWNvcmUtYS1yZWFsaXN0Ij48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYmhhdHRhY2hhcnl5YS1jb3JlLWEtcmVhbGlz
dDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgJmd0OyBEaWZmOiA8
YnI+DQomZ3Q7ICZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
cmZjZGlmZj91cmwyPWRyYWZ0LWJoYXR0YWNoYXJ5eWEtY29yZS1hLXJlYWxpc3QtMDEiPjx0dD48
Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJoYXR0
YWNoYXJ5eWEtY29yZS1hLXJlYWxpc3QtMDE8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9
Mj48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBXaXRoIEJl
c3QgUmVnYXJkczxicj4NCiZndDsgJmd0OyBBYmhpamFuIEJoYXR0YWNoYXJ5eWE8YnI+DQomZ3Q7
ICZndDsgQ29uc3VsdGFudCAvIFNjaWVudGlzdCw8YnI+DQomZ3Q7ICZndDsge0ludGVybmV0IFBy
b3RvY29scyB8IDVHIHwgU3RhbmRhcmRpemF0aW9ufSw8YnI+DQomZ3Q7ICZndDsgVENTIFJlc2Vh
cmNoLDxicj4NCiZndDsgJmd0OyBUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzPGJyPg0KJmd0OyAm
Z3Q7IEJ1aWxkaW5nIDFCLEVjb3NwYWNlPGJyPg0KJmd0OyAmZ3Q7IFBsb3QgLSAmbmJzcDtJSUYv
MTIgLE5ldyBUb3duLCBSYWphcmhhdCw8YnI+DQomZ3Q7ICZndDsgS29sa2F0YSAtIDcwMDE2MCxX
ZXN0IEJlbmdhbDxicj4NCiZndDsgJmd0OyBJbmRpYTxicj4NCiZndDsgJmd0OyBQaDotICs5MSAz
MyA2Njg4NDY5MTxicj4NCiZndDsgJmd0OyBDZWxsOi0gKzkxOTgzMDQ2ODk3MiB8ICs5MTg1ODM4
NzUwMDM8YnI+DQomZ3Q7ICZndDsgTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv
bSAmbHQ7PC9mb250PjwvdHQ+PGEgaHJlZj1tYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRj
cy5jb20+PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5j
b208L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFdl
YnNpdGU6IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cDovL3d3dy50Y3MuY29tLz48dHQ+PGZvbnQg
c2l6ZT0yPmh0dHA6Ly93d3cudGNzLmNvbTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0y
Pjxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCiZndDsgJmd0OyBFeHBlcmllbmNlIGNlcnRhaW50eS4gSVQgU2VydmljZXM8YnI+
DQomZ3Q7ICZndDsgQnVzaW5lc3MgU29sdXRpb25zPGJyPg0KJmd0OyAmZ3Q7IENvbnN1bHRpbmc8
YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAtLS0tLSZx
dW90O2l0cyZxdW90OyAmbHQ7aXRzLWJvdW5jZXNAaWV0Zi5vcmcgJmx0OzwvZm9udD48L3R0Pjxh
IGhyZWY9Im1haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZyI+PHR0Pjxmb250IHNpemU9Mj5tYWls
dG86aXRzLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj4m
Z3Q7Jmd0Ow0Kd3JvdGU6IC0tLS0tPGJyPg0KJmd0OyAmZ3Q7IFRvOiAmcXVvdDtBbGV4YW5kcmUg
UGV0cmVzY3UmcXVvdDsgJmx0O2FsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20NCjxicj4NCiZn
dDsgJmd0OyAmbHQ7PC9mb250PjwvdHQ+PGEgaHJlZj1tYWlsdG86YWxleGFuZHJlLnBldHJlc2N1
QGdtYWlsLmNvbT48dHQ+PGZvbnQgc2l6ZT0yPm1haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21h
aWwuY29tPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+Jmd0OyZndDs8YnI+DQomZ3Q7
ICZndDsgRnJvbTogJnF1b3Q7Q2Fyc3RlbiBCb3JtYW5uJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7IFNl
bnQgYnk6ICZxdW90O2l0cyZxdW90Ozxicj4NCiZndDsgJmd0OyBEYXRlOiAwMS8zMS8yMDE5IDA2
OjEyUE08YnI+DQomZ3Q7ICZndDsgQ2M6ICZxdW90O0FiaGlqYW4gQmhhdHRhY2hhcnl5YSZxdW90
OyAmbHQ7YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20NCjxicj4NCiZndDsgJmd0OyAmbHQ7
PC9mb250PjwvdHQ+PGEgaHJlZj1tYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+
PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208L2Zv
bnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7Jmd0OywNCiZxdW90O01pY2hhZWwgUmlj
aGFyZHNvbiZxdW90OyA8YnI+DQomZ3Q7ICZndDsgJmx0O21jckBzYW5kZWxtYW4uY2EgJmx0Ozwv
Zm9udD48L3R0PjxhIGhyZWY9bWFpbHRvOm1jckBzYW5kZWxtYW4uY2E+PHR0Pjxmb250IHNpemU9
Mj5tYWlsdG86bWNyQHNhbmRlbG1hbi5jYTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0y
PiZndDsmZ3Q7LA0KaXRzQGlldGYub3JnIDxicj4NCiZndDsgJmd0OyAmbHQ7PC9mb250PjwvdHQ+
PGEgaHJlZj1tYWlsdG86aXRzQGlldGYub3JnPjx0dD48Zm9udCBzaXplPTI+bWFpbHRvOml0c0Bp
ZXRmLm9yZzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPiZndDs8YnI+DQomZ3Q7ICZn
dDsgU3ViamVjdDogUmU6IFtpcHdhdmVdIEFkYXB0aXZlIFJFU1RmdWwgUmVhbC10aW1lIExpdmUg
U3RyZWFtaW5nDQpmb3IgPGJyPg0KJmd0OyAmZ3Q7IFRoaW5ncyAoQS1SRWFMaVNUKSc8YnI+DQom
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZxdW90O0V4dGVybmFsIGVtYWlsLiBPcGVuIHdpdGgg
Q2F1dGlvbiZxdW90Ozxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBJ
ZiBUQ1AncyBzdGF0ZSBtYWNoaW5lIHdhcyBhIGJvdHRsZW5lY2ssIGhhcyBvbmUgdHJpZWQNCnRv
IHVzZSBVRFA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBpbnN0ZWFkPzxicj4NCiZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgSSB0aGluayB0aGF0IGlzIGluZGVlZCBvbmUgb2YgdGhlIGFkdmFu
dGFnZXMgQ29BUCBicmluZ3MgZ28gdGhlDQp0YWJsZSBoZXJlLjxicj4NCiZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBEb2VzIENvQVAgd29yayBvbiBFdGhlcm5ldD88YnI+DQom
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IENvQVAgd2FzIGRlc2lnbmVkIHRvIGJlIGFibGUgdG8g
cnVuIG9uIFVEUCwgd2hpY2ggaXMgb24gSVAgd2hpY2gNCmluIHR1cm4gPGJyPg0KJmd0OyAmZ3Q7
IHdvcmtzIHZlcnkgd2VsbCBvbiBFdGhlcm5ldC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7ICZuYnNwOyZndDsgRG9lcyBDb0FQIHdvcmsgaW4gYW4gZW5kLXRvLWVuZCBtYW5uZXIgb3Ig
ZG9lcyBpdA0KbmVlZCBwcm90b2NvbDxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IGNvbnZlcnNp
b24gZ2F0ZXdheXM/PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIHdvcmtzIGVuZC10
by1lbmQgKGFzIGxvbmcgYXMgeW91ciBuZXR3b3JrIGRvZXNu4oCZdCBicmVhayBVRFApLjxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBJIHdhbnQgdG8gYXNrIHlvdTog
cGxlYXNlIHVzZSBJUHY2IGZvciBDb0FQIGFuZCBSRVNUZnVsLjxicj4NCiZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgQ29BUCB3YXMgZGVzaWduZWQgdG8gd29yayB3ZWxsIG92ZXIgSVB2NiAoYnV0
IHdvcmtzIGFzIHdlbGwgb3Zlcg0KSVB2NCkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyAmbmJzcDsmZ3Q7IFRoZW4gSSBzZWFyY2hlZCBmb3IgdGhlIGtleXdvcmQg4oCYSVB2NicgaW4g
dGhlIGRyYWZ0Ljxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IFvigKZdPGJyPg0KJmd0OyAmZ3Q7
ICZuYnNwOyZndDsgSWYgeW91IGFkZCDigJhJUHY2JyBjb25zaWRlcmF0aW9ucyB0byBpdCwgdGhl
biBJIHdpbGwNCmNvbW1lbnQgb24gaXQuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBG
b3IgYSBDb0FQIGFwcGxpY2F0aW9uIHN1Y2ggYXMgQS1SRWFMaVNULCBJUHY2IG1ha2VzIGxpdHRs
ZSBkaWZmZXJlbmNlDQo8YnI+DQomZ3Q7ICZndDsgKGJleW9uZCBiZWluZyBhYmxlIHRvIGFzc2ln
biBhZGRyZXNzZXMgdG8gYm90aCBlbmRzIGluIHRoZSBmaXJzdA0KcGxhY2UpLCA8YnI+DQomZ3Q7
ICZndDsgc28gSSBkb27igJl0IGtub3cgdGhlcmUgaXMgYSBsb3QgdG8gc2F5Ljxicj4NCiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgR3LDvMOfZSwgQ2Fyc3Rlbjxicj4NCiZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+DQomZ3Q7ICZndDsgaXRzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyBpdHNAaWV0
Zi5vcmcgJmx0OzwvZm9udD48L3R0PjxhIGhyZWY9bWFpbHRvOml0c0BpZXRmLm9yZz48dHQ+PGZv
bnQgc2l6ZT0yPm1haWx0bzppdHNAaWV0Zi5vcmc8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNp
emU9Mj4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHM+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0czwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg
c2l6ZT0yPjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPT09PT0tLS0tLT09PT09LS0t
LS09PT09PTxicj4NCiZndDsgJmd0OyBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg
aW4gdGhpcyBlLW1haWw8YnI+DQomZ3Q7ICZndDsgbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMg
dG8gaXQgbWF5IGNvbnRhaW48YnI+DQomZ3Q7ICZndDsgY29uZmlkZW50aWFsIG9yIHByaXZpbGVn
ZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmU8YnI+DQomZ3Q7ICZndDsgbm90IHRoZSBpbnRlbmRl
ZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsPGJyPg0KJmd0OyAmZ3Q7IHJldmll
dywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRoZTxicj4NCiZndDsgJmd0
OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZTxicj4NCiZndDsg
Jmd0OyBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElm
PGJyPg0KJmd0OyAmZ3Q7IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl
cnJvciw8YnI+DQomZ3Q7ICZndDsgcGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBlLW1haWwgb3Ig
dGVsZXBob25lIGFuZDxicj4NCiZndDsgJmd0OyBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkg
ZGVsZXRlIHRoZSBtZXNzYWdlPGJyPg0KJmd0OyAmZ3Q7IGFuZCBhbnkgYXR0YWNobWVudHMuIFRo
YW5rIHlvdTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGl0cyBtYWlsaW5n
IGxpc3Q8YnI+DQomZ3Q7IGl0c0BpZXRmLm9yZzxicj4NCiZndDsgPC9mb250PjwvdHQ+PGEgaHJl
Zj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cz48dHQ+PGZvbnQgc2l6
ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzPC9mb250PjwvdHQ+
PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg==
--=_alternative 0023A23F652583A1_=--


From nobody Fri Feb 15 04:53:50 2019
Return-Path: 
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 E2CD6130E73; Fri, 15 Feb 2019 04:53:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 lKnUBr8-Cq7a; Fri, 15 Feb 2019 04:53:39 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4128F1275F3; Fri, 15 Feb 2019 04:53:39 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x1FCratv066722; Fri, 15 Feb 2019 13:53:36 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 546FD206112; Fri, 15 Feb 2019 13:53:36 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3F41C2017FE; Fri, 15 Feb 2019 13:53:36 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x1FCrae6032630; Fri, 15 Feb 2019 13:53:36 +0100
To: Abhijan Bhattacharyya 
Cc: Carsten Bormann , "core@ietf.org" , its@ietf.org, its 
References:  <08d7924f-55c5-f89a-c2f6-cccb3fa4d071@gmail.com>   <3c66d20e-2db2-7e15-6080-ce3646f848f6@gmail.com>  <603fbed4-0a32-456e-7883-28dbbc9f8ca4@gmail.com> 
From: Alexandre Petrescu 
Message-ID: 
Date: Fri, 15 Feb 2019 13:53:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [ipwave] Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)'
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2019 12:53:43 -0000

Abhijan,

Thank you for the message.

Le 14/02/2019 à 07:29, Abhijan Bhattacharyya a écrit :
[...]
> We made a PoC of the concept and the experimentation and outcomes are
>  presented in Pages 78-80 of 
> https://datatracker.ietf.org/meeting/103/materials/slides-103-core-consolidated-slides-07.pdf


Thank you for the report.

It shows photo of testbed with laptops and raspberry Pis, and a
theoretical sketch of drone-to-access-point topology; it illustrates
that video streaming with A-REaLiST has better performance numbers (F,
PSNR, latency) than HTTP Streaming.  I trust it and it is good for video.

> But we used IPv4 pipe. While it is worth to do an experiment on how
> IPv6 improves the performance (it can only improve I believe).

It is good you used IPv4 pipe initially.

The IPv6 (instead of IPv4) recommendation is not for providing better
performance numbers (F, PSNR, latency) by using IPv6 instead of IPv4.
But it is for scaling up the laptop demonstrator to numerous drones and
access points outdoors where drones can fly, all while being connected
to the Internet.

Using IPv4 one may never be able to connect the drone-and-AP setting in
the outdoors, because there is no cellular  operator that gives enough
IP addresses for a scaleable setting.  In certain countries it is next
to impossible, whereas in others it is still possible but just for a 
little time.

IPv4 and NAT may be a solution, but that begs the question whether the
drone-and-AP setting using A-REaLiST protocol can work across NAT.  I
can understand that A-REaLiST needs to initiate in just one direction 
(so it is compatible with NAT): video initiated from drone to operator; 
but outdoors the operator must also initiate control to the drone, tell 
it where exactly to point the camera - s/he will require you the other 
direction to work too (send initial TCP/IP from control station to 
drone), and that is probably little compatible with NAT.

For these reasons, that have little to do directly with video latency, 
one must consider seriously IPv6 for A-REaLiST.

> But otherwise there should not be much of an impact higher up by a
> change in the network layer because CoAP is designed with 6LowPAN
> pipe in consideration as already emphasised by Carsten.

I am not sure 6LowPAN pipe is relevant for IPv6-over-OCB.  I would say 
it is not relevant at all.  But it is just a 'would'.

Yes, the 6LowPAN technology is some times used on 802.15.4 links.  The 
IPv6 technology without 6lowpan is some other times used on 802.15.4 
links too.

> May be we can discuss at length if we get an opportunity to present
> this in a physical meeting.

How is CoAP specified with respect to IPv6?  MUST it use IPv6?  Is it 
silent about the 'IPv6' keyword?

How is CoAP specified with respect to directionality?  Is CoAP 
compatible or incompatible with traversing NAT?

How is CoAP specified with respect to end-to-end principles?  MUST CoAP 
use intermediary gateways?

Alex


> 
> Thank you.
> 
> With Best Regards Abhijan Bhattacharyya Consultant / Scientist, 
> {Internet Protocols | 5G | Standardization}, TCS Research, Tata
> Consultancy Services Building 1B,Ecospace Plot -  IIF/12 ,New Town,
> Rajarhat, Kolkata - 700160,West Bengal India Ph:- +91 33 66884691 
> Cell:- +919830468972 | +918583875003 Mailto:
> abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com
>  ____________________________________________ 
> Experience certainty.        IT Services Business Solutions 
> Consulting ____________________________________________
> 
> 
> "its"  wrote on 02/08/2019 09:07:10 PM:
> 
>> From: "Alexandre Petrescu"  To:
>> "Abhijan Bhattacharyya" , "Carsten
>> Bormann"  Cc: "core@ietf.org" ,
>> its@ietf.org Date: 02/08/2019 09:08 PM Subject: Re: [ipwave]
>> Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)' 
>> Sent by: "its" 
>> 
>> "External email. Open with Caution"
>> 
>> 
>> Le 04/02/2019 à 20:00, Abhijan Bhattacharyya a écrit :
>>> Thank you Carsten for your comments. No one can speak about CoAP
>>> 
> better
>>> than you!
>>> 
>>> Alex, I have uploaded a new version of the draft. The links are
>>> given at the end of this mail. I have indeed tried to address
>>> your concern in
> respect
>>> to making the draft more "IPv6-relevant".
>>> 
>>> As Carsten rightly pointed out that the proposal works at the 
>>> application layer and is built on the foundation of CoAP, so it
>>> is Layer-3 agnostic. Also, as we all know, CoAP is designed for
>>> IPv6. However, implementation on IPv6 may influence the process
>>> of
> determining
>>> the maximum size of information segments. So, a new subsection
>>> has
> been
>>> added as part of the design guidelines. The small addition reads
>>> as
> below:
>>> 
>>> 
>>> 
>>> 6.3. Determining the segment size
>>> 
>>> Size of the information segment in a CoAP message should be
>> limited by the least
>>> possible MTU for the end-to-end channel. This is to ensure
>> that there is no
>>> undesired conversation state at the lower layers of the
>> protocol stack due to
>>> uncontrolled fragmentation leading to undesired explosion of
>> traffic in the
>>> network. For IPV6 network, the MTU can be determined using
>> Path MTU Discovery
>>> (PMTUD) [RFC8201] which bestows the responsibility of
>> determining the path MTU on
>>> the end-points itself.
>>> 
>>> The size of the segment should be guided by the
>> recommendations as specified in
>>> Section 4.6 of [RFC7252].
>>> 
>>> 
>>> 
>>> I hope this will now satisfy the criterion of finding IPv6 in the
>>> 
> draft.
>> 
>> Thank you very much for this valuable action.
>> 
>> It is very worth taking into consideration.
>> 
>> From an implementation standpoint, I would like to learn whether
>> some prototype features RESTful Real-time Live Streaming on IPv6,
>> or not
> on IPv6.
>> 
>> Alex
>> 
>>> 
>>> Looping in CoRE list as well to announce the new version to the
>>> WG
> where
>>> this draft originates.
>>> 
>>> Thank you.
>>> 
>>> URL: 
>>> https://www.ietf.org/internet-drafts/draft-bhattacharyya-core-a-
>> realist-01.txt
>>> Status:
> https://datatracker.ietf.org/doc/draft-bhattacharyya-core-a-realist/
>>> Htmlized:
> https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-01
>>> Htmlized:
>>> 
> https://datatracker.ietf.org/doc/html/draft-bhattacharyya-core-a-realist
>
> 
>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-bhattacharyya-core-a-realist-01
>
>>> 
>> 
>>> 
>>> With Best Regards Abhijan Bhattacharyya Consultant / Scientist, 
>>> {Internet Protocols | 5G | Standardization}, TCS Research, Tata
>>> Consultancy Services Building 1B,Ecospace Plot -  IIF/12 ,New
>>> Town, Rajarhat, Kolkata - 700160,West Bengal India Ph:- +91 33
>>> 66884691 Cell:- +919830468972 | +918583875003 Mailto:
>>> abhijan.bhattacharyya@tcs.com
> 
>>> Website: http://www.tcs.com  
>>> ____________________________________________ Experience
>>> certainty. IT Services Business Solutions Consulting 
>>> ____________________________________________
>>> 
>>> 
>>> -----"its" >
> wrote: -----
>>> To: "Alexandre Petrescu" >> > From: "Carsten Bormann" 
>>> Sent by: "its" Date: 01/31/2019 06:12PM Cc: "Abhijan
>>> Bhattacharyya" >> >, "Michael Richardson" 
>>> >, its@ietf.org 
>>>  Subject: Re: [ipwave] Adaptive RESTful
>>> Real-time Live Streaming for Things (A-REaLiST)'
>>> 
>>> "External email. Open with Caution"
>>> 
>>>> If TCP's state machine was a bottleneck, has one tried to use
>>>> UDP instead?
>>> 
>>> I think that is indeed one of the advantages CoAP brings go the
> table here.
>>> 
>>>> Does CoAP work on Ethernet?
>>> 
>>> CoAP was designed to be able to run on UDP, which is on IP which
>>> in
> turn
>>> works very well on Ethernet.
>>> 
>>>> Does CoAP work in an end-to-end manner or does it need
>>>> protocol conversion gateways?
>>> 
>>> I works end-to-end (as long as your network doesn’t break UDP).
>>> 
>>>> I want to ask you: please use IPv6 for CoAP and RESTful.
>>> 
>>> CoAP was designed to work well over IPv6 (but works as well over
>>> IPv4).
>>> 
>>>> Then I searched for the keyword ‘IPv6' in the draft. […] If you
>>>> add ‘IPv6' considerations to it, then I will comment on it.
>>> 
>>> For a CoAP application such as A-REaLiST, IPv6 makes little
>>> difference (beyond being able to assign addresses to both ends in
>>> the first
> place),
>>> so I don’t know there is a lot to say.
>>> 
>>> Grüße, Carsten
>>> 
>>> _______________________________________________ its mailing list 
>>> its@ietf.org  
>>> https://www.ietf.org/mailman/listinfo/its
>>> 
>>> =====-----=====-----===== Notice: The information contained in
>>> this e-mail message and/or attachments to it may contain 
>>> confidential or privileged information. If you are not the
>>> intended recipient, any dissemination, use, review, distribution,
>>> printing or copying of the information contained in this e-mail
>>> message and/or attachments to it are strictly prohibited. If you
>>> have received this communication in error, please notify us by
>>> reply e-mail or telephone and immediately and permanently delete
>>> the message and any attachments. Thank you
>>> 
>> 
>> _______________________________________________ its mailing list 
>> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>> 


From nobody Thu Feb 21 09:34:50 2019
Return-Path: 
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 78DA7131027 for ; Thu, 21 Feb 2019 09:34:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 tIo5KGD4lBD9 for ; Thu, 21 Feb 2019 09:34:46 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 260F613101B for ; Thu, 21 Feb 2019 09:34:46 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id v13so31523303wrw.5 for ; Thu, 21 Feb 2019 09:34:46 -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=37oJJzcs5/nucuhLbDPzfv9sKffe/WR/djV1IFvm3yQ=; b=DV8tJFGbwa/kKGwfTMeBWd0ywiWCAEKsl+MJjskpqqL0VBBVNBta8MeBKBoxg9mMFH INdYRsaOXj1bgi/dhe+SJKDOrENIKKczTr2zobiWFvGZx1MEuD03aU++ue/zLnBiBKk0 XX5pwH1s+GbsBiJFndAQ0xCEDtB8TOCu7tV3oOVo9zQlI8Og3g6yy/AX3JGc+FRJrazX 4gfcsTKuaVu5ucLbh1iHu7PC4BaTAj5UEubcIRN5QMXOvr7jAYr2TfrMbG/n0jeDjKec UimKmyuEsd1oGllhH4OFEl/CRZ+Oina00WvoeDEpotPdJ4LxnQXgre/5nGuuJTYimIlE L/Pw==
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=37oJJzcs5/nucuhLbDPzfv9sKffe/WR/djV1IFvm3yQ=; b=b7CEUc2oDFY3IhtRtg4jcE75barsYw4Mq7cls7tZpHwLo23KpW4FSs7ToDnVxI0P05 PvGSM+D/Ho7HoTuGv07K1WoYqQMdx3FBTmOumOyUF7odpnspM7RBDvh2tGmhNpi3IFBS S/P/C6B5nJUZd45dtfJgyVED0OYk+tlAggM3KdhOwTvf7895FTO/TrU96hdHACiN/3mJ ae/BpRSsBY0hN5baeK3pFqfsSvBih2x/LS0T6VOHTPgD6PJ4QLbBbSaiqyZqYgN9ydSp qGyQpn+A38sJ/IyNMYfrK72ne2EE7s2sMcBavX7VXjnSa0sIDa9a71YCrX+8DpcDCa4R CpAA==
X-Gm-Message-State: AHQUAuaueqmxevUk/zBU0rSYY+gcTN591tCmkF5F894u5knJQXDmnHtX /vcqBCqOvDjU187xFjytNK7zFP8MQWv70H7mH2U=
X-Google-Smtp-Source: AHgI3Ibi+GLpOYXpjPbiOQXRlSr5fCtOJtXMmbDhs/8lqC2sxc2A1Nm+CjmgGv0fMp8PS+K+V4J/uO3UhRetWJCS+Cs=
X-Received: by 2002:adf:ffcd:: with SMTP id x13mr28478775wrs.20.1550770484239;  Thu, 21 Feb 2019 09:34:44 -0800 (PST)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: "Mr. Jaehoon Paul Jeong" 
Date: Thu, 21 Feb 2019 07:34:32 -1000
Message-ID: 
To: CARLOS JESUS BERNARDOS CANO , Russ Housley 
Cc: Nabil Benamar , its@ietf.org, skku_iotlab_seminar@googlegroups.com,  Alexandre PETRESCU , Jaehoon Jeong 
Content-Type: multipart/alternative; boundary="000000000000d76c1205826ae3e2"
Archived-At: 
Subject: Re: [ipwave] IPWAVE hackathon
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2019 17:34:50 -0000

--000000000000d76c1205826ae3e2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Carlos, Russ and Nabil,
my SKKU team will have IPWAVE Basic Protocols Project this IETF-104
Hackathon.
https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon

This project is based on simulation and includes IPv6 over 802.11-OCB and
my Vehicular Neighbor Discovery with DAD Optimization as follows:

*IP Wireless Access in Vehicular Environments (IPWAVE) Basic Protocols*

   - Champion(s)
      - Jaehoon Paul Jeong 
   - Project(s)
      - Transmission of IPv6 Packets over IEEE 802.11-OCB (IPv6 over
      802.11-OCB)
      - IPv6 Neighbor Discovery for IP-Based Vehicular Networks
         - Router and Prefix Discovery and IPv6 address autoconfiguration
         - Duplicate Address Detection process
         - Multihop DAD process via V2V communications
      - Simulations of IPWAVE with SUMO, INET, and VEINS
         - Build IPv6/TCP/UDP protocol stack based on VEINS-4.7.1 and
         INET-4.0
         - Build basic IPWAVE running scenario, V2I and V2V based on
         VEINS-4.7.1 and SUMO-0.32.0
         - Transmit IPv6 data packets


   - Specifications:
      - =E2=80=8Bhttps://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80=
211ocb-34
      - =E2=80=8B
      https://tools.ietf.org/html/draft-jeong-ipwave-vehicular-neighbor-dis=
covery-05
      - =E2=80=8B
      https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-07


In future hackathons, my team will implement these in Linux, so our work
will be able to accommodate Nabil's work later.

I encourage our IPWAVERs to participate in this hackathon on site or
remotely.

Thanks.

Best Regards,
Paul




2019=EB=85=84 2=EC=9B=94 21=EC=9D=BC (=EB=AA=A9) =EC=98=A4=EC=A0=84 7:19, C=
ARLOS JESUS BERNARDOS CANO =EB=8B=98=EC=9D=B4
=EC=9E=91=EC=84=B1:

> Hi Nabil,
>
> Thanks for letting us know. If Paul's team is participating, maybe you ca=
n
> coordinate with him so they replicate what you did as a pre-step for a
> future hackathon where people from both teams could participate. I just
> think some activities on this would help moving IPWAVE activities forward=
.
>
> Thanks,
>
> Carlos
>
> On Thu, Feb 21, 2019 at 5:58 PM Nabil Benamar  wrote=
:
>
>> Thank you Carlos for raising this very crucial point!
>>
>> Indeed I have personally organized a Hackathon in Dakar last year during
>> the African Internet Summit, and it was a success story. We have been ab=
le
>> to test different ocb cards, recompiling the Linux Kernel and then see t=
he
>> ocb link communication.....
>>
>> I would love to do it again in upcoming IETF meetings, but unfortunately
>> I'm not participating this time!
>>
>> Best regards
>> Nabil
>>
>>
>>
>> On Thu, Feb 21, 2019, 17:35 CARLOS JESUS BERNARDOS CANO 
>> wrote:
>>
>>> Hi Nabil, Paul,
>>>
>>> In the last meeting we discussed about the possibility of organizing a
>>> hackathon on IPWAVE topics in Prague. Have you been working on this ide=
a?
>>> Maybe you should also ask Alex.
>>>
>>> If we could have some interop testing on basic IPv6 over OCB, I think
>>> would be really useful.
>>>
>>> Let us know what you think.
>>>
>>> Thanks,
>>>
>>> Carlos
>>>
>>

--000000000000d76c1205826ae3e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Carlos, Russ and Nabil,
my SKKU team will have IPWAVE Basic Protocols Project this IETF-104 Ha=
ckathon.

This project is based on simulation and incl=
udes IPv6 over 802.11-OCB and my Vehicular Neighbor Discovery with DAD Opti=
mization as follows:
IP Wireless Access in Vehicular Environments (I=
PWAVE) Basic Protocols
  • Champion(s)
    • Jaehoon Paul Jeong <pa=
uljeong at skku.edu>
  • P=
roject(s)
    • Transmission of IPv6 Packets over IEEE 802.11-OCB (IPv6 ov=
er 802.11-OCB)
    • IPv6 Neighbor Discovery for IP-Based Vehicular Netwo=
rks
      • Router and Prefix Discovery and IPv6 address autoconfiguration
      • Duplicate Address Detection process
      • Multihop DAD process via=
 V2V communications
    • Simulations of IPWAVE with SUMO, INET=
, and VEINS
      • Build IPv6/TCP/UDP protocol stack based on VEINS-4.7.1 a=
nd INET-4.0
      • Build basic IPWAVE running scenario, V2I and V2V based =
on VEINS-4.7.1 and SUMO-0.32.0
      • Transmit IPv6 data packets
      =

In future hackathons, my team will implement these=
 in Linux, so our work will be able to accommodate Nabil's work later.<=
/div>

I encourage our IPWAVERs=
 to participate in this hackathon on site or remotely.

Thanks.

Best Regards,
Paul




2019=
=EB=85=84 2=EC=9B=94 21=EC=9D=BC (=EB=AA=A9) =EC=98=A4=EC=A0=84 7:19, CARLO=
S JESUS BERNARDOS CANO <cjbc@it.uc3m.es>=EB=8B=98=EC=9D=B4 =EC=9E=91=
=EC=84=B1:
Hi Nabi=
l,

Thanks for letting us know. If Paul's team is par=
ticipating, maybe you can coordinate with him so they replicate what you di=
d as a pre-step for a future hackathon where people from both teams could p=
articipate. I just think some activities on this would help moving IPWAVE a=
ctivities forward.

Thanks,

Carlos

On Thu, Feb 21, 2019 at 5:58 PM Nabil Benamar <benamar73@gmail.com> wrote:
Thank you Carlos for raising this=
 very crucial point!

Indeed I =
have personally organized a Hackathon in Dakar last year during the African=
 Internet Summit, and it was a success story. We have been able to test dif=
ferent ocb cards, recompiling the Linux Kernel and then see the ocb link co=
mmunication.....

I would=
 love to do it again in upcoming IETF meetings, but unfortunately I'm n=
ot participating this time!

Best regards
Nabil<=
br>
=C2=A0=C2=A0=C2=A0 

=

On Thu, Feb 21, 2019, 17:35 CARLOS JE=
SUS BERNARDOS CANO <cjbc@it.uc3m.es> wrote:
Hi Nabil, Pa=
ul,

In the last meeting we discussed about the possibili=
ty of organizing a hackathon on IPWAVE topics in Prague. Have you been work=
ing on this idea? Maybe you should also ask Alex.

=
If we could have some interop testing on basic IPv6 over OCB, I think would=
 be really=C2=A0useful.

Let us know what you think=
.

Thanks,

Carlos








--000000000000d76c1205826ae3e2--


From nobody Fri Feb 22 01:31:28 2019
Return-Path: 
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 24CA41277CC for ; Fri, 22 Feb 2019 01:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
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 ZgoXufYXn0EU for ; Fri, 22 Feb 2019 01:31:22 -0800 (PST)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 55409124BF6 for ; Fri, 22 Feb 2019 01:31:22 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id y185so8471871wmd.1 for ; Fri, 22 Feb 2019 01:31:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=frI3LLtqfgzmuTdp7X5WPZtE7lu444lHMkqjUEAru28=; b=alZ/1+sMFtkmxlqsieQm6/wR9luIOuF/V0Bznuu1Q1LVRaaK1rtn5/wYEdzCY+Kv2K cLFJ+DOgR+rtdHczVOBAa8O28JKnIigZ3w97UZbusWJS4gX6T5j2x3feWd24ndGppKIw Y3/KxDczJ2TKLUVlAkjLOUnzpWqJnegWhyPsVro5RNIYUSrZBWgDA2uuUmozMco3IdUc Aq9KmUeydwuXBTJVYazf48jFLhobtSEA7bvt0znhJnupX2deafRIImuOVTXTfjAoboY8 3h1J0XDKEGXjWXDx/M+8VEnCAUbUBrYf/v9Zm1FGTcnOfY2erRSlwMEWklRGnEv40uut 1I9A==
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=frI3LLtqfgzmuTdp7X5WPZtE7lu444lHMkqjUEAru28=; b=CHeWJo/crt9O+Z6zyd2VB0jti1cX6fdxsdHIN5mrpwSdQMf6LrdazG3St6GDHYfvmq blcpy+KvjIKM62SAU3c7Zqrx5NXJM8FoZM+5IF+4KxLamDc4mEQQpiI101U11XhJ0rAn PSIPlsQJsaWQuBNB63yXPho05o/KYHH7N5HZFbR1cECo0vqaJEYsze1SYDyQpToX2PJH 89SFjJ5jwfgixv3X/HVIxm+HuRGYF+/1O0WhtKXsSNSIvaUrQrvn2XJs7DUWyxmzTrIr i3jSyabbmir9aB20M8OceWnl+JorftmulYTWfJP3A5GYs5YSaTFmVofHk2bE+P+eeOKS Y5aA==
X-Gm-Message-State: AHQUAuYqOe2892JdxUF4W03cKF8rvfGg46MgG/wKENri/r5C6/2ipYKP uYH92BfWRjmwAJYXeaGSjRpRVC/T3vdwkNSM+i2DrA==
X-Google-Smtp-Source: AHgI3IZDYmvoYp2//RgPpgaz834Y8VF9XBA71lfTXXzbHy+PpJX4SOKuPcSHC4EMNydMeFcKAXeU6GXyfxCcLGivmxA=
X-Received: by 2002:a1c:458:: with SMTP id 85mr1674462wme.97.1550827880361; Fri, 22 Feb 2019 01:31:20 -0800 (PST)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: CARLOS JESUS BERNARDOS CANO 
Date: Fri, 22 Feb 2019 10:31:04 +0100
Message-ID: 
To: "Mr. Jaehoon Paul Jeong" 
Cc: Russ Housley , Nabil Benamar ,  its , skku_iotlab_seminar@googlegroups.com,  Alexandre PETRESCU 
Content-Type: multipart/alternative; boundary="000000000000eac3ae0582784029"
Archived-At: 
Subject: Re: [ipwave] IPWAVE hackathon
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2019 09:31:26 -0000

--000000000000eac3ae0582784029
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Paul,

This is very good news. Please, let people know about this on the IPWAVE
mailing list. I think it'd also be good if you can report in 5-10 minutes
during the IPWAVE session in Prague about the outcome of the hackathon.

Thanks,

Carlos

On Thu, Feb 21, 2019 at 6:34 PM Mr. Jaehoon Paul Jeong <
jaehoon.paul@gmail.com> wrote:

> Hi Carlos, Russ and Nabil,
> my SKKU team will have IPWAVE Basic Protocols Project this IETF-104
> Hackathon.
> https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon
>
> This project is based on simulation and includes IPv6 over 802.11-OCB and
> my Vehicular Neighbor Discovery with DAD Optimization as follows:
>
> *IP Wireless Access in Vehicular Environments (IPWAVE) Basic Protocols*
>
>    - Champion(s)
>       - Jaehoon Paul Jeong 
>    - Project(s)
>       - Transmission of IPv6 Packets over IEEE 802.11-OCB (IPv6 over
>       802.11-OCB)
>       - IPv6 Neighbor Discovery for IP-Based Vehicular Networks
>          - Router and Prefix Discovery and IPv6 address autoconfiguration
>          - Duplicate Address Detection process
>          - Multihop DAD process via V2V communications
>       - Simulations of IPWAVE with SUMO, INET, and VEINS
>          - Build IPv6/TCP/UDP protocol stack based on VEINS-4.7.1 and
>          INET-4.0
>          - Build basic IPWAVE running scenario, V2I and V2V based on
>          VEINS-4.7.1 and SUMO-0.32.0
>          - Transmit IPv6 data packets
>
>
>    - Specifications:
>       - =E2=80=8B
>       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-34
>       - =E2=80=8B
>       https://tools.ietf.org/html/draft-jeong-ipwave-vehicular-neighbor-d=
iscovery-05
>       - =E2=80=8B
>       https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-=
07
>
>
> In future hackathons, my team will implement these in Linux, so our work
> will be able to accommodate Nabil's work later.
>
> I encourage our IPWAVERs to participate in this hackathon on site or
> remotely.
>
> Thanks.
>
> Best Regards,
> Paul
>
>
>
>
> 2019=EB=85=84 2=EC=9B=94 21=EC=9D=BC (=EB=AA=A9) =EC=98=A4=EC=A0=84 7:19,=
 CARLOS JESUS BERNARDOS CANO =EB=8B=98=EC=9D=B4
> =EC=9E=91=EC=84=B1:
>
>> Hi Nabil,
>>
>> Thanks for letting us know. If Paul's team is participating, maybe you
>> can coordinate with him so they replicate what you did as a pre-step for=
 a
>> future hackathon where people from both teams could participate. I just
>> think some activities on this would help moving IPWAVE activities forwar=
d.
>>
>> Thanks,
>>
>> Carlos
>>
>> On Thu, Feb 21, 2019 at 5:58 PM Nabil Benamar 
>> wrote:
>>
>>> Thank you Carlos for raising this very crucial point!
>>>
>>> Indeed I have personally organized a Hackathon in Dakar last year durin=
g
>>> the African Internet Summit, and it was a success story. We have been a=
ble
>>> to test different ocb cards, recompiling the Linux Kernel and then see =
the
>>> ocb link communication.....
>>>
>>> I would love to do it again in upcoming IETF meetings, but unfortunatel=
y
>>> I'm not participating this time!
>>>
>>> Best regards
>>> Nabil
>>>
>>>
>>>
>>> On Thu, Feb 21, 2019, 17:35 CARLOS JESUS BERNARDOS CANO 
>>> wrote:
>>>
>>>> Hi Nabil, Paul,
>>>>
>>>> In the last meeting we discussed about the possibility of organizing a
>>>> hackathon on IPWAVE topics in Prague. Have you been working on this id=
ea?
>>>> Maybe you should also ask Alex.
>>>>
>>>> If we could have some interop testing on basic IPv6 over OCB, I think
>>>> would be really useful.
>>>>
>>>> Let us know what you think.
>>>>
>>>> Thanks,
>>>>
>>>> Carlos
>>>>
>>>

--000000000000eac3ae0582784029
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Paul,

This is very good news. Please=
, let people know about this on the IPWAVE mailing list. I think it'd a=
lso be good if you can report in 5-10 minutes during the IPWAVE session in =
Prague about the outcome of the hackathon.

Thanks,=


Carlos

=

On Thu, Feb 21, 2019 at 6:34 PM Mr. J=
aehoon Paul Jeong <jaehoon.pau=
l@gmail.com> wrote:
Hi Carlos, Russ and Nabil,my SKKU team will have IPWAVE Basic Protocols Project this =
IETF-104 Hackathon.

This project is based on simulati=
on and includes IPv6 over 802.11-OCB and my Vehicular Neighbor Discovery wi=
th DAD Optimization as follows:
IP Wireless Access in Vehicular Envi=
ronments (IPWAVE) Basic Protocols
  • Champion(s)
  • Project(s)
    • Transmission of IPv6 Packets =
over IEEE 802.11-OCB (IPv6 over 802.11-OCB)
    • IPv6 Neighbor Discovery=
 for IP-Based Vehicular Networks
      • Router and Prefix Discovery and IPv=
6 address autoconfiguration
      • Duplicate Address Detection process
      • Multihop DAD process via V2V communications
    • Simulati=
ons of IPWAVE with SUMO, INET, and VEINS
      • Build IPv6/TCP/UDP protocol=
 stack based on VEINS-4.7.1 and INET-4.0
      • Build basic IPWAVE running=
 scenario, V2I and V2V based on VEINS-4.7.1 and SUMO-0.32.0
      • Transmi=
t IPv6 data packets

In future hackathons, my team will implement these in Linux=
, so our work will be able to accommodate Nabil's work later.

I encourage our IPWAVERs to parti=
cipate in this hackathon on site or remotely.

Thanks.

Best Regards,
Paul

=




2019=EB=85=84=
 2=EC=9B=94 21=EC=9D=BC (=EB=AA=A9) =EC=98=A4=EC=A0=84 7:19, CARLOS JESUS B=
ERNARDOS CANO <cjbc@it.uc3m.es>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1=
:
Hi Nabil,

Thanks for letting us know. If Paul's t=
eam is participating, maybe you can coordinate with him so they replicate w=
hat you did as a pre-step for a future hackathon where people from both tea=
ms could participate. I just think some activities on this would help movin=
g IPWAVE activities forward.

Thanks,
Carlos

On Thu, Feb 21, 2019 at 5:58 PM Nabil Benamar <<=
a href=3D"mailto:benamar73@gmail.com" rel=3D"noreferrer noreferrer" target=
=3D"_blank">benamar73@gmail.com> wrote:
Thank you Carlos for rai=
sing this very crucial point!

=
Indeed I have personally organized a Hackathon in Dakar last year during th=
e African Internet Summit, and it was a success story. We have been able to=
 test different ocb cards, recompiling the Linux Kernel and then see the oc=
b link communication.....

I would love to do it again in upcoming IETF meetings, but unfortunately =
I'm not participating this time!

Best regards<=
br>Nabil

=C2=A0=C2=A0=C2=A0 

On Thu, Feb 21, 2019, 17:35 =
CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> wrote:
<=
/div>
Hi =
Nabil, Paul,

In the last meeting we discussed about the =
possibility of organizing a hackathon on IPWAVE topics in Prague. Have you =
been working on this idea? Maybe you should also ask Alex.

If we could have some interop testing on basic IPv6 over OCB, I th=
ink would be really=C2=A0useful.

Let us know what =
you think.

Thanks,

Carlos=










--000000000000eac3ae0582784029--


From nobody Fri Feb 22 14:24:40 2019
Return-Path: 
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 C6CB9130E7F for ; Fri, 22 Feb 2019 14:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 chaIxxV8k5OM for ; Fri, 22 Feb 2019 14:24:34 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 F3E9912D861 for ; Fri, 22 Feb 2019 14:24:33 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id r5so3932874wrg.9 for ; Fri, 22 Feb 2019 14:24:33 -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=+0pUAPfGj8YFt2BRXZM3tJAHQ0hR3ggMq1QnGjb7J64=; b=Esdf/v7PuQ2EqEYOfVZkyT0admb+Upq2tLJFQbOuhLR/9EuPQJRdqS5JCKgupZI1ME MTNsZlEhFfZQsRccPqGZRFbGGPW6aKgwtrOUNW34KIzoQfwWf5K2jQxY7bzxkUvJYskq 8b6ESB3HXESMyoKO/Kxax7nKdpjXo76xnZ9PlOl8N59wqRgETDz0WEOMvZjhsEvMi71g BVUqhu4E+SV3VkbIZkq9LODLIYgiNmLhtYdXNJ6OfWOKiupfS6LYoBvEIC7oXavi14rA IxP/T92fIdjbMyRWunvokuZxOOxpEgq5QlJvY2drwH8rMUtMyXMVOXPB8UK/3ZbD3svT SALA==
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=+0pUAPfGj8YFt2BRXZM3tJAHQ0hR3ggMq1QnGjb7J64=; b=bxG1MGs2w51QoqKvFGFxMdepT7SkocAveFBiK+UM7BU+4WZTwgmTtUZAgW0UI6puVL QoCtwN0ScTmQJ6KjLZHKfXy5zb98agGB+IXljvTircYNhxpCig7X6qF0ZOKEKRYQBykQ aS/qea6sCF0ewKKyBYIJBB3+PjDQGjqmJ2WXX81GAC4uui6z1RzRelnF+95rV610Q3GV aEI5v34O6TAAcTvBEA9gIfhJwBA19iiCxWVwDctnhlEmEky9gEnt8qtNhQYIQ2c4dYR1 9GGewpNKLkN//roE7ZwXGMGF4JjY0N9m+lPy9dbKt74jgB7k98ZCbOn6Yn+Wy4PJGusV MYIQ==
X-Gm-Message-State: AHQUAuaYaXjAAPi+o32lpZ8+nQy4a4QDGQpq0M0Vxz3NMpggRqwF+o1E E1y3DetMzFX3g7JHDRM2pvf974cLXvFp37aDlNo=
X-Google-Smtp-Source: AHgI3IY3y6dwWCF5OGWpz6domiEXEIarZT9Vp2JMOL95E9/WKQVHt4kBCvWtr3wh5LYxZnjj8f9rP/CGMxqwGFeaJn8=
X-Received: by 2002:adf:ffcd:: with SMTP id x13mr4403241wrs.20.1550874271918;  Fri, 22 Feb 2019 14:24:31 -0800 (PST)
MIME-Version: 1.0
References:     
In-Reply-To: 
From: "Mr. Jaehoon Paul Jeong" 
Date: Sat, 23 Feb 2019 07:24:19 +0900
Message-ID: 
To: CARLOS JESUS BERNARDOS CANO 
Cc: Russ Housley , Nabil Benamar ,  skku_iotlab_seminar@googlegroups.com,  Alexandre PETRESCU , its@ietf.org,  Jaehoon Jeong , younghak@ssu.ac.kr,  =?UTF-8?B?7ISg6rK97J6s?= 
Content-Type: multipart/alternative; boundary="00000000000011b0900582830eb8"
Archived-At: 
Subject: Re: [ipwave] IPWAVE hackathon
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2019 22:24:38 -0000

--00000000000011b0900582830eb8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Carlos,
Sure, I can report IPWAVE Hackathon in IETF-104 IPWAVE session.
10 minutes will be good considering discussion.

IPWAVE WG,
Could you join our hackathon on site or remotely?
IPWAVE Basic Protocols Project
https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon

If you have intention to join this hackathon, please let me know.

Thanks.

Best Regards,
Paul



2019=EB=85=84 2=EC=9B=94 22=EC=9D=BC (=EA=B8=88) =EC=98=A4=ED=9B=84 6:31, C=
ARLOS JESUS BERNARDOS CANO =EB=8B=98=EC=9D=B4
=EC=9E=91=EC=84=B1:

> Hi Paul,
>
> This is very good news. Please, let people know about this on the IPWAVE
> mailing list. I think it'd also be good if you can report in 5-10 minutes
> during the IPWAVE session in Prague about the outcome of the hackathon.
>
> Thanks,
>
> Carlos
>
> On Thu, Feb 21, 2019 at 6:34 PM Mr. Jaehoon Paul Jeong <
> jaehoon.paul@gmail.com> wrote:
>
>> Hi Carlos, Russ and Nabil,
>> my SKKU team will have IPWAVE Basic Protocols Project this IETF-104
>> Hackathon.
>> https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon
>>
>> This project is based on simulation and includes IPv6 over 802.11-OCB an=
d
>> my Vehicular Neighbor Discovery with DAD Optimization as follows:
>>
>> *IP Wireless Access in Vehicular Environments (IPWAVE) Basic Protocols*
>>
>>    - Champion(s)
>>       - Jaehoon Paul Jeong 
>>    - Project(s)
>>       - Transmission of IPv6 Packets over IEEE 802.11-OCB (IPv6 over
>>       802.11-OCB)
>>       - IPv6 Neighbor Discovery for IP-Based Vehicular Networks
>>          - Router and Prefix Discovery and IPv6 address autoconfiguratio=
n
>>          - Duplicate Address Detection process
>>          - Multihop DAD process via V2V communications
>>       - Simulations of IPWAVE with SUMO, INET, and VEINS
>>          - Build IPv6/TCP/UDP protocol stack based on VEINS-4.7.1 and
>>          INET-4.0
>>          - Build basic IPWAVE running scenario, V2I and V2V based on
>>          VEINS-4.7.1 and SUMO-0.32.0
>>          - Transmit IPv6 data packets
>>
>>
>>    - Specifications:
>>       - =E2=80=8B
>>       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-3=
4
>>       - =E2=80=8B
>>       https://tools.ietf.org/html/draft-jeong-ipwave-vehicular-neighbor-=
discovery-05
>>       - =E2=80=8B
>>       https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking=
-07
>>
>>
>> In future hackathons, my team will implement these in Linux, so our work
>> will be able to accommodate Nabil's work later.
>>
>> I encourage our IPWAVERs to participate in this hackathon on site or
>> remotely.
>>
>> Thanks.
>>
>> Best Regards,
>> Paul
>>
>>
>>
>>
>> 2019=EB=85=84 2=EC=9B=94 21=EC=9D=BC (=EB=AA=A9) =EC=98=A4=EC=A0=84 7:19=
, CARLOS JESUS BERNARDOS CANO =EB=8B=98=EC=9D=B4
>> =EC=9E=91=EC=84=B1:
>>
>>> Hi Nabil,
>>>
>>> Thanks for letting us know. If Paul's team is participating, maybe you
>>> can coordinate with him so they replicate what you did as a pre-step fo=
r a
>>> future hackathon where people from both teams could participate. I just
>>> think some activities on this would help moving IPWAVE activities forwa=
rd.
>>>
>>> Thanks,
>>>
>>> Carlos
>>>
>>> On Thu, Feb 21, 2019 at 5:58 PM Nabil Benamar 
>>> wrote:
>>>
>>>> Thank you Carlos for raising this very crucial point!
>>>>
>>>> Indeed I have personally organized a Hackathon in Dakar last year
>>>> during the African Internet Summit, and it was a success story. We hav=
e
>>>> been able to test different ocb cards, recompiling the Linux Kernel an=
d
>>>> then see the ocb link communication.....
>>>>
>>>> I would love to do it again in upcoming IETF meetings, but
>>>> unfortunately I'm not participating this time!
>>>>
>>>> Best regards
>>>> Nabil
>>>>
>>>>
>>>>
>>>> On Thu, Feb 21, 2019, 17:35 CARLOS JESUS BERNARDOS CANO <
>>>> cjbc@it.uc3m.es> wrote:
>>>>
>>>>> Hi Nabil, Paul,
>>>>>
>>>>> In the last meeting we discussed about the possibility of organizing =
a
>>>>> hackathon on IPWAVE topics in Prague. Have you been working on this i=
dea?
>>>>> Maybe you should also ask Alex.
>>>>>
>>>>> If we could have some interop testing on basic IPv6 over OCB, I think
>>>>> would be really useful.
>>>>>
>>>>> Let us know what you think.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Carlos
>>>>>
>>>>

--00000000000011b0900582830eb8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Carlos,
Sure, I can report IPWAVE Hackat=
hon in IETF-104 IPWAVE session.
10 minutes will be g=
ood considering discussion.

IPWAVE WG,
Could you join our hackathon on site =
or remotely?
=
IPWAVE Basic Protocols Project=C2=A0

If you ha=
ve intention to join this hackathon, please let me know.

Thanks.

<=
div dir=3D"auto">Best Regards,
Paul



2019=EB=85=84 2=EC=9B=94 22=EC=9D=BC (=EA=B8=
=88) =EC=98=A4=ED=9B=84 6:31, CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>=EB=8B=98=EC=9D=B4 =EC=9E=91=
=EC=84=B1:
Hi Paul=
,

This is very good news. Please, let people know about =
this on the IPWAVE mailing list. I think it'd also be good if you can r=
eport in 5-10 minutes during the IPWAVE session in Prague about the outcome=
 of the hackathon.

Thanks,

Carlos

On Thu, Feb 21, 2019 at 6:34 PM Mr. Jaehoon Paul Jeong <=
jaehoon.paul@gmail.com> wrote:
Hi Carlos, Ru=
ss and Nabil,
my SKKU team will have IPWAVE Basic Protocol=
s Project this IETF-104 Hackathon.

This pr=
oject is based on simulation and includes IPv6 over 802.11-OCB and my Vehic=
ular Neighbor Discovery with DAD Optimization as follows:
IP Wireles=
s Access in Vehicular Environments (IPWAVE) Basic Protocols
  • Champio=
n(s)
    • Jaehoon Paul Jeong <pauljeong at skku.edu>
  • Pr=
oject(s)
    • Transmission of IPv6 Packets over IEEE 802.11-OCB (IPv6 ove=
r 802.11-OCB)
    • IPv6 Neighbor Discovery for IP-Based Vehicular Networ=
ks
      • Router and Prefix Discovery and IPv6 address autoconfiguration
      • Duplicate Address Detection process
      • Multihop DAD process via =
V2V communications
    • Simulations of IPWAVE with SUMO, INET,=
 and VEINS
      • Build IPv6/TCP/UDP protocol stack based on VEINS-4.7.1 an=
d INET-4.0
      • Build basic IPWAVE running scenario, V2I and V2V based o=
n VEINS-4.7.1 and SUMO-0.32.0
      • Transmit IPv6 data packets
      <=
/li>

    • In future hackathons, my team wi=
ll implement these in Linux, so our work will be able to accommodate Nabil&=
#39;s work later.

    I enco=
urage our IPWAVERs to participate in this hackathon on site or remotely.

    Thanks.

    Best Regards,
    Paul<=
/div>




    2019=EB=85=84 2=EC=9B=94 21=EC=9D=BC (=EB=AA=A9) =EC=98=A4=
=EC=A0=84 7:19, CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es=
>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
    Hi Nabil,

    Th=
anks for letting us know. If Paul's team is participating, maybe you ca=
n coordinate with him so they replicate what you did as a pre-step for a fu=
ture hackathon where people from both teams could participate. I just think=
 some activities on this would help moving IPWAVE activities forward.
    =


    Thanks,

    Carlos

    =

    On Thu, Fe=
b 21, 2019 at 5:58 PM Nabil Benamar <benamar73@gm=
ail.com> wrote:
    Thank you Carlos for raising this very crucial poi=
nt!

    Indeed I have personally o=
rganized a Hackathon in Dakar last year during the African Internet Summit,=
 and it was a success story. We have been able to test different ocb cards,=
 recompiling the Linux Kernel and then see the ocb link communication.....<=
/div>

    I would love to do it ag=
ain in upcoming IETF meetings, but unfortunately I'm not participating =
this time!

    Best regards
    Nabil

    =C2=A0=C2=
=A0=C2=A0 

    On Thu, Feb 21, 2019, 17:35 CARLOS JESUS BERNARDOS CA=
NO <cjbc@it.uc3m.es> wrote:
    Hi Nabil, Paul,
    In the last meeting we discussed about the possibility of=
 organizing a hackathon on IPWAVE topics in Prague. Have you been working o=
n this idea? Maybe you should also ask Alex.

    If we=
 could have some interop testing on basic IPv6 over OCB, I think would be r=
eally=C2=A0useful.

    Let us know what you think.

    Thanks,

    Carlos
    

    

    

    



--00000000000011b0900582830eb8--


From nobody Mon Feb 25 06:49:46 2019
Return-Path: 
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 01FA4129532 for ; Mon, 25 Feb 2019 06:49:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 v7EL1Zm_bqQe for ; Mon, 25 Feb 2019 06:49:43 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D7C1289FA for ; Mon, 25 Feb 2019 06:49:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 706F0300A54 for ; Mon, 25 Feb 2019 09:31:25 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6rYaHDEaTsnN for ; Mon, 25 Feb 2019 09:31:24 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 1C7CF300250 for ; Mon, 25 Feb 2019 09:31:24 -0500 (EST)
From: Russ Housley 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-Id: <70083A38-0362-40C8-8163-93B25C4B7B7B@vigilsec.com>
Date: Mon, 25 Feb 2019 09:49:40 -0500
To: IP Wireless Access in Vehicular Environments Discussion List 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: [ipwave] DRAFT IPWAVE WG Agenda for IETF 104
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2019 14:49:45 -0000

Please review the draft agenda.  As you can see, we have included time =
for additional topics.  Let us know if you want to make a presentation =
during this time.  Of course, the chartered topics have priority.

Russ & Carlos

=3D =3D =3D =3D =3D =3D =3D =3D

Agenda of the IPWAVE WG meeting at IETF 104
FRIDAY, 29 March 2019
10:50-12:50 Morning Session II, Athens/Barcelona

11:20 Administrativia  .......................................... 10 min
      Presenter: IPWAVE WG Chairs

** HACKATHON report

11:30 Implementing IPWAVE Basic Protocols  ...................... 15 min
          Presenter: Jaehoon Paul Jeong

** IPWAVE WG documents

11:45 Transmission of IPv6 Packets over IEEE 802.11 Networks  ... 15 min
      in mode Outside the Context of a Basic Service Set
         Presenter: Alex Petrescu
         Draft: draft-ietf-ipwave-ipv6-over-80211ocb-34

12:00  IP Wireless Access in Vehicular Environments (IPWAVE):  .. 15 min
       Problem Statement and Use Cases
          Presenter: Jaehoon Paul Jeong
          Draft: draft-ietf-ipwave-vehicular-networking-07

** Additional topics (time permitting)

12:15 

12:40 Any other business  ......................................  10 min=


From nobody Tue Feb 26 04:43:40 2019
Return-Path: 
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 83049124C04; Tue, 26 Feb 2019 04:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tcs.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 kd_Tw2lNFOuJ; Tue, 26 Feb 2019 04:43:25 -0800 (PST)
Received: from indelg02.tcs.com (indelg02.tcs.com [203.200.109.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100281200B3; Tue, 26 Feb 2019 04:43:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcs.com; i=@tcs.com; q=dns/txt; s=default2048; t=1551185005; x=1582721005; h=mime-version:in-reply-to:references:subject:from:to:cc: message-id:date; bh=Jf4mJ2VQTumHM+MPvoiua+oNwJmNgspDMQRgl/nhpIE=; b=knq7X+YphGXepuxd8OmlGUmuepukhcL3waRpoI7Wuslgj6qoZcXqt39Y fnzesIh6dG27ZUyUyWDabkN3XpEpmGs7bURr8sOOhvxghBx1c2yYDLzcn orCaD5PijWaEfB1HLm8fOV1JeuxARxLWUPy/KeL/87EQmNqfbMt2AYu+8 IiKIeuuTgUqfGn1jWa8OspH8ghUrLdNBhyDsKbLgH0SWzPT5csW05RrDZ uZUOBLNNwh550cBJuGkf37QaVH8uhnWAeimlbAdjftuV5Lm11hdE8xZ6V nFfPJJSusS2uUgdaATS4hqoy+ZwYWApR/Ws44K80Pczxm6lP7qZ7Z6xs4 A==;
IronPort-PHdr: =?us-ascii?q?9a23=3AzOt7+RFv6q6Ad8RUOmYPMp1GYnF86YWxBRYc79?= =?us-ascii?q?8ds5kLTJ76p8S+bnLW6fgltlLVR4KTs6sC17KG9fi4EUU7or+5+EgYd5JNUx?= =?us-ascii?q?JXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQ?= =?us-ascii?q?viPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCa+bL9oMBm6sRjau9ULj4dlNqs/0A?= =?us-ascii?q?bCrGFSe+RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG?= =?us-ascii?q?81/9HktQPCTQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUj?= =?us-ascii?q?m58axlVAHnhzsGNz4h8WHYlMpwjL5AoBm8oxBz2pPYbJ2JOPZ7eK7WYNEUSn?= =?us-ascii?q?dbXstJWCNOAZmyYIkBD+QcPehWsYrzqVUJoxSiHgSjHv/jxyVSi3/ywaE2zu?= =?us-ascii?q?IsGhzG0gw6GNIOtWzZocnuO6cSUOC1zrPHzTPeZP5L2Tfy8pTIcgw7rv6QXb?= =?us-ascii?q?J/a9DRyEkvFgzfk16drpbqMCiV1uQMsWiU9exgWfi0hG4nsQ5xviSvyd0whY?= =?us-ascii?q?nJnI0V0FDF9CVjz4suOd23VFV7bcS4H5tXsiGXLo17Sd4sTWFvvSY10LwGuZ?= =?us-ascii?q?ijcSgL1psn2xDfZ+aAc4iS7RLvTPqRLitjhH5/ZL2/gBOy/E69weP/Tsm5yE?= =?us-ascii?q?tGoyhbntXWq3wA1Abf5taJR/dn8Uqs3yuE2RrJ5eFeO080kLLWK5smwrEtiJ?= =?us-ascii?q?UeqV/DHirqmEXui6+Wa1kk9vCo6+v5ZrXmoYeROYxshA/7K6ognNGxDPg+PA?= =?us-ascii?q?YAWWaV4+Oy2qP/8EHkWLlKj/s2nbfFsJ3COMgWpLC1DxVI3osg8RqzETmr3M?= =?us-ascii?q?4XkHUfKVJKYhOHj4znO1HUJ/D4CO+yjE63nzdrxvDGPKfuApPXInfYkLfuZ6?= =?us-ascii?q?p961JGxwUvzdBQ/YhUC7EBIf3pQULxqMDXDgQjPwOoxObnDc1x1pkCVmKXHq?= =?us-ascii?q?+ZLKTSvEeS6eIrPeaNa5UauDDgJPg/+fHil2c5lkEBfamzw5QXc2y3Hul9Lk?= =?us-ascii?q?WWZHrjmNYBEWMQsgUiS+zqjUWIUSRPaHaqQ6I8+jY7BZq6AofEXICinqeM3C?= =?us-ascii?q?alEZ1KaGBKEFeMEW3nd4+cQfcDdDqSItN9kjwDTbWhSpMh1Qq3uADhzLpnM+?= =?us-ascii?q?zU9TEGupL4z9V15vPclQ089TBuCMSdyW6NRXlunmwUXz82wLx/oUtlx1eCza?= =?us-ascii?q?h4mOdVFd1N6PNVXAc2L5ncz/Z1C9rqQALOYs+JSEq6QtWhGTw+Usg+zMQJY0?= =?us-ascii?q?tmB9WjjxHD0zCtA78PmLzYTKAzp4vY0mj4Icpnxj7+2bU7gkItX4MbPGmrlq?= =?us-ascii?q?d5+xLeQZbEj1+UjK23XasZ1S/JsmyEyDzdkltfVVtZW6XEX3kZLmHWpMjl70?= =?us-ascii?q?jCRqW/GL1vZgJLyc+AI60MYN3gkUlPT/fqIsXPakqtkHz2DhGNkODfJLH2cn?= =?us-ascii?q?kQiX2OQHMPlBoeqDPfbVAz?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AFAAALLXVc/wQXEqxjGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGBDUyBEYEqPJlOfIgxjnEUgWMEJQEKhEkChCM?= =?us-ascii?q?1CA0BAwEBAgEBAgGBCAyCOikBgmYBAQEEAQEYVAsQBQYHBgQDAQIaAgUBBgc?= =?us-ascii?q?hBh8JCAYKAQgRCoMFAYFaAySqEAEBAYIehC8BAwICDEGDCg2CHosrgT53fiZ?= =?us-ascii?q?rghRJBy6CBlFHAQECAQEWgQsJAQsGAgE+DCwGglmCKgKJcSKHSYV7Bos7GjM?= =?us-ascii?q?HAoI8hQaHJ0KDVoFzKYU0i0qQLYEujQIBgRtxcFCCbAmCHxeBAAECgkiFFIV?= =?us-ascii?q?Hao12gk0BAQ?=
X-IPAS-Result: =?us-ascii?q?A2AFAAALLXVc/wQXEqxjGgEBAQEBAgEBAQEHAgEBAQGBU?= =?us-ascii?q?gQBAQEBCwGBDUyBEYEqPJlOfIgxjnEUgWMEJQEKhEkChCM1CA0BAwEBAgEBA?= =?us-ascii?q?gGBCAyCOikBgmYBAQEEAQEYVAsQBQYHBgQDAQIaAgUBBgchBh8JCAYKAQgRC?= =?us-ascii?q?oMFAYFaAySqEAEBAYIehC8BAwICDEGDCg2CHosrgT53fiZrghRJBy6CBlFHA?= =?us-ascii?q?QECAQEWgQsJAQsGAgE+DCwGglmCKgKJcSKHSYV7Bos7GjMHAoI8hQaHJ0KDV?= =?us-ascii?q?oFzKYU0i0qQLYEujQIBgRtxcFCCbAmCHxeBAAECgkiFFIVHao12gk0BAQ?=
X-IronPort-AV: E=Sophos; i="5.58,415,1544466600"; d="scan'208,217"; a="37146468"
X-DISCLAIMER: FALSE
MIME-Version: 1.0
Sensitivity: 
Importance: Normal
X-Priority: 3 (Normal)
In-Reply-To: 
References: ,  <08d7924f-55c5-f89a-c2f6-cccb3fa4d071@gmail.com>   <3c66d20e-2db2-7e15-6080-ce3646f848f6@gmail.com>  <603fbed4-0a32-456e-7883-28dbbc9f8ca4@gmail.com> 
From: Abhijan Bhattacharyya 
To: Alexandre Petrescu 
Cc: Carsten Bormann , its@ietf.org, "core@ietf.org" , its 
Message-ID: 
Date: Tue, 26 Feb 2019 18:13:12 +0530
X-Mailer: Lotus Domino Web Server Release 9.0.1FP10HF213   April 26, 2018
X-MIMETrack: Serialize by http on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 02/26/2019 18:13:12, Serialize complete at 02/26/2019 18:13:13, Itemize by http on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 02/26/2019 18:13:13, Serialize by Router on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 02/26/2019 18:13:14, Serialize complete at 02/26/2019 18:13:14
Content-Type: multipart/alternative; boundary="=_alternative 0045DFCA652583AD_="
Archived-At: 
Subject: Re: [ipwave] Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)'
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2019 12:43:31 -0000

--=_alternative 0045DFCA652583AD_=
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1

Hi Alex,

>Thank you for the report. .....  I trust it and it is good for
>video.

Thank you.

>The IPv6 (instead of IPv4) recommendation is not for providing better perf=
ormance numbers (F, PSNR, latency) by using IPv6 instead of IPv4.
>But it is for scaling up the laptop demonstrator to numerous drones and
>access points outdoors where drones can fly, all while being connected to =
the Internet.
>Using IPv4 one may never be able to connect the drone-and-AP setting
>in the outdoors, because there is no cellular operator that gives
>enough >IP addresses for a scaleable setting.=20
> ..............  For these reasons, that have little to do directly with v=
ideo latency,=20
> one must consider seriously IPv6 for A-REaLiST.

All your points are taken. We appreciate them as the fundamental considerat=
ions for moving towards IPv6. Even India is now have an enormous IPv6 adopt=
ion since the LTE roll-out. A-REaLiST, as mentioned earlier, is IP backbone=
 agnostic.

>I am not sure 6LowPAN pipe is relevant for IPv6-over-OCB.

Well, we never intended to say that we transfer video over 6LowPAN. We refe=
rred to 6LowPAN just to highlight the fact that CoAP by design is compatibl=
e with IPv6 and works well for sensors deploying 6LowPAN stack.

>How is CoAP specified with respect to IPv6? MUST it use IPv6? Is it
>
>silent about the 'IPv6' keyword? ........=20

CoAP is an application layer protocol and can work on both IPv4 and IPv6. T=
he specification (RFC 7252) has plenty of mentions about IPv6 (11 times in =
the body of the specification. 5 more in the reference section). You may pl=
ease check here (https://tools.ietf.org/html/rfc7252).

Yes it is an end-to-end protocol. The end-points may connect directly (just=
 like what we did during the presented experiments) or you may go through v=
ia proxies or gateways.=20
Traversing the NAT will be possible if you have the setting done through po=
rt-mapping , etc. just like any other system.

May be we can discuss more if we get a chance to meet face to face.

Thank you. Happy to discuss more.


With Best Regards
Abhijan Bhattacharyya
Consultant / Scientist,
{Internet Protocols | 5G | Standardization},=20
TCS Research,
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- +91 33 66884691
Cell:- +919830468972 | +918583875003
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Experience certainty.	IT Services
Business Solutions
Consulting
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F


-----"its"  wrote: -----

>To: Abhijan Bhattacharyya 
>From: Alexandre Petrescu=20
>Sent by: "its"=20
>Date: 02/15/2019 06:24PM
>Cc: Carsten Bormann , its@ietf.org, "core@ietf.org"
>, its 
>Subject: Re: [ipwave] Adaptive RESTful Real-time Live Streaming for
>Things (A-REaLiST)'
>
>"External email. Open with Caution"
>
>Abhijan,
>
>Thank you for the message.
>
>Le 14/02/2019 =E0 07:29, Abhijan Bhattacharyya a =E9crit :
>[...]
>> We made a PoC of the concept and the experimentation and outcomes
>are
>> presented in Pages 78-80 of=20
>>
>https://datatracker.ietf.org/meeting/103/materials/slides-103-core-co
>nsolidated-slides-07.pdf
>
>
>Thank you for the report.
>
>It shows photo of testbed with laptops and raspberry Pis, and a
>theoretical sketch of drone-to-access-point topology; it illustrates
>that video streaming with A-REaLiST has better performance numbers
>(F,
>PSNR, latency) than HTTP Streaming. I trust it and it is good for
>video.
>
>> But we used IPv4 pipe. While it is worth to do an experiment on how
>> IPv6 improves the performance (it can only improve I believe).
>
>It is good you used IPv4 pipe initially.
>
>The IPv6 (instead of IPv4) recommendation is not for providing better
>performance numbers (F, PSNR, latency) by using IPv6 instead of IPv4.
>But it is for scaling up the laptop demonstrator to numerous drones
>and
>access points outdoors where drones can fly, all while being
>connected
>to the Internet.
>
>Using IPv4 one may never be able to connect the drone-and-AP setting
>in
>the outdoors, because there is no cellular operator that gives
>enough
>IP addresses for a scaleable setting. In certain countries it is
>next
>to impossible, whereas in others it is still possible but just for a=20
>little time.
>
>IPv4 and NAT may be a solution, but that begs the question whether
>the
>drone-and-AP setting using A-REaLiST protocol can work across NAT. I
>can understand that A-REaLiST needs to initiate in just one direction
>
>(so it is compatible with NAT): video initiated from drone to
>operator;=20
>but outdoors the operator must also initiate control to the drone,
>tell=20
>it where exactly to point the camera - s/he will require you the
>other=20
>direction to work too (send initial TCP/IP from control station to=20
>drone), and that is probably little compatible with NAT.
>
>For these reasons, that have little to do directly with video
>latency,=20
>one must consider seriously IPv6 for A-REaLiST.
>
>> But otherwise there should not be much of an impact higher up by a
>> change in the network layer because CoAP is designed with 6LowPAN
>> pipe in consideration as already emphasised by Carsten.
>
>I am not sure 6LowPAN pipe is relevant for IPv6-over-OCB. I would
>say=20
>it is not relevant at all. But it is just a 'would'.
>
>Yes, the 6LowPAN technology is some times used on 802.15.4 links.
>The=20
>IPv6 technology without 6lowpan is some other times used on 802.15.4=20
>links too.
>
>> May be we can discuss at length if we get an opportunity to present
>> this in a physical meeting.
>
>How is CoAP specified with respect to IPv6? MUST it use IPv6? Is it
>
>silent about the 'IPv6' keyword?
>
>How is CoAP specified with respect to directionality? Is CoAP=20
>compatible or incompatible with traversing NAT?
>
>How is CoAP specified with respect to end-to-end principles? MUST
>CoAP=20
>use intermediary gateways?
>
>Alex
>
>
>>=20
>> Thank you.
>>=20
>> With Best Regards Abhijan Bhattacharyya Consultant / Scientist,=20
>> {Internet Protocols | 5G | Standardization}, TCS Research, Tata
>> Consultancy Services Building 1B,Ecospace Plot - IIF/12 ,New Town,
>> Rajarhat, Kolkata - 700160,West Bengal India Ph:- +91 33 66884691=20
>> Cell:- +919830468972 | +918583875003 Mailto:
>> abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com
>>  =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=20
>> Experience certainty. IT Services Business Solutions=20
>> Consulting =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>>=20
>>=20
>> "its"  wrote on 02/08/2019 09:07:10 PM:
>>=20
>>> From: "Alexandre Petrescu"  To:
>>> "Abhijan Bhattacharyya" , "Carsten
>>> Bormann"  Cc: "core@ietf.org" ,
>>> its@ietf.org Date: 02/08/2019 09:08 PM Subject: Re: [ipwave]
>>> Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)'=20
>>> Sent by: "its" 
>>>=20
>>> "External email. Open with Caution"
>>>=20
>>>=20
>>> Le 04/02/2019 =E0 20:00, Abhijan Bhattacharyya a =E9crit :
>>>> Thank you Carsten for your comments. No one can speak about CoAP
>>>>=20
>> better
>>>> than you!
>>>>=20
>>>> Alex, I have uploaded a new version of the draft. The links are
>>>> given at the end of this mail. I have indeed tried to address
>>>> your concern in
>> respect
>>>> to making the draft more "IPv6-relevant".
>>>>=20
>>>> As Carsten rightly pointed out that the proposal works at the=20
>>>> application layer and is built on the foundation of CoAP, so it
>>>> is Layer-3 agnostic. Also, as we all know, CoAP is designed for
>>>> IPv6. However, implementation on IPv6 may influence the process
>>>> of
>> determining
>>>> the maximum size of information segments. So, a new subsection
>>>> has
>> been
>>>> added as part of the design guidelines. The small addition reads
>>>> as
>> below:
>>>>=20
>>>> 
>>>>=20
>>>> 6.3. Determining the segment size
>>>>=20
>>>> Size of the information segment in a CoAP message should be
>>> limited by the least
>>>> possible MTU for the end-to-end channel. This is to ensure
>>> that there is no
>>>> undesired conversation state at the lower layers of the
>>> protocol stack due to
>>>> uncontrolled fragmentation leading to undesired explosion of
>>> traffic in the
>>>> network. For IPV6 network, the MTU can be determined using
>>> Path MTU Discovery
>>>> (PMTUD) [RFC8201] which bestows the responsibility of
>>> determining the path MTU on
>>>> the end-points itself.
>>>>=20
>>>> The size of the segment should be guided by the
>>> recommendations as specified in
>>>> Section 4.6 of [RFC7252].
>>>>=20
>>>> 
>>>>=20
>>>> I hope this will now satisfy the criterion of finding IPv6 in the
>>>>=20
>> draft.
>>>=20
>>> Thank you very much for this valuable action.
>>>=20
>>> It is very worth taking into consideration.
>>>=20
>>> From an implementation standpoint, I would like to learn whether
>>> some prototype features RESTful Real-time Live Streaming on IPv6,
>>> or not
>> on IPv6.
>>>=20
>>> Alex
>>>=20
>>>>=20
>>>> Looping in CoRE list as well to announce the new version to the
>>>> WG
>> where
>>>> this draft originates.
>>>>=20
>>>> Thank you.
>>>>=20
>>>> URL:=20
>>>> https://www.ietf.org/internet-drafts/draft-bhattacharyya-core-a-
>>> realist-01.txt
>>>> Status:
>>
>https://datatracker.ietf.org/doc/draft-bhattacharyya-core-a-realist/
>>>> Htmlized:
>> https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-01
>>>> Htmlized:
>>>>=20
>>
>https://datatracker.ietf.org/doc/html/draft-bhattacharyya-core-a-real
>ist
>>
>>=20
>>> Diff:
>>>>
>https://www.ietf.org/rfcdiff?url2=3Ddraft-bhattacharyya-core-a-realist-
>01
>>
>>>>=20
>>>=20
>>>>=20
>>>> With Best Regards Abhijan Bhattacharyya Consultant / Scientist,=20
>>>> {Internet Protocols | 5G | Standardization}, TCS Research, Tata
>>>> Consultancy Services Building 1B,Ecospace Plot - IIF/12 ,New
>>>> Town, Rajarhat, Kolkata - 700160,West Bengal India Ph:- +91 33
>>>> 66884691 Cell:- +919830468972 | +918583875003 Mailto:
>>>> abhijan.bhattacharyya@tcs.com
>> 
>>>> Website: http://www.tcs.com =20
>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Experience
>>>> certainty. IT Services Business Solutions Consulting=20
>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>>>>=20
>>>>=20
>>>> -----"its" >
>> wrote: -----
>>>> To: "Alexandre Petrescu" >>> > From: "Carsten Bormann"=20
>>>> Sent by: "its" Date: 01/31/2019 06:12PM Cc: "Abhijan
>>>> Bhattacharyya" >>> >, "Michael Richardson"=20
>>>> >, its@ietf.org=20
>>>>  Subject: Re: [ipwave] Adaptive RESTful
>>>> Real-time Live Streaming for Things (A-REaLiST)'
>>>>=20
>>>> "External email. Open with Caution"
>>>>=20
>>>>> If TCP's state machine was a bottleneck, has one tried to use
>>>>> UDP instead?
>>>>=20
>>>> I think that is indeed one of the advantages CoAP brings go the
>> table here.
>>>>=20
>>>>> Does CoAP work on Ethernet?
>>>>=20
>>>> CoAP was designed to be able to run on UDP, which is on IP which
>>>> in
>> turn
>>>> works very well on Ethernet.
>>>>=20
>>>>> Does CoAP work in an end-to-end manner or does it need
>>>>> protocol conversion gateways?
>>>>=20
>>>> I works end-to-end (as long as your network doesn’t break UDP).
>>>>=20
>>>>> I want to ask you: please use IPv6 for CoAP and RESTful.
>>>>=20
>>>> CoAP was designed to work well over IPv6 (but works as well over
>>>> IPv4).
>>>>=20
>>>>> Then I searched for the keyword ‘IPv6' in the draft. […] =
If you
>>>>> add ‘IPv6' considerations to it, then I will comment on it.
>>>>=20
>>>> For a CoAP application such as A-REaLiST, IPv6 makes little
>>>> difference (beyond being able to assign addresses to both ends in
>>>> the first
>> place),
>>>> so I don’t know there is a lot to say.
>>>>=20
>>>> Gr=FC=DFe, Carsten
>>>>=20
>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F it=
s mailing list=20
>>>> its@ietf.org =20
>>>> https://www.ietf.org/mailman/listinfo/its
>>>>=20
>>>> =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The in=
formation contained in
>>>> this e-mail message and/or attachments to it may contain=20
>>>> confidential or privileged information. If you are not the
>>>> intended recipient, any dissemination, use, review, distribution,
>>>> printing or copying of the information contained in this e-mail
>>>> message and/or attachments to it are strictly prohibited. If you
>>>> have received this communication in error, please notify us by
>>>> reply e-mail or telephone and immediately and permanently delete
>>>> the message and any attachments. Thank you
>>>>=20
>>>=20
>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F it=
s mailing list=20
>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>>>=20
>
>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>its mailing list
>its@ietf.org
>https://www.ietf.org/mailman/listinfo/its
>
--=_alternative 0045DFCA652583AD_=
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1
Content-ID: <>


    Hi Alex,

    >Thank you for the report. .....  I trust it and it is good for
    >video.

    Thank you.

    >The IPv6 (instead of IPv4) recommendation is not for p=
roviding better performance =
numbers (F, PSNR, latency) by using IPv6 instead of IPv4.
    >But it is fo=
r scaling up the laptop demonstrator to numerous drones and
    >access points outdoors where drones can =
fly, all while being connect=
ed to the Internet.>Using=
 IPv4 one may never be able to connect the drone-and-AP setting
    >in =
the outdoors, because there is no=
 cellular operator that gives
    >enough >IP addresses for a scaleable setting. 
    > ..............  For these reasons, that have little to do dir=
ectly with video latency,&nb=
sp;
    > one must consider seriously IPv6 for A-REaLiST.

    All your points are taken. We appreciate them as the fun=
damental considerations for moving towards IPv6. Even India is now have an =
enormous IPv6 adoption since the LTE roll-out. A-REaLiST, as mentioned earl=
ier, is IP backbone agnostic.

    >I am no=
t sure 6LowPAN pipe is relevant for IPv6-over-OCB.
    <=
br>
    Well, we never intended to say that we transfer video =
over 6LowPAN. We referred to 6LowPAN just to highlight the fact that CoAP b=
y design is compatible with IPv6 and works well for sensors deploying 6LowP=
AN stack.

    >H=
ow is CoAP specified with respect to IPv6? MUST it use IPv6? Is it>
    >s=
ilent about the 'IPv6' keyword? ........ 

    CoAP is an application la=
yer protocol and can work on both IPv4 and IPv6. The specification (RFC 725=
2) has plenty of mentions about IPv6 (11 times in the body of the specifica=
tion. 5 more in the reference section). You may please check here (https://tool=
s.ietf.org/html/rfc7252).

    Yes it is an end-to-=
end protocol. The end-points may connect directly (just like what we did du=
ring the presented experiments) or you may go through via proxies or gatewa=
ys. 
    Traversing the NAT will be possible if you have the set=
ting done through port-mapping , etc. just like any other system.

    May be we can discuss more if we get a chance to meet face =
to face.

    Thank you. Happy to discuss more.


    With Best Regards
    =0D    Abhijan Bhattacharyya
    =0D    Consultant =
/ Scientist,
    =0D{Interne=
t Protocols | 5G | Standardization}, 
    =0DTCS Res=
earch,
    =0DTata Consultancy Services
    =0DBuilding 1B,Ecospace
    =0DPlo=
t -  IIF/12 ,New Town, Rajarhat,
    =0DKolkata - 700160,West Bengal=0DIndia
    =0DPh:- +91 33 66884691
    =0DCell:- +919830468972 | +91858387=
5003
    =0DMailto: abhijan.bhattacharyya@tcs.com
    =0DWebsite: http://www.tcs.com
    =0D=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
    =0DExperience certainty.	IT Services
    =
=0D			Business Solutions
    =0D			Consulting
    =0D=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
    =0D


    -----"its" <its-bounces@ietf.org> wrote: -----

    >To: A=
bhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>
    >From: Alexa=
ndre Petrescu 
    >Sent by: "its" 
    >Date: 02/15/2019 06:24PM
    &g=
t;Cc: Carsten Bormann <cabo@tzi.org>, its@ietf.org, "c=
ore@ietf.org"
    ><core@ietf.org>, its <its-bounces@ietf.org>
    >Subject: Re: [ip=
wave] Adaptive RESTful Real-time Live Streaming for
    >Things (A-REaLiS=
T)'
    >
    >"External email. Open with Caution"
    >
    >Abhij=
an,
    >
    >Thank you for the message.
    >
    >Le 14/02/2019 =
=E0 07:29, Abhijan Bhattacharyya a =E9crit :
    >[...]
    >> We ma=
de a PoC of the concept and the experimentation and outcomes
    >are
    =
>>  presented in Pages 78-80 of 
    >>
    >https://datatracker.ietf.org/meeting/103/materials/slides-103-cor=
e-co
    >nsolidated-slides-07.pdf
    >
    >
    >Thank you f=
or the report.
    >
    >It shows photo of testbed with laptops and ra=
spberry Pis, and a
    >theoretical sketch of drone-to-access-point topol=
ogy; it illustrates
    >that video streaming with A-REaLiST has better p=
erformance numbers
    >(F,
    >PSNR, latency) than HTTP Streaming.  I=
 trust it and it is good for
    >video.
    >
    >> But we used =
IPv4 pipe. While it is worth to do an experiment on how
    >> IPv6 im=
proves the performance (it can only improve I believe).
    >
    >It i=
s good you used IPv4 pipe initially.
    >
    >The IPv6 (instead of IP=
v4) recommendation is not for providing better
    >performance numbers (=
F, PSNR, latency) by using IPv6 instead of IPv4.
    >But it is for scali=
ng up the laptop demonstrator to numerous drones
    >and
    >access p=
oints outdoors where drones can fly, all while being
    >connected
    &g=
t;to the Internet.
    >
    >Using IPv4 one may never be able to conne=
ct the drone-and-AP setting
    >in
    >the outdoors, because there is=
 no cellular  operator that gives
    >enough
    >IP addresses for a s=
caleable setting.  In certain countries it is
    >next
    >to impossi=
ble, whereas in others it is still possible but just for a 
    >little t=
ime.
    >
    >IPv4 and NAT may be a solution, but that begs the quest=
ion whether
    >the
    >drone-and-AP setting using A-REaLiST protocol=
 can work across NAT.  I
    >can understand that A-REaLiST needs to init=
iate in just one direction
    >
    >(so it is compatible with NAT): v=
ideo initiated from drone to
    >operator; 
    >but outdoors the oper=
ator must also initiate control to the drone,
    >tell 
    >it where =
exactly to point the camera - s/he will require you the
    >other 
    &g=
t;direction to work too (send initial TCP/IP from control station to 
    &g=
t;drone), and that is probably little compatible with NAT.
    >
    >F=
or these reasons, that have little to do directly with video
    >latency=
, 
    >one must consider seriously IPv6 for A-REaLiST.
    >
    >&g=
t; But otherwise there should not be much of an impact higher up by a
    &g=
t;> change in the network layer because CoAP is designed with 6LowPAN>> pipe in consideration as already emphasised by Carsten.
    >>I am not sure 6LowPAN pipe is relevant for IPv6-over-OCB.  I would>say 
    >it is not relevant at all.  But it is just a 'would'.
    &=
gt;
    >Yes, the 6LowPAN technology is some times used on 802.15.4 links=
.
    >The 
    >IPv6 technology without 6lowpan is some other times us=
ed on 802.15.4 
    >links too.
    >
    >> May be we can discuss=
 at length if we get an opportunity to present
    >> this in a physic=
al meeting.
    >
    >How is CoAP specified with respect to IPv6?  MUS=
T it use IPv6?  Is it
    >
    >silent about the 'IPv6' keyword?
    &g=
t;
    >How is CoAP specified with respect to directionality?  Is CoAP >compatible or incompatible with traversing NAT?
    >
    >How is=
 CoAP specified with respect to end-to-end principles?  MUST
    >CoAP >use intermediary gateways?
    >
    >Alex
    >
    >
    >=
;> 
    >> Thank you.
    >> 
    >> With Best Regards Ab=
hijan Bhattacharyya Consultant / Scientist, 
    >> {Internet Protocol=
s | 5G | Standardization}, TCS Research, Tata
    >> Consultancy Servi=
ces Building 1B,Ecospace Plot -  IIF/12 ,New Town,
    >> Rajarhat, Ko=
lkata - 700160,West Bengal India Ph:- +91 33 66884691 
    >> Cell:- +=
919830468972 | +918583875003 Mailto:
    >> abhijan.bhattacharyya@tcs.com Website: http://www.tc=
s.com
    >> <http://www.tcs.com/> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F 
    >> Experience certainty.        IT Services Busin=
ess Solutions 
    >> Consulting =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F
    >> 
    >> 
    >> "its" <its-bounces@ietf.org=
> wrote on 02/08/2019 09:07:10 PM:
    >> 
    >>> From=
: "Alexandre Petrescu" <alexandre.petrescu@gmail.com> To:
    >>>=
; "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>, "Carsten
    =
>>> Bormann" <cabo@tzi.org> Cc: "core@ietf.org" <core@ietf.org>,
    >>> its@ietf.org Date: 02/08/2019 09:08 PM Subjec=
t: Re: [ipwave]
    >>> Adaptive RESTful Real-time Live Streaming f=
or Things (A-REaLiST)' 
    >>> Sent by: "its" <its-bounces@ietf.org>>>> 
    >>> "External email. Open with Caution"
    >&=
gt;> 
    >>> 
    >>> Le 04/02/2019 =E0 20:00, Abhijan =
Bhattacharyya a =E9crit :
    >>>> Thank you Carsten for your co=
mments. No one can speak about CoAP
    >>>> 
    >> better=

    >>>> than you!
    >>>> 
    >>>> Ale=
x, I have uploaded a new version of the draft. The links are
    >>>=
;> given at the end of this mail. I have indeed tried to address
    >=
>>> your concern in
    >> respect
    >>>> to mak=
ing the draft more "IPv6-relevant".
    >>>> 
    >>>>=
; As Carsten rightly pointed out that the proposal works at the 
    >>=
;>> application layer and is built on the foundation of CoAP, so it>>>> is Layer-3 agnostic. Also, as we all know, CoAP is desig=
ned for
    >>>> IPv6. However, implementation on IPv6 may influ=
ence the process
    >>>> of
    >> determining
    >>=
>> the maximum size of information segments. So, a new subsection
    =
>>>> has
    >> been
    >>>> added as part of =
the design guidelines. The small addition reads
    >>>> as
    &=
gt;> below:
    >>>> 
    >>>> <Quote>
    &g=
t;>>> 
    >>>> 6.3. Determining the segment size
    &g=
t;>>> 
    >>>> Size of the information segment in a Co=
AP message should be
    >>> limited by the least
    >>>&g=
t; possible MTU for the end-to-end channel. This is to ensure
    >>&g=
t; that there is no
    >>>> undesired conversation state at the=
 lower layers of the
    >>> protocol stack due to
    >>>&=
gt; uncontrolled fragmentation leading to undesired explosion of
    >>=
;> traffic in the
    >>>> network. For IPV6 network, the MTU=
 can be determined using
    >>> Path MTU Discovery
    >>>=
> (PMTUD) [RFC8201] which bestows the responsibility of
    >>> =
determining the path MTU on
    >>>> the end-points itself.
    &=
gt;>>> 
    >>>> The size of the segment should be guid=
ed by the
    >>> recommendations as specified in
    >>>&g=
t; Section 4.6 of [RFC7252].
    >>>> 
    >>>> </=
Quote>
    >>>> 
    >>>> I hope this will now sat=
isfy the criterion of finding IPv6 in the
    >>>> 
    >> =
draft.
    >>> 
    >>> Thank you very much for this valuab=
le action.
    >>> 
    >>> It is very worth taking into co=
nsideration.
    >>> 
    >>> From an implementation standp=
oint, I would like to learn whether
    >>> some prototype features=
 RESTful Real-time Live Streaming on IPv6,
    >>> or not
    >&g=
t; on IPv6.
    >>> 
    >>> Alex
    >>> 
    >&=
gt;>> 
    >>>> Looping in CoRE list as well to announce t=
he new version to the
    >>>> WG
    >> where
    >>&=
gt;> this draft originates.
    >>>> 
    >>>> Tha=
nk you.
    >>>> 
    >>>> URL: 
    >>>> =
https://www.ietf.org/internet-drafts/draft-bhattachar=
yya-core-a-
    >>> realist-01.txt
    >>>> Status:<=
br>>>
    >https://datatracker.ietf.org/d=
oc/draft-bhattacharyya-core-a-realist/
    >>>> Htmlized:>> https://tools.ietf.org/html/draft-bhattach=
aryya-core-a-realist-01
    >>>> Htmlized:
    >>>&g=
t; 
    >>
    >https://datatracker.ietf.=
org/doc/html/draft-bhattacharyya-core-a-real
    >ist
    >>
    =
>> 
    >>> Diff:
    >>>>
    >https://www.ietf.org/rfcdiff?url2=3Ddraft-bhattacharyya-core-=
a-realist-
    >01
    >>
    >>>> 
    >>> <=
br>>>>> 
    >>>> With Best Regards Abhijan Bhattach=
aryya Consultant / Scientist, 
    >>>> {Internet Protocols | 5G=
 | Standardization}, TCS Research, Tata
    >>>> Consultancy Ser=
vices Building 1B,Ecospace Plot -  IIF/12 ,New
    >>>> Town, Ra=
jarhat, Kolkata - 700160,West Bengal India Ph:- +91 33
    >>>> =
66884691 Cell:- +919830468972 | +918583875003 Mailto:
    >>>> <=
a href=3D"mailto:abhijan.bhattacharyya@tcs.com" target=3D"=5Fblank">abhijan=
.bhattacharyya@tcs.com
    >> <mailto:abhijan.bhattacharyya@tcs.com>
    >>>> Website:     http://www.tcs.com <http://www.tcs.com/> 
    >>>> =5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Experience
    >>&=
gt;> certainty. IT Services Business Solutions Consulting 
    >>&g=
t;> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
    >&=
gt;>> 
    >>>> 
    >>>> -----"its" <its-bounces@ietf.org<=
/a> <mailto:=
its-bounces@ietf.org>>
    >> wrote: -----
    >>>&g=
t; To: "Alexandre Petrescu" <alexandre.petrescu@gmail.com 
    >>>&=
gt; <mailto:alexandre.petrescu@gmail.com>> From: "Carsten Bormann" >>>> Sent by: "its" Date: 01/31/2019 06:12PM Cc: "Abhijan
    =
>>>> Bhattacharyya" <abhijan.bhattacharyya@tcs.com 
    >>=
;>> <mailto:abhijan.bhattacharyya@tcs.com>>, "Michael Richar=
dson" 
    >>>> <mcr@sandelman.ca <mailto:mcr@sandelman.ca>>, its@ietf.org 
    >>>> <=
;mailto:its@ietf.org> Subject: Re: [ipwave] Adaptive RESTful
    >>>> Real-time =
Live Streaming for Things (A-REaLiST)'
    >>>> 
    >>>=
> "External email. Open with Caution"
    >>>> 
    >>&g=
t;>> If TCP's state machine was a bottleneck, has one tried to use>>>>> UDP instead?
    >>>> 
    >>>>=
 I think that is indeed one of the advantages CoAP brings go the
    >>=
; table here.
    >>>> 
    >>>>> Does CoAP work o=
n Ethernet?
    >>>> 
    >>>> CoAP was designed to b=
e able to run on UDP, which is on IP which
    >>>> in
    >&g=
t; turn
    >>>> works very well on Ethernet.
    >>>>=
; 
    >>>>> Does CoAP work in an end-to-end manner or does i=
t need
    >>>>> protocol conversion gateways?
    >>>=
;> 
    >>>> I works end-to-end (as long as your network does=
n’t break UDP).
    >>>> 
    >>>>> I want t=
o ask you: please use IPv6 for CoAP and RESTful.
    >>>> 
    &g=
t;>>> CoAP was designed to work well over IPv6 (but works as well =
over
    >>>> IPv4).
    >>>> 
    >>>>>=
; Then I searched for the keyword ‘IPv6' in the draft. […] If y=
ou
    >>>>> add ‘IPv6' considerations to it, then I wi=
ll comment on it.
    >>>> 
    >>>> For a CoAP appli=
cation such as A-REaLiST, IPv6 makes little
    >>>> difference =
(beyond being able to assign addresses to both ends in
    >>>> =
the first
    >> place),
    >>>> so I don’t know the=
re is a lot to say.
    >>>> 
    >>>> Gr=FC=DFe, Car=
sten
    >>>> 
    >>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F its mailing list 
    >>>&g=
t;     its@ietf.org <=
;mailto:its@ietf.org> 
    >>>>     https://www.ietf.org/mailman/listinfo/its
    =
>>>> 
    >>>> =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D--=
---=3D=3D=3D=3D=3D Notice: The information contained in
    >>>>=
 this e-mail message and/or attachments to it may contain 
    >>>&=
gt; confidential or privileged information. If you are not the
    >>&=
gt;> intended recipient, any dissemination, use, review, distribution,>>>> printing or copying of the information contained in this=
 e-mail
    >>>> message and/or attachments to it are strictly p=
rohibited. If you
    >>>> have received this communication in e=
rror, please notify us by
    >>>> reply e-mail or telephone and=
 immediately and permanently delete
    >>>> the message and any=
 attachments. Thank you
    >>>> 
    >>> 
    >>&g=
t; =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F its m=
ailing list 
    >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its
    >=
>> 
    >
    >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F
    >its mailing list
    >its@ietf.org
    >https://www.ietf.org/mail=
man/listinfo/its
    >    
--=_alternative 0045DFCA652583AD_=--


From nobody Wed Feb 27 04:40:55 2019
Return-Path: 
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 E7020130EC5 for ; Wed, 27 Feb 2019 04:40:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.733
X-Spam-Level: 
X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 eVEozjpcKadW for ; Wed, 27 Feb 2019 04:40:51 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6A5130EB8 for ; Wed, 27 Feb 2019 04:40:50 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x1RCemvD136654 for ; Wed, 27 Feb 2019 13:40:48 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A50D02035B0 for ; Wed, 27 Feb 2019 13:40:48 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9851920352F for ; Wed, 27 Feb 2019 13:40:48 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x1RCemtc017934 for ; Wed, 27 Feb 2019 13:40:48 +0100
To: "its@ietf.org" 
From: Alexandre Petrescu 
Message-ID: 
Date: Wed, 27 Feb 2019 13:40:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------1901381C8806B7A357454EBB"
Content-Language: fr
Archived-At: 
Subject: [ipwave] latency comparison on new V2X links (802.11 vs 5G links)
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2019 12:40:54 -0000

This is a multi-part message in MIME format.
--------------1901381C8806B7A357454EBB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

I am trying a comparison of latency that IP applications could afford on 
new V2X links from IEEE vs 3GPP cellular links.

Existing IP over 802.11-OCB (also known as 802.11p) with 10MHz channel 
width affords 1.2ms round-trip latency (DL plus UL) on average, as shown 
by the RTT field of the ping output, in a few trials.

Simulations and evaluations of New Radio (NR) of 3GPP claim a minimum 
0.23ms "DL latency using unicast transmission", as written in a publicly 
available document 3GPP TR 38.885 V1.0.0 (2018-11).

I wonder what would be a target latency that the newly formed group 
'802.11bd' would target?  Would it be still much lower than the 3GPP NR 
claimed latency? (currently, 802.11-OCB, aka p, offers much lower RTT 
latency than 4G+: it's 1.5ms vs 50ms).  Would 'bd' inherit the 
below-milisecond latencies experienced on 'ac'.

Latency has an importance in some use-cases like convoy maintenance, 
emergency messaging between cars, and similar.

Alex


--------------1901381C8806B7A357454EBB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
    Hi,
    
    
    I am trying a comparison
          of latency that IP applications could afford on new V2X links
          from IEEE vs 3GPP cellular links.
    
    
    Existing IP over
          802.11-OCB (also known as 802.11p) with 10MHz channel width
          affords 1.2ms round-trip latency (DL plus UL) on average, as
          shown by the RTT field of the ping output, in a few trials.
    
        
    
    
    Simulations and
          evaluations of New Radio (NR) of 3GPP claim a minimum 0.23ms
          "DL latency using unicast transmission", as written in a
          publicly available document 3GPP TR 38.885 V1.0.0 (2018-11).
    
    
    I wonder what would be a
          target latency that the newly formed group '802.11bd' would
          target?  Would it be still much lower than the 3GPP NR claimed
          latency? (currently, 802.11-OCB, aka p, offers much lower RTT
          latency than 4G+: it's 1.5ms vs 50ms).  Would 'bd' inherit the
          below-milisecond latencies experienced on 'ac'.
    
        
    
    
    Latency has an
          importance in some use-cases like convoy maintenance,
          emergency messaging between cars, and similar.
    
        
    
    
    Alex
    
        
    
  


--------------1901381C8806B7A357454EBB--