Subject: RE: [Sigtran] document status

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Tue, 21 May 2002 09:15:17 +0200

Dear all,

what is the SG-SG draft really heading for?

some day ago (Mo 20.05.2002)I received the figure and text below from Tolga

---snip---
 +------+---+                 +---+------+
 |      |M  |                 |M  |      |
 |      |T  |                 |T  |      |
 |STP1  |P  +------X----------+P  |SGPF  |
 |      |3  |                 |3  |      |
 |      |   |                 |   |      |
 +------+-+-+                 +---+---+--+
          |                           |
          |                           |
          |                           |
          |                           |
          |                           |
          |                   +---+---+--+
          |                   |M  |      |
          |                   |T  |      |
          |                   |P  |SGPF  |
          +-------------------+3  |      |
                              |   |      |
                              +---+------+

The draft does not say, that it defines IPSP communication. It defines
relationship between two SGs.
---snip---

In that case the newly introduced protocol messages are suitable.
In my understanding an SG still mediates between networks using different architectures, wheras at least in my interpretation IPSP-IPSP communication doesn't cross architectural borders.

Perhaps I'm wrong, but in my reading of the figure above the  communication between STP1 and both SGPF's is done with conventional TDM links running MTP2/MTP3 and only management messages destined for the "north" SGPF are relayed by the "south" SGPF.
In contrast the figures shown below have no TDM links at all, so the new protocol messages are useless, as there is neither SLC not FSN in M3UA.

Why refuse further discussion on these issues before deciding about converting it to a SIGTRAN work item? 

greetings 
HannsJuergen

>-----Original Message-----
>From: Tolga Asveren [mailto:[email-masked]]
>Sent: Monday, May 20, 2002 3:07 PM
>To: [email-masked]
>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.
>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
>
>   **********        ***********
>   *+-----+ *        * +-----+ *
>   *|ASP1 | *        * |ASP2 | *
>   *+--+--+ *        * +--+--+ *
>   *   |    *        *    |    *
>   *+--+--+ *        * +--+--+ *
>   *|SGP1 +-*--------*-+SGP2 | *
>   *+-----+ *        * +-----+ *
>   **********        ***********
>
>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.
>
>As I said , different people have different opinions, those are just my
>personal opinions.
>
>   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

---

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

HannsJuergen,

Please see my comments below.

  Tolga

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Schwarzbauer Hanns Juergen
> Sent: Tuesday, May 21, 2002 3:15 AM
> To: [email-masked]
[TOLGA] It just tries to define the communication between SGs. Then it is up
to you, how to make use of this functionality. It has realying capability,
might work to create IP-STPs and also to to communicate between two M3UA
entities in IP domain.
> In my understanding an SG still mediates between networks using
> different architectures, wheras at least in my interpretation
> IPSP-IPSP communication doesn't cross architectural borders.
[TOLGA] I think, in the context of this discussion, it is better to forget
about the word "gateway" in SG. Think it as IP-STP, this models it better.
>
> Perhaps I'm wrong, but in my reading of the figure above the
> communication between STP1 and both SGPF's is done with
> conventional TDM links running MTP2/MTP3 and only management
> messages destined for the "north" SGPF are relayed by the "south" SGPF.
> In contrast the figures shown below have no TDM links at all, so
> the new protocol messages are useless, as there is neither SLC
> not FSN in M3UA.
[TOLGA]The figure above and the ones below are different configurations but
I think the following one will make it more clear, where both of them are
combined :

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

So, you are right that for the below configurations, changeover mechanism
related messages are not necessary. They are only for the case, where SGs
are relaying for SS7 nodes.
>
> Why refuse further discussion on these issues before deciding
> about converting it to a SIGTRAN work item?
[TOLGA] If there is interest I have no problem, but if there is interest
then I believe it is also better to make it a WG item. In my opinion, it is
something needed.