[Sis-dtn] [EXT] RE: SIS-DTN Telecon Notes 20210630

[鈴木 清久]

Hello Tomaso,

Thank you for a polite reply. 

1)I agree with you. I probably had confused and/or missed about discussion point.
2)Thank you for your understanding.

Kiyo,

-----Original Message-----
From: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de> 
Sent: Monday, July 5, 2021 9:59 PM
To: 鈴木　清久 <suzuki.kiyohisa at jaxa.jp>
Cc: sis-dtn at mailman.ccsds.org
Subject: RE: [EXT] RE: SIS-DTN Telecon Notes 20210630

Hello Kiyo,

My answers inline (the colleagues on the distribution list can further elaborate):

-----Original Message-----
From: 鈴木　清久 <suzuki.kiyohisa at jaxa.jp> 


Hello, Tomaso,

Sorry for my response over weekend.

1)
I might confused. Is that in case of space packet as sim protocol (not application protocol) ? Because current SPP has two locations in entire stack.
[de Cola, Tomaso] Indeed the space protocol can operate in two ways, either as application protocol (possibly operating also on top of BP) or as shim layer (below LTP or CFDP, as stated in 133.0-B-2). I guess either way the APID defined on a mission-specific basis can make sure that no ambiguity arises. Then, the secondary header can be used to provide additional info about the transferred content, but I think this is beyond what we are discussing here.

2)
I read ARD 5yrs review material (unfortunately I could not participate), but TCP CL was not listed (only SLE over TCP) in the material.
Even IOAG catalog 2 was not listed about TCP CL (SLE listed). Only DTN in space GB was listed.
Of course, I agreed to proceed spec discussion and use about TCP more, but just it seems to relieve bit mismatching about "something over TCP" between GBs and/or service definition, if there would be mission needs (it's great). If already discussed about this, please ignore.
[de Cola, Tomaso] Yes indeed I was referring to some scenarios presented in the DTN GB, where the case of a full e2e DTN architecture appear. I agree with you that this very specific scenario has to be coordinated with the update of the ARD and related books.


-----Original Message-----
From: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de> 
Sent: Friday, July 2, 2021 7:24 PM
To: 鈴木　清久 <suzuki.kiyohisa at jaxa.jp>
Cc: sis-dtn at mailman.ccsds.org
Subject: RE: [EXT] RE: SIS-DTN Telecon Notes 20210630

Hello Kiyo,

What do you mean exactly for the first point? SPP does not allocate specific APID for upper layer protocols, but missions can do. On the other hand, EPP define specific Proto ID to this end. In any case there should not be ambiguity either way.

As to the second point, in relation to cross support architectures are you referring to what discussed in the recent telco lead by Peter Shames? I don't think however here we risk any CCSDS architecture violation. Can you expand a little bit more?

Best Regards,

Tomaso

-----Original Message-----
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of ?? ??
Sent: Freitag, 2. Juli 2021 02:20
To: sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] [EXT] RE: SIS-DTN Telecon Notes 20210630

Tomaso, Keith,

SPP APID: Yes, it may be optional basis because differentiation may be needed between this one and encap packet.
TCP CL: Consideration may be needed. Differentiation (or proposal of use cases) may be needed between this and SLE. 

Spec itself may be OK including in other topic such as LTP, but I think we need more careful consideration for use cases, requirement and stack violation within CCSDS architecture (in point view of ensuring consistency about SCCS ADD/ARD and Overview of Space Communications Protocols .)

Kiyo

-----Original Message-----
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Dr. Keith L Scott
Sent: Thursday, July 1, 2021 11:25 PM
To: Tomaso.deCola at dlr.de; sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] [EXT] RE: SIS-DTN Telecon Notes 20210630

OK, so we don’t have to worry about an APID for SPP, great.

For CLs, we can certainly include a TCP CL; I’d suggest the one that is standardized in the IETF as part of the BPv7 suite.  It should be pretty easy from a standardization / implementation standpoint.

                                --keith

From: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de>
Date: Thursday, July 1, 2021 at 4:17 PM
To: Dr. Keith L Scott <kscott at mitre.org>, sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: [EXT] RE: SIS-DTN Telecon Notes 20210630 Hi Keith, all,

Just two considerations:


  1.  SPP APID: as mentioned on the chat, the SANA registry for the APID is now counting only one approved APID. In the past there were two more for CFDP and LTP over SPP, but it was agreed in the latest specification of SPP (you can check Annex 2 for SANA considerations) that APID definitions should be mission specific and therefore no specific protocol mapping would be defined in the specification. This is a point we also discussed with Scott last Autumn once the spec was out, just to have some thoughts on how it could work for us. But as said at that point, any mission will be free to select its own APID(s) apparently.
  2.  Concerning CLs for BP, in the past we were also envisaging the case of BP over TCP for the terrestrial links, in case bundles could be forwarded from the ground station to the users by using classical TCP/IP infrastructure. Should this be considered too here, or will we in any case refer to the TCPCL spec from IETF?

My 0.02 cents,

Tomaso

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Dr. Keith L Scott
Sent: Mittwoch, 30. Juni 2021 18:07
To: sis-dtn at mailman.ccsds.org
Subject: [Sis-dtn] SIS-DTN Telecon Notes 20210630


SIS-DTN Telecon



BPsec -- Ed asked SEA-SEC for a quick review of format from the old SBSP book



LTP Orange

? Discussion

? Implementation

? Use cases?



BPv7

Felix Flentge

DTPC

? How to separate the various parts out of that

? Custody signaling in BPv7

? Stuff not covered in BIBE-CT -- want to use CT for multi-hop custody.

? Bundle might take a long time to get to their destination.

? independent custody signaling (based on ACS)

? Interested in a custody transfer mechanism where you don’t need to know/identify the next custodian

? Looking at very high data rate downlink scenarios / less predictable



Beau Blanding -- will be doing the writing, helped by Josh and Lee Pitts.



Maybe keep w/ BIBE-CT for now in CCSDS and augment with some other extension-block-supported mechanism later in CCSDS and/or IETF.



Convergence Layers for v7:

? LTP

? Encapsulation Packets

? Felix: Space packets

Simon Singh

Flow management

? Resource allocation / management in intermediate nodes

? Anybody else interested in flow management?



Extension blocks (previous hop, bundle age)

? Any node should be able to process these blocks

? Block processing flags



Actions:

? Look at the Orange thread

? NASA need for custody transfer?  PACE / Gateway

? Felix: write down thoughts on extension-block based custody transfer support

? Keith: figure out about APID assignment for BP over space packets

? Keith: definitive lists of capabilities for LTP and BP updates

? Understand the ‘traffic pared’ bundle expiration reason code

? What’s the purpose / use case?

? How does a node know that it’s neighbor isn’t just going to delete things?

_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn