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

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

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 networks 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

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 SCPSTP 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 (INLSP), and the Internet Engineering Task Force's (IETF) Internet Protocol Security (IPSEC) Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols. www.seminarsonly.com 4

SCPS

Seminar Report 2009

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.

SCPS File Protocol

SCPS-Transport Protocol

SCPS Security Protocol

SCPS-Network Protocol

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

www.seminarsonly.com

SCPS

Seminar Report 2009

The various applications and their requirements were studied. These applications included Ballistic Missile Defense/ Brilliant eyes Global positioning system Defense meteorological Satellite program

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.

www.seminarsonly.com

SCPS

Seminar Report 2009

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. 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. These

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

www.seminarsonly.com

SCPS

Seminar Report 2009

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 hosts 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.

www.seminarsonly.com

SCPS

Seminar Report 2009

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

www.seminarsonly.com

SCPS

Seminar Report 2009

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 prerecord 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;

www.seminarsonly.com

10

SCPS

Seminar Report 2009

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 Indicationthe ability to mark and reliably carry end-ofrecord indications for packet-oriented applications; Best Effort Communicationthe ability for an application to select correct, in-sequence, but possibly incomplete delivery of data; Header compression - addresses low-bandwidth environments;

www.seminarsonly.com

11

SCPS

Seminar Report 2009

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 FECit recovers quickly when packets get lost

in transit. SCPS-TP can recover from the loss of any number of packets in each roundtrip 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. 2. 3. 4. confidentiality integrity authentication 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

www.seminarsonly.com

12

SCPS

Seminar Report 2009

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-SPs 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-SPs 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.

www.seminarsonly.com

13

SCPS

Seminar Report 2009

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 users 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

www.seminarsonly.com

14

SCPS

Seminar Report 2009

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) 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 www.seminarsonly.com 15 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

SCPS

Seminar Report 2009

(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 of the other services. SCPS-SP PROTOCOL DATA UNIT with either integrity or confidentiality, or both; it cannot be provided without one or both

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

CLEAR HDR

PROTECTED HDR

USER DATA

ICV

Fig 2: SCPS-SP Protocol Data Unit

www.seminarsonly.com

16

SCPS

Seminar Report 2009

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 Internet Protocol No Initialization vector

Fig 3: Clear header format SCPS-SP Protected header

The SCPS-SP protected header formats are the following 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.

www.seminarsonly.com

17

SCPS

Seminar Report 2009

Protected Header Option

Security
Classification

Encapsulated Address Cipher pad

Label

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 capabilitydriven header construction as a means to control bit overhead. Capability-driven 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

www.seminarsonly.com

18

SCPS

Seminar Report 2009

particular network environmental conditions.

An example of an environmentally The third source of capability

required capability is header error protection. precedence (priority).

requirements is the network service user. An example of a user-required capability is

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:

www.seminarsonly.com

19

SCPS

Seminar Report 2009

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 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) c) Internet Protocol (IPv4) Address Family. The IP address family contains Internet Protocol version Six (IPv6) Address Family. IPv6 format addresses End-System Addresses that are appropriate for routing and delivery across the Internet. 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 subdivided as follows:

www.seminarsonly.com

20

SCPS

Seminar Report 2009

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:

www.seminarsonly.com

21

SCPS

Seminar Report 2009

The Extended End System Address identifies a single end system or an endsystem 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

www.seminarsonly.com

22

SCPS

Seminar Report 2009

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.

www.seminarsonly.com

23

SCPS

Seminar Report 2009

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

24

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

25

SCPS

Seminar Report 2009

REFERENCES
www.scps.org www.skipware.com www.ipnsig.org spacecom.grc.nasa.gov

www.seminarsonly.com

26

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 endto-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

27

SCPS

Seminar Report 2009

CONTENTS

Sl.No. 1. 2. 3. 4. 5. 6. 6.1 6.2 7. 8. 8.1 8.2 9. 9.1 9.2 9.3 10. 10.1 10.2 10.3 10.4

TOPIC

Pg.No.

INTRODUCTION01 SHIFTING INTERNET TO SPACE....02 NEED FOR A STANDARD PROTOCOL......02 WHY NOT TCP/IP......03 SPACE COMMUNICATION PROTOCOL STANDARDS..04 SCPS-FILE PROTOCOL....07 Error Recovery & Restart........08 Data Integrity.......09 SCPS-TRANSPORT PROTOCOL ....10 SCPS-SECURITY PROTOCOL.....12 SCPS-SP Types of security services ...14 SCPS-SP Protocol data unit.....15 SCPS-NETWORK PROTOCOL.....17 Address families...18 SCPS-NP packet...20 Routing.....21 APPLICATION SCENARIOS....22 Mobile tactical network...22 Sensor Webs22 Intelligent highways22 Emerging internet....23

www.seminarsonly.com

28

SCPS

Seminar Report 2009

11. 12.

CONCLUSION...24 REFERENCES...25

www.seminarsonly.com

29