Subject: [Sigtran] User Part Unavailable at ASP in M3UA

From: "Kuldeep Janjua" <[email-masked]>
Date: Mon, 18 Dec 2006 10:21:08 +0530

Brian,
In RFC 3332 section 3.4.5 "Destination User Part Unavailable (DUPU)
The DUPU message is used by an SGP to inform concerned ASPs that a remote
peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable." is
said that DUPU is sent by an SGP to ASP in case SG receives UPU from SS7
Point Code.

I want to know which message is sent by the ASP in case it detects the user
part unavailability?

Regards,
Kuldeep
C-DOT India.
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Kuldeep Janjua" <[email-masked]>
Date: Mon, 18 Dec 2006 11:53:33 +0530

Hi Pavan,
There can be three reasons, as much I know to user part unavailabilty:
1.User Unknown
2.User Uenequipped
3.User Inacessible.
According to you for case 1 ASP can generate Error Message and reply with
error code as "INVALID ROUTING CONTEXT" and will drop the recved msg.
But in RFC 3332, I was not able to undstd how the other two cases will be
handled at ASP, I think its not defined in RFC.

Any feedbacks.

Regards,
Kuldeep
C-DOT India.
On 12/18/06, Pavan Kumar <[email-masked]> wrote:
>
>  Hi Kuldeep
>
> I think there is no such message in ASP. Because you have the Routing Key
> in the ASP configuration.Which had been registered in SG. based on this
> information SG will send the message.
>
> Routing key involves the various ss7 parameters like si , ni , opc,dpc,sls
> , cic ,ssn. There are several combition for the Routing Key configuration.
> Once the Routing key is registered with SG , it willget the unique Id called
> Routing Context.
>
> If the configured Routing Context is not available after message sent from
> the SG. ASP application will reject the message no route found.
>
> This is my though , please let me know if i am wrong or need furthur
> information.
>
> Regards
> Pavan
> On 12/18/06, Kuldeep Janjua <[email-masked]> wrote:
>
> > Brian,
> > The DUPU message is used by an SGP to inform concerned ASPs that a
> > remote peer MTP3-User Part ( e.g., ISUP or SCCP) at an SS7 node is
> > unavailable." is said that DUPU is sent by an SGP to ASP in case SG receives
> > UPU from SS7 Point Code.
> >
> > I want to know which message is sent by the ASP in case it detects the
> > user part unavailability?
> >
> > Regards,
> > Kuldeep
> > C-DOT India.
> >
> >

---

From: Mahantesh <[email-masked]>
Date: Mon, 18 Dec 2006 11:54:23 +0530

Hi *Kuldeep,*
**
If u look at SS7 side, the MTP-STATUS message equivalent at IP side is SCON
or DUPU or DAUD.
But certain fields, which may be OPTIONAL, decide the waht actiion to take.
>From ASP the a SCON message is sent to SGP in case of UP unavailability.
SCON's optional field "*Concerned Destination: 32-bits" *helps at the other
end about unavailability.

*Rgrds,
-Mahantesh*

On 12/18/06, Kuldeep Janjua <[email-masked]> wrote:

> peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable."
> is said that DUPU is sent by an SGP to ASP in case SG receives UPU from SS7
> Point Code.
>

--

---

From: "Kuldeep Janjua" <[email-masked]>
Date: Mon, 18 Dec 2006 12:13:34 +0530

Hi Mahantesh,

I agree with you that SCON message can be sent from ASP when user part
becomes unavailable because of congestion ( SCON as per defination is for
congestion ).
So it (ASP) again do not cater to the case "User Uneqipped" .

Regards,
Kuldeep
C-DOT India.

On 12/18/06, Mahantesh <[email-masked]> wrote:
>
> Hi *Kuldeep,*
> **
> If u look at SS7 side, the MTP-STATUS message equivalent at IP side is
> SCON or DUPU or DAUD.
> SCON's optional field "*Concerned Destination: 32-bits" * helps at the
> other end about unavailability.
>
> *Rgrds,
> -Mahantesh*
>

---

From: Mahantesh <[email-masked]>
Date: Mon, 18 Dec 2006 12:25:39 +0530

*Kuldeep,**
*
This might help you resolve ur doubt...*cause/user field of SCON *message.

Unavailability *Cause* field: 16-bits

0 Unknown
1 Unequipped Remote User
2 Inaccessible Remote User

