# IETF 114 DTN WG Meeting Tuesday 2022-07-26 14:00 - 16:00 (UTC) Chairs: Rick Taylor, Ed Birrane Secretary: Adam Wiethuechter ## Abbreviations Zahed Sarker (AD): adZS Rick Taylor (Chair): cRT Rick Taylor: RT Ed Birrane (Chair): cEB Adam Wiethuechter (Sec): sAW Adam Wiethuechter: AW Keith Scott: KS Brian Sipos: BS Scott Burleigh: SB Jonathan Wilmot: JW Ronald in 't Velt: RV Mark Net: MN John Cook: JC Jordan Torgerson: JT Stuart Card: SC # Agenda ## Admin (5 mins) - Chairs cRT: promises not to sing cRT: note well cRT: bash of agenda cRT: originally two sessions, did not get cRT: wanted a working meeting on naming and addressing as broad cRT: condensing around some ideas, great to have some drafts but need scope cRT: compressed today; 1-hour of docs, 1-hour workshop cEB: nothing to add; check volume cEB: CCSDS WG cEB: builds stds for space; there is a DTN WG there cEB: area of overlap is how much of ecosystem/arch is shared across space and terrestieral, what is specific to each area? cEB: leads to naming and addressing, custody transfer, etc. cEB: specific details or general? cEB: asked to come and take some time to give their idea of overlap and gauge IETF ## CCSDS SIS-DTN Discussion (10 min) - Keith Scott - CCSDS is the international standards body responsible for standardizing communications with civial space missions. CCSDS is composed of space agencies, both national and multinational. - just finished profile of BPv7 to area director for std (https://cwe.ccsds.org/sis/_layouts/15/WopiFrame.aspx?sourcedoc={25DC4462-85DD-4691-86F0-1FF362AE1F6E}&file=CCSDS%20SIS-DTN%20BPv7%20Red%20Book%20Draft%20V4.docx&action=default) - very much grounded in BPv7 RFC - MUST implement 9171 and some restrictions you may face - e.g. no larger than 10MB bundles - service specification as required by CCSDS - convergence layer adaptors: e.g. LTP - type:value pair multiplex bundles into a LTP block - CBOR unsigned int, bundle - There are issues between the IETF and CCSDS not just of overlap of needed capabilities, but also the timing of those needs. CCSDS has some upcoming missions, (e.g. PACE, Gateway) that need SOMETHING to do now. We're trying to convince them to use the standards where they exist and, for additional requirements (mission-specific or not) to do something and we'll work to standardize those mechanisms that make sense. - Missions now using BP; still looking at BPv6 - Focused on custody transfer mechanism - Times where we diverge; understand where efforts going - Keep in line as much as makes sense - Pushed off a lot till later to get initial spec out door - Reliabality, accounting, qos - Things CCSDS need as well - Network management include accounting? - Reliability - Release resources ASAP - Stronger than convergence layers - single link; multiple access - EASA capability desire like in BPv6 - Thoughts blending relability and accountability - AKIN to aggregate custody signalling as developed for ISS - Signals and metadata about state of network that are bit effecient - Accounting (false start) - Where bundle, where resouses and how being used? cEB: questions now or at end? KS: lets do it now on reliablity cEB: when we talk about relability two porposals; is there a mechanism in an extension block or an artifact of a convergence layer? WG: do we believe that those are two options in parallel or 1 or the other? KS: always have option of reliable convergence layers; cant be one or the other. is network arch in such a way....1) need reliability from network to BP as a service; 2) will you do that with CLs? cRT: even if you have reliable CLs there has to be signalling at BP level to say you MUST use the reliable CLs. explicit in some way BIBE or some way, can not be implied. "I have built my network off reliable CLs therefor will be reliable" - IETF needs more generic solution for these things JW: little bit more; custody signal at bundle level. We have the resource to store it - cant get iether with reliable CL; CL says I have bit that were sent; doesnt say it was stored. Agree with KS all are options we should allow cRT: locked queue; good discussion but lets not eat session time SB: What sort of CL protocol source application desires to be used is a thing we need to consider in QoS - very useful BS: help frame discussion on flash point CLs cant provide it; LTP-CL could do but are silent on what ACK means; could say when ACK transfer it means stored and forwarded - so can have meaning just not specified cEB: lets not have here in real time - energy to ext block to signal reliability and custody. who should handle; ietf, ccsds? Please remember as use case - Accounting - first foray into networking for space; link to single spacecraft - concered of did bundle make it to destination - a lot of this network management - desire to be able to get insight where bundles are - important for multi-national cooperatives - autonomous systems in network by various national agencies - state of nodes - how much storage? how many errored bundles rcvd? - AMP? - realtime accounting needs; from BP status reports - operationally could make a lot of overhead in network - need to craft rules of kind of reports when - control of nodes and ability to specify this - terresterial nodes -> space nodes - AMP configurable in a way to create network management message for - i saw a bundle like this that went though me cRT: status reports are control plane in ground singalling; stats for smooth operations of network. DTN stack can ahd should collect and aggregate these. stats cEB: exactly right; did have DTN-NM for this mtg....not enough time this time. Some level of mobie auto is needed in mgmnt plane; self config and reporting especially for others. Not overlap is on the wire encoding of the model - DTN-AMA document touches this? CoAP for encoding? Hot topic. Autonomy model and use cases are shared across. cRT: OPS AD in the room - laison for larger mgmnt wgs; we have access to that depth of best practice OPS AD: right sort of atitude; cross share of ideas - Accounting (cont.) - Different UDP-CL; dirt simple - Need to incorperate into another document; if interested? cRT: Bran Sipos updating UDP-CL for -bis Erik Klien: handle MTU issues? KS: have to fragmented at BP layer to fit in the CL cRT: thanks! very informative; keep comms open is great cEB: ditto ## BPv7 Administrative Records, COSE Context (10 mins) - Brian Sipos - Admin Records - goal is feedback - same as presented last ietf - gap left from 9171 with table that was not updated so its updated with v6 adn v7 - request for adoption cRT: WG adoption call on list after session - COSE Context - Does what it needs to do in narrow scope - No PKI integrate sec. - Brought up in review by SEC DIR - Proposal to use pre-exsiting structure: COSE and put int BPSec - Embedded as Sec context - Single code point - Interop profile cRT: draft for this? BS: expired cRT: update and ask for adoption BS: feedback wanted cRT: small changes; push back alive and then do adoption EB: support this work and get more BPsec contexts are great; others in CCSDS cEB: has anyone in COSE reviewd? can that happen between now and then ater minor update to ressurect? cRT: worth adopting first; but early review totally valid cEB: fine and happy to adopt BS: put on cose list before and ignored due to being individual draft ## Neighbor Messaging & Discovery (15 min) - Brian Sipos - speculative and asking for comments - milestone for current charter - proposal - do not reinvent so make use of BPA and BPsec - BPsec for message signing - BPA lifetime and hop - CLs unicast and multicast - New message bundle mandating exisiting mechanisms - Neighbor is 1-hop that is direct via a CL - New well known endpoint; dtn:neighbor like dtn:none - contents are map with labels - like manet uses its owns packet and messaging format - No new ext blocks - Do same job as IP ND RV: always have to be UDP-CL present to do this BS: depending on use case; yes. slide 17. in open network you would need to use multicast udp but in controlled envirornment that is advertised by DLEP then probe the peer when link comes up RV: ??? BS: could be, hello message would cover same ground as IP ND + integrity, signing and other things SB: I like this idea a lot - CL aspect may not be right. Conveying in bundles is cool to get information to BPA. Simpler and cleaner to add aditionally discovery CL adapter; lot of link adapters so BP doesn't need to handle this. Thinking of LTP as a model. propose Neighbor Discovery CL protocol. cRT: disagree - no need for new CL; need a std way to pass around messages. dtn:neighbor is clever - leave internal BPA to do deal with how to get to neighbor over whatever they can; per CLA understanding - turning to naming and addressing topic EK: link-local multicast address BS: a smart BPA will do a lot of complicataed thing and dumb one just follow simple rules BS: separation between hello message content - interop minimum but a lot of vendor and special extension to expose for handshaking RV(v): think I have said this before, but NHDP is the NeighborHOOD Discovery Protocol of MANET, a totally different beast (aimed at discovering the 2-hop neighborhood of a node). cEB: Call attention to RV comment in chat cRT: in process of writing a draft? BS: link exists as standalone non-dt document as a "is this worthwhile?" cRT: this is on charter; looking for collaborators? Looking at RV. Want collabs? BS: yes definitely RV: Will be willing to review whatever you write, can not contribute a lot of text ATM BS: it exists as concept not detailed EK(v): is there a draft for this ND stuff? ## Naming and Addressing (15 mins) - Scott Burleigh - Defintions - Name = a character string to ID a thing of the same type - Location = a point in space - Address = Name of location - needs to be unique - Node = state machine that resides at location - Properties: name, address - Routing - To send/copy data through a network - Internet Routing - IP locations change infrequent - DTN Routing - BP locations change often - remote address currently known unsafe to use - Late Binding - ... - Destination needs Name not Address - Changes intra-region vs. inter-region? - How to get to edges? - Regions cRT: clarifying question; two ways to view it. 1) this is effectively subnetting, mobility within the space of topology it is localized. 2) do these regions have differet naming schemes between orgs and have agreements between them? SB: Lets tkae that later MN: at somepoint you imply in a region nodes don't change much... SB: within a region a nodes location might change a lot, but not swap between regions MN: clarified thank you - Management - working in a subnetting way of a region - global authority for global region tree - tree mgmnt JC: regions predefined or dynamic? SB: dynamic JC: defined by lcoation? SB: based on contact graph routing, region is not geo but topological - Discovery - region tree is recivsed by agreements between authorities - complete tree cRT: in danger into routing; we must dance around it. which of many next hops must we use? actually naming implicitly gives routing info. RT: something about this does not chime with me SB: discovery mechanism is adjusted locally you dont route on tree topology RT: understand difference between dynamic discovery of path or preplaced. describing name as address - Encoding - Global needs name and region - Evolving only name, you must late bind all the way - Two EID schemes - How to handle when nodes move from region to region? - Advanced notice of move - schedule impending move RT: summary slide useful. second bullet is my understanding of internet built (do not get caught up with ID/Location sep.). first point could be as hort term compromise - orgs interest? new EID scheme the same exact preknown path to get there - not like a DNS name and how to get there implicit. Against DTN but appeals to space comm, project and mission. IETF probably not a use case - should we tackle the harder problem. SB: second option superior and more dtn like, difference in way you encode destination is why it needs to be in naming and addressing. cEB: agree, resolves into naming and addressing. how does this imply format, structure and restrictions on names. different piece treated differently in binding perspective? SB: is there any topo info in the encoding? such as name of region then you have a global mgmnt tree. as soon as any topo info in the destination you are no longer doing late binding. cEB: if we go this route - that would be required to have late binding EK: does a node know all its availible names? or does it never change names? SB: only has one name EK: dtn:name dtn-region_xyz:name? SB: interesting way to do it JT: make comment evolving cost in probes the optimum tree would take some time - IPN may not be practical SB: agree, late binding within the region cRT: that topic would be routing and slightly out of scope but very relevant RT: we have talked about this concept before - love the approach but regions not to be topo significant but a way to subdivide name space. Region EASA and Region NASA both have a Mars Rover 2. As NASA I can send to mars-rover2.easa as an example. divide naming space, not routing space. flexible for autonomously named regions SB: hierarchial name structure and used node numbers not ascii and assigned in ranges assoicated with organzational entities. some routing system can use that hint to improve the routing then do it. notion of region for routing is separately important RT: lets take it offline SC: Comment; logical shaping to discussion, request: do not paint into corner with an arp function into different ID spaces, logical space and phy spaces, which are are HIP/HIT and HIP/HHIT and HF/ALE; question: do your regions partition or overlap? SB: good question. regions partition the topology and the same time a node a can be a member of multiple regions. take concept as member of multiple regions to extreme and say route interesting optomized ways. think direction to be avoided - regions are orgs in tree; implementation very hard to avoid loops in routing in other than tree you need more info about topology and goes back to global mgmnt of tree we want to avoid - if automatic tree forming by limiting rules adZS: do not have document and do not want to write docuement for this - was a really good discussion. overlapping regions; name collisions? advice please write things down. SB: articulte ideas at this level - if we are interesred in this direction then its time to start on a draft. cRT: I think great starting point with text to get to the pearl SB: agree cRT: collate and put your own ideas out there! be bold! hin - Ed compressed header from IANA RV(v): +1 for Stuart Card's comment on not painting ourselves into a corner. Developing naming & addressing further without having at least a concept of routing is dangerous, IMO ## Naming and Addressing Working Meeting (60 min) - All Attendees ## Open Mic (5 mins) cEB: observation no issue filling in session, interim? EK point; how are EIDs used from routing and sec and custody perspective? push to create strucute for EIDs and how do we exist with multiple names for nodes and EIDs and what is practical cascade into other areas? SB: We should settle on one EID scheme based on numbers RV: lots of downward thumbs cRT: thank you very much! look forward to see you again!