Subject: RE: [Sigtran] m3ua-mib-04 AS/SG concept

From: "Antonio Roque-Alvarez (ECE)" <[email-masked]>
Date: Wed, 25 Sep 2002 17:14:46 +0200

Hi Tolga,

So let me try to understand:
When an ASP has to send a message, it has to pass it through the LOCAL Routing Table in order to obtain the RC/AS. 
Once the AS is obtained the ASP goes to the Remote Destination Table (indexing with the DPC and the RC/AS) in order to obtain the SG, to send the message to, and check the DPC state (SSNM). 

m3uaDestTable 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| m3uaDestNA (index)								/...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| m3uaDestDPC (index)								/...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| m3uaLocalRC (index)								/...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| m3uaDestSG (index)								/...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Once the SG is obtained the ASP goes to the SGP table (indexing with SG and RC/AS) to obtain the proper SGP (or loadshare group of SGPs) to send the message to.
So my previous SGP table now changes to:

 m3uaSgpTable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| m3uaRcId (index)								/...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| m3uaSgId (index)								/...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| m3uaSpEpId (index)								/...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| m3uaSgpState									/...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| m3uaSgpRowStatus								/...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With this procedural, I don't see the need for the SG table as we are only interested in the state of the destination which is controlled in the DestTable. And the SGPs that belong to an SG are controlled in the SGP table.

