[Sois-tcons] Re: [SOIS] Slight changes to TCONS and SOIS architecture figures.

[Peter Shames]

There appears to be a fundamental problem with any of these diagrams 
and part of it stems from trying to show organizational boundaries 
(TCONS vs TCOA vs OBL) and functional protocol boundaries on the same 
diagram.  The protocol boundaries or layers are supposed to expose 
services as Service Access Points (SAP).  These SAPs and the services 
offered and expected are what needs to be emphasized.  These are only 
partly identified in these diagrams, many SAPs are implied but not 
clearly identified.

Further, and of perhaps more concern, all of these diagrams, as drawn, 
can easily be misinterpreted.  The diagrams read as though the 
following were true:

- there is a generic OBL interface implementation that allows access to 
any underlying link layer protocol
- there is a generic implementation of the intra-network service layer 
that can operate on top of the generic OBL data link and provide 
"intra-networking" across any and all OBL options
- there is a generic implementation of the inter-network service layer 
that can operate on top of a generic Intra-Network layer and operate 
across any and all underlying intra-networks to provide end to end 
transport and routing across several subnets
- the assumption is that one can get internetworking services, 
analogous to those that TCP/IP delivers, by using the TCONS "Network 
Services" interface and that TCP/IP, and TNOCS Network services and 
direct application access using the TCONS API can all coexist over any 
set of underlying layers

However, in reading the document and discussing this with our GSFC 
colleagues, what emerges is the following statement of what is really 
intended:

- there is an instance of a generic OBL interface implementation that 
allows access to only one link layer protocol, each link layer protocol 
requires its own implementation
- there is a specific implementation of an intra-network service layer 
that can operate on top of a single OBL data link and provide 
"intra-networking" across only this OBL option
- there is an implementation of the inter-network service layer that 
can operate on top of any Intra-Network layer but operates across only 
one underlying intra-network to provide end to end transport and 
routing within a single sub-net
- the assumption is that one can get internetworking services, 
analogous to those that TCP/IP delivers, by using the TCONS "Network 
Services" interface over a single subnet and that TCP/IP, and TCONS 
Network services and direct application access using the TCONS API can 
all coexist over this single underlying set of layers on a single 
subnet
- there is no intention to provide end to end transport and routing 
except by using TCP/IP (or SCPS)

These are very different statements of functionality and 
interoperability and are in no way compatible.  I would diagram them 
differently, essentially showing separate stacks in the second case and 
a single stack diagram in the first case, much as has been shown.  It 
appears that the "intra-network" approach that is proposed only works 
within a single, heterogeneous subnet and that not even the same set of 
services may be offered in common in different implementations due to 
limitations in the underlying data link.  Because of this it may be 
better to consider these "Intra-network" services as being the top 
layer of the data link and avoid the whole issue of implementing a 
"generic OBL" layer entirely.  It may make more sense to expose the 
"Intra-network service SAP" as the API at the top of a specific data 
link (or subnet, you choose the terminology).

I would also separate out from these diagrams any attempt to show the 
organizational boundaries on this same diagram until these technical 
issues are worked out.  It appears that this notion of a "generic OBL" 
interface is an artifact of trying to get the OBL WG to expose a 
service interface for the TCONS WG.  It may be that this is not the 
right way to develop these technical services.  Finally, while there is 
clearly value in being able to show which WG owns which elements and 
exposes which interfaces, this should not be the focus of all of the 
layer diagrams, which are about services, not organizations.

Regards, Peter


On Sep 12, 2005, at 6:59 AM, Scott,Keith L. wrote:

> <Proposed fig 2-1.ppt>
_______________________________________________________

Peter Shames
Manager - JPL Information Systems Standards Program
InterPlanetary Network and Information Systems Directorate
Jet Propulsion Laboratory, MS 301-265
California Institute of Technology
Pasadena, CA 91109 USA

Telephone: +1 818 354-5740,  Fax: +1 818 393-1333

Internet:  Peter.Shames at jpl.nasa.gov
________________________________________________________
"We shall not cease from exploration, and the end of all our exploring
will be to arrive at where we started, and know the place for the first 
time"

                                                                         
                      T.S. Eliot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5309 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/sois-tcons/attachments/20050912/586e3df7/attachment.bin