Re: M3UA: Routing Key and Network Appearance?

"Ilie Glib" <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <[email protected]>
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.