Network Working Group K. Morneault INTERNET-DRAFT Cisco Systems Expires in six months Feb 2002 IUA (RFC 3057) Outstanding Issues Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document captures problems and issues discovered on the SIGTRAN mailing list and at future bakeoffs for IUA [RFC3057]. This document will be updated after each bakeoff augmenting the existing draft to include any new issues discovered during inter-operability testing. Two basic sets of problems are identified by this draft: first, issues that need to be addressed when the next revision of IUA is created, i.e. issues that should be remembered in a BIS document; second, issues that were found that are strictly implementation problems. Table of Contents 1.0 Introduction................................................ 2 2.0 Issues found with the specification......................... 2 3.0 Implementation issues found................................. 7 4.0 Acknowledgements............................................12 5.0 Authors Addresses...........................................13 6.0 References..................................................13 1.0 Introduction This document captures problems and issues discovered on the SIGTRAN email list and at IUA bakeoff's. This document will be updated after each bakeoff augmenting the existing RFC to include any new issues discovered during inter-operability testing. Two basic sets of problems will be identified in this draft: first, issues that need to be addressed when the next revision of IUA [RFC3057] is defined, i.e. issues that should be documented in a BIS document; and second, issues that were found that are strictly implementation problems and would not be documented in the protocol specification. It is hoped that by capturing these issues various implementations have found, that developers wishing to implement IUA will be able to not repeat the mistakes of others. It is also hoped that this document can be an input into the applicability document for signaling transport being worked upon within the SIGTRAN working group. This document is divided into two parts. Section 2 details issues found on the SIGTRAN email list and at the bakeoff(s) that are clearly specification issues that need to be addressed. Section 3 details problems that various implementators have encountered in their implementations. Both sections will use the following format: Problem/Issue: A summary description of the problem/issue. Description: A detailed description of the problem. Advice/Solution: A synopsis of the solution that needs to be applied to the specification or implementation. Found at: The bakeoff that this issue arose at or when on the mailing list the issue was raised. 2.0 Issues found in the IUA Specification This section captures issues that need to be addressed when the next revision of IUA is defined. It is thought that this section will capture the problem and possibly suggest a basis for the beginning of the specification changes. All changes here are suggestions that will be subject to full working group review at the time a BIS work is begun. 2.1 Message Length in Common Header Problem/Issue: RFC was not clear if message length in common header should include padding bytes. Description: Even though parameter lengths do not include padding bytes, it would be useful if Common Header message length did include these bytes. The primary benefit would be to allow IUA to be used with a stream-oriented transport such as TCP. Advice/Solution: Message length MUST contain padding bytes. 2.2 ASP Down Reason Problem/Issue: Synchronize with other UAs by removing Reason parameter from ASP Down and ASP Down Ack messages. Description: The other UAs removed Reason parameter because a use could not be found for this parameter. Advice/Solution: Remove Reason parameter from ASP Down. ASP and SG implementations should accept the respective message without Reason parameter. 2.3 Info String Problem/Issue: Clarify processing of Info string in ASP Up and ASP Active messages. Description: Be clear that these strings are for diagnostic purposes only and do not need to be echoed back in the ASP Up or ASP Active Acknowledgement messages. Advice/Solution: Add clarify statement that Info string is for diagnostic purposes only and that Info string in Acknowledgement is independent. 2.4 Reception of ASP Up when ASP is Active Problem/Issue: Procedures are not clear as to how to handle receipt of an ASP Up when ASP is currently considered Active by SG. Description: Advice/Solution: SG sends ASP Up Acknowledgement and transitions state to Up from Active. 2.5 SCTP Restart Problem/Issue: How should IUA handle indication of SCTP retart. Description: Currently, the RFC does not discuss what IUA would do if it received a SCTP Restart indication. Advice/Solution: In the IUA layer on the SG side, a SCTP Restart should be treated like a SCTP Communication Lost indication in the ASP state machine. In the IUA layer on the ASP side, the current ASP state should be re-established (i.e. if the ASP was Active, an ASP Up and ASP Active message should be sent). 2.6 Remove Notify (AS Down) Problem/Issue: If AS transitions to Down, there are no ASPs to send Notify message. Description: Currently, there is a Status Identification for AS Down (value of 1) in the Notify message. This value would never be used because if AS is Down, there are not ASPs to send the Notify message to. Advice/Solution: Change "Application Server Down (AS_Down)" to "Reserved". 2.7 ASPSM and ASPTM Acknowledge Timer Problem/Issue: ASPSM and ASPTM acknowledge timer not clearly specified. Description: Text implies that ASP Up/Down/Active/Inactive messages may be re-transmitted if an Acknowledgement is not received, but does not describe timer. Advice/Solution: Add text that discusses use of T(ack) timer (cut from text added to M2UA/M3UA). 2.8 Document Formating Changes Problem/Issue: General formating changes to improve readability. Description: Take advantage of clarifications made to other UAs such as listing parameter tag values, etc. Advice/Solution: Add the list of parameter tag values to Section 3.1.5. Review other UAs for other formating changes that will make IUA more readable. 2.9 Add ASP Identifier Problem/Issue: Add ASP Identifier parameter to ASP Up and Notify messages. Add associated procedures for using ASP ID. Description: Add ASP Identifier parameter to ASP Up and Notify messages. Add associated procedures for using ASP ID. Advice/Solution: Cut-n-paste text changes from the other UAs regarding ASP Identifier. 2.10 Add TEI Query Message Problem/Issue: There is no means for Q.931 or IUA on ASP side to query for the TEI. Description: There are scenarios (Q.931 restart or ASP Override) in which Q.931 (or IUA on the ASP side) may lose the TEI assignment. Advice/Solution: Add a TEI Query message. The TEI query message would only contain common header and IUA header. The DLCI in the IUA header would be ignored by the IUA on the SG. The SG would respond to this message with a TEI Status Indication. 2.11 Traffic Mode Text clarifications Problem/Issue: Potentially confusing statement in Section 3.3.2.5 about traffic mode. Description: IUA section 3.3.2.5 says "Within a particular Interface Identifier, only one Traffic Mode Type can be used". Implying that within an AS, two Interface Identifiers may have different Traffic Mode Types. Advice/Solution: Change this statement to match M2UA, "Within a particular AS, only one traffic mode Type can be used." 2.12 Operational Recommendations (Section 1.3.3) Problem/Issue: Operational recommendations should be in an Appendix Description: There are operational recommendations in Section 1.3.3 that need to be moved to an Appendix. Advice/Solution: Move these recommendations to Appendix A. 2.13 References split into Normative and Informative Problem/Issue: References need to be split into Normative and Informative. Description: References need to be split into Normative and Informative. Advice/Solution: Follow lead of other UAs in terms of determining which references are normative and which are informative. Separate References section into two subsections (Normative and Informative). 2.14 Specify Character Set for INFO parameter Problem/Issue: Currently, a character set is not specified for INFO parameter. Description: A character set must be defined in order to ensure interoperability. Advice/Solution: Follow lead of other UAs by using UTF-8 character set with a maximum of 255 octets. 2.15 Specify Character Set for text-based Interface Identifier Problem/Issue: Currently, a character set is not specified for Interface Identifier parameter. Description: A character set must be defined in order to ensure interoperability. Advice/Solution: Follow lead of other M2UA by specifying ANSI X3.4-1986 (7-bit ASCII). 2.16 ASPSM and ASPTM procedures specified in Section 4 Problem/Issue: ASPSM and ASPTM procedures specified in Section 4 are slightly out-of-sync with other UAs. Description: Changes were made to the ASPSM and ASPTM procedures in the other UAs after IUA became a RFC. IUA should be updated with these changes. Advice/Solution: Make appropriate changes to IUA Section 4 to re-synchronize it with the other UAs. 3.0 Implementation issues found This section presents various implementation issues discovered at various bakeoffs. These issues do NOT require or indicate changes needed to IUA [RFC3057]. Instead these issues provide guidance to future implementors and provide input to the signaling transport applicability document where appropriate. 3.1 4.0 Acknowledgements The author would like to thank the following people that have provided comments and input for this document: Alex Audu, Greg Sidebottom, Srinivasa A. Shikaripura and Subhodeep Sarkar. 5.0 Authors Addresses Ken A. Morneault 13615 Dulles Technology Drive Herndon, VA 20171 USA EMail: kmorneau@cisco.com 6.0 References [RFC3057] - Morneault K., Rengasami S., Kalla M., Sidebottom G. - "ISDN Q.921-User Adaptation (IUA) Protocol", RFC 3057, February 2001.