TDLS2_TIMS_CSP_Interface_Reqmts_IRD_4_26_13_Draft.doc

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