Subject: RE: [Sigtran] IPSP issues

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

Hi Tolga, 

I agree that your configuration can work. But what I'm also looking for is simplicity. If I want an MSC to communicate with an HLR, I want the underlying protocols of that particular nodes do all the work for me. I don't want to include a third node.

In your drawing using the IPSP communication it will go thru the direct path. This means easiest configuration and faster transmission.

  RK1: DPC=1-1-1       RK2: DPC=2-2-2
  +------+            +------+
  | AS 1 |============| AS 2 |
  +--+---+            +--+---+
     |                   |
     |                   |
     |                   |
     |                   |
     |                   |
     |     +------+      |
     +-----+ SG 1 +------+
           +------+
         RK1: DPC=1-1-1
         RK2: DPC=2-2-2

I don't really understand why you want to include a third node there... What it is already defined works fine. Include the SG 1 you can also have a redundancy path but the primary will be the "====" one. AS1 will select the shortest path (association) among the available ones.

I don't see any benefits from your scenario for an AS-AS communication point of view. The good point of including a  SG is having connection to an SS7 network as well. BUt for those cases you can use my configuration above what is optimized.

Cheers // Javier.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 6:05 PM
> To: [email-masked]
> Subject: RE: [Sigtran] IPSP issues
> 
> 
> Hi Javier,
> 
> Again I think, we are saying the same thing with you. 
> Probably the only
> difference is, in my opinion, it is not important whether the 
> remote peer
> you are sending messages to (for example 1-1-1) is in IP 
> domain or in SS7
> domain. I think, the important point is (in the context of 
> this discussion)
> the behavior of the peer (not the remote endpoint, your 
> adjacent node) you
> are sending the messages. Regardless of where the remote 
> endpoint is (IP
> domain or SS7) , the messages and procedures are the same.
> For example, just as a very simple example, let's consider 
> the following
> configuration:
> 
>  RK1: DPC=1-1-1       RK2: DPC=2-2-2
>  +------+            +------+
>  | ASP1 |            | ASP2 |
>  +--+---+            +--+---+
>     |                   |
>     |                   |
>     |                   |
>     |                   |
>     |                   |
>     |     +------+      |
>     +-----+ SGP1 +------+
>           +------+
>         RK1: DPC=1-1-1
>         RK2: DPC=2-2-2
> 
> This is possible with existing m3ua draft, nd two 
> applications in IP domain
> can communicate in such a way. They can also communicate with 
> nodes in SS7
> domain. When there are different operators involved and 
> configurations are
> more complex, then one probably will want to have a 
> configuration with SG-SG
> communication.
> 
>    Tolga
> 
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:[email-masked]]
> > Sent: Tuesday, April 23, 2002 11:35 AM
> > To: 'Tolga Asveren'; [email-masked]
> > Subject: RE: [Sigtran] IPSP issues
> >
> >
> > Tolga, see below..
> >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Tuesday, April 23, 2002 5:41 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] IPSP issues
> > >
> > >
> > > Hi Javier,
> > >
> > > Personally I disagree that IPSP is described in the current
> > > draft. It is
> > > just a group of sentences, which were put there without
> > > consensus and deep
> > > thinking, because of time limitations.
> > > The fact, that people could let their nodes communicate in IP
> > > domain in the
> > > lastinteroperability event just shows me, that this is
> > > achievable with the
> > > well defined SGP/ASP functionalities.
> > >
> >
> > It is achievable indeed, and it is based in the SGP/ASP
> > functionalities that were define in advance. But the good thing
> > is that you have and IP-node that can talk to an SG or to another
> > IP-node at the end .... :-D
> >
> > Cheers // Javier.
> >
> > > (I sent all of the messages of the recent IPSP discussions as
> > > a text file
> > > attachment to the list, it waits approval from moderator
> > > because its size is
> > > bigger than 40K)
> > >
> > >    Tolga
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of
> > > > Javier Pastor-Balbas (ECE)
> > > > Sent: Tuesday, April 23, 2002 11:22 AM
> > > > To: [email-masked]'
> > > > Cc: [email-masked]'
> > > > Subject: RE: [Sigtran] IPSP issues
> > > >
> > > >
> > > > Hi Brian,
> > > >
> > > > I'm aware of some of your discussions but I just see your
> > > > proposal as another configuration different from what IPSP is.
> > > > IPSP communication is already included in the RFC as I explained
> > > > below and has been successfully tested in the last interop...
> > > > It's just a matter of solving the concerns that came up there.
> > > >
> > > > Cheers // Javier.
> > > >
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Tuesday, April 23, 2002 4:32 PM
> > > > > To: Javier Pastor-Balbas (ECE)
> > > > > Cc: 'Tolga Asveren'; [email-masked]
> > > > > Subject: Re: [Sigtran] IPSP issues
> > > > >
> > > > >
> > > > > Javier,
> > > > >
> > > > > I encourage you too look back in the archives of the IPSP
> > > mail list
> > > > > where we have already discussed these issues.  
> Perhaps Tolga could
> > > > > point to where those are.  As a group we arrived at the
> > > simpler model
> > > > > of SG-SG communication (without backhaul) using the
> > > existing messages.
> > > > >
> > > > > --brian
> > > > >
> > > > > Javier Pastor-Balbas (ECE) wrote:
> > > > > (Tue, 23 Apr 2002 15:30:07)
> > > > > > Hi Tolga,
> > > > > >
> > > > > > See below....
> > > > > >
> > > > > > Cheers / Javier.
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, April 23, 2002 3:16 PM
> > > > > > > To: [email-masked]
> > > > > > > Subject: RE: [Sigtran] IPSP issues
> > > > > > >
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > >
> > > > > > About the special name I agree with you that no new names
> > > > > were needed. I prefer to call it ASP-ASP
> > > > > > Note about the RFC names:
> > > > > > AS
> > > > > > IPSP: node that communicates with another IPSP
> > > > > >
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > >
> > > > > > In fact you may be right. I'll try to remake my 
> point better:
> > > > > >
> > > > > > IPSP is not and IP-node itself. "IPSP communication" is the
> > > > > "procedure" (using M3UA messages) that two AS (i.e IP nodes)
> > > > > need to use to talk among them.
> > > > > > And AS-SG procedures are the ones that an AS has to use to
> > > > > talk to an SG.
> > > > > >
> > > > > > We can think of ASP and IPSP as roles.The implementation of
> > > > > an AS in processes is as follows:
> > > > > > 	- An AS implementation is called ASP if it
> > > talks with and SGP
> > > > > > 	- An AS implementation is called IPSP if it talks to
> > > > > another AS implementation (also called IPSP)
> > > > > >
> > > > > > It can be possible that an AS can talk to both kind of
> > > > > nodes at the same time: an SG and another AS. In that case
> > > > > the implementation of that AS (what we call process) will
> > > > > take the roles of ASP and IPSP at the same time.
> > > > > >
> > > > > > I know this nomenclature is not very clear. In fact I tried
> > > > > to change the term "IPSP communication" for "ASP-ASP
> > > > > Communication" but some folks preferred to have different
> > > > > names to differenciate both situations. But anyway in the
> > > > > draft it is said that "an IPSP serves an AS" in the same way
> > > > > that it is said that "an ASP serves an AS".
> > > > > >
> > > > > > Therefore we can conclude that it is not possible to
> > > > > connect an ASP with an IPSP, since this are roles that the AS
> > > > > implementation can have. The AS is the one that can be called
> > > > > IP-node.  :-D
> > > > > >
> > > > > >
> > > > > > Hope this clarifies a little more...  :-/
> > > > > >
> > > > > >
> > > > > > > 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?
> > > > > >
> > > > > > I hope the discussion above clarifies my point... :-D
> > > > > >
> > > > > > >
> > > > > > > > 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Sigtran mailing list
> > > > > > > [email-masked]
> > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Sigtran mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > > --
> > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > >
> > > >
> > > > _______________________________________________
> > > > 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 13:24:02 -0400

