[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