Subject: Testing for DUPU

From: Jacques Rajchgod <[email-masked]>
Date: Fri, 19 Oct 2001 10:22:38 -0500

M3UA - any rev (but currently referring to "06" for a particular reason).

We are looking at section "DUPU" that deals with an SS7 stack whose Layer-4
component ISUP has become UNAV. The picture that we have from that section,
is as follows:

1) There is a healthy SS7 node.
2) The node has a healthy SS7 stack.
3) In that healthy SS7 stack, a Layer-4 Component has now become UNAV. Ex:
ISUP.
4) Other Layer-4 components in that healthy SS7 stack of that healthy SS7
node - are functioning well - ex: SSCP.

My question is:
How would I simulate such condition (of a Layer-4 ISUP going UNAV inside a
healthy SS7 stack) in a lab, for a Test Case?
I need to verify that a DUPU is generated by a SG on an ISUP becoming UNAV
inside a healthy SS7 stack of a healthy SS7 node...Any idea?

Additional question:
How could a SG tell that an ISUP component in a healthy SS7 node has
suddenly become UNAV, but that everything else is OK in that node? <-- as
opposed to an ISUP component being UNAV because the node is not receiving
calls? (Big difference....)

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

---
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: Fri, 19 Oct 2001 15:25:45 -0500

Jacques,

How you make a user part unavailable will depend on the IUT at hand.

--brian

Jacques Rajchgod wrote:                                   (Fri, 19 Oct 2001 10:22:38)
>    We are looking at section "DUPU" that deals with an SS7 stack whose
>    Layer-4 component ISUP has become UNAV. The picture that we have from
>    that section, is as follows:
>    
>    
>    
>    3) In that healthy SS7 stack, a Layer-4 Component has now become UNAV.
>    Ex: ISUP.
>    
>    4) Other Layer-4 components in that healthy SS7 stack of that healthy
>    SS7 node - are functioning well - ex: SSCP.
>    
>    
>    
>    My question is:
>    
>    How would I simulate such condition (of a Layer-4 ISUP going UNAV
>    inside a healthy SS7 stack) in a lab, for a Test Case?
>    
>    I need to verify that a DUPU is generated by a SG on an ISUP becoming
>    UNAV inside a healthy SS7 stack of a healthy SS7 node...Any idea?
>    
>    
>    
>    Additional question:
>    
>    suddenly become UNAV, but that everything else is OK in that node? <--
>    as opposed to an ISUP component being UNAV because the node is not
>    receiving calls? (Big difference....)
>    
>    
>    
>    Please kindly advise...
>    
>    Jacques Rajchgod
>    MCI Worldcom
>    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/

---

---

From: Al Varney <[email-masked]>
Date: Fri, 19 Oct 2001 12:45:34 -0500

>M3UA - any rev (but currently referring to "06" for a particular reason).

    I think version 09 is pretty similar in this regard.

>node - are functioning well - ex: SSCP.

    Your description is of a node ready to SEND SS7 UPU messages.  The DUPU 
section of M3UA deals with receiving SS7 UPU messages, not sending them.

>healthy SS7 stack) in a lab, for a Test Case?

    In a lab, use an SS7 protocol generator to send UPU to the SG over SS7 
links.  Or have an ISUP ASP send an ISUP message to an SCCP-only SCP.

>inside a healthy SS7 stack of a healthy SS7 node...Any idea?

    The M3UA spec has a SG generate DUPU only on receipt of a UPU on one of 
its SS7 signaling links.  M3UA doesn't mention any case where the SG 
generates the SS7 UPU itself.  Since the decision to generate UPU is 
implementation dependent in the SS7 specs, the M3UA spec will likely never 
be allowed to suggest when it is appropriate for a SG to generate SS7 UPU 
("That's implementation!!").  Maybe this means SG generation of UPU cannot 
be an M3UA test case??  (It could be an SS7 MTP test case.)

    Vendors of SGs might be willing to disclose conditions under which they 
generate SS7 UPU.  You might want to ask how they handle incoming ISUP 
messages when all ISUP ASPs have Deregistered the SI=ISUP key, or 
alternatively no ASP has registered SI=ISUP.  (Note that the SS7 specs 
assume UPU is inappropriate if ANY CIC can be processed via ISUP, so 
implementations supporting split-CIC-Registration have to also figure out 
when/how ISUP UCIC is generated.)

>calls? (Big difference....)

    I think the question is:  Can an ASP with multiple SI processes have 
one of those processes fail for a period of time worth reporting to the SS7 
network?  If so, the ASP must take some action to notify the SG it cannot 
handle (at the moment) that particular SI.  The only M3UA way to do that is 
to Deregister the SI.  At that point, I don't know how an SG can figure out 
whether the appropriate UPU Unavailability Cause is Unequipped or 
Inaccessible -- Unequipped is appropriate if the User Part doesn't exist, 
and Inaccessible is appropriate if the User Part is temporarily 
unavailable.  (Maybe the SG should send Inaccessible for a day or so after 
Deregistration, and then send Unequipped?)

    One side effect of the lack of an ASP -> SG user-part-availability 
indication is that any ASP that registers WITHOUT an optional SI (or SIs) 
will be expected to handle any incoming message with ANY SI value -- ASPs 
cannot force UPU to be generated based on an incoming message with an 
unexpected SI value.  And since the correct response to some (currently 
unassigned) SI values is unknown, I don't see where it makes sense for SI 
to be left out of a Registration.

    M3UA should also ban the Registration of SI=1 and SI=2 (not just SI=0), 
