ISO 15891:2000
(Main)Space data and information transfer systems — Protocol specification for space communications — Network protocol
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
General Information
Relations
Standards Content (Sample)
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 15891:2000(E)
©
ISO 2000
---------------------- Page: 1 ----------------------
ISO 15891:2000(E)
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.
© ISO 2000
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
---------------------- Page: 2 ----------------------
ISO 15891:2000(E)
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.
© ISO 2000 – All rights reserved iii
---------------------- Page: 3 ----------------------
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.
© ISO 2000 – All rights reserved 1
---------------------- Page: 4 ----------------------
ISO 15891:2000(E)
[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
---------------------- Page: 5 ----------------------
ISO 15891:2000(E)
RECOMMENDATION FOR SPACE
DATA SYSTEM STANDARDS
SPACE COMMUNICATIONS
PROTOCOL SPECIFICATION (SCPS)—
NETWORK PROTOCOL
(SCPS-NP)
CCSDS 713.0-B-1
BLUE BOOK
May 1999
© ISO 2000 – All rights reserved 3
---------------------- Page: 6 ----------------------
ISO 15891:2000(E)
(Blank page)
4 © ISO 2000 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 15891:2000(E)
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
© ISO 2000 – All rights reserved 5
---------------------- Page: 8 ----------------------
ISO 15891:2000(E)
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
---------------------- Page: 9 ----------------------
ISO 15891:2000(E)
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
© ISO 2000 – All rights reserved 7
---------------------- Page: 10 ----------------------
ISO 15891:2000(E)
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
---------------------- Page: 11 ----------------------
ISO 15891:2000(E)
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
© ISO 2000 – All rights reserved 9
---------------------- Page: 12 ----------------------
ISO 15891:2000(E)
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
---------------------- Page: 13 ----------------------
ISO 15891:2000(E)
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
11
© ISO 2000 – All rights reserved
---------------------- Page: 14 ----------------------
ISO 15891:2000(E)
(Blank page)
12 © ISO 2000 – All rights reserved
---------------------- Page: 15 ----------------------
ISO 15891:2000(E)
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
© ISO 2000 – All rights reserved 13
---------------------- Page: 16 ----------------------
ISO 15891:2000(E)
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
---------------------- Page: 17 ----------------------
ISO 15891:2000(E)
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
© ISO 2000 – All rights reserved 15
---------------------- Page: 18 ----------------------
ISO 15891:2000(E)
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
---------------------- Page: 19 ----------------------
ISO 15891:2000(E)
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-SD
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.