NASA MSFC Mission Operations Laboratory MSFC NASA MSFC Mission Operations Laboratory Cadre Currency Training: Ku Forward Capability and Operations – Phases I/II/III Last updated July, 2015

NASA MSFC Mission Operations Laboratory MSFC Page 2 Course Objectives  This course will:  Describe Ku forward capability  Explain Ku forward planning and real-time operations  Identify approved protocols  Describe Planning Requirements  Provide information about Ku Forward Phase I/II/III testing and upcoming documentation updates Payload Users Cadre Users  Safety Constraints

NASA MSFC Mission Operations Laboratory MSFC Page 3 Ku Forward Capability Summary  The ISS Ku Forward capability (a.k.a. OCA) used internally by MCC-Houston to support systems activities (e.g. plan uplinks) is being extended for use by the POIC Cadre and PD teams  Ku Forward allows users access to devices connected to the Payload LAN  Ku Forward uses standard Internet Protocol (IP) communication protocols.  Primary communication (command) path for majority of payloads is still S- Band commanding, and Ku Forward commanding will be assessed on case- by-case basis  Ku Forward “commands” are not defined in the Command & Telemetry Database and do not go through command server or any MDM for uplink/execution.  Hazardous and Critical commands will not be sent via Ku Forward and can only be sent by the PRO via S-band.  ISS Program has defined an approved set of standard IP communication protocols that are allowed

NASA MSFC Mission Operations Laboratory MSFC Page 4 Ku Forward Capability Summary (cont.)  Remote Payload User use of Internet Protocols to access their payloads  Pings and Remote Desktop  Secure Shell  File Uplinks  Access to CCSDS File Delivery Protocol (CFDP)  Payload use of the Ku Forward capability will be identified in their Payload Integration Agreement (PIA)  ISS Program (PSRP) will define any unique safety requirements pertaining to a Payload’s use of Ku Forward as part of the payload Safety Review process  POIC will manage/control Payload User access to the Ku Forward Capability in real-time via HOSC provided tools and our standard planning and real-time processes  PRO manages access in real-time via Command User Enablement Tool  DMC manages resource allocation  HOSC has developed a secure plan for remote Payload User access to Ku Forward  HOSC requires two factor authentication to their servers  Users can only access specific, approved destinations using preapproved IP protocols  Provides POIC FCT enable/disable control over these protocols

NASA MSFC Mission Operations Laboratory MSFC Page 5 HOSC Implementation in III Phases  Phase I ~ July 2014  POIC Cadre use of Internet Protocols to onboard devices Ping to Express Laptops, PEHG HRDL Gateways Remote Desktop to Express Laptops File Manipulation on EXPRESS Laptop Computers (ELC) (rename, copy, move, etc.) File Transfers from SSC Server (after JSL/SSC V5 onboard)  Capability was put in place post Inc. 40 transition and implementation of Chit (PEHG configurations)  Phase II ~ November 2014  CFDP available for cadre use, such as ELC file uplinks/downlinks  Includes PD team use of some Internet Protocols to communicate with their payloads  Phase III ~ Mar 2015  Full use of HOSC approved protocols

NASA MSFC Mission Operations Laboratory MSFC Page 6 Ku-Forward Payload Scenario Payload Ground Site Payload System Configured to communicate on the Payload LAN Running Secure Shell, CCSDS File Delivery Protocol, Remote Desktop, and/or Payload custom protocol Payload System Configured to communicate on the Payload LAN Running Secure Shell, CCSDS File Delivery Protocol, Remote Desktop, and/or Payload custom protocol User Actions Authenticates to EHS If authorized for Ku-Forward service, user will connect to the HOSC Payload Ethernet Gateway (HPEG) A list of user destinations and their respective protocols is returned to the user interface User will select a destination and start the session Using the Proxy IP Address returned the user will initiate the application they wish to use for that session Sessions are preserved across LOS windows When finished user will stop session HPEG checks for inactivity and will prompt user to reply. No reply will lead to a disconnect from HPEG User Actions Authenticates to EHS If authorized for Ku-Forward service, user will connect to the HOSC Payload Ethernet Gateway (HPEG) A list of user destinations and their respective protocols is returned to the user interface User will select a destination and start the session Using the Proxy IP Address returned the user will initiate the application they wish to use for that session Sessions are preserved across LOS windows When finished user will stop session HPEG checks for inactivity and will prompt user to reply. No reply will lead to a disconnect from HPEG POIC MCC WSC ISS RIC CDP Ku Comm Unit Payload PEHB PDSS ePVT HPEG eFDP

