1. February 14, 2013 POIWG Technical Overview CR 13351 / HM-3430 Ku Forward Capability

2. February 14, 2013 HM-3430 Review Introduction Primary Objectives of changes being implemented 1. Do not deprecate any current capability 2. Add the capability to store all uplink and downlink data that is not APID defined (by network address) 3. Provide Ku band management capability 4. Map payload/APID/Source network address to users 5. Allow the uplink path to be user selected and provide status 6. Proxy HOSC users to interface with the MCC-H Communications Data Processor (CDP) 7. Provide a common platform onboard for file transfer 8. Develop an appropriate test environments for Development, Test, and Verification 9. Development of User interfaces for ISS to ground Apps 10. Provide upcoming payload projects an internet like, standards based, direct methods to access on-board experiments 2

3. February 14, 2013 HM- 3430 Introduction 3

4. February 14, 2013 Project Requirements Schedule PhaseDescriptionRequired DateDate Driver 1TCP access for Cadre to ISS Express Laptops and network devices, Video retrieval Enhancements ATP + 12 monthsInitial Cadre capability 2TCP access for remote users to their devices and cadre ability to move files via CFDP from HOSC EPC client ATP + 18 monthsCadre and initial remote user capability 3Remote user ability to move file via CFDP to their devices ATP + 24 monthsFinal capability implementation ATP of 01/03/2013 4

5. February 14, 2013 5 Point Architecture Custom controls are unique to each system – HOSC has implemented a four-tier architecture – Each tier has unique attributes which are critical to securing the user’s needs

6. February 14, 2013 What is the model for Payload LAN access via Ku-forward System Design HM 3430 Architecture

7. February 14, 2013 7  Ku forward access is to bring Internet protocols to the ISS payload investigators  Do not break the current uplink model, extend to ku-band – Metering the uplink rate to reflect the traffic model allowed for payloads – Mapping of user/payload to private IP address onboard for uplink Do not allow a user to access other than approved assets – Scanning of all uplink streams for virus and/or protocol – Operable view of uplink activity Independent control of each uplink Control of single payloads and groups of payloads – Stream (RT) uplink and staging of uplink (files) – Logging of uplink data – Interface to MCC-H CDP – Ability to proxy (NAT) uplink from a remote user to CDP System Design HM-3430 Architecture

8. February 14, 2013 8  Do not break the current uplink model, extend to ku-band (cont’d) – Mapping of users/payloads to private IP addresses onboard for downlink – Associate (map) private vehicle IP address to a payload/APID – Automated storage and retrieval of downlink data – Maintain the current capability of PDSS providing science data streams directly to users – Ability to proxy (NAT) downlink to a remote user – TCP for command line access – UDP for video/file transfers, etc. – ICMP System Design CR 13351 Architecture

9. February 14, 2013 9  Extend the architecture without new hardware  Manage Ku forward on the OPS/TST servers  Access HOSC ISS Systems via a new ERIS service on current ePVT and PVT servers  PDSS is primarily complete with ECR HM-3420  EPC will be extended to support a command App for ku access  TReK will be extended to support ku access  Programmatic interface to be identified in PGUIDD  Available for all non-EPC accesses System Design HM-3430 Architecture

10. February 14, 2013 10 Information Architecture Regimen Based Security Model  All users are not eligible for Ku forward service  Requested service  Explicitly defined by service  Tier 1 is the client level  Users most login to the fully qualified PGUIDD ERIS interface  User direct access shall be via an EHS Ku Proxy  IP and port shall be explicitly checked  Access via VPN  No special purpose application required  Tier 2 is an ERIS server  Internal users are hosted on PVT servers  External users access via ePVT servers  Users will be prompted with their allowed configuration as defined by UCM  A user will only be allowed access based on their allowed configurations  Ku Proxy will encapsulate the user traffic to their onboard platform once verification is complete  Ku Proxy will pass encapsulated traffic to CCP (Tier 3 server)

11. February 14, 2013 11 Information Architecture Regimen Based Security Model  Tier 3 is an OPS server  All inputs consolidated for a single point of control  HPEG on the OPS server shall scan files, meter traffic, and routing to CDP with a Ground Transfer Header (GTH)  Remote users do not have access to OPS servers  No architectural or functional changes are expected at Tier 4

12. February 14, 2013 Backup 12

13. February 14, 2013 References – CCSDS 732.0-B-2 AOS Space Data Link Protocol CCSDS 732.0-B-2 – CCSDS 135.0-B-4 Space Link Identifiers CCSDS 135.0-B-4 – CCSDS 133.1-B-2 Encapsulation Service CCSDS 133.1-B-2 – CCSDS 133.0-B-1 Space Packet Protocol CCSDS 133.0-B-1 – CCSDS 727.0-B-4 CCSDS File Delivery Protocol (CFDP) CCSDS 727.0-B-4 – MSFC-SPEC-3618 International Space Station (ISS) Program ISS IP Ground Router (IIGoR) Architectural Control Document (ACD) 13 Project Requirements documents

14. February 14, 2013 Project Requirements Affected documents Level II – SSP 45001: Space Station Control Center to Huntsville Operations Support Center (HOSC) Interface Control Document International Space Station Program - Part II Revision B – SSP 52000-PDS, Rev E, Payload Data Sets Blank Book (Ground Data Services Blank Book Section) – SSP 50304 Rev C POIC Capabilities Document – SSP 50305-V1 Rev C POIC to Generic User Interface Definition Document (Vol. I) Revision C – SSP 57072, Appendix D, Standard Payload Integration Agreement for ISS Payloads 14