| draft-ietf-sigtran-iua-imp-guide-00Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-iua-imp-guide-00.txt. Network Working Group K. Morneault INTERNET-DRAFT Cisco Systems Expires in six months Apr 2002 IUA (RFC 3057) Outstanding Issues <draft-ietf-sigtran-iua-imp-guide-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 Conventions................................................. 2 3.0 Corrections to IUA [RFC3057]................................ 3 4.0 Acknowledgements............................................12 5.0 Authors Addresses...........................................13 6.0 References..................................................13 1. Introduction This document contains a compilation of all defects found up until May 2002 for the ISDN User Adaptation Layer (IUA) [RFC3057]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of IUA to clarify errors in the original IUA document. This document updates RFC3057 and text within this document, where noted, supersedes the text found in RFC3057. Each error will be detailed within this document in the form of: - The problem description, - The text quoted from RFC3057, - The replacement text, - A description of the solution. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. Corrections to IUA [RFC3057] 3.1 Message Length in Common Header 3.1.1 Description of the problem The RFC was not clear if message length in common header should include padding bytes. 3.1.2 Text changes to the document --------- Old text: (Section 3.1.4) --------- The Message length defines the length of the message in octets, including the Common header. --------- New text: (Section 3.2) --------- The Message Length defines the length of the message in octets, including the Common Header. For messages with a final parameter containing padding, the parameter padding MUST be included in the Message Length. Note: A receiver SHOULD accept the message whether or not the final parameter padding is included in the message length. 3.1.3 Solution description The message length must include padding bytes. 3.2 ASP Down Reason 3.2.1 Description of the problem There is a need to synchronize IUA with other UAs by removing Reason parameter from ASP Down and ASP Down Ack messages. The other UAs removed the Reason parameter because a use could not be found for this parameter. 3.2.2 Text changes to the document --------- Old text: (Section 3.3.2.3) --------- The ASPDN message contains the following parameters: Reason INFO String (Optional) The format for the ASPDN message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xa) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.3.1.). The Reason parameter indicates the reason that the remote IUA adaptation layer is unavailable. The valid values for Reason are shown in the following table. Value Description 0x1 Management Inhibit If a ASP is removed from Management Inhibit, the ASP will send an ASP Up message. --------- New text: (Section 3.3.2.3) --------- The ASPDN message contains the following parameters: INFO String (Optional) The format for the ASPDN message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.3.1.). --------- Old text: (Section 3.3.2.4) --------- The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote IUA peer. The ASP Down Ack message contains the following parameters: Reason INFO String (Optional) The format for the ASP Down Ack message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xa) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1.). The format of the Reason parameter is the same as for the ASP Down message (See Section 3.3.2.3). --------- New text: (Section 3.3.2.4) --------- The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote IUA peer. The ASP Down Ack message contains the following parameters: INFO String (Optional) The format for the ASP Down Ack message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1.). 3.2.3 Solution description The Reason parameter is removed from the ASP Down and ASP Down Acknowledge messages. ASP and SG implementations should accept the respective message without the Reason parameter. 3.3 ASP State Machine 3.3.1 Description of the problem Handling of ASP Up when in ASP-ACTIVE state and SCTP Restart indication are not specified. 3.3.2 Text changes to the document --------- Old text: (Section 4.3.1.1) --------- Figure 7 ASP State Transition Diagram +-------------+ +----------------------| | | Alternate +-------| ASP-ACTIVE | | ASP | +-------------+ | Takeover | ^ | | | ASP | | ASP | | Active | | Inactive | | | v | | +-------------+ | | | | | +------>| ASP-INACT | | +-------------+ | ^ | ASP Down/ | ASP | | ASP Down / SCTP CDI | Up | | SCTP CDI | | v | +-------------+ +--------------------->| | | ASP-DOWN | +-------------+ SCTP CDI: The local SCTP layer's Communication Down Indication to the Upper Layer Protocol (IUA) on an SG. The local SCTP will send this indication when it detects the loss of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE notification and COMMUNICATION LOST notification from the SCTP. --------- New text: (Section 4.3.1.1) --------- Figure 7 ASP State Transition Diagram +--------------+ +----------------------| | | Alternate +-------| ASP-ACTIVE | | ASP | +--------------+ | Takeover | ^ | | | ASP | | ASP Inactive / | | Active | | ASP Up | | | v | | +--------------+ | | | | | +------>| ASP-INACTIVE | | +--------------+ | ^ | ASP Down/ | ASP | | ASP Down / SCTP CDI/ | Up | | SCTP CDI / SCTP RI | | v SCTP RI | +--------------+ +--------------------->| | | ASP-DOWN | +--------------+ SCTP CDI: The local SCTP layer's Communication Down Indication to the Upper Layer Protocol (IUA) on an SG. The local SCTP will send this indication when it detects the loss of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE notification and COMMUNICATION LOST notification from the SCTP. SCTP RI: The local SCTP layer's Restart indication to the upper layer protocol (IUA) on an SG. The local SCTP will send this indication when it detects a restart from the ASP's peer SCTP layer. 3.3.3 Solution description A SCTP Restart Indication is treated the same as a Communication Down Indication with respect to the ASP state machine on the SG. If the SG receives an ASP Up from an ASP in the ASP-ACTIVE state, it should sends an ASP Up Acknowledgement and transition the ASP to the ASP-INACTIVE state. 3.4 AS State Machine 3.4.1 Description of the problem The AS state machine in the RFC has some editorial errors in the area of naming ASP states. 3.4.2 Text changes to the document --------- Old text: (Section 4.3.1.2) --------- Figure 8 AS State Transition Diagram +----------+ one ASP trans ACTIVE +-------------+ | |------------------------>| | | AS-INACT | | AS-ACTIVE | | | | | | |< | | +----------+ \ +-------------+ ^ | \ Tr Trigger ^ | | | \ at least one | | | | \ ASP in UP | | | | \ | | | | \ | | | | \ | | one ASP | | \ one ASP | | Last ACTIVE ASP trans | | all ASP \------\ trans to | | trans to INACT to | | trans to \ ACTIVE | | or DOWN INACT | | DOWN \ | | (start Tr timer) | | \ | | | | \ | | | | \ | | | v \ | v +----------+ \ +-------------+ | | -| | | AS-DOWN | | AS-PENDING | | | | (queueing) | | |<------------------------| | +----------+ Tr Expiry and no +-------------+ ASP in INACTIVE state Tr = Recovery Timer --------- New text: (Section 4.3.1.2) --------- Figure 8: AS State Transition Diagram +----------+ one ASP trans to ASP-ACTIVE +-------------+ | AS- |---------------------------->| AS- | | INACTIVE | | ACTIVE | | |<--- | | +----------+ \ +-------------+ ^ | \ Tr Expiry, ^ | | | \ at least one | | | | \ ASP in ASP-INACTIVE | | | | \ | | | | \ | | | | \ | | one ASP | | all ASP \ one ASP | | Last ACTIVE trans | | trans to \ trans to | | ASP trans to to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE ASP- | | \ ACTIVE | | or ASP-DOWN INACTIVE| | \ | | (start Tr) | | \ | | | | \ | | | v \ | v +----------+ \ +-------------+ | | --| | | AS-DOWN | | AS-PENDING | | | | (queueing) | | |<----------------------------| | +----------+ Tr Expiry and no ASP +-------------+ in ASP-INACTIVE state) Tr = Recovery Timer 3.4.3 Solution description The AS state machine is clarified by providing the correct ASP state names. 3.5 Remove Notify (AS Down) 3.5.1 Description of the problem If AS transitions to AS-DOWN, there are no ASPs to send Notify message. Therefore, there is no need for "Notify (AS Down)". 3.5.2 Text changes to the document --------- Old text: (Section 3.3.3.2) --------- The Status Identification parameter contains more detailed information for the notification, based on the value of the Status Type. If the Status Type is AS_State_Change the following Status Identification values are used: Value Description 1 Application Server Down (AS_Down) 2 Application Server Inactive (AS_Inactive) 3 Application Server Active (AS_Active) 4 Application Server Pending (AS_Pending) --------- New text: (Section 3.3.3.2) --------- The Status Identification parameter contains more detailed information for the notification, based on the value of the Status Type. If the Status Type is AS_State_Change the following Status Identification values are used: Value Description 1 Reserved 2 Application Server Inactive (AS-INACTIVE) 3 Application Server Active (AS-ACTIVE) 4 Application Server Pending (AS-PENDING) 3.5.3 Solution description Removed Notify (AS-DOWN). 3.6 List Tag Values 3.6.1 Description of the problem To improve readability, list the parameter values in one place. 3.6.2 Text changes to the document --------- Old text: (Section 3.1.5) --------- Parameter Tag: 16 bits (unsigned integer) The Tag field is a 16 bit identifier of the type of parameter. It takes a value of 0 to 65534. --------- New text: (Section 3.1.5) --------- Parameter Tag: 16 bits (unsigned integer) The Tag field is a 16-bit identifier of the type of parameter. It takes a value of 0 to 65534. Common parameters used by adaptation layers are in the range of 0x00 to 0x3f. The parameter Tags defined are as follows: Common Parameters. These TLV parameters are common across the different adaptation layers: Parameter Name Parameter ID ============== ============ Reserved 0x0000 Interface Identifier (integer) 0x0001 Not Used in IUA 0x0002 Interface Identifier (text) 0x0003 INFO String 0x0004 DLCI 0x0005 Not Used in IUA 0x0006 Diagnostic Information 0x0007 Interface Identifer Range 0x0008 Heartbeat Data 0x0009 Not Used in IUA 0x000a Traffic Mode Type 0x000b Error Code 0x000c Status 0x000d Protocol Data 0x000e Release Reason 0x000f TEI Status 0x0010 ASP Identifier 0x0011 Not Used in IUA 0x0012 - 0x003f The value of 65535 is reserved for IETF-defined extensions. Values other than those defined in specific parameter description are reserved for use by the IETF. 3.6.3 Solution description Add a list of parameter tags. 3.7 Add ASP Identifier 3.7.1 Description of the problem Add ASP Identifier parameter to ASP Up and Notify messages along with associated procedures for using ASP Identifier. This change further aligns IUA with the other UAs. 3.7.2 Text changes to the document --------- Old text: (Section 3.3.2.1) --------- The ASPUP message contains the following parameters: Info String (optional) The format for ASPUP Message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------- New text: (Section 3.3.2.1) --------- The ASPUP message contains the following parameters: ASP Identifier Optional Info String Optional The format for ASPUP Message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0011 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ASP Identifier: 32-bit unsigned integer The optional ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS. The SG should save the ASP Identifier to be used, if necessary, with the Notify message (see Section 3.8.2). --------- Old text: (Section 3.3.3.1) --------- None --------- New text: (Section 3.3.3.1) --------- 0x0e ASP Identifier Required 0x0f Invalid ASP Identifier The "ASP Identifier Required" is sent by a SG in response to an ASP Up message which does not contain an ASP Identifier parameter when the SG requires one. The ASP SHOULD resend the ASP Up message with an ASP Identifier. The "Invalid ASP Identifier" is send by a SG in response to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier. --------- Old text: (Section 3.3.3.2) --------- The Notify message will only use the common message header. The Notify message contains the following parameters: Status Type Status Identification Interface Identifiers (Optional) INFO String (Optional) The format for the Notify message with Integer-formatted Interface Identifiers is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xd) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Type | Status Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=integer) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifiers* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x8=integer range) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier StartN* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier StopN* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional Interface Identifiers | | of Tag Type 0x1 or 0x8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------- New text: (Section 3.3.3.2) --------- The Notify message will only use the common message header. The Notify message contains the following parameters: Status Type Status Identification ASP Identifier Optional Interface Identifiers Optional INFO String Optional The format for the Notify message with Integer-formatted Interface Identifiers is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xd) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Type | Status Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0011 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=integer) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifiers* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x8=integer range) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop1* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Start2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier Stop2* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier StartN* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier StopN* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional Interface Identifiers | | of Tag Type 0x1 or 0x8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.7.3 Solution description Added ASP Identifier to provide consistency with other UAs. 3.8 TEI Query 3.8.1 Description of the problem There is a need for Q.931 or IUA on the ASP side to query for the TEI(s). This need is based on scenarios (Q.931 restart or ASP Override) in which Q.931 or IUA on the ASP side may lose the TEI assignment. 3.8.2 Text changes to the document --------- Old text: (Section 3.1.2) --------- Management (MGMT) Messages 0 Error (ERR) 1 Notify (NTFY) 2 TEI Status Request 3 TEI Status Confirm 4 TEI Status Indication 5 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined MGMT extensions --------- New text: (Section 3.1.2) --------- Management (MGMT) Messages 0 Error (ERR) 1 Notify (NTFY) 2 TEI Status Request 3 TEI Status Confirm 4 TEI Status Indication 5 TEI Query Request 6 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined MGMT extensions --------- New text: (Section 3.3.3.4) --------- 3.3.3.4 TEI Query Message (Request) The TEI Query message is sent by the ASP to query the TEI(s). This message consists of the common header and IUA header. The DLCI in the IUA header MUST be ignored by the SG. The SG will respond to this message with a TEI Status Indication(s). 3.8.3 Solution description A TEI Query message is added to fulfill the need of the ASP side to be able to query the TEI value. 3.9 Traffic Mode Text 3.9.1 Description of the problem There is a potentially confusing statement in Section 3.3.2.5 about traffic mode. 3.9.2 Text changes to the document --------- Old text: (Section 3.3.2.5) --------- Within a particular Interface Identifier, only one Traffic Mode Type can be used. --------- New text: (Section 3.3.2.5) --------- Within a particular AS, only one Traffic Mode Type can be used. 3.9.3 Solution description Provided clarification that Traffic Mode is on a AS basis not an Interface Identifier basis. 3.10 Operational Recommendations 3.10.1 Description of the problem Operational recommendations should be in an Appendix instead of the main body of the RFC. 3.10.2 Text changes to the document --------- Old text: (Section 1.3.3) --------- 1.3.3 Signaling Network Architecture A Signaling Gateway is used to support the transport of Q.921-User signaling traffic to one or more distributed ASPs (e.g., MGCs). Clearly, the IUA protocol is not designed to meet the performance and reliability requirements for such transport by itself. However, the conjunction of distributed architecture and redundant networks does allow for a sufficiently reliable transport of signaling traffic over IP. The IUA protocol is flexible enough to allow its operation and management in a variety of physical configurations, enabling Network Operators to meet their performance and reliability requirements. To meet the ISDN signaling reliability and performance requirements for carrier grade networks, Network Operators SHOULD ensure that there is no single point of failure provisioned in the end-to-end network architecture between an ISDN node and an IP ASP. Depending of course on the reliability of the SG and ASP functional elements, this can typically be met by the provision of redundant QOS-bounded IP network paths for SCTP Associations between SCTP End Points, and redundant Hosts, and redundant SGs. The distribution of ASPs within the available Hosts is also important. For a particular Application Server, the related ASPs SHOULD be distributed over at least two Hosts. An example logical network architecture relevant to carrier-grade operation in the IP network domain is shown in Figure 2 below: Host1 ******** ************** * *_________________________________________* ******** * * * _________* * ASP1 * * * SG1 * SCTP Associations | * ******** * * *_______________________ | * * ******** | | ************** | | ******** | | * *_______________________________| * * | * SG2 * SCTP Associations | * *____________ | * * | | Host2 ******** | | ************** | |_________________* ******** * |____________________________* * ASP1 * * * ******** * * * ************** . . . Figure 2 - Logical Model Example For carrier grade networks, the failure or isolation of a particular ASP SHOULD NOT cause stable calls to be dropped. This implies that ASPs need, in some cases, to share the call state or be able to pass the call state between each other. However, this sharing or communication of call state information is outside the scope of this document. --------- New text: (Section 1.3.3) --------- None, all text moved to Appendix. Section and figure numbering adjusted accordingly. 3.10.3 Solution description Moved operational recommendations to Appendix. 3.11 Character Set for Text-Based Interface Identifier 3.11.1 Description of the problem Currently, a character set for the text-based Interface Identifier is not specified. 3.11.2 Text changes to the document Replace a dated reference from the list with the reference for ANSI X3.4-1986. --------- Old text: (Section 9) --------- [2] T1S1.7/99-220 Contribution, 'Back-hauling of DSS1 protocol in a Voice over Packet Network' --------- New text: (Section 9) --------- [2] Coded Character Set--7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986. --------- Old text: (Section 3.2) --------- The Tag value for the Text-based Interface Identifier is 0x3. The length is variable. --------- New text: (Section 3.2) --------- The Tag value for the Text-based [2] Interface Identifier is 0x3. The length is variable. 3.11.3 Solution description Add reference to 7-bit ASCII character set for text-based Interface Identifier. 3.12 References - Normative and Informative 3.12.1 Description of the problem The references should be split between normative and informative. 3.12.2 Text changes to the document --------- Old text: (Section 9) --------- [1] ITU-T Recommendation Q.920, 'Digital Subscriber signaling System No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer - General Aspects' [2] T1S1.7/99-220 Contribution, 'Back-hauling of DSS1 protocol in a Voice over Packet Network' [3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [4] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Architectural Framework for Signaling Transport", RFC 2719, October 1999. [5] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997. [6] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [7] Bradner, s., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. --------- New text: (Section 3.3.2.5) --------- 9.1 Normative [1] ITU-T Recommendation Q.920, 'Digital Subscriber signaling System No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer - General Aspects' [2] Coded Character Set--7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986. 9.2 Informative [3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [4] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Architectural Framework for Signaling Transport", RFC 2719, October 1999. [5] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997. [6] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [7] Bradner, s., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [9] RFC 2719, "Framework Architecture for Signaling Transport", L. Ong et al, October 1999 3.12.3 Solution description Separated the references into ormative and informative. 3.13 ASP Up Procedures 3.13.1 Description of the problem The ASP Up procedures need to be resynchronized with the other UAs. 3.13.2 Text changes to the document --------- Old text: (Section 4.3.3.1) --------- After an ASP has successfully established an SCTP association to an SG, the SG waits for the ASP to send an ASP Up message, indicating that the ASP IUA peer is available. The ASP is always the initiator of the ASP Up exchange. When an ASP Up message is received at an SG and internally the remote ASP is not considered locked-out for local management reasons, the SG marks the remote ASP as "Inactive". The SG responds with an ASP Up Ack message in acknowledgement. The SG sends an ASP-Up Ack message in response to a received ASP Up message even if the ASP is already marked as "Inactive" at the SG. If for any local reason the SG cannot respond with an ASP Up, the SG responds to a ASP Up with a with an ASP-Down Ack message with Reason "Management Blocking". At the ASP, the ASP Up Ack message received from the SG is not acknowledged by the ASP. If the ASP does not receive a response from the SG, or an ASP Down Ack is received, the ASP MAY resend ASP Up messages every 2 seconds until it receives a ASP Up Ack message from the SG. The ASP MAY decide to reduce the frequency (say to every 5 seconds) if an ASP Up Ack is not received after a few tries. The ASP MUST wait for the ASP Up Ack message from the SG before sending any ASP traffic control messages (ASPAC or ASPIA) or Data messages or it will risk message loss. If the SG receives QPTM, ASP Active or ASP Inactive messages before an ASP Up is received, the SG SHOULD discard these messages. --------- New text: (Section 4.3.3.1) --------- After an ASP has successfully established an SCTP association to an SG, the SG waits for the ASP to send an ASP Up message, indicating that the ASP IUA peer is available. The ASP is always the initiator of the ASP Up message. This action MAY be initiated at the ASP by an M-ASP_UP request primitive from Layer Management or MAY be initiated automatically by an IUA management function. When an ASP Up message is received at an SG and internally the remote ASP is in the ASP-DOWN state and not considered locked out for local management reasons, the SG marks the remote ASP in the state ASP-INACTIVE and informs Layer Management with an M-ASP_Up indication primitive. If the SG is aware, via current configuration data, which Application Servers the ASP is configured to operate in, the SG updates the ASP state to ASP-INACTIVE in each AS that it is a member. Alternatively, the SG may move the ASP into a pool of Inactive ASPs available for future configuration within Application Server(s), determined in a subsequent ASP Active procedure. If the ASP Up message contains an ASP Identifier, the SG should save the ASP Identifier for that ASP. The SG MUST send an ASP Up Ack message in response to a received ASP Up message even if the ASP is already marked as ASP-INACTIVE at the SG. If for any local reason (e.g., management lockout) the SG cannot respond with an ASP Up Ack message, the SG responds to an ASP Up message with an Error message with reason "Refused - Management Blocking". At the ASP, the ASP Up Ack message received is not acknowledged. Layer Management is informed with an M-ASP_UP confirm primitive. When the ASP sends an ASP Up message it starts timer T(ack). If the ASP does not receive a response to an ASP Up message within T(ack), the ASP MAY restart T(ack) and resend ASP Up messages until it receives an ASP Up Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Up messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_UP confirm primitive carrying a negative indication. The ASP must wait for the ASP Up Ack message before sending any other IUA messages (e.g., ASP Active). If the SG receives any other IUA messages before an ASP Up message is received (other than ASP Down - see Section 4.3.3.2), the SG MAY discard them. If an ASP Up message is received and internally the remote ASP is in the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as an Error message ("Unexpected Message), and the remote ASP state is changed to ASP-INACTIVE in all relevant Application Servers. If an ASP Up message is received and internally the remote ASP is already in the ASP-INACTIVE state, an ASP Up Ack message is returned and no further action is taken. 3.13.3 Solution description Updated ASP Up procedures based on other UAs. 3.14 ASP Down Procedures 3.14.1 Description of the problem The ASP Down procedures need to be resynchronized with the other UAs. 3.14.2 Text changes to the document --------- Old text: (Section 4.3.3.2) --------- The ASP will send an ASP Down to an SG when the ASP is to be removed from the list of ASPs in all Application Servers that it is a member and no longer receive any IUA traffic or management messages. Whether the ASP is permanently removed from an AS is a function of configuration management. The SG marks the ASP as "Down" and returns an ASP Down Ack message to the ASP if one of the following events occur: - to acknowledge an ASP Down message from an ASP, - to reply to ASPM messages from an ASP which is locked out for management reasons. The SG sends an ASP Down Ack message in response to a received ASP Down message from the ASP even if the ASP is already marked as "Down" at the SG. If the ASP does not receive a response from the SG, the ASP MAY send ASP Down messages every 2 seconds until it receives an ASP Down Ack message from the SG or the SCTP association goes down. The ASP MAY decide to reduce the frequency (say to every 5 seconds) if an ASP Down Ack is not received after a few tries. --------- New text: (Section 4.3.3.2) --------- The ASP will send an ASP Down to an SG when the ASP is to be removed from the list of ASPs in all Application Servers that it is a member and no longer receive any IUA traffic or management messages. This action MAY be initiated at the ASP by an M-ASP_DOWN request primitive from Layer Management or MAY be initiated automatically by an IUA management function. Whether the ASP is permanently removed from an AS is a function of configuration management. The SG marks the ASP as ASP-DOWN, informs Layer Management with an M-ASP_Down indication primitive, and returns an ASP Down Ack message to the ASP. The SG MUST send an ASP Down Ack message in response to a received ASP Down message from the ASP even if the ASP is already marked as ASP-DOWN at the SG. At the ASP, the ASP Down Ack message received is not acknowledged. Layer Management is informed with an M-ASP_DOWN confirm primitive. If the ASP receives an ASP Down Ack without having sent an ASP Down message, the ASP should now consider itself as in the ASP-DOWN state. If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state, the ASP should then initiate procedures to return itself to its previous state. When the ASP sends an ASP Down message it starts timer T(ack). If the ASP does not receive a response to an ASP Down message within T(ack), the ASP MAY restart T(ack) and resend ASP Down messages until it receives an ASP Down Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Down messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a negative indication. 3.14.3 Solution description Updated ASP Down procedures based on other UAs. 3.15 ASP Active Procedures 3.15.1 Description of the problem The ASP Active procedures need to be resynchronized with the other UAs. 3.15.2 Text changes to the document --------- Old text: (Section 4.3.3.4) --------- When an ASP Active (ASPAC) message is received, the SG responds to the ASP with a ASPAC Ack message acknowledging that the ASPAC was received and starts sending traffic for the associated Application Server(s) to that ASP. --------- New text: (Section 4.3.3.4) --------- If the Application Server can be successfully activated, the SG responds responds to the ASP with a ASPAC Ack message acknowledging that the ASPAC was received and starts sending traffic for the Application Server to that ASP. In the case where an "out-of-the-blue" ASP Active message is received (i.e., the ASP has not registered with the SG or the SG has no static configuration data for the ASP), the message MAY be silently discarded. The SG MUST send an ASP Active Ack message in response to a received ASP Active message from the ASP, if the ASP is already marked in the ASP-ACTIVE state at the SG. At the ASP, the ASP Active Ack message received is not acknowledged. Layer Management is informed with an M-ASP_ACTIVE confirm primitive. It is possible for the ASP to receive Data message(s) before the ASP Active Ack message as the ASP Active Ack and Data messages from an SG may be sent on different SCTP streams. Message loss is possible as the ASP does not consider itself in the ASP-ACTIVE state until reception of the ASP Active Ack message. When the ASP sends an ASP Active message it starts timer T(ack). If the ASP does not receive a response to an ASP Active message within T(ack), the ASP MAY restart T(ack) and resend ASP Active messages until it receives an ASP Active Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Active messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_ACTIVE confirm primitive carrying a negative indication. 3.15.3 Solution description Updated ASP Active procedures based on other UAs. 3.16 ASP Inactive Procedures 3.16.1 Description of the problem The ASP Inactive procedures need to be resynchronized with the other UAs. 3.16.2 Text changes to the document --------- Old text: (Section 4.3.3.5) --------- If no other ASPs are Active in the Application Server, the SG sends a NTFY (AS-Pending) to all inactive ASPs of the AS and either discards all incoming messages for the AS or starts buffering the incoming messages for T(r)seconds, after which messages will be discarded. T(r) is configurable by the network operator. If the SG receives an ASPAC from an ASP in the AS before expiry of T(r), the buffered traffic is directed to the ASP and the timer is cancelled. If T(r) expires, the AS is moved to the "Inactive" state. --------- New text: (Section 4.3.3.5) --------- When the ASP sends an ASP Inactive message it starts timer T(ack). If the ASP does not receive a response to an ASP Inactive message within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive messages until it receives an ASP Inactive Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Inactive messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in a M-ASP_Inactive confirm primitive carrying a negative indication. If no other ASPs in the Application Server are in the state ASP-ACTIVE, the SG MUST send a Notify message ("AS-Pending") to all of the ASPs in the AS which are in the state ASP-INACTIVE. The SG SHOULD start buffering the incoming messages for T(r) seconds, after which messages MAY be discarded. T(r) is configurable by the network operator. If the SG receives an ASP Active message from an ASP in the AS before expiry of T(r), the buffered traffic is directed to that ASP and the timer is cancelled. If T(r) expires, the AS is moved to the AS-INACTIVE state. 3.16.3 Solution description Updated ASP Inactive procedures based on other UAs. 3.17 Notify Procedures 3.17.1 Description of the problem The Notify procedures need to be resynchronized with the other UAs. 3.17.2 Text changes to the document --------- Old text: (Section 4.3.3.6) --------- A Notify message reflecting a change in the AS state is sent to all ASPs in the AS, except those in the "Down" state, with appropriate Status Identification. --------- New text: (Section 4.3.3.6) --------- A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. At the ASP, Layer Management is informed with an M-NOTIFY indication primitive. The Notify message must be sent whether the AS state change was a result of an ASP failure or reception of an ASP State management (ASPSM) / ASP Traffic Management (ASPTM) message. In the second case, the Notify message MUST be sent after any related acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack). 3.17.3 Solution description Updated Notify procedures based on other UAs. 3.18 Heartbeat Text Clarification 3.18.1 Description of the problem The are some minor error in the Heartbeat procedures text. 3.18.2 Text changes to the document --------- Old text: (Section 4.3.3.7) --------- After receiving an ASP Up Ack message from the SG in response to an ASP Up message, the ASP MAY optionally send Beat messages periodically, subject to a provisionable timer T(beat). The SG IUA, upon receiving a BEAT message from the ASP, responds with a BEAT ACK message. If no BEAT message (or any other IUA message) is received from the SG within the timer 2*T(beat), the SG will consider the remote IUA as "Down". The SG will also send an ASP Down Ack message to the ASP. --------- New text: (Section 4.3.3.7) --------- Either IUA peer may optionally send Heartbeat messages periodically, subject to a provisionable timer T(beat). Upon receiving a Heartbeat message, the IUA peer MUST respond with a Heartbeat Ack message. If no Heartbeat Ack message (or any other IUA message) is received from the IUA peer within 2*T(beat), the remote IUA peer is considered unavailable. Transmission of Heartbeat messages is stopped and the signalling process SHOULD attempt to re-establish communication if it is configured as the client for the disconnected IUA peer. 3.18.3 Solution description Updated Heartbeat procedures based on other UAs. 3.19 Error Message 3.19.1 Description of the problem There is a need to add the "Refused - Management Blocking" error code. Need to clearly specify that Error messages are not to be sent in response to an Error message. Also, need to indicate that the Diagnostic area must be used for the Invalid Interface Identifier error. 3.19.2 Text changes to the document --------- Old text: (Section 3.3.3.1) --------- Invalid Version 0x01 Invalid Interface Identifier 0x02 Unsupported Message Class 0x03 Unsupported Message Type 0x04 Unsupported Traffic Handling Mode 0x05 Unexpected Message 0x06 Protocol Error 0x07 Unsupported Interface Identifier Type 0x08 Invalid Stream Identifier 0x09 Unassigned TEI 0x0a Unrecognized SAPI 0x0b Invalid TEI, SAPI combination 0x0c The "Invalid Version" error would be sent if a message was received with an invalid or unsupported version. The Error message would contain the supported version in the Common header. The Error message could optionally provide the supported version in the Diagnostic Information area. The "Invalid Interface Identifier" error would be sent by a SG if an ASP sends a message with an invalid (unconfigured) Interface Identifier value. --------- New text: (Section 3.3.3.1) --------- Invalid Version 0x01 Invalid Interface Identifier 0x02 Unsupported Message Class 0x03 Unsupported Message Type 0x04 Unsupported Traffic Handling Mode 0x05 Unexpected Message 0x06 Protocol Error 0x07 Unsupported Interface Identifier Type 0x08 Invalid Stream Identifier 0x09 Unassigned TEI 0x0a Unrecognized SAPI 0x0b Invalid TEI, SAPI combination 0x0c Refused - Management Blocking 0x0d The "Invalid Version" error would be sent if a message was received with an invalid or unsupported version. The Error message would contain the supported version in the Common header. The Error message could optionally provide the supported version in the Diagnostic Information area. The "Invalid Interface Identifier" error would be sent by a SG if an ASP sends a message with an invalid (unconfigured) Interface Identifier value. For this error, the Diagnostic Information MUST contain the Common and IUA message headers of the offending message so that Invalid Interface Identifier can be identified. Error messages MUST NOT be generated in response to other Error messages. 3.19.3 Solution description Added new error code and clarified that Error messages must not be generated in response to an Error message. These changes make IUA more consistent with other UAs. 3.20 Misconfiguration of Interface Identifiers 3.19.1 Description of the problem Provide some examples of how to handle misconfiguration of Interface Identifiers. 3.20.2 Text changes to the document --------- New text: (Section 5.1.5) --------- This scenario shows the example IUA message flows for the establishment of traffic between an SG and an ASP in which some of the Interface Identifiers have been misconfigured on the ASP side. The SG in this case has Interface Identifers 1-5 configured for ASP1. SG ASP1 | | | | |<----ASP Active (IIDs 1-10)-----| |---ASP Active Ack (IIDs 1-5)--->| |-------Error (IIDs 6)---------->| |-------Error (IIDs 7)---------->| |-------Error (IIDs 8)---------->| |-------Error (IIDs 9)---------->| |-------Error (IIDs 10)--------->| | | 3.20.3 Solution description An example message flow is provided for the case of Interface Identifier misconfiguration. 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, Subhodeep Sarkar, Sujatha Krao and Ming Lin. 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. | ||||||||||||||||
Last modified: Tue, 27 Aug 2024 00:03:34 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. |