<!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.&nbsp; We need to keep 
these.&nbsp; Bob is right, technology is just now catching up.&nbsp; 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>&nbsp;</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>&nbsp;</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>&nbsp;</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.&nbsp; 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.&nbsp; I press for work in this&nbsp;area 
  every chance I get, as it would be quite valuable to tactical military users 
  that are faced with the&nbsp;IPv6 mandate.</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=956180914-03122004></SPAN>&nbsp;</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.&nbsp; As has been noted, these would&nbsp;not carry across 
  IP/NP gateways, and have value only in the NP&nbsp;portions of the 
  network.&nbsp; One&nbsp;capability in particular was the ability to signal 
  alternate routing treatments, such as flooding or (for example) two-path 
  limited flooding.&nbsp; As&nbsp;Howie mentioned in his note, 
  a&nbsp;significant source of our requirements was the&nbsp;Strategic Defense 
  Initiative (SDI) community.&nbsp; These alternate routing treatments gave us 
  the ability to&nbsp;exploit the&nbsp;cross-linked topology of the satellite 
  constellations that they were designing</FONT>&nbsp;<FONT face=Arial 
  color=#0000ff size=2>in order to provide very high probability of receipt and 
  minimal delay to important messages.&nbsp; Even though a 
  corresponding&nbsp;capability does not exist in IP networks, its invocation 
  can be handled either through DSCP mapping or by policy at an IP/NP 
  gateway.&nbsp; 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>&nbsp;</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.&nbsp; 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.&nbsp; The NP's path service has the dual properties 
  of providing very aggressive header compression and providing what amounts to 
  MPLS path identification.&nbsp; 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).&nbsp; The only reason that I mention this is because IP might not 
  be the best fit in all portions of a spacecraft network.&nbsp; (I know, 
  heresy, especially from me.)&nbsp; 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>&nbsp;</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.&nbsp; Further, we incorporated capabilities for the 
  NP to serve as the next generation Space Packet Protocol.&nbsp; If we think 
  that we'll need those capabilities, we should keep NP as a CCSDS 
  recommendation.&nbsp; 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.&nbsp; 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>&nbsp;</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.&nbsp; At minimum, I think they should be reviewed 
    as to whether they truly are recommendations for certain mission 
    scenarios.&nbsp; There should be some clarification, such as what you 
    started in your e-mail, about if/when these protocols should be 
    recommended.&nbsp; I think there should also be an assessment of what 
    continued support for these protocols exists and if there are any newer 
    alternatives.&nbsp; 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?&nbsp; <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>&nbsp;<BR><FONT face=arial size=2>We spent time at 
      the recent CCSDS meetings addressing interoperability and capability 
      issues with SCPS-TP.&nbsp; In addition to the SCPS Transport Protocol 
      (SCPS-TP), there are three other protocols in the SCPS 
      suite:<BR></FONT>&nbsp;<BR><FONT face=arial size=2>&nbsp; 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>&nbsp; 
      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>&nbsp; 
      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>&nbsp;<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.&nbsp; Possible actions for 
      these protocols include:<BR></FONT>&nbsp;<BR><FONT face=arial 
      size=2>&nbsp; o Approving the standards 'as-is' for another five 
      years.<BR>&nbsp; o Updating / clarifying aspects of the specifications (as 
      is being done for the TP)<BR>&nbsp; o Retiring some or all of the 
      standards<BR>&nbsp; o ....?<BR></FONT>&nbsp;<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.&nbsp; 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>&nbsp;<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).&nbsp; SCPS-NP also provides mechanisms for priority handling of 
      datagrams, as well as per-packet control of routing mechanisms.&nbsp; 
      Per-packet routing control is used to signal that certain packets should 
      be flooded to improve reliability.&nbsp; The smallest SCPS-NP header is 4 
      octets, significantly smaller than IPv4's 20-byte header.&nbsp; The main 
      disadvantage of SCPS-NP is that it is not bit-interoperable with IPv4/v6 
      --&nbsp; SCPS-NP headers would have to be translated into and out of 
      IPv4/v6 to allow interoperation with an IPv4/v6-based network.&nbsp; 
      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.&nbsp; Other differences between 
      SCPS-NP and IP include:<BR>&nbsp; 1) SCPS-NP has a 8191-byte maximum 
      packet size limit and no fragmentation<BR>&nbsp; 2) SCPS-NP supports a 
      maximum of 16 upper-layer (transport) protocols<BR>&nbsp; 3) SCPS-NP 
      supports 16 levels of precedence, independent of the IP TOS 
      field<BR>&nbsp; 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>&nbsp;<BR>SCPS-SP<BR>SCPS-SP provides capabilities similar to 
      IP Security (IPSEC) in the Internet world.&nbsp; The main differences 
      between SCPS-SP and IPSEC are:<BR>&nbsp; 1) SCPS-SP incurs two bytes of 
      overhead per packet, whereas IPSEC requires 10<BR>&nbsp; 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.&nbsp; If 
      the mission is pushing HDTV streams around at tens or hundreds of Mbps, a 
      few extra bytes for IPSEC will likely be tolerable.&nbsp; Smaller, lower 
      bandwidth missions might still be able to capitalize on the 
      savings.<BR>&nbsp; 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>&nbsp;<BR><FONT face=arial 
      size=2>SCPS-FP<BR>The SCPS File Protocol supports low-bandwidth file 
      transfers.&nbsp; The main features of SCPS-FP that have NOT been 
      implemented in modern FTP implementations are:<BR>&nbsp; 1) Record read, 
      update<BR>&nbsp; 2) Integrated file integrity checking<BR>&nbsp; 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>&nbsp;<BR>&nbsp;<BR>&nbsp;<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.&nbsp; 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.&nbsp; For 
      that reason I would suggest that these protocols be reaffirmed as 
      Recommendations within CCSDS.<BR></FONT>&nbsp;<BR><FONT face=arial 
      size=2>Again, I invite discussion on any/all of the 
      protocols.<BR></FONT>&nbsp;<BR>&nbsp;<BR><FONT face=arial size=2>Best 
      Regards,<BR></FONT>&nbsp;<BR><FONT face=arial 
      size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      --keith<BR></FONT>&nbsp;<BR>&nbsp;<BR>&nbsp;<BR>&nbsp;<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>&nbsp;<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 &amp; 
    Communication Systems Branch<BR>NASA Goddard Space Flight Center&nbsp; Code 
    567.3<BR>Greenbelt, MD 20771<BR>Phone: (301) 
    286-5294&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax:&nbsp;&nbsp; (301) 
    286-1769<BR>E-mail: dave.israel@nasa.gov<BR><BR>"Without deviation from the 
    norm, progress is not possible."&nbsp; -Frank Zappa 
</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>