ImageVerifierCode 换一换
格式:PDF , 页数:32 ,大小:122KB ,
资源ID:804878      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-804878.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ITU-T X 229-1988 REMOTE OPERATIONS PROTOCOL SPECIFICATION《远程操作 协议规范》.pdf)为本站会员(孙刚)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

ITU-T X 229-1988 REMOTE OPERATIONS PROTOCOL SPECIFICATION《远程操作 协议规范》.pdf

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

2、X.216 defines the Presentation Layer service;(d) that Recommendation X.217 defines the Association Control service;(e) that Recommendation X.218 defines the Reliable Transfer service;(f) that Recommendation X.219 defines the Remote Operations service and notation;(g) that there is a need for common

3、Remote Operations support for various applications,unanimously declaresthat this Recommendation defines the Remote Operations protocol of Open Systems Interconnection forCCITT Applications as given in the Scope and Field of Application.CONTENTS0 Introduction1 Scope and field of application2 Referenc

4、es3 Definitions4 Abbreviations5 Conventions6 Overview of the Protocol7 Elements of procedure8 Mapping to used services9 Conformance_1)Recommendation X.229 and ISO 9072-2 Information processing systems - Text Communication-RemoteOperations Part 2: Protocol specification were developed in close collab

5、oration and are technically aligned.2 Fascicle VIII.5 - Rec. X.22910 ConformanceAnnex A - ROPM State TablesAnnex B - Differences between this Recommendation and Recommendation X.410-1984Annex C - Summary of assigned object identifier values0 IntroductionThis Recommendation specifies the protocol for

6、 the services provided by an application-service-element - theRemote Operations Service Element (ROSE) - to support interactive applications in a distributed open systemsenvironment. This Recommendation is one of a set of Recommendations defining sets of application service-elementscommonly used by

7、a number of applications.Interactions between entities of a distributed application are modelled as Remote Operations, and definedusing a Remote Operations Notation. A Remote Operation is requested by one entity; the other entity attempts toperform the Remote Operation and then reports the outcome o

8、f the attempt. Remote Operations are supported by theROSE.This Recommendation is technically aligned with ISO 9072-2.1 Scope and field of applicationThis Recommendation specifies the protocol (abstract syntax) and procedures for the Remote OperationService Element (Recommendation X.219). The ROSE se

9、rvices are provided in conjunction with the AssociationControl Service Element (ACSE) services (Recommendation X.217) and the ACSE protocol (RecommendationX.227), optionally the Reliable Transfer Service Element (RTSE) services (Recommendation X.218) and the RTSEprotocol (Recommendation X.228), and

10、the presentation-service (Recommendation X.216).The ROSE procedures are defined in terms of:a) the interactions between peer ROSE protocol machines through the use of RTSE services or thepresentation-service;b) the interactions between the ROSE protocol machine and its service-user.This Recommendati

11、on specifies conformance requirements 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).Recommenda

12、tion X.209 - Specification of basic encoding 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 interconnect

13、ion for CCITT applications(see also ISO 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, notatio

14、n and service definition (see also ISO 9072-1).Recommendation X.227 - Association control protocol specification for CCITT applications (see also ISO 8650)Fascicle VIII.5 - Rec. X.229 3Recommendation X.228 - Reliable transfer: protocol specification (see also ISO 9066-2).3 Definitions3.1 Reference m

15、odel definitionsThis Recommendation is based on the concepts developed in Recommendation X.200 and makes use of thefollowing terms defined in it:a) application layer;b) application-process;c) application-entity;d) application-service-element;e) application-protocol-data-unit;f) application-protocol-

16、control-information;g) presentation-service;h) presentation-connection;i) session-service;j) session-connection;k) transfer syntax; andl) user-element.3.2 Service conventions definitionsThis Recommendation makes use of the following terms defined in Recommendation X.210:a) service-provider;b) servic

17、e-user;c) confirmed service;d) non-confirmed service;e) provider-initiated service;f) primitive;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 Reco

18、mmendation X.216:a) abstract syntax;b) abstract syntax name;c) presentation context.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 el

19、ement.4 Fascicle VIII.5 - Rec. X.2293.5 Reliable transfer definitionsThis Recommendation makes use of the following terms defined in Recommendation X.218:a) reliable transfer service element.3.6 ROSE service definitionsThis Recommendation makes use of the following terms defined in Recommendation X.

