Re: [Drip] Comment on -arch-22

[Robert Moskowitz <[e-mail]>]

Jens,

I have had a few moments to reread your message.  Let me try and tell 
you what our goals are for DRIP and what is in the immediate pipeline 
and what remains to tackle.

The DRIP charter is at:

https://datatracker.ietf.org/wg/drip/about/

we are constrained by our charter to be working on Remote ID, but that 
includes Network Remote ID.

Our first set of work is around Broadcast Remote ID, and I need to 
finish up the main document on our Trustworthy Remote ID using 
Hierarchical Host Identity Tags (HHIT).  Adam is working on the 
broadcast authentication messages and the Remote ID registration pieces.

One last part of the broadcast part is my crowd-sourced remote ID draft 
of which we have a customer that wants me to get this finished as well.

Operator privacy SHOULD be important for broadcast, but neither the FAA 
or EU seem to care about this, but my draft is available:

Then we move on to Network Remote ID.  I should add that supposedly once 
ASTM F38 finishes the current 1.1 document there is a general agreement 
to provide an 'open standard' for Network Remote ID. Currently, each USS 
has its own flavor of NRID.  This is our opportunity to drive the F38 
and other processes.  I really need to finish up Broadcast work so I can 
really fill in Network and would greatly love to have real help!  You 
seem to have a piece of the understanding of what is really perhaps 
needed here.

BTW, it is from the EU participants in F38 where the push to do an open 
Network RID approach.

I look forward to talking to you about this.  In my opinion, C2 and NRID 
use similar solutions, but C2 is more demanding in that both parties may 
move in the network.

As far as controlling media handoff rather that 'transparent', there is 
the work done in IEEE 802.21 that MAY be of help.  Lots of good work 
done, but there was no compelling use case.  Perhaps it is here?

Bob


On 3/24/22 08:59, Jens Finkhaeuser wrote:
> Hi,
>
> there is some conflict between the aviation world and the Internet 
> world, and since they meet in UAS, that's where the conflict happens.
>
> ------- Original Message -------
> On Thursday, March 24th, 2022 at 13:05, Robert Moskowitz 
> <[e-mail]> wrote:
>
>> Handoff among different links (and different link technologies) is 
>> something we are trying to address. In our own test flights, for C2 
>> (not UAS RID), we have used HIP, MP-TCP and other protocols to fail 
>> over transparently
> Yes, we essentially replicate MP-TCP components but for strictly 
> datagram/packet oriented "links" (terminology is a mess here with 
> respect to ISO/OSI but it seemed the best compromise). This is borne 
> out of issues with MP-TCP we've had in practice in border regions and 
> completely unrelated to drones.
>
> The protocol we've built here is a (set of) state machine(s) that 
> observe/manage unidirectional flows and consider a multi-link 
> established if at least one unidirectional flow in either direction is 
> active. I suppose it's a generalized form of MP-TCP's behaviour. Data 
> is encapsulated and sent over the highest priority egress flow.
>
> In practice, we've mostly used UDP/IP uniflows that then come in 
> pairs, so the protocol is a little overgeneralized for this case. 
> However, it allows us to use different send and return channels.
>
> I've written a draft paper about this, but it never got all that far 
> due to other work items gaining priority. If there's an interest in 
> this in the IETF, I wouldn't quite know which WG or when to carve out 
> time to convert this to an IETF appropriate form. Plus, my employer 
> would have to agree.
>
> Not that this is the main topic here.
>
>> Bob Moskowitz and I would appreciate any inputs/help we can get on 
>> leveraging DRIP (focused on UAS RID) to facilitate robust 
>> identity-oriented V2I communications for C2, DAA, etc. :-)
>
> Well, when I mentioned this aviation - network "conflict" above, we've 
> noted during our cooperation that the transparent failover is not 
> something that sits all too well with the aviation world. They're very 
> much in favour of higher level functions being in control of the 
> failover. That's something we can address, but detracts a little from 
> the simplicity of a plugin-in, multi-link technology. Live and learn.
>
> More to the point: I think the identifier/locator split you're 
> proposing as well as the specific formats for each are just fine, for 
> what it's worth, but my initial caveat that I haven't had all that 
> much time yet for review still stands.
>
> First point last: I think the majority of BVLOS scenarios do assume 
> Internet connectivity. Strictly speaking that's not true, but it is in 
> practical terms.
>
> EASA consideres different categories of drones; we tend to focus on 
> the "specific" category, which has weight/range/lift characteristics 
> suitable for commercial or emergency delivery missions. Because of the 
> commercial application, there's a strong desire to have low cost - 
> both in hardware and operations - which must be balanced against the 
> safety needs of the regulators.
>
> So any connectivity options are essentially based on off the shelf 
> offerings, which also means from a reliability/security perspective 
> they're treated as black channel. But for the purposes here, within 
> size, weight and power limits, it's easier to cram more of them into a 
> drone and get reliability from a software layer above than to invest 
> into different radio technology.
>
> So in practical terms, most commercial mission profiles will be able 
> to rely on 3GPP availability (maybe failing over to Wifi), which means 
> Internet access. That much is very true.
>
> But a variety of commercial or emergency applications are very 
> explicitly about remote or inaccessible areas. One scenario we're 
> discussing revolves around a rescue situation within a burning 
> chemical factory. You send in a robot on wheels and a swarm of drones 
> to map the area. The robot will most certainly act as radio base 
> station for the drones, and it may also act as a limited ground 
> control station - especially when it's own link to the outside of the 
> building is interrupted. Even if that link is stable, a mobile ground 
> control station placed outside of the building in a van may not 
> provide Internet access in all areas. Identification becomes necessary 
> whenever the drone loses and regains connectivity to its GCS, 
> whichever that is.
>
> The good news here is that this doesn't necessarily need to fit into 
> U-SPACE's network identification needs. It may be enough for U-SPACE 
> to cordon off the entire area because of the emergency situation, and 
> let identification become an entirely local concern. But the same 
> drone may need to report to U-SPACE in the next mission, so building 
> distinct and incompatible identification systems does not seem sensible.
>
> I really do need to read the DRIP drafts in much more depth... I saw 
> the "last call" and did a bit of a panic review. I'll be able to get 
> to that... maybe next week? I'll let you know.
>
> Jens
>