doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc2351.txt b/doc/rfc/rfc2351.txt
new file mode 100644
index 0000000..6335be5
--- /dev/null
+++ b/doc/rfc/rfc2351.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                          A. Robert
+Request for Comments: 2351                                          SITA
+Category: Informational                                         May 1998
+
+
+              Mapping of Airline Reservation, Ticketing,
+                     and Messaging Traffic over IP
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Security Disclaimer:
+
+   This document fails to adequately address security concerns.  The
+   protocol itself does not include any security mechanisms.  The
+   document notes that traffic can be authenticated based on external
+   mechanisms that use static identifiers or what are apparently clear-
+   text passwords, neither of which provide sound security.  The
+   document notes in general terms that traffic can be secured using
+   IPSEC, but leaves this form of sound security strictly optional.
+
+Abstract
+
+   This memo specifies a protocol for the encapsulation of the airline
+   specific protocol over IP.
+
+Table of Conents
+
+   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. Introduction
+
+   The airline community has been using a worldwide data network for
+   over 40 years, with two main types of traffic:
+
+    Transactional traffic
+
+      This is used typically 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 accesses
+      the central system (IBM or UNISYS) through a data network.
+
+      This traffic is also called TYPE A and is based on real-time
+      query/response with limited protection, high priority and can be
+      discarded. The user can access only one predetermined central
+      computer system. In case of 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 and is transmitted 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.
+
+
+
+
+
+Robert                       Informational                      [Page 2]
+
+RFC 2351                         MATIP                          May 1998
+
+
+   At the bottom level, synchronous protocols have been built since
+   1960's and well before the OSI and SNA standards.
+
+   At present, there is a big number of legacy equipment installed in
+   thousands of airline offices around the world. Many airlines do not
+   have immediate plans to replace their terminals with more modern
+   equipment using open standards. They are in search of more economical
+   ways for connecting these terminals to the present reservation
+   system.
+
+   Most airlines are willing to migrate from airline specific protocols
+   to standardized protocols in order to benefit from the lower cost of
+   new technologies, but the migration has been slow done to 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 available to take advantage of low cast networking, but they
+   are not scalable and cannot interact.
+
+   In the future, TCP/IP will be more commonly used as a common
+   transport means 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. The airlines implementing it in their
+   systems should have a TCP/IP stack to enable the traffic exchange
+   below:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Robert                       Informational                      [Page 3]
+
+RFC 2351                         MATIP                          May 1998
+
+
+     !----!          (            )
+     !    !----------(            )
+     !----!          (            )
+     Type B HOST     (   NETWORK  )
+                     (            )
+                     (            )            !---o
+     !----!          (            )--------! D !---o Type A stations
+     !----!----------(            )            !---o
+     !----!          (            )
+     TYPE A HOST           !
+                           !
+                           !
+                           !
+                        --------
+                       !       !
+                        --------
+                      Network Messaging System
+
+
+      (D) : Gateway TYPE A router
+
+   The different airline traffic flows concerned by this RFC are:
+
+     - TYPE A Host / Terminal
+     - TYPE A Host / TYPE A host
+     - TYPE B Host / Network messaging System
+
+   In the case of dumb terminals, a conversion is required on the
+   terminal side in order to have 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 latter
+   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)
+
+
+
+Robert                       Informational                      [Page 4]
+
+RFC 2351                         MATIP                          May 1998
+
+
+   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)
+
+
+
+Robert                       Informational                      [Page 5]
+
+RFC 2351                         MATIP                          May 1998
+
+
+   OSI
+   Open Standard Interface
+
+   P1024B
+   SITA implementation of the ALC, the IBM airlines 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)
+
+
+
+Robert                       Informational                      [Page 6]
+
+RFC 2351                         MATIP                          May 1998
+
+
+3. LAYERING
+
+   MATIP is an end to end protocol. Its purpose is to have a mapping
+   standard between the TCP layer and the airline application without
+   any routing element.
+
+     +-------------------------------+
+     |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 due to 4 bytes (H1, H2, A1, A2). These bytes are
+   assigned by the host and are unique per ASCU. Thus, a host can
+   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 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 is equal to 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, identification of End Systems may be carried out
+   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 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 = 351
+
+   Therefore the traffic type A or B is selected according to the TCP
+   port.
+
+6. MATIP SESSION ESTABLISHMENT
+
+   Prior to any exchange between two applications, a single MATIP
+   session is established above the TCP connection in order to identify
+   the traffic characteristic such as:
+
+     - Subtype of traffic for TYPE A (Type A host to host or Type A
+       conversational )
+     - Multiplexing used (for Type A)
+     - Data header
+     - Character set
+
+   A separate session and TCP connection must be established for each
+   set of parameters (e.g., P1024B, P1024C traffic between two points
+   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 out
+   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 is
+   up.  However it is not mandatory to close the TCP connection when
+   closing the associated MATIP session.
+
+   Typical exchange is:
+
+                      TCP session establishment
+
+             Session Open --------->
+                            <-----------   Open confirm
+                          data exchange
+             ---------------------->
+
+
+
+Robert                       Informational                      [Page 8]
+
+RFC 2351                         MATIP                          May 1998
+
+
+                             <-------------------------
+                             .
+                             .
+                             .
+    Session Close ----------------->
+                             .
+                             .
+                             .
+                              <-------------------------   Session Open
+   Open confirm ------------------->
+                        data exchange
+                               <-------------------------
+             ---------------------->
+
+   The Session Open command may contain configuration elements. An
+   Session Open command received on a session already opened (i.e., same
+   IP address and port number) will automatically clear the associated
+   configuration and a new configuration will be set up according to the
+   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 contain
+   information for the identification of the ASCUs and the session.
+   ASCUs are identified within a session by two or 4 bytes. A flag is
+   set to indicate if the ASCU is identified by 4 bytes (H1H2A1A2) or by
+   2 bytes (A1A2). In the latter case, H1H2 is reserved for session
+   identification.
+
+   The SO command is sent to open the MATIP session. In Type A
+   conversational it may contains the list of ASCUs configured in this
+   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 the
+   ASCUs 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 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
+
+
+   Ver
+   The `Ver' (Version) field represents the version of the MATIP. It
+   must contain the value 001 otherwise the packet is considered as
+   invalid.
+
+   C
+   Identifies 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 if the flag C is set to 1.
+
+   Length
+   This field indicates the number of bytes of the whole packet, header
+   included.
+
+   Notes : Fields identified as optional (Opt) are not transmitted if
+   not used.
+
+8. MATIP FORMAT FOR TYPE A CONVERSATIONAL TRAFFIC
+
+8. 1 Control Packet Format
+
+   There are 3 control packets to open or close the session at the MATIP
+   level.
+
+8.1.1 Session Open format (SO)
+
+   To be able to identify the session and before sending any data
+   packets, a Session Open command is sent. It can be initiated by
+   either side. In case of collision, the 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 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
+
+
+   RFU
+   Reserved for future use. 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.U
+
+   STYP
+   This is the traffic subtype (type being TYPE A).
+      0001 : TYPE A Conversational
+
+   MPX
+   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.
+
+
+   HDR
+   This field specifies which part of the airline's specific address is
+   placed ahead of the message texts transmitted over the session.
+   Possible values are:
+      00 : ASCU header = H1+H2+A1+A2
+      01 : ASCU Header = A1+A2
+      10 : No Header
+      11 : Not used
+
+   The MPX and HDR must be coherent. When ASCUs are multiplexed, the data
+   must contain the ASCU identification. The table below summarizes the
+   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
+
+
+   PRES
+   This field indicates the presentation format
+      0001 : P1024B presentation
+      0010 : P1024C presentation
+      0011 : 3270 presentation
+
+
+   H1 H2
+   These fields can logically identify the session if MPX is not equal to
+   00. When this field is not used, it must be set to 0. If used in
+   session (MPX <> 0) with HDR=00, H1H2 in data packet must have the same
+   value as set in SO command.
+
+   Nbr of ASCUs
+   Nbr_of_ASCUs field is mandatory and gives the number of ASCUs per
+   session. A 0 (zero) value means unknown. In this case the ASCU list is
+   not present in the `Open Session' command and must be sent by the
+   other end in the `Open Confirm' command.
+
+   ASCU LIST
+   Contains the list of identifier for each ASCU. If MPX=00 it has a
+   length of four bytes (H1H2A1A2) for each ASCU, otherwise it is two
+   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 it
+   conditionally upon checking hte configuration of each ASCU.
+
+   In case of acceptance, the OC indicates the number and the address of
+   the rejected ASCUs, if any. Alternatively, it indicates the list of
+   ASCUs configured for that MATIP session if the list provided by the
+   SO command was correct or the number of ASCUs configured in the
+   session was unknown (n. of ASCU 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 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 &
+           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
+   Flag indicating an error in the ASCU configuration provided in the SO
+   command.
+
+   NBR of ASCUs
+   If the MPX value is equal to 00 in the SO command, this field is two
+   bytes long. Otherwise, it is one byte.
+   If the R flag is set, the Nbr_of_ASCUs field represents the number of
+   ASCUs in error. Otherwise, it indicates the number of ASCUs configured
+   for that MATIP session.
+
+   Notes: The length of this field is either one or two bytes. In the SO
+   command, the length is always two bytes. This discrepancy comes from
+   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 user
+   data.
+
+   ASCU LIST
+   Depending on the R flag, this field indicates the list of ASCUs  (A1A2
+   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 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
+   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 reserved.
+
+8.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 has a different length and format
+   according to the value of HDR, PRES indicated during the session
+   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 is
+   different from 0.
+
+   Payload
+   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
+
+   There are 3 control packets to open or close the session at the MATIP
+   level.
+
+9.1.1 Session Open format (SO)
+
+   To be able to identify the session and before sending any data
+   packet, a Session Open command is sent. It can be initiated by either
+   side. In case of collision, the 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 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.
+
+
+
+
+
+Robert                       Informational                     [Page 15]
+
+RFC 2351                         MATIP                          May 1998
+
+
+   CD
+   This field specifies the Coding, as defined in section 8.1.1.1.
+
+   STYP
+   This is the traffic subtype (type being Type A).
+   0010 : TYPE A IATA Host to Host
+   1000 : SITA Host to Host
+
+   MPX
+   This flag specifies the multiplexing used within the MATIP session in
+   TYPE A SITA host to host. Possible values are:
+
+   00 : irrelevant
+   01 : multiple flow inside the TCP connection
+   10 : single flow inside the TCP connection
+
+   HDR
+   This field specifies which part of the airline's specific address is
+   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 ID
+   01 : used in TYPE A SITA Host to Host Header = Flow ID
+   10 : No Header (default for IATA host to Host)
+   11 : Not used
+
+   The MPX and HDR must be coherent. When flow are multiplexed, the data
+   must contain the flow identification. The table below summarizes the
+   possible combinations:
+
+         +---------------------+
+         |       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, H1H2 in data packet must
+   have the same value as set in SO command.
+
+   Flow ID
+   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 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.
+
+
+
+
+
+
+
+
+
+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 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 reserved
+
+9.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 has a different length and format
+   according to 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            |
+     +-------------------------------+
+
+
+
+Robert                       Informational                     [Page 18]
+
+RFC 2351                         MATIP                          May 1998
+
+
+   Payload packet
+   The payload format is relevant to the MATIP layer. It is formatted
+   according to the IATA host to host specifications and agreed
+   bilaterally by the sender and the receiver.
+
+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). For this purpose, a two way handshake,
+   using the Session commands defined hereafter, is performed
+   immediately after the establishment of the TCP level connection.
+   Either side can initiate this procedure. In case of collision, the
+   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           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Length
+   This field indicates the number of bytes of the whole command, header
+   included. The only possible values are equal to 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: BATAP
+   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 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 and is used to either refuse the session or accept it.
+
+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.U
+
+
+
+
+
+
+Robert                       Informational                     [Page 20]
+
+RFC 2351                         MATIP                          May 1998
+
+
+10.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|
+     +-+-+-+-+-+-+-+-+
+
+   Length of this packet is 5 Bytes.
+
+10.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
+   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 reserved
+
+10.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             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     |                         Payload                               |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Length
+   This field indicates the number of bytes of the whole packet, header
+   included.
+
+
+
+
+Robert                       Informational                     [Page 21]
+
+RFC 2351                         MATIP                          May 1998
+
+
+   Payload
+   Type B message formatted according to the IATA standard and
+   conforming to the rules of the accessed TYPE B service
+
+11. Security Considerations
+
+   The security is a very sensitive point for airline industry. Security
+   for the MATIP users can take place at different levels:
+
+   The ASCU must be defined to enable the session with the host
+   application. The control can be achieved in two ways: either the ASCU
+   address (H1 H2 A1 A2) is defined at the application level by the
+   means of a static configuration, or the ASCU is identified by a User
+   ID / password. In most cases, the User ID and Password are verified
+   by a dedicated software running in the central host. But they can
+   also be checked by the application itself.
+
+   The MATIP sessions being transported over TCP/IP, It can go through a
+   firewall. Depending on the firewall level, the control can be
+   performed at network (IP addresses) or TCP application layer.
+
+   For higher level of security all compliant implementations MAY
+   implement IPSEC ESP for securing control packets.  Replay protection,
+   the compulsory cipher suite for IPSEC ESP, and NULL encryption MAY be
+   implemented. Optionally, IPSEC AH MAY also be supported.  All
+   compliant implementations MAY also implement IPSEC ESP for protection
+   of data packets. Replay prevention and integrity protection using
+   IPSEC ESP mandated cipher suit MAY be implemented.  NULL encryption
+   also MAY be supported. 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
+
+
+
+
+
+
+
+
+
+Robert                       Informational                     [Page 22]
+
+RFC 2351                         MATIP                          May 1998
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   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, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Robert                       Informational                     [Page 23]
+