CAN CSA-ISO IEC 8878-1995 Information Technology - Telecommunications and Information Exchange between Systems - Use of X 25 to Provide the OSI Connection-Mode Network Service (Inc.pdf

1、I NTERNAT IO NAL STANDARD lSO/IEC 8878 Second edition 1992-1 2-1 5 (Reaffirmed 2004) Information technology - Telecommunications and information exchange between systems - Use of X.25 to provide the OS1 Connection-mode Network Service Technologies de !information - Tdecommunications et echange dinfo

2、rmations entre systemes - Utilisation du profocole X. 25 pour fournir le service de reseau OS1 en mode connexion National Standard of Canada CAN/CSA-ISO/IE C-8878-95 International Standard ISO/IEC 8878:1992 has been a do p t e d, without m o di f i ca t ion, as CAN/CSA-ISO/IEC- 1 8878-95, which has

3、been approved as a National Standard of Canada by the Standards Council of Canada. February 1995 Reference number ISO/IEC 8878:1992(E) Information technology Telecommunications and information exchange between systems Use of X.25 to provide the OSI Connection-mode Network ServiceTechnical Corrigendu

4、m 3:2013 (IDT) toNational Standard of CanadaCAN/CSA-ISO/IEC 8878-95(ISO/IEC 8878:1992, IDT)NOT FOR RESALE. / PUBLICATION NON DESTINE LA REVENTE.Standards Update ServiceTechnical Corrigendum 3:2013 toCAN/CSA-ISO/IEC 8878-95January 2013Title: Information technology Telecommunications and information e

5、xchange between systems Use of X.25 to provide the OSI Connection-mode Network ServicePagination: 1 pageTo register for e-mail notification about any updates to this publicationgo to shop.csa.caclick on CSA Update ServiceThe List ID that you will need to register for updates to this publication is 2

6、410243.If you require assistance, please e-mail techsupportcsagroup.org or call 416-747-2233.Visit CSA Groups policy on privacy at csagroup.org/legal to find out how we protect your personal information.INTERNATIONAL STANDARD ISO/IEC 8878:4992 TECHNICAL CORRIGENDUM 3 Published 1996-03-15 INTERNATION

7、AL ORGANIZATION FOR STANDARDIZATION*MEjIlYHAPOP.HA OPrAHM3AUMR i-l0 CTAHJlAPTl43AUMW ORGANISATION INTERNATIONALE DE NORMALISATION INTERNATIONAL ELECTROTECHNICAL COMMISSlON*ME)K/I.YHAPODHAfl OPfAHM3AUMfl no CTAHnAPTU3ALMM * ORGANISAT 0% IhlTERNATIONALL DE NORMA?15AT10N INTER N AT ION A L EL ECT R OT

8、E C H N I C A L C 0 M MI S S ION . M E Mfl Y F A POa H A P 3 n E KT POT EX H M 4 F C Initial Domain Part f) Authority and Format Identifier g) Initial Domain Identifier h) Domain Specific Part 3.4 X.25 definitions The following terms, as developed in the X.25 Packet Layer Protocol (CCITT Rec. X.25 1

9、 ISOAEC 8208), are used: a) virtual circuit b) Virtual Call c) logical channel d) Packet Layer e) Data Terminal Equipment f) Data Circuit-terminating Equipment g) DXE (either a DTE or a DCE) 3.5 X.96 definitions The following terms, as defined in CClTT Rec. X.96, are used: a) Category C call progres

10、s signal b) Category D call progress signal 4. Abbreviations 4.1 Network Service abbreviations AF I CONS DSP ID1 IDP N NC Nt NPAl NS NSAP Authority and Format Identifier Connection-Mode Network Service Domain Specific Part Initial Domain Identifier Initial Domain Part Network Network-connection Netw

11、ork Layer Network Protocol Address Information Network Service Network Service Access Point 3 ISO/IEC 8878:1992() 0 ISO/IEC 4.2 X.25 AEF AF 6-MTCN 6-TCN D-bit DCE DTE EDN EETDN FPF GFI LC M-bit MBS PLP P(R) P(S) PVC Q- bit TDSAI VC OS1 Open Systems Interconnection QOS Quality of Service SNPA Subnetw

