Subject: RE: M3UA also affected : [SUA issue 17] IPSP cases.

From: "Antonio Roque-Alvarez (ECE)" <[email-masked]>
Date: Tue, 28 Aug 2001 13:12:43 +0200

Hello,

Please, see comments inline...

Cheers,
Antonio

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 28, 2001 11:11 AM
To: sigtran
Cc: [email-masked]
Subject: RE: [SUA issue 17] IPSP cases.

Hi Brian,

> Which IPSP sends APSUP?  

Which ever one wants to.

> What happens if both IPSPs sends ASPUP?

Then you may get 2 SUA 'associations' - if this is
being done within a single operator network, it can
be handled as a network management issue.  

> When one IPSP sends ASPAC for an RC does it activate it for both
> IPSPs?  Or, does the other IPSP need to send ASPAC as well?  

I have always thought it is then active for both.  By accepting
the ASPAC, the recieving IPSP is implicitly accepting the RC.

[Antonio] This is something that also affects M3UA so I am interested... 
When an IPSP_1 receives an association establishment, an ASPUP msg. and a ASPAC msg. with RC_A ( which implies traffic for DPC_A )from IPSP_2, then IPSP_1 may execute a MTP_RESUME for DPC_A to the MTPL3-User. 
But, how the user at IPSP_2 knows which traffic is IPSP_1 interested ( in other words, what DPC(s) is IPSP_1 represented by ). 
I think that IPSP_1 should send ( trough the already established association ) ASPUP and ASPAC with RC_B. Then, IPSP_2 may then execute MTP_RESUME for DPC_B to its users.

Any comments on this ?

> When CO messages are exchanged, how does the receiving IPSP indicate
> protocol specific error conditions to the other IPSP?  (i.e, those
> which are provided peer-to-peer by the ER message in SCCP?).

COERR message.

> Is there any coupling of connection sections between IPSP?  

I haven't seen a requirement for coupling of connection sections.

> Does an IPSP ever act as a relay point?  As an SCCP relay?  As an MTP
> relay?  

As per SUA v7, no.  The SUA relay has not been well defined, as I 
understand it was something that Gery supported & we agreed that 
we should allow it, but not detail how it can be used.  Its use
could be specified in an extension draft.  It does not act as
an SCCP relay nor an MTP relay.

> What is the role of the AMF for IPSPs?  Does the AMF sit
> above or below the SCCP/SCCP-User interface?  

Below the use interface.  AMF is a function that SUA can use,
is somewhat analagous to GTT.  

> Does an IPSP provide an SCCP/SCCP-User interface to local SCCP-Users?  

Yes, just as an ASP would.

> Does an IPSP need to support multipled associations and multiple 
> routing contexts between IPSPs?  

No, but it may.  Implementation specific.

> What parts of the SCCP state machines must be implemented at the 
> IPSP?  

Enough to ensure proper working of the IPSP.

> Can an SG be both an SGP and an IPSP?

Anything is possible, but I probably wouldn't recommend this 
kind of configuration.  
 
====

Some things that I think could be better specified:

IPSP -> provides a user interface.  Does not provide relay functionality

SUA Relay Point -> does not provide a user interface. Does provide relay
functionality.

John

---
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: Tue, 28 Aug 2001 14:04:07 -0500

Antonio,

IPSP cases is also an issue for M3UA.  I think that similar
questions need to be answered and clarifications provided.

--brian

Antonio Roque-Alvarez (ECE) wrote:                        (Tue, 28 Aug 2001 13:12:43)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 28 Aug 2001 12:38:36 -0700

This is how I assumed that IPSP - IPSP worked, at least for M3UA.  To put it
simply, I assumed that the M3UA would be symmetrical in this case.  Each
side would need to drive its state (UP & ACTIVE) to the other side.  When
both are ACTIVE, traffic can flow.  This is per association.  This is one
association not two, but the traffic flow can be controlled from both sides.

The only difference is that one side needs to act as server and the other as
client for the setting up of SCTP associations; in my implementation, I have
made this a configurable item.  