Hi Javier,

I didn't say a third node is necessary. I just want to point out, already
defined functionalities are enough to handle communciation both to SS7 and
to IP nodes. For example your MSC most probably should look like:

 +------------+
 |            |
 |            |
 |   X        |
 |            |
 |    +-------+
 |    |ASP    |
 |    +-------+
 |    |SGP    |
 +----+-------+

What you put inside your node is an internal decision. The protocol just
defines the relationship between endpoints, and with already defined
endpoints, it works.

If you agree that a simple configuration is better, I think it is better
that you also consider all of the necessary details, to draw the ========
between ASs. I think it is more complicated than it appears first.

    Tolga

> Sent: Tuesday, April 23, 2002 12:28 PM
> I agree that your configuration can work. But what I'm also
> looking for is simplicity. If I want an MSC to communicate with
> an HLR, I want the underlying protocols of that particular nodes
> do all the work for me. I don't want to include a third node.
>
> In your drawing using the IPSP communication it will go thru the
> direct path. This means easiest configuration and faster transmission.
>
>
>
> I don't really understand why you want to include a third node
> there... What it is already defined works fine. Include the SG 1
> you can also have a redundancy path but the primary will be the
> "====" one. AS1 will select the shortest path (association) among
> the available ones.
>
> I don't see any benefits from your scenario for an AS-AS
> communication point of view. The good point of including a  SG is
> having connection to an SS7 network as well. BUt for those cases
> you can use my configuration above what is optimized.
>
>
> Cheers // Javier.
>
>
>
>