12、ork Point of Attachment a I bbreviations Address Extension Facility Address Field Basic Minimum Throughput Class Negotiation (Facility) Basic Throughput Class Negotiation (Facility) Delivery Confirmation bit Data Circuit-terminating Equipment Data Terminal Equipment Expedited Data Negotiation (Facil

13、ity) End-to-End Transit Delay Negotiation (Facility) Facility Parameter Field General Format Identifier Logical Channel More Data bit M- bit Sequence Packet Layer Protocol Packet receive sequence number Packet send sequence number Permanent Virtual Circuit Qualifier bit Transit Delay Selection And I

14、ndication (Facility) Virtual Call 5. Overview The Network Service (NS) provides for the transparent transfer of data between NS users. It makes invisible to these NS users the way in which supporting communications resources are utilized to achieve this transfer. 5.4 Elements of the X.25PLP-1984 use

15、d to support the OS1 CONS The X.25/PLP-1984, as defined by CClTT Rec. X.25 I ISOAEC 8208, provides a specific realization for the transparent transfer of data between NS users of the CONS. The elements of this protocol to be considered are a) the virtual-circuit types; b) the packet types and fields

16、 to be mapped to the primitives and parameters of the OS1 CONS; c) the optional user facilities and CCllT-Specified DTE facilities. Of the two types of virtual circuits defined in CCllT Rec. X.25 1 ISO/IEC 8208, the use of Virtual Calls (VCs) is mapped to the network connection (NC) establishment an

17、d release phases of the OS1 CONS in clauses 6 and 7 and to the data transfer phase in clauses 8-1 1. (The corresponding mapping for PVCs is given in Annex C.) Table 1 lists the X.25/PLP-1984 packets and associated fields that shall be used when supporting the OS1 CONS. In addition, the following opt

18、ional user facilities and CCIlT-Specified DTE facilities shall be used and/or agreed to: a) optional user facilities: 1) Fast Select (facility used; when operating in a DTE-to-DTE environment without an intervening packet- switched network, the use of the Fast Select Facility shall also be agreed to

19、 by the two DTEs); 2) Fast Select Acceptance (facility agreed to if operating in a packet-switched network environment); 3) Basic Throughput Class Negotiation (facility agreed to and used); 4) Transit Delay Selection And Indication (facility used). b) CCIlT-Specified DTE facilities: 4 0 ISO/IEC ISO/

20、IEC 8878:t 992(E) Table I - Packets and fields of the X.25/PtP-1984 used to support the OS1 CONS i Packet Types) CALL REQUEST INCOMING CALL CALL ACCEPTED CALL CONNECTED CLEAR REQUEST CLEAR INDICATION F- INTERRUPT RECEIVE READY6) RECEIVE NOT READY6) REJECT6) (if agreed to) RESET REQUEST RESET INDICAT

21、tON RESTART I N D I CAT ION Fields2) General Format Identifie?), Address Field, Facility Field, Call and Called User Data Field4) Clearing Cause Field, Diagnostic Code Field, Address Field, Facility Field, Clear User Data Field4) D-bit, M-bit, P(S)5), P(R)5), User Data field4) tnterrupt User Data Fi

22、eld4) P( R)5) Resetting Cause Field, Diagnostic Code Field Restarting Cause Field, Diagnostic Code Field Notes to Table 1 : 1 -The packets shown in the table are used in support of the primitives of the OS1 CONS. Other packets not shown in the table (Le., CLWR CONFIRMATION, INTERRUPT CONFIRMATION, R

23、ESET CONFIRMATION, and RESTART CONFIRMA- TION packets) are essential to the use of the packets shown. Yet other packets (i.e., RESTART REQUEST, DIAGNOSTIC, REGISTRATION REQUEST, and REGISTRATION CONFIRMATION packets) have no relationship to the provision of the OS! CONS. 2 - The information in the f

