Subject: SUAv8: DUNA and other SNMM messges

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 12 Oct 2001 20:23:56 -0500

Section 3.4.1 states:

   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.   

The Destination Address clearly MUST ONLY include the Affected Point
Code but MAY also include the SSN.   ^^^^

I still disagree with this approach.  It is far better to have a
separate Affected Point Code parameter and SSN parameter.  Examining
the Destination Address parameter at the receiver on each of these
messages to determine that it meets the requirement that it only
include point code and may include SSN is cumbersome at best.  It
is far more efficient to scan the message for an APC and SSN parameter.
This last call issue has not been addressed yet.

Same is true for the other SNMM messages.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

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

---

From: [email-masked]
Date: Sat, 13 Oct 2001 11:44:10 +0530

Hi,

I  agree with Brian to replace destination address in SSNM messages with "
Affected Point Code" and optional "SSN" parameter. When only  APC is to be
conveyed TLV defined in section 3.9.18 ( and shown below ) can be used.

3.9.18 Affected Point Code

       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 = 0x0012         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Mask       |                 Affected PC 1                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             . . .                             /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For conveying APC + SSN , TLV shown below can used. (Affected SSN)

       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 = 0x0013         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Mask       |                 Affected PC 1                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Reserved                      |   SSN value   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             . . .                             /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

One more comment about definition of DUNA  message ..

1.5.2 Address Mapping at the ASP
To direct messages to the SS7 network, the ASP MUST perform an address mapping
to choose the proper SGP for a given message.  This is accomplished by observing
the Destination Point Code and other elements of the outgoing message, SS7
network status, SGP availability, and Routing Context configuration tables.

3.4.1 Destination Unavailable (DUNA)
The DUNA message is sent from the SG or relay node to all concerned ASPs
(servicing SCCP-users considered local to the SG or relay node, see chapter
1.3.1.1), when a destination or SCCP-user has become unreachable. The SUA-User
at the ASP is expected to stop traffic to the affected destination or SCCP-user
through the SG or relay node initiating the DUNA.
>> The last sentence of section 3.4.1 suggests that SUA User at ASP should
maintain the status of destinations via each SG and should tell SUA via which SG
to route the message, section 1.5.2 says it should be done by SUA ??

Is the following intended for the cases when DUNA message contains either APC or
APC + SSN ?
" SUA layer at ASP on receiving the DUNA message should change availability
status of the destination via the SG whose SGP has sent DUNA message. If this
changes the overall availability of the destination (i.e. now there is no SG via
which that destination is available) SUA layer at ASP should notify the same to
SCCP Users who in turn should generating messages towards that destination"

Please clarify ?

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 10/13/2001 07:53:56 AM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]>
cc:    (bcc: Sandeep Mahajan/HSS)

Subject:  SUAv8: DUNA and other SNMM messges

Section 3.4.1 states:

--brian

--
Brian F. G. Bidulock    

¦ The reasonable man adapts himself to the ¦

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

---

---

From: [email-masked]
Date: Tue, 16 Oct 2001 20:53:06 +0300

Hi Brian,

> is far more efficient to scan the message for an APC and SSN 

Let me try to incorporate this into the SNMM messages and make sure
it doesn't cause any problems.  If I can get this into the document, as
suggested.  If I do this, I think it will take care of your concern 
for this issue & for the next mail (subject: SUAv8: Affected Point Code).

My feeling from the last call was that the approach contained in SUA v8
was sub-optional, but not technically deficient.  

best regards,
John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 17:36:09 -0500

John,

John Loughney wrote:                                         (Tue, 16 Oct 2001 20:53:06)
> was sub-optional, but not technically deficient.  

M3UA and SUA should be consistent here.  Of course M3UA uses Affected
Point Code not Destination Address.

--brian

> 
> best regards,
> John
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: [email-masked]
Date: Thu, 18 Oct 2001 00:08:34 +0300

Brian,

> Point Code not Destination Address.

Of course, SUA needs to consider SSN in some cases.  Could you propose
how to handle SSNs in the SNMM messages?  For example, when a DUNA
contains a SSN, how does the SSN relate to the Affected Point Code 
parameter (which may contain multiple point codes)?  Does the SSN refer
to all of the Affect PCs?  

Originally, by using the Destination Address field, this situation 
was simplified.

best regards,
John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 18:33:01 -0500

John,

Multiple point codes in the APC parameter is pretty useless both for
M3UA and SUA.  Only in response to a DAUD could this feature be used
(and then the ASP will likely have to break them back out anyway).
I would say that the APC can only contain one point code when SSN
is present.  Simple enough?

--brian

John Loughney wrote:                                         (Thu, 18 Oct 2001 00:08:34)

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 18 Oct 2001 09:19:10 +0200

John,

I agree with Brian on this one. There also was consensus on using APC and
ASSN instead of Destination Address to align with M3UA.

____________________________

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: donderdag 18 oktober 2001 1:33
To: sigtran
Cc: [email-masked]
Subject: Re: SUAv8: DUNA and other SNMM messges

John,

--brian

John Loughney wrote:                                         (Thu, 18 Oct
2001 00:08:34)

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

---