<p style="font-family:'굴림'; font-size:10pt;line-height:1.5;">Hi, Brian S.</p><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;"><br></p><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;"><span style="font-size: 13.3333px;">Yes, either way has benefits, and there are no technical issues. Absolutely, there is no need to argue about which one is more correct.</span></p><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;"><span style="font-size: 13.3333px;"><br></span></p><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;"><span style="font-size: 13.3333px;">Interfacing to another neighbor node through LTPCL over UDP is quite straightforward since it only needs to transmit all the LTP segmentation data to *113 UDP port (1113, 2113, 3113, and so on, according to the LTP node number).</span></p><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;"><span style="font-size: 13.3333px;"><br></span></p><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;"><span style="font-size: 13.3333px;">Of course, LTPCL over UDP can be used with multiplexing. It is technically fine. However, it does affect the configuration parameters' effort, so every node must know the contact information for how the opposite side allocates the reception port in the range of 1 to 65535.</span></p><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;"><span style="font-size: 13.3333px;"><br></span></p><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;"><span style="font-size: 13.3333px;">I think TCPCL has the same issue. Do we want to allocate a port number for this, e.g., xxx019 for dedicated use? Or do we want to reserve preferred port numbers from agencies, such as 1 to 1000 for NASA, 1000 to 2000 for ESA, 2000 to 3000 for KARI, and so on?</span></p><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;"><br></p><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;">Cheol</p><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;"></p><div style="margin-top:30px;margin-left:0.8em;font-size:12px;font-family:돋움,arial;color:#0066CC;font-weight: bold;">--------- 원본 메일 ---------</div><blockquote style="font-size:12px;border-left-style:solid;border-left-width:2px;margin-bottom:0pt;margin-left:0.8em;margin-right:0pt;margin-top:0pt;padding-left:1em;"><div style="font-family:arial,돋움;line-height:1.5"><b>보낸사람</b> : "Sipos, Brian J." <Brian.Sipos@jhuapl.edu><br><b>받는사람</b> : "구철회" <chkoo@kari.re.kr>, "Gao, Jay L (JPL-332C)[JPL Empl" <jay.l.gao@jpl.nasa.gov>, Felix Flentge <Felix.Flentge@esa.int>, "sburleig.sb@gmail.com" <sburleig.sb@gmail.com>, "Torgerson, J. Leigh (US 332C)" <jordan.l.torgerson@jpl.nasa.gov>, Keith Scott <keithlscott@gmail.com>, "Wilmot, Jonathan J. (GSFC-580." <jonathan.j.wilmot@nasa.gov>, Carlo Caini <carlo.caini@unibo.it><br><b>받은날짜</b> : 2023-09-07 (목) 02:51:05<br><b>제목</b> : RE: Is there a standardized way to implement/configure TCP convergence layer for Bundle transaction?<br><!-- original content --><div style="margin-top:5px;"><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><div class="WordSection1"><p class="MsoNormal" style="word-break:normal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Cheol,<o:p></o:p></span></p><p class="MsoNormal" style="word-break:normal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">While the TCPCL allows many possible strategies, as you point out, I’m not sure that these represent barriers to interoperability. If a passive TCPCL entity chooses to listen on one port or may separate ports, it doesn’t (or shouldn’t) affect the ability of a peer to attempt to establish a TCPCL session. There may be specific policy on a node that refuses connections or terminates sessions based on the peer parameters, but this seems like a policy or configuration alignment issue and not necessarily lack of interoperability (the node can be capable of interoperating but chooses by policy not to do so).<o:p></o:p></span></p><p class="MsoNormal" style="word-break:normal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p><p class="MsoNormal" style="word-break:normal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">I would be interested to see specific examples or hurdles with TCPCL practice, because if there are special cases that lead to trouble these should at least be captured as errata for RFC 9174 or as updated recommended practice.<o:p></o:p></span></p><p class="MsoNormal" style="word-break:normal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p><p class="MsoNormal" style="word-break:normal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">LTP on the other hand, because it lacks a strong binding to its segment transport, can cause headaches with middleboxes (for example when using UDP transport can confuse NAT and firewalls because it isn’t guaranteed to use a single 5-tuple “conversation” the way other UDP applications typically do). This also has beneficial side effects related to multi-homing though, so there isn’t really a right or wrong way.<o:p></o:p></span></p><p class="MsoNormal" style="word-break:normal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p><p class="MsoNormal" style="word-break:normal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Thanks for any feedback,<o:p></o:p></span></p><p class="MsoNormal" style="word-break:normal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Brian S.<o:p></o:p></span></p><p class="MsoNormal" style="word-break:normal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal" align="left" style="text-align:left;text-autospace:ideograph-other;word-break:normal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org> <b>On Behalf Of </b>??? via SIS-DTN<br><b>Sent:</b> Wednesday, September 6, 2023 12:29 AM<br><b>To:</b> 'Gao, Jay L (JPL-332C)[JPL Employee]' <jay.l.gao@jpl.nasa.gov>; 'Felix Flentge' <Felix.Flentge@esa.int>; sburleig.sb@gmail.com; Torgerson, J. Leigh (US 332C) <jordan.l.torgerson@jpl.nasa.gov>; 'Keith Scott' <keithlscott@gmail.com>; 'Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC <jonathan.j.wilmot@nasa.gov>; 'Carlo Caini' <carlo.caini@unibo.it><br><b>Cc:</b> sis-dtn@mailman.ccsds.org<br><b>Subject:</b> [EXT] [Sis-dtn] Is there a standardized way to implement/configure TCP convergence layer for Bundle transaction?<o:p></o:p></span></p></div></div><p class="MsoNormal" align="left" style="text-align:left"><o:p> </o:p></p><div><div id="APLWarningText"><table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" align="left"><tbody><tr><td width="100%" style="width:100.0%;background:#E0E0E0;padding:0in 0in 0in 0in"><p class="MsoNormal" align="left" style="text-align:left;text-autospace:ideograph-other;word-break:normal;mso-element:frame;mso-element-frame-hspace:1.8pt;mso-element-wrap:around;mso-element-anchor-vertical:paragraph;mso-element-anchor-horizontal:column;mso-height-rule:exactly"><b><span style="font-size:12.0pt;font-family:"Gulim",serif;color:red">APL external email warning: </span></b><span style="font-size:12.0pt;font-family:"Gulim",serif;color:black">Verify sender </span><a href="mailto:sis-dtn-bounces@mailman.ccsds.org"><span style="font-size:12.0pt;font-family:"Gulim",serif">sis-dtn-bounces@mailman.ccsds.org</span></a><span style="font-size:12.0pt;font-family:"Gulim",serif;color:black"> before clicking links or attachments</span><span style="font-size:12.0pt;font-family:"Gulim",serif"><o:p></o:p></span></p></td></tr></tbody></table><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;"><span style="font-family:"Times New Roman",serif"> </span><o:p></o:p></p></div></div><p class="MsoNormal">Hi Fellows<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Recently, I began to consider that the implementation of the TCP convergence layer, which conveys Bundles reliably, can be source of interoperability issues among various DTN implementations.<o:p></o:p></p><p class="MsoNormal">There is freedom in designing the TCP interface, with options like allocating a single TCP port to a node and multiplexing neighbor input, or allocating multiple TCP ports for each neighbor's transaction input.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Some implementations perform an interrogation step to obtain multiplexing information from neighboring nodes, such as IPN/DTN address.<o:p></o:p></p><p class="MsoNormal">Some implementations prefer multiple TCP daemons for connecting with neighbors.<o:p></o:p></p><p class="MsoNormal">In either case, DTN software may need to implement a specialized UTA or CLA interface for interfacing with various other DTN software via TCP convergence layer.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Is there a standardized way to do it? Or do we want to discuss about a standardized way here?<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">On the contrary, LTP, as a Convergence Layer, is a straightforward mechanism and a point-to-point protocol that simplifies Bundle input multiplexing, resulting in fewer interoperability issues, in my opinion. LTPCL is useful at the ground-space link, however TCPCL can be more suitable choice for terrestrial link. So, I think, TCPCL needs more attention for future DTN usage.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Best,<o:p></o:p></p><p class="MsoNormal">Cheol<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><o:p> </o:p></p></div></div>
</div><!-- original content --><br></div></blockquote><p style="font-family:'굴림'; font-size:10pt;line-height:1.5;"></p>
<img src='https://webmail.kari.re.kr:443/checkread/NjgyNzY0/c2lzLWR0bkBtYWlsbWFuLmNjc2RzLm9yZw==/' width='1px' height='1px' />