Subject: [Sigtran] RE: Re: M3UA v11 - Network appearance and Affected Point Codes in DUNA / DAVA

From: "Schantz, John" <[email-masked]>
Date: Tue, 29 Jan 2002 13:41:18 -0600

I'll jump in here since I didn't receive all of the messages in this thread.

If your node has a well behaved system that manages all remote PCs from a common process, then receiving a DUNA per RC or receiving a DUNA with multiple RCs is actually a waste of messages or information.  Its only in the case where you manage remote status information differently for some or each of the RCs do you need to get a DUNA per RC or receive a DUNA with multiple RCs.  In the latter case, you also have to be careful because some associations do not handle traffic for some RCs, hence, sending a DUNA with an unknown RC might be discarded and the association that do handle the RC don't receive a DUNA.  You may be better off sending a DUNA per RC to make sure that all of the management processes for the "node" has received one.

Now lets move on to NA.  I would prefer to manage networks (network appearances) separately.  Also what is the probability that an event will case status changes in multiple networks.  If it does happen, I would rather handle the status changes per network in separate SSNMs.

Please don't try to bring up the old debate between NA and RC.  There are plenty of systems that don't need RC but need NA when they are members of multiple networks.

John

-----Original Message-----
From: Li Li [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 11:28 AM
To: sigtran
Subject: RE: Re: M3UA v11 - Network appearance and Affected Point Codes
in DUNA / DAVA

Tolga,

I think what you argues in this email about the NA, either removing
or having multiple is quite a nice idea. You think it would
have any move towards this direction?

As what we've agreed upon in our implementation, correct me if I'm
wrong, we'd make both RC and NA configurable as either enabled or disabled. 
By default, it is disabled, which means that we don't put the NA or the RC 
in the message. But somehow, I'd think that RC should be put in the message.

Would you please help me out here as why RC is not needed either. If it
is configured to be "enabled", we should put RC or NA in the 
message. But should we put both RC and NA or always just one of them?
If configured as enabled, they should configure what we put there for 
RC or NA, is that right?

Sorry about these stupid questions. I'm still very blurry on the protocol
as I haven't managed to spend any time on them. Can only depend
on your expert opinions on them. Many thanks for your help in advance!

Cheers,

li

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 25, 2002 1:14 PM
> To: sigtran
> Cc: [email-masked]
> Subject: RE: Re: M3UA v11 - Network appearance and Affected 
> Point Codes
> in DUNA / DAVA
> 
> 
> Manfred,
> 
> In fact because RC is already in those messages (SSNM) 
> present and because
> it implicitly identifies also the network, NA is not 
> necessarily needed -at
> least in my opinion- in those messages. RC is enough to determine the
> network for affected PCs. But I agree that it is a little bit 
> strange that
> only one NA is existing in the message but affected PCs can belong to
> different networks. A nicer solution would be to remove NA or to allow
> multiple NAs in the message.
> 
>      Tolga
> 
> 
> > -----Original Message-----
> > From:   "Brian F. G. Bidulock" <[email-masked]>
> > Sent:   Friday, January 25, 2002 1:02 PM
> > To:     "sigtran" <[email-masked]>
> > Cc:     [email-masked]
> > Subject:     Re: M3UA v11 - Network appearance and Affected
> > Point Codes in DUNA / DAVA
> >
> >  Angermayr,
> > Angermayr Manfred wrote:                     (Fri, 25 Jan
> > 2002 06:51:15)
> > >
> > > Hello,
> > >
> > > I am a little bit confused about the affected point codes
> > and network
> > > appearances. In v10, chapter 3.4.1 there was a note, that
> > all Point Codes
> > > must be within the same network appearance. Unfortunately
> > this note was
> > > removed in v11.
> > >
> > > How should this work, if the affected point codes are
> > within different
> > > network appearances? There is only one NA parameter in the
> > DUNA message, so
> > > it can not be used in this case - but it is only optional anyway.
> > >
> > > Now assume that there are two different network appearances. RC 1
> > > (describing an RK of OPC 100, valid for all DPCs) is
> > defined within NA 1, RC
> > > 2 describing an RK of OPC 200, valid for all DPCs) is
> > defined within NA 2.
> > >
> > > In both networks the point codes 300 and 400 are known.
> > >
> > > Now I receive a DUNA, containing RC 1 and RC 2 and the
> > affected point codes
> > > 300 and 400. Do I consider 300 and 400 unavailable in both NAs?
> > Yes.
> > > Or do I
> > > assign the first affected PC to the first RC and the second
> > affected PC to
> > > the second RC? Does not work, if I get 2 RCs but 3 
> affected PCs ...
> > >
> > > Assume, that NA 1 and NA 2 have a different point code
> > format. How do I
> > > know, the PC format that is used for the different affected
> > point codes?
> > The PC format is implied by NA by RC.
> > >
> > > Is it really allowed and necessary to mix the affected
> > point codes of
> > > different networks within 1 DUNA messages? Why was the note
> > mentioned above
> > > removed?
> > Is it really necessary to restrict it?  There are a number of
> > circumstances
> > where signalling points have the same numerical point code 
> in multiple
> > networks (National and Private).
> > >
> > > In my opinion it should be written in the draft, that it
> > MUST be prohibited
> > > that different NAs are mixed within a single DUNA / DAVA /
> > DRST and SCON.
> > That would require the generation of two SNMM messages for an event
> > concerning a signle signalling point as above.  I disagree.
> > --brian
> > >
> > > By the way, the info string parameter is missing in the
> > error and all the
> > > registration messages. I think there is no reason, why it
> > should not be also
> > > part of this message class.
> > >
> > > Regards,
> > > Manfred
> > >
> > >
> > > ---
> > > You are currently subscribed to sigtran as: [email-masked]
> > > To unsubscribe send a blank email to
> > [email-masked]
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> 
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

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

