[CMC] Re: [CESG] Communiqué from IOP-2
Peter Shames
peter.m.shames at jpl.nasa.gov
Thu Dec 11 15:26:16 EST 2008
Adrian, et al,
The IOP Communique is welcome and it does appear to provide some
needed guidance for CCSDS and IOAG future efforts toward not just
ground based cross support and interoperability, but also toward
future space based services. The idea that all of the involved space
agencies having relevant missions and interests would be invited to
work together toward a Solar System Internetwork is a powerful one.
The set of identified topics, drawn from the IOAG-12 list is a
reasonable one, especially in light of the thrust toward
interoperability in space. However, the priorities of these topics
seem to need some adjustment given current agency plans, as best i
understand them, and the list of things still needing to be done to
complete key parts of the basic interoperability and cross support
fabric.
Furthermore, the implications of producing "end-to-end CFDP
service, ... -to-end space packet service, and end-to-end networked
communications architecture by ... developing the DTN suite as
standards." seems problematic at best. No one has implemented and
deployed an instance of the full end-to-end CFDP spec. There is no
useful spec for what "end-to-end space packet service" is, it is just
a data structure with some Green Book words about how it might be used
to do this. And in any event, DTN seems already to have "stolen the
march" on this if more than a couple of nodes are involved.
After some thought on this, tempered by my experience with what we
have been trying to do within the NASA networks to develop an
integrated network service architecture, I offer the following. It is
rather long, but please see if the logic makes sense.
Suggested priorities:
to develop as a priority cross support transfer
service specifications for:
a) simple relayed CFDP service
b) guideline for interagency routine file
transfer service (best practices recommendation)
c) simple relayed space packet service
to consolidate existing standards and standards
in work at a modest resource level, with a priority to the following:
a) space link monitoring cross-support transfer
service standard
b) space link radiometric cross-support
transfer service standard
c) space link service control cross-support
transfer service standard
d) AOS synchronous forward & return services
with high throughout, low latency & jitter, insert zone, and link
security
e) service management re-structuring and
extension, to include radiometric, D-DOR, files and space
internetworking
to initiate the transition to an end-to-end
networked communications architecture by :
a) developing a standard for CCSDS encapsulation
service;
b) developing a recommended practice for the
deployment of the IP suite.
c) developing the DTN suite as standards
d) developing end-to-end space internetworking
cross support transfer service standards and recommended practice
e) developing end-to-end space network
management cross support service standards (routing, network node
management, store & forward data management, data accountability, etc)
f) time synchronization services
Here is my rationale for these revised priorities and work program
contents:
The work to define a true end-to-end CFDP and space packet service,
including all of the ground terminus standardization and the on-board
management, routing, and accountability standards is redundant with
the work to develop the DTN suite of standards. While DTN is more
complex in content than any simple CFDP or packet relaying approach,
DTN has already shown itself capable of handling multi-node space
internetworking. Investing any significant new effort now in defining
and deploying multi-node, end-to-end CFDP or space packet services
does not appear to be a prudent use of resources.
Accordingly I would recommend that we just provide simple cross
support service interfaces, SLE CLTU & RAF/RCF for packet services and
a newly defined secure FTP interfaces (or some similar adopted
protocol) for CFDP. For on-board use I would recommend that we only
attempt to provide guidance for simple file and packet relaying
scenarios, i.e. no more than one hop as in the current Mars
configurations. This implies store and forward management of packets
or files at the intermediate node, but is simple enough that it can be
handled by "out of band" management or pre-agreement of the simplest
of routing and data management approaches. This requires very little
more standardization effort, but does require some operational
agreements that can be guided by a new CCSDS Recommended Practice.
All effort to support multi-node routing and space internetworking
should be directed towards the DTN suite, more on that later.
The cross support transfer standards that are needed include not just
a monitor data standard (including agreements on standard terminology
across the networks), but also require radiometric data transfer
standards and "service control" standards. The service control is to
permit users to modify service parameters (such as bit rate, mod
index, emergency mode, etc) during service execution. It does not in
any way imply direct equipment control, but does imply control over
the service execution / production. There are also related
requirements for new cross support "bit-stream" or "unframed
telemetry", which can handle either flawed frames or encrypted data
flows. This is a priority in some venues, but is not uniform.
A cross support transfer service that adequately supports AOS
synchronous forward services, along with associated high throughput,
low jitter and latency, performance characteristics, and supporting VC
merging, insert zone, and link layer security is a significant issue
for NASA's exploration missions. No other agency has yet expressed an
interest in this, but if advertised plans for ILN and joint Mars
exploration are any indication, the need for such high rate forward
and return services will soon be present for many agencies. There is
a related set of topics that are being addressed in the next
generation uplink working group, including forward coding and
emergency comms. This also needs to move forward rapidly and for the
same reasons.
In order for all of these cross support services to be requested,
configured and managed we need to have updates to the service
management specifications. This will require the current service
management spec to be re-structured, which the CSS / SM WG area has
already started to explore. There is a related issue of just what, if
anything, is needed in service management in order to configure and
manage these simple file and packet relaying cross support services.
There is the future question of what is needed to configure and manage
any new space internetworking services, including DTN and TCP/IP.
A standard service catalog framework and service level agreements are
also required to be developed by some organization. It is not listed
here, but was mentioned in the IOP Communique. Perhaps IOAG will do
this, they clearly need to be engaged in the process. The IOAG
agencies, or at least the operating arms of all agencies offering
standard cross supported space communications services, need to be the
ones who populate and maintain the service catalogs and operate the
service delivery interfaces. Some organization still need to provide
the catalog and SLE templates with agreed terminology and format.
In the realm of space internetworking we can expect the IOAG SISG /
SIAG to produce a high level view of what is expected in terms of
interoperable space internetworking. It will be the role of CCSDS to
actually develop the necessary standards. These have to include not
only the space comm protocols but also the architecture for how these
are to be delivered as services on the ground and to be operated as
service nodes in space. I've called this DTN and IP functionality
"space internetworking" in the belief that we are likely to want to
construct some sort of hybrid space internetworking framework, that
uses IP in confined localities where it makes sense, but uses DTN to
produce the "long haul" internetworking fabric. This implies a
requirement for IP "on-ramps" and "off-ramps", for development of not
just the DTN networking protocols, but also all of the ancillary
stuff, as in the Internet, that does routing, routing table
management, routing boundary hand-offs, and network operations
management, monitoring and control. We always say "TCP/IP" and ignore
the other 90% of the Internet RFCs that are about getting all of this
other stuff to work.
Similarly we need to determine how we, as a set of agencies that are
challenged to develop a "Solar System Internetwork (SSI)" will
actually configure, manage, operate and deliver these services. We
now expect to depend upon SLE and cross support transfer services, and
service management, to plan, schedule, configure and establish the
basic space links between ground assets and space assets. This
implies a comm architecture that has always had a control center(s) as
part of the path from end users to space and vice-versa. These may be
mission control centers, but are certainly network control centers.
If we are doing "space internetworking" is this still the case or do
we move toward some sort of routed architecture, much like the
Internet, where users think of this communications path a "just being
there, everywhere".
Terrestrially we have a very rich fabric of communications assets that
let's us just hop from wired connections, to WiFi (http://en.wikipedia.org/wiki/Wifi
), to 3G / HSPDA (http://en.wikipedia.org/wiki/HSDPA) or future WiMAX (http://en.wikipedia.org/wiki/WiMAX
), without a thought. However, it is hard to envisage even in the
2025 time frame that we would have anything like that level of
connectivity at the Moon, let alone Mars. Hence it is easy to assume
that we will still need to staple up comm circuits and the basic
physical links, just like we will still need to do pointing,
scheduling, transmitter / receiver & data handling equipment
configuration, etc. We might define some more automated data rate
change signaling and handling mechanisms, and we will surely need to
define multiple access methods at the link layer, and probably some
sort of universal demand access scheme, but none of this looks a lot
like WiFi or WiMAX. That does not mean, however, that there won't be
a drive toward using these existing technologies in situ, at the
edges, or in local enclaves. How does all of this work together and
do we have any sort of shared vision of that?
Probably of more importance from a technical and deployment point of
view is just what the router infrastructure looks like that will make
all of this happen? Will there be IP / WiMAX routers at some edge
nodes that funnel / tunnel IP traffic into DTN bundles? Will there be
DTN routers at all of our ground stations that directly accept DTN
bundles from any authenticated user on the Internet? How is access to
these long haul space links managed? How would we deal with denial of
service (DOS) attacks (and others) on our space comm assets? Does SLE
and SM still play a role in managing, configuring, and delivering data
across the space links? Where is the end of the space link, in a
control center or at the ground station? Is the DTN router fabric
exposed to the broad Internet at some number of well known points or
are there DTN routers deployed at all of the critical end points where
use of this service is required?
And most important for CCSDS, what are the interoperability and cross
support specifications for whatever we eventually envision that will
let pieces of this be built by different agencies (ground elements and
space elements) and still have it all interoperate? I think this is
all very important to figure out, and it does need to be a priority
for IOAG and CCSDS, but I strongly question whether it should take
precedence over getting those basic bread and butter comm items done
so that we take the next steps toward interoperable ground systems and
simple relay operations using files and packets. Hence my suggested
priorities and expanded content to the list.
My more than two cents. Aren't you glad you asked? How do we feed
any results of this CCSDS prioritization discussion back into the
IOAG, in response to the IOP-2 Resolution 5 that "the IOAG should
prioritize the requirements relevant to space communications
interoperability and cross-support".
Cheers, Peter
On 10 Dec 2008, at 10:08 AM, Adrian J. Hooke wrote:
> Please find the attached final Communiqué that was issued at this
> week's second Inter-Operability Plenary (IOP-2) meeting in Geneva,
> which concluded today.
>
> Your attention is drawn to the implications of Resolution #5,
> referencing IOAG R12.9.1 which states the following:
>
> "R 12.9.1 The IOAG requests the CCSDS:
> to develop as a priority cross support transfer
> service specifications for:
> a) end-to-end CFDP service and
> b) end-to-end space packet service.
> to initiate the transition to an end-to-end
> networked communications architecture by :
> a) developing a standard for CCSDS
> encapsulation service;
> b) developing the DTN suite as standards
> c) developing a recommended practice for the
> deployment of the IP suite.
> to consolidate existing standards and standards
> in work at a modest resource level, with a priority to the following:
> a) space link monitoring cross-support transfer
> service standard
> b) guideline for the interagency routine file
> transfer service (best practices recommendation)
> c) time synchronization services"
>
> Is CCSDS comfortable with accepting these priorities?
>
> Best regards
> Adrian J. Hooke
> Chairman, CCSDS Engineering Steering Group (CESG) and
> CCSDS Technical Liaison to the IOAG
> <FINAL Communique 12-10-08.doc><ATT00001.txt>
_______________________________________________________
Peter Shames
Manager - JPL Data Systems Standards Program
InterPlanetary Network Directorate
Jet Propulsion Laboratory, MS 301-230
California Institute of Technology
Pasadena, CA 91109 USA
Telephone: +1 818 354-5740, Fax: +1 818 393-0028
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 --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cmc/attachments/20081211/26e600b2/attachment-0001.htm
More information about the CMC
mailing list