Subject: WG Last Call on M3UA

From: Lyndon Ong <[email-masked]>
Date: Tue, 06 Mar 2001 08:50:43 -0800

Folks,

Now that the updated version of M3UA is out, it's time to move it to 
Working Group Last Call.  Two weeks would put us into the IETF meeting in 
Minneapolis, so my suggestion is that we run Last Call an extra week, that 
is, starting today but ending on close of business Tuesday, March 27th.  At 
the close of Last Call, Greg can then incorporate comments into another 
version and we can see if that looks ready to move forward.

Cheers,

L. Ong

---

From: [email-masked]
Date: Tue, 6 Mar 2001 21:58:00 +0200

Hi Lyndon,

> Working Group Last Call.  Two weeks would put us into the 
> IETF meeting in Minneapolis, so my suggestion is that we run Last 
> Call an extra week, that is, starting today but ending on close of 
> business Tuesday, March 27th.  At the close of Last Call, Greg can 
> then incorporate comments into another version and we can see if 
> that looks ready to move forward.

Could we get a short statement about the differences between version
5 and version 6?

Thanks,
John

---

From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
Date: Wed, 28 Mar 2001 17:17:57 -0500

-----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Tuesday, March 06, 2001 2:58 PM
To:	[email-masked]; [email-masked]
Subject:	RE: WG Last Call on M3UA

Hi Lyndon,

Thanks,
John

[Greg] For those of you on the list who did not attend the Minneapolis
Meeting, here is a list of the major changes from M3UA Issue 5 to Issue 6.
If you want a more detailed view, please send me an e-mail and I can e-mail
you back a Word document with ALL the changes highlighted - I don't want to
send an attachment to the list.

1) Added optional SSNM Destination Restricted protocol to cover the
redundant SG case.  Where an ASP routes traffic out to the PSTN through more
than one SG, an SG can now tell the ASP that it can still route to an SS7
destination, but its normal route is down.  This is an M3UA analogue to the
Transfer Restricted protocol in some national SS7 networks.

2) Added optional Registration/Deregistration messages and procedures.  An
ASP may now explicitly register with an SG to be included within an
Application Server configuration, before going active.  The SG may
create/delete a new Application Server (Routing Key) entry based on a
registration request.  To support this a new Routing Key parameter is added
and assignment/use of the Routing Context parameter is better defined (RC
value is assigned by the SG and used for messaging after Registration).
Message flows are added to Section 5 to illustrate.

3) Clarified Message Length calculation (includes all parameter padding
bytes).

4) Corrected error in example DATA payload representation - ITU and ANSI
(SS7 SIO/Label).  Note: a minor mistake in Issue 6 has been fixed up for
Issue 7.

5) Text aligned to IUA RFC 3057 where applicable/possible.

6) Added new Protocol Data 2 parameter to identify SS7 DATA message payloads
that include the Length Indicator octet.  This was added to support the
Japan TTC SS7 protocol use of LI spare bits to indicate the national Message
Priority.

7) Removed the Traffic Mode Type parameter from ASP Inactive Messages as it
served no useful purpose.

8) Added missing procedures to cover all the cases for issuing the Error
Message.

9) Tied up the procedures to show when the various SCTP "primitives" are
invoked.

10) Various other small clarifications / improvements.

Hope this helps,

     Greg

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