_______________ _ Fascicle VIII.5 - Rec. X.223 The drawings contained in this recommendation have been done in Autocad Recommendation X.223 USE OF X.25 TO PROVIDE THE OSI CONNECTION-MODE NETWORK SERVICE FOR CCITT APPLICATIONS (Melbourne, 1988) The CCITT, considering (a) that Recommendation X.200 defines the Reference Model of Open Systems Interconnection for CCITT Applications; (b) that Recommendation X.210 gives the Open Systems Interconnection (OSI) Layer Service Definition Conventions; (c) that Recommendation X.213 is the Network Service Definition for Open Systems Interconnection for CCITT Applications; (d) that Recommendation X.25 describes the Interface Between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet-Mode and Connected to Public Data Networks by Dedicated Circuit; (e) that Recommendation X.96 defines the Call Progress Signals in Public Data Networks, unanimously declares (1) that the scope, field of application, references definitions, symbols and abbreviations are given in ¤¤ 1 to 4; (2) that the mapping of X.25 protocol elements to CONS primitives is overviewed in ¤ 5; (3) that the detailed mapping for the network connection establishment phase described in ¤ 6; (4) that the detailed mapping for the network connection release phase is described in ¤ 7; (5) that the detailed mapping for the data transfer phase is described in ¤¤ 8 to 11. CONTENTS 0 Introduction 1 Scope and Field of Application 2 References 3 Definitions 4 Symbols and Abbreviations 5 Overview 5.1 Elements of the X.25/PLP Used to Support the CONS 5.2 General Operation of the X.25/PLP for Supporting the CONS 6 Network Connection Establishment Phase 6.1 Primitive/Parameter and Packet/Field Relationship 6.2 Procedures 7 Network Connection Release Phase 7.1 Primitive/Parameter and Packet/Field Relationship 7.2 Procedures 8 Data Transfer Phase - Data Transfer Service 8.1 Primitive/Parameter and Packet/Field Relationship 8.2 Procedures 9 Data Transfer Phase - Receipt Confirmation Service 9.1 Primitive/Parameter and Packet/Field Relationship 9.2 Procedures 10 Data Transfer Phase - Expedited Data Transfer Service 10.1 Primitive/Parameter and Packet/Field Relationship 10.2 Procedures 11 Data Transfer Phase - Reset Service 11.1 Primitive/Parameter and Packet/Field Relationship 11.2 Procedures Appendix I - Additional Considerations of CONS Primitives Appendix II - Use of X.25/PLP NPAI Appendix III - Transit Delay Calculations Appendix IV - Differences between Recommendation X.223 and ISO 8878 0 Introduction This Recommendation defines the method for providing the OSI Connection-Mode Network Service (CONS) for CCITT Applications through the use of the X.25 Packet Layer Protocol (X.25/PLP). Particularly, it specifies a mapping between the elements of the X.25/PLP and the primitives of the OSI CONS specified in Recommendation X.213. Appendix I provides additional considerations on the relationship between the X.25 protocol procedures and the CONS primitives. Appendix II illustrates the use of X.25 Network Protocol Address Information (NPAI), i.e., the Address Field and the Address Extension Facilities. Appendix III illustrates the use of X.25 transit delay facilities. The relationship between the X.25/PLP and the OSI CONS is shown in Figure 1/X.223. This relationship is described only in terms of the Network Layer entities that provide the CONS. No discussion is given here to describe the actions of a network layer entity that provides only a relay function for a given network connection. FIGURE 1/X.223 - T0700700-86 The OSI Network Service is defined in terms of: a) the primitive actions and events of the Service; b) the parameters associated with each primitive action and event, and the form which they take; and c) the interrelationship between, and the valid sequences of, these actions and events. The OSI Network Service does not specify individual implementations or products nor does it constrain the implementation of entities and interfaces within a computer system. The X.25/PLP is defined in terms of: a) procedures for Virtual Calls and Permanent Virtual Circuits; b) formats for packets assocaiated with these procedures; and c) procedures and formats for optional user facilities and CCITT-Specified DTE facilities. The use of the word ÒNetworkÓ to name the ÒNetworkÓ Layer of the OSI Reference Model should be distinguished from the use of the word ÒnetworkÓ to denote a communications network as conventionally understood. To facilitate this distinction, the term ÒsubnetworkÓ is used for a collection of physical equipment, commonly called a ÒnetworkÓ (reference Recommendation X.200). Subnetworks may be either public or private networks. In the case of public networks, their properties may be determined by separate Recommendations such as X.21 for a circuit-switched network or X.25 for a packet- switched network. Throughout the set of OSI standards, the term ÒServiceÓ refers to the abstract capability provided by one layer of the OSI Reference Model to the layer above it. Thus, the Network Service is a conceptual architectural Service, independent of administrative divisions. Note - It is important to distinguish the specialized use of the term ÒServiceÓ within the set of OSI standards from its use elsewhere to describe the provision of a service by an organization (such as the provision of a service by an Administration). 1 Scope and Field of Application The OSI CONS, as stated above, is defined in terms of a set of primitive actions and events and associated parameters. For a protocol to support this service, there must be a mapping between the abstract primitives and parameters of the CONS and the real elements of the protocol. This Recommendation provides such a mapping for the X.25/PLP. The X.25/PLP is usually regarded as operating between an end system (i.e., a ÒData Terminal EquipmentÓ in X.25 terminology) and a packet-switched public data subnetwork. However, the X.25/PLP can also be used in other environments to provide the OSI CONS. Examples of such other uses may be the direct connection or circuit- switched connection (including connection across a circuit-switched data subnetwork) of two end systems without an intervening packet- switched public data subnetwork, or the connection of an end system to an Integrated Service Digital Network. Guidance for the design of DTEs is available in ISO standard ISO 8208 (see reference 4). 2 References [1] Recommendation X.200 - Reference Model of Open Systems Interconnection for CCITT Applications. Note - See also ISO 7498 - OSI Basic Reference Model. [2] Recommendation X.210 - Open Systems Interconnection Layer Service Definition Conventions. Note - See also ISO TR 8509 - Network Service Connection. [3] Recommendation X.213 - Network Service Definition for Open Systems Interconnection for CCITT Applications. Note - See also ISO 8348 - Network Service Definition. [4] Recommendation X.25 - Interface Between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet-Mode and Connected to Public Data Networks by Dedicated Circuit. Note - This Recommendation is referred solely with respect to its packet layer protocol description. However, this Recommendation fully specifies the behaviour of the DCE while specifying only a minimum set of requirements for the DTE. Additional guidance for the design of DTEs is available in ISO standard ISO 8208. The development of a Recommendation describing X.25 DTE procedures for CCITT Applications is for further study. [5] Recommendation X.96 - Call Progress Signals in Public Data Networks. [6] ISO 8878 - Information Processing Systems - Data Communications - Use of X.25/PLP to Provide the OSI Connection-Mode Network Service. 3 Definitions 3.1 Reference Model Definitions The following concepts, developed and defined in the OSI Reference Model (Recommendation X.200), are used: a) Network connection, b) Network Layer, c) Network Service, d) Network Service Access Point, e) Network Service Access Point Address, f) Subnetwork. 3.2 Service Conventions Definitions The following terms, as they apply to the Network Layer and as defined in the Service Conventions Standard (Recommendation X.210), are used: g) Network Service user, h) Network Service provider, i) primitive, j) request, k) indication, l) response, m) confirm. 3.3 Network Service Definitions The following terms, as defined in the Network Service (Recommendation X.213), are used: n) Calling Network Service user, o) Called Network Service user. 3.4 Addressing Definitions The following concepts, as defined in Recommendation X.213, are used: p) Subnetwork Point of Attachment address, q) Network Protocol Address Information, r) Initial Domain Part, s) Authority and Format Identifiers, t) Initial Domain Identifier, u) Domain Specific Part. 3.5 X.25 Definitions The following concepts, as developed in Recommendation X.25, are used: v) Virtual Circuit, w) Virtual Call, x) Logical Channel, y) Packet Layer, z) Data Terminal Equipment, aa) Data Circuit-terminating Equipment, ab) DXE (either a DTE or a DCE). 3.6 X.96 Definitions The following terms, as defined in Recommendation X.96, are used: ac) Category C call progress signal, ad) Category D call progress signal. 4 Abbreviations 4.1 Network Service Abbreviations CONS Connection-Mode Network Service N Network NC Network Connection NL Network Layer SR Network Service NSAP Network Service Access Point OSI Open Systems Interconnection QOS Quality of Service 4.2 Addressing Abbreviations AFI Authority and Format Identifier DSP Domain Specific Part IDI Initial Domain Identifier IDP Initial Domain Part NPAI Network Protocol Address Information SNPA Subnetwork Point of Attachment 4.3 X.25 Abbreviations AEF Address Extension Facility AF Address Field D-Bit Delivery Confirmation bit DCE Data-Circuit-terminating Equipment DTE Data Terminal Equipment EDN Expedited Data Negotiation (Facility) EETDN End-to-End Transit Delay Negotiation (Facility) FPF Facility Parameter Field GFI General Format Identifier LC Logical channel M-bit More Data bit MBS M-bit Sequence MTCN Minimum Throughput Class Negotiation (Facility) PLP Packet Layer Protocol P(R) Packet receive sequence number P(S) Packet send sequence number TCN Throughput Class Negotiation (Facility) TDSAI Transit Delay Selection And Indication (Facility) VC Virtual Call 5 Overview This Network Service (NS) provides for the transponder 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.1 Elements of the X.25/PLP Used to Support the OSI CONS The X.25/PLP, as defined by Recommendation X.25, 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 to be mapped to the primitives and parameters of the OSI CONS; and c) the optional user facilities and CCITT-Specified DTE facilities. Of the two types of virtual circuits defined in Recommendation X.25, the use of Virtual Calls (VCs) is mapped to the Network Connection (NC) Establishment and Release Phases of the OSI CONS. Table 1/X.223 below lists the X.25/PLP packets and associated fields that shall be used when supporting the OSI CONS. TABLE 1/X.223 Packets and Fields of the X.25/PLP used to support the OSI CONS Packet Types 1) Fields 2) CALL REQUEST General Format Identifier 3), Adress INCOMING CALL Field, Facility Field, Call and Called CALL ACCEPTED User Data Field 4) CALL CONNECTED CLEAR REQUEST Clearing Cause Field, Diagnostic Code CLEAR INDICATION Field, Address Field, Facility Field, Clear User Data Field 4) DATA D-bit, M-bit, P(S) 5), P(R) 5), User Data Field 4) INTERRUPT Interrupt User Data Field 4) RECEIVE READY 6) P(R) 5) RECEIVE NOT READY 6) REJECT 6) (if agreed to) RESET REQUEST Resetting Cause Field, Diagnostic Code RESET INDICATION Field RESTART INDICATION Restarting Cause Field, Diagnostic Code Field Note 1 - The packets shown in the table are used in support of the primitives of the OSI CONS. Other packets not shown in the table (i.e. CLEAR CONFIRMATION, INTERRUPT CONFIRMATION, RESET CONFIRMATION and RESTART CONFIRMATION 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 OSI CONS. Note 2 - The information in the fields shown in the table have a direct relationship to the parameters associated with the primitives of the OSI CONS. Other fields not shown in the table (e.g. the Logical Channel Identifier, the Packet Type Identifier, the Address Length Fields, and the Facility Length Field) are essential to the use of the appropriate packets. Note 3 - Bit 7 of octet 1 of the General Format Identifier (GFI) in this packets is used to negociate the overall availability of the Delivery Confirmation bit (D-bit) in support of the Receipt Confirmation Service. As such, this bit has no specific field-name as defined in the X.25/PLP. Note 4 - All user data fields are octet aligned. Note 5 - The P(S) and P(R) fields are essential to the operation of the X.25/PLP in providing the Receipt Confirmation Service. Note 6 - The action implied by these packets has no relationship to the primitives of the OSI CONS. However, the P(R) field is essential to the operation of the X.25/PLP in providing the Receipt Confirmation Service. In addition, the following optional user facilities and CCITT- Specified DTE facilities shall be used and/or agreed to: a) optional user facilities: - 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 be agreed to by the two DTEs); - Fast Select Acceptance (facility agreed to if operating in a packet-switched network environment); - Throughput Class Negotiation (facility agreed to and used); and - Transit Delay Selection And Indication (facility used; when operating in a DTE-to-DTE environment without an intervening packet- switched network, use of the TDSAI facility is for further study). b) CCITT-Specified DTE facilities: - Called Address Extension (facility used); - Calling Address Extension (facility used); - End-to-End Transit Delay Negotiation (facility used); - Expedited Data Negotiation (facility used); and - Minimum Throughput Class Negotiation (facility used). 5.2 General Operation of the X.25/PLP For Supporting the OSI CONS The X.25/PLP can be used to provide the OSI CONS in an end system connected to a public X.25 packet-switched subnetwork. It can also be used in environments where end systems are connected by a dedicated path or by a circuit-switched connection. As shown in Figure 2/X.223, the 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 OSI CONS; and b) the packets and associated fields of the X.25/PLP. Request and response primitives are translated into packets to be transmitted across the DTE/DXE interface by the NL entity. Received packets, where appropriate, are translated by the NL entity into indication and confirm primitives. Appendix I provides additional considerations on the relationship between the X.25 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 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. FIGURE 2/X.223 - T0702720-87 There is also a relationship between some local mechanism used to identify a particular NC and a Logical Channel (LC) number used to identify a particular virtual circuit. This relationship is a local matter and is not discussed here. 6 Network Connection Establishment Phase Sections 6 to 11 of this Recommendation deal with the mapping of the OSI CONS to/from the X.25/PLP. 6.1 Primitive/Parameter and Packet/Field Relationships Table 2/X.223 shows the relationships between the primitives/parameters used during the Network Connection Establishment Phase and the packets/fields associated with the Call Set-up Procedures. 6.2 Procedures 6.2.1 Primitive/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 DTE/DXE interface. When 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. 6.2.2 NSAP Addresses Local operation determines the contents of the Network Protocol Address Information (NPAI) and whether Network Service Access Point (NSAP) Addresses, where explicitly supplied, are mapped to and from the Address Field (AF) or the Address Extension Facilities (AEF) of X.25/PLP call set-up packets. Appendix II describes guidelines for the methods by which the required AF contents may be derived from the NSAP Address. The permitted techniques for the placement of NSAP Addresses in either the AF or AEF are given in this clause. The encoding techniques to be employed are those specified in Recommendation X.25 for the AF and AEF. The content of these fields shall be in the preferred binary encoding defined in Recommendation X.213. Examples of encoding NSAP Addresses in the NPAI of the X.25/PLP are also given in Appendix II. Note - The use of the preferred binary encoding results in binary-coded decimal digits in the AF, as required by Recommendation X.25. 6.2.2.1 Encoding of NSAP Addresses 6.2.2.1.1 Use of the Address Field (AF) Under certain conditions, the NSAP Address, as defined in Recommendation X.213, is conveyed entirely in the AF. These conditions are: a) the NSAP Address consists solely of the Intial Domain Part (IDP), i.e., the Domain Specific Part (DSP) is null; b) the Authority and Format Identifier (AFI) can be deduced from the contents of the AF (e.g., with knowledge of the subnetwork to which the DTE is attached); c) the Initial Domain Identifier (IDI) is the same as the Subnetwork Point of Attachment (SNPA) Address; and d) the NL entity, through local knowledge, is aware that the remote NL entity does not operate according to CCITT Recommendation X.223 and cannot recognize the AEF. When all of the above conditions are satisfied, the AF is used to convey the semantics of the entire NSAP Address (the AFI is implied and the contents of the AF are equivalent to the IDI). TABLE 2/X.223 CONS:X.25/PLP Mapping for the Network Connection Establishment Phase CONS X.25/PLP PRIMITIVES: PACKETS: N-CONNECT request CALL REQUEST N-CONNECT indication INCOMING CALL N-CONNECT response CALL ACCEPTED N-CONNECT confirm CALL CONNECTED PARAMETERS: FIELDS (INCLUDING FACILITIES): Called Address Called DTE Address Field Calling Address Extension Facility Calling Address Calling DTE Address Field Calling Address Extension Facility Responding Address Called DTE Address Field Called Address Extension Facility Receipt Confirmation General Format Identifier Selection 1) Expedited Data Selection Expedited Data Negotiation Facility QoS-Parameter Set Throughput Class Negotiation Facility 2) Minimum Throughput Class Negotiation Facility Transit Delay Selection And Indication Facility End-to-End Transit Delay Negotiation Facility NS-User-Data Call and Called User Data Field Fast Select Facility 3) Note 1 - Bit 7 of octet 1 of the GFI in call setup packets is used to negociate the overall availability of the D-bit in support of the Receipt Confirmation Service. As such, this bit has no specific field-name as defined in the X.25/PLP. Note 2 - For proper operation, this optional user facility shall also be agreed to for use on the interface. Note 3 - For proper operation, the Fast Select Acceptance Facility shall also be agreed to on the interface when accessing a packet- switched network. 6.2.2.1.2 Use of the Address Extension Facility (AEF) If any of the conditions in ¤ 6.2.2.1.1 are not satisfied, the AEF shall be used. The NSAP address, complete with the AFI, is placed in the AEF (bits 8 and 7 of the first octet of the Facility Parameter Field (FPF) are both set to zero). In this case, the contents of the AF are not defined by this Recommendation. Guidelines for their derivation are given in Appendix II. 6.2.2.2 Decoding of the NSAP Addresses 6.2.2.2.1 Absent AEF Case If the AEF is not present, then local knowledge is required by the receiving NL entity to determine whether an OSI NAP Address is to be deduced from the content of the AF. If this local exchange indicates that an NSAP Address is present, its abstract syntax is as follows: a) the AFI is deduced from knowledge of the subnetwork from which the packet was received; b) the IDI is the same as the contents of the AF; and c) the DSP is absent. 6.2.2.2.2 AEF Case If the AEF is present and bits 8 and 7 of the leading octet of the FPF are both set to zero, then the NSAP Address is contained entirely within the AEF. The abstract synstax is as follows: a) the AFI is contained within the first two digits of the AEF; b) the IDI is the remainder of the IDP after any leading and trailing padding digits are discarded; and c) the DSP, if present, constitutes the remainder of the AEF content after any trailing padding digits are discarded. 6.2.3 Receipt Confirmation Selection Bit 7 of octet 1 in the GFI of X.25/PLP call set-up packets is mapped to/from the Receipt Confirmation Selection parameter of N- CONNECT primitives. If the Receipt Confirmation Selection parameter of the N- CONNECT request primitives indicates Òuse of Receipt ConfirmationÓ, then the NL entity, if it can support the D-bit Procedure as defined in ¤¤ 8.2.3 and 9.2.1, sets bit 7 of the GFI to 1 to indicate use of receipt confirmation during the Data Transfer Phase. If Òno use of Receipt ConfirmationÓ is indicated or the NL entity cannot support the D-bit Procedure, then bit 7 is set to 0. When an NL entity receives an INCOMING CALL packet with bit 7 of the GFI set to 1 but it cannot support the D-bit Procedure, it indicates Òno use of Receipt ConfirmationÓ in the Receipt Confirmation Selection parameter of the N-CONNECT indication primitive signaled to the Called NS user. Otherwise, if bit 7 of the GFI is set to 1 (respectively, 0), then the NL entity indicates Òuse (respectively, no use) of Receipt ConfirmationÓ in the Receipt Confirmation Selection parameter of the N-CONNECT indication primitive signaled to the Called NS user. When an NL entity receives an N-CONNECT response primitive with the Receipt Confirmation Selection parameter indicating Òuse (respectively, no use) of Receipt ConfirmationÓ, it sets bit 7 of the GFI in the CALL ACCEPTED packet to 1 (respectively, 0). When an NL entity receives a CALL CONNECTED packet with bit 7 of the GFI set to 1 (respectively, 0), it indicates Òuse (respectively, no use) of Receipt ConfirmationÓ in the Receipt Confirmation Selection parameter of the N-CONNECT confirm primitive signaled to the Calling NS user. 6.2.4 Expedited Data Selection The Expedited Data Negotiation (EDN) Facility of the X.25/PLP is mapped to/from the Expedited Data Selection parameter of N- CONNECT primitives, when appropriate. If the Expedited Data Selection parameter of the N-CONNECT request primitive indicates Òuse of Expedited DataÓ, then the NL entity, if it can support the Interrupt Procedure using 32-octet INTERRUPT packets, encodes the EDN Facility to indicate use of expedited data during the Data Transfer Phase. If Òno use of Expedited DataÓ is indicated or the NL entity cannot support 32- octet INTERRUPT packets, then the EDN Facility is omitted. When an NL entity receives an INCOMING CALL packet with no EDN Facility or with the EDN Facility indicating use of expedited data but it cannot support 32-octet INTERRUPT packets, it indicates Òno use of Expedited DataÓ in the Expedited Data Selection parameter of the N-CONNECT indication primitive signaled to the Called NS user. Otherwise, if the EDN Facility indicates use of expedited data, then the NL entity indicates Òuse of Expedited DataÓ in the Expedited Data Selection parameter of the N-CONNECT indication primitive signaled to the Called NS user. When an NL entity receives an N-CONNECT response primitive with the Expedited Data Selection parameter indicating Òuse of Expedited DataÓ, it encodes the EDN Facility in the CALL ACCEPTED packet to indicate use of expedited data. If the Expedited Data Selection parameter indicates Òno use of Expedited DataÓ, the NL entity omits the EDN Facility from the CALL ACCEPTED packet. When an NL entity receives a CALL CONNECTED packet with the EDN Facility indicating use of expedited data, it indicates Òuse of Expedited DataÓ in the Expedited Data Selection parameter of the N- CONNECT confirm primitive signaled to the Calling NS user. If the CALL CONNECTED packet has no EDN Facility, then the NL entity indicates Òno use of Expedited DataÓ to the Calling NS user. 6.2.5 QOS Parameter Set The set of QOS parameters that are conveyed during the NC Establishment Phase consists of three , parameters: a) the throughput for the direction of data transfer from the Calling NS user to the Called NS user; b) the throughput for the direction of data transfer from the Called NS user to the Calling NS user; and c) the transit delay that applies to both directions of data transfer. Note - The mapping of the Protection and Priority QOS parameters in CCITT Recommendation X.213 to the corresponding DTE Facilities described in CCITT Recommendation X.25 is for further study. For each of these three parameters, a set of ÒsubparametersÓ is defined as follows: a) a ÒTargetÓ value, which is the QOS value desired by the Calling NS user; b) a ÒLowest Quality AcceptableÓ value, which is the lowest QOS value agreeable to the Calling NS user; c) an ÒAvailableÓ value, which is the QOS value the NS provider is willing to provide; and d) a ÒSelectedÓ value, which is the QOS value to which the Called NS user agrees. The set of values that can be specified for each subparameter is defined in every Network Service. This set includes the value ÒunspecifiedÓ. It may also include a value defined to be a Òdefault valueÓ that is mutually understood by the NS provider and an NS user as applying in the absence of particular values. 6.2.5.1 Throughput QOS Parameters The Throughput Class Negotiation (TCN) Facility and the Minimum Throughput Class Negotiation (MTCN) Facility of the X.25/PLP are mapped to/from both Throughput QOS parameters of N- CONNECT primitives, when appropriate. The specific mapping of the X.25/PLP facilities to/from both sets of Throughput subparameters is given in Table 3/X.223. TABLE 3/X.223 Mapping of Throughput QOS Subparameters to X.25/PLP Facilities CONS X.25/PLP Subparameter Primitive Facil Packet ity Target N-CONNECT request TCN CALL REQUEST Lowest Quality N-CONNECT request MTCN CALL REQUEST Acceptable Available N-CONNECT indication TCN INCOMING CALL Lowest Quality N-CONNECT indication MTCN INCOMING Acceptable CALL Selected N-CONNECT response TCN CALL ACCEPTED Selected N-CONNECT confirm TCN CALL CONNECTED The set of values that can be specified for each Throughput subparameter ranges from 75 bits per second through 64000 bits per second, inclusive. This set consists of the following discrete values: 75, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 48000 and 64000 bits per second. An NL entity supports either all of these values or a contiguous subset of them. The value ÒunspecifiedÓ is also allowed. 6.2.5.1.1 Processing an N-CONNECT Request Primitive If an NL entity, when receiving an N-CONNECT request primitive, cannot support the Lowest Quality Acceptable throughput (i.e., the minimum throughput) when specified for either direction of data transfer, then it rejects the request. In this case, the NL entity does not transmit any X.25/PLP packet but it does not signal an N-DISCONNECT indication primitive to the Calling NS user. The Originator parameter is ÒNS ProviderÓ. The Reason parameter is ÒConnection Rejection-QOS Not Available/Transient ConditionÓ, or ÒConnection Rejection-QOS not Available/Transit ConditionÓ, or ÒConnection Rejection-QOS Not Available/Permanent ConditionÓ if the NL entity could never support the Lowest Quality Acceptable for either direction of data transfer. If an NL entity, when receiving the N-CONNECT request primitive, can support the Lowest Quality Acceptable throughput (i.e., the minimum throughput) when specified for both directions of data transfer, then it encodes the Target and Lowest Quality Acceptable values in the TCN and MTCN Facilities, respectively (as shown in Table 3/X.223). If the Target subparameter (of either or both of the Throughput QOS parameters) is ÒunspecifiedÓ, then the NL entity encodes the TCN Facility for the corresponding direction(s) of data transfer as the highest throughput rate supported by the NL entity. If the Lowest Quality Acceptable subparameter (of one of the Throughput QOS parameters) is ÒunspecifiedÓ, then the NL entity encodes the MTCN Facility for the corresponding direction(s) of data transfer as 75 bits per second. The TCN and MTCN Facilities are transmitted across the DTE/DXE interface in a CALL REQUEST packet. If the NL entity receives a N-CONNECT request primitive with the Lowest Quality Acceptable sub-parameters of both the Throughput QOS parameters ÒunspecifiedÓ, then the MTCN facility is not included in the CALL REQUEST packet. 6.2.5.1.2 Processing an INCOMING CALL Packet When receiving an INCOMING CALL packet, an NL entity compares the minimum throughput value specified in the MTCN Facility for each direction of data transfer to the available throughput value specified in the TCN Facility, when these are present. If, for either direction, the available throughput value is less than the minimum throughput value or if the NL entity cannot support the minimum throughput value, then the NL entity clears the call (i.e., transmits a CLEAR REQUEST packet). The cause is ÒDTE OriginatedÓ and the diagnostic is ÒConnection Rejection-QOS Not Available/Transient ConditionÓ, or ÒConnection Rejection-QOS Not Available/Permanent ConditionÓ if the NL entity could never support the lowest throughput value (these diagnostics have values 229 and 230, respectively). Otherwise, the NL entity indicates, for both directions of data transfer, the Available and Lowest Quality Acceptable throughput values in the Throughput QOS parameters of the N-CONNECT indication primitive signalled to the Called NS user. The Available and Lowest Quality Acceptable subparameters are mapped from the TCN and MTCN Facilities, respectively, as shown in Table 3/X.223. If an NL entity receives an INCOMING CALL packet without the MTCN Facility, then the NL entity indicates the value ÒunspecifiedÓ for the Lowest Quality Acceptable sub-parameters of both the Throughput QOS parameters of the N-CONNECT indication primitive signalled to the called NS user. 6.2.5.1.3 Processing an N-CONNECT Response Primitive When an NL entity receives an N-CONNECT response primitive, it encodes the Selected throughput values for both directions of data transfer, as given in the Throughput QOS parameters, in the TCN Facility returned in the CALL ACCEPTED packet. 6.2.5.1.4 Processing a CALL CONNECTED packet When an NL entity receives a CALL CONNECTED packet, it indicates the Selected throughput values for both directions of data transfer, as given in the TCN Facility, in the Throughput QOS parameters of the N-CONNECT confirm primitive signalled to the Calling NS user. 6.2.5.2 Transit Delay QOS Parameter The Transit Delay Selection And Indication (TDSAI) Facility and the End-to-End Transit Delay Negotiation (EETDN) Facility of the X.25/PLP are mapped to/from the Transit Delay QOS parameter of N-CONNECT primitives, when appropriate. The set of values that can be specified for each Transit Delay subparameter ranges from 1 millisecond through 65534 milliseconds, inclusive, in increments of 1 millisecond. An NL entity supports either all of these values or a contiguous subset of them. The value ÒunspecifiedÓ is also allowed. An NL entity in an end system shall be able to determine the cumulative transit delay attributable to the NS provider in that end system. This is the transit delay of the NL entity itself, all lower-layer entities, and the effects of the access line transmission rate. Appendix III illustrates the use of the X.25 TDSAI and EETDN Facilities in support of the end-to-end negotiation of the Transit Delay QOS parameter. 6.2.5.2.1 Processing an N-CONNECT Request Primitive If an NL entity, when receiving an N-CONNECT request primitive, cannot support the Lowest Quality Acceptable transit delay (i.e., the maximum transit delay), when specified, then it rejects the request. In this case, the NL entity does not transmit any X.25/PLP packet but it does signal an N-DISCONNECT indication primitive to the Calling NS user. The originator parameter is ÒNS ProviderÓ. The Reason parameter is ÒConnection Rejection-QOS Not Available/Transient ConditionÓ, or ÒConnection Rejection-QOS Not Available/Permanent ConditionÓ if the NL entity could never support the Lowest Quality Acceptable transit delay. If an NL entity, when receiving an N-CONNECT request primitive, can support the Lowest Quality Acceptable transit delay (i.e., the maximum transit delay) when specified, or when the Target transit delay is specified and the Lowest Quality Acceptable delay is unspecified, then: a) the NL entity encodes the cumulative transit delay attributable to the NS provider in the calling end system in the Òcumulative-transit-delay subfieldÓ (i.e., octets 1 and 2) of the EETDN Facility; b) if a Target transit delay is specified, then the NL entity encodes this value in the Òtarget-transit-delay subfieldÓ (i.e., octets 3 and 4) of the EETDN Facility (otherwise, this subfield is not used); Note - According to Recommendation X.213, the case where the Target transit delay is unspecified and the Lowest Quality Acceptable transit delay has a value other than unspecified is not permitted; logically, this case can be represented by the permitted assignment where an identical value is specified for both the Target and Lowest Quality Acceptable transit delays; c) if a Lowest Quality Acceptable transit delay is specified, then the NL entity encodes this value in the Òmaximum-acceptable- transit-delay subfieldÓ (i.e., octets 5 and 6) of the EETDN Facility (otherwise, this subfield is not used); and d) if the Target transit delay is specified and the operational environment is DTE-to-DCE, then the NL entity encodes the value of the TDSAI Facility as being less than the Target transit delay minus the cumulative transit delay for the calling end system; otherwise, the TDSAI Facility is encoded with any value (i.e., it is not constrained by this Recommendation). In a DTE-to- DTE operational environment, the usage of the TDSAI Facility is for further study. Note - Given a Òrouting management information baseÓ, the NL entity can refine the value encoded in the TDSAI Facility. For example, the value of the TDSAI Facility could take into account whether networks other than packet-switched networks are traversed in reaching the called end system or whether the called end system is reachable directly in a point-to-point configuration. The TDSAI (if applicable) and EETDN Facilities are transmitted across the DTE/DXE interface in a CALL REQUEST packet. Note - The value of the TDSAI Facility in a CALL REQUEST packet in a DTE/DCE environment provides a guideline to the DCE for allocating resources. The final transit-delay value applicable to the Virtual Call may be less than, equal to, or greater than the value in the CALL REQUEST packet. If an NL entity receives an N-CONNECT request primitive with both Target and Lowest Quality Acceptable sub-parameters ÒunspecifiedÓ, then the EETDN and the TDSAI (if applicable) is not included in the CALL REQUEST packet. 6.2.5.2.2 Processing an INCOMING CALL packet When receiving an INCOMING CALL packet, an NL entity computes the total NC transit delay by summing the values of: a) the TDSAI Facility; b) the Òcumulative-transit-dekay subfieldÓ (i.e., octets 1 and 2) of the EETDN Facility; and c) the transit delay attributable to the NS provider in the called end system. Note - The procedure suggested here for computing the value of the total NC transit delay is the best an NL entity can do in the absence of any Òexternal informationÓ. However, given a Òrouting management information baseÓ, the NL entity can refine this value. For example, the transit delay attributable to the effects of the access line transmission rate shall not be included when the called end system is connected to the calling end system in a point-to- point configuration (these effects have been accounted for by the calling end system). If the Òmaximum-acceptable-transit-delay subfieldÓ (i.e., octets 5 and 6) of the EETDN Facility is present, then the NL entity compares the value in this ÒsubfieldÓ to the total NC transit delay computed above. If the total NC transit delay is greater than the maximum-acceptable transit delay, then the NL entity clears the call (i.e., transmits a CLEAR REQUEST packet). The cause is ÒDTE OriginatedÓ and the diagnostic is ÒConnection Rejection-QOS Not Available/Transient ConditionÓ, or ÒConnection Rejection-QOS Not Available/Permanent ConditionÓ if the NL entity could never support the maximum-acceptable transit delay (these diagnostics have values 229 and 230, respectively). Otherwise, if either: 1) the total NC transit delay is less than or equal to the maximum-acceptable transit delay, or 2) the Òmaximum-acceptable-transit-delay subfieldÓ of the EETDN Facility is not present, then the NL entity indicates the Available transit-delay value (as given by the total NC transit delay computed above) in the Transit Delay QOS parameter of the N-CONNECT indication primitive signaled to the Called NS user. If an NL entity receives an INCOMING CALL packet without the EETDN or without the TDSAI Facilities, then the NL entity indicates the value ÒunspecifiedÓ for the Available transit delay of the N- CONNECT indication primitive signalled to the called NS user. 6.2.5.2.3 Processing an N-CONNECT Response Primitive When an NL entity receives an N-CONNECT response primitive, it encodes the total NC transit-delay value (as computed above) in the Òcumulative-transit-delay subfieldÓ (octets 1 and 3) of the EETDN Facility returned in the CALL ACCEPTED packet. Note 1 - There is no Transit Delay QOS Parameter in an N- CONNECT response primitive. Note 2 - The EETDN Facility returned in a CALL ACCEPTED packet only contains the Òcumulative-transit-delay subfieldÓ. If a N-CONNECT response primitive is received by an NL entity subsequent to a N-CONNECT indication primitive signalled from the NL entity with the Available transit delay parameter set to ÒunspecifiedÓ, then the NL entity does not include the EETDN in the CALL ACCEPTED packet. 6.2.5.2.4 Processing a CALL CONNECTED Packet When an NL entity receives a CALL CONNECTED packet, it indicates the selected transit-delay value, as given by the Òcumulative-transit-delay subfieldÓ of the EETDN Facility, in the Transit Delay QOS parameter of the N-CONNECT confirm primitive signaled to the Calling NS user. If a NL entity receives a CALL CONNECTED packet without the EETDN Facility, then the NL entity indicates an ÒunspecifiedÓ value in the N-CONNECT confirm primitive signalled to the NS user. 6.2.6 NS-User-Data The Call User Data Field of X.25/PLP CALL REQUEST and INCOMING CALL packets is used to transer the NS-user-data of N-CONNECT request and indication primitives, respectively. The Called User Data Field of X.25/PLP CALL ACCEPTED and CALL CONNECTED packets is used to transfer the NS-user-data of N-CONNECT response and confirm primitives, respectively. In addition, the Fast Select Facility shall be indicated in the CALL REQUEST packet sent by the Calling NL entity. 7 Network Connection Release Phase 7.1 Primitive/Parameter and Packet/Field Relationships Table 4/X.223 shows the relationships between the primitives/parameters used during the NC Release Phase and the packets/fields associated with the Call Clearing Procedures. TABLE 4/X.223 CONS:X.25/PLP Mapping for the Network Connection Release Phase CONS X.25/PLP PRIMITIVES: PACKETS: N-DISCONNECT request CLEAR REQUEST N-DISCONNECT indication CLEAR INDICATION, RESTART INDICATION 1) CLEAR REQUEST 2) PARAMETERS: FIELDS (INCLUDING FACILITIES): Originator and Reason Cause Code and Diagnostic Code Fields 3) NS-User-Data Clear User Data Responding Address Called DTD Address Field Called Address Extension Facility Note 1 - Receipt of a RESTART INDICATION packet should be treated as receipt of a CLEAR INDICATION packet for every logical channel and then mapped to an N-DISCONNECT indication primitive for every active NC associated with the Packet Layer Protocol being restarted. The Restarting Cause Code and Diagnostic Code Fields are then treated in the same manner as the Clearing Cause Code and Diagnostic Code Fields. Note 2 - See ¤ 7.2.1, Paragraph 2. Note 3 - The combination of Cause Code and Diagnostic Code Fields is mapped to/from the combination of Originator and Reason parameters. 7.2 Procedures 7.2.1 Primitive/Packet Mapping When an NL entity receives an N-DISCONNECT request primitive from an NS user, it transmits a CLEAR REQUEST packet across the DTE/DXE interface. If, however, the NL entity had previously transmitted a CLEAR REQUEST packet and signaled an N-DISCONNECT indication primitive to the NS user (because of a protocol error; see below), then it does not transmit another CLEAR REQUEST packet. If an NL entity detects an error in the operation of the X.25/PLP for which its action is to clear the VC (e.g., a format error in an INCOMING CALL packet or a timeout condition), then it transmits a CLEAR REQUEST packet across the DTE/DXE interface. If the virtual circuit is associated with an NC, then it also signals an N-DISCONNECT indication primitive to the NS user. When an NL entity receives a CLEAR INDICATION packet (or a RESTART INDICATION packet), it signals an N-DISCONNECT indication primitive to the NS user. It also transmits a CLEAR CONFIRMATION packet (or a RESTART CONFIRMATION packet) across the DTE/DXE interface. If, however, the NL entity had previously transmitted a CLEAR REQUEST packet for the NC (i.e., a clear collision), then it does not signal an N-DISCONNECT indication primitive to the NS user nor transmit a CLEAR CONFIRMATION packet. Note - If the received CLEAR INDICATION packet is in response to a previously-transmitted CALL REQUEST packet, the NL entity may retry the call if the Network Connection Establishment Delay has not been exceeded rather than immediately signalling an N- DISCONNECT indication primitive to its NS user. The NL entity may also use the Clearing Cause Code (see ¤ 7.2.2) in the CLEAR INDICATION packet to determine whether to retry the call. That is, the reattempt may be successful if the Clearing Cause Code is classified as Category C (see Recommendation X.96); on the other hand, a Category D code indicates a problem of a more permanent nature. The time interval between and number of reattempted calls is a local matter. If multiple attempts at establishing the NC are all unsuccessful, then the Originator-parameter and Reason- parameter values finally signaled in the N-DISCONNECT indication primitive are a local matter. If either NL entity wishes to disconnect an NC, it signals an N-DISCONNECT indiction primitive to its NS user and transmits a CLEAR REQUEST packet across the DTE/DXE interface. If, however, the NL entity in the calling DTE cannot, for example, support the QOS parameters specified in an N-CONNECT request primitive or does not have an LC available to set up a VC, then it signals an N- DISCONNECT indication primitive to the Calling NS user but it does not transmit a CLEAR REQUEST packet across the DTE/DXE interface. 7.2.2 Originator/Reason The combination of Originator and Reason parameters of the N- DISCONECT primitives is mapped to/from the combination of Clearing Cause Code (or Restarting Cause Code) and the Diagnostic Code Fields. The combination of the cause code ÒDTE OriginatedÓ (coded as all zeros) with a diagnostic in the set 241, 242 and 244-248 corresponds to an Originator-parameter values of ÒNS UserÓ. In this case, there is a one-to-one relationship between the values of the Reason parameter and these diagnostic codes. The cause code ÒDTE OriginatedÓ (coded as all zeros) used in combination with diagnostic codes other than those listed above corresponds to an Originator-parameter value of ÒNS ProviderÓ. There is a one-to-one relationship between the values of the Reason parameter and diagnostic codes 225-232 and 235. In other cases, the Originator-parameter and Reason-parameter values depend on: a) the cause and/or diagnostic codes; and b) whether the NC is in the NC Establishment Phase or in the Data Transfer Phase. The values of the Originator and Reason parameters are derived as follows: a) the Originator-parameter value is ÒNS ProviderÓ and the Reason-parameter value is Òdisconnection-permant conditionÓ when the NC is in the Data Transfer Phase and any of the following applies: - cause codes ÒOut of OrderÓ, ÒLocal Procedure ErrorÓ, ÒRemote Procedure ErrorÓ, or ÒRPOA Out of OrderÓ; - diagnostic code 122; b) the Originator-parameter value is ÒNS ProviderÓ and the Reason-parameter value is Òdisconnection-transient conditionÓ when the NC is in the Data Transfer Phase and any of the following applies: - cause code ÒNetwork CongestionÓ; - diagnostic codes 113 or 115; - cause code ÒDTE OriginatedÓ (coded as all zeros) with diagnostic codes 162 or 163; c) the Originator-parameter value is ÒNS ProviderÓ and the Reason-parameter value is Òconnection rejection-NSAP address unknown (permanent condition)Ó when the NC is in the NC Establishment Phase and any of the following applies: - cause codes ÒNot ObtainableÓ or ÒShip AbsentÓ; d) the Originator-parameter value is ÒNS ProviderÓ and the Reason-parameter value is Òconnection rejection-reason unspecified/permanent conditionÓ when the NC is in the NC Establishment Phase and any of the following applies: - cause codes ÒAccess BarredÓ, ÒFast Select Acceptance Not SubscribedÓ, ÒIncompatible DestinationÓ, ÒInvalid Facility RequestÓ, ÒOut of OrderÓ, ÒLocal Procedure ErrorÓ, ÒRemote Procedure ErrorÓ, ÒReverse Charging Acceptance Not SubscribedÓ, or ÒRPOA Out of OrderÓ; - diagnostic codes 121 or 122; - cause code ÒDTE OriginatedÓ (coded as all zeros) with diagnostic code 164; e) the Originator-parameter value is ÒNS ProviderÓ and the Reason-parameter value is Òconnection rejection-reason unspecified/transient conditionÓ when the NC is in the NC Establishment Phase and any of the following applies: - cause codes ÒNetwork CongestionÓ or ÒNumber BusyÓ; - diagnostic codes 112-120; - cause code ÒDTE OriginatedÓ (coded as all zeros) with a diagnostic code other than those listed above; f) the Originator-parameter and Reason-parameter values are both ÒUndefinedÓ for any other combination of cause and diagnostic codes. 7.2.3 NS-User Data The Clear User Data Field of X.25/PLP CLEAR REQUEST and CLEAR INDICATION packets is used to transfer the NS-user-data between NS users. 7.2.4 Responding Address Local operation determines the contents of the Called Address Field and whether the responding NSAP Address, where explicitly supplied, is mapped to/from the AF or the AEF in the X.25/PLP call clearing packets. Rules for encoding and decoding the responding NSAP Address are given in Clause ¤ 6.2.2. 8 Data Transfer Phase - Data Transfer Service 8.1 Primitive/Parameter and Packet/Field Relationships Table 5/X.223 shows the relationships between the primitives/parameters used for the Data Transfer Service and the packets/fields associated with the Data Transfer Procedures. TABLE 5/X.223 CONS:X.25/PLP Mapping for the Data Transfer Service CONS X.25/PLP PRIMITIVES: PACKETS: N-DATA request DATA N-DATA indication DATA PARAMETERS: FIELDS: NS-User-Data User Data, M-bit Confirmation Request D-bit, P(S) 8.2 Procedures 8.2.1 Primitive/Packet Mapping When an NL entity receives an N-DATA request primitive from an NS user, it transmits a sequence of one or more DATA packets, known as M-bit Sequence (MBS), across the DTE/DXE interface. The number of DATA packets needed in an MBS depends on the amount of NS-user- data and on the maximum Òpacket sizeÓ (i.e., the maximum User Data Field Length of DATA packets) permitted on the DTE/DXE interface. All DATA packets but the last one of an MBS contain the maximum number of octets, have their M-bit set to 1, and have their D-bit set to 0. The last DATA packet has its M-bit set to 0. The D-bit setting of the last DATA packet is dependent on the Confirmation Request parameter (see ¤ 8.2.3 below). When an NL entity receives an MBS, it signals an N-DATA indication primitive to the NS user. 8.2.2 NS-User-Data The User Data Fields of X.25/PLP DATA packets are used to transfer NS-user-data between NS users. 8.2.3 Confirmation Request The D-bit of the last DATA packet in an MBS is mapped to/from the Confirmation Request parameter. If an N-DATA request primitive indicates in the Confirmation Request parameter that confirmation of receipt is requested (respectively, not requested), then the D-bit of the last DATA packet in an MBS is set to 1 (respectively, 0). In the case of confirmation of receipt being requested, the NL entity shall use a locally-defined mechanism to associate the P(S) of the last DATA packet in the MBS with the N-DATA request primitive. (This mechanism shall also provide for an association of an N-DATA request primitive with an N-DATA ACKNOWLEDGE indication primitive; see ¤ 9.2.1). When an NL entity signals an N-DATA indication primitive to the NS user, it indicates in the Confirmation Request parameter that confirmation of receipt is requested (respectively, not requested) if the D-bit of the last DATA packet in an MBS is set to 1 (respectively, 0). When the last DATA packet in an MBS has its D- bit set to 1, the NL entity may not transmit a P(R) corresponding to that DATA packet across the DTE/DXE interface until it receives an N-DATA ACKNOWLEDGE request primitive from its NS user (see ¤ 9). In the case of the D-bit of the last DATA packet in an MBS being set to 1, the NL entity shall use a locally-defined mechanism to associate the P(S) of this packet with the N-DATA indication primitive. (This mechanism shall also provide for an association of an N-DATA indication primitive with an N-DATA ACKNOWLEDGE request primitive; see ¤ 9.2.1.) 9 Data Transfer Phase - Receipt Confirmation Service 9.1 Primitive and Packet/Field Relationships There is no distinct X.25/PLP packet associated with the N- DATA ACKNOWLEDGE request and N-DATA ACKNOWLEDGE indication primitives. The P(R) field of DATA, RECEIVE READY, RECEIVE NOT READY, and REJECT (if agreed to) packets is used to support the Receipt Confirmation Service. 9.2 Procedures 9.2.1 Primitive/Packet Mapping When an NL entity receives an N-DATA ACKNOWLEDGE request primitive from an NS user, it uses its locally-defined mechanism mentioned in ¤ 8.2.3 for associating an N-DATA ACKNOWLEDGE request primitive with a previously-issued N-DATA indication primitive [and, hence, a P(S)] to determine a P(R) to be transferred in the appropriate packet across the DTE/DXE interface. (Note that such acknowledgements shall be issued in the same order that the corresponding N-DATA indications were issued.) When an NL entity receives a P(R), it shall determine whether this P(R) is inclusive of a P(S) associated with a previously- received N-DATA request primitive that requested confirmation of receipt. If such an association is made, then the NL entity signals an N-DATA ACKNOWLEDGE indication primitive to the NS user. This N- DATA ACKNOWLEDGE indication primitive is associated, by the locally- defined mechanism mentioned in ¤ 8.2.3, to the previously-received N-DATA request primitive that had requested confirmation of receipt. 10 Data Transfer Phase - Expedited Data Transfer Service 10.1 Primitive/Parameter and Packet/Field Relationships Table 6/X.223 shows the relationships between the primitives/parameters used for the Expedited Data Transfer Service and the packets/fields associated with the Interrupt Transfer Procedures. TABLE 6/X.223 CONS:X.25/PLP Mapping for the Expedited Data Transfer Service CONS X.25/PLP PRIMITIVES: PACKETS: N-EXPEDITED DATA request INTERRUPT N-EXPEDITED DATA indication INTERRUPT PARAMETERS: FIELDS: NS-User-Data Interrupt User Data 10.2 Procedures 10.2.1 Primitive/Packet Mapping When an NL entity receives an N-EXPEDITED DATA request primitive from an NS user, it transmits an INTERRUPT packet across the DTE/DXE interface. An NL entity shall not transmit a second INTERRUPT packet before an outstanding INTERRUPT packet has been confirmed by an INTERRUPT CONFIRMATION packet. When an NL entity receives an INTERRUPT packet, it signals an N-EXPEDITED DATA indication primitive to the NS user. It also transmits an INTERRUPT CONFIRMATION packet across the DTE/DXE interface. 10.2.2 NS-User-Data The Interrupt User Data Field of X.25/PLP INTERRUPT packets is used to transfer expedited NS-user-data between NS users. 11 Data Transfer Phase - Reset Service 11.1 Primitive/Parameter and Packet/Field Relationships Table 7/X.223 shows the relationships between the primitives/parameters used for the Reset Service and the packets/fields associated with the Reset Procedures. TABLE 7/X.223 CONS:X.25/PLP Mapping for the Reset Service CONS X.25/PLP PRIMITIVES: PACKETS: N-RESET request RESET REQUEST N-RESET indication RESET INDICATION, RESET REQUEST 1) N-RESET response none N-RESET confirm none PARAMETERS: FIELDS: Originator and Reason Cause Code and Diagnostic Code Fields 2) Note 1 - See Clause 11.2.1, Paragraph 2. Note 2 - The combination of Cause Code and Diagnostic Code Fields is mapped to/from the combination of Originator and Reason parameters. 11.2 Procedures 11.2.1 Primitive/Packet Mapping When an NL entity receives an N-RESET request primitive from an NS user, it transmits a RESET REQUEST packet across the DTE/DXE interface. When the NL entity is ready to accept subsequent data, expedited data, and confirmations of receipt from the NS user, it signals an N-RESET confirm primitive. The issuing of this primitive may or may not be related to the completion of the X.25/PLP reset procedure. Any data or expedited data received from the NS user following the N-RESET confirm primitive is transmitted after completion of the X.25/PLP reset procedure. If an NL entity detects an error in the operation of the X.25/PLP for which its action is to reset the virtual circuit (e.g., a sequence error or a timeout condition), then it transmits a RESET REQUEST packet across the DTE/DXE interface. When an NL entity is ready to accept subsequent data, expedited data, and confirmations of receipt from the NS user, it signals an N-RESET indication primitive. The issuing of this primitive may or may not be related to the completion of the X.25/PLP reset procedure. Any data or expedited data received from the NS user following the N- RESET response primitive is transmitted after completion of the X.25/PLP reset procedure. When an NL entity receives a RESET INDICATION packet, it signals an N-RESET indication primitive to the NS user. When an N-RESET response primitive is received from the NS user, the NL entity shall be willing to accept the subsequent data, expedited data, and confirmations of receipt received from the NS user for transmission upon completion of the X.25/PLP reset procedure. During the reset process, the following actions are taken by the NL entity with respect to the operation of the X.25/PLP: a) For DATA packets: - those awaiting transmission may either be transmitted prior to transmitting a reset packet or flushed from the queue of DATA packets awaiting transmission; - those remaining in the transmit window when the reset procedure is completed are flushed; and - those that have been received prior to receiving a reset packet but which do not constitute an entire MBS are flushed from the ÒMBS reassembly areaÓ. b) The lower window edge for each direction of data transmission is set to 0 and subsequently transmitted DATA packets are numbered starting from 0. c) Any busy condition that had existed prior to the reset is considered not to exist any longer. d) Any outstanding INTERRUPT packet remains unconfirmed. e) All timer and retransmission parameters relating to data and interrupt transfer are set back to their initial value. No action is required with respect to the provision of the Network Service by an NL entity when it receives a RESET CONFIRMATION packet or a RESET INDICATION packet in response to a RESET REQUEST packet (i.e., a reset collision). However, it shall then be capable of receiving subsequent DATA and INTERRUPT packets and P(R) information. 11.2.2 Originator/Reason The combination of Originator and Reason parameters of the N- RESET primitives is mapped to/from the combination of Resetting Cause Code and Diagnostic Code Fields. The combination of the cause code ÒDTE OriginatedÓ (coded as all zeros) with the diagnostic ÒReset-User ResynchronizationÓ (diagnostic code 250) corresponds to an Originator-parameter value of ÒNS UserÓ and a Reason-parameter value identical to the diagnostic. All other combinations of cause codes, except ÒDTE OriginatedÓ coded as Ò10000000Ó, and diagnostic codes specified in Recommendation X.25, corresponds to an Originator-parameter value of ÒNS ProviderÓ. The value of the Reason parameter is derived as follows: a) ÒcongestionÓ if any of the following applies: - cause code ÒNetwork CongestionÓ; - cause code ÒDTE OriginatedÓ (coded as all zeros) and diagnostic 234; b) Òreason unspecifiedÓ for any other combination of cause and diagnostic codes. The cause code ÒDTE OriginatedÓ coded as Ò10000000Ó with any diagnostic code, as well as cause codes not specified in Recommendation X.25 with any diagnostic code, corresponds to values of both the Originator parameter and the Reason parameter of ÒUndefinedÓ. APPENDIX I (to Recommendation X.223) Additional Considerations of CONS Primitives I.1 Introduction The main body of this Recommendation presents a mapping between the Connection-Mode Network Service (CONS) primitives and the X.25/Packet Layer Protocol (PLP) elements. However, the designer of an end system should be aware that there are several issues related to the issuing of CONS primitives in addition to mapping them to X.25/PLP protocol elements. These issues realte to the provision of the appropriate ÒenvironmentÓ (i.e. supporting protocols at apropriate layers) within the end system in which the X.25/PLP is to operate. The purpose of this appendix is to briefly describe these issues. I.2 Environment for X.25/PLP operation For the purpose of this appendix, the environment in which the X.25/PLP operates depends on the technology of the subnetwork(s) to which the end system is attached. For example, the end system may be attached to a packet-switched public data network. While the mapping between the primitives of the CONS and the elements of the X.25/PLP does not depend on the particular subnetwork, the proprer provision of the environment for the X.25/PLP to operate does depend on it. The following subsections address the issues pertaining to provision of the environment in which the X.25/PLP operates. I.2.1 Initialization If, when receiving an N-CONNECT request primitive, the Network Layer (NL) entity determines that the necessary Subnetwork Point of Attachment (SNPA) in this end system is not available (i.e. cannot be used for transmitting CALL REQUEST packet), then appropriate procedures are necesary to be executed in the end system to make the SNPA available. Alternatively, the NL entity may reject the request. In this case, the corresponding procedures are not executed and the NL entity signals an N-DISCONNECT indication primitive to the Calling Network Service (NS) user. The Originator parameter is ÒNS ProviderÓ and the Reason parameter is ÒConnection Rejection-Reason Unspecified/Permanent Condition.Ó Note- It is beyond the scope of this Recommendation to indicate how the NL entity determines whether the necessary SNPA is or is not available. It is not the intent of this appendix to provide a complete set of procedures that are executed for the various subnetwork technologies in which the X.25/PLP may be used. Still, an example will provide an indication of these procedures. Example: Connection of an End System to an X.25 Packet-Switched Data Network Consider an end system connected to an X.25 packet-switched public data network by a dedicated line conforming to Recommendation X.21. If this interface is not available when an N- CONNECT request primitive is received by the NL entity, then the following steps are taken (in the order shown): a) the X.21 establishment procedures are performed and the X.21 data transfer phase is entered; b) the LAPB procedures are executed to establish the Link Level of the X.25 DTE/DCE interface and enter its data transfer phase; and c) the X.25/PLP restart procedure is executed. Only after the successful completion of all three steps above can the NL entity transfer an X.25/PLP CALL REQUEST packet across the DTE/DCE interface. It is also not the intent of this appendix to indicate how the NL entity is informed of the outcome of the initialization procedures. However, it is asumed that the NL entity is informed whether these procedures are successfully completed. The subsequent action of the NL entity depends on the outcome for example: a) Successful Initialization: the NL entity transmits a CALL REQUEST packet; or b) Unsuccessful Initialization: the NL entity may reattempt the initialization procedures again or signal an N-DISCONNECT indication primitive to the NS user but without transmitting a CLEAR REQUEST packet. In the latter case, the Originator parameter is ÒNS Provider.Ó The Reason parameter is ÒConnection Rejection- Reason Unspecified/Transient ConditionÓ. Note - A more detailed mapping of the Reason parameter to any diagnostic information available as a result of the failure of the initialization procedures may also be desired. In a similar fashion as above for an N-CONNECT request primitive, it should be recognized that the initialization procedures must be completed before an N-CONNECT indication primitive can be signaled to an NS user. 1.2.2 Premature Closedown If the environment in which the X.25/PLP operates prematurely closes down (i.e. while one or more NCs are established or in the process of being established), then the NL entity signals, for each established NC or NC in the process being estblished, an N- DISCONNECT indication primitive to the NS user but does not transmit a CLEAR REQUEST packet. The Originator parameter is ÒNS Provider.Ó The Reason parameter is: a) for established NCs, ÒDisconnection-Transient Condition,Ó or b) for NCs in the process of being established, ÒConnection Rejection-Transient ConditionÓ. Note - A more detailed mapping of the reason parameter to any diagnostic information available as a result of the premature closedown may also be desired. APPENDIX II (to Recommendation X.223) Use of X.25/PLP NPAI II.1 Introduction This appendix discusses the use of X.25/PLP Network Protocol Address Information (NPAI), i.e., the Address Field (AF) and the Address Extension Facility (AEF). It provides guidelines for obtaining the Subnetwork Point of Attachment (SNPA) Address from the Network Services Acces Point (NSAP)Address. It also illustrates how an NSAP Address may be encoded in X.25/PLP NPAI. II.2 Obtaining an SNPA address Two methods for obtaining an SNPA Address from an NSAP Address are described. The first one makes use of a directory, the second describes an algorithmic procedure. The two methods are not exclusive. II.2.1 Directory The directory is an abstract object which, given an NSAP Address, returns an SNPA Address. The operation of such a directory is not within the scope of this appendix. Conceptually, it may be viewed as a table look-up, a local directory, or a distributed directory. II.2.2 Algorithmic Procedure There are three cases that may be considered for deriving an SNPA Address from an NSAP Address: a) Domain Specific Part (DSP) absent: 1) The NSAP Address is composed of an Address and Format Identifier (AFI) and an Initial Domain Identifier (IDI). If the AFI is consistent with the AFI format of the subnetwork provider, the IDI may be used directly in the AF subject to network-dependent prefixes and formats to provide the encoded SNPA Address. In this case, the AFI is not conveyed as explicit protocol control information. Its existence is thus implied and must be capable of being correctly deduced by the recipient. 2) In the case where the AFI format of the NSAP Address is not consistent with the subnetwork provider, it may be necessary to make use of a directory as described in ¤ II.1.1 above. b) DSP present: The procedure to be followed in this case requires that the IDI and AFI be operated on as specified in Case (a) above to determine the SNPA Address. The only difference for this case is that, in addition to the above, the complete NSAP Address is inserted in the AEF. c) There may be cases, such as the use of escape digits (e.g. 8 = F.69, 9 = E.163), that do not require the use of directories. In cases such as this, the procedure defined in the appropriate addressing standard/recommendation (e.g. Recommendation X.121) may also be implied. II.3 Examples of NSAP Address Encoding Below are several examples of how an NSAP Address is encoded in X.25/PLP NPAI (i.e. the AF and the AEF). Section 6.2.2 specifies how this encoding is performed. As indicated, the preferred binary encoding, as defined in Recommendation X.213, is used as the encoding technique. The examples make use of hexadecimal notation; that is X`h1h2. . .` represents a string of hexadecimal digits. Padding digits are highlighted with an underscore. Example 1: AFI IDI DSP X'3 X'31341234 nul 6' 5678' l Assuming the conditions in ¤ 6.2.2.1.1 are all satisfied, the above NSAP Address is conveyed in the AF. The AF would then be encoded as: AF X'31341234 5678' Note that the need to include the Data Network Identification Code, which is 3134 in this example, and any prefix digits is a matter dependent on the packet-switched network to which the end system is attached. Example 2: AFI IDI DSP X'3 X'31341234 X'5F4230A2 7' 567890' 6789' This NSAP Address can only be conveyed in the AEF. The encoding of the Facility Parameter Field (FPF) of the AEF is as follows: FPF of AEF X'1 X'37313412345678905F C' 4230A26789' Note that the first octet of the FPF of the AEF indicates the usage of the AEF (in this case, full NSAP Addres) in bits 8 and 7 and the number of semi-octets that follow (twenty-eight) in bits 6, 5, 4, 3, 2 and 1. Example 3: AFI IDI DSP X'4 X'123456789 X'42 4' 012345' 97' This NSAP Address can only be conveyed in the AEF. The encoding of the FPF of the AEF is as follows: FPF of AEF X'1 X'4412345678901 6' 23454297F' Example 4: AFI IDI DSP X'4 X'123456789 X'FE49 5' 0123' 6A' This NSAP Address can only be conveyed in the AEF. The encoding of the FPF of the AEF is as follows: FPF of AEF X'1 X'4500123456789012 8' 3FFE496A' Example 5: AFI IDI DSP X'4 X'43 X'43678A4B09 7' 68' 5ECF' This NSAP Address can only be conveyed in the AEF. The encoding of the FPF of the AEF is as follows: FPF of AEF X'14 X'47436843678A4B ' 095ECF' APPENDIX III (to Recommendation X.223) Transit Delay Calculations This appendix illustrates how the various X.25 facilities are used to negotiate the end-to-end value of the transit delay QOS parameter. FIGURE - T0702730-87 The labels (a), (b), (c), (d), (e), (f) and (g) represent the various points between the entities involved in the scenario shown above at which the transit delay information is visible in the protocol control information. X.25 X.75 Utilities EETDN Facility Facility TDSAI TDS TDI CTD TTD MATD Call Request Phase a) t-2d1 (Note NA NA 2d1 t w 1) b) p1 NA NA 2d1 t w c) t-2d1-p1- NA NA 2d1+p1+(g1 t w (g1+g2) +g2) d) NA t-2d1-p1 p2+e 2d1+p1+(g1 t w -(g1+g2) +g2) e) p2+e+p3 NA NA 2d1+p1+(g1 t w +g2) f) t- NA NA 2d1+p1+(g1 t w [2d1+p1+(g1 +g2) +g2)] +(p2+e+p3) -(g3+g4)- + (p2+e+p3) (g3+g4) g) p4 NA NA 2d1+p1+(g1 t w +g2) +(p2+e+p3) + (g3+g4) Call Confirmation Phase (Note 2) g) NA NA NA 2d1+p1+(g1 NA NA +g2) +(p2+e+p3) + (g3+g4)+p4 f) p4 NA NA 2d1+p1+(g1 NA NA +g2) +(p2+e+p3) + (g3+g4)+p4 e) NA NA NA 2d1+p1+(g1 NA NA +g2) +(p2+e+p3) + (g3+g4)+p4 d) NA NA p2+e+p3 2d1+p1+(g1 NA NA +g2) +(p2+e+p3) + (g3+g4)+p4 c) p2+e+p3 NA NA 2d1+p1+(g1 NA NA +g2) +(p2+e+p3) + (g3+g4)+p4 b) NA NA NA 2d1+p1+(g1 NA NA +g2) +(p2+e+p3) + (g3+g4)+p4 a) p1 NA NA 2d1+p1+(g1 NA NA +g2) +(p2+e+p3) + (g3+g4)+p4 Note 1 - The calling DTE asumes d2 is the same as d1. Note 2 - The called DTE accepts the call if: 2d1+p1+(g1+g2)+(p2+e+p3)+(g3+g4)+p4£w. CTD Cumullative Transit Delay. EETDN End-to-End Transit Delay Negotiation (Facility). MATD Maximum-Acceptable Transit Delay. NA Not Applicable. TDI Transit Delay Indication (Utility). TDS Transit Delay Selection (Utility). TDSAI Transit Delay Selection and Indication (Facility). TTD Target Transit Delay. APPENDIX IV (to Recommendation X.223) Differences between Recommendation X.223 and ISO 8878 Recommendation X.223 is technically aligned with ISO 8878 (including only the aspects of Addendum 1 contained in SC 6 N5181 dealing with 64 kbit/s throughput class, and the erratum contained in SC 6 N5185) except for the following exceptions: IV.1 In Recommendatin X.223, the text in ¤ 6.2.2.1.1 specifies that, under certain conditions, the NSAP Address is always carried in the AF whereas ISO 8878 leaves this as an option. ISO 8878 lists three conditions; Recommendation X.223 lists these three plus a fourth, as follows: Òthe NL entity, through local knowledge, is aware that the remote NL entity does not operate according to CCITT Recommendation X.223 and cannot recognize the AEFÓ. IV.2 In Recommendation X.223, the text in ¤ 6.2.4 specifies that if Òno use of Expedited DataÓ is indicated or if the NL entity cannot support 32-octet INTERRUPT packets, then the EDN facility is always omitted. for the same case, ISO 8878 specifies that the EDN facility either may be carried specifying Òno use Expedited DataÓ, or may be omitted. IV.3 In ¤ 6.2.5.1 (Throughput QOS Parameters) of Recommendation X.223, two new paragraphs have been added which are not present in ISO 8878. These paragraphs are the last paragraph in ¤ 6.2.5.1.1, and the last paragraph in ¤ 6.2.5.1.2. Collectively, these paragraphs specify that whenever the Lowest Quality Acceptable sub-parameters of the Throughput QOS Parameters for both directions are ÒunspecifiedÓ in the N-CONNECT request, the MTCN facility is not included in the CALL REQUEST packet. ISO 8878 specifies that in such a case, the MTCN facility is encoded as 75 bits per second. IV.4 In ¤ 6.2.5.2 (Transit Delay QOS Parameter) of Recommendation X.223, four new paragraphs have been added which are not present in ISO 8878. These paragraphs are the last paragraph in ¤ 6.2.5.2.1, the last paragraph in ¤ 6.2.5.2.2, the last paragraph in ¤ 6.2.5.2.3 and the last paragraph in ¤ 6.2.5.2.4. Collectively, these paragraphs specify that whenever the Target and Lowest Quality Acceptable sub-parameters of the Transit Delay QOS Parameter are ÒunspecifiedÓ in the N-CONNECT request, the EETDN facility is not included in the CALL REQUEST packet. ISO 8878 does not address the case of the EETDN facility being absent. Additionally, in ¤ 6.2.5.2.1 of Recommendation X.223, the last sentence in Item d specifies that in DTE-to-DTE operational environments the usage of the TDSAI facility is for further study. ISO 8878 does not have such a sentence. IV.5 The scope of Recommendation X.223 does not include for provision of the OSI Connection-mode Network Service over 1980 X.25 subnetworks. Conversely, ISO 8878 provides for this and defines a protocol mechanism in Annex A. Also, material related to interoperability issues, including those raised by the presence of Annex A, is included in Annex B to ISO 8878 and is not included in this Recommendation.