Subject: Re: SUAv7 : General Comments

From: [email-masked]
Date: Sat, 1 Sep 2001 15:02:05 +0530

resending ..

Brian ,

This scenario is somewhat related or may be an extension of SUA as relay Node
case.  If we allow SUA to act as a relay Node in a IPSP-IPSP case (which is
still being discussed in another thread) and we have a network configuration
like ASP1- ASP2 - ASP3. In this configuration ASP1 route messages towards ASP3
via ASP2 (or ASP2 acts as relay). In this configuration all ASPs (ASP1 , ASP2
and ASP3) should not be required to connect to SG for sending/receiving messages
to/from SS7 network. If we only allow the case where all ASPs that need to
send/receive messages from SS7 network will have to directly connect to SG, it
will be administratively difficult and less optimum when number of nodes (ASPs)
in the IP network increase. Administratively difficult because all those ASPs
will have to be configured at SG and less optimum because there may be ASPs that
only occasionally exchange messages with SS7. So I am for allowing the case
where one or more ASPs connect to SG and other ASPs in the IP network use these
ASPs for sending/receiving messages from SS7 network.

Also allowing/disallowing this case can have impact on segmentation/reassembly
scheme being followed for CL transfer case. If SCCP at SG can be non terminating
SCCP , ASP need to support reassembly but it SCCP at SG can only be terminating
SCCP it will always pass reassembled messages to NIF/SUA and ASP need not to
support reassembly.

What do you think ?

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/31/2001 09:55:56 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]>
cc:    (bcc: Sandeep Mahajan/HSS)

Subject:  Re: SUAv7 : General Comments

Sandeep,

Pardon me.  I misunderstood.

It is hard to conceive of an SG - ASP1 - ASP2 case.  SG - ASP1 would be
backhaul, but ASP1 - ASP2 would be peer.  The peer case is not well
enough defined in the spec to way what would happen.  Also, I don't see
the point of ASP1 (or an number of ASPs in peer arrangement between SG
and ASP2) acting as relays.   SG should just go straight to ASP2.  What
is the purpose of having SUA relays?

--brian

[email-masked] wrote:                            (Fri, 31 Aug 2001
16:18:17)
>
> Brian ,
>
> I was talking about the SEP - SG - ASP1 - ASP2 case.
> In this case SEP sends a message to SG which is destined for SCCP User at
ASP2.
> Since ASP2 is not directly connected to SG. SG sends this message to ASP1,
ASP1
> apply AMF to this message, determines the next node and relays the message to
> ASP2. ASP2 then pass this message to local SCCP/SUA User. If we extend this
case
> there can be any number of intermediate nodes between SG and final ASP. In the
> above network configuration it is possible that GTT is not fully resolved at
> SCCP on SG (GTT yields RI= Route on GTT), but gets resolved at some
intermediate
> node in SUA network. This case can not be supported as a regular backhaul
case..
>
> Does/Should  SUA support this case ?
>
> Best Regards,
> -Sandeep

--
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: [email-masked]
Date: Sat, 1 Sep 2001 14:34:40 +0530

Brian ,

What do you think ?

Best Regards,
-Sandeep

Sandeep,

--brian

ASP2.
ASP1
case
intermediate
case..

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 1 Sep 2001 14:02:44 -0500

Sandeep,

As I state in the Network Evolution thread, I don't see any point for
SUA relay.  I don't see where SUA IPSP is anything but an ISO Network
Server provider which has already been specified for TCP/IP (and could
easily be extended for SCTP).  There is no need to try to recreate an
SS7 network in an IP network to accomplish what ISO accomplishes
directly and what IP is fully capable of without SUA.  There is no
need for all that RSERPOOL functionality in an attempt to circumvent
IP's QoS deficiencies: emerging IP QoS approaches should be adopted
instead.  The only significant difference between ISO and TCP is the
lack of record delimitation.  This can be handled either by TCP w/
frames or SCTP.  That also addresses segmentation issues.  Existing
RFCs are in place for carrying ISO with TCP/IP.

SCCP just provides service to an NS-User.  The SCCP protocol is tailored
for building NS-Providers which run on SS7.  All that is required for
SCCP Users (and other NS-Users) is a ISO NS-Provider for TCP/IP.  The
RFCs exist for this, why not use them?

--brian

On Sat, 01 Sep 2001, [email-masked] wrote:

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

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

