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

Fri Oct 23 17:08:25 UTC 2015

Yikes!!

 I agree that there needs to be an OSI stack that shows a network / transport layer, but I do not think that every link layer doc needs to show this.  All of the ABA configurations operate without a network / transport layer and will continue to do so.  The SSI configs, however, do have such a network / transport layer.  And note that the SCCS-ARD and the SLS OSLP both show how all of this stuff is intended to work together.  We do not need to invent something new in this case, we need to finish what we started.

I do agree that there is some “CCSDS angst” having to do with the existing application layer standards, like CFDP and AMS, and the relationship to other application layer standards like MOIMS apps and SOIS apps.  That is a key subject on the current “CCSDS Reference Architecture” discussions that are really focussed upon MOIMS & SOIS and how they use underlying communications / transport services, including SLS, SIS and CSS.  The position that has been agreed to date in the CESG and in the reference architetcure discussions is that MOIMS & SOIS rely upon these underlying layers.  Having said that there are more than a few murky application layer corners where details will need to be worked out.

My “Yikes” comment was directly prompted by this statement:

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.

It will probably not come as a surprise to anyone if I point out that this is a total “layer violation”.  I know you SIS guys just love to tunnel DTN over IP, so tunneling seems natural, but in this case I not only think this is a really bad idea, but that it violates what has been agreed to in IOAG and CCSDS and what has been documented in the SCCS-ARD.  So think of this as the “layering police” blowing a whistle on this one.

What has been agreed and documents, in no uncertain terms, is that DTN (preferentially) and IP (where feasible) would be used as the network / transport service for all SSI deployments.  At the end nodes, and for emergency support, we defined a “Last Hop” and “First Hop” application layer service that would, based on meta-data instructions, accept data delivered over the forward path and squirt it out at link layer.  It does the reverse in the return direction and also is to handle open loop and radiometric data.  This is “tunneling” of a sort, but it is what has been defined and agreed to.

These “last hop” and “first hop” services are documented in the IOAG SISG study report and in the SCCS-ARD/ADD.  May I suggest that if SIS wants to develop an application layer tunneling service (that uses, bye the bye, CFDP and DTN) that you focus upon carefully defining these first hop and last hop services.  You will find the architecture, services, and protocol stacks carefully documented in SCCS-ADD, CCSDS 901.0-G-1, in Sec 4.3.2, 4.4, and particularly in 6.5.3 and in the SCCS-ARD, CCSDS 901.1-M-1, in Sec 4.3.4 and 6.2.4.

As for USLP and link layer multiplexing, far as I understand what USLP is trying to do it is to provide link layer “trunk” multiplexing.  This is to multiplex several streams of link layer data, over a single hop, which would typically be between a single ground station and some sort of layer 2 space relay asset.  The TDRS fleet is an example of this now and it works in that way.  The new optical data link discussions also include such trunking for exactly the same sorts of relay spacecraft deployments.  These data links may well carry SIS DTN (or IP) traffic, and it is in discusison as to whether or not these relay assets are also layer 3 routing nodes and not just layer 2 switching nodes.  I personally think that developing layer 3 routing nodes makes a whole lot of sense if we are talking about routing nodes around distant planets, like Mars.

As a final note, just as I recommend that you SIS guys should stay away from link layer tunneling, that I would say to the SLS guys that they should stick to services that make sense in their layer, which are data links over a single hop, and that when routing services are required that SIS services should be invoked.

So, can we stick to what we have agreed and get the SIS guys to define these last hop & first hop services and not some new, “uncooked” link layer tunneling scheme?

Thanks, Peter

From: <sls-slp-bounces at mailman.ccsds.org<mailto:sls-slp-bounces at mailman.ccsds.org>> on behalf of Keith Scott <kscott at mitre.org<mailto:kscott at mitre.org>>
Date: Friday, October 23, 2015 at 9:18 AM
To: Greg Kazz <Greg.J.Kazz at jpl.nasa.gov<mailto:Greg.J.Kazz at jpl.nasa.gov>>, "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>>
Cc: "sis-dtn-owner at mailman.ccsds.org<mailto:sis-dtn-owner at mailman.ccsds.org>" <sis-dtn-owner at mailman.ccsds.org<mailto:sis-dtn-owner at mailman.ccsds.org>>
Subject: Re: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22

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 & AnalysisEmail:  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/4fb74e00/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/4fb74e00/attachment.png>