Subject: July Sigtran mail message archive, part 1

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 3 Aug 2001 09:17:10 -0700

Reply-To: [email-masked]
From: Mark Kobine <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA - Relationship between SG/AS/ASP/MGC
Date: Mon, 2 Jul 2001 10:58:17 +0100
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-SMTP-HELO: blueyonder.co.uk
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [195.188.53.124]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi Ken,

I recently asked how many AS's per SG and ASP's per MGC there can be.

Your answer to both questions was that it was possible to have more than 1
AS per SG or ASP per MGC but that this was unlikely.

We are now at a critical design stage and trying to decide whether or not to
support more than 1 AS/ASP per SG/MGC.

Could you quantify your earlier replies and give examples of scenarios with
more than 1 AS/ASP per SG/MGC please?

Many Thanks,
Mark

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Mon, 02 Jul 2001 11:56:59 +0100
From: Joyce Archibald <[email-masked]>
Organization: Agilent Technologies UK Ltd
X-Mailer: Mozilla 4.76 [en] (X11; U; HP-UX B.10.20 9000/778)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
X-SMTP-HELO: msgbas1.cos.agilent.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [192.6.9.33]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian and Greg,

Brian F. G. Bidulock wrote:
> What is the "Network Id"?  How does the SG derive this?  If you 
> are talking about the NI bits in an MSU, they may be different 
> for different links for the same point code in the same network. 

This must be fairly unusual, we monitor a lot of networks and I don't recall
meeting this.

> Also, in some circumstances, NI bits are used to extend the point 
> code by two bits.

Consider 3 scenarios:-

1. 1 SS7 network, NI bits always the same.

        ---------              ----             ----
       | SS7 nwk |------------| SG |-----------| AS |
        ---------              ----             ----

   No problem, all pointcodes are unique.

2. National and International SS7 networks, NI bits set.

       ---------------
      | Internat. SS7 |
      |  NI bits = 00 |---
       ---------------    |
                         ---        ----             ----
                        |STP|------| SG |-----------| AS |
                         ---        ----             ----
       ---------------    |
      |  Nat. SS7     |---
      |  NI bits = 10 |
       ---------------

   The same pointcode could exist in both National and International
   networks, so the SG needs to indicate which network a message is
   from. In this case it could use the NI bits.

3. 2 National networks, NI bits may be the same.

       ---------------
      |  Nat. SS7 (1) |
      |  NI bits = 10 |---
       ---------------    |      ----
                           -----|    |            ----
                                | SG |-----------| AS |
                           -----|    |            ----
       ---------------    |      ----
      |  Nat. SS7 (2) |---
      |  NI bits = 10 |
       ---------------

   The same pointcode could exist in both SS7 networks, so the SG
   needs to indicate which network a message is from. In this case
   it would need to map the linkset id and NI bits to a network
   identifier.

Not being a switch manufacturer I am not in a position to define how the SG
will work but IMHO when sending messages to the SS7 networks, the SG will
need to insert the correct NI bits (and message priority?) into the routing
label, and choose the appropriate linkset in case 3.

Also, how do you identify two endpoints with the same pointcode value in
Registration Request messages, if the Network Appearance parameter is
removed.

Regards,
Joyce

-- 
================================================================== Joyce
Archibald, TSD R&D,    | Phone:    +44 (0) 131 3317521 Agilent Technologies
UK Ltd  | Telnet:   313 2521 South Queensferry,           | Mailstop:
SQFRD3A EH30 9TG, Scotland.          | E-mail: [email-masked]
==================================================================

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA: Routing Key parameter
Date: Mon, 2 Jul 2001 15:40:06 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: albatross-ext.wise.edt.ericsson.se [194.237.142.116]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg,

I'd need your help to understand the RK parameter format defined in draft
v.6.

I do not know how the RK is built up from the included sub-parameters:
DPC(unique), NA(unique), SI(list), SSN(list), OPC(list) and CIC(list).

Let's say the RK sub-parameters are the following:

DPC1
NA1,
SI1,SI2
SSN1,SSN2,SSN3
OPC1
CIC1-30,CIC10-50

Then, is the RK made up with all the possible sub-parameters combinations??
I.e. could the following combinations be the RK defined?:
	DPC1,NA1,SI1,SSN1,OPC1,CIC1-30
	DPC1,NA1,SI1,SSN2,OPC1,CIC1-30
	DPC1,NA1,SI1,SSN3,OPC1,CIC1-30
	DPC1,NA1,SI2,SSN1,OPC1,CIC1-30
	DPC1,NA1,SI2,SSN2,OPC1,CIC1-30
	DPC1,NA1,SI2,SSN3,OPC1,CIC1-30
	DPC1,NA1,SI1,SSN1,OPC1,CIC10-50
	DPC1,NA1,SI1,SSN2,OPC1,CIC10-50
	DPC1,NA1,SI1,SSN3,OPC1,CIC10-50
	DPC1,NA1,SI2,SSN1,OPC1,CIC10-50
	DPC1,NA1,SI2,SSN2,OPC1,CIC10-50
	DPC1,NA1,SI2,SSN3,OPC1,CIC10-50

If so, it is not that straight forward because we should take into account
that some sub-parameters could be optional, then we may like to define SSN
(for example), for a set of combinations but not for the others. Moreover,
some sub-parameters are only valid for a particular SI, i.e. SSN is only a
valid value when SI=3 (as it is written in the draft), and CICrange is only
valid for SI=ISUP/TUP but not for SCCP.

Wouldn't we need to define the RK in a different way? Combination by
combination?

Apart from that, the CIC range sub-parameter is defined as an OPC + CICmin +
CICmax. Why the OPC appears again within this sub-parameter?? Isn't it
already defined? As far as I understand it must be only CICmin + CICmax

Could you clarify it to me?
/MCruz

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA - DEREG Results
Date: Mon, 2 Jul 2001 15:44:32 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.237.142.116]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg,

I recall the mail below sent a long time ago.
I checked the e-mail list but I couldn't find an answer to it.
I have the same doubt as Ben had and his proposal sounds reasonable to me.

What's your opinion about that?

Cheers
/MCruz

-----Original Message-----
From: Benjamin J. Wilson,,, [mailto:[email-masked]] Sent: Tuesday,
April 03, 2001 10:16 PM
To: sigtran
Subject: DEREG Results

Greg/Norm,

Might I suggest a bit of cleanup to the DEREG RSP and REG RSP?

It seems a DEREG RSP contains 1 DEREG RESULTS parameter which itself
contains many DEREG RESULT (singular) parameters.  It's not clear from the
text b/c no tag is in the diagram, but there is a tag for it in the list of
parameter ids at the beginning.

Since REG REQ has many Routing Key parameters it seems the DEREG RESULTS
parameter can be eliminated and the DEREG RSP could just contain many DEREG
RESULT parameters.

Hopefully this makes sense.

Ben

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Kevin McCandless <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Packing of DATA Payloads
Date: Mon, 2 Jul 2001 07:58:16 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: rainier.illuminet.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.116.20.100]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Joyce:

We have come across this scenario in a standard SS7 network, no IP,.  The
international network uses same point codes as the US network.  When the
international network enters a US POP, there is a switch that does point
code normalization/conversion to avoid the conflict.  Not sure if this helps
you but your situation is not unique.

Regards,

Kevin McCandless 
Senior Network Planner 
Illuminet 
913-814-6397 
[email-masked] 

-----Original Message-----
From: Joyce Archibald [mailto:[email-masked]] Sent: Monday,
July 02, 2001 5:57 AM
To: sigtran
Subject: Re: Packing of DATA Payloads

Hi Brian and Greg,

Brian F. G. Bidulock wrote:
> What is the "Network Id"?  How does the SG derive this?  If you 
> are talking about the NI bits in an MSU, they may be different 
> for different links for the same point code in the same network. 

This must be fairly unusual, we monitor a lot of networks and I don't recall
meeting this.

> Also, in some circumstances, NI bits are used to extend the point 
> code by two bits.

Consider 3 scenarios:-

1. 1 SS7 network, NI bits always the same.

        ---------              ----             ----
       | SS7 nwk |------------| SG |-----------| AS |
        ---------              ----             ----

   No problem, all pointcodes are unique.

2. National and International SS7 networks, NI bits set.

       ---------------
      | Internat. SS7 |
      |  NI bits = 00 |---
       ---------------    |
                         ---        ----             ----
                        |STP|------| SG |-----------| AS |
                         ---        ----             ----
       ---------------    |
      |  Nat. SS7     |---
      |  NI bits = 10 |
       ---------------

   The same pointcode could exist in both National and International
   networks, so the SG needs to indicate which network a message is
   from. In this case it could use the NI bits.

3. 2 National networks, NI bits may be the same.

       ---------------
      |  Nat. SS7 (1) |
      |  NI bits = 10 |---
       ---------------    |      ----
                           -----|    |            ----
                                | SG |-----------| AS |
                           -----|    |            ----
       ---------------    |      ----
      |  Nat. SS7 (2) |---
      |  NI bits = 10 |
       ---------------

   The same pointcode could exist in both SS7 networks, so the SG
   needs to indicate which network a message is from. In this case
   it would need to map the linkset id and NI bits to a network
   identifier.

Not being a switch manufacturer I am not in a position to define how the SG
will work but IMHO when sending messages to the SS7 networks, the SG will
need to insert the correct NI bits (and message priority?) into the routing
label, and choose the appropriate linkset in case 3.

Also, how do you identify two endpoints with the same pointcode value in
Registration Request messages, if the Network Appearance parameter is
removed.

Regards,
Joyce

-- 
================================================================== Joyce
Archibald, TSD R&D,    | Phone:    +44 (0) 131 3317521 Agilent Technologies
UK Ltd  | Telnet:   313 2521 South Queensferry,           | Mailstop:
SQFRD3A EH30 9TG, Scotland.          | E-mail: [email-masked]
==================================================================

---
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]
Date: Mon, 02 Jul 2001 17:43:10 +0200
From: Maria-Carmen Belinchon <[email-masked]>
Reply-To: [email-masked]
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
CC: [email-masked]
Subject: SCTP MIB
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: penguin-ext.wise.edt.ericsson.se [194.237.142.110]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi,

    The SCTP MIBv04 has been submitted to the IETF. Any comment will be very
appreciated.

regards,
MCarmen

Attachment Converted: "c:\program files\qualcomm\eudora
pro\attach\emecbv.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Deliver-To: <[email-masked]>
X-Recipient: <[email-masked]>
From: [email-masked]
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Multiple ASPAC ACKs ??
Date: Tue, 3 Jul 2001 08:34:08 +0530
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-Server: VPOP3 V1.3.0b - Registered to: CoSystems, Inc
X-SMTP-HELO: dfw-smtpout4.email.verio.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [129.250.36.44]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi All,
    Please excuse me if this question is already answered.

   Suppose an ASP sends ASPAC with multiple IUA identifiers.  When SG sends
a response, should it send
ASPAC ACK for all the IUA identifiers receive in ASPAC  OR can the SG send
multiple ASPAC ACKs containing
some IUA identifiers in each ASPAC ACK ??

	ASP				SG
	|	ASPAC (1-10)		|
	|--------------------------------------------->	|
	|	ASPAC ACK ( 1- 5)	|
	|<---------------------------------------------	|
	|	ASPAC ACK ( 6- 10)	|
	|<---------------------------------------------	|
	|				|

   Is the SG behaving properly in the above case ??

-thanks in advance,
Umesh.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: SG Relay Problems
Date: Tue, 3 Jul 2001 11:00:56 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

Just looking through my inbox & noticed that I didn't respond to this.

> > 2) Support for N-PCSTATE.  
> > 
> > I'm not so clear as to what is missing.
> > 
> Nothing earth-shattering, just an indication of routset
> (rather than subsystem) availability and congestion, and
> indication of routeset restriction via an SG.

For all DUNA, DAVA, SCON, etc mesages, we mark SSN as optional.
Shall I add text to state that when SSN is not present, we are to interpret
that it affects more than just the SSN?

Is this OK?

br,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA 06: AMF at ASP
Date: Tue, 3 Jul 2001 11:09:25 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x3.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x3.nokia.com [131.228.20.26]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> On approach without adding SGP management would be to insist that
> an ASP only routes messages to an SGP that it would receive from
> that SGP within the Routing Context/Routing Key under which it is
> currently active and receiving traffic.  The routing context itself,
> then, would be used by the ASP to select the SGP.

I'm having a little trouble parsing this sentance (I'm trying to address
this issue).  

Do you mean something like this:

An ASP SHOULD send responses only to that SGP which it recieved messages
from, within the routing context which it is currently active and receiving
traffic.  The routing context itself is effectively used by the ASP to
select the SGP.

thanks,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA6: SG Relay Problems
Date: Tue, 3 Jul 2001 11:30:28 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x4.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [131.228.20.27]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Gery & Brian,

> 1. Reassembly of XUDT at SG : I think everyone agrees on that 
> now. To deal
> with link/routeset failures, can everyone agree on following 
> procedure ?
> 
> "If a SG is operated in mated pair configuration, and it receives a
> non-first XUDT segment for which no reassembly process 
> exists, it should pass on this segment to it's mate; if the segment 
> was already received from the mated SG or if no mated SG is available, 
> the return on error procedures must be invoked."

Agreed.

> 2. Coupling of connection sections at SG : let's see if we can reach a
> compromise ...
> 
> The CR message can contain information (e.g. GT, SSN) based 
> on which an AS/ASP is selected. This information is no longer 
> present in subsequent CO messages. Therefor, in order to provide 
> seemless SS7 - IP interworking, coupling of connection sections 
> is required in the SG when :
> 
> - the SG acts as SEP : in this case SUA is used to provide 
> the interface between SCCP on the SG and the SCCP-user on the ASP.
> 
> - the SG acts as STP, and the AS/ASP cannot be derived from 
> the received SCCP-CO message, or the SEP cannot be derived from the 
> received SUA-CO message.
> 
> To avoid coupling, we need SS7 address info (at least a PC) 
> in all SUA-CO messages (CODT etc.) ! If we want coupling of 
> connection sections optional at the SG, we need to update the 
> SUA-CO messages in this respect. 

Question to Brian & Gery - how is this handled at STPs, especially at
network boundaries?

Brian, is the above solution acceptable to you?

> BTW : are we going to work with routing contexts instead of network
> appearance now in each SUA-CL and CO message ? If so, this 
> could be used for mapping to a SEP in case of "no coupling" at the SG. 
> To me this sounds like a good idea for 2 reasons :
> 
> - the network appearance parameter definition is still rather shaky
> - the routing context could well provide the same (and more) 
> functionality

So, are you suggesting colapseing network appearence into routing context?
 
> 4. Concerning DRST : let's see if I get it straight ... this 
> is to signal to concerned/neighbouring nodes that a SG/SUA-relay node 
> from a mated pair has lost connectivity to a SEP/SUA-end node and 
> routing should preferably continue over the other mate. The other 
> mate will receive a DUNA instead of a DRST, and when he loses connectivity

> to the same endpoint as well, both SGs will send DUNA to their neighbours.

This could be done, comments?
 
> Since SGs can consist of several SGPs (and would be modelled 
> as such in the ASP to guard SCTP connectivity), the SSNM messages 
> (DUNA, DAVA, SCON, DRST), when received from any of these SGPs, should 
> be regarded as valid for the entire SG.

agreed.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: SUA6: Open Issues
Date: Tue, 3 Jul 2001 11:40:21 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x3.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x3.nokia.com [131.228.20.26]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

I have these issues open for the current version of SUA.  I'd like to get
closure on these issues ASAP, then I think we could get ready for a last
call on SUA.

Open issues:

1) Align common parameter numbers with the other UAs.

2) Is DRST needed or not.

3) How to handle the coupling signaling gateways for SUA-connection 
   oriented messages.

4) Any issues related to the other UAs which may impact SUA
   (this I may need some help on, as I have not been following the
   other UAs so closely).

Anything else?

best regards,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Original-To: IETF-Announce:;;@cnri.reston.va.us@zrtps0jn
PP-Warning: Parse error in original version of preceding To line
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sigtran-sctp-mib-04.txt
Date: Tue, 03 Jul 2001 06:59:23 -0400
Sender: [email-masked]
X-SMTP-HELO: ietf.org
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [132.151.1.176]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
To: "sigtran" <[email-masked]>

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		: Stream Control Transmission Protocol Management 
                          Information Base using SMIv2
	Author(s)	: J. Pastor, M. Belinchon
	Filename	: draft-ietf-sigtran-sctp-mib-04.txt
	Pages		: 43
	Date		: 02-Jul-01
	
The Stream Control Transmission Protocol (SCTP) is a reliable transport
protocol operating on top of a connectionless packet network such as IP,
designed to transport PSTN signaling messages over the connectionless packet
network, but is capable of broader applications.
This memo defines the Management Information Base (MIB) module which
describes the minimum amount of objects needed to manage the implementation
of the SCTP.

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

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-sctp-mib-04.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-sctp-mib-04.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.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sigtran-sctp-mib-04.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-mib-04.txt> ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 03 Jul 2001 13:56:00 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: Multiple ASPAC ACKs ??
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Umesh,

Though it would be preferable for the SG to send a single ASPAC Ack, the ASP
should be able to handle this scenario.

Regards,

Ken

At 08:34 AM 7/3/01 +0530, [email-masked] wrote:
>Hi All,
>     Please excuse me if this question is already answered.
>
>    Suppose an ASP sends ASPAC with multiple IUA identifiers.  When SG
sends
>a response, should it send
>ASPAC ACK for all the IUA identifiers receive in ASPAC  OR can the SG send
>multiple ASPAC ACKs containing
>some IUA identifiers in each ASPAC ACK ??
>
>         ASP                             SG
>         |       ASPAC (1-10)            |
>         |---------------------------------------------> |
>         |       ASPAC ACK ( 1- 5)       |
>         |<--------------------------------------------- |
>         |       ASPAC ACK ( 6- 10)      |
>         |<--------------------------------------------- |
>         |                               |
>
>    Is the SG behaving properly in the above case ??
>
>-thanks in advance,
>Umesh.
>
>
>
>---
>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: "Tomar, Nitin" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA06: Routing Key Management procedure
Date: Tue, 3 Jul 2001 18:14:30 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hypnos.cps.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: hypnos.cps.intel.com [192.198.165.17]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greg, 

   Re-sending this mail and awaiting answer for these.

 regards
- Nitin

-----Original Message-----
From: Tomar, Nitin [mailto:[email-masked]] Sent: Tuesday, June 26,
2001 6:48 PM
To: sigtran
Subject: M3UA06: Routing Key Management procedure

Greg,
  
I have few queries/comments on Routing key procedure.

- Nitin.

1. Is RKM procedure valid for IPSP-IPSP communication as well? In either
case I think the draft can specify it clearly in section 3.5.5 and related
sections. If RKM is allowed for IPSP-IPSP scenario, can client and server
both initiate REG-REQ and DEREG-REQ messages, I do not find any reason they
should not do so.

2. De-registration request for RK not registered through REG REQ message is
valid or not? lets say RK was statically configured at an SG which supports
both static and dynamic configuration of RKs. 

3. In section 4.3.4.1 and 4.3.4.2, The draft does not specifies any timers
associated with the REG REQ and DEREG REQ messages, I think there is a need
for timers for RKM messages, as an ASP can not wait indefinitely for the REG
RSP if SG decides to respond to REG REQ containing multiple RKs with
multiple REG RSP messages'

The timer can be similar to what we have for ASPM messages, something like
this:
   
'When ASP sends an REG REQ it starts timer T(RK-ack). If the ASP does not
receive a response to REG REQ within T(RK-ack), the ASP may restart
T(RK-ack) and resend REG REQ messages until it receives an REG REQ message.
T(RK-ack) is provisionable, with a default of n seconds. Alternatively,
retransmission of REG RSP messages may be put under control of Layer
Management'

4. Can a ASP is authorized to send REG-REG only and not authorized to send
DEREG-REQ, in either case the draft can specify it clearly in section
4.3.4.2.

5. Figure for "Routing Key" parameter description can be modified to
indicate the Network Appearance (optional) as first parameter. [To comply
with section 3.3.1 stating 'Where the optional Network Appearance parameter
is present, it must be the first parameter in the message']

6. The 'Registration Status' parameter values in REG RSP message need one
more type of error value : 'Multiple SI not supported' as none of the
existing error value cover this [In case SG optionally support only one SI
in a Routing key as per section 1.4.2.2].

7. Section 3.5.5, 3.5.6, 3.5.7 and 3.5.8 numbering is duplicated.

----------------------------------------------------------------------------
-------

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 4 Jul 2001 01:59:18 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: SUA 06: AMF at ASP
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: scaup.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: scaup.mail.pas.earthlink.net [207.217.121.49]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

john.loughney,

[email-masked] wrote:           (Tue, 03 Jul 2001 11:09:25)
> Hi Brian,
> 
> > On approach without adding SGP management would be to insist that
> > an ASP only routes messages to an SGP that it would receive from
> > that SGP within the Routing Context/Routing Key under which it is
> > currently active and receiving traffic.  The routing context itself,
> > then, would be used by the ASP to select the SGP.
> 
> I'm having a little trouble parsing this sentance (I'm trying to 
> address this issue).  
> 
> Do you mean something like this:
> 
> An ASP SHOULD send responses only to that SGP which it recieved
> messages from, within the routing context which it is currently
> active and receiving traffic.  The routing context itself is 
> effectively used by the ASP to select the SGP.

No, that's not quite what I meant.  What I mean is that if the SGP is
sending messages to an ASP under a Routing Key, that the ASP only send
messages to the SGP associated with the same Routing Key.  For example, if
the Routing Key is PC=A, SSN=5, TID=122234, that the ASP send messages
associated with PC=A, SSN=5, TID=112234 only to SGPs for which it has
registered with that Routing Key.  Is that clearer?
(Probably not ;)

> 
> thanks,
> John
> 
> 
> ---
> You are currently subscribed to sigtran as: [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]
Date: Wed, 4 Jul 2001 02:01:32 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: SUA5: SG Relay Problems
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: avocet.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: avocet.mail.pas.earthlink.net [207.217.121.50]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

[email-masked] wrote:           (Tue, 03 Jul 2001 11:00:56)
> Hi Brian,
> 
> Just looking through my inbox & noticed that I didn't
> respond to this.
> 
> > > 2) Support for N-PCSTATE.  
> > > 
> > > I'm not so clear as to what is missing.
> > > 
> > Nothing earth-shattering, just an indication of routset
> > (rather than subsystem) availability and congestion, and
> > indication of routeset restriction via an SG.
> 
> For all DUNA, DAVA, SCON, etc mesages, we mark SSN as optional.
> Shall I add text to state that when SSN is not present, we 
> are to interpret that it affects more than just the SSN?
> 
> Is this OK?

I interpreted the section to mean that if the SSN is not provided that it is
implied by the Routing Context.  Switching that to "more than one SSN" is
somewhat different behavior.  But, if you want to preclude implied SSN by
routing context, I have no problem with that.

> 
> br,
> John
> 
> 
> ---
> You are currently subscribed to sigtran as: [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]
Date: Wed, 4 Jul 2001 02:14:00 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: SUA6: SG Relay Problems
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: avocet.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: avocet.mail.pas.earthlink.net [207.217.121.50]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

[email-masked] wrote:           (Tue, 03 Jul 2001 11:30:28)
> Hi Gery & Brian,
> 
> > 1. Reassembly of XUDT at SG : I think everyone agrees on that 
> > now. To deal
> > with link/routeset failures, can everyone agree on following 
> > procedure ?
> > 
> > "If a SG is operated in mated pair configuration, and it receives a
> > non-first XUDT segment for which no reassembly process 
> > exists, it should pass on this segment to it's mate; if the segment 
> > was already received from the mated SG or if no mated SG is available, 
> > the return on error procedures must be invoked."
> 
> Agreed.

Although this is reasonable, it appears that it is handled by the exiting
specification which require Class 1 for segmented messages.  The treatment
of out of order segments in Class 1 is handled by the SCCP procedures and
should not IMO be restated in the SUA spec.

I agree that there is not a problem here.

> 
> > 2. Coupling of connection sections at SG : let's see if we can reach a
> > compromise ...
> > 
> > The CR message can contain information (e.g. GT, SSN) based 
> > on which an AS/ASP is selected. This information is no longer 
> > present in subsequent CO messages. Therefor, in order to provide 
> > seemless SS7 - IP interworking, coupling of connection sections 
> > is required in the SG when :
> > 
> > - the SG acts as SEP : in this case SUA is used to provide 
> > the interface between SCCP on the SG and the SCCP-user on the ASP.
> > 
> > - the SG acts as STP, and the AS/ASP cannot be derived from 
> > the received SCCP-CO message, or the SEP cannot be derived from the 
> > received SUA-CO message.
> > 
> > To avoid coupling, we need SS7 address info (at least a PC) 
> > in all SUA-CO messages (CODT etc.) ! If we want coupling of 
> > connection sections optional at the SG, we need to update the 
> > SUA-CO messages in this respect. 
> 
> Question to Brian & Gery - how is this handled at STPs, especially
> at network boundaries?
> 
> Brian, is the above solution acceptable to you?

I will have to dig deeper into it.  Certainly I agree that some of the
messages need to be enhanced as stated by Gery to include more information
for the "decoupled" case.  I'm just not sure yet whether these are all the
cases.  I will get back to you.

> 
> > BTW : are we going to work with routing contexts instead of network
> > appearance now in each SUA-CL and CO message ? If so, this 
> > could be used for mapping to a SEP in case of "no coupling" at the SG. 
> > To me this sounds like a good idea for 2 reasons :
> > 
> > - the network appearance parameter definition is still rather shaky
> > - the routing context could well provide the same (and more) 
> > functionality
> 
> So, are you suggesting colapseing network appearence into routing 
> context?

Sounds good to me.  I have made the same suggestion for M3UA.

>  
> > 4. Concerning DRST : let's see if I get it straight ... this 
> > is to signal to concerned/neighbouring nodes that a SG/SUA-relay node 
> > from a mated pair has lost connectivity to a SEP/SUA-end node and 
> > routing should preferably continue over the other mate. The other 
> > mate will receive a DUNA instead of a DRST, and when he loses
connectivity
> 
> > to the same endpoint as well, both SGs will send DUNA to their
neighbours.
> 
> This could be done, comments?

Could it?  I don't think so.  The states of a point code: availabile/
unavailabile, restricted/unrestricted, congested/uncongested are all
orthoginal.  DUNA will just not fit the bill for DRST.

Destinations do not become restricted because they have become unavailable
to some STP: they become restricted because the only routes that an STP has
to the destination are "undesirable," either because they are experiencing
some congestion situations, or becuase they are of a lower priority than the
normal route to the destination.

Gery is a somewhat off on his description of restriction.

>  
> > Since SGs can consist of several SGPs (and would be modelled 
> > as such in the ASP to guard SCTP connectivity), the SSNM messages 
> > (DUNA, DAVA, SCON, DRST), when received from any of these SGPs, should 
> > be regarded as valid for the entire SG.
> 
> agreed.
> 
> John
> 
> 
> ---
> You are currently subscribed to sigtran as: [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]
Date: Wed, 4 Jul 2001 02:18:56 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: Packing of DATA Payloads
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: albatross.prod.itd.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: albatross.mail.pas.earthlink.net [207.217.120.120]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Joyce,

Joyce Archibald wrote:                           (Mon, 02 Jul 2001 11:56:59)

[snip]
> 
> Not being a switch manufacturer I am not in a position to define
> how the SG will work but IMHO when sending messages to the SS7
> networks, the SG will need to insert the correct NI bits (and
> message priority?) into the routing label, and choose the
> appropriate linkset in case 3.
> 
> Also, how do you identify two endpoints with the same pointcode
> value in Registration Request messages, if the Network Appearance
> parameter is removed.
> 

REGREQ is probably the only place that I can agree with a Network Appearance
parameter.  Once registered, however, the Routing Context is much more
usable for reasons already stated.

-- 
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]
Date: Wed, 4 Jul 2001 02:26:21 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M3UA: Routing Key parameter
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: swan.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: swan.mail.pas.earthlink.net [207.217.120.123]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Maria-Cruz,

Certainly, not all of the possible subparameter combinations make sense.
However, IMHO, I believe that it is up to the SG implementation to determine
(from local configuration) which combinations are valid and which are not
(and reject the resgistration when they are not).

In particular, SI numbering is different or many national variants of SS7,
and any attempt to list the valid subparaemters for every SI value would
have to take into account every national variant of SS7, and further, be
updated as each national variant is updated.

The SG should know which SS7 variants it is support and which combinations
are valid in an implementation dependent manner.

Does that help clarify a rationale behind not specifying subparameter sets?

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:   (Mon, 02 Jul 2001 15:40:06)
> 
> Hi Greg,
> 
> I'd need your help to understand the RK parameter format defined in draft
v.6.
> 
> I do not know how the RK is built up from the included sub-parameters:
> DPC(unique), NA(unique), SI(list), SSN(list), OPC(list) and CIC(list).
> 
> Let's say the RK sub-parameters are the following:
> 
> DPC1
> NA1,
> SI1,SI2
> SSN1,SSN2,SSN3
> OPC1
> CIC1-30,CIC10-50
> 
> Then, is the RK made up with all the possible sub-parameters
combinations??
> I.e. could the following combinations be the RK defined?:
> 	DPC1,NA1,SI1,SSN1,OPC1,CIC1-30
> 	DPC1,NA1,SI1,SSN2,OPC1,CIC1-30
> 	DPC1,NA1,SI1,SSN3,OPC1,CIC1-30
> 	DPC1,NA1,SI2,SSN1,OPC1,CIC1-30
> 	DPC1,NA1,SI2,SSN2,OPC1,CIC1-30
> 	DPC1,NA1,SI2,SSN3,OPC1,CIC1-30
> 	DPC1,NA1,SI1,SSN1,OPC1,CIC10-50
> 	DPC1,NA1,SI1,SSN2,OPC1,CIC10-50
> 	DPC1,NA1,SI1,SSN3,OPC1,CIC10-50
> 	DPC1,NA1,SI2,SSN1,OPC1,CIC10-50
> 	DPC1,NA1,SI2,SSN2,OPC1,CIC10-50
> 	DPC1,NA1,SI2,SSN3,OPC1,CIC10-50
> 
> 
> If so, it is not that straight forward because we should take into account
that
> some sub-parameters could be optional, then we may like to define SSN (for
example),
> for a set of combinations but not for the others. Moreover, some
sub-parameters
> are only valid for a particular SI, i.e. SSN is only a valid value when
SI=3 (as
> it is written in the draft), and CICrange is only valid for SI=ISUP/TUP
but not
> for SCCP.
> 
> Wouldn't we need to define the RK in a different way? Combination by
combination?
> 
> Apart from that, the CIC range sub-parameter is defined as an OPC + CICmin
+
> CICmax. Why the OPC appears again within this sub-parameter?? Isn't it
already
> defined? As far as I understand it must be only CICmin + CICmax
> 
> 
> Could you clarify it to me?
> /MCruz
> 
> 
> ---
> You are currently subscribed to sigtran as: [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]
Date: Wed, 4 Jul 2001 02:38:25 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA6: Open Issues
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: harrier.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: harrier.mail.pas.earthlink.net [207.217.121.12]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

[email-masked] wrote:           (Tue, 03 Jul 2001 11:40:21)
> Hi all,
> 
> I have these issues open for the current version of SUA.  I'd
> like to get closure on these issues ASAP, then I think we could
> get ready for a last call on SUA.
> 
> Open issues:
> 
> 1) Align common parameter numbers with the other UAs.
> 
> 2) Is DRST needed or not.
> 
> 3) How to handle the coupling signaling gateways for SUA-connection 
>    oriented messages.
> 
> 4) Any issues related to the other UAs which may impact SUA
>    (this I may need some help on, as I have not been following the
>    other UAs so closely).
> 
> Anything else?

Yes...

  5) Any issues not covered in 1, 2, 3, and 4.  ;)

> 
> best regards,
> John
> 
> 
> ---
> You are currently subscribed to sigtran as: [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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA - DEREG Results
Date: Wed, 4 Jul 2001 23:13:03 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail1.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [24.2.9.88]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Maria-Cruz,

I read Ben's e-mail before but seeing as nobody supported it I didn't make
the change in Issue 7.  I had input from one person off-line who didn't like
the general idea of multiple like parameters in the same message.   But if
there is support for this I have no problem at all to make the change.

Cheers,

   Greg

----- Original Message -----
From: "Maria-Cruz Bartolome-Rodrigo (ECE)"
<[email-masked]> To: "sigtran"
<[email-masked]> Sent: Monday, July 02, 2001 9:44 AM
Subject: RE: M3UA - DEREG Results

>
> Hi Greg,
>
> I recall the mail below sent a long time ago.
> I checked the e-mail list but I couldn't find an answer to it.
> I have the same doubt as Ben had and his proposal sounds reasonable
> to me.
>
> What's your opinion about that?
>
> Cheers
> /MCruz
>
>
>
>
> -----Original Message-----
> From: Benjamin J. Wilson,,, [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2001 10:16 PM
> To: sigtran
> Subject: DEREG Results
>
>
> Greg/Norm,
>
> Might I suggest a bit of cleanup to the DEREG RSP and REG RSP?
>
> It seems a DEREG RSP contains 1 DEREG RESULTS parameter which
> itself contains many DEREG RESULT (singular) parameters.  It's not
> clear from the text b/c no tag is in the diagram, but there is a
> tag for it in the list of parameter ids at the beginning.
>
> Since REG REQ has many Routing Key parameters it seems the DEREG
> RESULTS parameter can be eliminated and the DEREG RSP could just
> contain many DEREG RESULT parameters.
>
> Hopefully this makes sense.
>
> Ben
>
>
>
> ---
> 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]
Date: Thu, 5 Jul 2001 03:18:05 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA & SCTP - M3UA connects to more than one SG.
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: swan.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [207.217.120.123]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Guatam,

Given that:

	'an' != 'one and only one'

	'an' == 'at least one'

there is no contradiction between the M3UA draft and the SCTP RFC, (which,
by the way, is no longer just a draft... :)

--Brian

[email-masked] wrote:                   (Thu, 05 Jul 2001 13:28:06)
> 
> 
> 
> HI All,
> 
> 
> 
> <snip> m3ua-06
> 
> definition of Application Server Process (ASP) -
> 
> .....An ASP contains an SCTP end- point and may be configured to process
>       signalling
> 
> traffic within more than one Application Server.
> 
> 
> 
> Now Consider that the ASP connects to more than one SG, since the
definition of
>       the ASP says
> 
> that ASP contains "an" endpoint, it connects to both the SG's using the
_same_
>       sctp port and IP address
> 
> combination.
> 
> 
> 
> >But according to SCTP
> 
> 
> 
> Definition of Endpoint ->
> SCTP endpoint: .....A transport address used by an SCTP endpoint must not
be
> used by another SCTP  endpoint.  In other words, a transport address is
unique
> to an
>       SCTP endpoint.
> 
> Now we if go by the SCTP definition of Endpoint then we cannot have the
same
> transport address in more than
> one Endpoints. So the ASP should be represented by separate endpoints for
both
> the SG's.  But this would contradict
> the definition of ASP as given by the M3UA Draft.
> 
> Which of the two drafts is correct....?
> 
> 
> 
> Regards
> Gautam.
> 

-- 
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: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: M3UA: Routing Key parameter
Date: Thu, 5 Jul 2001 11:48:39 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: penguin-ext.wise.edt.ericsson.se [194.237.142.110]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian/Greg,

In my opinion IF the RK is made up with all the possible sub-parameters
combinations (about what I'm not sure yet) then I find a few PROBLEMS:

- Not all the subparameters combinations would make sense.
  It is right that not valid ones could be detected, e.g. SSN for ISUP,
  but the SG would have to firstable build up all the combinations and 
  then discard some of them, what implies an extra work that could be
  easily avoided with a more specific RK parameter definition. 
  Then, what would be the REG result?? Can we say it was successful?
  We wouldn't know if the discarding was a kind of mistake or just an
  invalid combination.

- It is impossible to define some subparameter combinations without
  defining a big set of invalid combinations

- Some subparameters are just optional (depending on network config
criteria)
  E.g. For ISUP only DPC and SI are mandatory. For this example, let's say
we
  do not want to specify these optional subparameters
(NA,NI,OPC,CICmin,CICmax),
  is that possible with the present RK parameter definition?? I do not think
so.

I think a possible SOLUTION would be to have a 'local-RK-identifier' per
valid combination set, then invalid combinations could be avoided (e.g.
having a local-RK-identifier per SI would avoid having SSN for ISUP),
definition is easier and more understandable and optional parameter dealing
becomes easier as well. 

On the other hand, it would mean that it may be needed more than one
'local-RK-identifier' to be assigned to the same RC (then the name
'local-RK-id' wouldn't be the most appropiate...). This could be solved as
well considering, for example, that all 'local-RK-ids' (maybe named 'routing
subparameter combination') within the same REG REQ message should be
assigned to the same RC.

Let me know if this make sense to you or I am messing up things.
/MCruz

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Wednesday,
July 04, 2001 9:26 AM
To: sigtran
Cc: [email-masked] Subject: Re: M3UA: Routing Key
parameter

Maria-Cruz,

Certainly, not all of the possible subparameter combinations make sense.
However, IMHO, I believe that it is up to the SG implementation to determine
(from local configuration) which combinations are valid and which are not
(and reject the resgistration when they are not).

In particular, SI numbering is different or many national variants of SS7,
and any attempt to list the valid subparaemters for every SI value would
have to take into account every national variant of SS7, and further, be
updated as each national variant is updated.

The SG should know which SS7 variants it is support and which combinations
are valid in an implementation dependent manner.

Does that help clarify a rationale behind not specifying subparameter sets?

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:   (Mon, 02 Jul 2001 15:40:06)
> 
> Hi Greg,
> 
> I'd need your help to understand the RK parameter format defined in draft
v.6.
> 
> I do not know how the RK is built up from the included sub-parameters:
> DPC(unique), NA(unique), SI(list), SSN(list), OPC(list) and CIC(list).
> 
> Let's say the RK sub-parameters are the following:
> 
> DPC1
> NA1,
> SI1,SI2
> SSN1,SSN2,SSN3
> OPC1
> CIC1-30,CIC10-50
> 
> Then, is the RK made up with all the possible sub-parameters
combinations??
> I.e. could the following combinations be the RK defined?:
> 	DPC1,NA1,SI1,SSN1,OPC1,CIC1-30
> 	DPC1,NA1,SI1,SSN2,OPC1,CIC1-30
> 	DPC1,NA1,SI1,SSN3,OPC1,CIC1-30
> 	DPC1,NA1,SI2,SSN1,OPC1,CIC1-30
> 	DPC1,NA1,SI2,SSN2,OPC1,CIC1-30
> 	DPC1,NA1,SI2,SSN3,OPC1,CIC1-30
> 	DPC1,NA1,SI1,SSN1,OPC1,CIC10-50
> 	DPC1,NA1,SI1,SSN2,OPC1,CIC10-50
> 	DPC1,NA1,SI1,SSN3,OPC1,CIC10-50
> 	DPC1,NA1,SI2,SSN1,OPC1,CIC10-50
> 	DPC1,NA1,SI2,SSN2,OPC1,CIC10-50
> 	DPC1,NA1,SI2,SSN3,OPC1,CIC10-50
> 
> 
> If so, it is not that straight forward because we should take into account
that
> some sub-parameters could be optional, then we may like to define SSN (for
example),
> for a set of combinations but not for the others. Moreover, some
sub-parameters
> are only valid for a particular SI, i.e. SSN is only a valid value when
SI=3 (as
> it is written in the draft), and CICrange is only valid for SI=ISUP/TUP
but not
> for SCCP.
> 
> Wouldn't we need to define the RK in a different way? Combination by
combination?
> 
> Apart from that, the CIC range sub-parameter is defined as an OPC + CICmin
+
> CICmax. Why the OPC appears again within this sub-parameter?? Isn't it
already
> defined? As far as I understand it must be only CICmin + CICmax
> 
> 
> Could you clarify it to me?
> /MCruz
> 
> 
> ---
> You are currently subscribed to sigtran as: [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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA6: Open Issues
Date: Thu, 5 Jul 2001 14:39:56 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> Yes...
> 
>   5) Any issues not covered in 1, 2, 3, and 4.  ;)

Please let us know, then.  Reducing carbon dioxide emissions is out of
scope, though ;)

thanks,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA6: SG Relay Problems
Date: Thu, 5 Jul 2001 15:20:17 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades9.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.78.143.119]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello all,

Just a summary of comments on the earlier points.

1. Reassembly of XUDT at SG, into CLDT towards SUA-node.

The difference with SCCP procedures here is that in SCCP, reassembly is
strictly performed in the end-node (also out-of-sequence detection), while
this is not the case here (ASP does not do this anymore). Ok, the major part
of the problem is resolved by the fact that all segments use protocol class
1, but for link/route failure cases we need this extra procedure in  the
mated SGs. It isn't needed in mated STPs.

2/3. Routing context : for SUA-07, I'd propose to use the Routing Context
instead of Network Appearance consistently as optional parameter in all
SUA-CL and -CO messages. During Final Call, we can put the dots on the i.

4. Use of DRST : think this needs a figure for proper explanation ;) See
attach; how y'all got powerpoint ;))

Situation :
- SS7 nodes a,b,c connected to a mated pair of SGs (SG1, SG2); and concerned
for SSNs serviced at ASPs x,y,z
- SGs are connected to mated pair of SRPs (SUA Relay Points), full mesh,
supposing single SGP per SG ...
- ASPs x,y,z connected to this mated pair of SRPs

1st Event : SCTP association between SRP1 and ASPx fails

Result :
- DRST(x) sent from SRP1 to : SG1, SG2, ASPy and ASPz - DUNA(x) sent from
SRP1 to SRP2

2nd Event : SCTP association between SRP2 and ASPx fails too => ASPx
isolation ! (Not in slides)

Result :
- DUNA(x) sent from SRP2 to SRP1
- Both SRP1 and SRP2 send DUNA(x) to : SG1, SG2, ASPy and ASPz - SG1 and SG2
send DUNA(x) to each other as well - SG1 and SG2 send SSP (subsystem
prohibited) for the applicable SSNs serviced at ASPx, if ASPx was the last
available one in the AS (routing context !)

3rd Event : ASPz failure

Result : same reaction as for ASP isolation; SRP1 sends DUNA(z) to SRP2
also, since there was no restriction first.
Of course, ASPx is out and doesn't receive DUNA(z).

Anything missing/other scenario's ?

5. Further SUA management procedures (chapter 4.3.3 in the draft ?)

5.1 At the receiving node

After reception of DUNA, SCON or DRST, the receiving node may start an audit
procedure to monitor the status of the affected destination (identified by
routing context). To this end, a DAUD message may be sent periodically for a
certain time interval, or until a DAVA message is received, whichever comes
first. The time interval should be restarted with each new reception of
DUNA, SCON or DRST.

Although congestion and restriction information is orthogonal and must be
maintained/monitored separately, this information is overruled by DUNA,
which signals unavailability.

When the time interval expires and no new status information is received,
the affected destination is considered available/uncongested/unrestricted
again.

5.2 At the sending node

The node which detects ASP status changes, either via ASP management or SCTP
notifications, shall inform it's concerned neighbours with the appropriate
SUA management message (DUNA, SCON, DRST).

Both the response method and the audit procedure must be supported :

- response method : for each n messages (n e.g. equal 8) received over an
SCTP association destined for the affected destination a DUNA, SCON or DRST
message shall be sent back.

- audit procedure : the node receiving a DAUD shall reply with DAVA, DUNA,
SCON or DRST depending on the status of the affected destination.

Remark : when an affected destination is both congested and restricted, both
SCON and DRST shall be sent back in either method.
=========================

Regards,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

Attachment Converted: "c:\program files\qualcomm\eudora
pro\attach\DRST_proc.ppt" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Thu, 5 Jul 2001 20:43:55 +0530
Subject: Re: M3UA & SCTP - M3UA connects to more than one SG.
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [202.54.26.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi ,

Does the following two combinations of SCTP port numbers and IP addresses
make two valid SCTP associations.

Host A                             HOST B 1)sctp_port=A, IP_addr= A  <----
association -----> sctp_port=B1, IP_addr=B 2)sctp_port=A, IP_addr=A
<----association ------> sctp_port=B2, IP_addr=B

For the case when association is initiated from Host B and when it is
initiated from Host A.

Regards
Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 07/05/2001 02:48:05 PM

Please respond to [email-masked]

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

Subject:  Re: M3UA & SCTP - M3UA connects to more than one SG.

Guatam,

Given that:

     'an' != 'one and only one'

     'an' == 'at least one'

there is no contradiction between the M3UA draft and the SCTP RFC, (which,
by the way, is no longer just a draft... :)

--Brian

[email-masked] wrote:                   (Thu, 05 Jul 2001 13:28:06)
>
>
>
> HI All,
>
>
>
> <snip> m3ua-06
>
> definition of Application Server Process (ASP) -
>
> .....An ASP contains an SCTP end- point and may be configured to process
>       signalling
>
> traffic within more than one Application Server.
>
>
>
> Now Consider that the ASP connects to more than one SG, since the
definition of
>       the ASP says
>
> that ASP contains "an" endpoint, it connects to both the SG's using the
_same_
>       sctp port and IP address
>
> combination.
>
>
>
> >But according to SCTP
>
>
>
> Definition of Endpoint ->
> SCTP endpoint: .....A transport address used by an SCTP endpoint must not
be
> used by another SCTP  endpoint.  In other words, a transport address is
unique
> to an
>       SCTP endpoint.
>
> Now we if go by the SCTP definition of Endpoint then we cannot have the
same
> transport address in more than
> one Endpoints. So the ASP should be represented by separate endpoints for
both
> the SG's.  But this would contradict
> the definition of ASP as given by the M3UA Draft.
>
> Which of the two drafts is correct....?
>
>
>
> Regards
> Gautam.
>

--
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]
Date: Thu, 05 Jul 2001 17:26:09 +0200
From: Michael Tüxen <[email-masked]>
X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UA & SCTP - M3UA connects to more than one SG.
X-SMTP-HELO: ilsa.franken.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ilsa.franken.de [193.175.24.42]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

this would be the normal situation if host B acts as a client, host A acts
as a server on the
well known port A. So it is a valid situation in this setup. Because SCTP is
a peer to
peer protocol the validness should not depend on the fact who is sending the
INIT the answer
to the question should also be that it is valid if host A send the INITs. A
mixed case is also
possible. I'm not sure if this scenario is supported by all implementations
and if it is possible
to do this with the socket interface?

Best regards
Michael

[email-masked] wrote:

> Hi ,
>
> Does the following two combinations of SCTP port numbers and IP addresses
make
> two valid SCTP associations.
>
> Host A                             HOST B
> 1)sctp_port=A, IP_addr= A  <---- association -----> sctp_port=B1,
IP_addr=B
> 2)sctp_port=A, IP_addr=A  <----association ------> sctp_port=B2, IP_addr=B
>
> For the case when association is initiated from Host B and when it is
initiated
> from Host A.
>
> Regards
> Sandeep
>
> "Brian F. G. Bidulock" <[email-masked]> on 07/05/2001 02:48:05 PM
>
> Please respond to [email-masked]
>
> To:   "sigtran" <[email-masked]>
> cc:    (bcc: Sandeep Mahajan/HSS)
>
> Subject:  Re: M3UA & SCTP - M3UA connects to more than one SG.
>
> Guatam,
>
> Given that:
>
>      'an' != 'one and only one'
>
>      'an' == 'at least one'
>
> there is no contradiction between the M3UA draft and the SCTP RFC,
> (which, by the way, is no longer just a draft... :)
>
> --Brian
>
> [email-masked] wrote:                   (Thu, 05 Jul 2001 13:28:06)
> >
> >
> >
> > HI All,
> >
> >
> >
> > <snip> m3ua-06
> >
> > definition of Application Server Process (ASP) -
> >
> > .....An ASP contains an SCTP end- point and may be configured to process
> >       signalling
> >
> > traffic within more than one Application Server.
> >
> >
> >
> > Now Consider that the ASP connects to more than one SG, since the
definition
> of
> >       the ASP says
> >
> > that ASP contains "an" endpoint, it connects to both the SG's using the
_same_
> >       sctp port and IP address
> >
> > combination.
> >
> >
> >
> > >But according to SCTP
> >
> >
> >
> > Definition of Endpoint ->
> > SCTP endpoint: .....A transport address used by an SCTP endpoint must
not be
> > used by another SCTP  endpoint.  In other words, a transport address is
unique
> > to an
> >       SCTP endpoint.
> >
> > Now we if go by the SCTP definition of Endpoint then we cannot have the
same
> > transport address in more than
> > one Endpoints. So the ASP should be represented by separate endpoints
for both
> > the SG's.  But this would contradict
> > the definition of ASP as given by the M3UA Draft.
> >
> > Which of the two drafts is correct....?
> >
> >
> >
> > Regards
> > Gautam.
> >
>
> --
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA - DEREG Results
Date: Thu, 5 Jul 2001 21:27:46 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: penguin-ext.wise.edt.ericsson.se [194.237.142.110]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg,

In issue 6 both messages (REG RSP and DEREG RSP) do have only one parameter
('Registration Results' and 'De-registration Results'), that's right, but
being those made up of multiple like parameters I do not think it makes
things easier at all, on the contrary I find that the proposal below will
simplify these messages and we will get rid of two parameters that are
mainly sub-parameter containers and rather useless.

What are the advantages of the actual format? 
I may misundertand something...

Thanks
/MCruz

-----Original Message-----
From: Greg Sidebottom [mailto:[email-masked]] Sent: Thursday, July 05,
2001 5:13 AM
To: sigtran
Subject: Re: M3UA - DEREG Results

Hi Maria-Cruz,

I read Ben's e-mail before but seeing as nobody supported it I didn't make
the change in Issue 7.  I had input from one person off-line who didn't like
the general idea of multiple like parameters in the same message.   But if
there is support for this I have no problem at all to make the change.

Cheers,

   Greg

----- Original Message -----
From: "Maria-Cruz Bartolome-Rodrigo (ECE)"
<[email-masked]> To: "sigtran"
<[email-masked]> Sent: Monday, July 02, 2001 9:44 AM
Subject: RE: M3UA - DEREG Results

>
> Hi Greg,
>
> I recall the mail below sent a long time ago.
> I checked the e-mail list but I couldn't find an answer to it.
> I have the same doubt as Ben had and his proposal sounds reasonable
> to me.
>
> What's your opinion about that?
>
> Cheers
> /MCruz
>
>
>
>
> -----Original Message-----
> From: Benjamin J. Wilson,,, [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2001 10:16 PM
> To: sigtran
> Subject: DEREG Results
>
>
> Greg/Norm,
>
> Might I suggest a bit of cleanup to the DEREG RSP and REG RSP?
>
> It seems a DEREG RSP contains 1 DEREG RESULTS parameter which
> itself contains many DEREG RESULT (singular) parameters.  It's not
> clear from the text b/c no tag is in the diagram, but there is a
> tag for it in the list of parameter ids at the beginning.
>
> Since REG REQ has many Routing Key parameters it seems the DEREG
> RESULTS parameter can be eliminated and the DEREG RSP could just
> contain many DEREG RESULT parameters.
>
> Hopefully this makes sense.
>
> Ben
>
>
>
> ---
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Fri, 6 Jul 2001 01:11:01 +0530
Subject: Re: M3UA & SCTP - M3UA connects to more than one SG.
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [202.54.26.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,
     What if A wants to act as a client? is this possible? could we have two
endpoints on the
same host with the same transport address?     what happens if the host is
multihomed?
is it possible for two endpoints to share some of the transport addresses
(IP +port)
bettwen them?

Hi,

this would be the normal situation if host B acts as a client, host A acts
as a server on the
well known port A. So it is a valid situation in this setup. Because SCTP is
a peer
to
peer protocol the validness should not depend on the fact who is sending the
INIT
the answer
to the question should also be that it is valid if host A send the INITs. A
mixed
case is also
possible. I'm not sure if this scenario is supported by all implementations
and if
it is possible
to do this with the socket interface?

Best regards
Michael

[email-masked] wrote:

> Hi ,
>
> Does the following two combinations of SCTP port numbers and IP addresses
make
> two valid SCTP associations.
>
> Host A                             HOST B
> 1)sctp_port=A, IP_addr= A  <---- association -----> sctp_port=B1,
IP_addr=B
> 2)sctp_port=A, IP_addr=A  <----association ------> sctp_port=B2, IP_addr=B
>
> For the case when association is initiated from Host B and when it is
initiated
> from Host A.
>
> Regards
> Sandeep
>
> "Brian F. G. Bidulock" <[email-masked]> on 07/05/2001 02:48:05 PM
>
> Please respond to [email-masked]
>
> To:   "sigtran" <[email-masked]>
> cc:    (bcc: Sandeep Mahajan/HSS)
>
> Subject:  Re: M3UA & SCTP - M3UA connects to more than one SG.
>
> Guatam,
>
> Given that:
>
>      'an' != 'one and only one'
>
>      'an' == 'at least one'
>
> there is no contradiction between the M3UA draft and the SCTP RFC,
> (which, by the way, is no longer just a draft... :)
>
> --Brian
>
> [email-masked] wrote:                   (Thu, 05 Jul 2001 13:28:06)
> >
> >
> >
> > HI All,
> >
> >
> >
> > <snip> m3ua-06
> >
> > definition of Application Server Process (ASP) -
> >
> > .....An ASP contains an SCTP end- point and may be configured to process
> >       signalling
> >
> > traffic within more than one Application Server.
> >
> >
> >
> > Now Consider that the ASP connects to more than one SG, since the
definition
> of
> >       the ASP says
> >
> > that ASP contains "an" endpoint, it connects to both the SG's using the
_same_
> >       sctp port and IP address
> >
> > combination.
> >
> >
> >
> > >But according to SCTP
> >
> >
> >
> > Definition of Endpoint ->
> > SCTP endpoint: .....A transport address used by an SCTP endpoint must
not be
> > used by another SCTP  endpoint.  In other words, a transport address is
unique
> > to an
> >       SCTP endpoint.
> >
> > Now we if go by the SCTP definition of Endpoint then we cannot have the
same
> > transport address in more than
> > one Endpoints. So the ASP should be represented by separate endpoints
for both
> > the SG's.  But this would contradict
> > the definition of ASP as given by the M3UA Draft.
> >
> > Which of the two drafts is correct....?
> >
> >
> >
> > Regards
> > Gautam.
> >
>
> --
> 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]

---
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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA - DEREG Results
Date: Thu, 5 Jul 2001 20:44:37 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail16.sdc1.sfba.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail16.sdc1.sfba.home.com [24.0.95.143]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Maria-Cruz,

I really don't know which approach is "easier" or "simpler" - I'll let the
implementors out there tell me their preference.  I don't remember the
REG/DEREG RSP format being given any real deep thought when we worked it out
- I suppose the current format saves a few Tag/Length bytes when there are
multiple results.  But if it is ugly or harder to process then I have no
problem changing it.

Cheers,

Greg Sidebottom
[email-masked]

----- Original Message -----
From: "Maria-Cruz Bartolome-Rodrigo (ECE)"
<[email-masked]> To: "sigtran"
<[email-masked]> Sent: Thursday, July 05, 2001 3:27 PM
Subject: RE: M3UA - DEREG Results

>
> Hi Greg,
>
> In issue 6 both messages (REG RSP and DEREG RSP) do have only one
> parameter ('Registration Results' and 'De-registration Results'),
> that's right, but being those made up of multiple like parameters
> I do not think it makes things easier at all, on the contrary
> I find that the proposal below will simplify these messages and
> we will get rid of two parameters that are mainly sub-parameter
> containers and rather useless.
>
> What are the advantages of the actual format?
> I may misundertand something...
>
> Thanks
> /MCruz
>
>
>
> -----Original Message-----
> From: Greg Sidebottom [mailto:[email-masked]]
> Sent: Thursday, July 05, 2001 5:13 AM
> To: sigtran
> Subject: Re: M3UA - DEREG Results
>
>
> Hi Maria-Cruz,
>
> I read Ben's e-mail before but seeing as nobody supported it I didn't make
> the change in Issue 7.  I had input from one person off-line who didn't
like
> the general idea of multiple like parameters in the same message.   But if
> there is support for this I have no problem at all to make the change.
>
> Cheers,
>
>    Greg
>
> ----- Original Message -----
> From: "Maria-Cruz Bartolome-Rodrigo (ECE)"
> <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Monday, July 02, 2001 9:44 AM
> Subject: RE: M3UA - DEREG Results
>
>
> >
> > Hi Greg,
> >
> > I recall the mail below sent a long time ago.
> > I checked the e-mail list but I couldn't find an answer to it.
> > I have the same doubt as Ben had and his proposal sounds reasonable
> > to me.
> >
> > What's your opinion about that?
> >
> > Cheers
> > /MCruz
> >
> >
> >
> >
> > -----Original Message-----
> > From: Benjamin J. Wilson,,, [mailto:[email-masked]]
> > Sent: Tuesday, April 03, 2001 10:16 PM
> > To: sigtran
> > Subject: DEREG Results
> >
> >
> > Greg/Norm,
> >
> > Might I suggest a bit of cleanup to the DEREG RSP and REG RSP?
> >
> > It seems a DEREG RSP contains 1 DEREG RESULTS parameter which
> > itself contains many DEREG RESULT (singular) parameters.  It's not
> > clear from the text b/c no tag is in the diagram, but there is a
> > tag for it in the list of parameter ids at the beginning.
> >
> > Since REG REQ has many Routing Key parameters it seems the DEREG
> > RESULTS parameter can be eliminated and the DEREG RSP could just
> > contain many DEREG RESULT parameters.
> >
> > Hopefully this makes sense.
> >
> > Ben
> >
> >
> >
> > ---
> > 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]
>
>
> ---
> 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: abhisek <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA & SCTP - M3UA connects to more than one SG.
Date: Fri, 6 Jul 2001 09:50:55 +0900
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-SMTP-HELO: moon.daewoo.co.kr
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.1.5]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

hi
RFC-2960 p-12 reads "A transport address used by an SCTP endpoint MUST not
be used by another SCTP endpoint".i think this answers ur first part of the
question (otherwise it will not be possible to identify different
endpoints). Also, multi homing is a concept, that is introduced just to
provide the alternate IP addresses for provoding network level fault
tolerence and it has nothing to do with port numbers (of course, u need to
have unique port number for an association irrespective of the number of IP
addresses used in that association).
regards,
abhisek
----- Original Message -----
From: <[email-masked]>
To: "sigtran" <[email-masked]> Sent: Friday, July 06, 2001
4:41 AM
Subject: Re: M3UA & SCTP - M3UA connects to more than one SG.

>
>
>
> Hi,
>      What if A wants to act as a client? is this possible? could we have
two
> endpoints on the
> same host with the same transport address?     what happens if the host is
> multihomed?
> is it possible for two endpoints to share some of the transport addresses
(IP
> +port)
> bettwen them?
>
>
>
>
>
>
> Hi,
>
> this would be the normal situation if host B acts as a client, host A acts
as a
> server on the
> well known port A. So it is a valid situation in this setup. Because SCTP
is a
> peer
> to
> peer protocol the validness should not depend on the fact who is sending
the
> INIT
> the answer
> to the question should also be that it is valid if host A send the INITs.
A
> mixed
> case is also
> possible. I'm not sure if this scenario is supported by all
implementations and
> if
> it is possible
> to do this with the socket interface?
>
> Best regards
> Michael
>
> [email-masked] wrote:
>
> > Hi ,
> >
> > Does the following two combinations of SCTP port numbers and IP
addresses make
> > two valid SCTP associations.
> >
> > Host A                             HOST B
> > 1)sctp_port=A, IP_addr= A  <---- association -----> sctp_port=B1,
IP_addr=B
> > 2)sctp_port=A, IP_addr=A  <----association ------> sctp_port=B2,
IP_addr=B
> >
> > For the case when association is initiated from Host B and when it is
> initiated
> > from Host A.
> >
> > Regards
> > Sandeep
> >
> > "Brian F. G. Bidulock" <[email-masked]> on 07/05/2001 02:48:05 PM
> >
> > Please respond to [email-masked]
> >
> > To:   "sigtran" <[email-masked]>
> > cc:    (bcc: Sandeep Mahajan/HSS)
> >
> > Subject:  Re: M3UA & SCTP - M3UA connects to more than one SG.
> >
> > Guatam,
> >
> > Given that:
> >
> >      'an' != 'one and only one'
> >
> >      'an' == 'at least one'
> >
> > there is no contradiction between the M3UA draft and the SCTP RFC,
> > (which, by the way, is no longer just a draft... :)
> >
> > --Brian
> >
> > [email-masked] wrote:                   (Thu, 05 Jul 2001
13:28:06)
> > >
> > >
> > >
> > > HI All,
> > >
> > >
> > >
> > > <snip> m3ua-06
> > >
> > > definition of Application Server Process (ASP) -
> > >
> > > .....An ASP contains an SCTP end- point and may be configured to
process
> > >       signalling
> > >
> > > traffic within more than one Application Server.
> > >
> > >
> > >
> > > Now Consider that the ASP connects to more than one SG, since the
definition
> > of
> > >       the ASP says
> > >
> > > that ASP contains "an" endpoint, it connects to both the SG's using
the
> _same_
> > >       sctp port and IP address
> > >
> > > combination.
> > >
> > >
> > >
> > > >But according to SCTP
> > >
> > >
> > >
> > > Definition of Endpoint ->
> > > SCTP endpoint: .....A transport address used by an SCTP endpoint must
not be
> > > used by another SCTP  endpoint.  In other words, a transport address
is
> unique
> > > to an
> > >       SCTP endpoint.
> > >
> > > Now we if go by the SCTP definition of Endpoint then we cannot have
the same
> > > transport address in more than
> > > one Endpoints. So the ASP should be represented by separate endpoints
for
> both
> > > the SG's.  But this would contradict
> > > the definition of ASP as given by the M3UA Draft.
> > >
> > > Which of the two drafts is correct....?
> > >
> > >
> > >
> > > Regards
> > > Gautam.
> > >
> >
> > --
> > 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]
>
>
>
> ---
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: M3UA & SCTP - M3UA connects to more than one SG.
Date: Fri, 6 Jul 2001 09:01:43 +0530
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-Server: VPOP3 V1.3.0b - Registered to: CoSystems, Inc
X-SMTP-HELO: dfw-smtpout2.email.verio.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: dfw-smtpout2.email.verio.net [129.250.36.42]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi Sandeep,
    The combination of SCTP Port numbers and IP addresses does make two
valid SCTP association.

-regards,
Umesh.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent: Thursday,
July 05, 2001 8:44 PM
To: sigtran
Subject: Re: M3UA & SCTP - M3UA connects to more than one SG.

Hi ,

Does the following two combinations of SCTP port numbers and IP addresses
make
two valid SCTP associations.

Host A                             HOST B 1)sctp_port=A, IP_addr= A  <----
association -----> sctp_port=B1, IP_addr=B 2)sctp_port=A, IP_addr=A
<----association ------> sctp_port=B2, IP_addr=B

For the case when association is initiated from Host B and when it is
initiated
from Host A.

Regards
Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 07/05/2001 02:48:05 PM

Please respond to [email-masked]

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

Subject:  Re: M3UA & SCTP - M3UA connects to more than one SG.

Guatam,

Given that:

     'an' != 'one and only one'

     'an' == 'at least one'

there is no contradiction between the M3UA draft and the SCTP RFC, (which,
by the way, is no longer just a draft... :)

--Brian

[email-masked] wrote:                   (Thu, 05 Jul 2001 13:28:06)
>
>
>
> HI All,
>
>
>
> <snip> m3ua-06
>
> definition of Application Server Process (ASP) -
>
> .....An ASP contains an SCTP end- point and may be configured to process
>       signalling
>
> traffic within more than one Application Server.
>
>
>
> Now Consider that the ASP connects to more than one SG, since the
definition
of
>       the ASP says
>
> that ASP contains "an" endpoint, it connects to both the SG's using the
_same_
>       sctp port and IP address
>
> combination.
>
>
>
> >But according to SCTP
>
>
>
> Definition of Endpoint ->
> SCTP endpoint: .....A transport address used by an SCTP endpoint must not
be
> used by another SCTP  endpoint.  In other words, a transport address is
unique
> to an
>       SCTP endpoint.
>
> Now we if go by the SCTP definition of Endpoint then we cannot have the
same
> transport address in more than
> one Endpoints. So the ASP should be represented by separate endpoints for
both
> the SG's.  But this would contradict
> the definition of ASP as given by the M3UA Draft.
>
> Which of the two drafts is correct....?
>
>
>
> Regards
> Gautam.
>

--
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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: workgroup status
Date: Fri, 6 Jul 2001 09:40:38 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x3.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [131.228.20.26]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Lyndon,

> -- we have tentatively been scheduled to meet on Tuesday 
> afternoon in London (Aug. 7th) for 1 hour.  Please send me an 
> email if you have a topic that you would like to discuss.

I could present a short update on SUA.

br,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 6 Jul 2001 02:08:46 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA6: SG Relay Problems
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: scaup.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: scaup.mail.pas.earthlink.net [207.217.121.49]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gery,

Please see comments below...

Verwimp Gery wrote:                            (Thu, 05 Jul 2001 15:20:17)
> Hello all,
> 
> Just a summary of comments on the earlier points.
> 
> 1. Reassembly of XUDT at SG, into CLDT towards SUA-node.
> 
> The difference with SCCP procedures here is that in SCCP, reassembly is
> strictly performed in the end-node (also out-of-sequence detection), while
> this is not the case here (ASP does not do this anymore). Ok, the major
part
> of the problem is resolved by the fact that all segments use protocol
class
> 1, but for link/route failure cases we need this extra procedure in  the
> mated SGs. It isn't needed in mated STPs.

I don't understand what you are getting at here...  What is the difference
between a mated SG and a mated STP, and how is it a problem for mated SGs
which is not already handled in the SS7 context?

> 
> 2/3. Routing context : for SUA-07, I'd propose to use the Routing Context
> instead of Network Appearance consistently as optional parameter in all
> SUA-CL and -CO messages. During Final Call, we can put the dots on the i.

I think that this would be a good start.

> 
> 4. Use of DRST : think this needs a figure for proper explanation ;) See
> attach; how y'all got powerpoint ;))
> 
> Situation:
> - SS7 nodes a,b,c connected to a mated pair of SGs (SG1, SG2); and
concerned
> for SSNs serviced at ASPs x,y,z
> - SGs are connected to mated pair of SRPs (SUA Relay Points), full mesh,
> supposing single SGP per SG ...
> - ASPs x,y,z connected to this mated pair of SRPs
> 
> 1st Event : SCTP association between SRP1 and ASPx fails
> 
> Result:
> - DRST(x) sent from SRP1 to : SG1, SG2, ASPy and ASPz
> - DUNA(x) sent from SRP1 to SRP2
> 
> 2nd Event : SCTP association between SRP2 and ASPx fails too => ASPx
> isolation ! (Not in slides)
> 
> Result:
> - DUNA(x) sent from SRP2 to SRP1
> - Both SRP1 and SRP2 send DUNA(x) to : SG1, SG2, ASPy and ASPz
> - SG1 and SG2 send DUNA(x) to each other as well
> - SG1 and SG2 send SSP (subsystem prohibited) for the applicable SSNs
> serviced at ASPx, if ASPx was the last available one in the AS (routing
> context !)

I can't imagine what you are trying to get at with these diagrams and
scenarios.  One of the cases that I was concerned about is as follows:

                   +-----+       +-----+
                   |     |       |     |
                  X| STP +-------+ SG1 |\
                 X |  A  |       |     | \
        /-----\ X  +-----+       +-----+  \ /-----\
        |     |X      |                    \|     |
        | SEP |       |                     | ASP |
        |     |\      |                    /|     |
        \-----/ \  +-----+       +-----+  / \-----\
                 \ |     |       |     | /
                  \| STP +-------+ SG2 |/
                   |  B  |       |     |
                   +-----+       +-----+

    Signalling link set between SEP and STP-A fails.  STP-A sends
    TFR to SG1.  SG1 needs to send DRST to ASP to let ASP know to
    stop (if possible) routing messages to SEP via SG1.

    When an SG sends TFR to the SS7 network should be left up to the
    implementation.

    The SRPs in your diagrams (what is an SRP anyway?) appear to be
    performing only the function of an STP and I see no apparent
    reason why one would need them.  Why are they there?

> 
> 3rd Event : ASPz failure
> 
> Result: same reaction as for ASP isolation; SRP1 sends DUNA(z) to SRP2
> also, since there was no restriction first.
> Of course, ASPx is out and doesn't receive DUNA(z).
> 
> Anything missing/other scenario's ?
> 
> 5. Further SUA management procedures (chapter 4.3.3 in the draft ?)
> 
> 5.1 At the receiving node
> 
> After reception of DUNA, SCON or DRST, the receiving node may start an
audit
> procedure to monitor the status of the affected destination (identified by
> routing context). To this end, a DAUD message may be sent periodically for
a
> certain time interval, or until a DAVA message is received, whichever
comes
> first. The time interval should be restarted with each new reception of
> DUNA, SCON or DRST.

I don't think that this will work well with similar procedures at MTP3 in
the SS7 network.  The SG itself does not really know the availability or
unavailability of signalling points because the messages which change status
may be lost.  The ASP must be made congizant of MTP restart procedures as
well as using N-PCSTATE semantics for these messages.

> 
> Although congestion and restriction information is orthogonal and must be
> maintained/monitored separately, this information is overruled by DUNA,
> which signals unavailability.
> 
This does not appear to be compatible with N-PCSTATE semantics.

> When the time interval expires and no new status information is received,
> the affected destination is considered available/uncongested/unrestricted
> again.

This is incompatible with both MTP procedures as well as N-PCSTATE
semantics.

> 
> 5.2 At the sending node
> 
> The node which detects ASP status changes, either via ASP management or
SCTP
> notifications, shall inform it's concerned neighbours with the appropriate
> SUA management message (DUNA, SCON, DRST).

Because an SUA ASP can not be considered to be equipped with an MTP transfer
function, I see no need for it ever to generate a DRST.

> 
> Both the response method and the audit procedure must be supported :

What is the rationale behind forcing an implementation to support both
procedures?  I don't see a need for the "MUST" on both procedures.

> 
> - response method : for each n messages (n e.g. equal 8) received over an
> SCTP association destined for the affected destination a DUNA, SCON or
DRST
> message shall be sent back.

I don't see the need for this procedure.  Also, I don't see the need for
requiring this specific algorithm on the implementation.  What is you
justification for this procedure?

> 
> - audit procedure : the node receiving a DAUD shall reply with DAVA, DUNA,
> SCON or DRST depending on the status of the affected destination.
> 
> Remark: when an affected destination is both congested and restricted,
both
> SCON and DRST shall be sent back in either method.

This should be made consistent with M3UA/MTP.

> =========================
> 

-- 
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: Tuexen Michael <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA & SCTP - M3UA connects to more than one SG.
Date: Fri, 6 Jul 2001 09:25:05 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: gorilla.mchh.siemens.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.138.158.18]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii, See my comments below.
Best regards
Michael
PS.: The first line is to make the mail reflector happy.

Michael Tuexen    Tel.:   +49 89 722 47210 Siemens AG        Fax:    +49 89
722 48212 ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Thursday, July 05, 2001 9:41 PM
> To:	sigtran
> Subject:	Re: M3UA & SCTP - M3UA connects to more than one SG.
> 
> 
> 
> 
> Hi,
>      What if A wants to act as a client? is this possible? could we have
two
> endpoints on the
> same host with the same transport address?
	[Tuexen Michael]  No, this is clearly stated in the RFC 2960. But in
your scenario you have one SCTP endpoint at host A and two at host B.
>      what happens if the host is
> multihomed?
	[Tuexen Michael]  It doesn't matter.
> is it possible for two endpoints to share some of the transport addresses
(IP
> +port)
> bettwen them?
	[Tuexen Michael]  No, this is alos clearly stated in RFC 2960. See
page 13.

> Hi,
> 
> this would be the normal situation if host B acts as a client, host A acts
as a
> server on the
> well known port A. So it is a valid situation in this setup. Because SCTP
is a
> peer
> to
> peer protocol the validness should not depend on the fact who is sending
the
> INIT
> the answer
> to the question should also be that it is valid if host A send the INITs.
A
> mixed
> case is also
> possible. I'm not sure if this scenario is supported by all
implementations and
> if
> it is possible
> to do this with the socket interface?
> 
> Best regards
> Michael
> 
> [email-masked] wrote:
> 
> > Hi ,
> >
> > Does the following two combinations of SCTP port numbers and IP
addresses make
> > two valid SCTP associations.
> >
> > Host A                             HOST B
> > 1)sctp_port=A, IP_addr= A  <---- association -----> sctp_port=B1,
IP_addr=B
> > 2)sctp_port=A, IP_addr=A  <----association ------> sctp_port=B2,
IP_addr=B
> >
> > For the case when association is initiated from Host B and when it is
> initiated
> > from Host A.
> >
> > Regards
> > Sandeep
> >
> > "Brian F. G. Bidulock" <[email-masked]> on 07/05/2001 02:48:05 PM
> >
> > Please respond to [email-masked]
> >
> > To:   "sigtran" <[email-masked]>
> > cc:    (bcc: Sandeep Mahajan/HSS)
> >
> > Subject:  Re: M3UA & SCTP - M3UA connects to more than one SG.
> >
> > Guatam,
> >
> > Given that:
> >
> >      'an' != 'one and only one'
> >
> >      'an' == 'at least one'
> >
> > there is no contradiction between the M3UA draft and the SCTP RFC,
> > (which, by the way, is no longer just a draft... :)
> >
> > --Brian
> >
> > [email-masked] wrote:                   (Thu, 05 Jul 2001
13:28:06)
> > >
> > >
> > >
> > > HI All,
> > >
> > >
> > >
> > > <snip> m3ua-06
> > >
> > > definition of Application Server Process (ASP) -
> > >
> > > .....An ASP contains an SCTP end- point and may be configured to
process
> > >       signalling
> > >
> > > traffic within more than one Application Server.
> > >
> > >
> > >
> > > Now Consider that the ASP connects to more than one SG, since the
definition
> > of
> > >       the ASP says
> > >
> > > that ASP contains "an" endpoint, it connects to both the SG's using
the
> _same_
> > >       sctp port and IP address
> > >
> > > combination.
> > >
> > >
> > >
> > > >But according to SCTP
> > >
> > >
> > >
> > > Definition of Endpoint ->
> > > SCTP endpoint: .....A transport address used by an SCTP endpoint must
not be
> > > used by another SCTP  endpoint.  In other words, a transport address
is
> unique
> > > to an
> > >       SCTP endpoint.
> > >
> > > Now we if go by the SCTP definition of Endpoint then we cannot have
the same
> > > transport address in more than
> > > one Endpoints. So the ASP should be represented by separate endpoints
for
> both
> > > the SG's.  But this would contradict
> > > the definition of ASP as given by the M3UA Draft.
> > >
> > > Which of the two drafts is correct....?
> > >
> > >
> > >
> > > Regards
> > > Gautam.
> > >
> >
> > --
> > 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]
> 
> 
> 
> ---
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 6 Jul 2001 02:35:12 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: workgroup status
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: harrier.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: harrier.mail.pas.earthlink.net [207.217.121.12]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Lyndon,

There are still rather significant issues with M3UA which have yet to be
addressed in a published draft.

Also, the M3UA-07 draft has hundreds of lines changed from the M3UA-06
draft.  Many of which were not discussed on the WG list.  In particular, a
fairly global changing of 'SG' to 'SGP' in much of the text has a
significant impact on interpretation and accuracy of the draft and a rather
drastic impact on implementation.  The differences between version 6 and
version 7 are not merely cosmetic and significant changes have been made.

Why do you believe that IESG review is appropriate at this time?

--Brian

Lyndon Ong wrote:                    (Thu, 05 Jul 2001 15:20:47)
>
> Folks,
> 
> An update on workgroup status:
> 
> -- we have tentatively been scheduled to meet on Tuesday afternoon
>    in London (Aug. 7th) for 1 hour.  Please send me an email if
>    you have a topic that you would like to discuss.
> 
> -- M3UA has finally been updated, once the document is on the
>    server I will ask for IESG review.
> 
> -- SCTP AS (yes, that's still around) has gotten further comments
>    from our A-Ds and will have to be revised and reissued.
> 
> -- we're getting closer to Last Call on M2UA, SUA and probably
>    M2PA, we'll see how much we can get through before London.
> 
> -- SCTP MIB was reissued as well.
> 
> Cheers,
> 
> L. Ong
> 

-- 
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]
Date: Fri, 6 Jul 2001 02:41:48 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Routing Key parameter
Reply-To: [email-masked]
Mail-Followup-To: sigtran <[email-masked]>
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: albatross.prod.itd.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: albatross.mail.pas.earthlink.net [207.217.120.120]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Maria,

Who would then police whether the appropriate local-RK-id was applied for
the given network appearance and the explicit values of, say, the SI (which
has national significance)?

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:   (Thu, 05 Jul 2001 11:48:39)

[snip]
> 
> I think a possible SOLUTION would be to have a 'local-RK-identifier' per 
> valid combination set, then invalid combinations could be avoided (e.g.
having
> a local-RK-identifier per SI would avoid having SSN for ISUP), definition
> is easier and more understandable and optional parameter dealing becomes
easier
> as well. 
> 
> On the other hand, it would mean that it may be needed more than one 
> 'local-RK-identifier' to be assigned to the same RC (then the name
'local-RK-id'
> wouldn't be the most appropiate...). This could be solved as well
considering, 
> for example, that all 'local-RK-ids' (maybe named 'routing subparameter
combination')
> within the same REG REQ message should be assigned to the same RC.
> 
> 
> Let me know if this make sense to you or I am messing up things.
> /MCruz
> 

-- 
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: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: workgroup status
Date: Fri, 6 Jul 2001 13:24:21 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,
   you say that "M3UA-07 draft has hundreds of lines changed from the
M3UA-06 draft", we are in crutial stage of desing and we are going for
implementation, when M3UA-07 is released, we might have a some/major rework
to make it compatible to 07.
   how are we going to take care of such issues or is there any solutions.
Thanks
Satish

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: 06 July 2001
13:05
To: sigtran
Subject: Re: workgroup status

Lyndon,

There are still rather significant issues with M3UA which have yet to be
addressed in a published draft.

Also, the M3UA-07 draft has hundreds of lines changed from the M3UA-06
draft.  Many of which were not discussed on the WG list.  In particular, a
fairly global changing of 'SG' to 'SGP' in much of the text has a
significant impact on interpretation and accuracy of the draft and a rather
drastic impact on implementation.  The differences between version 6 and
version 7 are not merely cosmetic and significant changes have been made.

Why do you believe that IESG review is appropriate at this time?

--Brian

Lyndon Ong wrote:                    (Thu, 05 Jul 2001 15:20:47)
>
> Folks,
>
> An update on workgroup status:
>
> -- we have tentatively been scheduled to meet on Tuesday afternoon
>    in London (Aug. 7th) for 1 hour.  Please send me an email if
>    you have a topic that you would like to discuss.
>
> -- M3UA has finally been updated, once the document is on the
>    server I will ask for IESG review.
>
> -- SCTP AS (yes, that's still around) has gotten further comments
>    from our A-Ds and will have to be revised and reissued.
>
> -- we're getting closer to Last Call on M2UA, SUA and probably
>    M2PA, we'll see how much we can get through before London.
>
> -- SCTP MIB was reissued as well.
>
> Cheers,
>
> L. Ong
>

--
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]
Date: Fri, 6 Jul 2001 03:13:47 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: workgroup status
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: snipe.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: snipe.mail.pas.earthlink.net [207.217.120.62]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Satish,

I think we are saying the same thing: M3UA-07 should be reviewed for
accuracy and impacts before moving it forward.

--Brian

Satish K wrote:                                 (Fri, 06 Jul 2001 13:24:21)
> Hi Brian,
>    you say that "M3UA-07 draft has hundreds of lines changed from the
> M3UA-06 draft", we are in crutial stage of desing and we are going for
> implementation, when M3UA-07 is released, we might have a some/major
rework
> to make it compatible to 07.
>    how are we going to take care of such issues or is there any solutions.
> Thanks
> Satish
> 

-- 
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: Schwarzbauer Hanns Juergen <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: workgroup status
Date: Fri, 6 Jul 2001 10:30:28 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: gorilla.mchh.siemens.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: gorilla.mchh.siemens.de [194.138.158.18]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings,

I can agree with this proposal.

HannsJuergen

> -----Original Message-----
> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Friday, July 06, 2001 10:14 AM
> To:	sigtran
> Subject:	Re: workgroup status
> 
> Satish,
> 
> I think we are saying the same thing: M3UA-07 should be reviewed
> for accuracy and impacts before moving it forward.
> 
> --Brian
> 
> Satish K wrote:                                 (Fri, 06 Jul 2001
13:24:21)
> > Hi Brian,
> >    you say that "M3UA-07 draft has hundreds of lines changed from the
> > M3UA-06 draft", we are in crutial stage of desing and we are going for
> > implementation, when M3UA-07 is released, we might have a some/major
rework
> > to make it compatible to 07.
> >    how are we going to take care of such issues or is there any
solutions.
> > Thanks
> > Satish
> > 
> 
> -- 
> 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: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SUA6 : SUA management procedures
Date: Fri, 6 Jul 2001 10:32:52 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades9.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: viap119.atea.be [194.78.143.119]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Remember we were extending the scope of the SSNM messages (DUNA, ...) to the
all-IP case as well. Similar to SS7 networks, you will have mated SRPs (SUA
Relay Points, equipped with the AMF) in the IP based network.

This case would be particularly interesting for 3G (3rd generation) Mobile
Networks (UMTS if you want) based on SCTP/IP transport. Routing between
PLMNs (Public Land Mobile Networks) would require either mated SRPs (both
interworking networks are 3G, but they don't want immediate SCTP
associations between their nodes => SRP must act as firewall for
accounting/screening purposes) or SGs (interworking with existing 2G TDM
based networks).

So, if MTP3 generates a TFR when a linkset goes down, why can't SUA generate
a DRST when an association goes down, but a mated SUA node exists ? That was
what I was trying to get at. Also, reception of TFR at the SG won't lead to
anything at the moment, since the SCCP is not informed of this by an
MTP-primitive. So SUA won't hear about it either.

Remark that similarly, no SCCP management messages are sent by the SG when
it receives DRST, there is no need to.

Hmm, I guess this will trigger a new thread so I changed the mail Subject
...

Further comments, see below !

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: vrijdag 6
juli 2001 9:09
To: sigtran
Subject: Re: SUA6: SG Relay Problems

Gery,

Please see comments below...

Verwimp Gery wrote:                            (Thu, 05 Jul 2001 15:20:17)
> Hello all,
> 
> Just a summary of comments on the earlier points.
> 
> 1. Reassembly of XUDT at SG, into CLDT towards SUA-node.
> 
> The difference with SCCP procedures here is that in SCCP, reassembly is
> strictly performed in the end-node (also out-of-sequence detection), while
> this is not the case here (ASP does not do this anymore). Ok, the major
part
> of the problem is resolved by the fact that all segments use protocol
class
> 1, but for link/route failure cases we need this extra procedure in  the
> mated SGs. It isn't needed in mated STPs.

I don't understand what you are getting at here...  What is the difference
between a mated SG and a mated STP, and how is it a problem for mated SGs
which is not already handled in the SS7 context?

[GV] : SS7 doesn't specify reassembly of XUDTs at an STP before sending
(let's say) LUDT to the SEP. Now we're doing it at an SG before sending a
big CLDT to the ASP.

> 
> 4. Use of DRST : think this needs a figure for proper explanation ;) See
> attach; how y'all got powerpoint ;))
> 

I can't imagine what you are trying to get at with these diagrams and
scenarios.  One of the cases that I was concerned about is as follows:

                   +-----+       +-----+
                   |     |       |     |
                  X| STP +-------+ SG1 |\
                 X |  A  |       |     | \
        /-----\ X  +-----+       +-----+  \ /-----\
        |     |X      |                    \|     |
        | SEP |       |                     | ASP |
        |     |\      |                    /|     |
        \-----/ \  +-----+       +-----+  / \-----\
                 \ |     |       |     | /
                  \| STP +-------+ SG2 |/
                   |  B  |       |     |
                   +-----+       +-----+

    Signalling link set between SEP and STP-A fails.  STP-A sends
    TFR to SG1.  SG1 needs to send DRST to ASP to let ASP know to
    stop (if possible) routing messages to SEP via SG1.

    When an SG sends TFR to the SS7 network should be left up to the
    implementation.

[GV] : SG1/2 would be connected to an STP-pair, via a pair of A-,B- or D-
linksets (Telcordia terminology again). So there's links missing between SG1
and STP B, and between SG2 and STP A. And I'd recommend an SCTP association
between the 2 SGs.
But let's stick to this architecture : currently, SCCP is not informed of
restriction by MTP-primitives. But if there really is no other route from
SG1 to SEP than via STP A, we'd have to invent a new MTP-primitive
(MTP_STATUS (restricted, SEP)) or whatever trick, to make SG1 send DRST to
ASP.
Hm, possible I guess, and it also would apply to my case, when the linkset
from SG1 to STP B already had failed ...
=================

    The SRPs in your diagrams (what is an SRP anyway?) appear to be
    performing only the function of an STP and I see no apparent
    reason why one would need them.  Why are they there?

[GV] : see above.
=================

> 
> 3rd Event : ASPz failure
> 
> Result: same reaction as for ASP isolation; SRP1 sends DUNA(z) to SRP2
> also, since there was no restriction first.
> Of course, ASPx is out and doesn't receive DUNA(z).
> 
> Anything missing/other scenario's ?
> 
> 5. Further SUA management procedures (chapter 4.3.3 in the draft ?)
> 
> 5.1 At the receiving node
> 
> After reception of DUNA, SCON or DRST, the receiving node may start an
audit
> procedure to monitor the status of the affected destination (identified by
> routing context). To this end, a DAUD message may be sent periodically for
a
> certain time interval, or until a DAVA message is received, whichever
comes
> first. The time interval should be restarted with each new reception of
> DUNA, SCON or DRST.

I don't think that this will work well with similar procedures at MTP3 in
the SS7 network.  The SG itself does not really know the availability or
unavailability of signalling points because the messages which change status
may be lost.  The ASP must be made congizant of MTP restart procedures as
well as using N-PCSTATE semantics for these messages.

[GV] : The interworking with existing MTP3 procedures is another issue. At
the SG, there's SCCP-SUA interworking, not MTP3-SUA interworking. And if the
SG doesn't know the (real) status of a SEP, the ASP is certainly not going
to know ...
We might use a routing context in the DUNA, ... messages (SS7 interworking
or all-IP case); it's always the trouble with management messages : if the
ASP doesn't recognize the affected destination somehow by address info or
routing context, the have no use at all.
===================

> 
> Although congestion and restriction information is orthogonal and must be
> maintained/monitored separately, this information is overruled by DUNA,
> which signals unavailability.
> 
This does not appear to be compatible with N-PCSTATE semantics.

[GV] : Hm, agreed, in SCCP the SCCP-user is not informed of restriction
(because SCCP is not informed). This doesn't preclude the use of DRST and
maintenance of restriction info purely on the SUA-level. Or we might enhance
N-PCSTATE semantics.

> When the time interval expires and no new status information is received,
> the affected destination is considered available/uncongested/unrestricted
> again.

This is incompatible with both MTP procedures as well as N-PCSTATE
semantics.

[GV] : these are purely SUA-procedures, they don't need to be compatible
with the MTP ones, or ?

> 
> 5.2 At the sending node
> 
> The node which detects ASP status changes, either via ASP management or
SCTP
> notifications, shall inform it's concerned neighbours with the appropriate
> SUA management message (DUNA, SCON, DRST).

Because an SUA ASP can not be considered to be equipped with an MTP transfer
function, I see no need for it ever to generate a DRST.

[GV] : see above, use of SRPs.

> 
> Both the response method and the audit procedure must be supported :

What is the rationale behind forcing an implementation to support both
procedures?  I don't see a need for the "MUST" on both procedures.

[GV] : Too strong. Let's say "... may be used."

> 
> - response method : for each n messages (n e.g. equal 8) received over an
> SCTP association destined for the affected destination a DUNA, SCON or
DRST
> message shall be sent back.

I don't see the need for this procedure.  Also, I don't see the need for
requiring this specific algorithm on the implementation.  What is you
justification for this procedure?

[GV] : Status information may have been lost, or for some other reason an
ASP may start sending traffic (via an SRP) to an
unavailable/congested/restricted destination.

> 
> - audit procedure : the node receiving a DAUD shall reply with DAVA, DUNA,
> SCON or DRST depending on the status of the affected destination.
> 
> Remark: when an affected destination is both congested and restricted,
both
> SCON and DRST shall be sent back in either method.

This should be made consistent with M3UA/MTP.

[GV] : I'll take a look there.

> =========================
> 

-- 
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: "Alf Heidermark (UAB)" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: workgroup status
Date: Fri, 6 Jul 2001 12:20:49 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: penguin-ext.wise.edt.ericsson.se [194.237.142.110]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Satish
But is their a requirement that version 7 shall be compatible with an
earlier version. Looking on the treatment of SCTP there does not seem to be
any backward compatible requirements, why is it needed for this update.

-----Original Message-----
From: Satish K [mailto:[email-masked]] Sent: den 6 juli 2001 09:54
To: sigtran
Subject: RE: workgroup status

Hi Brian,
   you say that "M3UA-07 draft has hundreds of lines changed from the
M3UA-06 draft", we are in crutial stage of desing and we are going for
implementation, when M3UA-07 is released, we might have a some/major rework
to make it compatible to 07.
   how are we going to take care of such issues or is there any solutions.
Thanks
Satish

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: 06 July 2001
13:05
To: sigtran
Subject: Re: workgroup status

Lyndon,

There are still rather significant issues with M3UA which have yet to be
addressed in a published draft.

Also, the M3UA-07 draft has hundreds of lines changed from the M3UA-06
draft.  Many of which were not discussed on the WG list.  In particular, a
fairly global changing of 'SG' to 'SGP' in much of the text has a
significant impact on interpretation and accuracy of the draft and a rather
drastic impact on implementation.  The differences between version 6 and
version 7 are not merely cosmetic and significant changes have been made.

Why do you believe that IESG review is appropriate at this time?

--Brian

Lyndon Ong wrote:                    (Thu, 05 Jul 2001 15:20:47)
>
> Folks,
>
> An update on workgroup status:
>
> -- we have tentatively been scheduled to meet on Tuesday afternoon
>    in London (Aug. 7th) for 1 hour.  Please send me an email if
>    you have a topic that you would like to discuss.
>
> -- M3UA has finally been updated, once the document is on the
>    server I will ask for IESG review.
>
> -- SCTP AS (yes, that's still around) has gotten further comments
>    from our A-Ds and will have to be revised and reissued.
>
> -- we're getting closer to Last Call on M2UA, SUA and probably
>    M2PA, we'll see how much we can get through before London.
>
> -- SCTP MIB was reissued as well.
>
> Cheers,
>
> L. Ong
>

--
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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Original-To: IETF-Announce:;;@cnri.reston.va.us@zrtps0jn
PP-Warning: Parse error in original version of preceding To line
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sigtran-m3ua-07.txt
Date: Fri, 06 Jul 2001 06:52:34 -0400
Sender: [email-masked]
X-SMTP-HELO: ietf.org
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
To: "sigtran" <[email-masked]>

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		: SS7 MTP3-User Adaptation Layer (M3UA)
	Author(s)	: G. Sidebottom et al.
	Filename	: draft-ietf-sigtran-m3ua-07.txt
	Pages		: 100
	Date		: 05-Jul-01
	
This Internet Draft defines a protocol for supporting the transport of any
SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol.  Also, provision is
made for protocol elements that enable a seamless operation of the MTP3-User
peers in the SS7 and IP domains. This protocol would be used between a
Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident
Database.  It is assumed that the SG receives SS7 signalling over a standard
SS7 interface using the SS7 Message Transfer Part (MTP) to provide
transport.

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

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-m3ua-07.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-m3ua-07.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.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sigtran-m3ua-07.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-sigtran-m3ua-07.txt> ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Tuexen Michael <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: workgroup status
Date: Fri, 6 Jul 2001 13:05:38 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: gorilla.mchh.siemens.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: gorilla.mchh.siemens.de [194.138.158.18]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Dear all,

my understanding is that there is NO compatibility requirements between
different  version of a draft. An ID is 'work in progress'.

Later on, when we have an RFC for M3UA, and we might work on a second
version of M3UA we might have to deal with backwards compatibility, but not
right now.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210 Siemens AG        Fax:    +49 89
722 48212 ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	Alf Heidermark (UAB) [SMTP:[email-masked]]
> Sent:	Friday, July 06, 2001 12:21 PM
> To:	sigtran
> Subject:	RE: workgroup status
> 
> Satish
> But is their a requirement that version 7 shall be compatible with an
earlier version. Looking on the treatment of SCTP there does not seem to be
any backward compatible requirements, why is it needed for this update.
> 
>  
> 
> -----Original Message-----
> From: Satish K [mailto:[email-masked]]
> Sent: den 6 juli 2001 09:54
> To: sigtran
> Subject: RE: workgroup status
> 
> 
> Hi Brian,
>    you say that "M3UA-07 draft has hundreds of lines changed from the
> M3UA-06 draft", we are in crutial stage of desing and we are going for
> implementation, when M3UA-07 is released, we might have a some/major
rework
> to make it compatible to 07.
>    how are we going to take care of such issues or is there any solutions.
> Thanks
> Satish
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 06 July 2001 13:05
> To: sigtran
> Subject: Re: workgroup status
> 
> 
> Lyndon,
> 
> There are still rather significant issues with M3UA which have
> yet to be addressed in a published draft.
> 
> Also, the M3UA-07 draft has hundreds of lines changed from the
> M3UA-06 draft.  Many of which were not discussed on the WG list.  In
> particular, a fairly global changing of 'SG' to 'SGP' in much of the
> text has a significant impact on interpretation and accuracy of the
> draft and a rather drastic impact on implementation.  The
> differences between version 6 and version 7 are not merely cosmetic
> and significant changes have been made.
> 
> Why do you believe that IESG review is appropriate at this time?
> 
> --Brian
> 
> Lyndon Ong wrote:                    (Thu, 05 Jul 2001 15:20:47)
> >
> > Folks,
> >
> > An update on workgroup status:
> >
> > -- we have tentatively been scheduled to meet on Tuesday afternoon
> >    in London (Aug. 7th) for 1 hour.  Please send me an email if
> >    you have a topic that you would like to discuss.
> >
> > -- M3UA has finally been updated, once the document is on the
> >    server I will ask for IESG review.
> >
> > -- SCTP AS (yes, that's still around) has gotten further comments
> >    from our A-Ds and will have to be revised and reissued.
> >
> > -- we're getting closer to Last Call on M2UA, SUA and probably
> >    M2PA, we'll see how much we can get through before London.
> >
> > -- SCTP MIB was reissued as well.
> >
> > Cheers,
> >
> > L. Ong
> >
> 
> --
> 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]
> 
> 
> ---
> 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: "Mangalpally, Narsimuloo [WBNG:WT16:SMTPPART]" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: workgroup status
Date: Fri, 6 Jul 2001 17:44:37 +0530
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Lyndon,

Please include DUA (DPNSS UA). 
As discussed earlier with you, now we have Ken from Cisco as co-author of
this draft.
I will be submitting latest version of this draft soon.
Anil Kumar will be attending this meeting to present DUA. 

Thanks,
Narsim

--------------------------------------------------------------------------
Narsimuloo Mangalpally
Project Manager, Wipro Nortel PCN lab, Telecom & Inter-networking Solutions,
Wipro Technologies Off: K-312, 5th Block, Koramangala, Bangalore - 560 098.
INDIA ?	Tel:  +91 (0)80 5538301 Ext. 2153      Res: +91 (0)80 5523610 Email:
[email-masked]        ??ESN:  872 8858 www.wipro.com The
world's First SEI CMM Level 5 Software Services Company
--------------------------------------------------------------------------

 -----Original Message-----
From: 	Lyndon Ong [mailto:[email-masked]] Sent:	Friday, July
06, 2001 3:51 AM
To:	sigtran
Subject:	workgroup status

Folks,

An update on workgroup status:

-- we have tentatively been scheduled to meet on Tuesday afternoon in London
(Aug. 7th) for 1 hour.  Please send me an email if you have a topic that you
would like to discuss.

-- M3UA has finally been updated, once the document is on the server I will
ask for IESG review.

-- SCTP AS (yes, that's still around) has gotten further comments from our
A-Ds and will have to be revised and reissued.

-- we're getting closer to Last Call on M2UA, SUA and probably M2PA, we'll
see how much we can get through before London.

-- SCTP MIB was reissued as well.

Cheers,

L. Ong

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
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]
To: "sigtran" <[email-masked]>
Subject: RE: SUA6: SG Relay Problems
Date: Fri, 6 Jul 2001 15:41:33 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x4.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [131.228.20.27]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> I don't understand what you are getting at here...  What is the
> difference between a mated SG and a mated STP, and how is it a
> problem for mated SGs which is not already handled in the SS7
> context?

I don't think it is different. A note might be useful to add, however.
Even you were confused at first ...
 
> > 
> > 2/3. Routing context : for SUA-07, I'd propose to use the 
> > Routing Context instead of Network Appearance consistently as 
> > optional parameter in all SUA-CL and -CO messages. During Final 
> > Call, we can put the dots on the i.
> 
> I think that this would be a good start.

Will put this on my things to add.

> > 4. Use of DRST : think this needs a figure for proper 
> > explanation ;) See attach; 
> I can't imagine what you are trying to get at with these diagrams
> and scenarios.  One of the cases that I was concerned about is as
> follows:
> 
>                    +-----+       +-----+
>                    |     |       |     |
>                   X| STP +-------+ SG1 |\
>                  X |  A  |       |     | \
>         /-----\ X  +-----+       +-----+  \ /-----\
>         |     |X      |                    \|     |
>         | SEP |       |                     | ASP |
>         |     |\      |                    /|     |
>         \-----/ \  +-----+       +-----+  / \-----\
>                  \ |     |       |     | /
>                   \| STP +-------+ SG2 |/
>                    |  B  |       |     |
>                    +-----+       +-----+
> 
>     Signalling link set between SEP and STP-A fails.  STP-A sends
>     TFR to SG1.  SG1 needs to send DRST to ASP to let ASP know to
>     stop (if possible) routing messages to SEP via SG1.
> 
>     When an SG sends TFR to the SS7 network should be left up to the
>     implementation.
> 
>     The SRPs in your diagrams (what is an SRP anyway?) appear to be
>     performing only the function of an STP and I see no apparent
>     reason why one would need them.  Why are they there?

SRP = IP-STP.  Gery's scenarios might be overly complex.   

Let me try to make sure the solution covers your scenario above.
Hopefully that should be enough!

> > 5. Further SUA management procedures (chapter 4.3.3 in the draft ?)

I'll review these and see what is needed.  Specific text is always
appreciated!

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Kevin McCandless <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: workgroup status
Date: Fri, 6 Jul 2001 08:40:57 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: rainier.illuminet.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.116.20.100]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Lyndon:

A detailed read out of all the Sigtran Protocols status and major issues
would be great.  I noticed you did not mention TUA.  

Thanks,

Kevin

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]] Sent: Thursday, July 05,
2001 5:21 PM
To: sigtran
Subject: workgroup status

Folks,

An update on workgroup status:

-- we have tentatively been scheduled to meet on Tuesday afternoon in London
(Aug. 7th) for 1 hour.  Please send me an email if you have a topic that you
would like to discuss.

-- M3UA has finally been updated, once the document is on the server I will
ask for IESG review.

-- SCTP AS (yes, that's still around) has gotten further comments from our
A-Ds and will have to be revised and reissued.

-- we're getting closer to Last Call on M2UA, SUA and probably M2PA, we'll
see how much we can get through before London.

-- SCTP MIB was reissued as well.

Cheers,

L. Ong

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
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]
To: "sigtran" <[email-masked]>
Date: Fri, 06 Jul 2001 09:37:05 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Expiredinmiddle: true
X-Mailer: MailCity Service
Subject: RE: workgroup status
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

Michael is perfectly correct, M3UA is still a draft, not an approved
document of IETF.  BTW, regarding the status of SCTP, there has been no
final decision to alter the checksum, and backwards compatibility has
certainly been an issue in the discussion - however, this is now in the TSV
Working Group and not this one.

We do need to bring M3UA to conclusion.  I don't see anything that should
prevent the protocol from proceeding forward (esp. given that v6 was baked
off without finding major problems).  It is my understanding that the
changes in the current version were made in response to comments on the list
based on v6.  However, I will hold off until Wednesday to let people have a
look at the new version and comment if they see a major issue.   

BTW, some of the concerns I believe are because some comments have been
coming in over an extended period of time, rather than being limited to the
2 week review period.  This was my fault for not having run a cleaner Last
Call, and I will try to avoid this in future.

Cheers,

L. Ong

--

On Fri, 6 Jul 2001 13:05:38    Tuexen Michael wrote:
>Dear all,
>
>my understanding is that there is NO compatibility requirements between
different  version of a draft. An ID is 'work in progress'.
>
>Later on, when we have an RFC for M3UA, and we might work on a second
version of M3UA we might have to deal with backwards compatibility, but not
right now.
>
>Best regards
>Michael
>
>Michael Tuexen    Tel.:   +49 89 722 47210
>Siemens AG        Fax:    +49 89 722 48212
>ICN WN CS SE 5    E-mail: [email-masked]
>
>> -----Original Message-----
>> From:	Alf Heidermark (UAB) [SMTP:[email-masked]]
>> Sent:	Friday, July 06, 2001 12:21 PM
>> To:	sigtran
>> Subject:	RE: workgroup status
>> 
>> Satish
>> But is their a requirement that version 7 shall be compatible with an
earlier version. Looking on the treatment of SCTP there does not seem to be
any backward compatible requirements, why is it needed for this update.
>> 
>>  
>> 
>> -----Original Message-----
>> From: Satish K [mailto:[email-masked]]
>> Sent: den 6 juli 2001 09:54
>> To: sigtran
>> Subject: RE: workgroup status
>> 
>> 
>> Hi Brian,
>>    you say that "M3UA-07 draft has hundreds of lines changed from the
>> M3UA-06 draft", we are in crutial stage of desing and we are going for
>> implementation, when M3UA-07 is released, we might have a some/major
rework
>> to make it compatible to 07.
>>    how are we going to take care of such issues or is there any
solutions.
>> Thanks
>> Satish
>> 
>> -----Original Message-----
>> From: Brian F. G. Bidulock [mailto:[email-masked]]
>> Sent: 06 July 2001 13:05
>> To: sigtran
>> Subject: Re: workgroup status
>> 
>> 
>> Lyndon,
>> 
>> There are still rather significant issues with M3UA which have
>> yet to be addressed in a published draft.
>> 
>> Also, the M3UA-07 draft has hundreds of lines changed from the
>> M3UA-06 draft.  Many of which were not discussed on the WG list.  In
>> particular, a fairly global changing of 'SG' to 'SGP' in much of the
>> text has a significant impact on interpretation and accuracy of the
>> draft and a rather drastic impact on implementation.  The
>> differences between version 6 and version 7 are not merely cosmetic
>> and significant changes have been made.
>> 
>> Why do you believe that IESG review is appropriate at this time?
>> 
>> --Brian
>> 
>> Lyndon Ong wrote:                    (Thu, 05 Jul 2001 15:20:47)
>> >
>> > Folks,
>> >
>> > An update on workgroup status:
>> >
>> > -- we have tentatively been scheduled to meet on Tuesday afternoon
>> >    in London (Aug. 7th) for 1 hour.  Please send me an email if
>> >    you have a topic that you would like to discuss.
>> >
>> > -- M3UA has finally been updated, once the document is on the
>> >    server I will ask for IESG review.
>> >
>> > -- SCTP AS (yes, that's still around) has gotten further comments
>> >    from our A-Ds and will have to be revised and reissued.
>> >
>> > -- we're getting closer to Last Call on M2UA, SUA and probably
>> >    M2PA, we'll see how much we can get through before London.
>> >
>> > -- SCTP MIB was reissued as well.
>> >
>> > Cheers,
>> >
>> > L. Ong
>> >
>> 
>> --
>> 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]
>> 
>> 
>> ---
>> 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]

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: workgroup status
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Date: Fri, 6 Jul 2001 12:45:42 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/06/2001 09:48:18 AM, Serialize 
             complete at 07/06/2001 09:48:18 AM
X-SMTP-HELO: radisys.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail-gw.radisys.com [206.102.10.35]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Lyndon,

The M3UA version baked off was v5, not v6.

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

Lyndon Ong <[email-masked]>
07/06/01 12:37 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        RE: workgroup status

Folks,

Michael is perfectly correct, M3UA is still a draft, not an approved
document of IETF.  BTW, regarding the status of SCTP, there has been no
final decision to alter the checksum, and backwards compatibility has
certainly been an issue in the discussion - however, this is now in the TSV
Working Group and not this one.

We do need to bring M3UA to conclusion.  I don't see anything that should
prevent the protocol from proceeding forward (esp. given that v6 was baked
off without finding major problems).  It is my understanding that the
changes in the current version were made in response to comments on the list
based on v6.  However, I will hold off until Wednesday to let people have a
look at the new version and comment if they see a major issue. 

BTW, some of the concerns I believe are because some comments have been
coming in over an extended period of time, rather than being limited to the
2 week review period.  This was my fault for not having run a cleaner Last
Call, and I will try to avoid this in future.

Cheers,

L. Ong

--

On Fri, 6 Jul 2001 13:05:38    Tuexen Michael wrote:
>Dear all,
>
>my understanding is that there is NO compatibility requirements between
different  version of a draft. An ID is 'work in progress'.
>
>Later on, when we have an RFC for M3UA, and we might work on a second
version of M3UA we might have to deal with backwards compatibility, but not
right now.
>
>Best regards
>Michael
>
>Michael Tuexen    Tel.:   +49 89 722 47210
>Siemens AG        Fax:    +49 89 722 48212
>ICN WN CS SE 5    E-mail: [email-masked]
>
>> -----Original Message-----
>> From:                 Alf Heidermark (UAB)
[SMTP:[email-masked]]
>> Sent:                 Friday, July 06, 2001 12:21 PM
>> To:           sigtran
>> Subject:              RE: workgroup status
>> 
>> Satish
>> But is their a requirement that version 7 shall be compatible with an
earlier version. Looking on the treatment of SCTP there does not seem to be
any backward compatible requirements, why is it needed for this update.
>> 
>> 
>> 
>> -----Original Message-----
>> From: Satish K [mailto:[email-masked]]
>> Sent: den 6 juli 2001 09:54
>> To: sigtran
>> Subject: RE: workgroup status
>> 
>> 
>> Hi Brian,
>>    you say that "M3UA-07 draft has hundreds of lines changed from the
>> M3UA-06 draft", we are in crutial stage of desing and we are going for
>> implementation, when M3UA-07 is released, we might have a some/major
rework
>> to make it compatible to 07.
>>    how are we going to take care of such issues or is there any
solutions.
>> Thanks
>> Satish
>> 
>> -----Original Message-----
>> From: Brian F. G. Bidulock [mailto:[email-masked]]
>> Sent: 06 July 2001 13:05
>> To: sigtran
>> Subject: Re: workgroup status
>> 
>> 
>> Lyndon,
>> 
>> There are still rather significant issues with M3UA which have
>> yet to be addressed in a published draft.
>> 
>> Also, the M3UA-07 draft has hundreds of lines changed from the
>> M3UA-06 draft.  Many of which were not discussed on the WG list.  In
>> particular, a fairly global changing of 'SG' to 'SGP' in much of the
>> text has a significant impact on interpretation and accuracy of the
>> draft and a rather drastic impact on implementation.  The
>> differences between version 6 and version 7 are not merely cosmetic
>> and significant changes have been made.
>> 
>> Why do you believe that IESG review is appropriate at this time?
>> 
>> --Brian
>> 
>> Lyndon Ong wrote:                    (Thu, 05 Jul 2001 15:20:47)
>> >
>> > Folks,
>> >
>> > An update on workgroup status:
>> >
>> > -- we have tentatively been scheduled to meet on Tuesday afternoon
>> >    in London (Aug. 7th) for 1 hour.  Please send me an email if
>> >    you have a topic that you would like to discuss.
>> >
>> > -- M3UA has finally been updated, once the document is on the
>> >    server I will ask for IESG review.
>> >
>> > -- SCTP AS (yes, that's still around) has gotten further comments
>> >    from our A-Ds and will have to be revised and reissued.
>> >
>> > -- we're getting closer to Last Call on M2UA, SUA and probably
>> >    M2PA, we'll see how much we can get through before London.
>> >
>> > -- SCTP MIB was reissued as well.
>> >
>> > Cheers,
>> >
>> > L. Ong
>> >
>> 
>> --
>> 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]
>> 
>> 
>> ---
>> 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]

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
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]
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Ride the Wave of Success!!/FREE MEMBERSHIP!!!
Sender: [email-masked]
Date: Sat, 7 Jul 2001 23:28:13 -0400
X-SMTP-HELO: yourwebsite.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: cd-179-62.ra30.dc.capu.net [64.50.179.62]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

JOIN NOW FOR FREE!!!
          
SERIOUS ONLINE INCOME:

 NO PRODUCTS TO SELL, NO MEETING TO ATTEND, NO MONTHLY QUOTAS

We are a  FOUR 4 YEAR OLD INTERNET BUSINESS AND GROWING VERY FAST. WE HAD
OVER 60,000 VIPS SIGNUP COMPANY WIDE IN THE MONTH OF JUNE 2001. SEE WHY
THOUSANDS OF PEOPLE FROM ALL OVER THE WORLD ARE JOINING US AT RECORD RATES.;

    THE  MEMBERSHIP IS FREE at. 
                             
http://onlineprofits.50megs.com.    . Enter your first and last name and
email address.

Afterwards you will start recieving various emails about company and the
business opportunity.  Also, you will become a  FREE MEMBER  and you can
START SHOPPING  from at least 70 brand name online stores and BE ENTERED in
our monthly $100 shopping spree!.  Take your time and review our company's
benefits and opportunities.
       . GUARANTEED  minimum commission every month
       . you can get 200 members a month added to you downline
       . Free Software
       . and a strong team support

Now remember anybody that signs up after you will be in your downline. This
is very important if you want join our company  and get a monthly check.
Don't pass this one up. 
GET YOUR FREE MEMBERSHIP AT:  
http://onlineprofits.50megs.com --- type in your name and email address and
hit the submit botton.
We will talk soon,
        
GIVIE IT A TRY, YOU HAVE NOTHING TO LOSE AND POSSIBLE A LOT TO GAIN.  

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Antonio Roque-Alvarez (ECE)" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Comments on M3UA MIB
Date: Mon, 9 Jul 2001 13:53:04 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.237.142.110]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello,

Thank you very much for your comments.
Please, find answers inline.

Regards,
Antonio

-----Original Message-----
From: Srivats P. [mailto:[email-masked]] Sent: Friday, June 29, 2001
9:32 AM
To: sigtran
Subject: Comments on M3UA MIB

Antonio,

I have some comments on the M3UA MIB Draft ver 01 -

1. Section 3.1.2.3 Signaling Process Table - Para 4 "Several SP will
correspond to one SP Endpoint. They will be linked by the Association Id."
I don't understand what you want to say by the above statement

[Antonio] What I try to say is that there may be more than one entry in the
table with the same AssocId ( that's the common link ). All this entries are
differentiated by the AppId which the SP is serving.

I will rephrase the hold chapter:

"Defines data related to a Signaling Process, identified by the Association
ID of the association established to that remote Endpoint where the SP is
running, and the Logical Application ID which the SP is serving.

A Signaling Process is a process instance that uses M3UA to communicate with
other signaling process. An ASP, an SGP and an IPSP are all signaling
processes.

As a SP can maintain different states and traffic handling modes for every
LApp it is serving, i.e. The ASP_1 may be ASP-ACTIVE(LOAD-SHARING) for AS_1,
ASP-INACTIVE for AS_2 and ASP-ACTIVE(OVER-RIDE) for AS_3. Then, one entry
will be created in this table per every combination of AS ID and Association
ID.

All the entries corresponding to the same SP running in an specific Endpoint
will have a common link, the Association Id."

2. Section 3.1.2.4 Signaling Process Endpoint Table - Para 6 "The main table
also contains statistics data related to the M3UA messaging exchanged
through that association between the Signaling Processes that hold the
association."
This has been moved to another table.

[Antonio] OK, removed

3. Section 3.1.2.5 Signaling Process Endpoint Statistics Table As per the
object definition for this table, the following fields need to be included
in this table - m3uaAppId and m3uaSpEpId Remove m3uaSpEpRowStatus.

[Antonio] You are right, indexes were missing, but SPE Table is indexed by
SPE ID and Assoc ID.
OK, removing m3uaSpEpRowStatus.

I have a question here. Do you want to maintain statistics on a per AS - ASP
basis ? In that case how do you propose to maitain statistics for messages
which are not related to a particular AS such as ASPUP, ASPDN etc. ?
Or should it be only on ASP basis, instead of AS - ASP ?

[Antonio] No, I don't want to maintain statistics on a per AS(App) - ASP(SP)
basis. I just want to maintain statistics on a per ASP(SP) basis, that's why
the main group if statistics is maintained in the SPE table. An SPE
identifies the SP that is running on it.
Statistics related to AS(App) are maintained in App Table. Currently there
is only one defined: Number of Times an App is unreachable ( because it is
DOWN ).

4. Section 3.1.2.6 Routing Table
What about "Routing Context" ? Or do you propose to use m3uaPeerAppId as the
routing context ?

[Antonio] I just wanted to remark that the result of the routing is an
Application ID, that is the same as the Routing Context. That makes me think
about changing all the references to "Logical Application" by "Routing
Context". Then, we would have:

- "RC Table" instead of "Logical Application Table".
- An entry in Signaling Process table would be indexed by AssocId and the
RcId which the SP is serving.

5. Section 3.1.2.6 Network Appearance Table Duplicate Section No., Add
m3uaNaRowStatus

[Antonio] OK, done.

6. Section 3.1.2.7.2 Local and Remote IP Address Tables I suggest using
m3uaSpEpId instead of m3uaAssocId as the index.

[Antonio] Could you elaborate on this a little more, please.

7. Object Definition of m3uaMaxStreamInbound Should it have a MAX-ACCESS of
"read-write" or "read-only" ?
Secondly the SCTP MIB already has this object, and while accepting incoming
associations, SCTP uses its own value rather than M3UA's value.

[Antonio] When SCTP is initialized, M3UA will have to provide a value to
SCTP. This is why I thought it should be configured here.
What about the case where the value configured in SCTP is bigger than the
value wanted by the user, M3UA in this case.

8. Object Definition of m3uaSpEpEntry
Index should not include "m3uaAppId"

[Antonio] Yes, you are right. This was already fixed in new version. It is
m3uaSpEpAssocId instead of m3uaAppId

9. Object Definition of m3uaSpEpStatRowStatus Delete definition as all
entries in this table are "read-only"

[Antonio] OK, done.

10. Object Definition of m3uaRoutingTable As the object is currently
defined, this cannot be used at at a ASP M3UA. A Routing Key at an ASP would
be for the peer Logical Application ie. SG. Thus, only the DPC component of
routing key would be used, everything else would be null.
But a DPC may be accessible to ASP via multiple SGs. But the table cannot
take multiple rows becoz that would lead to duplicate routing keys which is
the index for the table.

[Antonio] That's right. Then...
The result of the routing table would be a ResultSet each containing one or
more AppIds and a priority for every one. The routing table at SGP will only
allow to add one RC/App ID per ResultSet.

This means that a ResultSet Table must be added to the mib.

Any comments on that??

11. Typos -
-Date on Page 1. Should be May 23, 2001 -Abstract on Page 1 - Para 2. Should
be M3UA -Section 1. Introduction - Para 3. Should be M3UA -Object Definition
of "LOGICAL APPLICATION TABLE" : Change "Application Server" to "Logical
Application" and "AS" to "App"

[Antonio] OK, done

Thank you very much again and sorry for the late response.

Regards,
Srivats P.

---
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]
Date: Mon, 9 Jul 2001 18:9:7 +0500
From: "Srivats P." <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: M3UA Changes : 6 vs 7
Organization: Mercury Corporation, India
X-mailer: FoxMail 2.1 [en]
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Could you send over a summary of the changes between ver 6 and ver 7 ?

A MS-Word "comparison" document might also be useful. If I remember
correctly, you once offerred something similar ...

Regards,
Srivats P.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Diff between M3UA 6 and 7
Date: Mon, 9 Jul 2001 18:59:25 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,
  Can any one please tell me the difference between M3UA draft ver 6 and ver
7.
Thanks
Satish

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "BAND,RICHARD (HP-France,ex1)" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UAv7 comments
Date: Mon, 9 Jul 2001 15:41:53 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: gremg1.net.external.hp.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [192.6.111.73]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello all, 

Please consider the following comments on the M3UAv7 draft:

1. Transaction ID in Routing Key.
In paragraph 1.4.2.1, the TCAP Transaction ID is mentioned as one of the
MTP3-user specific fields that could be used in a routin key. However, in
the description of the Routing Key format on page 48, the TCAP Transaction
ID is not included. Could you please add it to the RK format?

2. OPC Masks in Routing Key.
In the Routing Key format on page 48, the mask for OPC entries in the OPC
list is always set to 0. Why not use masks to indicate e.g. that I want to
receive all traffic from a given cluster in an ANSI network?

3. Message Distribution at ASP and SGP: Although paragraphs 1.4.2.4 and
1.4.2.5 are dedicated to message distribution function, parapgraps 1.4.4.2
and 1.4.7 contain additional information on msg distribution w.r.t.
mis-sequencing. It might be a good idea to regroup all information in
paragraphs 1.4.2.4 and 1.4.2.5.
Also, in paragraph 4.1.1, message distribution is only mentioned in the
direction SGP to ASP, not the other way around.
Finally, would you consider including local congestion at the ASP in the
message distribution function at the SGP?

4. ASP State Transition Diagram
In the FSM, the ASP-ACTIVE and ASP-STANDBY states are depicted as a single
state. This doesn't seem correct, either they are a single state, and we
drop the notion of ASP-ACTIVE and ASP-STANDBY state, or they're not, and
they're depicted as two different states with proper state transitions.
It seems pretty clear that these are indeed different states, and that state
transitions have been defined in the draft, so I suggest that the FSM be
updated to reflect this.

5. De-activation of ACTIVE ASP in over-ride AS In the second alinea from the
bottom of page 75, it states that an ACTIVE ASP (ASP_A) in an over-ride AS
becomes INACTIVE when another ASP (ASP_B) sends an ASPAC(over-ride). Why
should ASP_A become INACTIVE and not STANDBY?
ASP_A would still be capable of handling traffic in case ASP_B goes down.
So, I propose that the SGP consider ASP_A as STANDBY, and that an
ASPAC_ACK(over-ride(Standby), previously over-ride) be sent to ASP_A to
inform it about the state change.

6. Client/Server notion
In paragraph 1.3.2.4, it states that: 
   "in order to avoid redundant SCTP associations between two M3UA peers,
one side (client) SHOULD be designated to establish the SCTP association, or
M3UA configuration knowledge maintained to detect redundant associations" My
understanding is that:
   a. SCTP is a symmetrical protocol
   b. during the initialization phase of an SCTP association, both parties
exchange the addresses they want to use, so that when one endpoint tries to
establish a second SCTP association with the other endpoint, the redundancy
of that connection will automatically be detected, and the 2nd attempt would
be rejected.
Is my understanding correct? If so, Could you please remove from the draft
the above quote, as well as paragraph 1.4.8.

Best Regards,

Richard Band

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 09 Jul 2001 10:40:27 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: M2UA update
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings:

A new M2UA draft will be posted soon.  This draft addresses all of the
outstanding issues discussed on the list.  It contains the following
changes:

* addition of procedures and messages to support automatic allocation of
signaling data links and signaling terminals

*  removed Traffic Mode type from ASP Inactive to align with M3UA

*  aligned text in Section 4 with M3UA

*  aligned common parameter values with M3UA/SUA

*  added Correlation ID/Data Ack for use with Broadcast traffic mode

*  general housekeeping / cleanup

I plan to ask Lyndon to issue a Last Call on this document.

Regards,

Ken

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA Changes : 6 vs 7
Date: Mon, 9 Jul 2001 12:36:22 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail1.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [24.2.9.88]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings,

   Yes, I'll provide a change summary later on tonight.

Cheers,

   Greg

----- Original Message -----
From: "Srivats P." <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Monday, July 09, 2001 12:00 AM
Subject: M3UA Changes : 6 vs 7

> Greg,
>
> Could you send over a summary of the changes
> between ver 6 and ver 7 ?
>
> A MS-Word "comparison" document might also
> be useful. If I remember correctly, you once
> offerred something similar ...
>
> Regards,
> Srivats P.
>
>
>
> ---
> 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: "Tomar, Nitin" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA07: Routing Context assignment
Date: Mon, 9 Jul 2001 18:15:40 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: thalia.fm.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: fmfdns02.fm.intel.com [132.233.247.11]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi All,

 I have an issue in Routing Context assignment in Dynamic RKM procedure  and
would like to know what other M3UA developers think of it.

Thanks
Nitin.

The section 4.2.4.1 of draft 7 states:
'The method of routing context value assignment at the SG/SGP is
implementation dependent but must be guaranteed to be unique across all SGPs
in an SG'

Consider the following scenario:

        -------------      <-- Reg Req (RK1)
        |   SGP1  |   -----------------------------
        -------------     Reg Rsp (RC1) ->   |
                                                         -------------
                                                         |   ASP1  |
                                                         -------------
                                                                  |
        -------------      <--- Reg Req (RK1)   |
        |   SGP2  |---------------------------------
        -------------      Reg Rsp (RC2) ->   

SGP1 and SGP2 are part of same SG, also SGP1 and SGP2 are two different
implementations of two different vendors [I think this is quite possible at
least from interoperability point of view]

        ASP1 wants to register RK1 with SGP1 [sends REG REQ and get REG RSP
as well] and gets RC1 from SGP1,
        now ASP1 wants to register RK1 with SGP2 and may get RC2 from SGP2
in REG RSP message.
        
As per draft, these RC1 and RC2 has to be unique and implementation
dependent, I'm just wondering how this will be achieved among different
implementations.

I think the above issue can be resolved by just modifying the definition of
Routing Context, 
Can we explicitly make the Routing Context's significance restricted between
SGP and ASP [which actually is]
exactly similar to what we have for network appearance, that will remove the
"implementation dependent but must be guaranteed to be unique" text from the
draft  and ASP will be able to handle both the RCs (RC1 towards SGP1 and RC2
towards SGP2) for a single RK and will send the ASPAC [RC1] towards SGP1 and
ASPAC [RC2] towards SGP2.

any comments?

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 9 Jul 2001 22:09:13 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Routing Context assignment
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.200]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Nitin,

I don't think that in M3UA07 it is really possible to have multiple SGP from
multiple vendors interoperable on just the basis of the M3UA07 spec.  I
agree it would be a good thing; however, M3UA07 doesn't really support it.

Several times throughout the M3UA07 draft, the SGP are identified as having
to present a single SG view, coordinate state between them, and permit
rerouting of traffic between them.  In the absence of an SGP to SGP protocol
to support interoperability, I don't believe that SGP from multiple vendors
will be able to interoperate within an SG.

If SGP were allowed to operate in a more "decoupled" fashion, then, your
proposal has merit.  However, that is not the case.

--Brian

Tomar, Nitin wrote:                             (Mon, 09 Jul 2001 18:15:40)
> Hi All,
> 
>  I have an issue in Routing Context assignment in Dynamic RKM procedure 
>  and would like to know what other M3UA developers think of it.
> 
> Thanks
> Nitin.
> 
> 
> The section 4.2.4.1 of draft 7 states:
> 'The method of routing context value assignment at the SG/SGP is
> implementation dependent but must be guaranteed to be unique across all
SGPs
> in an SG'
> 
> 
> Consider the following scenario:
> 
>         -------------      <-- Reg Req (RK1)
>         |   SGP1  |   -----------------------------
>         -------------     Reg Rsp (RC1) ->   |
>                                                          -------------
>                                                          |   ASP1  |
>                                                          -------------
>                                                                   |
>         -------------      <--- Reg Req (RK1)   |
>         |   SGP2  |---------------------------------
>         -------------      Reg Rsp (RC2) ->   
>      
> 
> SGP1 and SGP2 are part of same SG, also SGP1 and SGP2 are two different
> implementations of two different vendors [I think this is
> quite possible at least from interoperability point of view]
> 
>         ASP1 wants to register RK1 with SGP1 [sends REG REQ and get REG
RSP
> as well] and gets RC1 from SGP1,
>         now ASP1 wants to register RK1 with SGP2 and may get RC2 from SGP2
> in REG RSP message.
>         
> As per draft, these RC1 and RC2 has to be unique and implementation
> dependent, I'm just wondering how this will be achieved among 
> different implementations.
> 
> I think the above issue can be resolved by just modifying the definition
of
> Routing Context, 
> Can we explicitly make the Routing Context's significance restricted
between
> SGP and ASP [which actually is]
> exactly similar to what we have for network appearance, that will remove
the
> "implementation dependent but must be guaranteed to be unique" text from
the
> draft  and ASP will be able to handle both the RCs (RC1 towards SGP1 and
> RC2 towards SGP2) for a single RK and will send the ASPAC [RC1] towards
SGP1
> and ASPAC [RC2] towards SGP2.
> 
> any comments?
> 
> 
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [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]
Date: Tue, 10 Jul 2001 8:11:24 +0500
From: "Srivats P." <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Re: RE: Comments on M3UA MIB
Organization: Mercury Corporation, India
X-mailer: FoxMail 2.1 [en]
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Antonio,

Find comments inline ...

Regards,
Srivats P.

At 7/9/01 1:53:00 PM, you wrote:
>
>Hello,
>
>Thank you very much for your comments.
>Please, find answers inline.
>
>Regards,
>Antonio
>
>
>
>-----Original Message-----
>From: Srivats P. [mailto:[email-masked]]
>Sent: Friday, June 29, 2001 9:32 AM
>To: sigtran
>Subject: Comments on M3UA MIB
>
>
>Antonio,
>
>I have some comments on the M3UA MIB Draft ver 01 -
>
>1. Section 3.1.2.3 Signaling Process Table - Para 4
>"Several SP will correspond to one SP Endpoint. They will be linked by the 
>Association Id."
>I don't understand what you want to say by the above statement
>
>[Antonio] What I try to say is that there may be more than one entry in the
table with the same AssocId ( that's the common link ). All this entries are
differentiated by the AppId which the SP is serving.
>
>I will rephrase the hold chapter:
>
>"Defines data related to a Signaling Process, identified by the Association
ID of the association established to that remote Endpoint where the SP is
running, and the Logical Application ID which the SP is serving.
>
>A Signaling Process is a process instance that uses M3UA to communicate
with other signaling process. An ASP, an SGP and an IPSP are all signaling
processes.
>
>As a SP can maintain different states and traffic handling modes for every
LApp it is serving, i.e. The ASP_1 may be ASP-ACTIVE(LOAD-SHARING) for AS_1,
>ASP-INACTIVE for AS_2 and ASP-ACTIVE(OVER-RIDE) for AS_3. Then, one entry
>will be created in this table per every combination of AS ID and
Association ID.
>
>All the entries corresponding to the same SP running in an specific
Endpoint will have a common link, the Association Id."
>
>
>
>2. Section 3.1.2.4 Signaling Process Endpoint Table - Para 6
>"The main table also contains statistics data related to the M3UA messaging
>exchanged through that association between the Signaling Processes that
>hold the association."
>This has been moved to another table.
>
>[Antonio] OK, removed
>
>
>3. Section 3.1.2.5 Signaling Process Endpoint Statistics Table
>As per the object definition for this table, the following
>fields need to be included in this table - m3uaAppId and m3uaSpEpId
>Remove m3uaSpEpRowStatus.
>
>[Antonio] You are right, indexes were missing, but SPE Table is indexed by
SPE ID and Assoc ID.
>OK, removing m3uaSpEpRowStatus.

[Srivats] Why is Assoc Id part of the index ? In my opinion SPEP ID is
unique in itself and will suffice to serve as index.

>
>I have a question here. Do you want to maintain statistics
>on a per AS - ASP basis ? In that case how do you propose
>to maitain statistics for messages which are not related to a particular
>AS such as ASPUP, ASPDN etc. ?
>Or should it be only on ASP basis, instead of AS - ASP ?
>
>[Antonio] No, I don't want to maintain statistics on a per AS(App) -
ASP(SP) basis. I just want to maintain statistics on a per ASP(SP) basis,
that's why the main group if statistics is maintained in the SPE table. An
SPE identifies the SP that is runnin g
> on it.
>Statistics related to AS(App) are maintained in App Table. Currently there
is only one defined: Number of Times an App is unreachable ( because it is
DOWN ).
>
>
>
>4. Section 3.1.2.6 Routing Table
>What about "Routing Context" ? Or do you propose to use
>m3uaPeerAppId as the routing context ?
>
>[Antonio] I just wanted to remark that the result of the routing is an
Application ID, that is the same as the Routing Context. That makes me think
about changing all the references to "Logical Application" by "Routing
Context". Then, we would have:
>
>- "RC Table" instead of "Logical Application Table".
>- An entry in Signaling Process table would be indexed by AssocId and the
RcId which the SP is serving.

[Srivats] But then the text would become inconsistent with Routing Table at
ASP.

>
>
>
>5. Section 3.1.2.6 Network Appearance Table
>Duplicate Section No., Add m3uaNaRowStatus
>
>[Antonio] OK, done.
>
>
>6. Section 3.1.2.7.2 Local and Remote IP Address Tables
>I suggest using m3uaSpEpId instead of m3uaAssocId as
>the index.
>
>[Antonio] Could you elaborate on this a little more, please.

[Srivats] It is my understanding that spepId is unique and sufficient to
suffice as the index for the spep Table. And since it is possible to
configure the Local and Remote Address Tables for a particular SPEP, these
should be indexed using spep Id.

>
>
>7. Object Definition of m3uaMaxStreamInbound
>Should it have a MAX-ACCESS of "read-write" or "read-only" ?
>Secondly the SCTP MIB already has this object, and while
>accepting incoming associations, SCTP uses its own value rather
>than M3UA's value.
>
>[Antonio] When SCTP is initialized, M3UA will have to provide a value to
SCTP. This is why I thought it should be configured here.
>What about the case where the value configured in SCTP is bigger than the
value wanted by the user, M3UA in this case.

[Srivats] From Section 10 SCTP - ULP Interface of RFC 2970, I don't see any
such parameter in either the INITIALIZE or the ASSOCIATE primitive.

>
>8. Object Definition of m3uaSpEpEntry
>Index should not include "m3uaAppId"
>
>[Antonio] Yes, you are right. This was already fixed in new version. It is
m3uaSpEpAssocId instead of m3uaAppId
>
>9. Object Definition of m3uaSpEpStatRowStatus
>Delete definition as all entries in this table are "read-only"
>
>[Antonio] OK, done.
>
>10. Object Definition of m3uaRoutingTable
>As the object is currently defined, this cannot be used at
>at a ASP M3UA. A Routing Key at an ASP would be for the peer
>Logical Application ie. SG. Thus, only the DPC component of
>routing key would be used, everything else would be null.
>But a DPC may be accessible to ASP via multiple SGs. But the
>table cannot take multiple rows becoz that would lead to
>duplicate routing keys which is the index for the table.
>
>[Antonio] That's right. Then...
>The result of the routing table would be a ResultSet each containing one or
more AppIds and a priority for every one. The routing table at SGP will only
allow to add one RC/App ID per ResultSet.
>
>This means that a ResultSet Table must be added to the mib.
>
>Any comments on that??

[Srivats] Either you do that or define two routing tables one for ASP and
one for SG ... letme think this over ...

>
>11. Typos -
>-Date on Page 1. Should be May 23, 2001
>-Abstract on Page 1 - Para 2. Should be M3UA
>-Section 1. Introduction - Para 3. Should be M3UA
>-Object Definition of "LOGICAL APPLICATION TABLE" : Change 
>"Application Server" to "Logical Application" and "AS"
>to "App"
>
>[Antonio] OK, done
>
>Thank you very much again and sorry for the late response.
>
>Regards,
>Srivats P.
>
>
>
>---
>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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Original-To: IETF-Announce:;;@cnri.reston.va.us@zrtps0jn
PP-Warning: Parse error in original version of preceding To line
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sigtran-m2ua-09.txt
Date: Tue, 10 Jul 2001 10:27:38 -0400
Sender: [email-masked]
X-SMTP-HELO: ietf.org
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
To: "sigtran" <[email-masked]>

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		: SS7 MTP2-User Adaptation Layer
	Author(s)	: K. Morneault, R. Dantu, G. Sidebottom,
                          T. George, B. Bidulock, J. Heitz
	Filename	: draft-ietf-sigtran-m2ua-09.txt
	Pages		: 33
	Date		: 09-Jul-01
	
This Internet Draft defines a protocol for backhauling of SS7 MTP2 User
signaling messages over IP using the Stream Control Transmission Protocol
(SCTP).  This protocol would be used between a Signaling Gateway (SG) and
Media Gateway Controller (MGC).  It is assumed that the SG receives SS7
signaling over a standard SS7 interface using the SS7 Message Transfer Part
(MTP) to provide transport.  The Signaling Gateway would act as a Signaling
Link Terminal.

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

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-m2ua-09.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-m2ua-09.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.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sigtran-m2ua-09.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-sigtran-m2ua-09.txt> ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA - DEREG Results
Date: Tue, 10 Jul 2001 17:32:49 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: penguin-ext.wise.edt.ericsson.se [194.237.142.110]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg,

As I understand from the draft the REG/DEREG RSP is the following:

REG/DEREG RSP msg  ---|-- Reg/Deregistration ResultS (Tag=0x90/0x91)
				  (only 1 parameter per message?)

					|-- Reg/Deregistration Result
(tag=0x88/0x89)					|
					|-- Reg/Deregistration Result
(tag=0x88/0x89) Reg/Deregistration ResultS ---|--	....
					|-- Reg/Deregistration Result
(tag=0x88/0x89)
					|-- Reg/Deregistration Result
(tag=0x88/0x89)
					    (from 1 to N parameters)

The proposal would be the following:

				|-- Reg/Deregistration Result
(tag=0x88/0x89)					|
				|-- Reg/Deregistration Result
(tag=0x88/0x89) REG/DEREG RSP msg    ---|--	....
				|-- Reg/Deregistration Result
(tag=0x88/0x89)
				|-- Reg/Deregistration Result
(tag=0x88/0x89)
				    (from 1 to N parameters)

In this way two parameters could be saved (Reg/Deregistration ResultS), that
means 1 tag/length saved, and the message is better structured. 
I honestly think everybody will agree about that, unless there is a reason I
do not know to have these 'container' parameter (Reg/Dereg ResultS).

One more thing, in the explanation of 'Registration Results': '...The number
of results in a single REG RSP message MAY match the number of Routing Key
parameters found in the corresponding REG REQ message' Shouldn't that MAY be
replaced by MUST??

Thanks
/MCruz

-----Original Message-----
From: Greg Sidebottom [mailto:[email-masked]] Sent: Friday, July 06, 2001
2:45 AM
To: sigtran
Subject: Re: M3UA - DEREG Results

Hi Maria-Cruz,

I really don't know which approach is "easier" or "simpler" - I'll let the
implementors out there tell me their preference.  I don't remember the
REG/DEREG RSP format being given any real deep thought when we worked it out
- I suppose the current format saves a few Tag/Length bytes when there are
multiple results.  But if it is ugly or harder to process then I have no
problem changing it.

Cheers,

Greg Sidebottom
[email-masked]

----- Original Message -----
From: "Maria-Cruz Bartolome-Rodrigo (ECE)"
<[email-masked]> To: "sigtran"
<[email-masked]> Sent: Thursday, July 05, 2001 3:27 PM
Subject: RE: M3UA - DEREG Results

>
> Hi Greg,
>
> In issue 6 both messages (REG RSP and DEREG RSP) do have only one
> parameter ('Registration Results' and 'De-registration Results'),
> that's right, but being those made up of multiple like parameters
> I do not think it makes things easier at all, on the contrary
> I find that the proposal below will simplify these messages and
> we will get rid of two parameters that are mainly sub-parameter
> containers and rather useless.
>
> What are the advantages of the actual format?
> I may misundertand something...
>
> Thanks
> /MCruz
>
>
>
> -----Original Message-----
> From: Greg Sidebottom [mailto:[email-masked]]
> Sent: Thursday, July 05, 2001 5:13 AM
> To: sigtran
> Subject: Re: M3UA - DEREG Results
>
>
> Hi Maria-Cruz,
>
> I read Ben's e-mail before but seeing as nobody supported it I didn't make
> the change in Issue 7.  I had input from one person off-line who didn't
like
> the general idea of multiple like parameters in the same message.   But if
> there is support for this I have no problem at all to make the change.
>
> Cheers,
>
>    Greg
>
> ----- Original Message -----
> From: "Maria-Cruz Bartolome-Rodrigo (ECE)"
> <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Monday, July 02, 2001 9:44 AM
> Subject: RE: M3UA - DEREG Results
>
>
> >
> > Hi Greg,
> >
> > I recall the mail below sent a long time ago.
> > I checked the e-mail list but I couldn't find an answer to it.
> > I have the same doubt as Ben had and his proposal sounds reasonable
> > to me.
> >
> > What's your opinion about that?
> >
> > Cheers
> > /MCruz
> >
> >
> >
> >
> > -----Original Message-----
> > From: Benjamin J. Wilson,,, [mailto:[email-masked]]
> > Sent: Tuesday, April 03, 2001 10:16 PM
> > To: sigtran
> > Subject: DEREG Results
> >
> >
> > Greg/Norm,
> >
> > Might I suggest a bit of cleanup to the DEREG RSP and REG RSP?
> >
> > It seems a DEREG RSP contains 1 DEREG RESULTS parameter which
> > itself contains many DEREG RESULT (singular) parameters.  It's not
> > clear from the text b/c no tag is in the diagram, but there is a
> > tag for it in the list of parameter ids at the beginning.
> >
> > Since REG REQ has many Routing Key parameters it seems the DEREG
> > RESULTS parameter can be eliminated and the DEREG RSP could just
> > contain many DEREG RESULT parameters.
> >
> > Hopefully this makes sense.
> >
> > Ben
> >
> >
> >
> > ---
> > 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]
>
>
> ---
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Routing Key parameter
Date: Tue, 10 Jul 2001 17:43:15 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: albatross-ext.wise.edt.ericsson.se [194.237.142.116]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

I do not know if I've understood your question... You would specify the
appropiate  NA and SI (in the local-RK-id) if you need so.

There must be something in this mail thread we do not approach in the same
way... 

/MCruz

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Friday, July
06, 2001 9:42 AM
To: sigtran
Subject: Re: M3UA: Routing Key parameter

Maria,

Who would then police whether the appropriate local-RK-id was applied for
the given network appearance and the explicit values of, say, the SI (which
has national significance)?

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:   (Thu, 05 Jul 2001 11:48:39)

[snip]
> 
> I think a possible SOLUTION would be to have a 'local-RK-identifier' per 
> valid combination set, then invalid combinations could be avoided (e.g.
having
> a local-RK-identifier per SI would avoid having SSN for ISUP), definition
> is easier and more understandable and optional parameter dealing becomes
easier
> as well. 
> 
> On the other hand, it would mean that it may be needed more than one 
> 'local-RK-identifier' to be assigned to the same RC (then the name
'local-RK-id'
> wouldn't be the most appropiate...). This could be solved as well
considering, 
> for example, that all 'local-RK-ids' (maybe named 'routing subparameter
combination')
> within the same REG REQ message should be assigned to the same RC.
> 
> 
> Let me know if this make sense to you or I am messing up things.
> /MCruz
> 

-- 
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]
Date: Tue, 10 Jul 2001 16:23:01 -0400
From: Vince Deters <[email-masked]>
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: M3UA version 7 comments
X-SMTP-HELO: rtp-msg-core-1.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: rtp-msg-core-1.cisco.com [161.44.11.97]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Couple of small corrections....

- In section 3.7.1, in the traffic mode description:

"Over-ride (Standby) indicates that the
   traffic sender continues to use the currently active ASP until it
   can no longer send/receive traffic (i.e., the currently active ASP
   transitions to state ASP-DOWN or ASP-ACTIVE)."

That should be "...ASP-DOWN or ASP-INACTIVE..."

- In section 4.2.3.2, the third paragraph has an incomplete sentence at the
end.

Vince

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 10 Jul 2001 18:28:41 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA07 Comments
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      SAA14224
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-200.dallas.net [209.44.42.200]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Following are some preliminary comments on the M3UA07 draft.

In addition to these comments there are still the outstanding issues which
have not been addressed:
        
    o   DATA payload formats.
    o   Routing Context in DATA messages.
    o   Changeover and Changeback support.
    o   Correlation Id.
    o   Broadcast traffic mode.
    o   SGP management support.

Section 1.1 Scope, first paragraph:

	"...  The delivery mechanism SHOULD meet the following
	criteria:"

    What is the point in specifying what the _draft_ SHOULD do?
    This "SHOULD" does not place a recommendation on an
    implementation...  Either this "SHOULD" is implicitly met, or
    implicitly not met, by the draft itself.  Suggest rewording as:

	The delivery mechanism addresses the following objectives:

Section 1.2 Terminology, second last sentence in first paragraph
	(Application Server definition):

	"... An AS is contained within a single Network Appearance.
	..."

    What is this supposed to mean?

Section 1.2 Terminology, second paragraph (Application Server
	Process definition):

	"an active or standby" was changed to "active or back-up"

    Why?

Section 1.2 Terminology, fifth paragraph (Signalling Gateway
	definition):

	"Where an SG contains more than one SGP, the SG is a logical
	entity and the contained SGPs must be coordinated into a
	single management view to the SS7 network and to the
	supported Application Servers."

    This is not consistent with later text which describes that the
    ASP must maintain the reachability of routes on a per SGP basis.

    As far as the SS7 network is concerned, it may only be necessary
    to provide a single MTP management view towards the SS7 network
    if the SG actually provides its own point code.  In a "protocol
    conversion" implementation (where the SG has no separate point
    code of its own) it is not necessary to represent a single
    management view of the SG towards the SS7 network.  This text,
    however, says "must".

    As far as the Application Servers are concerned, from further
    text in the draft, it appears that the ASPs must keep track of
    the reachability of the SGPs and (as an option) may coordinate
    the state of the SGPs into a single view.  In this case, it
    appears that the ASPs are responsible for providing a single
    management view of the SG.  Again, this text says "must".

    This last sentence should be struck from the definition or
    "must" change to "could" or "might typically".

Section 1.2 Terminology, seventh paragraph (Signalling Process
	definition):

    Grammar:

	"Signalling Process - A process instance that uses M3UA to
	communicate with other signalling process."

	either "other signalling processes" or "another signalling
	process"

Section 1.2 Terminology, eigth paragraph (Routing Key definition):

	"Parameters within the Routing Key cannot extend across more
	than a single SS7 Destination Point Code."

    This statement is too restrictive as it precludes "alias" point
    codes at the AS/ASP.  Suggest the following rewording:

	Parameters within the Routing Key cannot extend across more
	than a single Signalling Point Management Cluster.

Section 1.2 Terminology, eleventh paragraph (Signalling Point
	Management Cluster definition):

	"The complete set of Application Servers represented to the
	SS7 network under one specific SS7 Point Code of one
	specific Network Appearance."

    Again, too restrictive and precludes a single signalling point
    being labelled with multiple "alias" point codes.  Suggest the
    following rewording:

	The complete set of Application Servers represented to the
	SS7 network under a single MTP entity (Signalling Point).

Section 1.2 Terminology, eleventh paragraph (Signalling Point
	Management Cluster definition):

	"SPMCs are used to sum the availability/congestion/User_Part
	status of an SS7 destination point code that is distributed
	in the IP domain, for the purpose of supporting MTP3
	management procedures at an SG."

    Again, too restrictive and precludes a signle signalling point
    being labeled with multiple "alias" point codes but having a
    common set of MTP3 management procedures which apply to the
    signalling point.  Suggest the following rewording:

	SPMCs are used to aggregate the availability, congestion and
	user part status of an MTP entity (Signalling Point) that is
	distributed in the IP domain, for the purpose of supporting
	MTP3 management procedures towards the SS7 network.

Section 1.2 Terminology, eleventh paragraph (Signalling Point
	Management Cluster definition):

	"... In this case, the SG availability/congestion/User_Part
	status must also be taken into account when considering any
	supporting MTP3 management actions."

    The word "must" causes confusion with MUST.  Change "must" to
    "should" or "could".

Section 1.2 Terminology, fifteenth paragraph (Network Appearance
	definition):

	"This partitioning is necessary where an SG is logically
	partitioned to appear as end node elements in multiple
	separate SS7 networks, in which case there is a separate
	network appearance for each point code in the SS7 networks."

    and

	"It is also necessary when an SG is configured as an STP
	hosting multiple point codes, or when configured as multiple
	end nodes within the same network, in which case each point
	code is a separate network appearance.between the SG and the
	Application Server Processes over a common SCTP
	Association."

    This implies that separate network appearances are required for
    both multiple and "alias" point codes, meaning that a separate
    AS is required for each point code, even though the same set of
    MTP3 management procedures may apply to the entire set.
    Definitely this language is somewhat confusing.  Suggest
    something more like the following:

	Network Appearance - The Network Appearance uniquely
	identifies one SS7 network of multiple disjoint SS7 networks
	in which an SPMC resides.

Section 1.2 Terminology, fifteenth paragraph (Network Appearance
	definition):

	"... A Network Appearance implicitly defines the SS7 Point
	Code(s), Network Indicator and MTP3 protocol
	type/variant/version used within a specific SS7 network
	partition."

    "SS7 network partition" is certainly not what is meant here.
    The draft should refer to a "separate" or "disjoint" "SS7
    network", not a "partition" of an SS7 network.

Section 1.2 Terminology, eighteenth paragraph (Host definition):

	"Host - The computing platform that the ASP process is
	running on."

    This also applies to the SGP.  Also, there is a implication
    throughout the document that a Host corresponds to a unique set
    of SCTP endpoints.  Also "ASP process" repeats the "process"
    designation.  Suggest the following:

	Host - The computing platform that a process (SGP or ASP) is
	running on.

Section 1.3.1 Protocol Architecture

    Second paragraph:

	"Within the framework architecture, this document defines an
	MTP3-User adaptation module suitable for supporting the
	transfer of messages of any protocol layer that is
	identified to the MTP Level 3 layer, in SS7 terms, as a user
	part."

    SS7 refers to these as 'MTP Users', not 'as a user part'.  Also,
    SS7 uses Levels, not layers, so "MTP Level 3 layer" is
    redundant.  Suggest the following rewording:

	Within the framework architecture, this document defines an
	MTP3-User adaptation module suitable for supporting the
	transfer of messages of

Section 1.3.1 Protocol Architecture

	"- Sequenced delivery of user messages within multiple
	streams, with an option for order-of-arrival delivery of
	individual user messages,"

    M3UA does not utilize order-of-arrival delivery and this aspect
    of SCTP cannot be taken avantage of by using SCTP as a transport
    for M3UA.

Section 1.3.1 Protocol Architecture

	"- Optional multiplexing of user messages into SCTP
	datagrams,"

    It is not clear how M3UA can utilize this optional feature of
    SCTP.

Section 1.3.1 Protocol Architecture

	"- Network-level fault tolerance through support of
	multi-homing at either or both ends of an association,"

    SCTP multi-homing can be used by a specific implementation and a
    specific configuration to support network-level fault tolerance,
    but SCTP does not provide this in itself.  M3UA does not get
    network- level fault tolerance merely by using SCTP as a
    transport, nor necessarily by merely using SCTP's multi-homing
    feature.

Section 1.3.1 Protocol Architecture

	"Under certain scenarios, such as back-to-back connections
	without redundancy requirements, the SCTP functions above
	MAY NOT be a requirement and TCP can be used as the
	underlying common transport protocol."

    Should an implementation support TCP as well?

Section 1.3.2

	"The M3UA layer does not itself provide the MTP3 services.
	However, in the case where an ASP is connected to more than
	one SGP, the M3UA layer at an ASP must maintain the status
	of configured SS7 destinations and route messages according
	to the availability and congestion status of the routes to
	these destinations via each SGP."

    In this text "SG" from version 6 has been changed to "SGP" in
    version 7.  This has the negative impact that this text requires
    that when the ASP is connected to more than one SGP, the ASP is
    required to maintain SS7 routing information on a per-SGP basis
    rather than a per-SG basis.  Although both cases are valid, it
    represents a significant departure from the version 6 model.

    For example, what does an SGP do with tranfer messages for which
    it has no route?  In the version 6 situation, it is clear that
    if the SG has a route, the SGP either deals with messages for
    that route (or take itself out of service).  Now it is not so
    clear.

    Also, the "must" here means what?  Does it mean MUST?

Section 1.3.2.1

	"The MTP-TRANSFER primitive information is encoded as in
	MTP3-User messages.  In this way, the SCCP and ISUP messages
	received from the SS7 network by the SGP are not re-encoded
	into a different format for transport between the M3UA
	peers.  The MTP3 Service Information Octet (SIO) and Routing
	Label (OPC, DPC, and SLS) are included, encoded as expected
	by the MTP3 and MTP3-User protocol layer."

    As discussed on the list, many MTP-User interfaces pass routing
    label information as parameters, which must then be "re-encoded"
    at the SG before transport to the ASP and "re-decoded" at the
    ASP to pass to the MTP-User.  This issue has not yet been
    addressed.

Section 1.3.2.1

	"At an ASP, in the case where a destination is reachable via
	multiple SGPs, the M3UA layer must also choose via which SGP
	the message is to be routed or support load balancing across
	the SGPs, ensuring that no missequencing occurs."

    M3UA in its current trim does not support the requirement that
    the ASP ensure that "no missequencing occurs".  Also, no
    procedure is given in M3UA to select an SGP from multiple SGPs
    for which the destination is available.  The management of SGPs
    at he ASP is an outstanding and significant issue.

Section 1.3.2.1

	"However, if the SS7 network is provisioned to support the
	Broadband MTP [20] to the final SS7 destination, the
	information block size limit may be increased past 272
	octets."

    This is also true for Q.703 Annex A operation which is cited as
    only supporting 272-octets as cited in [14] at the beginning of
    this paragraph.  Citing specific SS7 refererences here is of
    little use as the need for M3UA to respect maximum SIF sizes
    depends upon the implementation and the network configuration.

Section 1.3.2.2

	"The M3UA layer provides management of the underlying SCTP
	transport protocol to ensure that SGP-ASP and IPSP-IPSP
	transport is available to the degree called for by the
	MTP3-User signalling applications."

    The M3UA layer provides no such thing.  It has no procedures to
    ensure the availability to the levels expected by the MTP3-User
    as quantified in the SS7 specifications.

Section 1.3.2.3

	"At the SGP, the M3UA layer must also provide inter-working
	with MTP3 management functions to support seamless operation
	of the user SCN signalling applications in the SS7 and IP
	domains."

    This statement places a requirement (or an objective) on M3UA.
    It is arguable whether M3UA can "support seamless operation fo
    the user SCN signalling applications in the SS7 and IP domains".

Section 1.3.2.3

	"- Providing an indication to MTP3-Users at an ASP that a
	   remote destination in the SS7 network is not reachable.

	 - Providing an indication to MTP3-Users at an ASP that a
	   remote destination in the SS7 network is now reachable.

	 - Providing an indication to MTP3-Users at an ASP that
	   messages to a remote destination in the SS7 network are
	   experiencing SS7 congestion.

	 - Providing an indication to the M3UA layer at an ASP that
	   the routes to a remote destination in the SS7 network are
	   restricted.

	 - Providing an indication to MTP3-Users at an ASP that a
	   remote MTP3- User peer is unavailable.  

    The words "remote destination" here is confusing.  A local or
    adjacent destination can also become unreachable and can also
    experience congestion.

Section 1.3.2.4

	"The M3UA layer at the SGP maintains the availability state
	of all configured remote ASPs, in order to manage the SCTP
	Associations and the traffic between the M3UA peers.  As
	well, the active/inactive and congestion state of remote
	ASPs is maintained."

   SG changed to SGP has different meaning here.  Now it appears
   that it is each SGP's responsibility to maintain the state of all
   remote ASPs.  It also means that an ASP can be active for one SGP
   and inactive for another.  Although not necessarily incorrect,
   this is substantially different from the version 6 text.

Section 1.3.2.4

	"...M3UA configuration knowledge maintained to detect
	redundant..."

    Nit pick: should read "M3UA configuration information".

Section 1.3.2.4

	"... This may be achieved using the M-ASP_request or
	M-AS_STATUS request primitives. ..."

    Nit pick: should read "This MAY be achieved..."

Section 1.3.2.4

	"As shown in Figure 1 an ASP may be connected to multiple
	SGPs. In such a case a particular SS7 destination may be
	reachable via more than one SGP, i.e., via more than one
	route."

    Changing SG to SGP here has consequences for the implementation
    as discussed above.

Section 1.3.3

	"... However, the conjunction of distributed architecture
	and redundant networks does allow for a sufficiently
	reliable transport of signalling traffic over IP."

    "[S]ufficiently reliable" here is highly subjective.

Section 1.3.3

	"The M3UA protocol is flexible enough to allow its operation
	and management in a variety of physical configurations,
	enabling Network Operators to meet their performance and
	reliability requirements."

    Operators may require SGs (as they often require STPs) to be
    "loss-less" in that a single failure will not result in the loss
    of a message.  M3UA does not support this.  

Section 1.3.3

	"and SGPs within the available Hosts SHOULD also be
	considered. ..."

    Nit pick:  "SHOULD also be considered" and "MAY also be
    considered" and "MUST be considered" are really the same thing.
    There is no way of enforcing a consideration.  Therefore, "MAY"
    is more appropriate.

Section 1.3.3

	"As an example, for a particular Application Server, the
	related ASPs SHOULD be distributed over at least two Hosts."

    Nit pick:  "SHOULD" inside an example qualitified with
    "particular" but left unspecified has no weight.  Therefore,
    "MAY" is more appropriate.

Figure 1:

    What was the purpose of removing SG1 and SG2 from the figure?

Section 1.3.3

	"A pair of signalling gateway processes may represent, as an
	example, a single Signalling Gateway, serving a signalling
	point management cluster."

   This is less clear than the previous text with regard to the
   multiple SG arrangement diagrammed.  A "pair of SGP" has no
   significance over "n SGPs".  The configuration with multiple SG
   *is* significant.

Section 1.3.3

	"This message distribution function is based on the status
	of provisioned routing keys, the availability of signalling
	points in the SS7 network, and the redundancy model
	(active-standby, load-sharing, n+k) of the remote signalling
	processes."

    The message distribution function is not strictly dependent on
    "the availability of signalling points in the SS7 network".  The
    message distribution function *is* strictly dependent on the
    status of signalling routes (via the SGP in V7).

Section 1.3.3

	"For carrier grade networks, the failure or isolation of a
	particular signalling process SHOULD NOT cause stable calls
	or transactions to be lost.  This implies that signalling
	processes need, in some cases, to share the call/transaction
	state or be able to pass the call state information between
	each other.  In the case of ASPs performing call processing,
	coordination may also be required with the related Media
	Gateway to transfer the MGC control for a particular trunk
	termination.  However, this sharing or communication of
	call/transaction state information is outside the scope of
	this document."

    A "SHOULD NOT" implying something which is "outside the scope of
    this dcoument" has no weight.  This "SHOULD NOT" does not speak
    to the interoperability of M3UA, but addresses something out of
    scope.  It is really not the place of this document to specify
    what operators should or should not require with regards to
    stable calls or transactions.

Section 1.3.3

	"M3UA imposes no restrictions as to the exact layout of the
	network elements, the message distribution algorithms and
	the distribution of the signalling processes."

    The mapping of Network Appearances and SPMCs to point codes does
    restrict the distribution algorithms and the distribution of
    signalling processes.

Section 1.4.1

	"... The SG Point Code might also used for "

    Grammar:  should read "The SG Point Code might also be used
    for".

Section 1.4.1

	"The SG Point Code might also used for addressing any local
	MTP3-Users at the SG such as an SG-resident SCCP function."

    This implies that a set of routing keys or routing contexts can
    also be "local" to the SG.  When an ASP goes to register or
    perform an ASPAC against one of these "local" routing keys, how
    does the SG treat this?  It appears that the SG would have to
    keep track of the state of these "local" ASPs as well...  How
    does M3UA support this local ASP management?  The example, while
    interesting, is confusing.

Section 1.4.1

	"An SG may be logically partitioned to operate in multiple
	SS7 network appearances.  In such a case, the SG must be
	addressable with a Point Code in each network appearance,
	and represents a set of nodes in the IP domain into each SS7
	network. ..."

    This "must" is too restrictive.  Certainly a
    "protocol-conversion" approach (without an SG point code) is as
    valid across multiple network appearances as it is in one.
    Change the "must" to "could".

Section 1.4.1

	"Alias Point Codes [15] may also be used within an SG
	network appearance."

    This assertion is false due to the previous discussion on
    routing keys not spanning SPMCs (which are defined as point
    codes).  Changing the SPMC definition (as proposed above) would
    strengthen this assertion.

Section 1.4.1

	"Where an SG contains more than one SGP, the MTP3 routeset,
	SPMC and remote AS/ASP states of each SGP SHOULD be
	coordinated across all the SGPs.  Re-routing of traffic
	between the SGPs SHOULD also be supported"

    Gramar: missing period at end of second sentence.

    What is the purpose of adding this paragraph?  This attempts
    again to impose requirements on the SG/SGP implementation (and
    to what end?) What does one SGP care about what another SGP's
    view of the state of an ASP which is only active with another
    SGP?

Section 1.4.1

	"The M3UA places no restrictions on the SS7 Point Code
	representation of an AS."

    M3UA places the restriction that an AS cannot represent a point
    code and a set of alias point codes.  Redefinition of the
    Network Appearance and SPMC is required to permit this
    representation.

Section 1.4.1

	"If an ASP or group of ASPs is available to the SS7 network
	via more than one SG, each with its own Point Code, the
	ASP(s) should be represented by a Point Code that is
	separate from any SG Point Code."

    The "should" in this text attempts to place a restriction on SG
    implementation and network configuration.  If multiple SGs are
    capable of representing an AS as sharing one of the SG's point
    codes, it should be permitted.

    Also, there is nothing precluding a multiple SG approach where
    each SG represents an A-link in an A-linkset and the SG acts in
    "protocol conversion" mode between the SS7 network and the ASP.
    In this case, the SGs don't need point codes at all...  

    Change "should" to "might" or "will typically"

Section 1.4.1

	"This allows these SGs to be viewed from the SS7 network as
	"STPs", each having an ongoing "route" to the same ASP(s)."

    Associated STPs are permitted to have "local" MTP-Users which
    may be represented by a single AS in multiple ASP(s).  This
    accents the error in the previous restriction.  These are all
    examples and must not place requirements on the SG
    implementation or network configuration.

Section 1.4.1

	"Under failure conditions where the ASP(s) become(s)
	unavailable from one of the SGs, this approach enables MTP3
	route management messaging between the SG and SS7 network,
	allowing simple SS7 re-routing through an alternate SG
	without changing the Destination Point Code Address of SS7
	traffic to the ASP(s)."

    This is the slippery slope of specifying the NIF again.  This
    approach must be completely optional.

Section 1.4.1

	"Where an AS can be reached via more than one SGP it is
	equally important that the corresponding Routing Keys in the
	involved SGPs are identical.  (Note: It is possible for the
	SGP Routing Key configuration data to be temporarily
	out-of-synch during configuration updates)."

    s/SG/SGP/g here has an impact.  Suddenly each SGP must have the
    same routing keys and the associated SGs do not?  Why is it
    important anyway?  Just the statement that it is "important" is
    not a sufficient description of the situation.

Section 1.4.1

	"* Note:.  SG-to ûSG communication is recommended for
	carrier grade networks, using an MTP3 linkset or an
	equivalent, to allow re-routing between the SGs in the event
	of route failures.  Where SGPs are used, inter-SGP
	communication is recommended.  Inter-SGP protocol is outside
	of the scope of this document."

    Why can't you bring yourself to draw C-links?  They are a
    standard part of the SS7 signalling network in quasi-associated
    mode.  When you label the boxes "STP" you must draw C-links or
    you will cause confusion.

    In the note, it is not the place of the M3UA spec to make
    recommendations to SS7 network operators with regard to the use
    (or not) of C-links.  Also, what "equivalent" are you implying?

    Again, the draft recommends something (inter-SGP communication)
    which is outside the scope of the document.  The draft should
    not do this because it results in a restriction (at least a
    should) placed on implementation specifics.  At least downgrade
    "SHOULD" to "MAY" and "recommended" to "might be used".

Section 1.4.2.1

	"The distribution of SS7 messages between the SGP and the
	Application Servers is determined by the Routing Keys and
	their associated Routing Contexts."

    The SGP distributes messages to ASP(s), not to AS(s).  The SGP
    may select an ASP within an AS based on routing key/context.

Section 1.4.2.1

	"Possible SS7 address/routing information that comprise a
	Routing Key entry includes, for example, the OPC, DPC, SIO
	found in the MTP3 routing label, or MTP3-User specific
	fields such as the ISUP CIC, SCCP subsystem number, or TCAP
	transaction ID."

    TCAP transaction ID is not an MTP-User specific field: it is an
    SCCP-User specific field.

Section 1.4.2.2

	"Routing Keys SHOULD be unique in the sense that each
	received SS7 signalling message SHOULD have a single routing
	result to an Application Server."

    This "SHOULD" is not consistent with the concept of a "default
    AS".  In the case of a default AS, every routing key has two
    results: one in the case that the AS is available and the other
    (default) in the case that the AS is unavailable.  The "SHOULD"
    should be removed and this text made an example only.

Section 1.4.2.2

	"At an ASP, the Routing Context parameter uniquely
	identifies the range of signalling traffic associated with
	each Application Server that the ASP is configured to
	receive."

    But the Routing Context parameter is not included with DATA
    messages and it is therefore not possible for the ASP to
    discriminate traffic by routing context without reapplying the
    routing key "filter".  As the filter has already been applied by
    the SGP in the case of DATA messages from SGP to ASP, it seems
    pointless that the ASP should then again (and perhaps
    erroneously) apply the routing key filter to discriminate
    traffic.  Routing Context should be included as a mandatory
    parameter in DATA messages and Network Appearance removed.

Section 1.4.2.2

	"A Routing Key may be configured statically using an
	implementation dependent management interface, or
	dynamically using the M3UA Routing Key registration
	procedure.  A Routing Key may also be configured using the
	M3UA dynamic registration/deregistration procedures defined
	in this document."

    The second sentence is redundant.

Section 1.4.2.2

	"An M3UA element must implement at least one method of
	Routing Key provisioning."

    If an M3UA element wants to implement the null function why not
    let it?  Or, if the M3UA element wants to hardwire the routing
    keys and not provide a "management interface", why not let it?
    An M3UA element might not require a "provisioning" method.
    Certainly, provisioning systems and management interfaces are
    outside the scope of the document.

Section 1.4.2.4

	"To support this message distribution, the SGP must maintain
	the equivalent of a network address translation table, ..."

    The draft should not place restrictions on the SGP
    implementation.  Change "SGP must maintain" to "SGP MAY
    maintain" or "SGP might, for example, maintain".  Change "This
    is accomplished" to "This could be accomplished".  Change "in
    turn make reference" to "could in turn make reference".

Section 1.4.2.4

	"When there is no matching Routing Key entry for an incoming
	SS7 message, a default treatment SHOULD be specified."

    This attempts to define the NIF.  Downgrade "SHOULD" to "MAY".
    Again, there is no reason to impose a "SHOULD" restriction on an
    implementation dependent mechanism.  The "default" treatment
    could be to ignore messages in all such situations.  Further,
    the "SHOULD" does not speak to interoperability between M3UA
    peers.

Section 1.4.2.4

	"In order to direct messages to the SS7 network, the ASP
	must also perform a message distribution function in order
	to choose the proper SGP for a given message."

    Gramar:  change both occurences of "in order to" in this
    sentence with (simply) "to".  Actually, why not:

	The ASP must choose an SGP to direct a message to the SS7
	network.

Section 1.4.2.4

	"Where more than one route (or SGP) is possible for routing
	to the SS7 network, the ASP SHOULD maintain a dynamic table
	of available SGP routes for the SS7 destinations, taking
	into account the SS7 destination availability/restricted/congestion
	status received from the SGP(s), the availability status of
	the individual SGPs and configuration changes and fail-over
	mechanisms."

    What does the "SHOULD" apply to?  Maintaining the table?  Taking
    into account destinations status?  Configuration changes?  All
    of the above?  How the ASP goes about choosing is implementation
    dependent as it stands in the draft.  The draft need not impose
    how the ASP goes about choosing down to recommending dynamic
    tables.  Change "SHOULD" to "could, for example," and label the
    whole paragraph as an IMPLEMENTATION NOTE.

Section 1.4.2.4

	"There is, however, no M3UA messaging to manage the status
	of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging).
	Whenever an SCTP association to an SGP exists, the SGP is
	assumed to be ready for the purposes of responding to M3UA
	ASPSM messages.  

	Every SGP of one SG ASP regarding one AS provides identical
	SS7 connectivity to this ASP."

    This is an issue which has been discussed a fair amount on the
    list.  These to restrictions placed on the SG/SGP implementation
    are unworkable from an number of views.

    It is clear that it cannot be the case that the SGP are treated
    as completely equal.  An SG implementation with multiple SGP
    will likely require that the ASP choose the SGP in a determinate
    fashion.  It is reasonable to assume that an SGP will expect
    only symmetrical traffic from an ASP for the Routing Key for
    which the ASP has become active.

    In the first sentences, the SGP cannot be considered to be ready
    to accept SS7 traffic before the ASP has even registered.
    Therefore, it is not just the availability of the SCTP
    association which determines whether an SGP is available.

    Further, the last sentence quoted above is in direct conflict
    with other statements in the draft which indicate that the ASP
    must maintain the availablity and congestion of route set on a
    per-SGP basis.  Therefore, it is possible that that ASP cannot
    treat the SGP as providing "identical SS7 connectivity".

Section 1.4.2.4

	"Note: It is also possible for IP-based interfaces to be
	present, using the services of the MTP2-User Adaptation
	Layer (M2UA) [23] or M2PA [].  

    Missing reference for M2PA.

Section 1.4.2.4

	"These may be terminated at a Signalling Transfer Point
	(STP) or Signalling End Point (SEP)."

    Change "may" to "could".  It is not the place of the draft to
    "give permission" for this configuration.

Section 1.4.2.4

	"Using the services of MTP3, the SG may be capable of
	communicating with remote SS7 SEPs in a quasi-associated
	fashion, where STPs may be present in the SS7 path between
	the SEP and the SG."

    Change both instances of "may" to "could".  It is not the place
    of the draft to "give permission" for this configuration.

Section 1.4.3.2

	"The Signalling Gateway must maintain knowledge of relevant
	SS7 node and Signalling Point Management Cluster (SPMC)
	status in their respective domains in order to perform a
	seamless inter-working of the IP-based signalling and the
	SS7 domains.  For example, SG knowledge of the availability
	and/or congestion status of the SPMC and SS7 nodes must be
	maintained and disseminated in the respective networks, in
	order to ensure that end-to-end operation is transparent to
	the communicating SCN protocol peers at the SS7 node and
	ASP.  Where more than one SGP constitutes an SG, the
	knowledge of the SGPs must be coordinated into an overall SG
	view."

    This is extremely awkward after s/SG/SGP/g.  The text talks of
    "SG knowledge" (bad word usage) and then says that "the
    knowledge of the SGPs" must be coordinated.  This is so
    confusing, I don't know what the draft is trying to say here.
    Perhaps it would be sufficient to say:

	The SGPs, as subsystems of an SG, are responsible for
	performing interworking between the SS7 and IP networks.

    Furthermore, there are possible implementations ("protocol
    conversion" approaches) which are stateless and rely on the
    state of the subtending ASPs to reflect the state of the SPMC.
    In this case, the SGP would need to have no "knowledge" of the
    SPMC status, yet still achieve seamless interworking.  Each
    "must" in the quoted paragraph should be changed to "may".

Section 1.4.3.2

	"(These indication primitives are also made available to any
	existing local MTP3-Users at the SG, if present.)"

    This is completely within the realm of the SS7 specifications
    and specific to an SG implementation.  I propose that it be
    stricken.

Section 1.4.3.2

	"MTP3 management messages (such as TFPs or TFAs received
	from the SS7 network) MUST NOT be encapsulated as Data
	message Payload Data and sent either from SG to ASP or from
	ASP to SG.  The SG MUST terminate these messages and
	generate M3UA messages as appropriate."

    This "MUST" and "MUST NOT" is too restrictive.  MTP3 management
    messages which are for point codes other than that of the SG or
    an SPMC might be sent as DATA messages to the ASP.  Is there a
    reason to preclude the ASP from performing the "transfer
    function"?

    Also, when there are multiple SGs, there is the issue of how the
    SG is supposed to perform changeback on behalf of the SPMC when
    it cannot be guaranteed that the CBD has arrived at the SPMC
    before responding with a CBA.  Also, there is the issue of
    changeover at the ASP in the case that there are multiple
    SG/SGPs.

Section 1.4.3.3.

	"As an example, an SPMC providing MGC capabilities must
	provide complete support for ISUP (and any other MTP3 user
	located at the point code of the SPMC) for a given point
	code, according to the local SS7 network specifications."

    Change "must provide" to "could provide".  "according to the
    local SS7 network specifications" adds no value to the sentence
    and should be removed.

Section 1.4.3.3.

	"This measure is necessary to allow the SG to accurately
	represent the signalling point on the local SS7 network."

    Which measure?

Section 1.4.3.3.

	"In the case where an ASP is connected to more than one SGP,
	the M3UA layer must maintain the status of configured SS7
	destinations and route messages according to
	availability/congestion/restricted status of the routes to
	these SS7 destinations."

    Is this a s/SG/SGP/g error?  Is it required that the ASP keep
    track of these things when there is only one SG (but multiple
    SGP)?  Also, which M3UA layer must maintain this information?
    The one on the ASP?

Section 1.4.3.3.

	"The network address translation and mapping function of the
	M3UA layer supports signalling process fail-over functions
	in order to support a high availability of call and
	transaction processing capability."

    Gramar: change "in order to" to simply "to".

    So, the draft says that two largely unspecified functions
    support a function which supports high availability of a
    processing capability.  This is so vague it really means
    nothing.  Remove it.

Section 1.4.4.1

	"All MTP3-User messages (e.g., ISUP, SCCP) incoming to an SG
	from the SS7 network are assigned to a unique Application
	Server, based on the information in the message and the
	provisioned Routing Keys."

    This statement is too broad and is in error.  The SG certainly
    has some messages which come from the SS7 network which will not
    be assigned to an Application Server.  This is the case for
    "local" MTP-Users (which is mentioned previously in the draft)
    and for mangement messages which are destined for an SG's point
    code which is not part of the SPMC of any AS.

    A correct statement would be:

	MTP3-User messages (e.g., ISUP, SCCP) which match a
	provisioned Routing Key at an SGP are mapped to an
	Application Server.

Section 1.4.4.1

	"The Application Server is, in practical terms, a list of
	all ASPs configured to process a range of MTP3-User traffic
	defined by one Routing Key.  One or more ASPs in the list
	are normally active (i.e., handling traffic) while any
	others may be unavailable or inactive, to be possibly used
	in the event of failure or unavailability of the active
	ASP(s)."

    Even in logical terms this is true; however, if the draft would
    use the word "set" instead "list" there would be no confusion
    with an implementation directive.  That is:

	The Application Server is the set of all ASPs associated
	with a specific Routing Key.  Each ASP in this set may be
	active, inactive or unavailable.  Active ASP handle traffic;
	inactive ASPs might be used when active ASPs become
	unavailable.

	etc....

Section 1.4.4.1

	"To avoid a single point of failure, it is recommended that
	a minimum of two ASPs be in the list, resident in separate
	hosts and therefore available over different SCTP
	Associations."

    ASP implementation is implementation specific.  Who says that a
    single ASP is a single point of failure?  For example, on a
    fault-tolerant processor, a single ASP might not represent a
    single point of failure.  Also, who says that a host represents
    a single point of failure?  Again, a hardware fault-tolerant
    host need not represent a single point of failure.

    This recommendation presupposes an ASP implementation and should
    be struck.

Section 1.4.4.1

	   "Routing Key {DPC=x) - "Application Server #1"
		ASP1/Host3  - State = Active
		ASP1/Host3  - State = Inactive"

    The second Host3 should be "Host4" to agree with the text.

Section 1.4.4.1

	"Care must be exercised by a Network Operator in the
	selection of the routing information to be used as the
	Routing Key for a particular AS.  For example, where
	Application Servers are defined using ranges of ISUP CIC
	values, the Operator is implicitly splitting up control of
	the related circuit groups.  Some CIC value range
	assignments may interfere with ISUP circuit group management
	procedures."

    Change "Care must be" to "Care might need to be".  Certainly it
    is no more difficult for a group of ASPs to synchronize circuit
    group state than it is for them to synchronize call state.  It
    may not be necessary for a network operator to give any
    consideration whatsoever to the matter of routing key assignment
    (providing even that the network operator has any control over
     routing key assignment at the sub-circuit-group level).  Here,
    again, the draft makes assertions and recommendations concerning
    items which are clearly out of scope.

Section 1.4.4.1

	"In the process of fail-over, it is recommended that in the
	case of ASPs supporting call processing, stable calls do not
	fail.  It is possible that calls in "transition" MAY fail,
	although measures of communication between the ASPs involved
	can be used to mitigate this.  For example, the two ASPs MAY
	share call state via shared memory, or MAY use an ASP to ASP
	protocol to pass call state information.  Any ASP-to-ASP
	protocol to support this function is outside the scope of
	this document.

    Why not?  This presumes that this is an application requirement.
    A network operator other than a regulated carrier might not care
    if some number of stable calls fail.  This recommendation is out
    of scope.  In many places in the draft, the draft makes such a
    recommendation followed by the statement that it is out of
    scope.  Out of scope recommendations should be removed or
    converted to examples.

Section 1.4.4.2

	"Signalling Gateways MAY also be distributed over multiple
	hosts.  Much like the AS model, SGs may comprise one or more
	SG Processes (SGPs), distributed over one or more hosts,
	using an active/back-up or a load-sharing model."

    How does an ASP determine which of multiple SGPs to select?  How
    does an ASP determine whether multiple SGPs are active/back-up
    or load-sharing or some other algorithm?

Section 1.4.4.2

	"Should an SGP lose all or partial SS7 connectivity and
	other SGPs exist, the SGP SHOULD terminate the SCTP
	associations to the concerned ASPs."

    Given the current requirements that an SGP provide "identical"
    SS7 connectivity, I don't understand why this "MUST" was
    downgraded to a "SHOULD".  The ASP currently has no other
    mechanism to determine whether an SGP is active or not.

Section 1.4.4.2

	"From the perspective of the M3UA layer at an ASP, a
	particular SG is capable of transferring traffic to an SS7
	destination if an SCTP association with at least one SGP of
	the SG is established, the SGP has returned an
	acknowledgement to the ASP to indicate that the ASP is
	actively handling traffic for that destination, and the SGP
	has not indicated that the destination is inaccessible."

    There is a confusion between the destinations referred to in
    this text.  It is not clear whether the text is talking about a
    destination other than the ASP SPMC or whether the text is
    talking about the ASP SPMC.  The text seems to mix both in the
    same sentence, which is confusing.  Also, this text does not
    explicitly take MTP restart into consideration.  

    For security reasons and in consideration of gateway screening
    at the SG, it might not be advisable for the ASP to consider all
    SS7 destinations as accessible by default: only those
    destinations to which it has a route.

Section 1.4.5

    It is necessary to permit the SGP to temporarily remove traffic
    from an association also.

Section 1.4.6

	"The M3UA layer at an ASP or IPSP should indicate local
	congestion to an ..."

    Change "should" to "MAY".

Section 1.4.6

	"... that requires sequencing must be assigned to the same
	stream."

    Change "must" to "SHOULD".

Section 1.4.6

	"The use of SCTP streams within M3UA is recommended in order
	to minimize transmission and buffering delays, therefore
	improving the overall performance and reliability of the
	signalling elements.  The distribution of the MTP3 user
	messages over the various streams should be done in such a
	way to minimize message mis-sequencing, as required by the
	SS7 User Parts."

    Recommendations regarding delays, performance and reliability
    should be in a separate AS document.  Strike this text.

Section 1.5.1

    The diagram shows the NIF as being above the MTP3 interface and
    above a (non-specified) M3UA interface.  This does not
    correspond to the text which requires that the NIF interact with
    MTP routing functions and even interact with SCTP at the
    management level.  It would be more accurate to show the NIF as
    between the stacks as follows:

	  ********   SS7   *****************   IP   ********
	  * SEP  *---------*      SGP      *--------* ASP  *
	  ********         *****************        ********

	  +------+       +-------------------+      +------+
	  | ISUP |       |                   |      | ISUP |
	  +------+       +------+ NIF +------+      +------+
	  | MTP3 |       | MTP3 |     | M3UA |      | M3UA |
	  +------|       +------+-+   +------+      +------+
	  | MTP2 |       | MTP2 |  \  | SCTP |      | SCTP |
	  +------+       +------+   +-+------+      +------+
	  |  L1  |       |  L1  |     |  IP  |      |  IP  |
	  +------+       +------+     +------+      +------+ 
	      |_____________|             |____________|

	    SEP - SS7 Signalling End Point
	    SCTP - Stream Control Transmission Protocol
	    NIF - Nodal Inter-working Function

Section 3.1.2

         "4        SS7 Network Congestion (SCON)"

    SS7 Network Congestion is no longer a good description.  This
    message is also used to indicate nodal congestion at the ASP.

Section 3.3.1 Payload Data Message, Network Appearance, second
	paragraph:

	"In a DATA message, the Network Appearance implicitly
	defines the SS7 Point Code format used, the SS7 Network
	Indicator value, and the MTP3 and possibly the MTP3-User
	protocol type/variant/version used within the SS7 network
	partition.  ..."

    Again, "SS7 network partition" cannot possibly be what is meant
    here.  Although the SG can be partitioned, it is partitioned
    over multiple separate or disjoint (complete) SS7 networks.
    Change "SS7 network partition" to "specific SS7 network".

Section 4.3.1 At an SGP, second paragraph:

	"The SGP M3UA layer determines the set of concerned ASPs to
	be informed based on the SS7 network partition for which the
	primitive indication is relevant. ..."

    Again, suggest changing "SS7 network partition" to "specific SS7
    network".  `network partition' is certainly not what is meant
    here.

Section 4.3.1 At an SGP, third paragraph:

	"The SG M3UA MAY filter further based on the Affected Point
	Code in the MTP-PAUSE, MTP-RESUME or MTP-STATUS indication
	primitives.  In this way ASPs can be informed only of
	affected destinations to which they actually communicate.
	The SGP M3UA layer MAY also suppress DUPU messages to ASPs
	that do not implement an MTP3-User protocol peer for the
	affected MTP3-User."

    This sounds rather peculiar since the MTP3 at the SGP will
    likely perform this filtering by way of its routing and
    screening tables.  This is a function which normally sits below
    the MTP-User interface.  What was the purpose of adding this
    text?  Remove this text.

Section 4.3.1

	"DUNA, DAVA, SCON, and DRST messages MUST be sent
	sequentially and processed at the receiver in the order
	sent.  SCTP stream "0" is used to provide the sequencing.
	The only exception to this is if the international
	congestion method (see Q.704) is used.  If so, the Unordered
	bit in the SCTP DATA chunk MAY be used for the SCON
	message."

    Even SS7 permits TFA/TFR/TFP/TFC to be sent unsequenced.  This
    is because there are responsive procedures which will soon
    correct a reversal of the messages.  For congestion, adequate
    hysteresis is provided to avoid problems due to message
    reversal.  This text should be reworded to reflect this
    situation.  The "MUST" should be changed to a "MAY" and the
    reference to international congestion removed.

Section 4.3.2.1

	"In the case where a local event has caused the
	unavailability or congestion status of SS7 destinations, the
	M3UA layer at the ASP MUST pass up appropriate indications
	in the primitives to the M3UA User, as though equivalent
	SSNM messages were received.  For example, the loss of an
	SCTP association to an SGP may cause the unavailability of a
	set of SS7 destinations.  MTP-PAUSE indication primitives to
	the M3UA User are appropriate.  To accomplish this, the M3UA
	layer at an ASP maintains the status of routes via the
	SG(P), much like an MTP3 layer maintains route-set status."

    There is no way of enforcing this "MUST" without defining which
    actions are "appropriate" for each local event.  Furthermore,
    this does not address interoperability of the protocol and is
    an implementation decision.  Change "MUST" to "SHOULD".

    The last sentence is an implementation suggestion and should be
    marked as an IMPLEMENTATION NOTE.

Section 4.3.2.2

	"An M3UA layer at the ASP MAY choose to maintain knowledge
	of which SGPs are included in Signalling Gateways for the
	purpose of interpreting SSNM messaging from one SGP so as to
	apply to all the SGPs in the SG."

    This "MAY" does not speak well to interoperability between
    independent SGP and ASP implementations.  Surely the SGP must
    know what the effect of an SNMM sent to an ASP will be in terms
    of the other SGPs in the SG.  This "optional" mode of operating
    provides one more "a priori" thing that the SGP must know about
    the ASP.

    What happens when the ASP receives conflicting information from
    separate SGP within the same SG?

    Remove this option for the sake of interoperability.

Section 4.3.3

	"In the first of the cases above, the auditing  procedure
	must not be invoked for the case of a received SCON message
	containing a congestion level value of "no congestion" or
	undefined" (i.e., congestion Level = "0"). ...

    What is the draft trying to get at here?

Section 4.3.3

	"The SGP MUST respond to a DAUD message with the MTP3
	availability/congested status of the routeset associated
	with each Destination Point Code(s) in the DAUD message.
	..."

    This is problematic in the case that the DAUD message if for a
    destination to which the SGP has no route (as opposed to a
    destination to which the SGP has a route, but which is currently
    unavailable).  This is also a security issue in that an ASP
    should not be empowered to be able to inquire as to the status
    of all possible destinations: only destinations to which the ASP
    has authorized routes.

Grammar:

    Section 1.3.2.4, first paragraph, change "in order to" to "to".
    Section 1.3.2.4, second paragraph, change "In order to" to "to".
    Section 1.4.2.4, first paragraph, change "In order to" to "To".
    Section 1.4.2.5, first paragraph, change "In order to" to "To"
    and "in order to" to "to".
    Section 1.4.3.2, second paragraph, change both instances of "in
    order to" to "to".
    Section 1.4.4, first paragraph, change "in order to" to "to".
    Section 1.4.5, first paragraph, change "in order to" to "to".
    Section 1.4.7, second paragraph, change "in order to" to "to".
    Section 3.4.1, first paragraph, change "in order to" to "to".
    Section 3.4.4, sixth paragraph, change "in order to" to "to".
    Section 3.8.2, fifteenth paragraph, change "in order to" to "to".
    Section 4.2.3.4, sixteenth paragraph, change "in order to" to "to".
    Section 4.3.3, first paragraph, change "in order to" to "to".

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 10 Jul 2001 23:07:51 -0400
From: Jim Hughes <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SCTP Data Integrity
Reply-To: [email-masked]
User-Agent: Mutt/1.3.12i
X-SMTP-HELO: storage.network.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [129.191.1.4]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

SCTP data integrity.  
   
   This note is a general comment on the "SCTP Checksum Change"
   document to suggest the possibility of using a chained hash instead of
   a 32 bit CRC.

   A chained hash algorithm (SHA-1) will

   1. Significantly increase the reliability of the transfer.
   2. without significantly increasing the computing cost on current 
      commodity processors.
   3. Only slightly increasing the packet size (by less than 0.1% for
      2k packet size). 
   4. Retain the ability to check the reliability of each packet.
   5. Allow a complete check of the entire transfer.
   6. Allow a signature to be sent after session is complete to
      non-reputably authenticate and integrity check the entire session
      without the need for any key exchange or shared secrets of any
      kind.
   7. Works with multicast streams
   8. Allow packet and session integrity of the entire session to be
      checked by intervening nodes (firewalls) allowing covert channels
      auditing after the session is complete without preestablished
      secrets. 
   9. Can be done after encoding the transmission for confidentiality.

INCREASING THE RELIABILITY

   Considering the lifetime of a standard like SCTP, one must pay
   attention to the assumptions made in the standard, and this note
   argues, among other things, that a 32 bit CRC (actually a 32 bit
   anything) is not enough. 

   If one estimates the number of packets that are transfered on the 
   Internet, the number will be staggering.
   
   Assuming 10 years from now and there are 10 million (10e7) GbE
   links (10e9) operating at 10% duty cycle(10e-1), this is 10e15 bits
   per second. Assuming 10e-9 bit error rate, this is one MILLION
   (10e6) errors per second.

   The characteristic of these errors is an important point. If these
   are all 1 bit errors, they will all be detected even if we are using a
   checksum, but we know that this is not the case. If we take the
   opposite assumption that each of these errors has a hamming weight
   larger than the CRC, then the probability of the CRC not detecting the
   error is roughly one in 4x10e9.

   This calculates to an undetected error every 4000 seconds or about
   20 undetected data corruption events per day or 7,000 undetected
   data corruption events on the Internet per year using the proposed 
   32 bit CRC. 

   Considering that these events will be undetected and, if they occur
   in file transfers, these files will be stored and potentially
   replicated with these errors. These, arguably, have grave dangers. 

   Given the place that we are at in deciding what kinds of protection
   will be available, I believe we should choose something longer (and
   potentially stronger).

SMALL INCREASE IN COMPUTING COST

   In general CRC in software and hash algorithms have OOM similar
   computing requirements. In general, on a current commodity
   processor, CRC and SHA1 both require about 1 instruction per byte. 

   While SHA1 and CRC are similar in software, SHA1 requires
   significantly more transistors. Given Moore's law, this not
   significant. 

SLIGHT INCREASE IN PACKET SIZE

   SHA1 requires 20 bytes in each packet, compared to 4 bytes for
   CRC32. The increase is 16/2048. 

CHECK INDIVIDUAL PACKETS

   If packet n is P_n and the hash of packet n is H_n, this is calculated by

        H_n = SHA[H_(n-1),P_n]

   That is, when a packet is received, H_n can be checked and if
   the previous packet is known, then you can calculate if this packet
   is correct. 

   This does require that the packets be processed in order for this
   to work. 

COMPLETE CHECK OF THE ENTIRE TRANSFER

   If the session is p packets long, if H_p is correct, all previous
   packets and the reassembly are correct. 

SIGNATURE OF ENTIRE SESSION IS POSSIBLE

   Transferring a signature is possible. 

   A key ingredient in a signature starts with a hash of the entire
   object to be signed. H_p meets this requirement. It is possible to
   sign H_p and thus sign the entire session. 

   Since the hash of a file for signature does not require a key (ala
   HMAC), then the simple unkeyed SHA1 is all that is needed and the
   signature can be added at the end. 

MULTICAST

   Since there are no prekey, if this is a multicast, signatures are
   possible. All the end points need is the public key of the source. 

CHECKING BY INTERMEDIATE NODES

   In certain cases, it is important that data be known to be
   authentic before it is let in or out of certain networks. Since
   anyone can check SHA1 and Signatures (as well as CRCs) intermediate
   nodes can check this information. 

   Significantly different than IP-SEC, this does not require any
   shared secret pre-keying (IKE) of the endpoints.

CAN BE ADDED AFTER CONFIDENTIALITY

   Since the data is opaque to SCTP, if the data is encrypted before
   being transmitted, the addition of SHA1 and signature does not 
   change this fact. 

CONCLUSION

   Adding SHA1 instead of CRC increases reliability and allows
   signatures of the entire transfer. This change allows PGP like
   integrity to be possible for any application without the need 
   for pre encoding the data and post processing the data. 

   This requires little additional resources and provides more than 10
   orders of magnitude improvement in data reliability. 

Certainly, comments are welcome. 

Thanks

jim

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 11 Jul 2001 01:04:20 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA: Changeback Issue
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-200.dallas.net [209.44.42.200]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

All,

M3UA does not provide support for the SS7 MTP changeback procedure where
multiple SG are involved.

Here is the scenario:

               +-------+        - - - - - 
               |       |       | /-----\ |
               |  SG1  |---------| ASP1|
              /| "STP" |\      |/\-----/ |
          A1 / |       | \     /
            /  +-------+  \   /|   AS    |
    /----\ /       |       \ /
    | SP |/        |        X  |  SPMC   |
    |    |\        |       / \
    \----/ \       |      /   \|         |
            \  +-------+ /     \
          A2 \ |       |/      |\/-----\ |
              \|  SG2  |---------| ASP2|
               | "STP" |       | \-----/ |
               |       |        - - - - -
               +-------+

The SP loses linkset A1.  Traffic is succesfully changed over to linkset A2.
Linkset A1 restores.  SP peforms changeback procedure per Q.704 6.2.1 (b)
(i) (that is, on a per-destination basis).  It sends a CBD for each SLS
which is being diverted from A2 back to A1 with a DPC of the SPMC.

What is SG2 to do with the CBD?  If it responds with a CBA there may be
messages between SG2 and ASP1 or ASP2 which have not yet arrived at the ASP
and might be overtaken by the diverted traffic.

The SG must have a message which it can send to the each ASP which has the
same effect as a changeback-declaration which will be responded to by the
ASP with a changeback- acknowledgement so that mis-sequencing can be avoided
during changeback procedures per Q.704 6.2.1 (b)(i).

I can put together proposed text if anyone is interested.

-- 
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]
Reply-To: [email-masked]
From: Vikas <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA v07: Some Comments
Date: Wed, 11 Jul 2001 15:42:35 +0530
Organization: Mercury Corporation
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META
content="MSHTML 5.50.4134.600" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>
<DIV><FONT size=2><FONT size=2><FONT size=2> <P>hi everybody,</P>
<P>please&nbsp;consider on following problems and suggestions (in context of
M3UA draft v07):</P>
<P>&nbsp;</P>
<P>3.2 Variable-Length Parameter Format</P></FONT><FONT size=2> <P>Parameter
Tag: 16 bits (unsigned integer)</P></FONT><FONT size=2><FONT size=2>
<P>"Common parameters used by adaptation layers are in the range of 0x00 to
0xff. M3UA-specific parameters </P>
<P>have Tags in the range 0x80 to 0xbf."</P> <P>Problem -&gt; </P>
<P>The range for M3UA-specific parameters is inside the range for Common
parameters.</P>
<P>&nbsp;</P>
<P></P>
<P>3.2 Variable-Length Parameter Format</P><FONT size=2> <P>Parameter Tag:
16 bits (unsigned integer)</P></FONT> <P>The parameter Tags defined are as
follows:</P></FONT></FONT><FONT size=2> <P>0x88 Registration Result</P>
<P>0x89 De-registration Result</P>
<P>........</P><FONT size=2>
<P>0x90 Registration Results</P>
<P>0x91 De-Registration Results</P></FONT></FONT><FONT size=2> <P>Problem
-&gt;</P>
<P>the parameters&nbsp;"Registration Result" and "De-registration Result"
are defined twice.</P>
<P>&nbsp;</P>
<P>&nbsp;</P><FONT size=2>
<P>3.5.3 ASP Down</P>
<P>"The ASP Down message is used to indicate to a remote M3UA peer that the
</P> <P>adaptation layer is NOT ready to receive DATA, SSNM or ASPTM
messages."</P> <P>Suggestion -&gt;</P>
<P>The above para should be:</P>
<P>"The ASP Down message is used to indicate to a remote M3UA peer that the
</P> <P>adaptation layer is NOT ready to receive DATA, SSNM, RKM&nbsp;or
ASPTM messages."</P><FONT size=2><FONT size=2> <P>&nbsp;</P>
<P>&nbsp;</P>
<P>4.3.3 ASP Auditing</P>
<P></FONT>See the 6th line in the&nbsp;6th para:</P> <P>"If the SS7
destination is available and </P> <P>congested, the SGP responds with an
SCON message in addition to the </P> <P>DAVA message."</P>
<P>Does SCON&nbsp; not mean it is congested and available (afterall, how can
we find out congestion on a route that is unavailable!)? So no need for the
DAVA message here.</P>
<P>&nbsp;</P><FONT size=2><FONT size=2> <P>&nbsp;</P>
<P>4.2.3.1 ASP Up Procedures</P>
<P></FONT>"At the ASP, the ASP Up Ack message received is not acknowledged. 
Layer </P>
<P>Management is informed with an M-ASP_UP confirm primitive. When an
ASP</P> <P>enters the ASP-Inactive state from the ASP_Down state towards an
SGP </P> <P>the M3UA MUST mark all SS7 destinations configured to be
reachable via </P> <P>this SGP as available."</P>
<P>After this how and when the ASP will know the actual status of the SS7
network? I think&nbsp;SG, after sending ASP UP ACK message,&nbsp;should tell
ASP about all the Unavailable/congested/Restricted destinations
automatically.</P></FONT>
<P>&nbsp;</P>
<P></FONT></FONT></FONT>4.2.3.7 Heartbeat Procedures</P> <P></FONT>"At the
ASP, if no Heartbeat Ack message (or any other M3UA message) is </P>
<P>received from the M3UA peer within 2*T(beat), the remote M3UA peer is
</P> <P>considered unavailable. Transmission of Heartbeat messages is
stopped </P> <P>and the ASP SHOULD attempt to re-establish communication
with the SGP </P> <P>M3UA peer."</P>
<P>Problem -&gt;</P>
<P>how a ASP can attempt to re-stablish communication with a SGP if it (ASP)
has been configured to behave as server for this SGP?</P> <P>Suggestion
-&gt;</P>
<P>The above para should be:</P>
<P>"At the M3UA (ASP/SGP/IPSP), if no Heartbeat Ack message (or any other
M3UA message) is </P>
<P>received from the M3UA peer within 2*T(beat), the remote M3UA peer is
</P> <P>considered unavailable. Transmission of Heartbeat messages is
stopped </P> <P>and the signalling process SHOULD attempt to re-establish
communication if it is configured as client for the disconnected&nbsp;M3UA
peer."</P> <P>&nbsp;</P>
<P>&nbsp;</P></FONT></DIV><FONT size=2><FONT size=2> <P>4.4 MTP3 Restart</P>
<DIV>In the second para:</DIV>
<DIV>&nbsp;</DIV>
<DIV>"<FONT size=2>During the second part of the restart <P>procedure the
SGP M3UA layers at the SGPs inform all concerned ASPs in </P> <P>the
ASP-ACTIVE, ASP-STANDBY or ASP-INACTIVE states of any unavailable </P>
<P>SS7 destinations using the DUNA message."</P> <P>should be:</P>
<P>"<FONT size=2>During the second part of the restart </P> <P>procedure the
SGP M3UA layers at the SGPs inform all concerned ASPs in </P> <P>the
ASP-ACTIVE, ASP-STANDBY or ASP-INACTIVE states of any
unavailable/congested/restricted </P>
<P>SS7 destinations using the DUNA/SCON/DRST message respectively."</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>4.4 MTP3 Restart</P>
<P>In the last para:</P>
<P>"<FONT size=2>When the M3UA layer at an ASP receives a DUNA message
indicating SS7 </P>
<P>network isolation at an SG, it will stop any affected traffic via this
</P> <P>route. When the M3UA subsequently receives any DUNA messages from an
SGP </P> <P>it will mark the affected SS7 destinations as unavailable via
that SG. "</P> <P>Suggestion -&gt;</P>
<P>Analogus to the MTP restart mechanism, some mechanism should be defined
to consider all routes via the SG to be available and subsequently updated
via DUNA/SCON/DRST messages.</P>
<P>&nbsp;</P></FONT></FONT></FONT></FONT></DIV>
<DIV>Regards,<BR>Vikas.</FONT></DIV></FONT></DIV> ---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY></HTML>

</x-html>
From: Dinesh JN <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: MTU Fragmentatiion of control chunks
Date: Wed, 11 Jul 2001 17:19:19 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MIMETrack: Itemize by SMTP Server on Mailserver/ConvergSoft(Release 5.07a 
             |May 14, 2001) at 07/11/2001 05:15:18 PM, Serialize by Router
on 
             Mailserver/ConvergSoft(Release 5.07a |May 14, 2001) at
07/11/2001 
             05:15:48 PM, Serialize complete at 07/11/2001 05:15:48 PM
X-SMTP-HELO: mailserver.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.36]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

In RFC 2960

   we have come across this note in RFC 2960

   IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a
   INIT ACK that is quite large (more than 1500 bytes) due to the
   variable size of the state cookie AND the variable address list.  For
   example if a responder to the INIT has 1000 IPv4 addresses it wishes
   to send, it would need at least 8,000 bytes to encode this in the
   INIT ACK.

   the fragmentation of Data chunk is very clear,but in cases above note,
the size of the INIT CHUNK will be exceeding 1500 MTU, so how these chunks
have to be handle

thanx in advance
Dinesh

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Tuexen Michael <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: "'Brian F. G. Bidulock'" <[email-masked]>
Subject: RE: M3UA07 Comments
Date: Wed, 11 Jul 2001 14:12:00 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-MIME-Autoconverted: from 8bit to quoted-printable by
beamer.mchh.siemens.de 
                      id OAA04986
X-SMTP-HELO: beamer.mchh.siemens.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: beamer.mchh.siemens.de [194.138.158.163]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii, see my comments below.
Best regards
Michael
PS.: The first line is necessary to avoid that the message is bounced.
Dear List Admin, could you change this?

Michael Tuexen    Tel.:   +49 89 722 47210 Siemens AG        Fax:    +49 89
722 48212 ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Wednesday, July 11, 2001 1:29 AM
> To:	sigtran
> Subject:	M3UA07 Comments
> 
> Following are some preliminary comments on the M3UA07 draft.
> 
> In addition to these comments there are still the outstanding
> issues which have not been addressed:
>         
>     o   DATA payload formats.
	[Tuexen Michael]  In my understanding the MTP3 packet is transported
	as a sequence of bytes. So no modification is done. If you
internally handle the routing label differently how MUST send it out as
described in Q.70? series.
>     o   Routing Context in DATA messages.
>     o   Changeover and Changeback support.
>     o   Correlation Id.
>     o   Broadcast traffic mode.
>     o   SGP management support.
> 
> Section 1.1 Scope, first paragraph:
> 
> 	"...  The delivery mechanism SHOULD meet the following
> 	criteria:"
> 
>     What is the point in specifying what the _draft_ SHOULD do?
>     This "SHOULD" does not place a recommendation on an
>     implementation...  Either this "SHOULD" is implicitly met, or
>     implicitly not met, by the draft itself.  Suggest rewording as:
> 
> 	The delivery mechanism addresses the following objectives:
> 
> 
> Section 1.2 Terminology, second last sentence in first paragraph
> 	(Application Server definition):
> 
> 	"... An AS is contained within a single Network Appearance.
> 	..."
> 
>     What is this supposed to mean?
> 
> Section 1.2 Terminology, second paragraph (Application Server
> 	Process definition):
> 
> 	"an active or standby" was changed to "active or back-up"
> 
>     Why?
> 
> 
> Section 1.2 Terminology, fifth paragraph (Signalling Gateway
> 	definition):
> 
> 	"Where an SG contains more than one SGP, the SG is a logical
> 	entity and the contained SGPs must be coordinated into a
> 	single management view to the SS7 network and to the
> 	supported Application Servers."
> 
>     This is not consistent with later text which describes that the
>     ASP must maintain the reachability of routes on a per SGP basis.
> 
>     As far as the SS7 network is concerned, it may only be necessary
>     to provide a single MTP management view towards the SS7 network
>     if the SG actually provides its own point code.  In a "protocol
>     conversion" implementation (where the SG has no separate point
>     code of its own) it is not necessary to represent a single
>     management view of the SG towards the SS7 network.  This text,
>     however, says "must".
> 
>     As far as the Application Servers are concerned, from further
>     text in the draft, it appears that the ASPs must keep track of
>     the reachability of the SGPs and (as an option) may coordinate
>     the state of the SGPs into a single view.  In this case, it
>     appears that the ASPs are responsible for providing a single
>     management view of the SG.  Again, this text says "must".
> 
>     This last sentence should be struck from the definition or
>     "must" change to "could" or "might typically".
> 
> Section 1.2 Terminology, seventh paragraph (Signalling Process
> 	definition):
> 
>     Grammar:
> 
> 	"Signalling Process - A process instance that uses M3UA to
> 	communicate with other signalling process."
> 
> 	either "other signalling processes" or "another signalling
> 	process"
> 
> Section 1.2 Terminology, eigth paragraph (Routing Key definition):
> 
> 	"Parameters within the Routing Key cannot extend across more
> 	than a single SS7 Destination Point Code."
> 
>     This statement is too restrictive as it precludes "alias" point> 
>     codes at the AS/ASP.  Suggest the following rewording:
> 
> 	Parameters within the Routing Key cannot extend across more
> 	than a single Signalling Point Management Cluster.
> 
> Section 1.2 Terminology, eleventh paragraph (Signalling Point
> 	Management Cluster definition):
> 
> 	"The complete set of Application Servers represented to the
> 	SS7 network under one specific SS7 Point Code of one
> 	specific Network Appearance."
> 
>     Again, too restrictive and precludes a single signalling point
>     being labelled with multiple "alias" point codes.  Suggest the
>     following rewording:
> 
> 	The complete set of Application Servers represented to the
> 	SS7 network under a single MTP entity (Signalling Point).
> 
> Section 1.2 Terminology, eleventh paragraph (Signalling Point
> 	Management Cluster definition):
> 
> 	"SPMCs are used to sum the availability/congestion/User_Part
> 	status of an SS7 destination point code that is distributed
> 	in the IP domain, for the purpose of supporting MTP3
> 	management procedures at an SG."
> 
>     Again, too restrictive and precludes a signle signalling point
>     being labeled with multiple "alias" point codes but having a
>     common set of MTP3 management procedures which apply to the
>     signalling point.  Suggest the following rewording:
> 
> 	SPMCs are used to aggregate the availability, congestion and
> 	user part status of an MTP entity (Signalling Point) that is
> 	distributed in the IP domain, for the purpose of supporting
> 	MTP3 management procedures towards the SS7 network.
> 
> Section 1.2 Terminology, eleventh paragraph (Signalling Point
> 	Management Cluster definition):
> 
> 	"... In this case, the SG availability/congestion/User_Part
> 	status must also be taken into account when considering any
> 	supporting MTP3 management actions."
> 
>     The word "must" causes confusion with MUST.  Change "must" to
>     "should" or "could".
> 
> Section 1.2 Terminology, fifteenth paragraph (Network Appearance
> 	definition):
> 
> 	"This partitioning is necessary where an SG is logically
> 	partitioned to appear as end node elements in multiple
> 	separate SS7 networks, in which case there is a separate
> 	network appearance for each point code in the SS7 networks."
> 
>     and
> 
> 	"It is also necessary when an SG is configured as an STP
> 	hosting multiple point codes, or when configured as multiple
> 	end nodes within the same network, in which case each point
> 	code is a separate network appearance.between the SG and the
> 	Application Server Processes over a common SCTP
> 	Association."
> 
>     This implies that separate network appearances are required for
>     both multiple and "alias" point codes, meaning that a separate
>     AS is required for each point code, even though the same set of
>     MTP3 management procedures may apply to the entire set.
>     Definitely this language is somewhat confusing.  Suggest
>     something more like the following:
> 
> 	Network Appearance - The Network Appearance uniquely
> 	identifies one SS7 network of multiple disjoint SS7 networks
> 	in which an SPMC resides.
> 
> Section 1.2 Terminology, fifteenth paragraph (Network Appearance
> 	definition):
> 
> 	"... A Network Appearance implicitly defines the SS7 Point
> 	Code(s), Network Indicator and MTP3 protocol
> 	type/variant/version used within a specific SS7 network
> 	partition."
> 
>     "SS7 network partition" is certainly not what is meant here.
>     The draft should refer to a "separate" or "disjoint" "SS7
>     network", not a "partition" of an SS7 network.
> 
> Section 1.2 Terminology, eighteenth paragraph (Host definition):
> 
> 	"Host - The computing platform that the ASP process is
> 	running on."
> 
>     This also applies to the SGP.  Also, there is a implication
>     throughout the document that a Host corresponds to a unique set
>     of SCTP endpoints.  Also "ASP process" repeats the "process"> 
>     designation.  Suggest the following:
> 
> 	Host - The computing platform that a process (SGP or ASP) is
> 	running on.
> 
> Section 1.3.1 Protocol Architecture
> 
>     Second paragraph:
> 
> 	"Within the framework architecture, this document defines an
> 	MTP3-User adaptation module suitable for supporting the
> 	transfer of messages of any protocol layer that is
> 	identified to the MTP Level 3 layer, in SS7 terms, as a user
> 	part."
> 
>     SS7 refers to these as 'MTP Users', not 'as a user part'.  Also,
>     SS7 uses Levels, not layers, so "MTP Level 3 layer" is
>     redundant.  Suggest the following rewording:
> 
> 	Within the framework architecture, this document defines an
> 	MTP3-User adaptation module suitable for supporting the
> 	transfer of messages of
> 
> Section 1.3.1 Protocol Architecture
> 
> 	"- Sequenced delivery of user messages within multiple
> 	streams, with an option for order-of-arrival delivery of
> 	individual user messages,"
> 
>     M3UA does not utilize order-of-arrival delivery and this aspect
>     of SCTP cannot be taken avantage of by using SCTP as a transport
>     for M3UA.
> 
> Section 1.3.1 Protocol Architecture
> 
> 	"- Optional multiplexing of user messages into SCTP
> 	datagrams,"
> 
>     It is not clear how M3UA can utilize this optional feature of
>     SCTP.
> 
> Section 1.3.1 Protocol Architecture
> 
> 	"- Network-level fault tolerance through support of
> 	multi-homing at either or both ends of an association,"
> 
>     SCTP multi-homing can be used by a specific implementation and a
>     specific configuration to support network-level fault tolerance,
>     but SCTP does not provide this in itself.  M3UA does not get
>     network- level fault tolerance merely by using SCTP as a
>     transport, nor necessarily by merely using SCTP's multi-homing
>     feature.
> 
> Section 1.3.1 Protocol Architecture
> 
> 	"Under certain scenarios, such as back-to-back connections
> 	without redundancy requirements, the SCTP functions above
> 	MAY NOT be a requirement and TCP can be used as the
> 	underlying common transport protocol."
> 
>     Should an implementation support TCP as well?
> 
> Section 1.3.2
> 
> 	"The M3UA layer does not itself provide the MTP3 services.
> 	However, in the case where an ASP is connected to more than
> 	one SGP, the M3UA layer at an ASP must maintain the status
> 	of configured SS7 destinations and route messages according
> 	to the availability and congestion status of the routes to
> 	these destinations via each SGP."
> 
>     In this text "SG" from version 6 has been changed to "SGP" in
>     version 7.  This has the negative impact that this text requires
>     that when the ASP is connected to more than one SGP, the ASP is
>     required to maintain SS7 routing information on a per-SGP basis
>     rather than a per-SG basis.  Although both cases are valid, it
>     represents a significant departure from the version 6 model.
> 
>     For example, what does an SGP do with tranfer messages for which
>     it has no route?  In the version 6 situation, it is clear that
>     if the SG has a route, the SGP either deals with messages for
>     that route (or take itself out of service).  Now it is not so
>     clear.
> 
>     Also, the "must" here means what?  Does it mean MUST?
> 
> Section 1.3.2.1
> 
> 	"The MTP-TRANSFER primitive information is encoded as in
> 	MTP3-User messages.  In this way, the SCCP and ISUP messages
> 	received from the SS7 network by the SGP are not re-encoded
> 	into a different format for transport between the M3UA
> 	peers.  The MTP3 Service Information Octet (SIO) and Routing
> 	Label (OPC, DPC, and SLS) are included, encoded as expected
> 	by the MTP3 and MTP3-User protocol layer."
> 
>     As discussed on the list, many MTP-User interfaces pass routing
>     label information as parameters, which must then be "re-encoded"
>     at the SG before transport to the ASP and "re-decoded" at the> 
>     ASP>  to pass to the MTP-User.  This issue has not yet been
>     addressed.
> 
> Section 1.3.2.1
> 
> 	"At an ASP, in the case where a destination is reachable via
> 	multiple SGPs, the M3UA layer must also choose via which SGP
> 	the message is to be routed or support load balancing across
> 	the SGPs, ensuring that no missequencing occurs."
> 
>     M3UA in its current trim does not support the requirement that
>     the ASP ensure that "no missequencing occurs".  Also, no
>     procedure is given in M3UA to select an SGP from multiple SGPs
>     for which the destination is available.  The management of SGPs
>     at he ASP is an outstanding and significant issue.
> 
> Section 1.3.2.1
> 
> 	"However, if the SS7 network is provisioned to support the
> 	Broadband MTP [20] to the final SS7 destination, the
> 	information block size limit may be increased past 272
> 	octets."
> 
>     This is also true for Q.703 Annex A operation which is cited as
>     only supporting 272-octets as cited in [14] at the beginning of
>     this paragraph.  Citing specific SS7 refererences here is of
>     little use as the need for M3UA to respect maximum SIF sizes
>     depends upon the implementation and the network configuration.
> 
> Section 1.3.2.2
> 
> 	"The M3UA layer provides management of the underlying SCTP
> 	transport protocol to ensure that SGP-ASP and IPSP-IPSP
> 	transport is available to the degree called for by the
> 	MTP3-User signalling applications."
> 
>     The M3UA layer provides no such thing.  It has no procedures to
>     ensure the availability to the levels expected by the MTP3-User
>     as quantified in the SS7 specifications.
> 
> Section 1.3.2.3
> 
> 	"At the SGP, the M3UA layer must also provide inter-working
> 	with MTP3 management functions to support seamless operation
> 	of the user SCN signalling applications in the SS7 and IP
> 	domains."
> 
>     This statement places a requirement (or an objective) on M3UA.
>     It is arguable whether M3UA can "support seamless operation fo
>     the user SCN signalling applications in the SS7 and IP domains".
> 
> Section 1.3.2.3
> 
> 	"- Providing an indication to MTP3-Users at an ASP that a
> 	   remote destination in the SS7 network is not reachable.
> 
> 	 - Providing an indication to MTP3-Users at an ASP that a
> 	   remote destination in the SS7 network is now reachable.
> 
> 	 - Providing an indication to MTP3-Users at an ASP that
> 	   messages to a remote destination in the SS7 network are
> 	   experiencing SS7 congestion.
> 
> 	 - Providing an indication to the M3UA layer at an ASP that
> 	   the routes to a remote destination in the SS7 network are
> 	   restricted.
> 
> 	 - Providing an indication to MTP3-Users at an ASP that a
> 	   remote MTP3- User peer is unavailable.  
> 
>     The words "remote destination" here is confusing.  A local or
>     adjacent destination can also become unreachable and can also
>     experience congestion.
> 
> Section 1.3.2.4
> 
> 	"The M3UA layer at the SGP maintains the availability state
> 	of all configured remote ASPs, in order to manage the SCTP
> 	Associations and the traffic between the M3UA peers.  As
> 	well, the active/inactive and congestion state of remote
> 	ASPs is maintained."
> 
>    SG changed to SGP has different meaning here.  Now it appears
>    that it is each SGP's responsibility to maintain the state of all
>    remote ASPs.  It also means that an ASP can be active for one SGP
>    and inactive for another.  Although not necessarily incorrect,
>    this is substantially different from the version 6 text.
> 
> Section 1.3.2.4
> 
> 	"...M3UA configuration knowledge maintained to detect
> 	redundant..."
> 
>     Nit pick: should read "M3UA configuration information".
> 
> Section 1.3.2.4
> 
> 	"... This may be achieved using the M-ASP_request or
> 	M-AS_STATUS request primitives. ..."
> 
>     Nit pick: should read "This MAY be achieved..."
> 
> Section 1.3.2.4> 
> 
> 	> "As shown in Figure 1 an A> SP may be connected to multiple
> 	SGPs. In such a case a particular SS7 destination may be
> 	reachable via more than one SGP, i.e., via more than one
> 	route."
> 
>     Changing SG to SGP here has consequences for the implementation
>     as discussed above.
> 
> Section 1.3.3
> 
> 	"... However, the conjunction of distributed architecture
> 	and redundant networks does allow for a sufficiently
> 	reliable transport of signalling traffic over IP."
> 
>     "[S]ufficiently reliable" here is highly subjective.
> 
> Section 1.3.3
> 
> 	"The M3UA protocol is flexible enough to allow its operation
> 	and management in a variety of physical configurations,
> 	enabling Network Operators to meet their performance and
> 	reliability requirements."
> 
>     Operators may require SGs (as they often require STPs) to be
>     "loss-less" in that a single failure will not result in the loss
>     of a message.  M3UA does not support this.  
> 
> Section 1.3.3
> 
> 	"and SGPs within the available Hosts SHOULD also be
> 	considered. ..."
> 
>     Nit pick:  "SHOULD also be considered" and "MAY also be
>     considered" and "MUST be considered" are really the same thing.
>     There is no way of enforcing a consideration.  Therefore, "MAY"
>     is more appropriate.
> 
> Section 1.3.3
> 
> 	"As an example, for a particular Application Server, the
> 	related ASPs SHOULD be distributed over at least two Hosts."
> 
>     Nit pick:  "SHOULD" inside an example qualitified with
>     "particular" but left unspecified has no weight.  Therefore,
>     "MAY" is more appropriate.
> 
> Figure 1:
> 
>     What was the purpose of removing SG1 and SG2 from the figure?
> 
> Section 1.3.3
> 
> 	"A pair of signalling gateway processes may represent, as an
> 	example, a single Signalling Gateway, serving a signalling
> 	point management cluster."
> 
>    This is less clear than the previous text with regard to the
>    multiple SG arrangement diagrammed.  A "pair of SGP" has no
>    significance over "n SGPs".  The configuration with multiple SG
>    *is* significant.
> 
> Section 1.3.3
> 
> 	"This message distribution function is based on the status
> 	of provisioned routing keys, the availability of signalling
> 	points in the SS7 network, and the redundancy model
> 	(active-standby, load-sharing, n+k) of the remote signalling
> 	processes."
> 
>     The message distribution function is not strictly dependent on
>     "the availability of signalling points in the SS7 network".  The
>     message distribution function *is* strictly dependent on the
>     status of signalling routes (via the SGP in V7).
> 
> Section 1.3.3
> 
> 	"For carrier grade networks, the failure or isolation of a
> 	particular signalling process SHOULD NOT cause stable calls
> 	or transactions to be lost.  This implies that signalling
> 	processes need, in some cases, to share the call/transaction
> 	state or be able to pass the call state information between
> 	each other.  In the case of ASPs performing call processing,
> 	coordination may also be required with the related Media
> 	Gateway to transfer the MGC control for a particular trunk
> 	termination.  However, this sharing or communication of
> 	call/transaction state information is outside the scope of
> 	this document."
> 
>     A "SHOULD NOT" implying something which is "outside the scope of
>     this dcoument" has no weight.  This "SHOULD NOT" does not speak
>     to the interoperability of M3UA, but addresses something out of
>     scope.  It is really not the place of this document to specify
>     what operators should or should not require with regards to
>     stable calls or transactions.
> 
> Section 1.3.3
> 
> 	"M3UA imposes no restrictions as to the exact layout of the
> 	network elements, the message distribution algorithms and
> 	the distribution of the signalling processes."
> 
>     The mapping of Network Appearances and SPMCs to point codes does
>     restrict the distribution algorithms and the distribution of> 
>     signalling processes.
> 
> Section 1.4.1
> 
> 	"... The SG Point Code might also used for "
> 
>     Grammar:  should read "The SG Point Code might also be used
>     for".
> 
> Section 1.4.1
> 
> 	"The SG Point Code might also used for addressing any local
> 	MTP3-Users at the SG such as an SG-resident SCCP function."
> 
>     This implies that a set of routing keys or routing contexts can
>     also be "local" to the SG.  When an ASP goes to register or
>     perform an ASPAC against one of these "local" routing keys, how
>     does the SG treat this?  It appears that the SG would have to
>     keep track of the state of these "local" ASPs as well...  How
>     does M3UA support this local ASP management?  The example, while
>     interesting, is confusing.
> 
> Section 1.4.1
> 
> 	"An SG may be logically partitioned to operate in multiple
> 	SS7 network appearances.  In such a case, the SG must be
> 	addressable with a Point Code in each network appearance,
> 	and represents a set of nodes in the IP domain into each SS7
> 	network. ..."
> 
>     This "must" is too restrictive.  Certainly a
>     "protocol-conversion" approach (without an SG point code) is as
>     valid across multiple network appearances as it is in one.
>     Change the "must" to "could".
> 
> Section 1.4.1
> 
> 	"Alias Point Codes [15] may also be used within an SG
> 	network appearance."
> 
>     This assertion is false due to the previous discussion on
>     routing keys not spanning SPMCs (which are defined as point
>     codes).  Changing the SPMC definition (as proposed above) would
>     strengthen this assertion.
> 
> Section 1.4.1
> 
> 	"Where an SG contains more than one SGP, the MTP3 routeset,
> 	SPMC and remote AS/ASP states of each SGP SHOULD be
> 	coordinated across all the SGPs.  Re-routing of traffic
> 	between the SGPs SHOULD also be supported"
> 
>     Gramar: missing period at end of second sentence.
> 
>     What is the purpose of adding this paragraph?  This attempts
>     again to impose requirements on the SG/SGP implementation (and
>     to what end?) What does one SGP care about what another SGP's
>     view of the state of an ASP which is only active with another
>     SGP?
> 
> Section 1.4.1
> 
> 	"The M3UA places no restrictions on the SS7 Point Code
> 	representation of an AS."
> 
>     M3UA places the restriction that an AS cannot represent a point
>     code and a set of alias point codes.  Redefinition of the
>     Network Appearance and SPMC is required to permit this
>     representation.
> 
> Section 1.4.1
> 
> 	"If an ASP or group of ASPs is available to the SS7 network
> 	via more than one SG, each with its own Point Code, the
> 	ASP(s) should be represented by a Point Code that is
> 	separate from any SG Point Code."
> 
>     The "should" in this text attempts to place a restriction on SG
>     implementation and network configuration.  If multiple SGs are
>     capable of representing an AS as sharing one of the SG's point
>     codes, it should be permitted.
> 
>     Also, there is nothing precluding a multiple SG approach where
>     each SG represents an A-link in an A-linkset and the SG acts in
>     "protocol conversion" mode between the SS7 network and the ASP.
>     In this case, the SGs don't need point codes at all...  
> 
>     Change "should" to "might" or "will typically"
> 
> Section 1.4.1
> 
> 	"This allows these SGs to be viewed from the SS7 network as
> 	"STPs", each having an ongoing "route" to the same ASP(s)."
> 
>     Associated STPs are permitted to have "local" MTP-Users which
>     may be represented by a single AS in multiple ASP(s).  This
>     accents the error in the previous restriction.  These are all
>     examples and must not place requirements on the SG
>     implementation or network configuration.
> 
> Section 1.4.1
> 
> 	"Under failure conditions where the ASP(s) become(s)
> 	unavailable from one of the SGs, this approach enables MTP3> 
> 	> route managem> ent messaging between the SG and SS7 network,
> 	allowing simple SS7 re-routing through an alternate SG
> 	without changing the Destination Point Code Address of SS7
> 	traffic to the ASP(s)."
> 
>     This is the slippery slope of specifying the NIF again.  This
>     approach must be completely optional.
> 
> Section 1.4.1
> 
> 	"Where an AS can be reached via more than one SGP it is
> 	equally important that the corresponding Routing Keys in the
> 	involved SGPs are identical.  (Note: It is possible for the
> 	SGP Routing Key configuration data to be temporarily
> 	out-of-synch during configuration updates)."
> 
>     s/SG/SGP/g here has an impact.  Suddenly each SGP must have the
>     same routing keys and the associated SGs do not?  Why is it
>     important anyway?  Just the statement that it is "important" is
>     not a sufficient description of the situation.
> 
> Section 1.4.1
> 
> 	"* Note:.  SG-to ûSG communication is recommended for
> 	carrier grade networks, using an MTP3 linkset or an
> 	equivalent, to allow re-routing between the SGs in the event
> 	of route failures.  Where SGPs are used, inter-SGP
> 	communication is recommended.  Inter-SGP protocol is outside
> 	of the scope of this document."
> 
>     Why can't you bring yourself to draw C-links?  They are a
>     standard part of the SS7 signalling network in quasi-associated
>     mode.  When you label the boxes "STP" you must draw C-links or
>     you will cause confusion.
> 
>     In the note, it is not the place of the M3UA spec to make
>     recommendations to SS7 network operators with regard to the use
>     (or not) of C-links.  Also, what "equivalent" are you implying?
> 
>     Again, the draft recommends something (inter-SGP communication)
>     which is outside the scope of the document.  The draft should
>     not do this because it results in a restriction (at least a
>     should) placed on implementation specifics.  At least downgrade
>     "SHOULD" to "MAY" and "recommended" to "might be used".
> 
> Section 1.4.2.1
> 
> 	"The distribution of SS7 messages between the SGP and the
> 	Application Servers is determined by the Routing Keys and
> 	their associated Routing Contexts."
> 
>     The SGP distributes messages to ASP(s), not to AS(s).  The SGP
>     may select an ASP within an AS based on routing key/context.
> 
> Section 1.4.2.1
> 
> 	"Possible SS7 address/routing information that comprise a
> 	Routing Key entry includes, for example, the OPC, DPC, SIO
> 	found in the MTP3 routing label, or MTP3-User specific
> 	fields such as the ISUP CIC, SCCP subsystem number, or TCAP
> 	transaction ID."
> 
>     TCAP transaction ID is not an MTP-User specific field: it is an
>     SCCP-User specific field.
> 
> Section 1.4.2.2
> 
> 	"Routing Keys SHOULD be unique in the sense that each
> 	received SS7 signalling message SHOULD have a single routing
> 	result to an Application Server."
> 
>     This "SHOULD" is not consistent with the concept of a "default
>     AS".  In the case of a default AS, every routing key has two
>     results: one in the case that the AS is available and the other
>     (default) in the case that the AS is unavailable.  The "SHOULD"
>     should be removed and this text made an example only.
> 
> Section 1.4.2.2
> 
> 	"At an ASP, the Routing Context parameter uniquely
> 	identifies the range of signalling traffic associated with
> 	each Application Server that the ASP is configured to
> 	receive."
> 
>     But the Routing Context parameter is not included with DATA
>     messages and it is therefore not possible for the ASP to
>     discriminate traffic by routing context without reapplying the
>     routing key "filter".  As the filter has already been applied by
>     the SGP in the case of DATA messages from SGP to ASP, it seems
>     pointless that the ASP should then again (and perhaps
>     erroneously) apply the routing key filter to discriminate> 
>     traffic.  Routing Context should be included as a mandatory
>   >   parameter in DATA messages and Network Appearance removed.
> 
> Section 1.4.2.2
> 
> 	"A Routing Key may be configured statically using an
> 	implementation dependent management interface, or
> 	dynamically using the M3UA Routing Key registration
> 	procedure.  A Routing Key may also be configured using the
> 	M3UA dynamic registration/deregistration procedures defined
> 	in this document."
> 
>     The second sentence is redundant.
> 
> Section 1.4.2.2
> 
> 	"An M3UA element must implement at least one method of
> 	Routing Key provisioning."
> 
>     If an M3UA element wants to implement the null function why not
>     let it?  Or, if the M3UA element wants to hardwire the routing
>     keys and not provide a "management interface", why not let it?
>     An M3UA element might not require a "provisioning" method.
>     Certainly, provisioning systems and management interfaces are
>     outside the scope of the document.
> 
> Section 1.4.2.4
> 
> 	"To support this message distribution, the SGP must maintain
> 	the equivalent of a network address translation table, ..."
> 
>     The draft should not place restrictions on the SGP
>     implementation.  Change "SGP must maintain" to "SGP MAY
>     maintain" or "SGP might, for example, maintain".  Change "This
>     is accomplished" to "This could be accomplished".  Change "in
>     turn make reference" to "could in turn make reference".
> 
> Section 1.4.2.4
> 
> 	"When there is no matching Routing Key entry for an incoming
> 	SS7 message, a default treatment SHOULD be specified."
> 
>     This attempts to define the NIF.  Downgrade "SHOULD" to "MAY".
>     Again, there is no reason to impose a "SHOULD" restriction on an
>     implementation dependent mechanism.  The "default" treatment
>     could be to ignore messages in all such situations.  Further,
>     the "SHOULD" does not speak to interoperability between M3UA
>     peers.
> 
> Section 1.4.2.4
> 
> 	"In order to direct messages to the SS7 network, the ASP
> 	must also perform a message distribution function in order
> 	to choose the proper SGP for a given message."
> 
>     Gramar:  change both occurences of "in order to" in this
>     sentence with (simply) "to".  Actually, why not:
> 
> 	The ASP must choose an SGP to direct a message to the SS7
> 	network.
> 
> Section 1.4.2.4
> 
> 	"Where more than one route (or SGP) is possible for routing
> 	to the SS7 network, the ASP SHOULD maintain a dynamic table
> 	of available SGP routes for the SS7 destinations, taking
> 	into account the SS7 destination availability/restricted/congestion
> 	status received from the SGP(s), the availability status of
> 	the individual SGPs and configuration changes and fail-over
> 	mechanisms."
> 
>     What does the "SHOULD" apply to?  Maintaining the table?  Taking
>     into account destinations status?  Configuration changes?  All
>     of the above?  How the ASP goes about choosing is implementation
>     dependent as it stands in the draft.  The draft need not impose
>     how the ASP goes about choosing down to recommending dynamic
>     tables.  Change "SHOULD" to "could, for example," and label the
>     whole paragraph as an IMPLEMENTATION NOTE.
> 
> Section 1.4.2.4
> 
> 	"There is, however, no M3UA messaging to manage the status
> 	of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging).
> 	Whenever an SCTP association to an SGP exists, the SGP is
> 	assumed to be ready for the purposes of responding to M3UA
> 	ASPSM messages.  
> 
> 	Every SGP of one SG ASP regarding one AS provides identical
> 	SS7 connectivity to this ASP."
> 
>     This is an issue which has been discussed a fair amount on the
>     list.  These to restrictions placed on the SG/SGP implementation
>     are unworkable from an number of views.
> 
>     It is clear that it cannot be the case that the SGP are treated
>     as completely equal.  An SG implementation with multiple SGP
>     will likely require that the ASP choose the SGP in a determinate> 
>     fa> shion.  It is reasonable to assume that an SGP will expect
>     only symmetrical traffic from an ASP for the Routing Key for
>     which the ASP has become active.
> 
>     In the first sentences, the SGP cannot be considered to be ready
>     to accept SS7 traffic before the ASP has even registered.
>     Therefore, it is not just the availability of the SCTP
>     association which determines whether an SGP is available.
> 
>     Further, the last sentence quoted above is in direct conflict
>     with other statements in the draft which indicate that the ASP
>     must maintain the availablity and congestion of route set on a
>     per-SGP basis.  Therefore, it is possible that that ASP cannot
>     treat the SGP as providing "identical SS7 connectivity".
> 
> Section 1.4.2.4
> 
> 	"Note: It is also possible for IP-based interfaces to be
> 	present, using the services of the MTP2-User Adaptation
> 	Layer (M2UA) [23] or M2PA [].  
> 
>     Missing reference for M2PA.
> 
> Section 1.4.2.4
> 
> 	"These may be terminated at a Signalling Transfer Point
> 	(STP) or Signalling End Point (SEP)."
> 
>     Change "may" to "could".  It is not the place of the draft to
>     "give permission" for this configuration.
> 
> Section 1.4.2.4
> 
> 	"Using the services of MTP3, the SG may be capable of
> 	communicating with remote SS7 SEPs in a quasi-associated
> 	fashion, where STPs may be present in the SS7 path between
> 	the SEP and the SG."
> 
>     Change both instances of "may" to "could".  It is not the place
>     of the draft to "give permission" for this configuration.
> 
> Section 1.4.3.2
> 
> 	"The Signalling Gateway must maintain knowledge of relevant
> 	SS7 node and Signalling Point Management Cluster (SPMC)
> 	status in their respective domains in order to perform a
> 	seamless inter-working of the IP-based signalling and the
> 	SS7 domains.  For example, SG knowledge of the availability
> 	and/or congestion status of the SPMC and SS7 nodes must be
> 	maintained and disseminated in the respective networks, in
> 	order to ensure that end-to-end operation is transparent to
> 	the communicating SCN protocol peers at the SS7 node and
> 	ASP.  Where more than one SGP constitutes an SG, the
> 	knowledge of the SGPs must be coordinated into an overall SG
> 	view."
> 
>     This is extremely awkward after s/SG/SGP/g.  The text talks of
>     "SG knowledge" (bad word usage) and then says that "the
>     knowledge of the SGPs" must be coordinated.  This is so
>     confusing, I don't know what the draft is trying to say here.
>     Perhaps it would be sufficient to say:
> 
> 	The SGPs, as subsystems of an SG, are responsible for
> 	performing interworking between the SS7 and IP networks.
> 
>     Furthermore, there are possible implementations ("protocol
>     conversion" approaches) which are stateless and rely on the
>     state of the subtending ASPs to reflect the state of the SPMC.
>     In this case, the SGP would need to have no "knowledge" of the
>     SPMC status, yet still achieve seamless interworking.  Each
>     "must" in the quoted paragraph should be changed to "may".
> 
> Section 1.4.3.2
> 
> 	"(These indication primitives are also made available to any
> 	existing local MTP3-Users at the SG, if present.)"
> 
>     This is completely within the realm of the SS7 specifications
>     and specific to an SG implementation.  I propose that it be
>     stricken.
> 
> Section 1.4.3.2
> 
> 	"MTP3 management messages (such as TFPs or TFAs received
> 	from the SS7 network) MUST NOT be encapsulated as Data
> 	message Payload Data and sent either from SG to ASP or from
> 	ASP to SG.  The SG MUST terminate these messages and
> 	generate M3UA messages as appropriate."
> 
>     This "MUST" and "MUST NOT" is too restrictive.  MTP3 management
>     messages which are for point codes other than that of the SG or
>     an SPMC might be sent as DATA messages to the ASP.  Is there a> 
>     reason to preclude the ASP from performing the "trans> fer
>     function"?
> 
>     Also, when there are multiple SGs, there is the issue of how the
>     SG is supposed to perform changeback on behalf of the SPMC when
>     it cannot be guaranteed that the CBD has arrived at the SPMC
>     before responding with a CBA.  Also, there is the issue of
>     changeover at the ASP in the case that there are multiple
>     SG/SGPs.
> 
> Section 1.4.3.3.
> 
> 	"As an example, an SPMC providing MGC capabilities must
> 	provide complete support for ISUP (and any other MTP3 user
> 	located at the point code of the SPMC) for a given point
> 	code, according to the local SS7 network specifications."
> 
>     Change "must provide" to "could provide".  "according to the
>     local SS7 network specifications" adds no value to the sentence
>     and should be removed.
> 
> Section 1.4.3.3.
> 
> 	"This measure is necessary to allow the SG to accurately
> 	represent the signalling point on the local SS7 network."
> 
>     Which measure?
> 
> Section 1.4.3.3.
> 
> 	"In the case where an ASP is connected to more than one SGP,
> 	the M3UA layer must maintain the status of configured SS7
> 	destinations and route messages according to
> 	availability/congestion/restricted status of the routes to
> 	these SS7 destinations."
> 
>     Is this a s/SG/SGP/g error?  Is it required that the ASP keep
>     track of these things when there is only one SG (but multiple
>     SGP)?  Also, which M3UA layer must maintain this information?
>     The one on the ASP?
> 
> Section 1.4.3.3.
> 
> 	"The network address translation and mapping function of the
> 	M3UA layer supports signalling process fail-over functions
> 	in order to support a high availability of call and
> 	transaction processing capability."
> 
>     Gramar: change "in order to" to simply "to".
> 
>     So, the draft says that two largely unspecified functions
>     support a function which supports high availability of a
>     processing capability.  This is so vague it really means
>     nothing.  Remove it.
> 
> Section 1.4.4.1
> 
> 	"All MTP3-User messages (e.g., ISUP, SCCP) incoming to an SG
> 	from the SS7 network are assigned to a unique Application
> 	Server, based on the information in the message and the
> 	provisioned Routing Keys."
> 
>     This statement is too broad and is in error.  The SG certainly
>     has some messages which come from the SS7 network which will not
>     be assigned to an Application Server.  This is the case for
>     "local" MTP-Users (which is mentioned previously in the draft)
>     and for mangement messages which are destined for an SG's point
>     code which is not part of the SPMC of any AS.
> 
>     A correct statement would be:
> 
> 	MTP3-User messages (e.g., ISUP, SCCP) which match a
> 	provisioned Routing Key at an SGP are mapped to an
> 	Application Server.
> 
> Section 1.4.4.1
> 
> 	"The Application Server is, in practical terms, a list of
> 	all ASPs configured to process a range of MTP3-User traffic
> 	defined by one Routing Key.  One or more ASPs in the list
> 	are normally active (i.e., handling traffic) while any
> 	others may be unavailable or inactive, to be possibly used
> 	in the event of failure or unavailability of the active
> 	ASP(s)."
> 
>     Even in logical terms this is true; however, if the draft would
>     use the word "set" instead "list" there would be no confusion
>     with an implementation directive.  That is:
> 
> 	The Application Server is the set of all ASPs associated
> 	with a specific Routing Key.  Each ASP in this set may be
> 	active, inactive or unavailable.  Active ASP handle traffic;
> 	inactive ASPs might be used when active ASPs become
> 	unavailable.
> 
> 	etc....
> 
> Section 1.4.4.1
> 
> 	"To avoid a single point of failure, it is recommended that
> 	a minimum of two ASPs be in the list, resident in separate
> 	hosts and therefore available over different SCTP
> 	Associations."
> 
>     ASP implementation is implementation specific.  Who says that a> 
>     single ASP is a single point of failure?  For example, on a
>     fault-tolerant processor, a single ASP might not represent a
>     single point of failure.  Also, who says that a host represents
>     a single point of failure?  Again, a hardware fault-tolerant
>     host need not represent a single point of failure.
> 
>     This recommendation presupposes an ASP implementation and should
>     be struck.
> 
> Section 1.4.4.1
> 
> 	   "Routing Key {DPC=x) - "Application Server #1"
> 		ASP1/Host3  - State = Active
> 		ASP1/Host3  - State = Inactive"
> 
>     The second Host3 should be "Host4" to agree with the text.
> 
> Section 1.4.4.1
> 
> 	"Care must be exercised by a Network Operator in the
> 	selection of the routing information to be used as the
> 	Routing Key for a particular AS.  For example, where
> 	Application Servers are defined using ranges of ISUP CIC
> 	values, the Operator is implicitly splitting up control of
> 	the related circuit groups.  Some CIC value range
> 	assignments may interfere with ISUP circuit group management
> 	procedures."
> 
>     Change "Care must be" to "Care might need to be".  Certainly it
>     is no more difficult for a group of ASPs to synchronize circuit
>     group state than it is for them to synchronize call state.  It
>     may not be necessary for a network operator to give any
>     consideration whatsoever to the matter of routing key assignment
>     (providing even that the network operator has any control over
>      routing key assignment at the sub-circuit-group level).  Here,
>     again, the draft makes assertions and recommendations concerning
>     items which are clearly out of scope.
> 
> Section 1.4.4.1
> 
> 	"In the process of fail-over, it is recommended that in the
> 	case of ASPs supporting call processing, stable calls do not
> 	fail.  It is possible that calls in "transition" MAY fail,
> 	although measures of communication between the ASPs involved
> 	can be used to mitigate this.  For example, the two ASPs MAY
> 	share call state via shared memory, or MAY use an ASP to ASP
> 	protocol to pass call state information.  Any ASP-to-ASP
> 	protocol to support this function is outside the scope of
> 	this document.
> 
>     Why not?  This presumes that this is an application requirement.
>     A network operator other than a regulated carrier might not care
>     if some number of stable calls fail.  This recommendation is out
>     of scope.  In many places in the draft, the draft makes such a
>     recommendation followed by the statement that it is out of
>     scope.  Out of scope recommendations should be removed or
>     converted to examples.
> 
> Section 1.4.4.2
> 
> 	"Signalling Gateways MAY also be distributed over multiple
> 	hosts.  Much like the AS model, SGs may comprise one or more
> 	SG Processes (SGPs), distributed over one or more hosts,
> 	using an active/back-up or a load-sharing model."
> 
>     How does an ASP determine which of multiple SGPs to select?  How
>     does an ASP determine whether multiple SGPs are active/back-up
>     or load-sharing or some other algorithm?
> 
> Section 1.4.4.2
> 
> 	"Should an SGP lose all or partial SS7 connectivity and
> 	other SGPs exist, the SGP SHOULD terminate the SCTP
> 	associations to the concerned ASPs."
> 
>     Given the current requirements that an SGP provide "identical"
>     SS7 connectivity, I don't understand why this "MUST" was
>     downgraded to a "SHOULD".  The ASP currently has no other
>     mechanism to determine whether an SGP is active or not.
> 
> Section 1.4.4.2
> 
> 	"From the perspective of the M3UA layer at an ASP, a
> 	particular SG is capable of transferring traffic to an SS7
> 	destination if an SCTP association with at least one SGP of
> 	the SG is established, the SGP has returned an
> 	acknowledgement to the ASP to indicate that the ASP is
> 	actively handling traffic for that destination, and the SGP> 
> 	has not indicated that the destination is inaccessible."
> 
>     There is a confusion between the destinations referred to in
>     this text.  It is not clear whether the text is talking about a
>     destination other than the ASP SPMC or whether the text is
>     talking about the ASP SPMC.  The text seems to mix both in the
>     same sentence, which is confusing.  Also, this text does not
>     explicitly take MTP restart into consideration.  
> 
>     For security reasons and in consideration of gateway screening
>     at the SG, it might not be advisable for the ASP to consider all
>     SS7 destinations as accessible by default: only those
>     destinations to which it has a route.
> 
> Section 1.4.5
> 
>     It is necessary to permit the SGP to temporarily remove traffic
>     from an association also.
> 
> Section 1.4.6
> 
> 	"The M3UA layer at an ASP or IPSP should indicate local
> 	congestion to an ..."
> 
>     Change "should" to "MAY".
> 
> Section 1.4.6
> 
> 	"... that requires sequencing must be assigned to the same
> 	stream."
> 
>     Change "must" to "SHOULD".
> 
> Section 1.4.6
> 
> 	"The use of SCTP streams within M3UA is recommended in order
> 	to minimize transmission and buffering delays, therefore
> 	improving the overall performance and reliability of the
> 	signalling elements.  The distribution of the MTP3 user
> 	messages over the various streams should be done in such a
> 	way to minimize message mis-sequencing, as required by the
> 	SS7 User Parts."
> 
>     Recommendations regarding delays, performance and reliability
>     should be in a separate AS document.  Strike this text.
> 
> Section 1.5.1
> 
>     The diagram shows the NIF as being above the MTP3 interface and
>     above a (non-specified) M3UA interface.  This does not
>     correspond to the text which requires that the NIF interact with
>     MTP routing functions and even interact with SCTP at the
>     management level.  It would be more accurate to show the NIF as
>     between the stacks as follows:
> 
> 	  ********   SS7   *****************   IP   ********
> 	  * SEP  *---------*      SGP      *--------* ASP  *
> 	  ********         *****************        ********
> 
> 	  +------+       +-------------------+      +------+
> 	  | ISUP |       |                   |      | ISUP |
> 	  +------+       +------+ NIF +------+      +------+
> 	  | MTP3 |       | MTP3 |     | M3UA |      | M3UA |
> 	  +------|       +------+-+   +------+      +------+
> 	  | MTP2 |       | MTP2 |  \  | SCTP |      | SCTP |
> 	  +------+       +------+   +-+------+      +------+
> 	  |  L1  |       |  L1  |     |  IP  |      |  IP  |
> 	  +------+       +------+     +------+      +------+ 
> 	      |_____________|             |____________|
> 
> 	    SEP - SS7 Signalling End Point
> 	    SCTP - Stream Control Transmission Protocol
> 	    NIF - Nodal Inter-working Function
> 
> Section 3.1.2
> 
>          "4        SS7 Network Congestion (SCON)"
> 
>     SS7 Network Congestion is no longer a good description.  This
>     message is also used to indicate nodal congestion at the ASP.
> 
> Section 3.3.1 Payload Data Message, Network Appearance, second
> 	paragraph:
> 
> 	"In a DATA message, the Network Appearance implicitly
> 	defines the SS7 Point Code format used, the SS7 Network
> 	Indicator value, and the MTP3 and possibly the MTP3-User
> 	protocol type/variant/version used within the SS7 network
> 	partition.  ..."
> 
>     Again, "SS7 network partition" cannot possibly be what is meant
>     here.  Although the SG can be partitioned, it is partitioned
>     over multiple separate or disjoint (complete) SS7 networks.
>     Change "SS7 network partition" to "specific SS7 network".
> 
> 
> Section 4.3.1 At an SGP, second paragraph:
> 
> 	"The SGP M3UA layer determines the set of concerned ASPs to
> 	be informed based on the SS7 network partition for which the
> 	primitive indication is relevant. ..."
> 
>     Again, suggest changing "SS7 network partition" to "specific SS7> 
>     network".  `network partitio> n' is certainly not what is meant
>     here.
> 
> Section 4.3.1 At an SGP, third paragraph:
> 
> 	"The SG M3UA MAY filter further based on the Affected Point
> 	Code in the MTP-PAUSE, MTP-RESUME or MTP-STATUS indication
> 	primitives.  In this way ASPs can be informed only of
> 	affected destinations to which they actually communicate.
> 	The SGP M3UA layer MAY also suppress DUPU messages to ASPs
> 	that do not implement an MTP3-User protocol peer for the
> 	affected MTP3-User."
> 
>     This sounds rather peculiar since the MTP3 at the SGP will
>     likely perform this filtering by way of its routing and
>     screening tables.  This is a function which normally sits below
>     the MTP-User interface.  What was the purpose of adding this
>     text?  Remove this text.
> 
> Section 4.3.1
> 
> 	"DUNA, DAVA, SCON, and DRST messages MUST be sent
> 	sequentially and processed at the receiver in the order
> 	sent.  SCTP stream "0" is used to provide the sequencing.
> 	The only exception to this is if the international
> 	congestion method (see Q.704) is used.  If so, the Unordered
> 	bit in the SCTP DATA chunk MAY be used for the SCON
> 	message."
> 
>     Even SS7 permits TFA/TFR/TFP/TFC to be sent unsequenced.  This
>     is because there are responsive procedures which will soon
>     correct a reversal of the messages.  For congestion, adequate
>     hysteresis is provided to avoid problems due to message
>     reversal.  This text should be reworded to reflect this
>     situation.  The "MUST" should be changed to a "MAY" and the
>     reference to international congestion removed.
> 
> Section 4.3.2.1
> 
> 	"In the case where a local event has caused the
> 	unavailability or congestion status of SS7 destinations, the
> 	M3UA layer at the ASP MUST pass up appropriate indications
> 	in the primitives to the M3UA User, as though equivalent
> 	SSNM messages were received.  For example, the loss of an
> 	SCTP association to an SGP may cause the unavailability of a
> 	set of SS7 destinations.  MTP-PAUSE indication primitives to
> 	the M3UA User are appropriate.  To accomplish this, the M3UA
> 	layer at an ASP maintains the status of routes via the
> 	SG(P), much like an MTP3 layer maintains route-set status."
> 
>     There is no way of enforcing this "MUST" without defining which
>     actions are "appropriate" for each local event.  Furthermore,
>     this does not address interoperability of the protocol and is
>     an implementation decision.  Change "MUST" to "SHOULD".
> 
>     The last sentence is an implementation suggestion and should be
>     marked as an IMPLEMENTATION NOTE.
> 
> Section 4.3.2.2
> 
> 	"An M3UA layer at the ASP MAY choose to maintain knowledge
> 	of which SGPs are included in Signalling Gateways for the
> 	purpose of interpreting SSNM messaging from one SGP so as to
> 	apply to all the SGPs in the SG."
> 
>     This "MAY" does not speak well to interoperability between
>     independent SGP and ASP implementations.  Surely the SGP must
>     know what the effect of an SNMM sent to an ASP will be in terms
>     of the other SGPs in the SG.  This "optional" mode of operating
>     provides one more "a priori" thing that the SGP must know about
>     the ASP.
> 
>     What happens when the ASP receives conflicting information from
>     separate SGP within the same SG?
> 
>     Remove this option for the sake of interoperability.
> 
> Section 4.3.3
> 
> 	"In the first of the cases above, the auditing  procedure
> 	must not be invoked for the case of a received SCON message
> 	containing a congestion level value of "no congestion" or
> 	undefined" (i.e., congestion Level = "0"). ...
> 
>     What is the draft trying to get at here?
> 
> Section 4.3.3
> 
> 	"The SGP MUST respond to a DAUD message with the MTP3
> 	availability/congested status of the routeset associated
> 	with each Destination Point Code(s) in the DAUD message.
> 	..."
> 
>     This is problematic in the case that the DAUD message if for a
>     destination to which the SGP has no route (as opposed to a
>     destination to which the SGP has a route, but which is currently
>     unavailable).  This is also a security issue in that an ASP
>     should not be empowered to be able to inquire as to the status
>     of all possible destinations: only destinations to which the ASP
>     has authorized routes.
> 
> 
> Grammar:
> 
>     Section 1.3.2.4, first paragraph, change "in order to" to "to".
>     Section 1.3.2.4, second paragraph, change "In order to" to "to".
>     Section 1.4.2.4, first paragraph, change "In order to" to "To".
>     Section 1.4.2.5, first paragraph, change "In order to" to "To"
>     and "in order to" to "to".
>     Section 1.4.3.2, second paragraph, change both instances of "in
>     order to" to "to".
>     Section 1.4.4, first paragraph, change "in order to" to "to".
>     Section 1.4.5, first paragraph, change "in order to" to "to".
>     Section 1.4.7, second paragraph, change "in order to" to "to".
>     Section 3.4.1, first paragraph, change "in order to" to "to".
>     Section 3.4.4, sixth paragraph, change "in order to" to "to".
>     Section 3.8.2, fifteenth paragraph, change "in order to" to "to".
>     Section 4.2.3.4, sixteenth paragraph, change "in order to" to "to".
>     Section 4.3.3, first paragraph, change "in order to" to "to".
> 
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> 
> ---
> 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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA Changes : 6 vs 7
Date: Wed, 11 Jul 2001 09:06:31 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail4.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail4.rdc1.on.home.com [24.2.9.91]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings,

Here is my summary of the main protocol changes in Issue 7.

  - Added a Signalling Gateway definition that was noted as missing.

  - Changed procedures to reflect agreement that the ASP has routes to SGPs
instead of SGs.

  - Changed Network Appearance definition to one proposed by Norm and
discussed on list - aligned with SUA.

  - Now allow "overlapping" routing keys in registration - changed REG RESP
failure reason to "cannot support unique routing".  This allows SG to decide
whether it can configure a particular routing key, based on its
capabilities.

  - Lined up client/server text with M2UA (Section 1.4.8)

  - Added requested Layer management primitives for registration/dereg, and
added a missing indication primitive.

  - Editorial change to use consistent primitive, message and state name
formats.

  - Separated parameter Tag assignment into common and M3UA-specific ranges
as agreed in Minneapolis. Changed Tag values for all M3UA-specific Tag
values.

  - Changed ASP-Down Ack response to ASP-Up to an Error message (Error Code
= Refused - Management Blocking) as agreed on list.  Added that this Error
response could be to ASP-Active as well.

  - Added Traffic Mode Type to Registration Message as agreed in Minneapolis

  - Response to ASP-Up received from "active" ASP changed so that state is
reset to "inactive" - previously no state change.

  - Added procedure to clarify the case of an SCTP Restart indication
primitive (move ASP to ASP-DOWN state and start recovery)

  - added some IPSP-to-IPSP protocol clarifications for the ASP-Up
procedures.

  - Clarified that an ASP should deregister before sending ASP-DOWN.  Also
the ASP should become inactive in a RC before deregistering.

  - Clarified that an ASP-Active ("standby") received for an AS that has no
active ASPs will take the ASP to the active state right away.

  - Clarified that Notify messages must be sent AFTER any related ASPSM or
ASPTM messages (Bay-cough issue)

  - Clarified response to DAUD messages when there are congested
destinations (list discussion).

  - Clarified actions in the event of MTP Restart

  - Added newly assigned M3UA port number (2905) assignment

I did not include the following changes in Issue 7 as I felt uncomfortable
declaring consensus - these should be brought up as letter ballot comments:

   - adding of an ASP Id parameter as in M2Ua.  Need to review procedures.

   - Adding of new broadcast traffic modes (could be an extension draft
though)

   - Didn't remove standby modes - really wanted to delete but did not see
consensus

   - Didn't delete SCON from ASP to SGP - wanted to delete but did not see
consesnsus

   - Network Appearance not replaced with Routing Context - Looks workable
except for at REG REQ.  Need to study some more.

Hope this helps,

  Greg

----- Original Message -----
From: "Greg Sidebottom" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Monday, July 09, 2001 12:36 PM
Subject: Re: M3UA Changes : 6 vs 7

> Greetings,
>
>    Yes, I'll provide a change summary later on tonight.
>
> Cheers,
>
>    Greg
>
> ----- Original Message -----
> From: "Srivats P." <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Monday, July 09, 2001 12:00 AM
> Subject: M3UA Changes : 6 vs 7
>
>
> > Greg,
> >
> > Could you send over a summary of the changes
> > between ver 6 and ver 7 ?
> >
> > A MS-Word "comparison" document might also
> > be useful. If I remember correctly, you once
> > offerred something similar ...
> >
> > Regards,
> > Srivats P.
> >
> >
> >
> > ---
> > 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Wed, 11 Jul 2001 10:54:04 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: RE: M3UA - DEREG Results
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Maria,

I agree with your proposal.  The message diagrams should be update to
clearly show the use of the 0x88/0x89 tags.  

To answer your question below, the document says "MAY" because the SG does
not have to respond to a REG REQ with a single REG RSP.  For example, it can
send a REG RSP for each Routing Key.  Maybe we should add a sentence that
clarifies the "MAY"?

Regards,

Ken

At 05:32 PM 7/10/01 +0200, Maria-Cruz Bartolome-Rodrigo (ECE) wrote:
>Hi Greg,
>
>As I understand from the draft the REG/DEREG RSP is the following:
>
>REG/DEREG RSP msg  ---|-- Reg/Deregistration ResultS (Tag=0x90/0x91)
>                                   (only 1 parameter per message?)
>
>                                         |-- Reg/Deregistration Result
(tag=0x88/0x89)                                   |
>                                         |-- Reg/Deregistration Result
(tag=0x88/0x89)
>Reg/Deregistration ResultS ---|--       ....
>                                         |-- Reg/Deregistration Result
(tag=0x88/0x89)
>                                         |-- Reg/Deregistration Result
(tag=0x88/0x89)
>                                             (from 1 to N parameters)
>
>
>The proposal would be the following:
>
>                                 |-- Reg/Deregistration Result
(tag=0x88/0x89)                                   |
>                                 |-- Reg/Deregistration Result
(tag=0x88/0x89)
>REG/DEREG RSP msg    ---|--     ....
>                                 |-- Reg/Deregistration Result
(tag=0x88/0x89)
>                                 |-- Reg/Deregistration Result
(tag=0x88/0x89)
>                                     (from 1 to N parameters)
>
>In this way two parameters could be saved (Reg/Deregistration ResultS),
>that means 1 tag/length saved, and the message is better structured. 
>I honestly think everybody will agree about that, unless there is a
>reason I do not know to have these 'container' parameter (Reg/Dereg
ResultS).
>
>One more thing, in the explanation of 'Registration Results':
>'...The number of results in a single REG RSP message MAY match the 
>number of Routing Key parameters found in the corresponding REG REQ
message'
>Shouldn't that MAY be replaced by MUST??
>
>Thanks
>/MCruz
>
>-----Original Message-----
>From: Greg Sidebottom [mailto:[email-masked]]
>Sent: Friday, July 06, 2001 2:45 AM
>To: sigtran
>Subject: Re: M3UA - DEREG Results
>
>
>Hi Maria-Cruz,
>
>I really don't know which approach is "easier" or "simpler" - I'll let the
>implementors out there tell me their preference.  I don't remember the
>REG/DEREG RSP format being given any real deep thought when we worked it
>out - I suppose the current format saves a few Tag/Length bytes when there
>are multiple results.  But if it is ugly or harder to process then I have
no
>problem changing it.
>
>Cheers,
>
>Greg Sidebottom
>[email-masked]
>
>----- Original Message -----
>From: "Maria-Cruz Bartolome-Rodrigo (ECE)"
><[email-masked]>
>To: "sigtran" <[email-masked]>
>Sent: Thursday, July 05, 2001 3:27 PM
>Subject: RE: M3UA - DEREG Results
>
>
> >
> > Hi Greg,
> >
> > In issue 6 both messages (REG RSP and DEREG RSP) do have only one
> > parameter ('Registration Results' and 'De-registration Results'),
> > that's right, but being those made up of multiple like parameters
> > I do not think it makes things easier at all, on the contrary
> > I find that the proposal below will simplify these messages and
> > we will get rid of two parameters that are mainly sub-parameter
> > containers and rather useless.
> >
> > What are the advantages of the actual format?
> > I may misundertand something...
> >
> > Thanks
> > /MCruz
> >
> >
> >
> > -----Original Message-----
> > From: Greg Sidebottom [mailto:[email-masked]]
> > Sent: Thursday, July 05, 2001 5:13 AM
> > To: sigtran
> > Subject: Re: M3UA - DEREG Results
> >
> >
> > Hi Maria-Cruz,
> >
> > I read Ben's e-mail before but seeing as nobody supported it I didn't
make
> > the change in Issue 7.  I had input from one person off-line who didn't
>like
> > the general idea of multiple like parameters in the same message.   But
if
> > there is support for this I have no problem at all to make the change.
> >
> > Cheers,
> >
> >    Greg
> >
> > ----- Original Message -----
> > From: "Maria-Cruz Bartolome-Rodrigo (ECE)"
> > <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Monday, July 02, 2001 9:44 AM
> > Subject: RE: M3UA - DEREG Results
> >
> >
> > >
> > > Hi Greg,
> > >
> > > I recall the mail below sent a long time ago.
> > > I checked the e-mail list but I couldn't find an answer to it.
> > > I have the same doubt as Ben had and his proposal sounds reasonable
> > > to me.
> > >
> > > What's your opinion about that?
> > >
> > > Cheers
> > > /MCruz
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Benjamin J. Wilson,,, [mailto:[email-masked]]
> > > Sent: Tuesday, April 03, 2001 10:16 PM
> > > To: sigtran
> > > Subject: DEREG Results
> > >
> > >
> > > Greg/Norm,
> > >
> > > Might I suggest a bit of cleanup to the DEREG RSP and REG RSP?
> > >
> > > It seems a DEREG RSP contains 1 DEREG RESULTS parameter which
> > > itself contains many DEREG RESULT (singular) parameters.  It's not
> > > clear from the text b/c no tag is in the diagram, but there is a
> > > tag for it in the list of parameter ids at the beginning.
> > >
> > > Since REG REQ has many Routing Key parameters it seems the DEREG
> > > RESULTS parameter can be eliminated and the DEREG RSP could just
> > > contain many DEREG RESULT parameters.
> > >
> > > Hopefully this makes sense.
> > >
> > > Ben
> > >
> > >
> > >
> > > ---
> > > 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]
> >
> >
> > ---
> > 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]
>
>
>---
>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]
To: "sigtran" <[email-masked]>
Date: Wed, 11 Jul 2001 09:05:49 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: M2UA Last Call
X-Sender-Ip: 63.96.78.248
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

M2UA appears to be ready for WG Last Call.  If there are no objections, I
would like to start Last Call on Monday, July 16th, going until Friday, July
27th.

I would like to trial a tighter Last Call procedure, if people agree: --
let's try to get all of our comments in during the Last Call period --
before sending your comment on the list, send Ken and me an email and we
will assign a number to the comment, so that we can keep better track of the
comments and their resolution.

Cheers,

L. Ong

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: Routing Key Management procedure
Date: Wed, 11 Jul 2001 16:08:44 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail1.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail1.rdc1.on.home.com [24.2.9.88]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Nitin,

Thanks for the comments - I was hoping someone else would respond as
REG/DEREG is not my "cup-of-tea" but no such luck!

Responses below ...

----- Original Message -----
From: "Tomar, Nitin" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Tuesday, July 03, 2001 9:14 PM
Subject: RE: M3UA06: Routing Key Management procedure

>
> Greg,
>
>    Re-sending this mail and awaiting answer for these.
>
>  regards
> - Nitin
>
> -----Original Message-----
> From: Tomar, Nitin [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 6:48 PM
> To: sigtran
> Subject: M3UA06: Routing Key Management procedure
>
>
> Greg,
>
> I have few queries/comments on Routing key procedure.
>
> - Nitin.
>
> 1. Is RKM procedure valid for IPSP-IPSP communication as well? In either
> case I think the draft can specify it clearly in section 3.5.5 and related
> sections. If RKM is allowed for IPSP-IPSP scenario, can client and server
> both initiate REG-REQ and DEREG-REQ messages, I do not find any reason
> they should not do so.

[Greg] I agree that RKM should be possible for IPSP-to IPSP but this is not
an
application that I have an interest.  I'm not sure though that it makes
sense
to register in both directions point-to-point to set up a two way
communication.  I see that currently ASPs use the REG REQ to set-up two way
traffic with the SG - the SG doesn't need a separate procedure to register
for
which traffic it wants from the ASP, as it is usually related.  But I
suppose there
could be an application to Register in both directions to set up two sets of
two-way traffic beween IPSPs.  Do people need this described?

>
> 2. De-registration request for RK not registered through REG REQ message
is
> valid or not? lets say RK was statically configured at an SG which
supports
> both static and dynamic configuration of RKs.

[Greg] I don't think so, but it is really up to the configuration manager.
When we first put together the registration protocol we (the authors) agreed
that an SG would need to police whether the ASP is allowed to change a
particular piece of configuration data.  If the piece of configuration data
(RK) was "statically" created by a local mangement system, as opposed to
created based on a REG REQ, then an ASP sending a DEREG should not cause
deletion of the entry or RK.

It is possible that SGs could have features that will allow a lot of
flexibility here, such as allowing a new ASP to register/deregister
dynamically on a
statically defined RK, but I don't think we need to go there with the
protocol.  Perhaps the best way out is to have the configuration manager
decide whether to honor the DEREG REQ, based on the present RK data

>
> 3. In section 4.3.4.1 and 4.3.4.2, The draft does not specifies any timers
> associated with the REG REQ and DEREG REQ messages, I think there is a
need
> for timers for RKM messages, as an ASP can not wait indefinitely for the
REG
> RSP if SG decides to respond to REG REQ containing multiple RKs with
> multiple REG RSP messages'
>
> The timer can be similar to what we have for ASPM messages, something like
> this:
>
> 'When ASP sends an REG REQ it starts timer T(RK-ack). If the ASP does not
> receive a response to REG REQ within T(RK-ack), the ASP may restart
> T(RK-ack) and resend REG REQ messages until it receives an REG REQ
message.
> T(RK-ack) is provisionable, with a default of n seconds. Alternatively,
> retransmission of REG RSP messages may be put under control of Layer
> Management'
>

[Greg] Actually I think that these timers of marginal use, allowing the
resending of a message for which there is no response.  I see it as useful
for ASP Up/Down, and for ASP Active/Inact and REG/DEREG when there is only
one contained request (e.g., RK/RC).  But for ASP Active/Inact and REG/DEREG
with more than one request, they are not very useful.  Robust
implementations should probably run a timer per request (RK or RC), not per
message.  An implemenation can't leave these requests open indefinitely - if
there is no reponse to a request the application will have to take action to
retry or close it.  Per this text, and the current ASP Active text, if a REG
RESP is received containing a result for only one of two requests, then the
Timer is cancelled and we still have an outstanding request.  There are also
I think possible cases where a "response" is ambiguous, at least for ASP
Active messages that are errored.

So I think we have a couple of options: 1) add REG/DEREG timers ) on a
per/transaction basis (and change ASP-Active/Inactive timers), 2) remove the
explicit message timers and add text saying that the sending application
should run a timer to close/resend each request, or 3) remove the text.
Views?

> 4. Can a ASP is authorized to send REG-REG only and not authorized to
> send DEREG-REQ, in either case the draft can specify it clearly in
> section 4.3.4.2.
>

[Greg] I hope not.  Anyway the SG is currently allowed to refuse a REG or
DEREG.  If there is an application where it is useful to accept one but not
the other, I'd see this as a ploicy decision at the SG.  I don't think we
need to cover this in the protocol.

> 5. Figure for "Routing Key" parameter description can be modified to
> indicate the Network Appearance (optional) as first parameter. [To comply
> with section 3.3.1 stating 'Where the optional Network Appearance
parameter
> is present, it must be the first parameter in the message']

[Greg] Yes this is inconsistent.  I've also had the view expressed to me
that the Network Appearance shouldn't be first in the DATA message either as
it is technically an optional parameter and the Protocol Data parameter is
mandatory.  For some people, mandatory parameters should come first before
any optional parameters (like in SS7).  We should sort this out once and for
all for Issue 8 - IMHO it should be first in both RK and DATA (when present)
as suggested here but I'll do whatever the decoders feel is best.

Of course there is a proposal from Brian to replace the NA everywhere with
an RC - we should sort that idea out as well - see this thread.

>
> 6. The 'Registration Status' parameter values in REG RSP message need one
> more type of error value : 'Multiple SI not supported' as none of the
> existing error value cover this [In case SG optionally support only one SI
> in a Routing key as per section 1.4.2.2].
>

[Greg} I can add this. Actually there are a few more error values that
probably make sense. - "Invalid SI" , OPC, CIC Range, SSN", for example.
Others?

> 7. Section 3.5.5, 3.5.6, 3.5.7 and 3.5.8 numbering is duplicated.

[Greg] hopefully this is fixed in Issue 7 - no guarantees though!

Thanks Again,

     Greg

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA Changes : 6 vs 7
Date: Wed, 11 Jul 2001 16:13:50 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail1.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [24.2.9.88]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings,

I have a marked up MS-Word version of Issue 6 showing (almost) all the
changes to Issue 7.  E-mail me directly if you wish a copy and I can send it
to you.

Cheers,

   Greg
----- Original Message -----
From: "Srivats P." <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Monday, July 09, 2001 12:00 AM
Subject: M3UA Changes : 6 vs 7

> Greg,
>
> Could you send over a summary of the changes
> between ver 6 and ver 7 ?
>
> A MS-Word "comparison" document might also
> be useful. If I remember correctly, you once
> offerred something similar ...
>
> Regards,
> Srivats P.
>
>
>
> ---
> 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]
Date: Wed, 11 Jul 2001 15:28:56 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M3UA07 Comments
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.251]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Michael,

See the thread "Packing of DATA Payloads".

--Brian

Tuexen Michael wrote:                                      (Wed, 11 Jul 2001
14:12:00)

[snip]
> >     o   DATA payload formats.
> 	[Tuexen Michael]  In my understanding the MTP3 packet is transported
as
> 	a sequence of bytes. So no modification is done. If you internally
> 	handle the routing label differently how MUST send it out as
described
> 	in Q.70? series.
[snip]

-- 
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: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: MTU Fragmentatiion of control chunks
Date: Wed, 11 Jul 2001 15:49:58 -0500
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-dax1.ext.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.78.179.216]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

The idea is to support fragmentation of INIT_ACK chunk which may contain a
long list of IP addresses reported by the peer endpoint.

I would suggest that :

As in INIT and INIT ACK the chunk_flag field is reserved and ignored by the
receiver - it can be used to carry the fragmentation information - just like
in the DATA chunk
So :

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 2    | Reserved  |B|E|    Length                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   An unfragmented user message shall have both the B and E bits set to
   '1'.  Setting both B and E bits to '0' indicates a middle fragment of
   a multi-fragment user message, as summarized in the following table:

            B E                  Description
         ============================================================
         |  1 0 | First piece of a fragmented user message          |
         +----------------------------------------------------------+
         |  0 0 | Middle piece of a fragmented user message         |
         +----------------------------------------------------------+
         |  0 1 | Last piece of a fragmented user message           |
         +----------------------------------------------------------+
         |  1 1 | Unfragmented Message                              |
         ============================================================
         |             Table 1: Fragment Description Flags          |
         ============================================================

And then these flags can be used at the receving endpoint to re-assemble the
complete INIT_ACK chunk information.

-Rgds

!    -----Original Message-----
!    From: ext Dinesh JN [mailto:[email-masked]] !    Sent: 11
July, 2001 4:49 AM
!    To: sigtran
!    Subject: MTU Fragmentatiion of control chunks !    
!    
!    In RFC 2960
!    
!       we have come across this note in RFC 2960 !    
!       IMPLEMENTATION NOTE: An implementation MUST be prepared !    to
receive a
!       INIT ACK that is quite large (more than 1500 bytes) due to the !
variable size of the state cookie AND the variable !    address list.  For
!       example if a responder to the INIT has 1000 IPv4 !    addresses it
wishes
!       to send, it would need at least 8,000 bytes to encode !    this in
the
!       INIT ACK.
!    
!       the fragmentation of Data chunk is very clear,but in !    cases
above note,
!    the size of the INIT CHUNK will be exceeding 1500 MTU, so !    how
these chunks
!    have to be handle
!    
!    
!    thanx in advance
!    Dinesh
!    
!    
!    
!    ---
!    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]
Date: Wed, 11 Jul 2001 16:36:10 -0500
From: Qiaobing Xie <[email-masked]>
X-Mailer: Mozilla 4.77 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: MTU Fragmentatiion of control chunks
X-SMTP-HELO: motgate.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate.mot.com [129.188.136.100]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Shivani,

Supporting user data fragmentation and reassembly in SCTP is for network
efficiency. I don't see how you can justify the complexity of supporting
INIT/INIT_ACK fragmentation since these chunks are only exchanged once at
the setup of an association.

-Qiaobing

[email-masked] wrote:
> 
> The idea is to support fragmentation of INIT_ACK chunk which may contain a
> long list of IP addresses reported by the peer endpoint.
> 
> I would suggest that :
> 
> As in INIT and INIT ACK the chunk_flag field is reserved and ignored by
the
> receiver - it can be used to carry the fragmentation information - just
like
> in the DATA chunk
> So :
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |   Type = 2    | Reserved  |B|E|    Length                     |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>    An unfragmented user message shall have both the B and E bits set to
>    '1'.  Setting both B and E bits to '0' indicates a middle fragment of
>    a multi-fragment user message, as summarized in the following table:
> 
>             B E                  Description
>          ============================================================
>          |  1 0 | First piece of a fragmented user message          |
>          +----------------------------------------------------------+
>          |  0 0 | Middle piece of a fragmented user message         |
>          +----------------------------------------------------------+
>          |  0 1 | Last piece of a fragmented user message           |
>          +----------------------------------------------------------+
>          |  1 1 | Unfragmented Message                              |
>          ============================================================
>          |             Table 1: Fragment Description Flags          |
>          ============================================================
> 
> And then these flags can be used at the receving endpoint to re-assemble
the
> complete INIT_ACK chunk information.
> 
> -Rgds
> 
> !    -----Original Message-----
> !    From: ext Dinesh JN [mailto:[email-masked]]
> !    Sent: 11 July, 2001 4:49 AM
> !    To: sigtran
> !    Subject: MTU Fragmentatiion of control chunks
> !
> !
> !    In RFC 2960
> !
> !       we have come across this note in RFC 2960
> !
> !       IMPLEMENTATION NOTE: An implementation MUST be prepared
> !    to receive a
> !       INIT ACK that is quite large (more than 1500 bytes) due to the
> !       variable size of the state cookie AND the variable
> !    address list.  For
> !       example if a responder to the INIT has 1000 IPv4
> !    addresses it wishes
> !       to send, it would need at least 8,000 bytes to encode
> !    this in the
> !       INIT ACK.
> !
> !       the fragmentation of Data chunk is very clear,but in
> !    cases above note,
> !    the size of the INIT CHUNK will be exceeding 1500 MTU, so
> !    how these chunks
> !    have to be handle
> !
> !
> !    thanx in advance
> !    Dinesh
> !
> !
> !
> !    ---
> !    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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: MTU Fragmentatiion of control chunks
Date: Wed, 11 Jul 2001 16:42:33 -0500
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-dax1.ext.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.78.179.216]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Yes I agree.

-Rgds

!    -----Original Message-----
!    From: ext Qiaobing Xie [mailto:[email-masked]] !    Sent: 11 July,
2001 2:36 PM
!    To: sigtran
!    Subject: Re: MTU Fragmentatiion of control chunks !    
!    
!    Shivani,
!    
!    Supporting user data fragmentation and reassembly in SCTP !    is for
network
!    efficiency. I don't see how you can justify the complexity !    of
supporting
!    INIT/INIT_ACK fragmentation since these chunks are only !    exchanged
once
!    at the setup of an association.
!    
!    -Qiaobing
!    
!    [email-masked] wrote:
!    > 
!    > The idea is to support fragmentation of INIT_ACK chunk !    which may
contain a
!    > long list of IP addresses reported by the peer endpoint.
!    > 
!    > I would suggest that :
!    > 
!    > As in INIT and INIT ACK the chunk_flag field is reserved !    and
ignored by the
!    > receiver - it can be used to carry the fragmentation !    information
- just like
!    > in the DATA chunk
!    > So :
!    > 
!    >        0                   1                   2 !              3
!    >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 !    5 6 7 8
9 0 1
!    >       
!    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !
>       |   Type = 2    | Reserved  |B|E|    Length !                 |
!    >       
!    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !
!    > 
!    >    An unfragmented user message shall have both the B !    and E bits
set to
!    >    '1'.  Setting both B and E bits to '0' indicates a !    middle
fragment of
!    >    a multi-fragment user message, as summarized in the !    following
table:
!    > 
!    >             B E                  Description !    >          
!    ============================================================ !    >
|  1 0 | First piece of a fragmented user !    message          |
!    >          
!    +----------------------------------------------------------+ !    >
|  0 0 | Middle piece of a fragmented user !    message         |
!    >          
!    +----------------------------------------------------------+ !    >
|  0 1 | Last piece of a fragmented user !    message           |
!    >          
!    +----------------------------------------------------------+ !    >
|  1 1 | Unfragmented Message !               |
!    >          
!    ============================================================ !    >
|             Table 1: Fragment Description !    Flags          |
!    >          
!    ============================================================ !    > 
!    > And then these flags can be used at the receving !    endpoint to
re-assemble the
!    > complete INIT_ACK chunk information.
!    > 
!    > -Rgds
!    > 
!    > !    -----Original Message-----
!    > !    From: ext Dinesh JN [mailto:[email-masked]] !    > !
Sent: 11 July, 2001 4:49 AM !    > !    To: sigtran
!    > !    Subject: MTU Fragmentatiion of control chunks !    > !
!    > !
!    > !    In RFC 2960
!    > !
!    > !       we have come across this note in RFC 2960 !    > !
!    > !       IMPLEMENTATION NOTE: An implementation MUST be prepared !
> !    to receive a
!    > !       INIT ACK that is quite large (more than 1500 !    bytes) due
to the
!    > !       variable size of the state cookie AND the variable !    > !
address list.  For
!    > !       example if a responder to the INIT has 1000 IPv4 !    > !
addresses it wishes
!    > !       to send, it would need at least 8,000 bytes to encode !    >
!    this in the
!    > !       INIT ACK.
!    > !
!    > !       the fragmentation of Data chunk is very clear,but in !    > !
cases above note,
!    > !    the size of the INIT CHUNK will be exceeding 1500 MTU, so !    >
!    how these chunks
!    > !    have to be handle
!    > !
!    > !
!    > !    thanx in advance
!    > !    Dinesh
!    > !
!    > !
!    > !
!    > !    ---
!    > !    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] !    
!    
!    ---
!    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]
Sender: [email-masked]
Date: Wed, 11 Jul 2001 18:05:39 -0400
From: John Linton <[email-masked]>
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
CC: [email-masked]
Subject: comments on <draft-ietf-sigtran-sctp-mib-04.txt>
X-SMTP-HELO: rtp-msg-core-1.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: rtp-msg-core-1.cisco.com [161.44.11.97]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Sorry for my delay in reviewing the MIB I was out on vacation last week when
the draft was issued.

Here are my comments.

Global:

- The file contains several lines that exceed 72 characters. 

Line:193 change " nd" -> " and"
          first version of the SNMP message protocol is called SNMPv1 nd

Line: 411 fix format of comment.
    |      | sctpAssocRemAddressMaxPathRtx \  ... |   |

Line: 484

    All the lookup tables contains the time to identify when a row in the
    table was created.

    change to 

    All the lookup tables contains a timestamp to indicate when a row in
    the table was created.

Line: 453 Table has indexes ctpAssocId,  
                            sctpAssocLocalAddressIPType,
                            sctpAssocLocalAddressIP,

 3.1.2.1.1 Local IP addresses Table

    Table for local IP addresses information. This table stores
    information related to the local IP address/-es reserved for the
    association. It's indexed by the local IP addresses.

Line: 459 Table has indexes sctpAssocId,   -- shared index
                            sctpAssocRemAddressIPType,
                            sctpAssocRemAddressIP }  3.1.2.1.2 Remote IP
addresses Table

    Table for remote IP addresses information. This table stores
    information related to the remote IP address/-es reserved for the
    association. It's indexed by the remote IP addresses.

Line: 465 There are now five reverse lookup tables  3.1.2.2  Reverse Lookup
Tables

    There is also one reverse lookup table . This is an optional table to
    help management applications efficiently access conceptual rows in
    other tables. This is the way for not performing expensive tree walks
    through large number of associations.
 
  change to
 
    There are five reverse lookup table . These are optional tables to
    help management applications efficiently access conceptual rows in
    other tables. This is the way for not performing expensive tree walks
    through large number of associations.

Line: 495 Missing bullet/description for Remote IP Address lookup table
       -  Remote Primary IP Address: It allows to find the associations
          that have defined the specified remote IP address as primary.

Line: 502 Missing table for other lookup tables

Line: 558 InetPortNumber is not defined in INET-ADDRESS-MIB.
      InetAddressType, InetAddress, InetPortNumber
           FROM INET-ADDRESS-MIB         -- RFC2851

Line: 870,  reword to match sent descriptions 

    sctpStatRecCtrlChunks OBJECT-TYPE
      SYNTAX         Counter64
      MAX-ACCESS     read-only
      STATUS         current
      DESCRIPTION
           "Number of SCTP control chunks received from the peers (no
           duplicated included)."

      ::= { sctpScalars 18 }
     
    change  (no duplicated included)."
    to      (no retransmissions included)."

Line: 881  reword to match sent descriptions   
    sctpStatRecOrderChunks OBJECT-TYPE
      SYNTAX         Counter64
      MAX-ACCESS     read-only
      STATUS         current
      DESCRIPTION
           "Number of SCTP ordered data chunks received from the peers
           (no duplicated included)."

      ::= { sctpScalars 19 }

    change  (no duplicated included)."
    to      (no retransmissions included)."

Line: 892 reword to match sent descriptions
    sctpStatRecUnorderChunks OBJECT-TYPE
      SYNTAX         Counter64
      MAX-ACCESS     read-only
      STATUS         current
      DESCRIPTION
           "Number of SCTP unordered chunks (data chunks in which the U
           bit is set to 1) received from the peers (no duplicated
           included)."

      ::= { sctpScalars 20 }

    change  (no duplicated included)."
    to      (no retransmissions included)."

Line: 1193 correct reference
 sctpAssocMaxRetr 

      DESCRIPTION
           "The maximum number of data retransmissions in the association
           context. This value is specific for each association and the
           upper layer can change it calling the appropriate primitives.
           This value has to be smaller than the addition of all the
           maximum number for all the paths
           (sctpAssocRemAddressMaxPathRetrans).
           Recommended value: 10 attempts."

    Change (sctpAssocRemAddressMaxPathRetrans) to
           (sctpAssocRemAddressMaxPathRtx)

     DESCRIPTION
           "The maximum number of data retransmissions in the association
           context. This value is specific for each association and the
           upper layer can change it calling the appropriate primitives.
           This value has to be smaller than the addition of all the
           maximum number for all the paths
           (sctpAssocRemAddressMaxPathRtx).
           Recommended value: 10 attempts."

      ::= { sctpAssocEntry 12 }

Line: 1281 reword 

    sctpAssocLocalAddressTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF SctpAssocLocalAddressEntry
      MAX-ACCESS     not-accessible
      STATUS         current
      DESCRIPTION
           "Expanded table of sctpAssocTable based on the AssocId index.
            It shows several interesting data for each local address which
           takes part in this association."

      change to 

      DESCRIPTION
          "Expanded table of sctpAssocTable based on the sctpAssocId 
           index. This table shows data related to each local IP address 
           which is used by this association."

Line:1371
  sctpAssocRemAddressTable 
      DESCRIPTION
           "Expanded table of sctpAssocTable based on the AssocId index.
           It shows several interesting data for each remote peer IP
           address which is used in this association."
  change to 
      DESCRIPTION
           "Expanded table of sctpAssocTable based on the sctpAssocId 
           index. This table shows data related to each remote peer IP 
           address which is used by this association." Line: 1398

    sctpAssocRemAddressEntry OBJECT-TYPE
      SYNTAX         SctpAssocRemAddressEntry
      MAX-ACCESS     not-accessible
      STATUS         current
      DESCRIPTION
           "Information about THE most important variables for every
           remote IP address "

  change to

      DESCRIPTION
           "Information related to the remote IP addressed used 
            by this asssocation"

Line 1406:
    SctpAssocRemAddressEntry ::= SEQUENCE {
      sctpAssocRemAddressIPType          InetAddressType,
      sctpAssocRemAddressIP              InetAddress,
      sctpAssocRemAddressStatus          INTEGER,
      sctpAssocRemAddressHBFlag          INTEGER,
      sctpAssocRemAddressRTO             Unsigned32,
      sctpAssocRemAddressMaxPathRtx Unsigned32,
      sctpAssocRemAddressRtx        Counter64,     -- Statistic
      sctpAssocRemAddressStartTime  

reformat to 

    SctpAssocRemAddressEntry ::= SEQUENCE {
      sctpAssocRemAddressIPType          InetAddressType,
      sctpAssocRemAddressIP              InetAddress,
      sctpAssocRemAddressStatus          INTEGER,
      sctpAssocRemAddressHBFlag          INTEGER,
      sctpAssocRemAddressRTO             Unsigned32,
      sctpAssocRemAddressMaxPathRtx      Unsigned32,
      sctpAssocRemAddressRtx             Counter64,     -- Statistic
      sctpAssocRemAddressStartTime       TimeStamp
      }

Line: 1481 Should this be defined as a TruthValue
          Also the default should be true as specified in the [sctp]
          as follows.
 
          8.3 Path Heartbeat

          By default, an SCTP endpoint shall monitor the reachability of the
          idle destination transport address(es) of its peer by sending a 
          HEARTBEAT chunk periodically to the destination transport
          address(es).

    sctpAssocRemAddressHBFlag OBJECT-TYPE
      SYNTAX         INTEGER {
                          active(0),
                          inactive(1)
                      }
      MAX-ACCESS     read-only
      STATUS         current
      DESCRIPTION
           "The optional Heartbeat associated to one destination
           transport address could be active or not (value equal to 0 or
           1, respectively).
           An active destination transport address is the one considered
           available by a peer endpoint for receiving SCTP packets, as it
           is described in [sctp]."

      ::= { sctpAssocRemAddressEntry 4 }

    Change to    

    sctpAssocRemAddressHBFlag OBJECT-TYPE
      SYNTAX         TruthValue
      MAX-ACCESS     read-only
      STATUS         current
      DESCRIPTION
           "Indicate whether the association will monitor the 
            status of idle remote addresses as specified in 
            section 8.3 [sctp].

            'true'  - Heartbeating is enabled for this remote 
                      IP address.
            'false' - Heartbeating is disable for this remote 
                      IP address."

      ::= { sctpAssocRemAddressEntry 4 }

Line: 1537 The Units are unclear in this defintion.
      are we count failed packets or chunks?

    sctpAssocRemAddressRtx OBJECT-TYPE
      SYNTAX         Counter64
      MAX-ACCESS     read-only
      STATUS         current
      DESCRIPTION
           "Number of DATA retransmissions as defined in [sctp]."

      ::= { sctpAssocRemAddressEntry 7 }

General comments on lookup tables:
These tables seem to be provided to assist the managements stations in
collecting information that could be determine from a walk of the
associations table. I understand the need to provide information to the
management stations. However, the management stations generally have less
restrictions than routing devices. Using standard classes provided by C++ or
Java or any Data base I can easily construct code to provide the function of
these tables.

Line: 1573 updated description
    sctpLookupLocalPortTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF SctpLookupLocalPortEntry
      MAX-ACCESS     not-accessible
      STATUS         current
      DESCRIPTION
           "This table allows management stations to determine which
            associations are using a particular local port without
            having to walk the entire association 
            table(sctpAssocTable)."

Line 1592: updated description

    sctpLookupLocalPortEntry OBJECT-TYPE
      SYNTAX         SctpLookupLocalPortEntry
      MAX-ACCESS     not-accessible
      STATUS         current
      DESCRIPTION
          "This table is indexed by local port and association 
           identifier. Management stations can get a list 
           of assocations using a local port by specifying a 
           particular local port with an association 
           identifier of zero and walking the table until the
           local port changes values."

Line: 1626 updated description
    sctpLookupRemPortTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF SctpLookupRemPortEntry
      MAX-ACCESS     not-accessible
      STATUS         current
      DESCRIPTION
           "This table allows management stations to determine which
            associations are using a particular remote port without
            having to walk the entire association 
            table(sctpAssocTable)."
 
Line: 1637 update description

    sctpLookupRemPortEntry OBJECT-TYPE
      SYNTAX         SctpLookupRemPortEntry
      MAX-ACCESS     not-accessible
      STATUS         current
      DESCRIPTION
          "This table is indexed by remote port and association 
           identifier. Management stations can get a list 
           of assocations using a remote port by specifying a 
           particular remote port with an association
           identifier of zero and walking the table until the
           remote port changes values."

Line: 1671 updated descriptions

    sctpLookupRemHostNameTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF SctpLookupRemHostNameEntry
      MAX-ACCESS     not-accessible
      STATUS         current
      DESCRIPTION
           "This table allows management stations to determine which
            associations are using a particular remote host name without
            having to walk the entire association table(sctpAssocTable)."
      ::= { sctpTables 7 }

Line: 1691 Update description

    sctpLookupRemHostNameEntry OBJECT-TYPE
      SYNTAX         SctpLookupRemHostNameEntry
      MAX-ACCESS     not-accessible
      STATUS         current
      DESCRIPTION
          "This table is indexed by remote host name and association 
           identifier. Management stations can get a list of 
           assocations using a remote host name by specifying a 
           particular remote host name with an association
           identifier of zero and walking the table until the
           remote host name changes values."

Line: 1724 Update description

    sctpLookupRemPrimIPAddrTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF SctpLookupRemPrimIPAddrEntry
      MAX-ACCESS     not-accessible
      STATUS         current
      DESCRIPTION
           "This table allows management stations to determine which
            associations are using a particular remote IP address as
            the primary IP address without having to walk the 
            entire association table(sctpAssocTable)."
      ::= { sctpTables 8 }

Line: 1745 updated description

    sctpLookupRemPrimIPAddrEntry OBJECT-TYPE
      SYNTAX         SctpLookupRemPrimIPAddrEntry
      MAX-ACCESS     not-accessible
      STATUS         current
      DESCRIPTION
          "This table is indexed by remote primary IP address and
           association identifier. Management stations can get a list 
           of assocations using a particular remote IP address as
           the primary IP address by specifying a particular remote 
           remote primary IP address with an association identifier 
           of zero and walking the table until the remote primary
           address changes values."

Line: 1780

    sctpLookupRemIPAddrTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF SctpLookupRemIPAddrEntry
      MAX-ACCESS     not-accessible
      STATUS         current
      DESCRIPTION
           "This table allows management stations to determine which
            associations are using a particular remote IP address
            without having to walk the entire association 
            table(sctpAssocTable)."

Line: 1791

    sctpLookupRemIPAddrEntry OBJECT-TYPE
      SYNTAX         SctpLookupRemIPAddrEntry
      MAX-ACCESS     not-accessible
      STATUS         current
      DESCRIPTION
          "This table is indexed by remote IP address and
           association identifier. Management stations can get a list 
           of assocations using a remote IP address by specifying 
           a particular remote IP address with an association 
           identifier of zero and walking the table until the remote 
           IP address changes values."

Sincerely,
John Ferguson Linton

> 
> Hi,
> 
>     The SCTP MIBv04 has been submitted to the IETF. Any comment will be
very
> appreciated.
> regards,
> MCarmen
----------------------------------------------------------------------------
------------------------
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

-- 
Software Engineer: John Ferguson Linton Email:             [email-masked]
Division:          MWG - Apps/VAS Eng Voice:             (919) 392-6917
Fax:               (919) 392-2690
Building - Floor:  RTP MEADOW-4
Cube Number:      M4C1508
Company:          Cisco Systems, Inc.  
Address:          7025 Kit Creek Road 
                  Research Triangle Park, 
                  NC 27709-4967

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA - DEREG Results
Date: Wed, 11 Jul 2001 18:13:19 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail2.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail2.rdc1.on.home.com [24.2.9.89]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings,

OK, lets declare consensus on the parameter Tags then - I will make the
change for Issue8.

As for the comment on "MAY" , Ken's explanation is correct.  I agree that
some better wording is required.  How about:

'...The number of results in a single REG RSP message MAY be anywhere from
one to the total number of number of Routing Key parameters found in the
corresponding REG REQ message.  Where multiple REG RSP messages are used in
reply to REG REQ message, a specific result SHOULD be in only one REG RSP
message.  '

Also similar text for DEREG RSP.   Comments welcome,

   Greg Sidebottom

----- Original Message -----
From: "Ken Morneault" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Wednesday, July 11, 2001 10:54 AM
Subject: RE: M3UA - DEREG Results

>
>
> Maria,
>
> I agree with your proposal.  The message diagrams should be
> update to clearly show the use of the 0x88/0x89 tags.
>
> To answer your question below, the document says "MAY" because
> the SG does not have to respond to a REG REQ with a single
> REG RSP.  For example, it can send a REG RSP for each
> Routing Key.  Maybe we should add a sentence that clarifies the
> "MAY"?
>
> Regards,
>
> Ken
>
>
> At 05:32 PM 7/10/01 +0200, Maria-Cruz Bartolome-Rodrigo (ECE) wrote:
> >Hi Greg,
> >
> >As I understand from the draft the REG/DEREG RSP is the following:
> >
> >REG/DEREG RSP msg  ---|-- Reg/Deregistration ResultS (Tag=0x90/0x91)
> >                                   (only 1 parameter per message?)
> >
> >                                         |-- Reg/Deregistration Result
(tag=0x88/0x89)                                   |
> >                                         |-- Reg/Deregistration Result
(tag=0x88/0x89)
> >Reg/Deregistration ResultS ---|--       ....
> >                                         |-- Reg/Deregistration Result
(tag=0x88/0x89)
> >                                         |-- Reg/Deregistration Result
(tag=0x88/0x89)
> >                                             (from 1 to N parameters)
> >
> >
> >The proposal would be the following:
> >
> >                                 |-- Reg/Deregistration Result
(tag=0x88/0x89)                                   |
> >                                 |-- Reg/Deregistration Result
(tag=0x88/0x89)
> >REG/DEREG RSP msg    ---|--     ....
> >                                 |-- Reg/Deregistration Result
(tag=0x88/0x89)
> >                                 |-- Reg/Deregistration Result
(tag=0x88/0x89)
> >                                     (from 1 to N parameters)
> >
> >In this way two parameters could be saved (Reg/Deregistration ResultS),
> >that means 1 tag/length saved, and the message is better structured.
> >I honestly think everybody will agree about that, unless there is a
> >reason I do not know to have these 'container' parameter (Reg/Dereg
ResultS).
> >
> >One more thing, in the explanation of 'Registration Results':
> >'...The number of results in a single REG RSP message MAY match the
> >number of Routing Key parameters found in the corresponding REG REQ
message'
> >Shouldn't that MAY be replaced by MUST??
> >
> >Thanks
> >/MCruz
> >
> >-----Original Message-----
> >From: Greg Sidebottom [mailto:[email-masked]]
> >Sent: Friday, July 06, 2001 2:45 AM
> >To: sigtran
> >Subject: Re: M3UA - DEREG Results
> >
> >
> >Hi Maria-Cruz,
> >
> >I really don't know which approach is "easier" or "simpler" - I'll let
the
> >implementors out there tell me their preference.  I don't remember the
> >REG/DEREG RSP format being given any real deep thought when we worked it
> >out - I suppose the current format saves a few Tag/Length bytes when
there
> >are multiple results.  But if it is ugly or harder to process then I have
no
> >problem changing it.
> >
> >Cheers,
> >
> >Greg Sidebottom
> >[email-masked]
> >
> >----- Original Message -----
> >From: "Maria-Cruz Bartolome-Rodrigo (ECE)"
> ><[email-masked]>
> >To: "sigtran" <[email-masked]>
> >Sent: Thursday, July 05, 2001 3:27 PM
> >Subject: RE: M3UA - DEREG Results
> >
> >
> > >
> > > Hi Greg,
> > >
> > > In issue 6 both messages (REG RSP and DEREG RSP) do have only one
> > > parameter ('Registration Results' and 'De-registration Results'),
> > > that's right, but being those made up of multiple like parameters
> > > I do not think it makes things easier at all, on the contrary
> > > I find that the proposal below will simplify these messages and
> > > we will get rid of two parameters that are mainly sub-parameter
> > > containers and rather useless.
> > >
> > > What are the advantages of the actual format?
> > > I may misundertand something...
> > >
> > > Thanks
> > > /MCruz
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Greg Sidebottom [mailto:[email-masked]]
> > > Sent: Thursday, July 05, 2001 5:13 AM
> > > To: sigtran
> > > Subject: Re: M3UA - DEREG Results
> > >
> > >
> > > Hi Maria-Cruz,
> > >
> > > I read Ben's e-mail before but seeing as nobody supported it I didn't
make
> > > the change in Issue 7.  I had input from one person off-line who
didn't
> >like
> > > the general idea of multiple like parameters in the same message.
But if
> > > there is support for this I have no problem at all to make the change.
> > >
> > > Cheers,
> > >
> > >    Greg
> > >
> > > ----- Original Message -----
> > > From: "Maria-Cruz Bartolome-Rodrigo (ECE)"
> > > <[email-masked]>
> > > To: "sigtran" <[email-masked]>
> > > Sent: Monday, July 02, 2001 9:44 AM
> > > Subject: RE: M3UA - DEREG Results
> > >
> > >
> > > >
> > > > Hi Greg,
> > > >
> > > > I recall the mail below sent a long time ago.
> > > > I checked the e-mail list but I couldn't find an answer to it.
> > > > I have the same doubt as Ben had and his proposal sounds reasonable
> > > > to me.
> > > >
> > > > What's your opinion about that?
> > > >
> > > > Cheers
> > > > /MCruz
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Benjamin J. Wilson,,, [mailto:[email-masked]]
> > > > Sent: Tuesday, April 03, 2001 10:16 PM
> > > > To: sigtran
> > > > Subject: DEREG Results
> > > >
> > > >
> > > > Greg/Norm,
> > > >
> > > > Might I suggest a bit of cleanup to the DEREG RSP and REG RSP?
> > > >
> > > > It seems a DEREG RSP contains 1 DEREG RESULTS parameter which
> > > > itself contains many DEREG RESULT (singular) parameters.  It's not
> > > > clear from the text b/c no tag is in the diagram, but there is a
> > > > tag for it in the list of parameter ids at the beginning.
> > > >
> > > > Since REG REQ has many Routing Key parameters it seems the DEREG
> > > > RESULTS parameter can be eliminated and the DEREG RSP could just
> > > > contain many DEREG RESULT parameters.
> > > >
> > > > Hopefully this makes sense.
> > > >
> > > > Ben
> > > >
> > > >
> > > >
> > > > ---
> > > > 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]
> > >
> > >
> > > ---
> > > 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]
> >
> >
> >---
> >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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA version 7 comments
Date: Wed, 11 Jul 2001 18:46:14 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail2.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail2.rdc1.on.home.com [24.2.9.89]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Vince,

  Good catches - I have made the correction and deleted the sentence
fragment for Issue 8.

Thanks,

   Greg Sidebottom

----- Original Message -----
From: "Vince Deters" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Tuesday, July 10, 2001 4:23 PM
Subject: M3UA version 7 comments

> Couple of small corrections....
>
> - In section 3.7.1, in the traffic mode description:
>
> "Over-ride (Standby) indicates that the
>    traffic sender continues to use the currently active ASP until it
>    can no longer send/receive traffic (i.e., the currently active ASP
>    transitions to state ASP-DOWN or ASP-ACTIVE)."
>
> That should be "...ASP-DOWN or ASP-INACTIVE..."
>
> - In section 4.2.3.2, the third paragraph has an incomplete sentence at
the end.
>
> Vince
>
>
>
> ---
> 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]
To: "sigtran" <[email-masked]>
Date: Wed, 11 Jul 2001 17:12:42 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: M3UA status
X-Sender-Ip: 63.96.78.248
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

Well, I asked for comments, and we've gotten them (thanks for the detailed
review and well documented comments, Brian and also the other commenters).
In view of the number of comments on M3UA v7, Greg thinks and I agree that
we should have these discussed and incorporated into a v8 before we go for
IESG approval.  Greg will target v8 for end next week, before the cutoff
date.

My suggestion is that where there are open issues that will require any
major additions of text and procedures to resolve, that we hold off for this
edition of M3UA and put any significant enhancements into additional
documents, perhaps adding some text to explain what this version of M3UA
supports and does not.  This should help to keep us on schedule but open for
future extensions if these are desired.

Cheers,

L. Ong

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Routing Context assignment
Date: Thu, 12 Jul 2001 00:37:50 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail2.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail2.rdc1.on.home.com [24.2.9.89]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Nitin, Brian,

I agree with Brian - I can't see it as currently possible to have multiple
vendor SGPs in a single SG.  I think I can see it as useful for the SGPs to
use the same RC values for the same RKs while trying to share AS/ASP states
and allow redirection of traffic between the SGPs.   But assuming this is
true, then IMHO the Network Appearance values also need to be unique across
the contained SGPs in an SG as well.

Cheers,

   Greg

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Monday, July 09, 2001 11:09 PM
Subject: Re: M3UA07: Routing Context assignment

> Nitin,
>
> I don't think that in M3UA07 it is really possible to have multiple
> SGP from multiple vendors interoperable on just the basis of the
> M3UA07 spec.  I agree it would be a good thing; however, M3UA07
> doesn't really support it.
>
> Several times throughout the M3UA07 draft, the SGP are identified as
> having to present a single SG view, coordinate state between them,
> and permit rerouting of traffic between them.  In the absence of an
> SGP to SGP protocol to support interoperability, I don't believe
> that SGP from multiple vendors will be able to interoperate within
> an SG.
>
> If SGP were allowed to operate in a more "decoupled" fashion, then,
> your proposal has merit.  However, that is not the case.
>
> --Brian
>
> Tomar, Nitin wrote:                             (Mon, 09 Jul 2001
18:15:40)
> > Hi All,
> >
> >  I have an issue in Routing Context assignment in Dynamic RKM procedure
> >  and would like to know what other M3UA developers think of it.
> >
> > Thanks
> > Nitin.
> >
> >
> > The section 4.2.4.1 of draft 7 states:
> > 'The method of routing context value assignment at the SG/SGP is
> > implementation dependent but must be guaranteed to be unique across all
SGPs
> > in an SG'
> >
> >
> > Consider the following scenario:
> >
> >         -------------      <-- Reg Req (RK1)
> >         |   SGP1  |   -----------------------------
> >         -------------     Reg Rsp (RC1) ->   |
> >                                                          -------------
> >                                                          |   ASP1  |
> >                                                          -------------
> >                                                                   |
> >         -------------      <--- Reg Req (RK1)   |
> >         |   SGP2  |---------------------------------
> >         -------------      Reg Rsp (RC2) ->
> >
> >
> > SGP1 and SGP2 are part of same SG, also SGP1 and SGP2 are two different
> > implementations of two different vendors [I think this is
> > quite possible at least from interoperability point of view]
> >
> >         ASP1 wants to register RK1 with SGP1 [sends REG REQ and get REG
RSP
> > as well] and gets RC1 from SGP1,
> >         now ASP1 wants to register RK1 with SGP2 and may get RC2 from
SGP2
> > in REG RSP message.
> >
> > As per draft, these RC1 and RC2 has to be unique and implementation
> > dependent, I'm just wondering how this will be achieved among
> > different implementations.
> >
> > I think the above issue can be resolved by just modifying the definition
of
> > Routing Context,
> > Can we explicitly make the Routing Context's significance restricted
between
> > SGP and ASP [which actually is]
> > exactly similar to what we have for network appearance, that will remove
the
> > "implementation dependent but must be guaranteed to be unique" text from
the
> > draft  and ASP will be able to handle both the RCs (RC1 towards SGP1 and
> > RC2 towards SGP2) for a single RK and will send the ASPAC [RC1] towards
SGP1
> > and ASPAC [RC2] towards SGP2.
> >
> > any comments?
> >
> >
> >
> >
> >
> > ---
> > You are currently subscribed to sigtran as: [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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Tom Mattson <[email-masked]>
Subject: Stressed with Debt?
To: "sigtran" <[email-masked]>
Date: Thu, 12 Jul 2001 01:31:33 -0700
X-Mailer: diffondi V4,0,1,0 (W95/NT) (Build: Feb 20 2001)
X-SMTP-HELO: qube.leehaus.co.kr
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [211.217.221.143]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> <meta
name="ProgId" content="FrontPage.Editor.Document"> <title>We will help you
get the mortgage loan you want</title> </head>

<body>

<p align="center"><b><font color="#ff0000" size="5">We will help you get the
mortgage loan you want!&nbsp;<br>
</font><font color="#000000"><br>
Whether a new home loan is what you seek or<br> to refinance your current
home loan at a lower interest rate and payment, we can help!<br>
<br>
<font size="4">Mortgage rates haven't been this low in the last 12 months,
take action now!<br>
</font>Refinance your home with us and include all of those pesky credit
card bills or<br>
use the extra cash for that pool you've always wanted...&nbsp;<br> <br>
</font><font color="#0000ff" size="4">Where others says NO, we say
YES!!!<br> </font><font color="#000000">Even if you have been turned down
elsewhere, we can help!&nbsp;<br>
<br>
</font><font color="#0000ff">Easy terms!</font><font color="#000000"> Our
mortgage referral service combines the<u><br> highest quality loans with the
most economical rates and the easiest qualifications!</u>!<br> <br>
</font><font color="#ff0000" size="4">Take just 2 minutes to complete the
following form.<br>
</font></b><font color="#000000" size="2"><i>There is no obligation, all
information is kept strictly confidential, and you must be at least 18 years
of age.<br>
Service available within the United States only. This service is fast and
free.</i></font></p> <p align="center">&nbsp;</p>
<p align="center"><font face="Arial"><b><font color="#ff0000" size="4">FREE
INFORMATION REQUEST FORM</font><font color="#ff0000"
size="5">:</font></b></font></p> <script language="JavaScript">

 <!--
 function check(form) {
  if ( (form.Name.value == "") ||
     (form.City.value == "") ||
     (form.Address.value == "") ||
     (form.State.value == "") ||
     (form.Mortgage1.value == "") ||
     (form.Mortgage2.value == "") ||
     (form.PostalCode.value == "") ||
     (form.Email.value == "") ) {
  alert("Please fill in ALL required fields. Thank You!");
  return false;
  } else {
  return true;
  }
  }
 
  function validate(string) {
      if (!string) return false;
      var Chars = "0123456789 ";
 
      for (var i = 0; i < string.length; i++) {
         if (Chars.indexOf(string.charAt(i)) == -1)
            return false;
      }
            return true;
 }
  //-->

</script>
<form onsubmit="return check(this)"
action="mailto:[email-masked]" method="post"
encType="text/plain">
  <table width="600" align="center" border="0" bgcolor="#77BBFF">
    <tbody>
      <tr>
        <td align="middle" bgColor="#77BBFF" height="285"><br>
          <hr align="center" width="100%">
          <br>
          <p><font face="Arial" size="2">Please complete all the information
below.<br>
          Our loan specialist will be contacting you at your
convenience.<br>
          Thank You!</font></p>
          <table cellSpacing="0" cellPadding="0" width="600" align="center"
border="0">
            <tbody>
              <tr>
                <td vAlign="top" align="middle">
                  <hr align="center" width="100%">
                  <p><font face="Arial" size="2">Please use your mouse to
navigate between fields.</font></p>
                </td>
              </tr>
            </tbody>
          </table>
          <br>
          <table cellSpacing="0" cellPadding="2" width="535" align="center"
border="0">
            <tbody>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica, sans-serif"
color="#000000" size="2"><b>Your
                  Full Name</b></font></td>
                <td align="left" width="282"><input name="Name" size="20">
*</td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Address</b></font></td>
                <td width="282"><input name="Address" size="20"> *</td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>City</b></font></td>
                <td width="282"><input name="City" size="20"> *</td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>State(USA
                  Only)</b></font></td>
                <td width="282"><select size="1" name="State">
                    <option value="AK" selected>AK</option>
                    <option value="AL">AL</option>
                    <option value="AR">AR</option>
                    <option value="AZ">AZ</option>
                    <option value="CA">CA</option>
                    <option value="CO">CO</option>
                    <option value="CT">CT</option>
                    <option value="DC">DC</option>
                    <option value="DE">DE</option>
                    <option value="FL">FL</option>
                    <option value="GA">GA</option>
                    <option value="HI">HI</option>
                    <option value="IA">IA</option>
                    <option value="ID">ID</option>
                    <option value="IL">IL</option>
                    <option value="IN">IN</option>
                    <option value="KS">KS</option>
                    <option value="KY">KY</option>
                    <option value="LA">LA</option>
                    <option value="MA">MA</option>
                    <option value="MD">MD</option>
                    <option value="ME">ME</option>
                    <option value="MI">MI</option>
                    <option value="MN">MN</option>
                    <option value="MO">MO</option>
                    <option value="MS">MS</option>
                    <option value="MT">MT</option>
                    <option value="NC">NC</option>
                    <option value="ND">ND</option>
                    <option value="NE">NE</option>
                    <option value="NH">NH</option>
                    <option value="NJ">NJ</option>
                    <option value="NM">NM</option>
                    <option value="NV">NV</option>
                    <option value="NY">NY</option>
                    <option value="OH">OH</option>
                    <option value="OK">OK</option>
                    <option value="OR">OR</option>
                    <option value="PA">PA</option>
                    <option value="RI">RI</option>
                    <option value="SC">SC</option>
                    <option value="SD">SD</option>
                    <option value="TN">TN</option>
                    <option value="TX">TX</option>
                    <option value="UT">UT</option>
                    <option value="VA">VA</option>
                    <option value="VT">VT</option>
                    <option value="WA">WA</option>
                    <option value="WI">WI</option>
                    <option value="WV">WV</option>
                    <option value="WY">WY</option>
                  </select><b> * <u>UNITED STATES ONLY!</u></b></td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Zip/Postal
                  Code</b></font></td>
                <td width="282"><input maxLength="15" size="10"
name="PostalCode">
                  *</td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Home
                  Phone</b></font></td>
                <td width="282"><input maxLength="30" name="HPhone"
size="20"> *</td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Work
                  Phone</b></font></td>
                <td width="282"><input maxLength="55" name="WPhone"
size="20"> *</td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Email
                  Address</b></font></td>
                <td width="282"><input maxLength="30" name="Email"
size="20"> *</td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Best
                  Time To Call</b></font></td>
                <td width="282" background="Greenbackground.jpg"><select
size="1" name="CallTime">
                    <option value="Morning at Home" selected>Morning at
Home</option>
                    <option value="Morning at Work">Morning at Work</option>
                    <option value="Afternoon at Home">Afternoon at
Home</option>
                    <option value="Afternoon at Work">Afternoon at
Work</option>
                    <option value="Evening at Home">Evening at Home</option>
                    <option value="Late Evening at Work">Late Evening at
Home</option>
                  </select> *</td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Do
                  You Own Your Home?</b></font></td>
                <td width="282" background="Greenbackground.jpg"><select
size="1" name="Homeowner">
                    <option value="Yes" selected>Yes</option>
                    <option value="No">No</option>
                  </select><font color="#000000" size="1"> * Mobile Homes Do
Not
                  Qualify</font></td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Property
                  Value</b></font></td>
                <td width="282"><input onblur="if (!validate
(this.value&gt;= 50000)) { alert('Not Valid! Please enter the approximate
value of current property or property you wish to purchase \n (greater than
or equal to 50000) using only number characters - 0123456789');
this.focus(); this.select(); return false; }" size="13"
name="PropertyValue">
                  * <font color="#000000" size="1">Please use numbers
only</font></td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Property
                  Type</b></font></td>
                <td width="282" background="Greenbackground.jpg"><select
size="1" name="PropertyType">
                    <option value="Single Family Residence" selected>Single
                    Family Residence</option>
                    <option value="Condo">Condo</option>
                    <option value="Townhouse">Townhouse</option>
                    <option value="2-4 Plex">2-4 Plex</option>
                    <option value="Other">Other</option>
                  </select> *</td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Purchase
                  Price</b></font></td>
                <td width="282"><input size="13" name="PurchasePrice"> *
<font color="#000000" size="1">Please
                  use numbers only</font></td>
              </tr>
              <tr>
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>
                  <p>Year Acquired</b></font></p>
                </td>
                <td align="left" width="282"><input size="13"
name="YearAcquired">
                  *</td>
              </tr>
              <tr align="middle">
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>1st
                  Mortgage-Balance Owed</b></font></td>
                <td align="left" width="282"><input onblur="if (!validate
(this.value)) { alert('Not Valid! Please enter only number characters -
0123456789\n If you have no current mortgage please enter 0'); this.focus();
this.select(); return false; }" maxLength="30" size="13" name="Mortgage1">
                  * <font color="#000000" size="1">Please use numbers only
                  (ex:45000) enter 0 for none</font></td>
              </tr>
              <tr align="middle">
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>1st
                  Mortgage-Interest Rate</b></font></td>
                <td align="left" width="282"><b><select size="1"
name="CurrentIntRate">
                    <option value="select">Select</option>
                    <option value="7.0">Below 7.0</option>
                    <option value="7.25">7.1 - 7.49</option>
                    <option value="7.75">7.5 - 7.99</option>
                    <option value="8.0">8.0 - 8.49</option>
                    <option value="8.75">8.5 - 8.99</option>
                    <option value="9.25">9.0 - 9.49</option>
                    <option value="9.75">9.5 - 9.99</option>
                    <option value="10.0">10 or above</option>
                    <option value="0">None</option>
                  </select> %</b></td>
              </tr>
              <tr align="middle">
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Is
                  1st Adjustable or Fixed?</b></font></td>
                <td align="left" width="282"
background="Greenbackground.jpg"><select size="1" name="FirstType">
                    <option value="Fixed" selected>Fixed</option>
                    <option value="Adjustable">Adjustable</option>
                  </select> *</td>
              </tr>
              <tr align="middle">
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Employer</b></font></td>
                <td align="left" width="282"><input maxLength="30" size="15"
name="Employer">
                  *</td>
              </tr>
              <tr align="middle">
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Monthly
                  Gross&nbsp;Household Income</b></font></td>
                <td align="left" width="282"><input maxLength="30" size="13"
name="MonthlyGrIncome">
                  * <font color="#000000" size="1">Please use numbers
only</font></td>
              </tr>
              <tr align="middle">
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>2nd
                  Mortgage Balance owed</b></font></td>
                <td align="left" width="282"><input onblur="if (!validate
(this.value)) { alert('Not Valid! Please enter only number characters -
0123456789\n If you have no second mortgage please enter 0'); this.focus();
this.select(); return false; }" maxLength="30" size="13"
name="Mortgage2">&gt;
                  * <font color="#000000" size="1">Please use numbers
                  only(ex:45000) enter 0 for none</font></td>
              </tr>
              <tr align="middle">
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Amount
                  You Wish To Borrow</b></font></td>
                <td align="left" width="282"><select size="1"
name="BorrowRequest">
                    <option value="select">Select</option>
                    <option value="25000">15,000 - 30,000</option>
                    <option value="40000">30,000 - 45,000</option>
                    <option value="55000">45,000 - 60,000</option>
                    <option value="70000">60,000 - 75,000</option>
                    <option value="85000">75,000 - 90,000</option>
                    <option value="105000">90,000 - 110,000</option>
                    <option value="120000">110,000 - 125,000</option>
                    <option value="150000">125,000 &amp; Up</option>
                  </select> *</td>
              </tr>
              <tr align="middle">
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Credit
                  Rating</b></font></td>
                <td align="left" width="282"><select size="1"
name="CreditRating">
                    <option value="select">Select</option>
                    <option value="Excellent">Excellent</option>
                    <option value="Good">Good</option>
                    <option value="Fair">Fair</option>
                    <option value="Poor">Poor</option>
                    </select> *</td>
              </tr>
              <tr align="middle">
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Monthly
                  Debt</b></font></td>
                <td align="left" width="282"><input size="13"
name="MonthlyDebt">
                  * <font color="#000000" size="1">Please use numbers
<b>only</b></font></td>
              </tr>
              <tr vAlign="center">
                <td align="right" width="296"
background="Greenbackground.jpg"><font face="Arial, Helvetica,sans-serif"
color="#000000" size="2"><b>Loan
                  Interested In</b></font></td>
                <td align="left" width="282"><select size="1"
name="LoanInterested">
                    <option value="select">Select</option>
                    <option value="Refinance Only" selected>Refinance
Only</option>
                    <option value="Refinance with Cash Out">Refinance with
Cash Out</option>
                    <option value="Home Improvement">Home
Improvement</option>
                    <option value="Debt Consolidation">Debt
Consolidation</option>
                    <option value="Home Equity">Home Equity</option>
                  </select> *<br>
                  &nbsp;</td>
              </tr>
              <tr align="middle">
                <td align="middle" width="582" colSpan="2" ?>Fast &amp; Easy
                  -You Are Done !<br>
                  <input type="submit" value="Submit This Application"></td>
              </tr>
            </tbody>
          </table>
        </td>
      </tr>
    </tbody>
  </table>
</form>
<p><font face="Helvetica, sans-serif, Arial" size="2">REMOVAL INSTRUCTIONS:
This message is being sent to you in compliance with the current Federal
legislation.
You must have either posted an AD to my FFA site, web-site, or requested
information, or responded to one of our email letters. If you do not want to
receive further emails or any other information from us, or you have
received this mail in error, or for immediate removal you may simply use
reply on your email program with &quot;Remove from your mailing list
#21645&quot; in the subject.</font></p>

</body>

</html>

</x-html>
---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 12 Jul 2001 14:08:35 +0530
From: kusum <[email-masked]>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pdf
To: "sigtran" <[email-masked]>
Subject: comment on <draft-ietf-sigtran-sctp-mib-04.txt>
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi! All,

 There is one  point which i found is missing in SCTP MIB -draft -4.
As we have object
<sctpRemPrimaryAddress> for remote primary address .
we should have <sctpLocalPrimaryAddress> object for local primary address.
Please  give your comments.....
Regards......
KK......

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Original-To: IETF-Announce:;;@cnri.reston.va.us@zrtps0jn
PP-Warning: Parse error in original version of preceding To line
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sigtran-v5ua-01.txt
Date: Thu, 12 Jul 2001 07:07:18 -0400
Sender: [email-masked]
X-SMTP-HELO: ietf.org
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [132.151.1.176]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
To: "sigtran" <[email-masked]>

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		: V5.2-User Adaption Layer (V5UA)
	Author(s)	: E. Weilandt et al.
	Filename	: draft-ietf-sigtran-v5ua-01.txt
	Pages		: 20
	Date		: 11-Jul-01
	
This document defines a mechanism for backhauling of V5.2 messages over IP
using the Stream control Transmission Protocol (SCTP). This protocol would
be used between a Signaling Gateway (SG) and a Media Gateway controller
(MGC). It is assumed that the SG receives V5.2 sig- naling over a standard
V5.2 interface.
This document aims to build on top of the ISDN User Adaptation Layer
Protocol (<draft-ietf-sigtran-iua-10.txt>). It defines all differences to
the IUAP needed for the V5.2 implementation.

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

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-v5ua-01.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-v5ua-01.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.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sigtran-v5ua-01.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-sigtran-v5ua-01.txt> ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Tomar, Nitin" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Routing Context assignment
Date: Thu, 12 Jul 2001 13:49:12 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: rumor.cps.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: rumor.cps.intel.com [192.102.198.242]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg, Brian,

Lets assume that its currently not possible to have multiple vendor SGPs in
a single SG but
IMHO we can try to resolve the issues as much as possible within the
protocol rather than
keeping it "implementation dependent" and moreover by forcing RC assignments
to be shared
between SGPs, I think the draft is going into distributed architecture of
M3UA which is a proprietary
area, well above is my view point and being a M3UA-SGP developer I found
this approach to be 
more logical for non-distributed M3UA.

Thanks
Nitin. 

-----Original Message-----
From: Greg Sidebottom [mailto:[email-masked]] Sent: Wednesday, July 11,
2001 9:38 PM
To: sigtran
Subject: Re: M3UA07: Routing Context assignment

Hi Nitin, Brian,

I agree with Brian - I can't see it as currently possible to have multiple
vendor SGPs in a single SG.  I think I can see it as useful for the SGPs to
use the same RC values for the same RKs while trying to share AS/ASP states
and allow redirection of traffic between the SGPs.   But assuming this is
true, then IMHO the Network Appearance values also need to be unique across
the contained SGPs in an SG as well.

Cheers,

   Greg

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Monday, July 09, 2001 11:09 PM
Subject: Re: M3UA07: Routing Context assignment

> Nitin,
>
> I don't think that in M3UA07 it is really possible to have multiple
> SGP from multiple vendors interoperable on just the basis of the
> M3UA07 spec.  I agree it would be a good thing; however, M3UA07
> doesn't really support it.
>
> Several times throughout the M3UA07 draft, the SGP are identified as
> having to present a single SG view, coordinate state between them,
> and permit rerouting of traffic between them.  In the absence of an
> SGP to SGP protocol to support interoperability, I don't believe
> that SGP from multiple vendors will be able to interoperate within
> an SG.
>
> If SGP were allowed to operate in a more "decoupled" fashion, then,
> your proposal has merit.  However, that is not the case.
>
> --Brian
>
> Tomar, Nitin wrote:                             (Mon, 09 Jul 2001
18:15:40)
> > Hi All,
> >
> >  I have an issue in Routing Context assignment in Dynamic RKM procedure
> >  and would like to know what other M3UA developers think of it.
> >
> > Thanks
> > Nitin.
> >
> >
> > The section 4.2.4.1 of draft 7 states:
> > 'The method of routing context value assignment at the SG/SGP is
> > implementation dependent but must be guaranteed to be unique across all
SGPs
> > in an SG'
> >
> >
> > Consider the following scenario:
> >
> >         -------------      <-- Reg Req (RK1)
> >         |   SGP1  |   -----------------------------
> >         -------------     Reg Rsp (RC1) ->   |
> >                                                          -------------
> >                                                          |   ASP1  |
> >                                                          -------------
> >                                                                   |
> >         -------------      <--- Reg Req (RK1)   |
> >         |   SGP2  |---------------------------------
> >         -------------      Reg Rsp (RC2) ->
> >
> >
> > SGP1 and SGP2 are part of same SG, also SGP1 and SGP2 are two different
> > implementations of two different vendors [I think this is
> > quite possible at least from interoperability point of view]
> >
> >         ASP1 wants to register RK1 with SGP1 [sends REG REQ and get REG
RSP
> > as well] and gets RC1 from SGP1,
> >         now ASP1 wants to register RK1 with SGP2 and may get RC2 from
SGP2
> > in REG RSP message.
> >
> > As per draft, these RC1 and RC2 has to be unique and implementation
> > dependent, I'm just wondering how this will be achieved among
> > different implementations.
> >
> > I think the above issue can be resolved by just modifying the definition
of
> > Routing Context,
> > Can we explicitly make the Routing Context's significance restricted
between
> > SGP and ASP [which actually is]
> > exactly similar to what we have for network appearance, that will remove
the
> > "implementation dependent but must be guaranteed to be unique" text from
the
> > draft  and ASP will be able to handle both the RCs (RC1 towards SGP1 and
> > RC2 towards SGP2) for a single RK and will send the ASPAC [RC1] towards
SGP1
> > and ASPAC [RC2] towards SGP2.
> >
> > any comments?
> >
> >
> >
> >
> >
> > ---
> > You are currently subscribed to sigtran as: [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]

---
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: "Tomar, Nitin" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA06: Routing Key Management procedure
Date: Thu, 12 Jul 2001 14:12:23 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hypnos.cps.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: hypnos.cps.intel.com [192.198.165.17]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg, 
 Thanks for replying, see my comments below,

Regards
Nitin,

-----Original Message-----
From: Greg Sidebottom [mailto:[email-masked]] Sent: Wednesday, July 11,
2001 1:09 PM
To: sigtran
Subject: Re: M3UA06: Routing Key Management procedure

Hi Nitin,

Thanks for the comments - I was hoping someone else would respond as
REG/DEREG is not my "cup-of-tea" but no such luck!

Responses below ...

----- Original Message -----
From: "Tomar, Nitin" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Tuesday, July 03, 2001 9:14 PM
Subject: RE: M3UA06: Routing Key Management procedure

>
> Greg,
>
>    Re-sending this mail and awaiting answer for these.
>
>  regards
> - Nitin
>
> -----Original Message-----
> From: Tomar, Nitin [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 6:48 PM
> To: sigtran
> Subject: M3UA06: Routing Key Management procedure
>
>
> Greg,
>
> I have few queries/comments on Routing key procedure.
>
> - Nitin.
>
> 1. Is RKM procedure valid for IPSP-IPSP communication as well? In either
> case I think the draft can specify it clearly in section 3.5.5 and related
> sections. If RKM is allowed for IPSP-IPSP scenario, can client and server
> both initiate REG-REQ and DEREG-REQ messages, I do not find any reason
> they should not do so.

[Greg] I agree that RKM should be possible for IPSP-to IPSP but this is not
an
application that I have an interest.  I'm not sure though that it makes
sense
to register in both directions point-to-point to set up a two way
communication.  I see that currently ASPs use the REG REQ to set-up two way
traffic with the SG - the SG doesn't need a separate procedure to register
for
which traffic it wants from the ASP, as it is usually related.  But I
suppose there
could be an application to Register in both directions to set up two sets of
two-way traffic beween IPSPs.  Do people need this described?

[Nitin] I may be missing something here, do you mean that with REG REQ
message an ASP can specify an SGP that what traffic it'll be sending towards
it, if so how an SGP will come to know that the traffic related to the RK
specified in REG REQ message is handled by ASP or the ASP wants to send this
traffic to SGP.

>
> 2. De-registration request for RK not registered through REG REQ message
is
> valid or not? lets say RK was statically configured at an SG which
supports
> both static and dynamic configuration of RKs.

[Greg] I don't think so, but it is really up to the configuration manager.
When we first put together the registration protocol we (the authors) agreed
that an SG would need to police whether the ASP is allowed to change a
particular piece of configuration data.  If the piece of configuration data
(RK) was "statically" created by a local mangement system, as opposed to
created based on a REG REQ, then an ASP sending a DEREG should not cause
deletion of the entry or RK.

It is possible that SGs could have features that will allow a lot of
flexibility here, such as allowing a new ASP to register/deregister
dynamically on a
statically defined RK, but I don't think we need to go there with the
protocol.  Perhaps the best way out is to have the configuration manager
decide whether to honor the DEREG REQ, based on the present RK data

[Nitin] Fine,

>
> 3. In section 4.3.4.1 and 4.3.4.2, The draft does not specifies any timers
> associated with the REG REQ and DEREG REQ messages, I think there is a
need
> for timers for RKM messages, as an ASP can not wait indefinitely for the
REG
> RSP if SG decides to respond to REG REQ containing multiple RKs with
> multiple REG RSP messages'
>
> The timer can be similar to what we have for ASPM messages, something like
> this:
>
> 'When ASP sends an REG REQ it starts timer T(RK-ack). If the ASP does not
> receive a response to REG REQ within T(RK-ack), the ASP may restart
> T(RK-ack) and resend REG REQ messages until it receives an REG REQ
message.
> T(RK-ack) is provisionable, with a default of n seconds. Alternatively,
> retransmission of REG RSP messages may be put under control of Layer
> Management'
>

[Greg] Actually I think that these timers of marginal use, allowing the
resending of a message for which there is no response.  I see it as useful
for ASP Up/Down, and for ASP Active/Inact and REG/DEREG when there is only
one contained request (e.g., RK/RC).  But for ASP Active/Inact and REG/DEREG
with more than one request, they are not very useful.  Robust
implementations should probably run a timer per request (RK or RC), not per
message.  An implemenation can't leave these requests open indefinitely - if
there is no reponse to a request the application will have to take action to
retry or close it.  Per this text, and the current ASP Active text, if a REG
RESP is received containing a result for only one of two requests, then the
Timer is cancelled and we still have an outstanding request.  There are also
I think possible cases where a "response" is ambiguous, at least for ASP
Active messages that are errored.

So I think we have a couple of options: 1) add REG/DEREG timers ) on a
per/transaction basis (and change ASP-Active/Inactive timers), 2) remove the
explicit message timers and add text saying that the sending application
should run a timer to close/resend each request, or 3) remove the text.
Views?

[Nitin] I'm in favor of 1st option, as this issue is related to timers for
ASP-Active/Inactive too, it makes more sense to have these per/transaction
basis,
that may cause a bit more handling in the protocol but it will ensure the
consistency among the ASPM and DRKM procedures.

> 4. Can a ASP is authorized to send REG-REG only and not authorized to
> send DEREG-REQ, in either case the draft can specify it clearly in
> section 4.3.4.2.
>

[Greg] I hope not.  Anyway the SG is currently allowed to refuse a REG or
DEREG.  If there is an application where it is useful to accept one but not
the other, I'd see this as a ploicy decision at the SG.  I don't think we
need to cover this in the protocol.

[Nitin] OK,

> 5. Figure for "Routing Key" parameter description can be modified to
> indicate the Network Appearance (optional) as first parameter. [To comply
> with section 3.3.1 stating 'Where the optional Network Appearance
parameter
> is present, it must be the first parameter in the message']

[Greg] Yes this is inconsistent.  I've also had the view expressed to me
that the Network Appearance shouldn't be first in the DATA message either as
it is technically an optional parameter and the Protocol Data parameter is
mandatory.  For some people, mandatory parameters should come first before
any optional parameters (like in SS7).  We should sort this out once and for
all for Issue 8 - IMHO it should be first in both RK and DATA (when present)
as suggested here but I'll do whatever the decoders feel is best.

Of course there is a proposal from Brian to replace the NA everywhere with
an RC - we should sort that idea out as well - see this thread.

>
> 6. The 'Registration Status' parameter values in REG RSP message need one
> more type of error value : 'Multiple SI not supported' as none of the
> existing error value cover this [In case SG optionally support only one SI
> in a Routing key as per section 1.4.2.2].
>

[Greg} I can add this. Actually there are a few more error values that
probably make sense. - "Invalid SI" , OPC, CIC Range, SSN", for example.
Others?

> 7. Section 3.5.5, 3.5.6, 3.5.7 and 3.5.8 numbering is duplicated.

[Greg] hopefully this is fixed in Issue 7 - no guarantees though!

[Nitin ] Its fixed.

Thanks Again,

     Greg

---
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]
Date: Thu, 12 Jul 2001 16:41:49 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Routing Context assignment
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-251.dallas.net [209.44.42.251]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Nitin,

I believe that it is the statement in 4.2.4.1 that you quote is too
restrictive.

	"...  The method of Routing Contrext value assignment at
	the SG/SGP is implementation dependent but must be
	guaranteed to be unique across all SGPs in an SG."

I'm not quite sure in what respect the statement is attempting to impose
uniqueness.  The statement is confusing.

Let's look at this a little deeper.

Routing Context is used, when necessary, within an SCTP association to
distinguish between AS traffic flows on the same association.  Given that
this is the only use of Routing Context, an ASP only needs to have the
Routing Context uniquely identify an AS traffic flow within an association.

Given that in the current draft, each SGP has a one-to-one mapping to an
SCTP association, it follows that the Routing Context only really needs be
unique within the scope of an SGP to ASP association.

The restriction, however, allows an ASP to map Routing Context directly to
Application Server on a per-SG basis.  Removing the restriction and
permitting RC to be unique within the SGP only means that the ASP would map
Routing Contexts to Application Server on a per-SGP basis.

I don't see much difference between mapping per-SG and per-SGP (since the
ASP in M3UA-07 keeps a lot of per-SGP information).

Ok, you've got me convinced.  I propose that we change the sentence in
Section 4.2.4.1 to read:

	The method of Routing Context value assignment at the
	SGP is implementation dependent but must be guaranteed
	to be unique for each Application Server or Routing Key
	served by the SGP.

Would that work for you?

--Brian

Tomar, Nitin wrote:                  (Thu, 12 Jul 2001 13:49:12)
> 
> Hi Greg, Brian,
> 
> Lets assume that its currently not possible to have multiple
> vendor SGPs in a single SG but IMHO we can try to resolve the
> issues as much as possible within the protocol rather than
> keeping it "implementation dependent" and moreover by forcing
> RC assignments to be shared between SGPs, I think the draft is
> going into distributed architecture of M3UA which is a
> proprietary area, well above is my view point and being a
> M3UA-SGP developer I found this approach to be more logical
> for non-distributed M3UA.
> 
> Thanks
> Nitin. 
> 
> -----Original Message-----
> From: Greg Sidebottom [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2001 9:38 PM
> To: sigtran
> Subject: Re: M3UA07: Routing Context assignment
> 
> 
> Hi Nitin, Brian,
> 
> I agree with Brian - I can't see it as currently possible to
> have multiple vendor SGPs in a single SG.  I think I can see
> it as useful for the SGPs to use the same RC values for the
> same RKs while trying to share AS/ASP states and allow
> redirection of traffic between the SGPs.   But assuming this
> is true, then IMHO the Network Appearance values also need to
> be unique across the contained SGPs in an SG as well.
> 
> Cheers,
> 
>    Greg
> 
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Monday, July 09, 2001 11:09 PM
> Subject: Re: M3UA07: Routing Context assignment
> 
> 
> > Nitin,
> >
> > I don't think that in M3UA07 it is really possible to have
> > multiple SGP from multiple vendors interoperable on just the
> > basis of the M3UA07 spec.  I agree it would be a good thing;
> > however, M3UA07 doesn't really support it.
> >
> > Several times throughout the M3UA07 draft, the SGP are
> > identified as having to present a single SG view, coordinate
> > state between them, and permit rerouting of traffic between
> > them.  In the absence of an SGP to SGP protocol to support
> > interoperability, I don't believe that SGP from multiple
> > vendors will be able to interoperate within an SG.
> >
> > If SGP were allowed to operate in a more "decoupled"
> > fashion, then, your proposal has merit.  However, that is
> > not the case.
> >
> > --Brian
> >
> > Tomar, Nitin wrote:                             (Mon, 09 Jul 2001
> 18:15:40)
> > > Hi All,
> > >
> > >  I have an issue in Routing Context assignment in Dynamic
> > >  RKM procedure and would like to know what other M3UA
> > >  developers think of it.
> > >
> > > Thanks
> > > Nitin.
> > >
> > >
> > > The section 4.2.4.1 of draft 7 states:
> > > 'The method of routing context value assignment at the
> > > SG/SGP is implementation dependent but must be guaranteed
> > > to be unique across all SGPs in an SG'
> > >
> > >
> > > Consider the following scenario:
> > >
> > >         -------------      <-- Reg Req (RK1)
> > >         |   SGP1  |   -----------------------------
> > >         -------------     Reg Rsp (RC1) ->   |
> > >                                                          -------------
> > >                                                          |   ASP1  |
> > >                                                          -------------
> > >                                                                   |
> > >         -------------      <--- Reg Req (RK1)   |
> > >         |   SGP2  |---------------------------------
> > >         -------------      Reg Rsp (RC2) ->
> > >
> > >
> > > SGP1 and SGP2 are part of same SG, also SGP1 and SGP2 are
> > > two different implementations of two different vendors [I
> > > think this is quite possible at least from
> > > interoperability point of view]
> > >
> > > ASP1 wants to register RK1 with SGP1 [sends REG REQ and
> > > get REG RSP as well] and gets RC1 from SGP1, now ASP1
> > > wants to register RK1 with SGP2 and may get RC2 from SGP2
> > > in REG RSP message.
> > >
> > > As per draft, these RC1 and RC2 has to be unique and
> > > implementation dependent, I'm just wondering how this will
> > > be achieved among different implementations.
> > >
> > > I think the above issue can be resolved by just modifying
> > > the definition of Routing Context, Can we explicitly make
> > > the Routing Context's significance restricted between SGP
> > > and ASP [which actually is] exactly similar to what we
> > > have for network appearance, that will remove the
> > > "implementation dependent but must be guaranteed to be
> > > unique" text from the draft  and ASP will be able to
> > > handle both the RCs (RC1 towards SGP1 and RC2 towards
> > > SGP2) for a single RK and will send the ASPAC [RC1]
> > > towards SGP1 and ASPAC [RC2] towards SGP2.
> > >
> > > any comments?
> > >
> > >
> > >
> > >
> > >
> > > ---
> > > You are currently subscribed to sigtran as: [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]
> 
> 
> 
> ---
> 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]

-- 
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]
Date: Thu, 12 Jul 2001 17:24:35 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M3UA06: Routing Key Management procedure
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-251.dallas.net [209.44.42.251]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Nitin, Greg,

Please see comments below...

Tomar, Nitin wrote:                      (Thu, 12 Jul 2001 14:12:23)

[snip]
> >
> > Greg,
> >
> > I have few queries/comments on Routing key procedure.
> >
> > - Nitin.
> >
> > 1. Is RKM procedure valid for IPSP-IPSP communication as well? In
> > either case I think the draft can specify it clearly in section
> > 3.5.5 and related sections. If RKM is allowed for IPSP-IPSP
> > scenario, can client and server both initiate REG-REQ and DEREG-REQ
> > messages, I do not find any reason they should not do so.
> 
> [Greg] I agree that RKM should be possible for IPSP-to IPSP but this
> is not an application that I have an interest.  I'm not sure though
> that it makes sense to register in both directions point-to-point to
> set up a two way communication.  I see that currently ASPs use the REG
> REQ to set-up two way traffic with the SG - the SG doesn't need a
> separate procedure to register for which traffic it wants from the
> ASP, as it is usually related.  But I suppose there could be an
> application to Register in both directions to set up two sets of
> two-way traffic beween IPSPs.  Do people need this described?
> 
> [Nitin] I may be missing something here, do you mean that with REG REQ
> message an ASP can specify an SGP that what traffic it'll be sending
> towards it, if so how an SGP will come to know that the traffic
> related to the RK specified in REG REQ message is handled by ASP or
> the ASP wants to send this traffic to SGP.

This is stiking on an SGP issue which has been raised several times.
How does the SGP know what traffic it is to receive?

These issues are all related.  Placing the Routing Context in the DATA
message permits the the SGP to screen the DATA messages on the basis of
valid Routing Contexts.  Breaking the routing label into parameters permits
the SG to screen the routing label without parsing the DATA payload (after
the ASP has just finished packing it).

Placing the restriction that the ASP can only send messages to an SGP which
have the symmetrical Routing Key associated with the Routing Context permits
the SGP to know what traffic it is expected to process when a REG REQ is
performed and screen the messages per above when the messages actually
arrive.

> 
> >
> > 2. De-registration request for RK not registered through REG REQ
> > message is valid or not? lets say RK was statically configured at an
> > SG which supports both static and dynamic configuration of RKs.
> 
> [Greg] I don't think so, but it is really up to the configuration
> manager.  When we first put together the registration protocol we (the
> authors) agreed that an SG would need to police whether the ASP is
> allowed to change a particular piece of configuration data.  If the
> piece of configuration data (RK) was "statically" created by a local
> mangement system, as opposed to created based on a REG REQ, then an
> ASP sending a DEREG should not cause deletion of the entry or RK.
> 
> It is possible that SGs could have features that will allow a lot of
> flexibility here, such as allowing a new ASP to register/deregister
> dynamically on a statically defined RK, but I don't think we need to
> go there with the protocol.  Perhaps the best way out is to have the
> configuration manager decide whether to honor the DEREG REQ, based on
> the present RK data
> 
> [Nitin] Fine,
> 
> >
> > 3. In section 4.3.4.1 and 4.3.4.2, The draft does not specifies any
> > timers associated with the REG REQ and DEREG REQ messages, I think
> > there is a need for timers for RKM messages, as an ASP can not wait
> > indefinitely for the REG RSP if SG decides to respond to REG REQ
> > containing multiple RKs with multiple REG RSP messages'
> >
> > The timer can be similar to what we have for ASPM messages,
> > something like this:
> >
> > 'When ASP sends an REG REQ it starts timer T(RK-ack). If the ASP
> > does not receive a response to REG REQ within T(RK-ack), the ASP may
> > restart T(RK-ack) and resend REG REQ messages until it receives an
> > REG REQ message.  T(RK-ack) is provisionable, with a default of n
> > seconds. Alternatively, retransmission of REG RSP messages may be
> > put under control of Layer Management'
> >
> 
> [Greg] Actually I think that these timers of marginal use, allowing
> the resending of a message for which there is no response.  I see it
> as useful for ASP Up/Down, and for ASP Active/Inact and REG/DEREG when
> there is only one contained request (e.g., RK/RC).  But for ASP
> Active/Inact and REG/DEREG with more than one request, they are not
> very useful.  Robust implementations should probably run a timer per
> request (RK or RC), not per message.  An implemenation can't leave
> these requests open indefinitely - if there is no reponse to a request
> the application will have to take action to retry or close it.  Per
> this text, and the current ASP Active text, if a REG RESP is received
> containing a result for only one of two requests, then the Timer is
> cancelled and we still have an outstanding request.  There are also I
> think possible cases where a "response" is ambiguous, at least for ASP
> Active messages that are errored.
> 
> So I think we have a couple of options: 1) add REG/DEREG timers ) on a
> per/transaction basis (and change ASP-Active/Inactive timers), 2)
> remove the explicit message timers and add text saying that the
> sending application should run a timer to close/resend each request,
> or 3) remove the text.  Views?
> 
> [Nitin] I'm in favor of 1st option, as this issue is related to timers
> for ASP-Active/Inactive too, it makes more sense to have these
> per/transaction basis, that may cause a bit more handling in the
> protocol but it will ensure the consistency among the ASPM and DRKM
> procedures.

For the current T(ack) timer, control is essentially placed in the hands of
management: either management runs its own algorithm, or when the timer
expires management is informed of the failure.  

What this timer really accomplishes is seeing if the SG is dead on a valid
SCTP association.  I don't know how an SG could be "dead" for one RK
contained in a REG REQ but "alive" for another.  I like the idea of
cancelling the timer when when any REG RESP pertaining to the sent REG REQ
is returned.  That would mean that the ASP could do something like assume
that the SG is dead and, say, cycle the SCTP association under LM control.

I like with 1) and Nitin's text (with the exception that the timer is
cancelled when the first REG RESP message with a result pertaining to the
original REG REQ is received, and the addition of management primitives
M-REQ_REQ and M-REG_RESP so that management can also control the situation
as is currently provided for ASP_UP).

> 
> > 4. Can a ASP is authorized to send REG-REG only and not authorized
> > to send DEREG-REQ, in either case the draft can specify it clearly
> > in section 4.3.4.2.
> >
> 
> [Greg] I hope not.  Anyway the SG is currently allowed to refuse a REG
> or DEREG.  If there is an application where it is useful to accept one
> but not the other, I'd see this as a ploicy decision at the SG.  I
> don't think we need to cover this in the protocol.
> 
> [Nitin] OK,
> 
> > 5. Figure for "Routing Key" parameter description can be modified to
> > indicate the Network Appearance (optional) as first parameter. [To
> > comply with section 3.3.1 stating 'Where the optional Network
> > Appearance parameter is present, it must be the first parameter in
> > the message']
> 
> [Greg] Yes this is inconsistent.  I've also had the view expressed to
> me that the Network Appearance shouldn't be first in the DATA message
> either as it is technically an optional parameter and the Protocol
> Data parameter is mandatory.  For some people, mandatory parameters
> should come first before any optional parameters (like in SS7).  We
> should sort this out once and for all for Issue 8 - IMHO it should be
> first in both RK and DATA (when present) as suggested here but I'll do
> whatever the decoders feel is best.
> 
> Of course there is a proposal from Brian to replace the NA everywhere
> with an RC - we should sort that idea out as well - see this thread.
> 
> >
> > 6. The 'Registration Status' parameter values in REG RSP message
> > need one more type of error value : 'Multiple SI not supported' as
> > none of the existing error value cover this [In case SG optionally
> > support only one SI in a Routing key as per section 1.4.2.2].
> >
> 
> [Greg} I can add this. Actually there are a few more error values that
> probably make sense. - "Invalid SI" , OPC, CIC Range, SSN", for
> example.  Others?

Let's not get into adding a whole but of error codes here...

I think that Nitin's example is adequately covered under the "Error -
Invalid Routing Key" per the description in the on Page 79 of M3UA-07:

	"If the SGP determines that the received Routing Key data is
	invalid, or contains invalid parameter values, the SGP returns a
	Registration Response message to the ASP, containing a
	Registration Result "Error - Invalid Routing Key", "Error -
	Invalid DPC", "Error - Invalid Network Appearance" as
	appropriate."

Rather than getting into a long list of error results, why not add an
optional INFO String to the Registration Status which can contain additional
implementation specific or diagnostic information.

> 
> > 7. Section 3.5.5, 3.5.6, 3.5.7 and 3.5.8 numbering is duplicated.
> 
> [Greg] hopefully this is fixed in Issue 7 - no guarantees though!
> 
> [Nitin ] Its fixed.
> 
> 
> Thanks Again,
> 
>      Greg
> 

-- 
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]
Date: Thu, 12 Jul 2001 18:07:52 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA-07: ASP Id changes
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-251.dallas.net [209.44.42.251]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Here are all the modifications necessary to put ASP Id into M3UA to handle
the scenarios addressed in the thread "ASP Partitioning".
The changes are consistent with M2UA-09.  It is not really all that
difficult ;)

--Brian

--------------------------

Parameter Tag: 16 bits (unsigned integer)

...
           0x84        User/Cause
           0x0a        Reason
           0x0b        Traffic Mode Type
           0x0c        Error Code
           0x0d        Status 
+          0x0e        ASP Identifier
           0x85        Congestion Indications
           0x86        Concerned Destination
           0x87        Routing Key
           0x88        Registration Result
           0x89        De-registration Result

--------------------------

  The format for ASP Up message parameters is as follows:
  
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|         Tag = 0x0e            |             Length            | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +    |
ASP Identifier*                        | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Tag = 0x04            |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /                          INFO String                          /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
+ The optional ASP Identifier parameter contains a unique value that is +
locally significant among the ASPs that support an AS.  The SGP should +
save the ASP Identifier to be used, if necessary, with the Notify + message
(see Section 3.8.2).
  
--------------------------
  
  The Notify message contains the following parameters:
  
       Status                     Mandatory +      ASP Identifier
Optional
       Routing Context            Optional
       INFO String                Optional

--------------------------
  
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Tag = 0x0d             |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Status Type            |    Status Information         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|        Tag = 0x0e             |             Length            | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +    |
ASP Identifier*                        | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Tag = 0x06             |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /                       Routing Context                         / 
     \                                                               \

--------------------------

  4.2.3.1 ASP Up Procedures

...
  
! When an ASP Up message is received at an SGP and internally the remote !
ASP is in the ASP-DOWN state and not considered locked-out for local
  management reasons, the SGP marks the remote ASP in the state ASP- !
INACTIVE and informs Layer Management with an M-ASP_Up indication !
primitive.  If the SGP is aware, via current configuration data, which !
Application Servers the ASP is configured to operate in, the SGP ! updates
the ASP state to ASP-INACTIVE in each AS that it is a member.
! Alternatively, the SGP may move the ASP into a pool of Inactive ASPs !
available for future configuration within Application Server(s), !
determined in a subsequent Registration Request or ASP Active ! procedure.
If the ASP Up message contains an ASP Identifier, the SGP ! should save the
ASP Identifier for that ASP.  The SGP responds with an ! ASP Up Ack message
in acknowledgement.  The SGP sends an ASP Up Ack ! message in response to a
received ASP Up message even if the ASP is ! already marked as ASP- INACTIVE
at the SGP.  
  
--------------------------
  
  4.2.3.6 Notify Procedures
  
! A Notify message reflecting a change in the AS state MUST be sent to 
  all ASPs in the AS, except those in the ASP-DOWN state, with ! appropriate
Status Information and the ASP Identifier of the failed ! ASP.  The Notify
message MUST be sent after any ASP State or Traffic ! Management
acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ! ASP Active Ack,
or ASP Inactive Ack).  At the ASP, Layer Management is ! informed with an
M-NOTIFY indication primitive.
  
--------------------------

-- 
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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA-07: ASP Id changes
Date: Fri, 13 Jul 2001 08:51:39 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail4.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail4.rdc1.on.home.com [24.2.9.91]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Thanks Brian!

   I shall add it in to Iss8 today, assuming there are no objections on the
list.

Cheers,

  Greg
----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Thursday, July 12, 2001 7:07 PM
Subject: M3UA-07: ASP Id changes

> Greg,
>
> Here are all the modifications necessary to put ASP Id into M3UA to
> handle the scenarios addressed in the thread "ASP Partitioning".
> The changes are consistent with M2UA-09.  It is not really all that
> difficult ;)
>
> --Brian
>
> --------------------------
>
> Parameter Tag: 16 bits (unsigned integer)
>
> ...
>            0x84        User/Cause
>            0x0a        Reason
>            0x0b        Traffic Mode Type
>            0x0c        Error Code
>            0x0d        Status
> +          0x0e        ASP Identifier
>            0x85        Congestion Indications
>            0x86        Concerned Destination
>            0x87        Routing Key
>            0x88        Registration Result
>            0x89        De-registration Result
>
> --------------------------
>
>   The format for ASP Up message parameters is as follows:
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> +    |         Tag = 0x0e            |             Length            |
> +    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> +    |                        ASP Identifier*                        |
> +    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |         Tag = 0x04            |             Length            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      \                                                               \
>      /                          INFO String                          /
>      \                                                               \
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> + The optional ASP Identifier parameter contains a unique value that is
> + locally significant among the ASPs that support an AS.  The SGP should
> + save the ASP Identifier to be used, if necessary, with the Notify
> + message (see Section 3.8.2).
>
> --------------------------
>
>   The Notify message contains the following parameters:
>
>        Status                     Mandatory
> +      ASP Identifier             Optional
>        Routing Context            Optional
>        INFO String                Optional
>
>
> --------------------------
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |        Tag = 0x0d             |             Length            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |        Status Type            |    Status Information         |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> +    |        Tag = 0x0e             |             Length            |
> +    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> +    |                        ASP Identifier*                        |
> +    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |        Tag = 0x06             |             Length            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      \                                                               \
>      /                       Routing Context                         /
>      \                                                               \
>
> --------------------------
>
>   4.2.3.1 ASP Up Procedures
>
> ...
>
> ! When an ASP Up message is received at an SGP and internally the remote
> ! ASP is in the ASP-DOWN state and not considered locked-out for local
>   management reasons, the SGP marks the remote ASP in the state ASP-
> ! INACTIVE and informs Layer Management with an M-ASP_Up indication
> ! primitive.  If the SGP is aware, via current configuration data, which
> ! Application Servers the ASP is configured to operate in, the SGP
> ! updates the ASP state to ASP-INACTIVE in each AS that it is a member.
> ! Alternatively, the SGP may move the ASP into a pool of Inactive ASPs
> ! available for future configuration within Application Server(s),
> ! determined in a subsequent Registration Request or ASP Active
> ! procedure.  If the ASP Up message contains an ASP Identifier, the SGP
> ! should save the ASP Identifier for that ASP.  The SGP responds with an
> ! ASP Up Ack message in acknowledgement.  The SGP sends an ASP Up Ack
> ! message in response to a received ASP Up message even if the ASP is
> ! already marked as ASP- INACTIVE at the SGP.
>
> --------------------------
>
>   4.2.3.6 Notify Procedures
>
> ! A Notify message reflecting a change in the AS state MUST be sent to
>   all ASPs in the AS, except those in the ASP-DOWN state, with
> ! appropriate Status Information and the ASP Identifier of the failed
> ! ASP.  The Notify message MUST be sent after any ASP State or Traffic
> ! Management acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack,
> ! ASP Active Ack, or ASP Inactive Ack).  At the ASP, Layer Management is
> ! informed with an M-NOTIFY indication primitive.
>
> --------------------------
>
> --
> 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]
Date: Fri, 13 Jul 2001 08:48:17 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA-07: ASP Id changes
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.251]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

Sure!   See following text changes to SUA-06:

[email-masked] wrote:                  (Fri, 13 Jul 2001 15:58:36)
> 
> I'm assuming that you'd like to see this in SUA as well?
> 

--cut-here------X---------------

*** sua-06	Fri Jul 13 08:28:44 2001
--- sua-06.mods	Fri Jul 13 08:44:00 2001 ***************
*** 1887,1897 ****
        |         Tag = 0x0103          |      Parameter Length         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        /                     Destination Address                       /
        \                                                               \
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !
|         Tag = 0x000E          |             Length            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Congestion Level                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |         Tag = 0x0004          |             Length            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- 1887,1897 ----
        |         Tag = 0x0103          |      Parameter Length         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        /                     Destination Address                       /
        \                                                               \
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !
|         Tag = 0x000F          |             Length            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Congestion Level                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |         Tag = 0x0004          |             Length            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
***************
*** 1927,1936 ****
--- 1927,1940 ----
     that the Adaptation layer is up and running.
  
         0                     1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|            Tag = 0x000E       |             Length            | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +       |
ASP Identifier                         | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            Tag = 0x0109       |             Length            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        ASP Capabilities                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            Tag = 0x0004       |             Length            |
***************
*** 1938,1947 ****
--- 1942,1952 ----
        /                          Info String                          /
        \                                                               \
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
     Parameters
+      ASP Identifier                Optional
       ASP Capabilities              Optional
       Info String                   Optional
  
  3.5.2 ASP Up Ack (UP ACK)
  
***************
*** 2253,2270 ****
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Tag = 0x000D         |             Length            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Status Type/ID                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !
|          Tag = 0x0006         |             Length            |
  
  Loughney, et al.                                            [Page 39

  Internet Draft       SS7 SCCP-User Adaptation Layer      June 15, 2001
  
! 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        /                       Routing Context                         /
        \                                                               \
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Tag = 0x0004         |             Length            |
--- 2258,2278 ----
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Tag = 0x000D         |             Length            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Status Type/ID                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !
|          Tag = 0x000E         |             Length            | !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !       |
ASP Identifier                         |
  
  Loughney, et al.                                            [Page 39

  Internet Draft       SS7 SCCP-User Adaptation Layer      June 15, 2001
  
!       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !
|          Tag = 0x0006         |             Length            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        /                       Routing Context                         /
        \                                                               \
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Tag = 0x0004         |             Length            |
***************
*** 2275,2284 ****
--- 2283,2293 ----
  
     The NTFY message contains the following parameters:
  
     Parameters
       Status Type/ID                Mandatory +      ASP Identifier
Optional
       Routing Context               Optional
       Info String                   Optional
  
  3.8 Common Parameters
  
***************
*** 2298,2308 ****
     Not used in SUA                      0x0009
     Reason                               0x000A
     Traffic Mode Type                    0x000B
     Error Code                           0x000C
     Status Type/ID                       0x000D !    Congestion Level
0x000E
  
  3.8.1 Network Appearance
  
     The Network Appearance parameter identifies the SS7 network context
     for the message, for the purposes of logically separating the ---
2307,2318 ----
     Not used in SUA                      0x0009
     Reason                               0x000A
     Traffic Mode Type                    0x000B
     Error Code                           0x000C
     Status Type/ID                       0x000D !    ASP Identifier
0x000E !    Congestion Level                     0x000F
  
  3.8.1 Network Appearance
  
     The Network Appearance parameter identifies the SS7 network context
     for the message, for the purposes of logically separating the
***************
*** 2749,2769 ****
  3.8.14 Congestion Level
  
         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !
|         Tag = 0x000E          |             Length = 8        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Congestion Level                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
     Congestion Level field: 8-bits (unsigned integer)
  
     The valid values for the Congestion Level parameter range from 0 to
     7, where 0 indicates least congested and 7 indicates most congested
     subsystem.
  
  3.9 SUA-Specific parameters
  
     These TLV parameters are specific to the SUA protocol.
  
     Parameter Name                     Parameter ID --- 2759,2797 ----
  3.8.14 Congestion Level
  
         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !
|         Tag = 0x000F          |             Length = 8        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Congestion Level                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
     Congestion Level field: 8-bits (unsigned integer)
  
     The valid values for the Congestion Level parameter range from 0 to
     7, where 0 indicates least congested and 7 indicates most congested
     subsystem.
  
+ 3.8.15 ASP Identifier
+ 
+        0                   1                   2                   3 +
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +       |
Tag = 0x000E          |             Length = 8        | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +       |
ASP Identifier                         | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 
+    ASP Identifier field: 32-bits (unsigned integer) + 
+    The ASP Identifier field contains a unique value that is locally +
significant amoung the ASPs that support an AS.  The SGP should save the +
ASP Identifier to be used, if necessary, with the Notify message (see +
Section 3.7.2).
+ 
+ 
  3.9 SUA-Specific parameters
  
     These TLV parameters are specific to the SUA protocol.
  
     Parameter Name                     Parameter ID ***************
*** 3814,3823 ****
--- 3842,3855 ----
     wait for the ASP-UP Ack message before sending any other messages.
     If the remote peer receives any other SUA messages from an ASP,
     before an ASP-UP is received and acknowledged, the message should be
     discarded.
  
+    If the ASP Up message contains an ASP Identifier, the SGP should save
the +    ASP Identifier for that ASP, to be used in any Notify messages
which are +    sent indicating a change in the state of the ASP.
+ 
  4.4.2.2 ASP-Down
  
     The IPSP will mark an ASP as down if one of the following events
     occur:
  
***************
*** 3962,3974 ****
  
  4.4.3 SUA peer management messages
  
  4.4.3.1 Notify
  
!    A NTFY message reflecting a change in the AS state is sent to all !
ASPs in the AS, except those in the "Down" state, with appropriate !
Status Type/ID.
  
     In the case where a NTFY (AS-Pending) message is sent by an SG that
     now has no active ASPs to service the traffic, or a NTFY
     (Insufficient ASPs) is sent in the Loadshare mode, the NTFY does not
     explicitly force the ASP(s) receiving the message to become active.
--- 3994,4009 ----
  
  4.4.3 SUA peer management messages
  
  4.4.3.1 Notify
  
!    A NTFY message reflecting a change in the AS state MUST be sent to all
!    ASPs in the AS, except those in the ASP-DOWN state, with appropriate !
Status Type/ID and ASP Identifier of the failed ASP.  The Notify message !
MUST be sent after any ASP State or Traffic Management acknowledgement !
messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive !
Ack).
  
     In the case where a NTFY (AS-Pending) message is sent by an SG that
     now has no active ASPs to service the traffic, or a NTFY
     (Insufficient ASPs) is sent in the Loadshare mode, the NTFY does not
     explicitly force the ASP(s) receiving the message to become active.

--cut-here------X---------------

-- 
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]
Date: Fri, 13 Jul 2001 08:50:42 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA-07: Broadcast mode changes
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.251]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Here are the changes to include Broadcast mode.  They aren't really that bad
either.

---cut-here--------X-----------

*** m3ua-07.mods	Thu Jul 12 17:58:55 2001 --- m3ua-07.mods2	Fri
Jul 13 08:26:37 2001 ***************
*** 245,257 ****
  IP Server Process (IPSP) - A process instance of an IP-based 
  application.  An IPSP is essentially the same as an ASP, except that it
  uses M3UA in a point-to-point fashion.  Conceptually, an IPSP does not 
  use the services of a Signalling Gateway.
  
! Signalling Gateway Process (SGP) - A process instance of a Signalling !
Gateway.  It serves as an active, back-up or load-sharing process of a !
Signalling Gateway.
  
  Signalling Gateway - An SG is a signaling agent that receives/sends SCN 
  native signaling at the edge of the IP network [1].  An SG appears to 
  the SS7 network as an SS7 Signalling Point.  An SG contains a set of one 
  or more unique Signalling Gateway Processes, of which one or more is ---
245,257 ----
  IP Server Process (IPSP) - A process instance of an IP-based 
  application.  An IPSP is essentially the same as an ASP, except that it
  uses M3UA in a point-to-point fashion.  Conceptually, an IPSP does not 
  use the services of a Signalling Gateway.
  
! Signalling Gateway Process (SGP) - A process instance of a Signalling !
Gateway.  It serves as an active, back-up, load-sharing or broadcast !
process of a Signalling Gateway.
  
  Signalling Gateway - An SG is a signaling agent that receives/sends SCN 
  native signaling at the edge of the IP network [1].  An SG appears to 
  the SS7 network as an SS7 Signalling Point.  An SG contains a set of one 
  or more unique Signalling Gateway Processes, of which one or more is
***************
*** 625,635 ****
  signalling processes.  To support this, a signalling process must be 
  able to support distribution of M3UA messages to many simultaneous 
  active associations.  This message distribution function is based on 
  the status of provisioned routing keys, the availability of signalling 
  points in the SS7 network, and the redundancy model (active-standby, !
load-sharing, n+k) of the remote signalling processes.

  
  Sidebottom et al                                             [Page 11] ---
625,635 ----
  signalling processes.  To support this, a signalling process must be 
  able to support distribution of M3UA messages to many simultaneous 
  active associations.  This message distribution function is based on 
  the status of provisioned routing keys, the availability of signalling 
  points in the SS7 network, and the redundancy model (active-standby, !
load-sharing, broadcast, n+k) of the remote signalling processes.

  
  Sidebottom et al                                             [Page 11]
***************
*** 831,842 ****
  the individual ASPs in the list, as well as configuration changes and 
  possible fail-over mechanisms. 
  
  Normally, one or more ASPs are active in the AS (i.e., currently 
  processing traffic) but in certain failure and transition cases it is !
possible that there may be no active ASP available.  Both load-sharing ! and
backup scenarios are supported.
  
  When there is no matching Routing Key entry for an incoming SS7 
  message, a default treatment SHOULD be specified.  Possible solutions 
  are to provide a default Application Server at the SGP that directs all 
  unallocated traffic to a (set of) default ASP(s), or to drop the ---
831,842 ----
  the individual ASPs in the list, as well as configuration changes and 
  possible fail-over mechanisms. 
  
  Normally, one or more ASPs are active in the AS (i.e., currently 
  processing traffic) but in certain failure and transition cases it is !
possible that there may be no active ASP available.  Broadcast, !
load-sharing and backup scenarios are supported.
  
  When there is no matching Routing Key entry for an incoming SS7 
  message, a default treatment SHOULD be specified.  Possible solutions 
  are to provide a default Application Server at the SGP that directs all 
  unallocated traffic to a (set of) default ASP(s), or to drop the
***************
*** 996,1008 ****
  "k" ASPs are available to take over for a failed or unavailable ASP.  A 
  "1+1" active/back-up redundancy is a subset of this model. A simplex 
  "1+0" model is also supported as a subset, with no ASP redundancy.
  
  At the SGP, an Application Server list contains active and inactive ! ASPs
to support ASP load-sharing and fail-over procedures.  The list of ! ASPs
within a logical Application Server is kept updated in the SGP to ! reflect
the active Application Server Process(es).
  
  To avoid a single point of failure, it is recommended that a minimum of 
  two ASPs be in the list, resident in separate hosts and therefore 
  available over different SCTP Associations.  For example, in the 
  network shown in Figure 1, all messages to DPC x could be sent to ASP1 ---
996,1008 ----
  "k" ASPs are available to take over for a failed or unavailable ASP.  A 
  "1+1" active/back-up redundancy is a subset of this model. A simplex 
  "1+0" model is also supported as a subset, with no ASP redundancy.
  
  At the SGP, an Application Server list contains active and inactive ! ASPs
to support ASP broadcast, load-sharing and fail-over procedures.
! The list of ASPs within a logical Application Server is kept updated ! in
the SGP to reflect the active Application Server Process(es).
  
  To avoid a single point of failure, it is recommended that a minimum of 
  two ASPs be in the list, resident in separate hosts and therefore 
  available over different SCTP Associations.  For example, in the 
  network shown in Figure 1, all messages to DPC x could be sent to ASP1
***************
*** 1064,1084 ****
  Signalling Gateway is deployed as a cluster of hosts acting as a single 
  SG.  A primary/back-up redundancy model is possible, where the 
  unavailability of the SCTP association to a primary SGP could be used 
  to reroute affected traffic to an alternate SGP.  A load-sharing model 
  is possible, where the signalling messages are load-shared between !
multiple SGPs.  The distribution of the MTP3-user messages over the ! SGPs
should be done in such a way to minimize message mis-sequencing, ! as
required by the SS7 User Parts.
  
  It may also be possible for an ASP to use more than one SG to access a 
  specific SS7 end point, in a model that resembles an SS7 STP mated 
  pair.  Typically, SS7 STPs are deployed in mated pairs, with traffic 
  load-shared between them.  Other models are also possible, subject to 
  the limitations of the local SS7 network provisioning guidelines.
  
! >From the perspective of the M3UA layer at an ASP, a particular SG is 
  capable of transferring traffic to an SS7 destination if an SCTP 
  association with at least one SGP of the SG is established, the SGP has 
  returned an acknowledgement to the ASP to indicate that the ASP is 
  actively handling traffic for that destination, and the SGP has not 
  indicated that the destination is inaccessible.  When an ASP is ---
1064,1085 ----
  Signalling Gateway is deployed as a cluster of hosts acting as a single 
  SG.  A primary/back-up redundancy model is possible, where the 
  unavailability of the SCTP association to a primary SGP could be used 
  to reroute affected traffic to an alternate SGP.  A load-sharing model 
  is possible, where the signalling messages are load-shared between !
multiple SGPs.  A broadcast model is also possible, where signalling !
messages are sent to each active SGP in the SG.  The distribution of ! the
MTP3-user messages over the SGPs should be done in such a way to ! minimize
message mis-sequencing, as required by the SS7 User Parts.
  
  It may also be possible for an ASP to use more than one SG to access a 
  specific SS7 end point, in a model that resembles an SS7 STP mated 
  pair.  Typically, SS7 STPs are deployed in mated pairs, with traffic 
  load-shared between them.  Other models are also possible, subject to 
  the limitations of the local SS7 network provisioning guidelines.
  
! From the perspective of the M3UA layer at an ASP, a particular SG is 
  capable of transferring traffic to an SS7 destination if an SCTP 
  association with at least one SGP of the SG is established, the SGP has 
  returned an acknowledgement to the ASP to indicate that the ASP is 
  actively handling traffic for that destination, and the SGP has not 
  indicated that the destination is inaccessible.  When an ASP is
***************
*** 1090,1104 ****
  
  Sidebottom et al                                             [Page 19]
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
  
! both active/back-up and load-sharing model, in the event of failures, !
recovery and maintenance activities.  The ASP M3UA may also use this !
information for congestion avoidance purposes.  The distribution of the !
MTP3-user messages over the SGPs should be done in such a way to ! minimize
message mis-sequencing, as required by the SS7 User Parts.
  
  1.4.5 Flow Control
  Local Management at an ASP may wish to stop traffic across an SCTP 
  association in order to temporarily remove the association from service 
  or to perform testing and maintenance activity.  The function could ---
1091,1106 ----
  
  Sidebottom et al                                             [Page 19]
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
  
! active/back-up, load-sharing and broadcast models, in the event of !
failures, recovery and maintenance activities.  The ASP M3UA may also ! use
this information for congestion avoidance purposes.  The ! distribution of
the MTP3-user messages over the SGPs should be done in ! such a way to
minimize message mis-sequencing, as required by the SS7 ! User Parts.
  
  1.4.5 Flow Control
  Local Management at an ASP may wish to stop traffic across an SCTP 
  association in order to temporarily remove the association from service 
  or to perform testing and maintenance activity.  The function could
***************
*** 2746,2755 ****
--- 2748,2758 ----
     Server.  The valid values for Traffic Mode Type are shown in the 
     following table:
  
        1     Over-ride
        2     Load-share
+       3     Broadcast

  Sidebottom et al                                             [Page 48]
  
***************
*** 3184,3221 ****
     operation of the ASP within an AS. The valid values for Traffic Mode 
     Type are shown in the following table:
  
           1         Over-ride
           2         Load-share
!          3         Over-ride (Standby) !          4         Load-share
(Standby) ! 
!    Within a particular Routing Context, Over-ride and Load-share, !
either active or standby, MUST NOT be mixed.  The Over-ride value !
indicates that the ASP is operating in Over-ride mode, and the ASP !
takes over all traffic in an Application Server (i.e., primary/back- !    up
operation), over-riding any currently active ASPs in the AS.  In !
Load-share mode, the ASP will share in the traffic distribution with !
any other currently active ASPs.  The Standby versions of the Over- !
ride and Load-share Types indicate that the ASP is declaring itself !
ready to accept traffic but leaves it up to the sender as to when !    the
traffic is started.  Over-ride (Standby) indicates that the !    traffic
sender continues to use the currently active ASP until it !    can no longer
send/receive traffic (i.e., the currently active ASP !    transitions to
state ASP-DOWN or ASP-ACTIVE).  At this point the !    sender MUST move the
standby ASP to the ASP-ACTIVE state and !    commence traffic.  Load-share
(Standby) is similar - the sender !    continues to load-share to the
current ASPs until it is determined 

  Sidebottom et al                                             [Page 56]
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
  
!    that there is insufficient resources in the Load-share group.  When !
there are insufficient ASPs, the sender MUST move the ASP to state !
ASP-ACTIVE.
  
  Routing Context: n X 32-bit integers
  
     The optional Routing Context parameter contains (a list of) integers 
     indexing the Application Server traffic that the sending ASP is ---
3187,3230 ----
     operation of the ASP within an AS. The valid values for Traffic Mode 
     Type are shown in the following table:
  
           1         Over-ride
           2         Load-share
!          3         Broadcast
!          5         Over-ride (Standby) !          6         Load-share
(Standby) !          7         Broadcast (Standby) ! 
!    Within a particular Routing Context, Over-ride, Load-share  and !
Broadcast, either active or standby, MUST NOT be mixed.  The !    Over-ride
value indicates that the ASP is operating in Over-ride !    mode, and the
ASP takes over all traffic in an Application Server !    (i.e.,
primary/back- up operation), over-riding any currently !    active ASPs in
the AS.  In Load-share mode, the ASP will share in !    the traffic
distribution with any other currently active ASPs.  In !    the Broadcast
mode, the ASP will receive the same messages as any !    other currently
active ASP.  The Standby versions of the Over- !    ride, Load-share and
Broadcast Types indicate that the ASP is !    declaring itself ready to
accept traffic but leaves it up to the !    sender as to when the traffic is
started.  Over-ride (Standby) !    indicates that the traffic sender
continues to use the currently !    active ASP until it can no longer
send/receive traffic (i.e., the !    currently active ASP transitions to
state ASP-DOWN or ASP-ACTIVE).
!    At this point the sender MUST move the standby ASP to the !
ASP-ACTIVE state and commence traffic.  Load-share (Standby) and !
Broadcast (Standby) is similar - the sender continues to load-share !    or
broadcast to the current ASPs until it is determined that there

  Sidebottom et al                                             [Page 56]
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
  
!    is insufficient resources in the Load-share or Broadcast group.
!    When that there is insufficient resources in the Load-share or !
Broadcast group.  When there are insufficient ASPs, the sender MUST !
move the ASP to state ASP-ACTIVE.
  
  Routing Context: n X 32-bit integers
  
     The optional Routing Context parameter contains (a list of) integers 
     indexing the Application Server traffic that the sending ASP is
***************
*** 3240,3252 ****
  
  3.7.2 ASP Active Acknowledgement (ASP Active Ack)
  
  The ASP Active Ack message is used to acknowledge an ASP Active message 
  received from a remote M3UA peer.  In the case where an ASP Active !
(Over-ride (standby)) or ASP Active (Load-share (standby)) message is !
received, a second ASP Active Ack message is sent when the ASP is moved !
from the ASP-STANDBY to the ASP-ACTIVE state.
  
  The ASP Active Ack message contains the following parameters:
  
       Traffic Mode Type     Mandatory
       Routing Context       Optional
--- 3249,3262 ----
  
  3.7.2 ASP Active Acknowledgement (ASP Active Ack)
  
  The ASP Active Ack message is used to acknowledge an ASP Active message 
  received from a remote M3UA peer.  In the case where an ASP Active !
(Over-ride (standby)), ASP Active (Load-share (standby)) or ASP Active !
(Broadcast (standby)) message is received, a second ASP Active Ack ! message
is sent when the ASP is moved from the ASP-STANDBY to the ! ASP-ACTIVE
state.
  
  The ASP Active Ack message contains the following parameters:
  
       Traffic Mode Type     Mandatory
       Routing Context       Optional
***************
*** 3623,3635 ****
           2    Alternate ASP Active
  
  These notifications are not based on the SGP reporting the state change 
  of an ASP or AS.  In the Insufficent ASP Resources case, the SGP is 
  indicating to an ASP_INACTIVE ASP in the AS that another ASP is ! required
in order to handle the load of the AS (Load-sharing mode).  
! For the Alternate ASP Active case, an ASP is informed when an alternate !
ASP transitions to the ASP-ACTIVE state in Over-ride mode.  
  
  The format and description of the optional Routing Context and Info 
  String parameters is the same as for the ASP Active message (See 
  Section 
  3.5.5.)
--- 3633,3646 ----
           2    Alternate ASP Active
  
  These notifications are not based on the SGP reporting the state change 
  of an ASP or AS.  In the Insufficent ASP Resources case, the SGP is 
  indicating to an ASP_INACTIVE ASP in the AS that another ASP is ! required
in order to handle the load of the AS (Load-sharing or ! Broadcast mode).
For the Alternate ASP Active case, an ASP is ! informed when an alternate
ASP transitions to the ASP-ACTIVE state in ! Over-ride mode.  
  
  The format and description of the optional Routing Context and Info 
  String parameters is the same as for the ASP Active message (See 
  Section 
  3.5.5.)
***************
*** 3654,3673 ****
  
  The M3UA message distribution function (see Section 1.4.2.1) determines 
  the Application Server (AS) based on comparing the information in the 
  MTP-TRANSFER request primitive with a provisioned Routing Key. 
  
! >From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE 
  state is selected and a DATA message is constructed and issued on the 
  corresponding SCTP association.  If more than one ASP is in the ASP-
  ACTIVE state (i.e., traffic is to be load-shared across more than one 
  ASP), one of the ASPs in the ASP_ACTIVE state is selected from the ! list.
The selection algorithm is implementation dependent but could, ! for
example, be round-robin or based on, for example, the SLS or ISUP ! CIC.
The appropriate selection algorithm must be chosen carefully as ! it is
dependent on application assumptions and understanding of the ! degree of
state coordination between the ASP_ACTIVE ASPs in the AS. 

  Sidebottom et al                                             [Page 64]
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001 ---
3665,3686 ----
  
  The M3UA message distribution function (see Section 1.4.2.1) determines 
  the Application Server (AS) based on comparing the information in the 
  MTP-TRANSFER request primitive with a provisioned Routing Key. 
  
! From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE 
  state is selected and a DATA message is constructed and issued on the 
  corresponding SCTP association.  If more than one ASP is in the ASP-
  ACTIVE state (i.e., traffic is to be load-shared across more than one 
  ASP), one of the ASPs in the ASP_ACTIVE state is selected from the ! list.
If the ASPs are in Broadcast Mode, all active ASPs will be ! selected and
the message sent to each of the active ASPs.  The ! selection algorithm is
implementation dependent but could, for ! example, be round-robin or based
on, for example, the SLS or ISUP CIC.
! The appropriate selection algorithm must be chosen carefully as it is !
dependent on application assumptions and understanding of the degree ! of
state coordination between the ASP_ACTIVE ASPs in the AS. 

  Sidebottom et al                                             [Page 64]
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
***************
*** 4259,4280 ****
  default of 2 seconds.  Alternatively, retransmission of ASP Active 
  messages MAY be put under control of Layer Management.  In this method, 
  expiry of T(ack) results in an M-ASP_ACTIVE confirm primitive carrying 
  a negative indication.  
  
! There are four modes of Application Server traffic handling in the SGP !
M3UA layer - Over-ride, Over-ride (Standby), Load-share and Load-share !
(Standby).  The Traffic Mode Type parameter in the ASP Active message !
indicates the traffic handling mode used in a particular Application !
Server. If the SGP determines that the mode indicated in an ASP Active !
message is unsupported or incompatible with the mode currently ! configured
for the AS, the SGP responds with an Error message ! ("Unsupported / Invalid
Traffic Handling Mode").  If the Traffic ! Handling mode of the Application
Server is not already known via ! configuration data, then the Traffic
Handling mode indicated in the ! first ASP Active message causing the
transition of the Application ! Server state to AS-ACTIVE MAY be used to set
the mode.
  
  In the case of an Over-ride mode AS, reception of an ASP Active message 
  at an SGP causes the (re)direction of all traffic for the AS to the ASP 
  that sent the ASP Active message.  Any previously active ASP in the AS 
  is now considered to be in state ASP-INACTIVE and SHOULD no longer ---
4272,4294 ----
  default of 2 seconds.  Alternatively, retransmission of ASP Active 
  messages MAY be put under control of Layer Management.  In this method, 
  expiry of T(ack) results in an M-ASP_ACTIVE confirm primitive carrying 
  a negative indication.  
  
! There are six modes of Application Server traffic handling in the SGP !
M3UA layer - Over-ride, Over-ride (Standby), Load-share, Load-share !
(Standby), Broadcast, and Broadcast (Standby).  The Traffic Mode Type !
parameter in the ASP Active message indicates the traffic handling ! mode
used in a particular Application Server. If the SGP determines ! that the
mode indicated in an ASP Active message is unsupported or ! incompatible
with the mode currently configured for the AS, the SGP ! responds with an
Error message ("Unsupported / Invalid Traffic ! Handling Mode").  If the
Traffic Handling mode of the Application ! Server is not already known via
configuration data, then the Traffic ! Handling mode indicated in the first
ASP Active message causing the ! transition of the Application Server state
to AS-ACTIVE MAY be used to ! set the mode.
  
  In the case of an Over-ride mode AS, reception of an ASP Active message 
  at an SGP causes the (re)direction of all traffic for the AS to the ASP 
  that sent the ASP Active message.  Any previously active ASP in the AS 
  is now considered to be in state ASP-INACTIVE and SHOULD no longer
***************
*** 4332,4346 ****
  
  If there is no currently active ASP, an ASP Active Ack message 
  ("Loadshare") is returned right away and the traffic is directed to the 
  ASP.
  
- 
  All ASPs within a load-sharing mode AS must be able to process any 
  Data message received for the AS, in order to accommodate any potential 
  fail-over or rebalancing of the offered load.
  
  4.2.3.5 ASP Inactive Procedures
  
  When an ASP wishes to withdraw from receiving traffic within an AS, the 
  ASP sends an ASP Inactive message to the SGP or IPSP.  This action MAY 
  be initiated at the ASP by an M-ASP_INACTIVE request primitive from ---
4346,4387 ----
  
  If there is no currently active ASP, an ASP Active Ack message 
  ("Loadshare") is returned right away and the traffic is directed to the 
  ASP.
  
  All ASPs within a load-sharing mode AS must be able to process any 
  Data message received for the AS, in order to accommodate any potential 
  fail-over or rebalancing of the offered load.
  
+ In the case of a Broadcast mode AS, reception of an ASP Active message +
at an SGP or IPSP cuases the direction of traffic to the ASP sending + the
ASP Active message, in addition to all the other ASPs that are + currently
active in the AS.  The algorithm at the SGP for broadcasting + traffic
within an AS to all the active ASPs is a simple braoadcast + algorithm,
where every message is sent to each of the active ASPs.
+ 
+ An SGP or IPSP, upon reception of an ASP Active message for the first +
ASP in a Broadcast AS, MAY choose not to direct traffic to a newly + active
ASP until it determines that there are sufficient resources to + handle the
expected load (e.g., until there are "n" ASPs in state + ASP-ACTIVE in the
AS).
+ 
+ In the case of Broadcast (Standby) mode AS, the traffic is not started +
to the ASP until the SGP or IPSP determines that there are sufficient +
resuorces available in the AS.  This is likely when one of the active +
broadcast ASPs transitions to either the ASP-INACTIVE or ASP-DOWN + state.
At this point the ASP that sent the ASP Active message + ("Broadcast
(Standby)") is moved to the ASP_ACTIVE state and traffic + is started.  A
second ASP Active Ack message with a new Traffic Mode + Type ("Broadcast" -
previously "Broadcast (Standby)") is sent to the + ASP.  A Notify message
("Insufficient ASP resources active in AS") is + not sent in this case.
+ 
+ If there is no currently active ASP, an ASP Active Ack message +
("Broadcast") is returned right away and the traffic is directed to + the
ASP.
+ 
  4.2.3.5 ASP Inactive Procedures
  
  When an ASP wishes to withdraw from receiving traffic within an AS, the 
  ASP sends an ASP Inactive message to the SGP or IPSP.  This action MAY 
  be initiated at the ASP by an M-ASP_INACTIVE request primitive from
***************
*** 4375,4384 ****
--- 4416,4435 ----
  immediately included in the loadshare group and a Notify message is not 
  sent.  An ASP Inactive Ack message is sent to the ASP after all traffic 
  is halted and Layer Management is informed with an M-ASP_INACTIVE 
  indication primitive.
  
+ In the case of a Broadcast mode AS, the SGP moves the ASP to the +
ASP-INACTIVE state and the AS traffic is broadcast only to the + remaining
ASPs in the state ASP-ACTIVE.  A Notify message + ("Insufficient ASP
resources active in AS") MAY be sent to all + inactive ASPs, if required.
However, if a Broadcast ("Standby") ASP + is available, it may be now
immediately included in the broadcast + group and a Notify message is not
sent.  An ASP Inactive Ack message + is sent to the ASP after all traffic is
halted and Layer Management is + informed with an M-ASP_INACTIVE indication
primitive.
+ 
  Multiple ASP Inactive Ack messages MAY be used in response to an ASP 
  Inactive message containing multiple Routing Contexts, allowing the SGP 
  or IPSP to independently acknowledge for different (sets of) Routing 
  Contexts.  The SGP or IPSP sends an Error message ("Invalid Routing 
  Context") message for each invalid or un-configured Routing Context
***************
*** 4426,4438 ****
  informed with an M-NOTIFY indication primitive.
  
  In the case where a Notify message("AS-Pending") message is sent by an 
  SGP that now has no ASPs active to service the traffic, or where a 
  Notify message("Insufficient ASP resources active in AS") is sent in ! the
Loadshare mode, the Notify message does not explicitly compel the ! ASP(s)
receiving the message to become active. The ASPs remain in ! control of what
(and when) traffic action is taken.
  
  In the case where a Notify message does not contain a Routing Context
  parameter, the receiver must know, via configuration data, of which
  Application Servers the ASP is a member and take the appropriate action
for
  the ASP in each AS.
--- 4477,4489 ----
  informed with an M-NOTIFY indication primitive.
  
  In the case where a Notify message("AS-Pending") message is sent by an 
  SGP that now has no ASPs active to service the traffic, or where a 
  Notify message("Insufficient ASP resources active in AS") is sent in ! the
Loadshare or Broadcast mode, the Notify message does not ! explicitly compel
the ASP(s) receiving the message to become active.
! The ASPs remain in control of what (and when) traffic action is taken.
  
  In the case where a Notify message does not contain a Routing Context
  parameter, the receiver must know, via configuration data, of which
  Application Servers the ASP is a member and take the appropriate action
for
  the ASP in each AS.
***************
*** 4940,4955 ****
  state and ASP2 is to be a "back-up" in the event of communication 
  failure or the withdrawal from service of ASP1.  ASP2 may act as a hot, 
  warm, or cold back-up depending on the extent to which ASP1 and ASP2 
  share call/transaction state or can communicate call state under 
  failure/withdrawal events.  The example message flow is the same ! whether
the ASP Active messages indicate "Over-ride" or "Load-share" ! mode,
although typically this example would use an Over-ride mode. The ! SGP MAY
start sending any relevant DUNA, DRST and SCON messages to ASPs ! as soon as
they enter the ASP-INACTIVE state. In the case of MTP ! Restart, the
ASP-Active Ack message is only sent after all relevant ! DUNA/DRST/SCON
messages have been transmitted to the concerned ASP.

         SGP                        ASP1                        ASP2
          |                         |                          |
          |<--------ASP Up----------|                          | ---
4991,5007 ----
  state and ASP2 is to be a "back-up" in the event of communication 
  failure or the withdrawal from service of ASP1.  ASP2 may act as a hot, 
  warm, or cold back-up depending on the extent to which ASP1 and ASP2 
  share call/transaction state or can communicate call state under 
  failure/withdrawal events.  The example message flow is the same ! whether
the ASP Active messages indicate "Over-ride", "Load-share" ! or "Broadcast"
mode, although typically this example would use an ! Over-ride mode. The SGP
MAY start sending any relevant DUNA, DRST and ! SCON messages to ASPs as
soon as they enter the ASP-INACTIVE state. In ! the case of MTP Restart, the
ASP-Active Ack message is only sent after ! all relevant DUNA/DRST/SCON
messages have been transmitted to the ! concerned ASP.

         SGP                        ASP1                        ASP2
          |                         |                          |
          |<--------ASP Up----------|                          | 

---cut-here--------X-----------

-- 
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]
Date: Fri, 13 Jul 2001 09:01:51 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA-07: minor error
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-251.dallas.net [209.44.42.251]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

In the second to last paragraph of section 4.2.3.4 (in the middle of page 76
of v7), first sentence:

	In the case of a Load-share (Standby) mode AS, the traffic is not 
	started to the ASP until the SGP or IPSP determines that there are 
	insufficient resources available in the AS.  ...

This should be "sufficient" instead of "insufficient".

--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]
Date: Sun, 15 Jul 2001 02:28:03 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M3UA, M2UA, SUA: Mandatory ASP Identifier in ASP Up
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.251]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken, Greg, John,

I would like to propose that the ASP Identifier in the ASP Up message be
made mandatory as the SGP might have no other mechanism to identify the ASP
which has connected via an SCTP association.

That there exists cases where the SGP cannot identify the connecting ASP is
clear: any configuration which has multiple ASPs for a given host sharing
the same SCTP endpoints as illlustrated in the architectural diagrams for
M3UA as multiple ASPs per Host cannot be distinguished by SCTP endpoint.
The SGP has no other means to distinguish these ASPs and cannot perform
management blocking functions or AS state notifications or any other
procedures applicable in the AS-INACTIVE state.
In some configurations, the SGP will be unable to peform its functions
properly in all ASP states because it cannot identify the ASP and match it
to static configuration data.

Making the parameter mandatory allows the SGP to alway be able to
distinguish between connecting ASPs and apply the procedures appropriately.

The text in the ASP Up message description and text in the ASP Up procedures
would have to be changed to reflect that the ASP Id is a mandatory
parameter.

Comments?

-- 
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]