Subject: [M3UA & SUA]: SS7 Network Evolution and possible interworking bet ween M3UA and SUA

From: Young Michael-Y10724 <[email-masked]>
Date: Thu, 9 Aug 2001 15:14:32 -0400

Brian et all,

I found very interesting discussion in previous thread as below and I tend to agree to remove SSN from RC in M3UA.  This inspired me to initialise an new thread on SS7 nework evolution and possible interworking between M3UA and SUA (if I didn't miss anything).  I am more looking for clarification and Sigtran's view/position on subject issue.

From an operator's point of view, migrating from SS7 based Signalling network to IP based Signalling network will bring interworking issue, and migration will take a fairly long period.  If my understanding is correct, SCCP based applications protocols (MAP/TCAP, CAP/TCAP, RANAP etc...) can have options to seat on top of either SUA/SCTP or SCCP/M3UA/SCTP in IP domain.  However, unless all the operator's signalling network migrated from SS7 to IP, the interworking shall be mandated to legacy SS7 network.  Assume eventually we will have an pure IP signalling network, shall we mandate the interworking among different implementation approaches (eg. M3UA vs SUA)?
Can somebody give me a little bit background information why Sigtran developed so many addaption layers which are sometimes in a competing siuatoin at least to me?

Thanks & br,

Michael

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, August 09, 2001 9:35 AM
> To: sigtran
> Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
> 
> 
> Lyndon,
> 
> Getting back to the specific M3UA issue, no-one has come up
> with a situation where M3UA requires routing on SSN (despite
> Greg's defense of these phantom individuals).
> 
> I propose that it be removed from the draft.
> 
> --Brian
> 
> Lyndon Ong wrote:                             (Thu, 09 Aug 
> 2001 01:15:08)
> >
> > Brian,
> > 
> > I think what Greg means is "transports transparently" or something
> > to that effect, SCTP is the transport layer but M3UA (or SUA or
> > xUA) adapts SCTP to an existing upper layer protocol's needs.  SUA
> > (+SCTP) transports SCCP Users, rather than SCCP.  
> > 
> > Anyway, this discussion is getting off point.  For those folks who
> > have been arguing over SUA vs. M3UA, both are working group work
> > items and are on track to be completed by the group (albeit
> > slowly).
> > 
> > Let's get back to the specific M3UA issue :o)
> > 
> > Cheers,
> > 
> > L. Ong 
> > --
> > 
> > On Thu, 9 Aug 2001 00:50:32    Brian F. G. Bidulock wrote:
> > >Greg,
> > >
> > >Greg Sidebottom wrote:                            (Thu, 09 
> Aug 2001 00:10:04)
> > >> Hi Klaus,
> > >> 
> > >> We could never add such an indication - it is clearly 
> M3UA's mandate from
> > >> the beginning to transport SCCP (and ISUP, TUP).   I 
> have never understood
> > >> the M3UA and SUA to be competing Sigtran solutions for 
> transporting of SCCP
> > >> because SUA doesn't even transport SCCP.
> > >
> > >What is your definition of "transport" here?  Does M3UA "transport"
> > >MTP?  What about the IPSP cases?
> > >
> > >> 
> > >> While I'm on my soapbox ... The real issue in the thread 
> is how far one can
> > >> run with M3UA's routing flexibility before you break the 
> SCCP routing and/or
> > >> management going on a layer above.  (BTW, having an SCCP 
> layer in the SG
> > >> helps with this issue a lot, but I won't go there in 
> this e-mail).
> > >
> > >(Having SUA on SCCP running at the SG would help even more.)
> > >
> > >> How far
> > >> you can run with the M3UA routing flexibility also 
> depends on what subset of
> > >> SCCP services/management is being used by the SCCP-User 
> and applications.
> > >> SUA doesn't have to contend with this issue because it 
> doesn't transport
> > >> SCCP but rather provides the SCCP upper layer interface 
> (and services)
> > >> itself and interworks with the SCCP at the SG.
> > >
> > >Again, what is your definition of "transport"?  Both SUA 
> and M3UAs messages
> > >are parallels to SCCP and MTP PDUs.  Isn't it SCTP which 
> is "transporting"
> > >the MTP and SCCP?  Not M3UA?
> > >
> > >--Brian
> > >
> > >> 
> > >> Cheers,
> > >> 
> > >>    Greg
> > >> 
> > >> ----- Original Message -----
> > >> From: "Gradischnig, Klaus" <[email-masked]>
> > >> To: "sigtran" <[email-masked]>
> > >> Sent: Tuesday, August 07, 2001 4:24 AM
> > >> Subject: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.
> > >> 
> > >> 
> > >> > Greg,
> > >> >
> > >> > whether or not SSNs are removed from RKs I don't care 
> too much. However,
> > >> any
> > >> > indication that m3ua should not be used to transport 
> SCCP would be really
> > >> > objectionable.
> > >> >
> > >> > Klaus
> > >> >
> > >> > > -----Original Message-----
> > >> > > From: Greg Sidebottom [mailto:[email-masked]]
> > >> > > Sent: August 06, 2001 11:18 PM
> > >> > > To: sigtran
> > >> > > Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID 
> in example.
> > >> > >
> > >> > >
> > >> > > Hi Brian,
> > >> > >
> > >> > > As you know I have no vested interest in use of the SSN in
> > >> > > the RK.   I could
> > >> > > be arguing on my spare time (Sorry - I couldn't resist the
> > >> > > Monty Python
> > >> > > quote).  Seriously, I detected some support for leaving in
> > >> > > its use but if I
> > >> > > am in error I will graciously back off.   I have not 
> noticed most
> > >> > > implementers saying to scrap it - I saw notes from two
> > >> > > vendors to leave it
> > >> > > in and I have seen it used by another successfully 
> in a specific
> > >> > > application.  If they have changed their minds then great ,
> > >> > > lets remove it -
> > >> > > I'm really tired of arguing on behalf of others.
> > >> > >
> > >> > > Cheers,
> > >> > >
> > >> > >    Greg
> > >> > >
> > >> > > ----- Original Message -----
> > >> > > From: "Brian F. G. Bidulock" <[email-masked]>
> > >> > > To: "sigtran" <[email-masked]>
> > >> > > Cc: <[email-masked]>
> > >> > > Sent: Monday, August 06, 2001 9:12 PM
> > >> > > Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID 
> in example.
> > >> > >
> > >> > >
> > >> > > > Greg,
> > >> > > >
> > >> > > > Gee, Greg, that would be really cool if only 
> someone could come
> > >> > > > up with a need for doing this M3UA SSN thing.  On 
> the contrary,
> > >> > > > it appears that implementers prefer to scrap it.
> > >> > > >
> > >> > > > So discard it: there is no use for it.
> > >> > > >
> > >> > > > Again, I propose we scrap SSN from the M3UA 
> document altogether.
> > >> > > > Any implementors who care to object?
> > >> > > >
> > >> > > > --brian
> > >> > > >
> > >> > > >
> > >> > > > Greg Sidebottom wrote:                            
> (Mon, 06 Aug 2001
> > >> > > 17:48:56)
> > >> > > > > Hi Brian,
> > >> > > > >
> > >> > > > > Response below ..
> > >> > > > >
> > >> > > > > ----- Original Message -----
> > >> > > > > From: "Brian F. G. Bidulock" <[email-masked]>
> > >> > > > > To: "sigtran" <[email-masked]>
> > >> > > > > Sent: Monday, August 06, 2001 3:25 PM
> > >> > > > > Subject: Re: M3UAv8: SSN in Routing Key and TCAP 
> TID in example.
> > >> > > > >
> > >> > > > >
> > >> > > > > > Greg,
> > >> > > > > >
> > >> > > > > > This issue of SSN is more a matter of what the SIGTRAN
> > >> > > recommendation
> > >> > > > > > for SCCP transport will be.  Will it be SUA or 
> will it be M3UA?
> > >> > > > > > I believe that it should be SUA, as SUA 
> provides all the
> > >> > > interoperability
> > >> > > > > > mechanisms necessary for a separate SG and ASP
> > >> > > implementation to work
> > >> > > > > > together.  M3UA provides no expectation of
> > >> > > interoperability on SCCP.
> > >> > > > > > As such, I cannot understand why SIGTRAN would also
> > >> > > recommend SCCP on
> > >> > > > > > M3UA.  With SUA going to Last Call, SCCP elements
> > >> > > should quite simply
> > >> > > > > > be struck from the M3UA proposal.  Proprietary solution
> > >> > > can do what
> > >> > > > > > they may.
> > >> > > > > >
> > >> > > > > > --brian
> > >> > > > > >
> > >> > > > >
> > >> > > > > [Greg2] I believe that we really think very differently
> > >> > > here (not that
> > >> > > there
> > >> > > > > is anything wrong with that!).
> > >> > > > >
> > >> > > > > Here is my view (ignoring ISUP/TUP for a moment):
> > >> > > > >
> > >> > > > >
> > >> > > > >      - Sigtran transport of TCAP, RANAP, etc:  SUA
> > >> > > > >      - Sigtran transport of SCCP/(TCAP, RANAP ..): Any of
> > >> > > M2PA, M2UA,
> > >> > > M3UA
> > >> > > > >
> > >> > > depending on
> > >> > > > > architectural need
> > >> > > > >      - Sigtran transport of MTP3/SCCP/(TCAP, RANAP..):
> > >> > > M2UA or M2PA
> > >> > > > > depending on
> > >> > > > >
> > >> > >  architectural
> > >> > > > > need
> > >> > > > >
> > >> > > > > Any of M2UA, M2PA, and M3UA transport SCCP 
> within the Sigtran
> > >> > > architecture.
> > >> > > > > SCCP is running at the ASP, and the peer SCCP is at the
> > >> > > SG or at an SS7
> > >> > > > > node.  It goes without saying that for each of these
> > >> > > peers to actually
> > >> > > work
> > >> > > > > together properly, the upper layer SCCP needs to 
> be set up
> > >> > > > > correctly/responsibly in the network.  Having an M3UA
> > >> > > Routing Key use a
> > >> > > > > Subsystem number (which is the original question) may
> > >> > > make this more
> > >> > > > > challenging, or downright impossible for some
> > >> > > applications, but in the
> > >> > > end
> > >> > > > > it is up to the operation of SCCP to make this work.
> > >> > > This doesn't make
> > >> > > it
> > >> > > > > proprietary operation as long as SCCP is used 
> according to
> > >> > > specification.  I
> > >> > > > > don't believe we want/need to import an SCMG analog into
> > >> > > M3UA to make it
> > >> > > > > work for all cases.
> > >> > > > >
> > >> > > > > SUA to me is not for SCCP transport but for TCAP 
> (or RANAP ..)
> > >> > > transport.
> > >> > > > > The SCCP is terminated at the SG so the SUA spec
> > >> > > explicitly handles the
> > >> > > > > interworking between SUA and SCCP SCMG.   The SG is
> > >> > > relied upon to make
> > >> > > > > everything work together underneath the TCAP layer so it
> > >> > > provides more
> > >> > > > > flexibility of application than M3UA.  A similar argument
> > >> > > can be made
> > >> > > for
> > >> > > > > use of M3UA over M2UA - because the SG is relied upon to
> > >> > > make everything
> > >> > > > > work together underneath SCCP and ISUP, it provides more
> > >> > > flexibility in
> > >> > > > > application.  That does not make M3UA superior to M2UA
> > >> > > and cause us to
> > >> > > > > wonder why Sigtran allows us to have two choices for
> > >> > > transport of ISUP.
> > >> > > > >
> > >> > > > > Cheers,
> > >> > > > >
> > >> > > > >    Greg
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > > > --
> > >> > > > Brian F. G. Bidulock
> > >> > > > [email-masked]
> > >> > > > http://www.openss7.org/
> > >> > > >
> > >> > > >
> > >> > > > ---
> > >> > > > You are currently subscribed to sigtran as: 
> [email-masked]
> > >> > > > To unsubscribe send a blank email to
> > >> > > [email-masked]
> > >> > >
> > >> > >
> > >> > >
> > >> > > ---
> > >> > > You are currently subscribed to sigtran as:
> > >> > > [email-masked]
> > >> > > To unsubscribe send a blank email to
> > >> > > [email-masked]
> > >> > >
> > >> >
> > >> >
> > >> > ---
> > >> > You are currently subscribed to sigtran as: [email-masked]
> > >> > To unsubscribe send a blank email to
> > >> [email-masked]
> > >> 
> > >> 
> > >> 
> > >> ---
> > >> You are currently subscribed to sigtran as: [email-masked]
> > >> To unsubscribe send a blank email to 
> [email-masked]
> > >
> > >-- 
> > >Brian F. G. Bidulock
> > >[email-masked]
> > >http://www.openss7.org/
> > >
> > >
> > >---
> > >You are currently subscribed to sigtran as: 
> [email-masked]
> > >To unsubscribe send a blank email to 
> [email-masked]
> > >
> > 
> > 
> > Join 18 million Eudora users by signing up for a free 
> Eudora Web-Mail account at http://www.eudoramail.com
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to 
> [email-masked]
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 14:50:36 -0500

Michael,

With SSN removed from M3UA, there is no competing situation between
SIGTRAN adaption layers.  The choice of whether to implement an
application as an SCCP-User or an MTP-User (including an SCCP
function) exists in SS7 regardless of the existence of SIGTRAN UAs.
That this also exists in SIGTRAN is no suprise.

To take another approach, however, it feasilble to support both
M3UA and SUA at the same SGP/ASP: they have common ASP management
procedures.  For example, the addition of M3UA's DATA message and
routing key parameters to SUA would permit this new combined UA to
support both MTP-Users and SCCP-Users simultaneously.  It is a brief
extension draft to do so.  I can submit it after the draft lock-down
if the WG is interested.

--brian

Young Michael-Y10724 wrote:                                 (Thu, 09 Aug 2001 15:14:32)
> 
>    Brian et all,
>    
>    I found very interesting discussion in previous thread as below and I
>    tend to agree to remove SSN from RC in M3UA.  This inspired me to
>    initialise an new thread on SS7 nework evolution and possible
>    interworking between M3UA and SUA (if I didn't miss anything).  I am
>    more looking for clarification and Sigtran's view/position on subject
>    issue.
>    
>    From an operator's point of view, migrating from SS7 based Signalling
>    network to IP based Signalling network will bring interworking issue,
>    and migration will take a fairly long period.  If my understanding is
>    correct, SCCP based applications protocols (MAP/TCAP, CAP/TCAP, RANAP
>    etc...) can have options to seat on top of either SUA/SCTP or
>    SCCP/M3UA/SCTP in IP domain.  However, unless all the operator's
>    signalling network migrated from SS7 to IP, the interworking shall be
>    mandated to legacy SS7 network.  Assume eventually we will have an
>    pure IP signalling network, shall we mandate the interworking among
>    different implementation approaches (eg. M3UA vs SUA)?
>    
>    Can somebody give me a little bit background information why Sigtran
>    developed so many addaption layers which are sometimes in a competing
>    siuatoin at least to me?
>    
>    Thanks & br,
>    
>    Michael
>    

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

---

---

From: Young Michael-Y10724 <[email-masked]>
Date: Thu, 9 Aug 2001 17:52:13 -0400

Brian,

There is a misunderstanding here.  I am not saying removing SSN from M3UA relates to competing situation between UAs.  I agree with the principle that the specific user adaption layer should not tap upper protocol layer parameters.  Sorry I didn't make it clearer.

In current SS7 network, if an aaplication implemented as a SCCP-User, from MTP layer point of view, it is also a MTP-User.  There is no interworking issue here as there is only one protocol stack here except the MTP3B and SS7 variants cases.  

However, in Sigtran the situation is different.  A SCCP-user application can be implemented either on SCCP/M3UA/SCTP/IP stack or SUA/SCTP/IP stack.  I agree with you, supporting both M3UA and SUA at the same SGP/ASP is doable, but it will complicate the implementation and therefore it will increase the cost.  Now, two options are avaiable: 1) supporting both M3UA and SUA; 2) Supporting interworking between them.  I am looking forward to your draft for more detial information.  From the operator's point of view, they want to see a clear migration path from SS7 to IP.  Believe me, they are not expecting a lot of interworking after migrating their SS7 network to be IP based network.  If my understanding is correct, one of Sigtran's objective is to find a solution for IP based signalling transportation.  The clear migration path from SS7 to IP should be treated as a requirement to Sigtran work.

I hope you agree with me, no matter the applications are implemented as an SCCP/M3UA based or SUA based, they shall interworking with backbone SS7 network unless all the operators upgrade their network to be IP based.  Once we have a pure IP based signalling network, can you depict a clear picture to me how differently implemented applications can talk to each other?

BR,

Michael

> Sent: Thursday, August 09, 2001 12:51 PM
> To: sigtran
> Subject: Re: [M3UA & SUA]: SS7 Network Evolution and possible
> interworking bet ween M3UA and SUA
> 
> 
> Michael,
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 17:38:11 -0500

Michael,

Please see comments below....

Young Michael-Y10724 wrote:                (Thu, 09 Aug 2001 17:52:13)
> 
>    Brian,
>    
>    There is a misunderstanding here.  I am not saying removing SSN from
>    M3UA relates to competing situation between UAs.  I agree with the
>    principle that the specific user adaption layer should not tap upper
>    protocol layer parameters.  Sorry I didn't make it clearer.
>    
>    In current SS7 network, if an aaplication implemented as a SCCP-User,
>    from MTP layer point of view, it is also a MTP-User.  There is no
>    interworking issue here as there is only one protocol stack here
>    except the MTP3B and SS7 variants cases.
>    
>    However, in Sigtran the situation is different.  A SCCP-user
>    application can be implemented either on SCCP/M3UA/SCTP/IP stack or
>    SUA/SCTP/IP stack.

I see no difference here.  The SCCP-User should not need to change if it is
riding over SCCP or SUA.  The SCCP-User should need no knowledge of the
SCCP-Provider, whether that provider be implemented as pure SCCP or as an SUA
implementation of an SCCP provider.  The SCCP-User application developer
does not need to know the difference, and when the SCCP-User application runs,
it cannot tell the difference.

As far as the SCCP-User is concerned, there is no difference.

It is easily possible to integrate an SS7 SCCP-Provider with an SUA
SCCP-Provider at a single node.  (The node has a "local" SG function
which can support the same SUA AS as an internal SG or SGP).  In such
arrangements, the SCCP-User is completely unaware of what is providing
SCCP services, depending on local conditions it may be SUA or it may
be an SS7 SCCP.

Note also that SUA needs a fully SCCP to support it.  It does not provide
SCCP services in itself, it merely transports those services.

So, you are contrasting SCCP-User/SUA/SCCP/MTP with SCCP-User/SCCP/M3UA/MTP.
How about SCCP-User/SUA/SCCP/M3UA/MTP?  Or, SCCP-User/SUA/SCCP/M3UA/MTP/
M2UA/M2PA?  (For the backhaul case).  

> I agree with you, supporting both M3UA and SUA at
>    the same SGP/ASP is doable, but it will complicate the implementation
>    and therefore it will increase the cost.  Now, two options are
>    avaiable: 1) supporting both M3UA and SUA; 2) Supporting interworking
>    between them.  I am looking forward to your draft for more detial
>    information.  From the operator's point of view, they want to see a
>    clear migration path from SS7 to IP.  Believe me, they are not
>    expecting a lot of interworking after migrating their SS7 network to
>    be IP based network.  If my understanding is correct, one of Sigtran's
>    objective is to find a solution for IP based signalling
>    transportation.  The clear migration path from SS7 to IP should be
>    treated as a requirement to Sigtran work.
>    
>    I hope you agree with me, no matter the applications are implemented
>    as an SCCP/M3UA based or SUA based, they shall interworking with
>    backbone SS7 network unless all the operators upgrade their network to
>    be IP based.  Once we have a pure IP based signalling network, can you
>    depict a clear picture to me how differently implemented applications
>    can talk to each other?

