ISO 15893:2010 宇宙データおよび情報転送システム—宇宙通信プロトコル仕様（SCPS）—トランスポートプロトコル（SCPS-TP） | ページ 4

1.1 目的

この勧告の目的は、宇宙通信プロトコル仕様 (SCPS) トランスポート サービスを提供するサービスとプロトコルを定義することです。この定義により、SCPS ネットワークの宇宙セグメントと地上セグメントにおけるプロトコルの独立した実装が相互運用できるようになります。

1 INTRODUCTION

1.2 SCOPE

This Recommendation is intended to be applied to all systems that claim conformance to the SCPS Transport 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-TP may be found in reference [B2],

1.5 ORGANIZATION OF THIS RECOMMENDATION

This Recommendation contains six 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 protocols, summarizing the main technical requirements and describing the approach used to provide the protocols’ services. Sections 3 and 4 present the specifications for Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) in the SCPS environment. Section 5 establishes the requirements for maintaining management information. Section 6 presents conformance requirements for implementations.

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.

1.6 HOW TO READ THIS DOCUMENT

This document makes modifications and extensions to TCP and UDP for use in spacecraft communications environments, characterized by potentially long delays, unbalanced forward- and return-link data rates, and potentially high error rates. It is anticipated that some readers of this document will be protocol implementers, probably with TCP implementation experience. Other readers will be individuals more familiar with the particular application environment than with the protocols.

For readers and implementers already familiar with the internals of TCP and UDP, this document may best be used in the following manner:

• 1) Review section 6 of this document. It describes the implementation requirements for TCP and UDP, and gives an indication of those capabilities within TCP and UDP that have been modified (indicated by text to the effect ‘as amended by a.b.c of this document’, where a.b.c is a section reference in this document).Also in section 6 is a list of mission-specific capabilities that, depending on the needs of the mission, may be beneficial to add to the basic functionality of the protocols. Section 6 provides an introduction to these capabilities, and pointers back to sections 3 and 4, in which the capabilities are specified. Readers should use section 6 as a means of identifying the capability set required for their mission(s).Some of the capabilities required for a mission depend on the availability of other capabilities. These dependencies, along with a restatement of the implementation requirements, are documented in table form in the Protocol Implementation Conformance Statement that appears in annex C. Annex C specifies the format in which an implementer must document the details of his or her implementation.
• 2) Review sections 3 and 4, which specify SCPS-TP-unique options and modifications for TCP and UDP.
• 3) Review section 5, which identifies the management information requirements.

For readers and implementers who are generally familiar with the operation of TCP and UDP, but not the internals of the protocols, the following approach to reviewing this document may be useful:

• 1) Read over the UDP and TCP RFCs. The UDP specification is quite short (3 pages). The TCP specification is significantly longer, but also provides a substantial amount of background information. These documents were written in 1980 and 1981, respectively.
• 2) Read section 4 of RFC 1122. This document captures the Tessons learned’ from using TCP and UDP as of 1989. In addition to placing requirements on implementations of TCP and UDP, it provides a significant amount of explanatory information and discussion about rationale for particular requirements. RFC 1122 constitutes an extension to the base TCP and UDP specifications, in addition to describing implementation requirements.
• 3) Read over section 6 of this document. It refers to the TCP and UDP RFCs and to RFC 1122, and either endorses or revises the requirements put forward in RFC 1122. Read the ‘Mission-Specific Capabilities’ subsection, and identify whether any of these capabilities are necessary. If so, review the references identified in each of the mission-specific capability sections.
• 4) Finally, read sections 3 through 5.

Readers with little previous familiarity with TCP or UDP should consider reviewing an introductory text on the subject. One excellent example is TCP/IP Illustrated, Volume 1, by W. Richard Stevens (Copyright 1994, Addison-Wesley Professional Computing Series). Chapters 1, 11, and 17-24 are particularly relevant. Note that additional information about one of the mission-specific capabilities—the modifications to TCP to support Transactions— is presented in Chapters 1-12 of TCP/IP Illustrated, Volume 3, by W. Richard Stevens (Copyright 1996, Addison-Wesley Professional Computing Series).

1.7 CONVENTIONS AND DEFINITIONS

1.7.1 OCTET NUMBERING CONVENTION AND NOMENCLATURE

This document does not deal with transmission of any data 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, it is called ‘network byte order’. In this ordering scheme, bit 0 of a 32-bit value is the most significant bit; 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 that ‘Big Endian’ byte ordering is NOT what some machines (notably the 80x86 class of machines) use internally. Implemented must ensure that headers are converted to network byte order for transmission.

The following conventions apply throughout this Recommendation:

• a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
• b) the word ‘should’ implies an optional, but desirable, specification;
• c) the word ‘may’ implies an optional specification;
• d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.

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

Connection: A connection is defined by information that is named, persistent, and shared across the systems supporting an instance of communication. For transport protocols, these systems are the endpoints that terminate the transport protocol, but not intermediate systems.

End System: An addressable network entity within the SCPS Network.

