Subject: RE: [Sigtran] M3UA RFC 3332 - Sec 4.3.1

From: "S, Girish (Girish)" <[email-masked]>
Date: Wed, 18 Jan 2006 14:26:18 +0530

Thanks Barry, Brian,

Barry, Brian and All,

I wanted to know about this specific scenario which I picked from one of the
previous discussions sometime back where, we have the following stacks at
the both the ends.

         ********    IP    ********
         *IPSP-A*          *IPSP-B*
         ********          ********

         +------+          +------+
         |SCCP- |          |SCCP- |
         | User |          | User |
         +------+          +------+
         | SCCP |          | SCCP |
         +------+          +------+
         | M3UA |          | M3UA |
         +------+          +------+
         | SCTP |          | SCTP |
         +------+          +------+
         |  IP  |          |  IP  |
         +------+          +------+
             |________________|

Scenario in question is as follows,
1. At the bring up time, SCCP-User at IPSP-A is not ready or "blocked" by
the operator.
2. Layer Management of M3UA triggers the setting up of SCTP association and
start of M3UA procedures.
3. This causes an ASP Active to be sent from IPSP-A to IPSP-B, indicating
that the IPSP-A is ready to process signaling traffic for a particular
application server. (But the SCCP-User at IPSP-A is still "blocked")

Considering that the above sequence is to be maintained my question is, does
the M3UA standard allow IPSP-A to make use of the "local management
intervention" so that IPSP-A does not receive any traffic from IPSP-B until
the SCCP-User becomes "not blocked" ? 

Section 1.4.5 of RFC 3332 says, 

"Local Management at an ASP may wish to stop traffic across an SCTP
association to temporarily remove the association from service or to perform
testing and maintenance activity. The function could optionally be used to
control the start of traffic on to a newly available SCTP association."

Any thoughts ? 

Regards,

Girish 

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]]  On
Behalf Of Barry Nagelberg
Sent:	Tuesday, January 17, 2006 9:58 PM
To:	[email-masked]
Subject:	RE: [Sigtran] M3UA RFC 3332 - Sec 4.3.1

Girish,

This is implementation-dependent. An implementation may offer a user
interface through which the SGP-user could set the
"administration" state of the ASP. For example, if the user doesn't want to
accept a connection from a certain ASP,
she/he could set the ASP "administration" state to INACTIVE.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of S, Girish (Girish)
Sent: Tuesday, January 17, 2006 11:11 AM
To: [email-masked]
Subject: [Sigtran] M3UA RFC 3332 - Sec 4.3.1

Hi,
Please help me in understanding the significance of the "Local management
intervention" in the following section from RFC 3332...

****************************************************************************
********************************
4.3.1 ASP States

The state of each remote ASP, in each AS that it is configured to
operate, is maintained in the M3UA layer in the SGP. The state of a
particular ASP in a particular AS changes due to events. The events
include:

* Reception of messages from the peer M3UA layer at the ASP;
* Reception of some messages from the peer M3UA layer at other ASPs
in the AS (e.g., ASP Active message indicating "Override");
* Reception of indications from the SCTP layer; or
* Local Management intervention.
****************************************************************************
********************************

What would this mean ... ? How do I change the ASP state using this...?

Regards,

Girish

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 18 Jan 2006 06:05:05 -0700

S,,

You say the SCCP User is blocked, but not SCCP, correct?  The SCCP-User
at IPSP-B will not send traffic to the SCCP-User at IPSP-A until it
receives SSA for the subsystem (which is currently prohibited).  If the
SCCP layer at IPSP-A receives traffic for an unavailable subsystem it
will respond with SSP.

--brian

S, Girish (Girish) wrote:                        (Wed, 18 Jan 2006 14:26:18)

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