Subject: RE: [Sigtran] IPSP issues

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 22 Apr 2002 18:44:00 +0200

Well, I see this as the beginning of a long discussion...  ;-)

The M3UA does not define the relationship of two endpoints, IMO M3UA defines:
	- A protocol to transport the SS7-like signaling information over IP

When you talk about signaling over IP you can find two different scenarios:
	- Communication of a traditional SS7 node with an IP-based node thru a frontier node. i.e.transition from SS7 network to IP network: SG-AS scenario
	- Communication of two IP-nodes that have an SS7 user over them: IPSP-IPSP scenarios

This is the beginning of the whole discussion. These were the main two requirements that 3G telephony networks put on the table at the beginning of times. I mean, there is not a need to define the nodes themselves, but the means to communicate them. 

I need to have a clear idea how to communicate two nodes that are IP-based. It doesn't matter how I build them. I just want to have a protocol definition standardized. As you say if you put one or two SG functionalities inside a physical node is my problem and my internal architecture election. 

Another way of seeing this: why don't you consider to separate the SG as two nodes: an SS7 node and an IP node. AFterthat you can define a common protocol to communicate them and you can say that you don't need to define a SG but a protocol to be used between an IP node and an SS7 node. Each implementation can elect how to implement this: one, two or even three separate physical nodes??

