RE: DPC + OPC Routing

 
  Hello Cathy,
   
  Please see my comments inline.
   
  -Regards
  Anjali.

"Newman, Catherine J" <[email protected]> wrote:
    Ansi T1.112.4-1996 doesn't have the SCCP Flow Control procedures.
Ansi T1.112.4-2001 and T1.112.4-2005PPP have these procedures as
optional:
"5.5 SCCP Flow Control (Optional)"

And Section 5.3.6.7 & 8 and other related requirements have footnote 20:
20. Flow Control procedures in clause 5.5 are optional.

Telcordia GR-246, T1.112.4-2005 (the latest version) states these
procedures aren't used:
"5.5 SCCP Flow Control

NOTE: SCCP Flow Control procedures are not specified for use in Client
Company networks."

I'm pointing this out since I think there is likely to be
interoperability issues if UPU (re: SCCP) is sent in ANSI networks -
processing a received UPU (re:SCCP) is optional. ANSI T1.112.4 Section
5.5 should be made mandatory if this solution is agreed upon, but then
there will be backward compatibility issues. 

Alternately, limitations could be put on RK use (e.g., force user to
provision a separate SSN for each of the AS1 and AS2 in the original
example) to avoid such circumstances so no changes to standard SS7
procedures are needed.
   
  <<Anjali>> In the original example, the AS's configured had the Routing 
key as DPC + OPC and so there is no SSN configured in the RK. 
Also as per the M3UA RFC 4666, the use of SSN as well as CIC in the RK is not recommended(being application specific) and so removed from 3332 to 4666.
  
Also I think, the problem of deciding which message to use to communicate the 
status as Down, becomes potential in case when some ISUP based implementation is being used . This is because the RK DPC + OPC is used with such implementations and so we can have multiple AS's (with same DPC but different OPCs as RK) serving the same DPC.So if one AS handling traffic(lets say for an MSC point Code) goes down, there is a need to communicate this to the MSC(OPC). 
   
  In case of SCCP, networks might not use DPC + OPC routing because use of Global title at STP could result in DPC/DPC+SSN which could be mapped to an AS(with RK - DPC based) to route traffic over to IP. Hence if that AS goes down, this could be easily propagated as entire DPC going down.

  


Cathy 


-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Wednesday, April 11, 2007 3:16 AM
To: Newman, Catherine J
Cc: anjali gurmukhani; [email protected]; Hickman, Kelly A
Subject: Re: [Sigtran] DPC + OPC Routing

Cathy,

Take a look at ANSI T1.112.4-2000/5.3.6.2(5) and 5.3.6.3(5). When
SCCP Flow Control is used, MTP-STATUS (user part unavailable) will
trigger local N-STATE primitives indicating "User-out-of-Service".

Also ANSI T1.112.4-2000/5.3.6.7 and 5.3.6.8 N-PCSTATE will be locally
broadcast indicating "SCCP inaccessible".

Timer T(stat.info) is started or restarted in both cases and when it
expires, N-STATE (User-in-service) and N-PCSTAT(SCCP accessible) will
be locally broadcast.

But also, see ANSI T1.112.4-2000/5.5.2 and 5.5.4 which specifically
provide for SST (SSN=1) in response to MTP-STATUS (inaccessible or
unknown). Again, as part of "Optional" SCCP Flow Control.

Your information appears incorrect (or dated).

--brian

Newman, Catherine J wrote: (Tue, 10 Apr 2007
22:22:23)
> Brian,
> 
> ANSI SCCP does not support sending UPU for SCCP unavailability or
> sending SSTs for SSN=1 (these procedures went in as a draft at one
point
> in the early 90's and then were deleted). (Note, ITU SCCP does
support
> UPU for SCCP unavailability / SSTs/SSAs for SSN=1)
> 
> Instead, at an STP, a TFP/TFA regarding the alias PC should be sent
(see
> ANSI T1.111.4, Section 3.A and 3.B). There are no ANSI procedures,
that
> I am aware of, for handling SCCP unavailability at an end node. The
> assumption was, I believe, that SCCP can't fail independently of MTP
> with current end-node implementations. 
> 
> Cathy Newman
> 

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



       
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
 Check outnew cars at Yahoo! Autos.

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