1.5 DOCUMENT STRUCTURE
This document is divided into five numbered sections and three annexes:
a) Section 1 presents the purpose, scope, applicability and rationale of this
Recommended Standard and lists the conventions, definitions, and references used
throughout the document;
b) Section 2 provides an overview of the Encapsulation Service;
c) Section 3 defines the service primitives provided for this service;
d) Section 4 specifies the protocol data units and procedures employed by the service
provider;
e) Section 5 lists the managed parameters associated with this service;
f) Annex A lists all acronyms used within this document;
g) Annex B provides a list of informative references;
h) Annex C lists the changes from older CCSDS Recommendations [B2]-[B4].
i) Annex D specifies the internetwork multiprotocol extension (iMPE) header
j) Annex E enumerates the protocols supported via the iMPE header
Annex D
iMPE Header convention (Normative)
The primary purpose of the iMPE convention is to provide an interoperable way of
identifying the internetworking protocols being encapsulated by the encapsulation service
when this service is being used as the data link layer for a network layer protocol like the
Internet Protocol (IP). See Annex E for recommended protocols and their enumerations.
The internet multiprotocol extension (iMPE) is a convention used by a service user of the
Encapsulation Service. The user is identified by either using a specific ENCAP PID – i.e.
the iMPE value given in the Space Link Identifier blue book [8] -- or a pre-arranged
Space Packet application process identifier (APID). This service user uses the service
primitives defined in the main body of this recommendation. This service user receives
the service described in the main body, but offers an additional service. It provides an
additional protocol multiplexing/demultiplexing service to its user.
The iMPE convention allows demultiplexing of subprotocols used in internetworking. It
offers a sizable protocol identifier space while not impacting the protocol ID space used
by the Encapsulation Service itself. This abstracts, and allows the separation of protocols
and packet formats used in internetworking from core packet formats associated with the
CCSDS defined space packet service and ENCAP. No additional processing is
performed at the multiplexing/demultiplexing layer affiliated with the iMPE convention.
The multiplexing/demultiplexing services know nothing of the formats or conventions of
the protocols they are multiplexing or demultiplexing.
Prot X.1
Prot X.2
Prot X.n
(iMPE)
OSI
Layers
Figure 1 Relationship of iMPE to the Encapsulation Service
The iMPE convention is affiliated with a header format. This header is described in this
Annex. The header shall immediately follows the encapsulation service header as shown
in Figure 2. It is an extension to the encapsulation service header in that it effectively
expands the number of protocols that can have a standardized definition for transport
over CCSDS space links. It is not part of the encapsulation service header itself. When
using ENCAP, existence of this extension header shall be signaled by use of an ENCAP
Protocol ID (PID) defined in the Space Link Identifiers blue book.
Encapsulation Header
iMPE Header
PID (Bits 0-6)
PDU of Protocol being Encapsulated
Ext.
Bit 7
Optional
Byte
PID (Bits 0-6)
Figure 2 iMPE header format and placement
Ext.
Bit 7
Bit and octet ordering shall follow the conventions given in section 1.6.3. The header is
normally one byte long, but shall be extensible by using the last bit of each octave (the
7th bit which is the LSB). If the LSB of an octave is ‘0’, it shall be assumed that an
additional octave follows. The header, being one or more octaves, shall be interpreted as
an unsigned integer value per the convention given in section 1.6.3. The user datagram
shall immediately follow the iMPE extension header.
Note that, since the most significant octets occur first, zero octets are effectively fill
octets. Also note that all iMPE header numbers will by definition be odd.
To support the extension header, processing and parsing of the header is required.
Besides multiplexing and demultiplexing – which can subsequently involve stateless
mapping between link layer conventions used on other link layers -- no additional
processing is intended. Such processing would be considered to be specific to the
protocols that are identified via this header.
Annex E
iMPE Header enumerations and mappings
(Informative)
The primary purpose of the iMPE convention is to provide an interoperable way of
identifying the internetworking protocols being encapsulated by the encapsulation service
when this service is being used as the data link layer for a network layer protocol like the
Internet Protocol (IP). There often are many packet formats that have to be encapsulated.
The exact number of packet formats depends on the mission and its requirements. These
protocols are fully defined in other standards. Thus the intent is only to identify auxiliary
packet formats that are often used in support of a network layer protocol. As a
comparison, serial links between routers often carry the 16-bit PPP protocol field, and the
Ethernet protocol data units carry a 16-bit Ethernet type field. In these cases, the
enumeration of the protocols are defined by IANA and IEEE respectively. The tables
containing the enumerations then point to the standards that define the protocols
themselves. In this section, the enumerations to be used with the encapsulation service
are listed.
The alternate approach would have been to encapsulate a conventional link layer, such as
Multiprotocol over Frame Relay, and use its methods for identifying the auxiliary packet
formats.
For missions that only needs to support IPv4 datagrams and do not need any auxiliary
datagram formats, IPv4 can go native without the use of the encapsulation service.
Auxiliary protocols identified at the data link layer in support of IP include IPv4, IPv6, IP
compressed header formats, the address resolution protocol for multi-access link layers,
link layer control protocols including link metrics exchange and link health monitoring,
various link and network layer configuration protocols and authentication protocols.
Numerous non-IP network layer protocols are typically also found, ones that are often no
longer in use.
Addressing and routing protocols often tie into these protocols via initial configuration
exchanges and link state up/down information. It should be noted – however - that
routing protocols such as OSPF, PIM and BGP also maintain their own adjacency or state
via hello exchanges or refreshes at the network layer.
Most of these protocols are built around bi-directional links and require bi-directional
exchanges. Since in the space environment it is expected that network layer protocols
will have to be able to use one-way links, it is not recommended that these protocols be
required. It is the belief that if fairly simple networks are involved, and they are
monitored in a transparent manner, it is possible to use pre-arranged static settings rather
than relying on dynamic exchanges to verify and maintain correct configuration.
However, if appropriate for the mission, use of these protocols is not prohibited.
The following values are offered for use with the iMPE header convention.
Table 1: Enumerations for the iMPE header values
Value
Protocol
Reference
00100001 (TBR)
IPv4 datagarm
J. Postel. Internet
Protocol. STD 5,
September 1981. [RFC
791, RFC 950, RFC
919,
RFC 922, RFC 792,
RFC 1112
01010111 (TBR)
IPv6 datagram
S. Deering and R.
Hinden. Internet
Protocol, Version 6
(IPv6) Specification.
Draft
Internet Standard,
December 1998. [RFC
2460
01100001 (TBR)
FULL_HEADER
RFC 2507
01100011 (TBR)
COMPRESSED_TCP
RFC 2507
01100101 (TBR)
COMPRESSED_TCP_NO_DELTA
RFC 2507
01100111 (TBR)
COMPRESSED_NON_TCP
RFC 2507
01101001 (TBR)
COMPRESSED_RTP_8
RFC 2508
01101011 (TBR)
COMPRESSED_RTP_16
RFC 2508
01101101 (TBR)
COMPRESSED_UDP_8
RFC 2508
01101111 (TBR)
COMPRESSED_UDP_16
RFC 2508
01110001 (TBR)
CONTEXT_STATE
RFC 2507,2508
01110011 (TBR)
Identification of IP header
compression capabilities
FRF.20 or RFC 2509
(TBR)
Example mapping for MPoFR
Note that with the iMPE convention, routers can talk to each other using a CCSDS defined data
link layer. It is possible though, that the preference may be to map a link layer integrated into a
commercial-off-the-shelf router to the CCSDS defined data link layer. This section gives a quick
example on how that may be done.
MCC
CEV
Apps
Apps
Data Exchange
IP over CCSDS
service interface
IP service interface
Data Exchange
Transport
Transport
Network IP
ENCAP/AOS
ENCAP
PHY SN
PHY SN
Passes 1-hop
header compression
data between
adjacent routers
Network IP
Network IP
ENCAP/AOSMPoFR
PHY
MPoFR
DL
Data Link
PHY
PHY
PHY
Lower layer protocol interfaces
Figure 3 Mapping MPoFR values to an iMPE header
Stateless mapping
of bit fields
Cx Router
IP over CCSDS
formats
Routing, QoS,
IPHC, IPsec
Translate 4-byte MPoFR
header to 1-byte value
Packet Version Numbers
000
001
010
011
100
101
110
111
Encap Protocol IDs
Space Packet
SCPS-NP
IPv4 Datagram
Encap Packet
000
001
010
011
100
101
110
111
Encap Fill
IP
CFDP
-Proto Exten.
Arbitrary Octets
Value
Protocol
IPv4 datagarm
RFC 791, RFC 950, RFC 919,
RFC 922, RFC 792, RFC 1112
01010111 (TBR)
IPv6 datagram
RFC 2460
FULL_HEADER
RFC 2507
COMPRESSED_TCP
RFC 2507
01100101 (TBR)
COMPRESSED_TCP_NO
_DELTA
RFC 2507
01100111 (TBR)
COMPRESSED_NON_TC
P
RFC 2507
01101001 (TBR)
COMPRESSED_RTP_8
RFC 2508
01101011 (TBR)
COMPRESSED_RTP_16
RFC 2508
01101101 (TBR)
COMPRESSED_UDP_8
RFC 2508
01101111 (TBR)
COMPRESSED_UDP_16
RFC 2508
01110001 (TBR)
CONTEXT_STATE
RFC 2507,2508
01110011 (TBR)
Identification of IP header
compression capabilities
FRF.20 or RFC 2509 (TBR)
FULL_HEADER
COMPRESSED_TCP
COMPRESSED_TCP_NODELTA
COMPRESSED_NON_TCP
COMPRESSED_RTP_8
COMPRESSED_RTP_16
COMPRESSED_UDP_8
COMPRESSED_UDP_16
CONTEXT_STATE
0-253 byte Aggregation
111 of010
0
Octets
Pkt length 0-1
Reference
01100011 (TBR)
01100001 (TBR)
IP255
over
CCSDS
shim
User Frame
0-65535 byte Aggregation of
111 Octets
010 1
- 0
IPv4/v6
Q.922 Address
Q.922 Address
(Static Ch ID, no Fw or Bw Cong. Indication)
(Static Ch ID, no Fw or Bw Cong. Indication)
Build 4-byte
Aggregated Octet
encap header
Build 2-byte
Aggregated Octet
encap header
Pkt length
0-65535
IP over
CCSDS
Shim
User
Frame
…
MPoFR formats mapped
IP w/ HC
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
Len > 253BNo
AOS Encap
with IP over CCSDS Shim
Protocol ID Len of Len
00100001 (TBR)
Receive Data
Link Frame From
Router
Yes
Encap Packet Header Format
Pkt Version #
AOS Encap
with 1-byte protocol field
AOS Frame and fill generation
Dropped?
Q.922 Address
(Channel used for HC negotiation)
Control (0x02)
NLPID (see Table)
Control (0x03)
NLPID (0xCC or 0x8E)
Control (0x02)
NLPID (0x09)
Packet format defined
by RFC 2507/8
IPv4 or IPv6
Packet
Frame Relay IP header Compression
Control PDU
FCS
FCS
FCS
FEC/
Modulation/
RF
Figure 4 Process steps in mapping MPoFR to CCSDS encapsulation service
RATIONALE/COMMENTS:
Link Layers used for transporting IP traditionally have larger next layer protocol fields (PID
ranges) than those ENCAP currently defines. Although most of these values are used by
alternate protocols that are not of interest to CCSDS, best current practices in the use of IP in
networks do often make use of additional protocols at the link layer. Of interest is IP header
compression for use with resource constrained links.
The iMPE header is motivated in part by the desire to create a layering with currently defined
encapsulation services, and in part by the limited space for new protocols available with ENCAP.
The following were examined as candidates in this process.
Expanding the use of the ENCAP defined protocol ID extension field was considered. The use of
this header was specific to the 4-byte ENCAP header. The comment was made that resource
constrained links that benefit from header compression often carry smaller datagrams (e.g. VOIP
packets). Often smaller MTU sizes are defined to reduce jitter. This suggests the advantage of
being able to use the 2-byte ENCAP header format.
Link Layer Protocol ID Enumerations defined by other forums were considered for use here,
however two concerns exist. The first was to control the use of protocols defined by these forums
that may not be recommended for use in a space environment. The second was to make the
transition from IP header compression use with MPoFR on terrestrial networks as easy as
possible.
The EtherTypes protocol field definitions associated with the 802.x protocols were considered as
a candidate for the new protocol ID field. However EtherTypes don’t define IP header
compression.
The Frame Relay Header NLPI byte field values were considered as a candidate, but they don’t
cover IP header compression.
The Frame Relay FRF.20 field values were considered as a candidate, but the proposed header
size would have been 4 bytes, and some concerns (please verify if possible) about the use of
Frame Relay header only (note - no HDLC being proposed here) seem to exist.
The IANA defined values for PPP were considered. These do define the needed protocols
(although it is noted that ARP is not used on these links and thus not defined). The most
commonly used values can be found in the first byte, and using the Protocol field compression
convention (based on an ISO standard) this would amount to a single byte. Again, the there are
thought to be concerns in the community about use of PPP values (note no HDLC proposed
here). In addition it is noted that PPP strongly encourages the use bi-direction link control and
network control protocols that may not be appropriate for one-way space links.