Updated SUA sent out.

Hi all,

The IESG asked me to make a few small editorial changes to SUA so it can
have a final review (hopefully) on April 18th.

I made a few editorial corrections at the same time, the full changes are:

Abstract
	- expanded acronyms

Section 1.5.6 
	- "The SCCP layer at an ASP or IPSP " was replaced by 
        "The SUA layer at an ASP or IPSP "

Section 1.6.3 
	- The description of M-RK_DEREG Confirm: "ASP reports that it has 
	  received DEREG REQ..." was corrected to "ASP reports that it has 
	  received DEREG RESP"

Section 3.4.6 DRST
	- fixed references to SGP to SG.
	- clarified what SCCP primitive is considered when SSN is 
	  not included.

Section 3.5.1 
	- Tag of Info String was fixed.

Section 3.8.2 Registration Response (REG RSP)
	- The fixed first paragraph, had incomplete sentence.
	- Note 1, added statement similar to M3UA:

RE: Updated SUA sent out.

Thanks for the update on SUA.  

Do we have status on the IESG review of M3UA?  Time frame for an RFC
approval?

Thanks

Kevin.....

> -----Original Message-----
> From: john.loughney <at> nokia.com [mailto:john.loughney <at> nokia.com]
> Sent: Thursday, April 04, 2002 7:09 AM
> To: sigtran <at> ietf.org
> Cc: sob <at> harvard.edu
> Subject: [Sigtran] Updated SUA sent out.
> 
> 
> Hi all,
> 
> The IESG asked me to make a few small editorial changes to 
> SUA so it can
> have a final review (hopefully) on April 18th.
> 
> I made a few editorial corrections at the same time, the full 
> changes are:
> 
> Abstract
> 	- expanded acronyms
> 
> Section 1.5.6 

RE: Updated SUA sent out.

Hi Kevin,

M3UA was approved by IESG and is on the RFC editor's
queue.  I don't have a time frame for RFC numbering,
but the process generally takes a couple of months
(keep in mind IESG approved this some time ago).

Lyndon

-----Original Message-----
From: Kevin McCandless [mailto:KMcCandless <at> Illuminet.com]
Sent: Thursday, April 04, 2002 7:42 AM
To: sigtran <at> ietf.org
Cc: sob <at> harvard.edu
Subject: RE: [Sigtran] Updated SUA sent out.

Thanks for the update on SUA.  

Do we have status on the IESG review of M3UA?  Time frame for an RFC
approval?

Thanks

Kevin.....

> -----Original Message-----
> From: john.loughney <at> nokia.com [mailto:john.loughney <at> nokia.com]
> Sent: Thursday, April 04, 2002 7:09 AM
> To: sigtran <at> ietf.org
> Cc: sob <at> harvard.edu

Re: m3ua-implementors-guidev00, OPC list + missing issues

Tolga,

Pls see below.

Ken

At 12:35 PM 3/31/2002 -0800, Tolga Asveren wrote:
>Javier and Ken,
>
>After discovering that there is a link now for m3ua
>implementors guide on SIGTRAN page, here are some
>comments:
>
>1- I couldn't understand, why it is not clear to have
>an OPC list in the Registeration Reuqest, and what
>does this has to do with alias point codes. Previous
>text was pretty clear to me.
>
>2- AS state machine change for n+k case is not
>addresses, on intention or just forgotten?

Sorry, must have missed this one.  Was a 
consensus reached?  If so, could you please
summarize the issue and conclusion so that
it can be placed into the imp guide.

Otherwise, I'll add it to the list of open issues
(which I hope to post soon).

RE: m3ua-implementors-guidev00, OPC list + missing issues

Ken,

Please see below.

  Tolga

> -----Original Message-----
> From: sigtran-admin <at> ietf.org [mailto:sigtran-admin <at> ietf.org]On Behalf Of
> Ken Morneault
> Sent: Thursday, April 04, 2002 5:07 PM
> To: Tolga Asveren; sigtran <at> ietf.org
> Subject: Re: [Sigtran] m3ua-implementors-guidev00, OPC list + missing
> issues
>
>
>
>
> Tolga,
>
> Pls see below.
>
> Ken
>
> At 12:35 PM 3/31/2002 -0800, Tolga Asveren wrote:
> >Javier and Ken,
> >
> >After discovering that there is a link now for m3ua
> >implementors guide on SIGTRAN page, here are some
> >comments:
> >

Resetting conegestion level

Re: Resetting conegestion level

Sripriya,

When not in response to DAUD, SCON and DAVA are
sent per Section 4.5.1.  When SCON and DAVA are
sent, therefore depends on the protocol variant
at the SG, an precisely correspond to the
MTP-RESUME and MTP-STATUS primitives expected
at the ASP.

--brian

Sripriya Narayanan wrote:                     (Fri, 05 Apr 2002 15:12:04)
> 
>    Hello list,
>    
>        When the M3ua at MGC gets SCON followed by a DAVA, it means the
>    point code is congested, although available.
>    
>    Incase the congestion level has reduced, does the SG send DAVA or SCON
>    with level "0" or both?
>    
>        Incase SG sends DAVA, how is the ASP supposed to identify if it is
>    a DAVA resetting the congestion level or it is a DAVA immediately
>    following SCON conveying that the point code is congested although
>    available?
>    
>    
>    
>    Regards
>    
>    Sripriya

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

I-D ACTION:draft-ietf-sigtran-sua-13.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Signaling Transport Working Group of the IETF.

	Title		: Signalling Connection Control Part User Adaptation 
                          Layer (SUA)
	Author(s)	: J. Loughney, G. Sidebottom et al.
	Filename	: draft-ietf-sigtran-sua-13.txt
	Pages		: 117
	Date		: 04-Apr-02
	
This Internet Draft defines a protocol for the transport of any         Signalling Connection Control Part-User
signalling (e.g., Transaction Capabilities Protocol, Radio Acccess Network Application 
Protocol, 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 a Signalling Gateway to IP Signalling 
Endpoint architecture as well as a peer-to-peer IP Signalling 
Endpoint architecture.  Protocol elements are added to allow 
operation between peers in the Signaling System-7 and IP domains.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sua-13.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sigtran-sua-13.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-sua-13.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: Resetting conegestion level

Hi
   I have a query regarding Section 4.5.1 It says "DUNA, DAVA, SCON, and DRST
messages may be sent sequentially and processed at the receiver in the order
sent.
 Sequencing is not required for the DUPU or DAUD messages, which MAY be sent
unsequenced"

  About what kind of sequencing are we talking here? Does it give the specific
order in which these messages should go (although it does not seem so and
probably should not be so since Sec 4.5.3 says "the SGP MUST additionally r
espond with an SCON message before the DAVA or DRST message.") or response for
DAUD and sending of DAVA/DUNA/SCON etc when MTP-RESUME/PAUSE/STATUS are received
at NIF are two different cases to be considered.

 Kindly let me know.

Thanks
Sarika

"Brian F. G. Bidulock" <bidulock <at> openss7.org> on 04/05/2002 03:43:59 PM

Please respond to bidulock <at> openss7.org

To:   Sripriya Narayanan <sripriyan <at> netlab.hcltech.com>
cc:   sigtran <at> ietf.org (bcc: Sarika Gupta/HSS)

Subject:  Re: [Sigtran] Resetting conegestion level

Sripriya,

When not in response to DAUD, SCON and DAVA are
sent per Section 4.5.1.  When SCON and DAVA are
sent, therefore depends on the protocol variant
at the SG, an precisely correspond to the
MTP-RESUME and MTP-STATUS primitives expected
at the ASP.

--brian

Sripriya Narayanan wrote:                     (Fri, 05 Apr 2002 15:12:04)
>
>    Hello list,
>
>        When the M3ua at MGC gets SCON followed by a DAVA, it means the
>    point code is congested, although available.
>
>    Incase the congestion level has reduced, does the SG send DAVA or SCON
>    with level "0" or both?
>
>        Incase SG sends DAVA, how is the ASP supposed to identify if it is
>    a DAVA resetting the congestion level or it is a DAVA immediately
>    following SCON conveying that the point code is congested although
>    available?
>
>
>
>    Regards
>
>    Sripriya

--
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

M3UA outstanding issues

All:

The following are open issues that have not been fully discussed
on the list.  Please provide feedback so that we can bring them
to conclusion.

Also, if you favorite open issue has been forgotten, please resend
it to the list.

Regards,

Ken

------------------------------------open issues---------------------------------------

1)  use of broadcast mode not fully specified (use of correlation id 
not fully specified either)

This concern was addressed by Brian on the list.  If there is still 
discontent, could some specific complaints be listed or additional 
text proposed.

2)  REG msg only has Service Indicator.  There is interest in also 
allowing Network Indicator (i.e. change Service Indicator field to SIO or
add NI parameter to message).

Comment on the list that NA is sufficient.  Is there a need for NI in 
REG message?

3)  There was a long thread about the use of ASP ID.  Do some folks
still feel additional explanatory text is required or can we close this issue?

4) Handling traffic flow (i.e. destination) based Changeback (reference
ITU Q.704  Clause 6.2.1 b (i))

5) For SSNM with multiple Affected Point Code fields and with multiple 
RC fields, it should be described, how to correlate RC values to the Affected 
Point Codes.

6)  Discrepancy between implementations regarding uniqueness
of Routing Context

Scenario  ASP sends REG Routing Key request to each SGP 
per M3UA.

   Issue 1:  Can each SGP respond with different Routing Context
                 to REG request for the same Routing Key.

   Issue 2:  Why does ASP need to send REG RK to each
                 SGP when AS/Routing Key is across SG?