RFC 2351
Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP
RFC 2351: Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP ✈️
Bestie, this one is about airline traffic going over IP 💖 The title block says it was written by A. Robert at SITA. It's filed as Informational and dated May 1998. It doesn't list anything it obsoletes or updates, so no drama there 🌸
Status of this Memo 📌
This memo gives information to the Internet community. It is not an Internet standard of any kind, and it can be distributed without limits 🫶
Copyright Notice 💅
Copyright (C) The Internet Society (1998). All Rights Reserved.
Security Disclaimer 🙈
Okay bestie, this part is SERIOUS 😭 This document does not adequately address security concerns. The protocol itself has no security mechanisms. The document says traffic can be authenticated using external mechanisms that rely on static identifiers or what are apparently clear-text passwords, and neither of those gives sound security. It also says in general terms that traffic can be secured with IPSEC, but that sound security is left strictly optional 💀
Abstract 🦋
This memo defines a protocol for wrapping the airline-specific protocol up inside IP 📦
Table of Contents 🗺️
1. INTRODUCTION 2
2. TERMINOLOGY & ACRONYMS 4
3. LAYERING 7
4. TRAFFIC IDENTIFICATION 7
5. TCP PORT ALLOCATION 8
6. MATIP SESSION ESTABLISHMENT 8
7. OVERALL PACKET FORMAT FOR TYPE A & TYPE B 9
8. MATIP FORMAT FOR TYPE A CONVERSATIONAL TRAFFIC 10
8.1 Control Packet Format 10
8.1.1 Session Open format (SO) 10
8.1.2 Open Confirm format (OC) 12
8.1.3 Session Close (SC) 14
8.2 Data Packet Format 14
9. MATIP FORMAT FOR TYPE A HOST-TO-HOST TRAFFIC 15
9. 1 Control Packet Format 15
9.1.1 Session Open format (SO) 15
9.1.2 Open Confirm format (OC) 17
9.1.3 Session Close (SC) 17
9.2 Data Packet Format 18
10. MATIP FORMAT FOR TYPE B TRAFFIC 19
10.1 Control packet format 19
10.1.1 Session Open format (SO) 19
10.1.2 Open confirm format (OC) 20
10.1.3 Session Close (SC) 21
10.2 Data packet format 21
11. SECURITY CONSIDERATIONS 22
12. AUTHOR'S ADDRESS 22
13. FULL COPYRIGHT STATEMENT 231. Introduction ✨
The airline community has been running a worldwide data network for over 40 years 🌍 There are two main types of traffic:
Transactional traffic 💺
This is typically used for communication between an airline office or travel agency and a central computer system for seat reservations and ticket issuing. A dumb terminal or a PC reaches the central system (IBM or UNISYS) through a data network.
This traffic is also called TYPE A. It is based on real-time query/response with limited protection, high priority, and it can be discarded. The user can access only one predetermined central computer system. If there is no response (data loss), the user can duplicate the request 🔁
Messaging 📨
This is an e-mail application where real-time is not needed. However, a high level of protection is required. The addressing scheme uses an international format defined by IATA and contains the city and airline codes.
This traffic is also called TYPE B. It is sent with a high level of protection, multi-addressing, and 4 levels of priority 👑
The detailed formats for TYPE A and TYPE B messages are defined in the IATA standards 📚
At the bottom level, synchronous protocols have been built since the 1960s, well before the OSI and SNA standards. Iconic history 🕰️
At present, there is a big number of legacy equipment installed in thousands of airline offices around the world. Many airlines don't have immediate plans to replace their terminals with more modern equipment that uses open standards. They are looking for more economical ways to connect these terminals to the present reservation system 💸
Most airlines are willing to move from airline-specific protocols to standardized protocols so they can benefit from the lower cost of new technologies, but the migration has been slowed down by the following factors:
- Applications have not been migrated.
- Dumb terminals using airline protocols P1024B (IBM ALC) or P1024C (UNISYS UTS) are still numerous.
There are currently many different proprietary solutions based on gateways that take advantage of low-cost networking, but they are not scalable and cannot interact 🙄
In the future, TCP/IP will be used more commonly as a common transport for traffic types, because:
- TCP/IP is the standard protocol of UNIX based applications
- TCP/IP stacks are inexpensive
- TCP/IP is used on intranets.
The purpose of this RFC is to define the mapping of the airline traffic types over TCP/IP 🎀 Airlines implementing it in their systems should have a TCP/IP stack so they can exchange traffic as shown below:
!----! ( )
! !----------( )
!----! ( )
Type B HOST ( NETWORK )
( )
( ) !---o
!----! ( )--------! D !---o Type A stations
!----!----------( ) !---o
!----! ( )
TYPE A HOST !
!
!
!
--------
! !
--------
Network Messaging System
(D) : Gateway TYPE A routerThe different airline traffic flows covered by this RFC are:
- TYPE A Host / Terminal
- TYPE A Host / TYPE A host
- TYPE B Host / Network messaging System
For dumb terminals, a conversion is required on the terminal side so there is an IP connection between the host and the router. However, the IP connection is directly between the central airline host and the intelligent workstation if the workstation has a direct connection to the network, a TCP/IP stack, and a terminal emulation 💻✨
2. Terminology & Acronyms 📖
ALC: Airline Line Control. IBM airline-specific protocol (see P1024B).ASCII: American Standard Code for Information Interchange.ASCU: Agent Set Control Unit. Cluster at the user side.AX.25: Airline X.25. Airline application of the X.25 OSI model (published by IATA).BAUDOT: Alphabet defined in ITU-T Number 5. BAUDOT uses 5 bits. Padded BAUDOT uses 7 bits, with the Most significant bit (bit 7) for the parity and the bit 6 equal to 1.BATAP: Type B Application to Application Protocol. Protocol to secure the TYPE B traffic. It was specified by SITA and is now published by IATA (SCR Vol. 3).EBCDIC: Extended Binary Coded Decimal Interchange Code.Flow ID Traffic: Flow identifier used in host to host traffic to differentiate traffic flow types.HLD: High Level Designator. Indicates the entry or exit point of a block in the network.IA: Interchange Address. ASCU identifier in P1024B protocol.IATA: International Air Transport Association.IP: Internet Protocol.IPARS: International Program Airline Reservation System. IPARS code is used in ALC.HTH: Host to Host (traffic).LSB: Least Significant Bit.MATIP: Mapping of Airline Traffic over Internet Protocol.MSB: Most Significant Bit.OC: Open Confirm (MATIP command).OSI: Open Standard Interface.P1024B: SITA implementation of the ALC, the IBM airline-specific protocol. It uses 6-bit padded characters (IPARS) and IA/ TA for physical addressing.P1024C: SITA implementation of the UTS, the UNISYS terminal protocol. It uses 7-bit (ASCII) characters and RID/ SID for physical addressing.RFU: Reserved for Future Use.RID: Remote Identifier. ASCU identifier in P1024C protocol.SC: Session Close (MATIP command).SCR: System and Communication Reference (IATA document).SID: Station Identifier. Terminal identifier in P1024C protocol.SITA: Societe International de Telecommunications Aeronautiques.SO: Session Open (MATIP command).TA: Terminal Address. Terminal identifier in P1024B protocol.TCP: Transport Control Protocol.TYPE A Traffic: Interactive traffic or host to host.TYPE B Traffic: Messaging traffic in IATA compliant format with high level of reliability.UTS: Universal Terminal System by Unisys (see P1024C).
3. LAYERING 🧁
MATIP is an end to end protocol. Its purpose is to be a mapping standard between the TCP layer and the airline application without any routing element in between 🫧
+-------------------------------+
|Airline TYPE A | Airline TYPE B|
| | Application |
| |---------------|
| Application | BATAP |
+-------------------------------+
| MATIP A | MATIP B |
+-------------------------------+
| T.C.P |
+-------------------------------+
| I.P |
+-------------------------------+
| MEDIA |
+-------------------------------+4. TRAFFIC IDENTIFICATION 🔍
In TYPE A conversational traffic, the airline host application recognizes the ASCU by 4 bytes (H1, H2, A1, A2). These bytes are assigned by the host and are unique per ASCU. So a host can recognize the ASCU dynamically, independent of IP address 🪪
The H1 H2 A1 A2 bytes follow one of the three cases below:
A1,A2only are used andH1H2is set to0000.H1,H2identify the session andA1A2identifies the ASCU inside the session.H1,H2,A1,A2identify the ASCU.
The first two cases are fully compatible with the AX.25 mapping, where H1H2 may be equivalent to the HLD of the concentrator, i.e., 2 bytes hexadecimal. The third rule allows more flexibility but is not compatible with AX.25 🤓
In TYPE A host to host traffic, the identification field is also present and equals 3 bytes: H1 H2 Flow ID (optional). H1H2 are reserved for remote host identification (independently of the IP address) and must be allocated bilaterally 🤝
In Type B traffic, End Systems may be identified by HLDs, or directly by the pair of IP addresses 🖥️
5. TCP PORT ALLOCATION 🔌
IANA (Internet Assigned Numbers Authority) has allocated the following ports for MATIP TYPE A and TYPE B traffic:
MATIP Type A TCP port = 350
MATIP Type B TCP port = 351So you can tell whether traffic is type A or B just by looking at the TCP port 🦋
6. MATIP Session Establishment ✨
Okay so before two applications even start chatting, a single MATIP session gets set up on top of the TCP connection 💅 Its whole job is to figure out the traffic vibe, which covers:
- Subtype of traffic for TYPE A (Type A host to host or Type A conversational )
- Multiplexing used (for Type A)
- Data header
- Character set
Bestie, a separate session AND a separate TCP connection MUST be established for each set of parameters 🫶 For example, P1024B and P1024C traffic between two points needs two separate sessions. Different outfit, different session 👗
Either side can start the session 🙌 There's no keep-alive mechanism defined at the MATIP level, so session timeout just depends on the TCP timeout parameters ⏰
There are three commands for managing the MATIP session:
- Session Open (SO) to open a session.
- Open Confirm (OC) to confirm the SO command.
- Session close (SC) to close the current session.
A MATIP session can only be up if its TCP connection is up too 🌸 But closing the MATIP session doesn't mean you have to close the TCP connection. That part is not mandatory, so you're free to keep it open.
Here's the typical exchange:
TCP session establishment
Session Open --------->
<----------- Open confirm
data exchange
---------------------->
<-------------------------
.
.
.
Session Close ----------------->
.
.
.
<------------------------- Session Open
Open confirm ------------------->
data exchange
<-------------------------
---------------------->The Session Open command can carry configuration elements 🎀 If a Session Open command shows up on a session that's already open (same IP address and port number), the associated configuration gets automatically cleared, and a new one gets set up based on the info in that new open session command. Fresh start, no drama 💖
As the diagram shows, the open and close commands are symmetrical ✨
For type A conversational traffic, the SO and OC commands carry the info used to identify the ASCUs and the session 🦋 ASCUs are identified within a session by either two or four bytes. A flag says whether the ASCU is identified by four bytes (H1H2A1A2) or two bytes (A1A2). In the two-byte case, H1H2 is reserved for session identification.
The SO command is what opens the MATIP session. In Type A conversational traffic, it can contain the list of ASCUs configured in this session 🌈
The OC command confirms the SO command. It can refuse or accept it, either totally or conditionally. In Type A, it contains the list of ASCUs that were either rejected or configured in the session 💜
7. Overall Packet Format for Type A & Type B 🧚
The first 4 bytes of the MATIP header follow these rules, so pay attention bestie 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |C| Cmd | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Ver: This is the version of MATIP 🌷 It MUST contain the value 001, otherwise the packet is considered invalid.
C: This one tells you whether it's a CONTROL packet 🎯
- When set to 1, the packet is a Control packet.
- When set to 0, the packet is a Data packet.
Cmd: This field identifies the control command, but only if the C flag is set to 1 💫
length: This is the number of bytes in the whole packet, header included 📏
Notes: Fields marked as optional (Opt) aren't transmitted if they aren't used 🙈
8. MATIP Format for Type A Conversational Traffic 💅
8. 1 Control Packet Format
There are 3 control packets for opening or closing the session at the MATIP level 🫶
8.1.1 Session Open format (SO)
Before you send any data packets, you need to identify the session, so a Session Open command gets sent first 🔑 Either side can initiate it. If there's a collision, the open session from the side with the lower IP address gets ignored (rip to the lower IP 💀).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |1|1 1 1 1 1 1 0| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0|0 1|0| CD | STYP |0 0 0 0| RFU |MPX|HDR| PRES. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H1 | H2 | RFU |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | RFU | Nbr of ASCUs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nbr of ASCUs | ASCU list (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RFU: Reserved for future use 🔮 It MUST be set to zero.
CD: This field specifies the Coding 🔤
000 : 5 bits (padded baudot)
010 : 6 bits (IPARS)
100 : 7 bits (ASCII)
110 : 8 bits (EBCDIC)
xx1 : R.F.USTYP: This is the traffic subtype (the type being TYPE A) 🏷️
0001 : TYPE A ConversationalMPX: This flag says what multiplexing is used inside the TCP session 🧵 The possible values are:
00 : Group of ASCU with 4 bytes identification per ASCU (H1H2A1A2)
01 : Group of ASCUs with 2 bytes identification per ASCU (A1A2)
10 : single ASCU inside the TCP session.HDR: This field says which part of the airline's specific address goes ahead of the message texts sent over the session ✈️ The possible values are:
00 : ASCU header = H1+H2+A1+A2
01 : ASCU Header = A1+A2
10 : No Header
11 : Not usedMPX and HDR MUST be coherent with each other 🤝 When ASCUs are multiplexed, the data MUST contain the ASCU identification. Here's the table of allowed combinations:
+--------------------------+
| MPX | 00 | 01 | 10 |
+--------------------------+
| HDR | |
| 00 | Y | Y | Y |
| 01 | N | Y | Y |
| 10 | N | N | Y |
+--------------------------+PRES.: This field shows the presentation format 🎨
0001 : P1024B presentation
0010 : P1024C presentation
0011 : 3270 presentationH1 H2: These fields can logically identify the session when MPX isn't equal to 00 🪪 When this field isn't used, it MUST be set to 0. If it's used in the session (MPX <> 0) with HDR=00, the H1H2 in the data packet MUST have the same value as was set in the SO command.
Nbr of ASCUs: This field is mandatory and gives the number of ASCUs per session 🔢 A value of 0 (zero) means unknown. In that case the ASCU list isn't present in the Open Session command, and it MUST be sent by the other end in the Open Confirm command.
ASCU LIST: This contains the identifier for each ASCU 📋 If MPX=00, each ASCU takes four bytes (H1H2A1A2). Otherwise, each one takes two bytes (A1A2).
8.1.2 Open Confirm format (OC)
The OC (Open Confirm) command answers an SO (Session Open) command 💌 It's used to either refuse the session or accept it conditionally, depending on checking the configuration of each ASCU.
If it accepts, the OC says how many ASCUs were rejected (if any) and what their addresses are 🙅♀️ Or it lists the ASCUs configured for that MATIP session, if the list in the SO command was correct, or if the number of ASCUs configured in the session was unknown (number of ASCUs equals 0) 🎉
8.1.2.1 Refuse the connection
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cause |
+-+-+-+-+-+-+-+-+cause: This field gives the reason for refusing the MATIP session 🚫
0 0 0 0 0 0 0 1 : No Traffic Type matching between Sender &
Recipient
0 0 0 0 0 0 1 0 : Information in SO header incoherent
1 0 0 0 0 1 0 0
up to : Application dependent
1 1 1 1 1 1 1 1
Other values reserved.8.1.2.2 Accept the connection
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |1|1 1 1 1 1 0 1| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 R 0 0 0 0 0| Nbr of ASCUs |Nbr of ASCU(opt| ASCU LIST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R: This flag means there was an error in the ASCU configuration given in the SO command 🚨
NBR of ASCUs: If MPX is 00 in the SO command, this field is two bytes long. Otherwise, it's one byte 📏 If the R flag is set, this field is the number of ASCUs in error. Otherwise, it's the number of ASCUs configured for that MATIP session.
Notes: This field is either one or two bytes long. In the SO command, it's always two bytes. This mismatch comes from backward compatibility with AX25 (see chapter 4). In the SO command, it's possible to use a free byte defined in the AX25 call user data. Unfortunately, there's no such free byte in the AX25 clear user data 😭
ASCU LIST: Depending on the R flag, this lists the ASCUs (A1A2 or H1H2A1A2) either in error or within the session 📝
8.1.3 Session Close (SC)
The SC (Session Close) command is used to close an existing MATIP session 👋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |1|1 1 1 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Close Cause |
+-+-+-+-+-+-+-+-+Close Cause: This shows the reason the session was closed 🎬
0 0 0 0 0 0 0 0 : Normal Close
1 0 0 0 0 1 0 0
up to : Application dependent
1 1 1 1 1 1 1 1
Other values reserved.8.2 Data Packet Format 📦✨
okay so this is where the actual data rides, bestie 💅 every data packet starts with a header that's basically the same vibe as the control packets, just with the payload doing the real work 🫶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |0|0 0 0 0 0 0 0| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ID 🎀
This field is optional, and its length and format depend on the value of HDR and PRES that got agreed during the session establishment. It's giving "it depends on your settings" 💖
+------------------------------+-------------------------------+
|HDR | PRES = P1024B and 3270 | PRES = P1024C |
+------------------------------+-------------------------------+
|00 |ID = 4 bytes H1-H2-A1-A2 | ID = 5 bytes H1-H2-A1-0x01-A2 |
+------------------------------+-------------------------------+
|01 |ID = 2 bytes A1-A2 | ID = 3 bytes A1-0x01-A2 |
+------------------------------+-------------------------------+
|10 |ID = 0 bytes | ID = 0 bytes |
+------------------------------+-------------------------------+The H1 and H2 values must match the value given in the SO command if MPX is different from 0. Not a detail to skip, bestie 👀
Payload 🧚
The payload begins with the terminal identification:
- One byte Terminal identifier (TA) in P1024B
- Two bytes SID/DID Terminal identifier in P1024C.
9. MATIP FORMAT FOR TYPE A HOST-TO-HOST TRAFFIC 💜
9. 1 Control Packet Format 🎀
okay so there are 3 control packets to open or close the session at the MATIP level. Same three-of-a-kind energy as before, just the Type A host-to-host version 💅
9.1.1 Session Open format (SO) 🦋
Before you send any data packet, you need to identify the session, so a Session Open command gets sent first. Either side can start it. If both sides try at the same time (a collision), the open session from the side with the lower IP address gets ignored. Rude, but that's the rule 🙈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |1|1 1 1 1 1 1 0| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0|0 1|0| CD | STYP |0 0 0 0| RFU |MPX|HDR|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H1 | H2 | RFU |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID(opt)|
+-+-+-+-+-+-+-+-+RFU 🌸 Reserved for future use. Must be set to zero.
CD 🍓 This field specifies the Coding, as defined in section 8.1.1.1.
STYP 💖 This is the traffic subtype (the type being Type A).
0010 : TYPE A IATA Host to Host
1000 : SITA Host to HostMPX ✨ This flag specifies the multiplexing used within the MATIP session in TYPE A SITA host to host. The possible values are:
00 : irrelevant
01 : multiple flow inside the TCP connection
10 : single flow inside the TCP connectionHDR 🌈 This field specifies which part of the airline's specific address is placed ahead of the message text transmitted over the session. The possible values are:
00 : used in TYPE A SITA Host to Host Header = H1+H2+Flow ID
01 : used in TYPE A SITA Host to Host Header = Flow ID
10 : No Header (default for IATA host to Host)
11 : Not usedThe MPX and HDR must be coherent. When flows are multiplexed, the data must contain the flow identification. The table below sums up the possible combinations, so screenshot this one 📸
+---------------------+
| MPX | 01 | 10 |
+---------------------+
| HDR | | |
| 00 | Y | Y |
| 01 | Y | Y |
| 10 | N | Y |
+---------------------+H1 H2 🦋 These fields can be used to identify the session. When this field is not used, it must be set to 0. If HDR=00, the H1H2 in the data packet must have the same value as set in the SO command. Main character energy for matching values 👑
Flow ID 🧚 This field is optional and indicates the Flow ID (range 3F - 4F Hex).
9.1.2 Open Confirm format (OC) 🫶
The OC (Open Confirm) command is a response to an SO (Session Open) command. It's used to either refuse the session or accept it. Yes or no, babe 💅
9.1.2.1 Refuse the connection 💀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cause |
+-+-+-+-+-+-+-+-+Cause 🍓 This field indicates the reason for the MATIP session refusal:
0 0 0 0 0 0 0 1 : No Traffic Type matching between Sender &
Recipient
0 0 0 0 0 0 1 0 : Information in SO header incoherent
1 0 0 0 0 1 0 0
up to : Application dependent
1 1 1 1 1 1 1 1
Other values reserved.9.1.2.2 Accept the connection 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+9.1.3 Session Close (SC) 🔥
The SC (Session Close) command is used to close an existing MATIP session. Bye bye, session 👋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |1|1 1 1 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Close Cause |
+-+-+-+-+-+-+-+-+Close Cause 🌈 Indicates the reason for the session closure:
0 0 0 0 0 0 0 0 : Normal Close
1 0 0 0 0 1 0 0
up to : Application dependent
1 1 1 1 1 1 1 1
Other values reserved9.2 Data Packet Format 📬
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |0|0 0 0 0 0 0 0| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ID 🎀 This field is optional, and its length and format depend on the value of HDR indicated during the session establishment.
+-------------------------------+
|HDR | I.D. |
+-------------------------------+
|00 |ID = 3 bytes H1-H2 FLOW ID|
+-------------------------------+
|01 |ID = FLOW ID |
+-------------------------------+
|10 |ID nor present |
+-------------------------------+Payload packet 💜 The payload format is relevant to the MATIP layer. It's formatted according to the IATA host to host specifications and agreed bilaterally by the sender and the receiver. Two parties, one agreement 🤝
10. MATIP FORMAT FOR TYPE B TRAFFIC 🌈
10.1 Control packet format 🎀
There are 3 control packets used to open or close the session at the MATIP level for exchanging Type B data
10.1.1 Session Open format (SO) 🦋
Before sending any data packets, it is recommended to let the systems establishing a session check that they are indeed able to communicate (i.e., both systems agree on the characteristics of the traffic that will cross the connection). So a two way handshake, using the Session commands defined below, is performed right after the TCP level connection is established. Either side can start this procedure. If there's a collision, the open session from the side with the lower IP address gets ignored, same as Type A ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |1|1 1 1 1 1 1 0| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0| C D | PROTEC| BFLAG | Sender HLD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recipient HLD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length 🍓 This field indicates the number of bytes of the whole command, header included. The only possible values are 6 bytes or 10 bytes.
CD 🌸 This field specifies the Coding, as defined in section 8.1.1.1.
PROTEC 💖 Identifies the end to end Messaging Responsibility Transfer protocol used.
0010: BATAPAll other values are available.
BFLAG ✨ (X means `do not care'.)
X X 0 0 means that the fields Sender HLD, Recipient HLD do not exist in this packet. In this case, the exact length of the packet is 6 Bytes.
X X 1 0 means that the Sender HLD, Recipient HLD are carried respectively in bytes 9,10 and 11,12 of this packet. In this case, the exact length of the packet is 10 Bytes.
0 0 X X means that the connection request has been transmitted from a host (Mainframe system).
0 1 X X means that the connection request has been transmitted from a gateway).
Sender HLD 🧚 HLD of the Type B System sending the Session Open.
Recipient HLD 👑 HLD of the Type B system to which session opening is destined.
10.1.2 Open confirm format (OC) 🫶
The OC (Open Confirm) command is a response to an SO (Session Open) command. It's used to either refuse the session or accept it. Same energy as Type A, no cap 💅
10.1.2.1 Refuse the connection 💀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Cause |
+-+-+-+-+-+-+-+-+Length of this packet is 5 Bytes.
Cause 🎀 Indicates the cause of the rejection:
0 0 0 0 0 1 : No Traffic Type matching between Sender & Recipient
0 0 0 0 1 0 : Information in SO header incoherent
0 0 0 0 1 1 : Type of Protection mechanism are different
0 0 0 1 0 0 up to 1 1 1 1 1 1 : R.F.U10.1.2.2 Accept the connection ✨
okay so this one is the "yes, let's talk" packet 🦋 It's only 5 bytes, so it's super tiny and cute. Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+Length of this packet is 5 Bytes. 🌸
10.1.3 Session Close (SC) 💀
bestie, the SC (Session Close) command is the one you send when you want to end an existing MATIP session. Bye bye, session 👋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |1|1 1 1 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Close Cause |
+-+-+-+-+-+-+-+-+The Close Cause field tells everyone why the session is ending, and it's giving detective energy 🔍 The values work like this:
Close Cause
Indicates the reason for the session closure:
0 0 0 0 0 0 0 0 : Normal Close
1 0 0 0 0 1 0 0 up to 1 1 1 1 1 1 1 1 : Application dependent
Other values reservedSo a normal goodbye is all zeros 🫶 The "application dependent" range is up to the app to decide what it means, and anything else is reserved for later.
10.2 Data packet format 📦
this is where the actual messages live, and I'm obsessed with how simple it is 😭 The layout looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0| Ver |0|0 0 0 0 0 0 0| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length is the total number of bytes in the whole packet, header included. Counting the header in is a very important detail, so don't forget it 🍓
Payload is a Type B message that's formatted according to the IATA standard and follows the rules of the TYPE B service you're connecting to. So the packet is basically a little envelope carrying an airline-standard message 💌
11. Security Considerations 🔐
okay, security is a very big deal in the airline industry, so this part gets dramatic 💅 MATIP users can be protected at a few different levels.
First up, the ASCU has to be defined before it can start a session with the host application. There are two ways to do that. Either the ASCU address (H1 H2 A1 A2) is set at the application level through static configuration, or the ASCU is identified with a User ID / password. Most of the time, a dedicated piece of software on the central host checks that User ID and Password, but the application itself can also check them. 🎀
Next, MATIP sessions travel over TCP/IP, which means they can go through a firewall 🧱 Depending on how strong the firewall is, the check can happen at the network layer (using IP addresses) or at the TCP application layer.
For a higher level of security, compliant implementations MAY implement IPSEC ESP to protect control packets 🛡️ Replay protection, the compulsory cipher suite for IPSEC ESP, and NULL encryption MAY be implemented too. IPSEC AH is optional, and it MAY also be supported. Compliant implementations MAY also implement IPSEC ESP to protect data packets 🔥 Replay prevention and integrity protection using the IPSEC ESP mandated cipher suit MAY be implemented. NULL encryption also MAY be supported, and other IPSEC ESP required ciphers MAY also be supported.
12. Author's Address 🧚
Alain Robert S.I.T.A. 18, rue Paul Lafargue 92904 PARIS LA DEFENSE 10 FRANCE
Phone: 33 1 46411491 Fax: 33 1 46411277 EMail: arobert@par1.par.sita.int
13. Full Copyright Statement ⭐
Copyright (C) The Internet Society (1998). All Rights Reserved. 🌈
This document and translations of it may be copied and shared with others. Derivative works that comment on or explain it, or that help with implementing it, may also be written, copied, published and distributed, in whole or in part, with no restriction of any kind. The one condition is that the copyright notice above and this paragraph are included on every copy and derivative work. The document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards (in which case the copyright procedures in the Internet Standards process must be followed) or when it's being translated into languages other than English.
These limited permissions are perpetual and will not be revoked by the Internet Society or its successors or assigns. 💜
The document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈
📦 where this page comes from
- ietf: rfc2351 1998-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms