ITU-T X 228-1988 RELIABLE TRANSFER PROTOCOL SPECIFICATION《可靠传送 协议规范》.pdf

1、INTERNATIONAL TELECOMMUNICATION UNION)45G134 8 TELECOMMUNICATIONSTANDARDIZATION SECTOROF ITU/0%.G0G03934%-3G0G0).4%2#/%#4)/.0)#3G0G002/(b) that Recommendation X.210 defines the service conventions for describing the services of the OSIreference model;(c) that Recommendation X.216 defines the Present

2、ation Layer service;(d) that Recommendation X.217 defines the Association Control service;(e) that Recommendation X.218 defines the Reliable Transfer service;(f) that there is a need for common Reliable Transfer support for various applications;unanimously declaresthat this Recommendation defines th

3、e Reliable Transfer protocol of Open Systems Interconnection for CCITTApplications as given in the Scope and Field of Application.CONTENTS0 Introduction1 Scope and Field of Application2 References3 Definitions4 Abbreviations5 Conventions6 Overview of the Protocol7 Elements of Procedure8 Mapping to U

4、sed Services9 Abstract Syntax Definition of APDUs10 ConformanceAnnex A - State Transition TablesAnnex B - Differences between this Recommendation and Recommendation X.410-1984Annex C - Summary of Assigned Object Identifier Values1)Recommendation X.228 and ISO 9066-2 Information processing systems -

5、Text Communication - ReliableTransfer Part 2:Protocol Specification were developed in close collaboration and are technically aligned.2 Fascicle VIII.5 - Rec. X.2280 IntroductionThis Recommendation specifies the protocol for the services provided by an application-service- element - theReliable Tran

6、sfer Service Element (RTSE) - to provide for the Reliable Transfer of Application Protocol Data Units(APDUs) between open systems. This Recommendation is one of a set of Recommendations specifying the protocols forsets of application-service-elements commonly used by a number of applications.Reliabl

7、e Transfer provides an application-independent mechanism to recover from communication and end-system failure minimizing the amount of retransmission.This Recommendation is technically aligned with ISO 9066-2.1 Scope and Field of ApplicationThis Recommendation specifies the protocol (abstract syntax

8、) and procedures for the Reliable Transfer ServiceElement services (Recommendation X.218). The RTSE services are provided in conjunction with the AssociationControl Service Element (ACSE) services (Recommendation X.217) and the ACSE protocol (Recommendation X.227),and the presentation-service (Recom

9、mendation X.216).The RTSE procedures are defined in terms of:a) the interactions between peer RTSE protocol machines through the use of ACSE and the presentation-service.b) the interactions between the RTSE protocol machine and its service-user.This Recommendation specifies conformance requirements

10、for systems implementing these procedures.2 ReferencesRecommendation X.200 - Reference Model of Open Systems Interconnection for CCITT Applications (See alsoISO 7498)Recommendation X.208 - Specification of abstract syntax notation (See also ISO 8824).Recommendation X.209 - Specification of Basic Enc

11、oding Rules for the abstract syntax notation (See also ISO 8825).Recommendation X.210 - Open Systems Interconnection Layer Service Definition Conventions (See also ISO/TR 8509).Recommendation X.216 - Presentation Service Definition for Open Systems Interconnection for CCITT Applications(See also ISO

12、 8822).Recommendation X.217 - Association Control Service Definition for CCITT Applications (See also ISO 8649).Recommendation X.218 - Reliable Transfer: Model and Service Definition (See also ISO 9066-1)Recommendation X.219 - Remote Operations: Model, Notation and Service Definition (See also ISO 9

13、072-1)Recommendation X.227 - Association Control Protocol Specification for CCITT Applications (See also ISO 8650).3 Definitions3.1 Reference Model DefinitionsThis Recommendation is based on the concepts developed in Recommendation X.200 and makes use of thefollowing terms defined in it:a) Applicati

14、on Layer;b) application-process;c) application-entity;d) application-service-element;e) application-protocol-data-unit;f) application-protocol-control-information;Fascicle VIII.5 - Rec. X.228 3g) presentation-service;h) presentation-connection;i) session-service;j) session-connection; andk) user-ele

15、mentl) two-way-alternate interactionm) transfer syntax.3.2 Service Conventions DefinitionsThis Recommendation makes use of the following terms defined in Recommendation X.210:a) service-provider;b) service-user;c) confirmed service;d) non-confirmed service;e) provider-initiated service;f) primitive;

16、g) request (primitive);h) indication (primitive);i) response (primitive); andj) confirm (primitive).3.3 Presentation Service DefinitionsThis Recommendation makes use of the following terms defined in Recommendation X.216:a) abstract syntax;b) abstract syntax name;c) presentation context;d) default c

17、ontext.3.4 Association Control DefinitionsThis Recommendation makes use of the following terms defined in Recommendation X.217:a) application-association; association;b) application context;c) Association Control Service Element; andd) X.410-1984 mode.3.5 RTSE Service DefinitionsThis Recommendation

