As per Relevance of the word indicate, we have this rfc below:
Network Working Group A.
Request for Comments: 2351
Category: Informational May 1998
Mapping of Airline Reservation, Ticketing
and Messaging Traffic over
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
Security Disclaimer
This document fails to adequately address security concerns.
protocol itself does not include any security mechanisms.
document notes that traffic can be authenticated based on
mechanisms that use static identifiers or what are apparently clear
text passwords, neither of which provide sound security.
document notes in general terms that traffic can be secured
IPSEC, but leaves this form of sound security strictly optional
This memo specifies a protocol for the encapsulation of the
specific protocol over IP
Table of
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
Robert Informational [Page 1]
RFC 2351 MATIP May 1998
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 23
1.
The airline community has been using a worldwide data network
over 40 years, with two main types of traffic
Transactional
This is used typically for communication between an airline
or travel agency and a central computer system for
reservations and ticket issuing. A dumb terminal or a PC
the central system (IBM or UNISYS) through a data network
This traffic is also called TYPE A and is based on real-
query/response with limited protection, high priority and can
discarded. The user can access only one predetermined
computer system. In case of no response (data loss), the user
duplicate the request
This is an e-mail application where real-time is not needed
However a high level of protection is required. The
scheme uses an international format defined by IATA and
the city and airline codes
This traffic is also called TYPE B and is transmitted with a
level of protection, multi-addressing and 4 levels of priority
The detailed formats for TYPE A and TYPE B messages are defined
the IATA standards
Robert Informational [Page 2]
RFC 2351 MATIP May 1998
At the bottom level, synchronous protocols have been built
1960's and well before the OSI and SNA standards
At present, there is a big number of legacy equipment installed
thousands of airline offices around the world. Many airlines do
have immediate plans to replace their terminals with more
equipment using open standards. They are in search of more
ways for connecting these terminals to the present
system
Most airlines are willing to migrate from airline specific
to standardized protocols in order to benefit from the lower cost
new technologies, but the migration has been slow done to
following factors
- Applications have not been migrated
- Dumb terminals using airline protocols P1024B (IBM ALC) or P1024
(UNISYS UTS) are still numerous
There are currently many different proprietary solutions based
gateways available to take advantage of low cast networking, but
are not scalable and cannot interact
In the future, TCP/IP will be more commonly used as a
transport means for traffic types because
- TCP/IP is the standard protocol of UNIX based
- TCP/IP stacks are
- TCP/IP is used on intranets
The purpose of this RFC is to define the mapping of the
traffic types over TCP/IP. The airlines implementing it in
systems should have a TCP/IP stack to enable the traffic
below
Robert Informational [Page 3]
RFC 2351 MATIP May 1998
!----! ( )
! !----------( )
!----! ( )
Type B HOST ( NETWORK )
( )
( ) !---
!----! ( )--------! D !---o Type A
!----!----------( ) !---
!----! ( )
TYPE A HOST !
!
!
!
--------
! !
--------
Network Messaging
(D) : Gateway TYPE A
The different airline traffic flows concerned by this RFC are
- TYPE A Host /
- TYPE A Host / TYPE A
- TYPE B Host / Network messaging
In the case of dumb terminals, a conversion is required on
terminal side in order to have an IP connection between the host
the router. However, the IP connection is directly between
central airline host and the intelligent workstation if the
has a direct connection to the network, a TCP/IP stack and a
2. Terminology &
Airline Line Control: IBM airline specific protocol (see P1024B
American Standard Code for Information
Agent Set Control Unit: Cluster at the user side
AX.25
Airline X.25: Airline application of the X.25 OSI model (published
IATA
Robert Informational [Page 4]
RFC 2351 MATIP May 1998
Alphabet defined in ITU-T Number 5. BAUDOT uses 5 bits. Padded
uses 7 bits with the Most significant bit (bit 7) for the parity
the bit 6 equal to 1.
Type B Application to Application Protocol. Protocol to secure
TYPE B traffic. It was specified by SITA and is now published by
(SCR Vol. 3)
Extended Binary Coded Decimal Interchange
Flow ID
Flow identifier used in host to host traffic to
traffic flow types
High Level Designator: Indicates the entry or exit point of a
in the network
Interchange Address: ASCU identifier in P1024B protocol
International Air Transport
Internet
International Program Airline Reservation System: IPARS code is
in
Host to Host (traffic).
Least Significant
Mapping of Airline Traffic over Internet
Most Significant
Open Confirm (MATIP command
Robert Informational [Page 5]
RFC 2351 MATIP May 1998
Open Standard
P1024
SITA implementation of the ALC, the IBM airlines specific protocol
It uses 6-bit padded characters (IPARS) and IA/ TA for
addressing
P1024
SITA implementation of the UTS, the UNISYS terminal protocol. It
7-bit (ASCII) characters and RID/ SID for physical addressing
Reserved for Future
Remote Identifier: ASCU identifier in P1024C protocol
Session Close (MATIP command
System and Communication Reference. (IATA document
Station Identifier: Terminal identifier in P1024C protocol
Societe International de Telecommunications
Session Open (MATIP command
Terminal Address: Terminal identifier in P1024B protocol
Transport Control
TYPE A
Interactive traffic or host to
TYPE B
Messaging traffic in IATA compliant format with high level
Universal Terminal System by Unisys: (see P1024C
Robert Informational [Page 6]
RFC 2351 MATIP May 1998
3.
MATIP is an end to end protocol. Its purpose is to have a
standard between the TCP layer and the airline application
any routing element
+-------------------------------+
|Airline TYPE A | Airline TYPE B
| | Application |
| |---------------|
| Application | BATAP |
+-------------------------------+
| MATIP A | MATIP B |
+-------------------------------+
| T.C.P |
+-------------------------------+
| I.P |
+-------------------------------+
| MEDIA |
+-------------------------------+
4. TRAFFIC
In TYPE A conversational traffic, the airline host
recognizes the ASCU due to 4 bytes (H1, H2, A1, A2). These bytes
assigned by the host and are unique per ASCU. Thus, a host
dynamically recognize the ASCU independent of IP address
H1 H2 A1 A2 bytes follow one of the three cases below
- A1,A2 only are used and H1H2 is set to 0000.
- H1,H2 identify the session and A1A2 the ASCU inside the session
- H1,H2,A1,A2 identify the ASCU
The first two cases are fully compatible with the AX.25 mapping
H1H2 may be equivalent to the HLD of the concentrator, i.e., 2
hexadecimal. The third rule allows more flexibility but is
compatible with AX.25.
In TYPE A host to host traffic the identification field is
present and is equal to 3 bytes H1 H2 Flow ID (optional). H1H2
reserved for remote host identification (independently of the
address) and must be allocated bilaterally
In Type B traffic, identification of End Systems may be carried
by the use of HLDs, or directly by the pair of IP addresses
Robert Informational [Page 7]
RFC 2351 MATIP May 1998
5. TCP PORT
IANA (Internet Assigned Numbers Authority) has allocated
following ports for MATIP TYPE A and TYPE B traffic
MATIP Type A TCP port = 350
MATIP Type B TCP port = 351
Therefore the traffic type A or B is selected according to the
port
6. MATIP SESSION
Prior to any exchange between two applications, a single
session is established above the TCP connection in order to
the traffic characteristic such as
- Subtype of traffic for TYPE A (Type A host to host or Type
conversational )
- Multiplexing used (for Type A
- Data
- Character
A separate session and TCP connection must be established for
set of parameters (e.g., P1024B, P1024C traffic between two
needs two separate sessions).
The establishment of a MATIP session can be initiated by either side
No keep-alive mechanism is defined at MATIP level. Session time
relies on the TCP time-out parameters
There are three commands defined to manage 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 be up only if the associated TCP connection
up. However it is not mandatory to close the TCP connection
closing the associated MATIP session
Typical exchange is
TCP session
Session Open --------->
<----------- Open
data
---------------------->
Robert Informational [Page 8]
RFC 2351 MATIP May 1998
<-------------------------
.
.
.
Session Close ----------------->
.
.
.
<------------------------- Session
Open confirm ------------------->
data
<-------------------------
---------------------->
The Session Open command may contain configuration elements.
Session Open command received on a session already opened (i.e.,
IP address and port number) will automatically clear the
configuration and a new configuration will be set up according to
information contained in the new open session command
As illustrated above, the open and close commands are symmetrical
For type A conversational traffic, the SO and OC commands
information for the identification of the ASCUs and the session
ASCUs are identified within a session by two or 4 bytes. A flag
set to indicate if the ASCU is identified by 4 bytes (H1H2A1A2) or
2 bytes (A1A2). In the latter case, H1H2 is reserved for
identification
The SO command is sent to open the MATIP session. In Type
conversational it may contains the list of ASCUs configured in
session
The OC command confirms the SO command. It can refuse or accept it
totally or conditionally. In Type A, it contains the list of
ASCUs either rejected or configured in the session
7. OVERALL PACKET FORMAT FOR TYPE A & TYPE
The first 4 bytes of the MATIP header follow the following rules
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Robert Informational [Page 9]
RFC 2351 MATIP May 1998
The `Ver' (Version) field represents the version of the MATIP.
must contain the value 001 otherwise the packet is considered
invalid
Identifies a CONTROL packet
When set to 1, the packet is a Control
When set to 0, the packet is a Data
This field identifies the control command if the flag C is set to 1.
This field indicates the number of bytes of the whole packet,
included
Notes : Fields identified as optional (Opt) are not transmitted
not used
8. MATIP FORMAT FOR TYPE A CONVERSATIONAL
8. 1 Control Packet
There are 3 control packets to open or close the session at the
level
8.1.1 Session Open format (SO
To be able to identify the session and before sending any
packets, a Session Open command is sent. It can be initiated
either side. In case of collision, the open session from the
having the lower IP address is ignored
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Robert Informational [Page 10]
RFC 2351 MATIP May 1998
Reserved for future use. Must be set to zero
This field specifies the
000 : 5 bits (padded baudot
010 : 6 bits (IPARS
100 : 7 bits (ASCII
110 : 8 bits (EBCDIC
xx1 : R.F.
This is the traffic subtype (type being TYPE A).
0001 : TYPE A
This flag specifies the multiplexing used within the TCP session
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
This field specifies which part of the airline's specific address
placed ahead of the message texts transmitted over the session
Possible values are
00 : ASCU header = H1+H2+A1+A
01 : ASCU Header = A1+A
10 : No
11 : Not
The MPX and HDR must be coherent. When ASCUs are multiplexed, the
must contain the ASCU identification. The table below summarizes
allowed combinations
+--------------------------+
| MPX | 00 | 01 | 10 |
+--------------------------+
| HDR | |
| 00 | Y | Y | Y |
| 01 | N | Y | Y |
| 10 | N | N | Y |
+--------------------------+
Robert Informational [Page 11]
RFC 2351 MATIP May 1998
This field indicates the presentation
0001 : P1024B
0010 : P1024C
0011 : 3270
H1 H
These fields can logically identify the session if MPX is not equal
00. When this field is not used, it must be set to 0. If used
session (MPX <> 0) with HDR=00, H1H2 in data packet must have the
value as set in SO command
Nbr of
Nbr_of_ASCUs field is mandatory and gives the number of ASCUs
session. A 0 (zero) value means unknown. In this case the ASCU list
not present in the `Open Session' command and must be sent by
other end in the `Open Confirm' command
ASCU
Contains the list of identifier for each ASCU. If MPX=00 it has
length of four bytes (H1H2A1A2) for each ASCU, otherwise it is
bytes (A1A2).
8.1.2 Open Confirm format (OC
The OC (Open Confirm) command is a response to an SO (Session Open
command and is used to either refuse the session or accept
conditionally upon checking hte configuration of each ASCU
In case of acceptance, the OC indicates the number and the address
the rejected ASCUs, if any. Alternatively, it indicates the list
ASCUs configured for that MATIP session if the list provided by
SO command was correct or the number of ASCUs configured in
session was unknown (n. of ASCU equals 0).
8.1.2.1 Refuse the
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 |
+-+-+-+-+-+-+-+-+
This field indicates the reason for the MATIP session refusal
Robert Informational [Page 12]
RFC 2351 MATIP May 1998
0 0 0 0 0 0 0 1 : No Traffic Type matching between Sender &
0 0 0 0 0 0 1 0 : Information in SO header
1 0 0 0 0 1 0 0
up to : Application
1 1 1 1 1 1 1 1
Other values reserved
8.1.2.2 Accept the
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flag indicating an error in the ASCU configuration provided in the
command
NBR of
If the MPX value is equal to 00 in the SO command, this field is
bytes long. Otherwise, it is one byte
If the R flag is set, the Nbr_of_ASCUs field represents the number
ASCUs in error. Otherwise, it indicates the number of ASCUs
for that MATIP session
Notes: The length of this field is either one or two bytes. In the
command, the length is always two bytes. This discrepancy comes
backward compatibility with AX25 (see chapter 4). In the SO command
it is possible to use a free byte defined in the AX25 call user data
Unfortunately, there is no such free byte in the AX25 clear
data
ASCU
Depending on the R flag, this field indicates the list of ASCUs (A1A
or H1H2A1A2) either in error or within the session
Robert Informational [Page 13]
RFC 2351 MATIP May 1998
8.1.3 Session Close (SC
The SC (Session Close) command is used to close an existing
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
Indicates the reason for the session closure
0 0 0 0 0 0 0 0 : Normal
1 0 0 0 0 1 0 0
up to : Application
1 1 1 1 1 1 1 1
Other values reserved
8.2 Data Packet
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This field is optional and has a different length and
according to the value of HDR, PRES indicated during the
establishment
Robert Informational [Page 14]
RFC 2351 MATIP May 1998
+------------------------------+-------------------------------+
|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 |
+------------------------------+-------------------------------+
H1, H2 value must match the value given in the SO command if MPX
different from 0.
payload begins with the terminal identification
- One byte Terminal identifier (TA) in P1024
- Two bytes SID/DID Terminal identifier in P1024C
9. MATIP FORMAT FOR TYPE A HOST-TO-HOST
9. 1 Control Packet
There are 3 control packets to open or close the session at the
level
9.1.1 Session Open format (SO
To be able to identify the session and before sending any
packet, a Session Open command is sent. It can be initiated by
side. In case of collision, the open session from the side having
lower IP address is ignored
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)|
+-+-+-+-+-+-+-+-+
Reserved for future use. Must be set to zero
Robert Informational [Page 15]
RFC 2351 MATIP May 1998
This field specifies the Coding, as defined in section 8.1.1.1.
This is the traffic subtype (type being Type A).
0010 : TYPE A IATA Host to
1000 : SITA Host to
This flag specifies the multiplexing used within the MATIP session
TYPE A SITA host to host. Possible values are
00 :
01 : multiple flow inside the TCP
10 : single flow inside the TCP
This field specifies which part of the airline's specific address
placed ahead of the message text transmitted over the session
Possible values are
00 : used in TYPE A SITA Host to Host Header = H1+H2+Flow
01 : used in TYPE A SITA Host to Host Header = Flow
10 : No Header (default for IATA host to Host
11 : Not
The MPX and HDR must be coherent. When flow are multiplexed, the
must contain the flow identification. The table below summarizes
possible combinations
+---------------------+
| MPX | 01 | 10 |
+---------------------+
| HDR | | |
| 00 | Y | Y |
| 01 | Y | Y |
| 10 | N | Y |
+---------------------+
H1 H
These fields can be used to identify the session. When this field
not used, it must be set to 0. If HDR=00, H1H2 in data packet
have the same value as set in SO command
Flow
This field is optional and indicates the Flow ID (range 3F - 4F Hex).
Robert Informational [Page 16]
RFC 2351 MATIP May 1998
9.1.2 Open Confirm format (OC
The OC (Open Confirm) command is a response to an SO (Session Open
command and is used to either refuse the session or accept it
9.1.2.1 Refuse the
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 |
+-+-+-+-+-+-+-+-+
This field indicates the reason for the MATIP session
0 0 0 0 0 0 0 1 : No Traffic Type matching between Sender &
0 0 0 0 0 0 1 0 : Information in SO header
1 0 0 0 0 1 0 0
up to : Application
1 1 1 1 1 1 1 1
Other values reserved
9.1.2.2 Accept the
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
session
Robert Informational [Page 17]
RFC 2351 MATIP May 1998
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
Indicates the reason for the session closure
0 0 0 0 0 0 0 0 : Normal
1 0 0 0 0 1 0 0
up to : Application
1 1 1 1 1 1 1 1
Other values
9.2 Data Packet
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This field is optional and has a different length and
according to the value of HDR indicated during the
establishment
+-------------------------------+
|HDR | I.D. |
+-------------------------------+
|00 |ID = 3 bytes H1-H2 FLOW ID
+-------------------------------+
|01 |ID = FLOW ID |
+-------------------------------+
|10 |ID nor present |
+-------------------------------+
Robert Informational [Page 18]
RFC 2351 MATIP May 1998
Payload
The payload format is relevant to the MATIP layer. It is
according to the IATA host to host specifications and
bilaterally by the sender and the receiver
10. MATIP FORMAT FOR TYPE B
10.1 Control packet
There are 3 control packets used to open or close the session at
MATIP level for exchanging Type B
10.1.1 Session Open format (SO
Before sending any data packets, it is recommended to let the
establishing a session check that they are indeed able to
(i.e., Both systems agree on the characteristics of the traffic
will cross the connection). For this purpose, a two way handshake
using the Session commands defined hereafter, is
immediately after the establishment of the TCP level connection
Either side can initiate this procedure. In case of collision,
open session from the side having the lower IP address is ignored
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This field indicates the number of bytes of the whole command,
included. The only possible values are equal to 6 bytes or 10 bytes
This field specifies the Coding, as defined in section 8.1.1.1.
Identifies the end to end Messaging Responsibility Transfer
used
0010:
All other values available
BFLAG (X means `do not care
Robert Informational [Page 19]
RFC 2351 MATIP May 1998
X X 0 0 means that the fields `Sender HLD, Recipient HLD' do not
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
respectively in bytes 9,10 and 11,12 of this packet. In
case, the exact length of the packet is 10 Bytes
0 0 X X means that the connection request has been transmitted from
host (Mainframe system
0 1 X X means that the connection request has been transmitted from
gateway
Sender
HLD of the Type B System sending the Session Open
Recipient
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 and is used to either refuse the session or accept it
10.1.2.1 Refuse the
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
Indicates the cause of the
0 0 0 0 0 1 : No Traffic Type matching between Sender &
0 0 0 0 1 0 : Information in SO header
0 0 0 0 1 1 : Type of Protection mechanism are
0 0 0 1 0 0 up to 1 1 1 1 1 1 : R.F.
Robert Informational [Page 20]
RFC 2351 MATIP May 1998
10.1.2.2 Accept the
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
The SC (Session Close) command is used to close an existing
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
Indicates the reason for the session closure
0 0 0 0 0 0 0 0 : Normal
1 0 0 0 0 1 0 0 up to 1 1 1 1 1 1 1 1 : Application
Other values
10.2 Data packet
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This field indicates the number of bytes of the whole packet,
included
Robert Informational [Page 21]
RFC 2351 MATIP May 1998
Type B message formatted according to the IATA standard
conforming to the rules of the accessed TYPE B
11. Security
The security is a very sensitive point for airline industry.
for the MATIP users can take place at different levels
The ASCU must be defined to enable the session with the
application. The control can be achieved in two ways: either the
address (H1 H2 A1 A2) is defined at the application level by
means of a static configuration, or the ASCU is identified by a
ID / password. In most cases, the User ID and Password are
by a dedicated software running in the central host. But they
also be checked by the application itself
The MATIP sessions being transported over TCP/IP, It can go through
firewall. Depending on the firewall level, the control can
performed at network (IP addresses) or TCP application layer
For higher level of security all compliant implementations
implement IPSEC ESP for securing control packets. Replay protection
the compulsory cipher suite for IPSEC ESP, and NULL encryption MAY
implemented. Optionally, IPSEC AH MAY also be supported.
compliant implementations MAY also implement IPSEC ESP for
of data packets. Replay prevention and integrity protection
IPSEC ESP mandated cipher suit MAY be implemented. NULL
also MAY be supported. Other IPSEC ESP required ciphers MAY also
supported
12. Author's
Alain
S.I.T.A
18, rue Paul
92904 PARIS LA DEFENSE 10
Phone: 33 1 46411491
Fax: 33 1 46411277
EMail: arobert@par1.par.sita.
Robert Informational [Page 22]
RFC 2351 MATIP May 1998
13. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Robert Informational [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
