📄 rfc1085.txt
字号:
connectResponse ConnectResponse-PDU, releaseRequest ReleaseRequest-PDU, releaseResponse ReleaseResponse-PDU, abort Abort-PDU, userData UserData-PDU, cL-userData CL-UserData-PDURose [Page 26]RFC 1085 ISO Presentation Services December 1988 } -- connect request PDU ConnectRequest-PDU ::= [0] IMPLICIT SEQUENCE { version[0] -- version-1 corresponds to to this memo IMPLICIT INTEGER { version-1(0) }, reference SessionConnectionIdentifier, calling PresentationSelector OPTIONAL, called[2] IMPLICIT PresentationSelector OPTIONAL, asn[3] -- the ASN for PCI #1 IMPLICIT OBJECT IDENTIFIER, user-data UserData-PDU } SessionConnectionIdentifier ::= [0] SEQUENCE { callingSSUserReference T61String, commonReference UTCTime, additionalReferenceInformation[0] IMPLICIT T61String OPTIONAL } PresentationSelector ::= [1] IMPLICIT OCTET STRINGRose [Page 27]RFC 1085 ISO Presentation Services December 1988 -- connect response PDU ConnectResponse-PDU ::= [1] IMPLICIT SEQUENCE { reference -- present only in the udp-based -- service SessionConnectionIdentifier OPTIONAL, responding PresentationSelector OPTIONAL, reason[2] -- present only if the connection -- was rejected IMPLICIT Rejection-reason OPTIONAL, user-data -- present only if reason is absent -- OR has the -- value rejected-by-responder UserData-PDU OPTIONAL } Rejection-reason ::= INTEGER { rejected-by-responder(0) called-presentation-address-unknown(1), local-limit-exceeded(3), protocol-version-not-supported(4), } -- release request PDU ReleaseRequest-PDU ::= [2] IMPLICIT SEQUENCE { reference -- present only in the udp-based -- service SessionConnectionIdentifier OPTIONAL, user-data UserData-PDU }Rose [Page 28]RFC 1085 ISO Presentation Services December 1988 -- release response PDU ReleaseResponse-PDU ::= [3] IMPLICIT SEQUENCE { reference -- present only in the udp-based -- service SessionConnectionIdentifier OPTIONAL, user-data UserData-PDU } -- abort PDU Abort-PDU ::= [4] SEQUENCE { reference -- present only in the udp-based -- service SessionConnectionIdentifier OPTIONAL, user-data -- MAY BE present on user-initiated abort UserData-PDU OPTIONAL, reason[1] -- ALWAYS present on provider-initiated abort IMPLICIT Abort-reason OPTIONAL } Abort-reason ::= INTEGER { unspecified(0), unrecognized-ppdu(1), unexpected-ppdu(2), unrecognized-ppdu-parameter(4), invalid-ppdu-parameter(5), reference-mismatch(9) } -- data PDU UserData-PDU ::= [5] -- this is the ASN.1 objectRose [Page 29]RFC 1085 ISO Presentation Services December 1988 ANY -- if it is a top-level PDU, it -- is in PCI #1, otherwise PCI #3 -- data PDU for the udp-based service CL-UserData-PDU ::= [6] IMPLICIT SEQUENCE { reference SessionConnectionIdentifier, user-data[0] -- this is the ASN.1 object ANY -- it is always in PCI #1 } ENDAppendix B:Example of Serialization Consider the following call to ROSE: RO-INVOKE (operation number = 5 operation class = synchronous argument = NONE invocation identifier = 1 linked invocation id. = NONE priority = 0) .REQUEST Ultimately, ROSE will use the P-DATA service: P-DATA (user data = { 1, -- this is the PCI { -- this is the ASN.1 object invokeID 1, operation-value 5, argument {} } }) .REQUEST The presentation provider will construct a UserData PDU and send this via the transport connection:Rose [Page 30]RFC 1085 ISO Presentation Services December 1988 [5] { { 1, 5, {} } } Applying the basic encoding rules for ASN.1, we have an stream of 12 octets. a5 0a [5] tag len a0 08 [0] tag len 02 01 01 invokeID 1 tag len value 02 01 05 operation-value 5 tag len value 30 00 argument NULL tag len Of course, in actual use, the argument would not be NONE and this could be expected to dominate the size of the UserData PDU. However, it is worth nothing that the overhead of the encoding mechanism used is on the order of 10 octets, hardly a staggering amount!Appendix C:Determination of Network Called Address As described in Section 10, when the P-CONNECT.REQUEST primitive is issued the presentation provider must determine which of the network addresses present in the called presentation address parameter to use for the presentation connection. The first step in this determination is to examine the quality of service parameter and consider only those network addresses which support the corresponding transport service. In practice, it is likely that each network address will support exactly the same transport services, so using quality of service as a discriminant will either permit all or none or the network addresses present to be selected. This appendix describes a local policy which might be employed when deciding which network address to use. The policy distinguishes between "underlying failures" andRose [Page 31]RFC 1085 ISO Presentation Services December 1988 "connection establishment failures". An "underlying failure" occurs when, using the desired transport service, the initiating presentation provider is unable to contact the responding presentation provider. For the tcp-based service, this means that a TCP connection could not be established for some reason. For the udp-based service, it means that a response was not received before final time-out. In contrast, a "connection establishment failure" occurs when the responding presentation provider can be contacted, but the presentation connection is rejected by either the presentation provider or the correspondent presentation user. The policy is simple: starting with the first network address present, attempt the connection procedure. If the procedure fails due to an "underlying failure", then the next network address in the list is tried. This process is repeated until either an underlying connection is established or all network addresses are exhausted. If, however, a "connection establishment failure" occurs, then the presentation provider immediately indicates this failure to the presentation user and no further network addresses are considered. Note that this is only one conformant policy of many. For example, the presentation provider may wish to order network addresses based on the "intensity" associated with the members present in the set of transport services for each network address.Author's Address: Marshall Rose The Wollongong Group 1129 San Antonio Road Palo Alto, CA 94303 Phone: (415) 962-7100 EMail: mrose@TWG.COMRose [Page 32]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -