Subject: RE: [SUA issue 17 & M3UA issue #11] IPSP cases.

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 6 Sep 2001 12:09:01 +0200

Hi, 

Regarding a few concerns expressed by Brian in a previous mail about handling of links, linksets, routes, routesets, the changeover procedure and management inhibiting, here is some reassuring material:

The use of several links in a linkset, several routes and the changeover procedure, provides redundancy in MTP networks, and also increases the signalling capacity of a single link.

What must be achieved by M3UA is a message delivery without duplication or loss, in sequence when required, and also some redundancy in order to avoid a single point of failure.

In an IP network, the message delivery without duplication or loss is achieved by the SCTP, which also grants the sequence of the messages, refer to RFC 2960.

Network redundancy is provided by having several IP paths accessed through the corresponding IP routers for a given point to point communication, and IP has very powerful dynamic routing protocols (e.g. OSPF) among the routers to handle these paths, much better than the static methods of the MTP.

In order to provide nodal redundancy, SCTP provides multi-homing procedures, which apply to a single SCTP association, so multiple SCTP associations are not needed at all to provide redundancy, and applications don't have to be coordinated to achieve this, since SCTP takes care of it on its own.

And last, but not least, in order to provide the management inhibiting, an IPSP only needs to send an ASPIA message to prevent its peer from sending any traffic.

BR // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 9:36 AM
> To: sigtran
> Subject: Re: M3UA also affected : [SUA issue 17] IPSP cases.
> 
> 
> John,
> 
> Please see comments below...
> 
> John Loughney wrote:                                  (Wed, 
> 29 Aug 2001 09:03:43)
> > Hi Brian, Kurt & John S,
> > 
> > > That sounds reasonable to me and that would handle ASPSM and ASPTM
> > > procedures, but this symmetrical arrangement is far from 
> obvious in
> > > the draft.  In fact, the authors of both M3UA and SUA have both
> > > alluded to only one side requiring an ASPUP, not both.
> > 
> > So, chapter 4 in both SUA & M3UA will discuss this symetrical
> > arrangement.
> 
> It sounds to be different enough from the backhaul case to warrant
> it's own sub-section and own procedures.
> 
> > 
> > Ken & Greg - consider this a requrest.
> >  
> > > Can we state it one way or the other in the drafts so that an IPSP
> > > knows what to expect?
> > 
> > Will do.
> > 
> > > Then there is the problem of peer messages and state machine
> > > placement...
> > 
> > Can you let us know what you are expecting?
> > 
> > John
> 
> As described on the SUA issue thread, it does not appear that SUA has
> enough arguments to its messages to support SCCP peer PDUs.  Because
> there is no real reference other than the SCCP state machines for peer
> operation, if SUA message cannot support peer PDUs it is 
> really unclear
> how two IPSP SUA implementations can expect to interoperate.
> 
> M3UA does not support a complete MTP peer PDU set either.  It is the
> opinion of some that it does not need to, but where M3UA does 
> not provide
> an equivalent message to an MTP peer PDU, it falls squarely 
> on the draft
> to describe in what interoperable fashion the services 
> otherwise provided
> by those missing PDUs are provided now by SCTP or why those 
> services are
> not required for MTP-like transport.
> 
> For SUA I am concerned that existing SCCP state machines, as 
> an MTP-User
> has access to the entire routing label of each message, and 
> even describes
> the explicit use of DPC in SCCP routing.  SCCP 
> implementations are permitted
> to use any of the information which comes with the 
> MTP-TRANSFER primitive
> in providing services to SCCP-Users.  Without the information from the
> RL, SCCP cannot perform routing functions as described in the 
> SCCP specs.
> 
> For M3UA I am concerned that existing MTP state machines have 
> available
> to them information concerning the links, linksets, routes 
> and routesets
> upon which messages are both transmitted and received.  MTP also is
> aware of sequence numbers associated with links and has procedures to
> avoid duplication and missequencing of messages.  The changeover and
> changeback PDUs in MTP support these services and it is not apparent
> how similar services are to be provided between M3UA IPSP peers.
> Although there are some ways of performing similar things with SCTP,
> most of these procedures would require end-to-end application 
> coordination
> across multiple SCTP associations which is just not present 
> in all traffic
> modes described for M3UA.  Inhibiting is another concern.  Management
> inhibiting of routes and routesets is another.
> 
> For SUA it is unclear what is necessary to support SUA relay nodes in
> the IP domain, and unclear whether one really needs to build an SS7
> network inside IP in such a fashion.
> 
> For M3UA it is unclear what is necessry to support the 
> transfer function
> at an IPSP, and, again, unclear whether one really needs to build an
> SS7 network inside IP in such a fashion.
> 
> These are some of the issues I expect to surface once the 
> IPSP behavior
> is opened up.
> 
> There is enough IPSP stuff missing from the drafts that I 
> wonder if the
> drafts should not advance with backhaul only and be followed 
> with drafts
> addressing the IPSP case separately.
> 
> --brian
> 
> -- 
> 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]