Subject: RE: [Sigtran] document status

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 20 May 2002 17:31:36 +0200

Hi Reshma, 

Just to clarify: 
As Tolga previouly said, there are more opinions regarding these issues. And they are opinions that are different to what Tolga and Brian state in their assumptions.

- IPSP was agreed and not only for M3UA but also for other UALs. 
- What was not still agreed, (you can see it in the RFC), is the way that communication should be started (Open issue)
- IPSP is not necessarily ASPF+SGPF. RFC clearly says that is similar to an ASP
- IPSP communication is needed in order to avoid the use of SGs
- IPSP communication is in line with the current RFC since it allows the use of RK, RC and so on
- One physical node can work as an ASP talking to SS7 through a SG and also as an IPSP talking to another IPSP (IP nodes)

IPSP communication is not SG-SG communication. SG-SG communication is just an additional feature that you may or may not add to your network. But I said, from my personal point of view, it is just a different thing.

Cheers // Javier.

> -----Original Message-----
> From: reshma [mailto:[email-masked]]
> Sent: Monday, May 20, 2002 4:44 PM
> To: Tolga Asveren; [email-masked]
> Subject: Re: [Sigtran] document status
> 
> 
> Hi Tolga,
> > >
> > >     Some more doubts below.
> > > ----- Original Message -----
> > > From: "Tolga Asveren" <[email-masked]>
> > > To: <[email-masked]>
> > > Sent: Monday, May 20, 2002 6:36 PM
> > > Subject: RE: [Sigtran] document status
> > >
> > >
> > > > Reshma,
> > > >
> > > > In my opinion, the current text in M3UA draft was put there
> prematurely
> > > and
> > > > unfortunately just before work on it was stopped so 
> that it can become
> > > RFC.
> > >
> > > [Reshma] Does this mean IPSP section in the draft is no 
> more valid?
> > [TOLGA] No, it means in my opinion it is not necessary. But 
> I think nobody
> > will object that it was put there without consensus. So, I 
> wouldn't think
> > any changes there as changing something major in the m3ua 
> draft, because
> it
> > was never really defined by a group consensus. I think in 
> the following
> days
> > we will have more discussions and I hope we will finally reach a
> consensus.
> > >
> > > > Different people have still different opinions. For 
> example, if you
> are
> > > > using just SGPF and ASPF, then why do you need to 
> define it as it was
> > > > something new? Everybody is clever enough to combine the
> > > provided building
> > > > blocks based on the needs of their products. Also please note,
> > > rather than
> > > > providing a real peer-to-peer realtionship, this 
> approach simulates it
> > > with
> > > > two client-server relationships.
> > > > If you think, that what is needed is a way of letting 
> two nodes in IP
> > > domain
> > > > to communicate to each other (whether you call it IPSP 
> or not is up to
> > > you),
> > > > you will see that SG-SG communication also provides a 
> way of doing
> this.
> > > You
> > > > can think it as
> > >
> > > [Reshma] Just to clarify . What I call IPSP-IPSP communication ,
> > > is what you call SG-SG  communication?
> > [TOLGA] Not exactly. In my opinion, there is no need to 
> call something
> > specifically IPSP. We have building blocks, ASPF, SGPF. SG-SG draft
> defines
> > just the communication between SGs, so it is up to you how 
> to combine
> those
> > building blocks. I think, the crucial point is, those are 
> not node types
> but
> > defined functionalities. So, you can combine them as you 
> want in your
> > product, as long as you are compliant with the draft.
> 
> [Reshma] Does this mean that once we implement SG-SG communication ,
> Any two nodes can communicate in the IP domain using this 
> functionality?
> Is SG-SG communication defined as a result of need for 
> reliability as  in
> SS7
> network or peer to peer communication ?Please correct me if i am wrong
> 
> > >
> > > >
> > > >    **********        ***********
> > > >    *+-----+ *        * +-----+ *
> > > >    *|ASP1 | *        * |ASP2 | *
> > > >    *+--+--+ *        * +--+--+ *
> > > >    *   |    *        *    |    *
> > > >    *+--+--+ *        * +--+--+ *
> > > >    *|SGP1 +-*--------*-+SGP2 | *
> > > >    *+-----+ *        * +-----+ *
> > > >    **********        ***********
> > > >
> > > [Reshma] Again Just to clarify here ASP and SGPs are ASPF and
> > > SGPFs  right?
> > > Or am i wrong..?
> > [TOLGA] Yes.
> > >
> > > > or
> > > >
> > > >  ***********        ***********
> > > >  * +-----+ *        * +-----+ *
> > > >  * |U.P  | *        * |U.P  | *
> > > >  * +-----+ *        * +-----+ *
> > > >  * |SGP1 +-*--------*-+SGP2 | *
> > > >  * +-----+ *        * +-----+ *
> > > >  ***********        ***********
> > > >
> > > > SG-SG is also needed for a reasonable way of configuration and
> > > to transfer
> > > > between two SS7 entities, because it provides relaying 
> functionality.
> > >
> > > [Reshma]I Am not clear about this.Can u please explain me 
> what do u
> > > mean by relaying functionality here.?
> > [TOLGA] It means to act as an IP-STP between IP or SS7 
> domain entities.
> > >
> > > > As I said , different people have different opinions, 
> those are just
> my
> > > > personal opinions.
> > > >
> > >
> > > Thanks
> > > Reshma
> > >
> > > >    Tolga
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of
> > > > > reshma
> > > > > Sent: Monday, May 20, 2002 8:20 AM
> > > > > To: [email-masked]
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [Sigtran] document status
> > > > >
> > > > >
> > > > > Hi Brian,
> > > > >
> > > > >     As per my understanding IPSP has both SGP and ASP
> > > functionality.But
> > > > > i dont understand how IPSP-IPSP communication relates to SG-SG
> > > > > communication.Am i missing something?Can u please explain ?
> > > > >
> > > > > Thanks,
> > > > > Reshma
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > > > To: "reshma" <[email-masked]>
> > > > > Cc: <[email-masked]>
> > > > > Sent: Monday, May 20, 2002 5:14 PM
> > > > > Subject: Re: [Sigtran] document status
> > > > >
> > > > >
> > > > > > Reshma,
> > > > > >
> > > > > > What gave you that impression?
> > > > > >
> > > > > > --brian
> > > > > >
> > > > > > reshma wrote:                                  (Mon, 20 May
> > > > > 2002 13:39:27)
> > > > > > > Hi Brian,
> > > > > > >
> > > > > > >     The draft  "draft-bidas-sigtran-sgsg-00.txt" 
> does'nt say
> > > anything
> > > > > > > specific about IPSP.  I thought it was decided 
> that whatever
> > > > > is there on
> > > > > > > IPSP in the m3ua draft needs no change.  Only some more
> > > clarifications
> > > > > will
> > > > > > > be added if needed.  Please do clarify.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Reshma
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > > > > > To: "Tolga Asveren" <[email-masked]>
> > > > > > > Cc: <[email-masked]>
> > > > > > > Sent: Saturday, May 18, 2002 1:08 AM
> > > > > > > Subject: Re: [Sigtran] document status
> > > > > > >
> > > > > > >
> > > > > > > > Tolga, Javier,
> > > > > > > >
> > > > > > > > Continuing along the IPSP approach laid out in the RFC
> > > is futile.
> > > > > > > > Our IPSP discussions yielded the current SG-SG draft.
> > > There is no
> > > > > > > > need to consider IPSP separate from SG-SG.  I agree
> > > that the SG-SG
> > > > > > > > draft should be made a WG work item to address 
> peer-to-peer
> > > > > operation
> > > > > > > > for SUA as well as M3UA.
> > > > > > > >
> > > > > > > > I don't agree with the need for additional messages in
> > > the draft.
> > > > > > > > TRA can be handled with ASPAC and DAUD and 
> changeover (as you
> > > aptly
> > > > > > > > pointed out in previous discussions) can be 
> performed using
> the
> > > > > > > > methods described in draft-bidulock-sigtran-corid-00.txt
> > > > > (essentially
> > > > > > > > always adopting time-controlled changeover).  
> But, I would
> > > > > rather have
> > > > > > > > that discussion with the draft as a work item.
> > > > > > > >
> > > > > > > > IMO the interop demonstrated nothing with regard to the
> > > usability
> > > of
> > > > > > > > IPSP in the current RFC.  The interop did not 
> demonstrate
> > > > > actual MTP3
> > > > > > > > Users interworking over either single- or double-ended
> > > > > approaches, it
> > > > > > > > only tried exchanging a few M3UA messages.  Certainly
> > > the existing
> > > > > > > > arrangement can no better support lossless changeover
> > > than can the
> > > > > > > > RFC itself which is still missing the chanover 
> and changeback
> > > > > > > capabilities.
> > > > > > > >
> > > > > > > > The implementor's guilde should be more than 
> just an interop
> > > issues
> > > > > > > > list.  It was meant to address the 
> defficiencies in the RFC
> > > > > that were
> > > > > > > > left open by the working group in the spirit of 
> moving the RFC
> > > > > forward.
> > > > > > > > It would be better to focus on resolution to those
> > > defficiencies.
> > > > > Last
> > > > > > > > I checked, an ETSI interop was not an official 
> IETF event;
> > > > > however, it
> > > > > > > > appears to have carried more weight with the 
> authors of the
> > > > > implementors
> > > > > > > > guide that WG comments.  There has not been an SIGTRAN
> > > session at
> > > an
> > > > > > > > IETF plenary in some time.
> > > > > > > >
> > > > > > > > I will address in detail the concerns and 
> comments that I
> > > > > have on the
> > > > > > > > Implementor's Guide:  I was just waiting for a few more
> > > > > people to lose
> > > > > > > > their jobs in this field so that there will be less
> opposition.
> > > > > > > >
> > > > > > > > --brian
> > > > > > > >
> > > > > > > > Tolga Asveren wrote:
> > >     (Fri,
> > > 17
> > > > > May
> > > > > > > 2002 14:18:13)
> > > > > > > > > Hi Javier,
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Javier Pastor-Balbas (ECE)
> > > > > > > > > > [mailto:[email-masked]]
> > > > > > > > > > Sent: Friday, May 17, 2002 9:07 AM
> > > > > > > > > > To: 'Ong, Lyndon'; 'Tolga Asveren'; [email-masked]
> > > > > > > > > > Subject: RE: [Sigtran] document status
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hi Lyndon/Tolga,
> > > > > > > > > >
> > > > > > > > > > I didn't answer before because I thought my 
> view was clear
> > > > > > > > > > enough, but anyway I'll do it now. :-)
> > > > > > > > > >
> > > > > > > > > > I agree on having this SG-SG communication draft. I
> support
> > > it,
> > > > > > > > > > and I will help to this to become reality. I
> > > haven't still had
> > > > > > > > > > time to read it, but I'll do it during next week and
> > > > > I'll send my
> > > > > > > > > > comments.
> > > > > > > > > >
> > > > > > > > > > On the other hand, I don't think we need to define
> > > a new IPSP
> > > > > > > > > > communication. IPSP communication is 
> already defined in
> the
> > > RFC
> > > > > > > > > > and we don't have to change it for the moment. It is
> > > > > true that it
> > > > > > > > > > has some holes in the design, and those are what we
> > > > > should fix to
> > > > > > > > > > finish the RFC in a good way. Regarding 
> this, I plan to
> > > > > realise a
> > > > > > > > > > new draft that collects how IPSP 
> communication works. It's
> > > > > > > > > > nothing new but I see the need to have it to work
> > > from a clear
> > > > > > > baseline.
> > > > > > > > > [TOLGA] If there is nothing to be defined new and
> > > just some more
> > > > > > > > > clarifications, then why is "Implementors Guide" not
> > > enough for
> > > > > this? It
> > > > > > > was
> > > > > > > > > said that the only open issue is this double-ended"
> > > "single-ended"
> > > > > > > approach
> > > > > > > > > debate. What else is missing?
> > > > > > > > > >
> > > > > > > > > > I don't think either that focusing on new 
> works ,without
> > > > > > > > > > finishing the ones that are going on, is the best
> > > > > option. I would
> > > > > > > propose:
> > > > > > > > > > 1- finish the M3UA as it is first. This 
> means finish the
> > > > > > > > > > implementor's guide with the hole the 
> current v12 has.
> > > > > > > > > > 2- work in SG-SG
> > > > > > > > > > 3- More improvements if needed
> > > > > > > > > >
> > > > > > > > > > Focusing on other issues will delay the end of the
> > > > > current ones...
> > > > > > > :-/
> > > > > > > > > >
> > > > > > > > > > Cheers // Javier.
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Brian F. G. Bidulock
> > > > > > > > [email-masked]
> > > > > > > > http://www.openss7.org/
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > 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
> 
> 
> _______________________________________________
> 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, 20 May 2002 11:51:59 -0400

