RE: ASP Capabilities value 0x2 of interworking field

Brian,

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Tuesday, December 20, 2005 10:25 AM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] ASP Capabilities value 0x2 of interworking field
>
>
> Tolga,
>
> Tolga Asveren wrote:
>    (Tue, 20 Dec 2005 09:51:14)
> > Brian,
> >
> > > > > Interconnect is not done at the core of the network.  GTT
> is.  No self
> > > > > respecting SS7 network operator would connect your SUA
> junk to their
> > > > > primary STPs any day soon.  Lot's o' luck.
> > > > [TOLGA]I think you also agree that there is a need to
> organize networks
> > > > hierachicaly and for that reason we need relaying. That hierarchical
> > > > organization can depoend on different SS7 constructs depending
> > > on the needs
> > > > of the operator, e.g. GTT, and entities supporting relay
> can be deployed
> > > > anywhere in the network again depending on the needs.
> > >
> > > And so SUA permits any node to have the relay capability in
> the IP domain.
> > [TOLGA]I don't see how this can happen just by definition of
> IPSP or why we
> > should use IPSP by communicating with a node, which is relaying
> messages. In
> > any case, I think this is an architectural issue, which needs to be
> > discussed/clarified throughly.
>
> Not an issue at all.  Any node in the SS7 network can be an SCCP
> relay point
> as well.
[TOLGA]What about in IP domain? The goal with the protocols is to define a
sound architecture, which allows interoperability and does not allow room
for ambiguity. IMO allowing IPSP functionality to allow relaying is against
those principles. I also want to reemphasize that here we are speaking of
different roles played by SUA stack, i.e. we can have SUA-node which can
both relay and use IPSP communication. What we are discussing is, where
those different functionalites should reside.
>
> > >
> > > > [TOLGA]I disagree with you. It allows hierarchical
> organization/easier
> > > > configuration of the network and also backhauling SS7 traffic
> > > over IP. If
> > > > you look to other IP based protocols, which are supposed to be
> > > used between
> > > > core network entities, you will see similar capabilities as
> well, e.g.
> > > > Diameter. Probably, I should quote one of your favorites: "If
> > > you don't want
> > > > it, do not use it"
> > >
> > > STPs act a link concentrators.  When there are no links,
> there is no need
> > > for concentration.  MTP relay in the IP domain is pointless.
> > [TOLGA]I again have to disagree with you. STPs do perform more than just
> > link concentration, e.g. message routing. In IP domain, if you
> have direct
> > connections between each entity, any change in the configuration could
> > effect the whole network, and most people wouldn't like this at all. By
> > centralizing certain routing decisions, one can limit necessary
> changes to
> > those centralized entities. Furthermore, one could like to have relay to
> > backhaul SS7 traffic over IP or to have a single interface
> between different
> > administrative domains where some screening based on SS7
> constructs could be
> > performed. As I indicated before, relay is a common concept for IP-based
> > protocols as well, if they are going to be used between core network
> > enitites.
>
> For M3UA relaying in the IP domain, use BGCP, firewalling, NAT, other
> middlebxes, at the routers.  You don't need to fabricate the concept of
> an SS7 router (STP) in the IP network to perform its functions.  Those
> functions are already performed by IP.
[TOLGA]People usually want/need to perform the organization/security checks
based on the constructs of the protocol, which is payload from IP point of
view, e.g. SS7 constructs, hence there is the need to have entities working
on application layer from IP point of view. In any case, this is really
besides the point for this thread.
>
> --brian
>
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>