For the IPSP case (pure IP network) I can see what you're getting at, however,
in that case, the full SUA IPSP scenario doesn't make too much sense to me:
it would try to make too much of an SS7 network out of an IP network.  The
same is true for the IPSP M3UA cases.

SCCP-Users within an IP only network can be completely satisfied by ISO NSD.
ISO over TCP is already provided for in RFC: extension of ISO NSD carriage
directy over SCTP would be far more advantageous that attempting an entire IP
domain solution using SUA.  (I already brought this up and got screamed at.)

In the IPSP case for MTP, I think that you'll find that SCTP provides all of
the necessary capabilities already.  Change point code to IP address and
change SLS to stream id (or TCP socket) and you have an IP Domain MTP network.
There is no need for transfer functions or STP concepts in an IP Domain MTP
network, that function is already provided by IP routers and the IP network.

Do you see what I'm getting at?  I don't agree with using M3UA or SUA in the
IPSP or IP only case at all.  Where no interworking is required with an SS7
network, the services provided by TCP or SCTP, IP, and ISO NSD over TCP or
SCTP will suffice to provide all the necessary services to both MTP and SCCP
Users.  The only hurdle would be QOS, but neither SCTP nor any UA helps you
there anyway.

M3AU and SUA only has use in the backhaul case as far as I can see.

