![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc1006.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / rfcs|
Return to rfc1006.txt CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / rfcs |
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.