draft-ietf-sigtran-iua-imp-guide-00.txt   draft-ietf-sigtran-iua-imp-guide-01.txt 
Network Working Group K. Morneault Network Working Group K. Morneault
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Expires in six months Apr 2002 Expires in six months July 2002
IUA (RFC 3057) Outstanding Issues IUA (RFC 3057) Outstanding Issues
<draft-ietf-sigtran-iua-imp-guide-00.txt> <draft-ietf-sigtran-iua-imp-guide-01.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts all provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts
are working documents of the Internet Engineering Task Force (IETF), are working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at line 170 skipping to change at line 170
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 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 | | Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is 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 same as for the ASP Up message (See Section 3.3.2.1).
--------- ---------
Old text: (Section 3.3.2.4) Old text: (Section 3.3.2.4)
--------- ---------
The ASP Down Ack message is used to acknowledge an ASP Down message The ASP Down Ack message is used to acknowledge an ASP Down message
received from a remote IUA peer. received from a remote IUA peer.
The ASP Down Ack message contains the following parameters: The ASP Down Ack message contains the following parameters:
skipping to change at line 230 skipping to change at line 230
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 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 | | Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is 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 same as for the ASP Up message (See Section 3.3.2.1).
3.2.3 Solution description 3.2.3 Solution description
The Reason parameter is removed from the ASP Down and ASP Down The Reason parameter is removed from the ASP Down and ASP Down
Acknowledge messages. ASP and SG implementations should accept the Acknowledge messages. ASP and SG implementations should accept the
respective message without the Reason parameter. respective message without the Reason parameter.
3.3 ASP State Machine 3.3 ASP State Machine
3.3.1 Description of the problem 3.3.1 Description of the problem
skipping to change at line 1307 skipping to change at line 1307
If no other ASPs in the Application Server are in the state If no other ASPs in the Application Server are in the state
ASP-ACTIVE, the SG MUST send a Notify message ("AS-Pending") to 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. 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) The SG SHOULD start buffering the incoming messages for T(r)
seconds, after which messages MAY be discarded. T(r) is seconds, after which messages MAY be discarded. T(r) is
configurable by the network operator. If the SG receives an ASP 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 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. 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. If T(r) expires, the AS is moved to the AS-INACTIVE state.
At the ASP, the ASP Inactive Ack message received is not
acknowledged. Layer Management is informed with an M-ASP_INACTIVE
confirm primitive. If the ASP receives an ASP Inactive Ack without
having sent an ASP Inactive message, the ASP should now consider
itself as in the ASP-INACTIVE state. If the ASP was previously in
the ASP-ACTIVE state, the ASP should then initiate procedures to
return itself to its previous state.
3.16.3 Solution description 3.16.3 Solution description
Updated ASP Inactive procedures based on other UAs. Updated ASP Inactive procedures based on other UAs.
3.17 Notify Procedures 3.17 Notify Procedures
3.17.1 Description of the problem 3.17.1 Description of the problem
The Notify procedures need to be resynchronized with the The Notify procedures need to be resynchronized with the
other UAs. other UAs.
skipping to change at line 1444 skipping to change at line 1452
Unsupported Message Type 0x04 Unsupported Message Type 0x04
Unsupported Traffic Handling Mode 0x05 Unsupported Traffic Handling Mode 0x05
Unexpected Message 0x06 Unexpected Message 0x06
Protocol Error 0x07 Protocol Error 0x07
Unsupported Interface Identifier Type 0x08 Unsupported Interface Identifier Type 0x08
Invalid Stream Identifier 0x09 Invalid Stream Identifier 0x09
Unassigned TEI 0x0a Unassigned TEI 0x0a
Unrecognized SAPI 0x0b Unrecognized SAPI 0x0b
Invalid TEI, SAPI combination 0x0c Invalid TEI, SAPI combination 0x0c
Refused - Management Blocking 0x0d Refused - Management Blocking 0x0d
ASP Identifier Required 0x0e
Invalid ASP Identifier 0x0f
The "Invalid Version" error would be sent if a message was received The "Invalid Version" error would be sent if a message was received
with an invalid or unsupported version. The Error message would with an invalid or unsupported version. The Error message would
contain the supported version in the Common header. The Error contain the supported version in the Common header. The Error
message could optionally provide the supported version in the message could optionally provide the supported version in the
Diagnostic Information area. Diagnostic Information area.
The "Invalid Interface Identifier" error would be sent by a SG if an The "Invalid Interface Identifier" error would be sent by a SG if an
ASP sends a message with an invalid (unconfigured) Interface ASP sends a message with an invalid (unconfigured) Interface
Identifier value. For this error, the Diagnostic Information MUST Identifier value. For this error, the Diagnostic Information MUST
skipping to change at line 1468 skipping to change at line 1478
messages. messages.
3.19.3 Solution description 3.19.3 Solution description
Added new error code and clarified that Error messages must not be Added new error code and clarified that Error messages must not be
generated in response to an Error message. These changes make IUA generated in response to an Error message. These changes make IUA
more consistent with other UAs. more consistent with other UAs.
3.20 Misconfiguration of Interface Identifiers 3.20 Misconfiguration of Interface Identifiers
3.19.1 Description of the problem 3.20.1 Description of the problem
Provide some examples of how to handle misconfiguration of Interface Provide some examples of how to handle misconfiguration of Interface
Identifiers. Identifiers.
3.20.2 Text changes to the document 3.20.2 Text changes to the document
--------- ---------
New text: (Section 5.1.5) New text: (Section 5.1.5)
--------- ---------
skipping to change at line 1502 skipping to change at line 1512
|-------Error (IIDs 8)---------->| |-------Error (IIDs 8)---------->|
|-------Error (IIDs 9)---------->| |-------Error (IIDs 9)---------->|
|-------Error (IIDs 10)--------->| |-------Error (IIDs 10)--------->|
| | | |
3.20.3 Solution description 3.20.3 Solution description
An example message flow is provided for the case of Interface An example message flow is provided for the case of Interface
Identifier misconfiguration. Identifier misconfiguration.
3.21 ASP Inactive Traffic Mode Parameter
3.21.1 Description of the problem
The Traffic Mode Type parameter was removed from ASP Inactive
message for all other UAs.
3.21.2 Text changes to the document
---------
Old text: (Section 3.3.2.7)
---------
The ASPIA message contains the following parameters
Traffic Mode Type (Mandatory)
Interface Identifiers (Optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
INFO String (Optional)
The format for the ASP Inactive message parameters using 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the ASP Inactive message using text formatted (string)
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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers |
| of Tag Type 0x3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Traffic Mode Type parameter identifies the traffic mode of
operation of the ASP within an AS. The valid values for Traffic Mode
Type are shown in the following table:
Value Description
0x1 Over-ride
0x2 Load-share
---------
New text: (Section 3.3.2.7)
---------
The ASPIA message contains the following parameters
Interface Identifiers (Optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
INFO String (Optional)
The format for the ASP Inactive message parameters using 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 (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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the ASP Inactive message using text formatted (string)
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 (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers |
| of Tag Type 0x3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.21.3 Solution description
Remove Traffic Mode Type from ASP Inactive message in order to
remain consistent with other UAs.
3.22 Encoding of the DLCI parameter
3.22.1 Description of the problem
The text states the DLCI field is encoded in accordance to Q.921
and a figure is given. Using the standard interpretation of the IETF
for the significance of bits the encoding described in the figure
is not in accordance to Q.921.
3.22.2 Text changes to the document
--------
Old text (Section 3.2)
--------
3.2 IUA Message Header
In addition to the common message header, there will be a specific
message header for QPTM and the TEI Status MGMT messages. The IUA
message header will immediately follow the Common header in these
messages.
This message header will contain the Interface Identifier and Data
Link Connection Identifier (DLCI). The Interface Identifier
identifies the physical interface terminating the signaling channel
at the SG for which the signaling messages are sent/received. The
format of the Interface Identifier parameter can be text or integer.
The Interface Identifiers are assigned according to network operator
policy. The integer values used are of local significance only,
coordinated between the SG and ASP.
The integer formatted Interface Identifier MUST be supported. The
text formatted Interface Identifier MAY optionally be supported.
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 (0x1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 IUA Message Header (Integer-based Interface Identifier)
The Tag value for the Integer-based Interface Identifier is 0x1. The
length is always set to a value of 8.
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 (0x3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (text) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 IUA Message Header (Text-based Interface Identifier)
The Tag value for the Text-based Interface Identifier is 0x3. The
length is variable.
The DLCI format is shown below in Figure 6.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | SPR | SAPI |
+-----------------------------------------------+
| 1 | TEI |
+-----------------------------------------------+
Figure 6 DLCI Format
SPR: Spare 2nd bit in octet 1, (1 bit)
SAPI: Service Access Point Identifier, 3rd through 8th bits in octet
1 (6 bits)
TEI: Terminal Endpoint Identifier, 2nd through 8th bits in octet 2
(7 bits)
The DLCI field (including the SAPI and TEI) is coded in accordance
with Q.921.
--------
New text (Section 3.2)
--------
3.2 IUA Message Header
In addition to the common message header, there will be a specific
message header for QPTM and the TEI Status MGMT messages. The IUA
message header will immediately follow the Common header in these
messages.
This message header will contain the Interface Identifier and Data
Link Connection Identifier (DLCI). The Interface Identifier
identifies the physical interface terminating the signaling channel
at the SG for which the signaling messages are sent/received. The
format of the Interface Identifier parameter can be text or integer.
The Interface Identifiers are assigned according to network operator
policy. The integer values used are of local significance only,
coordinated between the SG and ASP.
The integer formatted Interface Identifier MUST be supported. The
text formatted Interface Identifier MAY optionally be supported.
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 (0x1) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 IUA Message Header (Integer-based Interface Identifier)
The Tag value for the Integer-based Interface Identifier is 0x1. The
length is always set to a value of 8. The Interface Identifier (integer)
is a 32-bit unsigned integer.
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 (0x3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (text) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 IUA Message Header (Text-based Interface Identifier)
The Tag value for the Text-based Interface Identifier is 0x3. The
length is variable.
The DLCI format is shown below in Figure 6.
most least
significant significant
bit bit
+-----+-----+-----+-----+-----+-----+-----+-----+
| SAPI | SPR | 0 |
+-----------------------------------------------+
| TEI | 1 |
+-----------------------------------------------+
Figure 6 DLCI Format
SPR: Spare 2nd bit in octet 1, (1 bit)
SAPI: Service Access Point Identifier, (6 bits)
TEI: Terminal Endpoint Identifier, (7 bits)
As an example SAPI = 0, TEI = 64, SPR = 0 would be encoded as
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | 0x81 | 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DLCI field (including the SAPI and TEI) is coded in accordance
with Q.921.
3.22.3 Solution description
It is now clearly stated that the DLCI field is encoded in accordance
with Q.921.
3.23 Updates to Message Flow Examples
3.23.1 Description of the problem
The message flow examples in Section 5 were missing Notify
messages.
3.23.2 Text changes to the document
--------
Old text (Section 5.1.1)
--------
SG ASP1
|
|<---------ASP Up----------|
|--------ASP Up Ack------->|
| |
|<-------ASP Active--------|
|------ASP Active Ack----->|
| |
--------
New text (Section 5.1.1)
--------
SG ASP1
|
|<---------ASP Up----------|
|--------ASP Up Ack------->|
| |
|-----NTFY(AS-INACTIVE)--->|
| |
|<-------ASP Active--------|
|------ASP Active Ack----->|
| |
|------NTFY(AS-ACTIVE)---->|
| |
--------
Old text (Section 5.1.2)
--------
SG ASP1 ASP2
| | |
|<--------ASP Up----------| |
|-------ASP Up Ack------->| |
| | |
|<-----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------->|
| | |
| | |
|<-------ASP Active-------| |
|-----ASP Active Ack----->| |
| | |
--------
New text (Section 5.1.2)
--------
SG ASP1 ASP2
| | |
|<--------ASP Up----------| |
|-------ASP Up Ack------->| |
| | |
|----NTFY(AS-INACTIVE)--->| |
|---------------------NTFY(AS-INACTIVE)------------->|
| | |
|<-----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------->|
| | |
| | |
|<-------ASP Active-------| |
|-----ASP Active Ack----->| |
| | |
|-----NTFY(AS-ACTIVE)---->| |
|----------------------NTFY(AS-ACTIVE)-------------->|
--------
Old text (Section 5.1.3)
--------
SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|--------ASP Up Ack------>| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)----| |
|----ASP Active Ack------>| |
| | |
|<----------------------------ASP Active (Ldshr)-----|
|-----------------------------ASP Active Ack-------->|
| | |
--------
New text (Section 5.1.3)
--------
SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|--------ASP Up Ack------>| |
| | |
|----NTFY(AS-INACTIVE)--->| |
|---------------------NTFY(AS-INACTIVE)------------->|
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)----| |
|----ASP Active Ack------>| |
| | |
|-----NTFY(AS-ACTIVE)---->| |
|----------------------NTFY(AS-ACTIVE)-------------->|
| | |
|<----------------------------ASP Active (Ldshr)-----|
|-----------------------------ASP Active Ack-------->|
| | |
--------
Old text (Section 5.1.4)
--------
SG ASP1 ASP2 ASP3
| | | |
|<------ASP Up-------| | |
|-----ASP Up Ack---->| | |
| | | |
|<--------------------------ASP Up-------| |
|------------------------ASPUp Ack)----->| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack----->|
| | | |
| | | |
|<-ASP Act (Ldshr)---| | |
|----ASP Act Ack---->| | |
| | | |
|<---------------------ASP Act (Ldshr)---| |
|----------------------ASP Act Ack------>| |
| | | |
--------
New text (Section 5.1.4)
--------
SG ASP1 ASP2 ASP3
| | | |
|<------ASP Up-------| | |
|-----ASP Up Ack---->| | |
| | | |
|-NTFY(AS-INACTIVE)->| | |
|--------------NTFY(AS-INACTIVE)-------->| |
|-----------------------NTFY(AS-INACTIVE)------------------->|
| | | |
|<--------------------------ASP Up-------| |
|------------------------ASPUp Ack)----->| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack----->|
| | | |
| | | |
|<-ASP Act (Ldshr)---| | |
|----ASP Act Ack---->| | |
| | | |
|<---------------------ASP Act (Ldshr)---| |
|----------------------ASP Act Ack------>| |
| | | |
|--NTFY(AS-ACTIVE)-->| | |
|---------------NTFY(AS-ACTIVE)--------->| |
|------------------------NTFY(AS-ACTIVE)-------------------->|
--------
Old text (Section 5.2.1)
--------
SG ASP1 ASP2
| | |
|<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| |
|-------------------NTFY(AS-Pending) --------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack)------->|
| |
--------
New text (Section 5.2.1)
--------
SG ASP1 ASP2
| | |
|<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| |
| | |
|----NTFY(AS-Pending)---->| |
|-------------------NTFY(AS-Pending)---------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack)------->|
| |
|----NTFY(AS-ACTIVE)----->| |
|-------------------NTFY(AS-ACTIVE)----------------->|
3.23.3 Solution description
The new text shows when the SG should send Notify messages.
4.0 Acknowledgements 4.0 Acknowledgements
The author would like to thank the following people that have The author would like to thank the following people that have
provided comments and input for this document: Alex Audu, provided comments and input for this document: Alex Audu,
Greg Sidebottom, Srinivasa A. Shikaripura, Subhodeep Sarkar, Greg Sidebottom, Srinivasa A. Shikaripura, Subhodeep Sarkar,
Sujatha Krao and Ming Lin. Sujatha Krao, Ming Lin, Shih-Chang Liang and Michael Tuexen.
5.0 Authors Addresses 5.0 Authors Addresses
Ken A. Morneault Ken A. Morneault
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA 20171 Herndon, VA 20171
USA USA
EMail: kmorneau@cisco.com EMail: kmorneau@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/