In the IP domain, MTP can be provided by SCTP itself and SCCP can be provided
using an NSD wrapper on SCTP.  Therefore, in the IP domain MTP-Users would use
SCTP and SCCP-Users would use SCTP.  With the necessary QOS, neither MTP-Users
nor SCCP-Users would be able to detect that they are using an IP network
rather than an SS7 network.

Both M3UA and SUA drafts have be criticized for not fully addressing the IPSP
cases.  I believe that other drafts are necessary for this completely IP
world which show MTP-Users running directly on SCTP and SCCP-Users running
directly on SCTP.  That is, rather than exporting the user interface over
SCTP, adapt the user interface to SCTP ULP.

I would be happy to write the drafts if the WG is interested.

--brian

>    > From: Brian F. G. Bidulock [[1]mailto:[email-masked]]
>    > [2]http://www.openss7.org/
>    >
>    >
>    > ---
>    [email-masked]
> References
>    1. mailto:[email-masked]
>    2. http://www.openss7.org/

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

---

---

From: Young Michael-Y10724 <[email-masked]>
Date: Thu, 9 Aug 2001 22:52:38 -0400

Brian,

Thanks for your detail explanation.  Please see my commments in line.

> Sent: Thursday, August 09, 2001 3:38 PM
> To: sigtran
[MYH] Agreed.

