<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">Ed, Dave,<br>
<br>
I will speak only for SCPS-SP. Historically speaking, SCPS-SP was
developed in parallel with the IETFs IPSEC. I attended a large number
of the IETF IPSEC meetings and followed the course of that protocol
development. The problem was, IPSEC was being developed for the
hardwired, terrestrial-based, high bandwidth Internet environment.
Protocol overhead, while taken into some account, was not a major issue
- a few hundred bytes here or there does not bother people running over
broadband circuits. Wireless at that time did not play into the
picture. <br>
<br>
At the time of SCPS development, we were still working with the folks
who were planning to orbit thousands of kinetic kill vehicles as part
of the old "Star Wars" SDI program. There were also the NASA folks who
claimed bandwidth starvation and who counted every overhead bit as too
much (which is where I coined my phrase "bit neanderthals"). SCPS-SP
was the response to both of these environements - an algorithms
neutral, low overhead protocol that did pretty much what IPSEC did (in
terms of providing encryption and authentication/integrity services)
but without all of IPSEC's bells and whistles (e.g,. IPSEC includes a
32-bit sequence counter to protect against replay - SCPS-SP says we
can't afford such a thing and we hope that only TCP or TP runs above
with its sequence counter).<br>
<br>
Do we still need SCPS-SP? Only if the old constraints are still with
us - bandwidth deprivation. If we've got landline-like bandwidths - it
can go away. If we still have narrow bandwidth that needs security, SP
will win over IPSEC. <br>
<br>
Howie<br>
</font></font><br>
Ed Greenberg wrote:<br>
<blockquote
cite="mid5.2.0.9.2.20041202151506.01d7cc38@mail.jpl.nasa.gov"
type="cite">Dave and Keith,<br>
<br>
I agree with Dave. Someone should answer the first question (Does
IP header compression replace SCPS-NP?). But in that vain NP was
designed to go where IP wouldn't and therefore it might still be a
valid
recommendation to keep . I believe that SP was produced because
there was no IP security spec at the time. I believe that FP should
be dropped, period!!! <br>
<br>
Ed Greenberg<br>
<br>
At 05:32 PM 12/2/2004 -0500, Dave Israel wrote:<br>
<blockquote type="cite" class="cite" cite="">Keith,<br>
<br>
I don't believe the NP, SP, and FP protocols should just be reaffirmed,
as is. At minimum, I think they should be reviewed as to whether
they truly are recommendations for certain mission scenarios. There
should be some clarification, such as what you started in your e-mail,
about if/when these protocols should be recommended. I think there
should also be an assessment of what continued support for these
protocols exists and if there are any newer alternatives. Some
questions that come to my mind (that I don't know the answers to)
are:<br>
<br>
- Does IP header compression replace SCPS-NP?<br>
- Will SCPS-SP meet the latest and future IT security requirements?<br>
- Has SCPS-FP been replaced by CFDP and other follow on file delivery
methods?<br>
- Does anybody really foresee these other protocols being used?
<br>
<br>
The term "SCPS" is starting to become synonymous with
"SCPS-TP," so carrying these other protocols, unless truly
needed, only increases the confusion.<br>
<br>
Somebody had to get the conversation going...<br>
<br>
Regards,<br>
Dave<br>
<br>
At 03:24 PM 11/30/2004, you wrote:<br>
<blockquote type="cite" class="cite" cite=""><font face="arial"
size="2">All,<br>
</font> <br>
<font face="arial" size="2">We spent time at the recent CCSDS
meetings
addressing interoperability and capability issues with SCPS-TP. In
addition to the SCPS Transport Protocol (SCPS-TP), there are three
other
protocols in the SCPS suite:<br>
</font> <br>
<font face="arial" size="2"> SCPS Network Protocol (SCPS-NP)
(<a href="http://www.ccsds.org/CCSDS/documents/713x0b1.pdf">http://www.ccsds.org/CCSDS/documents/713x0b1.pdf</a>)<br>
SCPS Security Protocol (SCPS-SP)
(<a href="http://www.ccsds.org/CCSDS/documents/713x5b1.pdf">http://www.ccsds.org/CCSDS/documents/713x5b1.pdf</a>)<br>
SCPS File Protocol (SCPS-FP)
(<a href="http://www.ccsds.org/CCSDS/documents/717x0b1.pdf">http://www.ccsds.org/CCSDS/documents/717x0b1.pdf</a>)<br>
</font> <br>
<font face="arial" size="2">These protocols were approved as
CCSDS
Recommendations a little over five years ago, and reviewing them falls
under the Cislunar Space Internetworking Working Group's charter.
Possible actions for these protocols include:<br>
</font> <br>
<font face="arial" size="2"> o Approving the standards 'as-is'
for
another five years.<br>
o Updating / clarifying aspects of the specifications (as is being
done for the TP)<br>
o Retiring some or all of the standards<br>
o ....?<br>
</font> <br>
<font face="arial" size="2">It is my personal belief that while
there has
not been as much commercial interest in the above standards as there
has
been in the SCPS Transport Protocol (SCPS-TP), they are still relevant
for space use, at least for certain mission sets. Below is a brief
reprise of the various protocols' capabilities, comparisons with their
Internet counterparts, and comments about their continued applicability
to CCSDS.<br>
</font> <br>
<font face="arial" size="2">SCPS-NP<br>
The SCPS Network Protocol allows for very compact representation of end
system addresses and groups of addresses (the latter via the path
address
feature). SCPS-NP also provides mechanisms for priority handling of
datagrams, as well as per-packet control of routing mechanisms.
Per-packet routing control is used to signal that certain packets
should
be flooded to improve reliability. The smallest SCPS-NP header is 4
octets, significantly smaller than IPv4's 20-byte header. The main
disadvantage of SCPS-NP is that it is not bit-interoperable with
IPv4/v6
-- SCPS-NP headers would have to be translated into and out of
IPv4/v6 to allow interoperation with an IPv4/v6-based network.
Translating between SCPS-NP and IP is possible, with the possible loss
in
IP of some of NP's capabilities such as the ability to select different
routing treatments as mentioned above. Other differences between
SCPS-NP and IP include:<br>
1) SCPS-NP has a 8191-byte maximum packet size limit and no
fragmentation<br>
2) SCPS-NP supports a maximum of 16 upper-layer (transport)
protocols<br>
3) SCPS-NP supports 16 levels of precedence, independent of the IP
TOS field<br>
4) SCPS-NP's version of ICMP (SCMP) supports explicit signaling of
congestion, corruption, and link outage if such information can be
acquired from the link layer.<br>
Its lower overhead and ability to signal per-packet routing options
make
SCPS-NP an attractive alternative to straight IPv4 (IPv6) for
bandwidth-constrained missions.<br>
<br>
SCPS-SP<br>
SCPS-SP provides capabilities similar to IP Security (IPSEC) in the
Internet world. The main differences between SCPS-SP and IPSEC
are:<br>
1) SCPS-SP incurs two bytes of overhead per packet, whereas IPSEC
requires 10<br>
2) SCPS-SP only allows one active security association per address
pair, while IPSEC allows multiple simultaneous SAs.<br>
For some mission scenarios the overhead savings of SCPS-SP are probably
not worth the effort. If the mission is pushing HDTV streams around
at tens or hundreds of Mbps, a few extra bytes for IPSEC will likely be
tolerable. Smaller, lower bandwidth missions might still be able to
capitalize on the savings.<br>
3) SCPS-SP does not provide replay protection, instead it relies
on transport sequence numbers.<br>
Because of its lower overhead, SCPS-SP is still relevant to
bandwidth-constrained missions that require security services.<br>
</font> <br>
<font face="arial" size="2">SCPS-FP<br>
The SCPS File Protocol supports low-bandwidth file transfers. The
main features of SCPS-FP that have NOT been implemented in modern FTP
implementations are:<br>
1) Record read, update<br>
2) Integrated file integrity checking<br>
3) Suppression of reply text<br>
The ability to read and update pieces of a file without reading/sending
the entire file could be of significant benefit to
bandwidth-constrained
(or asymmetric bandwidth) missions.<br>
</font> <br>
<br>
<br>
<font face="arial" size="2">In short, SCPS-NP, SCPS-SP, and
SCPS-FP provide
bit-efficient services that will be needed on future space
missions. While some missions will likely have bandwidth to burn,
others that are not so lucky will be able to reap significant benefits
from NP, SP, and FP. For that reason I would suggest that these
protocols be reaffirmed as Recommendations within CCSDS.<br>
</font> <br>
<font face="arial" size="2">Again, I invite discussion on any/all
of the
protocols.<br>
</font> <br>
<br>
<font face="arial" size="2">Best Regards,<br>
</font> <br>
<font face="arial" size="2">
--keith<br>
</font> <br>
<br>
<br>
<br>
<font face="arial" size="2">Dr. Keith Scott<br>
<a href="mailto:kscott@mitre.org">kscott@mitre.org</a><br>
+1.703.883.6547<br>
Chair, CCSDS Cislunar Space Internetworking Working Group<br>
</font> <br>
_______________________________________________<br>
Sis-CSI mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Sis-CSI@mailman.ccsds.org">Sis-CSI@mailman.ccsds.org</a><br>
<a
href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi"
eudora="autourl">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</a></blockquote>
<br>
______________________________________________________________<br>
Dave Israel<br>
Leader, Advanced Technology Development Group<br>
Microwave & Communication Systems Branch<br>
NASA Goddard Space Flight Center Code 567.3<br>
Greenbelt, MD 20771<br>
Phone: (301) 286-5294 Fax:
(301) 286-1769<br>
E-mail: <a class="moz-txt-link-abbreviated" href="mailto:dave.israel@nasa.gov">dave.israel@nasa.gov</a><br>
<br>
"Without deviation from the norm, progress is not
possible." -Frank Zappa <br>
_______________________________________________<br>
Sis-CSI mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Sis-CSI@mailman.ccsds.org">Sis-CSI@mailman.ccsds.org</a><br>
<a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi"
eudora="autourl">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</a></blockquote>
<x-sigsep></x-sigsep>
<p>Progress is impossible when you always do things the way they have
always
been done.</p>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Sis-CSI mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sis-CSI@mailman.ccsds.org">Sis-CSI@mailman.ccsds.org</a>
<a class="moz-txt-link-freetext" href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)
</pre>
</body>
</html>