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]