---

---

From: [email-masked]
Date: Mon, 3 Sep 2001 09:12:54 +0300

Hi Brian,

> Sandeep, Gery and I have been discussing whether it is possible to
> implement SCCP's full range of functionality to meet SUA's SCCP
> transparency claims and still meet SUA's objectives of not needing
> to modify (or "enhancing") either the SG's SCCP or the SCCP/SCCP-User
> interface.
> 
> Two issues remain from this thread (but they are already logged
> issues).  Support for decoupled operation without final GTT at the
> SG (Issue 14), and IPSP Condsiderations.
> 
> You have assured us that you, Ken and Greg are working on a proposal
> which might resolve IPSP Considerations.  Issue 14 has a standing
> proposal for resolution (REG REQ procedure) which has not been adopted
> and as such is still an open issue.

For issue 14, could a paragraph in chapter 4 be written to meet your needs,
with your proposal?  
 
> Sandeep and Gery's comments and insights on this thread have helped to
> frame these issues.  Much discussion has been focused on possible
> functional placement of SUA functions, whether all functions required
> by SUA of the NIF can be contained in the NIF between existing SCCP
> implementation or whether it requires dipping into the SCCP on the SG.
> Much discussion has also focussed on whether SCCP functionality must
> be spread to the ASP as well.  Additional discussion has talked about
> whether modificiations are required at the SCCP/SCCP-User interface
> at the ASP.
> 
> Consider this thread an inspection.  I believe that all issues which
> have developed from this thread have already been logged with issue
> numbers.

Good to hear.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Sep 2001 01:23:39 -0500

John,

The REG REQ proposal was a bit more than a paragraph in section 4.
What makes you think a paragraph in section 4 will do?

--brian

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

---

---

From: [email-masked]
Date: Mon, 3 Sep 2001 09:30:20 +0300

Hi Brian,

Your issue was about:

>> If this functionality waits for extension drafts, then
>> there is still the issue as to how decoupled connection-
>> oriented behavior is going to be supported in SUA.

So, my proposal is that we have a paragraph / section in 
Chapter 4 of SUA how this could work:

> As a quick solution, I propose that we add Routing Context
> as an optional parameter to the REG REQ message.  When included
> in the REG REQ message the SG should interpret this to mean
> that the Routing Key is to be added to the existing Routing
> Context.
> 
> To remove Routing Key components from an existing AS, the
> Routing Key parameters could be added as an optional component
> of the DEREG REQ message.  When an RK is included in the
> DEREG REQ message, the SG should interpret this to mean that
> the Routing Key is to be removed from the existing Routing
> Context.
> 
> The SG SHOULD apply the addition or removal of a Routing Key
> component to Routing Keys received on one SGP to all SGP
> consistent with the requirement that Routing Contexts must
> be coordinated across SGP in an SG.
> 
> In addition, for SUA decoupled operation, SLR (and a few
> other parameters of CORE or COAK) could be added to the SUA
> REG REQ as an optional parameter of the Routing Key.  This
> would permit an ASP to register with an SG the fact that it
> has a connection for a given SLR/Dest within an existing
> Routing Context.  This would permit seamless decoupled
> connection-oriented operation in SUA by permitting multiple
> SG to associate an ASP SLR/Dest value with a routing
> context for routing CODT messages.  An ASP operating across
> two SGP could register an SLR/Dest/... in the appropriate
> routing context with all SGs which do not receive the CORE
> or COAK message, so the SG can populate the attributes of
> the connection.

Now, as I mentioned before.  Negotiation was discussed 
in M3UA before & was seen as not needed.  You mention
that it is needed for Decoupled case, and (correct me if I 
am wrong) you are the (only) proponent of decoupled 
operation

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Sep 2001 01:53:24 -0500

John,

The SUA draft itself is a proponent of decoupled operation.
It states that:

   "This Internet Draft defines a protocol for the transport
    of any SS7 SCCP-User signalling (e.g., TCAP, RANAP, etc.)
    over IP using the Stream Control Transport Protocol.  The
    protocol should be modular and symmetric, to allow it to
    work in diverse architectures, such as Signalling Gateway
    to IP Signalling Endpoint architecture.  Protocol elements
    are added to allow seamless operation between peers in the
    SS7 and IP domains."