NASA MSFC Mission Operations Laboratory MSFC Page 7 Packet Routing Example  This diagram shows the process to get packets properly routed from the user to the onboard destination and back to the user  To make the connection possible without violating security requirements, the HPEG uses a process called Network Address Translation (NAT) to automatically change the addresses in the user’s source IP packet from the secret address to the public address  During the uplink, the HPEG Proxy IP address is changed to the Onboard Destination IP address  During the downlink, the Onboard Source IP address is changed to the HPEG Proxy IP address

NASA MSFC Mission Operations Laboratory MSFC Page 8 Verification and Testing Results  Phase I testing summary  DMC verified Ping functionality to the PEHG-1, PEHG-2, and COL PEHG  PRO verified Ping and RDP on Express Laptop 1  AMS will use SSH to the AMS Laptop as a pathfinder  At this time, ER1 and ER2 laptops have completed Phase 1 checkout. It is likely that by the time this presentation is read by a trainee, more laptops will have completed Phase 1 checkout.  Phase II testing summary  DMC verified Remote Desktop functionality following install of Network Monitoring System onboard  PRO verified CFDP functionality on the Express Laptop Computers by uplinking and downlinking files to and from the laptop.  PRO verified drive mapping functionality on the Express Laptop Computers by uplinking and downlinking files to and from the laptop.

NASA MSFC Mission Operations Laboratory MSFC Page 9 Cadre Use Cases  PRO will use Ku Forward to perform file uplinks to EXPRESS Laptops during Phase II  DMC plans to execute pings to onboard equipment as necessary during phase II operations and beyond. Additionally, DMC expects to utilize Remote Desktop to access the Network Monitoring System laptop following its install in late-2014/early-2015  If a user is having difficulty connecting to their destination, DMC and PRO will attempt to identify whether the issue is an onboard configuration issue or a ground systems issue. If the issue is onboard, PRO and DMC will use standard anomaly resolution methods and procedures to identify and correct the problem. If the connection problem is identified as a ground systems issue, the problem will be turned over to Marshall Data and the IST  After doing Phase I checkout on an EXPRESS laptop, these operations are possible:  Start/stop payload applications on EXPRESS laptops  Copy/rename/delete files as needed  Troubleshooting laptop connectivity (ping or just trying to log in)  In the future:  When RIC Release 9.2 is loaded on a rack, we will have to use Ku Forward for file downlinks from that laptop (this should be fixed in Release 10)  File uplinks for PDs that do not have File Authorization Table (FAT) names or that have files to big to go through PLMDM (8MB limit)  Payload Application installation on laptops  Virus definition updates on laptops

NASA MSFC Mission Operations Laboratory MSFC Page 10 Payload Users To use Ku Forward capabilities payloads are required to request the service in their provide/update PIA, submit safety re-flight/flight assessment, and provide required verification data. and show that they are on-board IT security compliant. The following Payloads are approved to use Ku Forward services: (ESA payload’s are not listed in the Payload Reg)Payloads that are currently interested in using Ku Forward capabilities:  AMS  ESA’s Meteron  Cold Atom Lab  FCF  SAMS  STPH-5  ISERV  CREAM  MUSES  NanoRacks  SABL  METERON OPSCOM Missions  Plant Habitat Note: AMS is the only payload apprNo payloads are currently approved

NASA MSFC Mission Operations Laboratory MSFC Page 11 Ku Forward Documentation Requirements  Payload Developers have to meet the following requirements prior to receiving OZ approval for Ku Forward services that the PIM is tracking:  Present at ASCB (Avionics and Software Control Board)  PIA approval with requested Ku Forward  Ku Forward requirements baselined  Ku Forward safety Memo submitted and accepted by PSRP (verification data submitted and approved; the software commands issued to payload software cannot create a hazard, and do not control a safety hazard)  Approval includes the removal of the Ops Constraint by SE&I, except for payloads that will use ESA Ku Forward service  Documentation: PSRP memo titled Payload Ku Forward Command/Operations Restrictions and SSP 52050, International Standard Payload Rack to International Space Station, Software Interface Control Document Part 1.  Ku Forward Services Tracking Matrix can be found at: OZ6 Payload Integration Management under the header “Miscellaneous”  Additional PD input required but not drivers for KuFWD approval:  Blank book entries (incl. what type of IP PD wants to use for GDS configurations)  ICD/PIRN (required to be approved at least 2 weeks prior to testing for PD to develop test procedures that align with final set of requirements needing testing)  Payload Regulations (section 4. Restricted Ops & Constraints NASA Payloads Approved to Use KU Forward Capability)

