<html>
<body>
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>
Sis-CSI@mailman.ccsds.org<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: dave.israel@nasa.gov<br><br>
"Without deviation from the norm, progress is not
possible." -Frank Zappa <br>
_______________________________________________<br>
Sis-CSI mailing list<br>
Sis-CSI@mailman.ccsds.org<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><p></x-sigsep>
Progress is impossible when you always do things the way they have always
been done.</body>
</html>