U. S. Department of Transportation Federal Aviation Administration Interface Requirements Document TDLS-CSP January 26, 2013 Version 1.1 Tower Data Link Services (TDLS) To Communications Service Provider (CSP) This page intentionally left blank. TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 INTERFACE REQUIREMENTS DOCUMENT APPROVAL SIGNATURE PAGE TDLS to CSP Approval Signatures Name Organization TDLS Program ATO-W FTI Program ATO-T Signature i Date Signed TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 This page intentionally left blank. ii TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 REVISION RECORD Revision Letter A Description Date Entered By AJW-178 Initial Submission to Configuration Control Board VERSION RECORD Version Description Date Number Entered By 0.0 Initial Draft August 25, 2009 AJW-178 0.1 Additional Requirements added. September 9, 2009 AJW-178 0.2 Subparagraph and Requirement numbering. November 2, 2009 AJW-178 0.3 Updated the Verification Requirements Traceability Matrix Issues raised in request for comments were resolved and IRD was updated to reflect changes. November 9, 2009 AJW-178 February 9, 2010 AJW-178 May 24, 2010 AJW-178 0.6 Issues raised and were resolved and IRD/ICD were updated to reflect. Added redundancy requirement. April 27, 2012 AJW-178 0.7 Updated for TDLS Version 12 May 19, 2012 AJW-178 0.8 June 22, 2012 AJW-178 0.9 Updated per Data Comm PO Comments, added Gate Request Message Updated to reflect WSSD 2.0 changes. July 23, 2012 AJW-178 0.10 Updated version submitted to DataComm. August 31, 2012 AJW-178 1.0 Post-FER release. November 27, 2012 AJW-178 1.1 Updated to include DCC and GREQ examples from January 26, 2013 SIDD ver 1.1, November 7, 2012 0.4 0.5 iii AJW-178 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 This page intentionally left blank. iv TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 Table of Contents 1 SCOPE ......................................................................................................................... 1 1.1 Summary ..................................................................................................................... 1 1.2 2 Subsystem Responsibility List ................................................................................... 2 APPLICABLE DOCUMENTS ................................................................................. 2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 Government Documents............................................................................................. 2 FAA Orders .................................................................................................................. 2 FAA Specifications....................................................................................................... 2 FAA Standards: ............................................................................................................ 3 Other FAA Documents: ................................................................................................ 3 2.2 3 Non-Government Documents .................................................................................... 3 INTERFACE REQUIREMENTS ............................................................................. 3 3.1 3.1.1 General Requirements ............................................................................................... 4 Security Requirements .................................................................................................. 4 3.2 Application General Requirements .......................................................................... 5 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 3.3.8 Functional Requirements ........................................................................................... 8 General Service Functional Requirements ................................................................... 8 Application Processes and Message Requirements ...................................................... 8 Message Content Requirements ................................................................................... 9 Relationship among Messages.................................................................................... 10 Quality of Service Requirements ................................................................................ 11 Error Handling Requirements ..................................................................................... 12 Interface Summary Table ........................................................................................... 14 Protocol Implementation ............................................................................................ 14 3.4 3.4.1 4 Physical Requirements / Characteristics ................................................................ 15 Electrical Power and Electronic Requirements / Characteristics ............................... 15 QUALITY ASSURANCE PROVISIONS .............................................................. 16 4.1 Responsibility for Verification ................................................................................ 16 4.2 Special Verification Requirements.......................................................................... 16 4.3 Verification Requirements Traceability Matrix .................................................... 16 4.4 4.4.1 4.4.2 5 6 Verification Levels and Methods............................................................................. 21 Verification Levels ..................................................................................................... 21 Verification Methods .................................................................................................. 22 PREPARATION FOR DELIVERY ....................................................................... 22 NOTES....................................................................................................................... 22 v TDLS to CSP Interface Requirement Document Version 1.1 6.1 NAS-IR-XXXXXXXX January 26, 2013 Definitions.................................................................................................................. 22 6.2 Abbreviations and Acronyms .................................................................................. 22 APPENDIX 1. SIMPLE MESSAGE HANDLING PROTOCOL ......................................... 1 A1.1 A1.1.1 A1.1.2 A1.1.3 A1.1.4 Protocol Formats ........................................................................................................ 1 Internet Layer - IP Datagram Format ........................................................................... 1 Transport Layer - TCP Segment Format ...................................................................... 1 TLSv1.0 Record Format ............................................................................................... 1 SMHP Message Format ................................................................................................ 2 A1.2 SMHP TCP Parameters ........................................................................................... 12 A1.3 A1.3.1 A1.3.2 A1.3.3 A1.3.4 A1.3.5 A1.3.6 SMHP TLSv1 Parameters ....................................................................................... 12 Version Compatibility ................................................................................................ 12 Cipher Suite Selection ................................................................................................ 12 Session Resumption.................................................................................................... 13 Renegotiations ............................................................................................................ 13 Authentication ............................................................................................................ 13 Handshake Errors ....................................................................................................... 13 A1.4 A1.4.1 A1.4.2 A1.4.3 SMHP Message Handling ........................................................................................ 13 Sending Heartbeat Messages ...................................................................................... 13 Sending Data Messages .............................................................................................. 13 Receiving SMHP Messages........................................................................................ 14 List of Figures Figure 1-1 Logical View, CSP to TDLS Interface ......................................................................... 1 Figure 3-1 TDLS-MS Connectivity Diagram ................................................................................. 7 Figure 3-2 Protocol Mapping for TDLS-MS ................................................................................ 14 List of Tables Table 1-1 Organization System Responsibility .............................................................................. 2 Table 3-1 TDLS-MS Application-Level Data Messages.............................................................. 10 Table 4-1 Verification Requirements Traceability Matrix ........................................................... 17 Table A1-1 Standard IP Datagram Structure .................................................................................. 1 Table A1-2 Standard TCP Segment Structure ................................................................................ 1 Table A1-3 TLS Record Format ..................................................................................................... 2 Table A1-4 SMHP Message Structure ............................................................................................ 2 Table A1-5 SMHP Message Header Format .................................................................................. 2 Table A1-6 SMHP GREQ Message ............................................................................................... 4 Table A1-7 GREQ Message Body Example .................................................................................. 4 Table A1-8 GREQ Reply Message Body Example ........................................................................ 5 Table A1-9 SMHP DCC Initial Clearance Message....................................................................... 6 vi TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 Table A1-10 SMHP DCC Revised Clearance Message ................................................................. 6 Table A1-11 Initial DCC Message Format for a Cleared as Filed ................................................. 6 Table A1-12 DCC ACK Message Body Example .......................................................................... 7 Table A1-13 Revised DCC Message Body Example ..................................................................... 8 Table A1-14 SMHP PDC Message................................................................................................. 9 Table A1-15 PDC and PDC ACK Message Body Examples ......................................................... 9 Table A1-16 SMHP TIS Message ................................................................................................ 10 Table A1-17 TIS and TIS ACK Message Body Examples........................................................... 10 Table A1-18 SMHP ACK Message Structure .............................................................................. 11 Table A1-19 SMHP NAK Message Structure .............................................................................. 11 Table A1-20 SMHP HART Message Structure ............................................................................ 12 Table A1-21 SMHP Version Message Structure .......................................................................... 12 vii TDLS to CSP Interface Requirement Document Version 1.1 1 NAS-IR-XXXXXXXX January 26, 2013 SCOPE This Interface Requirements Document (IRD) provides the requirements to establish a Transmission Control Protocol/ Internet Protocol (TCP/IP) interface between Tower Data Link Services (TDLS) and external Non-FAA users, referred to as the Communications Service Providers (CSP). In the context of this document, a CSP is defined as an entity that receives Gate Request (GREQ), Departure Clearance (DCL) Courtesy Copy (DCC) 1, Pre-Departure Clearance (PDC), Digital Automatic Terminal Information Service (D-ATIS), and other future messages from TDLS. The CSP also distributes the messages to commercial airlines and/or general aviation aircraft. Note that in this document, an AOC fits the definition of a CSP. 1.1 Summary Figure 1-1 shows a high-level logical drawing that illustrates the interface between TDLS and the CSP. Later in this document a more detailed drawing (Figure 3-1) will provide more information and show redundant pathways used to provide high availability to the TDLS Message Service (TDLS-MS). Figure 1-1 Logical View, CSP to TDLS Interface 1 Within this and related TDLS technical documents, the term DCL Courtesy Copy (DCC) is used to denote the textual clearance information that is sent to the AOC from the ground system. It is analogous to the Dispatch message in the Data Communication Implementation Team materials. 1 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 Communication between the CSP and TDLS is via the NAS Operational Internet Protocol (OPS-IP) network, with the CSP connecting through a NAS Enterprise Security Gateway (NESG). The TDLS Front End Processor (TDLS_FEP) serves as the proxy (FEP_PROXY) between the CSP and the TDLS Back End Processor (TDLS_BEP). The primary purpose of the TDLS_FEP is to isolate the CSP subsystem from the NAS OPS-IP network. The proxy also connects to and routes messages to the appropriate TDLS_BEP depending upon availability. This IRD defines the requirements the CSP must meet when connecting to the TDLS-MS. This IRD also defines the TDLS-MS protocol that will be used to pass messages between the TDLS Enterprise and the CSP. The TDLS Enterprise encompasses all subsystems and components within TDLS Program. This IRD was prepared in accordance with FAA-STD-025f, Preparation of Interface Documentation. 1.2 Subsystem Responsibility List Table 1-1, Organization System Responsibility, lists the key entities that will be in place to support this interface. Table 1-1 Organization System Responsibility SUBSYSTEM TDLS Common Name Responsible FAA Program Office Tower Data Link System ATO-W FTI FAA Telecommunication Infrastructure ATO-T CSP Communications Service Providers N/A The organizational system responsibility requirements are described in Section 3.1.2 of this IRD. 2 APPLICABLE DOCUMENTS The following documents form a part of this IRD to the extent specified herein. In the event of a conflict between the documents referenced herein and the contents of this IRD, the contents of this IRD will be the superseding requirements. 2.1 Government Documents 2.1.1 FAA Orders FAA Order 1600.6e March 11, 2004 2.1.2 FAA-G-2100H March 2005 Facility Security Policy FAA Specifications Electronic Equipment, General Requirements (Note: Both revision g and h are in effect.) 2 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 FTI NESG-2 February, 2009 NAS Enterprise Security Gateway User Guide Volume II for Non-NAS Users NAS-SR-1000 December 1995 National Airspace System (NAS) System Requirements Specification 2.1.3 FAA Standards: FAA-STD-025f November 30, 2007 Preparation of Interface Documentation FAA-STD-039c August 14, 2003 Open System Architecture and Protocols 2.1.4 Other FAA Documents: Number not yet assigned 2.2 Data Communications Implementation Team (DCIT) Departure Clearance Service (DCL) Trials Systems Integration Description Document, version 1.1, November 7, 2012 Non-Government Documents ANSI X3.4 December 30, 1986 American National Standard Code for Information Interchange (ASCII) ANSI X3.41 1974 Code Extension Techniques for Use with the 7-Bit Coded Character Set of ASCII. TIA/EIA-568-B.1 April 12, 2001 Commercial Building Telecommunications Cabling Standard IETF RFC 2246 January 1999 Transport Layer Security Protocol (TLS), Version 1.0 IETF RFC 791 September 1981 Internet Protocol DARPA Internet Program Protocol Specification IETF RFC 793 September 1981 Transmission Control Protocol, updated by RFC 3168 IETF RFC 3168 September 2001 The Addition of Explicit Congestion Notification (ECN) to IP 3 INTERFACE REQUIREMENTS This section provides the general functional and design requirements for the TCP/IP interface between the TDLS-MS and CSP subsystems. 3 TDLS to CSP Interface Requirement Document Version 1.1 3.1 NAS-IR-XXXXXXXX January 26, 2013 General Requirements This IRD defines the TDLS-MS interface which utilizes Simple Message Handling Protocol (SMHP) to exchange GREQ, DCC, PDC and D-ATIS messages between TDLS and CSP subsystems via TCP/IP. Other than the acknowledgement of messages this IRD imposes no requirements on the processing GREQ, DCC, PDC or D-ATIS messages at the application-level. 3.1.1 Security Requirements The following paragraphs provide the security requirements for each subsystem. This document does not specify security capabilities outside of the TDLS-MS system. The following subsections address the high-level security requirements for the TDLS-MS. CSP Security Requirements 3.1.1.1 IRD.WSSD470.TC.2001 The CSP shall access the TDLS_BEP through the TDLS_FEP. 3.1.1.2 IRD.WSSD442.TC.2002 The Transport Layer Security Version 1.0 (TLSv1.0) shall be used for authentication and message integrity (but not encryption) for all connections between the TDLS servers and CSP clients. 3.1.1.3 IRD.WSSD440.TC.2003 The CSP client shall authenticate the TDLS server using the TDLS server's certificate. 3.1.1.4 IRD.WSSD442.TC.2004 The CSP client shall submit an X509v3 client certificate to the TDLS server during the TLS handshake. TDLS Security Requirements 3.1.1.5 IRD.TSSD7016.TC.2005 All TDLS-MS equipment and cabling shall be located within FAA facilities, which are subject to FAA physical security policies, in accordance with FAA Order 1600.6e, Facility Security Policy. 3.1.1.6 IRD.WSSD462.TC.2006 The FAA shall be responsible for the security of the TDLS-MS equipment and transmission equipment up to the points of demarcation. 3.1.1.7 IRD.WSSD470.TC.2007 All Non-NAS subsystems shall be segregated in accordance with NAS-SR-1000, National Airspace System (NAS) System Requirements Specification. 3.1.1.8 IRD.WSSD470.TC.2008 The TDLS_FEP shall connect to the External DMZ of the NESG. 3.1.1.9 IRD.WSSD470.TC.2009 The TDLS_FEP shall be collocated with each NESG. 3.1.1.10 IRD.WSSD470.TC.2010 The TDLS_FEP shall serve as a proxy between the CSP subsystem and the TDLS_BEP. 3.1.1.11 IRD.WSSD439.TC.2011 The TDLS_FEP shall perform validation on incoming socket connections, verifying that the CSP's IP address is valid for the port with which it is attempting to establish a connection. 4 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 3.1.1.12 IRD.WSSD442.TC.2012 The TDLS_BEP shall present an X509v3 server certificate to the CSP client during the TLS handshake. 3.1.1.13 IRD.WSSD440.TC.2013 The TDLS_BEP shall authenticate the CSP client using the CSP client's certificate. 3.2 Application General Requirements 3.2.1.1 IRD.WSSD9691.TC.2024 TDLS Enterprise key subsystems shall be in place to support this interface. 3.2.1.2 IRD.WSSD462.TC.2025 The FTI key subsystems shall be in place to support this interface. Note: A key subsystem is a subsystem that is required for this interface to work. 3.2.1.3 IRD.WSSD462.TC.2026 The TDLS-MS shall utilize FTI communications infrastructure services between the TDLS_BEP and the TDLS_FEP. 3.2.1.4 IRD.WSSD462.TC.2027 The TDLS-MS shall utilize FTI communications infrastructure services between the TDLS_FEP and the FTI SDP at the NESG for the CSP connection. 3.2.1.5 IRD.WSSD342.TC.2124 The TDLS-MS interface shall allow service certification without loss of service. CSP Application General Requirements 3.2.1.6 IRD.WSSD470.TC.2028 The CSP shall connect through multiple NESGs for redundancy. Note: The external connectivity supported by FTI at the NESG is a VPN in accordance with the NAS Enterprise Security Gateway User Guide Volume II - for Non-NAS Users. 3.2.1.7 IRD.WSSD462.TC.2029 The CSP subsystem shall utilize a TCP/IP interface to communicate with TDLS-MS. 3.2.1.8 IRD.WSSD897.TC.2119 The CSP subsystem shall support the transmission of GREQ messages between the CSP and TDLS-MS. 3.2.1.9 IRD.WSSD9678.TC.2114 The CSP subsystem shall support the transmission of DCC messages between the CSP and TDLS-MS. 3.2.1.10 IRD.WSSD9691.TC.2030 The CSP subsystem shall support the transmission of PDC messages between the CSP and TDLS-MS. 3.2.1.11 IRD.WSSD9691.TC.2031 The CSP subsystem shall support the transmission of DATIS messages between CSP and TDLS-MS. TDLS Application General Requirements 3.2.1.12 IRD.WSSD462.TC.2032 The TDLS-MS shall utilize a TCP/IP interface to communicate to the CSP. 5 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 3.2.1.13 IRD.WSSD898.TC.2120 The TDLS-MS shall support the transmission of GREQ messages between TDLS and the CSPs. 3.2.1.14 IRD.WSSD9678.TC.2115 The TDLS-MS shall support the transmission of DCC messages between TDLS and the CSPs. 3.2.1.15 IRD.TSSD5012.TC.2033 The TDLS-MS shall support the transmission of PDC messages between TDLS and the CSPs. 3.2.1.16 IRD.TSSD5012.TC.2034 The TDLS-MS shall support the transmission of D-ATIS messages between TDLS and the CSPs. 3.2.1.17 IRD.TSSD0095.TC.2035 The network layer of the TDLS-MS message format shall comply with FAA-STD-039c, Open System Architecture and Protocols. 3.2.1.18 IRD.WSSD9691.TC.2036 The TDLS-MS shall provide Store-and-Forward message system. 3.2.1.19 IRD.WSSD435.TC.2037 The TDLS-MS shall provide alternate routing to the TDLS_BEPs. 3.2.1.20 IRD.WSSD9691.TC.2038 The TDLS-MS shall define an application level protocol in support of application data message acknowledgments. 3.2.1.21 IRD.WSSD9691.TC.2039 The TDLS-MS shall provide an application level protocol in support of an application heartbeat mechanism to validate connection integrity. 3.2.1.22 IRD.WSSD470.TC.2040 A TDLS_BEP shall be collocated with the NESG at the SLC NEMC. 3.2.1.23 IRD.WSSD470.TC.2041 A TDLS_BEP shall be collocated with the NESG at the ATL NEMC. The interface connections and data paths between the CSP and the TDLS-MS are shown in Figure 3-1. 6 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 Figure 3-1 TDLS-MS Connectivity Diagram 7 TDLS to CSP Interface Requirement Document Version 1.1 3.3 NAS-IR-XXXXXXXX January 26, 2013 Functional Requirements This subsection describes the functional requirements of the interface. It identifies the Application Processes (AP) associated with both systems; the information transferred between them, and the protocols used for the transport, network, link and physical layers. 3.3.1 General Service Functional Requirements TDLS FEP and BEP Functional Requirements 3.3.1.1 IRD.WSSD462.TC.2042 The TDLS_BEP shall connect directly to the NAS OPS-IP network. 3.3.1.2 IRD.WSSD470.TC.2043 The FEP_PROXY shall enable the CSP_CLIENT to connect to all available TDLS_BEPs. 3.3.1.3 IRD.WSSD9691.TC.2044 The FEP_PROXY shall allow the host operating system to select an originating port when establishing/reestablishing a TCP connection to the TDLS_BEP. 3.3.1.4 IRD.WSSD9691.TC.2111 The FEP_PROXY shall connect to the destination port 9049 when establishing/reestablishing a TCP connection to the TDLS_BEP. 3.3.1.5 IRD.WSSD455.TC.2045 To provide process isolation between CSPs, the FEP_PROXY shall spawn a process to establish the virtual connection between CSP_CLIENT and TDLS_SERVER once the FEP_PROXY accepts a TCP socket connection from the CSP_CLIENT. 3.3.1.6 IRD.WSSD455.TC.2046 The FEP_PROXY listener shall resume listening for incoming connections once the child process is spawned to service the CSP_CLIENT and TDLS_SERVER. 3.3.2 Application Processes and Message Requirements An AP is defined as an identifiable set of cooperating capabilities within a system that executes one or more information processing tasks. The following paragraphs describe the APs. Identification of Each Application Process 3.3.2.1 IRD.WSSD9691.TC.2047 The CSP Client Application (CSP_CLIENT) shall run on the CSP platform. 3.3.2.2 IRD.WSSD9691.TC.2048 The TDLS Server Application (TDLS_SERVER) shall run on the TDLS_BEP. Application Process Capability Requirements CSP_CLIENT Application Process Capability Requirements 3.3.2.3 IRD.WSSD9691.TC.2049 The CSP_CLIENT shall support SMHP, in accordance with Appendix 1, Simple Message Handling Protocol Specification. 3.3.2.4 IRD.WSSD435.TC.2050 The CSP_CLIENT shall automatically connect to the TDLS_FEP at startup. 3.3.2.5 IRD.WSSD435.TC.2051 The CSP_CLIENT shall automatically reestablish the TCP connection to the TDLS_FEP, if the connection is lost.. 8 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 3.3.2.6 IRD.WSSD435.TC.2052 The CSP_CLIENT shall allow the host operating system to select an originating port when establishing/reestablishing a TCP connection to the TDLS_FEP. 3.3.2.7 IRD.WSSD9691.TC.2110 The CSP_CLIENT shall connect to the destination port 9049 when establishing/reestablishing a TCP connection to the TDLS_FEP. 3.3.2.8 IRD.WSSD435.TC.2112 The CSP_CLIENT shall automatically reestablish the TCP connection with the TDLS_FEP within 30 seconds of a connection failure. 3.3.2.9 IRD.WSSD435.TC.2113 The CSP_CLIENT/(s) shall maintain simultaneous TCP connections with the TDLS_FEPs at the ALT and SLC NESGs 3.3.2.10 IRD.WSSD470.TC.2053 The CSP_CLIENT shall not encrypt messages at the application or TLS levels. Note: The VPN tunnel between the CSP's router and NSEG external router may encrypt the messages. TDLS_SERVER Application Process Capability Requirements 3.3.2.11 IRD.WSSD9691.TC.2054 The TDLS_SERVER shall support SMHP, in accordance with Appendix 1, Simple Message Handling Protocol Specification. 3.3.2.12 IRD.WSSD470.TC.2055 The TDLS_SERVER shall not encrypt messages at the application or TLS levels. 3.3.2.13 IRD.WSSD435.TC.2056 The TDLS_SERVER shall allow a single connection from the CSP originating from a particular TDLS_FEP. 3.3.2.14 IRD.WSSD435.TC.2057 The TDLS_SERVER shall allow multiple connections from a single CSP as long as the connections originate from different TDLS_FEPs. 3.3.2.15 IRD.WSSD455.TC.2058 To provide process isolation between CSPs, the TDLS_SERVER listener shall spawn a child server process to service the CSP_CLIENT. 3.3.2.16 IRD.WSSD435.TC.2059 The TDLS_SERVER listener shall resume listening for incoming connections once the child server process is spawned to service the CSP_CLIENT. 3.3.3 Message Content Requirements 3.3.3.1 IRD.WSSD9691.TC.2060 The application-level information units that cross this interface shall be SMHP messages. 3.3.3.2 IRD.WSSD9691.TC.2061 The only data message types supported across this interface shall be SMHP GREQ, DCC, PDC and D-ATIS (TIS) message types. Note: TIS is the SMHP message type identifier for D-ATIS message. DCC is the SMHP message type identifier for the Courtesy Copy message. GREQ is the SMHP message type identifier for a Gate Request message. The SMHP messages, or application messages, are defined in Appendix 1, Simple Message Handling Protocol Specification. The IATA Type B formatted data message is contained within 9 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 the payload of SMHP data messages of type GREQ, DCC, PDC and TIS. Table 3-1 lists the SMHP message types. Table 3-1 TDLS-MS Application-Level Data Messages Type GREQ DCC PDC TIS ACK NAK HART Traffic Direction TDLS_SERVER | CSP_CLIENT Transmit Frequency Unscheduled Unscheduled Unscheduled Unscheduled Unscheduled Unscheduled Unscheduled Size (Bytes) < 100 < 1500 < 400 < 1000 16 32 16 3.3.3.3 IRD.WSSD9691.TC.2062 The basic units of information between TDLS_SERVER and the CSP_CLIENT shall be SMHP Data Messages of type GREQ, DCC, PDC or TIS and SMHP Management Messages. 3.3.3.4 IRD.WSSD9691.TC.2063 All information units shall be composed of data fields represented as an American Standard Code for Information Interchange (ASCII) character set. 3.3.3.5 IRD.WSSD9691.TC.2064 ASCII implementations of character coded data shall be according to ANSI X3.4, American National Standard Code for Information Interchange (ASCII), Rev. 1992 and ANSI X3.41 Code Extension Techniques for Use with the 7-Byte Code Character Set of ASCII, 1990. 3.3.3.6 IRD.WSSD9678.TC.2135 The SMHP Data Message of type DCC shall contain a full route string in the route information for an initial or revised DCL that contains a route whenever the full route is not already included in the clearance sent up to the aircraft. 3.3.4 Relationship among Messages CSP Relationship among Messages Requirements 3.3.4.1 IRD.WSSD9691.TC.2121 Upon successful receipt of a SMHP Data Message of type GREQ the CSP_CLIENT shall respond with a SMHP Data Message of type GREQ, which contains the requested Gate information, to the TDLS application. 3.3.4.2 IRD.WSSD9691.TC.2116 Upon successful receipt of a SMHP Data Message of type DCC the CSP_CLIENT shall respond with a SMHP Data Message of type DCC, which contains the actual DCC Acknowledgement at the TDLS DCC application level. 3.3.4.3 IRD.WSSD9691.TC.2065 Upon successful receipt of a SMHP Data Message of type PDC, the CSP_CLIENT shall respond with a SMHP Data Message of type PDC, which contains the actual PDC Acknowledgement at the TDLS PDC application-level. 10 TDLS to CSP Interface Requirement Document Version 1.1 3.3.4.4 NAS-IR-XXXXXXXX January 26, 2013 IRD.WSSD9691.TC.2066 Upon successful receipt of a SMHP Data Message of type TIS, the CSP_CLIENT shall respond with a SMHP Data Message of type TIS, which contains the actual D-ATIS Acknowledgement at the D-ATIS application-level. TDLS Relationship among Messages Requirements 3.3.4.5 IRD.WSSD9691.TC.2122 When a GREQ message is issued by ATC at a TDLS remote site, a copy of the GREQ message shall be stored on the TDLS_BEPs . 3.3.4.6 IRD.WSSD9691.TC.2123 Once a GREQ message is stored on the TDLS_BEP, the TDLS_SERVER process shall forward the actual GREQ message to the appropriate CSP in a SMHP Data message of type GREQ. 3.3.4.7 IRD.WSSD9691.TC.2117 When a DCC message is issued by ATC at a TDLS remote site, a copy of the DCC message shall be stored on the TDLS_BEPs. 3.3.4.8 IRD.WSSD9691.TC.2118 Once a DCC message is stored on the TDLS_BEP, the TDLS_SERVER process shall forward the actual DCC message to the appropriate CSP in a SMHP Data message of type DCC. 3.3.4.9 IRD.WSSD9691.TC.2067 When a PDC message is issued by ATC at a TDLS remote site, a copy of the PDC message shall be stored on the TDLS_BEPs. 3.3.4.10 IRD.WSSD9691.TC.2068 Once a PDC message is stored on the TDLS_BEP, the TDLS_SERVER process shall forward the actual PDC message to the appropriate CSP in a SMHP Data message of type PDC. 3.3.4.11 IRD.WSSD9691.TC.2069 When ATC issues a D-ATIS message at a TDLS remote site, the actual D-ATIS message shall be stored on the TDLS_BEPs. 3.3.4.12 IRD.WSSD9691.TC.2070 Once a D-ATIS message is stored on the TDLS_BEP, the TDLS_SERVER process shall forward copies of the actual D-ATIS message to all appropriate CSPs in a SMHP Data message of type TIS. 3.3.5 Quality of Service Requirements Availability 3.3.5.1 IRD.WSSD326.TC.2071 The GREQ, DCC, PDC and D ATIS messages transmitted over the TDLS-MS interface are considered NAS essential, per NAS SR 1000, availability of this interface shall be greater than or equal to 99.997%. Restoration Time 3.3.5.2 IRD.WSSD339.TC.2072 This interface shall have a service restoration time of less than equal to one (1) minute. Message Size 3.3.5.3 IRD.WSSD9691.TC.2073 SMHP shall support a maximum message size of 9999 bytes. Note: Typical SMHP message sizes are listed in Table 3-1. Data Integrity 11 TDLS to CSP Interface Requirement Document Version 1.1 3.3.5.4 NAS-IR-XXXXXXXX January 26, 2013 IRD.WSSD478.TC.2125 The TDLS-MS interface shall check information inputs for accuracy, completeness, and validity at the network transport layer (TCP/IP) and at the application layer utilizing TLS v1.0 or greater. Derivation Guidance: The TIMS application CSCIs are responsible for validating the accuracy, completeness and validity of its inputs at the application layer. 3.3.5.5 IRD.WSSD462.TC.2126 The TDLS-MS interface shall protect the integrity of transmitted ground-ground information from unintended modifications by utilizing FTI services. 3.3.5.6 IRD.WSSD9691.TC.2074 At the lower level data integrity is a function of TCP and the lower-level protocols. At the application level, SMHP shall provide data message acknowledgement to the interface application. Latency 3.3.5.7 IRD.WSSD9691.TC.2075 The latency for application message transfer is a function of the FTI services associated with the NESG SDP, FTI SDPs, TDLS_FEPs, TDLS_BEPs, TDLS, CSP subsystems, and airline subsystems. Latency shall be less than equal to two (2) minutes. Note: Message Transfer Latency is defined as the time between when the application message was sent by TDLS, until the receipt of the application message acknowledgement at TDLS. Throughput 3.3.5.8 IRD.WSSD9691.TC.2076 Throughput is a function of the FTI services level and the access bandwidth of the NESG, TDLS_FEP, TDLS_BEP, and the CSP subsystem equipment. The bandwidth between the CSP_CLIENT and the TDLS_SERVER shall be at least 512 kbps. This IRD imposes no requirements for Priority, Urgency, Importance, and Expected Bit Error Rate. 3.3.6 Error Handling Requirements Error Logging 3.3.6.1 IRD.WSSD479.TC.2128 The TDLS-MS interface shall identify error conditions and generate error messages that provide information necessary for corrective actions without revealing, in error logs or administrative messages, sensitive information (e.g., passwords, PII) or information that could be exploited by adversaries. 3.3.6.2 IRD.WSSD429.TC.2129 All TDLS-MS error and audit logs shall be time stamped. 3.3.6.3 IRD.WSSD458.TC.2130 The TDLS-MS interface shall support the monitoring and control of communications at the external boundary of the system through gateways, proxies, routers, firewall, guards, and encrypted tunnels in accordance with NIST 80053 Revision 3 controls. 3.3.6.4 IRD.WSSD458.TC.2131 The TDLS-MS shall log the status of VPN connections between the TDLS FEP and the CSP. 12 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 3.3.6.5 IRD.WSSD459.TC.2132 The TDLS-MS shall support the monitoring and control of communications at key internal boundaries within the system through gateways, proxies, routers, firewall, guards, and encrypted tunnels in accordance with NIST 80053 Revision 3 controls. 3.3.6.6 IRD.WSSD459.TC.2133 The TDLS-MS interface shall log all operational messages and message status of messages that pass through the interface. 3.3.6.7 IRD.WSSD459.TC.2134 The TDLS-MS interface shall log the status of all TLS session between the TDLS FEP and the TDLS BEP. Load Sharing 3.3.6.8 IRD.WSSD326.TC.2077 The two TDLS_BEPs shall operate in a load-sharing capacity, with either server having the ability to support all CSP subsystems, when the alternate TDLS_BEP is unavailable. Failover Mode 3.3.6.9 IRD.WSSD326.TC.2078 When the FEP_PROXY process fails to open a TCP socket connection to the local TDLS_BEP, it shall attempt to connect to the alternate TDLS_BEP. 3.3.6.10 IRD.WSSD9691.TC.2079 When the CSP connects through multiple NESGs to the same TDLS_BEP the TDLS_FEP collocated with the TDLS_BEP shall be the primary proxy for servicing the CSP. Fallback Mode 3.3.6.11 IRD.WSSD9691.TC.2080 Once the FEP_PROXY connects to the failover TDLS_BEP, it shall continually attempt to connect to the local TDLS_BEP in the background. 3.3.6.12 IRD.WSSD9691.TC.2081 Once the FEP_PROXY connects to the local TDLS_BEP in the background, it shall close the socket connections to the local TDLS_BEP, the failover TDLS_BEP and the CSP_CLIENT, triggering the CSP_CLIENT to reestablish the connection to the TDLS_FEP. Recovery Mode 3.3.6.13 IRD.WSSD9691.TC.2082 When the FEP_PROXY process fails to open a connection to the failover TDLS_BEP, the FEP_PROXY process shall close the connection to the CSP_CLIENT, triggering the CSP_CLIENT to reestablish the socket connection. 3.3.6.14 IRD.WSSD9691.TC.2083 When the FEP_PROXY process loses a socket connection to either the CSP_CLIENT or the TDLS_SERVER, the FEP_PROXY process shall close the socket connections to both the TDLS_SERVER and the CSP_CLIENT, triggering the CSP_CLIENT to reestablish the socket connection. 3.3.6.15 IRD.WSSD326.TC.2084 When the CSP_CLIENT has nothing to send for 5 seconds, it shall send a SMHP heartbeat (HART) message to the TDLS_SERVER. 13 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 3.3.6.16 IRD.WSSD326.TC.2085 When it has been more than 20 seconds since receiving any data from the TDLS_SERVER, the CSP_CLIENT shall close the connection trigging the CSP_CLIENT to reestablish the TCP socket connection to the TDLS_FEP. 3.3.6.17 IRD.WSSD9691.TC.2086 When the CSP_CLIENT sends or receives a NAK message, indicating a garbled SMHP header, it shall close the socket connection and reestablish the connection to the TDLS_FEP. 3.3.6.18 IRD.WSSD326.TC.2087 When the TDLS_SERVER has nothing to send for 5 seconds, it shall send a SMHP heartbeat (HART) message to the CSP_CLIENT. 3.3.6.19 IRD.WSSD326.TC.2088 When it has been more than 20 seconds since receiving any data from the CSP_CLIENT, the TDLS_SERVER shall close the connection trigging the CSP_CLIENT to reestablish the TCP socket connection. 3.3.6.20 IRD.WSSD9691.TC.2089 When the TDLS_SERVER sends or receives a NAK message, indicating a garbled SMHP header, it shall close the socket connection triggering the CSP_CLIENT to reestablish the connection. 3.3.6.21 IRD.WSSD9691.TC.2090 When the TDLS_SERVER receives multiple connection requests from a CSP_CLIENT originating from the same TDLS_FEP, the TDLS_SERVER shall terminate the original connection and accept the new connection to the CSP_CLIENT. 3.3.7 Interface Summary Table The application-level data messages to be transmitted across the TDLS-MS TCP/IP interface are as summarized in Table 3-1. 3.3.8 Protocol Implementation Figure 3-2 depicts the protocol mapping for the TDLS-MS. TDLS BEP CSP SUBSYSTEM Simple Message Handling Protocol Data Messages & Management Messages Application Layer Transport Layer Security Transport Layer Security TLS TCP Transport Layer Transport Layer IP IP Internet Layer Network Interface Link Layer PhysicaLayer Application Layer FTI OPS-IP Network Link Layer NESG Link Layer Internet Layer Link Layer PhysicaLayer Physical Connection/Point of Demarcation Figure 3-2 Protocol Mapping for TDLS-MS Application Layer Services 14 Network Interface TDLS to CSP Interface Requirement Document Version 1.1 3.3.8.1 NAS-IR-XXXXXXXX January 26, 2013 IRD.WSSD9691.TC.2092 The Client/Service application layer services shall be in accordance with Appendix 1, SMHP Specification, for interoperability between TDLS-MS and the CSP client application. Transport Layer Security Services 3.3.8.2 IRD.WSSD442.TC.2093 TLS Version 1.0 as specified in RFC 2246 shall be used to provide authentication and message integrity. Transport Layer Services 3.3.8.3 IRD.WSSD462.TC.2094 The transport layer service for this interface shall be TCP, in accordance with the latest edition of FAA-STD-039c, Section 5.4, Transport Subprofile. 3.3.8.4 IRD.WSSD9691.TC.2109 The TCP_NODELAY option shall be set for TCP sockets so that multiple small packets can be sent before the first small packet is acknowledged at the TCP level. Naming and Addressing CSP Requirements 3.3.8.5 IRD.WSSD462.TC.2095 All CSP subsystems shall support IPv4 addressing in accordance with the latest edition FAA-STD-039c, Section 5.3.1, Internet Protocol. TDLS Requirements 3.3.8.6 3.4 IRD.WSSD462.TC.2096 TDLS subsystems shall support IPv4 addressing in accordance with the latest edition FAA-STD-039c, Section 5.3.1, Internet Protocol. Physical Requirements / Characteristics These subsections pertain only to the TDLS-MS servers. This IRD imposes no physical requirements on the user's subsystem equipment 3.4.1 Electrical Power and Electronic Requirements / Characteristics Power 3.4.1.1 IRD.TSSD7009.TC.2097 The TDLS_FEP and TDLS_BEP shall be connected to facility critical power in accordance FAA-G-2100H, Section 3.1.1, Electrical Power. Connectors 3.4.1.2 IRD.WSSD462.TC.2098 The TDLS-MS network interfaces shall provide RJ45 female connectors as specified in TIA/EIA-568-B. Wire/Cable CSP Wire/Cable Requirements 3.4.1.3 IRD.WSSD470.TC.2099 The CSP shall be responsible for providing all Ethernet cables between collocated CSP equipment and the NESG SDP. TDLS Wire/Cable Requirements 15 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 3.4.1.4 IRD.WSSD462.TC.2100 Category (CAT) 5e cabling with RJ45 male connectors as specified in TIA/EIA-568-B.1 shall be used to connect the TDLS_FEP and TDLS_BEP to the FTI SDPs. 3.4.1.5 IRD.WSSD462.TC.2101 The IFCET shall be responsible for providing all Ethernet cables between TDLS Enterprise equipment and the FTI SDPs. Grounding 3.4.1.6 IRD.TSSD7002.TC.2102 Within the electrical interfaces, grounding shall comply with FAA-G-2100H, Section 3.1.1.9, Grounding and Bonding. Fasteners No specific requirement. Electromagnetic Compatibility 3.4.1.7 4 IRD.TSSD7003.TC.2103 The electromagnetic compatibility shall be in accordance with FAA-G-2100H, Section 3.3.2, Electromagnetic Compatibility. QUALITY ASSURANCE PROVISIONS The following section specifies the process of verification for interface design characteristics. 4.1 Responsibility for Verification The government has responsibility for developing and implementing the verification of requirements for each project. The government may delegate verification activities to other organizations, independent contractors, and/or the major prime contractor. The Test and Evaluation (T&E) process guidelines within the Acquisition Management System (AMS) will be used and will be tailored as necessary for the levels and methods of verification in the Verification Requirements Traceability Matrix (VRTM). 4.2 Special Verification Requirements The special verification requirements will include, but not be limited to those defined in the following paragraphs. Prior to the start of integration level verification, functional interoperability will be demonstrated at the William J. Hughes Technical Center (WJHTC) System Support Computer Complex on the FTI National Test Bed (FNTB). Software interfaces between the CSP and the TDLS_BEP will be tested on the FTI National Test Bed (FNTB) network located at the William J. Hughes Technical Center, Atlantic City, NJ, before the CSP connects to the TDLS-MS on the FTI Operational Network. 4.3 Verification Requirements Traceability Matrix Verification will be in accordance with Table 4-1, Verification Requirements Traceability Matrix (VRTM). Verification levels and methods implemented in the VRTM are defined in the following paragraphs. 16 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 Table 4-1 Verification Requirements Traceability Matrix D=Demonstration A=Analysis I=Inspection T=Test X=Not Applicable Requirement Interface Requirements General Requirements Security Requirements CSP Requirements IRD 2001 Subsection Verification Phase and Method Subsystem Integration Site Level Level Level Remarks 3 Title 3.1 Title 3.1.1 Title Title 3.1.1.1 D T D IRD 2002 3.1.1.2 D T D IRD 2003 3.1.1.3 D T D IRD 2004 3.1.1.4 D T D Title TDLS Requirements IRD 2005 3.1.1.5 I I I IRD 2006 3.1.1.6 I I I IRD 2007 3.1.1.7 I I I IRD 2008 3.1.1.8 I I I IRD 2009 3.1.1.9 I I I IRD 2010 3.1.1.10 D T D IRD 2011 3.1.1.11 D T D IRD 2012 3.1.1.12 D T D IRD 2013 Application General Requirements IRD 2024 3.1.1.13 D T D 3.2.1.1 I I I IRD 2025 3.2.1.2 I I I IRD 2026 3.2.1.3 D D D IRD 2027 3.2.1.4 D D D IRD 2124 3.2.1.5 D D D 3.2 Title Title CSP Requirements IRD 2028 3.2.1.6 D D D IRD 2029 3.2.1.7 D D D IRD 2119 3.2.1.8 IRD 2114 3.2.1.9 T T T IRD 2030 3.2.1.10 T T T IRD 2031 3.2.1.11 T T T 17 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 Title TDLS Requirements IRD 2032 3.2.1.12 IRD 2120 3.2.1.13 IRD 2115 D D D 3.2.1.14 T T T IRD 2033 3.2.1.15 T T T IRD 2034 3.2.1.16 T T T IRD 2035 3.2.1.17 A A A IRD 2036 3.2.1.18 T T T IRD 2037 3.2.1.19 T T T IRD 2038 3.2.1.20 T T T IRD 2039 3.2.1.21 D D D IRD 2040 3.2.1.22 T T T IRD 2041 Functional Requirements General Service Functional Requirements TDLS FEP/ BEP Requirements IRD 2042 3.2.1.23 I I I 3.3.1.1 I I I IRD 2043 3.3.1.2 T T T IRD 2044 3.3.1.3 T T T IRD 2111 3.3.1.4 T T T IRD 2045 3.3.1.5 T T T IRD 2046 Application Processes & Message Requirements Identification of Each Application Process IRD 2047 3.3.1.6 T T T 3.3.2.1 D D D IRD 2048 Application Process Capability Requirements CSP_CLIENT Requirements IRD 2049 3.3.2.2 D D D 3.3.2.3 D D D IRD 2050 3.3.2.4 T T T IRD 2051 3.3.2.5 T T T IRD 2052 3.3.2.6 T T T 3.3 Title 3.3.1 Title Title 3.3.2 Title Title Title Title 18 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 IRD 2110 3.3.2.7 T T T IRD 2112 3.3.2.8 T T T IRD 2113 3.3.2.9 T T T IRD 2053 TDLS_SERVER Requirements IRD 2054 3.3.2.10 T T T 3.3.2.11 D D D IRD 2055 3.3.2.12 T T T IRD 2056 3.3.2.13 T T T IRD 2057 3.3.2.14 T T T IRD 2058 3.3.2.15 T T T IRD 2059 Message Content Requirements IRD 2060 3.3.2.16 T T T 3.3.3.1 D D D IRD 2061 3.3.3.2 T T T IRD 2062 3.3.3.3 D D D IRD 2063 3.3.3.4 T T T IRD 2064 3.3.3.5 T T T IRD 2135 Relationship among Requirements CSP Requirements IRD 2121 3.3.3.6 T T T IRD 2116 3.3.4.2 T T T IRD 2065 3.3.4.3 T T T IRD 2066 3.3.4.4 T T T Title 3.2.3 Title 3.3.4 Title Title 3.3.4.1 Title TDLS Requirements IRD 2122 3.3.4.5 IRD 2123 3.3.4.6 IRD 2117 3.3.4.7 T T T IRD 2118 3.3.4.8 T T T IRD 2067 3.3.4.9 T T T IRD 2068 3.3.4.10 T T T IRD 2069 3.3.4.11 T T T IRD 2070 Quality of Service Requirements IRD 2071 3.3.4.12 T T T 3.3.5.1 A A A IRD 2072 3.3.5.2 X X A 3.3.5 Title 19 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 IRD 2073 3.3.5.3 T T T IRD 2125 3.3.5.4 X X A IRD 2126 3.3.5.5 D D D IRD 2074 3.3.5.6 T T T IRD 2075 3.3.5.7 X X A IRD 2076 3.3.5.8 X X A IRD 2127 Error Handling Requirements IRD 2128 3.3.5.9 X T A 3.3.6.1 D D D IRD 2129 3.3.6.2 T T T IRD 2130 3.3.6.3 T T T IRD 2131 3.3.6.4 T T T IRD 2077 3.3.6.5 T T T IRD 2078 3.3.6.6 T T T IRD 2079 3.3.6.7 T T T IRD 2080 3.3.6.8 T T T IRD 2081 3.3.6.9 T T T IRD 2082 3.3.6.10 T T T IRD 2083 3.3.6.11 T T T IRD 2084 3.3.6.12 T T T IRD 2085 3.3.6.13 T T T IRD 2086 3.3.6.14 T T T IRD 2087 3.3.6.15 T T T IRD 2088 3.3.6.16 T T T IRD 2089 3.3.6.17 T T T IRD 2090 Interface Summary Table Protocol Implementation Requirements Application Layer Services IRD 2092 Transport Layer Security Services IRD 2093 Transport Layer Services IRD 2094 3.3.6.18 T T T 3.3.6 Title 3.3.7 Title 3.3.8 Title Title 3.3.8.1 D D D Title 3.3.8.2 T T T Title 3.3.8.3 I 20 I I TDLS to CSP Interface Requirement Document Version 1.1 IRD 2109 Naming and Addressing CSP Requirements IRD 2095 3.3.8.4 NAS-IR-XXXXXXXX January 26, 2013 I I I Title Title 3.3.8.5 D D D Title TDLS Requirements IRD 2096 Physical Requirements Electrical Power & Electronic Requirements IRD 2097 Connector Requirements IRD 2098 Wire/Cable Requirements CSP Requirements IRD 2099 TDLS Requirements IRD 2100 IRD 2101 Grounding Requirements IRD 2102 Fasteners Requirements N/A Electromagnetic Requirements IRD 2103 4.4 3.3.8.6 D D D 3.4 Title 3.4.1 Title 3.4.1.1 I I I Title 3.4.1.2 I I I Title Title 3.4.1.3 X X X Title 3.4.1.4 I I I 3.4.1.5 Title 3.4.1.6 I I I Title Title 3.4.1.7 A A A Verification Levels and Methods The three levels of verification are Subsystem, Integration, and Site. All requirements imposed by this IRD will be verified at one or more of these levels. 4.4.1 Verification Levels Subsystem Level: For subsystems developed under contract, this level of verification is usually accomplished at the contractor's facility and culminates in the formal acceptance of a contractual end-item. For subsystems developed by the Government, this level of verification is usually accomplished at the WJHTC, or at a key site. 21 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 Integration Level: This level of verification is conducted at the WJHTC, or at a key site. The verification conducted will determine if the hardware, software, or subsystem to be deployed for site installation will perform in a NAS environment and in accordance with NAS system-level operational and functional requirements. Site-level: This level of verification is usually performed at the designated site. The verification portion of the subsystem installation and checkout will emphasize demonstration of the overall system performance requirements. It includes the demonstration of an end-item, subsystem and/or system, the final acceptance demonstrations, and commissioning activities. 4.4.2 Verification Methods The four verification methods that can be used at any of the three verification levels are as follows: Inspection: Verification is accomplished by a visual examination of the item, reviewing descriptive documentation, and comparing the appropriate characteristics with predetermined standards, to determine conformance to requirements without the use of laboratory equipment or procedures. Demonstration: Verification is accomplished by operation, adjustment, or reconfiguration of items performing their design functions under specific scenarios. The items are instrumented and quantitative limits of performance monitored, but only check sheets (rather than actual performance data) recorded. Analysis: Verification is accomplished by technical or mathematical evaluation, mathematical models or simulation, algorithms, charts or circuit diagrams, and representative data. Test: Verification is accomplished through systematic exercising of the application item under appropriate conditions, with or without instrumentation, and the collection, analysis, and evaluation of quantitative data. 5 PREPARATION FOR DELIVERY This IRD imposes no explicit Preparation for Delivery requirements. 6 6.1 NOTES Definitions The following definitions apply to the terms used in this IRD: Demarcation (point of): A specific point in a chain of hardware and interconnecting circuitry where a change of responsibility for provisioning installation, and operation of the hardware and circuit configuration occurs. Interface: The means of communication, including hardware and software, between two entities. 6.2 Abbreviations and Acronyms ADNS ACK AJW-178 AMS Automated Digital Network System Acknowledgement Message TDLS Engineering group within the IFCET. Acquisition Management System 22 TDLS to CSP Interface Requirement Document Version 1.1 ANSI AP ARCTR ASCII ATC ATIS ATL ATO-T BEP BPS CSP CSP_CLIENT D-ATIS DCC DCIT DCL DMZ DOT DTS EIA ETX FAA FEP FEP_PROXY FNTB FTI HART IATA ICD IEEE IETF IFCET ISO IRD LAN NEMC NAS NAK NESG NEMC NAS-IR-XXXXXXXX January 26, 2013 American National Standard Institute Application Process FAA Aeronautical Center American Standard Code for Information Interchange Air Traffic Control Automatic Terminal Information Service Atlanta, GA Air Traffic Organization – Terminal services unit. Back End Processor Bits Per Second Communications Service Provider Communications Service Provider Client Digital ATIS (Automatic Terminal Information Service) SMHP message type that contains the DCL Courtesy Copy data Data Communications Implementation Team Delivery Clearance Demilitarized Zone Department of Transportation Data Transfer System Electronic Industries Alliance End of Text Federal Aviation Administration Front End Processor (for TDLS) Front End Processor (for TDLS) Proxy FTI National Test Bed FAA Telecommunications Infrastructure SMHP heartbeat Message International Air Transport Association Interface Control Document Institute of Electrical and Electronics Engineers, Inc. Internet Engineering Task Force Interfacility Communications Engineering Team. International Standards Organization Interface Requirements Document Local Area Network National Enterprise Management Center National Airspace System Non-Acknowledgement Message NAS Enterprise Security Gateways National Enterprise Management Center 23 TDLS to CSP Interface Requirement Document Version 1.1 OPS OSI PDC RFC RFS SDP SLC SMHP SOH STX T&E TBS TCP/IP TDLS TDLS_BEP TDLS_FEP TDLS_SERVER TDLS-MS TLS TIA TIS UTP VPN VRTM WAN WJHTC NAS-IR-XXXXXXXX January 26, 2013 Operational Open Systems Interconnection SMHP message type that contains Pre-Departure Clearance data Request for Comment Request For Service Service Delivery Point Salt Lake City, UT Simple Message Handling Protocol. Start of Header Start of Text Test and Evaluation To Be Supplied Transmission Control Protocol/Internet Protocol Tower Data Link Services Tower Data Link Services Back End Processor Tower Data Link Services Front End Processor Tower Data Link Services Server Tower Data Link Services Message Service Transport Layer Security Telecommunications Industry Association SMHP message type that contains D-ATIS data. Unshielded Twisted Pair Virtual Private Network Verification Requirements Traceability Matrix Wide Area Network William J. Hughes Technical Center 24 TDLS to CSP Interface Requirement Document Version 1.1 Appendix 1. NAS-IR-XXXXXXXX January 26, 2013 SIMPLE MESSAGE HANDLING PROTOCOL This appendix documents the application-layer Simple Message Handling Protocol (SMHP) which is used for messaging between the Tower Data Link Services Message Service (TDLS-MS) and the Communications Service Providers (CSP). The SMHP is based on TCP/IP for transport and internetworking and uses Transport Layer Security Version 1.0 (TLSv1.0) for authentication and message integrity. The SMHP does not encrypt or compress messages at the application or TLS layer. A1.1 A1.1.1 Protocol Formats Internet Layer - IP Datagram Format The IP datagram structure is depicted in Table A1-1 below. Each datagram frame consists of a header followed by the data field, and is defined in Request for Comments (RFC) 791 (Part of the Internet Engineering Task Force (IETF STD-5). The IP header will be 20 bytes in length, as none of these systems has plans to utilize the IP Options field. The maximum length for the data field will be 1480 bytes, based upon the widely used standard of a Maximum Transmission Unit (MTU) being 1500 bytes. Table A1-1 Standard IP Datagram Structure IP HEADER 20 Bytes A1.1.2 IP DATA 1 - 1480 Bytes Transport Layer - TCP Segment Format The TCP segment consists of the TCP header and TCP data fields which reside within the data field of the IP datagram as depicted in Table A1-2. The definition of the individual fields within the TCP header is contained in RFC 793 (IETF STD-7). The header field is 20 bytes in length and the data field has a maximum length of 1460 bytes. Table A1-2 Standard TCP Segment Structure IP HEADER 20 Bytes TCP HEADER 20 Bytes A1.1.3 IP DATA 1 - 1480 Bytes TCP DATA 1 - 1460 Bytes TLSv1.0 Record Format The TLSv1.0 record format (depicted in Table A1-3) consists of a header, a variable length payload, and a keyed-Hash Message Authentication Code (HMAC) which provides message integrity. RFC 2246 (IETF STD-1) defines TLSv1.0. Note that there could be multiple TLSv1.0 A1-1 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 records in one TCP segment and a TLSv1.0 record could span multiple TCP segments. Even if TLS record has a maximum of 16,408 Bytes and TCP data field has a max 1460 Bytes, many TLS messages are less than 1460 Bytes. Table A1-3 TLS Record Format TLS HEADER 5 Bytes A1.1.4 TLS DATA 1 – 16,383 Bytes HMAC SHA1 20 Bytes SMHP Message Format The SMHP message format consists of the SMHP header and a variable length payload, as shown in Table A1-4. An SMHP message is contained within a single TLSv1 record. Table A1-4 SMHP Message Structure TLSv1 Record Application Data Field SMHP BODY 0 – 9999 Bytes SMHP HDR 16 Bytes A1.1.4.1 SMHP Header Format The SMHP message contains a 16 byte header that contains the four fields described in Table A1-5. All fields in the header will consist of only alphanumeric and space characters except for the version and pad fields. Table A1-5 SMHP Message Header Format Field Length Description Body Length 4 characters The length of the body of the message in bytes in decimal format padded with leading '0' characters. If there is no body (such as for a heartbeat message) the body length field will be 0000. Sequence 4 characters The sequence number for the message being sent. The purpose of the sequence number is to facilitate the positive acknowledgement of messages. The sequence number will be padded with 0's to be exactly 4 characters in length. The sequence number will begin with 0001 and go to 9998. After 9998 it will cycle back to 0001. On restart of the connection, the sequence number will begin with 1 again. The value 9999 will be used for negative acknowledgements to report the receipt of A1-2 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 invalid SMHP headers. In such cases the received sequence number may not be determined. Heartbeat and version messages will also use the value 9999 for the sequence number in the header. The value of 0000 for the sequence number is reserved. Type 4 characters 'ACK ': communications level positive acknowledgement (0000 length message body) 'NAK ': communications level negative acknowledgement. The body will contain the header of the message being NAK'ed. 'GREQ', 'DCC ', 'PDC ' or 'TIS': application data messages. 'HART': heartbeat message (0000 length message body) 'VER': first PDU sent after successful TLS handshake to advertise the desired version of SMHP Version 1 byte The upper nibble contains the major version number and the lower nibble contains the minor version number of the SMHP being used. The initial version will be 0x10. The FAA will always implement newer versions of the protocol before CSPs. This will allow a CSP to advertise that it wishes to use an older version of the SMHP while working to upgrade to the latest version. If a CSP advertises a version which the FAA does not support, the connection will be denied. Pad 3 bytes A constant pattern 0xA5A5A5 interpreted as a sequence of bytes. This field can be checked for this value to ensure that the receiver is in sync with the writer of the data stream. Since the upper bit is set in the bytes of this pattern, this value cannot possibly be confused with any other value in the header of body of an SMHP PDU. A1.1.4.2 SMHP Body Format The SMHP body will only contain character oriented data. This obviates the need to convert data in SMHP messages to network byte order. The data in the SMHP body will be neither compressed nor encrypted. A1.1.4.3 SMHP Message Formats A1-3 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 SMHP messages can be divided into two groups: data messages and management messages. Management messages are used to manage the connection and will only be passed between the CSP client and TDLS-MS server processes. Data messages originate from and are consumed by applications external to the SMHP communications software. A1.1.4.3.1 SMHP Data Messages There are four types of SMHP data messages: GREQ (Gate Request), DCC (Courtesy Copy2), PDC and TIS (D-ATIS). The body for GREQ, DCC, PDC and TIS messages will contain International Air Transport Association (IATA) Type B messages. This format includes the destination and sender Automated Digital Network System (ADNS) addresses. SMHP GREQ Message Format A GREQ message (depicted in Table A1-6) is comprised of the SMHP header and the body which contains the GREQ message. Table A1-6 SMHP GREQ Message Body Length xxxx Sequence yyyy Type GREQ Version Pad Body 0x10 0xA5A5A5 GREQ MSG The body of a SMHP message of type GREQ can contain either a GREQ message or a GREQ reply message which contains the requested gate information. The TDLS-MS will only send GREQ messages to CSPs and CSPs will only send GREQ reply messages to the TDLS-MS. Note that the <SOH>, <STX>, and <ETX> strings are printable representations of the non-printable control characters SOH (ASCII 0x01), STX (0x02), and ETX (0x03) respectively. Table A1-7 depicts the format and gives an example of a GREQ message; Table A1-8 depicts the format and gives an example of a GREQ reply message. The Gate Assignment message element will be 5-8 alphanumeric characters; if the gate is unknown, a “G” will be sent. TDLS expects to receive a GREQ reply message from the AOC that contains this Gate Assignment message element to be displayed. The Subscriber Database allows AOCs to opt out from receiving a GREQ message from TDLS. Both GREQ and GREQ reply messages will be exchanged using SMHP. Table A1-7 GREQ Message Body Example Message Format (IATA Type B) Field Explanation 2 Example Within this and related TDLS technical documents, the term DCL Courtesy Copy (DCC) is used to denote the textual clearance information that is sent to the AOC from the ground system. It is analogous to the Dispatch message in the Data Comm Implementation Team materials. A1-4 TDLS to CSP Interface Requirement Document Version 1.1 Message Format (IATA Type B) <SOH>QU {IATA address TO } . {IATA address FROM} {DDHHMM} <STX>GRM { Sequence Number} {Flight ID } {Aircraft Reg #/Tail Number}{Departure Airport } <ETX> Field Explanation Receiving Automation System address (e.g., AOC automation) Sending Automation System address (e.g. TDLS at BNA) and day/time of message SMI (message type identifier) GRM for Gate Request Sequence number Flight ID (characters and numerals), optional tail number and departure airport End of Transmission NAS-IR-XXXXXXXX January 26, 2013 Example <SOH>QU ANPOCWN .BNATWXA 062117 <STX>GRM 89 SWA2331 N34522 KBNA <ETX> Table A1-8 GREQ Reply Message Body Example Message Format (IATA Type B) <SOH>QU {IATA address TO } .{IATA address FROM} {DDHHMM} <STX>GIR { Sequence Number} {Flight ID } {Aircraft Reg #/Tail Number}{Departure Airport } {Gate Assignment} <ETX> Field Explanation Receiving Automation System address (e.g., TDLS automation) Sending Automation System address (e.g. AOC) and day/time of message SMI(message type identifier) Gate ID Response Sequence number that matches sequence number of GREQ message for which this is a response Flight ID (characters and numerals), optional tail number and departure airport, gate assignment of Gxxx or G if unknown End of Transmission Example <SOH>QU BNATWXA . ANPOCWN 062118 <STX>GIR 89 SWA2331 N34522 KBNA B3 <ETX> SMHP DCC Message Format An Initial DCC message (depicted in Table A1-9) is comprised of the SMHP header and the body which contains the DCC message. A1-5 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 Table A1-9 SMHP DCC Initial Clearance Message Body Length Xxxx Sequence yyyy Type CCI Version Pad Body 0x10 0xA5A5A5 DCC MSG A Revised DCC message (depicted in Table A1-10) is comprised of the SMHP header and the body which contains the DCC message. The only difference between these two is the SMI in the Type field. Table A1-10 SMHP DCC Revised Clearance Message Body Length xxxx Sequence yyyy Type CCR Version Pad Body 0x10 0xA5A5A5 DCC MSG The body of a SMHP message of type DCC can contain either a DCC message or a DCC ACK message. The TDLS-MS will only send DCC messages to CSPs and CSPs will only send DCC ACK messages to the TDLS-MS. Note that the <SOH>, <STX>, and <ETX> strings are printable representations of the non-printable control characters SOH (ASCII 0x01), STX (0x02), and ETX (0x03) respectively. Table A1-11 depicts the format of an Initial DCC message, and provides an example of an Initial DCC message for a Cleared as Filed flight. The DCC message will always contain a separate full route string whenever an initial or revised DCL contains a partial route, and whenever the full route is not already included in the clearance sent up to the aircraft. All DCC message types (initials, revisions, and acknowledgements) will be exchanged using SMHP. The braces either identify or describe the data for the entry. Letters outside the braces, such as “QU”, are values that cannot be changed, modified, or deleted. Values between the brackets are part of the field. Additional information for the fields in Table A1-11 can be found in the DCIT DCL Trials Systems Integration Description Document. Table A1-11 Initial DCC Message Format for a Cleared as Filed Message Format (IATA Type B) <SOH>QU {IATA address TO } Field Explanation Example QU ANPOCWN Destination .{IATA address FROM} {DDHHMM} .OKCTWXA 081251 Automation System address <STX>CCI CCI SMI { Sequence Number} DCL DISPATCH MESSAGE – 003 DCL DISPATCH MESSAGE - NOT Sequence number and A1-6 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 Message Format (IATA Type B) NOT AN ATC CLEARANCE Field Explanation Example AN ATC CLEARANCE notification {Flight ID} {AirportDeparture} FDX9901 KMEM Flight ID and departure airport {Equipment} P{Departure time} D/A320/Q P1558 Equipment and departure time {Computer Identifier} {Expect Level [level]} 555 FL300 Computer code and expected altitude {Route Information} CLEARED TO KOAK AIRPORT CHLDR1.CHLDR Route Information (including Airport Destination, departure procedure, and departure transition fix) {Route Information} THEN AS FILED Route Information {Route Information} MAINT 5000FT Free Text Additional – Maintain Altitude {Free Text} DEP FREQ 124.650 Free Text Additional – Departure Frequency {Free Text} KMEM CHLDR1.CHLDR LIT057065 TUL KA39Y KD42U ILC OAL MADN5 KOAK Full Route String (indicates the route of flight as filed) <ETX> End of Transmission <ETX> Error! Not a valid bookmark self-reference. depicts the format and gives an example of a DCC ACK message. The DCC ACK format is similar to a PDC ACK; however, for a DCC ACK, any included gate information will be discarded by TDLS (TDLS expects gate information in a separate GREQ Reply message). A DCC ACK message from the AOCs is required by TDLS from those AOCs who receive a DCC message; the Subscriber Database allows AOCs to opt out from receiving any DCC message from TDLS. Table A1-12 DCC ACK Message Body Example Message Format (IATA Type B) <SOH>QU {IATA address TO } Field Explanation Receiving Automation System address (e.g., TDLS automation) A1-7 Example <SOH>QU BNATWXA TDLS to CSP Interface Requirement Document Version 1.1 Message Format (IATA Type B) .{IATA address FROM} {DDHHMM} <STX>DCC {Flight ID } {Sequence Number} {Aircraft Reg #/Tail Number}{ Departure Time} {Gate Assignment} <ETX> NAS-IR-XXXXXXXX January 26, 2013 Field Explanation Sending Automation System address (e.g. AOC) and day/time of message SMI (message type identifier) DCC Flight ID (characters and numerals), Sequence Number that matches sequence number of DCC message for which this is a response, optional Aircraft Registration Number/Tail Number, Departure Time in hours and minutes, optional Gate Assignment of ‘Gxxx’ or ‘G’ if unknown End of Transmission Example . ANPOCWN 062117 <STX>DCC SWA2331 89 N34522 P2145 G20B <ETX> Table A1-13 Revised DCC Message Body Example depicts the format of a revised DCC message and an example of a revised DCC message (revised UM79). The DCC ACK message shown in Message Format (IATA Type B) <SOH>QU {IATA address TO } Field Explanation Example QU ANPOCWN Destination .{IATA address FROM} {DDHHMM} .OKCTWXA 081251 Automation System address <STX>CCI CCI SMI { Sequence Number} DCL DISPATCH MESSAGE – NOT AN ATC CLEARANCE 003 DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE Sequence number and notification {Flight ID} {AirportDeparture} FDX9901 KMEM Flight ID and departure airport {Equipment} P{Departure time} D/A320/Q P1558 Equipment and departure time {Computer Identifier} {Expect Level [level]} 555 FL300 Computer code and expected altitude {Route Information} CLEARED TO KOAK AIRPORT CHLDR1.CHLDR Route Information (including Airport Destination, departure A1-8 TDLS to CSP Interface Requirement Document Version 1.1 Message Format (IATA Type B) Field Explanation NAS-IR-XXXXXXXX January 26, 2013 Example procedure, and departure transition fix) {Route Information} THEN AS FILED Route Information {Route Information} MAINT 5000FT Free Text Additional – Maintain Altitude {Free Text} DEP FREQ 124.650 Free Text Additional – Departure Frequency {Free Text} KMEM CHLDR1.CHLDR LIT057065 TUL KA39Y KD42U ILC OAL MADN5 KOAK Full Route String (indicates the route of flight as filed) <ETX> End of Transmission <ETX> Error! Not a valid bookmark self-reference. depicts the format and gives an example of a DCC ACK message. The DCC ACK format is similar to a PDC ACK; however, for a DCC ACK, any included gate information will be discarded by TDLS (TDLS expects gate information in a separate GREQ Reply message). A DCC ACK message from the AOCs is required by TDLS from those AOCs who receive a DCC message; the Subscriber Database allows AOCs to opt out from receiving any DCC message from TDLS. Table A1-12 Message Format (IATA Type B) <SOH>QU {IATA address TO } Field Explanation Example QU ANPOCWN Destination .{IATA address FROM} {DDHHMM} .OKCTWXA 081251 Automation System address <STX>CCI CCI SMI { Sequence Number} DCL DISPATCH MESSAGE – NOT AN ATC CLEARANCE 003 DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE Sequence number and notification {Flight ID} {AirportDeparture} FDX9901 KMEM Flight ID and departure airport {Equipment} P{Departure D/A320/Q P1558 Equipment and departure A1-9 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 Message Format (IATA Type B) time} Field Explanation {Computer Identifier} {Expect Level [level]} 555 FL300 Computer code and expected altitude {Route Information} CLEARED TO KOAK AIRPORT CHLDR1.CHLDR Route Information (including Airport Destination, departure procedure, and departure transition fix) {Route Information} THEN AS FILED Route Information {Route Information} MAINT 5000FT Free Text Additional – Maintain Altitude {Free Text} DEP FREQ 124.650 Free Text Additional – Departure Frequency {Free Text} KMEM CHLDR1.CHLDR LIT057065 TUL KA39Y KD42U ILC OAL MADN5 KOAK Full Route String (indicates the route of flight as filed) <ETX> End of Transmission <ETX> Example time Error! Not a valid bookmark self-reference. depicts the format and gives an example of a DCC ACK message. The DCC ACK format is similar to a PDC ACK; however, for a DCC ACK, any included gate information will be discarded by TDLS (TDLS expects gate information in a separate GREQ Reply message). A DCC ACK message from the AOCs is required by TDLS from those AOCs who receive a DCC message; the Subscriber Database allows AOCs to opt out from receiving any DCC message from TDLS. Table A1-12 is used for both the initial and the revised DCL. The braces either identify or describe the data for the entry. Letters outside the “QU”, are values that cannot be changed, modified, or deleted. Values between the part of the field. Additional information for the fields in Table A1-13 Revised DCC Message Body Example can be found in the DCIT DCL Trials Systems Integration Description Document. A1-10 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 Table A1-13 Revised DCC Message Body Example Message Format (IATA Type B) <SOH>QU {IATA address TO } Field Explanation Example QU ANPOCWN Destination .{IATA address FROM} {DDHHMM} .OKCTWXA 081251 Automation System address <STX>CCR CCR SMI { Sequence Number} DCL DISPATCH MESSAGE – NOT AN ATC CLEARANCE 005 DCL DISPATCH MESSAGE - NOT AN ATC CLEARANCE Sequence number and notification {Flight ID} {AirportDeparture} REVISED <Tag List> FDX9901 KMEM REVISED RTE DP Flight ID, departure airport and revision marking {Equipment} P{Departure time} D/A320/Q P1610 Equipment and departure time {Computer Identifier} REVISED {Expect Level [level]} 555 FL300 Computer code and expected altitude {Route Information} REVISED RTE CLEARED TO KA39Y VIA PIEPE ARG RZC PER Revised Route Information {Route Information} PIEPE1.PIEPE AFTER KA39Y REST OF ROUTE UNCHANGED Revised Departure Procedure Information {Route Information} MAINT 5000FT Free Text Additional – Maintain Altitude <ETX> End of Transmission <ETX> SMHP PDC Message Format A PDC message (depicted in Table A1-14) is comprised of the SMHP header and the body which contains the PDC message. Table A1-14 SMHP PDC Message Body Length Xxxx Sequence yyyy Type PDC Version Pad Body 0x10 0xA5A5A5 PDC MSG A1-11 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 The body of a SMHP message of type PDC can contain either a PDC message or a PDC ACK message. The TDLS-MS will only send PDC messages to CSPs and CSPs will only send PDC ACK messages to the TDLS-MS. Note that the <SOH>, <STX>, and <ETX> strings are printable representations of the non-printable control characters SOH (ASCII 0x01), STX (0x02), and ETX (0x03) respectively. Table A1-15 depicts examples of a PDC and a PDC ACK message that will be exchanged using SMHP. Table A1-15 PDC and PDC ACK Message Body Examples PDC Message Body (IATA Type B format): <SOH>QU ANPOCWN # <SOH>ADNS MSG Priority, Destination ADDR .BNATWXA 062117 # ADNS Source ADDR, Timestamp <STX>PDC # <STX>SMI 89 # System MSG ID # Flight ID, Beacon Code, Depart Point SWA2331 1375 KBNA B737/L P2145 # Aircraft Type/Heavy_Indicator, Depart Time 626 380 # Computer ID, Altitude KBNA BNA J45 STL IRK LMN # Route Information OVR ONL J151 BIL***KSEA # Route Information # Route Information/Remarks TITAN ONE DEPARTURE PROCEDURE, MAINT 5,000 EXP REQ ALT 10 MIN AFT T/O CONTACT DPT CNTL ON 119.35 # Remarks # Altitude Restriction Data # Departure Frequency Data TERMINAL RAMP IS UNCONTROLLED, # Remarks PUSHBACK AT YOUR DISCRETION, # Remarks CONTACT GROUND 121.9 FOR TAXI. # Remarks <ETX> # <ETX> PDC ACK Message (IATA Type B format): <SOH>QU BNATWXA # <SOH>ADNS MSG Priority, Destination ADDR .ANPOCWN 062117 # ADNS Source ADDR, Timestamp <STX>PDC # <STX>SMI SWA2331 89 Y C P2145 G 20B # Flight ID, MSG ID, Participating, C Depart Time, Gate <ETX> # <ETX> SMHP TIS Message Format A TIS message (depicted in Table A1-16) consists of the SMHP header and the body which contains the D-ATIS message. Table A1-16 SMHP TIS Message Body Length Xxxx Sequence yyyy Type TIS Version Pad 0x10 0xA5A5A5 A1-12 Body TIS MSG TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 The body of a TIS message can contain a TIS message or a TIS ACK message. The TDLS-MS will only send TIS messages to CSPs and CSPs will only send TIS ACK messages to the TDLS-MS. Note that the <SOH>, <STX>, and <ETX> strings are printable representations of the non-printable control characters SOH (ASCII 0x01), STX (0x02), and ETX (0x03) respectively. Table A1-17 depicts an example of a TIS and a TIS ACK message that will be exchanged using SMHP. Table A1-17 TIS and TIS ACK Message Body Examples TIS Message Body (IATA Type B format): <SOH>QU ANPDAXA # <SOH>ADNS MSG Priority, Destination ADDR .BNAATXA 071254 # ADNS Source ADDR, Timestamp <STX>TIS # <STX>SMI AD BNA /OS CR1253 # Body - BNA ATIS INFO R 1253Z. 30004KT 10SM SCT019 BKN095 BKN130 BKN200 25/21 A3001 (THREE ZERO ZERO ONE). ILS APCHS RY 2L, RY 2C IN USE. DEPG RY 2L, RY 2C. SIMUL DEPS IN PROG. CONTACT CLEARANCE DELIVERY 126.05 FOR CLEARANCE. NOTAMS... RWY 2R CLSD, RWY 31 CLSD. . . TAXIWAY ALPHA CLOSED NORTH OF ALPHA FOUR. Bird Activity in Vicinity of Airport. NUMEROUS TAXIWAY CLOSURES ASSOCIATED WITH CLOSED RUNWAYS. BNA TACAN AZIMUTH OTS. ...ADVS you have INFO R. <ETX> # <ETX> TIS ACK Message Body (IATA Type B format): <SOH>QU BNAATXA # <SOH>ADNS MSG Priority, Destination ADDR .ANPDAXA 071259 # ADNS Source ADDR, Timestamp <STX>TIS # <STX>SMI AD BNA /OS CR1253 # Body <ETX> # <ETX> A1.1.4.3.2 SMHP Management Messages ACK, NAK, and HART messages are SMHP management messages. SMHP ACK Management Message At the application level, SMHP data messages are acknowledged with a SMHP Acknowledgment (ACK) management message. The structure of a SMHP ACK management message is depicted in Table A1-18. The sequence number in the header is the same as the sequence number for the SMHP data message being acknowledged. Table A1-18 SMHP ACK Message Structure Body Length 0000 Sequence yyyy Type ACK Version Pad 0x10 0xA5A5A5 SMHP NAK Management Message A1-13 Body Null TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 At the application level, SMHP data messages can be rejected with a SMHP Negative Acknowledgment (NAK) management message. NAKs should only be sent in response to an invalid SMHP header. Table A1-19 depicts the structure of a NAK message. The invalid header is returned in the body so that it can be used by the sender to help determine the reason for the NAK. Table A1-19 SMHP NAK Message Structure Body Length 016 Sequence 9999 Type NAK Version Pad 0x10 0xA5A5A5 Body Bad Header If an SMHP NAK message is sent or received, the connection must be torn down and reestablished. SMHP HART Management Message The CSP client and the TDLS-MS server shall send an SMHP heartbeat (HART) management message if nothing has been sent for 5 seconds. This message is used to monitor the health of the communications channel. If nothing has been received from the peer for more than 20 seconds, the connection must be torn down and reestablished. Table A1-20 depicts the structure of a HART message. Table A1-20 SMHP HART Message Structure Body Length 0000 Sequence 9999 Type Version Pad HART 0x10 0xA5A5A5 Body Null SMHP Version Management Message The first message that the CSP should send to the TDLS-MS server after a successful TLS handshake is a version message. The version field should contain the highest version number that the CSP supports. Initially, the only version will be 1.0 encoded as 0x10. In the future, the FAA may upgrade SMHP and give the CSPs the option of remaining on the previous version of SMHP for a period of time. If a CSP advertises a version that the FAA does not support, the FAA will respond with a NAK message. Otherwise, the FAA will not respond to the VER message. Table A1-21 illustrates the structure of the VER message. Table A1-21 SMHP Version Message Structure Body Length 0000 Sequence 9999 Type VER Version Pad 0x10 0xA5A5A5 A1-14 Body Null TDLS to CSP Interface Requirement Document Version 1.1 A1.2 NAS-IR-XXXXXXXX January 26, 2013 SMHP TCP Parameters The TCP_NODELAY option should be set for TCP sockets so that multiple small packets can be sent before the first small packet is acknowledged at the TCP level. The messages that will be handled by SMHP will be small (especially the acknowledgments) and this should help ensure that the messages are received in a timely fashion. A1.3 A1.3.1 SMHP TLSv1 Parameters Version Compatibility The SMHP will only use TLSv1 (version 3.1 in the TLSv1 record header). Connections which attempt to use SSLv3 or SSLv2 will be rejected. A1.3.2 Cipher Suite Selection The SMHP client must advertise to the server in the ClientHello handshake message that it supports the TLS_RSA_WITH_NULL_SHA cipher suite. The TDLS-MS server will be programmed to use only TLS_RSA_WITH_NULL_SHA. This protocol suite uses RSA for key exchange and SHA1 for message digests. The WITH_NULL component of the cipher suite specifies that encryption will not be performed for the session. A1.3.3 Session Resumption Session resumption will not be supported by the SMHP. There will only be a handful of connections from the CSPs and these connections should be long lived. The minute increase in performance does not justify the increased complexity in the software to support session resumption. A1.3.4 Renegotiations The TDLS-MS server will not initiate renegotiations. However, if the CSP client initiates a renegotiation, the server will cooperate to generate a new TLS session. A1.3.5 Authentication During the TLSv1 handshake the TDLS-MS server will submit an X.509v3 server certificate to the CSP client and the CSP client will submit an X.509v3 client certificate to the TDLS-MS server. The client and server certificates will be signed and verified by IFCET's root CA certificate. IFCET will insert a unique identifier for each CSP in an extension in the CSP's client certificate that will be used identify the CSP when the CSP connects. A1.3.6 Handshake Errors If there were any errors with the TLSv1 handshake such as lack of TLS version compatibility, no cipher suite agreement, or an invalid client or server certificate then the connection must be torn down and the reason for the problem investigated. A1-15 TDLS to CSP Interface Requirement Document Version 1.1 A1.4 NAS-IR-XXXXXXXX January 26, 2013 SMHP Message Handling The procedures in this section to handle SMHP message apply to both the CSP client and the TDLS-MS server. Everything in this section assumes that a successful connection from CSP client has been made and that the TLSv1 handshake was successful. A1.4.1 Sending Heartbeat Messages Heartbeat messages (HART) monitor the communications channel to ensure continued connectivity between the channel endpoints. If an endpoint has had no data messages to send for at least 5 seconds, then it must send a heartbeat message to the peer. This enables the peer to distinguish between the lack of data to be transmitted with a break in the communications channel. If an endpoint has not received anything for 20 seconds, then it concludes that there is a break in the communications channel and the connection must be torn down and reestablished. A1.4.2 Sending Data Messages The communications software at each endpoint will periodically check for messages from external applications to send to the peer. This should be done every 100 - 200 milliseconds. When a message is available to send, an SMHP data message should be constructed in a buffer large enough to hold the entire message including the header. The whole message should be sent as a single system call. The variable used to populate the header sequence number should be updated as well as the variable for the time of the last message sent. SMHP data messages should be sent as fast as the communications channel will allow. A1.4.3 Receiving SMHP Messages The communications software at each endpoint will periodically (every 100 – 200 milliseconds) check for messages from the peer. Typically this would be done by using the select() system call which will return as soon as the socket for the TCP/IP interface becomes readable. When the socket becomes readable the communications software will perform the following steps. The software will first read 16 bytes for the header. The header will be parsed and the fields examined. The time of the last message received will be updated with the current time. The message will be handled according to its type. After parsing the header, the fields should be validated according the following criteria. The pad field must have the value 0xA5A5A5. The version field must be a supported value. Initially, the only supported value will be 0x10 (version 1.0). The body length field characters must be four ASCII digit characters (0x30 – 0x39). The sequence field characters must be four ASCII digit characters (0x30 – 0x39). The message type must be one of the values enumerated in Table A1-5 above. A1-16 TDLS to CSP Interface Requirement Document Version 1.1 NAS-IR-XXXXXXXX January 26, 2013 If the message is an SMHP data message, the body length has to be greater than 0. If the header is not valid, an SMHP NAK message must be constructed and sent to the peer. The invalid header should comprise the body of the message. After the message has been sent, the connection must be torn down and reestablished. A1.4.3.1 Handling SMHP Heartbeat Messages Heartbeat messages will be ignored except that they cause the time of last message received to be updated to the current time. Heartbeat messages are not acknowledged. A1.4.3.2 Handling SMHP Data Messages The communications software will read the number of bytes for the body as indicated by the header. The message type (GREQ, DCC, PDC or TIS) will be used to dispatch the message to the appropriate external application. An SMHP ACK message will be constructed and sent to the peer. The sequence number in the SMHP ACK message will be set to the value of the sequence number for the SMHP data message that was received. A1.4.3.3 Handling SMHP ACK Messages An SMHP ACK message informs the receiver that an SMHP data message that had been sent to the peer has been received and properly dispatched to the appropriate external application. The communications software can use this information to record the fact that the message was received by the peer and to track the performance of the communications channel. SMHP ACK messages are not acknowledged. A1.4.3.4 Handling SMHP NAK Messages An SMHP NAK message indicates that the peer received an invalid header. An invalid header could mean that the receiver was out of sync with the byte stream or the header was transmitted with incorrect values such as an invalid message type. The body of the SMHP NAK message contains the invalid header. The response to an SMHP NAK is to save the invalid header for analysis and tear down the connection. SMHP NAK messages are not acknowledged. A1-17