Subject: Re: [SUA & M3UA issue] IPSP cases.

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Sep 2001 18:49:38 -0500

John,

It is fairly clear from the ASP state machines and considerable
discussion that an ASP has a state on a per-AS basis.  Therefore,
in the text that you propose, should not moving the ASP to the
ASP-INACTIVE state be qualified by which AS this state transition
is performed?  Such as the following text which M3UAv8 uses to
qualify the situtation:

  "If the SGP is aware, via current configuration data, which
   Application Servers the ASP is configured to operate in, the
   SGP updates the ASP state to ASP-INACTIVE in each AS that it
   is a member.  Alternatively, the SGP may move the ASP into a
   pool of Inactive ASPs available for future configuration within
   Application Server(s), determined in a subsequent Registration
   Request or ASP Active procedure."

The procedure described below is asymmetric regarding ASPUP
procedures, and it should be clarified that each IPSP is responsible
for handling the state of the ASP within an AS (or common pool) as
decribed above for SGP.

In the backhaul case, the ASP does not necessarily move itself
to an ASP-INACTIVE state, wherease in the proposed IPSP text,
both IPSPs act as SGPs in this respect.

Because either side is permitted to send an ASPUP, it should be
described how the procedure is going to complete if there is an
ASPUP collision.  That is, are both sides required to respond to
the ASPUP?

The text should also describe how an IPSP will respond to an ASPUP
from the peer when it already has the peer ASP marked as up (as is
described for the ASP/SGP case in M3UA).  Does the IPSP ignore the
ASPUP?  Does it return ASPUP Ack?  What is the resulting state at
the IPSP receiving the ASPUP for an ASP already marked in the up
state?  Does the ASP move the ASP to ASP-INACTIVE upon receipt of
an ASPUP from the peer even though it has the ASP marked in the
ASP-ACTIVE state for some AS(s)?

Can we expect further text proposals to resolve the other issues
in the IPSP cases?

--brian

On Mon, 03 Sep 2001, John Loughney wrote:

> Hi all,
> 
> Working on Chapter 4 for both M3UA & SUA, so far, here is some of the 
> text in progress.
> 
> After the text some follow-on answers to some points raised.
> 
> ==== Text ====
> 
> 4.3.4 ASPM Procedures for Peer-to-Peer Messages
> 
> 4.3.4.1 ASP Up Procedures
> 
> [text clipped]
> 
> 4.3.4.1.2 IPSP Considerations
> 
> In the case of peer-to-peer IPSPs, either of the IPSPs (IPSP_A) may 
> start operations by sending an ASP Up message to the remote peer 
> (IPSP_B).  When the ASP Up message is received at IPSP_B and internally 
> the remote IPSP_A is in the ASP-DOWN state and not considered locked-
> out for local management reasons, IPSP_B marks the remote IPSP_A in the 
> state ASP-INACTIVE and informs Layer Management with an M-ASP_Up 
> indication primitive.  IPSP_B returns an ASP-Up Ack message to IPSP_A.  
> IPSP_A moves IPSP_B to the ASP-INACTIVE state upon reception of an ASP 
> Up Ack message, if is not already in the ASP_INACTIVE state, and 
> informs Layer Management with an M-ASP_UP confirmation primitive.
> If for any local reason (e.g., management lock-out) the IPSP_B cannot 
> respond with an ASP Up Ack message, it responds to an ASP Up message 
> with an Error message with Reason "Refused - Management Blocking" and 
> leaves IPSP_A in the ASP-DOWN state.  
> 
> 
> 
> ---
> 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/

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