DTN WG Minutes IETF 94 November 3, 2015 ============================== Administrativia ------------------------------ - Bluesheets distributed. - Notewell noted. Agenda Bashing ------------------------------ * No changes to the agenda Summary ------------------------------ 1. The DTNWG session will generate consensus within the room and take proposals to the mailing list for final disposition to allow non-DTNWG attendees to participate. 2. All open BP issues provided with a consensus recommendation - BP special be edited to remove possibilities for alternative implementations which will shorten the book sufficiently to not require two specifications. - The “Block was Forwarded Without Being Processed” flag will be removed from the BP specification. An extension block for this information will be proposed. - The 2 bit COS bits will be removed from the Primary Block. An extension block will be developed to capture class of service. - High-resolution timers will be made optional in the status message. - The BPA will provide the CLA with a bundle at a time of the BPA’s choosing. - The inventory block will be taken to the mailing list for discussion. - Multiple instances of an extension block type can be present in a bundle. These instances will be differentiated by a to-be-determined numbering scheme. - No change necessary for DTN support for ICN. Any specific issues should be adopted by the DTNRG. 3. SBSP will be renamed BPSEC and considered for DTNWG adoption. BPSEC will remove the BAB block. 4. A telecom meeting will be set up in January 2016. Questions (Q), Answers (A), and Comments (C): Presentation 1: draft-dtnwg-bp-00 Overview (Scott Burleigh) ------------------------------ Topic - Should policy and spec parts of BP be separated into 2 documents Scott Burleigh: There are two types of information in the BP specification. Should the specification be broken into two documents? C: Kevin Fall: Several portions of BP spec talk about potential implementations This text can be safely removed. At which point there is likely no need for a second document. C: Rick Taylor: In favor of splitting documents only if have enough for each. Topic - Behavior of the “Block Forwarded Without Being Processed” bit Should the “Block Forwarded Without Being Processed” bit be sticky, or should a node clear the bit if the node processes the extension block, even if a prior node did not process the block and set the bit. C: Rick Taylor: Understand semantic question of whether bit refers to the most recent node or any previous node. This is too much information to represent in 1 bit of information. Vote that for this bit, you set or clear it based on current node. C: Kevin Fall: Original intention was to understand if an option passed through the network. Argument for making the bit sticky. Q: Scott Burleigh: Can we remove this bit altogether? C: John Dowdell: Simplify it by removing it, or machete more complex by adding ID of the node that processed the block. C: Kevin Fall: Some users may want initial indication of what happened. Others may want more information for debugging. Full information not wanted by every user. Advocate removal. C: Rick Taylor: Issue with removing bit and moving functionality to an extension block is the impact on systems that do not understand the new extension block, but need to understand if a block was forwarded without being processed. C: Brian Habermas: If no one is currently using this flag, then the proposal to remove the flag makes sense. C: Scott Burleigh: Let’s remove the bit from the specification and address potential other cases later when we discuss adding an extension block for this information. Topic - ECOS features and the ECOS “Critical Flag” The critical flag in ECOS currently indicates that a bundle should be sent down all known possible routes. Is “critical” the correct name for this feature? C: Rick Taylor: Drop these flags. This is a big topic to cram into 4 bits and should be an extension block instead. C: Ronald In ’T Velt: Do not lose this capability. We have projects that are using this. We could use an extension block, as long as the extended classes of service remain in some way. Q: Scott Burleigh: Can we remove the current 2-bit class of service (COS), add an extension block for this, and stand up an ad-hoc working group to get this specified correctly? C: Kevin Fall: Agree to move this to extension block. Without knowledge, this capability look like flooding. Restricting setting this to only times when you have route knowledge may lead to troubling semantics. C: John Dowdell: Additionally, if the ECOS is an extension block, it prevents the primary block from changing as it goes through the network. Q: Marc Blanchet: What was the original driver for ECOS? Do we need this in the base protocol? A: Scott Burleigh: All use cases for ECOS were space-related. C: Scott Burleigh: Some extension blocks can be mandated in the BP spec as items removed from the primary block to keep the primary block immutable while keeping functionality. Examples being the previous hop extension block and the current custodian extension block. C: Jeremy Pierce-Mayer: Proposal is to remove COS bits from the primary block and use an extension block to capture class of service? We require ECOS for streaming. C: Scott Burleigh: Proposal is that ECOS is valuable but does not need to be in the primary block. Remove the current COS 2-bit fields in the primary block. Remove the ECOS block (it is not “extending” anything anymore). Create a COS extension block to capture this information. Q: Scott Burleigh: Does this require a re-charter? A: Marc Blanchet: No Charter is for a complete specification, not for a certain number of documents. Side Topic - Primary Block Immutability Q: Ronald In ’T Velt: Some effort to make new extension blocks to keep primary block immutable. What is the value of an immutable primary block? A: Scott Burleigh: Destination can understand what source node had specified. A: Ed Birrane: Allows an integrity mechanism on the primary block. Integrity is currently available for all blocks but primary. A: Rick Taylor: IPv6 header options have caused grief and taught us that having 1 part of the header immutable end-to-end is valuable. Side Topic - Mutability of Extension Blocks Q: Ronald In ’T Velt: Is a mutable primary block valuable if what we have taken out of the primary block rests instead in a mutable extension block? A: Ed Birrane: It prevents having to have a special canonicalization for the primary block. C: Scott Burleigh: There is a perception that extension blocks are second-class citizens. They are not. They are just as important as payload and primary blocks. C: Kevin Fall: Not every bundle has to have them though. Trying to define mutable versus immutable opens many more questions. C: Scott Burleigh: If a feature is not mandatory, it should not be in the primary block. Topic - Time in DTN Status Reports High-resolution (nanosecond) times increase size of status reports. Can we adjust this? Originally tried to remove this but dtnperf (and perhaps others) require this. Can we make high-resolution time optional? Q: Rick Taylor: This is part of network monitoring. Can we push this into some kind of instrumentation report? A: Scott Burleigh: Status reports are instrumentation. C: : I work with management protocols for DTN. High resolution time can be moved to an optional status block without much difficulty for my implementation. C: Rick Taylor: This may also help reduce number of required high-resolution timers. C: Scott Burleigh: High precision timers will be made optional with some status bit to indicate if they are included. Topic - Who controls bundle forward time? Does the BPA or the CLA determine when, exactly, a bundle is forwarded? Proposal to push as much as possible to the CLA. C: Kevin Fall: BPA should have most control. Consider environments where timing is tightly controlled with scheduled connectivity. The BPA has this information and must make these decisions. C: Jorge Ott: Agree with Kevin, but both must participate in the decision. CLA must deal with queue and MAC issues and interleaving decisions. C: Marc Blanchet: Agree with Jorge. Also, it is appropriate for BP specification to say that the BPA decides the time, understanding that it then goes to the CLA. C: Rick Taylor: Agree. Decisions made in both places. BPA decides when to place the bundle in the queue. CLA decides how to best send it. C: Kevin Fall: BP could give requested transmission moment to the CLA, and the CLA should report back on when it thought the bundle was sent. C: Rafael de Amorim Silva: Forwarding packets must be done by the BPA since on failure, the BPA has the timing to kick off a retransmission. Q: Ed Birrane: Does the BPA need to provide the CLA with a time and an error margin after which the CLA should not transmit? A: Rick Taylor: No. In our deployment we pool CLAs. A: Scott Burleigh: We can beed up the language on how the BPA presents the bundle to the CLA. But this seems like an engineering issue. C: Kevin Fall: The wording could simply be “the job of the BPA is to specify what CLA is used and when they are used.” Topic - Inventory What is the nature of the inventory and do we need one? Elwyn Davies requested an Inventory capability. Q: Rick Taylor: Is this a question of security? A: Ed Birrane: Not entirely. Do we need to understand if an extension block was dropped along the way. Q: Rick Taylor: Does this then become a network management issue? C: Scott Burleigh: Recommend deferring this issue in Elwyn’s absence. C: John Dowdell: In favor of making this optional. Can see the value in this, but also this inventory can change as it goes through the network. C: Scott Burleigh: As written this is immutable and in the primary block. C: Ed Birrane: Two different inventories: 1 is the set of extension blocks at the time of bundle creation. Second is a “table of contents” which lists current set of blocks in a bundle when received by a waypoint or by a destination. We should not confuse the two. C: Scott Burleigh: We will table this for now as we lack requirements. C: Rick Taylor: Please take this to the mailing list. Topic - Block Multiplicity Can there be multiple instances of a block type in a bundle? C: Rick Taylor: Yes. It seems simpler than taking apart the inside of a block and having to shuffle things around. C: Jorge Ott: Agree, as it is easier to deal with the outer layer and not tamper with protection. Topic - DTN support for ICN. C: Kevin Fall: This is a DTNRG issue. C: Jorge Ott: This should be handled in the DTNRG. Some question on whether origin matters in these cases. C: Scott Burleigh: Resolution should be that language in the BP specification defines bundle transmission and forwarding in a way that is consistent with how we think DTN for ICN would work. No change necessary for the BP specification. Recommend DTNRG investigate using DTN for ICN. Topic - SBSP Naming Q: Ed Birrane: Can we rename SBSP back to BSP? A: Rick Taylor: Naming collision would be confusing. Can we name this BPSec instead? Topic - Bundle Authentication Block (BAB) Do we need authentication at the bundle layer if there already exists authentication at the link layer? C: Rick Taylor: This is helpful because I pool CLAs. Q: Kevin Fall: Can you integrity protect the previous hop notification block as a way to get hoppy-hop bundle authentication? C: Ed Birrane: Remove BAB from BPSec and add bundle-hop-by-bundle-hop authentication strategies to a best-practices security document. Topic - Single Security Destination Can we keep a single security destination for all security blocks? Significant discussion with Kevin Fall on various use cases surrounding this. Agree to take this to meeting and mailing list. Topic - Security as applied to “fragments” Is there issue with policy to not apply security to fragments (where fragment means a bundle with a payload representing a portion of some applications original payload). Significant discussion with Kevin Fall around whether tunneling was the appropriate mechanism to prevent applying security to a bundle “fragment”. Agree to take this to meeting and mailing list. Topic - Adoption of BPSec by DTNWG Can this specification be adopted by the DTNWG? Q: Marc Blanchet: How many people have read the spec C: Marc Blanchet: Chairs will consider and make a determination. Wrap Up Activities ------------------------------ Topic - Interim Meetings An interim meeting will occur in January 2016.