[Sis-csi] The _other_ SCPS protocols (SP, NP, FP)
Darrell Ernst
dernst at mitre.org
Fri Dec 3 13:53:47 EST 2004
Brilliant Pebbles has been replaced by herds of motes and dust and swarming
UAVs that fit in the palm of your hand. We need to keep these. Bob is
right, technology is just now catching up. Motes are planned to use
cross-links, so NP should remain a viable option.
Darrell
_____
From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Robert C. Durst
Sent: Friday, December 03, 2004 10:22 AM
To: 'Dave Israel'; sis-csi at mailman.ccsds.org
Subject: RE: [Sis-csi] The _other_ SCPS protocols (SP, NP, FP)
Dave,
On the subject of "does IP header compression replace SCPS-NP," here is some
information that may be useful:
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.
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 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.
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.
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.
Best regards,
Bob Durst
_____
From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Dave Israel
Sent: Thursday, December 02, 2004 5:32 PM
To: sis-csi at mailman.ccsds.org
Subject: Re: [Sis-csi] The _other_ SCPS protocols (SP, NP, FP)
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20041203/a5e0c388/attachment.html
More information about the Sis-CSI
mailing list