[Sois-tcons] White paper contribution.

Massimiliano.Ciccone at esa.int Massimiliano.Ciccone at esa.int
Mon Jun 13 12:40:17 EDT 2005

Well done Jane !!
I managed to create a folder but I cannot rename or delete it...I will check
with Brian how to do it, please let me know how to name it.
Do you all have access to the private area of TCONS discussion board ?

If not please contact
Oliver Braian at: "Oliver Brian (BTAS)"<brian.oliver at btas.com>
and he will provide you a username and password to access the service.
Like all new things the adaptation is a bit painful at the beginning but I am
sure it will pay off overtime.



|         |           "Jane K. Marquart"       |
|         |           <Jane.K.Marquart at nasa.gov|
|         |           >                        |
|         |           Sent by:                 |
|         |           sois-tcons-bounces at mailma|
|         |           n.ccsds.org              |
|         |                                    |
|         |                                    |
|         |           13/06/2005 17.03         |
|         |                                    |
  |                                                                                                               |
  |        To:      Richard Schnurr <Rick.Schnurr at nasa.gov>, "Scott,Keith L." <KSCOTT at mitre.org>,                 |
  |        sois-tcons at mailman.ccsds.org                                                                           |
  |        cc:                                                                                                    |
  |        Subject: RE: [Sois-tcons] White paper contribution.                                                    |


I uploaded the 2 documents to

I couldn't create a new folder.  Kept getting errors.  I also put this e-mail
on the discussion board so as not to lose it.  Let's try to keep all
correspondence there from now on.

At 05:38 PM 6/10/2005 -0400, Richard Schnurr wrote:
      Hi Keith,

      In some ways I am the scribe but I will try to answer anyway.

      IP/NP is the current networking layer of choice for SOIS.  In some ways
      IP/NP could be given to SIS since all the QOS stuff other than the QOS
      tagging is below. This would simplify SOIS's life since we would simply
      hand this function over to SIS.

      The IP/NP layer does perform the routing between OBL.

      The span of an OBL is defined by the user.  IE if multiple networks of
      the same type are available the bridging of those networks would be
      implementation specific.  This is necessary from a fault tollerance

      Remember some of the Bus/Lan are networks onto themselves (for example)
      JWST is using a SpaceWire network to move data without IP.

      The TCONS-API is better than sockets from my perspective since it
      captures the close interaction between network messages and software
      actions in its call back interface however Jane is the one to discuss
      this and Scott's white paper on the messaging service must be
      interpreted and implemented.

      On the other hand the SOIS API is non-normative since hardware devices
      would not implement.

      Yes, TCONS currently makes no claims to support QOS over multiple OBL's
      (heterogenious or not - IE two separately scheduled SpaceWire networks
      would not support end to end QOS).  Although doing so would not be hard
      if both OBL's were in the same schedule domain.

      Steve, put the copyright notice on the document during the shutdown
      period.  He will have to comment on why.

      As far as I am concerned the document is copyright of the CCSDS since
      all of this is a group derived work.  Otherwise it would be ITAR :).

      The US government has the same write to copyright as anyone else.  The
      current court rulings indicate that US copyright occurs when pen is
      placed to paper with or without registration.  I am less familiar with
      the laws of Greece.  Lets not get into this legal stuff.

      If my clarifications lead to needed changes let me know.


      At 04:22 PM 6/10/2005, Scott,Keith L. wrote:
            So if I understand correctly, the architectural elements say
                  TCONS (in conjunction with/via OBL) provides QoS over
                  individual subnets, and that for traffic that spans
                  heterogeneous subnets, IP is the networking layer?
                  [Architectural Elements (2,3)] Application interfaces to
                  'TCONS' are via sockets and/or a TCONS-specific API. TCONS
                  makes no claims to support QoS over paths containing
                  multiple OBLs
            The inclusion of TCP/IP in the green SOIS box on slide 1 is sort
            of odd (since IP/TCP would normally be a SIS thing).  But taking
            as given that TCONS is a world unto itself in order to provide
            time-critical services, and needs a network layer to span
            heterogeneous subnets, it sort of makes sense.

            BTW: I believe that works by the U.S. Gov't are not eligible for
            copyright protection, and I'm not sure what legal standing 'The
            TCONS Working Group' has wrt copyright.  I'd be sort of
            interested if you know more about this.

                  From: sois-tcons-bounces at mailman.ccsds.org [
                  mailto:sois-tcons-bounces at mailman.ccsds.org] On Behalf Of
                  Richard Schnurr
                  Sent: Friday, June 10, 2005 11:38 AM
                  To: sois-tcons at mailman.ccsds.org
                  Subject: [Sois-tcons] White paper contribution.
                  Hi all,
                  OK, based on the last call I drafted the beginnings of a
                  white paper.

                  I kept it short - hopefully you can all read the whole

                  If we all agree to this structure and the descriptions I
                  think we can restart the books.

                  BTW, it would not hurt my feelings if we deleted the OBL
                  service interface and simply defined a Intra-network
                  service interface (This is what I did in this white paper).
                  Not clear that the OBL interface is usable since on board a
                  spacecraft we are time critical and OBL is a on demand type
                  of service not coordinated with anything else.

                  Also, the OBL service interface seems to get in the way
                  more than it helps.  For example some OBL's support
                  protocol multiplexing.  For those that do the Intra-Net
                  should map directly.  We already have IP addresses.  It
                  would seem that mapping directly from IP addresses to OBL
                  addresses is what is usually done and makes sense.

                  For these reasons I am proposing that the OBL service
                  interface be deleted and replaced with a private interface
                  to the Intra-networking service.

                  Please read my section on address mapping.  It makes sense
                  to me I think it can be implemented and it is in line with
                  existing IP implementations.

                  Steve, I modified the picture to remove the OBL service
                  interface and to move address resolution inside and between
                  the Intra-networking service and OBL. (In case you cannot
                  open the figure again).

                  If we stick to what is written here I think I can actually
                  see a way to implement this consistently across various
                  bus.  This is the first time I have had such clarity and I
                  am going on vacation before any of you spoil it.

                  I am on vacation next week.  So this and the modified
                  diagrams are my contribution to the white paper.


                  PS I did not use the message board because I do not have my
                  password.  Someone can post this if they like.  If you
                  reply to this message Please: do not reply inline  - add
                  your response to the top.  After one pass of the in line
                  comments I cannot follow and on a mailing list like this
                  the likely hood that I will get many reply's is almost
                  surely one.
                  As always correct my thinking as required.

      Richard G Schnurr Jr
      Chief Architect
      Electrical Systems Center
      Applied Engineering and Technology Directorate
      NASA GSFC Code 560.0
      Greenbelt MD 20771

      Sois-tcons mailing list
      Sois-tcons at mailman.ccsds.org

Jane _______________________________________________
Sois-tcons mailing list
Sois-tcons at mailman.ccsds.org

More information about the Sois-tcons mailing list