NASA MSFC Mission Operations Laboratory MSFC Page 12 Ku Forward Planning  Ku Forward resource tracking  Ku Forward resources will be modeled on NASA payload activities Resources track against NASA payload allocation of Ku Forward bandwidth ESA activities will also utilize the Ku Forward resources in the future System/JAXA Ku Forward bandwidth is part of the “OCA” bucket that is set aside in DSRC/CPS  Ku Forward resources are not modeled for system and JAXA activities  NASA payload activities with Ku Forward resources will be included in the JSL CMD band on OSTPV  Flight Rules – will be updated as needed for specific payloads

NASA MSFC Mission Operations Laboratory MSFC Page 13 Ku Forward Planning (cont.)  PPO PPO provides temporal relationship only, hence:  no command windows for PRO required for KuFWD; only PD command windows are required in the timeline for KuFWD  no explicit reference to KuFWD on PPO  PARD/ PPS add JSL CMD and KU_BD in PPS’ event bands for OSTPV bands CPS Attributes for Data Resources/Activities in US Segment  OPS Notes for JSL CMD contains a description of the activity, activity owner, and if applicable a procedure reference. JSL Uplink (Ku Forward) JSL UPLINKUPLINKIP_RAWJSL2PL Rack ID* Data Return for JSL Uplink (Ku Forward) JSL DOWNLINK IP_VIA_ICUIP_RAWJSL2LNR or ANRN/A (leave blank) KuFWDResource/ Activity Name Data Path (defined inside the resource) Data Format LocationIf Data Destination is… Address is … Ku Uplink via JSL pooledISS DATA–JSL UPLINKJSL UPLINKData rate in Mbps (NASA payloads only) pooledISS DATA–TOTALDIGITAL TOTALData rate in Mbps pooledISS DATA–HIGH RATEJSL DOWNLINKData rate in Mbps

NASA MSFC Mission Operations Laboratory MSFC Page 14 Ku Forward Real-time Operations  Ku Forward communications operations are not “commanding” in the traditional sense  Enabling a user opens a port to the onboard LAN through the HOSC Payload Ethernet Gateway (HPEG)  Pathway is opened up for two-way traffic via Ethernet instead of commands directly through the 1553/MDMs to the payload hardware  There will NOT be “commands” listed on Command Track  PRO manages access to Ku Forward in real-time via Command User Enablement tool  Activities on the timeline are managed by our standard planning and real-time processes  Data Flow Management  Ku Forward activity will be shown in the Data Flow Plan (DFP)  Bandwidth allocation & management Total uplink bandwidth is 25 Mbps, shared across ISS users (systems and payloads) Initial plan is for 8 to 10 Mbps to be devoted to NASA payloads Bandwidth is monitored on a payload basis Payload Users are expected to monitor and control their own uplink bandwidth If a payload overruns its allocated bandwidth and impacts other users, DMC will notify POD/PRO and PRO will disable Payload User HPEG from service

NASA MSFC Mission Operations Laboratory MSFC Page 15 Ku Forward Real-time Operations (cont.)  Allocations  Total uplink bandwidth is 25 Mbps, shared across ISS users (systems and payloads)  Nominally 8 Mbps will be reserved for payload use – bandwidth is restricted by HPEG The rate is modifiable and eventually the Payload allocation may grow to 12 Mbps ESA will be allocated part of this bandwidth for their Ku Forward operations also when they start in 2015  Systems (OCA) gets the remainder which includes JAXA Ku Forward allocation

