Delay/Disruption Tolerant Newtorking (dtn) WG

IETF 119, Brisbane
2024-03-22, 09:30-11:30 ET, Australia

Area Director: Zahed Sarker
Chairs: Ed Birrane, Rick Taylor
Secretary: Adam Wiethuechter

Introduction, Note Well & Milestones (5 mins)

Speaker: Chairs
Document: N/A

cEB: welcome all, pass to cRT for slides
cRT: welcome! Hello YouTube viewers!

Lots to get through, 10 mins left for open mic.
Ed will be 3GPP

Changing ADs, Zahed thank you so much! Welcome to Erik Kline!

cEB: various states of documents and current status with milestones

AD Updates (10 mins)

Speaker: Zahed Sarker / Erik Kline
Document: N/A

ZS:
Lot of DTNMA. Followup documents. Talking with other WGs.
Good shape, hope foes well.
Work and progress on registries with IANA

adEK: hello and thanks for bringing me up to speed.

-- technical difficulties with Brian Sipos, moving past his
presentations

Constrained Application Protocol (CoAP) over BP (25 mins)

Speaker: Carles Gomez
Document: https://datatracker.ietf.org/doc/draft-gomez-core-coap-bp/

• 2

  • intro and motivations
  • CoAP for IoT env. based on REST

• 3

  • main goal to specify CoAP over BP
  • target WG? -- CoRE / DTN?
  • keep both in loop

• 5

  • designed for over UDP
  • same model applied to BP

• 6

  • 2 sublayers
  • requests by clients, responses by server
  • messages; types CON, NON, ACK and RST

• 7

  • minor optimization
    • use "request report of bundle delivery" on BP(CoAP CON)
      message for CoAP ACK

• 8

  • message format
  • may need to increase message id field size for BP

• 9

  • parameter settings that may be relevant
  • do we need congestion control?

• 10

  • related time parameters
  • some implementations use 8-bit timers for CoAP

Rodney Van Meter: deep space numbers might not be enough for E2E or does
it only have to be time of flight?

Will need to include other delay components - the numbers on slide is
ideal

RVM: don't use such a small number for MID, but bit count does matter...

Correct - there is a trade off here.

RT: given that bundle has unique id with seq number, could Message ID be
delegated?

Had thought about - CON might need retries from source, but might be
encapsulated.

RT: sequence of message in conversation not of the bundle.

• 11

  • observe: send update notifications of server status

• 12

  • block wise transfers for larger payloads (fragmentation)
  • RFC9177 may be more suitable that RFC7959

• 13

  • URI scheme
  • new one: coap+bp similiar to CoAP except for endpoint ID
  • might not be needed?

RT: endpoint IDs, two different schemes. Numeric and DTN (text) both
have URI representation. Whoever said it was right. coap+dtn or coap+ipn
but just coap might be way to go.

• 15
  • reference times for interplanet comms

EB: where is pluto? new horizons team is sad.

DVM: 22.5 hours one way latency for Voyager I

Magnus Westerlund: flow control repair schemes. convergence layer
handles congestion. how many concurrent requests can you handle? how
many total messages wish to burden link with.

Joshua Deaton: missed or bad assumption; aggregating multiple CoAP in
single bundle?

Currently not considering but might be something to look at.

RT: really support this work. App layer protocols to run over BP.
guiding princpal and look at information in primary block or extension
to avoid semantic duplication.

Scott Burleigh: 1; contact antara technic that has closed source
implementation of CoAP over BP. CON messages; simplier to avoid config
problems to use NON instead and rely on BP being reliable and congestion
aware substrate.

Thank you.

cEB: not a call for an adoption, any concerns about approach
standardizing CoAP over BP?

adEK: concern, maintain comms with CoRE WG with reviews and critical
junctions

BIBE Updates (15 mins)

Speaker: Scott Burleigh / Alberto Montilla
Document: N/A

AM:

• 2

  • existing expired Aug 2020
  • new version soon
  • BIBE keep to service provider networks; tech demo in ISS
    upcoming
  • migration