20、219:a) association-initiating-application-entity; association-initiator;b) association-responding-application-entity; association-responder;c) invoking-application-entity; invoker;d) performing-application-entity; performer;e) requestor;f) acceptor;g) linked-operations;h) parent-operation;i) child-o

21、peration;j) RO-notation;k) remote operation service element;l) ROSE-provider;m) ROSE-user;n) RTSE-user;o) remote operations.3.7 Remote operation protocol specification definitionsFor the purpose of this Recommendation the following definitions apply:3.7.1 remote-operation-protocol-machine:The protoc

22、ol machine for the remote operation service element specified in this Recommendation.3.7.2 requesting-remote-operation-protocol-machine:The remote-operation-protocol-machine whose service-user is the requestor of a particular remote operationservice element service.3.7.3 accepting-remote-operation-p

23、rotocol-machine:The remote-operation-protocol-machine whose service-user is the acceptor for a particular remote operationservice element service.4 Abbreviations4.1 Data unitsAPDU application-protocol-data-unit.Fascicle VIII.5 - Rec. X.229 54.2 Types of application-protocol-data-unitsThe following a

24、bbreviations have been given to the application-protocol-data-units defined in thisRecommendation.ROIV RO-INVOKE application-protocol-data-unitRORS RO-RESULT application-protocol-data-unitROER RO-ERROR application-protocol-data-unitRORJ RO-REJECT application-protocol-data-unit4.3 Other abbreviations

25、The following abbreviations are used in this Recommendation.AE application entiryACSE association control service elementASE application service elementRO (or ROS) remote operationsROPM remote operations protocol machineROSE remote operations service elementRT reliable transferRTSE reliable transfer

26、 service element5 ConventionsThis Recommendation employs a tabular presentation of its APDU fields. In clause 7, tables are presented foreach ROSE APDU. Each field is summarized using the following notation:M presence is mandatoryU presence is a ROSE-user optionreq source is related request primitiv

27、eind sink is related indication primitiveresp source is related response primitiveconf sink is related confirm primitivesp source or sink is the ROPMThe structure of each ROSE APDU is specified in clause 9 using the abstract syntax notation ofRecommendation X.208.6 Fascicle VIII.5 - Rec. X.2296 Over

28、view of the protocol6.1 Service provisionThe protocol specified in Recommendation provides the ROSE services defined in Recommendation X.219.These services are listed in Table 1 /X.229.TABLE 1/X.229ROSE services summaryService TypeRO-INVOKERO-RESULTRO-ERRORRO-REJECT-URO-REJECT-PNon-confirmedNon-conf

29、irmedNon-confirmedNon-confirmedProvider-initiated6.2 Use of servicesThe ROSE protocol specified in this Recommendation needs a transfer service to pass information in the formof ROSE APDUs between peer application-entities (AEs).Two transfer services may be used alternatively:a) the RTSE services, i

30、f the RTSE is included in the application-context; orb) the presentation-service, if the RTSE is not included in the application-context.In both cases, an existing application-association, established and released by means of the ACSE services, isassumed.6.2.1 Use of the RTSE servicesIf the RTSE is

31、included in the application-context, this Recommendation assumes that the ROPM is the soleuser of the RT-TRANSFER service and the RT-TURN-GIVE service.The initiating AE may only request the release of the application-association by means of the RT-CLOSEservice if it possesses the turn. Therefore the

32、 RTSE-user and the ROPM are the user of the RT-TURN-PLEASEservice.The ROPM is the user of the RT-U-ABORT and RT-P-ABORT services.6.2.2 Use of the presentation-serviceIf the RTSE is not included in the application context, the ROPM is a user of the P-DATA service.6.3 ModelThe remote-operation-protoco

33、l-machine (ROPM) communicates with its service-user by means of primitivesdefined in Recommendation X.219. Each invocation of the ROPM controls a single application-association.The ROPM is driven by ROSE service request primitives from its service-user, and by indication and confirmprimitives of the

34、 RTSE services, or the presentation-service. The ROPM, in turn, issues indication primitives to itsservice-user, and request primitives on the used RTSE services, or the presentation-service. If the RTSE is included inthe application-context, the RT-TRANSFER indication, RT-TRANSFER request and RT-TR

