idnits 2.17.1 draft-rfced-info-matip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1002: '...rity all compliant implementations MAY...' RFC 2119 keyword, line 1005: '... encryption MAY be implemented. Optio...' RFC 2119 keyword, line 1006: '... implementations MAY also implement IP...' RFC 2119 keyword, line 1008: '...ndated cipher suit MAY be implemented....' RFC 2119 keyword, line 1009: '... encryption also MAY be supported. Oth...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 205 has weird spacing: '...traffic to di...' == Line 1003 has weird spacing: '...SP for secur...' == Line 1005 has weird spacing: '...Y also be...' == Line 1007 has weird spacing: '... Replay preve...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9539 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES SEPT 1998 INTERNET DRAFT 2 N.S.C Working Group A.Robert 3 INTERNET DRAFT SITA 4 Category: Informational March 1998 6 MAPPING OF AIRLINE TRAFFIC OVER IP 7 9 Status of This Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To learn the current status of any Internet-Draft, please check 23 the "1id-abstracts.txt" listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), 25 ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), 26 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 Abstract 32 This memo specifies a protocol for the encapsulation of the airline 33 specific protocol over IP. 35 Contents 37 . INTRODUCTION 3 39 2. TERMINOLOGY & ACRONYMS 5 41 3. LAYERING 7 43 4. TRAFFIC IDENTIFICATION 8 45 5. TCP PORT ALLOCATION 8 47 6. MATIP SESSION ESTABLISHMENT 8 48 7. OVERALL PACKET FORMAT FOR TYPE A & TYPE B 10 50 8. MATIP FORMAT FOR TYPE A CONVERSATIONAL TRAFFIC 11 52 8. 1 Control Packet Format 11 53 8.1.1 Session Open format (SO) 11 54 8.1.2 Open Confirm format (OC) 13 55 8.1.3 Session Close (SC) 14 57 8.2 Data Packet Format 15 59 9. MATIP FORMAT FOR TYPE A HOST-TO-HOST TRAFFIC 16 61 9. 1 Control Packet Format 16 62 9.1.1 Session Open format (SO) 16 63 9.1.2 Open Confirm format (OC) 18 64 9.1.3 Session Close (SC) 19 66 9.2 Data Packet Format 19 68 10. MATIP FORMAT FOR TYPE B TRAFFIC 20 70 10.1 Control packet format 20 71 10.1.1 Session Open format (SO) 20 72 10.1.2 Open confirm format (OC) 21 73 10.1.3 Session Close (SC) 22 75 10.2 Data packet format 23 77 11. SECURITY 23 79 12. AUTHOR ADDRESS 24 80 . Introduction 82 The airline community has been using a worldwide data network for over 83 40 years, with two main types of traffic: 85 Transactional traffic 87 This is used typically for communication between an airline office or 88 travel agency and a central computer system for seat reservations and 89 ticket issuing. A dumb terminal or a PC accesses the central system 90 (IBM or UNISYS) through a data network. 92 This traffic is also called TYPE A and is based on real-time 93 query/response with limited protection, high priority and can be 94 discarded. The user can access only one predetermined central computer 95 system. In case of no response (data loss), the user can duplicate the 96 request. 98 Messaging 100 This is an e-mail application where real-time is not needed. However a 101 high level of protection is required. The addressing scheme uses an 102 international format defined by IATA and contains the city and airline 103 codes. 105 This traffic is also called TYPE B and is transmitted with a high 106 level of protection, multi-addressing and 4 levels of priority. 108 The detailed formats for TYPE A and TYPE B messages are defined in the 109 IATA standards. 111 At the bottom level, synchronous protocols have been built since 112 1960's and well before the OSI and SNA standards. 114 At present, there is a big number of legacy equipment installed in 115 thousands of airline offices around the world. Many airlines do not 116 have immediate plans to replace their terminals with more modern 117 equipment using open standards. They are in search of more economical 118 ways for connecting these terminals to the present reservation system. 120 Most airlines are willing to migrate from airline specific protocols 121 to standardized protocols in order to benefit from the lower cost of 122 new technologies, but the migration has been slow done to the 123 following factors: 125 - Applications have not been migrated. 126 - Dumb terminals using airline protocols P1024B (IBM ALC) or P1024C 127 (UNISYS UTS) are still numerous. 129 There are currently many different proprietary solutions based on 130 gateways available to take advantage of low cast networking, but they 131 are not scalable and cannot interact. 133 In the future, TCP/IP will be more commonly used as a common transport 134 means for traffic types because: 135 - TCP/IP is the standard protocol of UNIX based applications 136 - TCP/IP stacks are inexpensive 137 - TCP/IP is used on intranets. 139 The purpose of this memo is to define the mapping of the airline 140 traffic types over TCP/IP. The airlines implementing it in their 141 systems should have a TCP/IP stack to enable the traffic exchange 142 below : 144 !----! ( ) 145 ! !----------( ) 146 !----! ( ) 147 Type B HOST ( NETWORK ) 148 ( ) 149 ( ) !---o 150 !----! ( )--------! D !---o Type A stations 151 !----!----------( ) !---o 152 !----! ( ) 153 TYPE A HOST ! 154 ! 155 ! 156 ! 157 -------- 158 ! ! 159 -------- 160 Network Messaging System 162 (D) : Gateway TYPE A router 164 The different airline traffic flows concerned by this memo are : 165 - TYPE A Host / Terminal 166 - TYPE A Host / TYPE A host 167 - TYPE B Host / Network messaging System 169 In the case of dumb terminals, a conversion is required on the 170 terminal side in order to have an IP connection between the host and 171 the router. However, the IP connection is directly between the central 172 airline host and the intelligent workstation if the latter has a 173 direct connection to the network, a TCP/IP stack and a terminal 174 emulation 176 2. Terminology & acronyms 178 ALC : 179 Airline Line Control: IBM airline specific protocol (see P1024B) 181 ASCII 182 American Standard Code for Information Interchange 184 ASCU 185 Agent Set Control Unit: Cluster at the user side. 187 AX.25 188 Airline X.25 : Airline application of the X.25 OSI model (published by 189 IATA) 191 BAUDOT 192 Alphabet defined in ITU-T Number 5. BAUDOT uses 5 bits. Padded BAUDOT 193 uses 7 bits with the Most significant bit (bit 7) for the parity and 194 the bit 6 equal to 1. 196 BATAP 197 Type B Application to Application Protocol. Protocol to secure the 198 TYPE B traffic. It was specified by SITA and is now published by IATA 199 (SCR Vol. 3) 201 EBCDIC 202 Extended Binary Coded Decimal Interchange Code 204 Flow ID Traffic 205 Flow identifier used in host to host traffic to differentiate traffic 206 flow types. 208 HLD 209 High Level Designator: Indicates the entry or exit point of a block in 210 the network. 212 IA 213 Interchange Address: ASCU identifier in P1024B protocol. 215 IATA 216 International Air Transport Association 218 IP 219 Internet Protocol 221 IPARS 222 International Program Airline Reservation System: IPARS code is used 223 in ALC 225 HTH 226 Host to Host (traffic). 228 LSB 229 Least Significant Bit 231 MATIP 232 Mapping of Airline Traffic over Internet Protocol 234 MSB 235 Most Significant Bit 237 OC 238 Open Confirm (MATIP command) 240 OSI 241 Open Standard Interface 243 P1024B 244 SITA implementation of the ALC, the IBM airlines specific protocol. It 245 uses 6- bit padded characters (IPARS) and IA/ TA for physical 246 addressing. 248 P1024C 249 SITA implementation of the UTS, the UNISYS terminal protocol. It uses 250 7-bit (ASCII) characters and RID/ SID for physical addressing. 252 RFU 253 Reserved for Future Use 255 RID 256 Remote Identifier: ASCU identifier in P1024C protocol. 258 SC 259 Session Close (MATIP command) 260 SCR : System and Communication Reference. (IATA document) 262 SID 263 Station Identifier: Terminal identifier in P1024C protocol. 265 SITA 266 Societe International de Telecommunications Aeronautiques 268 SO 269 Session Open (MATIP command) 271 TA 272 Terminal Address: Terminal identifier in P1024B protocol. 274 TCP 275 Transport Control Protocol 277 TYPE A Traffic 278 Interactive traffic or host to host 280 TYPE B Traffic 281 Messaging traffic in IATA compliant format with high level of 282 reliability 284 UTS 285 Universal Terminal System by Unisys: (see P1024C) 287 3. LAYERING 289 MATIP is an end to end protocol. Its purpose is to have a mapping 290 standard between the TCP layer and the airline application without any 291 routing element. 293 +-------------------------------+ 294 |Airline TYPE A | Airline TYPE B| 295 | | Application | 296 | |---------------| 297 | Application | BATAP | 298 +-------------------------------+ 299 | MATIP A | MATIP B | 300 +-------------------------------+ 301 | T.C.P | 302 +-------------------------------+ 303 | I.P | 304 +-------------------------------+ 305 | MEDIA | 306 +-------------------------------+ 308 4. TRAFFIC IDENTIFICATION 310 In TYPE A conversational traffic, the airline host application 311 recognizes the ASCU due to 4 bytes (H1, H2, A1, A2). These bytes are 312 assigned by the host and are unique per ASCU. Thus, a host can 313 dynamically recognize the ASCU independent of IP address. 315 H1 H2 A1 A2 bytes follow one of the three cases below: 316 - A1,A2 only are used and H1H2 is set to 0000. 317 - H1,H2 identify the session and A1A2 the ASCU inside the session. 318 - H1,H2,A1,A2 identify the ASCU. 320 The first two cases are fully compatible with the AX.25 mapping where 321 H1H2 may be equivalent to the HLD of the concentrator, i.e., 2 bytes 322 hexadecimal. The third rule allows more flexibility but is not 323 compatible with AX.25. 325 In TYPE A host to host traffic the identification field is also 326 present and is equal to 3 bytes H1 H2 Flow ID (optional). H1H2 are 327 reserved for remote host identification (independently of the IP 328 address) and must be allocated bilaterally. 330 In Type B traffic, identification of End Systems may be carried out by 331 the use of HLDs, or directly by the pair of IP addresses. 333 5. TCP PORT ALLOCATION 335 IANA (Internet Assigned Numbers Authority) has allocated the following 336 ports for MATIP TYPE A and TYPE B traffic: 337 MATIP Type A TCP port = 350 338 MATIP Type B TCP port = 351 340 Therefore the traffic type A or B is selected according to the TCP port. 342 6. MATIP SESSION ESTABLISHMENT 344 Prior to any exchange between two applications, a single MATIP session 345 is established above the TCP connection in order to identify the 346 traffic characteristic such as: 348 - Subtype of traffic for TYPE A (Type A host to host or Type A 349 conversational ) 350 - Multiplexing used (for Type A) 351 - Data header 352 - Character set 354 A separate session and TCP connection must be established for each set 355 of parameters (e.g., P1024B, P1024C traffic between two points needs 356 two separate sessions). 358 The establishment of a MATIP session can be initiated by either side. 359 No keep-alive mechanism is defined at MATIP level. Session time out 360 relies on the TCP time-out parameters. 362 There are three commands defined to manage the MATIP session: 364 - Session Open (SO) to open a session. 365 - Open Confirm (OC) to confirm the SO command. 366 - Session close (SC) to close the current session. 368 A MATIP session can be up only if the associated TCP connection is up. 369 However it is not mandatory to close the TCP connection when closing 370 the associated MATIP session. 372 Typical exchange is: 374 TCP session establishment 376 Session Open ---------> 377 <----------- Open confirm 378 data exchange 379 ----------------------> 380 <------------------------- 381 . 382 . 383 . 384 Session Close -----------------> 385 . 386 . 387 . 388 <------------------------- Session Open 389 Open confirm -------------------> 390 data exchange 391 <------------------------- 392 ----------------------> 394 The Session Open command may contain configuration elements. An Session 395 Open command received on a session already opened (i.e. same IP address 396 and port number) will automatically clear the associated configuration 397 and a new configuration will be set up according to the information 398 contained in the new open session command. 400 As illustrated above, the open and close commands are symmetrical. 402 For type A conversational traffic, the SO and OC commands contain 403 information for the identification of the ASCUs and the session. ASCUs 404 are identified within a session by two or 4 bytes. A flag is set to 405 indicate if the ASCU is identified by 4 bytes (H1H2A1A2) or by 2 bytes 406 (A1A2). In the latter case, H1H2 is reserved for session identification. 408 The SO command is sent to open the MATIP session. In Type A 409 conversational it may contains the list of ASCUs configured in this 410 session. 412 The OC command confirms the SO command. It can refuse or accept it, 413 totally or conditionally. In Type A, it contains the list of the ASCUs 414 either rejected or configured in the session. 416 7. OVERALL PACKET FORMAT FOR TYPE A & TYPE B 418 The first 4 bytes of the MATIP header follow the following rules. 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |0|0|0|0|0| Ver |C| Cmd | length | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Ver 427 The `Ver' (Version) field represents the version of the MATIP. It must 428 contain the value 001 otherwise the packet is considered as invalid. 430 C 431 Identifies a CONTROL packet. 432 When set to 1, the packet is a Control packet 433 When set to 0, the packet is a Data packet 435 Cmd 436 This field identifies the control command if the flag C is set to 1. 438 Length 439 This field indicates the number of bytes of the whole packet, header 440 included. 442 Notes : Fields identified as optional (Opt) are not transmitted if not 443 used. 445 8. MATIP FORMAT FOR TYPE A CONVERSATIONAL TRAFFIC 447 8. 1 Control Packet Format 449 There are 3 control packets to open or close the session at the MATIP 450 level. 452 8.1.1 Session Open format (SO) 454 To be able to identify the session and before sending any data 455 packets, a Session Open command is sent. It can be initiated by either 456 side. In case of collision, the open session from the side having the 457 lower IP address is ignored. 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 |0|0|0|0|0| Ver |1|1 1 1 1 1 1 0| length | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |0 0|0 1|0| CD | STYP |0 0 0 0| RFU |MPX|HDR| PRES. | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | H1 | H2 | RFU | 467 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Reserved | RFU | Nbr of ASCUs | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Nbr of ASCUs | ASCU list (opt) | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 RFU 474 Reserved for future use. Must be set to zero. 476 CD 477 This field specifies the Coding 478 000 : 5 bits (padded baudot) 479 010 : 6 bits (IPARS) 480 100 : 7 bits (ASCII) 481 110 : 8 bits (EBCDIC) 482 xx1 : R.F.U 484 STYP 485 This is the traffic subtype (type being TYPE A). 486 0001 : TYPE A Conversational 488 MPX 489 This flag specifies the multiplexing used within the TCP session. 490 Possible values are: 491 00 : Group of ASCU with 4 bytes identification per ASCU (H1H2A1A2) 492 01 : Group of ASCUs with 2 bytes identification per ASCU (A1A2) 493 10 : single ASCU inside the TCP session. 495 HDR 496 This field specifies which part of the airline's specific address is 497 placed ahead of the message texts transmitted over the session. 498 Possible values are : 500 00 : ASCU header = H1+H2+A1+A2 501 01 : ASCU Header = A1+A2 502 10 : No Header 503 11 : Not used 505 The MPX and HDR must be coherent. When ASCUs are multiplexed, the data 506 must contain the ASCU identification. The table below summarizes the 507 allowed combinations : 509 +--------------------------+ 510 | MPX | 00 | 01 | 10 | 511 +--------------------------+ 512 | HDR | | 513 | 00 | Y | Y | Y | 514 | 01 | N | Y | Y | 515 | 10 | N | N | Y | 516 +--------------------------+ 518 PRES 519 This field indicates the presentation format 520 0001 : P1024B presentation 521 0010 : P1024C presentation 522 0011 : 3270 presentation 524 H1 H2 525 These fields can logically identify the session if MPX is not equal to 526 00. When this field is not used, it must be set to 0. If used in 527 session (MPX <> 0) with HDR=00, H1H2 in data packet must have the same 528 value as set in SO command. 530 Nbr of ASCUs 531 Nbr_of_ASCUs field is mandatory and gives the number of ASCUs per 532 session. A 0 (zero) value means unknown. In this case the ASCU list is 533 not present in the `Open Session' command and must be sent by the 534 other end in the `Open Confirm' command. 536 ASCU LIST 537 Contains the list of identifier for each ASCU. If MPX=00 it has a 538 length of four bytes (H1H2A1A2) for each ASCU, otherwise it is two 539 bytes (A1A2). 541 8.1.2 Open Confirm format (OC) 543 The OC (Open Confirm) command is a response to an SO (Session Open) 544 command and is used to either refuse the session or accept it 545 conditionally upon checking hte configuration of each ASCU. 547 In case of acceptance, the OC indicates the number and the address of 548 the rejected ASCUs, if any. Alternatively, it indicates the list of 549 ASCUs configured for that MATIP session if the list provided by the SO 550 command was correct or the number of ASCUs configured in the session 551 was unknown (n. of ASCU equals 0). 553 8.1.2.1 Refuse the connection 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 |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| 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | cause | 561 +-+-+-+-+-+-+-+-+ 563 Cause 564 This field indicates the reason for the MATIP session refusal : 566 0 0 0 0 0 0 0 1 : No Traffic Type matching between Sender & 567 Recipient 568 0 0 0 0 0 0 1 0 : Information in SO header incoherent 570 1 0 0 0 0 1 0 0 571 up to : Application dependent 572 1 1 1 1 1 1 1 1 574 Other values reserved. 576 As specified in chapter 6, an already opened session is closed in this 577 case. 579 8.1.2.2 Accept the connection 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 |0|0|0|0|0| Ver |1|1 1 1 1 1 0 1| length | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 |0 0 R 0 0 0 0 0| Nbr of ASCUs |Nbr of ASCU(opt| ASCU LIST | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 R 594 Flag indicating an error in the ASCU configuration provided in the SO 595 command. 597 NBR of ASCUs 598 If the MPX value is equal to 00 in the SO command, this field is two 599 bytes long. Otherwise, it is one byte. 600 If the R flag is set, the Nbr_of_ASCUs field represents the number of 601 ASCUs in error. Otherwise, it indicates the number of ASCUs configured 602 for that MATIP session. 604 Notes : The length of this field is either one or two bytes. In the SO 605 command, the length is always two bytes. This discrepancy comes from 606 backward compatibility with AX25 (see chapter 4). In the SO command, 607 it is possible to use a free byte defined in the AX25 call user data. 608 Unfortunately, there is no such free byte in the AX25 clear user data. 610 ASCU LIST 611 Depending on the R flag, this field indicates the list of ASCUs (A1A2 612 or H1H2A1A2) either in error or within the session. 614 8.1.3 Session Close (SC) 616 The SC (Session Close) command is used to close an existing MATIP 617 session. 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 |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| 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Close Cause | 625 +-+-+-+-+-+-+-+-+ 627 Close Cause 628 Indicates the reason for the session closure: 630 0 0 0 0 0 0 0 0 : Normal Close 632 1 0 0 0 0 1 0 0 633 up to : Application dependent 634 1 1 1 1 1 1 1 1 636 Other values reserved. 638 8.2 Data Packet Format 640 0 1 2 3 641 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 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 |0|0|0|0|0| Ver |0|0 0 0 0 0 0 0| length | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | ID (optional) | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | | 648 | Payload | 649 | | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 ID 653 This field is optional and has a different length and format according 654 to the value of HDR, PRES indicated during the session establishment. 656 +------------------------------+-------------------------------+ 657 |HDR | PRES = P1024B and 3270 | PRES = P1024C | 658 +------------------------------+-------------------------------+ 659 |00 |ID = 4 bytes H1-H2-A1-A2 | ID = 5 bytes H1-H2-A1-0x01-A2 | 660 +------------------------------+-------------------------------+ 661 |01 |ID = 2 bytes A1-A2 | ID = 3 bytes A1-0x01-A2 | 662 +------------------------------+-------------------------------+ 663 |10 |ID = 0 bytes | ID = 0 bytes | 664 +------------------------------+-------------------------------+ 666 H1, H2 value must match the value given in the SO command if MPX is 667 different from 0. 669 Payload 670 payload begins with the terminal identification : 671 - One byte Terminal identifier (TA) in P1024B 672 - Two bytes SID/DID Terminal identifier in P1024C. 674 9. MATIP FORMAT FOR TYPE A HOST-TO-HOST TRAFFIC 676 9. 1 Control Packet Format 678 There are 3 control packets to open or close the session at the MATIP 679 level. 681 9.1.1 Session Open format (SO) 683 To be able to identify the session and before sending any data packet, 684 a Session Open command is sent. It can be initiated by either side. In 685 case of collision, the open session from the side having the lower IP 686 address is ignored. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 |0|0|0|0|0| Ver |1|1 1 1 1 1 1 0| length | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 |0 0|0 1|0| CD | STYP |0 0 0 0| RFU |MPX|HDR|0 0 0 0| 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | H1 | H2 | RFU | 696 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Flow ID(opt)| 698 +-+-+-+-+-+-+-+-+ 700 RFU 701 Reserved for future use. Must be set to zero. 703 CD 704 This field specifies the Coding, as defined in section 8.1.1.1. 706 STYP 707 This is the traffic subtype (type being Type A). 708 0010 : TYPE A IATA Host to Host 709 1000 : SITA Host to Host 711 MPX 712 This flag specifies the multiplexing used within the MATIP session in 713 TYPE A SITA host to host. Possible values are: 715 00 : irrelevant 716 01 : multiple flow inside the TCP connection 717 10 : single flow inside the TCP connection 719 HDR 720 This field specifies which part of the airline's specific address is 721 placed ahead of the message text transmitted over the session. 722 Possible values are : 724 00 : used in TYPE A SITA Host to Host Header = H1+H2+Flow ID 725 01 : used in TYPE A SITA Host to Host Header = Flow ID 726 10 : No Header (default for IATA host to Host) 727 11 : Not used 729 The MPX and HDR must be coherent. When flow are multiplexed, the data 730 must contain the flow identification. The table below summarizes the 731 possible combinations: 733 +---------------------+ 734 | MPX | 01 | 10 | 735 +---------------------+ 736 | HDR | | | 737 | 00 | Y | Y | 738 | 01 | Y | Y | 739 | 10 | N | Y | 740 +---------------------+ 742 H1 H2 743 These fields can be used to identify the session. When this field is 744 not used, it must be set to 0. If HDR=00, H1H2 in data packet must 745 have the same value as set in SO command. 747 Flow ID 748 This field is optional and indicates the Flow ID (range 3F - 4F Hex). 750 9.1.2 Open Confirm format (OC) 752 The OC (Open Confirm) command is a response to an SO (Session Open) 753 command and is used to either refuse the session or accept it. 755 9.1.2.1 Refuse the connection 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 |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| 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | cause | 763 +-+-+-+-+-+-+-+-+ 765 Cause 766 This field indicates the reason for the MATIP session refusal 768 0 0 0 0 0 0 0 1 : No Traffic Type matching between Sender & 769 Recipient 770 0 0 0 0 0 0 1 0 : Information in SO header incoherent 772 1 0 0 0 0 1 0 0 773 up to : Application dependent 774 1 1 1 1 1 1 1 1 776 Other values reserved. 778 9.1.2.2 Accept the connection 780 0 1 2 3 781 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 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 |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| 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 |0 0 0 0 0 0 0 0| 786 +-+-+-+-+-+-+-+-+ 788 9.1.3 Session Close (SC) 790 The SC (Session Close) command is used to close an existing MATIP 791 session. 793 0 1 2 3 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 |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| 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Close Cause | 799 +-+-+-+-+-+-+-+-+ 801 Close Cause 802 Indicates the reason for the session closure: 804 0 0 0 0 0 0 0 0 : Normal Close 806 1 0 0 0 0 1 0 0 807 up to : Application dependent 808 1 1 1 1 1 1 1 1 810 Other values reserved 812 9.2 Data Packet Format 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 |0|0|0|0|0| Ver |0|0 0 0 0 0 0 0| length | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | ID (optional) | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | | 822 | Payload | 823 | | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 ID 827 This field is optional and has a different length and format according 828 to the value of HDR indicated during the session establishment. 830 +-------------------------------+ 831 |HDR | I.D. | 832 +-------------------------------+ 833 |00 |ID = 3 bytes H1-H2 FLOW ID| 834 +-------------------------------+ 835 |01 |ID = FLOW ID | 836 +-------------------------------+ 837 |10 |ID nor present | 838 +-------------------------------+ 840 Payload packet 841 The payload format is relevant to the MATIP layer. It is formatted 842 according to the IATA host to host specifications and agreed 843 bilaterally by the sender and the receiver. 845 10. MATIP FORMAT FOR TYPE B TRAFFIC 847 10.1 Control packet format 849 There are 3 control packets used to open or close the session at the 850 MATIP level for exchanging Type B data 852 10.1.1 Session Open format (SO) 854 Before sending any data packets, it is recommended to let the systems 855 establishing a session check that they are indeed able to communicate 856 (i.e.: Both systems agree on the characteristics of the traffic that 857 will cross the connection). For this purpose, a two way handshake, 858 using the Session commands defined hereafter, is performed immediately 859 after the establishment of the TCP level connection. Either side can 860 initiate this procedure. In case of collision, the open session from 861 the side having the lower IP address is ignored. 863 0 1 2 3 864 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 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 |0|0|0|0|0| Ver |1|1 1 1 1 1 1 0| length | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 |0 0 0 0 0| C D | PROTEC| BFLAG | Sender HLD | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Recipient HLD | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 Length 874 This field indicates the number of bytes of the whole command, header 875 included. The only possible values are equal to 6 bytes or 10 bytes. 877 CD 878 This field specifies the Coding, as defined in section 8.1.1.1. 880 PROTEC 881 Identifies the end to end Messaging Responsibility Transfer protocol 882 used. 883 0010: BATAP 884 All other values available. 886 BFLAG (X means `do not care' 888 X X 0 0 means that the fields `Sender HLD, Recipient HLD' do not exist 889 in this packet. In this case, the exact length of the packet is 6 890 Bytes. 892 X X 1 0 means that the `Sender HLD, Recipient HLD' are carried 893 respectively in bytes 9,10 and 11,12 of this packet. In this 894 case, the exact length of the packet is 10 Bytes. 896 0 0 X X means that the connection request has been transmitted from a 897 host (Mainframe system) 899 0 1 X X means that the connection request has been transmitted from a 900 gateway) 902 Sender HLD 903 HLD of the Type B System sending the Session Open. 905 Recipient HLD 906 HLD of the Type B system to which session opening is destined. 908 10.1.2 Open confirm format (OC) 910 The OC (Open Confirm) command is a response to an SO (Session Open) 911 command and is used to either refuse the session or accept it. 913 10.1.2.1 Refuse the connection 915 0 1 2 3 916 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 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 |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| 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 |0|1| Cause | 921 +-+-+-+-+-+-+-+-+ 923 Length of this packet is 5 Bytes. 925 Cause 926 Indicates the cause of the rejection 928 0 0 0 0 0 1 : No Traffic Type matching between Sender & Recipient 929 0 0 0 0 1 0 : Information in SO header incoherent 930 0 0 0 0 1 1 : Type of Protection mechanism are different 931 0 0 0 1 0 0 up to 1 1 1 1 1 1 : R.F.U 933 10.1.2.2 Accept the connection 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 |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| 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 |0 0 0 0 0 0 0 0| 941 +-+-+-+-+-+-+-+-+ 943 Length of this packet is 5 Bytes. 945 10.1.3 Session Close (SC) 947 The SC (Session Close) command is used to close an existing MATIP 948 session. 950 0 1 2 3 951 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 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 |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| 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Close Cause | 956 +-+-+-+-+-+-+-+-+ 958 Close Cause 959 Indicates the reason for the session closure: 960 0 0 0 0 0 0 0 0 : Normal Close 961 1 0 0 0 0 1 0 0 up to 1 1 1 1 1 1 1 1 : Application dependent 963 Other values reserved 965 10.2 Data packet format 967 0 1 2 3 968 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 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 |0|0|0|0|0| Ver |0|0 0 0 0 0 0 0| length | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | | 973 | Payload | 974 | | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 Length 978 This field indicates the number of bytes of the whole packet, header 979 included. 981 Payload 982 Type B message formatted according to the IATA standard and conforming 983 to the rules of the accessed TYPE B service 985 11. Security 987 The security is a very sensitive point for airline industry. Security 988 for the MATIP users can take place at different levels : 990 The ASCU must be defined to enable the session with the host 991 application. The control can be achieved in two ways: either the ASCU 992 address (H1 H2 A1 A2) is defined at the application level by the means 993 of a static configuration, or the ASCU is identified by a User ID / 994 password. In most cases, the User ID and Password are verified by a 995 dedicated software running in the central host. But they can also be 996 checked by the application itself. 998 The MATIP sessions being transported over TCP/IP, It can go through a 999 firewall. Depending on the firewall level, the control can be 1000 performed at network (IP addresses) or TCP application layer. 1002 For higher level of security all compliant implementations MAY 1003 implement IPSEC ESP for securing control packets. Replay 1004 protection, the compulsory cipher suite for IPSEC ESP, and NULL 1005 encryption MAY be implemented. Optionally, IPSEC AH MAY also be 1006 supported. All compliant implementations MAY also implement IPSEC ESP 1007 for protection of data packets. Replay prevention and integrity 1008 protection using IPSEC ESP mandated cipher suit MAY be implemented. 1009 NULL encryption also MAY be supported. Other IPSEC ESP required 1010 ciphers MAY also be supported. 1012 12. Author address 1013 Alain Robert 1014 S.I.T.A. 1015 18, rue Paul Lafargue 1016 92904 PARIS LA DEFENSE 10 1017 FRANCE 1019 Phone : 33 1 46411491 1020 Fax : 33 1 46411277 1021 Email : arobert par1.par.sita.int 1022 @ 1024 INTERNET DRAFT EXPIRES SEPT 1998 INTERNET DRAFT