View
130
Download
0
Category
Tags:
Preview:
Citation preview
Seminar Report SPCS
INTRODUCTION
Like in most other areas, space research is also moving into large-scale
simulations using powerful computers. In fact, given the high cost, and often the
impracticability of conducting live experiments, space research has moved into
computer-based simulation long before most other streams.
This idea of taking the Internet to the space comes from the need for a low cost,
high reliability inter-planetary network. When countries started sending probes into
space, each used a unique set of protocols to communicate with earth. This was done
using Deep Space Network (DSN). Since communication was done with common
ground station, need for a common protocol increased with time. Taking the Internet to
space is the offshoot of this need for standardization. The Inter-Planetary Network
(IPN), a part of Jet Propulsion Laboratory (JPL), is managing this program.
Satellite images of earth have been easily and commercially available for
sometime now. These images are archived and distributed in various formats. Satellite
images use file formats that can save additional information used for computation.
Each satellite used customized systems for communication. For the sake of
interpretability with other systems, a set of protocols were designed, specified and
implemented. These protocols are currently being tested and they are called Space
Communications Protocols Standards (SCPS). These are the protocols used for space
communication.
www.seminarsonly.com 1
SCPS Seminar Report 2009
SHIFTING INTERNET TO SPACE
Earlier, satellites used customized system for communication using DSN.
With cooperation among nations and agencies, interpretability becomes
important.
NASA, US Defense department and National Security Agency of the US, jointly
designed, specified, implemented and are testing a set of protocols called Space
Communication Protocols Standards (SCPS).
NEED FOR A STANDARD PROTOCOL
There were problems in integrating the networks with DSN. The reasons which
caused the evolution of standard protocol are:
1. Probes of each country used unique set of protocol. Since the probes
communicated with same ground-station, need for a common protocol increased.
2. Cooperation among agencies and countries is increasing. But since each country
used different standards, this made the problem worse.
3. Need for a low-cost, high-reliability inter-planetary network.
4. The existing Internet protocols were not sufficient for the Space communication.
The error rate and round trip delay were the main factors.
www.seminarsonly.com 2
SCPS Seminar Report 2009
WHY NOT TCP/IP?
When a common standard was required for space communication, the first plan
was to use the existing TCP/IP stack protocol. But it was not practical.
A key limitation with TCP in high bit error networks is the lack of error
correction capabilities. Since TCP cannot correct bit errors, if even a single bit within a
packet is corrupted in transit, the receiver will discard the entire packet. This turns bit
errors into packet loss.
In addition, TCP can recover from the loss of only one packet per round trip. If
the network’s round-trip time is 500 milliseconds, then TCP can tolerate only one
packet loss per 500 milliseconds. To illustrate the implication of this limitation,
consider what happens if this network has a bit error rate of 10-5: TCP can send data at a
maximum rate of 200 kbps, no matter how fast the physical network is!
Another limitation of TCP is the strength of its data corruption protection. TCP
uses a relatively weak checksum scheme to detect bit errors in each packet. The
approach fails to detect bit errors relatively often at high bit error rates, allowing
corrupted data to be delivered to the application undetected.It has been calculated that
Window Based based TCP is not suitable for RTT = 40 min 20B/s throughput on 1Mb/s
link.
www.seminarsonly.com 3
SCPS Seminar Report 2009
SPACE COMMUNICATION PROTOCOL STANDARDS
The goal of the Space Communications Protocol Standards (SCPS) project is to
provide a suite of standard data handling protocols which (from a user viewpoint) make
a remote space vehicle appear to be just another "node on the Internet".
The SCPS protocols include:
A file handling protocol (the SCPS File Protocol, or SCPS-FP), optimized
towards the up-loading of spacecraft commands and software, and the downloading of
collections of telemetry data. The SCPS-FP is based on the well-known Internet File
Transfer Protocol (FTP).
An underlying retransmission control protocol (the SCPS Transport Protocol, or
SCPS-TP), optimized to provide reliable end-to-end delivery of spacecraft command
and telemetry messages between computers that are communicating over a network
containing one or more potentially unreliable space data transmission paths. The SCPS-
TP is based on the well-known Internet Transmission Control Protocol (TCP). Note that
the SCPS-TP extensions to TCP will solve similar problems in other environments, such
as those of the mobile/wireless and tactical communications communities.
A data protection mechanism (the SCPS Security Protocol, or SCPS-SP) that
provides the end-to-end security and integrity of such message exchange. The SCPS-SP
is derived from the Secure Data Network (SDNS) "SP3" protocol, the ISO Network
Layer Security Protocol (NLSP), the Integrated Network Layer Security Protocol (I-
NLSP), and the Internet Engineering Task Force's (IETF) Internet Protocol Security
(IPSEC) Encapsulating Security Payload (ESP) and Authentication Header (AH)
protocols.
A networking protocol (the SCPS Network Protocol, or SCPS-NP) that supports
both connectionless and connection-oriented routing of these messages through
networks containing space or other wireless data links. The SCPS-NP is based on the
www.seminarsonly.com 4
SCPS Seminar Report 2009
well-known Internet Protocol (IP), with modifications to support new space routing
needs and increased communications efficiency.
Fig 1: Layer Structure of SCPS
The Space Communications Protocol Standards (SCPS) exist as full ISO
standards, final Recommendations of the international Consultative Committee for
Space Data Systems. Space Communication Protocol is not a single protocol. But it is a
collection of protocols.
The various phases in the development of these standards are described below.
SCPS Phase 1 1993-1994-Exploration & Investigation
The various applications and their requirements were studied. These applications
included
Ballistic Missile Defense/ Brilliant eyes
Global positioning system
Defense meteorological Satellite program
www.seminarsonly.com 5
SCPS– File Protocol
SCPS-Transport Protocol
SCPS – Security Protocol
SCPS-Network Protocol
SCPS Seminar Report 2009
The capabilities of the protocols were also studied.
SCPS Phase 2 1995-1997-Development
The specifications of the protocols were developed. Then came the
implementation. After the implementation it was tested on the various application
scenarios.
SCPS Phase 3 1998-Deployment of the protocol
In 1998 the Space Communication Protocol was finalized and deployed in
various applications.
SCPS is not entirely new set of protocols. It is an extension of the existing
protocol to satisfy the requirements of the medium. This means that SCPS can easily
adopt where the TCP/IP is used.
The SCPS follows the OSI stack model. The major layer functions are in the
Transport and Network layers. It introduces another layer called SCPS Security
Protocol. This layer is introduced to provide protection of data and various security
services.
The application layer protocol SCPS FTP is used for all application protocols.
All the protocols, except SCPS Security Protocol are extensions of their TCP/IP
versions. The SCPS SP can be used with the existing TCP/IP.
Provide Internet access for future NASA Enterprise satellite and space
platforms,
Provide seamless interoperability between NASA mission networks and
terrestrial communications networks.
www.seminarsonly.com 6
SCPS Seminar Report 2009
SCPS – FILE PROTOCOL
The extensions to FTP and its augmentations as contained in Internet Standards
are necessitated by technical requirements for transfers of and operations on files and
analogous delimited data sets in the space communications environment. These
technical requirements include
transfers of command and data files to spacecraft;
transfers of application software to spacecraft;
transfers of science or mission data to ground without special level-zero
processing;
limited management of files onboard spacecraft (delete, rename, and directory
services);
automatic restart of transfers after an interruption;
reading of portions of files resident on board spacecraft; and
Updates/changes to files on board spacecraft.
The SCPS-TP protocol is characterized by a command/reply dialog on a stream
connection. The client Protocol Interpreter (PI) accepts input from the user, translates
user commands to server commands, and issues the server commands on the control
connection. The server PI parses those commands, looks up commands in a table, and
transfers control to the routine associated with the command. This specification defines
procedures for each PI to execute upon success or failure of commands. When a
command has been parsed and processed, either successfully or unsuccessfully, the
server issues a reply message on the control connection. Commands and replies are
short ASCII strings terminated with the ASCII control sequence <CRLF>.
SCPS-FP is based on Internet FTP. SCPS-FP maintains interoperability with
Internet FTP on the control connection. This Recommendation is designed to be
scaleable to fit onto the most resource-constrained service and yet expandable to full
Internet compatibility according to mission requirements.
www.seminarsonly.com 7
SCPS Seminar Report 2009
SCPS-FP is a profile of Internet FTP that adds capabilities to the Internet
standard as follows:
automatic restart of a failed transfer;
read, write, add, change, and delete individual file records;
interrupt (pause) a file transfer so that it can be restarted later from the interrupt
point;
suppress reply text to improve bandwidth efficiency;
assure file and record integrity in the case of abnormal connection loss.
These capabilities are designed to yield efficient transfer of file-oriented data
sets across the space link. The ASCII data type is optional for SCPS-FP file transfer
operations; it does not apply to SCPS-FP record operations. The ASCII type is not the
SCPS-FP default The IMAGE data type is the default for SCPS-FP and must be
supported by all SCPS-FP implementations.
The SCPS-FP user-PI must initiate the use of non-default ports because of the
need for SCPS-TP to hold the connection record for a timeout period to guarantee
reliable communication. If the structure is a file structure, the EOF is indicated by the
sending host’s closing of the data connection, in which case all bytes are data bytes.If
the structure is a record structure, indicating the file consists of contiguous CCSDS
Packets, the following provisions are required to enable use of FP restart and record
read/update capabilities.
ERROR RECOVERY AND RESTART
When a system failure is detected, the receiving Data Transfer Process (DTP)
shall determine the restart marker by querying the file system for the current size of the
file. Restarts markers shall not be imbedded in the data in stream mode.There are three
cases in which SCPS-FP restart may be accomplished in stream mode:
Eg. user-to-server transfer (e.g., STOR):
www.seminarsonly.com 8
SCPS Seminar Report 2009
1) the user-FP shall send ‘SIZE pathname’ to the receiving server-FP;
2) the server-FP shall send ‘213 pathname SIZE rrrr’ to the user-FP, where rrrr
is the size of the file (indicated by pathname) stored locally at the server;
3) to restart the transfer, the user-FP shall reposition its local file system using
restart marker rrrr and send the command ‘REST rrrr’ to the server-FP;
4) the server-FP shall save restart marker rrrr for restart;
Immediately after sending the REST command, the user-FP shall send the file
transfer command (such as RETR, STOR or LIST) that was being executed when the
system failure occurred.
Besides the automatic restart, manual restart and manual interrupt are also
possible.
DATA INTEGRITY
The various data integrity mechanisms include the following
File transfer integrity
The user-FP and server-FP shall roll back any incomplete changes made to a file
during a non-autorestart RETR or STOR operation that has terminated with errors,
thereby restoring the affected file to its pre-transfer state.
Record data integrity
The user-FP and server-FP shall roll back any incomplete changes made to a file
during a READ or UPDT operation that has terminated with errors, thereby restoring
the affected file to its pre–record operation state.
www.seminarsonly.com 9
SCPS Seminar Report 2009
To provide a secondary measure of integrity to ensure that a user does not
update the wrong file inadvertently, the user-FP and server-FP shall employ the
following CRC for the record update service to ensure the data integrity of the accessed
files.
SCPS –TRANSPORT PROTOCOL
This SCPS Recommendation is designed to support current communication
environments and those of upcoming missions. The modifications to the base protocols
are intended to address the communication environments and resource constraints that
space-based systems face.
The Technical Requirements for the Recommendation include:
support for communication with full reliability, best-effort reliability, and
minimal reliability;
efficient operation in a wide range of delay, bandwidth, and error conditions;
efficient operation in space-based processing environments;
support for precedence (priority) based handling;
support for connectionless multicasting;
support for packet-oriented applications.
The SCPS Transport Protocol (SCPS-TP) refers collectively to the protocols that
provide the full reliability, best-effort reliability, and minimal reliability services. The
full reliability service is provided by TCP. The best-effort service is provided by TCP
with minor modifications. The minimal reliability service is provided by UDP.
The SCPS-TP addresses the environmental requirements with the following
extensions:
www.seminarsonly.com 10
SCPS Seminar Report 2009
Reduces the handshaking necessary to start a TCP connection and provides
‘reliable datagram’ operation to handle command-response traffic, for very long delay
environments in which it is desirable to begin data transfer without waiting for a
connection handshake;
Window scaling - addresses communication environments that may have
more than 65k octets of data in transit at one time;
Round Trip Time Measurement -addresses environments that have high loss,
changing delays, or large amounts of data in transit at one time;
Protect Against Wrapped Sequence Numbers - addresses very long delay
environments or very high bandwidth missions;
Selective negative acknowledgment - addresses high loss environments;
Record Boundary Indication—the ability to mark and reliably carry end-of-
record indications for packet-oriented applications;
Best Effort Communication—the ability for an application to select correct,
in-sequence, but possibly incomplete delivery of data;
Header compression - addresses low-bandwidth environments;
Low-loss congestion control or optional non-use of congestion control;
Retransmission strategies for space environments that accommodate loss due
to data corruption, link outages, and congestion.
SCPS-TP is complementary to FEC—it recovers quickly when packets get lost
in transit. SCPS-TP can recover from the loss of any number of packets in each round-
trip time (subject only to bandwidth limitations). This is a substantial improvement over
the loss of only one packet per round-trip time that TCP can tolerate.
www.seminarsonly.com 11
SCPS Seminar Report 2009
SCPS – SECURITY PROTOCOL
The SCPS Security Protocol layer comes in between the SCPS Transport layer
and the Network Protocol layer. It is based on SP3/NLSP reduced protocol overhead. It
provides optional end to end protection of transmitted data. It prevents unauthorized
access, interception, modification, spoofing. The SCPS-SP provides the following
connectionless security services on an end-to-end basis (where the service endpoints are
defined by the implementer):
1. confidentiality
2. integrity
3. authentication
4. a combination of all of the above
The basic mode of operation of SCPS-SP is encapsulation of a Transport
Protocol Data Unit (T-PDU) into a Security Protocol Data Unit (S-PDU). The T-PDUs
may be enciphered to provide confidentiality, may have an Integrity Check Value (ICV)
calculated and appended to provide integrity (non-forge ability) of the T-PDU, or may
both be enciphered and have an ICV applied. Explicit authentication in SCPS-SP
requires the use of either the integrity and/or the confidentiality services. Implicit
authentication is provided as a by-product of key management. In the case where both
integrity and confidentiality are required, integrity is applied first, and then
confidentiality.
The concepts for this specification are drawn from a number of sources such as
Secure Data Network Systems (SDNS) Security Protocol 3 (SP3), ISO Network Layer
Security Protocol (NLSP), Internet Protocol Version 6 Encapsulating Security Payload
and Integrated Network Layer Security Protocol. SCPS-SP’s major point of departure
from these other security protocols is the insistence on near-optimal bit efficiency,
which was not a design requirement for the other protocols. The SCPS-SP has been
refined to ensure minimal transmitted bit overhead.
www.seminarsonly.com 12
SCPS Seminar Report 2009
The SCPS-SP assumes that it resides on top of a connectionless network service,
known throughout this specification as the Underlying Network (UN). An example of
such a protocol is the SCPS Network Protocol (SCPS-NP)
Processing within SCPS-SP is security-critical. Therefore, the Security Protocol
is the only portion of the SCPS suite that, from a security perspective, must be trusted to
perform its security functions correctly. This is not to imply that the other protocol
layers do not have to operate correctly. However, only SCPS-SP has the responsibility
to perform security-critical processing. The layers above SCPS-SP may handle
classified or proprietary data, but it is SCPS-SP’s job to ensure that the data is afforded
the requisite security protections before forwarding the data to the lower layers and onto
the network. Likewise, a protocol layer below SCPS-SP may handle sensitive data, but
only SCPS-SP has the responsibility for ensuring that the required security services are
applied.
The SCPS-SP employs both a clear and a protected header. The clear header,
which must remain un-enciphered, provides a small amount of processing information
to the security protocol. The protected header contains additional information which
may be enciphered (along with the user data), depending upon the system security
policy being enforced by the Security Protocol as well as the user’s security services
request. The security protection that the SCPS-SP attempts to provide is derived from a
combination of the security services requested by the SCPS-SP user and the protection
requirements imposed by the security domain administrator through the enforcement of
the local security policy.
Although the degree of protection afforded by the security mechanisms depends
on the use of specific cryptographic or digital signature secure hash techniques, correct
operation of this protocol is not dependent on the choice of any particular encipherment,
decipherment, or integrity algorithm. The choice of algorithms is left as a local security
matter.
In order for SCPS-SP to provide end-to-end protection services and still operate
across security-unaware networks, the addressing information in the UN layer must
www.seminarsonly.com 13
SCPS Seminar Report 2009
remain un-enciphered to allow PDU routing. Because the address information is not
enciphered, SCPS-SP does not provide protection against traffic analysis, nor does it
provide protection against jamming or low-probability-of-intercept (LPI). Traffic
analysis protection must be provided at the link layer; jamming and LPI protection must
be provided at the physical layer. SCPS-SP also does not provide protection against
replay attacks. It is assumed that either the encryption algorithm or a sequence number
provided by an upper-layer transport protocol, such as SCPS-TP (reference [B13]),
would protect against replay attacks.
The choice of a specific security policy, and therefore the protection that will be
achieved by the SCPS-SP user, is a local matter for determination by the security
domain administration.
SCPS-SP TYPES OF SECURITY SERVICES
SCPS-SP shall support the following types of Security Services:
1) integrity services;
2) confidentiality services;
3) Authentication services.
Integrity services
When integrity services are requested by a SCPS-SP user (e.g., an upper-layer
protocol) or are required as a default action to enforce an administrative security policy,
a) SCPS-SP shall calculate an ICV over the SCPS-SP clear and
protected headers, the user data, which includes any upper-layer protocol headers,
and potentially a secret data stream (e.g., a ‘secret key’);
b) the size of the ICV shall be established in the SA database
(integ_alg_ICV_length); The SCPS-SP operates with the assumption that there
exists a Security Association(SA) database that contains pertinent security
information, for use between the communicating entities, such as the encipher key,
www.seminarsonly.com 14
SCPS Seminar Report 2009
the key expiration, the key length, the Initialization Vector (IV) length, the
encipherment algorithm, the integrity algorithm, and the ICV length. Example
Security Association parameters are illustrated in section 5 (Security Association
Attributes) of this Recommendation.
c) the specific manner in which the ICV is calculated shall be
determined by the integrity algorithm as identified by integ_alg_id in the SA
database.
Confidentiality services
When confidentiality services are requested by a SCPS-SP user or are required
as a default action to enforce an administrative security policy, the SCPS-SP shall use
the encipherment key (cipher_key) in conjunction with the encipherment algorithm
(conf_alg_id) and algorithm mode (conf_alg_mode_id) specified in the SA database to
encipher the SCPS-SP protected header and the user data.
Authentication services
When authentication services are requested by a SCPS-SP user,
a) the source and destination network addresses shall be encapsulated
into the SCPS-SP protected header, and then either integrity and/or
confidentiality services shall be applied, as above;
b) Authentication must be requested with either integrity or
confidentiality, or both; it cannot be provided without one or both of the other
services.
SCPS-SP PROTOCOL DATA UNIT
The SCPS-SP Protocol Data Unit (PDU) shall consist of the following parts in
the following sequence:
www.seminarsonly.com 15
SCPS Seminar Report 2009
Clear Header (mandatory)
Protected Header (mandatory)
User Data (optional)
Integrity Check Value (optional)
The SCPS-SP PDU is illustrated in figure
Fig 2: SCPS-SP Protocol Data Unit
SCPS-SP clear header
The SCPS-SP Clear Header shall consist of the following fields in the following
sequence:
Internet Protocol Number (mandatory)
initialization vector (optional)
The SCPS-SP Clear Header is illustrated in figure
Fig 3: Clear header format
SCPS-SP Protected header
The SCPS-SP protected header formats are the following
www.seminarsonly.com
CLEAR
HDRPROTECTED
HDR
USER DATA ICV
Internet Protocol No
Initialization vector
16
SCPS Seminar Report 2009
The SCPS-SP Protected Header shall consist of the following fields in the
following sequence:
Protected Header Option Flags (mandatory)
Security Classification Label (optional)
Encapsulated Address (optional)
Cipher Pad (optional)
The SCPS-SP Protected Header is illustrated in figure 3-3.
Fig 4: Protected header format
SCPS – NETWORK PROTOCOL
The Technical Requirements for the Recommendation include:
support for connectionless and managed-connection operation;
efficient operation in constrained bandwidth conditions;
support for precedence (priority) based handling;
support for datagram lifetime control;
support for multiple routing options;
signaling of information pertinent to upper-layer protocol processing.
The SCPS Network Protocol (SCPS-NP) uses a technique called ‘capability-
driven header construction’ as a means to control bit overhead. Capability-driven
www.seminarsonly.com
Protected
Header
Option
Security
Classification
Label
Encapsulated
Address
Cipher pad
17
SCPS Seminar Report 2009
header construction simply means that the format of the SCPS-NP header is based
(exclusively) on the protocol capabilities required for the communication of the
particular datagram in question. That is, a datagram carries those header elements that
are required to provide service properly to the datagram, but no others.
The capabilities required to support a datagram are derived from three sources:
the protocol itself, the operating environment, and the network service user. Some
capabilities are required to support a particular protocol version. An example of this is
the capability of datagram length delimiting. Other capabilities are required to address
particular network environmental conditions. An example of an environmentally
required capability is header error protection. The third source of capability
requirements is the network service user. An example of a user-required capability is
precedence (priority).
The capability requirements from these three sources are used to select the set of
header elements necessary to provide the required services in the transmission of the
datagram. One key header element is a variable-length control field that identifies the
remaining header elements that are included in the datagram. This control field is
present in all versions of the SCPS-NP, and is the last header element before those
header elements specified in the control field.
In addition to user data transfer, this Recommendation specifies the means for
exchanging network-layer control information through the SCPS Network, and for
selectively passing that information to SCPS Network users.
ADDRESS FAMILIES
A Network Address (N-Address) in the SCPS Network shall meet the structural
requirements of one of three address families:
www.seminarsonly.com 18
SCPS Seminar Report 2009
a) SCPS Address Family.
The SCPS address family contains both End System Addresses (identifying a
single end system) and Path Addresses (identifying a pair of communication systems).
SCPS-family N-Addresses are structured as follows:
1) N-Addresses in the SCPS family are four octets in length and are represented
in this text as four eight-bit quantities separated by periods, e.g., w.x.y.z, where the
range of each of the alphabetic characters is from 0 to 255 decimal. The form w.x.y.z is
the extended form of a SCPS address. The Basic form of the SCPS address (z) may be
used if it can be guaranteed (through network configuration) that the w.x.y portion of
the address will be unambiguous through the life of the datagram.
2) The most-significant octet (the w octet) of a SCPS-family N-Address contains
the value 10 (decimal), which is the value, reserved by the Internet Assigned Numbers
Authority (IANA) for private Internet address spaces.
3) The x and y octets are combined to form the addressing domain for various
programs; the x.y field is known as the Domain Identifier (D-ID).A single mission may
be allocated more than one D-ID for its needs.
4) The z octet is administered by the program to which the D-ID is allocated and is
subdivided as follows:
bits 0-6 form a field, which contains either an End System Identifier (ES-
ID) or a Path Identifier (P-ID) in the range 0 to 126 (the value of 127 is
reserved for use in conjunction with the Multicast Flag to form the broadcast
address);
bit 7 is the Multicast Flag (M-Flag), which signals whether the address is
a multicast or unicast address:
o the M-Flag shall be set to ‘1’ for multicast addresses;
o the M-Flag shall be set to ‘0’ for unicast addresses.
b) Internet Protocol (IPv4) Address Family. The IP address family contains End-
System Addresses that are appropriate for routing and delivery across the Internet.
www.seminarsonly.com 19
SCPS Seminar Report 2009
c) Internet Protocol version Six (IPv6) Address Family. IPv6 format addresses
are intended for those programs that do not have significant bit-efficiency issues and
require global addressability.
SCPS – NP PACKET
The SCPS –NP Packet structure is as following
Header
The SCPS-NP header is mandatory for the SCPS-NP datagram and shall
consist of mandatory and capability-defined elements positioned contiguously. The
SCPS-NP header shall be constructed by concatenating elements that satisfy the
datagram capability requirements of the protocol, the network, and the user.
ADDRESS TYPES
The basic address types are as illustrated below
Basic End System Address:
A Basic End System Address identifies a single end system or an end-system
group. The Basic End System Address conforms to the structural rules of the SCPS
Address Family, and consists of the least-significant octet of an Extended End System
Address. Basic End System Addresses may be used in networks in which it can be
guaranteed (through network configuration) that the remaining portion of the address
will be unambiguous through the life of the datagram. (Note that Basic End System
Addresses are NOT parameters to the Unit Data service primitives.)
Basic Path Address:
A Basic Path Address identifies a managed virtual connection between two or
more end systems. The Path Address conforms to the structural rules of the SCPS
www.seminarsonly.com 20
SCPS Seminar Report 2009
Address Family and consists of the least-significant octet of an Extended Path Address.
Basic Path Addresses may be used in networks in which it can be guaranteed (through
network configuration) that the remaining portion of the address will be unambiguous
through the life of the datagram. (Note that Basic Path Addresses are NOT parameters
to the Unit Data service primitives.)
Extended End System Address:
The Extended End System Address identifies a single end system or an end-
system group. The Extended End System Address conforms to the structural rules of
either the SCPS Address Family or the IP Address Family. Extended End System
Addresses may be parameters to the primitives of the Unit Data service.
Extended Path Address:
The Extended Path Address identifies a managed virtual connection between
two or more end systems. The Path Address conforms to the structural rules of the
SCPS Address Family. (Note that Extended Path Addresses are NOT parameters to the
Unit Data service primitives.)
ROUTING
Routing tables shall be kept for
End System Addresses;
Path Addresses;
Multicast End System Addresses
For each type of address the corresponding route table is used for routing.
Flood routing
www.seminarsonly.com 21
SCPS Seminar Report 2009
Flood routing uses datagram replication to send many copies of a datagram
through the network to one or more final destinations. The flood routing technique used
in the SCPS Network uses a ‘serial number’ created from the source address and the
source timestamp to identify and suppress duplicates.
APPLICATION SCENARIOS
The various application scenarios include mobile tactical network, sensor webs,
intelligent highways etc.The details of various application scenarios are
MOBILE TACTICAL NETWORK
Battlefield and civil emergency operations are becoming increasingly dependent
on the use of digital communications among untethered nodes. Some communication
resources (e.g. satellites, helicopters, and fixed-wing aircraft) are highly mobile and
hence intermittently - although perhaps predictably - available. Connectivity in these
networks may become episodic and sometimes unidirectional because of distance,
terrain or policy (radio silence), so network partitioning must be accommodated.
Additionally, delays within connected portions of the network may be extremely
variable due to the nature of the communication media.
SENSOR WEBS
These types of networks may comprise a large collection of primitive sensor
devices interspersed with a smaller collection of more capable nodes, all interconnected
by some form of wireless communications. Complicated by node mobility and
operation in harsh environments with extremely limited power, such devices benefit
directly from the ability to offload their end-to-end communications to more capable
custodians and thus extend their operational lifetime by allowing their derived
information to only be harvested occasionally.
INTELLIGENT HIGHWAYS
www.seminarsonly.com 22
SCPS Seminar Report 2009
As vehicles become more complex, they increasingly contain multi-node
networks. Services such as “OnStar” provide very limited real time satellite
connectivity between vehicles and monitoring sites. Incorporation of DTN protocols
into vehicles and into communication nodes placed at intervals along highways (and
eventually streets) can reduce the required infrastructure cost by taking advantage of
delay tolerance and the ability to route via other vehicles to reach fixed infrastructure.
Enhanced driver services may be enabled, such as en-route traffic congestion avoidance,
alternate route calculation, point-of-interest location, vehicle health and safety
monitoring and breakdown assistance.
THE EMERGING INTERNET
With the number and diversity of "Internet capable" devices relentlessly
increasing, we are witnessing a growing heterogeneity among the stub networks that
connect them to the Internet backbone. These differences are manifesting themselves
not only in the interconnection technologies (optical, cable, wireless) but also in
capabilities of the devices themselves (constrained power, weight and volume) and their
associated communications policies (security, quality of service, usage charges). The
result of this Internet evolution is that user devices are becoming increasingly mobile,
and the end-to-end data path is traveling across a wider variety of environments.
Mobility coupled with power, weight, volume constraints suggests that end-to-end
communications dialogs across time disjoint connectivity are going to be highly likely,
if not inevitable.
www.seminarsonly.com 23
SCPS Seminar Report 2009
CONCLUSION
The SCPS are designed to meet these demands by increasing standardization and
interoperability both within and among CCSDS Agencies and other developers and
operators of spacecraft. SCPS augments these protocols by providing reliable stream or
file transfer over CCSDS frames at the link layer and dynamic networking for those
missions that need it. SCPS is aimed at a broad range of space missions including:
Support for spacecraft in low-earth and geosynchronous orbits, as well as lunar
and planetary spacecraft. The primary emphasis has been on support of missions at
lunar distances or closer. SCPS network and security protocols are relatively immune to
communications delay, and thus can support deep-space missions today.
Each mission can choose the appropriate layers and the appropriate options
within those layers. The individual protocols provide flexibility and optional features
that allow designers to tailor a communications protocol to meet the requirements and
constraints of a mission, without extensive software development.
SCPS has changed the face of the space communication applications. In the
future the interplanetary internet may make possible the communication between those
creatures that are believed to exist in space.
www.seminarsonly.com 24
SCPS Seminar Report 2009
REFERENCES
www.scps.org
www.skipware.com
www.ipnsig.org
spacecom.grc.nasa.gov
www.seminarsonly.com 25
SCPS Seminar Report 2009
ABSTRACT
The goal of the Space Communications Protocol Standards (SCPS) project is to
provide a suite of standard data handling protocols which (from a user viewpoint) make
a remote space vehicle appear to be just another "node on the Internet". A file handling
protocol (the SCPS File Protocol, or SCPS-FP), optimized towards the up-loading of
spacecraft commands and software, and the downloading of collections of telemetry
data. An underlying retransmission control protocol (the SCPS Transport Protocol, or
SCPS-TP), optimized to provide reliable end-to-end delivery of spacecraft command
and telemetry messages between computers that are communicating over a network
containing one or more potentially unreliable space data transmission paths. A data
protection mechanism (the SCPS Security Protocol, or SCPS-SP) that provides the end-
to-end security and integrity of such message exchange. A networking protocol (the
SCPS Network Protocol, or SCPS-NP) that supports both connectionless and
connection-oriented routing of these messages through networks containing space or
other wireless data links.
www.seminarsonly.com 26
SCPS Seminar Report 2009
CONTENTS
Sl.No. TOPIC Pg.No.
1. INTRODUCTION………………………………………………01
2. SHIFTING INTERNET TO SPACE………………………..…..02
3. NEED FOR A STANDARD PROTOCOL……………...……...02
4. WHY NOT TCP/IP...………………………………………...…03
5. SPACE COMMUNICATION PROTOCOL STANDARDS…..04
6. SCPS-FILE PROTOCOL…………..…………………………..07
6.1 Error Recovery & Restart………….…...…………...….08
6.2 Data Integrity………………………….……..………....09
7. SCPS-TRANSPORT PROTOCOL ……………………...…….10
8. SCPS-SECURITY PROTOCOL…………………………….....12
8.1 SCPS-SP Types of security services ………………...…14
8.2 SCPS-SP Protocol data unit………………………….....15
9. SCPS-NETWORK PROTOCOL………………………...……..17
9.1 Address families………………………………...………18
9.2 SCPS-NP packet……………………………………...…20
9.3 Routing…………………………………………….....…21
10. APPLICATION SCENARIOS……………………………..…..22
10.1 Mobile tactical network…………………………….…..22
10.2 Sensor Webs……………………………………………22
10.3 Intelligent highways……………………………………22
10.4 Emerging internet………………………………...….…23
11. CONCLUSION………………………………………………...24
12. REFERENCES…………………………………………..…….25
www.seminarsonly.com 27
Recommended