35、ANSFER confirmprimitives are used. In the case of an application-context excluding RTSE, the presentation-service P-DATA request,and P-DATA indication primitives are used. In this case the transfer is not confirmed.Fascicle VIII.5 - Rec. X.229 7The reception of an ROSE service primitive, or of an RT

36、SE service or of a presentation-service primitive, andthe generation of dependent actions are considered to be individual.During the exchange of APDUs, 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

37、 this Recommendation.During the execution of operations, the existence of an application-association between the peer AEs ispresumed. How this application-association is established and released is beyond the scope of this Recommendation(see Recommendations X.219, X.217, X.227, X.218 and X.228).Note

38、 - Each application-association may be identified in an end system by an internal, implementationdependent mechanism so that the ROSE service-user and the ROPM can refer to it.7 Elements of procedureThe ROSE protocol consists of the following elements of procedure:a) invocation;b) return-result;c) r

39、eturn-error;d) user-reject;e) provider-reject.In the following clauses, a summary of each of these elements of procedure is presented. This consists of asummary of the relevant APDUs, and high-level overview of the relationship between the ROSE service primitives, theAPDUs involved, and the transfer

40、 service that is used.The generic terms transfer service, transfer service-provider, transfer request, and transfer indication are usedin the context of clause 7. Clause 8 describes how these generic service primitives are mapped either on to the RTSEservices or the presentation-service.In clause 9

41、a detailed specification of the ROSE APDUs is given using the notation defined inRecommendation X.208.7.1 Invocation7.1.1 PurposeThe invocation procedure is used by one AE (the invoker) to request an operation to be performed by theother AE (the performer).7.1.2 APDUs usedThe invocation procedure us

42、es the RO-INVOKER (ROIV) APDU.The fields of the ROIV APDU are listed in Table 2/X.229.TABLE 2/X.229ROIV APDU fieldsField name Presence Source SinkInvoke-IDLinked-IDOperation-valueArgumentMUMUreqreqreqreqindindindind8 Fascicle VIII.5 - Rec. X.2297.1.3 Invocation procedureThis procedure is driven by t

43、he following events:a) an RO-INVOKE request primitive from the requestor;b) an ROIV APDU as user-data of a transfer indication primitive.7.1.3.1 RO-INVOKE request primitiveThe requesting ROPM forms an ROIV APDU from the parameter values of the RO-INVOKE requestprimitive. It issues a transfer request

44、 primitive. The user-data parameter of the transfer request primitive contains theROIV APDU.The requesting ROPM waits either for a transfer indication primitive from the transfer service-provider or anyother primitive from the requestor.7.1.3.2 ROIV APDUThe accepting ROPM receives an ROIV APDU from

45、its peer as user-data on a transfer indication primitive. Ifany of the fields of the ROIV APDU are unacceptable to this ROPM, the provider-reject procedure is performed, andno RO-INVOKE indication primitive is issued by the ROPM.If the ROIV APDU is acceptable to the accepting ROPM, it issues an RO-I

46、NVOKE indication primitive to theacceptor. The RO-INVOKE indication primitive parameters are derived from the ROIV APDU.The accepting ROPM waits either for a transfer indication primitive from the transfer service-provider or anyother primitive from the acceptor.7.1.4 Use of the ROIV APDU fieldsThe

47、ROIV fields are used as follows.7.1.4.1 Invoke-IDThis is the Invoke-ID parameter value of the RO-INVOKE request primitive. lt appears as the Invoke-IDparameter value of the RO-INVOKE indication primitive.The value of this field is transparent to the ROPM, however the value may be used in the provide

48、r rejectprocedure.7.1.4.2 Linked-IDThis is the Linked-ID parameter value of the RO-INVOKE request primitive. It appears as the Linked-IDparameter value of the RO-INVOKE indication primitive.The value of this field is transparent to the ROPM.7.1.4.3 Operation-valueThis is the Operation-value paramete

49、r value of the RO-INVOKE request primitive. lt appears as theOperation-value parameter value of the RO-INVOKE indication primitive.The value of this field is transparent to the ROPM.7.1.4.4 ArgumentThis is the Argument parameter value of the RO-INVOKE request primitive. It appears as the Argumentparameter value of the RO-INVOKE indication primitive.The value of this field is transparent to the ROPM.Fascicle VIII.5 - Rec. X.229 97.2 Return-result7.2.1 PurposeThe return-result procedure is used by one AE (the performer) to request the transfer of the result of asuccessfully perf

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1