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

[Rex Buddenberg <[e-mail]>]

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