ISO 15891:2000

INTERNATIONAL ISO
STANDARD 15891
First edition
2000-09-15
Space data and information transfer
systems — Protocol specification for space
communications — Network protocol
Systèmes de transfert des informations et données spatiales —
Spécification d'un protocole pour communications spatiales — Protocole du
réseau
Reference number
©
ISO 2000
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO 2000 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
Draft International Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
International Standard ISO 15891 was prepared by the Consultative Committee for Space Data Systems (CCSDS)
(as CCSDS 713.0-B-1) and was adopted (without modifications except those stated in clause 3 of this International
Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee SC 13, Space data and
information transfer systems.
INTERNATIONAL STANDARD ISO 15891:2000(E)
Space data and information transfer systems — Protocol
specification for space communications — Network protocol
1 Scope
This International Standard specifies the requirements for the services and protocols of the space communications
protocol specification (SCPS) network layer. These requirements are to allow independent implementation of this
protocol in space and ground segments of the SCPS network to interoperate.
This International Standard is applicable to any kind of space mission or infrastructure, regardless of complexity.
2 Conformance
This International Standard is applicable to all systems that claim conformance to the ISO/CCSDS SCPS network
protocol.
3 Requirements
Requirements are the technical recommendations made in the following publication (reproduced on the following
pages), which is adopted as an International Standard:
CCSDS 713.0-B-1, May 1999, Recommendation for space data system standards — Space communications
protocol specification (SCPS) — Network protocol (SCPS-NP).
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 713.0-B-1.
Pages i to v
This part is information which is relevant to the CCSDS publication only.
Page 1-6
Add the following information to the reference indicated in paragraph 1.7:
[2] Document CCSDS 301.0-B-2, April 1990, is equivalent to ISO 11104:1991.
Page B-1
Add the following information to the references indicated in annex B:
[B4] Document CCSDS 701.0-B-2, November 1992, is equivalent to ISO 13420:1997.
[B5] Document CCSDS 202.0-B-2, November 1992, is equivalent to ISO 12172:1998.
[B6] Document CCSDS 102.0-B-4, November 1995, is equivalent to ISO 13419:1997.
[B7] Document CCSDS 713.5-B-1, May 1999, is equivalent to ISO 15892:2000.
[B8] Document CCSDS 714.0-B-1, May 1999, is equivalent to ISO 15893:2000.
4 Revision of publication CCSDS 713.0-B-1
It has been agreed with the Consultative Committee for Space Data Systems that Subcommittee ISO/TC 20/SC 13
will be consulted in the event of any revision or amendment of publication CCSDS 713.0-B-1. To this end, NASA
will act as a liaison body between CCSDS and ISO.
2 © ISO 2000 – All rights reserved

RECOMMENDATION FOR SPACE
DATA SYSTEM STANDARDS
SPACE COMMUNICATIONS
PROTOCOL SPECIFICATION (SCPS)—
NETWORK PROTOCOL
(SCPS-NP)
CCSDS 713.0-B-1
BLUE BOOK
May 1999
(Blank page)
4 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
AUTHORITY
Issue: Blue Book, Issue 1
Date: May 1999
Location: Newport Beach, California, USA
This document has been approved for publication by the Management Council of the
Consultative Committee for Space Data Systems (CCSDS) and represents the consensus
technical agreement of the participating CCSDS Member Agencies. The procedure for
review and authorization of CCSDS Recommendations is detailed in reference [B1], and the
record of Agency participation in the authorization of this document can be obtained from the
CCSDS Secretariat at the address below.
This Recommendation is published and maintained by:
CCSDS Secretariat
Program Integration Division (Code MT)
National Aeronautics and Space Administration
Washington, DC 20546, USA
CCSDS 713.0-B-1 Page i May 1999
CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of member space Agencies. The Committee meets
periodically to address data systems problems that are common to all participants, and to
formulate sound technical solutions to these problems. Inasmuch as participation in the
CCSDS is completely voluntary, the results of Committee actions are termed
Recommendations and are not considered binding on any Agency.
This Recommendation is issued by, and represents the consensus of, the CCSDS Plenary
body. Agency endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever an Agency establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommendation. Establishing such a standard does not
preclude other provisions which an Agency may develop.
o Whenever an Agency establishes a CCSDS-related standard, the Agency will provide
other CCSDS member Agencies with the following information:
-- The standard itself.
-- The anticipated date of initial operational capability.
-- The anticipated duration of operational service.
o Specific service arrangements shall be made via memoranda of agreement. Neither this
Recommendation nor any ensuing standard is a substitute for a memorandum of
agreement.
No later than five years from its date of issuance, this Recommendation will be reviewed by
the CCSDS to determine whether it should: (1) remain in effect without change; (2) be
changed to reflect the impact of new technologies, new requirements, or new directions; or,
(3) be retired or canceled.
In those instances when a new version of a is issued, existing CCSDS-
Recommendation
related Agency standards and implementations are not negated or deemed to be non-CCSDS
compatible. It is the responsibility of each Agency to determine when such standards or
implementations are to be modified. Each Agency is, however, strongly encouraged to direct
planning for its new standards and implementations towards the later version of the
Recommendation.
CCSDS 713.0-B-1 Page ii May 1999
6 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
FOREWORD
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommendation is therefore subject to
CCSDS document management and change control procedures as defined in reference [B1].
Current versions of CCSDS documents are maintained at the CCSDS Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be addressed to the
CCSDS Secretariat at the address indicated on page i.
CCSDS 713.0-B-1 Page iii May 1999
CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
At time of publication, the active Member and Observer Agencies of the CCSDS were
Member Agencies
– British National Space Centre (BNSC)/United Kingdom.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– National Aeronautics and Space Administration (NASA)/USA.
– National Space Development Agency of Japan (NASDA)/Japan.
– Russian Space Agency (RSA)/Russian Federation.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– Centro Tecnico Aeroespacial (CTA)/Brazil.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Communications Research Laboratory (CRL)/Japan.
– Danish Space Research Institute (DSRI)/Denmark.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Federal Service of Scientific, Technical & Cultural Affairs (FSST&CA)/Belgium.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Industry Canada/Communications Research Centre (CRC)/Canada.
– Institute of Space and Astronautical Science (ISAS)/Japan.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Oceanic & Atmospheric Administration (NOAA)/USA.
– National Space Program Office (NSPO)/Taipei.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.
CCSDS 713.0-B-1 Page iv May 1999
8 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
DOCUMENT CONTROL
Document Title Date Status
CCSDS Space Communications May 1999 Original issue
713.0-B-1 Protocol Specification
(SCPS)—Network
Protocol (SCPS-NP)
CCSDS 713.0-B-1 Page v May 1999
CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
CONTENTS
Section Page
1 INTRODUCTION.1-1
1.1 PURPOSE .1-1
1.2 SCOPE .1-1
1.3 APPLICABILITY .1-1
1.4 RATIONALE .1-1
1.5 ORGANIZATION OF THIS RECOMMENDATION .1-1
1.6 CONVENTIONS AND DEFINITIONS .1-2
1.7 REFERENCES.1-6
2 OVERVIEW .2-1
3 PROTOCOL SPECIFICATION .3-1
3.1 ADDRESSING .3-1
3.2 SCPS NETWORK PROTOCOL SPECIFICATION.3-4
3.3 SCPS CONTROL MESSAGE PROTOCOL SPECIFICATION.3-31
4 MANAGEMENT INFORMATION BASE REQUIREMENTS.4-1
4.1 MIB REQUIREMENTS FOR THE SCPS-NP .4-1
4.2 MIB REQUIREMENTS FOR THE SCPS CONTROL
MESSAGE PROTOCOL.4-11
4.3 MIB REQUIREMENTS FOR THE SCPS ROUTING DATABASES .4-16
......................................................
ANNEX A ACRONYMS AND ABBREVIATIONS A-1
ANNEX B INFORMATIVE REFERENCES. B-1
ANNEX C PROTOCOL IMPLEMENTATION CONFORMANCE
STATEMENT PROFORMA .C-1
ANNEX D SCPS NETWORK SERVICE SPECIFICATION .D-1
Figure
3-1 SCPS-NP Datagram .3-4
3-2 Control Field Subfields .3-8
3-3 SCPS-NP Header - Basic Quality of Service Field.3-10
3-4 SCPS Control Message Protocol Header Format.3-32
D-1 Effects of Bit-Errors on Integrity of SCPS-NP Header Information.D-13
D-2 Probability of Undetected Bit Errors' Affecting SCPS-NP Header
When Protected by Internet Checksum .D-14
D-3 Probability of Uncorrupted SCPS-NP Datagram as a Function of
Datagram Length and Bit-Error Rate .D-15
CCSDS 713.0-B-1 Page vi May 1999
10 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
CONTENTS (continued)
Table Page
3-1 Relationship of Header Elements to Selected Protocol Capabilities.3-5
3-2 Assigned TP-ID Values.3-6
3-3 Mapping of Assigned SCPS TP-ID Values to IP Numbers .3-6
3-4 Control Field Elements.3-7
3-5 SCPS Network Protocol Address Types .3-8
3-6 Control Field Flag Settings for SCPS Address Formats .3-8
3-7 Routing Requirements Field Values .3-9
3-8 Verification of Header Validity.3-14
3-9 SCMP Message Types.3-33
3-10 Destination Unreachable Message Codes .3-34
D-1 Valid Values of the N-User_Internet_Protocol_Number Parameter.D-3
D-2 SCPS-NP-Supported Internet Protocol Numbers.D-5
CCSDS 713.0-B-1 Page vii May 1999
(Blank page)
12 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
1 INTRODUCTION
1.1 PURPOSE
The purpose of this Recommendation is to define the services and protocols of the Space
Communications Protocol Specification (SCPS) Network layer. This definition will allow
independent implementations of the protocols in the space and ground segments of the SCPS
Network to interoperate.
1.2 SCOPE
This Recommendation is intended to be applied to all systems that claim conformance to the
SCPS Network protocols.
1.3 APPLICABILITY
This Recommendation is designed to be applicable to any kind of space mission or
infrastructure, regardless of complexity. It is intended that this Recommendation become a
uniform standard among all CCSDS Agencies.
1.4 RATIONALE
The CCSDS believes it is important to document the rationale underlying the
recommendations chosen, so that future evaluations of proposed changes or improvements
will not lose sight of previous decisions. The concept and rationale for SCPS-NP may be
found in reference [B3].
1.5 ORGANIZATION OF THIS RECOMMENDATION
This Recommendation contains four sections and four annexes. This section presents
introductory material that establishes the context for the remainder of the document. Section
2 contains an overview of the protocol, summarizing the main technical requirements and
describing the approach used to provide the protocol’s services. Section 3 presents the
protocol specifications. Section 4 establishes the requirements for maintaining management
information.
The four annexes to this Recommendation provide supporting information. Some of the
annexes contain normative material, while some contain informative material. Annex A is
informative and contains the acronyms and abbreviations used commonly throughout the
document. Annex B is informative and contains the informative references cited throughout
the document. Annex C is normative and contains the proforma for the Protocol
Implementation Conformance Statement (PICS). The PICS unambiguously describes the
capabilities provided by an implementation of the protocol. Annex D is normative and
contains the service specification.
CCSDS 713.0-B-1 Page 1-1 May 1999
CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
1.6 CONVENTIONS AND DEFINITIONS
1.6.1 OCTET NUMBERING CONVENTION AND NOMENCLATURE
This document does not deal with transmission of any elements smaller than one octet. As
such, the transmission order of bits within an octet is an issue to be dealt with at lower layers.
However, the relative ordering of octets within a word and the unambiguous numbering of
bits within an octet are relevant here. The order in which multi-octet fields defined in this
document are submitted for transmission is called ‘Big Endian’ byte ordering. When applied
to networking, this is called ‘network byte order’. In this ordering scheme, bit 0 of a 32-bit
value is the Most Significant Bit (MSB); bit 31 is the least significant bit. The octet
containing bits 0-7 is transmitted first, followed by the octet containing bits 8-15, followed by
the octet containing bits 16-23, and finally the octet containing bits 24-31. Note also that
‘Big Endian’ byte ordering is NOT what some machines (notably the 80x86 class of
machines) use internally. Implementers must ensure that headers are converted to network
byte order for transmission.
The following conventions apply throughout this Recommendation:
– the words ‘shall’ and ‘must’ imply a binding and verifiable recommendation;
– the word ‘should’ implies an optional, but desirable, recommendation;
– the word ‘may’ implies an optional recommendation;
– the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
1.6.2 DEFINITIONS
Address Family: An address family specifies the structural rules required to interpret the
internal fields of an address. The SCPS Network supports three address families: the SCPS
address family, the Internet Protocol (IP) address family, and the Internet Protocol version
Six (IPv6) address family.
Address Type: An address type defines the meaning that the addresses have (that is,
whether they identify end systems or a path between end systems), the number of addresses
that appear in a SCPS Network Protocol header (two addresses if the addresses identify end
systems, only one if the address identifies a path between end systems), and the address
family that is valid for the addresses. Refer to table 3-5 for a list of Address Types supported
in the SCPS Network.
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.)
CCSDS 713.0-B-1 Page 1-2 May 1999
14 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
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.)
Confirm (primitive): A primitive issued by a service-provider to complete, at a particular
service-access-point, some procedure previously invoked by a request at that service-access-
point.
Domain Identifier: The Domain Identifier (D-ID) is an element of the Extended End
System Address and of the Extended Path Address. When part of the Extended End System
Address, it identifies groups of Basic End System Addresses. When part of the SCPS
Extended Path Address, it identifies groups of Basic Path Addresses. (Note that groups of
addresses does not mean group addresses.)
End System Identifier: The End System Identifier (ES-ID) is an element of Basic End
System Addresses and of Extended End System Addresses. It allows the identification of
individual systems or of multicast groups (when qualified by the multicast flag). It has valid
values between 0 and 127, although specific programs may choose not to make all of these
available.
End System: An addressable network entity within the SCPS Network.
: The Extended End System Address identifies a single end
Extended End System Address
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.)
Gateway: A network-addressable system that terminates a protocol at a given layer and
invokes similar services at the same layer of an adjacent network.
Host: A network-addressable system that may send or receive network-layer datagrams but
does not forward datagrams.
Indication (primitive): A primitive issued by a service provider either to invoke some
procedure or to indicate that a procedure has been invoked by the service user at a peer
service-access-point.
CCSDS 713.0-B-1 Page 1-3 May 1999
CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
Intermediate Delivery flag: A control field element that indicates whether the network user
data (the N-SDU) should be delivered to the destination system only (the typical case) or to
the destination and all intermediate systems. The parameter has two values: DESTINATION
(the default, value ‘0’), which indicates that the N-SDU shall be delivered only to the
destination address; and INTERMEDIATE (value ‘1’), which indicates that the N-SDU shall
be delivered to the destination address and to all intermediate systems encountered.
NOTE – The INTERMEDIATE setting of Intermediate Delivery flag is intended for
diagnostic use, to provide a single-transmission ‘traceroute’ service. The
‘traceroute’ service, used in the Internet, provides a response from each
intermediate router between a source and destination by repeatedly sending echo
messages to the destination, but starting the maximum hops at one, and
incrementing it one for each message. This results in the return of an error
message to the source from the router that discarded the datagram. The
traceroute service is simple, but it generates a significant amount of traffic and
takes a significant amount of time to trace a route.  The Intermediate Delivery
capability is intended to cause all intermediate systems to provide a response to
the same Echo Request. The address information and hop count information can
be used to construct the route to the destination.
Internet Protocol Number: The Internet Protocol Number is the transport protocol
identifier used by Internet Protocols. Values may range from 0 through 255, and valid values
are defined in reference [B14].
IP Address Family: The IP Address Family specifies a set of structural rules for the
interpretation of Extended End System Addresses; it is defined in reference [B11], and the
possible formats are refined in section 3.2.1.3 of reference [B12].
: The IPv6 Address Architecture is defined in RFC 2373 (see reference [B16]).
IPv6 Address
Note that the IPv6 address is not currently one of the valid types for the N-
Destination_Address or the N-Source_Address (refer to Annex D).
Maximum Transmission Unit: The Maximum Transmission Unit (MTU) specifies the
maximum amount of data that the subnetwork layer will accept in a single subnetwork
service request. The MTU for a route is the minimum of all known MTUs along that route.
NOTE – It is anticipated that this value will be known and managed as part of the routing
table information; however, techniques for dynamically discovering the MTU of
a route exist. Refer to RFC 1191, Path MTU Discovery (reference [B2]) for more
information.
Multicast Flag: The Multicast Flag (M-Flag) is an element of addresses within the SCPS
Address Family. The M-Flag indicates whether the address refers to a single end system or
path, or identifies a group address. Group addresses may identify zero or more end systems
or paths.
CCSDS 713.0-B-1 Page 1-4 May 1999
16 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
N-Address: an address in the SCPS Network. The attributes of an N-Address are the
Address Type and the Address Family.
See N-SDU.
Network Service Data Unit:
N-SDU: The Network Service Data Unit (N-SDU) is a parameter of the Unit Data service
primitives. It is a variable-length, octet-aligned data unit of arbitrary format. The maximum
length of an N-SDU is 8141 octets. Local restrictions on datagram size or extensions to the
protocol may further limit this size; the maximum length of an N-SDU for an
implementation shall be documented by the implementer.
NOTE – The maximum size of the N-SDU field is limited to the length resulting from
subtracting the maximum length of a SCPS-NP header from the maximum SCPS-
NP PDU length. The maximum length of the SCPS-NP header is 50 octets. The
length field in the SCPS-NP header is 13-bits, which allows an 8191-octet total
datagram length. Therefore, the maximum size of an N-SDU that is guaranteed to
fit in a SCPS-NP PDU is 8141 octets.
Path Identifier: The Path Identifier (P-ID) is an element of the Basic Path Address and the
Extended Path Address. It identifies a static, managed communication path between two (or
more) systems. Path Identifiers may range in value from 0 through 127, although specific
programs may restrict the P-IDs available.
Precedence field: A sub-field within the Basic Quality of Service field of the SCPS Network
Protocol header. When present, the Precedence field may vary from 0 to 15, with 0 being the
lowest precedence and 15 being the highest.
Primitive (also known as service-primitive): An abstract, implementation-independent
interaction between a service-user and the service-provider.
Program Specific field: A sub-field within the Basic Quality of Service field of the SCPS
Network Protocol header. When present, the Program Specific field may vary from 0 to 3.
Request (primitive): A primitive issued by a service-user to invoke some procedure.
Response (primitive): A primitive issued by a service-user to complete, at a particular
service-access-point, some procedure previously invoked by an indication at that service-
access-point.
Router: A network-addressable system that may send, receive, or forward network-layer
datagrams.
Routing Requirements field: A sub-field within the Basic Quality of Service field of the
SCPS Network Protocol header. When present, the Routing Requirements field may vary
from 0 to 3. Refer to 3.2.3.6 for the assigned values of this field. The default value for the
Routing Requirements field is 0, which indicates ‘normal’ routing.
CCSDS 713.0-B-1 Page 1-5 May 1999
CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
SCPS Network Address: A SCPS Network Address specifies one of the possible SCPS
Address formats and the values of the parameters required by that format.
: A point at which the services of a layer are made available to the
Service-Access-Point
layer above it.
Service-Primitive: See Primitive.
: A datagram is ‘silently discarded’ if no error message is generated (either
Silently Discard
to a local user or to a remote user) as a result of the discard. The practice of silently
discarding datagrams reduces the possibility that a misconfigured host will uncontrollably
generate erroneous traffic. The term ‘silent discard’ differs from ‘discard’ in that certain
actions, such as informing network service users about the discard, are not performed in a
silent discard. When the term ‘discard’ is used, other information must be used to determine
whether the network service user is informed.
Transport Protocol Identifier field: The Transport Protocol Identifier (TP-ID) is a field in
the SCPS-NP header that identifies the SCPS Network user (i.e., the transport protocol) from
which the datagram originated and to which the datagram should be delivered at its
destination(s). It is a 4-bit field that carries a translation of the N-
User_Internet_Protocol_Number parameter of the Unit Data service primitives. The
translation table appears in table 3-3.
Tuple: A tuple is an ordered set of arbitrary length.
1.7 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommendation. At the time of publication, the editions indicated were
valid. All documents are subject to revision, and users of this Recommendation are
encouraged to investigate the possibility of applying the most recent editions of the docu-
ments indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS Recommendations.
[1] K. Nichols, S. Blake, F. Baker, and D. Black.
Definition of the Differentiated Services
†
Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474, December 1998.
[2] Time Code Formats. Recommendation for Space Data Systems Standards, CCSDS
301.0-B-2. Blue Book. Issue 2. Washington, D.C.: CCSDS, April 1990.
†
Internet Request for Comments (RFC) texts are available on line in various locations (e.g., http://ietf.org/rfc/).
CCSDS 713.0-B-1 Page 1-6 May 1999
18 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
2 OVERVIEW
This Recommendation specifies a new service and protocol to meet the needs of current and
future space missions. It supports communication environments with static, highly managed
communication through fully connectionless communication with dynamic routing. All of
these types of operations are supported with near-optimal bit efficiency.
This Recommendation is based on concepts that have been drawn from a number of sources:
the notion of ‘Path Service’, or essentially a permanent-virtual-circuit form of addressing, is
drawn from the Consultative Committee for Space Data Systems (CCSDS) Recommendation
for Advanced Orbiting Systems, CCSDS-701.0-B-2 (reference [B4]), from the CCSDS
Recommendation for Telecommand, Part 2, CCSDS-202.0-B-2 (reference [B5]), and from
the CCSDS Recommendation for Packet Telemetry, CCSDS 102.0-B-3 (reference [B6]);
other ideas are taken directly or indirectly from the Internet Protocol specification and
numerous explanatory publications; and the SCPS-NP header construction approach is based
on the header compression concepts elaborated in RFC 1144 (reference [B17]—see annex B).
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 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).
CCSDS 713.0-B-1 Page 2-1 May 1999
CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
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.
CCSDS 713.0-B-1 Page 2-2 May 1999
20 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
3 PROTOCOL SPECIFICATION
3.1 ADDRESSING
3.1.1 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.
NOTE – 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).
NOTE – A single mission may be allocated more than one D-ID for its needs.
Determination of the registration authority to allocate and deallocate
domain identifiers is beyond the scope of this Recommendation.
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:
• the M-Flag shall be set to ‘1’ for multicast addresses;
• the M-Flag shall be set to ‘0’ for unicast addresses.
CCSDS 713.0-B-1 Page 3-1 May 1999
CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
b) Internet Protocol (IP) Address Family. The IP address family contains End-System
Addresses that are appropriate for routing and delivery across the Internet. The
structure of Internet addresses is defined in reference [B11] (RFC 791, section 2.3,
and RFC 1112, section 4) and reference [B12] (RFC 1122, section 3.2.1.3).
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. IPv6 address formats are specified in reference [B16].
3.1.2 BROADCAST ADDRESS DEFINITION
3.1.2.1 SCPS Address Family Broadcast Address Definition
3.1.2.1.1 Unless otherwise stated, the SCPS Address family conforms to the same broadcast
address definitions as the IP Address Family, described in 3.1.1.
3.1.2.1.2 A SCPS Address of 10.x.y.255 is the broadcast address for the x.y addressing
domain and shall be treated in the same manner as an IP-address family subnet-directed
broadcast with a subnet mask of 255.255.255.0 (refer to 3.1.2.2, below).
3.1.2.1.3 A SCPS Address of 10.255.255.255 is the broadcast address for the entire SCPS
addressing domain and shall be treated in the same manner as an IP-address family net-
directed broadcast (refer to 3.1.2.2, below).
3.1.2.2 Internet Protocol Address Family Broadcast Address Definition
NOTE - much of this text is from reference [B18].
3.1.2.2.1 Limited Broadcast Address
a) The limited broadcast address is defined as 255.255.255.255, where the form of the
address is specified in 3.1.1 a) 1), above.
b) Datagrams destined to the limited broadcast address shall be transmitted on all local
interfaces that support broadcasting.
c) Datagrams destined to the limited broadcast address shall not be forwarded upon
receipt.
3.1.2.2.2 Net-Directed Broadcast Address
a) The net-directed broadcast address has as its host ID all one-bits.
b) The Class A net-directed broadcast address is netid.255.255.255.
CCSDS 713.0-B-1 Page 3-2 May 1999
22 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
NOTE – The net-directed broadcast address for the entire SCPS Address Family is
10.255.255.255.
c) The Class B net-directed broadcast address is netid.255.255, since the network
identifier of a Class B network is the most-significant 16 bits of the address and the
host identifier is the least-significant 16 bits.
d) The Class C net-directed broadcast address is netid.255, since the network identifier
of a Class C network is the most-significant 24 bits of the address and the host
identifier is the least-significant 8 bits.
e) Routers shall be capable of forwarding datagrams addressed to net-directed broadcast
addresses.
f) Routers shall be capable of disabling the forwarding of net-directed broadcasts.
3.1.2.2.3 Subnet-Directed Broadcast Address
a) The subnet-directed broadcast address has as its host ID all one-bits with the
exception of those bits that specify the subnetwork.
b) Identification of an address as a subnet-directed broadcast address requires knowledge
of the subnet mask. If the subnet mask is not known, the datagram shall be treated as
a unicast transmission.
c) Datagrams addressed to subnet-directed broadcast addresses shall be broadcast only
within the specified subnetwork.
3.1.2.2.4 All-Subnets-Directed Broadcast Addresses
All-subnets-directed broadcast addresses shall not be supported.
NOTE – These addresses are identical in structure to net-directed broadcast addresses;
however, there is a subnet mask defined for the destination.
3.1.2.3 IPv6 Address Family Broadcast Address Definition
There are no broadcast addresses defined in IPv6.
CCSDS 713.0-B-1 Page 3-3 May 1999
CCSDS RECOMMENDATION FOR SCPS NETWORK PROTOCOL (SCPS-NP)
3.2 SCPS NETWORK PROTOCOL SPECIFICATION
3.2.1 SCPS-NP DATAGRAM
A SCPS-NP datagram shall consist of a header followed by zero or more octets of N-SDU.
3.2.2 SCPS-NP HEADER
3.2.2.1 SCPS-NP Header Format
The SCPS-NP header
...