idnits 2.17.1 draft-ietf-tn3270e-tcp62-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-25) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 45 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 46 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. == There is 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** 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 1553: '... Bits 4 and 6 MUST be set to 1,...' RFC 2119 keyword, line 1877: '... Bits 4 and 6 MUST be set to 0 and ...' RFC 2119 keyword, line 1973: '... MUST be set to X'7F' ...' RFC 2119 keyword, line 1974: '... Alias Address Mode MUST be set to the...' RFC 2119 keyword, line 2010: '...with this command. This field MUST be...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 834 has weird spacing: '...nection betwe...' == Line 1514 has weird spacing: '... of the node ...' == Line 1981 has weird spacing: '...l Field prefi...' -- 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 (December 1997) is 9628 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 2086, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 2089, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 2092, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TN3270E Working Group James Carmichael 2 Internet Draft Soumitra (Ronnie) Sarkar 3 Expiration Date: June, 1998 IBM Corporation 4 December 1997 6 LU6.2 over TCP/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 areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This draft describes IBM's support for running LU6.2 applications 30 over a TCP/IP network. This support is provided using a subset of the 31 X/Open architecture for Multiprotocol Transport Networking, which is 32 a general protocol conversion architecture for running any 33 application over any transport protocol. This draft is being 34 distributed to members of the Internet community in order to solicit 35 their reactions to the proposals contained in it. While the issues 36 discussed may not be directly relevant to the research problems of 37 the Internet, they may be interesting to a number of researchers and 38 implementers. 40 Any questions or comments relative to the contents of this draft 41 should be sent to the following Internet address: 42 carmich@us.ibm.com. 44 Contents 46 Status of this Memo................................................ 1 48 Abstract........................................................... 1 50 1. INTRODUCTION................................................... 3 52 2. A HIGH LEVEL OVERVIEW OF TCP62 FUNCTION........................ 4 53 2.1. Protocol Compensations Required for TCP62................. 5 54 2.1.1. LU6.2 Headers that Flow Over TCP/IP.................. 8 55 2.1.2. A Sample Flow........................................ 8 56 2.2. LU6.2 and Related Protocols to Disable When Running TCP62. 10 57 2.3. TCP62 Address Mapping..................................... 11 59 3. Protocol Compensations......................................... 12 60 3.1. Connection Establishment.................................. 13 61 3.2. Data Transfer............................................. 14 62 3.2.1. Nonexpedited Data.................................... 14 63 3.2.2. Expedited Data....................................... 14 64 3.2.2.1. Sending Expedited Data.......................... 14 65 3.2.2.2. Receiving Expedited Data........................ 18 66 3.3. MPTN Keepalive Protocol................................... 18 67 3.3.1. The Problem of Out-of-Sync Connections............... 18 68 3.3.2. A Keepalive Protocol Using Datagrams................. 19 69 3.4. Connection Termination.................................... 20 71 4. Other Protocol Issues Not Related to Compensations............. 21 72 4.1. Segmentation and Reassembly of APPC Request/Response Units 21 73 4.2. Pacing.................................................... 22 75 5. TCP62 Formats.................................................. 23 76 5.1. Migration Considerations.................................. 24 77 5.1.1. Processing Rules..................................... 24 78 5.1.2. Processing Actions................................... 25 79 5.1.2.1. Command......................................... 25 80 5.1.2.2. Field........................................... 26 81 5.2. Common Command Formats.................................... 26 82 5.2.1. Common Prefix........................................ 27 83 5.2.2. Optional Fields...................................... 28 84 5.2.3. MPTN Addresses....................................... 29 85 5.2.3.1. MPTN Qualifier.................................. 29 86 5.2.3.2. Address Mode.................................... 30 87 5.2.3.3. Node Address.................................... 30 88 5.2.3.4. Local Address................................... 30 89 5.2.4. Diagnostic Values.................................... 30 90 5.2.4.1. Primary Return Code Values...................... 31 91 5.2.4.2. Secondary Return Code Values.................... 31 92 5.2.4.3. Error Detector Address.......................... 33 93 5.2.4.4. Error Detector Data............................. 33 94 5.3. Command Formats........................................... 34 95 5.3.1. MPTN_Connect......................................... 34 96 5.3.1.1. MPTN_Connect Optional Fields.................... 36 97 5.3.2. MPTN_Hdr............................................. 40 98 5.3.3. MPTN_DG_OOB_Data..................................... 41 99 5.3.4. MPTN_DG_KEEPALIVE_Hdr................................ 44 101 SECURITY........................................................... 45 103 REFERENCES......................................................... 46 105 AUTHORS' ADDRESSES................................................. 46 107 1. INTRODUCTION 109 Applications that involve communications over a network are typically 110 written using a given application programming interface (API) that ties 111 it to a specific communications protocol, referred to as its "native" 112 protocol. For example, Telnet uses the sockets API which ties it to 113 TCP/IP, a version of DB2 uses the Advanced Peer to Peer Communications 114 (APPC) API, the native protocol for which is LU6.2, Lan Requester uses 115 the NetBEUI API and thus it's native protocol is NetBIOS, and so on. 117 Multiprotocol Transport Networking (MPTN) is an architecture for 118 building a class of middleware systems that allow applications, 119 originally designed to run on a given communications protocol, to run on 120 any other protocol (i.e., run over a "nonnative" protocol) without 121 change. Breaking the binding that typically exists between an 122 application and a communications protocol enables users to reduce the 123 number of protocols installed in their physical networks without giving 124 up their favorite applications. 126 In contrast to encapsulation techniques such as Data Link Switching, 127 where entire frames emitted by OSI layer 1 of a communications protocol 128 are encapsulated as data over another communications protocol, MPTN uses 129 a "protocol conversion" technique. TCP62 is the subset of MPTN 130 architecture which supports programs written to APIs that depend on the 131 LU6.2 protocol (e.g., APPC, CPIC) to run on a TCP/IP network. 133 [1]MPTN architecture addresses two separate problems - providing 134 application independence from communications protocols, and the problem 135 of network heterogeneity. 137 A node that performs protocol conversions at an end point, allowing an 138 application to run over a nonnative protocol without change, is called 139 an "MPTN access node". A TCP62 node is an access node that converts 140 LU6.2 to TCP/IP. 142 The network heterogeneity problem is addressed by an "MPTN gateway", 143 which performs transport layer concatenation of heterogeneous networks. 144 For example, a TCP62 gateway would allow an APPC application running on 145 a TCP/IP network to communicate with an APPC application on a native SNA 146 network. An MPTN gateway performs all the protocol conversions that an 147 access node performs, and additional protocol conversions to hide the 148 nonnative network (in the TCP62 case, TCP/IP) from the native network's 149 control flows (e.g., APPN control point protocols). MPTN gateway 150 technology is not an X/Open standard. This draft only covers the access 151 node function for LU6.2 over TCP/IP. 153 2. A HIGH LEVEL OVERVIEW OF TCP62 FUNCTION 155 To implement TCP62 function on a given platform, the following issues 156 need to be considered. 158 1. The LU6.2 stack on that platform needs to be modified so that 159 transport layer functions of an LU6.2 session are provided by 160 a TCP connection, after the session traffic has been processed 161 by protocol conversion software. 163 Since transport layer functions required by the LU6.2 stack 164 do not exactly match the characteristics of TCP connections, 165 "protocol compensations" have to be performed by the 166 conversion code. Definition of the formats and protocols for 167 performing such compensations is the primary focus of this 168 draft. 170 An important issue that needs to be addressed is - what 171 constitutes LU6.2 transport layer function. A secondary, but 172 related issue is - which LU6.2 headers need to flow across a 173 TCP/IP network for higher layer (OSI layer 5 and above) 174 functions. 175 2. Protocols associated with LU6.2, such as Advance Peer to Peer 176 Networking (APPN) control point protocols, as well as LU6.2 177 session level pacing protocols, must be prevented from flowing on 178 the TCP/IP network. 179 3. Since TCP62 allows LU6.2 applications to run unchanged over a 180 TCP/IP network, LU6.2 network resource names used by the latter 181 applications have to be mapped to the IP addresses of the 182 machines where those resources reside. This is referred to as 183 the "address mapping" problem. 185 The figure below illustrates logical components in a node running TCP62. 187 --------------- 188 | APPC/CPIC | 189 | application | 190 --------------- 191 ^ 192 | 193 v 194 --------------- 195 | LU6.2 | 196 | protocol |<--- 197 | stack | | Transport layer 198 --------------- | requests 199 v 200 ----------------- 201 | Protocol | 202 | compensations | 203 | + | 204 | Address | 205 | mapping | 206 ----------------- 207 ^ 208 | 209 v 210 ================= 211 == sockets API == 212 ================= 213 ----------------- 214 | TCP/IP | 215 | protocol | 216 | stack | 217 ----------------- 219 Figure 1. High Level Overview of the Components of a TCP62 Node 221 2.1. Protocol Compensations Required for TCP62 223 TCP62 maps LU6.2 sessions to TCP connections. It is a one-to-one 224 mapping. LU6.2 sessions provide connection-oriented semantics, ensuring 225 in-order, reliable delivery of data. OSI layer 5 and above functionality 226 is provided with half-duplex session management semantics and 227 transaction support (sync point). Since LU6.2 session semantics do not 228 exactly match the functions provided by a TCP connection, TCP62 code 229 must compensate for the differences. The functional differences between 230 the session semantics of each protocol is outlined below. 232 1. Connection setup with connection data: 234 When an APPC application wants to communicate with a partner 235 application, it requests that an APPC "conversation" for a given 236 class of service (COS) be set up to a partner LU, where the 237 partner application is identified by a "transaction program (TP) 238 name". The APPC stack in turn checks if an LU6.2 "session" for 239 that COS already exists to the partner. If so, then the 240 conversation setup involves flowing the appropriate LU6.2 format 241 (FMH5) on that session as control data. Otherwise, the session 242 must be set up over an MPTN connection using MPTN protocols. 244 LU6.2 session setup involves flowing a BIND (a set of bits that 245 define session parameters) to the session partner, which in OSI 246 terms constitutes "connection data". 247 The session partner returns a BIND response (connection response 248 data), and if it is acceptable to the node that initiated the 249 connection request, session setup is complete. Since the TCP 250 connection setup protocol does not require connection data, this 251 is an area that will require protocol compensation. 253 2. Record-oriented traffic 255 APPC conversations guarantee that units of data sent by APPC 256 applications will be delivered to the session partner with record 257 boundaries kept intact. This should be contrasted with TCP, which 258 is a stream-oriented transport layer protocol. 260 3. Expedited Data: 262 In MPTN architecture, expedited data is defined as "out-of-band" 263 data on a connection that can bypass the normal queueing 264 mechanisms that "normal" data on that connection is subjected to. 265 Expedited data on a connection can therefore bypass (i.e., arrive 266 at the destination before) normal data that was sent before it, 267 but must not arrive at the destination any later than normal data 268 that was sent after it. 270 The LU6.2 protocol stack requires support for expedited data for 271 the following two reasons: 273 - In older versions of the APPC API which supports half-duplex 274 conversations only, applications cannot send expedited 275 data, but the protocol stack itself sends expedited data that 276 needs to bypass normal data which can be held up due to 277 queueing LU6.2 congestion control. 279 - In full duplex APPC APIs (including CPIC), applications can 280 send expedited data with the same properties that the 281 APPC protocol depends on. 283 Expedited data in LU6.2 can be more than one byte long, and has 284 more general properties than those provided by the TCP (1-byte) 285 urgent data mechanism, making this another area where protocol 286 compensations will be required of a TCP transport provider, 288 4. Session Outage Notification: 290 APPC sync point functions (e.g., which provide 2-phase commit like 291 capability) depend on the APPC API to provide them with 292 immediate notification when a session is disrupted. In LU6.2, 293 such notification is provided by the Data Link Control (DLC) layer 294 of the stack, which performs LLC-2 level "keepalive" protocols 295 with the adjacent link station that constitutes the next hop in an 296 end-to-end LU6.2 session. 298 TCP/IP implements a keepalive protocol on a per connection basis, 299 but on most implementations (at the time when TCP62 was designed), 300 the keepalive timers were quite high (e.g., 2 hours) and were not 301 configurable. This led to the definition of a keepalive 302 compensation for this function, which needs to be implemented by 303 TCP62. 305 5. Duplex-Abortive Session Termination with Termination Data 307 In MPTN architecture, a connection termination request is 308 classified as duplex if transport user on one end of the 309 connection can terminate both ends of the full-duplex 310 connection. The connection termination is classified as 311 abortive if no guarantees are required to ensure that data 312 in flight needs to reach the other end of the connection, 313 when the termination request is received by the protocol 314 stack. 316 APPC applications view connections as conversations, whereas, 317 the LU6.2 stack's view of a connection is a session. Since LU6.2 318 sessions are normally terminated only when no conversations are 319 active, the requirement for abortive close seems quite natural. 320 Session termination with a conversation active is a severe enough 321 condition where any attempts to preserve the integrity of data in 322 flight would be meaningless. 324 An LU6.2 session is terminated by exchanging UNBIND and UNBIND 325 response formats on the session. In MPTN (as well as OSI) 326 parlance, this is known as termination data. Since TCP 327 connections do not provide the exchange of termination data 328 during connection shutdown, this is yet another area where a 329 compensation is required. 331 2.1.1. LU6.2 Headers that Flow Over TCP/IP 333 Since LU6.2 transport function in TCP62 is performed by TCP/IP, only 334 those LU6.2 headers that are required by higher layers of the LU6.2 335 stack need to flow over a TCP connection. For all LU6.2 formats that 336 flow over TCP connections, only the following headers are included: 338 - only the sequence number field of the LU6.2 transmission header 339 (TH) 340 - the entire request/response header (RH), except when reassembly of 341 LU6.2 request/response units (RUs) is being performed by TCP62. 343 While it is hard to exactly map SNA protocol stack functions to OSI 344 transport and session layer functions, it is a reasonable approximation 345 that the TH represents transport layer information while the RH contains 346 session layer information needed to implement functions such as half- 347 duplex conversations. The sequence number field in the TH is used to 348 implement acknowledged data transmissions in APPC and CPIC API, and 349 since that is not a typical transport layer function in protocols other 350 than SNA, a compensation was not provided for it, but instead, the LU6.2 351 implementation of that function is preserved - thus preserving a portion 352 of the transport header. 354 2.1.2. A Sample Flow 356 The example below illustrates the flows that take place when an 357 APPC/CPIC application on Node A requests a conversation with an 358 application on Node B. The LU6.2 stack finds no existing session to 359 reuse, and therefore creates one. The request goes through the TCP62 360 code, and the LU6.2 session is mapped to a TCP connection. Application 361 data flows on the LU6.2 session, and as payload on the TCP connection 362 (and sometimes, as payloads of UDP datagrams) after MPTN headers have 363 been added to indicate the protocol compensations being performed. 364 Finally, the conversation ends, and the session is terminated 365 (typically, LU6.2 sessions stay up and get reused for new conversations; 366 the session termination case is used to demonstrate the entire life 367 cycle of the connection). 369 Node A Node B 370 --------------- ---------------- 371 | APPC/CPIC | | APPC/CPIC | 372 | application | | application | 373 |=============| |==============| 374 | LU6.2 | | LU6.2 | 375 | stack | | stack | 376 |=============| |==============| 377 | TCP62 | | TCP62 | 378 |=============| |==============| 379 | TCP /IP | | TCP/IP | 380 --------------- ---------------- 382 Step 0: Perform the address mapping to discover the partner 383 node's IP address, given the LU name that the application 384 uses. The details of that step are omitted. 386 Step 1: Setup native TCP connection to partner node 387 <==============================> 389 Step 2: Exchange MPTN connection setup packets as data on TCP 390 connection, thus mapping an APPC session to a TCP connection. 392 IP header, TCP header, MPTN_Connect (incl. BIND image) 393 -------------------------------> 394 IP header, TCP header, MPTN_Connect RSP (incl. BIND RSP) 395 <------------------------------- 397 Step 3: Exchange LU6.2 (connection-oriented) application data over 398 TCP connection, using TCP62 protocol compensation headers. 399 Occasionally, UDP datagrams need to be used for certain 400 compensations, as described in a later section. 402 IP header, TCP/UDP header, compensation header, 403 SNA TH subset + RH, application/protocol data 404 <==============================> 406 Step 4: Terminate SNA session using TCP62 protocols. 407 The termination protocols use UDP only. 409 IP header, UDP header, protocol compensation header, 410 SNA TH subset + RH, application/protocol data 411 <==============================> 413 Figure 2. High Level Overview of TCP62 Protocols 415 2.2. LU6.2 and Related Protocols to Disable When Running TCP62 417 Since TCP62 was designed to be a protocol conversion approach instead of 418 a protocol encapsulation approach, every effort was made to filter out 419 aspects of LU6.2 and related protocols for which analogous functions 420 exist on a TCP/IP network. The two categories of protocols to be 421 disabled in a node running TCP62 are 423 1. APPN control point protocols. 424 2. LU6.2 pacing protocols. 426 APPN control point protocols serve the same function as routing 427 protocols in a TCP/IP network. These protocols implement a link state 428 routing algorithm (similar to OSPF), where special nodes called network 429 nodes (which form the APPN network backbone) continuously exchange 430 topology information, and use that information to compute an optimal 431 route between two logical units (LUs). 433 LU6.2 uses a window based flow control mechanism, which is conceptually 434 similar to TCP/IP's sliding window protocol. LU6.2 protocols use an 435 "adaptive pacing" mechanism, where the stack at the sending end of a 436 connection requests additional windows (one for each record that it will 437 send) from the receiver by setting a "pacing request" bit in the SNA 438 Record Header (RH). The stack at the receiving end of the session sends 439 an Isolated Pacing Message (IPM), based on the buffer capacity in the 440 node, to indicate how many more records the transmitting side can send 441 it. 443 Since TCP/IP already uses an various IP routing protocols that allows 444 any node on an IP network to reach any other node with an IP address on 445 that network, TCP62 prohibits APPN protocols (the routing protocol 446 associated with APPC) from running over TCP/IP, since that would amount 447 to running two separate routing protocols on the same network. The 448 address mapping compensation is used to map partner LU names to partner 449 IP addresses, and existing IP routing mechanisms (and ARP) are 450 sufficient to complete the rest of the steps leading to native SNA 451 connection setup. 453 LU6.2 flow control protocols are disallowed when running TCP62. In 454 particular, the pacing request bit of the LU6.2 RH must never be set 455 when sent over a TCP connection. In addition, IPMs must also be 456 prevented from flowing over TCP/IP. The rationale for this decision is 457 to prevent one set of pacing protocols from being run of top of another. 458 A TCP62 implementation must map the APPC adaptive pacing protocol to 459 TCP/IP's flow control protocol. This is described in greater detail in 460 Section 4.2, "Pacing". 462 2.3. TCP62 Address Mapping 464 Distributed applications use names to identify communication partners. 465 Different communications protocols use diverse naming conventions to 466 identify partner nodes, and applications within those nodes. APPC 467 applications use LU6.2 names to identify a logical units in nodes. LU 468 names are of the form 470 NETWORK-ID.LOGICAL-UNIT-NAME 472 where both the network-id and logical-unit-name parts can be up to 8 473 bytes long and use a subset of the EBCDIC character set. A transaction 474 program (TP) name, which can be up to 64 bytes long, is used to identify 475 the application in the partner node. A socket application uses a 4-byte 476 IP addresses to identify partner node, and a port number to identify the 477 partner application. 479 Address mapping can be thought of as a type of compensation to be 480 provided, not due to a mismatch in transport protocol function, but due 481 to a mismatch in naming conventions used in different protocols to 482 identify communications partners. Since an APPC/CPIC application uses an 483 LU name to identify its partner, this has to be translated to an IP 484 address by TCP62 so that communication with the node where the partner 485 LU resides can take place over TCP/IP. 487 In LU6.2, only the partner LU name is used when a session is set up. 488 The TP name is exchanged in a later flow. Therefore, a solution to the 489 address mapping problem in TCP62 requires a mechanism for mapping a 490 partner LU name to the partner IP address. Address mapping is performed 491 using the TCP/IP Domain Name System (DNS), which consists of a resolver 492 (client), which queries a domain name server or a local HOSTS file to 493 map a domain name to an IP address. Address mapping is TCP62 is 494 implemented as follows: 496 1. For each LU6.2 name that is a potential partner of an APPC 497 application running over TCP/IP, the name is converted to a 498 domain name using the following algorithm: 500 - the EBCDIC characters are converted to ASCII characters 501 - the ASCII character name, which is of the form 502 NETWORK-ID.LU-NAME 503 is converted to the form 504 LU-NAME.NETWORK-ID 505 by swapping the network and LU-name portions on either side 506 of the period. 508 - an SNASUFFIX (a configured value) that is common to all TCP62 509 nodes in the user's TCP/IP network is added to the above 510 name. 512 The SNASUFFIX is of the form A.B.C such that it adheres to 513 the rules of a valid TCP/IP domain name suffix. 515 For example, if the LU name (in ASCII) is NET1.LU1, and the 516 SNASUFFIX value for the customer network is 517 dept1.company2.com, then the domain name derived from the LU 518 name would be: 519 LU1.NET1.dept1.company2.com 521 2. The domain name is mapped to the IP address of the node where 522 that LU resides (in a TCP62) node, by either entering the mapping 523 in the database of a domain name server that serves the domain 524 dept2.company1.com, or in a HOSTS file that would need to be 525 distributed to all TCP62 nodes in the network. 527 3. When an LU6.2 stack in a TCP62 node requests an LU6.2 528 session to a partner LU, the TCP62 address mapping code 529 must do the following: 531 - apply the algorithm described in step 1 above to map the 532 partner LU name to a domain name 533 - query the DNS (using a standard sockets API call such as 534 gethostbyname) which will return the IP address mapped to 535 that domain name 536 - use the IP address that was returned to set up a TCP 537 connection to that node, in preparation for performing the 538 connection setup protocols to that node. 540 3. Protocol Compensations 542 The previous section introduced the need for protocol compensations. 543 This section describes how each compensation is performed. The formats 544 of MPTN flows that are used to perform these compensations is described 545 in Section 5, "TCP62 Formats". 547 In TCP62, one TCP connection is used to map an LU6.2 session. 548 Compensations are implemented by flowing MPTN headers, usually followed 549 by payloads that contain SNA packets. The MPTN header conveys to the 550 receiver the nature of the compensation, allowing it to take appropriate 551 action. Some MPTN headers flow on the TCP connection representing the 552 session, whereas others flow as payloads of UDP datagrams, either to 553 bypass TCP flow control (e.g., for expedited data), or because the 554 compensation is node-level rather than session level (e.g., for 555 implementing a keepalive protocol). 557 The life cycle of an SNA session can be summarized as follows: 558 - A session is set up by first creating a TCP connection to the 559 node hosting the partner LU, whose IP address is determined using 560 address mapping. The first packet on the connection is an 561 MPTN_Connect, a portion of which contains the LU6.2 BIND image. 562 The partner TCP62 node sends an MPTN_Connect response packet 563 back, which includes the BIND response, and the connection set up 564 is complete. 565 - Regular data transfers now begin. Data that flows on the 566 connection always consists of a 1-byte header that describes the 567 compensation. This is typically followed by SNA headers and data. 569 Expedited data flows using a more complex compensation mechanism. 570 The data is first sent on the connection, but if an expedited data 571 acknowledgement packet is not received in a fixed time (e.g., 3 572 seconds in IBM implementations), the expedited data is sent to 573 the partner in an "out-of-band" (OOB) datagram. OOB datagrams use 574 a more complex format and flow as UDP datagrams. 576 All SNA sessions require session outage notification compensation, 577 which is performed using "keepalive" datagrams. Keepalive datagrams 578 do not have any payload and also flow as UDP datagrams. The 579 keepalive compensation is performed on a node-pair basis, as long 580 as at least one LU6.2 session exists between those nodes. 582 - Finally, if the session is to be terminated, the UNBIND image is 583 sent to the partner node using the expedited data mechanism. 585 3.1. Connection Establishment 587 When establishing a LU6.2 session over TCP/IP, the normal TCP connection 588 establishment occurs first. The destination address is a combination of 589 the IP address obtained using address mapping, and the well-known port 590 utilized by MPTN. The values for the well-known ports are 397 for TCP 591 and 397 for UDP. After the TCP/IP connection has been established, the 592 two nodes exchange an MPTN_Connect command and response in order to set 593 up an MPTN connection. The initiating node sends the MPTN_Connect 594 command, including addressing information, connection characteristics, 595 and any connection data required. For LU6.2, the connection data is the 596 BIND RU. For detailed information about the MPTN_Connect and 597 MPTN_Connect response as they apply to LU6.2 over TCP/IP, please refer 598 to Section 5.3.1, "MPTN_Connect". 600 After processing the MPTN_Connect, the target node will send an 601 MPTN_Connect response. This response may include some changes to the 602 connection characteristics. The negotiable connection characteristics 603 are: maximum record length, maximum expedited record length, and 604 maximum length of connection termination data. These connection 605 characteristics may be negotiated down. The characteristics sent in the 606 MPTN_Connect response are the ones used on the connection. 608 In the MPTN_Connect command and response, there is a correlator suffix 609 field. This correlator suffix, when combined with the destination and 610 source MPTN addresses, must be unique for all time. 612 3.2. Data Transfer 614 When LU6.2 session data is sent, the stack builds a TH and an RH which 615 precedes the payload. The SNA headers are manipulated by the TCP62 code 616 so that only the sequence number part of the TH, and the RH with the 617 pacing request bit set to 0, flows on the TCP connection. On the 618 receiving node, the TCP62 code must rebuild the part of the TH that was 619 truncated by the sending node, and must also set the pacing bit on the 620 RH based on the implementation of pacing as described in Section 4.2, 621 "Pacing". 623 SNA session data is prefixed with a one-byte MPTN compensation header 624 that indicates the type of compensation being performed. When the data 625 flows over TCP, the compensation header is preceded by a four-byte 626 length field that indicates the length of the SNA data (including 627 headers), and also includes the sizes of the MPTN header and length 628 fields (5 bytes). 630 3.2.1. Nonexpedited Data 632 In TCP62, nonexpedited (or normal) data needs record-over-stream 633 compensation, since SNA honors record boundaries while TCP/IP is 634 stream-oriented. Normal data always flows over TCP, subject to the flow 635 control of the TCP connection. The one-byte compensation header 636 indicates that it is nonexpedited data with record boundaries preserved, 637 and the TCP62 code on the receiving node does not deliver it to the 638 local stack until the entire record arrives. 640 3.2.2. Expedited Data 642 3.2.2.1. Sending Expedited Data 644 LU6.2 requires the ability to send expedited data that fulfills two 645 requirements: 647 1) The expedited data must arrive before data sent later 648 on the connection. 650 2) The expedited data must be able to bypass normal data 651 queues, which may be backed up due to congestion. 653 Both the LU6.2 protocol stack, as well applications that use the full 654 duplex APPC API have the ability to send expedited data even if the 655 receiver is not receiving normal data. 657 In order to provide for these requirements, an MPTN compensation is 658 provided that sends data on the normal connection (to meet requirement 659 1, listed above), and, if needed, as a datagram (to meet requirement 2). 660 The receiver processes the version that arrives first, and discards the 661 other. 663 TCP/IP supports urgent data, but it's features are not rich enough to 664 meet the requirements of LU6.2. 666 - While TCP/IP support urgent data, there is no guarantee that 667 the urgent data will be sent if the window size on the TCP 668 connection is zero. Under zero-window conditions, newer releases of 669 BSD code send a TCP packet without any payload, but with the urgent 670 bit set, to inform the partner about the availability of urgent 671 data. 672 The partner can read all the normal data that precedes the urgent 673 data (the process of receiving the normal data will increase the 674 window size, enabling the sender to send data). However, when TCP62 675 was first designed, there was no indication that many TCP/IP 676 implementations on Wintel systems had this fix. 678 - The above fix, even if present, is not sufficient for LU6.2 679 use. The TCP urgent data mechanism only handles one byte of 680 urgent data, though additional urgent data can be handled if 681 there is an a priori agreement between the sender and the 682 receiver about the length. Since LU6.2 expedited data can have 683 arbitrary lengths, any scheme based on predefined lengths is 684 infeasible. 686 - Finally, the TCP urgent data mechanism only marks the most recently 687 sent urgent data. If the receiver does not process urgent data #1 688 by the time urgent data #2 is sent, all indications that data #1 689 was urgent are lost. 691 Given these limitations of the TCP urgent data mechanism, the expedited 692 data compensation designed for TCP62 is based on the assumption that TCP 693 has no expedited support at all. 695 Expedited data received from the LU6.2 stack is sent on the TCP 696 connection in the same way as normal data (with the LU6.2 headers 697 doctored, and preceded by a length and compensation header field), 698 except that the one-byte header field indicates that the data is 699 expedited. Expedited data requires an acknowledgement, which consists of 700 a length field and a one-byte compensation header that indicates that it 701 is an acknowledgement. There is no payload associated with this, and so 702 the length field should have a value of 5. The receiving TCP62 node 703 should send this acknowledgement as soon as it receives the expedited 704 data. Note that since the expedited data is sent on the TCP connection, 705 it is subject to TCP flow control, and may take a considerable amount of 706 time to reach the partner. Since this might happen, the compensation 707 mechanism uses a timer to wait for the acknowledgment, and if it does 708 not receive the acknowledgement in a reasonable amount of time (the 709 default is 3 seconds in IBM implementations), then the data is sent 710 using MPTN OOB datagrams, whose format is described in Section 5.3.3, 711 "MPTN_DG_OOB_Data". 713 When expedited data is sent as an OOB datagram, it appears as a payload 714 of an UDP datagram, whose destination address is the IP address of the 715 node hosting the partner LU, and the UDP port number is 397. The data 716 portion of the OOB datagram only consists of the MPTN header and the SNA 717 header subset and payload. Since UDP datagrams are not stream-oriented 718 but preserve record boundaries, the 4-byte length field is not required. 720 When expedited data is sent on an OOB datagram, the partner is expected 721 to respond with an OOB reply datagram which has no payload. If this 722 reply is not received in a reasonable amount of time (e.g., 10 seconds 723 is a default value on some IBM implementations, but the value can be 724 customized), the OOB datagram is retransmitted. If five retransmissions 725 yield no response, the connection is assumed to be dead and is torn 726 down. 728 In addition to the data being sent, the MPTN_DG_OOB_Data format includes 729 a connection correlator used to identify the associated connection, and 730 a connection sequence number that uniquely identifies that piece of 731 expedited data on the connection. These fields are described next. 733 3.2.2.1.1. Sequence Numbers in OOB Datagrams 735 Since expedited data that flows in an OOB datagram may reach the partner 736 in two different ways, the sequence number field allows the receiving 737 TCP62 node to discard whichever copy reaches it last. Note that when the 738 expedited data is first sent on the TCP connection, no sequence number 739 is included. Instead, the receiving TCP62 node is expected to keep a 740 count - which is sufficient because TCP delivers data in order, and 741 without loss. A sequence number field is required in the OOB datagram 742 because UDP datagrams can be lost and be delivered out of order. 744 The connection sequence numbers start at zero and increment after each 745 expedited message is sent. The sequence number field wraps (reset to 746 zero) at 65,535, which is sufficient to uniquely identify a given record 747 sent in an expedited fashion, assuming a reasonable amount of loss and 748 reordering of UDP datagrams. Retransmission of a previous expedited 749 message is not counted as a separate event. 751 3.2.2.1.2. Correlating an OOB Datagram to a Connection 753 The connection correlator in an OOB datagram consists of two parts: the 754 correlator address, which is a field that was assigned by the TCP62 node 755 that initiated the connection (and flowed on the MPTN_Connect packet), 756 and the correlator suffix, which is a value unique to SNA. The two 757 parts are concatenated to form the connection correlator. 759 There are two ways to correlate the MPTN_DG_OOB_Data to the associated 760 connection; the choice is up to the initiator of the format: 762 1) Using the connection correlator field only. 764 2) Using the connection correlator field and the optional receiver 765 connection alias field. 767 The connection correlator is recognized by both sides without any extra 768 protocol being involved. The receiver connection alias is a local 769 identifier that can be used by the destination for a quicker 770 identification of the connection. The receiver connection alias on an 771 inbound OOB datagram can be used to identify the connection in a faster 772 manner than performing a match on the connection correlator. The 773 connection alias could be a connection control block pointer, a socket 774 number, or any other field that is deemed suitable by an implementation. 776 In the first MPTN_DG_OOB_Data sent for the connection, the sender can 777 provide its own local identifier (in the sender connection alias field) 778 in addition to the connection correlator. The receiver locates the 779 connection using the connection correlator and stores the sender 780 connection alias so that it knows the value to be returned in the 781 receiver connection alias field in the future. 783 Whenever a TCP62 node builds an MPTN_OOB_DG_Data format to send to its 784 connection partner, it should include a receiver connection alias, if 785 available. Inclusion of the receiver connection alias is recommended 786 for performance reasons. 788 The sender of an OOB datagram should continue to include its sender 789 connection alias until it receives an indication from the target that it 790 has been received, either in a positive response to an MPTN_DG_OOB_Data 791 sent, or in an MPTN_DG_OOB_Data command from the partner with the 792 receiver connection alias containing its local id. 794 3.2.2.2. Receiving Expedited Data 796 The target of the expedited data transfer must respond to each instance 797 of the expedited data received with an appropriate acknowledgement, 798 either with an MPTN Header marked as an expedited acknowledgement which 799 is sent on the TCP connection, or an MPTN_DG_OOB_Data response packet, 800 which is sent using UDP. 802 In the case of the MPTN_DG_OOB_Data response, the connection sequence 803 number is included in the MPTN_DG_OOB_Data response, and informs the 804 partner that the data has been received and any retransmissions should 805 be stopped. 807 3.3. MPTN Keepalive Protocol 809 TCP62 nodes must implement a keepalive protocol because TCP connections 810 do not provide session outage notification (SON) in a timely manner. 811 Even though TCP provides a per connection KEEPALIVE facility, the 812 typical values of TCP keepalive timers (the period of inactivity after 813 which liveness checking is initiated) are much larger than SNA's SON 814 requirements. Note that in many current TCP implementations, the 815 KEEPALIVE timer is settable on a per connection basis, but since this 816 was not true when TCP62 was first designed, this compensation was deemed 817 necessary. 819 3.3.1. The Problem of Out-of-Sync Connections 821 When two access nodes have a number of MPTN connections between them 822 (ignoring connections that are coming up or are being taken down), one 823 of two things can happen to cause them to have different views of which 824 connections they have with each other: 826 - One of the access nodes crashes. This does not allow any 827 connection termination flows to reach the partner node to allow 828 the connections to be taken down. None of the TCP connections 829 are taken down either. If there is no activity on any of the 830 sessions, the two sides will have an inconsistent view of which 831 LU6.2 sessions they have with each other until the TCP KEEPALIVE 832 mechanism kicks in. 834 - An intermediate router in the TCP connection between the two 835 TCP62 nodes goes down for a while. During that period, each of 836 the two nodes can independently close one or more LU6.2 sessions 837 that they have with the partner. However, because of the dead 838 router, neither the TCP62 flows nor any TCP connection termination 839 flows can reach the partner. This would result in the two nodes 840 having an inconsistent view of the connections they have with 841 each other. 843 When two active TCP62 nodes have inconsistent views of the number of 844 LU6.2 sessions they have with each other, a new LU6.2 session set up 845 request initiated by one node (which believes that the number of 846 existing sessions is within limits) may be rejected by the partner node 847 (which believes that session limits have already been reached). 849 The above situation is a direct result of the fact that while the router 850 was down, the TCP keepalive mechanism did not get triggered. The 851 assumption here is that the router went down and came back up before the 852 TCP keepalive timer expired. Since TCP keepalive timers are often set 853 to an hour or more by default, and are not changeable in many 854 implementations, this is not an unrealistic scenario. 856 If the TCP keepalive timer was user settable, this problem could be 857 avoided by setting the timer value that is smaller the time required for 858 a router or an access node to be restarted after a crash (e.g., 2 859 minutes). However, most implementations do not allow this timer to be 860 changed by the user. The alternate solution is to implement an MPTN 861 keepalive protocol. The protocol is described in the next section. 863 3.3.2. A Keepalive Protocol Using Datagrams 865 The MPTN keepalive protocol is executed by two TCP62 nodes that have one 866 or more LU6.2 sessions with each other. LU6.2 sessions require SON, and 867 while SON is a session level characteristic, the keepalive protocol is 868 optimized to operate at a node-pair level. SON is a transport user 869 characteristic that flows on the MPTN_Connect packet (see Section 870 5.3.1.1.3, "User Characteristics") and both TCP62 nodes are thus aware 871 of when the keepalive protocol should be performed. The keepalive 872 protocol between a pair of nodes is stopped when the last LU6.2 session 873 between them is terminated. 875 The keepalive protocol involves sending a keepalive datagram if an 876 inactivity timer expires, and waiting for a response. 878 - When the first LU6.2 session between a pair of TCP62 nodes 879 is set up, an inactivity timer is started for that partner node. 880 The value of the timer should be user settable. 882 - When any data is received from the partner node - such as a 883 connection request, data on an existing connection, an 884 OOB datagram, or a keepalive datagram - the timer is reset. 885 However, if no data is received from that partner before the 886 timer expires, the MPTN keepalive protocol is initiated 887 with that partner by sending it a keepalive datagram. Like OOB 888 datagrams, keepalive datagrams flow as payloads of UDP datagrams 889 and are sent to port 397, the MPTN well-known datagram 890 port number. Keepalive datagrams never include any LU6.2 payload. 892 - Once the keepalive protocol is initiated, a keepalive datagram is 893 sent to the partner once every X seconds, where X is a value that 894 can be configured by the user. When a TCP62 node receives a 895 keepalive datagram, it must send a keepalive datagram RSP packet 896 back to the sender. If a node does not receive a response to a 897 keepalive datagram, or receive some other communication from 898 the partner node after having sent the datagram 5 times, it 899 concludes that the partner is either dead or is unreachable, and 900 all LU6.2 sessions to that partner are terminated. 902 To cover the case where a node goes down and comes back up before the 903 KEEPALIVE protocol is able to detect the outage, an optional node 904 initialization ID field is included as part of the MPTN_Connect command. 905 This field contains a value that uniquely identifies the instance of the 906 sending node, e.g., a time stamp corresponding to the time the node was 907 initialized. The receiving node keeps this value, and compares it with 908 future incoming node initialization IDs from the same partner. If the 909 values are different, the partner has gone down and recovered. Thus, 910 all sessions with the partner that require SON should be cleaned up. 912 3.4. Connection Termination 914 When an LU6.2 session is terminated, an RU containing an UNBIND image is 915 sent to the partner. A session termination request assumes that both 916 ends of the session will be terminated, and any data in flight can be 917 dropped. Since APPC applications use conversations on top of sessions as 918 application level connections, and since a session is rarely brought 919 down when a conversation is using it, these semantics make sense. 921 In LU6.2 protocols, an UNBIND image always flows as expedited data, 922 since it should not be held up by session level pacing. Therefore, in 923 TCP62, the transmission of the UNBIND request must use expedited data 924 compensation. Unlike all other expedited data, the UNBIND is only sent 925 as an OOB datagram, without first making an attempt to send it on the 926 connection first. The regular expedited data compensation mechanism is 927 designed to deal with the fact that the data can reach the partner node 928 in two different ways. In this case, since the action the receiver will 929 take is to terminate the connection, it was decided that a simpler 930 option would be to flow the termination request using one mechanism 931 only. And since using the TCP connection is potentially delay-prone, the 932 OOB option was chosen. 934 When an UNBIND image is sent to the partner as an OOB datagram, its 935 payload consists of a 1-byte compensation header that indicates duplex- 936 abortive compensation, and the payload in the UNBIND preceded by the TH 937 subset and the RH. As with regular expedited data, the payload does not 938 include the 4-byte length field. When the TCP62 code sends the 939 termination request, it should discard any data that was queued for 940 transmission on that session, and should disable further reception of 941 inbound data on that connection. 943 The TCP62 node that receives the UNBIND request passes it up to the 944 local SNA stack, and terminates the TCP connection after discarding any 945 session data that was queued for transmission on that connection. The 946 TCP connection termination uses the standard socket "close" call, and 947 represents orderly shutdown of one end of the connection. When the local 948 SNA stack sends an UNBIND response, the TCP62 code sends an OOB response 949 datagram back to the sender to indicate that the session termination on 950 that node is complete. The inclusion of the UNBIND response image in the 951 OOB datagram is optional. 953 When the node that initiated the connection termination request receives 954 the OOB datagram response, it should inform the SNA stack (manufacturing 955 an UNBIND image if one was not included in the response datagram), and 956 finally, it should terminate it's end of the TCP connection using the 957 orderly termination semantics of the socket "close" call. 959 4. Other Protocol Issues Not Related to Compensations 961 4.1. Segmentation and Reassembly of APPC Request/Response Units 963 In the APPC protocol, a request/response unit (RU) represents a unit of 964 data whose size (the RU size) is typically negotiated by all nodes in 965 the session path based on the smallest frame that a DLC in the session 966 path can transmit on a link. Irrespective of the size of the record that 967 an application sends across the APPC API, the largest record that flows 968 as the payload of an LU6.2 packet cannot be bigger than the RU size. 969 This ensures that when a negotiated RU size is used, no segmentation or 970 reassembly logic will be required in any hop of the session path. 972 When an APPN node in the session path does not implement RU size 973 negotiation function, segmentation and reassembly becomes inevitable for 974 that session when run natively. When LU6.2 sessions are run over TCP/IP 975 connections using MPTN, segmentation and reassembly are not required, 976 because TCP is a connection oriented protocol and an RU of any length 977 can be sent as a stream of bytes, (using a length field prefix to mark 978 the record length, as described in Section 5.3.2, "MPTN_Hdr") without 979 requiring any kind of "segmentation". However, when MPTN transport layer 980 gateways are installed in APPN-to-TCP/IP network boundaries, RU segments 981 created in a native SNA network must be reassembled somewhere in the 982 session path before the application endpoint in an SNA-over-TCP/IP 983 access node. 985 In TCP62, the reassembly is performed by the TCP62 code in the access 986 node that receives the segments. In a native node with only a (full) 987 APPC protocol stack, such reassembly is performed by a lower layer 988 component of the stack (Path Control). However, in the MPTN framework 989 for APPC over TCP/IP, the path control code is not involved in the 990 session path) - because it belongs to the sub-layer-4 part of the APPC 991 stack whose function is replaced by the TCP/IP stack - and therefore, 992 reassembly must be performed by the TCP62 code. 994 When an MPTN gateway receives segmented data on the SNA network and 995 sends it on the TCP/IP network, it adds the usual compensation headers 996 to the data, and flows the TH subset and RH that is defined for all data 997 over TCP. All LU6.2 segments that flow on a TCP connection consist of 998 the length field and the compensation header. On all segments except the 999 last one, the compensation header indicates that the data that follows 1000 is a record segmnent and not a full record. The last segment contains a 1001 regular record-over-stream compensation header, which is interpreted by 1002 the receiver as the last record to reassemble. 1004 When an MPTN gateway sends segments over the TCP/IP network, only the 1005 first segment contains the TH subset and RH. Subsequent segments only 1006 contain the RU, making it easy for the TCP62 code on the reassembling 1007 node to concatenate the segments into a complete record. Note that this 1008 is different from the manner in which segments are sent over a native 1009 LU6.2 connection. 1011 4.2. Pacing 1013 Congestion on a TCP connection is indicated to a sockets application by 1014 blocking its send calls (or returning appropriate error codes to 1015 nonblocking send calls). For an LU6.2 connection set up using a TCP 1016 connection, congestion would be caused by the receiving end's transport 1017 provider not receiving data (due to buffer limitations on it's end 1018 coupled with the receiving application's behavior). The TCP62 code on 1019 the sending end should sense such congestion and give appropriate 1020 feedback to the LU6.2 stack such that it can "fake out" the pacing 1021 protocols that the APPC stack in the sending node believes it is 1022 executing with the next hop node. 1024 The SNA stack code on the sending node requests a pacing window by 1025 setting the pacing request bit in the RH. When the TCP62 code on the 1026 same node sees this bit, it should reset it before sending the packet 1027 over the TCP connection that represents the session (since the pacing 1028 request bit should not flow over the TCP connection), but it should 1029 remember that the sender had asked for a pacing window. If all SNA 1030 packets sent on the TCP connection, including the one whose pacing 1031 request bit was set initially, are accepted for transmission by the TCP 1032 stack (as indicated by the return code of the "send" socket call), then 1033 the TCP connection is not congested and an IPM can be sent to the SNA 1034 stack immediately. Otherwise, the TCP62 code should wait until all 1035 packets including the one requesting a pacing window is sent before 1036 sending the IPM. 1038 On the receiving node, when TCP62 code receives an indication that there 1039 is data available on a TCP connection that represents a session, it 1040 checks if SNA buffers are available for receiving that data. It 1041 initially starts with one buffer for receiving an RU (this is true of 1042 native SNA sessions too). Once that buffer has been filled with inbound 1043 data, TCP62 should set the pacing request bit on the RU before giving it 1044 to the local SNA stack code. Depending on system buffer availability, 1045 the SNA stack will either send an IPM immediately, or when buffers 1046 become available. The TCP62 code should keep track of the IPM size to 1047 determine how many more inbound RUs can be received from the TCP 1048 connection before it has to ask for another window. 1050 If there is a system buffer shortage in the receiving node, the TCP62 1051 code will stop receiving IPMs from the local SNA stack, and will 1052 therefore stop receiving data on the TCP connection. When this happens, 1053 the TCP connection's receive queue will fill up, it will stop sending 1054 TCP window updates to the sender to reflect the local congestion, the 1055 sender (TCP62 code on the sending node) will see the congestion on it's 1056 "send" socket calls, and therefore, the TCP62 code will stop sending 1057 IPMs to the sender's SNA stack. That in turn will cause the SNA stack on 1058 the sending node to apply back pressure to the application sending data. 1059 This application of back pressure based on TCP flow control, and the 1060 virtualization of SNA hop-by-hop pacing within a node, is how pacing of 1061 LU6.2 connections is performed in TCP62. 1063 5. TCP62 Formats 1064 5.1. Migration Considerations 1066 In order to ease migration for future functionality that may be added to 1067 the architecture, MPTN defines a mechanism that allows MPTN nodes to use 1068 new functions when their partners support it and still be able to 1069 interoperate with back-level nodes. Every MPTN command and optional 1070 field contains a processing specification field that tells the receiving 1071 node how to handle the command or optional field based on a number of 1072 criteria. All MPTN nodes must understand the processing specification 1073 so that they can take the correct action when they encounter 1074 unrecognized fields. If a node receives an MPTN command with an illegal 1075 command processing specification value, it will discard the command. 1077 The processing specification is a one byte field in the common prefix 1078 that specifies: 1080 - Whether the command is a request or a response. 1082 - If a response, whether it is positive or negative. 1084 - The actions that should be taken by an access node or MPTN 1085 Gateway that does not recognize the command type. 1087 - If a negative response, the reason for the failure (rejected by 1088 the partner or not understood by the partner). 1090 For a more detailed description of the bits in the processing 1091 specification field, please refer to Section 5.2.1, "Common Prefix". 1093 5.1.1. Processing Rules 1095 The following rules govern the behavior of both up-level and back-level 1096 nodes in order to make orderly migration possible: 1098 1) Every optional field and every command contains a one-byte 1099 processing specification field that specifies the actions that 1100 should be taken by either an access node or gateway that does not 1101 recognize the command or field type. 1103 2) A destination node that fails to recognize a command type or 1104 optional field tag uses the processing specification value to 1105 choose an action. The possible actions are detailed in Section 1106 5.1.2, "Processing Actions". 1108 3) Commands are processed before optional fields. If the command is 1109 valid, then the setting of the processing specification relies 1110 solely on the result of any optional field processing. 1112 4) All optional fields should be processed, unless an error has 1113 already been encountered. 1115 5) It is possible that future format changes may require multiple 1116 copies of the same optional field, while a back-level node may 1117 understand only a single instance of the field. If this happens, 1118 the receiver uses the first instance of the field and treats any 1119 additional copies of the field that it does not expect as 1120 unrecognized fields, i.e., it should ignore or fail them as 1121 specified in their processing specification fields. 1123 6) Certain required fields and optional fields (those having an 1124 overall length count) may be extended in the future by adding 1125 additional information to the end of the existing format. This 1126 may be done if and only if the success of the command does not 1127 depend on the user being able to process the additional 1128 information. For example, the user transport requirements 1129 field may be extended with additional user characteristics that 1130 a back-level destination access node does not recognize and can 1131 ignore. In this case, a destination access node should not fail 1132 a command because the field is longer than expected. When the 1133 destination access node returns such a field in a reply, the 1134 following processing applies: 1136 a) When the destination access node recognizes the additional 1137 information it must echo it back. 1139 b) When the destination access node does not recognize the 1140 additional information, it is required that the destination 1141 access node drop the part not recognized. In this case, 1142 it cannot be assumed that if the additional information is 1143 returned, it is understood. 1145 7) Reserved fields fields are set to zero by the sender and ignored 1146 by the receiver. This allows future use of these bits without 1147 breaking a back-level node. 1149 5.1.2. Processing Actions 1151 This section describes the actions taken by a destination node that does 1152 not recognize a field or command. 1154 5.1.2.1. Command 1156 If the processing specification indicates that the destination is not 1157 required to recognize the command, then the destination node should 1158 discard the command. 1160 If the processing specification indicates that the destination is 1161 required to recognize the command, then the destination node should: 1163 - Set the following fields in the command processing specification: 1164 MPTN response indicator 1165 MPTN negative response indicator 1166 MPTN destination unrecognized indicator 1168 - Set the Time To Live (TTL) field to initial value 1170 - Optionally add diagnostics field 1172 - Return the command to the source 1174 5.1.2.2. Field 1176 If the processing specification indicates that the destination is not 1177 required to recognize the field, then the destination node should set 1178 the MPTN destination unrecognized indicator in the optional field and 1179 proceed with the rest of the command processing. 1181 If the processing specification indicates that the destination is 1182 required to recognize the field, then the destination node should: 1184 - Set the following fields in the command processing specification: 1185 MPTN response indicator 1186 MPTN negative response indicator 1188 - Set the following fields in the field processing specification: 1189 MPTN destination unrecognized indicator 1191 - Set the Time To Live (TTL) field to initial value 1193 - Optionally add diagnostics field 1195 - Return the command to the source 1197 5.2. Common Command Formats 1199 Establishing, maintaining, and terminating LU6.2 connections over TCP/IP 1200 involves the use of several different command formats. These command 1201 formats do share some common characteristics. These common 1202 characteristics will be discussed in this section. 1204 5.2.1. Common Prefix 1206 Each command includes a 4-byte prefix, referred to in this draft as the 1207 "common prefix" field. This prefix identifies the command, provides 1208 processing information, and specifies the length of the command. 1210 The format of the prefix is as follows: 1212 Byte Content 1214 0 Type indicator for this command. Possible values are: 1216 X'80' MPTN_Connect 1217 X'83' MPTN_DG_OOB_Data 1218 X'84' MPTN_DG_KEEPALIVE_Hdr 1220 1 Flag field that indicates whether this is a request or 1221 response, and also provides processing information. 1223 Bit Meaning 1225 0 When set to 1, indicates that this is a response. 1226 Otherwise, this is a request. 1228 1 Reserved in a request. When set to 1 in a response, 1229 indicates that this is a negative response. 1231 2 Reserved in a request and a positive response. When 1232 set to 1, indicates that the command was recognized 1233 by the destination but rejected. 1235 3 Reserved. 1237 4 When set to 1 in a request, indicates that a gateway 1238 must reject the command if it is unrecognized by 1239 sending a negative response to the originator. When 1240 set to 0 in a request, indicates that a gateway must 1241 forward the unrecognized command to the destination. 1243 The bit is forwarded without modification in a 1244 response. 1246 5 Reserved in a request. When set to 1 in a response, 1247 indicates that the gateway did not recognize this 1248 command. 1250 Bits 4 and 5 set to B'11' in a response indicate that 1251 the command failed because it was not recognized by 1252 the gateway. 1254 6 When set to 1 in a request, indicates that the 1255 destination must reject the command if it is 1256 unrecognized. When set to 0 in a request, indicates 1257 that the destination is to discard the unrecognized 1258 command. 1260 The bit is returned without modification in a 1261 response. 1263 7 Reserved in a request. When set to 1 in a response, 1264 indicates that the destination did not recognize this 1265 command. 1267 Bits 6 and 7 set to B'11' in a response indicate that 1268 the command failed because it was not recognized by 1269 the destination. 1271 2 to 3 Length, in binary, of this command. Includes the four 1272 bytes used for this common prefix. 1274 5.2.2. Optional Fields 1276 Each command may contain one or more optional fields. These optional 1277 fields are preceded by a 4-byte prefix. This prefix identifies which 1278 optional field this is, provides processing information, and specifies 1279 the length of the optional field. 1281 The format of this prefix is as follows: 1283 Byte Content 1285 0 Type indicator for this optional field. Possible values 1286 are: 1287 X'05' service mode 1288 X'0A' connection data 1289 X'18' user characteristics 1290 X'19' compensations required 1291 X'1A' optional compensations 1292 X'1C' node initialization ID 1293 X'28' sender connection alias 1294 X'29' receiver connection alias 1295 X'F0' diagnostics 1297 1 Processing specification for this optional field. 1299 Bit Meaning 1301 0 to 3 Reserved 1303 4 When set to 1 in a request, indicates that the 1304 gateway must reject the command if this optional 1305 field is unrecognized. Echoed in a response. 1307 5 Reserved in a request. When set to 1 in a 1308 response, indicates that a gateway did not 1309 recognize this optional field. 1311 Bits 4 and 5 set to B'11' in a response indicate 1312 that the command failed because this optional 1313 field was not recognized by a gateway. 1315 6 When set to 1 in a request, indicates that the 1316 destination must reject the command if this 1317 optional field is unrecognized by the destination. 1319 7 Reserved in a request. When set to 1 in a 1320 response, indicates that the destination did not 1321 recognize this optional field. 1323 Bits 6 and 7 set to B'11' in a response indicate 1324 that the command failed because this optional 1325 field was not recognized by the destination. 1327 2 to 3 Length, in binary, of this optional field. Includes the 1328 four bytes used for used for this optional field prefix. 1330 5.2.3. MPTN Addresses 1332 Addresses used in MPTN command have a common format. Each MPTN address 1333 consists of an MPTN qualifier, an address mode, a node address, and a 1334 local address. These subfields are described in the sections that 1335 follow: 1337 When an address used in an MPTN command is optional, it is preceded by 1338 the 4-byte prefix used for all optional fields, described in "Optional 1339 Fields". 1341 5.2.3.1. MPTN Qualifier 1343 An MPTN qualifier is a 1-byte hexadecimal code that identifies the 1344 "address family" to which the address belongs. For LU6.2 over TCP/IP, 1345 this value is always X'0B' which means that this address represents a 1346 SNA network-qualified LU name. In this case, all address values will be 1347 encoded in EBCDIC. 1349 5.2.3.2. Address Mode 1351 The address mode used in an MPTN address is a 1-byte hexadecimal code 1352 that identifies the type of addressing used. For LU6.2 over TCP/IP, the 1353 only possible value is 'X01' which represents an individual address. 1355 5.2.3.3. Node Address 1357 The node address in an MPTN address is the network address by which the 1358 node can be located. This address has a variable length, and therefore 1359 includes a 1-byte length field. Since a null node address is not 1360 permitted, the node address length will take values from 4 to 18 bytes 1361 for LU6.2 over TCP/IP because the node address corresponds to a 1362 network-qualified LU name. The format of the node address is: 1364 Byte Content 1366 0 Length (n + 1), in binary, of the node address 1368 1 to n Node address 1370 5.2.3.4. Local Address 1372 Local addresses are not used with LU6.2 over TCP/IP; therefore, this 1373 field will always have a value of X'01'. This value represents a null 1374 local address. 1376 5.2.4. Diagnostic Values 1378 Diagnostics can be sent on any negative response. When used, they 1379 provide information about the reason for the failure of the command. 1381 A negative response can include more than one Diagnostics field. The 1382 subfields of the Diagnostics field include a diagnostics prefix as 1383 described in the "Optional Fields" section, a primary return code, a 1384 secondary return code, an error detector address, and error detector 1385 data. 1387 5.2.4.1. Primary Return Code Values 1389 The primary return code describes the primary reason for the failure of 1390 the command. The format of this field is as follows: 1392 Byte Content 1394 0 Reserved 1396 1 1-byte hexadecimal code of the command type that was in 1397 error 1399 2 to 3 Primary return code. The following values are defined 1400 for this field: 1401 X'0001' Connection limits exceeded 1402 X'0002' User not found 1403 X'0003' User not reachable 1404 X'0006' Service mode not supported 1405 X'0007' Rejected by user 1406 X'0008' User not listening 1407 X'0009' Time to live counter expired 1408 X'0014' User characteristics mismatch 1409 X'0015' Compensation unrecognized 1410 X'0016' Compensation mismatch 1411 X'0017' Error in user data 1412 X'001E' Connection data unexpected 1413 X'001F' Connection data missing 1414 X'0020' Compensations required field missing 1415 X'0029' Error in destination address 1416 X'002A' Error in source address 1417 X'002B' Optional fields out of sequence 1418 X'002C' Error in correlator 1419 X'002D' Length error: field too long 1420 X'002E' Length error: field too short 1421 X'002F' Error in receiver connection alias 1422 X'0032' Format error 1423 X'0033' Invalid header in MPTN_DG_OOB_Data 1424 X'003C' Internal processing error 1426 Primary return codes X'0001', X'0002', X'0003', X'0020', X'0029', 1427 X'002A', X'002C', X'002D', X'002E', X'0032', and X'003C' provide 1428 additional diagnostic information through use of a secondary return 1429 code. Secondary return codes are described in the next section. 1431 5.2.4.2. Secondary Return Code Values 1433 Three alternative uses and formats are defined for this field. Format 1 1434 specifies an offset into the command where an error was detected. This 1435 value is given relative to the start of the common prefix field, 1436 assuming offset 0 for the first byte of that field. Format 2 describes 1437 the secondary reason for the failure, where the secondary return code is 1438 defined in the context of the primary return code. Format 3 identifies 1439 the optional field in error and the instance of the field if multiple 1440 instances are present in the request. 1442 Byte Content 1444 0 Format of the Secondary Return Code. The 1445 following values are defined for this field: 1446 X'00' Format 1 1447 X'80' Format 2 1448 X'C0' Format 3 1450 1 Reserved 1452 2 to 3 Dependent on format: 1454 Format 1: Offset to error in command. 1456 Format 2: For primary return code = X'0001': 1458 X'0001' Rejected by access node 1459 X'0002' Rejected by gateway 1461 For primary return code = X'0002': 1463 X'0005' Address unknown 1464 X'0006' Qualifier unknown 1466 For primary return code = X'0003': 1468 X'000A' Net ID unreachable 1469 X'000B' Node address unrecognized 1470 X'000C' Node unreachable 1472 For primary return code = X'0029' 1473 or X'002A' 1475 X'000E' Unrecognized MPTN 1476 qualifier 1477 X'000F' Unrecognized address mode 1478 X'0010' Invalid address mode 1479 X'0011' Missing node address 1480 X'0012' Node address too long 1481 X'0013' Invalid node address 1482 X'0014' Invalid MPTN qualifier 1483 X'0015' Node address too short 1484 X'0016' Host address unexpected 1486 For primary return code = X'002C' 1488 X'0018' Out of range 1489 X'0019' Duplicate 1491 For primary return code = X'0032' 1493 X'001B' Error in fixed field 1495 For primary return code = X'003C' 1497 X'001E' Temporary error 1498 X'001F' Permanent error 1500 Format 3: For primary return code = X'0020', 1501 X'002D', or X'002E': 1503 Byte Meaning 1505 0 Field identifier of the 1506 optional field in error. 1508 1 Index (starting from 0) 1509 of the instance of the 1510 field having the error. 1512 5.2.4.3. Error Detector Address 1514 The error detector address contains the address of the node that 1515 detected the failure. It is an MPTN address, and is therefore 1516 structured according to the description in "MPTN Addresses". In this 1517 usage, the local address subfield is always present, but may or may not 1518 include an address value. 1520 5.2.4.4. Error Detector Data 1522 The node that detects the failure is allowed to send up to 254 bytes of 1523 additional information related to the failure. The format of this field 1524 is as follows: 1526 Byte Content 1527 0 Length (n + 1), in binary, of the error detector data. 1529 1 to n Error data specified by the error detector. Format 1530 for this data is byte string. 1532 5.3. Command Formats 1534 5.3.1. MPTN_Connect 1536 An MPTN_Connect request is the first command sent over a TCP/IP 1537 connection in order to establish a LU6.2 session. An MPTN_Connect 1538 response acknowledges that request, and indicates whether or not the 1539 connection was accepted. Both positive and negative responses are 1540 defined for the MPTN_Connect. The format of the command as it relates 1541 running LU6.2 applications over TCP/IP is as follows: 1543 Field Name Size Range Contents 1544 (in bytes) 1546 Record Length 4 Specifies the overall length of 1547 the command, including the four 1548 bytes used for its own 1549 specification. 1551 Command Type 1 X'80' 1553 Processing 1 Bits 4 and 6 MUST be set to 1, 1554 Specification indicating that the message 1555 must be recognized by both a 1556 gateway and the destination. The 1557 remaining bits in this field are 1558 set as described in the "Common 1559 Prefix" section. 1561 Command Length 4 The size of this command minus 1562 the four byte record length field. 1564 Time To Live 1 Used to prevent commands from 1565 circulating endlessly. When a 1566 command arrives with a value of 1, 1567 the command is either at its 1568 destination or, if not, will be 1569 rejected and returned to the 1570 initiator of the connection as a 1571 negative response. 1573 Destination 5 to 512 Specifies the target address of 1574 Address the connection. This is the 1575 receiver of the MPTN_Connect 1576 request, and the sender of an 1577 MPTN_Connect response. This 1578 field is described in section 1579 "MPTN Addresses". 1581 Source 5 to 512 Specifies the source address of 1582 Address the connection. This is the 1583 sender of the MPTN_Connect 1584 request, and the receiver of an 1585 MPTN_Connect response. This 1586 field is described in section 1587 "MPTN Addresses". 1589 Correlator Suffix 2 to 9 Used to correlate a request with 1590 its response. The source address, 1591 taken together with the correlator 1592 suffix, uniquely identifies the 1593 MPTN connection for all time. 1594 Byte 0 is the length(n + 1), in 1595 binary, of the correlator suffix 1596 value. Bytes 1 to n represent 1597 the actual value. 1599 User Transport This section is composed of the 1600 Requirements six fields listed next. 1602 User Transport 1 Length field for the user transport 1603 Requirements requirements. If the value in this 1604 Length field is greater than 15 (the length 1605 of the currently-defined subfields), 1606 all data beyond the first 15 bytes 1607 is ignored. 1609 Maximum Record 4 Maximum size for a record that can be 1610 Length sent on this connection. 1612 Maximum Expedited 4 Maximum size for an expedited data 1613 Data Length record that can be sent on this 1614 connection. 1616 Maximum 4 Maximum size for termination data that 1617 Termination Data can be sent on this connection. 1618 Length 1620 Termination Type 1 For LU6.2 over TCP/IP, this value is 1621 always X'20' - Duplex Abortive 1623 Expedited Marking 1 For LU6.2 over TCP/IP, this value is 1624 always X'00' which specifies that the 1625 LU6.2 application does not need to 1626 mark the position in the normal data 1627 where expedited data was sent. 1629 5.3.1.1. MPTN_Connect Optional Fields 1631 The following fields are "MPTN Optional" fields that are required to run 1632 LU6.2 applications over TCP/IP. A description of each field is given 1633 and, if necessary, a format of subfields associated with the "MPTN 1634 Optional" field. 1636 5.3.1.1.1. Service Mode 1638 Specification of the level of transport service required in each 1639 transport network. Consists of the subfields Service Mode Prefix, MPTN 1640 Service Mode, and User-Defined Service Mode. The field is present when 1641 the sender requires a specific level of service. 1643 Service Mode Prefix is an Optional Field prefix, as described in Section 1644 5.2.2 "Optional Fields". The type indicator (byte 0) is set to X'05'. 1645 Bits 4 and 6 of the processing specification (byte 1) are set to 1 and 1646 0, respectively. This indicates that a negative response is required if 1647 the field is unrecognized by the destination. The remaining bits in the 1648 processing specification are set as described in Section 5.2.2 "Optional 1649 Fields". 1651 MPTN Service Mode is a predefined service mode required by the user. 1652 The field is 1-byte in length with the following possible values: 1654 X'00' Only user-defined service-mode is specified. No MPTN- 1655 defined service mode will be used as a default. 1656 X'01' No specific service mode is required. 1657 X'02' High bandwidth is required. 1658 X'03' Fast response time is required. 1659 X'04' Secure service with high bandwidth is required. 1660 X'05' Secure service with fast response time is required. 1662 For LU6.2 over TCP/IP, the service mode maps to the SNA class of service 1663 in the following way: 1665 SNA Class of Service MPTN Service Mode 1666 CONNECT X'01' 1667 BATCH X'02' 1668 INTER X'03' 1669 BATCHSC X'04' 1670 INTERSC X'05' 1671 SNASVCMG X'01' 1672 CPSVCMG X'01' 1674 Note that at the time this draft was written, there were no known 1675 implementations of the secure modes, X'04' and X'05'. General security 1676 for TCP/IP is being defined by the IETF. 1678 The User-Defined Service Mode identifies the service mode required by 1679 the transport user. When this field is supported by a gateway, then 1680 this value takes precedence over the value specified in MPTN Service 1681 Mode. The format of this field is as follows: 1683 Byte Content 1685 0 Length (n + 1), in binary, of the user-defined service 1686 mode 1688 1 to n User-defined service mode (when present). Format is 1689 ASCII character string. 1691 5.3.1.1.2. Connection Data 1693 In a request, this field contains the BIND RU. In a positive response, 1694 this field contains a positive BIND_RSP. In a negative response, this 1695 field contains data related to the connection failure if any was 1696 specified; however, if any Diagnostics optional field except X'0007', 1697 Rejected by User, is present, this field echoes back the data sent on 1698 the MPTN_Connect request. Consists of the subfields Connection Data 1699 Prefix and Connection Data Value. Always present for LU6.2 over TCP/IP. 1701 The Connection Data Prefix is an Optional Field prefix, as described in 1702 Section 5.2.2 "Optional Fields". The type indicator (byte 0) is set to 1703 X'0A'. Bits 4 and 6 of the processing specification Byte 1) are set to 1704 0 and 1, respectively. This indicates that a negative response is not 1705 required if the field is unrecognized by a gateway, but it is required 1706 if the field is unrecognized by the destination. The remaining bits in 1707 the processing specification are set as described in Section 5.2.2 1708 "Optional Fields". 1710 The Connection Data Value field contains the connection data specified 1711 by the user. 1713 5.3.1.1.3. User Characteristics 1715 Specifies the user characteristics for which support is requested on 1716 this connection. When more than one user characteristic is required, 1717 the user characteristic identifiers can be specified in any order. The 1718 contents of this field are not changed by a gateway. This field 1719 consists of the subfields User Characteristics Prefix and User 1720 Characteristics Value. The field is present when specific user 1721 characteristics are requested. 1723 User Characteristics Prefix is an Optional Field prefix, as described in 1724 Section 5.2.2, "Optional Fields". The type indicator (byte 0) is set to 1725 X'18'. Bits 4 and 6 of the processing specification (byte 1) are both 1726 set to to 0, indicating that a negative response is not required if the 1727 field is unrecognized either by a gateway or by the destination. The 1728 remaining bits in the processing specification are set as described in 1729 Section 5.2.2, "Optional Fields". 1731 User Characteristics Value is a list of user characteristic values 1732 representing the user characteristics to be used on this connection. 1733 The list consists of 1-byte unsigned binary values. The number of 1734 elements in the list is determined by subtracting 4 from the value 1735 stored in the length subfield (bytes 2 and 3) of the User 1736 Characteristics Prefix field. The value that can appear in this field 1737 for LU6.2 over TCP/IP is: 1739 X'01' Session Outage Notification (SON) 1741 If the User Characteristics field is understood by the destination but a 1742 certain value is not supported then that value should be set to X'00' in 1743 the response. 1745 5.3.1.1.4. Compensations Required 1747 Specifies the compensations that will be used on this connection. When 1748 more than one compensation is required, the compensation identifiers can 1749 be specified in any order. The contents of this field can change at 1750 every gateway. This field consists of the subfields Compensations 1751 Prefix and Compensations Value. The fix is present when compensations 1752 are required. 1754 The Compensations Prefix is an Optional Field prefix, as described in 1755 Section 5.2.2, "Optional Fields". The type indicator (byte 0) is set to 1756 X'19'. Bits 4 and 6 of the processing specification (byte 1) are both 1757 set to 1, indicating that a negative response is required if the field 1758 is unrecognized either by a gateway or by the destination. The 1759 remaining bits in the processing specification are set as described in 1760 Section 5.2.2, "Optional Fields". 1762 The Compensations Value field is a list of MPTN headers and command 1763 identifier values representing the compensations to be used on this MPTN 1764 segment. This field is a list of 1-byte unsigned binary values. The 1765 number of elements in the list is determined by subtracting 4 from the 1766 value stored in the length subfield (bytes 2 and 3) of the Compensations 1767 Prefix field. For LU6.2 over TCP/IP, the compensations required 1768 include: 1770 X'00' Record boundary marker 1771 X'01' Expedited message 1772 X'03' Expedited message acknowledgement 1773 X'10' Duplex-abortive termination 1774 X'20' Segmented Message 1775 X'83' MPTN_DG_OOB_Data message needed for expedited data 1777 5.3.1.1.5. Optional Compensations 1779 Specifies the optional compensations that are requested on this 1780 connection. When more than one optional compensation is specified, the 1781 compensation identifiers can be specified in any order. The contents of 1782 this field can change at every gateway. This field consists of the 1783 subfields Optional Compensations Prefix and Optional Compensations 1784 Value. This field is present when optional compensations are requested. 1786 The Optional Compensations Prefix field is an Optional Field prefix, as 1787 described in Section 5.2.2, "Optional Fields". The type indicator (byte 1788 0) is set to X'1A'. Bits 4 and 6 of the processing specification (byte 1789 1) are both set to 0, indicating that a negative response is not 1790 required if the field is unrecognized either by a gateway or by the 1791 destination. The remaining bits in the processing specification are set 1792 as described in Section 5.2.2, "Optional Fields". 1794 The Optional Compensations Value field is a list of MPTN headers and 1795 command identifier values representing the optional compensations to be 1796 used on this MPTN segment. This field is a list of 1-byte unsigned 1797 binary values. The number of elements in the list is determined by 1798 subtracting 4 from the value stored in the length subfield (bytes 2 and 1799 3) of the Optional Compensations Prefix field. For LU6.2 over TCP/IP, 1800 the optional compensations include: 1802 X'84' MPTN_DG_KEEPALIVE_Hdr message needed for session outage 1803 notification 1805 If the Optional Compensations field is understood by the destination but 1806 a certain value is not supported then that value should be set to X'00' 1807 in the response. 1809 5.3.1.1.6. Node Initialization ID 1811 This field represents a value that uniquely identifies the instance of 1812 the sending node, e.g., a time corresponding to when the node was 1813 initialized. This field consists of a Node Initialization ID Prefix, 1814 and Node Initialization ID Value. This field is optional and used when 1815 there is a danger that a node may be terminated and reinitialized in 1816 less time than the keepalive process will detect. 1818 The Node Initialization ID Prefix is an Optional Field prefix, as 1819 described in Section 5.2.2, "Optional Fields". The type indicator (byte 1820 0) is set to X'1C'. Bits 4 and 6 of the processing specification are 1821 both set to 0, indicating that a negative response is not required if 1822 the field is unrecognized either by a gateway or by the destination. 1823 The remaining bits in the processing specification are set as described 1824 in Section 5.2.2, "Optional Fields". 1826 The Node Initialization ID Value field specifies the node initialization 1827 ID, e.g., a time stamp. The field may be from 2 to 8 bytes in length. 1828 sp 1830 5.3.1.1.7. Diagnostics 1832 This field is only allowed on negative MPTN_Connect responses. For a 1833 description, please refer to Section 5.2.4, "Diagnostic Values". 1835 5.3.2. MPTN_Hdr 1837 MPTH headers are 1-byte fields that are inserted before the user's data 1838 on an MPTN connection. The field specifies which compensation, if any, 1839 is in use. The possible identifiers required for running LU6.2 1840 applications over TCP/IP include: 1842 X'00' Record boundary marker 1843 X'01' Expedited message 1844 X'03' Expedited message acknowledgement 1845 X'10' Duplex-abortive termination 1846 X'20' Segmented message 1848 User data may follow the MPTN header. When user data follows MPTN 1849 header X'10', then that data is an UNBIND specified by the transport 1850 user. User data is present when the transport user sends data 1851 associated with the MPTN header. The user data field is not required 1852 for some compensations, such as the various termination compensations 1853 when they are used without user termination data and acknowledgements. 1855 For LU6.2 over TCPI/IP, the MPTN header will be preceded by a 4-byte 1856 record length that specifies the overall length of the message including 1857 the four bytes used for its own specification. 1859 5.3.3. MPTN_DG_OOB_Data 1861 The MPTN_DG_OOB_Data is a command defined for sending data on a separate 1862 path from the connection ("out of band"), to ensure that it reaches the 1863 partner. This is command can be used, for example, to insure that SNA 1864 expedited data reaches the target node. The format of the command as it 1865 relates to running LU6.2 applications over TCP/IP is as follows: 1867 Field Name Size Range Contents 1868 (in bytes) 1870 Record Length 4 Specifies the overall length of 1871 the command, including the four 1872 bytes used for its own 1873 specification. 1875 Command Type 1 X'83' 1877 Processing 1 Bits 4 and 6 MUST be set to 0 and 1, 1878 Specification respectively. This indicates that 1879 a negative response is not required 1880 if the message is unrecognized by a 1881 gateway, but it is required if the 1882 message is unrecognized by the 1883 destination. The remaining bits in 1884 in this field are set as described in 1885 Section 5.2.1, "Common Prefix". 1887 Command Length 4 Represents the size of this entire 1888 message. It includes the four bytes 1889 used for the Common Prefix, but does 1890 not include the four bytes for the 1891 Record Length field, the size of the 1892 MPTN Header, or the size of the User 1893 Data. 1895 Connection Sequence number used to correlate this 1896 Sequence Number 2 datagram with activity on a specific 1897 connection. 1899 Correlator Address 5 to 512 Specifies the address of the user that 1900 initiated the connection that the 1901 out-of-band data relates to. This 1902 field is described in Section 5.2.3, 1903 "MPTN Addresses". 1905 Correlator Suffix 2 to 9 Used with the Correlator Address field 1906 to correlate this out-of-band data to 1907 its connection. (This is the same 1908 value that was sent in the 1909 MPTN_Connect command for the 1910 connection.) Byte 0 is the length 1911 (n + 1), in binary of the correlator 1912 suffix value. Bytes 1 to n represent 1913 the actual value. 1915 Sender Connection 9 to 516 Specifies a connection alias that, when 1916 Alias used in the acknowledgement, will 1917 enable the sender to quickly identify 1918 the associated connection. Consists of 1919 the following subfields: Sender Alias 1920 Prefix, Sender Alias MPTN Qualifier, 1921 Sender Alias Address Mode, Sender Alias 1922 Node Address, and Sender Alias Local 1923 Address. Sender Alias Prefix is an 1924 Optional Field prefix, as described in 1925 Section 5.2.2, "Optional Fields". The 1926 type indicator (byte 0) is set to 1927 X'28'. Bits 4 and 6 of the processing 1928 specification (byte 1) are both set to 1929 0. This indicates that a negative 1930 response is not required if the field 1931 is unrecognized by a gateway or by the 1932 destination. The remaining bits in the 1933 processing specifications are set as 1934 described in Section 5.2.2, "Optional 1935 Fields". The remaining subfields are 1936 described in Section 5.2.3, "MPTN 1937 Addresses". Note that the Sender Alias 1938 MPTN Qualifier must be set to X'7F' 1939 and the Sender Alias Address Mode must 1940 be set to the value X'01'. 1942 This field is present when the sender 1943 (of a request or response) wants to 1944 communicate a local form address to the 1945 destination and is not required. 1947 Receiver 9 to 516 Specifies a connection alias that 1948 Connection Alias enables the receiver to quickly 1949 identify the connection for which this 1950 out-of-band data was sent. This is the 1951 connection alias that the sender 1952 received earlier from the partner. 1953 Consists of the following subfields: 1954 Receiver Alias Prefix, Receiver Alias 1955 MPTN Qualifier, Receiver Alias Address 1956 Mode, Receiver Alias Node Address, and 1957 Receiver Alias Local Address. Receiver 1958 Alias Prefix is an Optional Field 1959 prefix as described in Section 5.2.2, 1960 "Optional Fields". The type indicator 1961 (byte 0) is set to X'29'. Bits 4 and 6 1962 of the processing specification (byte 1963 1) are both set to 0. This indicates 1964 that a negative response is not 1965 required if the field is unrecognized 1966 by a gateway or by the destination. 1967 The remaining bits in the processing 1968 specification are set as described in 1969 Section 5.2.2, "Optional Fields". The 1970 remaining subfields are described in 1971 Section 5.2.3, "MPTN Addresses". Note 1972 that the Receiver Alias MPTN Qualifier 1973 MUST be set to X'7F' and the Receiver 1974 Alias Address Mode MUST be set to the 1975 value X'01'. 1977 This field is present when the sender 1978 has previously received a sender 1979 connection alias from the partner. 1981 Maximum Datagram 4 This is an Optional Field prefix as 1982 Common Prefix described in Section 5.2.2, "Optional 1983 Fields". The type indicator (byte 0) 1984 is set to X'2E'. Bits 4 and 6 of the 1985 processing specification (byte 1) are 1986 both set to 0. The remaining bits in 1987 the processing specification are set 1988 as described in Section 5.2.2, 1989 "Optional Fields". 1991 This field is present when TCP/IP 1992 stack can receive a datagram bigger 1993 than the largest datagram 1994 guaranteed to be receivable by TCP/IP. 1996 Maximum Datagram 4 This field represents the maximum 1997 Value datagram receive size supported by the 1998 sending TCP/IP stack. This field is 1999 only present when the Maximum Datagram 2000 Common Prefix is present. The value 2001 is expressed in a binary form and is 2002 limited to 4 bytes in length. 2004 Diagnostics 18 to 779 This field is only allowed on negative 2005 MPTN_DG_OOB_Data responses. For a 2006 description, please refer to Section 2007 5.2.4, "Diagnostic Values". 2009 MPTN Header 1 Indicates the compensations associated 2010 with this command. This field MUST be 2011 in a request and MUST NOT be in a 2012 response. The values are expressed in 2013 a hexadecimal format. The following 2014 values are allowed: 2015 X'01' user expedited data 2016 X'10' duplex-abortive termination 2018 User Data 0 to Contains the transport user's data. If 2019 (2 32 - 32) MPTN Header is X'01', then this is user 2020 expedited data. If MPTN header is 2021 X'10', then this is termination data 2022 specified by the transport user. This 2023 field may be present in a request 2024 depending on the MPTN Header. This 2025 field MUST NOT be present in a 2026 response. 2028 5.3.4. MPTN_DG_KEEPALIVE_Hdr 2030 The MPTN_DG_KEEPALIVE_Hdr is a command defined for detecting session 2031 outage notification in a timely manner. 2033 Field Name Size Range Contents 2034 (in bytes) 2036 Record Length 4 Specifies the overall length of 2037 the command, including the four 2038 bytes used for its own 2039 specification. 2041 Command Type 1 X'84' 2042 Processing 1 Bits 4 and 6 are both set to 0, 2043 Specification indicating that no negative 2044 response is required if the command 2045 is unrecognized by a gateway or the 2046 destination. The remaining bits in 2047 the processing specification are set 2048 as described in Section 5.2.2, 2049 "Optional Fields". 2051 Command Length 2 This value represents the size of this 2052 entire command excluding the four byte 2053 record length field. 2055 Source Address 5 to 512 Specifies the provider address of the 2056 sender of the keepalive command. This 2057 is the sender of an 2058 MPTN_DG_KEEPALIVE_Hdr request, and the 2059 receiver of the MPTN_DG_KEEPALIVE_Hdr 2060 response. The contents of this field 2061 are described in Section 5.2.3, 2062 "MPTN Addresses". 2064 Destination 5 to 512 Specifies the provider address of the 2065 Address receiver of the keepalive command. 2066 This is the receiver of an 2067 MPTN_DG_KEEPALIVE_Hdr request, and the 2068 sender of the MPTN_DG_KEEPALIVE_Hdr 2069 response. The contents of this field 2070 are described in Section 5.2.3, 2071 "MPTN Addresses". 2073 Diagnostics 18 to 779 This field is only allowed on negative 2074 MPTN_DG_OOB_Data responses. For a 2075 description, please refer to Section 2076 5.2.4, "Diagnostic Values". 2078 SECURITY 2080 This draft does not attempt to address the issue of security. This 2081 draft does not affect any existing level of SNA security that exists 2082 today. 2084 REFERENCES 2086 [1] X/OPEN CAE Specification, Multiprotocol Transport Networking 2087 (XMPTN): Access Node (ISBN: 1-85912-106-3, P521) 2089 [2] X/OPEN CAE Specification, Multiprotocol Transport Networking 2090 (XMPTN): Data Formats (ISBN: 1-85912-111-X, C522) 2092 [3] Multiprotocol Transport Networking (MPTN) Architecture: Technical 2093 Overview, IBM Document #GC31-7073. 2095 AUTHORS' ADDRESSES 2097 James Carmichael Soumitra (Ronnie) Sarkar 2098 IBM Corporation IBM Corporation 2099 P.O. Box 12195 P.O. Box 12195 2100 Research Triangle Park, NC 27709 Research Triangle Park, NC 27709 2101 USA USA 2103 phone: +1 919-254-5798 phone: +1 919-254-6461 2104 email: carmich@us.ibm.com email: sarkar@us.ibm.com 2106