[Sis-csi] The _other_ SCPS protocols (SP, NP, FP)

Ed Greenberg egreenbe at jpl.nasa.gov
Thu Dec 2 18:20:58 EST 2004


Dave and Keith,

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!!!

Ed Greenberg

At 05:32 PM 12/2/2004 -0500, Dave Israel wrote:
>Keith,
>
>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:
>
>- Does IP header compression replace SCPS-NP?
>- Will SCPS-SP meet the latest and future IT security requirements?
>- Has SCPS-FP been replaced by CFDP and other follow on file delivery methods?
>- Does anybody really foresee these other protocols being used?
>
>The term "SCPS" is starting to become synonymous with "SCPS-TP," so 
>carrying these other protocols, unless truly needed, only increases the 
>confusion.
>
>Somebody had to get the conversation going...
>
>Regards,
>Dave
>
>At 03:24 PM 11/30/2004, you wrote:
>>All,
>>
>>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:
>>
>>   SCPS Network Protocol (SCPS-NP) 
>> (<http://www.ccsds.org/CCSDS/documents/713x0b1.pdf>http://www.ccsds.org/CCSDS/documents/713x0b1.pdf)
>>   SCPS Security Protocol (SCPS-SP) 
>> (<http://www.ccsds.org/CCSDS/documents/713x5b1.pdf>http://www.ccsds.org/CCSDS/documents/713x5b1.pdf)
>>   SCPS File Protocol (SCPS-FP) 
>> (<http://www.ccsds.org/CCSDS/documents/717x0b1.pdf>http://www.ccsds.org/CCSDS/documents/717x0b1.pdf)
>>
>>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:
>>
>>   o Approving the standards 'as-is' for another five years.
>>   o Updating / clarifying aspects of the specifications (as is being 
>> done for the TP)
>>   o Retiring some or all of the standards
>>   o ....?
>>
>>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.
>>
>>SCPS-NP
>>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:
>>   1) SCPS-NP has a 8191-byte maximum packet size limit and no fragmentation
>>   2) SCPS-NP supports a maximum of 16 upper-layer (transport) protocols
>>   3) SCPS-NP supports 16 levels of precedence, independent of the IP TOS 
>> field
>>   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.
>>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.
>>
>>SCPS-SP
>>SCPS-SP provides capabilities similar to IP Security (IPSEC) in the 
>>Internet world.  The main differences between SCPS-SP and IPSEC are:
>>   1) SCPS-SP incurs two bytes of overhead per packet, whereas IPSEC 
>> requires 10
>>   2) SCPS-SP only allows one active security association per address 
>> pair, while IPSEC allows multiple simultaneous SAs.
>>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.
>>   3) SCPS-SP does not provide replay protection, instead it relies on 
>> transport sequence numbers.
>>Because of its lower overhead, SCPS-SP is still relevant to 
>>bandwidth-constrained missions that require security services.
>>
>>SCPS-FP
>>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:
>>   1) Record read, update
>>   2) Integrated file integrity checking
>>   3) Suppression of reply text
>>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.
>>
>>
>>
>>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.
>>
>>Again, I invite discussion on any/all of the protocols.
>>
>>
>>Best Regards,
>>
>>         --keith
>>
>>
>>
>>
>>Dr. Keith Scott
>><mailto:kscott at mitre.org>kscott at mitre.org
>>+1.703.883.6547
>>Chair, CCSDS Cislunar Space Internetworking Working Group
>>
>>_______________________________________________
>>Sis-CSI mailing list
>>Sis-CSI at mailman.ccsds.org
>>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
>
>______________________________________________________________
>Dave Israel
>Leader, Advanced Technology Development Group
>Microwave & Communication Systems Branch
>NASA Goddard Space Flight Center  Code 567.3
>Greenbelt, MD 20771
>Phone: (301) 286-5294      Fax:   (301) 286-1769
>E-mail: dave.israel at nasa.gov
>
>"Without deviation from the norm, progress is not possible."  -Frank Zappa
>_______________________________________________
>Sis-CSI mailing list
>Sis-CSI at mailman.ccsds.org
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi

Progress is impossible when you always do things the way they have always 
been done. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20041202/cae200cd/attachment.html


More information about the Sis-CSI mailing list