Regards,
Antonio

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Wednesday, September 25, 2002 4:42 PM
> To: [email-masked]
> Subject: RE: [Sigtran] m3ua-mib-04 AS/SG concept
> 
> 
> Hi Antonio,
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Antonio Roque-Alvarez (ECE)
> > Sent: Wednesday, September 25, 2002 9:56 AM
> > To: [email-masked]
> > Subject: RE: [Sigtran] m3ua-mib-04 AS/SG concept
> >
> >
> > Hi Srivats, Tolga:
> >
> > I will try to answer both of you in the same mail:
> >
> > - Why do we need the SG info ?
> [TOLGA]I think we need list of SGPs belonging to one SG. And also it
> personally makes to me more sense to keep some tables (like 
> DPC table) per
> SG, instead of per SGP, because SSNM is per SG.
> >
> > - From what I can deduce from your mails and what I have 
> read in the RFC:
> >   - We should maintain an SGP table. This table would represent
> > the state of every SGP per local AS/RC in the ASP. The 
> table would be:
> >
> > m3uaSgpTable
> > 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+
> > | m3uaRcId (index)
> > 	/...|
> > 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+
> > | m3uaSpEpId (index)
> > 	/...|
> > 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+
> > | m3uaSgpState
> > 		/...|
> > 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+
> > | m3uaSgpRowStatus
> > 	/...|
> > 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+
> >
> >   - There should be a LOCAL Routing Table with the Routing Keys
> > of the LOCAL ASs served by the ASP.
> >     This table is used by the ASP:
> >       - To obtain the local AS/RC which the message to be sent
> > belongs to (and include it in the message when applies).
> >       - To obtain the RC of the message received in order to
> > distribute to local ASs.
> [TOLGA] If necessary, received DATA will have RC inside. 
> there is no need to
> do RK analysis on the incoming messages. For outgoing 
> messages depending on
> implementation RK analysis on ASP side might be necessary or 
> not, but at
> least we need to fill RC value, unless we use the association 
> for one RK.
> >     This table is a portion of the whole tables stored in the SGPs.
> >     My question: Should this table be managed by an standard MIB?
> >
> > - Should the Destination table be limited to DPC or should other
> > fields be considered?
> [TOLGA] I always assume, when we refer to DPC, it means 
> DPC+NA. As I stated
> in my previous message, IMO it is better to keep DPC 
> information per SG/AS
> pair, because SSNM is per SG and has RC inside. So, a table 
> with keys DPC+AS
> might be usefull, with fields SG and DPCStatus.
> >   (chapter 1.4.2.5 in the RFC).
> >   Then, should we use a REMOTE Routing Table (the same type of
> > table as in SGPs) instead of this Destination table?
> [TOLGA] I think, two table approach is better for ASP side, 
> one for RK(the
> local AS) and one for DPC.
> >
> >
> > Regards,
> > Antonio
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Wednesday, September 25, 2002 2:59 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] m3ua-mib-04 AS/SG concept
> > >
> > >
> > > Hi Antonio,
> > >
> > > Although they are quite similar with comments from 
> Srivats, still my
> > > comments/questions below.
> > >
> > >    Tolga
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of
> > > > Antonio Roque-Alvarez (ECE)
> > > > Sent: Wednesday, September 25, 2002 6:03 AM
> > > > To: [email-masked]
> > > > Subject: RE: [Sigtran] m3ua-mib-04 AS/SG concept
> > > >
> > > >
> > > > Hi Tolga,
> > > >
> > > > This mail will answer your previous mail as well.
> > > >
> > > > Writing my answer to your first concerns, I was trying to
> > > > remember why I treated the SG as an AS when I modeled 
> the MIB the
> > > > first time (It will be two years ago in December). In that times
> > > > my view was that the AS and SG should behave symmetrically.
> > > > Anyway, thousands of mails have been exchanged and now 
> we have an
> > > > RFC. So I will modulate what we have there.
> > > >
> > > > I propose to modelate in the following way:
> > > >
> > > > Same tables were used for managing SGP/IPSP and ASP. Now,
> > > > different tables will be used:
> > > >
> > > > Tables in SGP/IPSP:
> > > > The LappTable is renamed as the ASTable
> > > > The AppSpEpTable is renamed as the ASPTable
> > > > The RTTable remains the same: Composed by expanded tables that
> > > > make up Routing Keys.
> > > [TOLGA] I think that's fine.
> > > >
> > > > Tables in ASP:
> > > > The LappTable is removed: There is no need to maintain the
> > > state of SGs.
> > > [TOLGA] IMO, it is better to keep SG related info, but 
> probably with a
> > > table, which has a different name.
> > > > The AppSpEpTable is removed: There is no need to maintain the
> > > > state of SGPs.
> > > [TOLGA] We need to keep SGP states per AS. 1.4.2.5 first
> > > paragraph says "The
> > > ASP must also take into account whether the related 
> Routing Context is
> > > active or not (See Section 4.3.4.3)."
> > >
> > > > The RTTable is renamed as DestTable and converted: Single Table.
> > > [TOLGA] I think it is a better idea to keep RK 
> definitions also on ASP
> > > side(depending on application keeping the corresponding
> > > traffic range might
> > > be necessary or not but at least RC info is necessary, also
> > > we should think
> > > about dynamic registration case)
> > > > No expanded tables are used. The table will look like:
> > > >
> > > > m3uaDestTable
> > > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > > +-+-+-+-+
> > > > | m3uaDestNI (index)
> > > > 	/...|
> > > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > > +-+-+-+-+
> > > > | m3uaDestDPC (index)
> > > > 	/...|
> > > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > > +-+-+-+-+
> > > > | m3uaDestSpEp (index)
> > > > 		/...|
> > > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > > +-+-+-+-+
> > > >
> > > > Same destinations will be accessible using different
> > > EndPoints. Example:
> > > >
> > > > NI    DPC     EP
> > > > ----------------
> > > > 2  -  10  =>  1
> > > > 2  -  20  =>  1
> > > > 2  -  30  =>  2
> > > >
> > > > An ASP only needs to control the state of the EndPoint.
> > > [TOLGA]What do you mean exactly by "state of the EndPoint"?
> > > We also should
> > > consider that reachability status of DPC is per SG (SSNM is
> > > per SG) and also
> > > SSNM has RC field inside. It seems to me keeping status
> > > information per
> > > SG/AS for DPCs is inline with RFC.
> > > >
> > > > Common Tables:
> > > > The SpEpTable remains the same.
> > > >
> > > >
> > > > I think this view makes things simpler. Any other views or
> > > > comments in the list ??
> > > >
> > > > Thanks and regards,
> > > > Antonio
> > > >
> > > > > -----Original Message-----
> > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > Sent: Tuesday, September 24, 2002 4:48 PM
> > > > > To: [email-masked]
> > > > > Subject: RE: [Sigtran] m3ua-mib-04 AS/SG concept
> > > > >
> > > > >
> > > > > Hi Antonio,
> > > > >
> > > > >
> > > > > I believe again related with this issue one 
> comment/question about
> > > > > Application-Endpoint Table:
> > > > > (Assuming entries of m3uaAppTable are SGs on ASP side)
> > > > > Application-Endpoint table entries will be SGPs on ASP
> > > side. There is
> > > > > m3uaAppEpState field there ith possible values of
> > > > > active,inactive,down. Now,
> > > > > because ASP can send traffic of multiple RKs to the same
> > > SG (no 1:1
> > > > > relationship between SG and RK), how can we know states of
> > > > > SGPs per AS on
> > > > > ASP side with such a datamodel?
> > > > >
> > > > >     Tolga
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > Tolga Asveren
> > > > > > Sent: Tuesday, September 24, 2002 10:30 AM
> > > > > > To: [email-masked]
> > > > > > Subject: RE: [Sigtran] m3ua-mib-04 AS/SG concept
> > > > > >
> > > > > >
> > > > > > Hi Antonio,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > > Antonio Roque-Alvarez (ECE)
> > > > > > > Sent: Tuesday, September 24, 2002 9:46 AM
> > > > > > > To: [email-masked]
> > > > > > > Subject: RE: [Sigtran] m3ua-mib-04 AS/SG concept
> > > > > > >
> > > > > > >
> > > > > > > Hi Tolga,
> > > > > > >
> > > > > > > I apologize for the so very late response.
> > > > > > >
> > > > > > > So, if I understand you well, you mean that an SG is not a
> > > > > > > Logical Entity and that it does not represent a 
> traffic range.
> > > > > > [TOLGA] My comment about SG not being a "Logical 
> Entity" was in
> > > > > > the context
> > > > > > of MIB document, i.e. that I didn't find it 
> appropriate SG to be
> > > > > > an element
> > > > > > of the "Logical Application Table".
> > > > > > >
> > > > > > > If we look at the definition of Signalling Gateway in
> > > the brand
> > > > > > > new RFC (page 5) we can read: "Where an SG contains
> > > more than one
> > > > > > > SGP, the SG is a logical entity and the...".
> > > > > > >
> > > > > > > Besides, IMHO, an SG represents a traffic range since
> > > the moment
> > > > > > > that a set of traffic that want to reach some
> > > destinations in the
> > > > > > > SS7 network will be routed to a specific SG.
> > > > > > >
> > > > > > > My modeling view here is that what a Signalling
> > > Process sees (as
> > > > > > > remote elements) is set of "Logical Entities" where
> > > to route/send
> > > > > > > traffic to. In the ASP case the "logical entities"
> > > are SGs and in
> > > > > > > the SGP/IPSP case they are ASs.
> > > > > > [TOLGA]But even if you take this view, there is no 1:1
> > > > > > realtionship between
> > > > > > traffic ranges and SG , whereas there is between AS 
> and traffic
> > > > > > ranges. For
> > > > > > example on ASP side, how will the m3uaRouting table look
> > > > > like if ASP is
> > > > > > connected to multiple SGs? Separete entries for each of
> > > > > them? Personally I
> > > > > > wouldn't prefer this approach.
> > > > > > >
> > > > > > > Basically the "logical entity" is the result of an
> > > operation in
> > > > > > > the routing table.
> > > > > > >
> > > > > > > Thanks and regards,
> > > > > > > Antonio
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > > Sent: Thursday, September 05, 2002 8:27 PM
> > > > > > > > To: [email-masked]
> > > > > > > > Subject: [Sigtran] m3ua-mib-04 AS/SG concept
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Antonio,
> > > > > > > >
> > > > > > > >
> > > > > > > > IMO, thinking a "Logical Application" as either 
> AS or SG is
> > > > > > > > not the most
> > > > > > > > correct way of modelling. SG does not represent 
> a traffic
> > > > > > > > range but AS does.
> > > > > > > > So, I think it is better to think "Logical
> > > Application Table"
> > > > > > > > as the entity
> > > > > > > > corresponding to AS at both ASP nodes and SGP nodes (of
> > > > > course IPSP as
> > > > > > > > well).
> > > > > > > >
> > > > > > > >        Tolga
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Sigtran mailing list
> > > > > > > > [email-masked]
> > > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Sigtran mailing list
> > > > > > > [email-masked]
> > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > >
> > > > > > _______________________________________________
> > > > > > Sigtran mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 25 Sep 2002 12:04:09 -0400

