RE: M3UA: Routing Key and Network Appearance?

Dario,

I think the reason could be described as a mix of history and compromise.
Technically, RC implies NA.

  Thanks,
  Tolga


-----Original Message-----
From: Dario Filjar [mailto:[email protected]]
Sent: Tuesday, January 16, 2007 6:35 AM
To: [email protected]; [email protected]
Subject: RE: [Sigtran] M3UA: Routing Key and Network Appearance?


Hi Tolga, Brian, Ilie and others,

thanks for this clarification.
Just one short question: what is the purpose of NA parameter in DATA and
SSNM (DUNA, DAVA, DAUD, SCON, DUPU, DRST) messages.
I can only clearly see the purpose of NA in RKM message (Registration
Request) and ERROR message.

thanks in advance.
Kind regards, Dario


Tolga Asveren <[email protected]> wrote:
Ilie,

I don't know what was the purpose to update the explanation for Network
Appearence in 3.6.1. (not that I think the RFC3332 version was complete and
clear) and don't think the current text makes sense and I see no reason why
there should be an exception to "RKs can't span SPMCs" rule. One can really
try to provide that type of "flexibility", i.e. allowing traffic for more
than one network on the same association without using routing keys but IMO
it just is confusing and can create interoperability problems and what's the
big deal with using RCs? I think the type of operation described in 3.6.1
Network Appearence (not to be confused with not using RC in messages if
association is used for traffic for only a single RK) simply is unnecessary
and is against the principle of M3UA being an interface mimicing
MTP3/MTP3-User Part interface.

Just stick to the "RK's can't span SPMC" principle and everything is clear
again ;-) (I agree with you though, that the text in 3.6.1 is confusing and
IMHO even wrong).

Thanks,
Tolga