Extended End System Address: The Extended End System Address identifies a single end system or an end-system group. The Extended End System Address conforms to the structural rules of either the SCPS Address Family or the IP Address Family. Extended End System Addresses may be parameters to the primitives of the Unit Data service.

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 packets, but does not forward packets.

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 [1],

IP Address Family: The IP Address Family specifies a set of structural rules for the interpretation of Extended End System Addresses, and is defined in reference [1], and the possible formats are refined in section 3.2.1.3 of RFC 1122 (reference [2]).

Maximum Segment Size: The maximum amount of user data that can be carried in a Segment. This value is calculated by subtracting the size of the network, security, and transport layer headers from the MTU size.

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.

N-Address: an address in the SCPS Network. The attributes of an N-Address are the Address Type and the Address Family.

N-Basic_Quality_of_Service parameter: The Basic Quality of Service (QOS) parameter of the N-UNITDATA service primitives carries information necessary to provide special network processing services for the datagram. It is a data structure that contains three sub-parameters: precedence, routing requirements, and a program-specific field.

N-Destination_Address: The N-Destination_Address is a parameter of all of the SCPS Network service primitives. It is an N-Address that identifies the destination end system of a packet in the SCPS Network. The N-Destination_Address parameter must be of the Extended End System address type, and may be of either the IP or the SCPS address family.

Network-Service Data Unit: See N-SDU.

N-Expanded_Quality_of_Service parameter: The Expanded QOS parameter provides a mechanism for specifying ground-relevant QOS requests. The valid values of this parameter are defined in RFC 2474 (reference [B7]).

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 8145 octets.

N-Source_Address: The N-Source_Address is a parameter to many of the primitives of the SCPS network service. It is an N-Address that identifies the end system originating a packet in the SCPS Network. The N-Source_Address must be of the Extended End System address type and may be of either the IP or the SCPS address family. The N-Source_Address may not be a multicast or a broadcast address.

N-Source_Timestamp parameter: The N-Source_Timestamp is a parameter of several SCPS Network service primitives. This parameter permits the Network Service user to provide a source timestamp to accompany the N-SDU. The Source Timestamp parameter consists of a timestamp format field and a timestamp value field.

N-User_Internet_Protocol_Number parameter: The N-User_Internet_Protocol_Number is a parameter to several of the SCPS Network service primitives. The values of this parameter used by the SCPS-TP are shown in table 1-1.

Port: An identifier of the transport service user.

Precedence parameter: The precedence parameter is an element of the NBasic_Quality_of_Service parameter of the N-UNITDATA service primitives. The precedence parameter is specified by a network service user to identify the relative importance of this data compared to other data within the network. It is an integer with a valid range from 0 to 15, with 0 being the lowest precedence and 15 being the highest. Local policy may cause the user-specified precedence parameter to be overridden. The network service user may also supply a null value for the precedence parameter, in which case the network service would assign a default value for the precedence parameter.

Program Specific parameter: The program-specific parameter is an element of the NBasic_Quality_of_Service parameter that provides a mechanism for programs to carry two bits of information in the SCPS-NP header. This information is interpreted by program-specific extensions to the SCPS-NP and has a default value of 0.

Pseudo-Header: A pseudo-header, in TCP and UDP, is a collection of information that is used for the purposes of checksum calculation, but not actually shipped as part of the transport layer protocol data unit. The information in the pseudo-header consists of the source and destination addresses, the Internet Protocol Number of the transport protocol, and the length of the transport protocol data unit.

Router: A network-addressable system that may send, receive, or forward network-layer packets.

Routing Requirements parameter: The Routing Requirements parameter is an element of the N-Basic_Quality_of_Service parameter of the N-UNITDATA service primitives. The Routing Requirements parameter has two currently defined values: ‘normal’ routing and ‘flood’ routing.

SCPS Network Address: A SCPS Network Address specifies one of the possible SCPS Address formats (via the FMT-ID parameter) and the values of the parameters required by that format.

Segment: A segment is the Protocol Data Unit of the Transmission Control Protocol (TCP).

Service-Access-Point: A Service-Access-Point (SAP) is the point at which the services of a layer are made available to the layer above it.

Silently Discard: A packet is ‘silently discarded’ if no error message is generated (either to a local user or to a remote user) as a result of the discard.

T-SDU: The Transport Service Data Unit (T-SDU) is a parameter of several of the SCPS-TP service primitives. It is a variable-length, octet-aligned data unit of arbitrary format. The maximum length of a T-SDU is an implementation issue.

Timestamp Format field: The Timestamp Format field of the N-Source_Timestamp parameter identifies the format of the source timestamp that is supplied by the Network User. The available formats are specified in reference [10],

Timestamp Value: The Source Timestamp Value field of the N-Source_Timestamp parameter contains the value of the timestamp that shall accompany the Network Service Data Unit.

Transport-Service Data Unit: See T-SDU.

1.8 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 documents indicated below. The CCSDS Secretariat maintains a register of currently valid CCSDS Recommendations.

ANNEX B

INFORMATIVE REFERENCES
(This annex is not part of the Recommendation.)