[Sis-csi] The _other_ SCPS protocols (SP, NP, FP)
Donald P Olsen
Donald.P.Olsen at aero.org
Thu Dec 9 13:46:06 EST 2004
Greetings:
I have been following this chain of email of late and since I am not a protocol person, I will only address the link level issue of bandwidth efficiency. Since we are talking about an RF link and not a land line link, and since bandwidth in allocated
frequency bands is a finite resource, bandwidth efficiency of adding sequence counters etc for security what take as a percentage of the data rate, needs to be small and a few, perhaps no higher than 10 percent, for protocol overhead seems like a
reasonable number.
Don
Howard Weiss <Howard.Weiss at sparta.com>
Sent by: sis-csi-bounces at mailman.ccsds.org
To
Ed Greenberg <egreenbe at jpl.nasa.gov>
12/03/2004 05:39 AM cc
Dave Israel <dave.israel at nasa.gov>, sis-csi at mailman.ccsds.org
Subject
Re: [Sis-csi] The _other_ SCPS protocols (SP, NP, FP)
Ed, Dave,
I will speak only for SCPS-SP. Historically speaking, SCPS-SP was developed in parallel with the IETFs IPSEC. I attended a large number of the IETF IPSEC meetings and followed the course of that protocol development. The problem was, IPSEC was being
developed for the hardwired, terrestrial-based, high bandwidth Internet environment. Protocol overhead, while taken into some account, was not a major issue - a few hundred bytes here or there does not bother people running over broadband circuits.
Wireless at that time did not play into the picture.
At the time of SCPS development, we were still working with the folks who were planning to orbit thousands of kinetic kill vehicles as part of the old "Star Wars" SDI program. There were also the NASA folks who claimed bandwidth starvation and who
counted every overhead bit as too much (which is where I coined my phrase "bit neanderthals"). SCPS-SP was the response to both of these environements - an algorithms neutral, low overhead protocol that did pretty much what IPSEC did (in terms of
providing encryption and authentication/integrity services) but without all of IPSEC's bells and whistles (e.g,. IPSEC includes a 32-bit sequence counter to protect against replay - SCPS-SP says we can't afford such a thing and we hope that only TCP or TP
runs above with its sequence counter).
Do we still need SCPS-SP? Only if the old constraints are still with us - bandwidth deprivation. If we've got landline-like bandwidths - it can go away. If we still have narrow bandwidth that needs security, SP will win over IPSEC.
Howie
Ed Greenberg wrote:
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)
SCPS Security Protocol (SCPS-SP) (http://www.ccsds.org/CCSDS/documents/713x5b1.pdf)
SCPS File Protocol (SCPS-FP) (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
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.
_______________________________________________
Sis-CSI mailing list
Sis-CSI at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
--
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)
_______________________________________________
Sis-CSI mailing list
Sis-CSI at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
More information about the Sis-CSI
mailing list