********************************************************************** DDN MGT Bulletin 41 DCA DDN Defense Communications System 7 Oct 88 Published by: DDN Network Info Center (NIC@SRI-NIC.ARPA) (800) 235-3155 DEFENSE DATA NETWORK MANAGEMENT BULLETIN The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network Information Center under DCA contract as a means of communicating official policy, procedures and other information of concern to management personnel at DDN facilities. Back issues may be read through the TACNEWS server ("@n" command at the TAC) or may be obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or 10.0.0.51] using login="anonymous" and password="guest". The pathname for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the bulletin number). ********************************************************************** DEFENSE DATA NETWORK PACKET SWITCH SOFTWARE DEPLOYMENT MANAGERIAL INFORMATION DCA Msg 281940Z Sep 88 Subject: Defense Data Network Packet Switch Software Deployment Managerial Information Reference: DCA Msg 281941Z Sep 88, Defense Data Network Packet Switch Software Deployment, Technical Information 1. Defense Data Network Packet Switch Software Deployment By this message the Defense Communications Systems Data Systems (DCSDS) a. Establishes the plan for deploying the Defense Data Network's Packet Switching Node Release 7.0 New End-to-End (DDN PSN 7.0 NEE) system to the MILNET (see the deployment schedule in section 2.), b. Solicits the cooperation and participation of the MILNET subscriber community during the deployment testing which begins 29 October 1988 (see subscriber testing responsibilities in section 3.), c. Requests MILNET subscribers to identify their host's X.25 facilities negotiation capabilities by 1 January 1989 (section 4.), and d. Provides a brief status of recent activities leading to this stage of deployment (section 4.). By the referenced message DCSDS provides a PSN 7.0 technical status based upon the recent off-line testing with MILNET hosts. The Defense Data Network (DDN) will soon contain a new version of Packet Switching Node (PSN) software designated PSN 7.0 NEE, which more strictly complies with the CCITT Recommendation X.25. The strict adherence to standards requires a deliberate deployment approach coordinated with subscribers to ensure continuity of MILNET operations. Subscribers who do not participate in the activities preparatory to the final PSN 7.0 NEE deployment risk loss of MILNET service due to incompatibility. Consequently, request all addressees to acknowledge receipt of this message to DCA WASHINGTON DC //B610//. (Note: Based upon the ARPANET Beta testing, AHIP user impact is not acticipated; however, prudent MILNET testing indicates that AHIP subscribers should also participate.) 2. PSN 7.0 NEE Deployment Approach and Schedule The PSN 7.0 NEE deployment is the second phase of the PSN 7.0 deployment on MILNET. (Phase 1 was the MILNET deployment of PSN 7.0 Old End-to-End (OEE), a PSN 6.0-compatible system, achieved by 30 August 1988.) The Phase 2 deployment will consist of five interim short duration cutover tests and a final permanent cutover. The interim cutovers will provide ample opportunity for both subscribers and network analysts to participate in a MILNET operational test of PSN 7.0 NEE prior to its permanent operational use. The first three interim cutovers will occur on weekends. The next two cutovers will occur on a weekday to maximize the PSN 7.0 NEE system's exposure in the MILNET. The final cutover will take place at the begining of the week. The cutover schedule follows: Day Time Cutover Zulu/Eastern Zulu Eastern Duration C1 29/29 Oct 88 1600Z 1200 EDT 12 hours C2 12/12 Nov 88 1100Z 0600 EST 12 hours C3 19/19 Nov 88 1100Z 0600 EST 24 hours C4 30/30 Nov 88 0501Z 0001 EST 24 hours C5 14/14 Dec 88 0501Z 0001 EST 24 hours C6 09/09 Jan 89 0501Z 0001 EST Permanent The dates are subject to modification as testing proceeds depending on test results. The dates also are negotiable for military exigencies. Additional tests may be scheduled on an individual host or MILNET-wide basis. DCSDS will notify the subscriber community of any schedule modifications. 3. Procedures and Operational Support for Phase 2 Deployment The first hour of each period in section 2. above will be dedicated to the cutover of PSN 7.0 from OEE to NEE, a MILNET-wide cutover. The Cambridge Monitoring Center (CMC) will cutover groups of PSNs at a time to NEE. DCSDS directs subscribers not to attempt communications during this period for two reasons: the cutover segments the network and taxes network resources. Thus, communications will be slow or nonexistent during the hour. The second hour of the test period will mark the beginning of the operational test. DCSDS asks subscribers to participate in the test by exercising their normal applications and reporting anomalies to the Monitoring Center Trouble Desk in their respective areas (the PMMC, CMMC or EMMC) using established reporting procedures. Should the Trouble Desk's telephone be busy, please call again. If you can still not reach the Trouble Desk, please report your problem via electronic mail to MILUPGRADE@BBN.COM, using the format outlined in the next paragraph. Additional staff will support the Trouble Desks during the testing periods. Also, network analysts located at the CMC will provide expert assistance. In order to efficiently utilize the Trouble Desks, DCSDS asks those people reporting problems to give the following information to the operator: a. Reporter's Name b. Reporter's Telephone Number (both Autovon and Commercial) c. Reporter's Address d. URDB Subscriber/System Name e. IP Address f. Equipment Manufacturer and Model Designator (Specify Host, Front End, PADs, etc. as appropriate) g. Software Manufacturer and Product Designator (Specify Operating System, Network Protocol (X.25B, X.25S, HDH, 1822), Upper Level Protocols, Application Packages, etc. as appropriate and available) h. Statement of Problem Attempted Activity or Function Expected Result Actual Result Impact on User i. Availability for follow-up test during test period, hours of availability in Zulu time j. Follow-up test POC if different from reporter DCSDS asks subscribers to assist MC personnel as necessary in duplicating problems to enable an accurate analyses. See Section 4.1 for additional testing procedures. The last hour of the test period will be dedicated to cutting back to PSN 7.0 OEE. The same caveats apply to this hour as to the first hour: do not attempt communications, service will be slow or nonexistent. The determination to perform the final cutover will be contingent upon the alleviation of communications disruptions encountered during the tests. 4. PSN 7.0 Status 4.1 Testing Incidents The problems already encountered during the off-line testing with MILNET hosts fall under the categories of administration and X.25 conformance. Incidents encountered during cutover testing may fill a third category of non-X.25 errors. 4.1.1 Administrative Problems and Information Request The off-line testing with MILNET hosts encountered a problem related to flow control negotiation causing hosts to clear calls. The superseded configuration of flow control negotiation parameters for certain PSN host ports caused the problem and the particular X.25 implementation of PSN 6.0 and PSN 7.0 OEE masked the problem. A temporary patch will correct the problem in PSN 7.0 NEE. The MC will remove the patch during the initial operational phase of PSN 7.0 NEE upon identification and execution of the configuration modifications. In order to correct the configurations, DCSDS asks all subscribers to forward by 1 January 1989 responses to the following questions via front channel message to DCA WASH DC //B612//: Can your host currently negotiate a. window size, b. packet size, c. precedence, and d. throughput class? What are the minimum and maximum logical channel numbers your host supports? 4.1.2 X.25 Conformance Problems The off-line testing also uncovered a problem related to self-addressed calls which caused hosts to clear calls. In one test case the problem surfaced during a file transfer test; the implication being that the user need not explicitly request self-addressing to experience the problem. DCSDS thus asks all subscribers to exercise as much of their normal applications or general routines as possible to identify the chance of service denial after operational cutover to PSN 7.0 NEE. 4.1.3 Non-X.25 Incidents The off-line testing encountered a problem related to packet sequencing. The host layer above X.25 (IP) improperly fragmented a message. The problem workaround (modifying the packet size) indicates that different host configurations of X.25 interface characteristics can result in terminated service. Thus, DCSDS not only asks subscribers to exercise their normal applications, but also to exercise those applications under their variously configurable environments. An outstanding problem from the ARPANET Beta tests relates to the HDH interface. On a random basis the interface between the BBN packet switch and an ACC Gateway resets itself. DCSDS has now staffed the problem analysis effort. 5.0 Points of Contact The point of contact for any administrative issues regarding this message (such as test schedules or configuration requirements) is Mr. George Bradshaw, DCA Code B612, AV 364-5306, Commercial (703)285-5306, Bradshaw @ DDN1.ARPA. The points of contact for any test procedure questions are Mr. Mark Whitney (BBN, Commercial (617)873-2874, MWhitney @ BBN.COM) and Mr. Edward Smith (BBN, Commercial (703)848-4838, ESmith @ BBN.COM). Address questions related to communications protocols (X.25, IP, etc.) to Mr. Andrew Malis (BBN, AMalis@BBN.COM) with a courtesy copy to Bradshaw@DDN1.ARPA. Address any issues of general community interest to MILUPGRADE@BBN.COM. TECHNICAL INFORMATION DCA Msg 281941Z Sep 88 Subject: Defense Data Network Packet Switch Software Deployment Technical Information Reference: DCA Msg 281940Z Sep 88, Defense Data Network Packet Switch Software Deployment, Mangerial Information 1. Defense Data Network Packet Switch Software Deployment This message discusses, in technical terms, the current status of Defense Data Network Packet Switching Node Release 7.0 New End-to-End (DDN PSN 7.0 NEE) in parallel with section 4 of reference, which provides a managerial status overview. This message also provides technical details concerning the recent PSN 7.0 NEE off-line testing with MILNET hosts. 2. PSN 7.0 Definition PSN 7.0 is the newest release of software for the DDN's packet switching nodes. PSN 7.0 embodies 1) a PSN 6.0-compatible system designated Old End-to-End (OEE) to facilitate release deployment and 2) the full capability system designated New End-to-End (NEE). NEE consumes up to 50% fewer network resources with X.25 transmissions and consequently has the potential to improve throughput by a similar percentage depending upon topological and utilization considerations. These improvements come primarily through a redesign of subnetwork transport services and new functionality for network services. The transport service improvements provide: 1) efficient X.25 acknowledgment handling throughout the network, and 2) flow control for congestion within a single packet switching node. The network service functions support 1) four levels of precedence and 2) pre-emption to guarantee throughput of critical traffic during periods of high network utilization. 3. PSN 7.0 NEE Testing PSN 7.0 will have undergone five distinct periods of testing prior to operational use on the MILNET: early 1987 Development Testing late 1987 Beta Testing on ARPANET mid 1988 Off-line Testing with MILNET hosts mid 1988 Phase 1 (OEE) Deployment on MILNET early 1988 Phase 2 (NEE) Deployment on MILNET Following its beta testing, PSN 7.0 received extensive operational exposure on the ARPANET and has become a stable system. The recent off-line testing with MILNET hosts has exposed X.25 problems involving self-addressed calls and flow control negotiation; both issues are discussed later (PSN 7.0 NEE tested against systems listed below). DCSDS has completed the deployment of PSN 7.0 Old End-to-End (OEE) Phase 1. The PSN 7.0 NEE Phase 2 deployment will consist of controlled interim and final cutovers to the full capability PSN 7.0 system. PSN 7.0 NEE Tested with Following Systems AFLC APDS CCSO/XPNB DLA DSACS ESD/SCO IDSS IMMIS JACS/J/J NARDAC NAVTIS NCPDS PASS-SDS PERDIMMS SAF/ACES 3.1 Host Testing Technical Description Two major problem issues currently exist: 1) the superseded configuration of flow control negotiation parameters for certain PSN host ports, and 2) the inability of one communications protocol implementation to handle self-addressed calls. 3.1.1 Flow Control Negotiation CCITT Recommendation X.25 specifies flow control methods which allow the DCE to be either an active (initiator) or passive negotiating element, depending upon the network implementation. In practice, the PSN configuration parameters "Window and Packet Size Negotiation Subscription" support this network dependence. PSN 6.0 and PSN 7.0 OEE ignore the setting of these parameters and do not actively participate in negotiations. PSN 7.0 NEE participates in negotiation when the parameters are set to "yes", which is also the default setting for MILNET. Therefore all MILNET hosts, whether or not they can participate in flow control negotiation will, under PSN 7.0 NEE, receive negotiation offerings for window and packet size from the PSN. If the parameters were set to "no", PSN 7.0 NEE would not send negotiation offerings to the host. The problem is that hosts which cannot negotiate will clear a connection if the PSN attempts negotiation. The resolution to this problem is to configure the PSN host ports properly. DCSDS has established a deployment approach to 1) provide, in the short term, a patch to NEE, temporarily reverting the release to PSN 6.0 compatibility, and 2) define and execute configuration corrections in the long term. 3.1.2 Self-Addressed Calls CCITT Recommendation X.25 states, in essence for the purposes of this discussion, that an outgoing and incoming call will exist on different virtual channels with that difference identified by a unique number called the logical channel number (LCN). PSN 6.0 and PSN 7.0 OEE did not conform to the X.25 standard and assigned the same number to an outgoing and incoming call which was self-addressed. PSN 7.0 NEE conforms to the standard. The result is that at least one higher level protocol implementation which apparently was sensitive to this difference has not functioned properly during the off-line tests under PSN 7.0 NEE. In this case, an FTP implementation could not transfer files. The configuration for this test was an IBM 4300 with a Series 1 front end. UCLA ARPANET Control Protocol V1.6 resided in the 4300, EDX V5 resided in the Series 1. Several alternatives exist for resolving this problem. a. Replace or correct the protocol implementations which do not abide by the X.25 standard. b. Modify the PSN 7.0 NEE software to act like PSN 6.0, bringing it out of X.25 conformance. c. Modify the topological aspect of the file transfer by "teleneting" one's self to the file's destination and "pulling" the file to the destination rather than "pushing" the file to the destination. The following caveats apply to the alternatives. Alternative a. places the onus on host administrators, alternative b. is not in accord with government policy to follow standards, and alternative c. may cause logistics problems with userid and password assignment. The PSN 7.0 NEE cutover testing results will determine the expedient alternative based upon the types and extent of subscriber impact throughout the network. 3.1.3 Flow Control Implementations The PSN 7.0 NEE off-line testing with MILNET hosts uncovered an anomaly in one implementation of the DOD Internet Protocol. The IP incorrectly fragmented a TCP message causing the TCP connection to clear. The fragmentation resulted in two "final" (X.25 Category B) packets for the same sequence of packets. In the original test the packet size was 256 octets. The host transmitted a sequence of packets, the first group of which were correctly category A packets each 256 octets in length. The second to last packet of the sequence was a category B packet by virtue of its 128 octet length (not a "full" packet). The last packet of the sequence was also a category B packet by virtue of its size (seven octets). One experiment configured a packet size of 128 bytes and yielded a successful workaround which resulted in a single category B packet of seven octets. The system was a Sperry 5000 with Adax X25/IP/TCP. 4.0 Points of Contact The point of contact for any administrative questions is Mr. George Bradshaw, DCA Code B612, AV 364-5306, Commercial (703)285-5306. The point of contact for any test procedure questions is Mr. Mark Whitney (BBN, Commercial (617)873-2874, MWhitney@BBN.COM). Address questions related to X.25 technical issues to Mr. Andrew Malis (BBN, AMalis@BBN.COM) with a courtesy copy to Bradshaw@DDN1.ARPA. Address any issues of general community interest to MILUPGRADE@BBN.COM.