Title: ADS - Incorrect User Abort handling (PDR 98050009 follow-up) PDR Reference: M0090003 Originator Reference: TES Q-ADS-17 SARPs Document Reference: 2.2.1.5.3.14 Status: ADOPTED Impact: B PDR Revision Date: 30/01/03 (RESOLVED -> ADOPTED) 05/03/01 (PROPOSED -> RESOLVED) 15/11/00 (ACCEPTED -> PROPOSED) 14/09/2000 (SUBMITTED -> ACCEPTED) PDR Submission Date: 13/09/2000 Submitting State/Organization: Eurocontrol Submitting Author Name: Tony Kerr Submitting Author E-mail Address: tony.kerr@ecsoft.co.uk Submitting Author Supplemental: Contact Information: tel. +44 1344 867199 fax. +44 1344 868442 SARPs Date: Doc 9705 Edition 2 Draft Doc 9705 Edition 3 SARPs Language: English Summary of Defect: Interoperability testing between Eurocontrol's TES and an ADS implementation in Japan has shown that ADS-user-abort and ADS-provider-abort appear to be incorrect in the Ground and Air ADS AB modules. Consider the following scenario, which describes what is expected to happen when the ground system issues ADS-user-abort request for an active dialogue. The ADS-ground user issues ADS-user-abort req. There are no parameters. This is passed from Ground ADS HI module to the Ground ADS AB module. The LI module is requested to invoke D-ABORT with parameters: Originator = "user" User data not provided (absent) Ground ADS LI module invokes the D-ABORT req and enters the LI-G-IDLE state. In ULCS, A-ABORT req is invoked with parameters: Diagnostic = "No reason given" User Information not provided (absent) In ACSE, an ABRT APDU is formed, with the following fields: Abort-source = "acse-service-user" Abort-diagnostic = "no reason given" User-information - should not be present P-U-ABORT req is issued, with ABRT as user-data. The Ground CF intercepts the P-U-ABORT req, encodes the user data as an acse-apdu, and maps it to P-DATA req with the resulting encoding as user data. It enters the NULL state. At the receiving (Air) side, P-DATA ind containing ABRT is received. The Air CF invokes P-U-ABORT ind at the ACSE lower service boundary, with the ABRT as user data. (It also issues P-U-ABORT req to disconnect the transport connection.) In ACSE, the ABRT is received. An A-ABORT ind is issued with the following parameters: Abort Source taken from the ABRT = "acse-service-user" Diagnostic taken from the ABRT = "no reason given" User Information taken from the ABRT - should not be present. The association is released. The Air CF receives the A-ABORT ind. D-ABORT ind is issued to ADS-Air-ASE with parameters: Originator = "user" User Data taken from the A-ABORT ind - should not be present. The CF enters the NULL state. The ADS-Air-ASE LI module receives the D-ABORT ind. The air LI module passes the D-ABORT ind to the air AB module and enters the LI-A-IDLE state. The Air AB module receives the D-ABORT ind. There seems to be a SARPs error here. The D-ABORT ind should have Originator = "user". But 2.2.1.5.3.14.4 specifies "and with data in the User Data parameter." There will *never* be user data in the User Data parameter, as none was provided in the D-ABORT request, in 2.2.1.5.3.14.1. If there is no user data, then error handling would be invoked. There is a second problem here. None of the error cases in 2.2.1.5.4 applies, so 2.2.1.5.4.4 is invoked. The AB module is requested to abort, but the abort request comes from the AB module itself. 2.2.1.5.3.14.2 does not apply and an infinite loop is entered. Assigned SME: Sub-Volume II SME Proposed SARPs amendment: 1/ In 2.2.1.5.3.14.4, delete "and with data in the User Data parameter," 2/ In 2.2.1.5.3.14.5, insert after "provider", "and with data in the User Data parameter," 3/ Add a new sub-clause in 2.2.1.5.3.14 describing what shall happen if an internal error is detected in the AB module. Impact on interoperability: ADS-User-Abort requests result in unpredictable behaviour in the ADS peer. Validation Status: SME Recommendation to CCB: RESOLVED PDR 98050009 already identified the issue. Only an ADS-provider-PDU can be passed as UserData parameter of a D-ABORT indication with the originator set to "provider". Other combinations are not allowed (user data with originator = "user", or no user data with originator = "provider") and must be checked by the ADS ASE. The SARPs version at the time of the PDR specified only the "filter check", i.e. check that if data were present they must be an ADS-provider-PDU. The check of consistency between the originator parameter and the user data parameter was not done. The PDR originator proposed to implement the parameter consistency check in the LI module (Exception Handling). The SME team preferred to implement the parameter consistency check not in LI but in the ADS-ASE module because this was the way it was done for all other D-primitives. Unfortunately, the change was wrong since section 2.2.1.5.3.14.4 reads: "Upon receipt of a D-ABORT indication with the originator parameter value set to the abstract value "user" and with data in the User Data parameter, the AB module shall..." instead of: "Upon receipt of a D-ABORT indication with the originator parameter value set to the abstract value "user" and with NO data in the User Data parameter, the AB module shall..." and section 2.2.1.5.3.14.5 was not changed the way you propose. It should read: "Upon receipt of a D-ABORT indication with the originator parameter value set to the abstract value "provider" *and with data in the User Data parameter*, the AB module shall..." The SME2 Team propose to change SV2 as follows: 1/ change section 2.2.1.5.3.14.4 to read as above (i.e. replace "with data" by "with no data"), 2/ In 2.2.1.5.3.14.5, insert after "provider", "and with data in the User Data parameter," 3/ in section 2.2.1.5.3.14.2, delete "from the LI, DC, EC, PC or EM modules" to make the exception handling section applicable to the AB module itself. => the PDR originator reviewed and agreed with the proposed change. CCB Decision: atnp_ccb_chair: ACCEPTED (14/09/00) atnp_ccb_chair: PROPOSED (15/11/00) CCB-13 (Honolulu): RESOLVED (05/03/00)