CCSDS CONCEPT PAPER
CCSDS Concept Paper: Extended Signaling for SCPS-TP
Keith Scott
The MITRE Corporation
June 23, 2005
Introduction
This document is a concept paper for the Consultative Committee for Space Data Systems (CCSDS). CCSDS
concept papers are working documents of the Consultative Committee for Space Data Systems (CCSDS), its areas,
and its working groups. CCSDS concept papers are valid for a maximum of nine months and may be updated,
replaced, or obsoleted by other documents at any time.
Abstract
This concept paper proposes modifications to the Space Communications Protocol Specification – Transport
Protocol (SCPS-TP, [1]) to allow extended signaling between source and destination during the TCP SYN exchange.
The proposed modification re-uses the SCPS Capabilities Option (TCP Option 20) as the container option that
allows for additional standardized signaling, as well as vendor- and community-specific signaling between SCPS-TP
endpoints.
Background
TCP, TCP Options
The Transport Control Protocol, TCP [2] is a reliable protocol at layer 4 (transport) of the ISO network model [3].
TCP provides reliable, in-order data delivery with duplicate suppression at the receiver. The base TCP protocol is
extensible through the use of TCP options. Options are type-length-value encoded in the TCP header, allowing for
signaling between source and destination that either was not envisioned at the time the base TCP protocol was
developed, or was deemed sufficiently optional as to not be required on every TCP connection. Examples of
common TCP options include window scaling (TCP option 2), Selective ACKnowledgments (SACK) permitted
(TCP option 4), and SCPS Capabilities (TCP option 20).
A TCP header consists of a 'base' header that includes source and destination ports, sequence and acknowledgment
numbers, and other information. TCP options, if present, appear immediately following the base TCP header. The
base header is 20 bytes long, and contains within it a 4-bit length field that gives the overall length of the TCP
header, including any TCP options. A 4-bit header length field allows for a maximum TCP header of 60 bytes; the
20 bytes of base TCP header leaves 40 bytes available for TCP options.
CCSDS CONCEPT PAPER
Page 1
CCSDS CONCEPT PAPER
0
15 16
16-bit source port number
31
16-bit destination port number
32-bit sequence number
32-bit acknowledgment number
4-bit header
length
reserved (6 bits)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16-bit TCP checksum
16-bit window size
16-bit urgent pointer
options (if any)
data (if any)
Figure 1: TCP Header
SCPS-TP
In the early 1990s, NASA was interested in network- and transport-layer protocols for communicating with
spacecraft. The characteristics of space communications are such that the performance of TCP, even with the
options available at the time, could suffer. The long delays, error rates, and constrained and asymmetric bandwidths
typical of space communications at the time prompted NASA and the US Department of Defense to sponsor the
development of extensions to TCP that would allow it to be tuned for better performance in these types of stressed
environments.
NASA brought these efforts to CCSDS, and they resulted in a set of protocol specifications that provide efficient,
high-performance communication in stressed environments, including space. The Space Communications Protocol
Specification (SCPS) suite includes a network protocol [4], a security protocol [5], a transport protocol, the SCPSTP, and a file transfer protocol [6]. While the network and security protocols are not interoperable with their
terrestrial counterparts, IP and IPSec respectively, the transport and file transfer protocols can interoperate with
'standard' TCP and FTP.
The SCPS-TP is implemented as a set of TCP options (TCP options 20-23). Option 20 (SCPS Capabilities) is used
by endpoints during the TCP SYN exchange to determine whether or not both of them support certain capabilities,
much the same way two endpoints would exchange window scaling options. Option 20 actually allows endpoints to
negotiate a number of capabilities, including a not entirely-reliable 'best effort' transport service, two different forms
of Selective Negative ACKnowledgments (SNACK), a error-tolerant header compression scheme, and whether the
endpoints will use network-layer timestamps.
Because SCPS-TP is simply a set of TCP options, it is interoperable with other TCPs that do not implement the
SCPS extensions. If a non-SCPS capable endpoint attempts to establish a TCP connection with a SCPS-capable
endpoint, then it will NOT provide a SCPS Capabilities option, and the SCPS-capable endpoint will know that it can
use only those options advertised by the sender. Conversely, if a SCPS-TP-capable endpoint attempts to establish a
connection with a TCP implementation that does not support SCPS-TP capabilities, the non-SCPS-capable endpoint
will ignore the SCPS Capabilities option in the TCP SYN segment, and specifically will not return it in the SYNACK. This will tell the sender that the receiver does not support the SCPS capabilities, and that it should fall back
to using only those services the receiver does support.
There are a number of other features specified in [1] that allow operators to improve the performance of the protocol
over space links. Many of these involve 'sender-side' modifications that do not impact interoperability with other
TCP implementations, and are not discussed further here.
CCSDS CONCEPT PAPER
Page 2
CCSDS CONCEPT PAPER
TCP Performance Enhancing Proxies
As mentioned earlier, SCPS-TP was originally developed for communicating with spacecraft. The goal was to
support a model of operations where scientists and investigators on Earth could communicate directly with
instruments on-board spacecraft, over the stressed space communication links.
Towards the end of the development of SCPS-TP, Internet Service Providers (ISPs) were gaining experience with
using satellite communications (satcom) links to extend the reach of their services. These satellite communications
links were generally point-to-point transponded links, so there was no demodulation on-board the satellite. TCP
connections over these links, however, showed remarkably poor performance. The reason was that these satcom
links exhibited exactly the performance characteristics SCPS-TP was designed to overcome: long delays, high bit
error rates, and in some cases asymmetrical bandwidth. Tuning parameters of the end systems' TCP stacks can
sometimes improve performance in these situations, but those improvements are usually limited, and can also result
in adverse performance for connections that do not use the stressed link.
One means to improve end-to-end TCP performance over these links is to employ a Performance Enhancing Proxy,
or PEP [7]. A particular class of PEP is what is commonly referred to as a 'split-connection' PEP. These devices
split end-to-end TCP connections into three pieces: source to PEP1, PEP1 to PEP2, and PEP2 to destination. The
advantage of this approach is that the inter-PEP protocol used between PEP1 and PEP2 need not be TCP. In
particular, the inter-PEP protocol may choose to NOT employ congestion control (which is required in TCP), and
may employ other mechanisms to improve performance over the stressed communication link.
TCP
TCP
Other
Other
TCP
IP
IP
IP / NP
IP / NP
IP
TCP
IP
Link
Link
Link
Link
Link
Link
Figure 2: TCP Performance Enhancing Proxies
A number of commercial vendors have developed products that implement the SCPS-TP protocol, usually as PEPs
that are designed to be used over satellite channels. There are two major advantages to these vendors in using the
SCPS-TP protocol as the inter-PEP protocol:
1. The SCPS-TP protocol is sufficiently tunable that it can provide good or excellent performance across a
wide range of link characteristics.
2. SCPS-TP is a standard, allowing multiple vendors' PEP implementations to interoperate, provided that they
all adhere to the standard.
Extended Capabilities Signaling in SCPS-TP
One might want to signal additional capabilities that are not supported by the current SCPS Capabilities option, such
as the ability to do data compression, the compression algorithm, the ability to support advanced option negotiation
on non-SYN segments, etc. Signaling each of these capabilities separately in the style of traditional TCP options
such as MSS would quickly consume the remaining space in the 40 bytes allocated to TCP options.
Proposed Modifications to the SCPS-TP Specification
This paper proposes to modify the SCPS-TP specification to allow two SCPS-TP-compliant endpoints to negotiate
additional capabilities during the SYN exchange. The endpoints could be two end systems implementing the SCPSTP protocol, or a pair of PEPs. The proposed method is, as far as we know, backward compatible with existing
CCSDS CONCEPT PAPER
Page 3
CCSDS CONCEPT PAPER
implementations. We briefly describe the proposed modifications here; the next sub-section contains text that would
be inserted directly into the SCPS-TP specification.
The main concept behind this proposal is a slight variant one originally put forward by Jerry Toporek on the sisscps-interest mailing list – to re-use the SCPS Capabilities TCP option (option 20) more than once in the TCP
header. All instances of option 20 after the first would be interpreted in the context of 'extended' capability signaling
described here.
Under this proposal, extended capability binding space identifiers will be assigned to individual vendors, as well as
to communities of interest.
If a vendor or community wants to support multiple options, then those must be multiplexed in a vendor- or
community-specific way underneath the extended option data.
SCPS-TP Modifications
This section contains text to be applied against the current issue of the SCPS-TP specification [1]. Note that the text
here would be inserted into the specification and defines a set of extensions. The 'core' SCPS-TP specification (as
defined in section 3.2.3 of [1] remains in effect.
[Insert new section 3.2.5 immediately preceding section 3.3 (DATA TRANSFER)]
3.2.5 SCPS-TP EXTENDED CAPABILITIES OPTION
The following format is used to signal 'extended' SCPS capabilities.
Extended capabilities allow endpoints to perform signaling in addition to
that supported by the 'standard' SCPS Capabilities option described above.
Extended capabilities are identified by reuse of the SCPS Capabilities Option
(option 20) two or more times on a particular SYN packet (TCP packet with the
SYN bit set). These extended option 20s are prohibited from having length 4
to help differentiate them from 'standard' SCPS Capabilities Options. The
FIRST SCPS Capabilities Option present on a SYN segment must have length 4
and is interpreted as above.
The intent of allowing extended capabilities is to allow vendors and
communities of interest to implement features unique to particular
environments. Each vendor or community of interest will be assigned a unique
identifier. Extended SCPS
3.2.5.1 Extended Capability Format
The first part of an extended capability signal is the presence of a second
(third, etc.) SCPS Capabilities Option (TCP option 20). This option has the
standard TCP option format, as shown in Figure 3-2. The type of this option
is SCPS Capabilities (20), and the length is variable, but prohibited from
being 4 (the mandated length of the base SCPS Capabilities option above).
NOTE - The first SCPS Capabilities option on a SYN segment MUST be the
'standard' SCPS Capabilities Option defined in section 3.2.3 with
length = 4. It is not possible to have an extended SCPS capabilities
option (length !=4) without preceding it with a 'standard' SCPS
capabilities option of length 4, formatted as in section 3.2.3.
CCSDS CONCEPT PAPER
Page 4
CCSDS CONCEPT PAPER
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+-----------------------------------------------+
|
SCPS Capabilities (20)
|
+-----------------------------------------------+
|
Length (!=4)
|
+-----------------------------------------------+
|
Extended Capabilities
|
+-----------------------------------------------+
Figure 3-2: Beginning of extended
capabilities signaling
octet 1
octet 2
variable, determined by
Length field
Length: The value of this field equals the total number of octets in all of
the extended capability options signaled by this (extended) SCPS capabilities
option, including octets 1 and 2. That is, the length field of extended SCPS
capabilities options behaves as a normal TCP option length field. The value
of the length field may NOT be equal to 4 to ensure that implementations that
do not understand extended capabilities do not confuse an extended capability
SCPS option with a 'standard' SCPS capabilities option (section XXXXX).
Figure 3-3 shows the format for each individual extended capability.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+-----------------------------------------------+
|
Extended Capability Binding Space ID
|
+-----------------------------------------------+
| Extended cap. length |
Extended
|
+-----------------------+
capability
+
|
data
|
+-----------------------------------------------+
Figure 3-3: Format for extended
capabilities
octet 1
octet 2
variable, determined by
Extended cap. length field
3.2.5.1.1 Extended Capability Fields
3.2.5.1.1.1 Extended Capability Binding Space ID
This identifies the particular extended capability binding space. The
extended capability data is interpreted in the context of this identifier.
The extended capability binding space identifier is an arbitrary integer that
identifies the format of the extended capability data, which could contain
information about one or more extended capabilities. For example, a
particular vendor might use a single binding space identifier and signal a
number of individual capabilities with flags in the extended capability data
field. The format of identifying the particular capabilities would be
completely vendor-specific. In general there would be at most one extended
capability binding space ID per vendor or community of interest. If vendors
or communities want to implement multiple extended capabilities, they will
need to define their own signaling/multiplexing method for those capabilities
within a particular extended capability DATA area. Vendors are strongly
encouraged to make the format of their extended capabilities public knowledge
NOTE - Assignment of extended capability binding space IDs is discussed in
section 3.2.5.3 below.
3.2.5.1.1.2 Extended Capability Length
CCSDS CONCEPT PAPER
Page 5
CCSDS CONCEPT PAPER
The extended capability length field specifies the length of the extended
capability, exclusive of the octets containing the extended capability type
and length, in 16-bit words. Thus in Figure 3-3 an extended capability
length of 0x0 would indicate that only octets 1 and 2 in the figure were
present, a value of 0x1 would indicate a total length of four octets (octets
1 and 2 in Figure 3-3 plus two additional octets of extended capability
data). A value of 0x2 would indicate a total length of six octets, etc.
NOTE – The minimum length of an extended capability is 2 octets (the octet
containing the binding space identifier and the octet whose first 4
bits contain the length). The last four bits of the second octet are
the first four bits of the extended capability data, and are always
present, even if unused by the particular capability.
3.2.5.1.2 Support for Multiple Extended Capability Binding Spaces
More than one extended capability binding space identifier can be indicated
under a single extended SCPS Capabilities option, as shown in Figure 3-4.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+-----------------------------------------------+
|
SCPS Capabilities (20)
| octet 1
+-----------------------------------------------+
|
Length (!=4)
| octet 2
+-----------------------------------------------+
|
Extended Capability Binding Space ID1
| octet 3
+-----------------------------------------------+
| Extended cap. len1
|
Extended
| octet 4
+-----------------------+
capability
+
|
data1
| variable
+-----------------------------------------------+
|
Extended Capability Binding Space ID2
| octet n
+-----------------------------------------------+
| Extended cap. len2
|
Extended
| octet n+1
+-----------------------+
capability
+
|
data2
| variable
+-----------------------------------------------+
Figure 3-4: A single extended SCPS
capabilities option with multiple extended
capability binding spaces.
3.2.5.1.3 Alternate Support for Multiple Extended Capability Binding Spaces
Although it is less bit-efficient than the method described in 3.2.5.1.2,
multiple extended capabilities can also be signaled with additional SCPS
Capabilities options as shown in Figure 3-5.
CCSDS CONCEPT PAPER
Page 6
CCSDS CONCEPT PAPER
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+-----------------------------------------------+
|
SCPS Capabilities (20)
| octet 1
+-----------------------------------------------+
|
Length (!=4)
| octet 2
+-----------------------------------------------+
|
Extended Capability Binding Space ID1
| octet 3
+-----------------------------------------------+
| Extended cap. len1
|
Extended
| octet 4
+-----------------------+
capability
+
|
data1
| variable
+-----------------------------------------------+
|
SCPS Capabilities (20)
| octet n
+-----------------------------------------------+
|
Extended Capability Binding Space ID2
| octet n+1
+-----------------------------------------------+
| Extended cap. len2
|
Extended
| octet n+2
+-----------------------+
capability
+
|
data2
| variable
+-----------------------------------------------+
Figure 3-5: Using multiple SCPS Capabilities
options to express multiple extended capabilities.
3.2.5.1.4 Extending the Extended Capability Binding Identifier Space
An extended capability binding space identifier value of 0xFF (255d) is used
to extend the extended capability binding space from 255 to 511 values. A
value of 255d in the extended capabilities binding space identifier field
indicates that the actual extended capability binding space identifier is
calculated by adding 256d to the value of the octet following the octet
containing the extended capability length (octet 5 in Figure 3-6 below). If
octet 5 in Figure 3-6 were itself 0xFF (255d), the extended capability
binding space identifier would be 512 plus the value of the octet following
octet 5.
NOTE – Using this extension method, the position of the extended capability
length field is fixed relative to the start of the extended capability
binding space identifier, regardless of the number of bytes needed to
express the extended capability binding space identifier.
CCSDS CONCEPT PAPER
Page 7
CCSDS CONCEPT PAPER
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+-----------------------------------------------+
|
SCPS Capabilities (20)
|
+-----------------------------------------------+
|
Length (!=4)
|
+-----------------------------------------------+
| Extended Capability Binding Space Esc (0xFF) |
+-----------------------------------------------+
| Extended cap. len
|
Reserved
|
+-----------------------+-----------------------+
| Extended Capability Binding Space ID'
|
+-----------------------------------------------+
| Extended Capability Data
|
+-----------------------------------------------+
octet 1
octet 2
octet 3
octet 4
octet 5
variable (defined by
extended cap. Length
field).
Figure 3-6: An extended SCPS-TP capability
specified by a binding space identifier in
the 256-511 range.
If extended capability binding space extensions are in use (i.e. octet 3 of
figure 3-6 is 0xFF) then the 4 bits following the extended capability length
are set to zero on transmission and must be ignored on receipt.
3.2.5.2 Meanings of Specific Extended Capability Binding Space Identifiers
3.2.5.2.1 Processing Unrecognized Extended Capability Binding Spaces
As with TCP options, implementations must ignore extended capability binding
spaces that they do not understand. In these cases the implementations can
read the extended capability length field and skip over the unknown data to
continue processing the rest of the extended capabilities (if any).
NOTE – Extended capabilities that require negotiation (presumably most)
should be handled similarly to other TCP options. That is, if the
sender of the SYN signals that it wants to use extended capability X,
presumably the sender of the SYN-ACK will accept/reject the use of
that capability via an appropriate option in the SYN-ACK. As with
other TCP options, failure to explicitly accept an extended option
should be treated as a reject, so that the correct action is taken in
the case that the receiver simply didn't parse the extended
capability.
3.2.5.2.2 Standard Extended Capabilities Binding Space Identifiers
Values 0x00 through 0x0F for the extended capability binding space identifier
are reserved for standards use.
3.2.5.2.3 Experimental Extended Capabilities Binding Space ID
Extended capability binding space identifier 0xFE (254d) is reserved for
experimentation. Implementations using this experimental extended capability
binding space MUST take precautions to ensure that they are interpreting the
extended capability data correctly.
3.2.5.3 Assignment of Extended Capability Binding Space Identifiers
CCSDS CONCEPT PAPER
Page 8
CCSDS CONCEPT PAPER
CCSDS will assign extended capability binding space identifiers to interested
parties. These parties may be individual vendors of SCPS-TP products, or
communities of interest that want to jointly define a set of extended
capabilities for a particular environment.
[Insert new line in table C2.5.1 (Frame Structure – Uncompressed SCPS-TP TCP
Headers) immediately after the 'scps' item.]
+-------------------------------------------------------------+
| scpsext | Extended SCPS Capabilities | SCPS TP 3.2.5 |
M |
+-------------------------------------------------------------+
Additional Implications
The PICS table C2.2 in the SCPS-TP specification states that compliant implementations must implement the
Connection Establishment protocol feature, as described in RFC 793: 3.4 and SCPS-TP: 3.2 The proposed
modification becomes part of section 3.2 of the SCPS-TP spec, and therefore support for processing extended SCPS
capabilities becomes mandatory. Note that the proposed section 3.2.5.2.1 states that while a conformant
implementation must be able to ignore extended capabilities options that it does not understand, it is not required to
understand any. Thus an implementation that simply ignored all but the first SCPS Capabilities Option (and thus
ignored all extended capabilities) would be compliant.
Acknowledgements
This document draws heavily from discussions on the CCSDS SIS_SCPS-INTEREST mailing list, including but not
limited to postings by Patrick Feighery, Jerry Toporek, Eric Travis, and Charlie Younghusband.
References
[1] CCSDS 714.0-B-1. Space Communications Protocol Specification (SCPS)—Transport Protocol (SCPS-TP).
Blue Book. Issue 1. May 1999.
[2] J. Postel. Transmission Control Protocol. STD 7, September 1981. [RFC 793]
[3] "Data Processing - Open Systems Interconnection - Basic Reference Model", ISO/TC97/SC16/DIS7498
[4] Space Communications Protocol Specification (SCPS)—Network Protocol (SCPS-NP). Recommendation for
Space Data System Standards, CCSDS 713.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May 1999.
[5] Space Communications Protocol Specification (SCPS)—Security Protocol (SCPS-SP). Recommendation for
Space Data System Standards, CCSDS 713.5-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May 1999.
[6] Space Communications Protocol Specification (SCPS)—File Protocol (SCPS-FP). Recommendation for Space
Data System Standards, CCSDS 717.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May 1999.
[7] J. Border et. al. Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations. RFC 3135,
June 2001
CCSDS CONCEPT PAPER
Page 9