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

From: [email-masked]
Date: Mon, 3 Sep 2001 11:12:59 +0300

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]