Skip to main content

Agenda IETF105: hotrfc
agenda-105-hotrfc-03

The information below is for an old version of the document.
Meeting Agenda Hot RFC Lightning Talks (hotrfc) Team Snapshot
Date and time 2019-07-21 22:00
Title Agenda IETF105: hotrfc
State Active
Other versions plain text
Last updated 2019-07-02

agenda-105-hotrfc-03
HotRFC @ IETF-105, Montreal
Sunday, July 21, 2019, 1800-2000
Info: https://www.ietf.org/how/meetings/105/hotrfc/
Materials: https://datatracker.ietf.org/meeting/105/session/hotrfc

=====================================================================

1. Service Oriented IP

Brian E Carpenter <brian.e.carpenter@gmail.com>

Service Oriented Internet Protocol (SOIP) proposes a new,
backwards-compatible, approach to packet forwarding, where the service
required rather than the IP address required acts as the vector for
routing packets at the edge of the network. There's a draft
(draft-jiang-service-oriented-ip) and there's even some toy code, at
https://github.com/becarpenter/tlv.

=====================================================================

2. Asymmetric IPv6

Brian E Carpenter <brian.e.carpenter@gmail.com>

Asymmetric IPv6 is a new approach to IPv6 header compression for use
in IoT scenarios where minimizing packet size is crucial but routing
performance must be maximized. There's a draft
(draft-jiang-asymmetric-ipv6). The idea is to make packets shorter
without needing a decompression step.

=====================================================================

3. iCAN Do It

Liubing (Leo) <leo.liubing@huawei.com>

iCAN (instant Congestion Assessment Network) is a mechanism running
directly on network nodes:

o To adjust the flows paths based on real-time measurement of the
  candidate paths.

o The measurement is to reflect the congestion situation of each path,
  so that the ingress nodes could decide which flows need to be
  switched from a path to another.  This is something that current SDN
  and TE technologies can hardly achieve:

o Controller is slow and far from the data plane, it is neither able
  to assess the real-time congestion situation of each path, nor able
  to assure the data plane always go as expected (especially in SRv6
  scenarios). However, iCAN can work with SDN perfectly: controller
  planning multi-path transmission, and iCAN does the flow
  optimization automatically.

o Traditional TE is not able to adjust the flow paths in real-time.
 
Aim: call for attention and partners
Relevance to IETF: This work might be related to TEAS/SPRING/IPPM WGs.

=====================================================================

4. Trustworthy Multipurpose RemoteID (TM-RID)

Bob Moskowitz <rgm@labs.htt-consult.com>
Stuart Card <stu.card@axenterprize.com>

To mitigate the risks presented by Unmanned Aircraft Systems (UAS),
the US FAA and other government agencies internationally soon will
require, and various bodies are drafting standards for, remote
identification. ASTM's proposed Broadcast Remote ID specifies how
Unmanned Aircraft (UA) within Line Of Sight (LOS) of an observer can
use a one-way RF broadcast to identify themselves and provide other
latency-sensitive safety-critical information. ASTM's proposed Network
Remote ID specifies how this same information can be obtained,
starting from an observed UA's location, via the Internet. All such
proposals hinge on a unique ID for each UA, a method whereby this ID
(along with operator contact information etc.) can be registered, and
a method by which a subsequent ID assertion can be authenticated by
authorized parties.

Network RemoteID uses the Internet to map current aircraft locations
to identities. To avoid being deceived by malicious spoofing of these
critical mappings, we need strong authentication. To maintain privacy
(from unauthorized eavesdroppers, not from legitimate authorities), we
need strong encryption. HIP provides both of these. Thus, we propose
to consolidate the 4-tuple of (UA ID, UA physical location, UA onboard
host ID, UA onboard host logical location [IP address list]) to a
3-tuple by standardizing the HIP Host Identity Tag (HIT) as a 4th
RemoteID type. Depending upon the level of adoption by a given UAS
operator, this can provide 3 levels of benefit:

  1. Use of the Internet Domain Name System (DNS, the world’s largest
     distributed database, with well-established update procedures) as
     a RemoteID registry

  2. Strong authentication of not only Network RemoteID but also
     Broadcast RemoteID messages

  3. Rapid establishment of authenticated and encrypted communications
     with any observed UA that is suitably equipped.

We call this “Trustworthy Multipurpose RemoteID (TM-RID)” and have
begun preparations for prototyping and experimentation at the New York
UAS Test Site.

A sidebof will be held Monday at 6pm in room C2.

=====================================================================

5. Mobility Networking

Sharon Barkai <sharon.barkai@getnexar.com>

Would like to introduce a new draft-rfc we have been working on in the
area of mobility, v2v, v2x, networking within the LISP working
group. LISP is a set of RFCs dealing with virtual IP and
map-assisted-ip-overlays.

Over the past decade mobility networks progress was slow and quite
stuck for multiple reasons. Many of these reason primarily stem from
questionable pre-assumed peer-to-peer model for mobility, and
redundant protocol wars that follow - DSRC/c-v2x.

Vehicles in most road situations are not really peers, they briefly
happen to be in the same place at the same time. An enforced peer to
peer model to communicate situations introduces privacy,
interoperability, security, timing, and convergence problems which are
hard to impossible to solve.

As an example, a vehicle reaching a junction and about to turn into an
invisible problem (to him) such as construction, jaywalker, double
park, school-bus. The problem is clearly visible to cross traffic, but
that vehicle may receive multiple, conflicting, or no indications at
all from cross cars it doesn't know or trust.

To solve this problem we focused strictly on layer3-4 or
connectionless brokered mobility sessions. We use the
shared-road-location, or geo-state, as the brokering anchor of v2v v2x
communications. Nexar, having some of the largest v2v fleets, 10Ks in
every major US city, 100Ms miles of ride logs, together with Cisco and
academia propose the nexagon draft.

Nexagons tiles every road, lane, junction, shoulder, sidewalk with
1sqm H3 hexagons giving each an aggregated unicast and multicast
virtual IP (LISP EID) address.  These are the in-network geo-state
network hexagons enable brokered, verified, private, resilient, LISP
based pub-sub exchange of road information. H3 Hexagons offer clear
bit operations to track impacted neighboring tiles, clear bitwise
geo-spatial hierarchy, approximation of lan-lat-rad that tiles, and
algorithmic 64bit HID to 128bit IP EID mapping.

We will describe the draft briefly in hotRFC, and few v2v v2x examples
including red-light-breach brokered-relayed in under 2msec in lab
conditions the largest 5G carrier, as well as real life footage
examples from US cities happening daily as time permits.  The draft
will be discussed at more length in the routing area LISP-WG meeting
on July 22.  Any questions can be forwarded to lisp@ietf.org or to
myself sharon@getnexar.com, or to any of the co-authors listed in the
draft.

Hope this is clear, attaching a couple links to short video and the
draft.

https://youtu.be/dK2II3oFzqE
https://tools.ietf.org/html/draft-barkai-lisp-nexagon-05

=====================================================================

6. An open congestion control architecture with network cooperation
   for RDMA fabric

Roni Even (A) <roni.even@huawei.com>

The requirement document discusses major problems of current Remote
Direct Memory Access (RDMA) fabric technologies and the requirements
for better performance. Based on that, the architecture document
proposes an open control architecture of hosts and networks for the
high performance RDMA fabric to provide better congestion handling for
High Performance Computing (HPC) and distributed storage accessing
applications which requires low latency and high throughput.

We will also have a side meeting to continue the discussion from
IETF104.

=====================================================================