Cheers // Javier.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Monday, April 22, 2002 6:27 PM
> To: [email-masked]
> Subject: RE: [Sigtran] IPSP issues
> 
> 
> Javier,
> 
> I think one of the differences in our approaches is , what 
> the protocol
> should define. In my opinion, the protocol just defines the 
> relationship
> between two endpoints. So, in one node, you can put whatever 
> functionality
> you want (and inside your node, you can have propriatery 
> interfaces between
> them). You can even think and implement them as one 
> functionality, as long
> as your endpoints behave according to the protocol. So, based 
> on this, I
> don't understand what is the difference to rely just on SGP/ASP
> functionalities or to combine them and rename this as IPSP.
> Basically, what I am saying is, we shouldn't try to define 
> "node types" but
> we should define just the relationship between endpoints.
> 
>    Tolga
> 
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:[email-masked]]
> > Sent: Monday, April 22, 2002 12:03 PM
> > To: 'Tolga Asveren'; [email-masked]
> > Subject: RE: [Sigtran] IPSP issues
> >
> >
> > Hi Tolga,
> >
> > Thanks a lot for this nice summary. It looks like a good approach
> > to start discussion....  :-D
> >
> > Basically, what I see, is that you want to remove the IPSP (let's
> > say direct IP-node to IP-node) communication and communicate two
> > different IP-nodes using a SG in the middle. I think that it may
> > be OK for whenever those specific scenarios happen.
> >
> > But I also need a direct IP-node to IP-node communication. I
> > don't want to have always an SGP in the middle. IP-node to
> > IP-node (IPSP-IPSP or ASP-ASP or whatever you can call it) is a
> > very important scenario for the IP telephony network that MUST be
> > considered, since it is the end of the nodes evolution to the
> > all-IP world.
> >
> > IMO ASP-SGP-ASP communication is a very particular scenario that
> > has to be avoided whenever it is possible to have ASP-ASP. We
> > need to be efficient and not use more resources than needed...  :-D
> >
> > Then I see this contribution as a good one, but I don't think
> > that this is against the IPSP communication. It's one more
> > scenario that can be considered as application for the M3UA 
> protocol.
> >
> >
> > Cheers // Javier.
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Monday, April 22, 2002 3:44 PM
> > > To: [email-masked]
> > > Subject: [Sigtran] IPSP issues
> > >
> > >
> > > Javier,
> > >
> > > Probably after this brief overview, what was discussed in
> > > IPSP list, it is
> > > more clear why I said, there are no extra explanations
> > > necessary in IG for
> > > IPSP mode. The decision there was, a new process type 
> -IPSP- is not
> > > necessary. In fact, also the first discussions about IPSP
> > > mode were going to
> > > that direction, but time did not allow to finish those.
> > > In my opinion, the only thing necessary in IG related with
> > > IPSP is, to say
> > > that it is no more needed.
> > >
> > >     Tolga
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of
> > > > Tolga Asveren
> > > > Sent: Thursday, April 18, 2002 9:32 PM
> > > > To: [email-masked]
> > > > Subject: [Sigtran] inter-IP communciation
> > > >
> > > >
> > > > Hi,
> > > >
> > > >
> > > > I will try to give a brief overview what was discussed and
> > > agreed (again
> > > > just from my point of view) in IPSP list. It will have only
> > > the general
> > > > ideas, because I wanted to send something quickly so that
> > > we can decide
> > > > where to put this information (of, course first let's 
> see whether
> > > > everybody
> > > > likes the listed ideas or not), the real draft itself -if
> > > > necessary-, I will
> > > > try to submit soon but the following will probably be
> > > enough to understand
> > > > the proposed approach. (I will explain in more detail how
> > > the models are
> > > > working, put more examples and try to discuss about
> > > > advantages/disadvantages
> > > > of each proposed method. Especially for  inter-IP 
> communication with
> > > > multiple SGPs case, more explanation is necessary but because it
> > > > corresponds
> > > > what was called before to double-ended approach, I think
> > > people won't have
> > > > big difficulty to get the idea)
> > > >
> > > > In my opinion, the most important decision in the IPSP
> > > discussions was to
> > > > base inter-IP communication on existing ASP/SGP
> > > fuctionalities, where no
> > > > additonal IPSP functionality is defined.
> > > >
> > > >
> > > >     Tolga
> > > >
> > > >
> > > >
> > > >
> > > > Inter-IP Communication
> > > > ========================
> > > > 1.Overview
> > > > The purpose of this document is to recommend methods of inter-IP
> > > > communication for UA peers, based on the functionalities already
> > > > defined in
> > > > the corresponding RFCs/drafts and SG-SG communication, as
> > > > described in draft
> > > > [.....].
> > > > The strategy is, making use of alredy defined SGP/ASP
> > > functionalities and
> > > > SG-SG communication, rather than defining a new functionality
> > > > type (that is
> > > > the reason, why I think, it is more appropriate to call it
> > > > inter-IP, instead
> > > > of IPSP)
> > > >
> > > >
> > > > 2.Inter-IP Communication Methods
> > > > 2.1 Inter-IP Communication with SG-SG Protocol
> > > >      -----              -----
> > > >    //     \\          //     \\
> > > >   |  ASP    |        |  ASP    |
> > > >   |  Cloud 1|        |  Cloud 2|
> > > >    \\     //          \\     //
> > > >      --+--              --+--
> > > >        |                  |
> > > >        |                  |
> > > >     +--+--+            +--+--+
> > > >     | SG1 +------------+ SG2 |
> > > >     +--+--+            +--+--+
> > > >        |                  |
> > > >        |                  |
> > > >        |                  |
> > > >        |     +-----+      |
> > > >        +-----+ SG3 +------+
> > > >              +--+--+
> > > >                 |
> > > >                 |
> > > >               --+--
> > > >             //     \\
> > > >            |  ASP    |
> > > >            |  Cloud 3|
> > > >             \\     //
> > > >               -----
> > > > Figure 1. Inter-IP communication with SG-SG protocol
> > > >
> > > >
> > > > This method uses SGP/ASP functionalities as defined in
> > > corresponding RFCs
> > > > for UAs. Communication between SGs is based on SG-SG
> > > communication as
> > > > defined in draft[...]. For that reason, this method is only
> > > applicable for
> > > > UAs, for which SG-SG protocol is defined (so, currently
> > > just for M3UA).
> > > > It should be noted that in this method, configuration
> > > changes or dynamic
> > > > status changes (AS/ASP state changes, RK definitions
> > > etc....)in ASP clouds
> > > > are transparent to other ASP clouds, as long as they 
> don't affect
> > > > the status
> > > > of SPMC.
> > > >
> > > >
> > > > 2.2 Inter-IP Communciation with one SGP
> > > >  +------+     +------+      +------+
> > > >  | ASP1 |     | ASP2 |      | ASP3 |
> > > >  +---+--+     +--+---+      +--+---+
> > > >      |           |             |
> > > >      |           |             |
> > > >      |           |             |
> > > >      |           |             |
> > > >      |           |             |
> > > >      |        +--+---+         |
> > > >      +--------+ SGP1 +---------+
> > > >               +------+
> > > > Figure 2. Inter-IP communication with one SGP
> > > >
> > > > This method uses SGP/ASP functionalities as defined in the
> > > corresponding
> > > > RFCs for UAs. It does not need any additional
> > > functionality, so should be
> > > > considered only as a sample configuration of the already
> > > defined SGP/ASP
> > > > functionalities.
> > > >
> > > >
> > > >
> > > > 2.3 Inter-IP Communication with multiple SGPs
> > > >
> > > >  +-----+           +-----+
> > > >  |ASP1 +-----------+SGP2 |
> > > >  +--+--+           +--+--+
> > > >     |                 |
> > > >     |                 |
> > > >     |                 |
> > > >  +--+--+           +--+--+
> > > >  |SGP1 +-----------+ ASP2|
> > > >  +-----+           +-----+
> > > > Figure 3. Inter-IP communication with multiple SGPs
> > > >
> > > >
> > > > This method uses SGP/ASP functionalities as defined in the
> > > corresponding
> > > > RFCs for UAs. It does not need any other functionality, 
> so should be
> > > > considered only as a sample configuration of the already
> > > defined SGP/ASP
> > > > functionalities.
> > > > In this method, associations between peers is used in a
> > > > unidirectional way,
> > > > unlike the regular SGP/ASP case. The interfaces between
> > > ASP1/SGP1 and
> > > > ASP2/SGP2 may be implemented with a proprietarty method. ASPs
> > > > should be able
> > > > to know, which SGPs to use to send out messages for a
> > > specific AS. For
> > > > example a message from ASP1 to ASP2 will go through the
> > > following steps:
> > > > 1-ASP1 sends the message to SGP1 (based on RK, ASP1 knows, to
> > > > which SGP the
> > > > message should be sent)
> > > > 2-SGP1 sends the message to SGP2 (based on RK, SGP1 knows, to
> > > > which ASP the
> > > > message should be sent)
> > > >
> > > > It should be noted, both ASPs and SGPs differentiate between
> > > > peers not only
> > > > based on RKs, but also on the direction of the messages.
> > > >
> > > > With this method, the situation, where the message path
> > > between two user
> > > > applications is open only in one direction, migth happen.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 22 Apr 2002 13:43:44 -0400

