Internet DRAFT - draft-feighery-ip-over-ccsds
draft-feighery-ip-over-ccsds
Internet Draft P.D. Feighery
Document: draft-feighery-ip-over-ccsds-00.txt The MITRE
Corporation
Expires: April 2004 October 2003
IP Over CCSDS Protocols
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at
http://www.ietf.org/shadow.html.
Abstract
This document describes how to encapsulate Internet Protocol
version 4 and version 6 packets can be encapsulated in
Consultative Committee for Space Data Systems (CCSDS) Space
Data Link Protocols.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC-2119 [2].
Feighery Expires - April 2004 [Page 1]
IP over CCSDS October 2003
Table of Contents
1. Introduction..................................................2
1.1 Introduction to CCSDS.....................................2
1.2 CCSDS Publications........................................3
2. Encapsulating Internet Protocols within CCSDS.................4
2.1 IPv4 Encapsulation within CCSDS...........................4
2.2 IPv6 Encapsulating within CCSDS...........................4
2.3 Address Resolution and Channel Assignment.................5
3. Interaction with Higher Layers................................5
3.1 Transport layer Encapsulation.............................5
3.2 Maximum Transmission Unit.................................6
3.3 Link Reliability Mechanisms...............................6
3.3.1 Forward Error Correction (FEC)..........................7
3.3.2 Data Link Retransmissions...............................7
Security Considerations..........................................7
References.......................................................7
Author's Address.................................................8
1. Introduction
The Consultative Committee for Space Data Systems (CCSDS)
defines architectures and protocols for space communications.
The CCSDS has evolved, over the past 20 years, in parallel
with the emergence of the terrestrial Internet and inevitably
questions are asked as to the relevance of CCSDS and the
Internet to each other. This paper provides guidelines to
developers on how to use Internet protocols over CCSDS data
links.
1.1 Introduction to CCSDS
The Consultative Committee for Space Data Systems (CCSDS) was
formed in 1982 by the major space agencies of the world to
provide a forum for discussion of common problems in the
development and operation of space data systems. It is
currently composed of ten member agencies, twenty-three
observer agencies, and over 100 industrial associates. Since
its establishment, it has been actively developing
Recommendations for data- and information-systems standards
to:
- Reduce the cost to the various agencies of performing
common data functions by eliminating unjustified project-
unique design and development;
Feighery Expires - April 2004 [Page 2]
IP over CCSDS October 2003
- Promote interoperability and cross support among
cooperating space agencies to reduce operations costs by
sharing facilities.
To date more than 200 missions have elected to fly with CCSDS
protocols and have realized the benefits: reduced cost, risk
and development time, as well as enhanced interoperability and
cross-support.
1.2 CCSDS Publications
CCSDS publishes recommendations for protocols to effect free-
space communications, both in the radio frequency (RF) and
optical bands. These recommendations apply to both space-to-
ground links and space-to-space links. These protocols make no
attempt to directly utilize terrestrial subnet protocols.
Instead, CCSDS has produced specialized protocol
recommendations that ensure optimum subnetwork performance in
the demanding space communications environment. The space
community has wholeheartedly embraced these recommendations,
resulting in global interoperability between spacecraft and
earth stations.
CCSDS' optimization approach is consistent with that adopted
elsewhere in the networking community. Each subnetwork in an
end-to-end communications path adopts protocols dedicated to
the medium or communications environment. A route may involve
any number of subnetwork protocols (e.g. 802.11, Ethernet,
PPP, ATM) with interoperability and end-to-end delivery
achieved via the overlaying Internet Protocol (IP).
CCSDS has a number of subnetwork solutions for different
environments. They are:
'Packet Telemetry(TM)[3]' for telemetry downlink from the
majority of spacecraft
'Packet Telecommand(TC) [4]' for telecommand uplink to the
majority of spacecraft
'Advanced Orbiting Systems (AOS) [5]' used for downlink
from high data rate, high visibility spacecraft (e.g.
Envisat, International Space Station)
'Proximity One (Prox-1) [6]' for low power links in deep
space missions. Proximity One is symmetrical in uplink and
downlink and is favored as a possible integrated solution
for all future missions
Feighery Expires - April 2004 [Page 3]
IP over CCSDS October 2003
Spacecraft Onboard Interface Systems (SOIS) is the term for
activities of a CCSDS working group producing recommendations
for the internal communications onboard spacecraft. The
recommendations will address the use of commercial off-the-
shelf local area networks and also the specialized Spacewire
high speed protocol. SOIS is looking at a number of different
link and network layer technologies.
2. Encapsulating Internet Protocols within CCSDS
This section describes how both IPv4 and IPv6 packets can be
encapsulated in CCSDS Space Data Link Layer protocols,
including telecommand, telemetry, and proximity-1.
2.1 IPv4 Encapsulation within CCSDS
All of the CCSDS protocols directly support IPv4 and can carry
IP packets without the need for any kind of intervening
convergence layer. Telecommand and Telemetry use the first 3
bits of the source data field to identify the encapsulated
protocol. Using this technique, if the first 3 bits of the
source data are 010 the encapsulated packet is treated as an
IPv4 packet. Note that the first four bits of an IPv4 packet
contain the IP version number (0100 for IPv4). Proximity-1
uses a 3-bit 'virtual port' identifier to demultiplex data to
higher layers. AOS uses a technique similar to Telecommand
and Telemetry, with the IP packet encapsulated using the AOS
multiplexing service [section 5.3.6.2.c of 5].
Telmetry and AOS frames can accommodate full-sized IPv4
packets in single CCSDS data link layer frames. Telecommand
frames contain a 10-bit length field, but a single IPv4
datagram can be split across several TC frames and reassembled
before being demultiplexed to IP at the destination.
Proximity-1 frames use an 11-bit frame length field, but can
also split a single IP datagram across several Prox-1 frames.
Thus TC and Prox-1 allow for transparent link level
fragmentation and reassembly of IPv4 packets.
2.2 IPv6 Encapsulating within CCSDS
Some protocols, including IPv6, are not directly transferable
with CCSDS data link layer protocols. To accommodate the
delivery of IPv6 datagrams using CCSDS data link layers, CCSDS
has developed a generic encapsulation service [7] The
encapsulation protocol contains a 3-bit protocol identifier
field that identifies the encapsulated protocol. The binary
value of 100 has been standardized in [8] to denote IPv6. The
encapsulation protocol also allows for up to 32 bits to
Feighery Expires - April 2004 [Page 4]
IP over CCSDS October 2003
identify the length of the encapsulated packet. Proximity-1
frames can carry IPv6 packets without an intervening
encapsulation layer by designating a particular virtual port
identifier to be the IPv6 process on the destination machine.
2.3 Address Resolution and Channel Assignment
One issue when forwarding IP datagrams is determining the
correct data link layer address of the next IP hop. Many
shared media subnetworks (e.g. Ethernet) define protocols that
allow link endpoints to automatically determine data link
addresses given an IP address, a process referred to as
address resolution. Other link layers, such as the Point-to-
Point protocol (PPP) have no such address resolution protocol,
relying instead on pre-configuration of the link endpoints.
Address resolution protocols generally rely on the existence
of a link layer broadcast address. The resolver can then
transmit a request to this broadcast address that is answered
only the the resolvee. In the CCSDS protocols, the data link
layer address is defined by the GSCID. There is currently no
broadcast GSCID defined in CCSDS. That is, there is no GSCID
that, if used as the destination of a telemetry, telecommand,
or prox-1 frame, will be processed by all receivers. If in
the future an address resolution capability is desired, CCSDS
should consider the allocation of a broadcast SCID.
Within the CCSDS link layer protocols, the GSCID concatenated
with the virtual channel ID (VCID) (abbreviated as GVCID) is
used to identify the channel over which data is to be
transferred, including the link-layer destination. This
document assumes that there is a mapping between next-hop IP
addresses and GSCIDs. How that mapping is instantiated and
maintained is outside the scope of this document, and static
configuration is an option.
3. Interaction with Higher Layers
3.1 Transport layer Encapsulation
TCP, which provides a reliable in-order mechanism for
transferring data between systems without duplications, has
become ubiquitous throughout the Internet. Unfortunately, TCP
experiences performance limitations when operating over
satellite and other stressed environments. The IETF
documented some of these concerned in RFC 2488 entitled
ôEnhancing TCP Over Satellite Channels using Standard
Mechanismsö.
Feighery Expires - April 2004 [Page 5]
IP over CCSDS October 2003
The SCPS Transport Protocol [9] defines a set of extensions to
TCP to increase performance in stressed environments. In
particular, SCPS-TP can be configured to run with alternate
congestion control mechanisms in environments where it is
appropriate. The TCP Vegas congestion control mechanism is
appropriate where different end-to-end paths share common
resources. The pure rate control (i.e. no congestion control
per se) variant can be used if the connection has dedicated
resources.
Internet transport protocols (including TCP and UDP) are
encapsulated inside IP packets. Neither TCP nor UDP depend on
the framing used to carry IP packets. Thus if IP is used over
CCSDS data links, all upper-layer protocols that use IP
(including TCP and the SCPS-TP extensions) can be used with no
modification. Similarly, application protocols such as ftp
and http are encapsulated inside TCP/UDP, and are unaffected
by the choice of data link layer.
3.2 Maximum Transmission Unit
When one IP host has a large amount of data to send to another
host, the data is transmitted as a series of IP datagrams. It
is usually preferable that these datagrams be of the largest
size that does not require fragmentation anywhere along the
path from the source to the destination. Fragmentation occurs
when an IP datagram is too large to be transmitted atomically
via a particular link layer protocol. The largest datagram
that can be transmitted end to end is referred to as the
pathÆs Maximum Transmission Unit (or PMTU), and is equal to
the minimum of the link MTUs of each hop in the path.
TCP defines the Maximum Segment Size (MSS) as the maximum
amount of data that can fit into a full sized segment. The IP
datagrams carrying fill-sized TCP segments are generally 40-52
bytes larger than the MSS (to account for the TCP and IP
headers). While CCSDS links can accommodate maximum sized IP
segments, they may choose to limit the MTU of particular links
to smaller values. Applications using TCP over CCSDS links
should use the MSS option as defined in RFC 793 to try to
prevent fragmentation.
3.3 Link Reliability Mechanisms
RFC 3155, "End-to-End Performance Implications of Links with
Errors" discusses specific problems related to high bit error
rates and the performance of the TCP protocol. A TCP sender
adapts its use of network path capacity based on feedback from
the TCP receiver. As TCP is not able to distinguish between
Feighery Expires - April 2004 [Page 6]
IP over CCSDS October 2003
losses due to congestion and losses due to uncorrected errors,
it is not able to accurately determine available path capacity
in the presence of significant uncorrected errors.
3.3.1 Forward Error Correction (FEC)
The Proximity One protocol contains powerful Forward Error
Correction (FEC) Code. The FEC will reduce the probability of
a packet drop at the network layer. This will result in fewer
lost packets at the transport layer, thus not degrading the
performance of TCP.
3.3.2 Data Link Retransmissions
RFC 3366, "Advice to link designers on link Automatic Repeat
reQuest (ARQ)" provides advice to the designers of digital
communication equipment and link-layer protocols employing
link-layer ARQ techniques. The CCSDS Telecommand and
Proximity One protocols incorporate automatic retransmission
features that could be used to eliminate bit errors in these
subnetworks. However, link-layer ARQ introduces unpredictable
and potentially long delays in packet delivery that will
interact with TCP timers to seriously degrade communications
efficiency and is not a recommended approach. Note that the
unpredictable delays of link layer ARQ are different than
Prox-1's FEC, which imposes a fixed delay. For future uplinks
supporting TCP, the use of Proximity One with FEC should be
preferred over Proximity One or Telecommand with ARQ.
Security Considerations
This document does not introduce any new security issues.
CCSDS links are generally deployed in highly controlled
environments, and it is assumed that network access to the
point of presence is provided via secure boundaries.
References
1 Bradner, S., "The Internet Standards Process û Revision 3",
BCP 9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
3 CCSDS 102.0-B-5. Packet Telemetry. Blue Book. Issue 5.
November 2000
Feighery Expires - April 2004 [Page 7]
IP over CCSDS October 2003
4 CCSDS 202.0-B-3. Telecommand. Blue Book. Issue 3. June
2001.
5 CCSDS 701.0-B-3. Advanced Orbiting Systems, Networks and
Data Links. June 2001.
6 CCSDS 211.0-B-2. Proximity-1 Space Link Protocol -- Data
Link Layer. Blue Book. Issue 2. April 2003.
7 CCSDS 133.1-R-1. Encapsulation Service. Red Book.
Issue 1.1. April 2002
8 CCSDS 135.0-R-1. Space Link Identifiers. Red Book
November 2000
9 CCSDS 714.0-B-1. Space Communications Protocol
Specification (SCPS) Transport Protocol.
Author's Address
Patrick Feighery
The MITRE Corporation
7515 Colshire Drive
McLean VA 22102
Email: feighery@mitre.org
Feighery Expires - April 2004 [Page 8]
