|
|
1.1 ! root 1: ! 2: ! 3: ! 4: Network Working Group Marshall T. Rose, Dwight E. Cass ! 5: Request for Comments: RFC 1006 Northrop Research and Technology Center ! 6: May 1987 ! 7: ! 8: ! 9: ! 10: ISO Transport Service on top of the TCP ! 11: Version: 3 ! 12: ! 13: ! 14: Status of this Memo ! 15: ! 16: This memo specifies a standard for the Internet community. Hosts ! 17: on the Internet that choose to implement ISO transport services ! 18: on top of the TCP are expected to adopt and implement this ! 19: standard. TCP port 102 is reserved for hosts which implement this ! 20: standard. Distribution of this memo is unlimited. ! 21: ! 22: This memo specifies version 3 of the protocol and supersedes ! 23: [RFC983]. Changes between the protocol as described in Request for ! 24: Comments 983 and this memo are minor, but are unfortunately ! 25: incompatible. ! 26: ! 27: ! 28: ! 29: ! 30: ! 31: ! 32: ! 33: ! 34: ! 35: ! 36: ! 37: ! 38: ! 39: ! 40: ! 41: ! 42: ! 43: ! 44: ! 45: ! 46: ! 47: ! 48: ! 49: ! 50: ! 51: ! 52: ! 53: ! 54: ! 55: ! 56: ! 57: ! 58: M. Rose & D. Cass [Page 1] ! 59: ! 60: RFC 1006 May 1987 ! 61: ! 62: ! 63: 1. Introduction and Philosophy ! 64: ! 65: ! 66: The Internet community has a well-developed, mature set of ! 67: transport and internetwork protocols (TCP/IP), which are quite ! 68: successful in offering network and transport services to ! 69: end-users. The CCITT and the ISO have defined various session, ! 70: presentation, and application recommendations which have been ! 71: adopted by the international community and numerous vendors. ! 72: To the largest extent possible, it is desirable to offer these ! 73: higher level directly in the ARPA Internet, without disrupting ! 74: existing facilities. This permits users to develop expertise ! 75: with ISO and CITT applications which previously were not ! 76: available in the ARPA Internet. It also permits a more ! 77: graceful convergence and transition strategy from ! 78: TCP/IP-based networks to ISO-based networks in the ! 79: medium-and long-term. ! 80: ! 81: There are two basic approaches which can be taken when "porting" ! 82: an ISO or CCITT application to a TCP/IP environment. One ! 83: approach is to port each individual application separately, ! 84: developing local protocols on top of the TCP. Although this is ! 85: useful in the short-term (since special-purpose interfaces to the ! 86: TCP can be developed quickly), it lacks generality. ! 87: ! 88: A second approach is based on the observation that both the ARPA ! 89: Internet protocol suite and the ISO protocol suite are both ! 90: layered systems (though the former uses layering from a more ! 91: pragmatic perspective). A key aspect of the layering principle ! 92: is that of layer-independence. Although this section is ! 93: redundant for most readers, a slight bit of background material ! 94: is necessary to introduce this concept. ! 95: ! 96: Externally, a layer is defined by two definitions: ! 97: ! 98: a service-offered definition, which describes the services ! 99: provided by the layer and the interfaces it provides to ! 100: access those services; and, ! 101: ! 102: a service-required definitions, which describes the services ! 103: used by the layer and the interfaces it uses to access those ! 104: services. ! 105: ! 106: Collectively, all of the entities in the network which co-operate ! 107: to provide the service are known as the service-provider. ! 108: Individually, each of these entities is known as a service-peer. ! 109: ! 110: Interally, a layer is defined by one definition: ! 111: ! 112: a protocol definition, which describes the rules which each ! 113: service-peer uses when communicating with other service-peers. ! 114: ! 115: ! 116: ! 117: M. Rose & D. Cass [Page 2] ! 118: ! 119: RFC 1006 May 1987 ! 120: ! 121: ! 122: Putting all this together, the service-provider uses the protocol ! 123: and services from the layer below to offer the its service to the ! 124: layer above. Protocol verification, for instance, deals with ! 125: proving that this in fact happens (and is also a fertile field ! 126: for many Ph.D. dissertations in computer science). ! 127: ! 128: The concept of layer-independence quite simply is: ! 129: ! 130: IF one preserves the services offered by the service-provider ! 131: ! 132: THEN the service-user is completely naive with respect to the ! 133: protocol which the service-peers use ! 134: ! 135: ! 136: For the purposes of this memo, we will use the layer-independence ! 137: to define a Transport Service Access Point (TSAP) which appears ! 138: to be identical to the services and interfaces offered by the ! 139: ISO/CCITT TSAP (as defined in [ISO8072]), but we will in fact ! 140: implement theISO TP0 protocol on top of TCP/IP (as defined in ! 141: [RFC793,RFC791]), not on top of the the ISO/CCITT network ! 142: protocol. Since the transport class 0 protocol is used over the ! 143: TCP/IP connection, it achieves identical functionality as ! 144: transport class 4. Hence, ISO/CCITT higher level layers (all ! 145: session, presentation, and application entities) can operate ! 146: fully without knowledge of the fact that they are running on a ! 147: TCP/IP internetwork. ! 148: ! 149: ! 150: ! 151: ! 152: ! 153: ! 154: ! 155: ! 156: ! 157: ! 158: ! 159: ! 160: ! 161: ! 162: ! 163: ! 164: ! 165: ! 166: ! 167: ! 168: ! 169: ! 170: ! 171: ! 172: ! 173: ! 174: ! 175: ! 176: M. Rose & D. Cass [Page 3] ! 177: ! 178: RFC 1006 May 1987 ! 179: ! 180: ! 181: 2. Motivation ! 182: ! 183: ! 184: In migrating from the use of TCP/IP to the ISO protocols, there ! 185: are several strategies that one might undertake. This memo was ! 186: written with one particular strategy in mind. ! 187: ! 188: The particular migration strategy which this memo uses is based ! 189: on the notion of gatewaying between the TCP/IP and ISO ptotocol ! 190: suites at the transport layer. There are two strong arguments ! 191: for this approach: ! 192: ! 193: 1. Experience teaches us that it takes just as long to get good ! 194: implementations of the lower level protocols as it takes to get ! 195: implementations of the higher level ones. In particular, it has ! 196: been observed that there is still a lot of work being done at the ! 197: ISO network and transport layers. As a result, implementations ! 198: of protocols above these layers are not being aggressively ! 199: pursued. Thus, something must be done "now" to provide a medium ! 200: in which the higher level protocols can be developed. Since ! 201: TCP/IP is mature, and essentially provides identical ! 202: functionality, it is an ideal medium to support this development. ! 203: ! 204: 2. Implementation of gateways at the IP and ISO IP layers are ! 205: probably not of general use in the long term. In effect, this ! 206: would require each Internet host to support both TP4 and TCP. ! 207: As such, a better strategy is to implement a graceful migration ! 208: path from TCP/IP to ISO protocols for the ARPA Internet when the ! 209: ISO protocols have matured sufficiently. ! 210: ! 211: Both of these arguments indicate that gatewaying should occur at ! 212: or above the transport layer service access point. Further, the ! 213: first argument suggests that the best approach is to perform the ! 214: gatewaying exactly AT the transport service access point to ! 215: maximize the number of ISO layers which can be developed. ! 216: ! 217: NOTE: This memo does not intend to act as a migration or ! 218: intercept document. It is intended ONLY to meet the ! 219: needs discussed above. However, it would not be ! 220: unexpected that the protocol described in this memo ! 221: might form part of an overall transition plan. The ! 222: description of such a plan however is COMPLETELY ! 223: beyond the scope of this memo. ! 224: ! 225: Finally, in general, building gateways between other layers in the ! 226: TCP/IP and ISO protocol suites is problematic, at best. ! 227: ! 228: To summarize: the primary motivation for the standard described in ! 229: this memo is to facilitate the process of gaining experience with ! 230: higher-level ISO protocols (session, presentation, and ! 231: application). The stability and maturity of TCP/IP are ideal for ! 232: ! 233: ! 234: ! 235: M. Rose & D. Cass [Page 4] ! 236: ! 237: RFC 1006 May 1987 ! 238: ! 239: ! 240: providing solid transport services independent of actual ! 241: implementation. ! 242: ! 243: ! 244: ! 245: ! 246: ! 247: ! 248: ! 249: ! 250: ! 251: ! 252: ! 253: ! 254: ! 255: ! 256: ! 257: ! 258: ! 259: ! 260: ! 261: ! 262: ! 263: ! 264: ! 265: ! 266: ! 267: ! 268: ! 269: ! 270: ! 271: ! 272: ! 273: ! 274: ! 275: ! 276: ! 277: ! 278: ! 279: ! 280: ! 281: ! 282: ! 283: ! 284: ! 285: ! 286: ! 287: ! 288: ! 289: ! 290: ! 291: ! 292: ! 293: ! 294: M. Rose & D. Cass [Page 5] ! 295: ! 296: RFC 1006 May 1987 ! 297: ! 298: ! 299: 3. The Model ! 300: ! 301: ! 302: The [ISO8072] standard describes the ISO transport service ! 303: definition, henceforth called TP. ! 304: ! 305: ASIDE: This memo references the ISO specifications rather ! 306: than the CCITT recommendations. The differences ! 307: between these parallel standards are quite small, ! 308: and can be ignored, with respect to this memo, ! 309: without loss of generality. To provide the reader ! 310: with the relationships: ! 311: ! 312: Transport service [ISO8072] [X.214] ! 313: Transport protocol [ISO8073] [X.224] ! 314: Session protocol [ISO8327] [X.225] ! 315: ! 316: ! 317: The ISO transport service definition describes the services ! 318: offered by the TS-provider (transport service) and the interfaces ! 319: used to access those services. This memo focuses on how the ARPA ! 320: Transmission Control Protocol (TCP) [RFC793] can be used to offer ! 321: the services and provide the interfaces. ! 322: ! 323: ! 324: +-----------+ +-----------+ ! 325: | TS-user | | TS-user | ! 326: +-----------+ +-----------+ ! 327: | | ! 328: | TSAP interface TSAP interface | ! 329: | [ISO8072] | ! 330: | | ! 331: +----------+ ISO Transport Services on the TCP +----------+ ! 332: | client |-----------------------------------------| server | ! 333: +----------+ (this memo) +----------+ ! 334: | | ! 335: | TCP interface TCP interface | ! 336: | [RFC793] | ! 337: | | ! 338: ! 339: ! 340: For expository purposes, the following abbreviations are used: ! 341: ! 342: TS-peer a process which implements the protocol described ! 343: by this memo ! 344: ! 345: TS-user a process talking using the services of a TS-peer ! 346: ! 347: ! 348: ! 349: ! 350: ! 351: ! 352: ! 353: M. Rose & D. Cass [Page 6] ! 354: ! 355: RFC 1006 May 1987 ! 356: ! 357: ! 358: TS-provider the black-box entity implementing the protocol ! 359: described by this memo ! 360: ! 361: ! 362: For the purposes of this memo, which describes version 2 of the ! 363: TSAP protocol, all aspects of [ISO8072] are supported with one ! 364: exception: ! 365: ! 366: Quality of Service parameters ! 367: ! 368: ! 369: In the spirit of CCITT, this is left "for further study". A ! 370: future version of the protocol will most likely support the QOS ! 371: parameters for TP by mapping these onto various TCP parameters. ! 372: ! 373: The ISO standards do not specify the format of a session port ! 374: (termed a TSAP ID). This memo mandates the use of the GOSIP ! 375: specification [GOSIP86] for the interpretation of this field. ! 376: (Please refer to Section 5.2, entitled "UPPER LAYERS ADDRESSING".) ! 377: ! 378: Finally, the ISO TSAP is fundamentally symmetric in behavior. ! 379: There is no underlying client/server model. Instead of a server ! 380: listening on a well-known port, when a connection is established, ! 381: the TS-provider generates an INDICATION event which, presumably ! 382: the TS-user catches and acts upon. Although this might be ! 383: implemented by having a server "listen" by hanging on the ! 384: INDICATION event, from the perspective of the ISO TSAP, all TS- ! 385: users just sit around in the IDLE state until they either generate ! 386: a REQUEST or accept an INDICATION. ! 387: ! 388: ! 389: ! 390: ! 391: ! 392: ! 393: ! 394: ! 395: ! 396: ! 397: ! 398: ! 399: ! 400: ! 401: ! 402: ! 403: ! 404: ! 405: ! 406: ! 407: ! 408: ! 409: ! 410: ! 411: ! 412: M. Rose & D. Cass [Page 7] ! 413: ! 414: RFC 1006 May 1987 ! 415: ! 416: ! 417: 4. The Primitives ! 418: ! 419: ! 420: The protocol assumes that the TCP[RFC793] offers the following ! 421: service primitives: ! 422: ! 423: Events ! 424: ! 425: connected - open succeeded (either ACTIVE or PASSIVE) ! 426: ! 427: connect fails - ACTIVE open failed ! 428: ! 429: data ready - data can be read from the connection ! 430: ! 431: errored - the connection has errored and is now closed ! 432: ! 433: closed - an orderly disconnection has started ! 434: ! 435: Actions ! 436: ! 437: listen on port - PASSIVE open on the given port ! 438: ! 439: open port - ACTIVE open to the given port ! 440: ! 441: read data - data is read from the connection ! 442: ! 443: send data - data is sent on the connection ! 444: ! 445: close - the connection is closed (pending data is ! 446: sent) ! 447: ! 448: ! 449: This memo describes how to use these services to emulate the following ! 450: service primitives, which are required by [ISO8073]: ! 451: ! 452: Events ! 453: ! 454: N-CONNECT.INDICATION ! 455: - An NS-user (responder) is notified that ! 456: connection establishment is in progress ! 457: ! 458: ! 459: N-CONNECT.CONFIRMATION ! 460: - An NS-user (responder) is notified that ! 461: the connection has been established ! 462: ! 463: N-DATA.INDICATION ! 464: - An NS-user is notified that data can be ! 465: read from the connection ! 466: ! 467: ! 468: ! 469: ! 470: ! 471: M. Rose & D. Cass [Page 8] ! 472: ! 473: RFC 1006 May 1987 ! 474: ! 475: ! 476: N-DISCONNECT.INDICATION ! 477: - An NS-user is notified that the connection ! 478: is closed ! 479: ! 480: Actions ! 481: ! 482: N-CONNECT.REQUEST ! 483: - An NS-user (initiator) indicates that it ! 484: wants to establish a connection ! 485: ! 486: N-CONNECT.RESPONSE ! 487: - An NS-user (responder) indicates that it ! 488: will honor the request ! 489: ! 490: N-DATA.REQUEST - An NS-user sends data ! 491: ! 492: N-DISCONNECT.REQUEST ! 493: - An NS-user indicates that the connection ! 494: is to be closed ! 495: ! 496: The protocol offers the following service primitives, as defined ! 497: in [ISO8072], to the TS-user: ! 498: ! 499: Events ! 500: ! 501: T-CONNECT.INDICATION ! 502: - a TS-user (responder) is notified that ! 503: connection establishment is in progress ! 504: ! 505: T-CONNECT.CONFIRMATION ! 506: - a TS-user (initiator) is notified that the ! 507: connection has been established ! 508: ! 509: T-DATA.INDICATION ! 510: - a TS-user is notified that data can be read ! 511: from the connection ! 512: ! 513: T-EXPEDITED DATA.INDICATION ! 514: - a TS-user is notified that "expedited" data ! 515: can be read from the connection ! 516: ! 517: T-DISCONNECT.INDICATION ! 518: - a TS-user is notified that the connection ! 519: is closed ! 520: ! 521: ! 522: ! 523: ! 524: ! 525: ! 526: ! 527: ! 528: ! 529: ! 530: M. Rose & D. Cass [Page 9] ! 531: ! 532: RFC 1006 May 1987 ! 533: ! 534: ! 535: Actions ! 536: ! 537: T-CONNECT.REQUEST ! 538: - a TS-user (initiator) indicates that it ! 539: wants to establish a connection ! 540: ! 541: T-CONNECT.RESPONSE ! 542: - a TS-user (responder) indicates that it ! 543: will honor the request ! 544: ! 545: T-DATA.REQUEST - a TS-user sends data ! 546: ! 547: T-EXPEDITED DATA.REQUEST ! 548: - a TS-user sends "expedited" data ! 549: ! 550: T-DISCONNECT.REQUEST ! 551: - a TS-user indicates that the connection ! 552: is to be closed ! 553: ! 554: ! 555: ! 556: ! 557: ! 558: ! 559: ! 560: ! 561: ! 562: ! 563: ! 564: ! 565: ! 566: ! 567: ! 568: ! 569: ! 570: ! 571: ! 572: ! 573: ! 574: ! 575: ! 576: ! 577: ! 578: ! 579: ! 580: ! 581: ! 582: ! 583: ! 584: ! 585: ! 586: ! 587: ! 588: ! 589: M. Rose & D. Cass [Page 10] ! 590: ! 591: RFC 1006 May 1987 ! 592: ! 593: ! 594: 5. The Protocol ! 595: ! 596: ! 597: The protocol specified by this memo is identical to the protocol ! 598: for ISO transport class 0, with the following exceptions: ! 599: ! 600: - for testing purposes, initial data may be exchanged ! 601: during connection establishment ! 602: ! 603: - for testing purposes, an expedited data service is ! 604: supported ! 605: ! 606: - for performance reasons, a much larger TSDU size is ! 607: supported ! 608: ! 609: - the network service used by the protocol is provided ! 610: by the TCP ! 611: ! 612: ! 613: The ISO transport protocol exchanges information between peers in ! 614: discrete units of information called transport protocol data units ! 615: (TPDUs). The protocol defined in this memo encapsulates these ! 616: TPDUs in discrete units called TPKTs. The structure of these ! 617: TPKTs and their relationship to TPDUs are discussed in the next ! 618: section. ! 619: ! 620: PRIMITIVES ! 621: ! 622: The mapping between the TCP service primitives and the service ! 623: primitives expected by transport class 0 are quite straight- ! 624: forward: ! 625: ! 626: network service TCP ! 627: --------------- --- ! 628: CONNECTION ESTABLISHMENT ! 629: ! 630: N-CONNECT.REQUEST open completes ! 631: ! 632: N-CONNECT.INDICATION listen (PASSIVE open) ! 633: finishes ! 634: ! 635: N-CONNECT.RESPONSE listen completes ! 636: ! 637: N-CONNECT.CONFIRMATION open (ACTIVE open) ! 638: finishes ! 639: ! 640: DATA TRANSFER ! 641: ! 642: N-DATA.REQUEST send data ! 643: ! 644: N-DATA.INDICATION data ready followed by ! 645: ! 646: ! 647: ! 648: M. Rose & D. Cass [Page 11] ! 649: ! 650: RFC 1006 May 1987 ! 651: ! 652: ! 653: read data ! 654: ! 655: CONNECTION RELEASE ! 656: ! 657: N-DISCONNECT.REQUEST close ! 658: ! 659: N-DISCONNECT.INDICATION connection closes or ! 660: errors ! 661: ! 662: Mapping parameters is also straight-forward: ! 663: ! 664: network service TCP ! 665: --------------- --- ! 666: CONNECTION RELEASE ! 667: ! 668: Called address server's IP address ! 669: (4 octets) ! 670: ! 671: Calling address client's IP address ! 672: (4 octets) ! 673: ! 674: all others ignored ! 675: ! 676: DATA TRANSFER ! 677: ! 678: NS-user data (NSDU) data ! 679: ! 680: CONNECTION RELEASE ! 681: ! 682: all parameters ignored ! 683: ! 684: ! 685: ! 686: CONNECTION ESTABLISHMENT ! 687: ! 688: The elements of procedure used during connection establishment ! 689: are identical to those presented in [ISO8073], with three ! 690: exceptions. ! 691: ! 692: In order to facilitate testing, the connection request and ! 693: connection confirmation TPDUs may exchange initial user data, ! 694: using the user data fields of these TPDUs. ! 695: ! 696: In order to experiment with expedited data services, the ! 697: connection request and connection confirmation TPDUs may ! 698: negotiate the use of expedited data transfer using the ! 699: negotiation mechanism specified in [ISO8073] is used (e.g., ! 700: setting the "use of transport expedited data transfer service" ! 701: bit in the "Additional Option Selection" variable part). The ! 702: default is not to use the transport expedited data transfer ! 703: service. ! 704: ! 705: ! 706: ! 707: M. Rose & D. Cass [Page 12] ! 708: ! 709: RFC 1006 May 1987 ! 710: ! 711: ! 712: In order to achieve good performance, the default TPDU size is ! 713: 65531 octets, instead of 128 octets. In order to negotiate a ! 714: smaller (standard) TPDU size, the negotiation mechanism ! 715: specified in [ISO8073] is used (e.g., setting the desired bit ! 716: in the "TPDU Size" variable part). ! 717: ! 718: To perform an N-CONNECT.REQUEST action, the TS-peer performs ! 719: an active open to the desired IP address using TCP port 102. ! 720: When the TCP signals either success or failure, this results ! 721: in an N-CONNECT.INDICATION action. ! 722: ! 723: To await an N-CONNECT.INDICATION event, a server listens on ! 724: TCP port 102. When a client successfully connects to this ! 725: port, the event occurs, and an implicit N-CONNECT.RESPONSE ! 726: action is performed. ! 727: ! 728: NOTE: In most implementations, a single server will ! 729: perpetually LISTEN on port 102, handing off ! 730: connections as they are made ! 731: ! 732: DATA TRANSFER ! 733: ! 734: The elements of procedure used during data transfer are identical ! 735: to those presented in [ISO8073], with one exception: expedited ! 736: data may be supported (if so negotiated during connection ! 737: establishment) by sending a modified ED TPDU (described below). ! 738: The TPDU is sent on the same TCP connection as all of the other ! 739: TPDUs. This method, while not faithful to the spirit of [ISO8072], ! 740: is true to the letter of the specification. ! 741: ! 742: To perform an N-DATA.REQUEST action, the TS-peer constructs the ! 743: desired TPKT and uses the TCP send data primitive. ! 744: ! 745: To trigger an N-DATA.INDICATION action, the TCP indicates that ! 746: data is ready and a TPKT is read using the TCP read data ! 747: primitive. ! 748: ! 749: CONNECTION RELEASE ! 750: ! 751: To perform an N-DISCONNECT.REQUEST action, the TS-peer simply closes ! 752: the TCP connection. ! 753: ! 754: If the TCP informs the TS-peer that the connection has been closed or ! 755: has errored, this indicates an N-DISCONNECT.INDICATION event. ! 756: ! 757: ! 758: ! 759: ! 760: ! 761: ! 762: ! 763: ! 764: ! 765: ! 766: M. Rose & D. Cass [Page 13] ! 767: ! 768: RFC 1006 May 1987 ! 769: ! 770: ! 771: 6. Packet Format ! 772: ! 773: ! 774: A fundamental difference between the TCP and the network service ! 775: expected by TP0 is that the TCP manages a continuous stream of ! 776: octets, with no explicit boundaries. The TP0 expects information ! 777: to be sent and delivered in discrete objects termed network ! 778: service data units (NSDUs). Although other classes of transport ! 779: may combine more than one TPDU inside a single NSDU, transport ! 780: class 0 does not use this facility. Hence, an NSDU is identical ! 781: to a TPDU for the purposes of our discussion. ! 782: ! 783: The protocol described by this memo uses a simple packetization ! 784: scheme in order to delimit TPDUs. Each packet, termed a TPKT, is ! 785: viewed as an object composed of an integral number of octets, of ! 786: variable length. ! 787: ! 788: NOTE: For the purposes of presentation, these objects are ! 789: shown as being 4 octets (32 bits wide). This ! 790: representation is an artifact of the style of this ! 791: memo and should nto be interpreted as requiring ! 792: that a TPKT be a multiple of 4 octets in length. ! 793: ! 794: A TPKT consists of two parts: a packet-header and a TPDU. The ! 795: format of the header is constant regardless of the type of packet. ! 796: The format of the packet-header is as follows: ! 797: ! 798: 0 1 2 3 ! 799: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ! 800: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 801: | vrsn | reserved | packet length | ! 802: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 803: ! 804: where: ! 805: ! 806: vrsn 8 bits ! 807: ! 808: This field is always 3 for the version of the protocol described in ! 809: this memo. ! 810: ! 811: packet length 16 bits (min=7, max=65535) ! 812: ! 813: This field contains the length of entire packet in octets, ! 814: including packet-header. This permits a maximum TPDU size of ! 815: 65531 octets. Based on the size of the data transfer (DT) TPDU, ! 816: this permits a maximum TSDU size of 65524 octets. ! 817: ! 818: The format of the TPDU is defined in [ISO8073]. Note that only ! 819: TPDUs formatted for transport class 0 are exchanged (different ! 820: transport classes may use slightly different formats). ! 821: ! 822: ! 823: ! 824: ! 825: M. Rose & D. Cass [Page 14] ! 826: ! 827: RFC 1006 May 1987 ! 828: ! 829: ! 830: To support expedited data, a non-standard TPDU, for expedited data ! 831: is permitted. The format used for the ED TPDU is nearly identical ! 832: to the format for the normal data, DT, TPDU. The only difference ! 833: is that the value used for the TPDU's code is ED, not DT: ! 834: ! 835: 0 1 2 3 ! 836: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ! 837: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 838: | header length | code |credit |TPDU-NR and EOT| user data | ! 839: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 840: | ... | ... | ... | ... | ! 841: | ... | ... | ... | ... | ! 842: | ... | ... | ... | ... | ! 843: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 844: ! 845: After the credit field (which is always ZERO on output and ignored ! 846: on input), there is one additional field prior to the user data. ! 847: ! 848: TPDU-NR and EOT 8 bits ! 849: ! 850: Bit 7 (the high-order bit, bit mask 1000 0000) indicates the end ! 851: of a XSDU (expedited TSDU). All other bits should be ZERO on ! 852: output and ignored on input. ! 853: ! 854: Note that the TP specification limits the size of an expedited ! 855: transport service data unit (XSDU) to 16 octets. ! 856: ! 857: ! 858: ! 859: ! 860: ! 861: ! 862: ! 863: ! 864: ! 865: ! 866: ! 867: ! 868: ! 869: ! 870: ! 871: ! 872: ! 873: ! 874: ! 875: ! 876: ! 877: ! 878: ! 879: ! 880: ! 881: ! 882: ! 883: ! 884: M. Rose & D. Cass [Page 15] ! 885: ! 886: RFC 1006 May 1987 ! 887: ! 888: ! 889: 7. Comments ! 890: ! 891: ! 892: Since the release of RFC983 in April of 1986, we have gained much ! 893: experience in using ISO transport services on top of the TCP. In ! 894: September of 1986, we introduced the use of version 2 of the ! 895: protocol, based mostly on comments from the community. ! 896: ! 897: In January of 1987, we observed that the differences between ! 898: version 2 of the protocol and the actual transport class 0 ! 899: definition were actually quite small. In retrospect, this ! 900: realization took much longerr than it should have: TP0 is is ! 901: meant to run over a reliable network service, e.g., X.25. The TCP ! 902: can be used to prrvide a service of this type, and, if no one ! 903: complains to loudly, one could state that this memo really just ! 904: describes a method for encapsulating TPO inside of TCP! ! 905: ! 906: The changes in going from version 1 of the protocol to version 2 ! 907: and then to version 3 are all relatively small. Initially, in ! 908: describing version 1, we decided to use the TPDU formats from the ! 909: ISO transport protocol. This naturally led to the evolution ! 910: described above. ! 911: ! 912: ! 913: ! 914: ! 915: ! 916: ! 917: ! 918: ! 919: ! 920: ! 921: ! 922: ! 923: ! 924: ! 925: ! 926: ! 927: ! 928: ! 929: ! 930: ! 931: ! 932: ! 933: ! 934: ! 935: ! 936: ! 937: ! 938: ! 939: ! 940: ! 941: ! 942: ! 943: M. Rose & D. Cass [Page 16] ! 944: ! 945: RFC 1006 May 1987 ! 946: ! 947: ! 948: 8. References ! 949: ! 950: ! 951: [GOSIP86] The U.S. Government OSI User's Committee. ! 952: "Government Open Systems Interconnection Procurement ! 953: (GOSIP) Specification for Fiscal years 1987 and ! 954: 1988." (December, 1986) [draft status] ! 955: ! 956: [ISO8072] ISO. ! 957: "International Standard 8072. Information Processing ! 958: Systems -- Open Systems Interconnection: Transport ! 959: Service Definition." ! 960: (June, 1984) ! 961: ! 962: [ISO8073] ISO. ! 963: "International Standard 8073. Information Processing ! 964: Systems -- Open Systems Interconnection: Transport ! 965: Protocol Specification." ! 966: (June, 1984) ! 967: ! 968: [ISO8327] ISO. ! 969: "International Standard 8327. Information Processing ! 970: Systems -- Open Systems Interconnection: Session ! 971: Protocol Specification." ! 972: (June, 1984) ! 973: ! 974: [RFC791] Internet Protocol. ! 975: Request for Comments 791 (MILSTD 1777) ! 976: (September, 1981) ! 977: ! 978: [RFC793] Transmission Control Protocol. ! 979: Request for Comments 793 (MILSTD 1778) ! 980: (September, 1981) ! 981: ! 982: [RFC983] ISO Transport Services on Top of the TCP. ! 983: Request for Comments 983 ! 984: (April, 1986) ! 985: ! 986: [X.214] CCITT. ! 987: "Recommendation X.214. Transport Service Definitions ! 988: for Open Systems Interconnection (OSI) for CCITT ! 989: Applications." ! 990: (October, 1984) ! 991: ! 992: [X.224] CCITT. ! 993: "Recommendation X.224. Transport Protocol ! 994: Specification for Open Systems Interconnection (OSI) ! 995: for CCITT Applications." (October, 1984) ! 996: ! 997: ! 998: ! 999: ! 1000: ! 1001: ! 1002: M. Rose & D. Cass [Page 17] ! 1003: ! 1004: RFC 1006 May 1987 ! 1005: ! 1006: ! 1007: [X.225] CCITT. ! 1008: "Recommendation X.225. Session Protocol Specification ! 1009: for Open Systems Interconnection (OSI) for CCITT ! 1010: Applications." ! 1011: (October, 1984) ! 1012: ! 1013: ! 1014: ! 1015: ! 1016: ! 1017: ! 1018: ! 1019: ! 1020: ! 1021: ! 1022: ! 1023: ! 1024: ! 1025: ! 1026: ! 1027: ! 1028: ! 1029: ! 1030: ! 1031: ! 1032: ! 1033: ! 1034: ! 1035: ! 1036: ! 1037: ! 1038: ! 1039: ! 1040: ! 1041: ! 1042: ! 1043: ! 1044: ! 1045: ! 1046: ! 1047: ! 1048: ! 1049: ! 1050: ! 1051: ! 1052: ! 1053: ! 1054: ! 1055: ! 1056: ! 1057: ! 1058: ! 1059: ! 1060: ! 1061: M. Rose & D. Cass [Page 18] ! 1062:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.