<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=238445018-03122004><FONT face=Arial
color=#0000ff size=2>Brilliant Pebbles has been replaced by herds of motes and
dust and swarming UAVs that fit in the palm of your hand. We need to keep
these. Bob is right, technology is just now catching up. Motes are
planned to use cross-links, so NP should remain a viable
option.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=238445018-03122004><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=238445018-03122004><FONT face=Arial
color=#0000ff size=2>Darrell</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> sis-csi-bounces@mailman.ccsds.org
[mailto:sis-csi-bounces@mailman.ccsds.org] <B>On Behalf Of </B>Robert C.
Durst<BR><B>Sent:</B> Friday, December 03, 2004 10:22 AM<BR><B>To:</B> 'Dave
Israel'; sis-csi@mailman.ccsds.org<BR><B>Subject:</B> RE: [Sis-csi] The
_other_ SCPS protocols (SP, NP, FP)<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2>Dave,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2>On the subject of "does IP header compression replace
SCPS-NP," here is some information that may be useful:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2>Currently, IP Header Compression does not support
multicast. This would be a useful capability to have, but since the
current compression schemes are really oriented toward pairwise state
maintenance, it doesn't seem likely. I press for work in this area
every chance I get, as it would be quite valuable to tactical military users
that are faced with the IPv6 mandate.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2>Additionally, NP has some features that are not reflected
directly in IP. As has been noted, these would not carry across
IP/NP gateways, and have value only in the NP portions of the
network. One capability in particular was the ability to signal
alternate routing treatments, such as flooding or (for example) two-path
limited flooding. As Howie mentioned in his note,
a significant source of our requirements was the Strategic Defense
Initiative (SDI) community. These alternate routing treatments gave us
the ability to exploit the cross-linked topology of the satellite
constellations that they were designing</FONT> <FONT face=Arial
color=#0000ff size=2>in order to provide very high probability of receipt and
minimal delay to important messages. Even though a
corresponding capability does not exist in IP networks, its invocation
can be handled either through DSCP mapping or by policy at an IP/NP
gateway. As such, these capabilities remain viable.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2>Finally, we provided explicit support for a CCSDS
path-like addressing capability as a means of reducing overhead. It has
the ability to support variable sized path addresses, providing additional
address range that may be useful as the Space Packet Protocol Path encounters
address space limitations. The NP's path service has the dual properties
of providing very aggressive header compression and providing what amounts to
MPLS path identification. This is essentially a virtual circuit service,
where circuit setup is either static (i.e. PVCs) or accommodated by a protocol
outside of NP (e.g., SNMP via the NP MIB or an explicit control plane
protocol). The only reason that I mention this is because IP might not
be the best fit in all portions of a spacecraft network. (I know,
heresy, especially from me.) But path service is available in NP for
those missions that need it.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2>To summarize, there are capabilities in SCPS-NP that were
put there specifically for cross-linked satellite constellations, and for
which no IP analog exists. Further, we incorporated capabilities for the
NP to serve as the next generation Space Packet Protocol. If we think
that we'll need those capabilities, we should keep NP as a CCSDS
recommendation. I don't think that "Historic" is an appropriate
redesignation for the NP (or the other SCPS documents), because the situation
is not that the technology is obsolete, but rather that the need hasn't yet
caught up with the technology. I don't believe that there's a path from
Blue to Orange in the current procedures, so I'd say keep them at
Blue.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2>Best regards,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=956180914-03122004><FONT face=Arial
color=#0000ff size=2>Bob Durst</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> sis-csi-bounces@mailman.ccsds.org
[mailto:sis-csi-bounces@mailman.ccsds.org] <B>On Behalf Of </B>Dave
Israel<BR><B>Sent:</B> Thursday, December 02, 2004 5:32 PM<BR><B>To:</B>
sis-csi@mailman.ccsds.org<BR><B>Subject:</B> Re: [Sis-csi] The _other_ SCPS
protocols (SP, NP, FP)<BR></FONT><BR></DIV>
<DIV></DIV>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 class=cite cite="" type="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><X-SIGSEP>
<P></X-SIGSEP>______________________________________________________________<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
</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>