Title: FIS - LI Problems Handling Exception Handling, Abort Situations PDR Reference: 98120013 Originator Reference: acifis08 SARPs Document Reference: FIS SARPs Sections 2.4.5.3.12.5.1, 2.3.5.3.12.5.2 and Tables 2.4.5-10/a and 2.4.5-10/b Status: RESOLVED Impact: C (Clarification) PDR Revision Date: 21/01/99 (PROPOSED -> RESOLVED) 19/01/99 (ACCEPTED -> PROPOSED) 16/12/98 (SUBMITTED -> ACCEPTED) PDR Submission Date: 03/12/98 Submitting State/Organization: AIRSYS ATM (ACI) Submitting Author Name: Ilkiewicz, M / Stokes, S Submitting Author E-mail Address: michel.ilkiewicz@cdv.vly.sextant. thomson-csf.com, Shawn.Stokes@ATNSI.com Submitting Author Supplemental Contact Information: SARPs Date: IV2.2, IV2.3 (Doc 9705 Ed1) SARPs Language: English Summary of Defect: There are two related LI Exception Handling, Abort problems: Problem 1: The FIS SARPs, Section 2.4.5.3.12.5.2 indicates that if LI which is in the LI-IDLE state, "... the LI module shall ignore the request". However, if the dialogue service provider is waiting for a response to a Start Indication (that was determined to be invalid by LI and thus the LI requested that the AB module Abort), the LI should invoke the D-ABORT request primitive rather than ignore. Sections 2.4.5.4.2.1, 2.4.5.4.4.1, and 2.4.5.4.6.1 are exception handling requirements which include covering cases where a D-START indication is received by the LI process and determined to be invalid. These exception handling requirements indicate that the LI should request the AB process to Abort and then remain in its current state. In order for the D-START indication to be received, the LI must be in LI-IDLE state and thus the "current state" would be the LI-IDLE state. At this point, the dialogue service provider has issued a D-START indication and has not received a response to that D-START indication. The LI process (still in the LI-IDLE state) will receive a request to issue a D-ABORT request from the AB process, but because it is in the idle state, the LI will ignore this request to issue a D-ABORT request and the dialogue service provider is still waiting for a response to the D-START indication. The solution would be to allow the LI module - when requested by the AB module to abort the dialogue - to abort the dialogue when one exists and to ignore the request when none exists. The second problem when resolved will be examples of this case. Note: Table 2.4.5-10/a. would need to be updated to reflect these changes as well. Problem 2: Sections 2.4.5.3.12.8.1 and 2.4.5.3.12.9.1 cover LI Exception Handling, Abort situations where an invalid D-START confirmation with result of rejected is received. These requirements indicate that the LI should request the HI to invoke a FIS-provider-abort indication. The problem with this is that the UC or DC process that is awaiting a response to the original request will not be informed of the Start CNF rejected or the FIS-provider-abort indication. The solution would be to request the AB process to abort with the appropriate Abort Reason and enter the LI-IDLE state. AB process will then ask the UC and DC process to stop operations and the LI to issue a D-ABORT request. But because of requirement 2.4.5.3.12.5.2, LI will ignore the request to ABORT. Note: Table 2.4.5-10/b is correct and does not need to be updated to reflect these changes. Assigned SME: Sub-Volume II SME Proposed SARPs amendment: Problem 1: 1/ Delete section 2.4.5.3.12.5.2. 2/ Change in section 2.4.5.3.12.5.1 from: 2.4.5.3.12.5.1 If not in the LI-IDLE state, the LI module shall: a) invoke the D-ABORT request primitive to: 2.4.5.3.12.5.1 The LI module shall: a) if a dialogue exists, invoke the D-ABORT request primitive 3/ In Table 2.4.5-10/a, set the contents of cells (AB_D_ABORT req, LI-IDLE), (AB_D_ABORT req, LI-START-I), (AB_D_ABORT req, LI-DIALOGUE), (AB_D_ABORT req, LI-START-R) and (AB_D_ABORT req, LI-END-I) to: if dialogue exists D-ABORT res -> LI-IDLE Problem 2: 4/ Section 2.4.5.3.12.8.1 a) should be modified from: a) request the FIS HI module to invoke a FIS-provider-abort indication with the abstract value "cannot establish contact with the peer" as parameter, and To: a) request the AB module to abort with the reason "cannot establish contact with the peer", and 5/ Section 2.4.5.3.12.9.1 a) should be modified from: a) request the FIS HI module to invoke a FIS-provider-abort indication with the abstract value "contact refused by the peer" as , and To: a) request the AB module to abort with the reason "contact refused by the peer", and SME Recommendation to CCB: CCB Decision: atnp_ccb_chair (SUBMITTED) CCB-8a (Honolulu) : RESOLVED (21/01/99)