Subject: [Sigtran] M3UA distributing ISUP group messages

From: "Wung, Joseph" <[email-masked]>
Date: Fri, 27 Dec 2002 15:14:38 -0500

Each of the ISUP group related messages, i.e., CGB, CGU, GRS, GRA, etc.,
has a range field in addition to the CIC parameter that together specify a
range
of circuits to operate on.  I would assume that the SGP that receives those
message
would distribute them toward an ASP based on the CIC parameter in the
messages 
without looking at the range field.  This may be ok if the entire range fall
into the same 
AS as the CIC.  What if the range crosses the boundary of the AS?  This may
seem 
like an implementation dependent issue, but it does impact how ISUP messages
are 
distributed based on the routing key.  Any solution?

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 27 Dec 2002 13:59:02 -0700

Joseph,

Section A.2.1 says:

  "For example, where Application Servers are defined using ranges of
   ISUP CIC values, the Operator is implicitly splitting up control of
   the related circuit groups.  Some CIC value range assignments may
   interfere with ISUP circuit group management procedures."

The solution is: don't split up your circuit groups across ASPs: which
makes sense anyway.

--brian

Wung, Joseph wrote:                              (Fri, 27 Dec 2002 15:14:38)
> Each of the ISUP group related messages, i.e., CGB, CGU, GRS, GRA, etc., has
> a range field in addition to the CIC parameter that together specify a range
> message would distribute them toward an ASP based on the CIC parameter in
> the messages without looking at the range field.  This may be ok if the
> entire range fall into the same AS as the CIC.  What if the range crosses
> the boundary of the AS?  This may seem like an implementation dependent
> issue, but it does impact how ISUP messages are distributed based on the
> routing key.  Any solution?
> 
> Joe

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