Markdown Version | Session Recording

Session Date/Time: 22 Mar 2022 13:30

dtn

Summary

The DTN Working Group at IETF 113 saw significant administrative progress with the successful rechartering and publication of four new RFCs (Bundle Protocol v7, TCP Convergence Layer, Bundle Protocol Security, and Default Security Context for BPSEC). Vint Cerf delivered a keynote on the vision and activities of the Interplanetary Networking Special Interest Group (IPN SIG), highlighting DTN's critical role in space communications due to unique challenges that render traditional TCP/IP unsuitable.

Technical presentations covered new charter items and ongoing work, including Bundle-in-Bundle Encapsulation (VIBE) and Quality of Service for BPv7 by Scott Burleigh, and updates on the Administrative Record Type Registry, COSE Context for BPSEC, and Bundle Version Detection by Brian Sipos. Emery Jones presented updates to the Delay Tolerant Network Management Architecture (DTNMA) and a related naming proposal, while Sarah Cerami provided a valuable live demonstration of the Asynchronous Network Management System (ANMS) implementation. The session concluded with discussions on the external use of DTN Endpoint IDs and the potential need to refresh RFC 4838. Due to a packed agenda, the chairs noted the need for an interim meeting and requested two sessions for the next IETF to accommodate the growing volume of work.

Key Discussion Points

• Administrative & Charter Update:

  • Chairs opened the session, reminding attendees of the IETF Note Well and logistics for the hybrid meeting.
  • The DTN Working Group's rechartering was successfully completed and approved by the IAB.
  • Four new RFCs have been published: RFC 9171 (Bundle Protocol v7), RFC 9172 (TCP Convergence Layer v4), RFC 9173 (Bundle Protocol Security Specification), and RFC 9174 (BPSEC Default Security Contexts). This marks a significant milestone, "bookending" previous work and enabling the new charter items.

