| draft-ietf-sigtran-iua-imp-guide-00 Description: Request For Comments
You 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.
|
Documentation