Subject: M3UA v9: ASP Up Procedures

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 11 Oct 2001 16:35:39 -0500

Section 4.3.4.1 says:

  The ASP must wait for the ASP Up Ack message before sending any other 
  M3UA messages (e.g., ASP Active or REG REQ).  If the SGP receives any 
  other M3UA messages before an ASP Up message is received, the SGP 
  SHOULD discard them.

The recommendation to discard messages is a poor recommendation.  Change
SHOULD to MAY.  (This has been brought up before as well.)

--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: Jacques Rajchgod <[email-masked]>
Date: Fri, 12 Oct 2001 09:37:48 -0500

Inside the text...

Jacques Rajchgod
MCI Worldcom
Next Generation System Evaluation
Tel: [972] 729-7180
E-mail: [email-masked]

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, October 11, 2001 4:36 PM
> To: sigtran
> Subject: M3UA v9: ASP Up Procedures
>
>
> Section 4.3.4.1 says:
>

From Jacques
---------------------
So now, I have two vendors that I am evaluating for recommendation to my
client.
Vendor A discards all messages (per above scenario) but vendor B does not.
Which one should I consider "complying"
and therefore could recommend to my client? Or could I consider both as
complying?

Another question:

1) ASP sends ASP-UP
2) ASP is "impatient" and sends immediately ASP-ACT to the SG.
3) ASPUP-ACK has not yet been received from the SG.
4) Now then: The SG has received in-tandem: An ASPUP and an ASPACT.
The receipt of the ASPUP by the SG satisfies the above section ("If the SGP
receives any
other M3UA messages before an ASP Up message is received...") but what
happens to the section
"The ASP must wait for the ASP Up Ack (from the SG) message before sending
any other M3UA messages"?

The SG has not yet sent an ACK for the UP, so, should the SG reject the
ASPACT with "Invalid State", I guess ?

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 12 Oct 2001 17:58:26 -0500

Jacques,

Please see comments inline...

Jacques Rajchgod wrote:                                   (Fri, 12 Oct 2001 09:37:48)
> client.  Vendor A discards all messages (per above scenario) but vendor B
> does not.  Which one should I consider "complying" and therefore could
> recommend to my client? Or could I consider both as complying?

Certainly my point was that an implementation which chooses not
to dicard messages should be considered as complying.

An implmentation which discards messages could also be
considered to comply; however, as SS7 has its own performance
requirements with regards to discard of messages, I wonder
whether an implementation which discards as a matter of course
can be made to meet those requirements.

When considering implemetnation recommdendations it might be
advisable to see whether implementations meet SS7 requirements
(both conformance and performance) before seeing whether they
meet M3UA requirements.  If SS7 discard performance objectives
are being met, it is moot how the implementation behaves in this
regard.

As performance is left to the implementation by M3UA, there is
no reason why it should make recommendations with regard to
when to discard messages that could otherwise be processed.

> ASPACT with "Invalid State", I guess ?

That is a different matter.  The ASP should not be impatient.
There is no issue with regard to performance objectives here.
The ASP is compelled to send ASP UP and then wait for ASP UP ACK
before continuing.  If the SG receives an ASP AC before sending
an ASP UP ACK it should send Error("Unexpected Message").
Perhaps the "must" in the quote from section 4.3.4.1 should be
"MUST".

--brian

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

---

---

From: Angermayr Manfred <[email-masked]>
Date: Tue, 16 Oct 2001 09:55:08 +0200

Hello Brian,
the MTP restart procedure - I assume you refer to chapter 4.6 - and the ASP UP procedure address 2 different cases.
The MTP restart sections describes what should be done when the MTP3 in the SG undergoes an MTP Restart. This means that the SG has lost all its SS7 links. The connection between the SG and the ASP however is still active. Therefore in this case it makes sense, to go on with the 'normal' processing of the SS7 states (sending DUNA and DAVA) as described in the MTP restart section.
The scenario in the ASP up procedure however is different. Up to now the ASP has no connection to the SG or the ASP has lost this connection. Therefore it is a good approach to initialize the SS7 states, and begin processing the these states at defined point.
There are two possibilities of initializing the SS7 states: allowed and unavailable. 
As normally all SS7 states should be reachable from the SG, the initialization to allowed is the better choice, because then in the normal case the SG does not need to send any SSNM messages for the activation of an ASP.
Therefore I think the text in section 4.3.4.1 should not be changed.

Regards,
Manfred

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Donnerstag, 11. Oktober 2001 22:38
An: sigtran
Betreff: M3UA v9: ASP Up Procedures

Section 4.3.4.1 says:

  At the ASP, the ASP Up Ack message received is not acknowledged. Layer 
  Management is informed with an M-ASP_UP confirm primitive.  When an ASP
  enters the ASP-Inactive state from the ASP-Down state towards an SGP 
  the M3UA MUST mark all SS7 destinations configured to be reachable via 
  this SGP as available.

This MUST and the the marking of the SS7 destinations is no longer applicable
with the revised restart procedures.  Remove the last seentence from this
paragraph or reword to match the restart procedures.

--brian

-- 
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: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 17 Oct 2001 14:27:16 +0200

Ok !!  Agreed.

Cheers // Javier.

> Sent: Thursday, October 11, 2001 11:36 PM
> To: sigtran
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---