brian@sdcc3.UUCP (Brian Kantor) (01/07/85)
ACKNOWLEDGMENTS This specification was prepared by BBN Communications Corporation under contract to the Defense Data Network Program Management Office of the Defense Communications Agency. The specification has been reviewed by the Defense Communications Engineering Center for accuracy and completeness. The draft of this specification has been disseminated to industry by the National Bureau of Standards for review and comments which have been incorporated in the final specification. This specification has been approved for use on the Defense Data Network by the DoD Protocol Standards Steering Group. Comments on this specification should be directed to the Defense Communications Agency, ATTN: Defense Data Network Program Managment Office, Code B610, Washington, D.C. 20305 Table of Contents 1 INTRODUCTION.......................................... 1 1.1 Background.......................................... 1 1.1.1 X.25 and FIPS 100/Federal Standard 1041........... 1 1.1.2 X.25-to-X.25 and X.25-to-1822 Interoperability................................ 2 1.2 Compliance.......................................... 4 1.2.1 Compliance With CCITT X.25 and FIPS 100/Fed. Std. 1041.............................. 4 1.2.2 DTE Compliance With This Specification............ 4 2 INTERFACE SPECIFICATION............................... 6 2'1 Call Establishment Conventions...................... 6 2.1.1 Addressing........................................ 6 2.1.1.1 Address Formats and Fields...................... 6 2.1.1.1.1 Reserved...................................... 7 2.1.1.1.2 Flag.......................................... 7 2.1.1.1.3 DDN host Identifier........................... 7 2.1.1.1.4 Sub-Address................................... 7 2.1.1.2 Supplying Missing Address Information........... 7 2.1.2 DDN-Specific Facilities........................... 8 2.1.2.1 Type of Service Selection....................... 8 2.1.2.2 Call Precedence................................. 9 2.1.3 Protocol Identification.......................... 10 2.1.4 Logical Channel Assignment....................... 10 2.2 Packet Level Procedures............................ 11 2.3 Link Level Procedures.............................. 12 2.3.1 Link Level Parameters and Options................ 12 2.3.2 Timer T1 and Parameter T2........................ 12 2.3.3 Maximum I Frame Size............................. 13 2.4 Physical Level Specifications...................... 14 3 BIBLIOGRAPHY......................................... 16 APPENDIX A: DDN X.25 Implementation Details............ A-1 A-1 Introduction...................................... A-1 A-2 Operational Features of DDN X.25 DCE Releases..... A-1 A-2.1 Initial Feature Support......................... A-1 A-2.2 Exception-Handling Procedures................... A-2 A-2.2.1 Non-Octet-Aligned Data........................ A-2 A-2.2.2 RESTART REQUEST Packet........................ A-2 A-2.2.3 RESET REQUEST Packet.......................... A-2 A-2.2.9 CLEAR REQUEST Packet.......................... A-3 A-2.3 Virtual Circuit Resource Availability........... A-3 A-3 Detailed Features and Facilities Specifications.................................. A-3 A-3.1 Additional Diagnostic Codes..................... A-3 A-3.2 X.25 IP Interoperability Considerations......... A-6 A-3.3 The DDN Logical Addressing Facility............. A-7 A-3.3.1 Logical Addresses............................. A-7 A-3.3.2 Enabling and Disabling Logical Addresses...... A-7 A-4 Limitations of DDN Basic X.25 Service............. A-8 A-5 Derivation of DDN X.25 Addresses.................. A-9 APPENDIX Q: DDN Synchronous Level 1 Specification...... B-1 B-1 Introduction...................................... B-1 B-2 Supported Interfaces.............................. B-1 APPENDIX C: Federal Information Processing Standard Publication 100...................................... C-1 TABLES DDN X.25 Address Fields................................... 7 "Derivation of Maximum I Frame Size".................... 14 DDN X.25 Physical Signaling Rates and Interfaces......... 15 Additional Packet Level Diagnostic Codes................ A-4 IP Precedence to X.25 Precedence Mapping................ A-6 EIA and CCITT Interchange Circuits...................... B-3 Signal Selection by CCITT Interchange Circuit Number................................................ B-4 Typical Level 1 Connection Schemes...................... B-5 Interface Type by Service Speed......................... B-7 RS-232-C Interface...................................... B-8 MIL-188-114 Interface (and equivalents)................. B-9 V.35 Interface......................................... B-10 FIGURES Typical Level 1 Connection Schemes...................... B-4 INTRODUCTION This report specifies the attachment of an X.25 host to the Defense Data Network (DDN). In particular, this report describes specific options and features of CCITT Recommendation X.25 (1980) and Federal Information Processing Standard (FIPS) 100/Federal Standard (Fed. Std.) 1041 (July 1983) required of a host X.25 implementation to enable that host to communicate with a DDN X.25 Interface Message Processor ("IMP", the DDN packet switching node). This report, in conjunction with FIPS 100/Fed. Std. 1041, should enable DDN host site managers and others planning to attach a host by means of X.25, rather than the 1822 interface, to determine, first, whether or not the X.25 implementation of the host in question is adequate for operation with DDN, and, second, what options, parameter settings, etc. must or may be selected for operation with DDN. This report assumes that the reader is familiar with CCITT Recommendation X.25 and FIPS 100/Fed. Std. 1041. A copy of FIPS 100/Fed. Std. 1041 is attached as Appendix C of this report. In this document, the term "Administration" refers to the Defense Communications Agency (DCA Code B610, Washington, D. C. 20305). 1.1 Background 1.1.1 X.25 and FIPS 100/Federal Standard 1041 The CCITT Recommendation X.25 describes the interface between host computers (data terminal equipment, or DTEs) and data circuit-terminating equipment (DCEs, which effect communication with remote hosts over computer networks) for hosts operating in the packet mode on public data networks. The X.25 interface standard is defined as three independent architectural levels, following the Open Systems Interconnection (OSI) Reference Model. The three levels are: Level 1: The PHYSICAL level of the connection. The physical, electrical, functional, and procedural characteristics to activate, _____________ * As used in this report, "1822 interface" refers to the interface specified in Bolt Beranek and Newman Inc. (BBN) Report No. 1822, "Specification for the Interconnection of a Host and an IMP," revision of December 1981. -1- maintain, and deactivate the physical link between the DTE and the DCE. Level 2: The LINK level of the connection. The link access procedure for data interchange across the link between the DTE and the DCE. Level 3: The PACKET level of the connection. The packet format and control procedures for the exchange of packets containing control information and user data between the DTE and the DCE, and between the DTE and a remote DTE. CCITT Recommendation X.25 contains many options and implementation choices. FIPS 100/Fed. Std. 1041, which specifies the general use of X.25 for the Federal Government, defines some of the choices left open in X.25. This document describes the X.25 interface to a particular network, DDN. Thus in several areas where X.25 allows a choice, a single choice appropriate for DDN is specified; in areas which X.25 leaves unspecified, addressing in particular, conventions are specified that are consistent with the overall architecture of DDN and the interoperability goals described below. The effect of this approach is to make DDN service available to hosts in a way that requires no changes to a host DTE implementation that is compliant with FIPS 100/Fed. Std. 1041 and CCITT Recommendation X.25. By implementing extensions described in this specification, a host will be able to take advantage of additional DDN features required in military networks, such as precedence and logical addressing. The reader is referred to CCITT Recommendation X.25 and to FIPS 100/Fed. Std. 1041 for detailed information not provided in the body of this document. 1.1.2 X.25-to-X.25 and X.25-to-1822 Interoperability A key goal of the DDN X.25 implementation is interoperability among all DDN subscribers. That is, effective communication should be possible, not only between subscribers attached to the DDN using identical vendor-supplied X.25 implementations, but between subscribers using different X.25 implementations, and between a subscriber using an X.25 interface to the DDN and a subscriber using an 1822 interface to the DDN. Achieving this goal of interoperability requires that all DDN -2- X.25 subscribers conform to this interface specification and implement the DoD standard higher level protocols. True interoperability among DDN hosts requires, in particular, implementation of the DoD standard protocols TCP (Transmission Control Protocol) and IP (Internet Protocol), as well as the higher-level protocols which implement DDN standard services, " when such services are provided by the host: the Telnet Protocol for character-oriented terminal support, the File Transfer Protocol (FTP) for file movement between hosts, and the Simple Mail Transfer Protocol (SMTP) for communication between electronic mail service hosts. The DDN X.25 DCE offers two types of service to X.25 DTEs: 1. DDN Standard X.25 Service, which, when used in conjunction with DoD standard protocols, provides interoperable communication between an X.25 DTE and other DDN hosts that also implement the DoD standard protocols, whether they are connected to DDN via the 1822 interface or via the X.25 interface; and 2. DDN Basic X.25 Service, which provides communication only between an X.25 DTE and other DDN X.25 DTEs implementing compatible higher-level protocols. Section 2.1.2.1 of this report describes the conventions to be used by a DTE to specify the type of service desired for each X.25 virtual call. All DDN X.25 DTEs will be required to develop and initiate a plan to use the DoD standard protocol architecture and DDN standard X.25 service. Use of DDN basic X.25 service imposes some restrictions on the nature of the network communications service that a host can obtain. These restrictions are discussed in Appendix A, Section A-4. -3- 1.2 Compliance 1.2.1 Compliance With CCITT X.25 and FIPS 100/Fed. Std. 1041 The DDN X.25 Interface Specification is compliant with CCITT Recommendation X.25 and FIPS 100/Fed. Std. 1041. The DDN X.25 DCE supports all facilities specified as E (essential) by FIPS 100/Fed. Std. 1041, and no facilities specified as A (additional). The additional facilities not supported are: (i) datagrams and associated facilities, and (ii) bilateral closed user groups. In that FIPS 100/Fed. Std. 1041 describes features for a DCE, DDN X.25 DTEs may support any or all facilities specified as either E or A by FIPS 100/Fed Std. 1041. However, DDN X.25 DTEs must not use the facilities identified above that are not supported by the DDN X.25 DCE. 1.2.2 DTE Compliance With This Specification This document specifies several areas in which the DDN X.25 DCE is capable of operating in several modes. For example, Section 2.4 lists a number of signaling rates supported by the DCE. In such cases, a DDN X.25 DTE must implement at least one of the options listed (or the set of options required of a DTE by FIPS 100/Fed. Std. 1041) but need not implement all of the options listed (unless required by FIPS 100/Fed. Std. 1041). Determining the adequacy of the options supported by a DTE vendor for meeting a DDN subscriber's requirements is the responsibility of the subscriber. In addition to the CCITT X.25 and FIPS 100/Fed. Std. 1041 requirements described in Section 1.2.1 above, DDN X.25 DTEs may wish to take advantage of additional DDN-specific features that are compatible extensions to the public standards. Implementation of a DDN-specific feature by a host is required only if the host wishes to take advantage of the service or information provided by the feature. For example, a host that wishes to establish calls only at the default precedence level assigned to it need not implement the precedence facility described in Section 2.1.2.2. However, a host that wishes to have flexibility in the precedence of the calls it establishes must implement this facility. -4- Any deficiencies with respect to this specification in a vendor-supplied X.25 DTE implementation contemplated for use with the DDN X.25 DCE should be rectified so as to attain compliance with this specification. Proper operation with DDN of an X.25 DTE that is not compliant with this specification cannot be guaranteed and should not be attempted. To this end, a test program is available through the Administration. 2 INTERFACE SPECIFICATION 2.1 Call Establishment Conventions This section specifies DDN X.25 call establishment conventions. 2.1.1 Addressing DDN addresses are assigned to subscriber DTEs by the Administration. Two basic forms of address are provided: physical addresses, which correspond to the node number and DCE port number of the node to which the DTE is connected, and logical addresses, which are mapped transparently by DCE software into a corresponding physical network address. Each DTE is assigned one physical address, and may be assigned one or more logical addresses. All DDN addresses are either twelve or fourteen BCD (binary-coded decimal) digits in length. A calling DTE need not determine whether a given address is a physical or logical address, in order to establish a call to that address. .2.1.1.1 Address Formats and Fields DDN addresses have the following format: ZZZZ F DDDDDDD (SS) The various fields of the address are presented in Table 2.1 and are explained below. Length Field Meaning (BCD digits) ZZZZ Reserved (must be zero) 4 F Flag 1 DDDDDDD DDN Host Identifier 7 (SS) Sub-address (optional) 0 or 2 TOTAL 12 or 14 Table 2.1 DDN X.25 Address Fields -6- 2.1.1.1.1 Reserved The Reserved field corresponds to the DNIC field generally used in public data networks. Pending assignment of a DDN DNIC, this field must be zero. 2.1.1.1.2 Flag The Flag field is used to differentiate physical and logical addressing. The value zero indicates physical addressing, while the value one indicates logical addressing. A value of nine is used in the setup of calls to enable and disable logical addresses; see Appendix A, Section A-3.3.1. 2.1.1.1.3 DDN Host Identifier The DDN Host Identifier is a seven-digit address, either logical or physical, assigned to a subscriber DTE by the DDN Administration. 2.1.1.1.4 Sub-Address The Sub-Address may be used by a DTE for any.purpose. It is carried across the network without modification. Its presence is optional. 2.1.1.2 Supplying Missing Address Information The DDN X.25 DCE incorporates a mechanism to supply "missing" address information in CALL REQUEST and CALL ACCEPTED packets received from an attached DTE. This mechanism is useful in DTE software testing and physical address determination. If a DTE sends a CALL REQUEST packet with no calling address field, the local DCE will insert the physical calling DDN Host Identifier with no subaddress field. If a DTE sends a CALL REQUEST or CALL ACCEPTED packet with either or both calling or called addresses that contain F = zero and DDDDDDD = zero, the local DCE will replace the DDN Host Identifier field (DDDDDDD) with the physical address of the DTE. -7- DTE implementors are cautioned that use of this mechanism in accepting calls to a DTE's logical address (See Appendix A, Section A-3.3) can result in confusion on the part of the calling DTE and is not advised. 2.1.2 DDN-Specific Facilities Two DDN-specific features are requested by means of "private" or non-CCITT facilities in CALL REQUEST and CALL ACCEPTED packets. If either or both of these facilities are requested in a CALL REQUEST or CALL ACCEPTED packet, they must follow all CCITT X.25 facilities and must be preceded by a single facility marker, two octets of zero. 2.1.2.1 Type of Service Selection The DDN X.25 provides two types of service, DDN basic X.25 service and DDN standard X.25 service. DDN standard X.25 service provides only local DTE to local DCE support of the X.25 connection. Data is carried via the network to its destination (using protocols internal to the network), where it is delivered using the access protocol of the destination host (i.e., either 1822 or DDN standard X.25 service). This access method is oriented towards DDN X.25 hosts using the DoD standard TCP/IP higher level protocols. No X.25 procedures change when using DDN standard X.25 service; however, the significance of the procedures changes (see Appendix A, Section A-3.2). There is no end-to-end X.25-level acknowledgment or guarantee of delivery of data packets with DDN standard X.25 service; reliability of DDN standard X.25 service is provided instead by the use of a reliable transport protocol. DDN basic X.25 service provides end-to-end call management with significance as described in CCITT Recommendation X.25 and FIPS 100/Fed. Std. 1041. This access method is oriented towards hosts that have existing higher level protocol implementations that require reliable packet delivery at the network level. Selection of DDN standard or DDN basic X.25 service must be made on a call-by-call basis by the DDN X.25 DTE at the time of call setup. To specify DDN standard X.25 service, a DTE must include in the CALL REQUEST packet a facility two octets long, coded as follows: 00000100 00000001 -8- If this facility is not specified, DDN basic X.25 service will be provided. 2.1.2.2 Call Precedence The precedence of a call is negotiated by an X.25 DTE by means of a facility two octets long, coded as: 00001000 000000XX where XX is the precedence, from 0 (lowest precedence) to 3 (highest precedence). If this facility is not used, the call will be established at the subscriber's default precedence. A DTE is not permitted to establish a call at a precedence level higher than that authorized for that DTE by the Administration. An attempt to do so will result in the DDN X.25 DCE returning to the DTE a CLEAR INDICATION packet with clearing cause 00001001, "Out of order," with diagnostic code 194, "Requested precedence too high". Calls of a lower precedence may be cleared by a DCE if DCE or other network resources are required, or if access to the local or remote DTE is required (for a call of higher precedence). In this event, a CLEAR INDICATION packet will be sent with the clearing cause 00000101, "Network congestion," and with a diagnostic code specifying the reason for the preemption. The diagnostic codes employed for this purpose are 192, "Cleared due to higher precedence call at local DCE," and 193, "Cleared due to higher precedence call at remote DCE". Similarly, an attempt to establish a call may be unsuccessful if network resources are engaged in calls of higher priority than that requested. In this case, a CLEAR INDICATION packet will be sent with the clearing cause 00001001, "Out of order," and with either diagnostic code 192 or 193, as appropriate. The diagnostic codes described in the preceding paragraphs are DDN-specific diagnostic codes; additional information about these codes may be found in Appendix A, Section A-3.1. -9- 2.1.3 Protocol Identification X.25 DTEs employing the DoD standard TCP/IP protocol architecture must indicate this by means of the call user data field of the CALL REQUEST packet. The first octet of this field must be set to 11001100 to identify the DoD standard protocol architecture. Indication of the use of the DoD standard protocol architecture is independent of the selection of DDN standard or DDN basic X.25 service by means of the facility specified in Section 2.1.2.1 above. Therefore, a host employing the DoD standard protocol architecture and using DDN standard X.25 service must include both the DDN standard X.25 service facility and the call user data DoD standard protocol identification in its CALL REQUEST packet. A DTE using a protocol architecture other than the standard DoD protocol architecture is free to use any call user data protocol identification recognized by the DTEs with which it wishes to communicate. Identification of protocol architectures other than the DoD standard architecture is not standardized or enforced by the Administration. Subscribers are cautioned, therefore, that conflicts among various vendor-assigned protocol identifications may arise. 2.1.4 Logical Channel Assignment The assignment of logical channels by the DDN X.25 DCE follows the requirements and guidelines of FIPS 100/Fed. Std. 1041 and Annex A of CCITT X.25. Within the guidelines of CCITT X.25 Annex A, the range of logical channel numbers assigned to permanent virtual circuits, incoming, two-way, and outgoing virtual calls for DDN DCEs is configured for each DTE attached to a DCE by the Administration. DDN X.25 DTEs must follow the logical channel selection requirements of FIPS 100/Fed. Std. 1041. The number of logical channels available to a DTE is dependent upon the configuration of the DCE to which the DTE is attached, and upon the dynamic requirements placed upon other DCEs that share the same DDN packet switching node. -10- 2.2 Packet Level Procedures DDN X.25 packet level procedures are as specified by FIPS 100/Fed. Std. 1041 and CCITT X.25. The following additional information is provided: 1. The maximum window size that may be negotiated is seven. 2. Modulo 128 packet level sequence numbering is not supported. 3. Maximum packet sizes of 16, 32, 64, 128, 256, 512, and 1024 octets may be negotiated. 4. The DDN X.25 DCE uses additional packet level diagnostic codes, specified in Appendix A, Table A-1. DDN X.25 DTEs may, but are not required to, make use of the information conveyed by these codes. 5. The Qualifier bit (Q-bit) is passed transparently by the DDN X.25 DCE in DDN basic X.25 service. DTEs using DDN basic X.25 service may use the Q- bit in any way that is consistent with FIPS 100/Fed. Std. 1041. 6. The DDN X.25 DCE implements the diagnostic packet. It is sent under conditions specified in Annex D of CCITT X.25. The DTE is not required to act on the information provided in diagnostic packets. 7. DTEs using DDN standard X.25 service must restrict the maximum number of data bits in a complete packet sequence to be no more than 8056. This ensures that the data from a packet sequence transmitted by an X.25 host will fit within the maximum 1822 message length limit upon delivery to an 1822 host. This restriction is necessary as existing 1822 host implementations are not re- quired to accept messages longer than 8063 bits. * ________________ * DTEs using DDN standard X.25 service will generally be transmitting Internet Protocol datagrams, the length of which, by convention, does not approach this limit. Therefore, unless a protocol other than the Internet Protocol is used with DDN standard X.25 service, this is a technical restriction that will have no practical impact upon the design of DTE software. See Appendix A, Section A-3.2. -11- DDN X.25 DTEs connecting to DDN through an X.25 Internet Private Line Interface (IPLI) must reduce the maximum complete packet sequence length by an additional 256 bits to allow for IPLI overhead. 2.3 Link Level Procedures DDN X.25 link level procedures are as specified by FIPS 100/Fed. Std. 1041 and CCITT X.25. This section presents additional information. 2.3.1 Link Level Parameters and Options 1. The default value of K, the maximum number of sequentially numbered I frames that the DCE will have outstanding (unacknowledged) at any given time, is seven. A DDN X.25 DCE may be configured on a per-DTE basis to provide optional values of K from one to six. 2. The default value of N2, the maximum number of transmissions and retransmissions of a frame following the expiration of the T1 timer, is twenty. This value can be changed to any value from one to 200 as a DCE configuration parameter on a per-DTE basis. 3. The optional 32-bit FCS is not supported. 2.3.2 Timer T1 and Parameter T2 The period of the timer T1 used by the DDN X.25 DCE reflects assumptions about the processing speed of the DTE. The DCE assumes that parameter T2, the response latency of the DTE to a frame from the DCE, is no greater than 1/2 second. Likewise, the DCE guarantees that its parameter T2, the latency in responding to frames from the DTE, is 1/2 second for signaling rates of 19.2 Kb/s or slower, and 1/4 second for faster links. A lower bound for timer T1 may be computed to be 4X + T2, based on the assumptions that: * the link propagation time is negligible, -12- * the worst-case frame transmission time is X, * timer T1 is started when a frame is scheduled for output, * each frame is scheduled just as transmission of the previous frame starts, * frames are not aborted, and * each frame and its predecessor are of maximum length Nl = 8248 bits (see Section 2.3.3 below). As an example, for a signaling rate of 9.6 Kb/s, this yields X = .86 sec. If T2 is .5 sec., the total time for the DTE to respond in the worst case should be 3.9 seconds. In fact, the DCE uses a T1 timer value of 4 seconds for a link speed of 9.6 Kb/s. In no case does the DCE use a value for T1 smaller than 3 seconds. This means that, for faster links, the DTE's T2 parameter may be lengthened because the X term in the above formula is smaller. For links of 19.2 Kb/s or faster, DTEs are expected to satisfy latency requirements that allow the DCE to use the formula 4X + T2 (DTE) < 3 seconds = T1 (DCE). The DTE may choose any value for T1 that is compatible with the DCE's T2 parameter values. The value of T1 used by the DTE may always be set longer than the formula indicates, with the result that recovery from certain types of link errors will be slower. However, the DCE's parameter T2 cannot be reduced, so the formula should be viewed as yielding a lower bound on the DTE's T1 timer. 2.3.3 Maximum I Frame Size The maximum number Nl of bits in an I Frame is 8248, accommodating a data packet with up to 1024 data octets. The derivation of this number is shown in Table 2.2. DTEs using DDN standard X.25 service must observe the restriction on the number of data bits in a complete packet sequence given in Section 2.2 above. -13- X.25 No. of Field Name Level Bits Address 2 8 Control 2 8 General Format Identifier 3 4 Logical Channel Number 3 12 Packet Type 3 8 User Data 3 8192 (max) Frame Check Sequence 2 16 TOTAL 8248 (max) Table 2.2 Derivation of Maximum I Frame Size 2.4 Physical Level Specifications The DDN X.25 physical level specification is in conformance with FIPS 100/Fed. Std. 1041 and CCITT X.25. This section presents additional information. A DDN X.25 DTE may either be collocated with its DCE or may be connected to it via an access line. In all cases the DTE presents a physical DTE interface; the DDN will supply the matching DCE interface. DDN X.25 service offers four physical level interfaces: RS-232-C (CCITT V.28), RS-449, both balanced and unbalanced (CCITT V.ll and V.10, respectively; also MIL-188- 114 balanced and unbalanced), and CCITT V.35. Appendix B of this document describes in detail the choices of physical interface available to the DDN subscriber and the specifications for each type of interface. Table 2.3, below, summarizes the physical interfaces available at each data rate supported by the DDN X.25 DCE, and indicates which interfaces are recommended at each signaling rate. A DDN X.25 DTE may implement any or all of the signaling rates shown. At each signaling rate implemented, the DTE must offer at least one of the physical interface options listed as "R" (recommended) or "A" (available) for that rate in Table 2.3. Implementors are encouraged to offer the widest variety of signaling rates and physical interfaces practical to maximize the ease of use of their equipment in DDN. -14- Physical Signaling Rate in Kb/s Interface 1.2 2.4 4.8 9.6 14.4 48 50 56 64 100 RS-232-C R R R R R - - - - - RS-449 unbal. A A A A - - - - - - (and equiv.) RS-449 balanced A A A A A A A A A R (and equiv.) CCITT V.35 - - - - - R A R R A Legend R = Recommended A = Available - = Not available (Taken from Appendix B, Table B-4 Table 2.3 DDN X.25 Physical Signaling Rates and Interfaces 3 BIBLIOGRAPHY 1. "Specification for the Interconnection of a Host and an IMP". Report No. 1822, Bolt Beranek and Newman Inc" Cambridge, MA, revision of December 1981. 2. CCITT Recommendation X.25, "Interface Between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks," International Telegraph and Telephone Consultative Committee Yellow food, Vol. VIII.2, Geneva, 1981. 3. "Defense Data Network Subscriber Interface Guide," Defense Communications Agency, Washington, DC, July 1983. 4. "Internet Protocol Transition Workbook," SRI International, Menlo Park, CA, March 1982. 5. "Internet Protocol Implementation Guide," SRI International, Menlo Park, CA, August 1982. APPENDIX A: DDN X.25 Implementation Details A-1 Introduction This Appendix serves three purposes. First, it provides information concerning the planned evolution of DDN X.25 capabilities. Second, it provides information on the use of certain DDN X.25 features and facilities at a greater level of detail than is appropriate for inclusion in the body of the DDN X.25 Interface Specification. Specifications for the use of DDN X.25 features and facilities given in this Appendix are mandatory on the part of DDN X.25 DTEs that wish to make use of these features and facilities. Finally, this Appendix presents a discussion of the limitations on the use of DDN services that will be encountered by hosts using only DDN basic X.25 service. A-2 Operational Features of DDN X.25 DCE Releases The capabilities of the DDN X.25 DCE will evolve over time from an initial set of capabilities to the full capabilities of this DDN X.25 Interface Specification. This section describes release-dependent features of the DDN X.25 DCE. Implementors should note that not all optional facilities of the specification will initially be available for use by DTEs. Releases of new DCE capabilities will be compatible with DTE hardware and software implementations that meet the full DDN X.25 Interface Specification. A-2.1 Initial Feature Support The initial release of the DDN X.25 DCE will support flow control parameter negotiation and fast select. In addition, the DDN X.25 DCE may be configured by the DDN Administration to provide non-standard default window and packet sizes as described in CCITT X.25 Sections 7.1.2 and 7.2.1. The call precedence and type of service selection facilities will be accepted, but not acted upon, by the network. Only DDN basic X.25 service will be supported. Planned future DCE releases will support all facilities specified in FIPS 100/Federal Standard 1041 with the exception of those "additional" facilities that are listed in Section 1.2.1 of this document. A-1 A detailed schedule of DDN X.25 DCE releases and the capabilities of each release will be supplied in a separate document. A-2.2 Exception-Handling Procedures Certain of the exception- or error-handling procedures of the initial release of the DDN X.25 DCE differ in detail from the procedures specified in FIPS 100/Federal Standard 1041. These differences are described below. A later release of the DDN X.25 DCE will bring these procedures into conformance. In the interim, the variances in these procedures will not preclude satisfactory operation between the DCE and a DTE, provided the DTE operates in accordance with FIPS 100/Federal Standard 1041. A-2.2.1 Non-Octet-Aligned Data Data packets received by the DDN X.25 DCE that are not aligned on an octet boundary are discarded at the link level. They are not passed to the DCE packet level, and no packet level diagnostic code is returned to the DTE. A-2.2.2 RESTART REQUEST Packet The DDN X.25 DCE will not discard, but will instead act upon, a RESTART REQUEST packet that (i) is too long (unless it exceeds the maximum frame size for the link level), or (ii) contains a non-zero cause field. A-2.2.3 RESET REQUEST Packet The DDN X.25 DCE will not discard, but will instead act upon, a RESET REQUEST packet that contains a non-zero reset cause field. A-2 A-2.2.4 CLEAR REQUEST Packet The DDN X.25 DCE will not discard, but will instead act upon, a CLEAR REQUEST packet that contains a non-zero clearing cause field. A-2.3 Virtual Circuit Resource Availability In its current implementation, the DDN X.25 packet switching node is capable of supporting a minimum of one hundred simultaneous virtual circuits. As was discussed in Section 2.1.4, resources of the node are shared dynamically among the DCEs attached to the node. Therefore, no explicit guarantees are made of the number of simultaneous virtual circuits that can be made by a single DTE. Depending upon the configuration of the node, the number of simultaneous circuits supported by the node can be significantly greater than one hundred. A-3 Detailed Features and Facilities Specifications This section provides detailed specifications and descriptions of use for certain DDN X.25 features and facilities. A-3.1 Additional Diagnostic Codes The DDN X.25 DCE is capable of providing additional information to DTEs in RESTART, RESET, CLEAR INDICATION, and DIAGNOSTIC packets by means of diagnostic codes that are extensions to the set of diagnostic codes given in Annex E of CCITT Recommendation X.25. These codes are taken from the set of codes "reserved for network specific diagnostic information," and are thus not in conflict with code assignments made in Annex E. The values of these codes, and their meanings, are given in Table A-1 below. A-3 Code Value Meaning 128 IMP is unavailable. The packet-forwarding mechanisms of the network are unavailable to the DCE. Sent in RESET, CLEAR and RESTART packets. 130 Link level came up. Sent in RESTART and RESET packets. 131 Link level went down at remote DTE. Sent in CLEAR and RESET packets. 132 Remote DTE restarted. Sent in CLEAR and RESET packets. 133 Local resources not available for call establishment. The local DCE has too few resources to establish another call. Sent in CLEAR and DIAGNOSTIC packets. 134 Remote resources not available for call establishment. The remote DCE has too few resources to establish another call. Sent in CLEAR packets. 136 Remote host dead. The link to the remote DTE is down. Sent in CLEAR and RESET packets. 137 Remote IMP dead. The IMP to which the remote DTE is attached is down. Sent in CLEAR and RESET packets. 138 Logical subnetwork access barred. The remote DTE cannot be reached because of a communities-of- interest prohibition. Sent in CLEAR and RESET packets. 139 Connection lost. An internal error has occurred at either the remote or the local DCE which has made their virtual circuit data structures inconsistent. Sent in CLEAR and RESET packets. 140 Response lost. A response from the remote DCE failed to arrive within a reasonable time. Sent in CLEAR and RESET packets. A-4 141 Calling logical address not enabled or not authorized. Sent in CLEAR packets. 142 Calling logical name incorrect for this DTE. Sent in CLEAR packets. 143 Called logical name not authorized. Sent in CLEAR packets. 144 Called logical name not enabled. Sent in CLEAR packets. 145 Called logical name has no enabled DTEs. Sent in CLEAR packets. 146 Use of logical addresses invalid in this network. Sent in CLEAR packets. 147 Declared logical name now in effect. Sent in CLEAR packets. 148 Declared logical name was already in effect. Sent in CLEAR packets. 149 Declared logical name is now disabled. Sent in CLEAR packets. 150 Declared logical name was already disabled. Sent in CLEAR packets. 151 Incoming calls barred. Sent in CLEAR packets. 152 Outgoing calls barred. Sent in CLEAR packets. 192 Cleared due to higher precedence call at local DCE. Sent in CLEAR packets. 193 Cleared due to higher precedence call at remote DCE. Sent in CLEAR packets. 194 Requested precedence too high. The DTE is not authorized to establish a call at the requested precedence level. Sent in CLEAR packets. Table A-1. Additional Packet Level Diagnostic Codes A-5 A-3.2 X.25 IP Interoperability Considerations When DDN standard X.25 service is requested at call establishment (as described in Section 2.1.2.1), the call is in effect established between the DTE and a local X.25 entity. This entity subsequently extracts the IP datagrams from the X.25 data packets for transmission through the DDN Internet. This approach requires that certain conventions be followed: 1. IP datagrams are to be sent as X.25 complete packet sequences. That is, datagrams begin on packet boundaries and the M ("more data") bit is used for datagrams that are larger than one packet. Only one IP datagram is to be sent per X.25 complete packet sequence. 2. By convention, the maximum IP datagram size is 576 octets. This packet size can most efficiently be accommodated by negotiating an X.25 maximum packet size of 1024; alternatively, a DTE may use an X.25 complete packet sequence to transmit an IP datagram. 3. Because the X.25 connection is in effect terminated locally, the D and Q bits have no significance and should be set to zero. 4. The precedence bits of the IP type-of-service field are to be mapped into X.25 precedence bits (see Section 2.1.2.2) as specified in Table A-2. IP Precedence X.25 Precedence 000 00 001 01 010 10 011 - 111 11 Table A-2. IP Precedence to X.25 Precedence Mapping A-6 A-3.3 The DDN Logical Addressing Facility The DDN logical addressing facility allows references to hosts by either their physical network address or by one or more location-independent logical addresses, and allows hosts to exercise partial control over the logical address(es) by which they can be referenced. Implementation of DDN logical addressing by a host is optional. The DDN Administration will assign seven-digit logical addresses, and will maintain a logical addressing data base. The host is then responsible for notifying the network ("enabling") of the "names" (logical addresses), if any, by which it wishes to be known. It cannot receive calls addressed to a name or originate calls under that name unless it has enabled that name. It also cannot enable a name that is not authorized for that physical address. Names can also be enabled automatically by the network, under the control of the Administration. A-3.3.1 Logical Addresses Logical addressing is invoked when a called address is supplied to the IMP with the flag digit F = one. The logical address consists of seven BCD digits. This name is mapped by the logical addressing facility into a DDN physical network address. The logical name need not be unique for the physical address, nor is the physical address necessarily unique for the name. A-3.3.2 Enabling and Disabling Logical Addresses To enable and disable logical addresses, the DDN X.25 host must send declarative CALL REQUEST packets to the DCE using a called address with the format: ZZZZ F DDDDDDD (SS) where the address fields are as described in Section 2.1.1. The Flag F must be set to nine, the DDN Host Identifier field specifies the logical address under consideration, and the subaddress field, which must be present, specifies the type of transaction. Declarative calls are cleared immediately by the local DCE. A-7 If SS is zero, the logical name is enabled in normal mode,; that is, that physical port will accept incoming calls to that name, and allow outgoing calls from that name. If SS is one, the logical name is disabled. If SS is two, the logical address is enabled in reverse translation mode; in this mode, the called address field of incoming call packets will be translated into a physical address (i.e., an address containing a flag F = 0), if it was given by the calling DTE (X.25 host), as a logical address (i.e., containing a flag F = 1). Whenever a DTE comes up, or restarts, the logical names for that DTE are returned to their default state, which may be either enabled or disabled, as configured by the DDN Administration. A-4 Limitations of DDN Basic X.25 Service The Defense Data Network is an Internetwork environment. That is, DDN as a whole is made up of a number of constituent packet switching networks that are interconnected via gateways. Communication across gateways requires the use of the Internet Protocol, which, for a host accessing DDN using X.25, requires that the host implement the DoD standard protocol architecture and employ DDN standard X.25 service. In addition, a classified host is attached to a DDN constituent network of lower classification by means of an Internet Private Line Interface (IPLI). IPLIs, which themselves contain gateways, also require the use of the Internet Protocol; moreover, they do not, as currently designed, offer an X.25 host interface. These attributes of the DDN Internet have two implications for users of DDN basic X.25 service: 1. DDN hosts that do not implement IP and higher- level DDN protocols, and which use only DDN basic X.25 service, cannot communicate across gateways. Their network communication is therefore restricted to a single DDN constituent network. 2. X.25 hosts cannot be provided classified service on a constituent network of lower classification. Should X.25 host access be developed for the IPLI in the future, classified network access will be made available to hosts using DDN standard X.25 service only. A-8