IETF 116 TVR working group meeting # Agenda {#agenda} Monday 2023-03-27 06:30 - 08:00 (UTC) Co-chairs: Tony Li (cTL, TL), Ed Birrane (cEB, EB) Secretary: Adam Wiethuechter (sAW, AW) # Intro (10 min) {#intro-10-min} ## Administrivia: (Chairs, 5 minutes) {#administrivia-chairs-5-minutes} Bad joke by cEB to start. (great start, fantastic in fact) Notewell check. You are being recorded and shall be posted. Please sign in using Meetecho. If you want to be in queue, even in room, please join the queue. Please keep audio and video off unless presenting or asking question. Please wear a mask if in room unless speaking. Agenda bash. Will start with schedule information and why/how use it. End will be lining up document writing. ## Charter and Scoping: (Chairs cTL, 5 minutes) {#charter-and-scoping-chairs-ctl-5-minutes} White on white for slides...what a concept. (another bad joke, 2/2 is this a trend?) Ground rules - play nice. Focus on goals Goals * making all docs on slide Non-goals * not every use case * do not care about trivia * transport protocols (rtg protocol is not a dump trucks) * Not modifying routing protocols * Up to other WGs * Could take requests to them * Recommend behavior Write a draft! Give presentation! Discuss on list! cEB: any agenda bash? nope lets move! # Presentations (65 min) {#presentations-65-min} ## TVR Use Cases Review (Ed Birrane, 5 min) {#tvr-use-cases-review-ed-birrane-5-min} https://datatracker.ietf.org/doc/draft-birrane-tvr-use-cases/ When did BoF wanted a few use-cases of what trying to accomplish and their benefits. Use-cases can be used as rubric for future work. Case 1: local resource preservation * sense of schedule awareness leads to local resource preservation Case 2: adapting to external conditions * total cost of ownership can be limited when knowing high/low cost uses Case 3: mobile devices * predicted mobility * distance, antennuation * planned topology changes Poll: Should these use cases be in a info rfc? * 42/1/43 Marc Blanchet (MB): i like use-case info docs if they go clearly into requirements cEB: fair and noted. still would go through wglc and make sure it work. Volunteers? multiple authors are good. ## The AIXM temporality model and TVR (Emery Annis, 10 min) {#the-aixm-temporality-model-and-tvr-emery-annis-10-min} https://aixm.aero/sites/aixm.aero/files/imce/AIXM51/aixm\_temporality\_1.0.pdf On behalf of Brian Sipos. Background on aero temporality model. existing time variant info model. Temportality model * need to convey time based, schedule information * common language to understand and bounds * absolute and periodic time * completely abstract of producers and users of info * state of system, feature or propery * not why state changed * different industry with a lot of work and lessons learned AIXM origin * link on slide * Aero Info Exchange Model (AXIM) * need of conveying time variant info * wrote a separate piece * notice to air mission (notam) * concept been used a planning tool for cruise liners connecting to geo sats Model structure * feature and its properties * runway * time can be used * state * planned Terms * see slide * model supports both permanant definition over time and temporary Example * baseline with start and end of life * clear state changes * temporary values * update baseline with perm deltas * describes conflict resolution for model Repetition * periodic behavior in schedule Parameter interpolation * parameter values discreet for axim * express as function Horizontal concept * planning horizon * horizons can be very short * not part of datamodel, but maybe use case For TVR * express parameters over time concept * gives them ability how to consume information Conclusion * go read axim model * check concepts * if datamodel for tvr see if we can borrow concepts and language Jorge Amodio (JA): model free? EA: published and free to use it Toerless Ecket (TE): mentioned something as a function rather than table? worse case example in axim? very interesting for tvr. EA: is granularity so small that there are 1000s of states over a short period of time. details would need to be worked out - how to negotiate, etc. They did not do that they left discret. TE: following antennas? cEB: lets move, Q Misell: does axim a mechanism for confidence of data in model EA: language and examples in UML for how to convey. It could be added. shouldnt be part of info model - so users can decide them. ## Time Variant Scenarios in the TIDAL network (Li Zhang, 5 min) {#time-variant-scenarios-in-the-tidal-network-li-zhang-5-min} https://datatracker.ietf.org/doc/draft-zzl-tvr-use-case-tidal-network/ Tidel effect of traffic on networks * slide showing the behavior of traffic Assumptions * traffic is predictable * algorithm to disable nodes for scale of traffic * data model with time-based info * collection and advertisement (sharing?) of data model * routing is based on data model Example / problems to solve * how do we describe time info into a data model? * new routing algs? avoid packet loss during changes ## A Brief History of Contact Graph Routing (Scott Burleigh, 15 min) {#a-brief-history-of-contact-graph-routing-scott-burleigh-15-min} No Draft Deep space * wireless signal * long distances (with physical limitations) * low data rate * omni-directional transmit * high latency * no negotiation * low capacity * small ground station supporting many spacecraft * they all move (rotate on axis or orbits) * body fixed antenna * signal interruption is routine * AW: no end to end connectivity! * overall * limited * async * expensive * precious * ground pointing to space is "tracking" * ethernet cable you plug and unplug * command of ground station and spacecraft in tandem * based on schedule * "pass plan" - file Except of Ulysses pass plan * routine for spacecraft comm operation Mars relay * more complex * relayed instead of direct comm back to earth * rover to orbitter (as relay) to earth Contact plans * generalization of "tracking passes" * representation of time-vary topology * schedule distributed * managed and authoritative * managed knowledge of physical topology of network * example graph and table * overlay of table to graph * looks like routing table - but NOT * map of time varying network topology * no routes * learns routes between nodes using contact plan * similiar to BGP Contact Graph Routing * way to use info from plan to compute routes * directed graph Example of CGR CGR routing table * list of complete routes * not next hops * max utilization is very important * shortest usable route is best * if none, recompute to find and if not found discard * load balancing with recomputation for utilization Chronology * 2007 with ION * DINET experiment * on ISS since 2016 * internation standard in CCSDS * alternative method is proposed cEB: can we present such thing at another meeting? SB: yes! cEB: thank you for the history. no queue questions. ## Forwarding in the Context of TVR (Marc Blanchet, 10 min) {#forwarding-in-the-context-of-tvr-marc-blanchet-10-min} https://datatracker.ietf.org/doc/draft-blanchet-tvr-forwarding/ Rationale * space comms * BP in Swift for Apple and linux * policy forwarding bundles * BP is store and forward * what do you do with bundles for forwarding or dropping? * generalized from BP to IP * packet and bundle interchangable in these presentations Forward * stored and saved with timestamp * when route states changed things are sent that can be Policies Needed * packet memory full already * drop? * remove old? * what is sent first? * expired packet * storing may be demanding * preference what is stored * when dropped error to source * could be costly to do * what if too old and error irrelvant Drop Policies * list, enum * drop oldest * drop last from these sources * drop last for these destinations * drop last based on field of packet/bundle * error reply? (never or if not too old) Forward Policy * link back * which do i forward first? * first from these sources * first to these destinations * first based on field of packet/bundle Comments * Why IP? use-cases with little delay but still need time-variance * should do a Yang model * Weighted concurrent policies * Default policy? * define header fields that would be instantiated in policies WG adoption and comments Rick Taylor (RT): if not in scope here can be in dtn. Very relevant in BP. Open to suggestion from floor if TVR handles this. cEB: please take to mailing list! Erik Kline: sceptical useful for IP, will go to list Ron Velt: forsee support opportunistic routing? lots of work out there already. PROFIT. cEB: that is not in scope for TVR. we can take to list. RV: strange but okay. ## A Contact Plan Data Model (Marc Blanchet, 10 min) {#a-contact-plan-data-model-marc-blanchet-10-min} https://datatracker.ietf.org/doc/draft-blanchet-tvr-contactplan/ Rationale: * everyone has different model...ugh. * document to do this! Example in JSON * contacts have uuid Comments * Yang (Dean and Tony) - Dean offers to help * unnumbered links: agreed * top level id and for each index or only id in records or both. to be discussed * empty list of contacts: ok * list of dests * for dtn-bp, no prefix like ip/cidr * time start/stop: may state one is mandatory, or even none to support incomplete contact plans * bandwidth/latency: bandwidth used in BP. might remove latency as layer violation. * convergence layer syntax: requested and agreed. * No need for format (Scott Burleigh), ok for data model useful. format is up to implementor * probability of contact: to be looked at. used in some BP implementations Thanks for early review, WG adoption and comments. RT: implemented similiar in manet, split metrics away from links (common). Have dynamic sets of metrics. Some metric may show up so flex is good. Support adoption, needs work but in good direction. ## Using ALTO for Exposing Time-Variant Routing Information (Luis Contreras, 10 min) {#using-alto-for-exposing-time-variant-routing-information-luis-contreras-10-min} https://datatracker.ietf.org/doc/draft-contreras-tvr-alto-exposure/ Rationale * predictable chnages fo TVR * comes from higher level systems (OSS, network controller) * can anticipate impact * algorithms with experimental observations Calendared topologies * ALTO \[RFC8896\] * cost calender * attributes to describe scope ALTO for TVR * enable TVR info to applications * assess to solve * define how ALTO can participate to routing process * data model(s) leveraged for ALTO Relevance * Attribute parameters used as input for data models * cost calender use case * apps use the data in the calender * collect feedback # Wrap-Up (Chairs, 15 min) {#wrap-up-chairs-15-min} Goal behind discussion and presentation; cases and existing work dealing with schedules Find commonalities. Turn into drafts. Have information use-case document. Need people to start working on these things. Go to mailing list, who is interested in what pieces and consolidate around ideas. Start to collab so there is drafts for next session. ## Call for Authors: 5 min {#call-for-authors-5-min} ## Walk-On Topics: 5 min {#walk-on-topics-5-min} ## Final Comments: 5 min {#final-comments-5-min} # Open Mic {#open-mic} Dean: info model is somewhat been defined based on Marc document and other presentations. Lots of options requirements. Well defined for space; more terrestial use-cases. cEB: agreed Stu Card: may have missed; probability!!! predictions and have uncertaintity. Where is this? We have explicit representation of confidence/probability? cEB: agreed and noted to discuss on list Lou Berger: dont understand all link attributes for schedule. opaque attributes. use-case, requirements? We defintely need cEB: heard and agreed. multiple radios, how to distinguish? cEB: almost 100 people, clearly something with lots of interest. Active on mailing list and coordinate on drafts! We will see you all in a couple months. Understand reqs and info models for time variant information. eEB: closes with another terrible joke. it is a trend and as it should be.