Hi Antonio,

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Sent: Wednesday, September 25, 2002 11:15 AM
> To: [email-masked]
> When an ASP has to send a message, it has to pass it through the
> LOCAL Routing Table in order to obtain the RC/AS.
> Once the AS is obtained the ASP goes to the Remote Destination
> Table (indexing with the DPC and the RC/AS) in order to obtain
> the SG, to send the message to, and check the DPC state (SSNM).
>
> m3uaDestTable
[TOLGA] I think there should be a status field in this table(as far as I
understand from your above explanation, you also think it is necessary, so I
believe just a typo(?)) Multiple SGs might be configured/used for the same
DPC/AS pair. So, isn't it better to keep the key as NA+DPC+RC by excluding
SG from the key? What do you think?
>
> Once the SG is obtained the ASP goes to the SGP table (indexing
> with SG and RC/AS) to obtain the proper SGP (or loadshare group
> of SGPs) to send the message to.
> | m3uaSgId (index)
[TOLGA] IMO, it is better to have RC+SG as key, because of a similar reason
as explained above.
>
> With this procedural, I don't see the need for the SG table as we
> are only interested in the state of the destination which is
> controlled in the DestTable. And the SGPs that belong to an SG
> are controlled in the SGP table.
[TOLGA] In fact what I meant was, to know somehow, to which SG SGPs are
belonging to. You are right, with m3uaSgId in m3uaSgpTable and with
m3uaDestTable as above, one can live without an additional SGTable.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 25 Sep 2002 13:43:47 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 25 Sep 2002 12:04:09)
> SG from the key? What do you think?

RC has no significance unless the SG is included.  RC assignments
are local to an SG.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 25 Sep 2002 16:00:46 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, September 25, 2002 3:44 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] m3ua-mib-04 AS/SG concept
>
>
> Tolga,
>
> Tolga Asveren wrote:
[TOLGA] Yes, you are right, I oversaw this So, maybe replacing m3uaLocalRC
with m3uaAsId might be better. This will enable to have the key as
NA+DPC+AsId.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 25 Sep 2002 14:25:31 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 25 Sep 2002 16:00:46)
> with m3uaAsId might be better. This will enable to have the key as

What's an AsId ?

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 25 Sep 2002 16:58:09 -0400

Brian,

> > with m3uaAsId might be better. This will enable to have the key as
[TOLGA] A value, internally unique on ASP for AS/RK -unlike RC-. Call it
AsId, or RkId or whatever you like. If m3uaRouting table on ASP side will be
similar to what it currently stands in MIB document, I think it will be
called m3uaRKId.