Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt

["Templin (US), Fred L" <[e-mail]>]

Thank you, Rex - it will be good to have solutions that will address these needs
for worldwide vehicular communications in the not-too-distant future.

Regards - Fred

> -----Original Message-----
> From: Rex Buddenberg [mailto:[e-mail]]
> Sent: Friday, February 25, 2022 11:27 AM
> To: Templin (US), Fred L <[e-mail]>; Erik Kline <[e-mail]>
> Cc: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Dirk.von-
> [e-mail]
> Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt
> 
> Fred,
> 
> Wish I'd gotten this organized conception when I was still teaching
> such subjects. Belongs in textbooks.
> 
> b
> 
> On Fri, 2022-02-25 at 18:20 +0000, Templin (US), Fred L wrote:
> > Erik, the only place I know of that you will find the “6M’s”
> > discussed are in AERO/OMNI
> > themselves. Those documents are currently in the RFC ISE queue, but
> > could probably
> > serve the community better if they were brought into an IETF working
> > group and/or
> > advanced through some other standards-track publication approach. Any
> > thoughts?
> >
> > Thanks - Fred
> >
> > From: Erik Kline [mailto:[e-mail]]
> > Sent: Thursday, February 24, 2022 3:59 PM
> > To: Templin (US), Fred L <[e-mail]>
> > Cc: Pascal Thubert (pthubert) <[e-mail]>; housley@vigilsec.
> > com; [e-mail]; [e-mail]; [e-mail]
> > Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-
> > networking-26.txt
> >
> > Fred,
> >
> > I cannot find (via some light Google searching) any reference to an
> > industry standard understanding of these "6 Ms".  If we're going to
> > set down Principles of Networking like this I wonder if we should try
> > to get more review or maybe look for some academic citation even.
> >
> > If there is existing literature on this I'd be interested to read it.
> >
> > Thanks,
> > -Erik
> >
> > On Thu, Feb 24, 2022 at 12:51 PM Templin (US), Fred L <Fred.L.Templin
> > @boeing.com> wrote:
> > All, see below for my comments on 'draft-ietf-ipwave-vehicular-
> > networking-26.txt'.
> > It might be worth noting that my colleagues and I have been looking
> > at vehicular
> > communications use cases for a long time (e.g., see: RANGERS
> > [RFC6139]).
> >
> > Indeed, support for vehicular communications of all forms (land, sea,
> > air, space)
> > has long been the driving force behind the AERO and OMNI technologies
> > which
> > have taken their current shape as a result. Please see below for
> > comments and
> > make corresponding changes to the document.
> >
> > Fred Templin
> >
> > ---
> >
> > Comments on 'draft-ietf-ipwave-vehicular-networking-26.txt':
> > **************************************************
> > 1) Section 1, change: "Asymmetric Extended Route Optimization (AERO)
> > [I-D.templin-6man-aero]"
> > to:
> > "Automatic Extended Route Optimization based on the Overlay Multilink
> > Network Interface (AERO/OMNI) [I-D.templin-6man-aero][I-D.templin-
> > 6man-omni]".
> >
> > 2) Section 3, change: "The use cases presented in this section serve
> > as
> > the description and motivation for the need to extend IPv6 and its
> > protocols
> > to facilitate "Vehicular IPv6"."
> > to:
> > "The use cases presented in this section serve as the description and
> > motivation
> > for the need to augment IPv6 and its protocols to facilitate
> > "Vehicular IPv6"."
> >
> > 3) Section 3.2, change the paragraph beginning: "The existing IPv6
> > protocol
> > must be augmented through protocol changes..."
> > to:
> > "The existing IPv6 protocol must be augmented either through protocol
> > changes
> > or by including a new adaptation layer in the architecture that
> > efficiently
> > maps IPv6 to a diversity of link layer technologies. Augmentation is
> > necessary
> > to support wireless multihop V2I communications in a highway where
> > RSUs are
> > sparsely deployed, so a vehicle can reach the wireless coverage of an
> > RSU
> > through the multihop data forwarding of intermediate vehicles."
> >
> > 4) Section 3.3, change the paragraph beginning: "The existing IPv6
> > protocol
> > must be augmented through protocol changes..."
> > to:
> > "The existing IPv6 protocol must be augmented through protocol
> > changes or
> > by including a new adaptation layer in the architecture that
> > efficiently
> > maps IPv6 to a diversity of underlying link layer technologies.
> > Augmentation
> > is necessary to support wireless multihop V2X or V2I2X communications
> > in an
> > urban road network where RSUs are deployed at intersections, so a
> > vehicle
> > (or a pedestrian's smartphone) can reach the wireless coverage of an
> > RSU
> > through the multihop data forwarding of intermediate vehicles (or
> > pedestrians'
> > smartphones) as packet forwarders."
> >
> > 5) Section 4.1, second paragraph, change: "OMNI (Overlay Multilink
> > Network
> > Interface) [I-D.templin-6man-omni]"
> > to:
> > "AERO/OMNI [I-D.templin-6man-aero][I-D.templin-6man-omni]".
> >
> > 6) Section 4.1, third paragraph, change: "Furthermore, 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.
> > Note
> > that 2001:DB8::/32 is a documentation prefix [RFC3849] for example
> > prefixes in this document, and also that any routable IPv6 address
> > needs to be routable in a VANET and a vehicular network including IP-
> > RSUs."
> > to:
> > "In a first addressing alternative, 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. Note that 2001:DB8::/32 is a
> > documentation prefix [RFC3849] for example prefixes in this document,
> > and also that any routable IPv6 address needs to be routable in a
> > VANET
> > and a vehicular network including IP-RSUs. In a second alternative,
> > each
> > wireless media interface is configured with an IPv6 Unique Local
> > Address
> > (ULA) [RFC4193] that is assured unique within the vehicular network
> > according to AERO/OMNI and [RFC5889]. The ULA supports both V2V and
> > V2I
> > multihop forwarding within the vehicular network (e.g., via a VANET
> > routing protocol) while each vehicle can communicate with Internet
> > correspondents using global IPv6 addresses via OMNI interface
> > encapsulation over the wireless interface."
> >
> > 7) Section 4.1, fifth paragraph, change: "Alternatively, mobile nodes
> > can employ a "Bring-Your-Own-Addresses (BYOA)" technique using their
> > own IPv6 Unique Local Addresses (ULAs) [RFC4193] over the wireless
> > network, which does not require the messaging (e.g., Duplicate
> > Address
> > Detection (DAD)) of IPv6 Stateless Address Autoconfiguration (SLAAC)
> > [RFC4862]."
> > to:
> > "Alternatively, mobile nodes can configure IPv6 Unique Local
> > Addresses
> > (ULAs) according AERO/OMNI then support global communications through
> > OMNI interface encapsulation and forwarding of packets with MNP-based
> > global IPv6 addresses over the wireless networks. The use of
> > AERO/OMNI
> > ULA autoconfiguration assures uniqueness such that Duplicate Address
> > Detection (DAD) of IPv6 Stateless Address Autoconfiguration (SLAAC)
> > [RFC4862] is not needed."
> >
> > 8) Section 4.2, add the following as a final paragraph:
> > "In a second alternative when vehicles configure an OMNI interface
> > over
> > an underlying VANET based on ULA addressing, the global IPv6
> > addresses
> > covered by the MNP on-board the vehicle are not injected into the
> > VANET
> > routing system but instead traverse the VANET in the forwarding plane
> > via OMNI encapsulation. This allows each vehicle to maintain a
> > constant
> > and unchanging MNP delegation even as it moves between IP-RSUs. This
> > avoids any need for vehicle on-board network renumbering due to
> > mobility and avoids repeated injections and withdrawals of MNP
> > prefixes within the VANET."
> >
> > 9) Section 4.3, add new paragraph following paragraph beginning
> > "Figure 3 shows the internetworking" as follows:
> > "When two vehicles within a ULA-based VANET need to communicate
> > without
> > the assistance of any infrastructure, they can exchange
> > unencapsulated
> > IPv6 packets with ULA-based addresses which will be forwarded
> > according
> > to the VANET routing protocol. Alternatively, the vehicles can use
> > OMNI
> > interface encapsulation to exchange IPv6 packets with global
> > addresses
> > taken from their respective MNPs. The encapsulation source and
> > destination
> > ULAs are algorithmically bound to the IPv6 source and destination
> > global
> > addresses which allows for stateless encapsulation address
> > determination."
> >
> > 10) Section 4.3, final paragraph, there is no reason to cite as
> > examples
> > all RFC variants of the OLSR protocol and all extensions of the DLEP
> > protocol - pick one (or at most 2) RFCs for each. Also, it is
> > important
> > to state that standard OSPF routing has been optimized to support
> > MANET
> > applications. Suggested rewrite:
> > "...which serves MANET routing protocols such as the different
> > versions
> > of Optimized Link State Routing Protocol (OLSR) [RFC3626][RFC7181],
> > Open
> > Shortest Path First (OSPF) derivatives (e.g., [RFC5614]) and the
> > Dynamic
> > Link Exchange Protocol (DLEP) [RFC8175] with its extensions."
> >
> > 11) Section 5.1, second paragraph, change: "they need to be
> > configured
> > with a link-local IPv6 address or a global IPv6 address"
> > to:
> > "they need to be configured with link-local, unique-local and/or
> > global
> > IPv6 addresses"
> >
> > 12) Section 5.2, third paragraph, change: "An efficient DAD is
> > required
> > to reduce the overhead of the DAD packets during a vehicle's travel
> > in
> > a road network"
> > to:
> > "DAD is not needed in networks that follow the OMNI ULA
> > autoconfiguration
> > procedures. In other cases when DAD is needed, it must be made
> > efficient
> > to reduce the overhead of the DAD packets during a vehicle's travel
> > in
> > a road network"
> >
> > 13) Section 5.1.1, third paragraph, change: "There is a relationship
> > between a link and a prefix, besides the different scopes that are
> > expected from the link-local and global types of IPv6 addresses."
> > to:
> > "There is a relationship between a link and a prefix, besides the
> > different scopes that are expected from the link-local, unique-local
> > and global types of IPv6 addresses."
> >
> > 14) Section 5.1.1, add a new second-to-last paragraph as follows:
> > "Often when two VANETs merge some vehicles may configure addresses
> > from
> > a first subnet prefix while other vehicles configure addresses from
> > other
> > subnet prefixes. These merge events must not interfere with the
> > vehicle-to-vehicle multihop forwarding necessary to support
> > continuous
> > communications. Additionally, when a vehicle enters the network for
> > the
> > first time it may need to use a temporary ULA address in initial
> > messages
> > to negotiate with an IP-RSU for an address within the subnet. The
> > VANET
> > must therefore provide (short-term) forwarding for vehicles with
> > foreign
> > addresses, while the subnet prefix serves as an aggregation point of
> > reference for a particular IP-RSU without impeding multihop
> > forwarding
> > between vehicles that may belong to different subnets."
> >
> > 15) Section 5.1.3 goes too far in expanding on RPL. It is based on
> > the
> > claim that: "However, it will be costly to run both vehicular ND and
> > a
> > vehicular ad hoc routing protocol in terms of control traffic
> > overhead
> > [RFC9119].". But, the AERO/OMNI approach uses only the MANET routing
> > protocol control messages at the subnet level then applies unicast-
> > only
> > IPv6 ND messaging at the OMNI interface level so that there is no
> > traffic
> > amplification due to multicast IPv6 ND within the subnet. Therefore,
> > a
> > new third paragraph telling how it works in AERO/OMNI should be added
> > as follows:
> > "The AERO/OMNI approach avoids this issue by using MANET routing
> > protocols
> > only (i.e., and no multicast IPv6 ND messaging) in the wireless
> > network
> > underlay while applying efficient unicast IPv6 ND messaging in the
> > OMNI
> > overlay on an as-needed basis for router discovery and NUD. This
> > greatly
> > reduces the overhead for VANET-wide multicasting while providing
> > agile
> > accommodation for dynamic topology changes."
> >
> > Additionally, the RPL text should be reduced by at least 50%.
> >
> > 16) Section 5.2, paragraph 6 change: "Even though the SLAAC with
> > classic
> > ND costs a DAD during mobility management, the SLAAC with [RFC8505]
> > does
> > not cost a DAD."
> > to:
> > "Even though classic IPv6 ND requires the use of DAD on many link
> > types
> > during mobility management, address autoconfiguration based on
> > [RFC8505]
> > and/or AERO/OMNI does not require DAD."
> >
> > 17) Section 5.2, paragraph 6, remove the following text entirely:
> > "On the other hand, a BYOA does not allow such direct routability
> > to the Internet since the BYOA is not topologically correct, that is,
> > not routable in the Internet. In addition, a vehicle configured with
> > a BYOA needs a tunnel home (e.g., IP-RSU) connected to the Internet,
> > and the vehicle needs to know which neighboring vehicle is reachable
> > inside the VANET toward the tunnel home. There is nonnegligible
> > control
> > overhead to set up and maintain routes to such a tunnel home over
> > the VANET."
> >
> > Reason: There is always a cost for maintaining mobility management
> > for addresses within an MNP. It can be done either by frequent
> > advertisements/withdrawals of the MNP in the global routing system or
> > through coordination with a mobility anchor point in an overlay via
> > encapsulation. The Connexion by Boeing experience showed that dynamic
> > routing protocol updates do not scale in the global Internet. The
> > AERO/OMNI services instead minimize routing protocol disturbance
> > while using efficient mobility signaling in the overlay.
> >
> > 18) Section 5.2, near the end, remove the following sentence: "IP
> > tunneling over the wireless link should be avoided for performance
> > efficiency."
> >
> > Reason: IP tunneling is used only in support of global-scoped IPv6
> > communication (not local-scoped) and can use effective header
> > compression for greater efficiency as in AERO/OMNI. In addition,
> > there is value in using encapsulation both from the standpoint of
> > minimizing global routing protocol overhead and by accommodating
> > path MTU diversity (see below).
> >
> > 19) Add a new Section 5.3 as follows:
> > "5.3 Accommodating MTU Diversity
> >
> > The wireless and/or wired-line links in paths between both mobile
> > nodes and fixed network correspondents may configure a variety of
> > Maximum Transmission Units (MTUs), where all IPv6 links are required
> > to support a minimum MTU of 1280 octets and MAY support larger MTUs.
> > Unfortunately, determining the path MTU (i.e., the minimum link MTU
> > in the path) has proven to be inefficient and unreliable due to the
> > uncertain nature of the loss-oriented ICMPv6 messaging service used
> > for path MTU discovery. Recent developments have produced a more
> > reliable path MTU determination service for TCP [RFC4821] and UDP
> > [RFC8899] however the MTUs discovered are always limited by the most
> > restrictive link MTU in the path (often 1500 octets or smaller).
> >
> > The AERO/OMNI service addresses the MTU issue by introducing a new
> > layer in the Internet architecture known as the "OMNI Adaptation
> > Layer
> > (OAL)". The OAL allows end systems that configure an OMNI interface
> > to utilize a full 65535 octet MTU by leveraging the IPv6
> > fragmentation
> > and reassembly service during encapsulation to produce fragment sizes
> > that are assured of traversing the path without loss due to a
> > size restriction. (This allows end systems to send packets that are
> > often much larger than the actual path MTU.)
> >
> > Performance studies over the course of many decades have proven that
> > applications will see greater performance by sending smaller numbers
> > of large packets (as opposed to larger numbers of small packets) even
> > if fragmentation is needed. The OAL further supports even larger
> > packet
> > sizes through the IP Parcels construct [I-D.templin-intarea-parcels]
> > which provides "packet-in-packet" encapsulation for a total size up
> > to 4MB. Together, the OAL and IP Parcels will provide a revolutionary
> > new capability for greater efficiency in both mobile and fixed
> > networks."
> >
> > 20) Appendix B, add the following as a final paragraph:
> > "AERO and OMNI together securely and efficiently address the
> > following
> > 6 M's of Modern Internetworking for mobile V2V, V2I and V2X Clients:
> >
> >    1.  Multilink: A Client's ability to coordinate multiple diverse
> >        underlying data links as a single logical unit (i.e., the OMNI
> >        interface) to achieve the required communications performance
> > and
> >        reliability objectives.
> >
> >    2.  Multinet: The ability to span the OMNI link over a segment
> >        routing topology with multiple diverse administrative domain
> >        network segments while maintaining seamless E2E communications
> >        between mobile Clients and correspondents such as air traffic
> >        controllers and fleet administrators.
> >
> >    3.  Mobility: A Client's ability to change network points of
> >        attachment (e.g., moving between wireless base stations) which
> >        may result in an underlying interface address change without
> >        disruptions to ongoing communication sessions with peers over
> > the
> >        OMNI link.
> >
> >    4.  Multicast: The ability to send a single network transmission
> > that
> >        reaches multiple Clients belonging to the same interest group
> >        without disturbing other Clients not subscribed to the
> > interest
> >        group.
> >
> >    5.  Multihop: A mobile Client's V2V relaying capability useful
> > when
> >        multiple forwarding hops between vehicles may be necessary to
> >        reach back to an infrastructure access point connection to the
> >        OMNI link.
> >
> >    6.  MTU Assurance: The ability to deliver packets of various
> > robust
> >        sizes between peers without loss due to a link size
> > restriction,
> >        and to dynamically adjust packet sizes in order to achieve the
> >        optimal performance for each independent traffic flow."
> > _______________________________________________
> > its mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/its