> -----Original Message-----
> From: Ilie Glib [mailto:[email protected]]
> Sent: Wednesday, January 10, 2007 9:47 AM
> To: Tolga Asveren
> Cc: Dario Filjar; [email protected]
> Subject: Re: [Sigtran] M3UA: Routing Key and Network Appearance?
>
>
> Tolga,
>
> I am sorry, my last mail was not so clear.
> The conflict that I see is between statement:
>
> > > > > (section 3.6.1.)
> > > > > Network Appearance: ...."If the Network Appearance is not
> > > > specified and the
> > > > > Routing Key applies to all Network Appearances, then this
> > > > Routing Key MUST
> > > > > be the only one registered for the association; that is,
> > > > Routing Context is
> > > > > implied and DATA and SSNM messages are discriminated on Network
> > > > Appearance
> > > > > rather than on Routing Context"
>
> (which I interpret as a description of a case where an RC/RK defines a
> traffic range that belongs to more than one Network, I read this
> statement as it is allowed to use more than one NA per RC)
>
> and the statements
>
> > > > > (section 1.2):
> > > > > Routing Key: ....."Parameters within the Routing Key cannot
> > > > extend across
> > > > > more than a single Signalling Point Management Cluster".
>
> > > > > (section 3.7.1.)
> > > > > Routing Context: ...."There is one-to-one relationship
> between an index
> > > > > entry and an SGP Routing Key or AS Name. Because an AS can only
> > > > appear in
> > > > > one Network Appearance, the Network Appearance parameter is not
> > > > required in
> > > > > ASP Active message"
>
> while the latter two statements say that it can be only one NA per RC.
>
> Since only the first statement is normative, multiple NAs per RC
> are allowed.
> Am I correct in my interpretation?
>
> Regards
>
> /Ilie
>
>
> On 1/10/07, Ilie Glib wrote:
> > Hello Tolga,
> >
> > obviously definitions of concepts for NA, RK, RC do not match some
> > mandatory statements in the M3UA RFC. I interpret it as a problem,
> > isn't it correct?
> >
> > Of course implementors shall follow normative statements in the RFC,
> > although they are in contradiction with some definitions in the RFC.
> >
> > Tolga, I can agree with you, if you say that implementations that
> > follow normative statements in the RFC are interoperable. However, it
> > means that those implementations do not comply with the definitions in
> > the RFC.
> >
> > Regards
> >
> > /Ilie
> >
> > On 1/10/07, Tolga Asveren wrote:
> > > Hi Ilie,
> > >
> > > What problems are there with NA in M3UA? AFAIK, there aren't any.
> > >
> > > Thanks,
> > > Tolga
> > >
> > > > -----Original Message-----
> > > > From: Ilie Glib [mailto:[email protected]]
> > > > Sent: Wednesday, January 10, 2007 6:16 AM
> > > > To: Dario Filjar
> > > > Cc: [email protected]
> > > > Subject: Re: [Sigtran] M3UA: Routing Key and Network Appearance?
> > > >
> > > >
> > > > Hello Dario,
> > > >
> > > > Well, in order to not have problems with NA, I suggest you use SUA,
> > > > since it does not allow sending NA parameter in its messages, except
> > > > for ERROR and RKMM. Network Context is determined by RC
> values. Thus,
> > > > there is no NA related problems in SUA.
> > > >
> > > > But M3UA is more mature than SUA, therefore, I believe, SUA has much
> > > > more problems than M3UA.
> > > >
> > > > Regards
> > > >
> > > > /Ilie
> > > >
> > > > On 1/4/07, Dario Filjar wrote:
> > > > > Hi,
> > > > > I have some difficulties to understand the relation between
> > > > Routing Key and
> > > > > Network Appearance.
> > > > >
> > > > > At first, it seems that one AS belongs to single network only.
> > > > > This opinion is supported by the following statements
> from the RFC4666:
> > > > >
> > > > > (section 1.2):
> > > > > Routing Key: ....."Parameters within the Routing Key cannot
> > > > extend across
> > > > > more than a single Signalling Point Management Cluster".
> > > > >
> > > > > Signalling Point Management Cluster: the complete set of
> > > > Application Servers
> > > > > represented to the SS7 network under a single MTP entity
> > > > (Signalling Point)
> > > > > in one specific Network Appearance."
> > > > >
> > > > > (section 3.7.1.)
> > > > > Routing Context: ...."There is one-to-one relationship
> between an index
> > > > > entry and an SGP Routing Key or AS Name. Because an AS can only
> > > > appear in
> > > > > one Network Appearance, the Network Appearance parameter is not
> > > > required in
> > > > > ASP Active message"
> > > > >
> > > > >
> > > > > However some statement support the opposite, that is, AS
> (represented by
> > > > > Routing Key) in more than one Network Appearance:
> > > > >
> > > > > (section 3.6.1.)
> > > > > Network Appearance: ...."If the Network Appearance is not
> > > > specified and the
> > > > > Routing Key applies to all Network Appearances, then this
> > > > Routing Key MUST
> > > > > be the only one registered for the association; that is,
> > > > Routing Context is
> > > > > implied and DATA and SSNM messages are discriminated on Network
> > > > Appearance
> > > > > rather than on Routing Context"
> > > > >
> > > > > Here it is explicitly stated that RK can apply to more
> than one Network
> > > > > Appearance.
> > > > >
> > > > > There is another statement which not only supports the
> > > > AS-in-multiple-NAs
> > > > > theory, but also possibly (does it?) supports idea of having
> > > > multiple SCTP
> > > > > Associations between SG and ASP:
> > > > >
> > > > > (section 3.3.1)
> > > > > Network Appearance: ...."Where an SG operates in the context of
> > > > a single SS7
> > > > > network, or if individual SCTP associations are dedicated
> to each SS7
> > > > > network
> > > > > Context, the Network Appearance is not required"
> > > > >
> > > > > Can you please comment on that?
> > > > > Thanks!
> > > > > Kind regards,
> > > > > Dario
> > > > >
> > > > > __________________________________________________
> > > > > Do You Yahoo!?
> > > > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > > > http://mail.yahoo.com
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email protected]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Ilie
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email protected]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > >
> >
> >
> > --
> > Ilie
> >
>
>
> --
> Ilie


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





Don't be flakey. Get Yahoo! Mail for Mobile and
always stay connected to friends.