Subject: RE: [Sigtran] IPSP issues

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 23 Apr 2002 14:45:38 +0200

Hi Tolga, 

See below...

Cheers // Javier.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Monday, April 22, 2002 7:44 PM
> To: [email-masked]
> Subject: RE: [Sigtran] IPSP issues
> 
> 
> Javier,
> 
> Please see comments below.
> 
>   Tolga
> 
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:[email-masked]]
> > Sent: Monday, April 22, 2002 12:44 PM
> > To: 'Tolga Asveren'; [email-masked]
> > Subject: RE: [Sigtran] IPSP issues
> >
> >
> > Well, I see this as the beginning of a long discussion...  ;-)
> [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:
> > 	- 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.
> [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.
> >

The sentence "IPSP, a node which behaves like a SG when sending messages and like an AS when receiving messages" is right. But it does NOT mean that an IPSP is made of an ASP and an SG. You can reuse some of the logic inside the SG to create your IPSP since the protocol is the same at the end.

> > 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.

SG has a lot more of things that you don't needed for an IPSP. This is because the node concept is completely different. An IPSP is an IP-only node. No SS7 functionality under the 4th layer. But also no SG functionality to send messages to a the peer.

See it as the following:
If you add to an AS the functionality needed for an SG to send messages to an AS, and you mix it according with the M3UA RFC, you'll have an IP node that can talk to an SG but also DIRECTLY to another IP-node. It is what is already defined and it works fine. It worked fine in the last interop. The open issue we have is to decide the start-up of the connection, but the rest doesn't need any urgent modification...

<END>

> >
> >
> >
> > 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
> 

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 23 Apr 2002 09:16:13 -0400

Hi Javier,

To make this thread more productive let me list my concerns:

1) The fact, that "IPSP" is described in a few lines in M3UA draft is in my
view enough evidence, that it just reuses already defined ASP/SGP
functionalities. I don't think there is a need to give a special name to
this, because it is just a special configuration of the existing
functionalities. Of course, different people might have different opinions
on that issue.

2) I don't necessarily agree with your sentence "IPSP is an IP-only node".
In the recent IPSP discussions, the question which everybody was asking was
"Can I have an aasociation between IPSP and SGP, what about IPSP and ASP?".
That is also one of the reasons, why I like to see it as a special
configuration of ASP/SGP, because, in such a case the relationship between
endpoints is well defined.

Your main concern is -as far as I understand- that SGP functionality has
some components, which are not necessary for "IPSP" case. For which parts
are you concerned?

> See it as the following:
> If you add to an AS the functionality needed for an SG to send
> messages to an AS, and you mix it according with the M3UA RFC,
> you'll have an IP node that can talk to an SG but also DIRECTLY
> to another IP-node. It is what is already defined and it works
> fine. It worked fine in the last interop. The open issue we have
> is to decide the start-up of the connection, but the rest doesn't
> need any urgent modification...
That is also exactly what I am saying. More and more I have the feeling, the
main difference is, you want to give this thing a new name and I don't.
Well, this is not a big issue :-)

    Tolga