rfc1698.txt
来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,543 行 · 第 1/5 页
TXT
1,543 行
0C) and the higher pdu will appear as part of the reason code, which will start with 02. (The only remaining code is 01 = user congestion.)6.4 Data-phase TSDU This is the core of the skinny stack. The lengths shown use a particular set of choices for indefinite and definite lengths that means that the application data length only affects one field. Making the two earlier indefinite lengths definite would require more calculation - adding 4 octets after the application data is assumed to be quicker. This header is also designed to be 20 octets long, thus maintaining 4-byte alignment between transport and application buffers. Implementations are recommended to use this encoding. It is possible to rapidly match incoming data against it - if there is no mismatch until the length field, the location of the beginning of the data can be determined without further analysis. SPDUs 01 00 . - S-GIVE-TOKEN - required by basic concatenation - but no parameters 01 00 . - S-DATA - no parameters - what follows is User - Information, not User Data, so is not included in - the SPDU length fields - P-DATA PPDU - TD (why TD ? Typed-data id TTD !) 61 80 {1 - User-data [APPLICATION 1] 30 80 {2 - [SEQUENCE] PDV-list 02 01 03 - [INTEGER] pcid for application data, P-CONNECT PPDU - remembered by both sides 81 83yyyyyy xxxxxx -- [1] octet-aligned presentation data value(s) -- length of length (3 octets) then three octets yyyyyy -- for the length of the user data xxxxxx 00 00 }2 - End-of-contents for end of PDV-list 00 00 }1 - End-of-contents for end of Presentation User-data If the application data is in ASN.1, and a single ASN.1 value is being sent on the TSDU, the same header can be used except for the tag on the presentation data values, which becomes A0 (= [0], constructed). If there are multiple data values to be sent, this header can be expanded in several ways: a) if there are several ASN.1 values from the same presentation context, they can be concatenated and treated as an octet-aligned value (using the header as shown above, with tag 81 (or A1 - I think its primitive) or each ASN.1 value can be an itemFurniss [Page 23] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994 (tagged A0), one after the other b) if the data values are from different presentation contexts (group IV), each is in its own {2} group within the {1}. On receipt, for the simple octet-aligned case, the data value may itself have a constructed encoding - this will make the tag A1, and it will contain elements each tagged 04 (OCTET STRING). According to CULR- 1, these elements are primitive (otherwise they would be 24 of course).6.5 Closedown - release request When all is done, and you want to close down gracefully, send this on T-DATA. - FINISH SPDU 09 10 {1 - 9 identifies FINISH * Ls ? - No Transport Disconnect item - default is release Transport-connection C1 0E {2 - User data (code 193) - P-RELEASE req/ind PPDU (has no name) 61 80 {3 - [APPLICATION 1], user data, fully-encoded 30 80 {4 - [SEQUENCE] PDV-list 02 01 01 -- pcid for ACSE, remembered from setup A0 80 {5 - [0] single asn.1-type - A-RELEASE request APDU - RLRQ 62 80 {6 - [APPLICATION 2] identifies RLRQ 80 01 00 - [0] reason, value 0 means normal * La ? -- the user information field may or may not be required - ( not required for Group I) ?BE 80 {7 - [30] IMPLICIT SEQUENCE ?28 80 {8 - [EXTERNAL] -- the transfer-syntax oid is not present this time ?02 01 03 - [INTEGER] this is the pcid for the application - data ?A0 La xxxxx -- [0] single-ASN.1-type application data -- (see note at end of 6.1) ?00 00 }8 - end of EXTERNAL -- conceivably there may be several EXTERNALS, probably in -- different presentation contexts (different pcids) ?00 00 }7 - end of user information field 00 00 }6 - end of RLRQ 00 00 }5 - end of single asn.1-type 00 00 }4 - end of PDV-list 00 00 }3 - end of Presentation User-dataFurniss [Page 24] RFC 1698 ThinOSI Upper-Layers Cookbook October 19946.6 Closedown - release response On receiving a FINISH, you send this to tell the other end it is all over - Session DISCONNECT SPDU 0A Ls {1 - SI=10, DISCONNECT C1 Ls {2 - User data - P-RELEASE rsp PPDU 61 80 {3 - [APPLICATION 1], user data, fully-encoded 30 80 {4 - [SEQUENCE] PDV-list 02 01 01 -- [INTEGER] pcid for ACSE, remembered from setup A0 80 {5 - [0] single asn.1-type - A-RELEASE response APDU - RLRE 63 80 {6 - [APPLICATION 3] identifies RLRE 80 01 00 - [0] reason, value 0 means normal * La ? -- the user information field may or may not be required - (not required for Group I) ?BE 80 {7 - [30] IMPLICIT SEQUENCE ?28 80 {8 - [EXTERNAL] -- the transfer-syntax oid is not present this time ?02 01 03 - [INTEGER] this is the pcid for the application - data ?A0 La xxxxx -- [0] single-ASN.1-type application data -- (see note at end of 6.1) ?00 00 }8 - end of EXTERNAL -- conceivably there may be several EXTERNALS, probably in -- different presentation contexts (different pcids) ?00 00 }7 - end of user information field 00 00 }6 - end of RLRE 00 00 }5 - end of single asn.1-type 00 00 }4 - end of PDV-list 00 00 }3 - end of Presentation userdata6.7 Deliberate abort It is not clear whether this is any use - just clearing the Transport connection will be more effective. It goes on T-DATA, but asks for the far-side to close the T-connection. - Session ABORT SPDU 19 Ls {1 - SI of 25 is ABORT 11 01 03 - Transport Disconnect PV, code 17 -- value = '...00011'b means please -- release T-conn, user abort * Ls ? C1 11 {2 - Session User DataFurniss [Page 25] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994 - P-U-ABORT PPDU - ARU A0 80 {3 - [0] implicit sequence for normal mode A0 80 {4 - [0] presentation-context-identifier-list 30 80 {5 - [SEQUENCE] 02 01 01 - [INTEGER]pcid for ACSE 06 02 5101 - [OID] for acse transfer syntax = BER 00 00 }5 -- there will be one {6} group for each application -- presentation context that is used in this message -- if there is no user data, the {6} group can be -- omitted 30 80 {6 02 01 03 - [INTEGER] pcid for application data 06 La xxxxxx - [OID] transfer syntax for application data 00 00 }6 00 00 }4 - end of presentation-context-identifier-list 61 80 {7 - [APPLICATION 1], user data, fully-encoded 30 80 {8 - [SEQUENCE] PDV-list 02 01 01 - [INTEGER] pcid for ACSE as on CP PPDU A0 05 {9 - [0] single asn.1-type - A-ABORT APDU - ABRT 64 80 {10 - [APPLICATION 4] identifies ABRT 80 01 01 - [0] value 1 is acse-service-provider -- the user information field may or may not be required ?BE 80 {11 - [30] IMPLICIT SEQUENCE ?28 80 {12 - [EXTERNAL] -- the transfer-syntax oid is not present this time -- (according to CULR-1) ?02 01 03 - [INTEGER] this is the pcid for the application - data ?A0 La xxxxx -- [0] single-ASN.1-type application data -- (see note at end of 6.1) ?00 00 }12 - end of EXTERNAL -- conceivably there may be several EXTERNALS, probably in -- different presentation contexts (different pcids) ?00 00 }11 - end of user information field 00 00 }10 - end of ABRT 00 00 }9 - end of single asn.1-type 00 00 }8 - end of PDV-list 00 00 }7 - end of Presentation user-data 00 00 }3 - end of ARU-PPDUFurniss [Page 26] RFC 1698 ThinOSI Upper-Layers Cookbook October 19946.8 Provider abort Generated when an internal error occurs (i.e., something has gone mildly (?) wrong in the cookbook implementation). Rather than accuse anyone of protocol errors, we just abort at session. ABORT SPDU 19 03 {1 - SI=25 = ABORT SPDU 11 01 09 - Transport Disconnect PV, code 17 -- value = '...01001'b release T-conn -- no reason * Ls ?6.9 Abort accept If a Session abort (of any kind) is sent, it is possible that the far-end will send back an abort accept. If this happens, disconnect the transport. (The abort messages above do not propose that the transport connection be reused, and in this case, an abort accept is just the far-end passing the transport-disconnect initiative back.) This session message need never be sent - just disconnect transport on receiving an abort. ABORT ACCEPT SPDU 1A 00 . - SI=26 = ABORT ACCEPT SPDU, no parameters7. References [CULR-1] ISO/IEC DISP 11188-1 - Information Technology - International Standardised Profile - Common Upper Layer Requirements - Part 1: Basic Connection oriented requirements (DISP ballot ends June 1994). [CULR-3] Draft of Common Upper-layer requirements - Part 3: Minimal OSI upper layers facilities (A later draft will be proposed as ISP 11188/3). [ISO8072] Information processing systems - Open Systems Interconnection - Transport service definition; ISO, 1986. [ISO8073] Information processing systems - Open Systems Interconnection - Transport protocol specification; ISO, 1986. [ISO8326] Information processing systems - Open Systems Interconnection - Basic connection oriented session service definition; ISO, 1987 (or review copy of revised text = ISO/IEC JTC1/SC21 N4657, April 1990).Furniss [Page 27] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994 [ISO8327] Information processing systems - Open Systems Interconnection - Basic connection oriented session protocol specification; ISO, 1987 (or review copy of revised text = ISO/IEC JTC1/SC21 N4656, April 1990). [ISO8649] Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element; ISO, 1989. [ISO8650] Information processing systems - Open Systems Interconnection - Protocol specification for the Association Control Service Element; ISO, 1989. [ISO8822] Information processing systems - Open Systems Interconnection - Connection-oriented presentation service definition; ISO, 1989. [ISO8823] Information processing systems - Open Systems Interconnection - Connection-oriented presentation protocol specification; ISO, 1989. [ISO8824] Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), ISO/IEC 1990. [ISO8825] Information t⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?