Subject: M3UA-10, SUA-09: Section 4.5.2

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 29 Dec 2001 16:39:03 -0600

--------------------------------

M3UA-10: Section 4.5.2

> 4.5.2 At an ASP
>
> 4.5.2.1 Single SGP Configurations

Change this title to "Single SG Configurations".

>
> At an ASP, upon receiving an SS7 Signalling Network Management (SSNM) 
> message from the remote M3UA Peer, the M3UA layer invokes the 
> appropriate primitive indications to the resident M3UA-Users.  Local 
> management is informed.
>
> In the case where a local event has caused the unavailability or 
> congestion status of SS7 destinations, the M3UA layer at the ASP SHOULD
> pass up appropriate indications in the primitives to the M3UA User, as 
> though equivalent SSNM messages were received.  For example, the loss 
> of an SCTP association to an SGP may cause the unavailability of a set 
> of SS7 destinations.  MTP-PAUSE indication primitives to the M3UA User 
> are appropriate.  
>
> Implementation Note: To accomplish this, the M3UA layer at an ASP 
> maintains the status of routes via the SG(P), much like an MTP3 layer 
> maintains route-set status.

Move this note to Section 4.5.2.2 and change "SG(P)" to "SG" to conform
to list concensus.

>
> 4.5.2.2 Multiple SGP Configurations
>

Change this title to "Multiple SG Configurations".

> At an ASP, upon receiving a Signalling Network Management message from 
> the remote M3UA Peer, the M3UA layer updates the status of the affected 
> route(s) via the originating SG and determines, whether or not the 
> overall availability or congestion status of the effected 
> destination(s) has changed. If so, the M3UA layer invokes the 
> appropriate primitive indications to the resident M3UA-Users.  Local 
> management is informed.  
>

--------------------------------

SUA-09: Section 4.5.2:

> 4.5.2 At an ASP 
> 
> 4.5.2.1 Single SGP Configurations 

Change this title to "Single SG Configurations".

>     
>    At an ASP, upon receiving an SS7 Signalling Network Management (SSNM) 
>    message from the remote SUA Peer, the SUA layer invokes the 
>    appropriate primitive indications to the resident SUA-Users.  Local 
>    management is informed. 
>     
>    In the case where a local event has caused the unavailability or 
>    congestion status of SS7 destinations, the SUA layer at the ASP 
>    SHOULD pass up appropriate indications in the primitives to the SUA 
>    User, as though equivalent SSNM messages were received.  For example, 
>    the loss of an SCTP association to an SGP may cause the 
>    unavailability of a set of SS7 destinations.  MTP-PAUSE indication 
>    primitives to the SUA User are appropriate.   

Change MTP-PAUSE to N-PCSTATE.

>  
>    Implementation Note: To accomplish this, the SUA layer at an ASP 
>    maintains the status of routes via the SG(P). 

Change "SG(P)" above to "SG" and move this note to section 4.5.2.2.

> 
> 4.5.2.2 Multiple SGP Configurations 

Change this title to "Multiple SG Configurations".

>     
>    At an ASP, upon receiving a Signalling Network Management message 
>    from the remote SUA Peer, the SUA layer updates the status of the 
>    affected route(s) via the originating SGP and determines, whether or 

Change "SGP" above to "SG".

>    not the overall availability or congestion status of the effected 
>    destination(s) has changed. If so, the SUA layer invokes the 
>    appropriate primitive indications to the resident SUA-Users.  Local 
>    management is informed.   

--brian
    
-- 
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]