draft-morneault-sigtran-iua-issues-01

Network Working Group                                      K. Morneault
INTERNET-DRAFT                                            Cisco Systems

Expires in six months                                          Feb 2002

                  IUA (RFC 3057) Outstanding Issues
            <draft-morneault-sigtran-iua-issues-01.txt>

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: [email protected]

6.0 References

   [RFC3057] - Morneault K., Rengasami S., Kalla M., Sidebottom G. -
   "ISDN Q.921-User Adaptation (IUA) Protocol", RFC 3057, February 
   2001.