Subject: RE: [Sigtran] m3ua IG : SSNM

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

Hi Ken, 

I wasn't aware of those discussions in the Plugtest... And I've not found any test case regarding this. Am I correct or I missed it?

But anyway I've always seen that configuration as a valid one but not specifically covered in the RFC...  :-/. Moreover, sometimes it is talked about the congestion/availability/restriction of SS7 destination: this means that it clearly refers to MTP3 destinations (SS7). how can an IP route be congested/restricted ?  :-(. How can you send a TFC to the concerned SS7 destination if it is located in IP ?

There are several things to define explicitely if we want to cover IP-STP in the current RFC. One first point would be the discrimination whether we talk about an SS7 destination in IP or an SS7 destination in SS7. Actually, IMO all the SS7 destinations refer to SS7 destination in the SS7 domain

My conclusion is therefore obvious: SS7 destination are in SS7 networks from the RFC point of view...

As I've already said, I think that this was not included in the draft explicitly, although I know you can reach those configurations as an easy extension of the already defined concepts... 

And also in the same way, you might define SG-SG using the main components of M3UA. Although I agree this does not have a so obvious development.

Cheers // Javier.

> -----Original Message-----
> From: Ken Morneault [mailto:[email-masked]]
> Sent: Friday, May 24, 2002 3:44 PM
> To: Tolga Asveren; [email-masked]
> Subject: RE: [Sigtran] m3ua IG : SSNM
> 
> 
> 
> 
> Javier,
> 
> I agree with Tolga that this is a supported configuration.  It was
> briefly discussed by some at the plugtest and it was noted that
> SSNM messages applied to IP based SS7 destinations also.
> 
> If people feel the current text regarding "SS7 destinations" isn't
> clear enough to cover this case, then we should improve the text.
> I thought the text was sufficient, but since there are differing 
> opinions, the implementors guide should contain a note on this.
> 
> Ken
> 
> At 09:09 AM 5/24/2002 -0400, Tolga Asveren wrote:
> >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

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

---

From: Ken Morneault <[email-masked]>
Date: Fri, 24 May 2002 10:47:33 -0400

Javier,

Pls see below.

Ken

>I wasn't aware of those discussions in the Plugtest... And I've not found any test case regarding this. Am I correct or I missed it?

You are correct on these points.  The discussions at the Plugtest were not
formulated as an issue so they were not recorded.  Further, the test cases
did not cover this configuration.

>My conclusion is therefore obvious: SS7 destination are in SS7 networks from the RFC point of view...

Yes, but todays SS7 destinations in the SS7 network may be tomorrow's SS7 destinations
in the IP network talking to other SS7 destinations in the IP network.  I don't think we should 
rely on IPSP as the only means to support this scenario (though it may be used). 

>As I've already said, I think that this was not included in the draft explicitly, although I know you can reach those configurations as an easy extension of the already defined concepts... 

Yes, since it is not explicit in the RFC, it would be worth clarifying in the imp guide.

>And also in the same way, you might define SG-SG using the main components of M3UA. Although I agree this does not have a so obvious development.

I agree also.

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 24 May 2002 11:03:30 -0400

Javier,

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Javier Pastor-Balbas (ECE)
> Sent: Friday, May 24, 2002 10:30 AM
> To: 'Ken Morneault'; Tolga Asveren; [email-masked]
> I wasn't aware of those discussions in the Plugtest... And I've
> not found any test case regarding this. Am I correct or I missed it?
>
> But anyway I've always seen that configuration as a valid one but
> not specifically covered in the RFC...  :-/. Moreover, sometimes
> it is talked about the congestion/availability/restriction of SS7
> destination: this means that it clearly refers to MTP3
> destinations (SS7). how can an IP route be congested/restricted ?
>  :-(. How can you send a TFC to the concerned SS7 destination if
> it is located in IP ?
[TOLGA] An SCTP association can also be congested. There is SCON to report
this to concerned ASPs. Probably restricted won't apply, unless there is
SG-SG, which has relaying capability. For availability, it is obvious that
this concept exists, it is availability of the SPMC.
>
> There are several things to define explicitely if we want to
> cover IP-STP in the current RFC. One first point would be the
> discrimination whether we talk about an SS7 destination in IP or
> an SS7 destination in SS7. Actually, IMO all the SS7 destinations
> refer to SS7 destination in the SS7 domain
[TOLGA] My opinion is, that no special explanations are necessary for this.
> As I've already said, I think that this was not included in the
> draft explicitly, although I know you can reach those
> configurations as an easy extension of the already defined concepts...
[TOLGA] If people don't want to see this in M3UA then I will add it to SG-SG
but my personal opinion is, the correct place is M3UA draft and in fact the
only necessary thing is -just to prevent confusions- a few sentences in IG
(if people think it is clear enough, then even this is not necessary)
>
> And also in the same way, you might define SG-SG using the main
> components of M3UA. Although I agree this does not have a so
> obvious development.
[TOLGA] SG-SG is already making use of M3UA concepts, that is the reason why
it is so straightforward and easy to implement.