> As far as the SCCP-User is concerned, there is no difference.
[MYH] Agreed.
> SCCP services, depending on local conditions it may be SUA or it may
[MYH] Agreed.  The SG function is a must.
> SCCP services in itself, it merely transports those services.
[MYH] It is true in the case of interworking with SS7 network.  However, I don't see the necessity for a full SCCP in the case of SUA peer to peer.
> M2UA/M2PA?  (For the backhaul case).  
[MYH] Actually this is my concern.  From SCCP-User point of view, it doesn't care about underlying protocol as long as its required services are provided.  However, the operators (or some vendors) have to consider this as there are so many choices available.
> same is true for the IPSP M3UA cases.
[MYH] Agreed.  That's why I am confused of.  Later, you pointed out that both SUA and M3UA haven't addressed IPSP case very well.
> domain solution using SUA.  (I already brought this up and 
[MYH] Sorry, first time for me to meet ISO NSD.  I'd appreciate if you can foward me the related RFC.  I am very interested in it.  How about other people's opinion in Sigran community?
> network, that function is already provided by IP routers and 
[MYH} Agreed.  However there are a lot of different ways to do one job, but we need one way to be standardised here.
> Users.  The only hurdle would be QOS, but neither SCTP nor 
[MYH]  I can clearly see you what you are getting at, but I can only comment after I see the ISO NSD.  Meanwhile, are you proposing removing IPSP peer to peer or all IP case from current SUA or M3UA spec?
> M3AU and SUA only has use in the backhaul case as far as I can see.
[MYH] Therefore my understanding is M3UA and SUA only has use in case of interworking and the interworking must be with SS7 network.  Please correct me if I am wrong.
> rather than an SS7 network.
[MYH] I would be glad to see the SCCP can be provided by NSD/SCTP in IP domain.
> SCTP, adapt the user interface to SCTP ULP.
[MYH] I agree.  Just to clarify myself again, before all the signalling network to be IP based, the interworking must go through SS7 network, therefore operators have flexibility to deploy different xUA over SCTP.
> I would be happy to write the drafts if the WG is interested.
[MYH] I am very interested in it.
> >    > >    tend to agree to remove SSN from RC in M3UA.  
> This inspired me
> >    to

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 02:10:03 -0500

Michael,

Please see additional comments below...

Young Michael-Y10724 wrote:                                 (Thu, 09 Aug 2001 22:52:38)
> > >    There is a misunderstanding here.  I am not saying
> > >    removing SSN from M3UA relates to competing situation
> > >    between UAs.  I agree with the principle that the
> > >    specific user adaption layer should not tap upper
> > >    In current SS7 network, if an aaplication implemented
> > >    as a SCCP-User, from MTP layer point of view, it is
> > >    also a MTP-User.  There is no interworking issue here
> > >    as there is only one protocol stack here except the
> > >    MTP3B and SS7 variants cases.
> > >
> > >    However, in Sigtran the situation is different.  A
> > >    SCCP-user application can be implemented either on
> > >    SCCP/M3UA/SCTP/IP stack or SUA/SCTP/IP stack.
> >
> > I see no difference here.  The SCCP-User should not need to
> > change if it is riding over SCCP or SUA.  The SCCP-User
> > should need no knowledge of the SCCP-Provider, whether that
> > provider be implemented as pure SCCP or as an SUA
> > implementation of an SCCP provider.  The SCCP-User
> > application developer does not need to know the difference,
> > and when the SCCP-User application runs, it cannot tell the
> > difference.
>
> [MYH] Agreed.
> 
> >
> > It is easily possible to integrate an SS7 SCCP-Provider with
> > an SUA SCCP-Provider at a single node.  (The node has a
> > "local" SG function which can support the same SUA AS as an
> > internal SG or SGP).  In such arrangements, the SCCP-User is
> > completely unaware of what is providing SCCP services,
> > depending on local conditions it may be SUA or it may be an
> > SS7 SCCP.
>
> > Note also that SUA needs a fully SCCP to support it.  It
> > does not provide SCCP services in itself, it merely
> > transports those services.
>
> [MYH] It is true in the case of interworking with SS7 network.
> However, I don't see the necessity for a full SCCP in the case
> of SUA peer to peer.

I agree.  Even more, I would say that SCCP is not even required
for SCCP-User peer to peer interation: just an NS-Provider.

> 
> >
> > So, you are contrasting SCCP-User/SUA/SCCP/MTP with
> > SCCP-User/SCCP/M3UA/MTP.  How about
> > SCCP-User/SUA/SCCP/M3UA/MTP?  Or,
> > SCCP-User/SUA/SCCP/M3UA/MTP/ M2UA/M2PA?  (For the backhaul
> > case).
>
> [MYH] Actually this is my concern.  From SCCP-User point of
> view, it doesn't care about underlying protocol as long as its
> required services are provided.  However, the operators (or
> some vendors) have to consider this as there are so many
> choices available.
> 

"That's the nice thing about standards:
 there's so many to choose from."

> >
> >
> > > I agree with you, supporting both M3UA and SUA at the same
> > > SGP/ASP is doable, but it will complicate the
> > > implementation and therefore it will increase the cost.
> > > Now, two options are avaiable: 1) supporting both M3UA and
> > > SUA; 2) Supporting interworking between them.  I am
> > > looking forward to your draft for more detial information.
> > > From the operator's point of view, they want to see a
> > > clear migration path from SS7 to IP.  Believe me, they are
> > > not expecting a lot of interworking after migrating their
> > > SS7 network to be IP based network.  If my understanding
> > > is correct, one of Sigtran's objective is to find a
> > > solution for IP based signalling transportation.  The
> > > clear migration path from SS7 to IP should be treated as a
> > > requirement to Sigtran work.
> > >
> > > I hope you agree with me, no matter the applications are
> > > implemented as an SCCP/M3UA based or SUA based, they shall
> > > interworking with backbone SS7 network unless all the
> > > operators upgrade their network to be IP based.  Once we
> > > have a pure IP based signalling network, can you depict a
> > > clear picture to me how differently implemented
> > > applications can talk to each other?
> >
> > For the IPSP case (pure IP network) I can see what you're
> > getting at, however, in that case, the full SUA IPSP
> > scenario doesn't make too much sense to me: it would try to
> > make too much of an SS7 network out of an IP network.  The
> [MYH] Agreed.  That's why I am confused of.  Later, you
> pointed out that both SUA and M3UA haven't addressed IPSP case
> very well.

