Re: [ipwave] RSU minor textual issue

[Rex Buddenberg <[e-mail]>]

Russ,

You said:

> Some RSUs will be routers, but others will not.  For example, an RSU
> that sends messages to vehicles about foggy conditions does not need
> to be a router.  I think the definition should allow both cases.> 


I think that a specific focus on RSU would make some sense.  Some
thoughts:

- router.  RSU would be a router.  plain/simple.  The wired internet on
its backside (terrestrial-WAN in my classroom terminology) would
certainly be made up of routable networks.  And the radio-WANs on the
front side would be routable network(s) too.  

- yes, but...  There are major differences, both qualitative and
quantitative between terrestrial-WANs and radio-WANs.  
     o terrestrial plumbing is largely made up of point-point links
(example, fiber optic strings between routers).  Radio-WANs are shared
media (with consequent need for MAC which is absent in point-point
stuff). 
     o capacity.  Radio-WANs are measured, on good days, in Mbit/sec
and that capacity is pro-rated across all stations on the net.  By
contrast, fiber links are routinely provisioned at 10Gbit/sec -- four
orders of magnitude more capacious (a capacity essentially infinite
compared to the radio-WAN).  This disparity will continue to grow over
time -- compare the potential of 1) DWDM advances and 2) more fibers to
the limitations of spectrum.   Multicast has far more payoff in radio-
WAN than in point-point plumbing.  Especially in a bandwidth-limited
radio-WAN.  
     o noise.  The radio-WAN will experience orders of magnitude more
bit error rate than the terrestrial-WAN.  This tends to influence
variables like packet size -- the noisier the environment the smaller
the packets, minimizing the expense per bit error.  
     Some of these limitations might indicate some layer 7 gateway
functions rather than the simple layer 3 forwarding that a router does.
 

- server functions.  RSU is ideally situated to provide some auxiliary
functions. And some are vital. DNS is a fairly obvious example.  DNS
lookups can consume a considerable amount of connection setup time so
colocating a caching DNS server at RSU strikes  me as cost-effective.
And as noted in last message, serving public keys would be required
somewhere in the internetwork; closer to the moving vehicle should be
better.
    Another server function that comes immediately to my mind is
differential GPS* (or differential Galileo if you are to be Euro and
eschew US GPS;-). An auxiliary function as a dGPS reference receiver
makes sense to me; the marginal cost is low.
    It'd make sense to mount cameras as peripherals to RSU, at least in
some situations -- your foggy conditions example.  This list is
flexible and open-ended; both functions to help automobile traffic and
functions to help traffic managers ashore.


Suggestion.  Would a standards-track RFC titled 'Requirements for
RoadSi
de Units' make sense?  Not unlike the old RFC1812

     
(*in a former life, I designed the differential GPS program that US
Coas
t Guard ran in maritime areas to provide integrity check and
improved
accuracy to raw GPS.  I can explain, ad nauseum, why this is a
good idea
and how it would work.  As we are discovering how fragile GPS
is, we may
see Loran reappear and differential Loran works too --
indeed that's
where we got the dGPS idea from.)


On Thu, 2017-05-18 at 09:33 -0400, Russ Housley wrote:
> 

(*in a former life, I designed the differential GPS program that US
Coast Guard ran in maritime areas to provide integrity check and
improved accuracy to raw GPS.  I can explain, ad nauseum, why this is a
good idea and how it would work.  As we are discovering how fragile GPS
is, we may see Loran reappear and differential Loran works too --
indeed that's where we got the dGPS idea from.)

> > On May 18, 2017, at 5:39 AM, Alexandre Petrescu <alexandre.petrescu
> > @gmail.com> wrote:
> > 
> > OLD:
> > > RSU: Road Side Unit. An IP router equipped with, or connected to,
> > > at
> > > least one interface that is 802.11 and that is an interface that
> > > operates in OCB mode.
> > A comment was made stating that an RSU is not a router, and that an
> > RSU
> > may be connected to a router via an interface, e.g. Ethernet, to
> > access
> > the infrastructure if required.
> > 
> > But I think that some Road Side Units are indeed IP routers and
> > they
> > access the infrastructure and the Internet.  This is an important
> > point
> > when using the IP protocol - be connected.
> > 
> > I think I keep that text that way at this time.
> > 
> > End issue.
> Alex:
> 
> Some RSUs will be routers, but others will not.  For example, an RSU
> that sends messages to vehicles about foggy conditions does not need
> to be a router.  I think the definition should allow both cases.
> 
> Russ
> 
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its