---

From: [email-masked]
Date: Tue, 29 Jan 2002 12:20:33 -0800

Hi John,

You didn't miss anything on this thread, just because of my fault an
company-internal message has reached SIGTRAN list. I apologize for this.

    Tolga

> From:   "Schantz, John" <[email-masked]>
> Sent:   Tuesday, January 29, 2002 2:59 PM
> To:     [email-masked];"sigtran"
> <[email-masked]>;"sigtran-old"
> <[email-masked]>
> Cc:
> Subject:     [Sigtran] RE: Re: M3UA v11 - Network appearance
> and Affected Point Codes in DUNA         / DAVA
>
> If your node has a well behaved system that manages all
> remote PCs from a common process, then receiving a DUNA per
> RC or receiving a DUNA with multiple RCs is actually a waste
> of messages or information.  Its only in the case where you
> manage remote status information differently for some or each
> of the RCs do you need to get a DUNA per RC or receive a DUNA
> with multiple RCs.  In the latter case, you also have to be
> careful because some associations do not handle traffic for
> some RCs, hence, sending a DUNA with an unknown RC might be
> discarded and the association that do handle the RC don't
> receive a DUNA.  You may be better off sending a DUNA per RC
> to make sure that all of the management processes for the
> "node" has received one.
> Now lets move on to NA.  I would prefer to manage networks
> (network appearances) separately.  Also what is the
> probability that an event will case status changes in
> multiple networks.  If it does happen, I would rather handle
> the status changes per network in separate SSNMs.
> Please don't try to bring up the old debate between NA and
> RC.  There are plenty of systems that don't need RC but need
> NA when they are members of multiple networks.
> John

---

From: [email-masked]
Date: Tue, 29 Jan 2002 12:17:35 -0800

John,

During RC discussions, I remember that the configuration below was accepted
as a valid one - at least nobody could say it is a not-existing
configuration-, correct me please if I am wrong.
The reason you are mentioning -ASPs servicing somewhat independent AS sets-
is not a valid one according to me, to make RC mandatory in SSNM messages.
In such a case, it would be responsibility of SG, to send SSNM to the
appropriate ASPs, based on the ASs they are serving.
But I think, even just making SSNM format similar to other messages is a
good argument to include RC in those messages. Afterall, if we always want
to rely on very strong arguments and if we are realy so picky, what could
be a good reason to include NA in DATA?

    Tolga

> Sent:   Tuesday, January 29, 2002 2:49 PM
> Subject:     RE: Re: M3UA v11 - Network appearance and
> Affected Point Codes in DUNA          / DAVA
>
> > > [email-masked]
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > ---
> > > [email-masked]
> >
> >
> >
> >
> > ---
> > [email-masked]
> >
> ---
> [email-masked]
> ---
> [email-masked]