Subject: RE: [Sigtran] m3ua IG : SSNM

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 24 May 2002 15:07:04 +0200

Hi Tolga, 

In the scenario you have depicted, there is no communication between AS1 and AS2. Communication between ASP and SGP, from the RFC'spoint of view, will be done towards the SS7 network. Communication between AS1 and AS2, from the RFC's point of view, will be done using IPSP communication.

If you desire direct communication between AS1 and AS2 you should also allow that your process works using the IPSP communication like in the following figure:

  AS1: DPC=1-1-1        AS2: DPC=2-2-2
  +-------+            +-------+
  |IPSP1  |============|IPSP2  |
  |ASP1   |            | ASP2  |
  +---+---+            +---+---+
      |                    |
      |                    |
      |                    |
      |                    |
      |                    |
      |                    |
      |     +-------+      |
      |     |SGP1   |      |
      +-----+       +------+
            +-------+
            AS1: 1-1-1
            AS2: 2-2-2

The SG was conceived as a GATEWAY between SS7 and IP, but not between IP nodes. 

Cheers // Javier.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Friday, May 24, 2002 3:10 PM
> To: [email-masked]
> Subject: RE: [Sigtran] m3ua IG : SSNM
> 
> 
> Javier,
> 
> I disagree with this. Because I very well remember that there was a
> consensus during initial IPSP discussions that such a 
> configuration is a
> valid one:
> 
> 
>  AS1: DPC=1-1-1        AS2: DPC=2-2-2
>  +-------+            +-------+
>  |ASP1   |            |ASP2   |
>  |       |            |       |
>  +---+---+            +---+---+
>      |                    |
>      |                    |
>      |                    |
>      |                    |
>      |                    |
>      |                    |
>      |     +-------+      |
>      |     |SGP1   |      |
>      +-----+       +------+
>            +-------+
>            AS1: 1-1-1
>            AS2: 2-2-2
> 
> If SSNM is not generated for SPMCs, then this can't work 
> properly. And is
> there any reason, why this configuration shouldn't be supported?
> 
>    Tolga
> 
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:[email-masked]]
> > Sent: Friday, May 24, 2002 8:47 AM
> > To: 'Bep Verberk'; Tolga Asveren
> > Cc: [email-masked]; [email-masked]'
> > Subject: RE: [Sigtran] m3ua IG : SSNM
> >
> >
> > Hi guys,
> >
> > In the M3UA RFC, "SS7 destination" is a destination in the SS7
> > network. In the same way IP destination is a destination in the
> > IP network. This assumes that a SG is connecting an SS7 network
> > with an IP network. It's just a way of differenciating both types
> > of nodes.
> >
> > Tolga, what you suggest should go in the SG-SG draft since it is
> > a particular procedure not included in the original RFC.
> >
> > Cheers // Javier.
> >
> > -----Original Message-----
> > From: Bep Verberk [mailto:[email-masked]]
> > Sent: Friday, May 24, 2002 2:25 PM
> > To: Tolga Asveren
> > Cc: [email-masked]; [email-masked]'
> > Subject: RE: [Sigtran] m3ua IG : SSNM
> >
> >
> >
> >
> > Q.704 does not clarify that in the
> > sigtran docs the term "ss7 destination" should refer to
> > IP based destinations as well as traditional ss7 network
> > destinations.
> >
> > I agree with Tolga's suggestion, and will leave it at that.
> >
> > Bep
> >
> >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [ mailto:[email-masked]
> > <mailto:[email-masked]> ]
> > > Sent: Thursday, May 23, 2002 6:37 PM
> > > To: Verberk, Bep [CAR:7M00:EXCH]
> > > Cc: Tolga Asveren; [email-masked]
> > > Subject: Re: [Sigtran] m3ua IG : SSNM
> > >
> > >
> > > Bep,
> > >
> > > M3UA calls in the terminology of Q.704 which defines a
> > > destination.
> > >
> > > --brian
> > >
> > > Bep Verberk wrote:
> > > (Thu, 23 May 2002 17:47:46)
> > > >
> > > >    see below.
> > > >
> > > >    > -----Original Message-----
> > > >    > From: Brian F. G. Bidulock [[1]
> > mailto:[email-masked] <mailto:[email-masked]> ]
> > > >    > Sent: Thursday, May 23, 2002 3:33 PM
> > > >    > To: Verberk, Bep [CAR:7M00:EXCH]
> > > >    > Cc: Tolga Asveren; [email-masked]
> > > >    > Subject: Re: [Sigtran] m3ua IG : SSNM
> > > >    >
> > > >    >
> > > >    > Bep,
> > > >    >
> > > >    > SS7 destination is anything that goes in a DPC.  Any point
> > > >    > code is a destination to any other point code.
> > > >
> > > >    [BEP] I completeley agree, my concern is related to future
> > > >    readers trying to understand the RFCs. My
> > > >    question was  - where in the sigtran
> > > >    documents is the definition of "ss7 destination" ?
> > > >    If it is defined somewhere that I'm missing then there
> > > >    is no issue.
> > > >
> > > >    If it is not defined then I belive it should be,
> > > >    since it is probable that people
> > > >    interpret it as only destinations on the traditional
> > > >    SS7 network.
> > > >
> > > >    >
> > > >    > --brian
> > > >    >
> > > >    > Bep Verberk wrote:
> > > >    > (Thu, 23 May 2002 12:22:22)
> > > >    > >
> > > >    > >    Brian,
> > > >    > >    that depens on your interpretation of "ss7 
> destination".
> > > >    > >    Can you point us to where this is defined as
> > > referring to SPMCs
> > > >    > >    as well as traditional SS7 destinations.
> > > >    > >
> > > >    > >    In any case I think at least a footnote is
> > > appropriate for the
> > > >    > >    clarification Tolga refers to.
> > > >    > >
> > > >    > >    Bep
> > > >    > >
> > > >    > >    > -----Original Message-----
> > > >    > >    > From: Brian F. G. Bidulock
> > > >    [[1][2] mailto:[email-masked]
> > <mailto:[email-masked]> ]
> > > >    > >    > Sent: Thursday, May 23, 2002 10:51 AM
> > > >    > >    > To: Tolga Asveren
> > > >    > >    > Cc: [email-masked]
> > > >    > >    > Subject: Re: [Sigtran] m3ua IG : SSNM
> > > >    > >    >
> > > >    > >    >
> > > >    > >    > Tolga,
> > > >    > >    >
> > > >    > >    > Tolga Asveren wrote:
> > > >    > >    > (Thu, 23 May 2002 10:34:53)
> > > >    > >    > > This is related with one of the messages I
> > > sent before.
> > > >    > >    > Let's consider again
> > > >    > >    > > the following configuration:
> > > >    > >    > >
> > > >    > >    > >  AS1: DPC=1-1-1        AS2: DPC=2-2-2
> > > >    > >    > >  +-------+            +-------+
> > > >    > >    > >  |ASP1   |            |ASP2   |
> > > >    > >    > >  |       |            |       |
> > > >    > >    > >  +---+---+            +---+---+
> > > >    > >    > >      |                    |
> > > >    > >    > >      |                    |
> > > >    > >    > >      |                    |
> > > >    > >    > >      |                    |
> > > >    > >    > >      |                    X
> > > >    > >    > >      |                    |
> > > >    > >    > >      |     +-------+      |
> > > >    > >    > >      |     |SGP1   |      |
> > > >    > >    > >      +-----+       +------+
> > > >    > >    > >            +-------+
> > > >    > >    > >            AS1: 1-1-1
> > > >    > >    > >            AS2: 2-2-2
> > > >    > >    > >
> > > >    > >    > > As I said in an earlier message, I think it
> > > is appropriate
> > > >    > >    > to send DUNA for
> > > >    > >    > > 2-2-2 to ASP1 in such a case. M3UA draft 
> limits use
> > > >    > of SSNM with
> > > >    > >    SS7
> > > >    > >    > > destinations. For example for DUNA it is said
> > > in 3.4.1:
> > > >    > >    > > "The DUNA message is sent from an SGP in 
> an SG to all
> > > >    > >    > concerned ASPs to
> > > >    > >    > > indicate that the SG has determined that one
> > > or more SS7
> > > >    > >    > destinations are
> > > >    > >    > > unreachable"
> > > >    > >    > >
> > > >    > >    > > I propose, this sentence is changed to be
> > > able to cover
> > > >    > >    > also corresponding
> > > >    > >    > > SPMC change cases, otherwise I will add 
> this to SG-SG
> > > >    draft.
> > > >    > >    >
> > > >    > >    > The sentence already covers this case: 2-2-2 is
> > > a destination
> > > >    > >    > to 1-1-1.
> > > >    > >    > No change is required.
> > > >    > >    >
> > > >    > >    > --brian
> > > >    > >    >
> > > >    > >    >
> > > >    > >    > >
> > > >    > >    > >     Tolga
> > > >    > >    > >
> > > >    > >    > >
> > > >    > >    > >
> > > >    > >    > >
> > > >    > >    > >
> > > >    > >    > >
> > > >    > >    > > _______________________________________________
> > > >    > >    > > Sigtran mailing list
> > > >    > >    > > [email-masked]
> > > >    > >    > > [2][3]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > <https://www1.ietf.org/mailman/listinfo/sigtran>
> > > >    > >    >
> > > >    > >    > --
> > > >    > >    > Brian F. G. Bidulock
> > > >    > >    > [email-masked]
> > > >    > >    > [3][4] http://www.openss7.org/ 
> <http://www.openss7.org/>
> > > >    > >    >
> > > >    > >    > _______________________________________________
> > > >    > >    > Sigtran mailing list
> > > >    > >    > [email-masked]
> > > >    > >    > [4][5]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > <https://www1.ietf.org/mailman/listinfo/sigtran>
> > > >    > >    >
> > > >    > >
> > > >    > > References
> > > >    > >
> > > >    > >    1. [6] mailto:[email-masked]
> <mailto:[email-masked]>
> > >    > >    2. [7] https://www1.ietf.org/mailman/listinfo/sigtran
> <https://www1.ietf.org/mailman/listinfo/sigtran>
> > >    > >    3. [8] http://www.openss7.org/ <http://www.openss7.org/>
> > >    > >    4. [9] https://www1.ietf.org/mailman/listinfo/sigtran
> <https://www1.ietf.org/mailman/listinfo/sigtran>
> > >    >
> > >    > --
> > >    > Brian F. G. Bidulock
> > >    > [email-masked]
> > >    > [10] http://www.openss7.org/ <http://www.openss7.org/>
> > >    >
> > >
> > > References
> > >
> > >    1. mailto:[email-masked] <mailto:[email-masked]>
> > >    2. mailto:[email-masked] <mailto:[email-masked]>
> > >    3. https://www1.ietf.org/mailman/listinfo/sigtran
> <https://www1.ietf.org/mailman/listinfo/sigtran>
> > >    4. http://www.openss7.org/ <http://www.openss7.org/>
> > >    5. https://www1.ietf.org/mailman/listinfo/sigtran
> <https://www1.ietf.org/mailman/listinfo/sigtran>
> > >    6. mailto:[email-masked] <mailto:[email-masked]>
> > >    7. https://www1.ietf.org/mailman/listinfo/sigtran
> <https://www1.ietf.org/mailman/listinfo/sigtran>
> > >    8. http://www.openss7.org/ <http://www.openss7.org/>
> > >    9. https://www1.ietf.org/mailman/listinfo/sigtran
> <https://www1.ietf.org/mailman/listinfo/sigtran>
> > >   10. http://www.openss7.org/ <http://www.openss7.org/>
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/ <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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 24 May 2002 09:32:41 -0400

Javier,

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Javier Pastor-Balbas (ECE)
> Sent: Friday, May 24, 2002 9:07 AM
> To: 'Tolga Asveren'; [email-masked]
> In the scenario you have depicted, there is no communication
> between AS1 and AS2. Communication between ASP and SGP, from the
> RFC'spoint of view, will be done towards the SS7 network.
> Communication between AS1 and AS2, from the RFC's point of view,
> will be done using IPSP communication.
[TOLGA] I still don't see any reason, why SGP1 shouldn't allow routing
between AS1 and AS2. This configuration was accepted as a valid one. And
more important than this, what is the technical reason, not to support it?
>
> If you desire direct communication between AS1 and AS2 you should
> also allow that your process works using the IPSP communication
> like in the following figure:
[TOLGA] There are cases, where I don't desire direct communication between
AS1 and AS2 and unfortunately the ==== line you draw is not really defined
today.(we are waiting for your document ;-) )
>   AS1: DPC=1-1-1        AS2: DPC=2-2-2
[TOLGA] I think now it is clear, it should be thought as IP-STP.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 May 2002 10:24:54 -0500

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Fri, 24 May 2002 15:07:04)
>   AS1: DPC=1-1-1        AS2: DPC=2-2-2

Your statement is particularly false: see following excerpt from RFC 2719:

| 3.5. SG to SG
| 
|    This section identifies a protocol architecture for support of
|    signaling between two endpoints in an SCN signaling network, using
|    signaling transport directly between two SGs.
| 
|    The following figure describes protocol architecture for a scenario
|    with two SGs providing different levels of function for interworking
|    of SS7 and IP. This corresponds to the scenario given in Figure 3.
| 
|    The SS7 User Part (S7UP) shown is an SS7 protocol using MTP directly
|    for transport within the SS7 network, for example, ISUP.
| 
|    In this scenario, there are two different usage cases of SIG, one
|    which transports MTP3 signaling, the other which transports ISUP
|    signaling.
| 
|             ******  SS7  ******   IP     ******  IP   ******
|             *SEP *-------* SG1*----------* SG2*-------*MGC *
|             ******       ******          ******       ******
| 
|             +----+                                    +----+
|             |S7UP|                                    |S7UP|
|             +----+                     +----+----+    +----+
|             |MTP3|                     |MTP3|    |    |    |
|             +----+    +---------+      +----+ SIG|    |SIG |
|             |MTP2|    |MTP2|SIG |      |SIG |    |    |    |
|             +    +    +    +----+      +----+----+    +----+
|             |    |    |    | IP |      |   IP    |    | IP |
|             +----+    +----+----+      +----+----+    +----+
| 
|             S7UP - SS7 User Part
| 
|                       Figure 10: SG to SG Case 1
| 
|    The following figure describes a more generic use of SS7-IP
|    interworking for transport of SS7 upper layer signaling across an IP
|    network, where the endpoints are both SS7 SEPs.
| 
| 
|             ******   SS7  ******    IP     ******  SS7   ******
|             *SEP *--------* SG *-----------* SG *--------*SEP *
|             ******        ******           ******        ******
| 
|             +----+                                       +-----+
|             |S7UP|                                       | S7UP|
|             +----+                                       +-----+
|             |MTP3|                                       | MTP3|
|             +----+        +---------+     +---------+    +-----+
|             |MTP2|        |MTP2| SIG|     |SIG |MTP2|    | MTP2|
|             +    +        +    +----+     +----+    +    +     +
|             |    |        |    | IP |     | IP |    |    |     |
|             +----+        +----+----+     +----+----+    +-----+
| 
|                       Figure 11: SG to SG Case 2
| 

IP to IP transport of SS7 was originally conceived of as using gateway.  In
the SG-SG draft Tolga is saying that the SEP and SG in these diagrams can be
one box.

Javier, I don't see your IPSP described in RFC 2719.  Because IP domain
communication was originally conceived as using an SG.

--brian

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