They don't address the IPSP case well at all.  Most of the
"export-the-user-interface" stuff in M3UA/SUA which is necessary
for the backhaul case is useless and bloated in the peer-to-peer
case.

> 
> >
> > SCCP-Users within an IP only network can be completely
> > satisfied by ISO NSD.  ISO over TCP is already provided for
> > in RFC: extension of ISO NSD carriage directy over SCTP
> > would be far more advantageous that attempting an entire IP
> [MYH] Sorry, first time for me to meet ISO NSD.  I'd
> appreciate if you can foward me the related RFC.  I am very
> interested in it.  How about other people's opinion in Sigran
> community?

Look at RFC 1006, 1859 and 2126.  Also look at the ISO NSD
documents (X.200/ISO/IEC 7498 and X.213/ISO/IEC 8348) and
the long thread "Reinventing the Wheel".

> 
> >
> > In the IPSP case for MTP, I think that you'll find that SCTP
> > provides all of the necessary capabilities already.  Change
> > point code to IP address and change SLS to stream id (or TCP
> > socket) and you have an IP Domain MTP network.  There is no
> > need for transfer functions or STP concepts in an IP Domain
> > MTP network, that function is already provided by IP routers
> > and the IP network.
>
> [MYH} Agreed.  However there are a lot of different ways to do
> one job, but we need one way to be standardised here.

"The nice thing about standards: there are so
 many to choose from."

> >
> > Do you see what I'm getting at?  I don't agree with using
> > M3UA or SUA in the IPSP or IP only case at all.  Where no
> > interworking is required with an SS7 network, the services
> > provided by TCP or SCTP, IP, and ISO NSD over TCP or SCTP
> > will suffice to provide all the necessary services to both
> > MTP and SCCP Users.  The only hurdle would be QOS, but
> > neither SCTP nor any UA helps you there anyway.
>
> [MYH]  I can clearly see you what you are getting at, but I
> can only comment after I see the ISO NSD.  Meanwhile, are you
> proposing removing IPSP peer to peer or all IP case from
> current SUA or M3UA spec?

Yes.

> [MYH] Therefore my understanding is M3UA and SUA only has use
> in case of interworking and the interworking must be with SS7
> network.  Please correct me if I am wrong.

That is my point.  M3UA and SUA are only useful for interworking
with an SS7 network.  When completely in the IP domain, they are
overbloated and useless, and often attempt to recreate an SS7
network within the IP network by treating SCTP as "wires".

> 
> >
> > In the IP domain, MTP can be provided by SCTP itself and
> > SCCP can be provided using an NSD wrapper on SCTP.
> > Therefore, in the IP domain MTP-Users would use SCTP and
> > SCCP-Users would use SCTP.  With the necessary QOS, neither
> > MTP-Users nor SCCP-Users would be able to detect that they
> > are using an IP network rather than an SS7 network.
>

It can.  Class 0 can be provided by UDP.  SSCOP-MCE can also
provide SCCP directly (it provides NSD).

> >
> > Both M3UA and SUA drafts have be criticized for not fully
> > addressing the IPSP cases.  I believe that other drafts are
> > necessary for this completely IP world which show MTP-Users
> > running directly on SCTP and SCCP-Users running directly on
> > SCTP.  That is, rather than exporting the user interface
> > over SCTP, adapt the user interface to SCTP ULP.
>
> [MYH] I agree.  Just to clarify myself again, before all the
> signalling network to be IP based, the interworking must go
> through SS7 network, therefore operators have flexibility to
> deploy different xUA over SCTP.
> 
> >

Are others?

--brian

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

---

---

From: Amish Chana <[email-masked]>
Date: Fri, 10 Aug 2001 22:13:24 +0100

Brian,

See comments below....

Amish

[snip]
>network within the IP network by treating SCTP as "wires".

True.

> > [MYH] I am very interested in it.

I'd also be interested in drafts that address the IPSP, but don't re-build 
SS7 analogies in the IP space - yet achieve the QoS requirements.

Just one question: You mention having SCCP users running directly over SCTP. 
What about the functions currectly performed by SCCP, e.g. GTT and SRF?

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 16:35:45 -0500

Amish,

Amish Chana wrote:                                          (Fri, 10 Aug 2001 22:13:24)
> SS7 analogies in the IP space - yet achieve the QoS requirements.

Unfortunately addressing QoS requirements are largely outside the
scope of the SIGTRAN WG.  Even outside the scope of TSV.  Perhaps
a draft could point to DIFFSERV or MPLS or other IP domain approaches,
but would rely on these other mechanisms to provide the underlying
IP QoS necessary to support SCCP QoS.  The draft could speak, I suppose,
to how to map SCCP-User QoS parameters (protocol class, sequence control,
hop counters, etc.) into DIFFSERV or MPLS parameters.

Several more interested parties and I will write the draft.  Was your
interest primarily SPA or M3PA?

> What about the functions currectly performed by SCCP, e.g. GTT and SRF?

GTT => DNS, ENUM, LDAP
SRF => IP Routing

The SCCP-User is unaware of the mechanisms used to perform address
translation or relaying.  As long as the message gets to the destination
SCCP-User, there is no difficulty.  This is how ISO NSD runs on IP
today.

Actually there is nothing stopping the draft from addressing SCCP/UDP-TCP
and SCCP/SSCOP-MCE in the same blow.

--brian

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

---

---

From: Amish Chana <[email-masked]>
Date: Fri, 10 Aug 2001 23:25:09 +0100

Brian,

Both would interest me. SPA for TCAP/RANAP and M3PA for ISUP.

Amish.

---

---

From: Jeff Copley <[email-masked]>
Date: Mon, 20 Aug 2001 14:20:50 -0500

Michael,

As I am working through this thread I see the absence of M2PA.  M2PA can
certainly carry SCCP as does M3UA.

Jeff

> Young Michael-Y10724 wrote:
> 
> Brian,
> 
> SUA/SCTP/IP stack.  I agree with you, supporting both M3UA and SUA at
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 15:21:23 -0500

Jeff,

I think that it is pretty clear that M2PA does not represent
a final choice for the completely IP domain.  Treating an
IP network like a bunch of wires emulated using SCTP is definitely
not running SS7 in the IP domain in my mind: it is just an SS7
network made up of SCTP "wires" where the IP network is demoted
to a carrier facility.

It would be a similar statement, and just as germane to the
discussion, to say that PWE3 can carry SCCP (by emulating a
T1/E1/J1, time slot or unchannelized).

--brian

Jeff Copley wrote:                                           (Mon, 20 Aug 2001 14:20:50)
> > > (Thu, 09 Aug 2001 15:14:32)
> > > >
> > > >    Brian et all,
> > > >
Content-Description: Card for Jeff Copley
> begin:vcard 
> n:Copley;Jeff
> tel;work:972.519.3758
> x-mozilla-html:FALSE
> org:Alcatel USA, Inc.
> version:2.1
> email;internet:[email-masked]
> adr;quoted-printable:;;1000 Coit Road=0D=0AMS NSGAP;Plano;Texas;75075-5813;USA
> x-mozilla-cpt:;20864
> fn:Jeff Copley
> end:vcard
> 
> 
> 

Content-Description: footer

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

---

---

From: Jeff Copley <[email-masked]>
Date: Mon, 20 Aug 2001 16:24:24 -0500

Brian,

It's all made up of wires.  In the beginning we had the telegraph.  In
the end, IP will be old technology.  How we get there is the issue.  How
many stumbles and falls we make.  I like small steps and strong footing.

Jeff

"Brian F. G. Bidulock" wrote:
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 17:09:30 -0500

Jeff,

Two things (consider this levity) :)

1) It is not all made up of wires: Carrier pidgeons are not wires.  Did you
   hear about the successful ICMP Ping using real carrier pidgeons?  Wireless
   IP networks are not made up of wires at the core (just on the edge and
   short wires at that).  The original ALOHA protocol which led to Ethernet
   was wireless.  Were you aware of these things called wireless devices,
   Jeff? ;)  I even have a several phones that work without wires!

2) IP is not old technology: it is the old and the new technology, the ever
   evolving panacea of connection-less (accent on the connection-less)
   datagram services: the peer to peer precept of the Internet heralded both
   for its success and its simplicity, that has outlived and outgrown every
   wire-connected WAN flavor-of-the-day to come out of the SCN world.

Better toe the IP line Jeff before someone calls you a bell-head ;)

--brian

Jeff Copley wrote:                                           (Mon, 20 Aug 2001 16:24:24)

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

---