![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc1085.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 rfc1085.txt CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / rfcs |
1.1 root 1:
2:
3:
4:
5:
6:
7: Network Working Group M. Rose
8: Request for Comments: 1085 TWG
9: December 1988
10:
11:
12: ISO Presentation Services
13: on top of TCP/IP-based internets
14:
15: Status of this Memo
16:
17: This memo proposes a standard for the Internet community.
18: Distribution of this memo is unlimited.
19:
20: 1. Introduction
21:
22: [RFC1006] describes a mechanism for providing the ISO transport
23: service on top of the Transmission Control Protocol (TCP) [RFC793]
24: and Internet Protocol (IP) [RFC791]. Once this method is applied,
25: one may implement "real" ISO applications on top of TCP/IP-based
26: internets, by simply implementing OSI session, presentation, and
27: application services on top of the transport service access point
28: which is provided on top of the TCP. Although straight-forward,
29: there are some environments in which the richness provided by the OSI
30: application layer is desired, but it is nonetheless impractical to
31: implement the underlying OSI infrastructure (i.e., the presentation,
32: session, and transport services on top of the TCP). This memo
33: describes an approach for providing "stream-lined" support of OSI
34: application services on top of TCP/IP-based internets for such
35: constrained environments.
36:
37: 2. Terminology
38:
39: In as much as this memo is concerned primarily with concepts defined
40: in the framework of Open Systems Interconnection (OSI) as promulgated
41: by the International Organization for Standardization (ISO), the
42: terminology used herein is intended to be entirely consistent within
43: that domain of discourse. This perspective is being taken despite
44: the expressed intent of implementing the mechanism proposed by this
45: memo in the Internet and other TCP/IP-based internets. For those
46: more familiar with the terminology used in this latter domain, the
47: author is apologetic but unyielding.
48:
49: Although no substitute for the "correct" definitions given in the
50: appropriate ISO documents, here is a short summary of the terms used
51: herein.
52:
53:
54:
55:
56:
57:
58: Rose [Page 1]
59:
60: RFC 1085 ISO Presentation Services December 1988
61:
62:
63: Application Context:
64: The collection of application service elements which
65: cooperatively interact within an application-entity.
66:
67: Application Service Element:
68: A standardized mechanism, defined by both a service and a
69: protocol, which provides a well-defined capability, e.g.,
70:
71: ROSE - the Remote Operations Service Element,
72: which orchestrates the invocation of "total"
73: operations between application-entities [ISO9066/2].
74:
75: ACSE - the Association Control Service Element,
76: which manages associations between application
77: entities [ISO8650].
78:
79: Object Identifier:
80: An ordered set of integers, used for authoritative
81: identification.
82:
83: Presentation Service:
84: A set of facilities used to manage a connection between two
85: application-entities. The fundamental responsibility of the
86: presentation service is to maintain transfer syntaxes which
87: are used to serialize application protocol data units for
88: transmission on the network and subsequent de-serialization
89: for reception.
90:
91: Protocol Data Unit (PDU):
92: A data object exchanged between service providers.
93:
94: Serialization:
95: The process of applying an abstract transfer notation to an
96: object described using abstract syntax notation one (ASN.1)
97: [ISO8824] in order to produce a stream of octets.
98: De-serialization is the inverse process.
99:
100: It is assumed that the reader is familiar with terminology
101: pertaining to the reference model [ISO7498], to the service
102: conventions in the model [ISO8509], and to the
103: connection-oriented presentation service [ISO8822].
104:
105: 3. Scope
106:
107: The mechanism proposed by this memo is targeted for a particular
108: class of OSI applications, namely those entities whose application
109: context contains only an Association Control Service Element (ACSE)
110: and a Remote Operations Service Element (ROSE). In addition, a
111:
112:
113:
114: Rose [Page 2]
115:
116: RFC 1085 ISO Presentation Services December 1988
117:
118:
119: Directory Services Element (DSE) is assumed for use by the
120: application-entity, but only in a very limited sense. The
121: organization of such an entity is as follows:
122:
123:
124: +------------------------------------------------------------+
125: | |
126: | Application-Entity |
127: | |
128: | +------+ +------+ +------+ |
129: | | ACSE | | ROSE | | DSE | |
130: | +------+ +------+ +------+ |
131: | |
132: +------------------------------------------------------------+
133: | |
134: | Presentation Services |
135: | |
136: | P-CONNECT P-RELEASE P-DATA |
137: | P-U-ABORT |
138: | P-P-ABORT |
139: | |
140: +------------------------------------------------------------+
141:
142:
143: The mechanism proposed by this memo is not applicable to entities
144: whose application context is more extensive (e.g., contains a
145: Reliable Transfer Service Element). The mechanism proposed by this
146: memo could be modified to support additional elements. However, such
147: extensions would, at this time, merely serve to defeat the purpose of
148: providing the minimal software infrastructure required to run the
149: majority of OSI applications.
150:
151: The motivation for this memo was initially derived from a requirement
152: to run the ISO Common Management Information Protocol (CMIP) in
153: TCP/IP-based internets. In its current definition, CMIP uses
154: precisely the application service elements provided for herein. It
155: may be desirable to offer CMIP users a quality of service different
156: than the one offered by a connection with a high-quality level of
157: reliability. This would permit a reduced utilization of connection-
158: related resources. This memo proposes a mechanism to implement this
159: less robust -- and less costly -- quality of service.
160:
161: 4. Approach
162:
163: The approach proposed by this memo relies on the following
164: architectural nuances:
165:
166:
167:
168:
169:
170: Rose [Page 3]
171:
172: RFC 1085 ISO Presentation Services December 1988
173:
174:
175: - the TCP is a stream-oriented transport protocol
176:
177: - ASN.1 objects, when represented as a stream of octets are
178: self-delimiting
179:
180: - The ISO presentation service permits the exchange of ASN.1
181: objects
182:
183: - The ACSE and ROSE require the following presentation
184: facilities:
185:
186: The Connection Establishment Facility
187:
188: The Connection Termination Facility
189:
190: The Information Transfer Facility (P-DATA
191: service only)
192:
193: - The majority of the parameters used by the services which
194: provide these facilities can be "hard-wired" to avoid
195: negotiation
196:
197: In principle, these nuances suggest that a "cheap" emulation of the
198: ISO presentation services could be implemented by simply serializing
199: ASN.1 objects over a TCP connection. This approach is precisely what
200: is proposed by this memo.
201:
202: Given this perspective, this memo details how the essential features
203: of the ISO presentation service may be maintained while using a
204: protocol entirely different from the one given in [ISO8823]. The
205: overall composition proposed by this memo is as follows:
206:
207:
208: +-----------+ +-----------+
209: | PS-user | | PS-user |
210: +-----------+ +-----------+
211: | |
212: | PS interface PS interface |
213: | [ISO8822] |
214: | |
215: +----------+ ISO Presentation Services on the TCP +----------+
216: | client |-----------------------------------------| server |
217: +----------+ (this memo) +----------+
218: | |
219: | TCP interface TCP interface |
220: | [RFC793] |
221: | |
222:
223:
224:
225:
226: Rose [Page 4]
227:
228: RFC 1085 ISO Presentation Services December 1988
229:
230:
231: In greater detail, the "client" and "server" boxes implement the
232: protocol described in this memo. Each box contains three modules:
233:
234: - a dispatch module, which provides the presentation services
235: interface,
236:
237: - a serialization module, containing a serializer, which takes
238: an ASN.1 object and applies the encoding rules of [ISO8825]
239: to produce a stream of octets, and a de-serializer, which
240: performs the inverse operation, and
241:
242: - a network module, which manages a TCP connection.
243:
244: The software architecture used to model a network entity using this
245: approach is as follows:
246:
247:
248: +---------+ +----------+ +-----+
249: | | | | output +---------------+ input | n |
250: | | | |<--------| de-serializer |<--------| e |
251: | | | | queue +---------------+ queue | t |
252: | PS-user |----| dispatch | | w |
253: | | | | input +---------------+ output | o |
254: | | | |-------->| serializer |-------->| r |
255: | | | | queue +---------------+ queue | k |
256: +---------+ +----------+ +-----+
257:
258: |---- serialization module ----|
259:
260:
261: The ISO presentation layer is concerned primarily with the
262: negotiation of transfer syntaxes in addition to the transformation to
263: and from transfer syntax. However, using the mechanism proposed by
264: this memo, no negotiation component will be employed. This memo
265: specifies the fixed contexts which exist over each presentation
266: connection offered. This memo further specifies other constants
267: which are used in order to eliminate the need for presentation layer
268: negotiation.
269:
270: 5. Fundamental Parameters
271:
272: There are certain parameters which are used by the presentation
273: service and are defined here.
274:
275: 1. Presentation address:
276:
277: The structure of a presentation address is presented in Addendum 3
278: to [ISO7498]. This memo interprets a presentation address as an
279:
280:
281:
282: Rose [Page 5]
283:
284: RFC 1085 ISO Presentation Services December 1988
285:
286:
287: ordered-tuple containing:
288:
289: - one or more network addresses
290: - a transport selector
291: - a session selector
292: - a presentation selector
293:
294: Each selector is an uninterpreted octet string of possibly zero
295: length. The mechanism proposed in this memo completely ignores
296: the values of these selectors. Note however that the value of the
297: presentation selector is preserved by the provider.
298:
299: A network address is interpreted as containing three components:
300:
301: - a 32-bit IP address
302:
303: - a set indicating which transport services are available
304: at the IP address (currently only two members are defined:
305: TCP and UDP; as experience is gained, other transport
306: services may be added); as a local matter, if a member is
307: present it may have an "intensity" associated with it:
308: either "possibly present" or "definitely present"
309:
310: - a 16-bit port number
311:
312: As a consequence of these interpretations, any application-entity
313: residing in the network can be identified by its network address.
314:
315: 2. Presentation context list
316:
317: A list of one or more presentation contexts. Each presentation
318: context has three components:
319:
320: - a presentation context identifier (PCI), an integer
321:
322: - an abstract syntax name, an object identifier
323:
324: - an abstract transfer name, an object identifier
325:
326: The range of values these components may take is severely
327: restricted by this memo. In particular, exactly two contexts are
328: defined: one for association control and the other for the
329: specific application service element which is being carried as ROS
330: APDUs (see the section on connection establishment for the precise
331: values).
332:
333: In addition, if the presentation context list appears in a
334: "result" list (e.g., the Presentation context result list
335:
336:
337:
338: Rose [Page 6]
339:
340: RFC 1085 ISO Presentation Services December 1988
341:
342:
343: parameter for the P-CONNECT service), a fourth component is
344: present:
345:
346: - an acceptance indicator
347:
348: which indicates if the context was accepted by both the service
349: provider and the remote peer. If the context was not accept, a
350: brief reason, such as "abstract syntax not supported" is given.
351:
352: For the novice reader, one might think of the abstract syntax
353: notation as defining the vocabulary of some language, that is, it
354: lists the words which can be spoken. In contrast, the abstract
355: transfer notation defines the pronunciation of the language.
356:
357: 3. User data
358:
359: User data passes through the presentation service interface as
360: ASN.1 objects (in a locally defined form). Associated with each
361: object is a presentation context identifier. The PCI
362: distinguishes the context for which the data is intended. The
363: range of values the PCI may take is severely restricted by this
364: memo. Exactly one of two contexts must always be used: either the
365: value for the ACSE presentation context or the value for the ROSE.
366:
367: 4. Quality of Service
368:
369: Quality of service is a collection of "elements". Each element
370: denotes some characteristics of the communication, e.g., desired
371: throughput, and some value in an arbitrary unit of measure. For
372: our purposes, only one quality of service element is interpreted,
373: "transport-mapping". Currently, the "transport-mapping" element
374: takes on one of two values: "tcp-based" or "udp-based". At
375: present, the two values may also be referred to as "high-quality"
376: or "low-quality", respectively.
377:
378: As experience is gained, other values may be added. These values
379: would correspond directly to the new transport services which are
380: listed in the network address.
381:
382: 5. Version of Session Service
383:
384: Some application service elements (e.g., the ACSE) invoke
385: different procedures based on the (negotiated) version of the
386: session service available. Implementations of this memo always
387: indicate that session service version 2 has been negotiated.
388:
389:
390:
391:
392:
393:
394: Rose [Page 7]
395:
396: RFC 1085 ISO Presentation Services December 1988
397:
398:
399: 6. Choice of Transport Service
400:
401: Discussion thus far has centered along the use of the TCP as the
402: underlying transport protocol. However, it has also been noted that
403: it may be desirable to permit a quality of service with less
404: reliability in order to take advantage of some other characteristic
405: of the transport service.
406:
407: The introduction of this service has several profound impacts on the
408: model, and it is beyond the scope of this memo to enumerate these
409: impacts. However, this memo does propose a mechanism by which such a
410: facility is implemented.
411:
412: To begin, we use the quality of service parameter for the P-CONNECT
413: service to select an underlying transport service. Only one element
414: is currently interpreted, "transport-mapping" which takes the value
415: "tcp-based" or "udp-based". If the value is "tcp-based", then the
416: presentation provider will use TCP as the underlying transport
417: service. If, however, the value of "transport-mapping" is "udp-
418: based", then the presentation provider will use the UDP instead.
419:
420: The User Datagram Protocol (UDP) [RFC768] is used to implement the
421: udp-based service. Very few transport-level facilities are placed on
422: top of the UDP service, i.e., it is not the intent of this memo to
423: "re-invent" the facilities in the TCP. Hence, It is critical to
424: understand that
425:
426: low-quality means LOW-QUALITY!
427:
428: Because the UDP is a packet-oriented protocol, it is necessary to
429: slightly redefine the role of the serialization module. For the
430: serializer, we say that each top-level ASN.1 object placed on the
431: input queue will form a single UDP datagram on the output queue which
432: is given to the network. Similarly, for the de-serializer, we say
433: that each UDP datagram placed on the input queue from the network
434: will form a single top-level ASN.1 object placed on the output queue.
435: The term "top-level ASN.1 object" refers, of course, to the protocol
436: data units being exchanged by the presentation providers.
437:
438: It should be noted that in its current incarnation, this memo permits
439: the choice of two different transport protocols, e.g., the TCP or the
440: UDP. However, as experience is gained and as other transport
441: protocols are deployed (e.g., the VMTP), then future incarnations of
442: this memo will permit these transport protocols to be used. This is
443: a three step process: first, the set of transport services defined
444: for the network address is updated; second, a corresponding value is
445: added to the range of the quality of service element "transport-
446: mapping"; and, third, the following sections of this memo are
447:
448:
449:
450: Rose [Page 8]
451:
452: RFC 1085 ISO Presentation Services December 1988
453:
454:
455: modified accordingly.
456:
457: 7. Connection Establishment
458:
459: The Connection Establishment facility consists of one service, the
460: P-CONNECT service.
461:
462: 7.1. The P-CONNECT Service
463:
464: This service is used to bring two identified application-entities
465: into communication. Its successful use results in a presentation
466: connection, with an initial defined context set, being established
467: between then. This connection is available for their subsequent
468: communication. This is a confirmed service whose effects are
469: sequenced and non-destructive.
470:
471: If the udp-based service is selected, then a presentation connection
472: is formed which should be used infrequently and will have minimal
473: reliability characteristics.
474:
475: For our purposes, the P-CONNECT service:
476:
477: - requests TCP or UDP resources,
478:
479: - builds a fixed defined context set, and
480:
481: - exchanges initial user data.
482:
483: Following are the interpretation of and the defaults assigned to the
484: parameters of the P-CONNECT service:
485:
486: 1. Calling Presentation Address
487:
488: This is a presentation address. Although the ISO presentation
489: service states that this parameter is mandatory, in practice, a
490: local implementation rule may be used to determine an
491: "ephemeral" address to use.
492:
493: 2. Called Presentation Address
494:
495: This is a presentation address. Note that when issuing the P-
496: CONNECT.REQUEST primitive, this parameter may contain more than
497: one network address. In the P-CONNECT.INDICATION primitive
498: however, only one network address, the one actually used to
499: establish the presentation connection, is present. (Appendix C
500: describes a strategy which might be used to determine the actual
501: network address).
502:
503:
504:
505:
506: Rose [Page 9]
507:
508: RFC 1085 ISO Presentation Services December 1988
509:
510:
511: 3. Responding Presentation Address
512:
513: This parameter is identical to the value of the Called
514: Presentation Address parameter of the P-CONNECT.INDICATION
515: primitive.
516:
517: 4. Multiple defined Contexts
518:
519: Always TRUE. Note that this parameter is present only in the
520: DIS version of the presentation service.
521:
522: 5. Presentation context definition list
523:
524: Two contexts are defined:
525:
526: PCI Abstract Syntax Name Abstract Transfer Name
527: --- -------------------- ----------------------
528: 1 specific to the application "iso asn.1 abstract
529: transfer"
530: 1.0.8825
531:
532: 3 "acse pci version 1" "iso asn.1 abstract
533: transfer"
534: 2.2.1.0.0 1.0.8825
535:
536: The abstract syntax and transfer names for the ACSE PCI are for
537: use with the DIS version of association control. If the IS
538: version is being used, then this PCI is used instead:
539:
540: 3 "acse pci version 1" "asn.1 basic encoding"
541: 2.2.1.0.1 2.1.1
542:
543: 6. Presentation context result list
544:
545: Identical to the Presentation context definition list with the
546: addition that the acceptance indicator for both contexts is
547: "accepted".
548:
549: 7. Default Context Name
550:
551: None.
552:
553: 8. Default Context Result
554:
555: Not applicable.
556:
557:
558:
559:
560:
561:
562: Rose [Page 10]
563:
564: RFC 1085 ISO Presentation Services December 1988
565:
566:
567: 9. Quality of Service
568:
569: The element "transport-mapping" takes the value "tcp-based" or
570: "udp-based". In the future the range of values may be extended.
571:
572: 10. Presentation Requirements
573:
574: None (the kernel functional unit is always used).
575:
576: 11. Session Requirements
577:
578: Full duplex.
579:
580: 12. Initial synchronization point serial number
581:
582: None.
583:
584: 13. Initial Assignment of tokens
585:
586: None.
587:
588: 14. Session connection identifier
589:
590: Unlike the "real" presentation service, depending on the quality
591: of service selected, this parameter may have great significance
592: to presentation provider. Hence, the following format of the
593: session connection identifier is mandated by this memo.
594:
595: user data: a local string encoded as a T.61 string
596: using ASN.1, e.g., given string "gonzo":
597:
598: 14 05 67 6f 6e 7a 6f
599: tag length "g" "o" "n" "z" "o"
600:
601: common data: a universal time encoding using ASN.1, e.g.,
602: given time "880109170845":
603:
604: 17 0c 38 38 30 31 30 ...
605: tag length "8" "8" "0" "1" "0" ...
606:
607: additional data: any string encoded as a T.61 string using ASN.1
608: (optional)
609:
610: As a local convention, the presentation provider may disregard
611: the first two octets of each data component for transmission on
612: the network as when the session connection identifier is
613: represented with ASN.1, the tag and length octets will be added
614: anyway.
615:
616:
617:
618: Rose [Page 11]
619:
620: RFC 1085 ISO Presentation Services December 1988
621:
622:
623: 15. User Data
624:
625: A single ASN.1 object is present, the appropriate A-ASSOCIATE
626: PDU, carried in presentation context 3.
627:
628: 16. Result
629:
630: One of the following values: acceptance, user-rejection,
631: provider-rejection (transient), or provider-rejection
632: (permanent).
633:
634: 8. Connection Termination
635:
636: The Connection Termination facility consists of three services, the
637: P-RELEASE, P-U-ABORT, and P-P-ABORT services.
638:
639: 8.1. The P-RELEASE Service
640:
641: This service provides the service user with access to a negotiated
642: release facility. This service has effects which are sequenced and
643: non-destructive. Either presentation user is permitted to request
644: this service. However, in the event of collision, a provider-
645: initiated abort procedure will be invoked.
646:
647: If the udp-based service is selected, then any data in transit may be
648: discarded.
649:
650: For our purposes, the P-RELEASE service:
651:
652: - waits for the serialization module to drain,
653:
654: - sends release user data, and
655:
656: - releases TCP or UDP resources
657:
658: Following are the interpretation of and the defaults assigned to the
659: parameters of the P-RELEASE service:
660:
661: 1. Result
662:
663: Release accepted.
664:
665: 2. User data
666:
667: A single ASN.1 object is present, the appropriate A-RELEASE PDU,
668:
669:
670:
671:
672:
673:
674: Rose [Page 12]
675:
676: RFC 1085 ISO Presentation Services December 1988
677:
678:
679: 8.2. The P-U-ABORT Service
680:
681: This service can be used by either presentation user to force the
682: release of a presentation connection at any time and have the
683: correspondent presentation user informed of this termination. This
684: service has effects which are not sequenced with respect to preceding
685: service invocations and may be destructive. It does not require the
686: agreement of both service users.
687:
688: For our purposes, the P-U-ABORT service:
689:
690: - flushes the serialization module,
691:
692: - sends abort user data, and
693:
694: - releases TCP or UDP resources
695:
696: Following are the interpretation of and the defaults assigned to the
697: parameters of the P-U-ABORT service:
698:
699: 1. Presentation context identifier list
700:
701: Contained in the ASN.1 objects, if any, that are delivered as
702: user data.
703:
704: 2. User data
705:
706: A single ASN.1 object is present, an A-ABORT PDU, carried in
707: presentation context 3.
708:
709: 8.3. The P-P-ABORT Service
710:
711: This service is the means by which the service provider may indicate
712: the termination of the presentation connection for reasons internal
713: to the service provider. This service has effects which are not
714: sequenced with respect to preceding service invocations. The
715: execution of this service disrupts any other concurrently active
716: service and may thus be destructive.
717:
718: For our purposes, the P-P-ABORT service:
719:
720: - flushes the serialization module, and
721:
722: - releases TCP or UDP resources
723:
724: Following are the interpretation of and the defaults assigned to the
725: parameters of the P-P-ABORT service.
726:
727:
728:
729:
730: Rose [Page 13]
731:
732: RFC 1085 ISO Presentation Services December 1988
733:
734:
735: 1. Provider reason
736:
737: An integer code detailing why the connection was aborted. Codes
738: include, but are not limited to: invalid PPDU parameter,
739: unexpected PPDU, unrecognized PPDU, and specified reason.
740:
741: 2. Abort data
742:
743: None.
744:
745: 9. Information Transfer
746:
747: Although the Information Transfer facility consists of many services,
748: only one, the P-DATA service, is provided by this memo.
749:
750: 9.1. The P-DATA Service
751:
752: This services provides the service user with a data transfer
753: capability. This service has effects which are sequenced and non-
754: destructive.
755:
756: If the udp-based service is selected, then there is an upper-bound on
757: the size of the serialized ASN.1 objects which may be transmitted.
758: This limit, imposed by the UDP, is 65536 octets. As a practical
759: matter, it is probably a good idea to keep datagrams less than or
760: equal to 536 octets in size.
761:
762: For our purposes, the P-DATA service:
763:
764: - sends user data
765:
766: Following are the interpretation of and the defaults assigned to the
767: parameters of the P-DATA service:
768:
769: 1. User data
770:
771: A single ASN.1 object is present, a remote operations APDU,
772: carried in presentation context 1.
773:
774: 10. Elements of Procedure
775:
776: The service provider is in one of the following states:
777:
778: IDLE, WAIT1, WAIT2, DATA, WAIT3, or WAIT4
779:
780: The possible events are:
781:
782: PS-user P-CONNECT.REQUEST
783:
784:
785:
786: Rose [Page 14]
787:
788: RFC 1085 ISO Presentation Services December 1988
789:
790:
791: P-CONNECT.RESPONSE
792: P-RELEASE.REQUEST
793: P-RELEASE.RESPONSE
794: P-DATA.REQUEST
795: P-U-ABORT.REQUEST
796:
797: network TCP closed or errored(*)
798: receive ConnectRequest PDU
799: receive ConnectResponse PDU
800: receive ReleaseRequest PDU
801: receive ReleaseResponse PDU
802: receive UserData(*) or CL-UserData(**) PDU
803: receive user-initiated Abort PDU
804: receive provider-initiated Abort PDU
805: timer expires(**)
806:
807:
808: The possible actions are:
809:
810: PS-user P-CONNECT.INDICATION
811: P-CONNECT.CONFIRMATION
812: P-RELEASE.INDICATION
813: P-RELEASE.CONFIRMATION
814: P-DATA.INDICATION
815: P-U-ABORT.INDICATION
816: P-P-ABORT.INDICATION
817:
818: network open TCP(*)
819: close TCP(*)
820: send ConnectRequest PDU
821: send ConnectResponse PDU
822: send ReleaseRequest PDU
823: send ReleaseResponse PDU
824: send UserData(*) or CL-UserData(**) PDU
825: send user-initiated Abort PDU
826: send provider-initiated Abort PDU
827: set timer(**)
828:
829: (*) tcp-based service only
830: (**) udp-based service only
831:
832: 10.1. Elements of Procedure specific to the tcp-based service
833:
834: The provider maintains the following information for each
835: presentation connection:
836:
837: - a local designator for the PS-user
838:
839:
840:
841:
842: Rose [Page 15]
843:
844: RFC 1085 ISO Presentation Services December 1988
845:
846:
847: - a local designator for a TCP connection
848:
849: - the state of the connection (e.g., IDLE, WAIT1, and so on)
850:
851: Upon receiving an event from the network, the provider finds the
852: associated presentation connection. Matching is done by simply
853: comparing local designators for the TCP connection. Whenever a
854: connection remains in or returns to the IDLE state, any associated
855: resources, such as an attachment to a local TCP port, are released.
856:
857: In the procedures which follow, outgoing PDUs are "placed on the
858: input queue for the serializer". This has a different meaning
859: depending on the type of PDU being enqueued. If the PDU is not an
860: abort PDU (user-initiated or provider-initiated), then the PDU is
861: simply appended to the input queue regardless of the number of PDUs
862: present. If however, the PDU is an abort PDU, then the provider
863: checks the size of the input queue. If the input queue is non-empty
864: or if the serializer is busy transmitting to the network, then the
865: abort PDU is discarded, and the serializer is flushed, aborting any
866: output to the network in progress. However, if the input queue is
867: empty, then the Abort PDU is appended to the queue, and a small timer
868: started. If the timer expires before the PDU has been serialized and
869: transmitted, then the serializer is flushed, aborting any output to
870: the network in progress.
871:
872: Further, in general, whenever the TCP connection is closed (either
873: locally by the provider, or remotely by the network) or has errored,
874: the serializer is flushed. The one exception to this is if a
875: ReleaseResponse PDU is being serialized and transmitted to the
876: network. In this case, the provider will not close the TCP
877: connection until after the serializer has finished.
878:
879: 10.2. Elements of Procedure specific to the udp-based service
880:
881: The provider maintains the following information for each
882: presentation connection:
883:
884: - a local designator for the PS-user
885:
886: - the 32-bit IP address and 16-bit UDP port number of the
887: initiating host
888:
889: - the 32-bit IP address and 16-bit UDP port number of the
890: responding host
891:
892: - the session connection identifier used to establish the
893: presentation connection
894:
895:
896:
897:
898: Rose [Page 16]
899:
900: RFC 1085 ISO Presentation Services December 1988
901:
902:
903: - a local designator for an UDP endpoint
904:
905: - the state of the connection (e.g., IDLE, WAIT1, and so on)
906:
907: - a retransmission counter
908:
909: Upon receiving an event from the network, the provider finds the
910: associated presentation connection. Matching is done on the basis of
911: addresses, ports, and the session connection identifier (i.e., two
912: different presentation connections may differ only in their session
913: connection identifier). If no presentation connection can be found,
914: then for the purposes of discussion, it may be assumed that a
915: "vanilla" presentation connection is created and initialized to the
916: IDLE state. Further, whenever a connection remains in or returns to
917: the IDLE state, any associated resources, such as an attachment to a
918: local UDP port, are released.
919:
920: In the procedures which follow, outgoing PDUs are "placed on the
921: input queue for the serializer". This means that the ASN.1 object is
922: serialized and the resulting sequence of octets is sent as a single
923: UDP datagram.
924:
925: 10.3. State Transitions
926:
927: Following are the rules for transitioning states. If an event
928: associated with a user-generated primitive is omitted, then it is an
929: interface error for the user to issue that primitive in the given
930: state. Each state considers all possible incoming PDUs.
931:
932: We assume that for the tcp-based service, that some entity starts a
933: passive TCP open. When the passive open completes, the entity, using
934: some local rule, locates a PS-user to be associated with the incoming
935: presentation connection. This presentation connection is then placed
936: in the IDLE state. The entity then continues listening for other
937: passive opens to complete. The mechanisms associated with this
938: entity are entirely a local matter, the concept of this listener is
939: introduced solely as a modeling artifact.
940:
941: Finally, if the udp-based service is selected, then CL-UserData PDUs
942: are exchanged by the provider instead of UserData PDUs.
943:
944:
945: IDLE state
946:
947: Event: P-CONNECT.REQUEST primitive issued
948:
949: Based on the quality of service parameter and the list of network
950: addresses in the called presentation address parameter, the provider
951:
952:
953:
954: Rose [Page 17]
955:
956: RFC 1085 ISO Presentation Services December 1988
957:
958:
959: selects an address for the use of the presentation connection. The
960: method for making this determination is a local matter. (Appendix C
961: discusses a strategy which might be used.) For the discussion that
962: follows, we assume that a network address supporting the desired
963: quality of service has been determined.
964:
965: Based on the network address chosen from the called presentation
966: address parameter, the provider selects a compatible network address
967: from the calling presentation address parameter. The provider
968: attaches itself to the port associated with this network address.
969: (By local determination, this address need not be used, and an
970: "ephemeral" port may be chosen by the provider.)
971:
972: For the tcp-based service, the provider attempts to establish a TCP
973: connection to the network address listed in the called presentation
974: address. If the connection can not be established, the P-
975: CONNECT.CONFIRMATION(-) primitive is issued with a reason of
976: provider-rejection, and the provider remains in the IDLE state.
977:
978: Regardless, the user data parameter is placed in a ConnectRequest
979: PDU, which is put on the input queue for the serializer.
980:
981: For the udp-based service, the provider sets the retransmission
982: counter to a small value (e.g., 2), and now starts a small timer.
983:
984: Regardless, the provider enters the WAIT1 state.
985:
986:
987: Event: ConnectRequest PDU received
988:
989: The provider issues the P-CONNECT.INDICATION primitive and enters the
990: WAIT2 state.
991:
992:
993: Event: any other PDU received
994:
995: If the PDU is not an Abort PDU, the provider constructs a provider-
996: initiated Abort PDU, which is put on the input queue for the
997: serializer. Regardless, the provider remains in the IDLE state.
998:
999:
1000: WAIT1 state
1001:
1002: Event: P-U-ABORT.REQUEST primitive issued
1003:
1004: The user data parameter is placed in an Abort PDU, which is put on
1005: the input queue for the serializer. The provider enters the IDLE
1006: state.
1007:
1008:
1009:
1010: Rose [Page 18]
1011:
1012: RFC 1085 ISO Presentation Services December 1988
1013:
1014:
1015: Event: ConnectResponse PDU received
1016:
1017: For the udp-based service, the timer is cancelled. If the PDU
1018: indicates rejection, the P-CONNECT.CONFIRMATION(-) primitive is
1019: issued and the provider enters the IDLE state. Otherwise, the P-
1020: CONNECT.CONFIRMATION(+) primitive is issued and the provider enters
1021: the DATA state.
1022:
1023:
1024: Event: user-initiated Abort PDU received
1025:
1026: The provider issues the P-U-ABORT.INDICATION primitive and enters the
1027: IDLE state.
1028:
1029:
1030: Event: any other PDU received
1031:
1032: If the PDU not an Abort PDU, the provider constructs a provider-
1033: initiated Abort PDU, which is put on the input queue for the
1034: serializer. Regardless, The provider issues the P-P-ABORT.INDICATION
1035: primitive and enters the the IDLE state.
1036:
1037:
1038: Event: timer expires
1039:
1040: The provider decrements the retransmission counter. If the resulting
1041: value is less than or equal to zero, the provider issues the P-
1042: CONNECT.CONFIRMATION(-) primitive and enters the IDLE state.
1043: Otherwise, a ConnectRequest PDU is put on the input queue for the
1044: serializer, the small timer is started again, and the provider
1045: remains in the WAIT1 state.
1046:
1047:
1048: WAIT2 state
1049:
1050: Event: P-CONNECT.RESPONSE primitive issued
1051:
1052: The user data parameter is placed in a ConnectResponse PDU, which is
1053: put on the input queue for the serializer. If the result parameter
1054: had the value user-rejection, the provider enters the IDLE state.
1055: Otherwise if the parameter had the value acceptance, the provider
1056: enters the DATA state.
1057:
1058:
1059:
1060:
1061:
1062:
1063:
1064:
1065:
1066: Rose [Page 19]
1067:
1068: RFC 1085 ISO Presentation Services December 1988
1069:
1070:
1071: Event: P-U-ABORT.REQUEST primitive issued
1072:
1073: The user data parameter is placed in an Abort PDU, which is put on
1074: the input queue for the serializer. The provider enters the IDLE
1075: state.
1076:
1077:
1078: Event: user-initiated Abort PDU received
1079:
1080: The provider issues the P-U-ABORT.INDICATION primitive and enters the
1081: IDLE state.
1082:
1083:
1084: Event: any other PDU received
1085:
1086: If the PDU is not an Abort PDU, the provider constructs a provider-
1087: initiated Abort PDU, which is put on the input queue for the
1088: serializer. Regardless, The provider issues the P-P-ABORT.INDICATION
1089: primitive and enters the the IDLE state.
1090:
1091:
1092: DATA state
1093:
1094: Event: P-DATA.REQUEST primitive issued
1095:
1096: The user data parameter is placed in a UserData PDU, which is put on
1097: the input queue for the serializer. The provider remains in the DATA
1098: state.
1099:
1100:
1101: Event: P-RELEASE.REQUEST primitive issued
1102:
1103: The user data parameter is placed in a ReleaseRequest PDU, which is
1104: put on the input queue for the serializer.
1105:
1106: For the udp-based service, the provider sets the retransmission
1107: counter to a small value (e.g., 2), and now starts a small timer.
1108:
1109: Regardless, the provider enters the WAIT3 state.
1110:
1111:
1112: Event: P-U-ABORT.REQUEST primitive issued
1113:
1114: The user data parameter is placed in an Abort PDU, which is put on
1115: the input queue for the serializer. The provider enters the IDLE
1116: state.
1117:
1118:
1119:
1120:
1121:
1122: Rose [Page 20]
1123:
1124: RFC 1085 ISO Presentation Services December 1988
1125:
1126:
1127: Event: UserData PDU received
1128:
1129: The provider issues the P-DATA.INDICATION primitive and remains in
1130: the DATA state.
1131:
1132:
1133: Event: ReleaseRequest PDU received
1134:
1135: The provider issues the P-RELEASE.INDICATION primitive, and enters
1136: the WAIT4 state.
1137:
1138:
1139: Event: user-initiated Abort PDU received
1140:
1141: The provider issues the P-U-ABORT.INDICATION primitive and enters
1142: the IDLE state.
1143:
1144:
1145: Event: any other PDU received
1146:
1147: If the PDU is not an Abort PDU, the provider constructs a provider-
1148: initiated Abort PDU, which is put on the input queue for the
1149: serializer. Regardless, the provider issues the P-P-ABORT.INDICATION
1150: primitive and enters the the IDLE state.
1151:
1152:
1153: WAIT3 state
1154:
1155: Event: P-U-ABORT.REQUEST primitive issued
1156:
1157: The user data parameter is placed in an Abort PDU, which is put on
1158: the input queue for the serializer. The provider enters the IDLE
1159: state.
1160:
1161:
1162: Event: ReleaseResponse PDU received
1163:
1164: For the udp-based service, the timer is cancelled. The provider
1165: issues the P-RELEASE.CONFIRMATION primitive and enters the IDLE
1166: state.
1167:
1168:
1169: Event: user-initiated Abort PDU received
1170:
1171: The provider issues the P-U-ABORT.INDICATION primitive and enters the
1172: IDLE state.
1173:
1174:
1175:
1176:
1177:
1178: Rose [Page 21]
1179:
1180: RFC 1085 ISO Presentation Services December 1988
1181:
1182:
1183: Event: any other PDU received
1184:
1185: If the PDU is not an Abort PDU, the provider constructs a provider-
1186: initiated Abort PDU, which is put on the input queue for the
1187: serializer. Regardless, the provider issues the P-P-ABORT.INDICATION
1188: primitive and enters the the IDLE state.
1189:
1190:
1191: Event: timer expires
1192:
1193: The provider decrements the retransmission counter. If the resulting
1194: value is less than or equal to zero, the provider constructs a
1195: provider-initiated Abort PDU, which is put on the input queue for the
1196: serializer. It then issues the P-P-ABORT.INDICATION primitive and
1197: enters the IDLE state. Otherwise, a ReleaseRequest PDU is put on the
1198: input queue for the serializer, the small timer is started again, and
1199: the provider remains in the WAIT3 state.
1200:
1201:
1202: WAIT4 state
1203:
1204: Event: P-RELEASE.RESPONSE primitive issued
1205:
1206: The user data parameter is placed in a ReleaseResponse PDU, which is
1207: put on the input queue for the serializer. The provider now enters
1208: the IDLE state.
1209:
1210: Event: P-U-ABORT.REQUEST primitive issued
1211:
1212: The user data parameter is placed in an Abort PDU, which is put on
1213: the input queue for the serializer. The provider now enters the IDLE
1214: state.
1215:
1216:
1217: Event: user-initiated Abort PDU received
1218:
1219: The provider issues the P-U-ABORT.INDICATION primitive and enters the
1220: IDLE state.
1221:
1222:
1223: Event: any other PDU received
1224:
1225: If the PDU is not an Abort PDU, the provider constructs a provider-
1226: initiated Abort PDU, which is put on the input queue for the
1227: serializer. Regardless, the provider issues the P-P-ABORT.INDICATION
1228: primitive and enters the the IDLE state.
1229:
1230:
1231:
1232:
1233:
1234: Rose [Page 22]
1235:
1236: RFC 1085 ISO Presentation Services December 1988
1237:
1238:
1239: 11. Directory Services
1240:
1241: Although not properly part of the presentation service, this memo
1242: assumes and specifies a minimal Directory service capability for use
1243: by the application-entity.
1244:
1245: The function of the Directory Service Element is to provide two
1246: mappings: first, a service name is mapped into an application entity
1247: title, which is a global handle on the service; and, second, the
1248: application-entity title is mapped onto a presentation address.
1249:
1250: The structure of presentation addresses were defined in Section 5.
1251:
1252: The structure of application-entity titles is less solidly agreed
1253: upon at the present time. Since objects of this type are not
1254: interpreted by the presentation service, this memo does not specify
1255: their structure. If the DIS version of association control is being
1256: used, then use of an OBJECT IDENTIFIER will suffice. If the IS
1257: version is being employed, then application-entity titles consist of
1258: two parts: an application-process title and an application-entity
1259: qualifier. It is suggested that the AP-Title use an OBJECT
1260: IDENTIFIER and that the AE-Qualifier use NULL.
1261:
1262: This memo requires the following mapping rules:
1263:
1264: 1. The service name for an OSI application-entity using the
1265: mechanisms proposed by this memo is:
1266:
1267: <designator> "-" <qualifier>
1268:
1269: where <designator> is a string denoting either domain name or a
1270: 32-bit IP address, and <qualifier> is a string denoting the type
1271: of application-entity desired, e.g.,
1272:
1273: "gonzo.twg.com-mgmtinfobase"
1274:
1275: 2. Any locally defined mapping rules may be used to map the
1276: service designation into an application-entity title.
1277:
1278: 3. The application-entity title is then mapped into a
1279: presentation address, with uninterpreted transport, session, and
1280: presentation selectors, and one or more network addresses, each
1281: containing:
1282:
1283: -the 32-bit IP address resolved from the <designator> portion
1284: of the service name,
1285:
1286: - a set indicating which transport services are available
1287:
1288:
1289:
1290: Rose [Page 23]
1291:
1292: RFC 1085 ISO Presentation Services December 1988
1293:
1294:
1295: at the IP address,
1296:
1297: - the 16-bit port number resolved from the <qualifier>
1298: portion of the service name (using the Assigned Numbers
1299: document), and
1300:
1301: - optionally, a presentation selector, which is an
1302: uninterpreted sequence of octets.
1303:
1304: The method by which the mappings are obtained are straight-forward.
1305: The directory services element employs the Domain Name System along
1306: with a local table which may be used to resolve the address employing
1307: local rules.
1308:
1309: In the simplest of implementations, the DNS is used to map the
1310: <designator> to an IP address, and to fill-in the set of transport
1311: services available at the IP address. The port number is found in a
1312: local table derived from the current Assigned Numbers document.
1313: Finally, the presentation selector is empty.
1314:
1315: A more ambitious implementation would use a local table to perhaps
1316: provide a presentation selector. This would be useful, e.g., in
1317: "proxy" connections. The network address would resolve to the proxy
1318: agent for the non-IP device, and the presentation selector would
1319: indicate to the proxy agent the particular non-IP device desired.
1320: This implies, of course, that the local table and the proxy agent
1321: bilaterally agree as to the interpretation of each presentation
1322: selector.
1323:
1324: 12. Remarks
1325:
1326: To begin, if one really wanted to implement ISO applications in a
1327: TCP/IP-based network, then the method proposed by [RFC1006] is the
1328: preferred method for achieving this. However, in a constrained
1329: environment, where it is necessary to host an application layer
1330: entity with a minimal amount of underlying OSI infrastructure, this
1331: memo proposes an alternative mechanism. It should be noted that an
1332: OSI application realized using this approach can be moved directly to
1333: an [RFC1006]-based environment with no modifications.
1334:
1335: A key motivation therefore is to minimize the size of the alternate
1336: underling infrastructure specified by this memo. As more and more
1337: presentation services functionality is added, the method proposed
1338: herein would begin to approximate the ISO presentation protocol.
1339: Since this in contrary to the key motivation, featurism must be
1340: avoided at all costs.
1341:
1342:
1343:
1344:
1345:
1346: Rose [Page 24]
1347:
1348: RFC 1085 ISO Presentation Services December 1988
1349:
1350:
1351: 13. Acknowledgements
1352:
1353: Several individuals contributed to the technical quality of this
1354: memo:
1355:
1356: Karl Auerbach, Epilogue Technologies
1357: Joseph Bannister, Unisys
1358: Amatzia Ben-Artzi, Sytek
1359: Stephen Dunford, Unisys
1360: Lee Labarre, MITRE
1361: Keith McCloghrie, The Wollongong Group
1362: Jim Robertson, Bridge Communications
1363: Glenn Trewitt, Stanford University
1364:
1365: 14. References
1366:
1367: [ISO7498] Information Processing Systems - Open Systems
1368: Interconnection, "Basic Reference Model", October, 1984.
1369:
1370: [ISO8509] Information Processing Systems - Open Systems
1371: Interconnection, " Service Conventions".
1372:
1373: [ISO8650] Information Processing Systems - Open Systems
1374: Interconnection, " Protocol Specification for the
1375: Association Control Service Element (Final Text
1376: of DIS 8650)", January, 1988.
1377:
1378: [ISO8822] Information Processing Systems - Open Systems
1379: Interconnection, " Connection Oriented Presentation
1380: Service Definition (Final Text of DIS 8822)",
1381: April, 1988.
1382:
1383: [ISO8823] Information Processing Systems - Open Systems
1384: Interconnection, " Connection Oriented Presentation
1385: Protocol Specification (Final Text of DIS 8822)",
1386: April, 1988.
1387:
1388: [ISO8824] Information Processing Systems - Open Systems
1389: Interconnection, " Specification of Abstract Syntax
1390: Notation One (ASN.1)", December, 1987.
1391:
1392: [ISO8825] Information Processing Systems - Open Systems
1393: Interconnection, "Specification of basic encoding rules
1394: for Abstract Syntax Notation One (ASN.1)",
1395: December, 1987.
1396:
1397: [ISO9072/2] Information Processing Systems - Text Communication
1398: MOTIS, " Remote Operations Part 2: Protocol
1399:
1400:
1401:
1402: Rose [Page 25]
1403:
1404: RFC 1085 ISO Presentation Services December 1988
1405:
1406:
1407: Specification (Working Document for DIS 9072/2)",
1408: November, 1987.
1409:
1410: [RFC768] Postel, J., "User Datagram Protocol", RFC 768, USC/ISI,
1411: 28 August 1980.
1412:
1413: [RFC791] Postel, J., "Internet Protocol - DARPA Internet Program
1414: Protocol Specification", RFC 791, USC/ISI,
1415: September 1981.
1416:
1417: [RFC793] Postel, J., "Transmission Control Protocol - DARPA
1418: Internet Program Protocol Specification", RFC 793,
1419: USC/ISI, September 1981.
1420:
1421: [RFC1006] Rose, M., and D. Cass, "ISO Transport 1 on Top of the
1422: TCP Version: 3", Northrop Research and Technology
1423: Center, May 1987.
1424:
1425: Appendix A:
1426:
1427: Abstract Syntax Definitions
1428:
1429: RFC1085-PS DEFINITIONS ::=
1430:
1431: BEGIN
1432:
1433: PDUs ::=
1434: CHOICE {
1435: connectRequest
1436: ConnectRequest-PDU,
1437:
1438: connectResponse
1439: ConnectResponse-PDU,
1440:
1441: releaseRequest
1442: ReleaseRequest-PDU,
1443:
1444: releaseResponse
1445: ReleaseResponse-PDU,
1446:
1447: abort
1448: Abort-PDU,
1449:
1450: userData
1451: UserData-PDU,
1452:
1453: cL-userData
1454: CL-UserData-PDU
1455:
1456:
1457:
1458: Rose [Page 26]
1459:
1460: RFC 1085 ISO Presentation Services December 1988
1461:
1462:
1463: }
1464:
1465:
1466:
1467: -- connect request PDU
1468:
1469: ConnectRequest-PDU ::=
1470: [0]
1471: IMPLICIT SEQUENCE {
1472: version[0] -- version-1 corresponds to to this
1473: memo
1474: IMPLICIT INTEGER { version-1(0) },
1475:
1476: reference
1477: SessionConnectionIdentifier,
1478:
1479: calling
1480: PresentationSelector
1481: OPTIONAL,
1482:
1483: called[2]
1484: IMPLICIT PresentationSelector
1485: OPTIONAL,
1486:
1487: asn[3] -- the ASN for PCI #1
1488: IMPLICIT OBJECT IDENTIFIER,
1489:
1490: user-data
1491: UserData-PDU
1492: }
1493:
1494: SessionConnectionIdentifier ::=
1495: [0]
1496: SEQUENCE {
1497: callingSSUserReference
1498: T61String,
1499:
1500: commonReference
1501: UTCTime,
1502:
1503: additionalReferenceInformation[0]
1504: IMPLICIT T61String
1505: OPTIONAL
1506: }
1507:
1508: PresentationSelector ::=
1509: [1]
1510: IMPLICIT OCTET STRING
1511:
1512:
1513:
1514: Rose [Page 27]
1515:
1516: RFC 1085 ISO Presentation Services December 1988
1517:
1518:
1519: -- connect response PDU
1520:
1521: ConnectResponse-PDU ::=
1522: [1]
1523: IMPLICIT SEQUENCE {
1524: reference -- present only in the udp-based
1525: -- service
1526: SessionConnectionIdentifier
1527: OPTIONAL,
1528:
1529: responding
1530: PresentationSelector
1531: OPTIONAL,
1532:
1533: reason[2] -- present only if the connection
1534: -- was rejected
1535: IMPLICIT Rejection-reason
1536: OPTIONAL,
1537:
1538: user-data -- present only if reason is absent
1539: -- OR has the
1540: -- value rejected-by-responder
1541: UserData-PDU
1542: OPTIONAL
1543: }
1544:
1545: Rejection-reason ::=
1546: INTEGER {
1547: rejected-by-responder(0)
1548: called-presentation-address-unknown(1),
1549: local-limit-exceeded(3),
1550: protocol-version-not-supported(4),
1551: }
1552:
1553:
1554: -- release request PDU
1555:
1556: ReleaseRequest-PDU ::=
1557: [2]
1558: IMPLICIT SEQUENCE {
1559: reference -- present only in the udp-based
1560: -- service
1561: SessionConnectionIdentifier
1562: OPTIONAL,
1563:
1564: user-data
1565: UserData-PDU
1566: }
1567:
1568:
1569:
1570: Rose [Page 28]
1571:
1572: RFC 1085 ISO Presentation Services December 1988
1573:
1574:
1575: -- release response PDU
1576:
1577: ReleaseResponse-PDU ::=
1578: [3]
1579: IMPLICIT SEQUENCE {
1580: reference -- present only in the udp-based
1581: -- service
1582: SessionConnectionIdentifier
1583: OPTIONAL,
1584:
1585: user-data
1586: UserData-PDU
1587: }
1588:
1589: -- abort PDU
1590:
1591: Abort-PDU ::=
1592: [4]
1593: SEQUENCE {
1594: reference -- present only in the udp-based
1595: -- service
1596: SessionConnectionIdentifier
1597: OPTIONAL,
1598:
1599: user-data -- MAY BE present on user-initiated abort
1600: UserData-PDU
1601: OPTIONAL,
1602:
1603: reason[1] -- ALWAYS present on provider-initiated abort
1604: IMPLICIT Abort-reason
1605: OPTIONAL
1606: }
1607:
1608: Abort-reason ::=
1609: INTEGER {
1610: unspecified(0),
1611: unrecognized-ppdu(1),
1612: unexpected-ppdu(2),
1613: unrecognized-ppdu-parameter(4),
1614: invalid-ppdu-parameter(5),
1615: reference-mismatch(9)
1616: }
1617:
1618:
1619: -- data PDU
1620:
1621: UserData-PDU ::=
1622: [5] -- this is the ASN.1 object
1623:
1624:
1625:
1626: Rose [Page 29]
1627:
1628: RFC 1085 ISO Presentation Services December 1988
1629:
1630:
1631: ANY -- if it is a top-level PDU, it
1632: -- is in PCI #1, otherwise PCI #3
1633:
1634:
1635: -- data PDU for the udp-based service
1636:
1637: CL-UserData-PDU ::=
1638: [6]
1639: IMPLICIT SEQUENCE {
1640: reference
1641: SessionConnectionIdentifier,
1642:
1643: user-data[0] -- this is the ASN.1 object
1644: ANY -- it is always in PCI #1
1645: }
1646:
1647: END
1648:
1649: Appendix B:
1650:
1651: Example of Serialization
1652:
1653:
1654: Consider the following call to ROSE:
1655:
1656: RO-INVOKE (operation number = 5
1657: operation class = synchronous
1658: argument = NONE
1659: invocation identifier = 1
1660: linked invocation id. = NONE
1661: priority = 0)
1662: .REQUEST
1663:
1664: Ultimately, ROSE will use the P-DATA service:
1665:
1666: P-DATA (user data = {
1667: 1, -- this is the PCI
1668: { -- this is the ASN.1 object
1669: invokeID 1,
1670: operation-value 5,
1671: argument {}
1672: }
1673: })
1674: .REQUEST
1675:
1676: The presentation provider will construct a UserData PDU and send this
1677: via the transport connection:
1678:
1679:
1680:
1681:
1682: Rose [Page 30]
1683:
1684: RFC 1085 ISO Presentation Services December 1988
1685:
1686:
1687: [5] {
1688: {
1689: 1,
1690: 5,
1691: {}
1692: }
1693: }
1694:
1695: Applying the basic encoding rules for ASN.1, we have an stream of 12
1696: octets.
1697:
1698: a5 0a [5]
1699: tag len
1700:
1701: a0 08 [0]
1702: tag len
1703: 02 01 01 invokeID 1
1704: tag len value
1705:
1706: 02 01 05 operation-value 5
1707: tag len value
1708:
1709: 30 00 argument NULL
1710: tag len
1711:
1712: Of course, in actual use, the argument would not be NONE and this
1713: could be expected to dominate the size of the UserData PDU. However,
1714: it is worth nothing that the overhead of the encoding mechanism used
1715: is on the order of 10 octets, hardly a staggering amount!
1716:
1717: Appendix C:
1718:
1719: Determination of Network Called Address
1720:
1721: As described in Section 10, when the P-CONNECT.REQUEST primitive is
1722: issued the presentation provider must determine which of the network
1723: addresses present in the called presentation address parameter to use
1724: for the presentation connection. The first step in this
1725: determination is to examine the quality of service parameter and
1726: consider only those network addresses which support the corresponding
1727: transport service. In practice, it is likely that each network
1728: address will support exactly the same transport services, so using
1729: quality of service as a discriminant will either permit all or none
1730: or the network addresses present to be selected. This appendix
1731: describes a local policy which might be employed when deciding which
1732: network address to use.
1733:
1734: The policy distinguishes between "underlying failures" and
1735:
1736:
1737:
1738: Rose [Page 31]
1739:
1740: RFC 1085 ISO Presentation Services December 1988
1741:
1742:
1743: "connection establishment failures". An "underlying failure" occurs
1744: when, using the desired transport service, the initiating
1745: presentation provider is unable to contact the responding
1746: presentation provider. For the tcp-based service, this means that a
1747: TCP connection could not be established for some reason. For the
1748: udp-based service, it means that a response was not received before
1749: final time-out. In contrast, a "connection establishment failure"
1750: occurs when the responding presentation provider can be contacted,
1751: but the presentation connection is rejected by either the
1752: presentation provider or the correspondent presentation user.
1753:
1754: The policy is simple: starting with the first network address
1755: present, attempt the connection procedure. If the procedure fails
1756: due to an "underlying failure", then the next network address in the
1757: list is tried. This process is repeated until either an underlying
1758: connection is established or all network addresses are exhausted.
1759: If, however, a "connection establishment failure" occurs, then the
1760: presentation provider immediately indicates this failure to the
1761: presentation user and no further network addresses are considered.
1762:
1763: Note that this is only one conformant policy of many. For example,
1764: the presentation provider may wish to order network addresses based
1765: on the "intensity" associated with the members present in the set of
1766: transport services for each network address.
1767:
1768: Author's Address:
1769:
1770: Marshall Rose
1771: The Wollongong Group
1772: 1129 San Antonio Road
1773: Palo Alto, CA 94303
1774:
1775: Phone: (415) 962-7100
1776:
1777: EMail: [email protected]
1778:
1779:
1780:
1781:
1782:
1783:
1784:
1785:
1786:
1787:
1788:
1789:
1790:
1791:
1792:
1793:
1794: Rose [Page 32]
1795:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.