24、ields shown in the table have a direct relationship to the parameters associated with the primitives of the OS1 CONS. Other fields not shown in the table (e.g., the Logical Channel Identifier, the Packet Type Identifier, the Q-bit, the Address Length Fields, and the Facility Length Field) are essent

25、ial to the use of the appropriate packets. 3 - Bit 7 of octet 1 of the General Format Identifier (GFI) in these packets is used to negotiate the overall availability of the Delivery Confirmation bit (D-bit) in support of the Receipt Confirmation Service. As such, this bit has no specific fieid-name

26、as defined in the X.25/PLP-1984, 4 -All user data fields are octet aligned. 5 - The P(S) and P(R) fields are essential to the operation of the X.25/PLP-1984 in providing the Receipt Confirmation Service. 6-The action implied by these packets has no relationship to the primitives of the OS1 CONS. How

27、ever, the P(R) field is essential to the operation of the X.25/PLP-1984 in providing the Receipt Confirmation Service. 1) Called Address Extension (facility used); 2) Calling Address Extension (facility used); 3) End-to-End Transit Delay Negotiation (facility used); 4) Expedited Data Negotiation fac

28、ility used); 5) Basic Minimum Throughput Class Negotiation (facility used); 6) Priority (facility used with 1988 or later versions of the X.25/PLP). 5.2 General operation of the X.25/PLP-1984 for supporting the OS1 CONS The X.25/PLP-1984 can be used to provide the OS1 CONS in an end system connected

29、 to a public or private X.25 packet-switched subnetwork. It can also be used in environments where the end system is connected to a Local Area Network or where end systems are connected by a dedicated path or by a circuit-switched connection. 5 ISO/IEC 8878:1992(E) 0 ISO/IEC As shown in Figure 2, th

30、e NS provider (more particularly, the Network Layer (NL) entity in an end system) must provide a translation between a) the primitives and parameters of the OS1 CONS; b) the packets and associated fields of the X.25/PLP-1984. END SYSTEM A END SYSTEM B NS USERS NETWORK SERVICE _-_ NS PROVIDER 1 1 I 1

31、 : 1 Pi- 1 PROTOCOL . DTE/DXE I I I C PACKET LAYER PROTOCOL INTERFACE (Note) NOTE - This interface consists of zero or more Network Layer entities providing a Network Layer relay function. Figure 2 - Operation of OS1 Connection-Mode Network Service and X.25 Packet Layer Protocol (1 984) Request and

32、response primitives are translated into packets to be transmitted across the DTWDXE interface by the NL entity. Received packets, where appropriate, are translated by the NL entity into indication and confirm primitives. Annex E provides additional considerations on the relationship between the X.25

33、 protocol procedures and the CONS primitives. NOTE -The Network Service Definition specifies valid sequences of primitives at an NC endpoint and valid parameter responses at the called NC endpoint to Receipt Confirmation negotiation, Expedited Data negotiation, and Quality of Service (QOS) parameter

34、 negotiation. The necessity for the NL entity to monitor compliance and the actions to be taken on non- compliance are a local matter, and not subject to standardization. There is also a relationship between some local mechanism used to identify a particular NC and a Logical Channel (LC) number used

35、 to identify a particular virtual circuit. This relationship is a local matter and is not discussed here. 6 0 ISO/IEC ISO/IEC 8878:1992(E) 6. Network connection establishment phase 6.1 Prim itive/Parameter and packet/f ield relationships Table 2 shows the relationships between the primitives/paramet

36、ers used during the NC establishment phase and the packetslfields associated with the call setup procedures. Table 2 - CONS:X.25/PLP-1984 mapping for the NC establishment phase CONS PRIM IT1VES : N-CON NECT request N - CO N N ECT indication N-CONNECT response N-CONNECT confirm PARAMETERS: Called Add

37、ress Calling Address Responding Address Receipt Confirmation Selection Expedited Data Selection QOS-Parameter Set NS- User-B ata X.25/PLP-I 984 PACKETS: CALL REQUEST INCOMING CALL CALL ACCEPTED CALL CONNECTED FIELDS (INCLUDING FACl LIT1 ES) : Called DTE Address Field Called Address Extension Facilit