NASA MSFC Mission Operations Laboratory MSFC Page 16 Ku Forward Planning  Ku Forward resource tracking  Ku Forward resources will be modeled on NASA payload activities Resources track against NASA payload allocation of Ku Forward bandwidth ESA activities will also utilize the Ku Forward resources in the future System/JAXA Ku Forward bandwidth is part of the “OCA” bucket that is set aside in DSRC/CPS  Ku Forward resources are not modeled for system and JAXA activities  Modeling of Ku Forward resources begins with Phase II of the Ku Forward implementation plan Planning Data Sets for Increment 41/42 include Ku Forward resource modeling  NASA payload activities with Ku Forward resources will be included in the JSL CMD band on OSTPV

NASA MSFC Mission Operations Laboratory MSFC Page 17 Approved Protocols  The approved set of IP communication protocols are compliant with NASA IT Security Requirements  Approved protocols: SSH (Secure Shell), SCP (Secure Copy Protocol), FTPS (File Transfer Protocol Secure), RDP (Remote Desktop Protocol), HTTP (Hypertext Transfer Protocol), HTTPS (Hypertext Transfer Protocol Secure), CFDP (CCSDS File Delivery Protocol), BP (Bundle Protocol, use for Delay/Disruption Tolerant Network protocol - DTN), ICMP (Internet Control Message Protocol)  Prohibited protocols are FTP (File Transfer Protocol) and Telnet  HOSC is only certified for CFDP, HTTPS, ICMP, RDP, and SSH at this time

NASA MSFC Mission Operations Laboratory MSFC Page 18 Payload Safety Approach to Ku Forward  All Payloads that wish to utilize Ku Forward are required participate in a re-flight assessment with the Payload Safety Review Panel (PSRP)  Upon completion of the safety assessment, Payloads with no hazardous commands identified during the safety review process will have no constraints toward utilizing Ku Forward commanding capability  Payloads with hazardous commands identified must utilize the current service provided by the Payload Operations Integration Center (POIC) in which POIC is the sole source for hazardous commanding or operations  All Hazardous Commands must be S-Band commands defined in the POIC’s command database  Only the POIC PRO position will have access to those commands and will send those commands for the Payload Developer under the compliance of all Hazard Controls and Flight Rules  Payload Developers must prove through Hazard Report verifications that their use of KU Forward for all other non-hazardous commanding cannot result in a Hazardous Command being sent to the Payload  The POIC will also have the capability to inhibit the Ku-forward path for a payload during any potentially hazardous operations, such as Extra Vehicular Activity (EVA) or Visiting Vehicle proximity operations, as defined by the payload specific Hazard Controls and Flight Rules

NASA MSFC Mission Operations Laboratory MSFC Page 19 Documentation Updates Status  POH Vol 2 Standard Operating Procedure Updates  SOP 1.15 PEHG-1/2 FAILURE/LAN TRANSITION WITH JSL  SOP 1.21 KU COMM UNIT ANOMALY RESOLUTION  SOP 6.5 COMMAND LINK MANAGEMENT  Ground Command Procedures  DMC will start using RDP (Phase I capability) Remote Desktop Protocol to an onboard destination  POIC Ground Command Procedures Book Volume 2, Annex 5: EXPRESS/ARIS/WORF Ku Forward Procedures, All Flights 3.6 File Uplink Using Ku Forward  Generic OIP Payload Ku-band Internet Protocol Communication via JSL-2 Assets  Flight Rules – will be updated as needed for specific payloads

NASA MSFC Mission Operations Laboratory MSFC Page 20 Acronyms CCSDSConsultative Committee for Space Data Systems CDPCCSDS Data Processor CFDPCCSDS File Delivery Protocol CMDCommand CPSConsolidated Planning System DFPData Flow Plan EHSEnhanced HOSC System ELCEXPRESS Logistics Carrier EVAExtra Vehicular Activity eFDPexternal Functional Data Processor ePVTexternal PriVaTe LAN FATFile Authorization Table FCTFlight Control Team FTPFile Transfer Protocol GCPGround Command Procedures HPEGHOSC Payload Ethernet Gateway HRDLHigh Rate Data Link HTTPSHypertext Transfer Protocol Secure ICMPInternet Control Message Protocol IPInternet Protocol ISTIntegrated Support Team JSLJoint Station LAN LANLocal Area Network MDMMultiplexer/Demultiplexer NATNetwork Address Translation PDPayload Developer PEHGPayload Ethernet Hub Gateway PIAPayload Integration Agreement PDSSPayload Data System Services RDPRemote Desktop Protocol RICRack Interface Controller SSHSecure Shell WSCWhite Sands Complex