Javier,

Please see comments below.

  Tolga

> Sent: Monday, April 22, 2002 12:44 PM
[TOLGA] I think this is the reason, why there is this WG :-)
>
> The M3UA does not define the relationship of two endpoints, IMO
[TOLGA] In my view, any protocol (not just M3UA) defines the relationship of
two endpoints and the messaging between them.
> M3UA defines:
> 	- Communication of a traditional SS7 node with an IP-based
> node thru a frontier node. i.e.transition from SS7 network to IP
> network: SG-AS scenario
> This is the beginning of the whole discussion. These were the
> main two requirements that 3G telephony networks put on the table
> at the beginning of times. I mean, there is not a need to define
> the nodes themselves, but the means to communicate them.
>
> I need to have a clear idea how to communicate two nodes that are
> IP-based. It doesn't matter how I build them. I just want to have
> a protocol definition standardized. As you say if you put one or
> two SG functionalities inside a physical node is my problem and
> my internal architecture election.
[TOLGA] One of the important points is, SGP has the distribution capability,
which is the needed thing to let two nodes in IP domain to communicate each
other. For example, if you think the double-ended approach of the
discussions, it is proven that it just requires SGP and ASP functionalities
as defined in M3UA (It was even said "IPSP, a node which behaves like a SGP
when sending messages and like an ASP when receiving messages -or vice
versa- ") So, in my view, the protocol definition you want to have is
already defined in the existing M3UA protocol. No change in the state
machines is necessary and the relationship between two endpoints is well
defined.
>
> Another way of seeing this: why don't you consider to separate
> the SG as two nodes: an SS7 node and an IP node. AFterthat you
> can define a common protocol to communicate them and you can say
> that you don't need to define a SG but a protocol to be used
> between an IP node and an SS7 node. Each implementation can elect
> how to implement this: one, two or even three separate physical nodes??
[TOLGA] I think your concern is that SGP has also MTP3 functionality. I
agree, in an all IP configuration, MTP3 functionality is not needed. You
just reuse distribution and management functionality of it. And for
separating SG into multiple nodes, I don't think there is something, which
forbids this. Just there is no standard protocol for this. For example, if
it is said that in all IP scenarios, no MTP3 functionality is needed in SGs,
will this address your concern?
BTW, although I listed 3 different approaches in my original message, to be
honest, I think  1-(solution based on SG-SG communication) and 2-(one SGP
solution) should be  enough.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Apr 2002 12:44:27 -0500

Javier,

Please see comments below...

Javier Pastor-Balbas (ECE) wrote:                          (Mon, 22 Apr 2002 18:44:00)
> 	- Communication of a traditional SS7 node with an IP-based node thru a
> 	frontier node. i.e.transition from SS7 network to IP network: SG-AS
> 	scenario
> This is the beginning of the whole discussion. These were the main two
> requirements that 3G telephony networks put on the table at the beginning of
> times. I mean, there is not a need to define the nodes themselves, but the
> means to communicate them. 

So, are you saying that we wasted our time defining and specifying the
behavior of ASPs and SGPs?

--brian

> 
> I need to have a clear idea how to communicate two nodes that are IP-based.
> It doesn't matter how I build them. I just want to have a protocol
> definition standardized. As you say if you put one or two SG functionalities
> inside a physical node is my problem and my internal architecture election. 
> 
> Another way of seeing this: why don't you consider to separate the SG as two
> nodes: an SS7 node and an IP node. AFterthat you can define a common
> protocol to communicate them and you can say that you don't need to define a
> SG but a protocol to be used between an IP node and an SS7 node. Each
> implementation can elect how to implement this: one, two or even three
> separate physical nodes??
> 
> 
> 
> Cheers // Javier.
> 

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