Javier,

If IPSP is not SGPF+ASPF, there is a need of a new state machine for it and
also relationship between IPSP and SGP/ASPs should be defined. My point is,
if it is ASPF+SGPF, it is just a special configuration and shouldn't be
advertised as a new functionality.

I agree with you that IPSP communication is not SG-SG communication but I
disagree that there was a consensus about IPSP in the WG.

   Tolga

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Javier Pastor-Balbas (ECE)
> Sent: Monday, May 20, 2002 11:32 AM
> To: 'reshma'; Tolga Asveren; [email-masked]
> As Tolga previouly said, there are more opinions regarding these
> issues. And they are opinions that are different to what Tolga
> and Brian state in their assumptions.
>
> - What was not still agreed, (you can see it in the RFC), is the
> way that communication should be started (Open issue)
> - One physical node can work as an ASP talking to SS7 through a
> SG and also as an IPSP talking to another IPSP (IP nodes)
>
> IPSP communication is not SG-SG communication. SG-SG
> communication is just an additional feature that you may or may
> not add to your network. But I said, from my personal point of
> view, it is just a different thing.
>
> Cheers // Javier.
>
>
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 May 2002 10:53:30 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Mon, 20 May 2002 17:31:36)
> Hi Reshma, 
> 
> Just to clarify: 
>
> As Tolga previouly said, there are more opinions regarding these issues. And
> they are opinions that are different to what Tolga and Brian state in their
> assumptions.
> 

