SCPS - Report

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.



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.



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



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


SCPS– File Protocol

SCPS-Transport Protocol

SCPS – Security Protocol

SCPS-Network Protocol


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.



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.



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):



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.



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:



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.



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.



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



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,



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:



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


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


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:



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.



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



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



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



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.



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.



REFERENCES

www.scps.org

www.skipware.com

www.ipnsig.org

spacecom.grc.nasa.gov



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.



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


SCPS - Report

Documents

administrative

common protocol

detect bit

path address

remote space

basic path

extended path

data protection