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

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

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.

Tables in ASP:
The LappTable is removed: There is no need to maintain the state of SGs.
The AppSpEpTable is removed: There is no need to maintain the state of SGPs.
The RTTable is renamed as DestTable and converted: Single Table. 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.

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

---

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

Antonio,

I don't think we want to be using NI in the MIB.  NI only has meaning
with respect to a specific MTP linkset and is not a global value
as you have shown it here.

--brian

Antonio Roque-Alvarez (ECE) wrote:                                                 (Wed, 25 Sep 2002 12:03:23)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 25 Sep 2002 08:59:11 -0400

Hi Antonio,

Although they are quite similar with comments from Srivats, still my
comments/questions below.

   Tolga

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Sent: Wednesday, September 25, 2002 6:03 AM
> To: [email-masked]
> 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.
>
[TOLGA] I think that's fine.
> 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
[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
[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.