• Vint Cerf - IPN SIG & DTN Vision:

  • Vint Cerf, representing the Interplanetary Networking Special Interest Group (IPN SIG), announced its transition to an Interplanetary Networking Chapter of the Internet Society.
  • The IPN SIG boasts over 800 members and has several working groups: Strategy (100-year network vision), Projects (implementation and testing), Architecture & Governance (rules, jurisdiction for space operations), Library, Outreach, and Business (commercialization of space).
  • Intentions: Implement and test a terrestrial/Low Earth Orbit (LEO) DTN-based network to ensure reliability, robustness, and scalability before deep-space deployment. Focus on network management, security, configuration, and supporting useful applications (messaging, video, AI/ML). Emphasize multi-party interoperability and interworking between different BP implementations.
  • Collaborations: Active engagement with NASA DTN Working Group (ISS, LunarNet), ESA (Moonlight), Utica College, and El Modio.
  • Governance in Space: Highlighted complex questions around jurisdiction, private property, historical sites, and dispute resolution in space, referencing the Artemis Accords.
  • Public Engagement: Proposed a "SETI@home"-style application for public participation in terrestrial DTN testing.
  • Why DTN?: Explained that traditional TCP/IP is unsuitable for interplanetary distances due to extreme variable delays (e.g., 40-minute round-trip time to Mars) and frequent disruptions from orbital dynamics and planetary rotation. DTN's store-and-forward nature is critical to overcome these limitations.
  • Expectations from DTN WG: Continue refining protocols (including support for real-time streaming in low-latency scenarios while maintaining delay-tolerant functionality), greater focus on delay-tolerant applications, exercise and standardize naming/addressing structures (parallels with IANA and CCSDS's SENA), and consider commercialization aspects in mixed government/commercial environments.

• Scott Burleigh - Bundle-in-Bundle Encapsulation (VIBE):

  • History: VIBE originated in 2009, re-envisioned in 2013 as a Convergence Layer Protocol (CLP) rather than an application.
  • Motivation: Address limitations in BPv6 custody transfer (inaccurate RTT estimation for retransmission, fragmentation defeating custody), and enable cross-domain security (e.g., defense against traffic analysis) and reliable CL transmission over asymmetric paths.
  • Design: VIBE uses BP as a CLP. An encapsulating bundle's payload includes a transmission ID, expected ACK time, and the encapsulated bundle. Acknowledgements are aggregated in an administrative record with a disposition code and transmission ID sequences. Retransmission occurs if ACK is not received by the expected time.
  • Open Issue: Need a mechanism for sender to express expected ACK time as an interval if participating nodes lack accurate clocks.
  • Applications: Provides custodial reliability (now removed from BPv7), cross-domain security, defense against traffic analysis, transient Quality of Service (QoS) marking, critical forwarding, source path routing, and certified multicast.
  • Discussion: Question arose about whether custody transfer (CT) should be integrated with VIBE or a separate extension. Scott argued for VIBE as a CLP for reliability, but acknowledged flexibility.

• Scott Burleigh - Quality of Service (QoS):

  • Context: QoS, like custody transfer, was removed from BPv7. The question is how a Bundle Protocol Agent (BPA) should prioritize bundles for forwarding.
  • Internet QoS Review: Briefly discussed Integrated Services (InServ - poor scalability, not delay-tolerant) and Differentiated Services (DiffServ - code points, per-hop behavior, no hard guarantees, business-level non-conformance).
  • BPv6 QoS Review: Class of Service (Bulk, Standard, Expedited) was largely an "honor system" with limited utility. Extended Class of Service (ordinal tag, service selection flags, numeric label) also had issues.
  • Challenges: Head-of-line blocking is a significant problem in DTN due to potentially large bundle sizes, inhibiting effective QoS.
  • Proposal: Introduce a bundle processing flag for QoS handling, applicable only to bundles less than 64KB (to mitigate head-of-line blocking). Bundles with the QoS flag set to '1' would be prioritized over '0'. A QoS Extension Block could define service requests (flags, eCoS, numeric data label), with IANA managing a registry of labels. Per-hop behaviors would be node administration responsibility, without guarantees (similar to DiffServ).
  • Discussion: Zahed questioned the suitability of mimicking DiffServ, citing its deployment issues. Scott clarified DiffServ as an example of desired behavior, not a direct model to implement.

• Brian Sipos - Administrative Record Type Registry:

  • Purpose: Update the IANA registry for administrative record types to include BPv7, aligning with existing registries for bundle/block processing flags and block types.
  • Key Update: Add the CCSDS Aggregate Custody Signal (code point 4), which was previously standardized but not explicitly registered in IANA.
  • Details: Confirmed pre-existing codepoints (1, 2, 4) and proposed reserving high-value codepoints for 32-bit values. The document primarily serves as bookkeeping.
  • Request: Working group adoption to formalize this registry update, which is necessary for future allocations (e.g., for VIBE, ACME node ID validation).

• Brian Sipos - COSE Context for BPSEC:

  • Motivation: BPSEC's default security contexts are symmetric-key focused and lack features like key identifiers needed for PKI environments. For internet-facing DTN nodes and interagency interoperability, PKI is standard.
  • COSE Integration: CBOR Object Signing and Encryption (COSE) is well-suited for one-directional security and fits the existing BPSEC framework. It offers extensibility for PKI and future post-quantum cryptography algorithms.
  • Design: A single COSE context for both Bundle Integrity Block (BIB) and Bundle Confidentiality Block (BCB) with type identifiers differentiating uses. COSE allows embedding PKI information (e.g., X.509 certificates).
  • Interoperability Profile: The document defines how to embed COSE messages in BPSEC blocks and specifies an interoperability profile covering symmetric key, key wrap, and asymmetric key (PKI) behaviors, with modern PKI algorithms.
  • Benefit: Enables "off-the-shelf" use in existing PKI X.509 environments, leveraging established certificate authorities and infrastructure.
  • Updates Needed: Alignment with RFC 9173 encoding, further definition of processing requirements for PKI environments, and minimum COSE header contents (learning from S/MIME).
  • Request: Working group adoption, citing interest from NASA and CCSDS for interagency PKI.

• Brian Sipos - Bundle Version Detection:

  • Problem: In environments processing both BPv6 and BPv7 (e.g., shared convergence layers), there's no defined way to unambiguously distinguish between the two bundle versions from a byte string. Existing tools often make brittle assumptions about BPv7 encoding offsets.
  • Goal: Provide fine-grained detection logic without requiring full bundle processing, preventing interoperability issues.
  • Proposed Mechanism:
    • Logical Approach: Exploit the lack of collision between BPv6 and BPv7 encodings for unambiguous detection. A general-purpose CBOR stream decoding sequence can identify the version.
    • Optimized Algorithms: For constrained or fixed-encoding environments, more optimized methods (e.g., bit operations mimicking CBOR decoding, byte string pattern matching) could be documented (with caveats about breaking on valid but non-deterministic bundles).
  • Request: Gauge interest for an informational document to provide best practices for implementers.
  • Discussion: Joshua Deaton (Marshall Space Flight Center) affirmed the need, noting their ISS implementation uses a v6-then-v7 check, and saw value in documenting this.

• Emery Jones - DTN Management Architecture (DTNMA):

  • Renaming: Document renamed from "Asynchronous Management Architecture" to "Delay Tolerant Network Management Architecture" for clarity, emphasizing its focus on challenged networks.
  • Purpose: Define the motivation, design principles, and concepts for an Operations, Administration, and Maintenance (OAM) architecture for DTNs.
  • Services: Specifies necessary services (e.g., authorized administration, accounting, error control) and desirable solution properties (asynchronous, dynamic, model-driven, hierarchically organized information).
  • Key Clarifications: Defined the need for AAA (Authorization, Authentication, Accounting), stressed the "asynchronous" nature (down to the transport layer), and emphasized a model-driven approach for autonomy and compression.
  • Roles: Clarified roles and responsibilities of Agents (managed elements) and Managers (controlling/reporting nodes).
  • Visualizations: Updated diagrams to illustrate asynchronous reporting, combined reports, and multiplexed management scenarios.
  • Discussion: Ed Birrane emphasized the "asynchronous" nature must extend to the transport layer. Joshua Deaton inquired about handling long-delayed or burst reports, suggesting policy-driven report lifetime/deletion based on storage. Rick Taylor noted that as an architectural document, it could proceed without accompanying documents.
  • Request: Working group to review the updated document for completeness and correctness to facilitate its progression.

• Emery Jones - Naming Resources in Application Models:

  • New Proposal: Emery introduced a new individual document proposing a method for naming resources within application models defined for DTNMA.
  • Request: Seek working group interest.
  • Decision: Chairs deemed this within charter scope and encouraged Emery to publish it as an individual draft, garner interest on the mailing list, and prepare for a deeper dive at a future meeting.

• Sarah Cerami - Asynchronous Network Management System (ANMS) Implementation:

  • Purpose: ANMS aims to operate DTN protocols alongside terrestrial networks, facilitate AMP adoption, and serve as a baseline for the AMP specification.
  • Architecture: Designed to connect to both terrestrial and space networks, provide default visualizations for mission operators, and enable command and control. Services include data management, health/status monitoring, and agent command/control via AMP. It is containerized and modular, allowing custom plugins.
  • Implementation Update: The first "spiral" of ANMS is complete and slated for open-source release within approximately one month, pending internal review.
  • Demonstration (via screenshots):
    • Welcome Screen: Showed different tabs for future features (Network, Alerts, System Management) and current ones (Monitor, Agents, Messaging).
    • Monitor Tab: Displayed Grafana plugins showing live data from BP agent reports (e.g., number of bundles in custody, message rate), with raw reports viewable.
    • Agents Tab: Demonstrated ability to manage agents, send commands, and automatically construct time-based rules for periodic reports (e.g., ltp-agent-endpoint-report, bp-agent-full-report). Also allows sending raw CBOR commands.
    • Messaging Tab: Provides tools to construct and parse commands, converting strings to CBOR, JSON, and UML diagrams.
  • Community Engagement: Sarah expressed excitement for the open-source release to gather feedback from the community.

• Rick Taylor - Endpoint IDs (EIDs):

  • Review: EIDs are a pair of schema and content (e.g., ipn and dtn schemas defined in RFC 9171), with considerations for multiplicity (unicast, multicast).
  • Question 1: External Use of DTN Schema: Given dtn schema is registered in URI schemes registry, how can tools like curl use it (e.g., curl dtn://dtn.org/service/demuxpart -F file1.txt)?
    • Proposal: Parse URI into a "name" and "demux" part. Resolve the "name" component via DNS to an IP address. Establish a TCPCLv4 session to that IP address to transmit the bundle. This allows public internet infrastructure to be used for initial bundle delivery.
    • Clarifications: This doesn't preclude non-internet BPAs, intermediate proxies/gateways, or further DTN routing (e.g., IPN addresses in the demux part) beyond the DNS-resolved endpoint.
  • Question 2: IPN Schema Usage: Proposed that the ipn schema, being restricted (e.g., unicast only), is best used internally within autonomous DTN regions (like a "landscaped address").
  • Question 3: Other EID Schemas: Confirmed that groups can define their own EID schemas by documenting them and requesting a new Bundle Protocol URI type scheme number.
  • Discussion: Due to time constraints, Rick suggested taking this topic to the mailing list and potentially an interim meeting.

• Ed Birrane - Refresh RFC 4838:

  • Question: Given the significant experience gained with BPv6, the evolution to BPv7, and ongoing work in network management, security, QoS, and custody transfer, is it time to refresh RFC 4838 (Delay-Tolerant Network Architecture), published in 2007?
  • Decision: This question will be taken to the mailing list for wider discussion.

Decisions and Action Items

• Working Group Adoption Requests: The chairs will initiate working group adoption requests for:
  • Brian Sipos's "Administrative Record Type Registry" document.
  • Brian Sipos's "COSE Context for BPSEC" document.
  • Emery Jones's "DTN Management Architecture" document.
• Individual Draft Publication: Emery Jones is encouraged to publish his "Naming Resources in Application Models" as an individual draft and seek interest on the mailing list.
• Mailing List Discussions:
  • Rick Taylor will initiate discussion on Endpoint IDs (specifically the external use of DTN EIDs and the proposed DNS-based resolution) on the mailing list.
  • Ed Birrane will initiate discussion on the mailing list regarding whether to refresh RFC 4838.
• Future Meeting Planning: The chairs will plan an interim meeting to delve deeper into various topics and will request two sessions for IETF 114 to accommodate the significant amount of work.

Next Steps

• All working group participants are encouraged to review the documents presented (Administrative Record Type Registry, COSE Context for BPSEC, DTN Management Architecture) and engage in discussions on the mailing list for their potential adoption.
• Engage in the mailing list discussions regarding the external use of DTN Endpoint IDs and the proposed refresh of RFC 4838.
• Look out for announcements regarding an interim meeting to continue technical discussions.
• Prepare for IETF 114, which is expected to feature two DTN Working Group sessions.