since protocols using those values will likely need to be able to control 
the specific signaling links used at an SG.  The M3UA DATA message cannot 
be sent to a specific signaling link, so an ASP cannot properly handle SLT 
messages, for example.

Al Varney

---

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 23 Oct 2001 02:37:33 -0400

resending ...

----- Original Message -----
From: "Greg Sidebottom" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 22, 2001 3:37 PM
Subject: Re: Testing for DUPU

> Hi Al,
>
>    I agree (as usual!) with your points below and have made an addition in
> M3UA Section 3.6.1 to disallow SI values of '1', or '2' in an SI of a REG
> REQ.   There's no impact on DUPU as these values are not used by SS7 UPU
> procedures.
>
> Thanks,
>
>    Greg
>
> ----- Original Message -----
> From: "Al Varney" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Friday, October 19, 2001 1:45 PM
> Subject: Re: Testing for DUPU
>
>
> Ex:
SS7
> > >How would I simulate such condition (of a Layer-4 ISUP going UNAV
inside
> a
> UNAV
as

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Oct 2001 01:51:37 -0500

Greg,

There is no need to disallow SI=1 or SI=2 in the spec.  The SGP/IPSP is
fully able to refuse registration of SI=1 or SI=2 in the current draft.

--brian

Greg Sidebottom wrote:                                       (Tue, 23 Oct 2001 02:37:33)

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

---

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 23 Oct 2001 12:47:17 -0400

Hi Brian,

Good point - I guess we could say the same about the current text
disallowing of SI='0' as well?  Should we delete the sentence or would an
implementation note serve here.  The v9 text in Section 3.6.1 (SI parameter)
is:

    "An SI value of zero is not valid in M3UA."

Cheers,

   Greg

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, October 23, 2001 2:51 AM
Subject: Re: Fw: Testing for DUPU

> > > >     Your description is of a node ready to SEND SS7 UPU messages.
The
> > > DUPU
> > > >     In a lab, use an SS7 protocol generator to send UPU to the SG
over
> > > >     The M3UA spec has a SG generate DUPU only on receipt of a UPU on
one
> > > of
> > > > be allowed to suggest when it is appropriate for a SG to generate
SS7
> > UPU
> > > >     Vendors of SGs might be willing to disclose conditions under
which
> > > they
> > > > implementations supporting split-CIC-Registration have to also
figure
> > out
> > > > one of those processes fail for a period of time worth reporting to
the
> > > > handle (at the moment) that particular SI.  The only M3UA way to do
that
> > > is
> > > > to Deregister the SI.  At that point, I don't know how an SG can
figure
> > > out
> > > > unassigned) SI values is unknown, I don't see where it makes sense
for
> > SI
> > > > be sent to a specific signaling link, so an ASP cannot properly
handle
> > SLT
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Oct 2001 12:40:54 -0500

Greg,

I would prefer if the spec did not impose requirements where the
SG already has the ability to reject the value.  What is the use
between saying that SI=0 is invalid?  It does not change what the
SG will do if it receives SI=0.

--brian

Greg Sidebottom wrote:                          (Tue, 23 Oct 2001 12:47:17)

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

---

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 23 Oct 2001 17:20:25 -0400

Brian,

I agree - lets delete the sentence

Cheers,

     Greg

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, October 23, 2001 1:40 PM
Subject: Re: Fw: Testing for DUPU

> > > Greg Sidebottom wrote:                                       (Tue, 23
Oct
> > 2001 02:37:33)
> > > > > M3UA Section 3.6.1 to disallow SI values of '1', or '2' in an SI
of a
> > REG
> > > > > REQ.   There's no impact on DUPU as these values are not used by
SS7
> > > > > > >M3UA - any rev (but currently referring to "06" for a
particular
> > > > reason).
> > > > > > > Layer-4 component ISUP has become UNAV. The picture that we
have
> > from
> > > > > > >3) In that healthy SS7 stack, a Layer-4 Component has now
become
> > UNAV.
> > > > > > section of M3UA deals with receiving SS7 UPU messages, not
sending
> > them.
> > > > > > implementation dependent in the SS7 specs, the M3UA spec will
likely
> > > > never
> > > > > > ("That's implementation!!").  Maybe this means SG generation of
UPU
> > > > cannot
> > > > > > generate SS7 UPU.  You might want to ask how they handle
incoming
> > ISUP
> > > > > > >How could a SG tell that an ISUP component in a healthy SS7
node
> > has
> > > > > > >suddenly become UNAV, but that everything else is OK in that
node?
> > <--
> > > > > >     I think the question is:  Can an ASP with multiple SI
processes
> > have
> > > > > > network?  If so, the ASP must take some action to notify the SG
it
> > > > cannot
> > > > > > Inaccessible -- Unequipped is appropriate if the User Part
doesn't
> > > > exist,
> > > > > > unavailable.  (Maybe the SG should send Inaccessible for a day
or so
> > > > after
> > > > > > indication is that any ASP that registers WITHOUT an optional SI
(or
> > > > SIs)
> > > > > > will be expected to handle any incoming message with ANY SI
value --
> > > > ASPs
> > > > > > cannot force UPU to be generated based on an incoming message
with
> > an
> > > > > >     M3UA should also ban the Registration of SI=1 and SI=2 (not
just
> > > > > SI=0),
> > > > > > since protocols using those values will likely need to be able
to
> > > > control
> > > > > > the specific signaling links used at an SG.  The M3UA DATA
message
> > > > cannot

---