• 3

  • service provider networks
  • domain is used loosely in definition
  • critical for policy enforcement within a domain

SB:

• 4
  • overview of changes BIBE in ION around Service Provider usecase
  • need control over parameters in BIBE source that condition
    forwarding
  • add additional processing flag for BIBE for exception to rule in
    RFC9171

RT: admin records for BIBE; BIBE payload is admin record through tunnel
surely wouldn't set bundle in primary block. do you need change 9171?

Stil ladmin record when it is received at destination the payload of the
encapped bundle needs to be delivered to BP agent not the user. BP agent
gets ...

RT: get wary of changing 9171, need a diagram?

Diagram would be nice otherwise brain breaks. doesnt depart from intent
of spec.

RT: challenge once encapped the content of the payload is opaque until
the decap point. hence the more flags in outer payload the more
transparent you make opaque payload...

Simplest way I could think of.

RT: list or wait for more information

• 5
  • summary of what Joshua Deaton and others are doing
    Joshua Deaton:
  • BIBE was for encap of different versions
  • for implementation in ISS
  • defintion pseudo-BPv6 BIBE admin record in an annex so that it
    can covered for keeping both directions
  • redirect options for convergence layers
    AM:
  • delivering draft once ready

Quality of Service Extension for BP (20 mins)

Speaker: Teresa Algarra
Document: N/A

Hello from Germany working on QoS for BP for PhD work

• 2

  • focus on Earth to Moon comms
  • congestion with single relay point
  • CCSDS orange book

• 3

  • proposing extension blocks
  • 1x QoS block
  • Nx Network QoS block

• 4

  • block structures are similiar
  • Network QoS blocks can be added and removed along with way
  • using CBOR maps

• 5

  • User QBEB
  • traffic priority
    • values are ranges allowing ranges within info type

• 7

  • 3x queues: critical, quasi-real, store&forward
  • weighted queuing

• 9

  • required reliability
  • ranges again

• 10

  • latest only (wip)
  • someone else is working on this

• 12

  • NQEB short as for more local use
  • could translate UQEB into internal policy

AM: consider/compare options with policy in node? why carry in extension
block.

Added due to being incredible complex and not scalable

JD: discuss the reason for inserting node id rather than BIB to ID that
fact?

Chosen to avoid one network block going into another network.

JD: why couldnt you just use BIB (Bundle Integrity Block) to identify
that fact and drop both when they need to go away?

Haven't looked into using that - thank you.

JD: make network block field as option in user block.

Problem then the block would be dynamic and check that original content
has not been modified along the way.

JD: can take offline

RT: great work. thank you for spliting the blocks. big heterogenous
networks that from DSCP that as soon as packets leave one admin domain
QoS is stripped away. if application (user) can say what is important to
them in a way in an immutable way so other blocks can be added and
removed along the way - that is spot on.

SB(chat): FWIW, I remain skeptical that anything beyond a user-asserted
data label (or "flow label", or other species of label) needs to be
carried in a QOS extension block. The idea being that each BPA can use
some combination of source EID, destination EID, data label, bundle
size, day of the week, whatever to select the QOS policy that it will
want to use. That determination can be complex, it can be simple, but I
think it's what nodes are going to do in practice anyway.

BPv7 Admin. Record Types Registry (5 mins)

Speaker: Brian Sipos
Document:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpv7-admin-iana/

cEB: i am not Brian Sipos but I shall be for the next few minutes.

• 2
  • still in WGLC, need to update
  • expired last month and no comments were made
  • holding up work in ACME

cRT: add one thing. ADs can we proceed with IESG review with expired
doc?

adEK: there was talk of never expiring documents as all documents never
go away...

BPSec COSE Context (10 mins)

Speaker: Brian Sipos
Document: https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-cose/

• 5

  • adopting of cose to avoid redoing work

• 7

  • no issues would change document massively just increase interop

• 9

  • not intended to replace existing BPSec
  • through WGLC no additional comments
  • look for shepard for this document

cRT: sheparding is not difficult

BP EID Patterns (10 mins)

