Network Working Group K. Morneault INTERNET-DRAFT Cisco Systems June 1, 2001 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 2.1 Stream negotiation.......................................... 2 2.2 Chunk issues................................................ 3 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 Reasons Problem/Issue: Interest in providing a Reason to indicate a fault on an ASP. In addition, if SG does not recognize ASP Down Reason should it send ASP Down Acknowledge anyway. Description: Currently, the only Reasons provided is Management Inhibit. But, an ASP can be down due to a run-time fault in which case a fault isolation mechanism will take the ASP out-of- service, or Down. In the case of a SG receiving an ASP Down with unrecognized Reason, the SG should respond with an ASP Down Acknowledgement. Advice/Solution: Add a Reason value for "ASP Fault". Add text to clarify unrecognized ASP Down Reason. 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: A SCTP Restart should be treated like a SCTP Communication Lost indication. 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: Text implies that ASP Up/Down/Active/Inactive messages may be re-transmitted if an Acknowledgement is not received, but does not describe timer. Description: Advice/Solution: Add text that discusses use of T(ack) timer (cut from text added to M3UA). 2.8 Document Formating Changes Problem/Issue: General formating changes to improve readability. Description: Advice/Solution: Add the list of parameter tag values to Section 3.1.5. 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 and Greg Sidebottom. 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.