Sorry, but left out an important point - A couple carriers suggested to provide CV2X gateway that would turn BSMs to tile geo-state enumerations such as hard-brake.
This will allow car OEMs that walked away from DSRC and those who didn't to interoperate at some level. Stressing the point that the h3-lisp spec is at another layer. Once again the current network testing is still limited to a few K drivers in each of the US major cities, most are uber/lyft drivers and use smartphones as the cpe, dash-cams with kinematics as the sensors. --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Sep 19, 2019, at 10:05 PM, Sharon Barkai <sharon.bar...@getnexar.com> > wrote: > > Thank you William. > > Sorry if my summary did some injustice to the DSRC spec trying to account for > the adaptation challenges and the budgets considered necessary by gov-muni. > > But I think you would agree that specifying only the virtual ip geo-state > grid-brokering is a different approach. > > It may or may result in different adoption pattern, it may be limited in the > end to be a kind of an in-network live-map of furniture, signs, defects etc, > or, it may cover the whole spectrum of hazards, alerts, breaches in the end. > Testing level at this point is limited to a few thousands of cars in the > major US cites. > > v2i testing has also been limited to junction traffic light cameras, so > overall v2v v2i has been focused mainly on creating an H3 machine vision > puzzle using LISP. > > Regardless hope you feel this H3-LISP direction is worth a shot. > > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 > >> On Sep 19, 2019, at 9:19 PM, William Whyte <wwh...@qti.qualcomm.com> wrote: >> >> Hi all, >> >> Some of the history below is wrong, so I’d like to correct it (with no >> comment on LISP itself): >> >> >> 1. Couple of decades ago a peer to peer layer2 protocol called DSRC was >> >> specified over WiFi spectrum with basic safety messages (BSM) in which >> >> cars conveyed their GPS and kinematics sensor events like hard-brake, >> >> sharp-turn. Additional payment and information messages were specified as >> >> well. >> >> The V2X system specified by the DSRC/WAVE standards in IEEE and SAE covers >> the whole stack (not just layer 2) and supports both broadcast and unicast >> operations (it’s not inherently peer-to-peer, though some of the defined >> applications are peer-to-peer). >> >> For example, in the US: >> * Layers 1 and 2 are defined in 802.11p, now incorporated into the main >> 802.11 standard as 802.11 *O*utside the *C*ontext of a *B*asic Service Set >> (OCB) >> * Supported transport and network layer protocols include WSMP, a single-hop >> protocol best suited to broadcast, TCP over IPv6 and IDP over IPv6. These >> are specified in IEEE 1609.3 and other IEEE 1609 standards >> * Applications that use the system and messages that the applications use >> are defined in IEEE 1609.11 and (mainly) in SAE J2735 and the SAE J2945/x >> series of standards. The process of specifying applications is ongoing – the >> para above makes it seem like a set of applications was defined and then the >> specification process stopped. >> >> (The situation in Europe is similar except that the lower layers above layer >> 2 are specified in ETSI and the higher layers are specified in CEN, with >> some overlap; there is also a series of standards from ISO TC 204 which >> address the same area). >> >> >>2. For privacy considerations road-side-units (RSU) were specified as well >> >>to hand MAC keys to be used so cars will not be tracked. This double >> >>infrastructure presented a barrier so DSRC over cellular was specified >> >>CV2X. The 5G evolution is supposed to match the latency of peer to peer >> >>WiFi. >> >> RSUs are not required to be actively involved in V2V safety. >> >> Vehicles use certificates to sign messages, not MAC keys. >> >> Anti-tracking is important, agreed! This is achieved by giving vehicles a >> large number of simultaneously valid certificates and allowing them to >> switch between them periodically. >> >> There is no “double infrastructure”. >> >> C-V2X uses the same security system as DSRC and was proposed not so much >> because of technical shortcomings with DSRC as because of a business model >> failure – DSRC hasn’t been deployed because of concerns that it wouldn’t be >> widespread enough to be effective and the hope is that C-V2X will have >> synergies with other communications hardware on the car that will lower the >> total cost of ownership (as well as providing a migration path to >> higher-capacity channels) >> >> >> 3. The peer to peer challenges however remained, the need to test every >> >> product with every other product is a barrier for extending the protocol >> >> to support on vehicle vision and sensory annotations which evolved since >> >> - such as machine vision and liadr. >> >> There is no need to test every product with every other product. OmniAir and >> ETSI run conformance test services that test conformance to the standards, >> and products that implement the standards in general interoperate. This is >> similar to how not every WiFi chip needs to be tested against every other >> WiFi chip; instead, each chip can be individually certified and give a high >> confidence of interoperability. >> >> >> Also timing sequence for relaying annotations between vehicles remains a >> >> problem since both DSRC and CV2X have no memory and cars drive away. >> >> Memory of “annotations” would be implemented higher up the stack – whether >> or not the layer 2 protocol maintains the information is immaterial. Some >> architectures (like the ETSI and ISO ITS Station) identify functional >> components within the devices that would maintain that state; some (like the >> IEEE WAVE device architecture) leave it as an implementation choice. I agree >> that the existing standards don’t fully address this issue, though. >> >> Hope this corrects some misunderstandings. >> >> Cheers, >> >> William >> >> >> >> >> >> >> From: its <its-boun...@ietf.org> On Behalf Of Ratliff, Stanley >> Sent: Thursday, September 19, 2019 10:50 AM >> To: Sharon Barkai <sharon.bar...@getnexar.com>; Victor Moreno (vimoreno) >> <vimor...@cisco.com> >> Cc: lisp@ietf.org; i...@ietf.org >> Subject: [EXT] Re: [ipwave] [lisp] I-D Action: >> draft-barkai-lisp-nexagon-10.txt >> >> This looks like interesting work. But, don’t we already have a WG addressing >> vehicular networks? Has there been any collaboration with the ipwave WG? >> Just curious. >> >> Regards, >> Stan >> >> From: lisp <lisp-boun...@ietf.org> On Behalf Of Sharon Barkai >> Sent: Thursday, September 19, 2019 1:30 AM >> To: Victor Moreno (vimoreno) <vimor...@cisco.com> >> Cc: lisp@ietf.org >> Subject: Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt >> >> ***WARNING! THIS EMAIL ORIGINATES FROM OUTSIDE ST ENGINEERING IDIRECT.*** >> >> Thank you Victor. >> >> Quick recap of mobility networks evolution: >> >> 1. Couple of decades ago a peer to peer layer2 protocol called DSRC was >> specified over WiFi spectrum with basic safety messages (BSM) in which cars >> conveyed their GPS and kinematics sensor events like hard-brake, sharp-turn. >> Additional payment and information messages were specified as well. >> >> 2. For privacy considerations road-side-units (RSU) were specified as well >> to hand MAC keys to be used so cars will not be tracked. This double >> infrastructure presented a barrier so DSRC over cellular was specified CV2X. >> The 5G evolution is supposed to match the latency of peer to peer WiFi. >> >> 3. The peer to peer challenges however remained, the need to test every >> product with every other product is a barrier for extending the protocol to >> support on vehicle vision and sensory annotations which evolved since - such >> as machine vision and liadr. Also timing sequence for relaying annotations >> between vehicles remains a problem since both DSRC and CV2X have no memory >> and cars drive away. >> >> Addressable geo-states brokering solves timing, interoperability, and >> extendability limitations, and, edge-processing address latency needs => >> demonstrated in single-digit latencies in production environments, sub >> 5msecs in labs. >> >> >From here selecting LISP as the layer3 protocol of choice the road is short >> >and explained in the draft: >> >> o The support for logical EIDs for states based on (de-facto) geo-spatial >> standard grids >> >> o controlling latency and high availability by routing to states at the edge >> >> o supporting ephemeral EIDs for vehicles >> >> o signal-free-multicast for limited cast of many geo-spatial channels >> >> o the distributed connectionless scale >> >> o the multi-vendor interoperability that allows for “bring your own XTR” to >> protect geo-privacy >> >> o the ability to overlay multiple cellular network providers and multiple >> cloud-edge providers >> >> ... are some of the features which make LISP a good choice for mobility >> VPNs.. Hope this helps. >> >> --szb >> Cell: +972.53.2470068 >> WhatsApp: +1.650.492.0794 >> >> > On Sep 19, 2019, at 7:01 AM, Victor Moreno (vimoreno) <vimor...@cisco.com> >> > wrote: >> > >> > I think a thorough understanding of mobility requirements and dependencies >> > and how LISP may or may not accommodate these scenarios is key. I would >> > like to see us work on this and other mobility related drafts (e.g. Ground >> > based LISP). >> > >> > Victor >> > >> >> On Sep 18, 2019, at 11:18 AM, Dino Farinacci <farina...@gmail.com> wrote: >> >> >> >> I’m a side author on this document and more of a reviewer. But I’ll >> >> answer your questions on behalf of a WG member. >> >> >> >>> Before I get more privacy feedback (if I do) I want to know >> >>> 1) does the WG actually care about this? >> >> >> >> I do. Because understanding in deep detail the use-cases, allows us to >> >> understand if LISP has the necessary protocol features. >> >> >> >>> 2) Is it ready for more extensive review? >> >> >> >> Yes. >> >> >> >>> I realize we have not adopted this document. Some of this feedback is to >> >>> help the chairs judge what to do when the authors do ask for adoption. >> >> >> >> We are at a point of the protocol’s life where working on use-cases >> >> allows more adoption. I am for making this a working group document (even >> >> though the authors have not formally requested). >> >> >> >> Dino >> >> >> >> _______________________________________________ >> >> lisp mailing list >> >> lisp@ietf.org >> >> https://www.ietf.org/mailman/listinfo/lisp >> > _______________________________________________ >> > lisp mailing list >> > lisp@ietf.org >> > https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> >> >> >> This electronic message and any files transmitted with it contains >> information from iDirect, which may be privileged, proprietary and/or >> confidential.. It is intended solely for the use of the individual or entity >> to whom they are addressed. If you are not the original recipient or the >> person responsible for delivering the email to the intended recipient, be >> advised that you have received this email in error, and that any use, >> dissemination, forwarding, printing, or copying of this email is strictly >> prohibited. If you received this email in error, please delete it and >> immediately notify the sender.
_______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
