[Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22

[Scott, Keith L.]

Some comments on the draft USLP book:

Figure 2-1: Relationship with OSI Layers

  *   The OSI stack has a Network Layer between Data Link and Transport, and I would argue that the CCSDS Layers do as well (that being either IP or BP).
  *   I’d also like to make an argument for showing up to the application layer, since I think that a lot of CCSDS’ angst comes from not actually thinking that we HAVE applications.

General: What the heck is the tunneling service?

  *   If this really is intended to be tunneling frames across multiple links, we probably need to have a chat between SLP and DTN.  We (DTN) have a NOTION (ok, haven’t done the definition yet) of a ‘standard application’ to tunnel frames (of possibly different kinds, but would presumably include USLP) across the layer-3 network and spit them out somewhere else.  The receiving application would then extract the frames and instructions and emit them towards a destination.  The motivation for this is to be able to send link-layer commands to a spacecraft with which you (as the ground, e.g.) do not have direct link-layer connectivity.  A similar setup would work in the reverse direction, tunneling frames back from a spacecraft.  We (in DTN) have always envisioned these as ‘emergency’ applications, since I’m not keen on what would be essentially extending CSTS across multiple space links!
     *   The point is, if you really mean to tunnel across multiple links, it might be better to get the tunnel service from the network.
  *   Didn’t seem to me that the description in the book was complete?  4.1.5.1.6 didn’t seem complete, but maybe it’s a nascent idea?

SCIDs in General

  *   To Gian Paolo’s comment about putting the SCID as early as possible in the frame: does putting the SCID early do any good unless you also have the Source/Destination indicator bit?
  *   Not having the ability to put BOTH a source and destination address in the frame means that
     *   When I receive transmissions to ME (Source/Destination bit indicates destination SCID in frame), I don’t know where they came from.  Sure, this information may be implied, but what if I’m receiving from someone and there could be multiple senders (I’m thinking multiple rovers hearing from orbiters on Mars, or a similar situation on the Moon)?
        *   Would the ability to include both source and destination addresses allow us to simplify the Mars hailing procedures?
     *   This pretty much ensures that it would be really hard to use USLP for anything involving dynamic link discovery (I’m thinking mostly human spaceflight stuff), since dynamic discovery methods generally need both a broadcast address (which I suppose we could define) and the ability to know who transmitted.  This might not be a problem — anything dynamic might be the realm of something that looks a lot more like an adaptation of a terrestrial data link protocol.

3.2.2.5 TFDF TUNNELING DATA UNIT (TFDF_SDU)

  *   Is this heading title a misnomer?  It seems like you’re mainly describing the TFDF Service Data Unit, which might CONTAIN a TFDF Tunneling Data Unit (?)

3.5 TFDF Tunneling Service

  *   Same question here.  The text seems to deal much more with a TFDF SDU than anything to do with tunneling.

6.2.2.5 TFDF TUNNELING DATA UNIT (TFDF_SDU)

  *   Is Section 6 where section 3 went?  Seems like section 6 (Annex) is a repeat of Section 3…

TFDF Header Always Present?

  *   Is the TFDF header always present whenever the length of the TFDF_SDU > 0?

====

—keith
Dr. Keith Scott                                                                        Office: +1.703.983.6547
Chief Engineer, J86A                                                             Fax:      +1.703.983.7142
Communications Network Engineering & Analysis Email:  kscott at mitre.org<mailto:kscott at mitre.org>
The MITRE Corporation<http://www.mitre.org/>
M/S H300
7515 Colshire Drive
McLean, VA 22102

Area Director, CCSDS<http://www.ccsds.org/> Space Internetworking Services<http://cwe.ccsds.org/sis/default.aspx>

MITRE self-signs its own certificates.  Information about the MITRE PKI Certificate Chain is available from http://www.mitre.org/tech/mii/pki/

[cid:62DF199A-3B64-4F9A-AA4D-FDB0DA4D46DC]<http://www.mitre.org/>



From: <sls-slp-bounces at mailman.ccsds.org<mailto:sls-slp-bounces at mailman.ccsds.org>> on behalf of Greg Kazz <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Date: Thursday, October 22, 2015 at 4:25 PM
To: "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>
Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22

Dear SLP members,

The lastest version which we plan to review at the SLP WG meeting in Darmstadt on Nov 9 and 10 is now in the CWE under the following URL:

http://tiny.cc/goc14x

Note that the filename contains the date of: 10-22-15gk_clean2

However, the latest changes using the Word tracking feature are there. Also note that Section 3 has been put back into this version. I cannot explain how it disappeared during the previous revision. Also we have tried to be more consistent with the outlines followed by TC, TM, and AOS where applicable.

Best regards,

Greg
Chairman SLP WG



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20151023/d0e326e9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6B72C8A7-BF57-46DC-B33A-CAE20825E097[2].png
Type: image/png
Size: 2755 bytes
Desc: 6B72C8A7-BF57-46DC-B33A-CAE20825E097[2].png
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20151023/d0e326e9/attachment.png>