I view AS/RK/RC as IPSP specific.  When one side sends an ASPAC, it is only
activating its AS/RK/RC (i.e., it can receive traffic for this RK
definition).  The other side must send an ASPAC to activate its AS/RK/RC so
that a two-way flow can occur.

John

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, August 28, 2001 2:04 PM
> To: sigtran
> Subject: Re: M3UA also affected : [SUA issue 17] IPSP cases.
> 
> 
> Antonio,
> 
> > When an IPSP_1 receives an association establishment, an 
> ASPUP msg. and a ASPAC msg. with RC_A ( which implies traffic 
> for DPC_A )from IPSP_2, then IPSP_1 may execute a MTP_RESUME 
> for DPC_A to the MTPL3-User. 
> > But, how the user at IPSP_2 knows which traffic is IPSP_1 
> interested ( in other words, what DPC(s) is IPSP_1 represented by ). 
> > I think that IPSP_1 should send ( trough the already 
> established association ) ASPUP and ASPAC with RC_B. Then, 
> IPSP_2 may then execute MTP_RESUME for DPC_B to its users.
> > 
> > Any comments on this ?
> > 
> > 
> > 
> > To unsubscribe send a blank email to 
> [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]
> 

---

---

From: Kurt Kite <[email-masked]>
Date: Tue, 28 Aug 2001 15:02:02 -0500

My view is similar to John's. See below for more comments.

/Kurt

> made this a configurable item.

I actually have both sides initiate the SCTP association. SCTP supports both
sides initiating the request and will resolve both requests to the same association.

I treat ASPUP the same way. Both sides will send it.

> that a two-way flow can occur.

I have this view as well.

> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 15:30:10 -0500

Kurt, John,

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.

Can we state it one way or the other in the drafts so that an IPSP
knows what to expect?

Then there is the problem of peer messages and state machine
placement...

--brian

Kurt Kite wrote:                                             (Tue, 28 Aug 2001 15:02:02)

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

---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 09:03:43 +0300

Hi Brian, Kurt & John S,

> alluded to only one side requiring an ASPUP, not both.

So, chapter 4 in both SUA & M3UA will discuss this symetrical
arrangement.

Ken & Greg - consider this a requrest.
 
> Can we state it one way or the other in the drafts so that an IPSP

Will do.

> Then there is the problem of peer messages and state machine

Can you let us know what you are expecting?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 02:11:20 -0500

John,

Please see questions below...

John Schantz wrote:                                   (Tue, 28 Aug 2001 12:38:36)
> that a two-way flow can occur.

If I follow you correctly, this ASPAC is only one sided and only permits
a unidirectional traffic flow.  An ASPAC from each side is required for
bidirectional traffic.

When one side sends ASPAC, which AS/RK/RC is it activating?  Is it the
AS/RK/RC of the peer?  That is, if one side has sent ASPAC and the other
has not, traffic can only flow from the side receiving the ASPAC to the
side sending it.

If this is the case, the side sending the ASPAC is would not be permitted
to send data until it receives an ASPAC?  If I follow you correctly, then
the ASPAC Ack doesn't really do much because the sender of the ASPAC would
not be permitted to send data after the receipt of an ASPAC Ack: it must
wait for an ASPAC from its peer before sending data.

If I follow you correctly, would it not be possible for the peer to activate
the other direction of traffic flow on another association if it wanted
to?

Could the possibility of a unidirectional situation not cause havoc for
MTP's traffic management?  MTP is always full duplex in that if a
destination is prohibited to a MTP-User the MTP-User also can expect to
receive no messages from the prohibited destination.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 02:36:23 -0500

John,

Please see comments below...

John Loughney wrote:                                  (Wed, 29 Aug 2001 09:03:43)
> So, chapter 4 in both SUA & M3UA will discuss this symetrical

It sounds to be different enough from the backhaul case to warrant
it's own sub-section and own procedures.

> Can you let us know what you are expecting?

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/

---