In concept.  It appears in the framework document, however, in the framework
document it is true peer-to-peer, not bastardized client-server.

>
> - What was not still agreed, (you can see it in the RFC), is the way that
>   communication should be started (Open issue)

I suggest you look through the mail archives.  There were far more open
issues than just starting communication.  There was routing key and RC
management, routing granularity, routing conflicts, administration of
RC values, ...  and on.  There were quite a few long ladders.

> - IPSP is not necessarily ASPF+SGPF. RFC clearly says that is similar to an

But always groups its behavior with an SGP.

> - IPSP communication is needed in order to avoid the use of SGs

SGs are needed to provide IPSP communication.

> - IPSP communication is in line with the current RFC since it allows the use

Disagree.  See archives.

>
> - One physical node can work as an ASP talking to SS7 through a SG and also
>   as an IPSP talking to another IPSP (IP nodes)

Not without also having an SGPF.

>
> 
> IPSP communication is not SG-SG communication. SG-SG communication is just
> an additional feature that you may or may not add to your network. But I
> said, from my personal point of view, it is just a different thing.

Just a better thing than unmanageable criss-cross client-server attempting to
mimic peer-to-peer behavior.

I agree with Tolga: the only reason there is IPSP state this way is because
you jammed it into the draft before it went to RFC without concensus.

--brian

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

---

From: "reshma" <[email-masked]>
Date: Mon, 20 May 2002 21:32:27 +0530

Hi Javier,

    Some comments below.
    ----- Original Message -----
From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
To: "'reshma'" <[email-masked]>; "Tolga Asveren"
<[email-masked]>; <[email-masked]>
Sent: Monday, May 20, 2002 9:01 PM
Subject: RE: [Sigtran] document status

> Hi Reshma,
>
> Just to clarify:
> As Tolga previouly said, there are more opinions regarding these issues.
And they are opinions that are different to what Tolga and Brian state in
their assumptions.
> - IPSP is not necessarily ASPF+SGPF. RFC clearly says that is similar to
an ASP

[Reshma]I feel IPSP is ASPF+SGPF .B'coz IPSP has  the functionalities of
ASP plus some functions  of SGP (like Message distribution function at the
SG depening on RK's)

> - One physical node can work as an ASP talking to SS7 through a SG and
also as an IPSP talking to another IPSP (IP nodes)
I  too agree with rest of your opinion.

Thanks,
Reshma

---

From: "reshma" <[email-masked]>
Date: Mon, 20 May 2002 22:01:12 +0530

Hi Brian,

    Some doubts below..

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Cc: "'reshma'" <[email-masked]>; "Tolga Asveren"
<[email-masked]>; <[email-masked]>
Sent: Monday, May 20, 2002 9:23 PM
Subject: Re: [Sigtran] document status

> > As Tolga previouly said, there are more opinions regarding these issues.
And
> RC values, ...  and on.  There were quite a few long ladders.

[Reshma] But how these issues are solved in SG-SG communication?

> >
> > - IPSP is not necessarily ASPF+SGPF. RFC clearly says that is similar to
an
> >   ASP

[Reshma] Can u please explain why SGs are needed?

>
> >
> > - IPSP communication is in line with the current RFC since it allows the
use
> >   of RK, RC and so on

[Reshma] In archives there are only different opinions from different people
but no decisions taken :-(

> > - One physical node can work as an ASP talking to SS7 through a SG and
also
> mimic peer-to-peer behavior.

[Reshma] I dont understand why  you call SG-SG communication peer to peer
and
IPSP-IPSP communication(what Javier talks about)  as client-server ?Can u
please explain.

Thanks,
Reshma

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 May 2002 11:40:36 -0500

reshma,

reshma wrote:                                              (Mon, 20 May 2002 22:01:12)
> > Javier Pastor-Balbas (ECE) wrote:                          (Mon, 20 May

SG-SG removes need for RC and RK.  Routing is performed on SNMM as it is
in the SS7 network.  All these issues fall away.

> [Reshma] Can u please explain why SGs are needed?

Because the one IPSP's ASP-F needs another IPSP's SGP-F to talk to, therefore,
Javier's IPSP needs both ASP-F and SGP-F.  Take a look in the M3UA RFC how
many times IPSP behavior is equivalent to SGP behavior ("... in the IPSP/SGP
case...") and how many times it is talked about as equivalent to ASP behavior.
On even cursory examination, it is blatantly obvious that IPSP needs both
functions of an ASP and functions of an SGP.  It is this schyzophrenic
behavior that causes all the problems.  With SG-SG communication there is no
need to expose the AS to the network (just as there is no need in SS7).  ASPs
can be hung off backhaul if required (or desired) and the model is clean.

> but no decisions taken :-(

Exactly the point: IPSP was placed in the RFC without concensus.

> IPSP-IPSP communication(what Javier talks about)  as client-server ?Can u

Because IPSP as Javier describes it always has to act like a client (ASP) to
another IPSP acting as a server (SGP) and visa versa.  Peer-to-peer is not
paired client-server talking to reverse paired server-client: it is a peer
talking to a peer.  This is what SG-SG does.

--brian

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

---

From: "reshma" <[email-masked]>
Date: Mon, 20 May 2002 23:41:30 +0530

Hi Brian,

    Some more doubts..

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "reshma" <[email-masked]>
Cc: "Javier Pastor-Balbas (ECE)" <[email-masked]>;
"Tolga Asveren" <[email-masked]>; <[email-masked]>
Sent: Monday, May 20, 2002 10:10 PM
Subject: Re: [Sigtran] document status

> reshma wrote:                                              (Mon, 20 May
2002 22:01:12)
> > > Javier Pastor-Balbas (ECE) wrote:                          (Mon, 20
May
> > 2002 17:31:36)
issues.
> > And
> > > > they are opinions that are different to what Tolga and Brian state
in
> > their

[Reshma] So In IPSP we will only support Static configuration of Pointcodes
on both the sides
and once the connection is setup between 2 SGs they exchange  SSNM msgs
to let each other know about PC status? Is RK REG Concept not needed in
IPSPs?
Then what was the purpose of Single exchange and double exchange ?How this
purpose is
served in SG-SG Communication?

> can be hung off backhaul if required (or desired) and the model is clean.

[Reshma] So what you are refering as SG -SG is actually SGPF -SGPF ?
Or are u refering ASPF&SGPF together an SG?

> > > > IPSP communication is not SG-SG communication. SG-SG communication
is
> > just
> > > Just a better thing than unmanageable criss-cross client-server
attempting
> > to

[Reshma] But in SG-SG also it is SGPF talking to ASPF and vice versa acting
as
clint/server..? Or am i missing something..?

Thanks,
Reshma

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 20 May 2002 14:49:37 -0400

Reshma,

Although it was a call for Brian, please also see my comments below.

   Tolga

> served in SG-SG Communication?
[TOLGA] In my opinion, it should be enough to exchange SSNM, but this issue
might be discussed more. Single-exchange, double-exchange issue is not
related with SG-SG communication.

> Or are u refering ASPF&SGPF together an SG?
[TOLGA] Just SGPF-SGPF. SG-SG draft defines the communication between them.

> clint/server..? Or am i missing something..?
[TOLGA] Important point is how SGPFs are talking to each other, which is
peer-to-peer. So, with SG-SG protocol a peer-to-peer relationship is defined
between two M3UA entities. If one wants to have ASPF on top of SGPFs, then
this communciation will be done as defined in M3UA protocol and it is a
client/server relationship. But please note, the relationship between SGPFs
is peer-to-peer.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 May 2002 14:04:48 -0500

Reshma,

Tolga saved me the answer.  But a few more comments:

Tolga Asveren wrote:                             (Mon, 20 May 2002 14:49:37)
> related with SG-SG communication.

RK registration is not required.  SS7 Point Codes are statically allocated.
SS7 MTP Users have no DNS, no gethostbyname(), not mechanism for resolving
any other forms of address other than a statically allocate Point Code.
SCCP Users can use the GTT service (which will translate things like a
phone number into a point code; however, even GTT tables are statically
allocated).  This is true for M3UA in backhaul today.  There is no way
to "register" a point code with the SS7 network.  An SG "owns" that point
code: it is statically allocated.

--brian

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

---

From: "reshma" <[email-masked]>
Date: Tue, 21 May 2002 12:35:01 +0530

Hi,
    Thanks for ur Comments.
Some more doubts below..

> related with SG-SG communication.

[Reshma] But SSNM msgs between ASP-SGP  is a result of  TFA,TFP etc
(maps to MTP_PAUSE ,MTP_RESUME).But in caseof IPSP(what u say as SGPF) there
is no MTP3 which initaites these messages..?Are u saying DUNA,DAVA generated
locally..? But how..?

> [TOLGA] Just SGPF-SGPF. SG-SG draft defines the communication between
them.

[Reshma] So as u say IPSP is a SGPF and hence IPSP-IPSP communication ?
But the name SG-SG communication is misleading then :-(

> client/server relationship. But please note, the relationship between
SGPFs

[Reshma] If there is a ASPF over SGPF how does it become client server?
both sides there will be SGPF& ASPFs so it is peer to peer.I agree
SGPF -SGPF will be
peer to peer but i dont understand why u say IPSP(SGPF&ASPF) to IPSP
communication
is not peer to peer?

Thanks,
Reshma

---

From: "reshma" <[email-masked]>
Date: Tue, 21 May 2002 13:11:11 +0530

Hi  Brian ,

    Some doubts below

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "Tolga Asveren" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 21, 2002 12:34 AM
Subject: Re: [Sigtran] document status

> code: it is statically allocated.

[Reshma]I agree that pointcodes are statically allocated in SS7 network.
But the pointcode assigned to an IPSP(what u say as SG) is just for the
IPSP to communicate with other IPSPs in point to point fashion and these
pointcodes might not be exposed to SS7 world .And what you are refering
as SG is not real SG but SGPF in case of IPSP ?? Or am i missing something?

Thanks,
Reshma

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 21 May 2002 09:21:27 -0400

Reshma,

> Sent: Tuesday, May 21, 2002 3:05 AM
[TOLGA] First of all I am not saying SGPF is IPSP. Because SGPFs are
controlling SPMC as a whole, they can generate those messages. Also for
ASP-SGP case, when SGP decides that SPMC is down, then it triggers MTP3 to
generate a TFP, now it will send DUNA to peer SGs.
> But the name SG-SG communication is misleading then :-(
[TOLGA] No, SG-SG communication is just communication between SGs, as the
name says. It is not IPSP. But SG-SG communication provides a way of two
M3UA entities communicate in IP domain. Several possible examples are
already given in the previous messages.
> peer to peer but i dont understand why u say IPSP(SGPF&ASPF) to IPSP
[TOLGA] Whether you put ASPF over SGPF, or have ASPF in different host ot
you have directly NIF/LM+User Parts over SGPF is your choice, nobody can
dictate this. I think, one of the important points here is, we are defining
functionalities and endpoint behaviors with the protocol, not what a node
should contaon not specific products.
First I want to repeat that SG-SG is not IPSP. Secondly if one wants to have
ASPF on top of SGPF (on the same host or on different host) the relationship
between them will be a client/server relationship.

---

From: "reshma" <[email-masked]>
Date: Tue, 21 May 2002 19:48:00 +0530

Hi Tolga,

 Some more doubts below..

> generate a TFP, now it will send DUNA to peer SGs.

 [Reshma]  Okay then how do u say that we can use SG-SG communication for
IPSP-IPSP also?Or this feature in SG-SG communication wont be used in
IPSP-IPSP
communication..?

> between them will be a client/server relationship.

[Reshma] Okay..But why do u say IPSP is only SGPF ?Can u explain ?

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 21 May 2002 10:34:57 -0400

Reshma,

> IPSP-IPSP also?Or this feature in SG-SG communication wont be used in
[TOLGA] I am not saying this. How in general SG-SG works is clear. It has
relaying functionality, can transfer over IP between SS7 nodes and it
provides a way to let two M3UA entities communicate to each other. I don't
think it is a good idea to call any M3UA peer-to-peer communication IPSP.
Just think, what is described in SG-SG communication as IP-STP
functionality.

> [Reshma] Okay..But why do u say IPSP is only SGPF ?Can u explain ?
[TOLGA] I am not saying this.

---

From: "reshma" <[email-masked]>
Date: Tue, 21 May 2002 20:06:49 +0530

Tolga,

> generate a TFP, now it will send DUNA to peer SGs.

[Reshma] I thought SGPF is one with some of the functionalities(SG
functionalities of IPSP) ?
Is it not so?

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 21 May 2002 10:51:21 -0400

Reshma,

> Sent: Tuesday, May 21, 2002 10:37 AM
[TOLGA] No. SGPF = Signalling Gateway Process Functionality. As I said
before, it is better to think it as IP-STP functionality.

---

From: "reshma" <[email-masked]>
Date: Tue, 21 May 2002 20:29:12 +0530

> before, it is better to think it as IP-STP functionality.

[Reshma] That is SG acting as STP ?

-reshma

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 21 May 2002 11:11:47 -0400

Reshma,

> Sent: Tuesday, May 21, 2002 10:59 AM
[TOLGA] Yes, and it can communicate to other IP-STPs, this is in fact, what
SG-SG draft defines.

---

From: "reshma" <[email-masked]>
Date: Tue, 21 May 2002 22:41:18 +0530

Hi Tolga ,

> [TOLGA] Yes, and it can communicate to other IP-STPs, this is in fact,
what

[Reshma] Okay that was my understanding from the draft initially.And the
only reason i could think this was needed was for Reliability and for
Switching between two SGs (IP-STPs) whenever needed. But i am still not
clear about
how this can increase inter-IP communication capabilities of M3UA peers ?
Can u help me in this..?

Thanks,
Reshma

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 21 May 2002 13:37:35 -0400

Reshma,

> Sent: Tuesday, May 21, 2002 1:11 PM
SG-SG communication defines a peer-to-peer relationship between SGs (which
are M3UA entities). So, they can communicate among themselves. I will redraw
one of the figures from a previous message:

                           -----
                        ///     \\\
                      ||           |
                      | ASP cloud3  |
                      ||           |
                        \\\     ///
                           --+--
                             |
                             |
                             |
                             |
                             |
                       +-----+----+
                       |          |
                       | SGPF3    |
                       |          |
                       +---+---+--+
                           |   |
                           |   |          +----------+
                           |   |          | ASP2     |
                           |   |          |          |
                           |   |          +----+-----+
        +----------+       |   |               |
        | User P.  |       |   |               |
        |  NIF/LM  |       |   |               |
        +----------+       |   |          +----+-----+
        |          +-------+   +----------+          |
        | SGPF1    +----------------------+ SGPF2    |
        |          |                      |          |
        +----------+                      +----------+
        | MTP3  1  |                      | MTP3  2  |
        +----+-----+                      +-----+----+
             |                                  |
             |                                  |
             |                                  |
             |                                  |
             |                                  |
             |                                  |
             |                                  |
        +----+-----+                      +-----+----+
        |          |                      |          |
        | STP1     |                      | STP2     |
        |          |                      |          |
        +----------+                      +----------+

I think, this figure shows well, what you can do, once SG-SG communication
is there.
SG-SG communication brings also relaying functionality. This is important to
relay between SS7 nodes and also to have configurable systems in IP domain.
As I stated previously in one of my messages, if you have n nodes, and if
you change the RK in one of them, do you want to change the RKs in all of
the other n-1 nodes or only in a few concentration nodes (especially when
there are multiple operators present)?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 May 2002 15:06:16 -0500

reshma,

reshma wrote:                                              (Tue, 21 May 2002 13:11:11)

-X--snip--X-
> as SG is not real SG but SGPF in case of IPSP ?? Or am i missing something?

It is mooth whether one can concieve of an all-IP network where point codes
are dynamically allocated: the MTP-Users can only handle static configuration.
MTP-Users must know the point codes of their peers before they can operate.
They are only built for static configuration and have no mechanism to discover
the point codes of their peers and no way to refer to there peers with other
than a point code.  I'm sorry, I thought I made that clear above.

--brian

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

---

From: "reshma" <[email-masked]>
Date: Wed, 22 May 2002 18:38:25 +0530

Hi Brian,

    Some doubts again,

issues.
in
> in the SS7 network.  All these issues fall away.

[Reshma] I agree that for IPSP-IPSP communication also we dont need RC and
RK
but how can we use SSNM messages to exchange status..? How can we get the PC
status ? Or only a TAL is enough?

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 May 2002 10:03:43 -0400

Reshma,

Again just my personal opinions below.

  Tolga

> Sent: Wednesday, May 22, 2002 9:08 AM
> To: [email-masked]
> Cc: Javier Pastor-Balbas (ECE); Tolga Asveren; [email-masked]
> > > > > - What was not still agreed, (you can see it in the RFC),
> is the way
> > > that
[TOLGA] For example DAVA = PC available, DUNA = PC unavailable etc... One
can query the status of a PC with DAUD. There is nothing new here. TAL was
only there to mark the end of SSNM exchanged at association startup. By
changing the bahvior at startup, it is possible to get rid of it and I would
be happy to see this happen, but still to be discussed.

---

From: "reshma" <[email-masked]>
Date: Wed, 22 May 2002 20:15:14 +0530

Hi Tolga,

> > [Reshma]    What do you mean by m3ua entities here? is it only SG ? or
SGP
> > and ASP?
> > I thought IPSP is also a m3ua entity :-(  .Is there any separate
> > draft/document
> > coming out for IPSP in near future ?
> [TOLGA] As indicated in the figure, there is a peer-to-peer relationship
> between SGs. But also user applications (directly on top of SGPF, or on a
> ASPF) can also communicate to each other by staying totally in IP domain.

[Reshma] From the figure u have drawn my understanding is:
1.The block containing  [NIF/LM/U.P+SGPF1+MTP3 1]   is an SG which
acts as relay point for STP1
2.The block SGPF3 is also an SG (NIF/LM/U.P+SGPF3+MTP3) which is
connected to set of ASPs  one side and has peer to peer communication
with [NIF/LM/U.P+SGPF1+MTP3] SG block
3.The block with [SGPF2+MTP3 2] is another SG which is also acting as
relay point for STP2 and also connected to an ASP ie ASP2.

Is my understanding correct ?And does this figure convey any more
information?

---

From: "reshma" <[email-masked]>
Date: Wed, 22 May 2002 20:24:03 +0530

Hi Tolga,

> be happy to see this happen, but still to be discussed.

[Reshma] Yes i understand .But what i am asking is in case of  normal ASP-SG
 communication DUNA is a result of  (TFP in MTP3) MTP_PAUSE_IND from
 MTP3 and DAVA (TFA in MTP3) MTP_RESUME_IND from MTP3 to the
 upper layer . But initially just after the connection establishment how do
u send
DUNA or DAVA without any message from MTP3?

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 May 2002 11:08:22 -0400

Reshma,

> Sent: Wednesday, May 22, 2002 10:54 AM
[TOLGA] SGPFs are controlling SPMCs as a whole. So, at any given time, they
know whether SPMC is available or not. There is no involvement of MTP3 here.
Everyhting is handled by SGPF itself.

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 May 2002 11:18:05 -0400

Reshma,

> Tolga Asveren
> Sent: Wednesday, May 22, 2002 11:08 AM
> To: [email-masked]
> > > > [Reshma] I agree that for IPSP-IPSP communication also we
> dont need RC
> > and
> > > > RK
[TOLGA] Just as an addition, for the PCs in SS7 domain, the same applies for
MTP3. If one wants to contact them, one should have MTP3 functionality. But
in this case, MTP3 knows at a given the the status of those PCs and SGPF can
retireve this information from there. The interface between SGPF and MTP3
functionalities is implementation dependent.

---

From: "reshma" <[email-masked]>
Date: Wed, 22 May 2002 20:50:44 +0530

Hi Tolga,

> Everyhting is handled by SGPF itself.

[Reshma] As per the draft :
"Signalling Point Management Cluster (SPMC) - The complete set of
Application Servers represented to the SS7 network under a single MTP
entity (Signalling Point) in one specific Network Appearance."

But how does SGPF comes to know about the status ? By the AS status?

Thanks,
reshma

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 May 2002 11:34:20 -0400

Reshma,

> Sent: Wednesday, May 22, 2002 11:21 AM
By status of ASs, in fact this is something between ASPF and SGPF, nothing
new.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 May 2002 10:22:40 -0500

Reshma,

reshma wrote:                                              (Wed, 22 May 2002 20:15:14)
> Is my understanding correct ?And does this figure convey any more

You missed a couple of lines.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 May 2002 11:44:11 -0400

Brian,

Yes, your explanation is a more complete one. Probably we will need to add
the same explanation and maybe some references to Q.704 to SG-SG draft.

   Tolga

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, May 22, 2002 11:26 AM
> To: Tolga Asveren
> Cc: [email-masked]
> I consider M3PA to be a routeset and the SGPF to contain MTP3
> functionality (state machines, routing).  DUNA would be sent on
> an association under the same conditions that MTP3 would send
> TFP on a route.  DAVA, for TFA.  Etc.
>
> --brian
>
> Tolga Asveren wrote:                                        (Wed,
> 22 May 2002 11:08:22)
> > Reshma,
> >
> >
> > > > changing the bahvior at startup, it is possible to get rid
> of it and I
> > > would

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 May 2002 10:26:10 -0500

Tolga,

--brian

Tolga Asveren wrote:                                        (Wed, 22 May 2002 11:08:22)

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

---

From: "reshma" <[email-masked]>
Date: Mon, 27 May 2002 20:17:37 +0530

Hi Brian,

> You missed a couple of lines.

[Reshma] Can u tell me what i have missed here.I think that may help me in
understanding
SG-SG  draft better.

Thanks,
Reshma

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 27 May 2002 12:29:36 -0500

reshma,

reshma wrote:                                              (Mon, 27 May 2002 20:17:37)
> [Reshma] Can u tell me what i have missed here.I think that may help me in

Look at each line in Tolga's diagram and consider the relationship.

--brian

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