38、y Calling DTE Address Field Calling Address Extension Facility Called DTE Address Field Called Address Extension Facility General Format Identifier) Expedited Data Negotiation Facility Basic Throughput Class Negotiation Facility2) Basic Minimum Throughput Class Negotiation Facility Transit Delay Sel

39、ection And Indication Facility End-to-End Transit Delay Negotiation Facility Priority Facility Call and Called User Data Field Fast Select Facilig) Notes to Table 2: 1 -Bit 7 of octet 1 of the GFI in call setup packets is used to negotiate the overall availability of the D-bit in support of the Rece

40、ipt Confirmation Service. As such, this bit has no specific field-name as defined in the X.251Pl-P-1984. 2 - For proper operation, this optional user facility shall also be agreed to for use on the interface. 3 - For proper operation, the Fast Select Acceptance Facility shall also be agreed to on th

41、e interface when accessing a packet-switched network. 6.2 Procedures 6.2.1 Prirnitive/Packet mapping When an NL entity receives an N-CONNECT request or an N-CONNECT response primitive from an NS user, it transmits a CALL REQUEST or a CALL ACCEPTED packet, respectively, across the DTHDXE interface. W

42、hen an NL entity receives an INCOMING CALL or a CALL CONNECTED packet, it signals an N-CONNECT indication or an N-CONNECT confirm primitive, respectively, to the NS user. 7 ISO/IEC 8878:1992( E) 0 ISO/IEC 6.2.2 Network addresses Local operation determines the contents of the Network Protocol Address

43、 Information (NPAI) and whether Network Addresses, where explicitly supplied, are mapped to and from the Address Field (AF) or the Address Extension Facilities (AEF) of X.25/PLP-1984 call setup packets. Annex F describes guidelines for the methods by which the required AF contents may be derived fro

44、m the Network Address. The permitted techniques for the placement of Network Addresses in either the AF or AEF are given in this clause. The encoding techniques to be employed are those specified in CCllT Rec. X.25 I ISO/IEC 8208 for the AF and AEF. The content of these fields shall be in the prefer

45、red binary encoding defined in CCITT Rec. X.213 I ISO/IEC 8348. Examples of encoding Network Addresses in the NPAI of the X.25/PLP-1984 are also given in Annex F. 6.2.2.1 Encoding of Network addresses 6.2.2.1.1 Use of the Address Field (AF) Under certain conditions, the Network Address, as defined i

46、n CCIlT Rec. X.213 I ISOAEC 8348, may be conveyed entirely in the AF. These conditions are a) the Network Address consists solely of the Initial Domain Part (IDP) (i.e., the Domain Specific Part (DSP) is b) the Authority and Format Identifier (AFI) can be deduced from the contents of the AF (e.g., w

47、ith knowledge of c) the Initial Domain Identifier (IDI) is the same as the Subnetwork Point of Attachment (SNPA) Address. null); the subnetwork to which the DTE is attached); When all of the above conditions are satisfied, the AF may be used to convey the semantics of the entire Network Address (the

48、 AFI is implied and the contents of the AF are equivalent to the IDI). In these cases, the AEF may also be used (see 6.2.2.1 2). NOTE -The use of the preferred binary encoding results in binary-coded decimal digits in the AF, as required by CClTT Rec. X.25 1 lSO/IEC 8208. 6.2.2.1.2 Use of the AEF If

49、 any of the conditions in 6.2.2.1 .I are net satisfied, the AEF shall be used. The Network Address, complete with AF1, is placed in the AEf (bits 8 and 7 of the first octet of the Facility Parameter Field (FPF) of the AEF are both set to zero). In this case, the contents of the AF are not defined by this International Standard. Guidelines for their derivation are given in Annex F. 6.2.2.2 Decoding of Network addresses If, after decoding the Network address as specified in the subclauses below, the Network address does not exist, then the NL entity clears the ca