Subject: [Sigtran] SUA 14 editorial suggestions

From: "Richard Adams" <[email-masked]>
Date: Tue, 21 Jan 2003 16:38:34 +0100

John,
If I repeat editorial suggestions already made, then I apologise! If there is still time, here are the editorials I found.

Section 1 Introduction
 Replace one of the [ANSI SCCP] references with [ITU SCCP].
 Replace i.e. with e.g. in the parentheses, since the list isn't complete.
 And SCCP user _messages_ are transported between two signalling endpoints.

Old text:
This draft defines a protocol for the transport SS7 SCCP [ANSI SCCP]
   [ANSI SCCP] Users (i.e. TCAP, RANAP, etc.) signalling messages over
   IP using the Stream Control Transmission Protocol (SCTP) [2960].
   This protocol would be used between a Signalling Gateway (SG) and
   Signaling Endpoint located in an IP network.  Additionally, the
   protocol can be used to transport SS7 SCCP users between two
   signaling endpoints located within an IP network.

New text:
This draft defines a protocol for the transport SS7 SCCP [ANSI SCCP]
   [ITU SCCP] Users (e.g. TCAP, RANAP, etc.) signalling messages over
   IP using the Stream Control Transmission Protocol (SCTP) [2960].
   This protocol would be used between a Signalling Gateway (SG) and
   Signaling Endpoint located in an IP network.  Additionally, the
   protocol can be used to transport SS7 SCCP user messages between two
   signaling endpoints located within an IP network.

Subsection 1.2 Terminology
Need to add a definition of Network Appearance. I suggest a modified form of
M3UA's.

Old text:
None.

New Text:
Network Appearance - The Network Appearance is an SUA local reference
(typically an integer) shared by SG and AS that together with a Signalling
Point Code or global title uniquely identifies an SS7 node by indicating the
specific SS7 network it belongs to.

Subsection 1.3.1.2 SG as relay-point
Global Title Translation in SCCP yields an "entity set", not an "entity".

Old text:
A Global Title translation is executed at the SG, before the
   destination of the message can be determined.  The actual location
   of the SCCP-user is irrelevant to the SS7 network.  GT Translation
   yields an "SCCP entity", from an AS can be derived.  Selection of
   the AS is thus based on the SCCP called party address  (and possibly
   other SS7 parameters depending on the implementation).

New text:
A Global Title translation is executed at the SG, before the
   destination of the message can be determined.  The actual location
   of the SCCP-user is irrelevant to the SS7 network.  GT Translation
   yields an "SCCP entity set", from which an AS can be derived.
   Selection of the AS is thus based on the SCCP called party address
   (and possibly other SS7 parameters depending on the implementation).

Subsection 1.4.4 Interworking with SCCP Network Management Functions
The latest ITU Q.711 is for 2001, and since the references don't mention the
date, this is the one implied, I think.
N-STATE is defined in ITU Q.711 clause 6.3.2.3.2 Table 16/Q.711.
N-PCSTATE is defined in ITU Q.711 clause 6.3.2.3.3 Table 17/Q.711.
N-COORD is defined in ITU Q.711 clause 6.3.2.3.1 Table 15/Q.711.
I haven't looked at the ANSI references.
Old text:

   Generic   |Specific   |
   Name      |Name       |ANSI/ITU Reference
      ----------+-----------+---------------------------------------------
   N-State   |Request    |ITU-Q.711   Chap 6.3.2.3.2 (Tab 14/Q.711)
             |Indication |ANSI-T1.112 Chap 2.3.2.3.2 (Tab 8E/T1.112.1)
   ----------+-----------+---------------------------------------------
   N-Pcstate |Indication |ITU-Q.711   Chap 6.3.2.3.3 (Tab 15/Q.711)
             |           |ANSI-T1.112 Chap 2.3.2.3.4 (Tab 8G/T1.112.1)
   N-Coord   |Request    |ITU-Q.711   Chap 6.3.2.3.1 (Tab 13/Q.711)
             |Indication |ANSI-T1.112 Chap 2.3.2.3.3 (Tab 8F/T1.112.1)
             |Response   |
             |Confirm    |