18、makes use of the following terms defined in Recommendation X.218:a) association-initiating-application-entity; association-initiator;b) association-responding-application-entity; association-responder;c) sending-application-entity; sender;d) receiving-application-entity; receiver;e) requestor;f) acc

19、eptor;4 Fascicle VIII.5 - Rec. X.228g) Reliable Transfer Service Element;h) RTSE-user;i) RTSE-provider;j) ACSE-provider;k) monologue interaction;l) syntax-matching-services;m) Reliable Transfer;n) X.410-1984 mode; ando) normal mode.3.6 Reliable Transfer Protocol Specification DefinitionsFor the purp

20、ose of this Recommendation the following definitions apply:3.6.1 reliable-transfer-protocol-machine:The protocol machine for the Reliable Transfer Service Element specified in this Recommendation.3.6.2 requesting-reliable-transfer-protocol-machine:The reliable-transfer-protocol-machine whose RTSE-us

21、er is the requestor of a particular Reliable TransferService Element service.3.6.3 accepting-reliable-transfer-protocol-machine:The reliable-transfer-protocol-machine whose RTSE-user is the acceptor for a particular Reliable TransferService Element service.3.6.4 sending-reliable-transfer-protocol-ma

22、chine:The reliable-transfer-protocol-machine whose RTSE-user is the sender.3.6.5 receiving-reliable-transfer-protocol-machine:The reliable-transfer-protocol-machine whose RTSE-user is the receiver.3.6.6 association-initiating-reliable-transfer-protocol-machine:The reliable-transfer-protocol-machine

23、whose RTSE-user is the association-initiator.3.6.7 association-responding-reliable-transfer-protocol-machine:The reliable-transfer-protocol-machine whose RTSE-user is the association-responder.Fascicle VIII.5 - Rec. X.228 54 Abbreviations4.1 Data UnitsAPDU application-protocol-data-unit.4.2 Types of

24、 Application-protocol-data-unitsThe following abbreviations have been given to the application-protocol-data-units defined in thisRecommendation.RTAB RT-P-ABORT and RT-U-ABORT application-protocol-data-unitRTORQ RT-OPEN-REQUEST application-protocol-data-unitRTOAC RT-OPEN-ACCEPT application-protocol-

25、data-unitRTORJ RT-OPEN-REJECT application protocol-data-unitRTTR RT-TRANSFER application-protocol-data-unitRTTP RT-TOKEN-PLEASE application-protocol-data-unit4.3 Other AbbreviationsThe following abbreviations are used in this Recommendation.AE application-entityACSE Association Control Service Eleme

26、ntASE application-service-elementRTPM reliable-transfer-protocol-machineRT (or RTS) Reliable TransferRTSE Reliable Transfer Service Element5 ConventionsThis Recommendation employs a tabular presentation of its APDU fields. In clause 7, tables are presented foreach RTSE APDU. Each field is summarized

27、 using the following notation:M presence is mandatoryU presence is a RTSE service-user optionT presence is a RTPM optionreq source is related request primitiveind sink is related indication primitiveresp source is related response primitiveconf sink is related confirm primitivesp source or sink is t

28、he RTPMThe structure of each RTSE APDU is specified in clause 9 using the abstract syntax notation ofRecommendation X.208.6 Overview of the Protocol6.1 Service ProvisionThe protocol specified in this Recommendation provides the services defined in Recommendation X.218. Theseservices are listed in Ta

29、ble 1/X.228.6 Fascicle VIII.5 - Rec. X.228TABLE 1/X.228RTSE Service SummaryService TypeRT-OPEN ConfirmedRT-CLOSE ConfirmedRT-TRANSFER ConfirmedRT-TURN-PLEASE Non-confirmedRT-TURN-GIVE Non-confirmedRT-P-ABORT Provider-initiatedRT-U-ABORT Non-confirmed6.2 Use of Services6.2.1 ACSE ServicesThe RTPM req

30、uires access to the A-ASSOCIATE, A-RELEASE, A-ABORT and A-P-ABORT services. ThisRecommendation assumes that the RTPM is the sole user of these services.6.2.2 Use of the Presentation-serviceThe RTPM requires access to the P-ACTIVITY-START, P-DATA, P-MINOR-SYNCHRONIZE, P-ACTIVITY-END, P-ACTIVITY-INTER

31、RUPT, P-ACTIVITY-DISCARD, P-U-EXCEPTION-REPORT, P-ACTIVITY-RESUME, P-P-EXCEPTION-REPORT, P-TOKEN-PLEASE and P-CONTROL-GIVE services. This Recommendationassumes that the RTPM is the sole user of the above services.The RTPM requires access to local syntax-matching-services provided by the presentation

32、-service provider.This syntax-matching-service consists of:a) an encoding service enabling the transformation from the local representation of an APDU value into anencoded-APDU-value of type OCTET STRING the value of which is the representation of the APDUvalue specified by the negotiated transfer s

33、yntax;b) a decoding service enabling the transformation from an encoded-APDU-value into the local representationof the APDU value.If X.410-1984 mode or simple encoding is used by the Presentation Layer, the APDU value is encoded asASN.1 type ANY. If full encoding is used by the Presentation Layer, t

