Subject: Re: [Sigtran] m3ua- IG

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 10 Jan 2003 11:29:14 +0200

Brian,
--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> TOLGA,
>
> TOLGA ASVEREN wrote:
>                                 (Fri, 10 Jan 2003
> 10:47:09)
> >
> > Brian,
> > --- "Brian F. G. Bidulock" <[email-masked]>
> wrote:
> > > TOLGA,
> > >
> > > TOLGA ASVEREN wrote:
> > >                                 (Fri, 10 Jan
> 2003
> > > 10:18:25)
> > > >
> > > > [TOLGA] For class0/class1 SCCP SSN based RKs
> seems
> > > to me doable. SSN state
> > > > can be kept on SG based on AS status, and also
> > > routing of management
> > > > messages probably won´t be very difficult for
> the
> > > ones destined for a
> > > > specific subsystem.
> > >
> > > Routing of management messages is impossible in
> an
> > > interoperable way.
> > > Where they should go is niether specified nor
> > > obvious from the point
> > > of view of using SSN for routing.  The ASP must
> know
> > > where and when it
> > > will receive SCCP management messages to be
> > > interoperable.  M3UA does
> > > not specify this, and so SSN routing keys are
> not
> > > supported.
> > [TOLGA] Why should ASP know anything special not
> defined in RFC? It serves
> > an AS for a specific DPC+SSN and it is SGs
> responsibility to distribute
> > messages properly -including management messages-.
> One can look to SCCP
> > management message and decide for which SSN it is
> send.
>
> That would not be using the SSN in the messaage
> (which is SSN=0), that
> would be using the ASSN.  Also, you would need to
> use the APC rather than
> the DPC in the message.  These things are not even
> mentioned for M3UA.
[TOLGA] This is precisely what I mean with implementation dependent: how RK
analysis is done.
>
> Also, where does it say that the ASP registered with
> SSN=5 is the "rignt"
> place to send SCCP management messages?
[TOLGA] Each AS should receive management messages sent for the SSN it
serves. Only management messages sent for the whole SCCP need to be
replicated.
>
> --brian
>
>
> > >
> > > > A MSU containing SCCP congestion message needs
> to
> > > be
> > > > mapped to multiple DATA messages. One can
> argue
> > > that this violates some of
> > > > the paragraphs in RFC (the ones you pointed
> out,
> > > that one MSU should be
> > > > mapped to one DATA), but in fact this really
> does
> > > not bring a real
> > > > interoperability problem, because it does not
> > > require any special behaviour
> > > > from the peer. But still I would think a
> > > clarification sentence saying that
> > > > it might be necessary to map one MSU to
> multiple
> > > DATA to support non-MTP3
> > > > RKs, could be helpfull.
> > > >
> > > > BTW, I agree for most of the changes you
> propose.
> > > IMO it is not a problem
> > > > to delete SSN examples but I prefer that RK
> types
> > > are kept flexible.
> > >
> > > Then the IG changes I proposed should meet with
> your
> > > approval.
> > [TOLGA] I don´t think the changes require any
> approval from me :) But yes,
> > I don´t think, they bring any restriction.
>
> Then do you support them?
[TOLGA] Yes, to prevent a possible confusion for newcomers and to not
repeat this discussion again. I also believe, a sentence about the
necessity for a management funtionality for non-MTP3 RK types migth be
usefull.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Jan 2003 02:41:12 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Fri, 10 Jan 2003 11:29:14)
> serves. Only management messages sent for the whole SCCP need to be

Where does it say that?  Valerie thinks that SSN=0 should be
registered for as a separate broadcast AS.  Your diverging
view are an excellent example of why interoperability will not
result.

--brian

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