New text:

   Generic   |Specific   |
   Name      |Name       |ANSI/ITU Reference
   ----------+-----------+---------------------------------------------
   N-STATE   |Request    |ITU-Q.711   Chap 6.3.2.3.2 (Tab 16/Q.711)
             |Indication |ANSI-T1.112 Chap 2.3.2.3.2 (Tab 8E/T1.112.1)
   ----------+-----------+---------------------------------------------
   N-PCSTATE |Indication |ITU-Q.711   Chap 6.3.2.3.3 (Tab 17/Q.711)
             |           |ANSI-T1.112 Chap 2.3.2.3.4 (Tab 8G/T1.112.1)
   ----------+-----------+---------------------------------------------
   N-COORD   |Request    |ITU-Q.711   Chap 6.3.2.3.1 (Tab 15/Q.711)
             |Indication |ANSI-T1.112 Chap 2.3.2.3.3 (Tab 8F/T1.112.1)
             |Response   |
             |Confirm    |

Subsection 1.5.1 Address Mapping at the SG
Replace occurrences of "t(r)""by "T(r)" to make this consistent with other
UAs and section 4.3.4.4.

Old text:
   Normally, one or more ASPs are active in the AS (i.e., currently
   processing traffic) but in certain failure and transition cases it
   is possible that there may not be an active ASP available. The SGP
   will buffer the message destined for this AS for a time t(r) or
   until an ASP becomes available. When no ASP becomes available before
   expiry of t(r), the SGP will flush the buffered messages and
   initiate the appropriate return or refusal procedures.

New text:
   Normally, one or more ASPs are active in the AS (i.e., currently
   processing traffic) but in certain failure and transition cases it
   is possible that there may not be an active ASP available. The SGP
   will buffer the message destined for this AS for a time T(r) or
   until an ASP becomes available. When no ASP becomes available before
   expiry of T(r), the SGP will flush the buffered messages and
   initiate the appropriate return or refusal procedures.

Subsection 1.6.1 Definition of the upper boundary
N-INFORM is defined in [ITU Q711] clause 6.1.1.3.2 Table 8/Q.711.
N-UNIT DATA is defined in [ITU Q711] clause 6.2.2.3.1 Table 12/Q.711.
N-NOTICE is defined in [ITU Q711] clause 6.2.2.3.2 Table 13/Q.711.
I haven't checked the ANSI references, and don't have them with me.
Also, the User at the ASP needs to be informed of SS7 network
availability/unavailability and congestion, so that it can modify the
traffic it offers, and give permission or not for subsystem state changes.
That is why the N-COORD, N-STATE and N-PCSTATE primitives are defined in
ITU - they are between the SCCP and its Users. ITU Q.711 clause 6.3.2 Tables
14/Q.711, 15/Q.711, 16/Q.711 and 17/Q.711. So they need to be added here.

Old text:
   The following primitives are supported between the SUA and an SCCP-
   user (a reference to ITU and ANSI sections where these primitives
   and corresponding parameters are described, is also given):

   Generic     |Specific  |
   Name        |Name      |ANSI/ITU Reference
   ------------+----------+-------------------------------------------
   N-Connect   |Request   |ITU-Q.711   Chap 6.1.1.2.2 (Tab 2/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.2 (Tab 2/T1.112.1)
               |Response  |
               |Confirm   |
   ------------+----------+-------------------------------------------
   N-Data      |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 3/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 3/T1.112.1)
   ------------+----------+-------------------------------------------
   N-Expedited |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 4/Q.711)
   Data        |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 4/T1.112.1)
   ------------+----------+-------------------------------------------
   N-Reset     |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 5/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 5/T1.112.1)
               |Response  |
               |Confirm   |
   ------------+----------+-------------------------------------------
   N-Disconnect|Request   |ITU-Q.711   Chap 6.1.1.2.4 (Tab 6/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.4 (Tab 6/T1.112.1)
   ------------+----------+-------------------------------------------
   N-Inform    |Request   |ITU-Q.711   Chap 6.1.1.3.1 (Tab 7/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.5 (Tab 6A/T1.112.1)
   ------------+----------+-------------------------------------------
   N-Unit Data |Request   |ITU-Q.711   Chap 6.2.2.3.1 (Tab 10/Q.711)
               |Indication|ANSI-T1.112 Chap 2.2.2.3.1 (Tab 8A/T1.112.1)
   ------------+----------+-------------------------------------------
   N-Notice    |Indication|ITU-Q.711   Chap 6.2.2.3.2 (Tab 11/Q.711)
               |          |ANSI-T1.112 Chap 2.2.2.3.2 (Tab 8B/T1.112.1)

New text:
   The following primitives are supported between the SUA and an SCCP-
   user (a reference to ITU and ANSI sections where these primitives
   and corresponding parameters are described, is also given):

   Generic     |Specific  |
   Name        |Name      |ANSI/ITU Reference
   ------------+----------+-------------------------------------------
   N-CONNECT   |Request   |ITU-Q.711   Chap 6.1.1.2.2 (Tab 2/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.2 (Tab 2/T1.112.1)
               |Response  |
               |Confirm   |
   ------------+----------+-------------------------------------------
   N-DATA      |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 3/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 3/T1.112.1)
   ------------+----------+-------------------------------------------
   N-EXPEDITED |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 4/Q.711)
   DATA        |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 4/T1.112.1)
   ------------+----------+-------------------------------------------
   N-RESET     |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 5/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 5/T1.112.1)
               |Response  |
               |Confirm   |
   ------------+----------+-------------------------------------------
   N-DISCONNECT|Request   |ITU-Q.711   Chap 6.1.1.2.4 (Tab 6/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.4 (Tab 6/T1.112.1)
   ------------+----------+-------------------------------------------
   N-INFORM    |Request   |ITU-Q.711   Chap 6.1.1.3.2 (Tab 8/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.5 (Tab 6A/T1.112.1)
   ------------+----------+-------------------------------------------
   N-UNITDATA  |Request   |ITU-Q.711   Chap 6.2.2.3.1 (Tab 12/Q.711)
               |Indication|ANSI-T1.112 Chap 2.2.2.3.1 (Tab 8A/T1.112.1)
   ------------+----------+-------------------------------------------
   N-NOTICE    |Indication|ITU-Q.711   Chap 6.2.2.3.2 (Tab 13/Q.711)
               |          |ANSI-T1.112 Chap 2.2.2.3.2 (Tab 8B/T1.112.1)
   ------------+----------+--------------------------------------------
   N-STATE     |Request   |ITU-Q.711   Chap 6.3.2.3.2 (Tab 16/Q.711)
               |Indication|ANSI-T1.112 Chap 2.3.2.3.2 (Tab 8E/T1.112.1)
   ------------+----------+--------------------------------------------
   N-PCSTATE   |Indication|ITU-Q.711   Chap 6.3.2.3.3 (Tab 17/Q.711)
               |          |ANSI-T1.112 Chap 2.3.2.3.4 (Tab 8G/T1.112.1)
   ------------+----------+--------------------------------------------
   N-COORD     |Request   |ITU-Q.711   Chap 6.3.2.3.1 (Tab 15/Q.711)
               |Indication|ANSI-T1.112 Chap 2.3.2.3.3 (Tab 8F/T1.112.1)
               |Response  |
               |Confirm   |

Subsection 3.1 Common Message Header
Need to state what the reserved field is set to.

Old text:
   Note that the 'data' portion of SUA messages SHALL contain SCCP-User
   data, not the encapsulated SCCP message.

   Optional parameters can only occur at most once in an SUA message.

New text:
   Note that the 'data' portion of SUA messages SHALL contain SCCP-User
   data, not the encapsulated SCCP message.

   Optional parameters can only occur at most once in an SUA message.

   The Reserved field shall be set to 0 in messages sent, and shall not be
   examined on reception.

Subsection 3.2.1 Connectionless Data Transfer (CLDT)
The sequence control parameter is not supplied for class 0 from SCCP User to
SCCP. It is mandatory here. So what value is it ? I suggest 0.

Old text:
   Implementation note: This message covers the following SCCP
   messages: unitdata (UDT), extended unitdata (XUDT), long unitdata
   (LUDT).

New text:
   Implementation note: This message covers the following SCCP
   messages: unitdata (UDT), extended unitdata (XUDT), long unitdata
   (LUDT). Sequence Control shall be set to 0 for class 0 messages.

Subsection 3.4.1 Destination Unavailable (DUNA)
How many point codes can be in the Affected Point Code parameter of a DUNA
message containing an SSN? I suggest just 1, that of the destination
containing the unavailable subsystem.

Old text:
Note 1:    When the SSN is included, the DUNA message corresponds to
              the SCCP N-STATE primitive. When SSN is not, the DUNA
              message corresponds to the SCCP N-PCSTATE primitive.
New text:
Note 1:    When the SSN is included, the DUNA message corresponds to
           the SCCP N-STATE primitive, and contains just one point code
           in the Affected Point Code parameter. When the SSN is not
           included, the DUNA message corresponds to the SCCP
           N-PCSTATE primitive.

Subsection 3.4.4 Network Congestion (SCON)
The N-STATE primitive between SCCP and SCCP User only indicates User In
Service (UIS for the User status parameter), or User out of Service (UOS).
It does not indicate congestion. The congestion status of a subsystem other
than SCCP is not reported directly. The SSC message is for SCCP/subsystem
congested, and always has its affected SSN parameter set to 1 (section
5.2.7.1 in my 2001 version of Q.714). So the SCON with SSN must have SSN =
1, and it corresponds with the N-PCSTATE indication containing both Remote
SCCP status and Restricted importance level parameters (see 6.3.2.2.6 and
table 17 of Q.711 of 2001. N-STATE User status is defined in 6.3.2.2.2 of
Q.711).
You might want to use N-STATE to report subsystem congestion for SUA, but
the congestion procedures in Q.714 handle only MTP (network and signalling
point) congestion, and SCCP and nodal congestion. If there is more than 1
SCCP user at an ASP sending messages to a destination at or towards which
there is SCCP/subsystem congestion, then both have to use the same RIL for
that destination.
I have another problem with SCON and SSC mapping, but for now I think Note 1
should provisionally change.

Old text:
Note 1:    When the SSN is included, the SCON message corresponds to
              the SCCP N-STATE primitive. When SSN is not included, the
              SCON message corresponds to the SCCP N-PCSTATE primitive.
New text:
Note 1: When the SSN is included it must be equal to 1. If the SSN is
        included the SCON corresponds to the N-PCSTATE primitive used to
        convey the Restricted Importance Level (RIL) to the SCCP user.
        When the SSN is not included, the SCON message corresponds to
        the SCCP N-PCSTATE primitive reporting signalling point or
        network congestion status.

Subsection 3.4.5 Destination User Part Unavailable (DUPU)
This should contain just one point code in the Affected Point Code field.

Old text:
 Note 1:    The DUPU corresponds to the SCCP N-PCSTATE primitive.

New text:
 Note 1:    The DUPU corresponds to the SCCP N-PCSTATE primitive, and
            contains in the Affected Point Code parameter just one point
            code.

Subsection 3.7.1 Error (ERR)
This might have already been caught, the value of the Tag for the Network
Appearance parameter should be 0x010D.
Old text:
       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 = 0x000C         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Error Code                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0006          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0012          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Mask     |                 Affected PC 1                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                              ...                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Mask     |                 Affected PC n                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x010D          |         Length = 8            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Network Appearance                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0007         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                        Diagnostic Info                        /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Error Code                    Mandatory
     Routing Context               Mandatory *1
     Network Appearance            Mandatory *1
     Affected Point Code           Mandatory *1
     Diagnostic Information        Optional

   Note 1: Only mandatory for specific error codes.

Subsection 3.9.17 ASP Identifier
Delete the last paragraph (it is an incorrect version of the paragraph
before it):
" The optional ASP Identifier parameter would contain a unique value that is
locally significant among the ASPs that support an AS. The SGP shall save
the ASP Identifier to be used, if necessary, with the Notify message (see
Section 3.3.3.2)."

Subsection 3.10 SUA-Specific parameters
Note that the parameter SSN used in SNM messages is the same as Subsystem
Number defined in subsection 3.10.2.5.
Note that in subsection 3.10.12 defining the User/Cause parameter, it is
named "Cause/User".
Subsection 3.10.12 Cause / User
Note that in messages using this parameter, and in subsection 3.10 listing
the SUA-Specific parameters, this is referred to as "User/Cause".
The value of the Length of the User/Cause parameter should be 8.

Old text:
      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 = 0x010c          |             Length = 32       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Cause             |            User               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

New text:
      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 = 0x010c          |             Length = 8        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Cause             |            User               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Subsection 3.10.13 Network Appearance
The value of the Length of the Network Appearance parameter should be 8.

Old text:
      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 = 0x010D          |             Length = 32       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Network Appearance                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

New text:
      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 = 0x010D          |             Length = 8        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Network Appearance                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Subsection 3.10.22 Sequence Control
Replace the reference with ITU Q.711 section 6.2.2.2.2.

Old text:
   Sequence Control (1.1.2/Q.714)

   The field is coded with the value of the sequence control parameter
   associated with a group of messages and are chosen so as to ensure
   proper loadsharing of message groups over SLS values while ensuring
   that sequence control values within message groups have the sequence
   control value coded with the same value as the initial message of
   the message group.

New text:
   Sequence Control (6.2.2.2.2/Q.711)

   The field is coded with the value of the sequence control parameter
   associated with a group of messages and are chosen so as to ensure
   proper loadsharing of message groups over SLS values while ensuring
   that sequence control values within message groups have the sequence
   control value coded with the same value as the initial message of
   the message group.

Subsection 4.2 Receipt of Primitives from the Layer Management
NOTE:   Third paragraph, the ASP (not the SGP) or IPSP initiate the
establishment of the SCTP association.

Old text:
   When an SCTP association has been successfully established, the SCTP
   will send an SCTP-COMMUNICATION_UP notification primitive to the
   local SUA layer.  At the SGP or IPSP that initiated the request, the
   SUA layer will send an M-SCTP_ESTABLISH confirm primitive to Layer
   Management when the association setup is complete.  At the peer SUA
   layer, an M-SCTP_ESTABLISH indication primitive is sent to Layer
   Management upon successful completion of an incoming SCTP association
   setup.

New text:

   When an SCTP association has been successfully established, the SCTP
   will send an SCTP-COMMUNICATION_UP notification primitive to the
   local SUA layer.  At the ASP or IPSP that initiated the request, the
   SUA layer will send an M-SCTP_ESTABLISH confirm primitive to Layer
   Management when the association setup is complete.  At the peer SUA
   layer, an M-SCTP_ESTABLISH indication primitive is sent to Layer
   Management upon successful completion of an incoming SCTP association
   setup.

Subsection 4.3.4.2 ASP Down Procedures
In the first paragraph, replace "DATA" with "Connectionless or Connection -
Oriented".
Replace "SSNM" with "SNM".

Old text:
   The ASP will send an ASP Down message to an SGP when the ASP wishes
   to be removed from service in all Application Servers that it is a
   member and no longer receive any DATA, SSNM or ASPTM 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 SUA
   management function.

New text:
   The ASP will send an ASP Down message to an SGP when the ASP wishes
   to be removed from service in all Application Servers that it is a
   member and no longer receive any Connectionless or
   Connection - Oriented, SNM or ASPTM 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 SUA
   management function.

Subsection 4.5.1 At an SGP
Replace "SSNM" with "SNM" in the first paragraph.

Old text:
   On receiving a N-STATE, N-PCSTATE and N-INFORM indication primitive
   from the nodal inter-working function at an SGP, the SGP SUA layer
   will send a corresponding SS7 Signalling Network Management (SSNM)
   DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the SUA peers
   at concerned ASPs.  The SUA layer must fill in various fields of the
   SSNM messages consistently with the information received in the
   primitives.

New text:
   On receiving a N-STATE, N-PCSTATE and N-INFORM indication primitive
   from the nodal inter-working function at an SGP, the SGP SUA layer
   will send a corresponding SS7 Signalling Network Management (SNM)
   DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the SUA peers
   at concerned ASPs.  The SUA layer must fill in various fields of the
   SNM messages consistently with the information received in the
   primitives.

The following paragraphs are inconsistent in SCTP stream useage:

   DUNA, DAVA, SCON, and DRST messages are sent sequentially and
   processed at the receiver in the order sent.  SCTP stream 0 **SHOULD
   NOT** be used. The Unordered bit in the SCTP DATA chunk MAY be used for
   the SCON message.

   Sequencing is not required for the DUPU or DAUD messages, which MAY
   be sent un-sequenced.  **Again, SCTP stream 0 is used**, with optional
   use of the Unordered bit in the SCTP DATA chunk.

I think the new text of the first of these paras should be:

   DUNA, DAVA, SCON, and DRST messages are sent sequentially and
   processed at the receiver in the order sent.  SCTP stream 0 SHOULD
   be used. The Unordered bit in the SCTP DATA chunk MAY be used for
   the SCON message.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Jan 2003 09:09:35 -0700

Richard,

Richard Adams wrote:                                                               (Tue, 21 Jan 2003 16:38:34)

--X---[snip]---X--

I don't think that we should replace references with 2001 specs.
Let's just put the correct date of the document under "References".

>    (LUDT). Sequence Control shall be set to 0 for class 0 messages.

It was intended to be mandatory for class 0 a well.  The SUA user should
set this value to a value that will ensure equal loadsharing.

>            included, the DUNA message corresponds to the SCCP

It could contain mutliple affected point code parameters.

>             contains in the Affected Point Code parameter just one point

It could be multiple.

>    from Layer Management or MAY be initiated automatically by an SUA

SSNM is correct.

>    SNM messages consistently with the information received in the
SSNM is correct.

>    be used. The Unordered bit in the SCTP DATA chunk MAY be used for

DUNA, DAVA, SCON and DRST - not on stream 0
DUPU, DAUD - use stream 0

There is no inconsistency.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/