Decoupled operation is provided in SS7 SCCP.  It is not something
I invented.  Without it there cannot be seamless operation as
has been demonstrated for a good number of months.

As SUA cannot meet its own objectives, I suggest that either
the objectives be changed, or SUA adjusted to meet the objective
of seamless operation with the SS7 network.

The REG REQ was one proposal.

What do you propose to say in Chapter 4 which will address
this issue?

--brian

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

---

---

From: [email-masked]
Date: Mon, 3 Sep 2001 12:32:01 +0530

Hi ,

As this case is related to SUA relay functionality ( which current draft
supports but is SUA last call open issue,  IPSP IPSP case),  I think it will be
best to resume discussion on this after IPSP - IPSP issue is resolved.

John , Do you think support for SEP- SG- ASP1 - ASP2  case can be considered
along with IPSP - IPSP issue, as this relates to SUA as relay node
functionality.

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 09/02/2001 01:32:44 AM

Sandeep,

--brian

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

---

---

---

From: [email-masked]
Date: Mon, 3 Sep 2001 10:03:32 +0300

Hi Sandeep,

> As this case is related to SUA relay functionality ( which 
> current draft supports but is SUA last call open issue,  IPSP 
> IPSP case), I think it will be best to resume discussion on 
> this after IPSP - IPSP issue is resolved.

Agreed.

> John , Do you think support for SEP- SG- ASP1 - ASP2  case 
> can be considered along with IPSP - IPSP issue, as this relates 
> to SUA as relay node functionality.

Yes, there are several people who have requested this functionality.
My goal is to add support so that is an implementation / network
admistration decision if this functionality is supported.

John

---

---

From: [email-masked]
Date: Mon, 3 Sep 2001 10:12:34 +0300

Brian,

> has been demonstrated for a good number of months.

I do not see how SUA prohibits seamless operation.  
 
> What do you propose to say in Chapter 4 which will address

First things first.  I will close out some other issues before
I seriously start working on this issue.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Sep 2001 02:39:50 -0500

John,

John Loughney wrote:                              (Mon, 03 Sep 2001 10:12:34)
> I do not see how SUA prohibits seamless operation.  

SUA cannot operate with SG's as STPs.  (STPs are not constrained
in SS7 to do final GTT, nor to do coupling).  See the thread
"SUA5: SG Relay Problems" for a detailed discussion.  Also see
the discussion earlier on this thread.