Speaker: Brian Sipos
Document: https://datatracker.ietf.org/doc/draft-sipos-dtn-eid-pattern/

• 11

  • compatible with ipn scheme update

• 13

  • propose capabilities with dtn and ipn scheme patterns

• 15

  • EID pattern not an EID; do not interchange

cEB: does this have utility as patterning?

AM: do support this and has value for grouping and formatting. common
standard dealing with numbers.

cRT: same as AM. patterns are for users and their tooling for text
representation of EIDs. concerns of where this interacts with routing.
defining common text representation for pattern matching full support.

cEB: same as CIDR

RT: worries me. patterns do not solve without logical operations,
especially for ipn. good first start and publishing will open more
question which is good.

cEB: any concerns with this as proposed (looking at examples)?

SB: think very good. nicely compressed and very useful.

BS: does not have a lot of implementation experience yet. GitHub has
some issues tracked already. aspects not looked at: how to handle
unknown scheme (posted on ML). not a matter of if, but how.

cEB: what is proposed use in routing?

BS: interesting point. the way CIDR is used for config was not intended?
this is opposite direction, could use in configuration and protocols for
routing but not intent. and also authorization.

cEB: can you explain complex logic

BS: has to be worked out in draft when dealing with numbers and ranges
is easy. authority part has structure? either match all or regex. can't
say easily regex(a) subset of regex(b). follow approach of dns name, but
not then maybe do pattern logic for heirarchy. expediate: do not deal
with dtn scheme.

BS: next step is feedback! we don't know enough about dtn authority
component and focus on ipn and what is useful now. include imc or
anything in future.

JD: ipn pattern please. is there any reason for patterning for service
number?

BS: each part of handled symmetrically so it applies to service numbers.
these patterns are useful for application to register to endpoints.

JD: used internally. good work.

3GPP SA1 Store-Forward Use Cases (10 mins)

Speaker: Ed Birrane
Document: N/A

• 2

  • 3GPP SA-1 WG focus on requirements
  • store and forward satellite operations

• 3

  • non geo stationary space segment dtn work

• 4

  • look up using title of slides

• 5

  • subset of some requirements for store&forward

Bringing up for informational to DTN service coming out of 3GPP
SA-2 architecture wg in 3GPP
Many arch proposals
How are they aware of the standard we are producing?

Charles Eckel: laison manager for 3GPP and is now on radar. Looked at
SA-2 and do reference DTN work from here. We could have a laison and
talk about leveraging work we have done. This document is not part of
normative specification, should look to see if there is a TS. More with
SA-2 and others.

cEB: any help on the points of contacts are helpful.

Jim Reid: ITU Study Group 13 and advancing cause of QoS for sat stuff -
we need to aware to stop them doing bad things.

Jenny Cao: @TVR meeting, presentation pointed out that DTN was marked
out of scope (but important).

cRT: store&forward means so many things. very bounded for their
use-cases. BP may be considered overkill for them. more for solving
broader problems than their use case. interested to see where they go.

AM: additional topic not covered here but is lunar surface in a similiar
context.

AMM/ADM/ARI Updates for DTNMA

Speaker: Ed Birrane

Work here is not complete, just been adopted.

adEK: related with AOB, presentation in NETMOD?

cEB: went well! overall was no concern all supportive questions and
comments. goals of command based was understood and NETMOD chairs
affirmed that is good to do and done in DTN. Review with NETMOD. YANG
Next is coming, we are invited to open issues with anything found hard
to model now.

Open Mic (10 mins)

Speaker: N/A
Document: N/A

cRT: jumping in. we need to look at DTN scheme. We need more maturity
how we specify EIDs. DNS form was mentioned. Not a lot of BCP. What is a
DTN URI and what does it mean?

Scott Johnson: if we are considering DTN like/structured names we should
engage DNS community and a RR type for that. CH record type? if we give
DNS names make accomodation.

cRT: just meant text format, not tying to record.

SJ: will want lookuo function.

JR: I am a DNS person. You want a RR its really easy.

cEB: lets consider on ML! See you are 120!!