<!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=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></BODY></HTML>