Gery's proposal at the end of June was to place SS7 address info
(at least PC) in all SUA-CO messages (CODT etc.).  (See note of
Fri, 29 Jun 2001 12:19.24 +0200 on thread "SUA5: SG Relay
Problems.") Although this was agreed to at v5, the change was never
made and support is still missing for STP operation of the SG.

The issue remains.  Either the ASP is given a mechanism to register
the connection with the alternate SG, or Destination Address
(also sequence control) will need to be added to all CODT messages
as agreed back in June.

Lyndon assured us that these outstanding issues which were not
addressed in SUAv7 would be addressed in last call.  The issue
was entered for last call because SUAv7 did not address them
even though they were raised an solutions dicussed at SUAv5.

Please address them now.

--brian

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

---

---

From: [email-masked]
Date: Mon, 3 Sep 2001 10:49:56 +0300

Brian,

> even though they were raised an solutions dicussed at SUAv5.

As in this very second?  Give me some time to work through the issues
before you make demands, please.  I would like to get through all of 
the remaining issues this week, but it would require co-operation with
the other authors & list members.

John

---

---

From: [email-masked]
Date: Mon, 3 Sep 2001 11:43:14 +0300

Hi Brian,

> Of course not this second, but please in SUAv8, and as part of
> the last call process as was assured by Lyndon, rather than swept
> under the carpet again.

Of course.  It was not swept under the rug on purpose ... it was an
oversight.

John

---

---

From: [email-masked]
Date: Mon, 3 Sep 2001 13:01:36 +0300

Hi all,
 
Please find the attached status of SUA.
 
The open issues are:

2<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office"
/>

Routing Context & Network Appearance

[email-masked] <mailto:[email-masked]> 

In Progress

No Action Needed?

11

Gracefull shutdown of SGP

[email-masked] <mailto:[email-masked]> 

In Progress

Working on text.

12

Section 4.1.3 text

[email-masked] <mailto:[email-masked]> 

In Progress

Need to see if addition of SMI is needed.

14

Changes and additions required for decoupled operation.

[email-masked] <mailto:[email-masked]> 

In progress

Discussion ongoing.

15

Segmentation/Reassembly/Sequencing

[email-masked] <mailto:[email-masked]> 

In progress

Discussion ongoing.

17

IPSP cases

[email-masked] <mailto:[email-masked]> 

Open

Discussion ongoing.

19

CODT Message

[email-masked] <mailto:[email-masked]> 

In Progress

Discussion ongoing.

24

Routing Context Definition

[email-masked] <mailto:[email-masked]> 

In progress

No action needed.

26

N-COORD primitive support

[email-masked] <mailto:[email-masked]> 

Open

Waiting for text

Issues 2 and 24 do not require any SUA action, in my opinion.
Issue 11 is under "construction" ...
Issues 12, 15, 17, 19 have proposed solutions, waiting to see if they are
sufficient.
Issue 14 still needs a proposal.
Issue 26 is waiting text from the person who submitted the issue.
 
The tally below is:
 
SUA Status as of August 21th, 2001.

Issue No.

Title

Submitter

Status 

Comment

1

M2UAv0, M3UAv8, SUAv7: Traffic Mode Type

 <mailto:[email-masked]> [email-masked]

Closed

Needs to be co-ordinated with other UAs

2

Routing Context & Network Appearance

[email-masked] <mailto:[email-masked]> 

In Progress

No Action Needed?

3

SCCP Message Priority

 <mailto:[email-masked]> [email-masked]

Closed

Added

4

ASP Capablities

 <mailto:[email-masked]> [email-masked]

Closed

ASP Capabilities removed.

5

SUAv7, M3UAv8: Heartbeat Procedures

 <mailto:[email-masked]> [email-masked]

Closed

Editorial

6

Flags Parameter

 <mailto:[email-masked]> [email-masked]

closed

Related to issue 3

7

COREF missing Flags parm

 <mailto:[email-masked]> [email-masked]

closed

Related to issue 6

8

Dynamic Registration

 <mailto:[email-masked]> [email-masked]

Closed

Text added

9

M3UAv8, SUAv7: SGP sending ASP Down/Ack

 <mailto:[email-masked]> [email-masked]

Closed

Under revision.

10

Missing Status Information

 <mailto:[email-masked]> [email-masked]

Closed

Added

11

Gracefull shutdown of SGP

[email-masked] <mailto:[email-masked]> 

In Progress

Working on text.

12

Changes and additions required for decoupled operation.

[email-masked] <mailto:[email-masked]> 

In Progress

Needs to be co-ordinated with other UAs

13

M2UAv9, M3UAv8, SUAv7: Common Parameters (again)

 <mailto:[email-masked]> [email-masked]

Closed

Done

14

SG Relay Problems

[email-masked] <mailto:[email-masked]> 

In progress

Discussion ongoing.

15

Segmentation/Reassembly/Sequencing

[email-masked] <mailto:[email-masked]> 

In progress

Discussion ongoing.

16

AMF at ASP

 <mailto:[email-masked]> [email-masked]

Closed

17

IPSP cases

[email-masked] <mailto:[email-masked]> 

Open

Discussion ongoing.

18

Interworking Between SUA and SCCP/M3UA

 <mailto:[email-masked]> [email-masked]

Closed

To be discussed in the AS

19

CODT Message

[email-masked] <mailto:[email-masked]> 

In Progress

Discussion ongoing.

20

Alignment of SUA, M2UA, M3UA and IUA common parameters

[email-masked]

Closed

Suggested changes, included them to SUAv8

21

Broadcast Traffic Mode Type

[email-masked]

Closed

Brian submitted text

22

Flow Control and Congestion Management

 <mailto:[email-masked]> [email-masked]

Closed

Discussion ongoing.

23

Expedited data transfer Procedure

 <mailto:[email-masked]> [email-masked]

Closed

Add support

24

Routing Context Definition

[email-masked] <mailto:[email-masked]> 

In progress

No action needed.

25

section 1.3.1 comments

 <mailto:[email-masked]> [email-masked]

Closed

Editorial comments

26

N-COORD primitive support

[email-masked] <mailto:[email-masked]> 

Open

Waiting for text

27

Hostname as a routing parameter

 <mailto:[email-masked]> [email-masked]

Closed

Text clarification needed

 

---