1 / 43

IP in Space Green Book v0.1

IP in Space Green Book v0.1. Rationale, Scenarios, and Profiles for the Application of the Internet Protocol Suite (IPS) in Space Operations. IP in Space Green Book: Overview. Rationale, Scenarios, and Profiles for the Application of the Internet Protocol Suite (IPS) in Space Operations - v0.1

tanith
Download Presentation

IP in Space Green Book v0.1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IP in Space Green Bookv0.1 Rationale, Scenarios, and Profiles for the Application of the Internet Protocol Suite (IPS) in Space Operations

  2. IP in Space Green Book: Overview Rationale, Scenarios, and Profiles for the Application of the Internet Protocol Suite (IPS) in Space Operations - v0.1 - Discusses current, planned and possible future uses of the Internet Protocol (IP) as part of Space Operations • Focuses on a specific Design Reference Mission (DRM) – Human Space flight (HSF) in Low Earth Orbit (LEO) • Attempts to capture lessons learned from the Constellation Program • Green book content aligns with objectives 4-7 of the IP over CCSDS Space Links WG charter Address residual IPO Charter Objectives Capture Constellation Program lessons learned

  3. IP in Space Green Book: Organization 1.1 Introduction: Purpose and Scope 2.1 Overview: Background 3.0 Scenarios 3.1 Terrestrial applications of IP in Space Ops 3.2 Use of IP within the cabin/habitat 3.3 Application of IP between spacecraft an other systems 3.4 IP in Lunar and planetary surface Missions (TBD) 3.5 Operation and Management of the network (incomplete) 4.0 Protocols and Application Profiles 4.1 IP Protocol Layers (Network Layer Up) 4.2 IP Datagram Forwarding 4.3 Network Layer Security 4.4 Operational Configurations Appendix A-1: Transporting IP over CCSDS Links Appendix A-2: Applicability Matrix for CCSDS Blue books Appendix A-3: Applicability Matrix for IETF RFCs (incomplete) Scenario based capture how IP is (or proposed to be) used

  4. Scenarios for LEO DRM How IP is used within the Control Center, the Cabin environment and on the Spacelinks is different

  5. 3.1 Terrestrial applications of IP in Space Ops • The terrestrial environment is split into two spheres of the application of IP: Communication within the control center and communication between the control center and ground station (and other ground destinations) • The main point of this section is that nearly the full range of the IP suite is available for ground-to-ground communication, and that IP is not only an appropriate solution for all phases of ground comm, but virtually unavoidable for some aspects such ground station to control center return data forwarding. IP is widely used for communications with the Control Center and within the Control Center

  6. 3.2 Use of IP with the cabin/habitat • There is an assumption of multiple endpoints within the spacecraft in order to take advantage of internetworking. • Common IP equipment, such as laptops, make their way into habitable environments. • For communications not limited by space links, the full range of IPS is available for use • For communication which must use the space link, limitations apply (see the next section). COTS products and IP can be leveraged for crew support functions

  7. 3.3 Application of IP between spacecraft an other systems (1) 3.3.1 Potential Advantages for use of IP in Space – Why use IP? • If custom developments are possible, many of the suboptimal aspects of adopting IP to space could be addressed directly – however maturing a complex communications protocol is costly and takes time. • Use of IPS opens the door to the leveraging fully developed COTS available software for addressing, name resolution, traffic prioritization, multiplexing at multiple layers, standard interfaces to data link layers, static and dynamic routing, mobility, management protocols, multicast, support for real-time applications and security. • Even over space links • Crew can use IP for non-critical apps without additional training • Payload operators can operate end-to-end without protocol conversion • Real-time apps (e.g. voice) and support protocols (e.g. RTP) require tuning, but limited software development • If the space link can be considered constant (two-way) then operations can take advantage of addressing, traffic prioritization, multiplexing, static routing, standard interfaces, multicast and security • For mission phases where the spacecraft is docked or on the launch pad, the full suite is available for use Leveraging IP where appropriatecan save cost and schedule

  8. 3.3 Application of IP between spacecraft an other systems (2) 3.3.2 Programmatic Constraints of Leveraging IP • Programs and spacecraft designers take a minimalist approach to software • If controllers won’t change control approaches to simplify operations through IPS (e.g. route failover, traffic prioritization) then advantages will be limited • There is currently no entity prepared to support IP routing at the ground station 3.3.2.1 Custom Space Router • Every implementation of IP in Space for HSF so far has included a router which also includes unique application gateway functions, because the operations within the spacecraft is not IP. • The custom space router approach prevents the potential huge savings of buying a COTS device adapted by the vendor for space 3.3.2.2 Ground Station Communication Options • Use of SLE to “extend the link” removes the concept of routing at the ground station • Routing at the ground station permits the building of complex space network in which remote operators, control centers, ground stations, spacecraft, and end devices become location independent. Programmatic Constraints and Limitations exist

  9. 3.3 Application of IP between spacecraft an other systems (3) 3.3.3 Limitations of IPS in Space Environments The unique nature of space communication is often raised as a concern to extending IP, developed for terrestrial use, into the space communication. Section 3.3.3 address the issues raised by each concern. 3.3.3.1 Intermittency : (Illustrated for DRM) 3.3.3.2 Mobility: TDRSS handovers (DRM) 3.3.3.3 One-way Links: Want communications to maintain at least one-way communcations if links become one-way links 3.3.3.4Parallel connections and routing: In HSF, considerations are made to split traffic on multiple available links by application. In IPS, forwarding is done mainly by consideration of the IP address. To accommodate IP forwarding end systems use multiple addresses and associated an app with a particular address by configuration. Use of multiple addresses also allows for automated failover between the links. Space Operations include environments for which IP has not been matured

  10. 3.3 Application of IP between spacecraft an other systems (4) 3.3.3.2 Mobility: Environments heavily invested in SLE will have difficulty making use of protocols to automate connectivity such as Mobile IP and routing protocols. 3.3.3.3 One-way Links: Some protocols in IPS require a handshake to function. Several are examined in this subsection. However, the rarity of the occurrence of a one-way link in HSF, calls the constraint into question as a major design consideration . TCP: Will not function over a one-way link, but also a poor choice on lossy or high-latency links. TCP is avoided for apps that must work between space and ground. IKE: Crucial to implementation of IPSec in space, IKE does require a handshake. However, existing IPSec tunnels can continue to function for any specified period following drop in a single direction. As implemented currently by vendors, IKE functions poorly (tends to timeout) over space links. However, this is not a problem with the IKE protocol, only vendor implementation. Routing Protocols: Where one-way links could be expected, routing protocols would not be useful. However, routing protocols would continue to be useful over the portions of the network not subject to one-way outages. IPHC: Header compression handshakes are a problem on one-way links, because all vendor implementations use a link layer negotiation to ensure that link partners have compatible configurations. However, communication will not fail on one-way links. Header compression will cease. RTCP: A subprotocol of RTP to support performance optimization, sudden loss of RTCP due to a one-way outage will not adversely impact the remaining communication. Apps using RTP will continue to function, regardless of RTCP. Examples of IP protocol adaptation for one-way links

  11. 3.4 IP in Lunar and planetary surface Missions • (TBD) Skip?

  12. 3.5 Operation and Management of the network • This section is still under development. Network Operations and Management should also be a subject area under each communication scenario: ground based, intra-vehicle, space-to-ground, and planetary surface. However, something still should be said about unifying a network composed of some or all of these scenarios. Incomplete

  13. 4.0 Use of IPS with HSF for DRM • The capability discussed in this section provides IP datagram transport with limited routing and Quality of Service over space links for operations. • The following capabilities were leveraged/tailored • Unicast and multicast • VoIP, G.729 • Quality of Service • Header compression • Static IP addressing and routing • Profiles for IP protocols reflect RFC compliant subsets that were selected to work over one-way links and tolerate the anticipated intermittencies. • Mobility addressed “at layer 2” for TDRSS-like satellite handovers in orbit • Leveraged the planned infrastructure below the IP layer providing concurrent redundant AOS frame transport between all necessary ground stations and mission controls. • Recording of the RF links in the design reference mission was used to avoid having the IP network ensure that all signals sent from space would be retrievable Concepts for Leveraging IP for Operational Link Applications for HSF

  14. 4.0 Use of IPS with HSFVoice Loops and Telemetry volume • Voice Loops are supported over the operational link • G.729 (quality bandwidth efficient vocoder) is transported over the IP operational network. • Several vocoder frames were grouped into an IP packet (e.g. 100 ms “ptime”). • Jitter buffers were sized to accommodate higher levels of jitter and playout times were controllable form the ground. • Voice activation is supported (silence suppression was not). However, during critical mission phases, mission controls would continue transmitting voice packets even when the person designated to speak on the air ground loop at the control center was not keyed to talk. • For the DRM, performance monitoring and optimization was done via the telemetry processing and display system rather than utilizing RTCP. • QoS to support voice • Mission Controls is assumed to oversee the data scheduled on the uplink to ensure it isn’t oversubscribed • Discussions did indicate the need for protocols at the SLE and IP layers to cover shorter term jitter/aggregation. • Use of DiffServ Expedited Forwarding / Assured Forwarding • Header Compression to support telemetry volume on low rate links • Header compression is defined to address the IP overhead issue on low rate operational links. • Header compression capabilities can be costly if they have to be implemented in hardware, so significant work was needed to select an appropriate sub functionality that was robust. • For the DRM, the need for actually implementing the IP header compression protocols was balanced against the telemetry volume reduction the IP headers would imply during the critical mission phases such as ascent. Voice, Telemetry and Commanding multiplexed over IP Space links

  15. 4.0 Use of IPS with HSFAddressing, Routing • Unicast and multicast were defined • Multicast allows bandwidth savings in limited configurations - the same telemetry streams or a voice loop data from a spacecraft can be processed by both control center and launch control • For the DRM, Mission Controls will process all spacecraft data and disseminate it in post-processed form. • Mission Control traditionally ingests telemetry and voice loops, and makes them available in calibrated form to other parties over IP networks. Voice is similarly disseminated between terrestrial participants using T1/E1 DS0 channels. • Static IP addressing and routing for the initial design reference mission. • These parameters are controlled in a manner similar to other link parameters Concepts for Leveraging IP on Operational Link for addressing and routing

  16. 4.0 Use of IPS with HSFSteps past DRM? • Most of these limitations/tailoring can become counterproductive as more complex mission phases are approached. • Having statically configured parameters will at some point reduce reliability due to misconfiguration, and the personnel overheads required to oversee them also become large. • To allow link controls, mobility and routing to do their job requires a high degree of trust in them to respond correctly in the environments encountered. Extensive experience with these environments, and lab equipment with flight like settings do not exist, but current thoughts are discussed in the fourth scenario. • Finally, note than DTN will be picking up some of the needs for the future design reference missions. Many dynamic natures of the protocols are good --- once we’ve acquired trust in them

  17. 4.1 IP Protocol Layers IP, UDP, RTP, CFDP RFCs applied to space ops

  18. 4.2 IP Datagram Forwarding RFCs applied to space ops

  19. 4.3 Network Layer SecurityIPsec, SHA-256, AES, 3-DES, ESP, GCM, IKE RFCs applied to space ops

  20. 4.4 Operational ConfigurationsICMP, Header Compression, DiffServ, SNMP RFCs applied to space ops

  21. Appendix A-1: Transporting IP over CCSDS Links • IP protocols actually depend on control protocols that have to be separately identified at the link layer. • Suggests simply encapsulating the link layer used at the routers egress in CCSDS ENCAP has significant merits. • The down side is that the link layers used in spacecraft would not be forced to be interoperable because they are router dependent, and because CCSDS already defined packet encapsulation, the approach chosen was to use AOS/ENCAP as the CCSDS standardized method of transporting IP datagrams between routers. • Agreed to use AOS/ENCAP with IPE shim (See CCSDS 135.0) • A link layer translation bridge was required on the ground. • This is shown in Figure 7. • The reliability of a custom developed bridge in a human spaceflight environment was a point of discussion. • The desire was to make the bridge translation functions as simple and stateless as possible. • However, the bridge will have to provide some form of support for certain link layer protocols, such as header compression. CCSDS has it’s own link layer for IP

  22. Appendix A-1: Transporting IP over CCSDS Links Approach requires “bridging” link layer used by COTS router

  23. Appendix A-1: Transporting IP over CCSDS LinksApplication of IPE/ENCAP/AOS • A further discussion involved how projects interpreted the CCSDS link layer specifications. Several issues were debated. • MTU size and ENCAP headers • CCSDS does not have a maximum transmission unit (MTU) size inherit in the link – progressively larger ENCAP headers are used. • No project opted to support the largest ENCAP header size. • Some projects decided not to support the small ENCAP header size. * • IPE Shim • The IPE shim is defined to be extensible by using the low bit to signal extensions. • All needed IPE protocols were covered with a single byte, so no project opted to implement the extension capability in their hardware. • AOS frame processing • The placement of IP packets in AOS frames was another discussion. • In an actual implementations, the data is pulled and then an AOS frame is constructed. • If at that moment, there is not enough data to fully populate the AOS frame, there frame will be constructed as is. • The implication is that once ENCAP idle packets start, no useful data will follow in that frame. • For this reason, projects declared that upon finding and ENCAP idle, they’d stop processing the rest of the AOS frame. • IPE vs. IPv4/6 vs. Native IPv4 • There originally were multiple ways of putting an IP packet into an AOS frame. • Recently the CCSDS deprecated all but one approach, justifying projects that had opted to only include the IPE approach. *It is noted that the above implementation choices actually can hurt interoperability. An example is a system that generates 2-byte encap headers when small IP packets are encountered, but a receiving system that only understands 4-byte encap headers. Programs applied CCSDS IPO standards

  24. Appendix A-2: Applicability Matrix for CCSDS Blue books – CCSDS 133.1 CCSDS standards supporting IP for space ops

  25. Appendix A-2: Applicability Matrix for CCSDS Blue books – CCSDS 732.0 CCSDS standards supporting IP for space ops

  26. Appendix A-3: Applicability Matrix for IETF RFC 2507 example

  27. Appendix A-3: Applicability Matrix for IETF RFC 2508 example

  28. Appendix A-3: Applicability Matrix for IETF RFC 3551 example

  29. Conclusions • The IP in Space Green Book doesn’t currently have a conclusion section, but if it did, it might be: • IP is an integral part of current space operations • Use of IPS, as the world’s most widely deployed internetwork layer protocol suite, has the potential to provide significant savings over custom end-to-end solutions (especially for HSF). • While more investigation is required in some areas, issues surrounding the use of IP in space can be addressed by CCSDS blessed tailoring of IETF specs

  30. Comments Received (1) From Bob Durst: • Requirements vs. profile “I think that Section 4, rather than being a Profile (see note about reserved words in 1, above) is, or could be, the requirements that you place on the IP implementation supporting each of these scenarios.  • Response: Yes, it is appropriate to recast the requirements in terms of each of the scenarios. Could do so in next version. • Section 3.5 “ … goes on to discuss Operation and Management, which seems like that should be one aspect of the various other scenarios rather than its own section.” • Response: There is a brief discussion on operations and management and management considerations each section. There are some aspects of network operations and management that are applicable across scenario boundaries, such as managing an IP spacecraft link or IP spacecraft internal network from a control center. Action to reword for distinction and clarity.

  31. Comments Received (2) From Bob Durst (continued) • Section 3: “.. level of detail within each of the main subsections is pretty different. ..might make things a bit more consistent...scope of IP application, types of data carried, user performance/service requirements for each type of data, mapping onto underlying links, connectivity patterns, particular constraints, etc.” • Response: Agree that consistency of information for each scenario is appropriate. Detail may vary, but type of info should be consistent. • “Diagram at start of section three that doesn’t belong to all the scenarios…” • Response: The intention of Figure 1 is to show all scenarios in a single end-to-end communication path, in which design choices are available. The graphic will be revisited to improve clarity.

  32. Comments Received (3) • From Keith Scott “… in short I think the current draft leans too heavily towards rationale and not enough towards pulling requirements out of the scenarios. ” - Response: Agreed. As written this book doesn’t fit any CCSDS document mold. It should be rewritten as a true green book for IP, with specifications going into a corresponding magenta book, or as a white paper documenting Constellation Program experiences.

  33. From the SIS-IPO Working group charter:The IP over CCSDS Space Links WG will have the following objectives: (1) 1) Describe the recommended method(s) of transferring IPv4, IPv6 and compressed IP header datagrams over the four underlying internationally standardized CCSDS link layer protocols: – TM Space Data Link Protocol – TC Space Data Link Protocol – AOS Space Data Link Protocol – Proximity-1 Space Data Link Protocol • [Proposed Completed – CCSDS 702.1-R-4]

  34. From the SIS-IPO Working group charter:The IP over CCSDS Space Links WG will have the following objectives: (2 & 3) 2) Recommend the standard CCSDS options for carrying IP datagrams within those CCSDS frames, including the mode where those IP datagrams under go header compression. • [Proposed Completed- CCSDS 702.1-R-4] 3) Utilize the “IP over CCSDS Links BOF” Concept Paper (http://public.ccsds.org/sites/cwe/sis-ipo/default.aspx) as the framework for the content of the CCSDS IP over CCSDS Recommended Practice specification. • [Proposed Completed – CCSDS 702.1-R-4]

  35. From the SIS-IPO Working group charter:The IP over CCSDS Space Links WG will have the following objectives: (4) 4) Describe the application profiles that contain the appropriate CCSDS standards and IETF RFCs (Section 4.1) and associated options for management and operations (Sections 3.1.1, 3.1.2, 3.3.2.2, 4.4.3) of end-to-end IP networking over space links.

  36. From the SIS-IPO Working group charter:The IP over CCSDS Space Links WG will have the following objectives: (5) 5) Cover the configuration aspects (e.g., routers, switches) of set up and management of the elements of the IP internetwork in space. (Section 4.2)

  37. From the SIS-IPO Working group charter:The IP over CCSDS Space Links WG will have the following objectives: (6) 6) Include a description of the end-to-end security protocols and techniques for IP Internetworking in Space. (Section 4.3)

  38. From the SIS-IPO Working group charter:The IP over CCSDS Space Links WG will have the following objectives: (7) 7) Include a description of the operations engineering aspects, management practices and operability features that need to be engineered into the end-to-end IP network. (Section 4.4)

  39. Backup Charts • More 4.1 details

  40. 4.1 IP Protocol Layers

  41. 4.1 IP Protocol Layers

  42. 4.1 IP Protocol Layers

  43. 4.1 IP Protocol Layers

More Related