MTP3-*User Identity* field: 16-bits

0 to 2 Reserved
*3 SCCP*
4 TUP
*5 ISUP*
6 to 8 Reserved
9 Broadband ISUP
10 Satellite ISUP
11 Reserved

12 AAL type 2 Signalling
13 Bearer Independent Call Control (BICC)
14 Gateway Control Protocol
15 Reserved

*Rgrds,
-Mahantesh*

On 12/18/06, Kuldeep Janjua <[email-masked]> wrote:
> > SCON's optional field "*Concerned Destination: 32-bits" *helps at the
> > On 12/18/06, Kuldeep Janjua <[email-masked] > wrote:
> >
> > > Brian,

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 18 Dec 2006 00:17:55 -0700

Kuldeep,

In the case that the RK is based on SI value, ASP Inactive is the correct
message.  In the case that RK is based on PC, user part flow control is
the responsibility of the ASP (i.e. it could send UPU (the SS7 message, not
the M3UA SNMM message) to the other end, or an equivalent user part message
(e.g. Subsystem Prohibited).

--brian

Kuldeep Janjua wrote:                           (Mon, 18 Dec 2006 10:21:08)
>    remote  peer  MTP3-User  Part  (e.g.,  ISUP or SCCP) at an SS7 node is
>    unavailable."  is  said  that DUPU is sent by an SGP to ASP in case SG
>    receives UPU from SS7 Point Code.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 18 Dec 2006 00:20:52 -0700

Mahantesh,

SCON does not have an MTP3-User Identity field.  It is use to indicate
so-called "nodal" congestion only.

--brian

Mahantesh wrote:                            (Mon, 18 Dec 2006 12:25:39)
> 
>    Kuldeep,
> 
>    This  might  help  you  resolve  ur  doubt...cause/user  field of SCON
>    message.
>    Unavailability Cause field: 16-bits
> 
>      0 Unknown
>      1 Unequipped Remote User
>    MTP3-User Identity field: 16-bits
> 
>      0 to 2 Reserved
>      3 SCCP
>      4 TUP
>      5 ISUP
>      6 to 8 Reserved
>      9 Broadband ISUP
>      10 Satellite ISUP
>      11 Reserved
> 
>      12 AAL type 2 Signalling
>    Rgrds,
>    -Mahantesh

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

---

From: "Kuldeep Janjua" <[email-masked]>
Date: Mon, 18 Dec 2006 13:23:05 +0530

Brian,
Thanks for reply, according to ur feedback I have following doubts:

1.How it can send UPU from ASP, as it will not conform to the M3UA message
type?
2.Why ASP can not send the DUPU message to the SGP?

I think there is a need to specify this issue in RFC 3332.
Regards,
Kuldeep

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 18 Dec 2006 01:05:15 -0700

Kuldeep,

Kuldeep Janjua wrote:                        (Mon, 18 Dec 2006 13:23:05)
>    1.How  it  can  send  UPU from ASP, as it will not conform to the M3UA
>    message type?

	You cannot.  Just as in Q.701 where there is no mechanism for the
	MTP-User to signal unavailabilty to the MTP provider using the
	defined primitive interface.

>    2.Why ASP can not send the DUPU message to the SGP?

	Because there is no equivalent primitive in Q.701. (i.e. there
	is no MTP_STATUS-Request primitive).  MTP-Users do not cause UPU
	to be sent.  And MTP-SAPs are based on SI and (as is specified in
	ANSI) if the MTP-SAP is based on whole-point code, it is the user
	parts responsibility to signal user part unavailability (i.e. with
	user part messages, not MTP messages).

>    I think there is a need to specify this issue in RFC 3332.

	RFC 3332 has been obsoleted by RFC 4666.  See previous discussions
	on the topic.

--brian

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

---

From: Mahantesh <[email-masked]>
Date: Mon, 18 Dec 2006 14:24:12 +0530

Sorry guys!!

SCON has only Cause field.

      0 Unknown
      1 Unequipped Remote User

But, why ASP-INACTIVE ?
No where in the RFC it is mentioned that "when UP is unavailable, send
INACTIVE".

*Rgrds,
-Mahantesh *

---

From: "Kuldeep Janjua" <[email-masked]>
Date: Mon, 18 Dec 2006 14:47:36 +0530

Yes Mahantesh,

Even I too could not find its reference in RFC 4666. It will be nice if some
body can specify it.

Kuldeep

---

From: Mahantesh <[email-masked]>
Date: Mon, 18 Dec 2006 15:40:33 +0530

*Kuldeep,*

What if ASP is ACTIVE and unable to send the signalling UNIT to USER PART?
In such case you can't send ASP-INACTIVE message to the other end.

*Any FEEDBACK for the below paragraph.*

On receiving an *MTP-TRANSFER* request primitive from an upper layer at an
ASP the M3UA layer sends a corresponding DATA message to its M3UA peer.

Keeping the above statement in mind, we can say that there must be a way for
M3UA layer at ASP to know about the UPPER LAYER [USER PART]
availability/unavailability. When an ASP unable to send the signalling
message to the UPPER layer it will come to know about it

          UP                                  UP
            |                                      ^
            V                                     |
LM --> M3UA      or         LM <-- M3UA

When UP is unavailable other end will be made known about the
unavailability. AND
*The optional Concerned Destination parameter is only used if the SCON
message is sent from an ASP to the SGP.*

*Rgrds,
-Mahantesh*
On 12/18/06, Kuldeep Janjua <[email-masked]> wrote:
>
> Yes Mahantesh,
>
> Even I too could not find its reference in RFC 4666. It will be nice if
> some body can specify it.
>
> Kuldeep
>
>
>
> > On 12/18/06, Brian F. G. Bidulock <[email-masked] > wrote:
> > >
> > > Mahantesh,
> > >

---

From: "Kuldeep Janjua" <[email-masked]>
Date: Mon, 18 Dec 2006 16:07:35 +0530

Mahantesh,

ASP Inactive have following parameters:
1.Routing Context
2.INFO
I think what Brian is discussing is that ASP Inactive Message will contain
the routing context parameter, which will let SGP to know that corresponding
traffic range is not available and then SGP can handle the message
accordingly. But its not specified anywhere in the RFC.
>From my point of view Error Message with "Invalid Routing Context" should be
sent, which will stop the further processing of the message at SGP.

As per definition SCON is signalling congestion message so it can be sent
from ASP only in the case when M3UA at ASP detects that there is congestion
for the corresponding user part.So it take care of "UP unavailability" in
case of  "congestion at ASP for UP" only.

There can be other reasons as well for user part unavailability. Those cases
are also required to taken care of.

Regards,
Kuldeep

On 12/18/06, Mahantesh <[email-masked]> wrote:
> Keeping the above statement in mind, we can say that there must be a way
> for M3UA layer at ASP to know about the UPPER LAYER [USER PART]
> > On 12/18/06, Mahantesh <[email-masked] > wrote:
> > >
> > > Sorry guys!!
> > >

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 18 Dec 2006 04:24:14 -0700

Kuldeep,

Kuldeep Janjua wrote:                           (Mon, 18 Dec 2006 16:07:35)
>    [1]2.INFO
>    I  think  what  Brian  is discussing is that ASP Inactive Message will
>    contain the routing context parameter, which will let SGP to know that
>    corresponding  traffic  range is not available and then SGP can handle
>    the message accordingly. But its not specified anywhere in the RFC.

Actions taken toward the SS7 network are implementation dependent, however,
UPU sent when an AS with an RK based on SI value is unavailable is obvious.

>    >From  my  point  of view Error Message with "Invalid Routing Context"
>    should  be sent, which will stop the further processing of the message
>    at SGP.

Bad thing to do: the RC is valid.

>    As  per  definition SCON is signalling congestion message so it can be
>    sent  from ASP only in the case when M3UA at ASP detects that there is
>    congestion  for  the  corresponding  user  part.So it take care of "UP
>    unavailability" in case of  "congestion at ASP for UP" only.

SCON from ASP to SGP is used to signal M3UA congestion (not user part
congestion).  As in SS7, MTP user part congestion is handled within the
user part protocol (e.g. congestion parameter in ISUP release messages).

>    There can be other reasons as well for user part unavailability. Those
>    cases are also required to taken care of.

If an PC based RK is used (all SI values, thus all MTP-Users) then the SG
assumes that all user parts for the PC live or die together (i.e. are all
available or all unavailable).  This is the same for SS7 based on a PC-wide
MTP-SAP (which was only specified in older ANSI documents).

--brian

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