draft-morneault-sigtran-iua-issues-00

Network Working Group                                 K. Morneault
INTERNET-DRAFT                                       Cisco Systems
                                                      June 1, 2001

                  IUA (RFC 3057) Outstanding Issues
            <draft-morneault-sigtran-iua-issues-00.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
   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: [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.