34、he APDU value is encoded as ASN.1 typeEXTERNAL. (For X.410-1984 mode, single encoding and full encoding see Recommendation X.226).This Recommendation recognizes that the ACSE services require access to the P-CONNECT, P-RELEASE,P-U-ABORT and P-P-ABORT services. This Recommendation assumes that the AC

35、SE and the RTPM are the sole usersof any of the above, or of any other, presentation-services.During the lifetime of an application-association, the underlying presentation-connections either use a singlepresentation context or multiple presentation contexts as a part of the presentation multiple de

36、fined context facility. Thechoice is determined by the use of the Single Presentation Context parameter of the RT-OPEN service as described inclause 8.1.1.1.3 and 8.1.1.1.4.6.3 ModelThe reliable-transfer-protocol-machine (RTPM) communicates with its service-user by means of primitivesdefined in Reco

37、mmendation X.218. Each invocation of the RTPM controls a single application-association.Fascicle VIII.5 - Rec. X.228 7The RTPM is driven by RTSE service request and response primitives from its service-user, and by indicationand confirm primitives from the ACSE services and the presentation-service.

38、 The RTPM, in turn, issues indication andconfirm primitives to its service-user and request and response primitives on the used ACSE services or presentation-service.The reception of an RTSE service primitive, or of an ACSE service primitive, or of a presentation-serviceprimitive, and the generation

39、 of dependent actions are considered to be indivisible.During the use of the RTSE services, the existence of both the association-initiating AE and the association-responding AE is presumed. How these AEs are created is beyond the scope of this Recommendation.During the use of the RTSE services, exc

40、ept RT-OPEN, the existence of an application-association between thepeer AEs is presumed.Note - Each application-association may be identified in an end system by an internal, implementationdependent mechanism so that the RTSE service-user, and the RTPM, and the ACSE service-provider can refer to it

41、.7 Elements of procedureThe RTSE protocol consists of the following elements of procedure:a) association-establishmentb) association-releasec) transferd) turn-pleasee) turn-givef) error reporting:f1) user-exception-reportf2) provider-exception-reportg) error handling:g1) transfer-interruptg2) transf

42、er-discardg3) association-abortg4) association-provider-aborth) error recovery:h1) transfer-resumption (for recovery from g1), or after successful h3) from g3) or g4)h2) transfer-retry (for recovery from g2)h3) association-recovery (for recovery from g3 or g4)i) abort:i1) transfer-abort (recovery fr

43、om g1) or g2) or g3) or g4) not possible)i2) provider-abort (recovery from g1) or g2) or g3) or g4) not possible)i3) user-abort.In the following clauses, a summary of each of these elements of procedure is presented. This consists of asummary of the relevant APDUs, and a high-level overview of the r

44、elationship between the RTSE service primitives andthe APDUs involved and the used presentation-service.Clause 8 describes how the service primitives are mapped on the ACSE services, and on the presentation-service.8 Fascicle VIII.5 - Rec. X.2287.1 Association-establishment7.1.1 PurposeThe associati

45、on-establishment procedure is used to establish an application-association.7.1.2 APDUs usedThe association-establishment procedures uses the RT-OPEN-REQUEST (RTORQ) APDU, the RT-OPEN-ACCEPT (RTCAC) APDU, and the RT-OPEN-REJECT (RTORJ) APDU.Note - These APDUs are also used in the association-recovery

46、 procedure.7.1.2.1 RTORQ APDUThe RT-OPEN REQUEST (RTORQ) APDU is used in the request to establish an application-association. Thefields of the RTORQ APDU are listed in Table 2/X.228.7.1.2.2 RTOAC APDUThe RT-OPEN-ACCEPT (RTOAC) APDU is used in the positive response to the request to establish anappli

47、cation-association. The fields of the RTOAC APDU are listed in Table 3/X.228.TABLE 2/X.228RTORQ APDU FieldsField name Presence Source SinkCheckpoint-size T sp spWindow-size T sp spDialogue-mode U req indUser-data (Note 1) U req indSession-connection-identifier (Note 2) T sp spApplication-protocol (N

48、ote 3) U req indNote 1 - The User-data field is used solely in the association-establishment procedure.Note 2 - The Session-connection-identifier field is used solely in the association-recovery procedure.Note 3 - The Application-protocol field is used solely in the X.410-1984 mode.TABLE 3/X.228RTOA

49、C APDU FieldsField name Presence Source SinkCheckpoint-size T sp spWindow-size T sp spUser-data (Note 1) U resp confSession-connection-identifier (Note 2) T sp spNote 1 - The User-data field is used solely in the association-establishment procedure.Note 2 - The Session-connection-identifier field is used solely in the association-recovery procedure.Fascicle VIII.5 - Rec. X.228 97.1.2.3 RTORJ APDURT-OPEN-REJECT (RTORJ) APDU is used in the negative response to the request to establish an application-association. The fields of the RTORJ APDU are listed in Table 4/X.228.TABLE 4/X.228RTORJ AP