* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ipwave Status Pages

IP Wireless Access in Vehicular Environments (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2016-Oct-18 —  

IETF-101 ipwave minutes

Session 2018-03-19 0930-1200: Sandringham - Audio stream - ipwave chatroom


minutes-101-ipwave-00 minutes

          IPWAVE WG meeting at IETF 101
          MONDAY, 19 March 2018 at 0930-1200, Sandringham
          Chairs: Russ Housley, Carlos J. Bernardos
          Minute takers: Dorothy Stanley, Sri Gundavelli
          Jabber scribe: Sri Gundavelli
          9:30 Administrativia
               Presenters: Russ Housley (RH) and Carlos Bernardos (CB)
          CB:  We hope that the IPv6-over-OCB document is ready
          right after this meeting.  If the pending issue is resolved today, then
          the next step is review by the 6man WG, and then submit to IESG.
          CB: We need review on the Use Cases, Survey and Problem Statement
          document; without more discussion on the mail list, it cannot move
          RH: The working group received a Liaison Statement: "LS on Establishment
          of SAE Cellular V2X Technical Committee and Associated Task Forces".  No
          response is needed since the IPWAVE WG is not taking on any work related
          to 5G or LTE.
          CB: There was a meeting on Collaboration on ITS Communication Standards
          on March 9th.  CB participated remotely, and he provided an overview of
          the work going on in the IPWAVE WG.
          ** IPWAVE WG documents
          Transmission of IPv6 Packets over IEEE 802.11 Networks in mode
          Outside the Context of a Basic Service Set (IPv6-over-80211ocb)
               Presenter: Alex Petrescu (AP)
               Draft: draft-ietf-ipwave-ipv6-over-80211ocb-21
          AP reviewed changes to the document since Singapore, and then he proposed
          text to resolve the open issue.
          Chair: are there any comments on the changes proposed?
          Comment: Concern with non-QoS for certain high priority frames.
          AP: Use of background is to compare with other traffic in the network
          that is not IP traffic.  In some use cases, adaptive cruise control and
          platooning scenarios, should have a priority higher than background.
          However, possible to have background value for IP.  We can consider a
          change to that in the future.
          Chair: I see agreement on the text proposed for the document. Once the
          draft is updated, we will sent it to the 6MAN WG for review (as required
          by the charter).  Once that review is complete, it will be sent to the
          IP-based Vehicular Networking: Use Cases, Survey and Problem Statement
                Presenter: Jaehoon Paul Jeong (JPJ)
                Draft: draft-ietf-ipwave-vehicular-networking-02
          JPJ presented the latest revision of the draft.  The next steps are:
              - Synchronize with IPv6-over-802.11ocb
              - Enhance use case section
              - WG Last call
          Justin Dean (JD) [MANET WG chair]: Document does not clearly state the
          problems that need to be solved, but it does describe a set of solutions.
          Suresh Krishnan (SK) [Area Director]: Have a goal of reducing the number
          of purely informational documents.  We have not seen a lot of discussion
          on this document.  If problem statement document does not advance; it can
          still be viewed as a resource for the IPWAVE WG.  That said, we want the
          WG to agree on the set of problems to be solved.
          JD and SG volunteers to review the document in 2-3 weeks.
          ** Rechartering discussion
          SK introduces the goals for the rechartering discussion. Routing
          protocols are out of scope. Work on the PS document is a pre-condition
          to do rechartering. Discussion on the PS is needed in the WG.
          IP Interfaces for RSU Manageability
                Presenter: Sri Gundavelli
          Sri Gundavelli (SG): Focus has been on how to transmit a packet, but
          there has been no discussion of neighbor discovery.  Several gaps in
          protocols related to security and manageability.
          Tony Li (TL): Current solution works; no special version of neighbor
          discovery is needed.
          Erik Nordmark (EN): There is question on handover behaviour.  Every 1K
          meters have a transfer to roadside unit.  Maybe some components can be
          Comment: About semantics: Yes, it works.  Does it work efficiently?
          Neighbor table may change very rapidly.  Maybe we can improve efficiency
          in highly mobile environment.
          Comment: In cellular, we have large network infrastructure that manages
          IP addresses, and we want to see equivalent components here.
          Comment: IETF does protocols, not architectures. Let other SDOs work on
          the architecture.  Are there specific pain points that we need to fix?
          SG: A set of questions about IPv6 ND for 802.11-OCB
              - What exactly defines an IPv6 link for such environments?
              - What is the impact of fast moving nodes?
              - how IPv6 prefixes hosted?
                -- Need explanation of system view, especially vehicle versus RDU.
          Comment: Any prefixes hosted in the vehicle will be NATed. Router is
          advertising the RAs.
          Comment: No NAT in the car.
          Jabber Comment: RSUs are not required for communication.
          SK: That is a deployment question.  We do not need to do it here.
          Similar to roaming on WLAN; we do not define how the roaming works.
          Questions are valid, but it does not need to be done here.  Talking
          about a mobility problem belongs in other IETF WGs, these are not a
          problem of running IPv6 over OCB.
          Comment: If we discover a problem with multicast, do we do that here?
          SK: Yes, but do not pre-suppose a link model.
          Comment: OCB is for a particular environment.
          SK: Vehicle to Vehicle – a MANET problem.  Need to be very specific.
          Comment: Neighbor environment is very dynamic, including hidden
          terminals. V2V with no RSU in path. How do identities map for
          Comment: 802.11 considering evolution of PHY mechanisms.  It will be
          backwards compatible, enable future extensions, and new use cases.
          SG: Vehicular Mobility Anchor – Do we need to introduce the concept of
          an anchor for vehicular networks.
          Comment: Need to provide guidance on services and applications – what
          applications/traffic is central gateway used for?
          Comment: As soon as support IPv6, you get all internet applications.
          They all just work because it is IP.  Nothing fancy needed; just pass
          the packets.
          Comment: How many links does the vehicle pass?
          Comment: Care about V2V.
          Comment: Crossing mobility domains difficult – not sure want to take
          that on.
          Comment: Vehicle network architecture – reduce delay.
          Comment: OCB support all identified use cases today.  New IEEE 802.11
          PHY work for longer range, higher throughput – Study Group started.
          Potential new work item: Mapping IP to Access Category in 802.11-OCB
                Presenter: Jérôme Härri (JH)
          TL: I do not think how this works operationally.  We do not have
          security today on DSCP.  How do prevent DSCP from being forged?  We do
          not have a way to prevent it.  There are no mechanisms out there today.
          JH explained the 3 steps that can be used for solving this (see slides).
          AP: With respect to DSCP not being secure, any one on the Internet can
          replace it in the middle.  This could be secured with IPSec.
          SK: Its not clear from the presentation on what you are proposing.  We
          need some justification on why it needs done and what needs to be done.
          JH: We need to have some default mappings.
          SK: I understand you want to define some defaults.  Take IPWAVE traffic
          and map it to some DSCP values. You want to define those values?
          JH: Yes.
          Prefix/Service Discovery, DNS Naming and Seamless IP Networking
                Presenter: Jaehoon Paul Jeong (JPJ)
                Drafts: draft-jeong-ipwave-vehicular-neighbor-discovery-02
          JPJ suggested three new work items for the IPWAVW WG:
             - Vehicular Neighbor Discovery for V2X Networking
               - Prefix Discovery
               - Service Discovery
             - DNS Naming Services
             - Seamless IP Networking
          IP for V2V and V2I
                Presenter: Alex Petrescu (AP)
          AP: A movement detection procedure that measures the signal strength of
          IP messages that can be used as 'Beacons'.  These Beacon IP messages
          should contain enough IP and L2 information for a mobile router to
          decide whether to change the subnet and send a Binding Update.  Note
          that the MAC address of IP-RSU and prefix of the link are not
          EN: Asked how the DNS naming works and why its needs.  Use of DNS, or
          re-creating the same steps for this use case of two neighboring cars
          which will stay together for 2 seconds is starting on a wrong premise.
          AP: Agreed with Erik's comment.  We need to think about boot strapping
          of communication between vehicles.
          TL: We seem to be taking about things that are not OCB specific.  There
          are already other zero-conf and other approaches.  Lets not re-invent the
          vehicle please.
          JH: There is going to be strong specifications from SAE and ITU
          Rechartering discussion and open mic
          JPJ: Current document survey many topics, we need to focus on few
          problems.  After mail list discussion, we should discuss what topics we
          should work on and then I will update the document.
          TL: IP lacks security and by design.  Do not look at IETF for help.
          Rotating MAC address will break every thing.
          SK reminded people about MAC randomization experiments.
          Sandra: We need to focus on specific problems based on the survey
          document.  Maybe we supposed to include link models and mobility

Generated from PyHt script /wg/ipwave/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -