Subject: Re: [SUA Issue 26] N-COORD Primitive

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Sep 2001 16:41:35 -0500

John,

Given that DRST really has no N-STATE primitivie equivalent,
it may be possible to use DRST for N-COORD when an SMI/SSN
is in the Destination Address message.  This would require
no additional messages or parameters.  (We would need a
change to the Note for DRST to change N-STATE to N-COORD
and perhaps some description in section 4.)  If the SMI/SSN
version of the subsystem described in 3.9.11 is used as a
subparm in 3.9.2.5 (i.e, adding optional SMI coding to SSN in
3.9.2.5 at least for SNMM), then we could be done.

The only text needed could be a single paragraph for section
4.

I think this might have the most minimal impact on the existing
draft: DRST N-STATE is not used anyway and no message/parameter
additions will be required.

Comments?

If this is generally acceptable, I will supply text.

--brian

On Fri, 31 Aug 2001, John Loughney wrote:

> Hi all,
> 
> This issue seems not to have much support at the moment.
> 
> I am looking forward to Brian's proposal for additional 
> functionality.  
> 
> Any comments on this issue would be helpful.
> 
> John
> 
> > -----Original Message-----
> > From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: 30 August, 2001 00:19
> > To: sigtran
> > Subject: Re: [SUA Issue 26] N-COORD Primitive
> > 
> > 
> > John,
> > 
> > I'm not joking.  The reason for carrying it forward is the same
> > reason for carring other parameters forward: transparent transport
> > of SCCP.
> > 
> > It is certainly not within the scope of SUA to question the very
> > protocol that it claims to transport with full transparency.
> > 
> > SUA must either drop its full transparency claims and list
> > restrictions (pointless if all that is required is a parameter
> > definition), or provide definitions for the transport of parameters
> > which may appear useless to some but which have not yet been removed
> > from SS7 specifications.
> > 
> > Existing SCCP application written to use SMI should be able to be
> > ported to an SUA implementation with minimal modification.  It is
> > easier to define an SMI parameter in SUA than to otherwise ensure
> > and describe how these applications are to be ported transparently
> > without an SUA SMI parameter.
> > 
> > --brian
> > 
> > John Schantz wrote: (Wed, 29 Aug 2001 07:59:53)
> > >
> > > Your joking about SMI (Subsystem Multiplicity Indicator), 
> > right?  It has
> > > very little meaning and use today.  Why carry it forward?
> > > 
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to 
> > [email-masked]
> > 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: [email-masked]
Date: Thu, 6 Sep 2001 08:55:45 +0300

Brian,

> If this is generally acceptable, I will supply text.

Currently 3.9.2.5 looks like this:

3.10.2.5 Subsystem Number

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 = 0x8003          |            Length = 8         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Reserved	            |   SSN value   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Would you prefer it to be this:

3.10.2.5 Subsystem Number

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 = 0x8003          |            Length = 8         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             SMI               |    Reserved   |      SSN      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Subsystem Number (SSN) is one octet.

Subsystem Multiplicity Indicator (SMI) can have the following values:

0x00		Reserved
0x01		Replicated
0x02		Solitary
0x03		Unknown

Is this OK?  (or should I just make SMI 1 octect from bits 16 to 23)
If so, I await the text for the usage text.

thanks,
John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Sep 2001 05:15:02 -0500

John,

Perhaps you could answer a couple of questions first:

  3.9.2.2 Address Indicator: What is the purpose of this field?
  I can't think what it could possibly be used for...
  If the ASP doesn't want SSN, PC or GT included, why put
  the subfield in the address?

  DUNA/DAVA/DAUD/SCON/DRST:  Why is the complete Destination
  Address format placed in these messages?  Routing Indicator
  is meaningless, Address Indicator is meaningless, PC and
  SSN are the only subparameters which are useful and GT is
  useless.  Why not just place Affected PC (common UA
  parameter) and SMI/SSN in the messages (not a subparms)
  instead of Destination Address?  This would make the coding
  of affected PC/SSN far less awkward and would also be consistent
  with M3UA's use of these messages.

  Like this:

    3.x.x Destination Unavailable (DUNA)

    ...

    The format for the DUNA Message 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 = 0x0006         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                       Routing Context                         /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x0005         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Affected Point Code                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x010C         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        SMI / Subsystem                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x0004         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                          Info String                          /

    \                                                               \

    Parameters
      Routing Context               Optional
      Affected Point Code           Mandatory
      SMI/Subsystem                 Optional   *1
      Info String                   Optional

    Note 1:    When the SMI/Subsystem is included, the DUNA message
	       corresponds to the SCCP N-STATE primitive.  When
	       SMI/Sybsystem is not included, the DUNA message
	       corresponds to the SCCP N-PCSTATE primitive.

  And the same for DAVA, SCON, DAUD...

  Then we have:

    3.x.x Destination Restricted (DRST)

    ...

    The format for the DRST Message 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 = 0x0006         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                       Routing Context                         /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x0005         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Affected Point Code                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x010C         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        SMI / Subsystem                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x0004         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                          Info String                          /

    \                                                               \

    Parameters
      Routing Context               Optional
      Affected Point Code           Mandatory
      SMI/Subsystem                 Optional   *1
      Info String                   Optional

    Note 1:    When SMI/Sybsystem is not included, the DRST message
	       corresponds to the SCCP N-PCSTATE primitive.  When the
	       SMI/Subsystem is included, the DRST message corresponds
	       to the SCCP N-COORD primitive.  If SMI is coded to 0,
	       DRST corresponds to the request or response forms of
	       the N-COORD primitive; otherwise, the DRST corresponds
	       to the indication and confirm froms of the N-COORD
	       primitive.

  Why is there no DUPU?  DUPU is required to provide Remote SCCP
  status per Q.711 clause 6.3.2.2.6.  See also clause 6.3.2.3.3
  where the N-PCSTATE resulting from an MTP-STATUS reporting user
  part unavailability is required.

  We need:

    3.x.x Destination User Part Unavailable (DUPU)

    ...

    The format for the DUPU Message is a 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 = 0x0006         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                       Routing Context                         /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x0005         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Affected Point Code                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x????         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          User/Cause                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x0004         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                          Info String                          /

    \                                                               \

    Parameters
      Routing Context               Optional
      Affected Point Code           Mandatory
      User/Cause                    Mandatory
      Info String                   Optional

    and

    3.x.x.x User / Cause

     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 = 0x????         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Cause             |             User              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The User field is a 16-bit field which contains the MTP User
    identity of the remote SCCP.  This field is here for compatibility
    with M3UA and MAY be ignored.

    Cause is a 16-bit field which provides the reason for the
    unavailability of the remote SCCP.  The valid values for the Cause
    parameter are as follows:

             0         Unknown
	     1         Unequipped Remote SCCP
	     2         Inaccessible Remote SCCP

Given these changes to DUNA/DAVA/DAUD/SCON/DRST and addition of DUPU,
then full N-PCSTATE and N-COORD primitives will be supportable using
these messages.

Make a few additions to Section 1.4.4:

  1.4.4 Interworking with SCCP Network Management Functions

    SUA uses the existing ASP management messages for ASP status
    handling.  The interworking with SCCP management messages consists
    of DUNA, DAVA, DAUD, DRST, DUPU or SCON messages on receipt of SSP,
    SSA, SST or SSC to the appropriate ASPs.  See also chapter 1.4.5.
    The primitives below are considered to be send between the SCCP and
    SUA management functions in the SG to trigger events in the IP and
    SS7 domain.

    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 |Request    |ITU-Q.711   Chap 6.3.2.3.3 (Tab 15/Q.711)
              |Indication |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    |
    ----------+-----------+---------------------------------------------

In section 3.1.3 add DUPU.
In section 4.1.3 add DUPU.

And that will just about do it.

--brian

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

---

---

From: [email-masked]
Date: Thu, 6 Sep 2001 14:49:05 +0300

Hi Brian,

>   the subfield in the address?

There was a discussion on this a while ago, I'll try to dig
up the thread.
 
>   with M3UA's use of these messages.

There was some discussion of using the above in the all-IP
case.  In such a case, there may not be a PC.

>   part unavailability is required.

There was a discussion that DUPU was not needed, I will dig up
the thread.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Sep 2001 07:02:41 -0500

John,

> There was a discussion on this a while ago, I'll try to dig

I would be very interested to see if there is a reason.

> case.  In such a case, there may not be a PC.

There is no N-PCSTATE primitive with an IP address in Q.711.
Which protocol specification requires an IP address?

> There was a discussion that DUPU was not needed, I will dig up

Read clause 6.3.2.3.3.  It is required to communicate the "Remote SCCP
status", e.g, when the remote SCCP is unequipped.  It is there in the
spec and not supported in any other message.

--brian

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

---

---

From: [email-masked]
Date: Tue, 11 Sep 2001 10:31:55 +0300

Hi all,

> > additions will be required.

I await his text.

Additionally, subsystem number parameter will be changed to:

> |        Reserved               |      SMI      |      SSN      |

And DUPU needs to be included as well.

best regards,
John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 03:15:31 -0500

John,

John Loughney wrote:                                         (Tue, 11 Sep 2001 10:31:55)
> > > additions will be required.

I provided text two notes ago on this thread. (Sep 6 05:15)

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

---

---

From: [email-masked]
Date: Tue, 11 Sep 2001 11:20:08 +0300

Hi Brian,

-clip-
> > > > The only text needed could be a single paragraph for section

-clip-

> I provided text two notes ago on this thread. (Sep 6 05:15)

-clip-

I'm updating the messages in chapter 3.

The note you refered to had text for was for:

Is that sufficient for you?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 03:47:00 -0500

John,

John Loughney wrote:                                         (Tue, 11 Sep 2001 11:20:08)
> Is that sufficient for you?

 Change:

    4.1.3 SS7 Signalling Network Manageemnt Procedures

    When an SCCP Subsystem Management (SCMG) message is received from
    the SS7 network, the SGP needs to determine whether there are
    concerned Application Servers interested in subsystem status
    changes.  The SUA management function is informed with N-State
    indication primitive upon which it formats and transfers the
    applicable SNM message to the list of concerned ASPs using stream ID
    "0".

 To:

    4.1.3 SS7 Signalling Network Manageemnt Procedures

    When an SCCP Subsystem Management (SCMG) message is received from
    the SS7 network, the SGP needs to determine whether there are
    concerned Application Servers interested in subsystem status
    changes.  The SUA management function is informed with the N-State
 |  or N-Coord primitive upon which it formats and transfers the
 |  applicable SNMM message to the list of concerned ASPs using stream ID
    "0".

--brian

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

---

---

From: [email-masked]
Date: Tue, 11 Sep 2001 12:56:57 +0300

Hi Brian,

> > And DUPU needs to be included as well.

DUPU in M3UA v8 contains:

    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 = 0x0204          |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Cause             |            User               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

User/Cause: 32-bits

   The Unavailability Cause and MTP3-User Identity fields, associated 
   with the Affected DPC in the Affected Destinations parameter, are 
   encoded as follows:

Unavailability Cause field: 16-bits (unsigned integer)

   The Unavailability Cause parameter provides the reason for the 
   unavailability of the MTP3-User.  The valid values for the 
   Unavailability Cause parameter are shown in the following table. 
   The values agree with those provided in the SS7 MTP3 User Part 
   Unavailable message.  Depending on the MTP3 protocol used in the 
   Network Appearance, additional values may be used - the 
   specification of the relevant MTP3 protocol variant/version 
   recommendation is definitive.

         0         Unknown
         1         Unequipped Remote User
         2         Inaccessible Remote User 

This cannot be directly used for SUA, for example from Q711:

6.3.2.2.2	User status

The parameter "user status" is used to inform a SCCP user of the status of
the affected subsystem.

"User status" may assume one of the following values:
-	User-in-service (UIS);
-	User-out-of-service (UOS).

6.3.2.2.5	Signalling point status

The parameter "signalling point status" is used to inform a user of the
status of an affected signalling point.

"Signalling point status" may assume the following values:

-	signalling point inaccessible;
-	signalling point congested;
-	signalling point accessible.

6.3.2.2.6	Remote SCCP status

The parameter "remote SCCP status" is used to inform a user of the status of
a remote SCCP.

"Remote SCCP status" may assume the following values:
-	remote SCCP available;
-	remote SCCP unavailable, reason unknown;
-	remote SCCP unequipped;
-	remote SCCP inaccessible;
-	remote SCCP congested.

My proposal would be to use:

3.10.6 SCCP Cause

    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 = 0x0106          |             Length = 8        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 	       Reserved              |   Cause Type  |  Cause Value  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This parameter bundles the SCCP parameters Release cause, Return cause,
Reset cause, Error cause and Refusal cause.

	Cause Type can have the following values:

	Return Cause		0x1
	Refusal Cause		0x2
	Release Cause		0x3
	Reset Cause			0x4
	Error Cause			0x5
>	User Status			0x6
>	Signaling Point Status	0x7
>	Remote SCCP Status	0x8
>	Restricted Importance level 0x9

and the values as given in q711

Comments?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 06:28:30 -0500

John,

John Loughney wrote:                                         (Tue, 11 Sep 2001 12:56:57)
[snip]
> > > And DUPU needs to be included as well.
[snip]
> This cannot be directly used for SUA, for example from Q711:

It can.

	0	Unknown
	1	Unequipped Remote User
> -	remote SCCP congested.

Inserted above is the mapping.  Note that remote SCCP available and
remote SCCP congested cannot be signalled from MTP UFC, the remainder
are directly from UPU.

> My proposal would be to use:

Above is already signalled by DUNA/DAVA/SCON (N-STATE).

> >	Signaling Point Status	0x7

Above is already signalled by DUNA/DAVA/SCON (N-PCSTATE).

> >	Remote SCCP Status	0x8

Above is what is proposed to be addressed by DUPU.

> and the values as given in q711

Section 6.3.2.2 does not give values for these as they
are N-Primitive arguments.

> Comments?

Go with the DUPU.

--brian

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

---

---

From: [email-masked]
Date: Tue, 11 Sep 2001 14:58:29 +0300

Brian,

What I am suggesting is that this parameter from M3UA v8 may not
be ideal:

As SUA does not need to concern itself about the 'user' - SCCP 
is implied.

> > 3.10.6 SCCP Cause

To have a new cause type:

	Remote Status			0x5

> 	2	Inaccessible Remote User

So DUPU in SUA would look like this:

The format for DUPU 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 = 0x0006          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Routing Context                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0103          |            Length             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   /                     Destination Address                       / 
   \                                                               \ 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |         Tag = 0x0106          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           SCCP Cause                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0004          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                          INFO String                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Does that work for you?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 13:07:27 -0500

John,

The "User" can be coded to that SCCP's SI value.  There can
be several SCCP's at a given point code, each with different
SI values, although normally there is only one with SI=3.
The parameter is appropriate because this is precisely what
SCCP gets from MTP.

--brian

John Loughney wrote:                                         (Tue, 11 Sep 2001 14:58:29)

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

---

---

From: [email-masked]
Date: Thu, 13 Sep 2001 10:04:55 +0300

Brian,

So, what would this work for you:

3.10.12 Cause / User

   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               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"User" is coded to that SCCP's SI value.  There may be several SCCP's at a
given point code, each with different SI values, although normally there is
only one with SI = 3.

Cause may take the following values

 	0	remote SCCP unavailable, reason unknown;
	1	remote SCCP unequipped;
 	2	remote SCCP inaccessible;
      3	remote SCCP congested.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Sep 2001 02:52:45 -0500

John,

John Loughney wrote:                                         (Thu, 13 Sep 2001 10:04:55)
> So, what would this work for you:
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Where does this last one come from?  The first three can be generated
at the SG by a received UPU.  What SS7 message causes the last condition?
There are no UFC congestion messages in MTP, are there?  (See Q.704/15.17.5)
Strike the "remote SCCP congested".

Then it will be perfectly consistent with M3UA (and MTP UPU), even in the
values of the causes, as it should be as this derives from UPU as does M3UA
DUPU.

--brian

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

---

---

From: [email-masked]
Date: Thu, 13 Sep 2001 11:36:13 +0300

Brian,

> There are no UFC congestion messages in MTP, are there?  (See 
> Q.704/15.17.5) Strike the "remote SCCP congested".

I shall.  This was 'hanging' on a mail that you sent, which I
didn't quite see why you were proposing it - but it must
have been a cut 'n paste error.

John

---

---

From: [email-masked]
Date: Tue, 18 Sep 2001 13:22:14 +0300

Brian,

>  |  applicable SNMM message to the list of concerned ASPs 

Done.

John

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 18 Sep 2001 15:42:05 +0200

Brian,

First to answer some of your questions turning up in this thread :

1) DUPU ("User Part Unavailability") :

In case of SUA, it is clear the remote SS7 SCCP status is meant, which can
be signalled via DUNA (SSN = 1). And where did you get the idea "multiple
SCCP's, with different SI values" may exist at a given point code ? First of
all, the UPU procedures are not considered all that useful in any given SS7
network at the moment, let alone a UPU for each "SCCP instance" at a certain
point code.

Besides, when RC is included in the SNMM messages (also DUNA), there's no
need at all for a, in my opinion, totally superfluous DUPU message in SUA,
nor perhaps M3UA for that matter.

2) SSN parameter :

Agreed to have a 0x010C (I believe that's the tag) combined SMI/SSN
parameter in SNMM messages instead of SSN only. However, John please keep
the address parameter SSN (0x8003) as it was (just SSN).

3) Address parameter in SNMM : 
Agreed to delete it. I guess working with RC, Affected DPC and SMI/SSN
parameters is sufficient, also considering the all-IP case.

4) Definition of DRN and SRN in SUA :
Brian, in SS7 there is already a problem with a size 24 bit (too small), so
please let's use the full field here. In decoupled approach for CO, we can
make a note the MSB must be coded zero.

5) Use of Address Indicator :
Since we are transporting the SCCP-user messages, not the SCCP msg or MTP
primitive itself, we need information whether the SPC/SSN fields of the SCCP
addresses must be populated. E.g. the DPC must be present in the SUA
destination address (the RC might span several DPCs) otherwise the SG cannot
identify the SEP (assumed route on DPC+SSN). However, in the SCCP called
party address, it is not needed to encode the SPC field, since the DPC is
already populated into the routing label.

Finally some words/questions on the N-COORD procedures :

The example architecture was 2 SGs acting as SEPs (SCPs for AIN), where the
application was actually on an ASP. Basically, we still need a means to
indicate request and permission to go out of service in the ASPTM
procedures. Has this been covered already somewhere ? The SGs can continue
to use SOR/SOG between each other (if they're only connected via SS7).

Or was there a proposal for 2 new SNMM messages ?

Regards,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 11 september 2001 20:07
To: sigtran
Subject: Re: [SUA Issue 26] N-COORD Primitive
Importance: High

John,

--brian

John Loughney wrote:                                         (Tue, 11 Sep
2001 14:58:29)

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 18 Sep 2001 12:51:34 -0500

Verwimp,

Verwimp Gery wrote:                                       (Tue, 18 Sep 2001 15:42:05)
> nor perhaps M3UA for that matter.

DUNA (SSN = 1) cannot distinguish "unequipped" which is a permanent condition,
from "inaccessible" which is a transient condition.  Thus the SCCP Cause is
required.  DUPU is a normal and natural place to put this.

> the address parameter SSN (0x8003) as it was (just SSN).

N-COORD (DRST) needs to distinguish between request, indication, response
and confirmation primitives.  The only distinction is the presence or absence
of the SMI parameter.  If it stays coupled to SSN (which is mandatory) then
it needs a "not-specified" coding other than 0.

> parameters is sufficient, also considering the all-IP case.

Ok.

> make a note the MSB must be coded zero.

Ok.

> already populated into the routing label.

So?  That still does not tell me when to use Address Indicator or why?
Could you provide some rules (text) for its use?

> to use SOR/SOG between each other (if they're only connected via SS7).

The SOR/SOG refers to subsystem out of service, not point code unavailability.
The ASP always has the ability to withdraw from service: ASPIA.

> Or was there a proposal for 2 new SNMM messages ?

Huh?

--brian

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

---

---

From: [email-masked]
Date: Wed, 19 Sep 2001 10:05:50 +0300

Gery, 

Some comments:

> parameter in SNMM messages instead of SSN only. However, John 
> please keep the address parameter SSN (0x8003) as it was (just SSN).

It is.

> parameters is sufficient, also considering the all-IP case.

Text added to the SNM messages:

Valid Destination Address parameters are Affected Point Code & SSN.   

John

---

---

From: [email-masked]
Date: Wed, 19 Sep 2001 10:11:28 +0300

Brian,

> N-COORD (DRST) needs to distinguish between request, 
> indication, response and confirmation primitives.  The 
> only distinction is the presence or absence
> of the SMI parameter.  If it stays coupled to SSN (which is 
> mandatory) then it needs a "not-specified" coding other than 0.

How does this work for you:

0x00		Reserved
0x01		Replicated
0x02		Solitary
0x03		Unknown
0x04		Unspecified

John

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 19 Sep 2001 09:32:30 +0200

Brian,

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 18 september 2001 19:52
To: sigtran
Subject: Re: [SUA Issue 26] N-COORD Primitive

Verwimp,

Verwimp Gery wrote:                                       (Tue, 18 Sep 2001
15:42:05)
> nor perhaps M3UA for that matter.

DUNA (SSN = 1) cannot distinguish "unequipped" which is a permanent
condition,
from "inaccessible" which is a transient condition.  Thus the SCCP Cause is
required.  DUPU is a normal and natural place to put this.

[GV] : "Cause" would then be a good parameter for DUNA (also SSN <> 1),
don't you agree ?

N-COORD (DRST) needs to distinguish between request, indication, response
and confirmation primitives.  The only distinction is the presence or
absence
of the SMI parameter.  If it stays coupled to SSN (which is mandatory) then
it needs a "not-specified" coding other than 0.

[GV] : I don't see a problem since there's 2 different contexts (2 different
tags) anyway. Just to prevent any misunderstanding : no SMI in address
parameter SSN (0x8003), separate parameter (0x010C) SMI/SSN for SNMM.

Ok.

Ok.

[GV] : The rules are already there, in relation with the Routing Indicator.
Anything unclear about them ?

> to use SOR/SOG between each other (if they're only connected via SS7).

The SOR/SOG refers to subsystem out of service, not point code
unavailability.
The ASP always has the ability to withdraw from service: ASPIA.

[GV] : The RC (==> SSN) of ASPIA would specify for which traffic portion the
ASP wants to go out of service. Only ASP down is for the entire ASP.

Huh?

[GV] : Guess I have to dig through your DRST proposal with use of SMI
indicating "replicated" ...

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 02:58:02 -0500

John,

John Loughney wrote:                                  (Wed, 19 Sep 2001 10:05:50)
> Valid Destination Address parameters are Affected Point Code & SSN.   

At least APC MUST be present.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 03:00:54 -0500

John,

John Loughney wrote:                                  (Wed, 19 Sep 2001 10:11:28)
> Subsystem Multiplicity Indicator (SMI) can have the following values:

SMI actually indicates the number of replications of the subsystem.

I suggest:

0x00	    Reserved/Unknown
0x01	    Solitary
0x02	    Duplicated
0x03	    Triplicated
0x04	    Quadruplicated
...	    ...
0xff	    Unspecified

--brian

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

---

---

From: [email-masked]
Date: Wed, 19 Sep 2001 11:05:40 +0300

Hi Brian,

> SMI actually indicates the number of replications of the subsystem.

Works for me.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 03:34:41 -0500

Gery,

Verwimp Gery wrote:                                (Wed, 19 Sep 2001 09:32:30)
> [GV]: "Cause" would then be a good parameter for DUNA (also SSN <> 1),
> don't you agree ?

No, I would prefer that User/Cause be used with DUPU consistent with M3UA,
rather than trying to overload DUNA further.

> [GV]: I don't see a problem since there's 2 different contexts (2 different

That could work, but should have text to support it.

> [GV]: The rules are already there, in relation with the Routing Indicator.

There are no rules.  Do you call the following rules?
    
| 3.9.2.2 Address Indicator 
|  
|    This parameter is needed for interworking with SS7 networks. The 
|    address indicator specifies what address parameters are actually 
|    received in the SCCP address from the SS7 network, or are to be 
|    populated in the SCCP address when the message is sent into the SS7 
|    network. The value of the routing indicator needs to be taken into 
|    account. 
|     
|    The address indicator is coded as follows: 
|     
|     Bit 1 is used to indicate inclusion of the SSN 
|     
|     0         Do not include SSN when optional 
|      1         Include SSN 
|     
|      Bit 2 is used to indicate inclusion of the PC 
|     
|     0         Do not include PC, regardless of the routing indicator 
|               value 
|      1        Include PC 
|     
|     Bit 3 is used to indicate inclusion of the Global Title 
|     
|     0         Do not include GT when optional (routing indicator /= 1) 
|      1        Include GT 
|     
|    Bits 4-8 are spare and should be coded zero. 

When address parameters are not to be included in sent SCCP messages,
don't place them in the SUA address!  When address parameters were not
included in received SCCP messages, they cannot be included in SUA
addresses anyways!

Remove the Address Indicator.  It does nothing.

> > The example architecture was 2 SGs acting as SEPs (SCPs for AIN), where
> > the application was actually on an ASP. Basically, we still need a means
> > to indicate request and permission to go out of service in the ASPTM
> [GV]: The RC (==> SSN) of ASPIA would specify for which traffic portion the

ASP down is TFP or UPU or SSP or no address translation transient.  So
is ASPIA.  ASP down has the effect of rendering all the active RCs inactive
for the given ASP.  If the ASP wants SOR/SOG from its mate, it simply uses
the DRST procedures.

> [GV]: Guess I have to dig through your DRST proposal with use of SMI

Dig away..

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 03:37:43 -0500

John,

Gery had another suggestion: use the non-SMI version of SSN when
SMI is not included.  That is a more definitive way of including
or excluding SMI and I prefer Gery's approach.  When SMI is included
use the SMI/SSN form of the parameter, when it is not, use the
SSN-only form of the parameter.

The note on DRST can then just talk to whether the SMI is "present"
or not.

--brian

John Loughney wrote:                                  (Wed, 19 Sep 2001 11:05:40)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: [email-masked]
Date: Wed, 19 Sep 2001 11:43:03 +0300

Hi Brian,

> The note on DRST can then just talk to whether the SMI is "present"

Currently, I have SUA edited so there is only one SSN parameter.
This parameter contains both the SMI field and the SSN field.

Do you suggest that SUA should have 2 parameters?

	1) SSN only
	2) SMI/SNN

I'm not sure what this gains you.  Generally, I like reducing the
number of parameters in a protocol.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 03:50:09 -0500

John,

John Loughney wrote:                                  (Wed, 19 Sep 2001 11:43:03)
> number of parameters in a protocol.

SUA-07 had two parameters.  On the basis of what consensus was one
removed?  While your making changes, I would prefer seeing:

	1) SSN only
	2) SMI only

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 19 Sep 2001 12:04:22 +0200

Brian,

[snip, snip]

[GV2] : SNMM messages in SUA are extended with the SMI/SSN parameter, and
deal with both PC_ (without SSN) and N_state (with SSN, subsystem
management) indications. Unfortunately, M3UA has DUPU for it's users; it
could well have SI included in DUNA, DAVA too ... This would have been a
nicer consistency, but that's just a matter of taste I guess.

[GV2] : Restoration of the previously deleted SMI/SSN parameter. Must be in
one of the earlier editions.

[GV2] : Yes.

[GV2] : Quite the contrary. E.g. if you don't put the DPC in the SUA
destination address, and it isn't obvious from the RC, the SG is at a loss
where to send the message to. You have no option but to populate the PC
field. Now, this doesn't mean the SG must put it in the called party address
as well (some operators even don't want it there), and this is what the AI
specifies.

Another example : the SG-SCCP receives no PC in the calling party address,
but has the OPC from the routing label. Now, in order to route back, it has
to populate the PC field in the source address with this OPC. However, it is
interesting for the SCCP-user on the ASP to know whether a PC was present in
the received SCCP address, or that it was populated from the OPC field
(distinction between originating node or last SCCP relay node where GTT
occurred).

Same for GT, when e.g. final GTT would already occur at the SG and there's
no use to transport it further.

Hope these examples clarify the use of AI.
[endGV2]

-Gery

---

---

From: [email-masked]
Date: Wed, 19 Sep 2001 12:44:07 +0300

Brian,

> removed?  

In SUA 07, it was removed because it was not used in any messages.
Additionally, attached mail from you seemed to indicate adding SMI
as a optional parameter was OK.
 
John

===========================

From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: [SUA Issue 26] N-COORD Primitive
Date: Thu, 6 Sep 2001 00:41:35 +0300 
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
List-Unsubscribe: <mailto:[email-masked]>
content-class: urn:content-classes:message
x-mimeole: Produced By Microsoft Exchange V6.0.4712.0
Content-Type: text/plain;
	charset="iso-8859-1"

John,

Comments?

--brian

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 05:41:42 -0500

John,

SUA 07 section 3.9.11 has an SMI/SSN parameter.  I wasn't
suggesting removing it, I was suggesting using it because
it was there.  If we are removing and adding parameters,
a separate SMI parameter (only needed in SNMM) is preferrable
to pushing SMI into SSN.

--brian

John Loughney wrote:                          (Wed, 19 Sep 2001 12:44:07)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 05:38:54 -0500

Gery,

Verwimp Gery wrote:                              (Wed, 19 Sep 2001 12:04:22)
> [GV2]: SNMM messages in SUA are extended with the SMI/SSN parameter, and

Consistentcy with M3UA where possible is desirable.

[snip]
> [GV2]: Yes.
> [GV2]: Quite the contrary. E.g. if you don't put the DPC in the SUA

The SG uses SCCP routing rules to decide how to populate SCCP address
parameters just as it does for SCCP-Users today.  There is no address
indicator field in the SCCP-User primitives and the SG does not require
them to perform its function.  As such Address Indicator is still useless
in this case.

> (distinction between originating node or last SCCP relay node where GTT

The SCCP-User needs no such information.  All it needs is the PC of the
originator, it doesn't care whether it came in the SCCP CgPA or the
MTP OPC.  Address Indicator is useless in this case.

> no use to transport it further.

Whether GT is retained is an SCCP routing function and not at the
disposal of, or of concern to, the SCCP-User.

> Hope these examples clarify the use of AI.

Quite frankly they do not.  In none of the circumstances that you describe
is it necessary for the SG to make use of this parameter.  SCCP-Users are
not provided with this control over the SCCP routing function and the SCCP
routing function performs these manipulations without the SCCP-User needing
to specify anything in this regard.

I'm afraid you'll have to come up with a case which is not already handled
by the SCCP routing rules (which I doubt is possible because nothing like
Address Indicator is present in the SCCP-User primitive interface).

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 19 Sep 2001 13:10:16 +0200

Brian,

Well, everyone is entitled to his opinion. You mean to say SCCP has it's own
routing rules and doesn't care about the preferences of it's user ? If you
don't want it, overrule it with your routing rules. To make a point : the
rule to plain populate it in SCCP when it's present in the SUA message (as
you mentioned before) and vice versa doesn't work in the examples below.

BTW : the user interface doesn't mention "message priority" explicitly
either. Then why not remove it as well and let it up to the rules for SCCP
at the SG to populate it ?

So let's strike a compromise and let them both be there. If you want to make
AI optional that's ok for me.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 19 september 2001 12:39
To: sigtran
Subject: Re: [SUA Issue 26] N-COORD Primitive

Gery,

[snip]

--brian

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

---

---

---

From: [email-masked]
Date: Wed, 19 Sep 2001 15:37:03 +0300

Brian,

> a separate SMI parameter (only needed in SNMM) is preferrable

For the SNM messages, is only SMI needed or is SMI & SSN needed?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 11:54:55 -0500

John,

SMI is needed sometimes (optional) in SNMM.  SSN is needed
sometimes (optional) in SNMM.  They are needed at different
times.

--brian

John Loughney wrote:                                         (Wed, 19 Sep 2001 15:37:03)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Sep 2001 11:52:55 -0500

Gery,

Verwimp Gery wrote:                                       (Wed, 19 Sep 2001 13:10:16)
> routing rules and doesn't care about the preferences of it's user ?

Yes.  In the same way that UDP users don't need to specify the next-hop
address, just the destination address.

> If you don't want it, overrule it with your routing rules.

It would be a matter of overriding to use AI: overriding the standardized
SCCP routing procedures.

> To make a point : the rule to plain populate it in SCCP when it's present in
> the SUA message (as you mentioned before) and vice versa doesn't work in the
> examples below.
> 
> BTW: the user interface doesn't mention "message priority" explicitly

MP bits are part of SIO which is explicitly part of the MTP-User primitive
interface.

> AI optional that's ok for me.

Remove it.  It is unnecessary cruft.

--brian

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

---

---

From: [email-masked]
Date: Thu, 20 Sep 2001 09:47:30 +0300

Hi Brian,

> sometimes (optional) in SNMM.  They are needed at different

OK - I shall add SMI as a seperate & optional parameter in
SNM messages.  The SNN will not contain SMI.

SMI looks like this:

3.10.24 SMI

   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 = 0x0118          |            Length = 8         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Reserved                  |       SMI      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0x00	    Reserved/Unknown
0x01	    Solitary
0x02	    Duplicated
0x03	    Triplicated
0x04	    Quadruplicated
...	    ...
0xff	    Unspecified

SNN looks like this:

0                   1                   2                   3

The internationally standardized SSN values are described in chapter 3.4.2.2
of Q.713.

DUNA (as an example of the SNM messages) looks like this:

The format for DUNA Message parameters is as follows:

    0                   1                   2                   3
   |         Tag = 0x0118          |            Length             |
   |                              SMI                              |

Parameters
	Routing Context			Optional
	Destination Address		Mandatory *1
	SMI					Optional
	Info String 			Optional

Note 1:	The destination address refers to the node that has become
unavailable.  The Destination Address parameters MUST include the Affected
Point Code and MAY include the SSN.  When the SSN is included in the
Destination Address parameter, the DUNA message corresponds to the SCCP
N-STATE primitive. When SSN is not included in the Destination Address
parameter, the DUNA message corresponds to the SCCP N-PCSTATE primitive.  

Let me know if there are any holes left in this.

br,
John

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 20 Sep 2001 08:58:03 +0200

Last one for me on this issue.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 19 september 2001 18:53
To: sigtran
Subject: Re: [SUA Issue 26] N-COORD Primitive

Gery,

Verwimp Gery wrote:                                       (Wed, 19 Sep 2001
13:10:16)

[GV] : According to these standards, everything is optional. You can even
send an empty address. Either SG or ASP should be able to have control.

[GV] : Correct. Not the SCCP-User interface.

[GV] : I think it's more useful information than MP. Using the ASP's MP
could also override SS7 rules. What's your problem with AI being optional ?

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Sep 2001 03:25:29 -0500

Gery,

Verwimp Gery wrote:                            (Thu, 20 Sep 2001 08:58:03)
[snip]
> > 
> > Well, everyone is entitled to his opinion. You mean to say SCCP has it's
> > own routing rules and doesn't care about the preferences of it's user ?
> 
> [GV]: According to these standards, everything is optional. You can even

SUA does not need control.  It is the SCCP at the SG which controls what
goes in the SCCP address parameter just as it does for SS7.  There is no
need for SUA to control this just as there is no need for the SCCP-User
to control this in SS7.

> 
> > To make a point : the rule to plain populate it in SCCP when it's present
> > in the SUA message (as you mentioned before) and vice versa doesn't work
> > in the examples below.
> > 
> [GV]: Correct. Not the SCCP-User interface.
>
The SCCP-User interface does not even define protocol class: it refers
to some QOS parms (which if you look at the NSD are throughput and
failure probabilities).  MP does derive from probability of message
transfer failures due to congestion just as protocol class does and
thus has as useful a place as protocol class does in the SUA message.
See Al Varney's comments on this matter.

> > So let's strike a compromise and let them both be there. If you want to
> > make AI optional that's ok for me.
> 
> [GV]: I think it's more useful information than MP. Using the ASP's MP could
> also override SS7 rules. What's your problem with AI being optional ?

My problem is there is no use for AI.  There is a use for MP and MP can be
considered as derived from SCCP-User QOS parms.  It is clear that the SCCP
can use MP to adjust message priorities when delivering messages to MTP.
SCCP has no need for AI: it is not even an SS7 parameter.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Sep 2001 03:31:45 -0500

John,

There is no need for the RI or AI of the Destination Address
parameter for SNMM.  Is there any reason not to just include
Affected Point Code as mandatory and SSN as optional instead
of Destination Address parameter?  Affected Point Code happens
to be a Common UA parameter...  This is more consistent with
M3UA as it only adds SSN and SMI to the message.  Such as:

	Parameters
	    Routing Context		Optional
	    Affected Point Code		Mandatory
	    Subsystem Number		Optional *1
	    SMI				Optional
	    Info String			Optional

That will get rid of the useless RI and AI fields and ease
the ASP's burden of checking for validity within the Destination
Address parameter different from other data messages.

--brian

John Loughney wrote:                        (Thu, 20 Sep 2001 09:47:30)

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

---

---

From: [email-masked]
Date: Thu, 20 Sep 2001 12:53:15 +0300

Gery,

It seems that Brian feels that Address Indicator is not 
needed. Could you provide a couple of bullet points on
why it is needed?  

Additionally, if there are others out there with an opinion,
please comment.

br,
John

3.9.2.2 Address Indicator 
  
   This parameter is needed for interworking with SS7 networks. The 
   address indicator specifies what address parameters are actually 
   received in the SCCP address from the SS7 network, or are to be 
   populated in the SCCP address when the message is sent into the SS7 
   network. The value of the routing indicator needs to be taken into 
   account. 

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 20 Sep 2001 12:42:41 +0200

Hi John,

Yes we're having a good old trench fight ;)

The primitive interface argument isn't going to get us anywhere. In ANSI,
there's a QOS parameter which is not further specified (you can attribute
anything you want to this one ...) and in ITU, only protocol class and
importance are stated.

Both MP and AI are SS7 parameters; I refer to the SCCP address indicator
byte : this contains

- routing indicator (1 bit)
- GT indicator (4 bits)
- SPC and SSN inclusion bits

My point is simple : the SG cannot under any circumstance know what is to be
populated. The mere absence or presence of the GT, SPC and/or SSN in the SUA
addresses is not always enough for the SG to know what to do (keeping in
mind SCCP routing rules). Of this, I've already given a number of examples,
but to give one more :

The ASP may not know the OPC of the SG (e.g. routing exclusively on GT), but
may want the SG to include it's point code in the SCCP calling party address
(e.g. backrouting UDTS in case of failure) before sending it to the SS7
network (STP/SEP).

I agree with having it as an optional parameter, not with it's removal.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 20 september 2001 11:53
To: sigtran
Subject: RE: [SUA Issue 26] N-COORD Primitive

Gery,

br,
John

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Sep 2001 05:55:42 -0500

Gery,

Verwimp Gery wrote:                              (Thu, 20 Sep 2001 12:42:41)
> byte: this contains

The SS7 AI and SUA AI are unrelated.  The SS7 AI includes the RI and GTI
and indicates if the SPC and SSN are *actually* in the address.  In SUA
this is accomplished with tags (the SPC and SSN are in the address if their
tags and values are present).

The SUA AI has no point or parallel.

> (e.g. backrouting UDTS in case of failure) before sending it to the SS7

There is no need for AI in your example: ASNI T1.112.4-4 Clause 2.1 SCCP
Addressing states:

   "If a reply or a message return is required, the Calling Party Address
    plus the OPC in the routing label must contain sufficient information
    to uniquely identify the originator of the message.  If the message
    requires global title translation where the OPC may change, then the
    Calling Party Address should not contain SSN only."

SCCP handles this nicely on its own without prompting from the ASP or User.

> I agree with having it as an optional parameter, not with it's removal.

It's useless, remove it.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 20 Sep 2001 13:30:05 +0200

Again you miss the point ...

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 20 september 2001 12:56
To: sigtran
Subject: Re: [SUA Issue 26] N-COORD Primitive

Gery,

[GV] : Presence or absence in SUA does not always translate into these
inclusion bits.

[GV] : So ? The ANSI statement just confirms my approach ... Calling Party
Address contains SPC if Called Party Address was routed on GT; but it's no
requirement (perhaps even undesired) if the Calling Party Address itself is
a GT. Different applications (e.g. CCBS, IN) might have different routing
requirements. Are you going to provide for all that on your SG ?

It's useless, remove it.

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Sep 2001 11:19:34 -0500

Gery,

Verwimp Gery wrote:                                       (Thu, 20 Sep 2001 13:30:05)
> [GV]: Presence or absence in SUA does not always translate into these
> inclusion bits.

Right, SUA AI has no point or parallel.

> [GV]: So ? The ANSI statement just confirms my approach ... Calling Party

Yes, in the SCCP, where it belongs.  These are SCCP implementation matters
and have no need of an SUA AI.

--brian

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

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Fri, 21 Sep 2001 09:39:55 -0500

John,

I agree with Gery. 

Klaus

> From: Verwimp Gery [mailto:[email-masked]]
> Sent: September 20, 2001 6:43 AM
> To: sigtran
> You are currently subscribed to sigtran as: 
> [email-masked]

---