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

Date: Wed, 25 Jul 2001 05:08:56 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv7: SG redundancy
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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Pierre,

Please see more comments below...

Garnero, Pierre wrote:                    (Wed, 25 Jul 2001 11:43:56)
> Brian,
> 
> just some comments below:
> 
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, July 25, 2001 11:20 AM
> > To: sigtran
> > Subject: Re: M3UAv7: SG redundancy
> > 
> > 
> > Pierre,
> > 
> > Please see comments below...
> > 
> > Garnero, Pierre wrote:                                   
> > (Wed, 25 Jul 2001 10:33:34)
> > > Hello Hong,
> > > 
> > > please find another point of view, included in Brians comments...
> > > 
> > > Cheers,
> > > 
> > > PiG
> > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Wednesday, July 25, 2001 8:28 AM
> > > > To: sigtran
> > > > Subject: Re: M3UAv7: SG redundancy
> > > > 
> > > > 
> > > > Hong,
> > > > 
> > > > You bring up some good questions.
> > > > 
> > > > Hong Liu wrote:                              (Wed, 25 Jul 
> > > > 2001 08:08:07)
> > > > > Hi, Brian,
> > > > > 
> > > > > I am also confused by the notion of SG vs. SGP in the 
> > > > current M3UA spec.
> > > > > Maybe you can help me to understand the concepts better. I 
> > > > noticed that
> > > > > there was a long thread of discussions on the list a few 
> > > > months ago on
> > > > > this topic. So I apologize in advance if I bring up 
> > > > something that has
> > > > > already been clarified.
> > > > > 
> > > > > According to the current spec, an SG is a logical 
> > entity if it is
> > > > > composed of more than one SGP. From the SS7 network point 
> > > > of view, SG is
> > > > > the one that acts as an SS7 signaling point and is thus 
> > > > assigned a point
> > > > > code. Does it imply that all the SGPs of an SG will bear 
> > > > the same point
> > > > > code even if they are geographically separated? Is that 
> > > > what it means in
> > > > > the spec regarding a single management view to the SS7 network?
> > > > > 
> > > > > On the IP side, is it required that an ASP set up an M3UA 
> > > > association
> > > > > with each of the active SGPs? Or in other words, is it 
> > > > allowed by the
> > > > > spec that an ASP only sets up M3UA associations to a 
> > > > (non-empty) subset
> > > > > of the active SGPs?
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > --Hong
> > > > > 
> > > > [snip]
> > > > 
> > > > I believe that there are several points in the draft 
> > which lead to a
> > > > definition of an SG.  These are:
> > > > 
> > > >    o   An SGP is a unique transport (SCTP) endpoint.
> > > > 
> > > >    o   An SG is a collection or set of one or more SGPs.
> > > > 
> > > >    o   An SG terminates SS7 signalling links from the SS7 network.
> > > > 
> > > >    o   An SG has one set of Routing Keys which are shared 
> > by all the
> > > >        SGPs which make up the SG.
> > > > 
> > > >    o   Each SGP in an SG offers identical connectivity to the SS7
> > > >        network.
> > > > 
> > > > There are no restrictions placed on what point codes an SG 
> > > > does or does
> > > > not represent.  There are no restrictions placed on how many 
> > > > SGP a Host
> > > > represents.  There are no restrictions in terms of the 
> > geographical
> > > > positioning of SGP within an SG.
> > > > 
> > > 
> > > The draft stats: "An SG appears to the SS7 network as an 
> > SS7 Signalling 
> > > Point". 
> > > So, for a specific SS7 network, an SG has a unique point code.
> > 
> > An SG appears to the SS7 network as having a point code,
> > but it doen't have to have one of its own.  This was clearly
> > intended in the draft from the start: that the SG can just
> > represent the SPMC point code which "belongs" to the ASPs.
> > If the SG has a point code separate from the ASP, then it
> > would have to be an STP.  That is not required by the spec.
> > 
> Yes, an SG has a point code from the SS7 point of view ...
> We are in sync here !!! :-)

No we are not in sync.  The SG "represents" one or more point codes to the
SS7 network.  It does not necessarily "have" one.
I though that the draft made this crystal clear.  The SG may or may not have
local MTP-Users.  If it has no local MTP-Users and is not equipped with the
transfer function, then it does not "have" a point code.

> > > 
> > > > When your consider these points, an SG, in principle, 
> > looks like the
> > > > following:
> > > > 
> > > >                                                            
> > > >                            SG                              
> > > >                 / - - - - - - - - - - - \    SCTP          
> > > >                 |                       | Associations     
> > > >                        __________                          
> > > >                 |     |          |------|-----------       
> > > >                       |   SGP1   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >         SS7            __________                          
> > > >        Links    |     |          |------|-----------       
> > > >     ------------      |   SGP2   |------------------       
> > > >     ------------|     |__________|------|-----------       
> > > >     ------------       __________                       To 
> > > >     ------------|     |          |------|-----------   ASPs
> > > >     ------------      |   SGP3   |------------------       
> > > >     ------------|     |__________|------|-----------       
> > > >     ------------       __________                          
> > > >     ------------|     |          |------|-----------       
> > > >     ------------      |   SGP4   |------------------       
> > > >     ------------|     |__________|------|-----------       
> > > >     ------------                                           
> > > >                 |           .           |                  
> > > >                             .                              
> > > >                 |           .           |                  
> > > >                        __________                          
> > > >                 |     |          |------|-----------       
> > > >                       |   SGPn   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >                                                            
> > > >                 |                       |                  
> > > >                 \ - - - - - - - - - - - /                  
> > > > 
> > > > Where the argument, errr.., discussion errupts centers around the
> > > > restriction that all SGP in an SG must have identical connectivity
> > > > to the SS7 network and SHOULD be able to transfer traffic between
> > > > them to accomplish that feat.
> > > > 
> > > > My position is that, while in principle this sounds good, in 
> > > > practice it
> > > > does not:
> > > > 
> > > 
> > > My position is the opposite... :-)
> > 
> > Uhmm.
> > 
> > > 
> > > > On of the purposes of allowing multple SGP is to allow 
> > the SG to be a
> > > > collection of multiple hosts for redudancy and scaling.  
> > > > Unfortunately,
> > > > when SGPs are multiple hosts, the possibility of a 
> > "partitioned" SG
> > > > due to internal failures is possible.  That could look like this:
> > > > 
> > > >                                                            
> > > >                            SG                              
> > > >                 / - - - - - - - - - - - \    SCTP          
> > > >                 |                       | Associations     
> > > >                        __________                          
> > > >                 |     |          |------|-----------       
> > > >                       |   SGP1   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >         SS7            __________                          
> > > >        Links    |     |          |------|-----------       
> > > >     ------------      |   SGP2   |------------------       
> > > >     ------------|     |__________|------|-----------       
> > > >    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
> > > >     ------------       __________                       To 
> > > >     ------------|     |          |------|-----------   ASPs
> > > >     ------------      |   SGP3   |------------------       
> > > >     ------------|     |__________|------|-----------       
> > > >     ------------       __________                          
> > > >     ------------|     |          |------|-----------       
> > > >     ------------      |   SGP4   |------------------       
> > > >     ------------|     |__________|------|-----------       
> > > >     ------------                                           
> > > >                 |           .           |                  
> > > >                             .                              
> > > >                 |           .           |                  
> > > >                        __________                          
> > > >                 |     |          |------|-----------       
> > > >                       |   SGPn   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >                                                            
> > > >                 |                       |                  
> > > >                 \ - - - - - - - - - - - /                  
> > > > 
> > > > In some of the above "partitioned" scenarios, the SGPs 
> > need to be able
> > > > to tell the ASPs that they can no longer service specific 
> > > > traffic flows
> > > > towards the SS7 newtork.  In the current draft this can be 
> > > > accomplished
> > > > in two ways, both which are problematic.
> > > > 
> > > >   1.  The SGP can use DUNA, DAVA, and DRST independently from 
> > > > each of the
> > > >       SGP to indicate the difference in availability of 
> > > > routesets to the
> > > >       SS7 newtork above the partition and below the 
> > partition in the
> > > >       diagram.
> > > > 
> > > >       With the way that keeping DUNA, DAVA, DRST and SCON 
> > on a per-SGP
> > > >       basis at the ASP has been "watered down", however, in 
> > > > the M3UA-08
> > > >       draft, the SG cannot be guaranteed that the ASPs 
> > will respond
> > > >       properly to these partitioned indications.  If the 
> > ASPs respond
> > > >       under the "single management view", as is their 
> > option in the
> > > >       latest draft, this case will reduce to case (2) below.
> > > > 
> > > >   2.  The SGP drop their associations to the ASPs.  That is, 
> > > > The entire
> > > >       SG goes off-line.
> > > > 
> > > This is true but this is only 1 part of the problem.
> > > A partionned SG means also multiple PC with the same Id on 
> > the same SS7
> > > network.
> > 
> > It is the case in the SS7 network that we assign one point code
> > to two STPs (alias point code for GTT).  It does not cause problems
> > in the SS7 network.
> > 
> > > And this last problem is not solved by M3UA.
> > 
> > But could easily.
> I suppose that here we disagree on the level of quality the SG must
provide.
> And I think that this level will not be determined by you or me but by the

> future users of M3UA.
> My position is that an SS7 platform (SG) partition does not work because
> it could loose SS7 messages (1 or 1000 it cannot be acceptable, for me).
> M3UA cannot do anything here, it is a pure SS7 problem.
> > 
> > > Well, such a problem is mitigated by some particular SS7 
> > configurations, 
> > > for instance, when SGPs are connected to one and only one adjacent,
> > > but in this case, the configuration don't take advantage of the SS7
> > > redundancy:
> > > if one SGP fails, an entire route is lost...
> > > So, I think that inter SGP communications must be designed 
> > by SG vendors
> > > and not by M3UA.
> > > I really think that SG vendors could be creative in this 
> > domain and provide
> > > an inter SGP communication mechanism very reliable, or even 
> > provide a 
> > > mechanism (may be with another LAN dedicated to this 
> > purpose) to "detect"
> > > SG platform partition... and avoid, even when using "single 
> > management
> > > view",
> > > to drop all the SGP associations to the ASPs. 
> > 
> > All this cost for guaranteed inter-SGP communication is not necessary.
> Well, does everybody in this mailing list agree on this comment ?
> > With just a little support from M3UA, the platform could run fully
> > partitioned and happy.  Detailed discussion of this was provided on
> > other threads.  Aside from low volume changeover messages and routing
> > messages there should never be a need to route user level 
> > traffic between
> > SGP.  A patition in that case only causes minor message loss during
> > changeovers and is acceptable because the probability of partitioning
> > failure coupled with the probability of changeover can be 
> > engineered to
> > meet message lost requirements quite economically.
> What means carrier-grade then ? 
> Anyway, I think that truth here depends on the quality level the final
> user wants ... and each future user will have its own definition of
> "carrier-grade" level.

Don't be ridiculous.  The arrangement only loses messages when failures
occur.  This is permitted.  Just as long as the failure rate is controlled
to within those bounds which are acceptable by the message loss requirements
of MTP.

Compare this to how may messages your fancy inter-SGP arrangement is going
to lose when (not "if") it partitions.

> > 
> > I have handled the problem, it just needs minor support from M3UA.
> > 
> On the IP side, may be. Not on the SS7 side (IMHO).

M3UA is not responsible for the SS7 side, the SG implementation is.  M3UA
need only provide the mechanisms reqruired by the SG to perform its
function.  I do not have to prove to _you_ that the SS7 side works.

I am not shutting off my customer's $1M/hr cash flow just to satisfy a "MAY"
in the spec.

> > > 
> > > 
> > > > There is only one arrangement of SG/SGP in my mind that 
> > can keep this
> > > > from happening:  Make every SG consist of only one SGP, 
> > and have each
> > > > SG support only one SS7 link, like this:
> > > > 
> > > >                 / - - - - - - - - - - - \    SCTP          
> > > >                 | SG                    | Associations     
> > > >        SS7             __________                          
> > > >        Link     |     |          |------|-----------       
> > > >    -------------------|   SGP1   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >                                                            
> > > >                 |                       |                  
> > > >                 \ - - - - - - - - - - - /                  
> > > >                 / - - - - - - - - - - - \    SCTP          
> > > >                 | SG                    | Associations     
> > > >        SS7             __________                          
> > > >        Link     |     |          |------|-----------       
> > > >    -------------------|   SGP2   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >                                                            
> > > >                 |                       |                  
> > > >                 \ - - - - - - - - - - - /                  
> > > >                 / - - - - - - - - - - - \    SCTP          
> > > >                 | SG                    | Associations     
> > > >        SS7             __________                          
> > > >        Link     |     |          |------|-----------       
> > > >    -------------------|   SGP3   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >                                                            
> > > >                 |                       |                  
> > > >                 \ - - - - - - - - - - - /                  
> > > >                             .                              
> > > >                             .                              
> > > >                             .                              
> > > >                 / - - - - - - - - - - - \    SCTP          
> > > >                 | SG                    | Associations     
> > > >        SS7             __________                          
> > > >        Link     |     |          |------|-----------       
> > > >    -------------------|   SGPn   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >                                                            
> > > >                 |                       |                  
> > > >                 \ - - - - - - - - - - - /                  
> > > > 
> > > > This is possible, however, it pretty much reduces M3UA to M2UA.
> > > > 
> > > > I would rather see the SGP be provided with some 
> > mechanism by way of
> > > > which it can be assured that the ASPs will respond properly to
> > > > partitioned SGP.
> > > > 
> > > > Until they do, I cannot see that M3UA can be implemented in a
> > > > carrier-class arrangement with ASPs which treat the SG with a 
> > > > "single management view".
> > > Well, no, I think it is possible but requires a lot of experience
> > > in distributed computing (at least for the SGP vendors..). 
> > > > 
> > > > 
> > > > --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]
> > > > 
> > > 
> > > 
> > > ---
> > > 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]

-- 
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, 25 Jul 2001 05:20:35 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: M3UA-08: Flow Control
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

SCTP provides no per-stream user level flow control.  In practice, the
advantages of circumventing hol blocking are defeated in SCTP by the lack of
per-stream flow control.  I may be advisable to open a separate SCTP
assocation per AS to accomodate this.

--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]
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-m2pa-03.txt
Date: Wed, 25 Jul 2001 06:41:04 -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		: SS7 MTP2-User Peer-to-Peer Adaptation Layer
	Author(s)	: T. George, R. Dantu, M. Kalla, H. Schwarzbauer,
                          G. Sidebottom, K. Morneault
	Filename	: draft-ietf-sigtran-m2pa-03.txt
	Pages		: 51
	Date		: 24-Jul-01
	
This Internet Draft defines a protocol supporting the transport of Signaling
System Number 7 (SS7) Message Transfer Part (MTP) Layer 3 signaling messages
over Internet Protocol (IP) using the services of the Stream Control
Transmission Protocol (SCTP).  This protocol would be used between SS7
Signaling Points employing the MTP Level 3 protocol. The SS7 Signaling
Points may also employ standard SS7 links using the SS7 MTP Layer 2 to
provide transport of MTP Layer 3 signaling messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-m2pa-03.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-m2pa-03.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-m2pa-03.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-m2pa-03.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-sigtran-m2pa-03.txt> ---
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-sua-07.txt
Date: Wed, 25 Jul 2001 06:41:09 -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 SCCP-User Adaptation Layer (SUA)
	Author(s)	: J. Loughney, G. Sidebottom, G. Mousseau, 
                          S. Lorusso, L. Coede, G. Verwimp, 
                          J. Keller, F. Escobar, W. Sully, S. Furniss
	Filename	: draft-ietf-sigtran-sua-07.txt
	Pages		: 87
	Date		: 24-Jul-01
	
This Internet Draft defines a protocol for the transport of any SS7
SCCP-User signaling (e.g., TCAP, RANAP, etc.) over IP using the Stream
Control Transport Protocol.  The protocol should be modular and symmetric,
to allow it to work in diverse architectures, such as a Signaling Gateway to
IP Signaling Endpoint architecture as well as a peer-to-peer IP Signaling
Endpoint architecture.  Protocol elements are added to allow seamless
operation between peers in the SS7 and IP domains.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sua-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-sua-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-sua-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-sua-07.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-sigtran-sua-07.txt> ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 25 Jul 2001 06:33:34 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Tom George <[email-masked]>
Subject: M2PA: User Level Acknowledgements
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Tom,

I still see that you don't understand that M2PA needs user level
acknowledgements which SCTP does not provide.
The draft as it stands cannot handle Receive Congestion or Remote Processor
Outage conditions correctly.

It will be necessary to put a sequence number on M2PA data messages and pass
back an ACK at the M2PA level to fix this.  SCTP will not help.

--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]
From: "Desiderio, Didier" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv7: SG redundancy
Date: Wed, 25 Jul 2001 13:38:22 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zmamail04.zma.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zmamail04.zma.compaq.com [161.114.64.104]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,
Can you explain that, consider the following :

1/ SGP in the same SG do not have a "single management point of view" that
is
to say they are sharing the same ss7 destinations but each SGP has its own
management view...

                        SG
             + - - - - - - - - - - - +
     SS7     |                       |
    Links           __________            SCTP  ------------|     |
|      | Associations   __________  ------------      |   SGP1
|----------------------|          |  ------------|     |__________|      |
|   ASP    |
                    __________                  +----|__________|
------------|     |          |      |          |  ------------      |   SGP2
|-----------------+  ------------|     |__________|      |

             |                       |
             + - - - - - - - - - - - +

2/ all destinations in SGP1 are UP.
3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for all
destinations...
3/ The SCTP asso SGP1-ASP just falling.
4/ ASP has to send data to one destination and this SG is the priority
route.

Does the ASP not send this data? 
Does the ASP choose another SG to send this DATA?
>> even if the destination is not considered as DOWN from SS7 point of view
and
   this SG is the priority route!!!!

And is it aceptable on the M3UA point of view?

/Didier

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Wednesday,
July 25, 2001 12:09 PM To: sigtran
Subject: Re: M3UAv7: SG redundancy

Pierre,

Please see more comments below...

Garnero, Pierre wrote:                    (Wed, 25 Jul 2001 11:43:56)
> Brian,
> 
> just some comments below:
> 
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, July 25, 2001 11:20 AM
> > To: sigtran
> > Subject: Re: M3UAv7: SG redundancy
> > 
> > 
> > Pierre,
> > 
> > Please see comments below...
> > 
> > Garnero, Pierre wrote:                                   
> > (Wed, 25 Jul 2001 10:33:34)
> > > Hello Hong,
> > > 
> > > please find another point of view, included in Brians comments...
> > > 
> > > Cheers,
> > > 
> > > PiG
> > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Wednesday, July 25, 2001 8:28 AM
> > > > To: sigtran
> > > > Subject: Re: M3UAv7: SG redundancy
> > > > 
> > > > 
> > > > Hong,
> > > > 
> > > > You bring up some good questions.
> > > > 
> > > > Hong Liu wrote:                              (Wed, 25 Jul 
> > > > 2001 08:08:07)
> > > > > Hi, Brian,
> > > > > 
> > > > > I am also confused by the notion of SG vs. SGP in the 
> > > > current M3UA spec.
> > > > > Maybe you can help me to understand the concepts better. I 
> > > > noticed that
> > > > > there was a long thread of discussions on the list a few 
> > > > months ago on
> > > > > this topic. So I apologize in advance if I bring up 
> > > > something that has
> > > > > already been clarified.
> > > > > 
> > > > > According to the current spec, an SG is a logical 
> > entity if it is
> > > > > composed of more than one SGP. From the SS7 network point 
> > > > of view, SG is
> > > > > the one that acts as an SS7 signaling point and is thus 
> > > > assigned a point
> > > > > code. Does it imply that all the SGPs of an SG will bear 
> > > > the same point
> > > > > code even if they are geographically separated? Is that 
> > > > what it means in
> > > > > the spec regarding a single management view to the SS7 network?
> > > > > 
> > > > > On the IP side, is it required that an ASP set up an M3UA 
> > > > association
> > > > > with each of the active SGPs? Or in other words, is it 
> > > > allowed by the
> > > > > spec that an ASP only sets up M3UA associations to a 
> > > > (non-empty) subset
> > > > > of the active SGPs?
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > --Hong
> > > > > 
> > > > [snip]
> > > > 
> > > > I believe that there are several points in the draft 
> > which lead to a
> > > > definition of an SG.  These are:
> > > > 
> > > >    o   An SGP is a unique transport (SCTP) endpoint.
> > > > 
> > > >    o   An SG is a collection or set of one or more SGPs.
> > > > 
> > > >    o   An SG terminates SS7 signalling links from the SS7 network.
> > > > 
> > > >    o   An SG has one set of Routing Keys which are shared 
> > by all the
> > > >        SGPs which make up the SG.
> > > > 
> > > >    o   Each SGP in an SG offers identical connectivity to the SS7
> > > >        network.
> > > > 
> > > > There are no restrictions placed on what point codes an SG 
> > > > does or does
> > > > not represent.  There are no restrictions placed on how many 
> > > > SGP a Host
> > > > represents.  There are no restrictions in terms of the 
> > geographical
> > > > positioning of SGP within an SG.
> > > > 
> > > 
> > > The draft stats: "An SG appears to the SS7 network as an 
> > SS7 Signalling 
> > > Point". 
> > > So, for a specific SS7 network, an SG has a unique point code.
> > 
> > An SG appears to the SS7 network as having a point code,
> > but it doen't have to have one of its own.  This was clearly
> > intended in the draft from the start: that the SG can just
> > represent the SPMC point code which "belongs" to the ASPs.
> > If the SG has a point code separate from the ASP, then it
> > would have to be an STP.  That is not required by the spec.
> > 
> Yes, an SG has a point code from the SS7 point of view ...
> We are in sync here !!! :-)

No we are not in sync.  The SG "represents" one or more point codes to the
SS7 network.  It does not necessarily "have" one.
I though that the draft made this crystal clear.  The SG may or may not have
local MTP-Users.  If it has no local MTP-Users and is not equipped with the
transfer function, then it does not "have" a point code.

> > > 
> > > > When your consider these points, an SG, in principle, 
> > looks like the
> > > > following:
> > > > 
> > > >                                                            
> > > >                            SG                              
> > > >                 / - - - - - - - - - - - \    SCTP          
> > > >                 |                       | Associations     
> > > >                        __________                          
> > > >                 |     |          |------|-----------       
> > > >                       |   SGP1   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >         SS7            __________                          
> > > >        Links    |     |          |------|-----------       
> > > >     ------------      |   SGP2   |------------------       
> > > >     ------------|     |__________|------|-----------       
> > > >     ------------       __________                       To 
> > > >     ------------|     |          |------|-----------   ASPs
> > > >     ------------      |   SGP3   |------------------       
> > > >     ------------|     |__________|------|-----------       
> > > >     ------------       __________                          
> > > >     ------------|     |          |------|-----------       
> > > >     ------------      |   SGP4   |------------------       
> > > >     ------------|     |__________|------|-----------       
> > > >     ------------                                           
> > > >                 |           .           |                  
> > > >                             .                              
> > > >                 |           .           |                  
> > > >                        __________                          
> > > >                 |     |          |------|-----------       
> > > >                       |   SGPn   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >                                                            
> > > >                 |                       |                  
> > > >                 \ - - - - - - - - - - - /                  
> > > > 
> > > > Where the argument, errr.., discussion errupts centers around the
> > > > restriction that all SGP in an SG must have identical connectivity
> > > > to the SS7 network and SHOULD be able to transfer traffic between
> > > > them to accomplish that feat.
> > > > 
> > > > My position is that, while in principle this sounds good, in 
> > > > practice it
> > > > does not:
> > > > 
> > > 
> > > My position is the opposite... :-)
> > 
> > Uhmm.
> > 
> > > 
> > > > On of the purposes of allowing multple SGP is to allow 
> > the SG to be a
> > > > collection of multiple hosts for redudancy and scaling.  
> > > > Unfortunately,
> > > > when SGPs are multiple hosts, the possibility of a 
> > "partitioned" SG
> > > > due to internal failures is possible.  That could look like this:
> > > > 
> > > >                                                            
> > > >                            SG                              
> > > >                 / - - - - - - - - - - - \    SCTP          
> > > >                 |                       | Associations     
> > > >                        __________                          
> > > >                 |     |          |------|-----------       
> > > >                       |   SGP1   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >         SS7            __________                          
> > > >        Links    |     |          |------|-----------       
> > > >     ------------      |   SGP2   |------------------       
> > > >     ------------|     |__________|------|-----------       
> > > >    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
> > > >     ------------       __________                       To 
> > > >     ------------|     |          |------|-----------   ASPs
> > > >     ------------      |   SGP3   |------------------       
> > > >     ------------|     |__________|------|-----------       
> > > >     ------------       __________                          
> > > >     ------------|     |          |------|-----------       
> > > >     ------------      |   SGP4   |------------------       
> > > >     ------------|     |__________|------|-----------       
> > > >     ------------                                           
> > > >                 |           .           |                  
> > > >                             .                              
> > > >                 |           .           |                  
> > > >                        __________                          
> > > >                 |     |          |------|-----------       
> > > >                       |   SGPn   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >                                                            
> > > >                 |                       |                  
> > > >                 \ - - - - - - - - - - - /                  
> > > > 
> > > > In some of the above "partitioned" scenarios, the SGPs 
> > need to be able
> > > > to tell the ASPs that they can no longer service specific 
> > > > traffic flows
> > > > towards the SS7 newtork.  In the current draft this can be 
> > > > accomplished
> > > > in two ways, both which are problematic.
> > > > 
> > > >   1.  The SGP can use DUNA, DAVA, and DRST independently from 
> > > > each of the
> > > >       SGP to indicate the difference in availability of 
> > > > routesets to the
> > > >       SS7 newtork above the partition and below the 
> > partition in the
> > > >       diagram.
> > > > 
> > > >       With the way that keeping DUNA, DAVA, DRST and SCON 
> > on a per-SGP
> > > >       basis at the ASP has been "watered down", however, in 
> > > > the M3UA-08
> > > >       draft, the SG cannot be guaranteed that the ASPs 
> > will respond
> > > >       properly to these partitioned indications.  If the 
> > ASPs respond
> > > >       under the "single management view", as is their 
> > option in the
> > > >       latest draft, this case will reduce to case (2) below.
> > > > 
> > > >   2.  The SGP drop their associations to the ASPs.  That is, 
> > > > The entire
> > > >       SG goes off-line.
> > > > 
> > > This is true but this is only 1 part of the problem.
> > > A partionned SG means also multiple PC with the same Id on 
> > the same SS7
> > > network.
> > 
> > It is the case in the SS7 network that we assign one point code
> > to two STPs (alias point code for GTT).  It does not cause problems
> > in the SS7 network.
> > 
> > > And this last problem is not solved by M3UA.
> > 
> > But could easily.
> I suppose that here we disagree on the level of quality the SG must
provide.
> And I think that this level will not be determined by you or me but by the

> future users of M3UA.
> My position is that an SS7 platform (SG) partition does not work because
> it could loose SS7 messages (1 or 1000 it cannot be acceptable, for me).
> M3UA cannot do anything here, it is a pure SS7 problem.
> > 
> > > Well, such a problem is mitigated by some particular SS7 
> > configurations, 
> > > for instance, when SGPs are connected to one and only one adjacent,
> > > but in this case, the configuration don't take advantage of the SS7
> > > redundancy:
> > > if one SGP fails, an entire route is lost...
> > > So, I think that inter SGP communications must be designed 
> > by SG vendors
> > > and not by M3UA.
> > > I really think that SG vendors could be creative in this 
> > domain and provide
> > > an inter SGP communication mechanism very reliable, or even 
> > provide a 
> > > mechanism (may be with another LAN dedicated to this 
> > purpose) to "detect"
> > > SG platform partition... and avoid, even when using "single 
> > management
> > > view",
> > > to drop all the SGP associations to the ASPs. 
> > 
> > All this cost for guaranteed inter-SGP communication is not necessary.
> Well, does everybody in this mailing list agree on this comment ?
> > With just a little support from M3UA, the platform could run fully
> > partitioned and happy.  Detailed discussion of this was provided on
> > other threads.  Aside from low volume changeover messages and routing
> > messages there should never be a need to route user level 
> > traffic between
> > SGP.  A patition in that case only causes minor message loss during
> > changeovers and is acceptable because the probability of partitioning
> > failure coupled with the probability of changeover can be 
> > engineered to
> > meet message lost requirements quite economically.
> What means carrier-grade then ? 
> Anyway, I think that truth here depends on the quality level the final
> user wants ... and each future user will have its own definition of
> "carrier-grade" level.

Don't be ridiculous.  The arrangement only loses messages when failures
occur.  This is permitted.  Just as long as the failure rate is controlled
to within those bounds which are acceptable by the message loss requirements
of MTP.

Compare this to how may messages your fancy inter-SGP arrangement is going
to lose when (not "if") it partitions.

> > 
> > I have handled the problem, it just needs minor support from M3UA.
> > 
> On the IP side, may be. Not on the SS7 side (IMHO).

M3UA is not responsible for the SS7 side, the SG implementation is.  M3UA
need only provide the mechanisms reqruired by the SG to perform its
function.  I do not have to prove to _you_ that the SS7 side works.

I am not shutting off my customer's $1M/hr cash flow just to satisfy a "MAY"
in the spec.

> > > 
> > > 
> > > > There is only one arrangement of SG/SGP in my mind that 
> > can keep this
> > > > from happening:  Make every SG consist of only one SGP, 
> > and have each
> > > > SG support only one SS7 link, like this:
> > > > 
> > > >                 / - - - - - - - - - - - \    SCTP          
> > > >                 | SG                    | Associations     
> > > >        SS7             __________                          
> > > >        Link     |     |          |------|-----------       
> > > >    -------------------|   SGP1   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >                                                            
> > > >                 |                       |                  
> > > >                 \ - - - - - - - - - - - /                  
> > > >                 / - - - - - - - - - - - \    SCTP          
> > > >                 | SG                    | Associations     
> > > >        SS7             __________                          
> > > >        Link     |     |          |------|-----------       
> > > >    -------------------|   SGP2   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >                                                            
> > > >                 |                       |                  
> > > >                 \ - - - - - - - - - - - /                  
> > > >                 / - - - - - - - - - - - \    SCTP          
> > > >                 | SG                    | Associations     
> > > >        SS7             __________                          
> > > >        Link     |     |          |------|-----------       
> > > >    -------------------|   SGP3   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >                                                            
> > > >                 |                       |                  
> > > >                 \ - - - - - - - - - - - /                  
> > > >                             .                              
> > > >                             .                              
> > > >                             .                              
> > > >                 / - - - - - - - - - - - \    SCTP          
> > > >                 | SG                    | Associations     
> > > >        SS7             __________                          
> > > >        Link     |     |          |------|-----------       
> > > >    -------------------|   SGPn   |------------------       
> > > >                 |     |__________|------|-----------       
> > > >                                                            
> > > >                 |                       |                  
> > > >                 \ - - - - - - - - - - - /                  
> > > > 
> > > > This is possible, however, it pretty much reduces M3UA to M2UA.
> > > > 
> > > > I would rather see the SGP be provided with some 
> > mechanism by way of
> > > > which it can be assured that the ASPs will respond properly to
> > > > partitioned SGP.
> > > > 
> > > > Until they do, I cannot see that M3UA can be implemented in a
> > > > carrier-class arrangement with ASPs which treat the SG with a 
> > > > "single management view".
> > > Well, no, I think it is possible but requires a lot of experience
> > > in distributed computing (at least for the SGP vendors..). 
> > > > 
> > > > 
> > > > --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]
> > > > 
> > > 
> > > 
> > > ---
> > > 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]

-- 
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: Wed, 25 Jul 2001 06:43:15 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: John Loughney <[email-masked]>
Subject: SUAv7: Traffic Modes
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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

There is no Broadcast mode AS in the spec.  Please add Traffic Mode
Broadcast and the Correlation Id parameter that goes with it.  Line up the
traffic modes and procedures to match M3UAv8.

Broadcast mode solves the SGP having to know the TID allocation policy of
the ASPs.  It also solves a lot of synchronization and failover problems
between ASPs on TCAP queries.

Would you like text?

--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: Wed, 25 Jul 2001 06:49:48 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv7: SG redundancy
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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Didier,

I have answered this before, but, again: If I can modify your diagram
sligtly:
  
                          SG
               + - - - - - - - - - - - +
       SS7     |Switch                 |
      Links       |   __________            SCTP
   ------------|--|  |          |      | Associations   __________
   ------------ --|--|   SGP1   |-X-X-X-X-X-X-X-X-X-X--|          |
   ------------|--|  |__________|      |               |   ASP    |
                  |   __________                  +----|__________|
   -X-X-X-X-X--|--|  |          |      |          |
   -X-X-X-X-X-- --|--|   SGP2   |-----------------+
   -X-X-X-X-X--|--|  |__________|      |
                  |
               |                       |
               + - - - - - - - - - - - +
  
If there is another degree of freedom between the SGP and the SS7 Links
(H.100 bus, M2UA) then in your scenario I would have SGP2 take over the SS7
links from SGP1.
There is still no need to route user level traffic between SGP.  Depending
on the architecture, it might be too drastic a measure off the start.

--Brian

> 2/ all destinations in SGP1 are UP.
> 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for all
> destinations...
> 3/ The SCTP asso SGP1-ASP just falling.

Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
13:38:22)
> Brian,
> Can you explain that, consider the following :
> 
> 1/ SGP in the same SG do not have a "single management point of view" that
> is
> to say they are sharing the same ss7 destinations but each SGP has its own

> management view...
> 
>                         SG
>              + - - - - - - - - - - - +
>      SS7     |                       |
>     Links           __________            SCTP
>  ------------|     |          |      | Associations   __________
>  ------------      |   SGP1   |----------------------|          |
>  ------------|     |__________|      |               |   ASP    |
>                     __________                  +----|__________|
>  ------------|     |          |      |          |
>  ------------      |   SGP2   |-----------------+
>  ------------|     |__________|      |
> 
>              |                       |
>              + - - - - - - - - - - - +
> 
> 2/ all destinations in SGP1 are UP.
> 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for all
> destinations...
> 3/ The SCTP asso SGP1-ASP just falling.
> 4/ ASP has to send data to one destination and this SG is the priority
> route.
> 
> Does the ASP not send this data? 
> Does the ASP choose another SG to send this DATA?
> >> even if the destination is not considered as DOWN from SS7 point of
view
> and
>    this SG is the priority route!!!!
> 
> And is it aceptable on the M3UA point of view?
> 
> /Didier
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 12:09 PM
> To: sigtran
> Subject: Re: M3UAv7: SG redundancy
> 
> 
> Pierre,
> 
> Please see more comments below...
> 
> Garnero, Pierre wrote:                    (Wed, 25 Jul 2001 11:43:56)
> > Brian,
> > 
> > just some comments below:
> > 
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, July 25, 2001 11:20 AM
> > > To: sigtran
> > > Subject: Re: M3UAv7: SG redundancy
> > > 
> > > 
> > > Pierre,
> > > 
> > > Please see comments below...
> > > 
> > > Garnero, Pierre wrote:                                   
> > > (Wed, 25 Jul 2001 10:33:34)
> > > > Hello Hong,
> > > > 
> > > > please find another point of view, included in Brians comments...
> > > > 
> > > > Cheers,
> > > > 
> > > > PiG
> > > > 
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Wednesday, July 25, 2001 8:28 AM
> > > > > To: sigtran
> > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > 
> > > > > 
> > > > > Hong,
> > > > > 
> > > > > You bring up some good questions.
> > > > > 
> > > > > Hong Liu wrote:                              (Wed, 25 Jul 
> > > > > 2001 08:08:07)
> > > > > > Hi, Brian,
> > > > > > 
> > > > > > I am also confused by the notion of SG vs. SGP in the 
> > > > > current M3UA spec.
> > > > > > Maybe you can help me to understand the concepts better. I 
> > > > > noticed that
> > > > > > there was a long thread of discussions on the list a few 
> > > > > months ago on
> > > > > > this topic. So I apologize in advance if I bring up 
> > > > > something that has
> > > > > > already been clarified.
> > > > > > 
> > > > > > According to the current spec, an SG is a logical 
> > > entity if it is
> > > > > > composed of more than one SGP. From the SS7 network point 
> > > > > of view, SG is
> > > > > > the one that acts as an SS7 signaling point and is thus 
> > > > > assigned a point
> > > > > > code. Does it imply that all the SGPs of an SG will bear 
> > > > > the same point
> > > > > > code even if they are geographically separated? Is that 
> > > > > what it means in
> > > > > > the spec regarding a single management view to the SS7 network?
> > > > > > 
> > > > > > On the IP side, is it required that an ASP set up an M3UA 
> > > > > association
> > > > > > with each of the active SGPs? Or in other words, is it 
> > > > > allowed by the
> > > > > > spec that an ASP only sets up M3UA associations to a 
> > > > > (non-empty) subset
> > > > > > of the active SGPs?
> > > > > > 
> > > > > > Cheers,
> > > > > > 
> > > > > > --Hong
> > > > > > 
> > > > > [snip]
> > > > > 
> > > > > I believe that there are several points in the draft 
> > > which lead to a
> > > > > definition of an SG.  These are:
> > > > > 
> > > > >    o   An SGP is a unique transport (SCTP) endpoint.
> > > > > 
> > > > >    o   An SG is a collection or set of one or more SGPs.
> > > > > 
> > > > >    o   An SG terminates SS7 signalling links from the SS7 network.
> > > > > 
> > > > >    o   An SG has one set of Routing Keys which are shared 
> > > by all the
> > > > >        SGPs which make up the SG.
> > > > > 
> > > > >    o   Each SGP in an SG offers identical connectivity to the SS7
> > > > >        network.
> > > > > 
> > > > > There are no restrictions placed on what point codes an SG 
> > > > > does or does
> > > > > not represent.  There are no restrictions placed on how many 
> > > > > SGP a Host
> > > > > represents.  There are no restrictions in terms of the 
> > > geographical
> > > > > positioning of SGP within an SG.
> > > > > 
> > > > 
> > > > The draft stats: "An SG appears to the SS7 network as an 
> > > SS7 Signalling 
> > > > Point". 
> > > > So, for a specific SS7 network, an SG has a unique point code.
> > > 
> > > An SG appears to the SS7 network as having a point code,
> > > but it doen't have to have one of its own.  This was clearly
> > > intended in the draft from the start: that the SG can just
> > > represent the SPMC point code which "belongs" to the ASPs.
> > > If the SG has a point code separate from the ASP, then it
> > > would have to be an STP.  That is not required by the spec.
> > > 
> > Yes, an SG has a point code from the SS7 point of view ...
> > We are in sync here !!! :-)
> 
> No we are not in sync.  The SG "represents" one or more point
> codes to the SS7 network.  It does not necessarily "have" one.
> I though that the draft made this crystal clear.  The SG may
> or may not have local MTP-Users.  If it has no local MTP-Users
> and is not equipped with the transfer function, then it does
> not "have" a point code.
> 
> > > > 
> > > > > When your consider these points, an SG, in principle, 
> > > looks like the
> > > > > following:
> > > > > 
> > > > >                                                            
> > > > >                            SG                              
> > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > >                 |                       | Associations     
> > > > >                        __________                          
> > > > >                 |     |          |------|-----------       
> > > > >                       |   SGP1   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >         SS7            __________                          
> > > > >        Links    |     |          |------|-----------       
> > > > >     ------------      |   SGP2   |------------------       
> > > > >     ------------|     |__________|------|-----------       
> > > > >     ------------       __________                       To 
> > > > >     ------------|     |          |------|-----------   ASPs
> > > > >     ------------      |   SGP3   |------------------       
> > > > >     ------------|     |__________|------|-----------       
> > > > >     ------------       __________                          
> > > > >     ------------|     |          |------|-----------       
> > > > >     ------------      |   SGP4   |------------------       
> > > > >     ------------|     |__________|------|-----------       
> > > > >     ------------                                           
> > > > >                 |           .           |                  
> > > > >                             .                              
> > > > >                 |           .           |                  
> > > > >                        __________                          
> > > > >                 |     |          |------|-----------       
> > > > >                       |   SGPn   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >                                                            
> > > > >                 |                       |                  
> > > > >                 \ - - - - - - - - - - - /                  
> > > > > 
> > > > > Where the argument, errr.., discussion errupts centers around the
> > > > > restriction that all SGP in an SG must have identical connectivity
> > > > > to the SS7 network and SHOULD be able to transfer traffic between
> > > > > them to accomplish that feat.
> > > > > 
> > > > > My position is that, while in principle this sounds good, in 
> > > > > practice it
> > > > > does not:
> > > > > 
> > > > 
> > > > My position is the opposite... :-)
> > > 
> > > Uhmm.
> > > 
> > > > 
> > > > > On of the purposes of allowing multple SGP is to allow 
> > > the SG to be a
> > > > > collection of multiple hosts for redudancy and scaling.  
> > > > > Unfortunately,
> > > > > when SGPs are multiple hosts, the possibility of a 
> > > "partitioned" SG
> > > > > due to internal failures is possible.  That could look like this:
> > > > > 
> > > > >                                                            
> > > > >                            SG                              
> > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > >                 |                       | Associations     
> > > > >                        __________                          
> > > > >                 |     |          |------|-----------       
> > > > >                       |   SGP1   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >         SS7            __________                          
> > > > >        Links    |     |          |------|-----------       
> > > > >     ------------      |   SGP2   |------------------       
> > > > >     ------------|     |__________|------|-----------       
> > > > >    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
> > > > >     ------------       __________                       To 
> > > > >     ------------|     |          |------|-----------   ASPs
> > > > >     ------------      |   SGP3   |------------------       
> > > > >     ------------|     |__________|------|-----------       
> > > > >     ------------       __________                          
> > > > >     ------------|     |          |------|-----------       
> > > > >     ------------      |   SGP4   |------------------       
> > > > >     ------------|     |__________|------|-----------       
> > > > >     ------------                                           
> > > > >                 |           .           |                  
> > > > >                             .                              
> > > > >                 |           .           |                  
> > > > >                        __________                          
> > > > >                 |     |          |------|-----------       
> > > > >                       |   SGPn   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >                                                            
> > > > >                 |                       |                  
> > > > >                 \ - - - - - - - - - - - /                  
> > > > > 
> > > > > In some of the above "partitioned" scenarios, the SGPs 
> > > need to be able
> > > > > to tell the ASPs that they can no longer service specific 
> > > > > traffic flows
> > > > > towards the SS7 newtork.  In the current draft this can be 
> > > > > accomplished
> > > > > in two ways, both which are problematic.
> > > > > 
> > > > >   1.  The SGP can use DUNA, DAVA, and DRST independently from 
> > > > > each of the
> > > > >       SGP to indicate the difference in availability of 
> > > > > routesets to the
> > > > >       SS7 newtork above the partition and below the 
> > > partition in the
> > > > >       diagram.
> > > > > 
> > > > >       With the way that keeping DUNA, DAVA, DRST and SCON 
> > > on a per-SGP
> > > > >       basis at the ASP has been "watered down", however, in 
> > > > > the M3UA-08
> > > > >       draft, the SG cannot be guaranteed that the ASPs 
> > > will respond
> > > > >       properly to these partitioned indications.  If the 
> > > ASPs respond
> > > > >       under the "single management view", as is their 
> > > option in the
> > > > >       latest draft, this case will reduce to case (2) below.
> > > > > 
> > > > >   2.  The SGP drop their associations to the ASPs.  That is, 
> > > > > The entire
> > > > >       SG goes off-line.
> > > > > 
> > > > This is true but this is only 1 part of the problem.
> > > > A partionned SG means also multiple PC with the same Id on 
> > > the same SS7
> > > > network.
> > > 
> > > It is the case in the SS7 network that we assign one point code
> > > to two STPs (alias point code for GTT).  It does not cause problems
> > > in the SS7 network.
> > > 
> > > > And this last problem is not solved by M3UA.
> > > 
> > > But could easily.
> > I suppose that here we disagree on the level of quality the SG must
> provide.
> > And I think that this level will not be determined by you or me but by
the
> 
> > future users of M3UA.
> > My position is that an SS7 platform (SG) partition does not work because
> > it could loose SS7 messages (1 or 1000 it cannot be acceptable, for me).
> > M3UA cannot do anything here, it is a pure SS7 problem.
> > > 
> > > > Well, such a problem is mitigated by some particular SS7 
> > > configurations, 
> > > > for instance, when SGPs are connected to one and only one adjacent,
> > > > but in this case, the configuration don't take advantage of the SS7
> > > > redundancy:
> > > > if one SGP fails, an entire route is lost...
> > > > So, I think that inter SGP communications must be designed 
> > > by SG vendors
> > > > and not by M3UA.
> > > > I really think that SG vendors could be creative in this 
> > > domain and provide
> > > > an inter SGP communication mechanism very reliable, or even 
> > > provide a 
> > > > mechanism (may be with another LAN dedicated to this 
> > > purpose) to "detect"
> > > > SG platform partition... and avoid, even when using "single 
> > > management
> > > > view",
> > > > to drop all the SGP associations to the ASPs. 
> > > 
> > > All this cost for guaranteed inter-SGP communication is not necessary.
> > Well, does everybody in this mailing list agree on this comment ?
> > > With just a little support from M3UA, the platform could run fully
> > > partitioned and happy.  Detailed discussion of this was provided on
> > > other threads.  Aside from low volume changeover messages and routing
> > > messages there should never be a need to route user level 
> > > traffic between
> > > SGP.  A patition in that case only causes minor message loss during
> > > changeovers and is acceptable because the probability of partitioning
> > > failure coupled with the probability of changeover can be 
> > > engineered to
> > > meet message lost requirements quite economically.
> > What means carrier-grade then ? 
> > Anyway, I think that truth here depends on the quality level the final
> > user wants ... and each future user will have its own definition of
> > "carrier-grade" level.
> 
> Don't be ridiculous.  The arrangement only loses messages when
> failures occur.  This is permitted.  Just as long as the failure
> rate is controlled to within those bounds which are acceptable by
> the message loss requirements of MTP.
> 
> Compare this to how may messages your fancy inter-SGP arrangement
> is going to lose when (not "if") it partitions.
> 
> > > 
> > > I have handled the problem, it just needs minor support from M3UA.
> > > 
> > On the IP side, may be. Not on the SS7 side (IMHO).
> 
> M3UA is not responsible for the SS7 side, the SG implementation
> is.  M3UA need only provide the mechanisms reqruired by the SG
> to perform its function.  I do not have to prove to _you_ that
> the SS7 side works.
> 
> I am not shutting off my customer's $1M/hr cash flow just to
> satisfy a "MAY" in the spec.
> 
> > > > 
> > > > 
> > > > > There is only one arrangement of SG/SGP in my mind that 
> > > can keep this
> > > > > from happening:  Make every SG consist of only one SGP, 
> > > and have each
> > > > > SG support only one SS7 link, like this:
> > > > > 
> > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > >                 | SG                    | Associations     
> > > > >        SS7             __________                          
> > > > >        Link     |     |          |------|-----------       
> > > > >    -------------------|   SGP1   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >                                                            
> > > > >                 |                       |                  
> > > > >                 \ - - - - - - - - - - - /                  
> > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > >                 | SG                    | Associations     
> > > > >        SS7             __________                          
> > > > >        Link     |     |          |------|-----------       
> > > > >    -------------------|   SGP2   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >                                                            
> > > > >                 |                       |                  
> > > > >                 \ - - - - - - - - - - - /                  
> > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > >                 | SG                    | Associations     
> > > > >        SS7             __________                          
> > > > >        Link     |     |          |------|-----------       
> > > > >    -------------------|   SGP3   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >                                                            
> > > > >                 |                       |                  
> > > > >                 \ - - - - - - - - - - - /                  
> > > > >                             .                              
> > > > >                             .                              
> > > > >                             .                              
> > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > >                 | SG                    | Associations     
> > > > >        SS7             __________                          
> > > > >        Link     |     |          |------|-----------       
> > > > >    -------------------|   SGPn   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >                                                            
> > > > >                 |                       |                  
> > > > >                 \ - - - - - - - - - - - /                  
> > > > > 
> > > > > This is possible, however, it pretty much reduces M3UA to M2UA.
> > > > > 
> > > > > I would rather see the SGP be provided with some 
> > > mechanism by way of
> > > > > which it can be assured that the ASPs will respond properly to
> > > > > partitioned SGP.
> > > > > 
> > > > > Until they do, I cannot see that M3UA can be implemented in a
> > > > > carrier-class arrangement with ASPs which treat the SG with a 
> > > > > "single management view".
> > > > Well, no, I think it is possible but requires a lot of experience
> > > > in distributed computing (at least for the SGP vendors..). 
> > > > > 
> > > > > 
> > > > > --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]
> > > > > 
> > > > 
> > > > 
> > > > ---
> > > > 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]
> 
> -- 
> 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]

-- 
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: "Desiderio, Didier" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv7: SG redundancy
Date: Wed, 25 Jul 2001 14:17:20 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zmamail04.zma.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zmamail04.zma.compaq.com [161.114.64.104]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,
Thanks for your answer and sorry to insist but in your diagram, does SGP2
send (or not) the DUNAs? 
and if no, 
you have only one "single management point of view" of ss7 destinations per
SG
that change a lot of things...

/Didier

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Wednesday,
July 25, 2001 1:50 PM
To: sigtran
Subject: Re: M3UAv7: SG redundancy

Didier,

I have answered this before, but, again: If I can modify your diagram
sligtly:
  
                          SG
               + - - - - - - - - - - - +
       SS7     |Switch                 |
      Links       |   __________            SCTP
   ------------|--|  |          |      | Associations   __________
   ------------ --|--|   SGP1   |-X-X-X-X-X-X-X-X-X-X--|          |
   ------------|--|  |__________|      |               |   ASP    |
                  |   __________                  +----|__________|
   -X-X-X-X-X--|--|  |          |      |          |
   -X-X-X-X-X-- --|--|   SGP2   |-----------------+
   -X-X-X-X-X--|--|  |__________|      |
                  |
               |                       |
               + - - - - - - - - - - - +
  
If there is another degree of freedom between the SGP and the SS7 Links
(H.100 bus, M2UA) then in your scenario I would have SGP2 take over the SS7
links from SGP1.
There is still no need to route user level traffic between SGP.  Depending
on the architecture, it might be too drastic a measure off the start.

--Brian

> 2/ all destinations in SGP1 are UP.
> 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for all
> destinations...
> 3/ The SCTP asso SGP1-ASP just falling.

Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
13:38:22)
> Brian,
> Can you explain that, consider the following :
> 
> 1/ SGP in the same SG do not have a "single management point of view" that
> is
> to say they are sharing the same ss7 destinations but each SGP has its own

> management view...
> 
>                         SG
>              + - - - - - - - - - - - +
>      SS7     |                       |
>     Links           __________            SCTP
>  ------------|     |          |      | Associations   __________
>  ------------      |   SGP1   |----------------------|          |
>  ------------|     |__________|      |               |   ASP    |
>                     __________                  +----|__________|
>  ------------|     |          |      |          |
>  ------------      |   SGP2   |-----------------+
>  ------------|     |__________|      |
> 
>              |                       |
>              + - - - - - - - - - - - +
> 
> 2/ all destinations in SGP1 are UP.
> 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for all
> destinations...
> 3/ The SCTP asso SGP1-ASP just falling.
> 4/ ASP has to send data to one destination and this SG is the priority
> route.
> 
> Does the ASP not send this data? 
> Does the ASP choose another SG to send this DATA?
> >> even if the destination is not considered as DOWN from SS7 point of
view
> and
>    this SG is the priority route!!!!
> 
> And is it aceptable on the M3UA point of view?
> 
> /Didier
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 12:09 PM
> To: sigtran
> Subject: Re: M3UAv7: SG redundancy
> 
> 
> Pierre,
> 
> Please see more comments below...
> 
> Garnero, Pierre wrote:                    (Wed, 25 Jul 2001 11:43:56)
> > Brian,
> > 
> > just some comments below:
> > 
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, July 25, 2001 11:20 AM
> > > To: sigtran
> > > Subject: Re: M3UAv7: SG redundancy
> > > 
> > > 
> > > Pierre,
> > > 
> > > Please see comments below...
> > > 
> > > Garnero, Pierre wrote:                                   
> > > (Wed, 25 Jul 2001 10:33:34)
> > > > Hello Hong,
> > > > 
> > > > please find another point of view, included in Brians comments...
> > > > 
> > > > Cheers,
> > > > 
> > > > PiG
> > > > 
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Wednesday, July 25, 2001 8:28 AM
> > > > > To: sigtran
> > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > 
> > > > > 
> > > > > Hong,
> > > > > 
> > > > > You bring up some good questions.
> > > > > 
> > > > > Hong Liu wrote:                              (Wed, 25 Jul 
> > > > > 2001 08:08:07)
> > > > > > Hi, Brian,
> > > > > > 
> > > > > > I am also confused by the notion of SG vs. SGP in the 
> > > > > current M3UA spec.
> > > > > > Maybe you can help me to understand the concepts better. I 
> > > > > noticed that
> > > > > > there was a long thread of discussions on the list a few 
> > > > > months ago on
> > > > > > this topic. So I apologize in advance if I bring up 
> > > > > something that has
> > > > > > already been clarified.
> > > > > > 
> > > > > > According to the current spec, an SG is a logical 
> > > entity if it is
> > > > > > composed of more than one SGP. From the SS7 network point 
> > > > > of view, SG is
> > > > > > the one that acts as an SS7 signaling point and is thus 
> > > > > assigned a point
> > > > > > code. Does it imply that all the SGPs of an SG will bear 
> > > > > the same point
> > > > > > code even if they are geographically separated? Is that 
> > > > > what it means in
> > > > > > the spec regarding a single management view to the SS7 network?
> > > > > > 
> > > > > > On the IP side, is it required that an ASP set up an M3UA 
> > > > > association
> > > > > > with each of the active SGPs? Or in other words, is it 
> > > > > allowed by the
> > > > > > spec that an ASP only sets up M3UA associations to a 
> > > > > (non-empty) subset
> > > > > > of the active SGPs?
> > > > > > 
> > > > > > Cheers,
> > > > > > 
> > > > > > --Hong
> > > > > > 
> > > > > [snip]
> > > > > 
> > > > > I believe that there are several points in the draft 
> > > which lead to a
> > > > > definition of an SG.  These are:
> > > > > 
> > > > >    o   An SGP is a unique transport (SCTP) endpoint.
> > > > > 
> > > > >    o   An SG is a collection or set of one or more SGPs.
> > > > > 
> > > > >    o   An SG terminates SS7 signalling links from the SS7 network.
> > > > > 
> > > > >    o   An SG has one set of Routing Keys which are shared 
> > > by all the
> > > > >        SGPs which make up the SG.
> > > > > 
> > > > >    o   Each SGP in an SG offers identical connectivity to the SS7
> > > > >        network.
> > > > > 
> > > > > There are no restrictions placed on what point codes an SG 
> > > > > does or does
> > > > > not represent.  There are no restrictions placed on how many 
> > > > > SGP a Host
> > > > > represents.  There are no restrictions in terms of the 
> > > geographical
> > > > > positioning of SGP within an SG.
> > > > > 
> > > > 
> > > > The draft stats: "An SG appears to the SS7 network as an 
> > > SS7 Signalling 
> > > > Point". 
> > > > So, for a specific SS7 network, an SG has a unique point code.
> > > 
> > > An SG appears to the SS7 network as having a point code,
> > > but it doen't have to have one of its own.  This was clearly
> > > intended in the draft from the start: that the SG can just
> > > represent the SPMC point code which "belongs" to the ASPs.
> > > If the SG has a point code separate from the ASP, then it
> > > would have to be an STP.  That is not required by the spec.
> > > 
> > Yes, an SG has a point code from the SS7 point of view ...
> > We are in sync here !!! :-)
> 
> No we are not in sync.  The SG "represents" one or more point
> codes to the SS7 network.  It does not necessarily "have" one.
> I though that the draft made this crystal clear.  The SG may
> or may not have local MTP-Users.  If it has no local MTP-Users
> and is not equipped with the transfer function, then it does
> not "have" a point code.
> 
> > > > 
> > > > > When your consider these points, an SG, in principle, 
> > > looks like the
> > > > > following:
> > > > > 
> > > > >                                                            
> > > > >                            SG                              
> > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > >                 |                       | Associations     
> > > > >                        __________                          
> > > > >                 |     |          |------|-----------       
> > > > >                       |   SGP1   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >         SS7            __________                          
> > > > >        Links    |     |          |------|-----------       
> > > > >     ------------      |   SGP2   |------------------       
> > > > >     ------------|     |__________|------|-----------       
> > > > >     ------------       __________                       To 
> > > > >     ------------|     |          |------|-----------   ASPs
> > > > >     ------------      |   SGP3   |------------------       
> > > > >     ------------|     |__________|------|-----------       
> > > > >     ------------       __________                          
> > > > >     ------------|     |          |------|-----------       
> > > > >     ------------      |   SGP4   |------------------       
> > > > >     ------------|     |__________|------|-----------       
> > > > >     ------------                                           
> > > > >                 |           .           |                  
> > > > >                             .                              
> > > > >                 |           .           |                  
> > > > >                        __________                          
> > > > >                 |     |          |------|-----------       
> > > > >                       |   SGPn   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >                                                            
> > > > >                 |                       |                  
> > > > >                 \ - - - - - - - - - - - /                  
> > > > > 
> > > > > Where the argument, errr.., discussion errupts centers around the
> > > > > restriction that all SGP in an SG must have identical connectivity
> > > > > to the SS7 network and SHOULD be able to transfer traffic between
> > > > > them to accomplish that feat.
> > > > > 
> > > > > My position is that, while in principle this sounds good, in 
> > > > > practice it
> > > > > does not:
> > > > > 
> > > > 
> > > > My position is the opposite... :-)
> > > 
> > > Uhmm.
> > > 
> > > > 
> > > > > On of the purposes of allowing multple SGP is to allow 
> > > the SG to be a
> > > > > collection of multiple hosts for redudancy and scaling.  
> > > > > Unfortunately,
> > > > > when SGPs are multiple hosts, the possibility of a 
> > > "partitioned" SG
> > > > > due to internal failures is possible.  That could look like this:
> > > > > 
> > > > >                                                            
> > > > >                            SG                              
> > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > >                 |                       | Associations     
> > > > >                        __________                          
> > > > >                 |     |          |------|-----------       
> > > > >                       |   SGP1   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >         SS7            __________                          
> > > > >        Links    |     |          |------|-----------       
> > > > >     ------------      |   SGP2   |------------------       
> > > > >     ------------|     |__________|------|-----------       
> > > > >    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
> > > > >     ------------       __________                       To 
> > > > >     ------------|     |          |------|-----------   ASPs
> > > > >     ------------      |   SGP3   |------------------       
> > > > >     ------------|     |__________|------|-----------       
> > > > >     ------------       __________                          
> > > > >     ------------|     |          |------|-----------       
> > > > >     ------------      |   SGP4   |------------------       
> > > > >     ------------|     |__________|------|-----------       
> > > > >     ------------                                           
> > > > >                 |           .           |                  
> > > > >                             .                              
> > > > >                 |           .           |                  
> > > > >                        __________                          
> > > > >                 |     |          |------|-----------       
> > > > >                       |   SGPn   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >                                                            
> > > > >                 |                       |                  
> > > > >                 \ - - - - - - - - - - - /                  
> > > > > 
> > > > > In some of the above "partitioned" scenarios, the SGPs 
> > > need to be able
> > > > > to tell the ASPs that they can no longer service specific 
> > > > > traffic flows
> > > > > towards the SS7 newtork.  In the current draft this can be 
> > > > > accomplished
> > > > > in two ways, both which are problematic.
> > > > > 
> > > > >   1.  The SGP can use DUNA, DAVA, and DRST independently from 
> > > > > each of the
> > > > >       SGP to indicate the difference in availability of 
> > > > > routesets to the
> > > > >       SS7 newtork above the partition and below the 
> > > partition in the
> > > > >       diagram.
> > > > > 
> > > > >       With the way that keeping DUNA, DAVA, DRST and SCON 
> > > on a per-SGP
> > > > >       basis at the ASP has been "watered down", however, in 
> > > > > the M3UA-08
> > > > >       draft, the SG cannot be guaranteed that the ASPs 
> > > will respond
> > > > >       properly to these partitioned indications.  If the 
> > > ASPs respond
> > > > >       under the "single management view", as is their 
> > > option in the
> > > > >       latest draft, this case will reduce to case (2) below.
> > > > > 
> > > > >   2.  The SGP drop their associations to the ASPs.  That is, 
> > > > > The entire
> > > > >       SG goes off-line.
> > > > > 
> > > > This is true but this is only 1 part of the problem.
> > > > A partionned SG means also multiple PC with the same Id on 
> > > the same SS7
> > > > network.
> > > 
> > > It is the case in the SS7 network that we assign one point code
> > > to two STPs (alias point code for GTT).  It does not cause problems
> > > in the SS7 network.
> > > 
> > > > And this last problem is not solved by M3UA.
> > > 
> > > But could easily.
> > I suppose that here we disagree on the level of quality the SG must
> provide.
> > And I think that this level will not be determined by you or me but by
the
> 
> > future users of M3UA.
> > My position is that an SS7 platform (SG) partition does not work because
> > it could loose SS7 messages (1 or 1000 it cannot be acceptable, for me).
> > M3UA cannot do anything here, it is a pure SS7 problem.
> > > 
> > > > Well, such a problem is mitigated by some particular SS7 
> > > configurations, 
> > > > for instance, when SGPs are connected to one and only one adjacent,
> > > > but in this case, the configuration don't take advantage of the SS7
> > > > redundancy:
> > > > if one SGP fails, an entire route is lost...
> > > > So, I think that inter SGP communications must be designed 
> > > by SG vendors
> > > > and not by M3UA.
> > > > I really think that SG vendors could be creative in this 
> > > domain and provide
> > > > an inter SGP communication mechanism very reliable, or even 
> > > provide a 
> > > > mechanism (may be with another LAN dedicated to this 
> > > purpose) to "detect"
> > > > SG platform partition... and avoid, even when using "single 
> > > management
> > > > view",
> > > > to drop all the SGP associations to the ASPs. 
> > > 
> > > All this cost for guaranteed inter-SGP communication is not necessary.
> > Well, does everybody in this mailing list agree on this comment ?
> > > With just a little support from M3UA, the platform could run fully
> > > partitioned and happy.  Detailed discussion of this was provided on
> > > other threads.  Aside from low volume changeover messages and routing
> > > messages there should never be a need to route user level 
> > > traffic between
> > > SGP.  A patition in that case only causes minor message loss during
> > > changeovers and is acceptable because the probability of partitioning
> > > failure coupled with the probability of changeover can be 
> > > engineered to
> > > meet message lost requirements quite economically.
> > What means carrier-grade then ? 
> > Anyway, I think that truth here depends on the quality level the final
> > user wants ... and each future user will have its own definition of
> > "carrier-grade" level.
> 
> Don't be ridiculous.  The arrangement only loses messages when
> failures occur.  This is permitted.  Just as long as the failure
> rate is controlled to within those bounds which are acceptable by
> the message loss requirements of MTP.
> 
> Compare this to how may messages your fancy inter-SGP arrangement
> is going to lose when (not "if") it partitions.
> 
> > > 
> > > I have handled the problem, it just needs minor support from M3UA.
> > > 
> > On the IP side, may be. Not on the SS7 side (IMHO).
> 
> M3UA is not responsible for the SS7 side, the SG implementation
> is.  M3UA need only provide the mechanisms reqruired by the SG
> to perform its function.  I do not have to prove to _you_ that
> the SS7 side works.
> 
> I am not shutting off my customer's $1M/hr cash flow just to
> satisfy a "MAY" in the spec.
> 
> > > > 
> > > > 
> > > > > There is only one arrangement of SG/SGP in my mind that 
> > > can keep this
> > > > > from happening:  Make every SG consist of only one SGP, 
> > > and have each
> > > > > SG support only one SS7 link, like this:
> > > > > 
> > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > >                 | SG                    | Associations     
> > > > >        SS7             __________                          
> > > > >        Link     |     |          |------|-----------       
> > > > >    -------------------|   SGP1   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >                                                            
> > > > >                 |                       |                  
> > > > >                 \ - - - - - - - - - - - /                  
> > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > >                 | SG                    | Associations     
> > > > >        SS7             __________                          
> > > > >        Link     |     |          |------|-----------       
> > > > >    -------------------|   SGP2   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >                                                            
> > > > >                 |                       |                  
> > > > >                 \ - - - - - - - - - - - /                  
> > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > >                 | SG                    | Associations     
> > > > >        SS7             __________                          
> > > > >        Link     |     |          |------|-----------       
> > > > >    -------------------|   SGP3   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >                                                            
> > > > >                 |                       |                  
> > > > >                 \ - - - - - - - - - - - /                  
> > > > >                             .                              
> > > > >                             .                              
> > > > >                             .                              
> > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > >                 | SG                    | Associations     
> > > > >        SS7             __________                          
> > > > >        Link     |     |          |------|-----------       
> > > > >    -------------------|   SGPn   |------------------       
> > > > >                 |     |__________|------|-----------       
> > > > >                                                            
> > > > >                 |                       |                  
> > > > >                 \ - - - - - - - - - - - /                  
> > > > > 
> > > > > This is possible, however, it pretty much reduces M3UA to M2UA.
> > > > > 
> > > > > I would rather see the SGP be provided with some 
> > > mechanism by way of
> > > > > which it can be assured that the ASPs will respond properly to
> > > > > partitioned SGP.
> > > > > 
> > > > > Until they do, I cannot see that M3UA can be implemented in a
> > > > > carrier-class arrangement with ASPs which treat the SG with a 
> > > > > "single management view".
> > > > Well, no, I think it is possible but requires a lot of experience
> > > > in distributed computing (at least for the SGP vendors..). 
> > > > > 
> > > > > 
> > > > > --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]
> > > > > 
> > > > 
> > > > 
> > > > ---
> > > > 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]
> 
> -- 
> 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]

-- 
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: Wed, 25 Jul 2001 07:28:01 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv7: SG redundancy
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Didier,

Yes, it would send DUNAs iff it was a permitted way of getting the ASP to
stop traffic to the SGP.

These examples show the need for SGP management.  If not DUNAs then
something else...

--Brian

Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
14:17:20)
> Brian,
> Thanks for your answer and sorry to insist but in your diagram,
> does SGP2 send (or not) the DUNAs? 
> and if no, 
> you have only one "single management point of view" of ss7 destinations
per
> SG
> that change a lot of things...
> 
> /Didier
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 1:50 PM
> To: sigtran
> Subject: Re: M3UAv7: SG redundancy
> 
> 
> Didier,
> 
> I have answered this before, but, again: If I can modify your
> diagram sligtly:
>   
>                           SG
>                + - - - - - - - - - - - +
>        SS7     |Switch                 |
>       Links       |   __________            SCTP
>    ------------|--|  |          |      | Associations   __________
>    ------------ --|--|   SGP1   |-X-X-X-X-X-X-X-X-X-X--|          |
>    ------------|--|  |__________|      |               |   ASP    |
>                   |   __________                  +----|__________|
>    -X-X-X-X-X--|--|  |          |      |          |
>    -X-X-X-X-X-- --|--|   SGP2   |-----------------+
>    -X-X-X-X-X--|--|  |__________|      |
>                   |
>                |                       |
>                + - - - - - - - - - - - +
>   
> If there is another degree of freedom between the SGP
> and the SS7 Links (H.100 bus, M2UA) then in your scenario
> I would have SGP2 take over the SS7 links from SGP1.
> There is still no need to route user level traffic
> between SGP.  Depending on the architecture, it might
> be too drastic a measure off the start.
> 
> --Brian
> 
> 
> > 2/ all destinations in SGP1 are UP.
> > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for all
> > destinations...
> > 3/ The SCTP asso SGP1-ASP just falling.
> 
> Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
> 13:38:22)
> > Brian,
> > Can you explain that, consider the following :
> > 
> > 1/ SGP in the same SG do not have a "single management point of view"
that
> > is
> > to say they are sharing the same ss7 destinations but each SGP has its
own
> 
> > management view...
> > 
> >                         SG
> >              + - - - - - - - - - - - +
> >      SS7     |                       |
> >     Links           __________            SCTP
> >  ------------|     |          |      | Associations   __________
> >  ------------      |   SGP1   |----------------------|          |
> >  ------------|     |__________|      |               |   ASP    |
> >                     __________                  +----|__________|
> >  ------------|     |          |      |          |
> >  ------------      |   SGP2   |-----------------+
> >  ------------|     |__________|      |
> > 
> >              |                       |
> >              + - - - - - - - - - - - +
> > 
> > 2/ all destinations in SGP1 are UP.
> > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for all
> > destinations...
> > 3/ The SCTP asso SGP1-ASP just falling.
> > 4/ ASP has to send data to one destination and this SG is the priority
> > route.
> > 
> > Does the ASP not send this data? 
> > Does the ASP choose another SG to send this DATA?
> > >> even if the destination is not considered as DOWN from SS7 point of
> view
> > and
> >    this SG is the priority route!!!!
> > 
> > And is it aceptable on the M3UA point of view?
> > 
> > /Didier
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, July 25, 2001 12:09 PM
> > To: sigtran
> > Subject: Re: M3UAv7: SG redundancy
> > 
> > 
> > Pierre,
> > 
> > Please see more comments below...
> > 
> > Garnero, Pierre wrote:                    (Wed, 25 Jul 2001 11:43:56)
> > > Brian,
> > > 
> > > just some comments below:
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Wednesday, July 25, 2001 11:20 AM
> > > > To: sigtran
> > > > Subject: Re: M3UAv7: SG redundancy
> > > > 
> > > > 
> > > > Pierre,
> > > > 
> > > > Please see comments below...
> > > > 
> > > > Garnero, Pierre wrote:                                   
> > > > (Wed, 25 Jul 2001 10:33:34)
> > > > > Hello Hong,
> > > > > 
> > > > > please find another point of view, included in Brians comments...
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > PiG
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Wednesday, July 25, 2001 8:28 AM
> > > > > > To: sigtran
> > > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > > 
> > > > > > 
> > > > > > Hong,
> > > > > > 
> > > > > > You bring up some good questions.
> > > > > > 
> > > > > > Hong Liu wrote:                              (Wed, 25 Jul 
> > > > > > 2001 08:08:07)
> > > > > > > Hi, Brian,
> > > > > > > 
> > > > > > > I am also confused by the notion of SG vs. SGP in the 
> > > > > > current M3UA spec.
> > > > > > > Maybe you can help me to understand the concepts better. I 
> > > > > > noticed that
> > > > > > > there was a long thread of discussions on the list a few 
> > > > > > months ago on
> > > > > > > this topic. So I apologize in advance if I bring up 
> > > > > > something that has
> > > > > > > already been clarified.
> > > > > > > 
> > > > > > > According to the current spec, an SG is a logical 
> > > > entity if it is
> > > > > > > composed of more than one SGP. From the SS7 network point 
> > > > > > of view, SG is
> > > > > > > the one that acts as an SS7 signaling point and is thus 
> > > > > > assigned a point
> > > > > > > code. Does it imply that all the SGPs of an SG will bear 
> > > > > > the same point
> > > > > > > code even if they are geographically separated? Is that 
> > > > > > what it means in
> > > > > > > the spec regarding a single management view to the SS7
network?
> > > > > > > 
> > > > > > > On the IP side, is it required that an ASP set up an M3UA 
> > > > > > association
> > > > > > > with each of the active SGPs? Or in other words, is it 
> > > > > > allowed by the
> > > > > > > spec that an ASP only sets up M3UA associations to a 
> > > > > > (non-empty) subset
> > > > > > > of the active SGPs?
> > > > > > > 
> > > > > > > Cheers,
> > > > > > > 
> > > > > > > --Hong
> > > > > > > 
> > > > > > [snip]
> > > > > > 
> > > > > > I believe that there are several points in the draft 
> > > > which lead to a
> > > > > > definition of an SG.  These are:
> > > > > > 
> > > > > >    o   An SGP is a unique transport (SCTP) endpoint.
> > > > > > 
> > > > > >    o   An SG is a collection or set of one or more SGPs.
> > > > > > 
> > > > > >    o   An SG terminates SS7 signalling links from the SS7
network.
> > > > > > 
> > > > > >    o   An SG has one set of Routing Keys which are shared 
> > > > by all the
> > > > > >        SGPs which make up the SG.
> > > > > > 
> > > > > >    o   Each SGP in an SG offers identical connectivity to the
SS7
> > > > > >        network.
> > > > > > 
> > > > > > There are no restrictions placed on what point codes an SG 
> > > > > > does or does
> > > > > > not represent.  There are no restrictions placed on how many 
> > > > > > SGP a Host
> > > > > > represents.  There are no restrictions in terms of the 
> > > > geographical
> > > > > > positioning of SGP within an SG.
> > > > > > 
> > > > > 
> > > > > The draft stats: "An SG appears to the SS7 network as an 
> > > > SS7 Signalling 
> > > > > Point". 
> > > > > So, for a specific SS7 network, an SG has a unique point code.
> > > > 
> > > > An SG appears to the SS7 network as having a point code,
> > > > but it doen't have to have one of its own.  This was clearly
> > > > intended in the draft from the start: that the SG can just
> > > > represent the SPMC point code which "belongs" to the ASPs.
> > > > If the SG has a point code separate from the ASP, then it
> > > > would have to be an STP.  That is not required by the spec.
> > > > 
> > > Yes, an SG has a point code from the SS7 point of view ...
> > > We are in sync here !!! :-)
> > 
> > No we are not in sync.  The SG "represents" one or more point
> > codes to the SS7 network.  It does not necessarily "have" one.
> > I though that the draft made this crystal clear.  The SG may
> > or may not have local MTP-Users.  If it has no local MTP-Users
> > and is not equipped with the transfer function, then it does
> > not "have" a point code.
> > 
> > > > > 
> > > > > > When your consider these points, an SG, in principle, 
> > > > looks like the
> > > > > > following:
> > > > > > 
> > > > > >                                                            
> > > > > >                            SG                              
> > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > >                 |                       | Associations     
> > > > > >                        __________                          
> > > > > >                 |     |          |------|-----------       
> > > > > >                       |   SGP1   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >         SS7            __________                          
> > > > > >        Links    |     |          |------|-----------       
> > > > > >     ------------      |   SGP2   |------------------       
> > > > > >     ------------|     |__________|------|-----------       
> > > > > >     ------------       __________                       To 
> > > > > >     ------------|     |          |------|-----------   ASPs
> > > > > >     ------------      |   SGP3   |------------------       
> > > > > >     ------------|     |__________|------|-----------       
> > > > > >     ------------       __________                          
> > > > > >     ------------|     |          |------|-----------       
> > > > > >     ------------      |   SGP4   |------------------       
> > > > > >     ------------|     |__________|------|-----------       
> > > > > >     ------------                                           
> > > > > >                 |           .           |                  
> > > > > >                             .                              
> > > > > >                 |           .           |                  
> > > > > >                        __________                          
> > > > > >                 |     |          |------|-----------       
> > > > > >                       |   SGPn   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >                                                            
> > > > > >                 |                       |                  
> > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > 
> > > > > > Where the argument, errr.., discussion errupts centers around
the
> > > > > > restriction that all SGP in an SG must have identical
connectivity
> > > > > > to the SS7 network and SHOULD be able to transfer traffic
between
> > > > > > them to accomplish that feat.
> > > > > > 
> > > > > > My position is that, while in principle this sounds good, in 
> > > > > > practice it
> > > > > > does not:
> > > > > > 
> > > > > 
> > > > > My position is the opposite... :-)
> > > > 
> > > > Uhmm.
> > > > 
> > > > > 
> > > > > > On of the purposes of allowing multple SGP is to allow 
> > > > the SG to be a
> > > > > > collection of multiple hosts for redudancy and scaling.  
> > > > > > Unfortunately,
> > > > > > when SGPs are multiple hosts, the possibility of a 
> > > > "partitioned" SG
> > > > > > due to internal failures is possible.  That could look like
this:
> > > > > > 
> > > > > >                                                            
> > > > > >                            SG                              
> > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > >                 |                       | Associations     
> > > > > >                        __________                          
> > > > > >                 |     |          |------|-----------       
> > > > > >                       |   SGP1   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >         SS7            __________                          
> > > > > >        Links    |     |          |------|-----------       
> > > > > >     ------------      |   SGP2   |------------------       
> > > > > >     ------------|     |__________|------|-----------       
> > > > > >    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
> > > > > >     ------------       __________                       To 
> > > > > >     ------------|     |          |------|-----------   ASPs
> > > > > >     ------------      |   SGP3   |------------------       
> > > > > >     ------------|     |__________|------|-----------       
> > > > > >     ------------       __________                          
> > > > > >     ------------|     |          |------|-----------       
> > > > > >     ------------      |   SGP4   |------------------       
> > > > > >     ------------|     |__________|------|-----------       
> > > > > >     ------------                                           
> > > > > >                 |           .           |                  
> > > > > >                             .                              
> > > > > >                 |           .           |                  
> > > > > >                        __________                          
> > > > > >                 |     |          |------|-----------       
> > > > > >                       |   SGPn   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >                                                            
> > > > > >                 |                       |                  
> > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > 
> > > > > > In some of the above "partitioned" scenarios, the SGPs 
> > > > need to be able
> > > > > > to tell the ASPs that they can no longer service specific 
> > > > > > traffic flows
> > > > > > towards the SS7 newtork.  In the current draft this can be 
> > > > > > accomplished
> > > > > > in two ways, both which are problematic.
> > > > > > 
> > > > > >   1.  The SGP can use DUNA, DAVA, and DRST independently from 
> > > > > > each of the
> > > > > >       SGP to indicate the difference in availability of 
> > > > > > routesets to the
> > > > > >       SS7 newtork above the partition and below the 
> > > > partition in the
> > > > > >       diagram.
> > > > > > 
> > > > > >       With the way that keeping DUNA, DAVA, DRST and SCON 
> > > > on a per-SGP
> > > > > >       basis at the ASP has been "watered down", however, in 
> > > > > > the M3UA-08
> > > > > >       draft, the SG cannot be guaranteed that the ASPs 
> > > > will respond
> > > > > >       properly to these partitioned indications.  If the 
> > > > ASPs respond
> > > > > >       under the "single management view", as is their 
> > > > option in the
> > > > > >       latest draft, this case will reduce to case (2) below.
> > > > > > 
> > > > > >   2.  The SGP drop their associations to the ASPs.  That is, 
> > > > > > The entire
> > > > > >       SG goes off-line.
> > > > > > 
> > > > > This is true but this is only 1 part of the problem.
> > > > > A partionned SG means also multiple PC with the same Id on 
> > > > the same SS7
> > > > > network.
> > > > 
> > > > It is the case in the SS7 network that we assign one point code
> > > > to two STPs (alias point code for GTT).  It does not cause problems
> > > > in the SS7 network.
> > > > 
> > > > > And this last problem is not solved by M3UA.
> > > > 
> > > > But could easily.
> > > I suppose that here we disagree on the level of quality the SG must
> > provide.
> > > And I think that this level will not be determined by you or me but by
> the
> > 
> > > future users of M3UA.
> > > My position is that an SS7 platform (SG) partition does not work
because
> > > it could loose SS7 messages (1 or 1000 it cannot be acceptable, for
me).
> > > M3UA cannot do anything here, it is a pure SS7 problem.
> > > > 
> > > > > Well, such a problem is mitigated by some particular SS7 
> > > > configurations, 
> > > > > for instance, when SGPs are connected to one and only one
adjacent,
> > > > > but in this case, the configuration don't take advantage of the
SS7
> > > > > redundancy:
> > > > > if one SGP fails, an entire route is lost...
> > > > > So, I think that inter SGP communications must be designed 
> > > > by SG vendors
> > > > > and not by M3UA.
> > > > > I really think that SG vendors could be creative in this 
> > > > domain and provide
> > > > > an inter SGP communication mechanism very reliable, or even 
> > > > provide a 
> > > > > mechanism (may be with another LAN dedicated to this 
> > > > purpose) to "detect"
> > > > > SG platform partition... and avoid, even when using "single 
> > > > management
> > > > > view",
> > > > > to drop all the SGP associations to the ASPs. 
> > > > 
> > > > All this cost for guaranteed inter-SGP communication is not
necessary.
> > > Well, does everybody in this mailing list agree on this comment ?
> > > > With just a little support from M3UA, the platform could run fully
> > > > partitioned and happy.  Detailed discussion of this was provided on
> > > > other threads.  Aside from low volume changeover messages and
routing
> > > > messages there should never be a need to route user level 
> > > > traffic between
> > > > SGP.  A patition in that case only causes minor message loss during
> > > > changeovers and is acceptable because the probability of
partitioning
> > > > failure coupled with the probability of changeover can be 
> > > > engineered to
> > > > meet message lost requirements quite economically.
> > > What means carrier-grade then ? 
> > > Anyway, I think that truth here depends on the quality level the final
> > > user wants ... and each future user will have its own definition of
> > > "carrier-grade" level.
> > 
> > Don't be ridiculous.  The arrangement only loses messages when
> > failures occur.  This is permitted.  Just as long as the failure
> > rate is controlled to within those bounds which are acceptable by
> > the message loss requirements of MTP.
> > 
> > Compare this to how may messages your fancy inter-SGP arrangement
> > is going to lose when (not "if") it partitions.
> > 
> > > > 
> > > > I have handled the problem, it just needs minor support from M3UA.
> > > > 
> > > On the IP side, may be. Not on the SS7 side (IMHO).
> > 
> > M3UA is not responsible for the SS7 side, the SG implementation
> > is.  M3UA need only provide the mechanisms reqruired by the SG
> > to perform its function.  I do not have to prove to _you_ that
> > the SS7 side works.
> > 
> > I am not shutting off my customer's $1M/hr cash flow just to
> > satisfy a "MAY" in the spec.
> > 
> > > > > 
> > > > > 
> > > > > > There is only one arrangement of SG/SGP in my mind that 
> > > > can keep this
> > > > > > from happening:  Make every SG consist of only one SGP, 
> > > > and have each
> > > > > > SG support only one SS7 link, like this:
> > > > > > 
> > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > >                 | SG                    | Associations     
> > > > > >        SS7             __________                          
> > > > > >        Link     |     |          |------|-----------       
> > > > > >    -------------------|   SGP1   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >                                                            
> > > > > >                 |                       |                  
> > > > > >                 \ - - - - - - - - - - - /                  
> > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > >                 | SG                    | Associations     
> > > > > >        SS7             __________                          
> > > > > >        Link     |     |          |------|-----------       
> > > > > >    -------------------|   SGP2   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >                                                            
> > > > > >                 |                       |                  
> > > > > >                 \ - - - - - - - - - - - /                  
> > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > >                 | SG                    | Associations     
> > > > > >        SS7             __________                          
> > > > > >        Link     |     |          |------|-----------       
> > > > > >    -------------------|   SGP3   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >                                                            
> > > > > >                 |                       |                  
> > > > > >                 \ - - - - - - - - - - - /                  
> > > > > >                             .                              
> > > > > >                             .                              
> > > > > >                             .                              
> > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > >                 | SG                    | Associations     
> > > > > >        SS7             __________                          
> > > > > >        Link     |     |          |------|-----------       
> > > > > >    -------------------|   SGPn   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >                                                            
> > > > > >                 |                       |                  
> > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > 
> > > > > > This is possible, however, it pretty much reduces M3UA to M2UA.
> > > > > > 
> > > > > > I would rather see the SGP be provided with some 
> > > > mechanism by way of
> > > > > > which it can be assured that the ASPs will respond properly to
> > > > > > partitioned SGP.
> > > > > > 
> > > > > > Until they do, I cannot see that M3UA can be implemented in a
> > > > > > carrier-class arrangement with ASPs which treat the SG with a 
> > > > > > "single management view".
> > > > > Well, no, I think it is possible but requires a lot of experience
> > > > > in distributed computing (at least for the SGP vendors..). 
> > > > > > 
> > > > > > 
> > > > > > --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]
> > > > > > 
> > > > > 
> > > > > 
> > > > > ---
> > > > > 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]
> > 
> > -- 
> > 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]
> 
> -- 
> 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]

-- 
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: "Desiderio, Didier" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv7: SG redundancy
Date: Wed, 25 Jul 2001 14:51:36 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zmamail04.zma.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.114.64.104]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Perhaps we need 2 levels for the DUNA (same for DAVA, DRST, SCON...):

-> Destination Unavailable for the SG  (-> GLOBAL, DUNA).
-> Destination Unavailable for the SGP (-> LOCAL, DUNA).

Endeed in the sample bellow... SGP2 can send a DUNA(LOCAL)... So the
destination
is still accessible by SGP2 but it is not the more "efficiant way" to send
the message.

/Didier

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Wednesday,
July 25, 2001 2:28 PM
To: sigtran
Subject: Re: M3UAv7: SG redundancy

Didier,

Yes, it would send DUNAs iff it was a permitted way of getting the ASP to
stop traffic to the SGP.

These examples show the need for SGP management.  If not DUNAs then
something else...

--Brian

Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
14:17:20)
> Brian,
> Thanks for your answer and sorry to insist but in your diagram,
> does SGP2 send (or not) the DUNAs? 
> and if no, 
> you have only one "single management point of view" of ss7 destinations
per
> SG
> that change a lot of things...
> 
> /Didier
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 1:50 PM
> To: sigtran
> Subject: Re: M3UAv7: SG redundancy
> 
> 
> Didier,
> 
> I have answered this before, but, again: If I can modify your
> diagram sligtly:
>   
>                           SG
>                + - - - - - - - - - - - +
>        SS7     |Switch                 |
>       Links       |   __________            SCTP
>    ------------|--|  |          |      | Associations   __________
>    ------------ --|--|   SGP1   |-X-X-X-X-X-X-X-X-X-X--|          |
>    ------------|--|  |__________|      |               |   ASP    |
>                   |   __________                  +----|__________|
>    -X-X-X-X-X--|--|  |          |      |          |
>    -X-X-X-X-X-- --|--|   SGP2   |-----------------+
>    -X-X-X-X-X--|--|  |__________|      |
>                   |
>                |                       |
>                + - - - - - - - - - - - +
>   
> If there is another degree of freedom between the SGP
> and the SS7 Links (H.100 bus, M2UA) then in your scenario
> I would have SGP2 take over the SS7 links from SGP1.
> There is still no need to route user level traffic
> between SGP.  Depending on the architecture, it might
> be too drastic a measure off the start.
> 
> --Brian
> 
> 
> > 2/ all destinations in SGP1 are UP.
> > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for all
> > destinations...
> > 3/ The SCTP asso SGP1-ASP just falling.
> 
> Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
> 13:38:22)
> > Brian,
> > Can you explain that, consider the following :
> > 
> > 1/ SGP in the same SG do not have a "single management point of view"
that
> > is
> > to say they are sharing the same ss7 destinations but each SGP has its
own
> 
> > management view...
> > 
> >                         SG
> >              + - - - - - - - - - - - +
> >      SS7     |                       |
> >     Links           __________            SCTP
> >  ------------|     |          |      | Associations   __________
> >  ------------      |   SGP1   |----------------------|          |
> >  ------------|     |__________|      |               |   ASP    |
> >                     __________                  +----|__________|
> >  ------------|     |          |      |          |
> >  ------------      |   SGP2   |-----------------+
> >  ------------|     |__________|      |
> > 
> >              |                       |
> >              + - - - - - - - - - - - +
> > 
> > 2/ all destinations in SGP1 are UP.
> > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for all
> > destinations...
> > 3/ The SCTP asso SGP1-ASP just falling.
> > 4/ ASP has to send data to one destination and this SG is the priority
> > route.
> > 
> > Does the ASP not send this data? 
> > Does the ASP choose another SG to send this DATA?
> > >> even if the destination is not considered as DOWN from SS7 point of
> view
> > and
> >    this SG is the priority route!!!!
> > 
> > And is it aceptable on the M3UA point of view?
> > 
> > /Didier
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, July 25, 2001 12:09 PM
> > To: sigtran
> > Subject: Re: M3UAv7: SG redundancy
> > 
> > 
> > Pierre,
> > 
> > Please see more comments below...
> > 
> > Garnero, Pierre wrote:                    (Wed, 25 Jul 2001 11:43:56)
> > > Brian,
> > > 
> > > just some comments below:
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Wednesday, July 25, 2001 11:20 AM
> > > > To: sigtran
> > > > Subject: Re: M3UAv7: SG redundancy
> > > > 
> > > > 
> > > > Pierre,
> > > > 
> > > > Please see comments below...
> > > > 
> > > > Garnero, Pierre wrote:                                   
> > > > (Wed, 25 Jul 2001 10:33:34)
> > > > > Hello Hong,
> > > > > 
> > > > > please find another point of view, included in Brians comments...
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > PiG
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Wednesday, July 25, 2001 8:28 AM
> > > > > > To: sigtran
> > > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > > 
> > > > > > 
> > > > > > Hong,
> > > > > > 
> > > > > > You bring up some good questions.
> > > > > > 
> > > > > > Hong Liu wrote:                              (Wed, 25 Jul 
> > > > > > 2001 08:08:07)
> > > > > > > Hi, Brian,
> > > > > > > 
> > > > > > > I am also confused by the notion of SG vs. SGP in the 
> > > > > > current M3UA spec.
> > > > > > > Maybe you can help me to understand the concepts better. I 
> > > > > > noticed that
> > > > > > > there was a long thread of discussions on the list a few 
> > > > > > months ago on
> > > > > > > this topic. So I apologize in advance if I bring up 
> > > > > > something that has
> > > > > > > already been clarified.
> > > > > > > 
> > > > > > > According to the current spec, an SG is a logical 
> > > > entity if it is
> > > > > > > composed of more than one SGP. From the SS7 network point 
> > > > > > of view, SG is
> > > > > > > the one that acts as an SS7 signaling point and is thus 
> > > > > > assigned a point
> > > > > > > code. Does it imply that all the SGPs of an SG will bear 
> > > > > > the same point
> > > > > > > code even if they are geographically separated? Is that 
> > > > > > what it means in
> > > > > > > the spec regarding a single management view to the SS7
network?
> > > > > > > 
> > > > > > > On the IP side, is it required that an ASP set up an M3UA 
> > > > > > association
> > > > > > > with each of the active SGPs? Or in other words, is it 
> > > > > > allowed by the
> > > > > > > spec that an ASP only sets up M3UA associations to a 
> > > > > > (non-empty) subset
> > > > > > > of the active SGPs?
> > > > > > > 
> > > > > > > Cheers,
> > > > > > > 
> > > > > > > --Hong
> > > > > > > 
> > > > > > [snip]
> > > > > > 
> > > > > > I believe that there are several points in the draft 
> > > > which lead to a
> > > > > > definition of an SG.  These are:
> > > > > > 
> > > > > >    o   An SGP is a unique transport (SCTP) endpoint.
> > > > > > 
> > > > > >    o   An SG is a collection or set of one or more SGPs.
> > > > > > 
> > > > > >    o   An SG terminates SS7 signalling links from the SS7
network.
> > > > > > 
> > > > > >    o   An SG has one set of Routing Keys which are shared 
> > > > by all the
> > > > > >        SGPs which make up the SG.
> > > > > > 
> > > > > >    o   Each SGP in an SG offers identical connectivity to the
SS7
> > > > > >        network.
> > > > > > 
> > > > > > There are no restrictions placed on what point codes an SG 
> > > > > > does or does
> > > > > > not represent.  There are no restrictions placed on how many 
> > > > > > SGP a Host
> > > > > > represents.  There are no restrictions in terms of the 
> > > > geographical
> > > > > > positioning of SGP within an SG.
> > > > > > 
> > > > > 
> > > > > The draft stats: "An SG appears to the SS7 network as an 
> > > > SS7 Signalling 
> > > > > Point". 
> > > > > So, for a specific SS7 network, an SG has a unique point code.
> > > > 
> > > > An SG appears to the SS7 network as having a point code,
> > > > but it doen't have to have one of its own.  This was clearly
> > > > intended in the draft from the start: that the SG can just
> > > > represent the SPMC point code which "belongs" to the ASPs.
> > > > If the SG has a point code separate from the ASP, then it
> > > > would have to be an STP.  That is not required by the spec.
> > > > 
> > > Yes, an SG has a point code from the SS7 point of view ...
> > > We are in sync here !!! :-)
> > 
> > No we are not in sync.  The SG "represents" one or more point
> > codes to the SS7 network.  It does not necessarily "have" one.
> > I though that the draft made this crystal clear.  The SG may
> > or may not have local MTP-Users.  If it has no local MTP-Users
> > and is not equipped with the transfer function, then it does
> > not "have" a point code.
> > 
> > > > > 
> > > > > > When your consider these points, an SG, in principle, 
> > > > looks like the
> > > > > > following:
> > > > > > 
> > > > > >                                                            
> > > > > >                            SG                              
> > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > >                 |                       | Associations     
> > > > > >                        __________                          
> > > > > >                 |     |          |------|-----------       
> > > > > >                       |   SGP1   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >         SS7            __________                          
> > > > > >        Links    |     |          |------|-----------       
> > > > > >     ------------      |   SGP2   |------------------       
> > > > > >     ------------|     |__________|------|-----------       
> > > > > >     ------------       __________                       To 
> > > > > >     ------------|     |          |------|-----------   ASPs
> > > > > >     ------------      |   SGP3   |------------------       
> > > > > >     ------------|     |__________|------|-----------       
> > > > > >     ------------       __________                          
> > > > > >     ------------|     |          |------|-----------       
> > > > > >     ------------      |   SGP4   |------------------       
> > > > > >     ------------|     |__________|------|-----------       
> > > > > >     ------------                                           
> > > > > >                 |           .           |                  
> > > > > >                             .                              
> > > > > >                 |           .           |                  
> > > > > >                        __________                          
> > > > > >                 |     |          |------|-----------       
> > > > > >                       |   SGPn   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >                                                            
> > > > > >                 |                       |                  
> > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > 
> > > > > > Where the argument, errr.., discussion errupts centers around
the
> > > > > > restriction that all SGP in an SG must have identical
connectivity
> > > > > > to the SS7 network and SHOULD be able to transfer traffic
between
> > > > > > them to accomplish that feat.
> > > > > > 
> > > > > > My position is that, while in principle this sounds good, in 
> > > > > > practice it
> > > > > > does not:
> > > > > > 
> > > > > 
> > > > > My position is the opposite... :-)
> > > > 
> > > > Uhmm.
> > > > 
> > > > > 
> > > > > > On of the purposes of allowing multple SGP is to allow 
> > > > the SG to be a
> > > > > > collection of multiple hosts for redudancy and scaling.  
> > > > > > Unfortunately,
> > > > > > when SGPs are multiple hosts, the possibility of a 
> > > > "partitioned" SG
> > > > > > due to internal failures is possible.  That could look like
this:
> > > > > > 
> > > > > >                                                            
> > > > > >                            SG                              
> > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > >                 |                       | Associations     
> > > > > >                        __________                          
> > > > > >                 |     |          |------|-----------       
> > > > > >                       |   SGP1   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >         SS7            __________                          
> > > > > >        Links    |     |          |------|-----------       
> > > > > >     ------------      |   SGP2   |------------------       
> > > > > >     ------------|     |__________|------|-----------       
> > > > > >    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
> > > > > >     ------------       __________                       To 
> > > > > >     ------------|     |          |------|-----------   ASPs
> > > > > >     ------------      |   SGP3   |------------------       
> > > > > >     ------------|     |__________|------|-----------       
> > > > > >     ------------       __________                          
> > > > > >     ------------|     |          |------|-----------       
> > > > > >     ------------      |   SGP4   |------------------       
> > > > > >     ------------|     |__________|------|-----------       
> > > > > >     ------------                                           
> > > > > >                 |           .           |                  
> > > > > >                             .                              
> > > > > >                 |           .           |                  
> > > > > >                        __________                          
> > > > > >                 |     |          |------|-----------       
> > > > > >                       |   SGPn   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >                                                            
> > > > > >                 |                       |                  
> > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > 
> > > > > > In some of the above "partitioned" scenarios, the SGPs 
> > > > need to be able
> > > > > > to tell the ASPs that they can no longer service specific 
> > > > > > traffic flows
> > > > > > towards the SS7 newtork.  In the current draft this can be 
> > > > > > accomplished
> > > > > > in two ways, both which are problematic.
> > > > > > 
> > > > > >   1.  The SGP can use DUNA, DAVA, and DRST independently from 
> > > > > > each of the
> > > > > >       SGP to indicate the difference in availability of 
> > > > > > routesets to the
> > > > > >       SS7 newtork above the partition and below the 
> > > > partition in the
> > > > > >       diagram.
> > > > > > 
> > > > > >       With the way that keeping DUNA, DAVA, DRST and SCON 
> > > > on a per-SGP
> > > > > >       basis at the ASP has been "watered down", however, in 
> > > > > > the M3UA-08
> > > > > >       draft, the SG cannot be guaranteed that the ASPs 
> > > > will respond
> > > > > >       properly to these partitioned indications.  If the 
> > > > ASPs respond
> > > > > >       under the "single management view", as is their 
> > > > option in the
> > > > > >       latest draft, this case will reduce to case (2) below.
> > > > > > 
> > > > > >   2.  The SGP drop their associations to the ASPs.  That is, 
> > > > > > The entire
> > > > > >       SG goes off-line.
> > > > > > 
> > > > > This is true but this is only 1 part of the problem.
> > > > > A partionned SG means also multiple PC with the same Id on 
> > > > the same SS7
> > > > > network.
> > > > 
> > > > It is the case in the SS7 network that we assign one point code
> > > > to two STPs (alias point code for GTT).  It does not cause problems
> > > > in the SS7 network.
> > > > 
> > > > > And this last problem is not solved by M3UA.
> > > > 
> > > > But could easily.
> > > I suppose that here we disagree on the level of quality the SG must
> > provide.
> > > And I think that this level will not be determined by you or me but by
> the
> > 
> > > future users of M3UA.
> > > My position is that an SS7 platform (SG) partition does not work
because
> > > it could loose SS7 messages (1 or 1000 it cannot be acceptable, for
me).
> > > M3UA cannot do anything here, it is a pure SS7 problem.
> > > > 
> > > > > Well, such a problem is mitigated by some particular SS7 
> > > > configurations, 
> > > > > for instance, when SGPs are connected to one and only one
adjacent,
> > > > > but in this case, the configuration don't take advantage of the
SS7
> > > > > redundancy:
> > > > > if one SGP fails, an entire route is lost...
> > > > > So, I think that inter SGP communications must be designed 
> > > > by SG vendors
> > > > > and not by M3UA.
> > > > > I really think that SG vendors could be creative in this 
> > > > domain and provide
> > > > > an inter SGP communication mechanism very reliable, or even 
> > > > provide a 
> > > > > mechanism (may be with another LAN dedicated to this 
> > > > purpose) to "detect"
> > > > > SG platform partition... and avoid, even when using "single 
> > > > management
> > > > > view",
> > > > > to drop all the SGP associations to the ASPs. 
> > > > 
> > > > All this cost for guaranteed inter-SGP communication is not
necessary.
> > > Well, does everybody in this mailing list agree on this comment ?
> > > > With just a little support from M3UA, the platform could run fully
> > > > partitioned and happy.  Detailed discussion of this was provided on
> > > > other threads.  Aside from low volume changeover messages and
routing
> > > > messages there should never be a need to route user level 
> > > > traffic between
> > > > SGP.  A patition in that case only causes minor message loss during
> > > > changeovers and is acceptable because the probability of
partitioning
> > > > failure coupled with the probability of changeover can be 
> > > > engineered to
> > > > meet message lost requirements quite economically.
> > > What means carrier-grade then ? 
> > > Anyway, I think that truth here depends on the quality level the final
> > > user wants ... and each future user will have its own definition of
> > > "carrier-grade" level.
> > 
> > Don't be ridiculous.  The arrangement only loses messages when
> > failures occur.  This is permitted.  Just as long as the failure
> > rate is controlled to within those bounds which are acceptable by
> > the message loss requirements of MTP.
> > 
> > Compare this to how may messages your fancy inter-SGP arrangement
> > is going to lose when (not "if") it partitions.
> > 
> > > > 
> > > > I have handled the problem, it just needs minor support from M3UA.
> > > > 
> > > On the IP side, may be. Not on the SS7 side (IMHO).
> > 
> > M3UA is not responsible for the SS7 side, the SG implementation
> > is.  M3UA need only provide the mechanisms reqruired by the SG
> > to perform its function.  I do not have to prove to _you_ that
> > the SS7 side works.
> > 
> > I am not shutting off my customer's $1M/hr cash flow just to
> > satisfy a "MAY" in the spec.
> > 
> > > > > 
> > > > > 
> > > > > > There is only one arrangement of SG/SGP in my mind that 
> > > > can keep this
> > > > > > from happening:  Make every SG consist of only one SGP, 
> > > > and have each
> > > > > > SG support only one SS7 link, like this:
> > > > > > 
> > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > >                 | SG                    | Associations     
> > > > > >        SS7             __________                          
> > > > > >        Link     |     |          |------|-----------       
> > > > > >    -------------------|   SGP1   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >                                                            
> > > > > >                 |                       |                  
> > > > > >                 \ - - - - - - - - - - - /                  
> > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > >                 | SG                    | Associations     
> > > > > >        SS7             __________                          
> > > > > >        Link     |     |          |------|-----------       
> > > > > >    -------------------|   SGP2   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >                                                            
> > > > > >                 |                       |                  
> > > > > >                 \ - - - - - - - - - - - /                  
> > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > >                 | SG                    | Associations     
> > > > > >        SS7             __________                          
> > > > > >        Link     |     |          |------|-----------       
> > > > > >    -------------------|   SGP3   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >                                                            
> > > > > >                 |                       |                  
> > > > > >                 \ - - - - - - - - - - - /                  
> > > > > >                             .                              
> > > > > >                             .                              
> > > > > >                             .                              
> > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > >                 | SG                    | Associations     
> > > > > >        SS7             __________                          
> > > > > >        Link     |     |          |------|-----------       
> > > > > >    -------------------|   SGPn   |------------------       
> > > > > >                 |     |__________|------|-----------       
> > > > > >                                                            
> > > > > >                 |                       |                  
> > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > 
> > > > > > This is possible, however, it pretty much reduces M3UA to M2UA.
> > > > > > 
> > > > > > I would rather see the SGP be provided with some 
> > > > mechanism by way of
> > > > > > which it can be assured that the ASPs will respond properly to
> > > > > > partitioned SGP.
> > > > > > 
> > > > > > Until they do, I cannot see that M3UA can be implemented in a
> > > > > > carrier-class arrangement with ASPs which treat the SG with a 
> > > > > > "single management view".
> > > > > Well, no, I think it is possible but requires a lot of experience
> > > > > in distributed computing (at least for the SGP vendors..). 
> > > > > > 
> > > > > > 
> > > > > > --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]
> > > > > > 
> > > > > 
> > > > > 
> > > > > ---
> > > > > 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]
> > 
> > -- 
> > 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]
> 
> -- 
> 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]

-- 
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: Wed, 25 Jul 2001 08:10:52 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv7: SG redundancy
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Didier,

Now that you mention different kinds of DUNA, there is another distrinction
which needs to be made:

-> Destination Unavailable Permanent Condition (No route in routing tables)
-> Destination Unavailable Transient Condition (Received TFP for
destination)

--Brian

Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
14:51:36)
> Brian,
> 
> Perhaps we need 2 levels for the DUNA (same for DAVA, DRST, SCON...):
> 
> -> Destination Unavailable for the SG  (-> GLOBAL, DUNA).
> -> Destination Unavailable for the SGP (-> LOCAL, DUNA).
> 
> Endeed in the sample bellow... SGP2 can send a DUNA(LOCAL)... So the
> destination
> is still accessible by SGP2 but it is not the more "efficiant way" to send

> the message.
> 
> /Didier
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 2:28 PM
> To: sigtran
> Subject: Re: M3UAv7: SG redundancy
> 
> 
> Didier,
> 
> Yes, it would send DUNAs iff it was a permitted way of
> getting the ASP to stop traffic to the SGP.
> 
> These examples show the need for SGP management.  If
> not DUNAs then something else...
> 
> --Brian
> 
> Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
> 14:17:20)
> > Brian,
> > Thanks for your answer and sorry to insist but in your diagram,
> > does SGP2 send (or not) the DUNAs? 
> > and if no, 
> > you have only one "single management point of view" of ss7 destinations
> per
> > SG
> > that change a lot of things...
> > 
> > /Didier
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, July 25, 2001 1:50 PM
> > To: sigtran
> > Subject: Re: M3UAv7: SG redundancy
> > 
> > 
> > Didier,
> > 
> > I have answered this before, but, again: If I can modify your
> > diagram sligtly:
> >   
> >                           SG
> >                + - - - - - - - - - - - +
> >        SS7     |Switch                 |
> >       Links       |   __________            SCTP
> >    ------------|--|  |          |      | Associations   __________
> >    ------------ --|--|   SGP1   |-X-X-X-X-X-X-X-X-X-X--|          |
> >    ------------|--|  |__________|      |               |   ASP    |
> >                   |   __________                  +----|__________|
> >    -X-X-X-X-X--|--|  |          |      |          |
> >    -X-X-X-X-X-- --|--|   SGP2   |-----------------+
> >    -X-X-X-X-X--|--|  |__________|      |
> >                   |
> >                |                       |
> >                + - - - - - - - - - - - +
> >   
> > If there is another degree of freedom between the SGP
> > and the SS7 Links (H.100 bus, M2UA) then in your scenario
> > I would have SGP2 take over the SS7 links from SGP1.
> > There is still no need to route user level traffic
> > between SGP.  Depending on the architecture, it might
> > be too drastic a measure off the start.
> > 
> > --Brian
> > 
> > 
> > > 2/ all destinations in SGP1 are UP.
> > > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for
all
> > > destinations...
> > > 3/ The SCTP asso SGP1-ASP just falling.
> > 
> > Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
> > 13:38:22)
> > > Brian,
> > > Can you explain that, consider the following :
> > > 
> > > 1/ SGP in the same SG do not have a "single management point of view"
> that
> > > is
> > > to say they are sharing the same ss7 destinations but each SGP has its
> own
> > 
> > > management view...
> > > 
> > >                         SG
> > >              + - - - - - - - - - - - +
> > >      SS7     |                       |
> > >     Links           __________            SCTP
> > >  ------------|     |          |      | Associations   __________
> > >  ------------      |   SGP1   |----------------------|          |
> > >  ------------|     |__________|      |               |   ASP    |
> > >                     __________                  +----|__________|
> > >  ------------|     |          |      |          |
> > >  ------------      |   SGP2   |-----------------+
> > >  ------------|     |__________|      |
> > > 
> > >              |                       |
> > >              + - - - - - - - - - - - +
> > > 
> > > 2/ all destinations in SGP1 are UP.
> > > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for
all
> > > destinations...
> > > 3/ The SCTP asso SGP1-ASP just falling.
> > > 4/ ASP has to send data to one destination and this SG is the priority
> > > route.
> > > 
> > > Does the ASP not send this data? 
> > > Does the ASP choose another SG to send this DATA?
> > > >> even if the destination is not considered as DOWN from SS7 point of
> > view
> > > and
> > >    this SG is the priority route!!!!
> > > 
> > > And is it aceptable on the M3UA point of view?
> > > 
> > > /Didier
> > > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, July 25, 2001 12:09 PM
> > > To: sigtran
> > > Subject: Re: M3UAv7: SG redundancy
> > > 
> > > 
> > > Pierre,
> > > 
> > > Please see more comments below...
> > > 
> > > Garnero, Pierre wrote:                    (Wed, 25 Jul 2001 11:43:56)
> > > > Brian,
> > > > 
> > > > just some comments below:
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Wednesday, July 25, 2001 11:20 AM
> > > > > To: sigtran
> > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > 
> > > > > 
> > > > > Pierre,
> > > > > 
> > > > > Please see comments below...
> > > > > 
> > > > > Garnero, Pierre wrote:                                   
> > > > > (Wed, 25 Jul 2001 10:33:34)
> > > > > > Hello Hong,
> > > > > > 
> > > > > > please find another point of view, included in Brians
comments...
> > > > > > 
> > > > > > Cheers,
> > > > > > 
> > > > > > PiG
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > Sent: Wednesday, July 25, 2001 8:28 AM
> > > > > > > To: sigtran
> > > > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > > > 
> > > > > > > 
> > > > > > > Hong,
> > > > > > > 
> > > > > > > You bring up some good questions.
> > > > > > > 
> > > > > > > Hong Liu wrote:                              (Wed, 25 Jul 
> > > > > > > 2001 08:08:07)
> > > > > > > > Hi, Brian,
> > > > > > > > 
> > > > > > > > I am also confused by the notion of SG vs. SGP in the 
> > > > > > > current M3UA spec.
> > > > > > > > Maybe you can help me to understand the concepts better. I 
> > > > > > > noticed that
> > > > > > > > there was a long thread of discussions on the list a few 
> > > > > > > months ago on
> > > > > > > > this topic. So I apologize in advance if I bring up 
> > > > > > > something that has
> > > > > > > > already been clarified.
> > > > > > > > 
> > > > > > > > According to the current spec, an SG is a logical 
> > > > > entity if it is
> > > > > > > > composed of more than one SGP. From the SS7 network point 
> > > > > > > of view, SG is
> > > > > > > > the one that acts as an SS7 signaling point and is thus 
> > > > > > > assigned a point
> > > > > > > > code. Does it imply that all the SGPs of an SG will bear 
> > > > > > > the same point
> > > > > > > > code even if they are geographically separated? Is that 
> > > > > > > what it means in
> > > > > > > > the spec regarding a single management view to the SS7
> network?
> > > > > > > > 
> > > > > > > > On the IP side, is it required that an ASP set up an M3UA 
> > > > > > > association
> > > > > > > > with each of the active SGPs? Or in other words, is it 
> > > > > > > allowed by the
> > > > > > > > spec that an ASP only sets up M3UA associations to a 
> > > > > > > (non-empty) subset
> > > > > > > > of the active SGPs?
> > > > > > > > 
> > > > > > > > Cheers,
> > > > > > > > 
> > > > > > > > --Hong
> > > > > > > > 
> > > > > > > [snip]
> > > > > > > 
> > > > > > > I believe that there are several points in the draft 
> > > > > which lead to a
> > > > > > > definition of an SG.  These are:
> > > > > > > 
> > > > > > >    o   An SGP is a unique transport (SCTP) endpoint.
> > > > > > > 
> > > > > > >    o   An SG is a collection or set of one or more SGPs.
> > > > > > > 
> > > > > > >    o   An SG terminates SS7 signalling links from the SS7
> network.
> > > > > > > 
> > > > > > >    o   An SG has one set of Routing Keys which are shared 
> > > > > by all the
> > > > > > >        SGPs which make up the SG.
> > > > > > > 
> > > > > > >    o   Each SGP in an SG offers identical connectivity to the
> SS7
> > > > > > >        network.
> > > > > > > 
> > > > > > > There are no restrictions placed on what point codes an SG 
> > > > > > > does or does
> > > > > > > not represent.  There are no restrictions placed on how many 
> > > > > > > SGP a Host
> > > > > > > represents.  There are no restrictions in terms of the 
> > > > > geographical
> > > > > > > positioning of SGP within an SG.
> > > > > > > 
> > > > > > 
> > > > > > The draft stats: "An SG appears to the SS7 network as an 
> > > > > SS7 Signalling 
> > > > > > Point". 
> > > > > > So, for a specific SS7 network, an SG has a unique point code.
> > > > > 
> > > > > An SG appears to the SS7 network as having a point code,
> > > > > but it doen't have to have one of its own.  This was clearly
> > > > > intended in the draft from the start: that the SG can just
> > > > > represent the SPMC point code which "belongs" to the ASPs.
> > > > > If the SG has a point code separate from the ASP, then it
> > > > > would have to be an STP.  That is not required by the spec.
> > > > > 
> > > > Yes, an SG has a point code from the SS7 point of view ...
> > > > We are in sync here !!! :-)
> > > 
> > > No we are not in sync.  The SG "represents" one or more point
> > > codes to the SS7 network.  It does not necessarily "have" one.
> > > I though that the draft made this crystal clear.  The SG may
> > > or may not have local MTP-Users.  If it has no local MTP-Users
> > > and is not equipped with the transfer function, then it does
> > > not "have" a point code.
> > > 
> > > > > > 
> > > > > > > When your consider these points, an SG, in principle, 
> > > > > looks like the
> > > > > > > following:
> > > > > > > 
> > > > > > >                                                            
> > > > > > >                            SG                              
> > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > >                 |                       | Associations     
> > > > > > >                        __________                          
> > > > > > >                 |     |          |------|-----------       
> > > > > > >                       |   SGP1   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >         SS7            __________                          
> > > > > > >        Links    |     |          |------|-----------       
> > > > > > >     ------------      |   SGP2   |------------------       
> > > > > > >     ------------|     |__________|------|-----------       
> > > > > > >     ------------       __________                       To 
> > > > > > >     ------------|     |          |------|-----------   ASPs
> > > > > > >     ------------      |   SGP3   |------------------       
> > > > > > >     ------------|     |__________|------|-----------       
> > > > > > >     ------------       __________                          
> > > > > > >     ------------|     |          |------|-----------       
> > > > > > >     ------------      |   SGP4   |------------------       
> > > > > > >     ------------|     |__________|------|-----------       
> > > > > > >     ------------                                           
> > > > > > >                 |           .           |                  
> > > > > > >                             .                              
> > > > > > >                 |           .           |                  
> > > > > > >                        __________                          
> > > > > > >                 |     |          |------|-----------       
> > > > > > >                       |   SGPn   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >                                                            
> > > > > > >                 |                       |                  
> > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > 
> > > > > > > Where the argument, errr.., discussion errupts centers around
> the
> > > > > > > restriction that all SGP in an SG must have identical
> connectivity
> > > > > > > to the SS7 network and SHOULD be able to transfer traffic
> between
> > > > > > > them to accomplish that feat.
> > > > > > > 
> > > > > > > My position is that, while in principle this sounds good, in 
> > > > > > > practice it
> > > > > > > does not:
> > > > > > > 
> > > > > > 
> > > > > > My position is the opposite... :-)
> > > > > 
> > > > > Uhmm.
> > > > > 
> > > > > > 
> > > > > > > On of the purposes of allowing multple SGP is to allow 
> > > > > the SG to be a
> > > > > > > collection of multiple hosts for redudancy and scaling.  
> > > > > > > Unfortunately,
> > > > > > > when SGPs are multiple hosts, the possibility of a 
> > > > > "partitioned" SG
> > > > > > > due to internal failures is possible.  That could look like
> this:
> > > > > > > 
> > > > > > >                                                            
> > > > > > >                            SG                              
> > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > >                 |                       | Associations     
> > > > > > >                        __________                          
> > > > > > >                 |     |          |------|-----------       
> > > > > > >                       |   SGP1   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >         SS7            __________                          
> > > > > > >        Links    |     |          |------|-----------       
> > > > > > >     ------------      |   SGP2   |------------------       
> > > > > > >     ------------|     |__________|------|-----------       
> > > > > > >    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
> > > > > > >     ------------       __________                       To 
> > > > > > >     ------------|     |          |------|-----------   ASPs
> > > > > > >     ------------      |   SGP3   |------------------       
> > > > > > >     ------------|     |__________|------|-----------       
> > > > > > >     ------------       __________                          
> > > > > > >     ------------|     |          |------|-----------       
> > > > > > >     ------------      |   SGP4   |------------------       
> > > > > > >     ------------|     |__________|------|-----------       
> > > > > > >     ------------                                           
> > > > > > >                 |           .           |                  
> > > > > > >                             .                              
> > > > > > >                 |           .           |                  
> > > > > > >                        __________                          
> > > > > > >                 |     |          |------|-----------       
> > > > > > >                       |   SGPn   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >                                                            
> > > > > > >                 |                       |                  
> > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > 
> > > > > > > In some of the above "partitioned" scenarios, the SGPs 
> > > > > need to be able
> > > > > > > to tell the ASPs that they can no longer service specific 
> > > > > > > traffic flows
> > > > > > > towards the SS7 newtork.  In the current draft this can be 
> > > > > > > accomplished
> > > > > > > in two ways, both which are problematic.
> > > > > > > 
> > > > > > >   1.  The SGP can use DUNA, DAVA, and DRST independently from 
> > > > > > > each of the
> > > > > > >       SGP to indicate the difference in availability of 
> > > > > > > routesets to the
> > > > > > >       SS7 newtork above the partition and below the 
> > > > > partition in the
> > > > > > >       diagram.
> > > > > > > 
> > > > > > >       With the way that keeping DUNA, DAVA, DRST and SCON 
> > > > > on a per-SGP
> > > > > > >       basis at the ASP has been "watered down", however, in 
> > > > > > > the M3UA-08
> > > > > > >       draft, the SG cannot be guaranteed that the ASPs 
> > > > > will respond
> > > > > > >       properly to these partitioned indications.  If the 
> > > > > ASPs respond
> > > > > > >       under the "single management view", as is their 
> > > > > option in the
> > > > > > >       latest draft, this case will reduce to case (2) below.
> > > > > > > 
> > > > > > >   2.  The SGP drop their associations to the ASPs.  That is, 
> > > > > > > The entire
> > > > > > >       SG goes off-line.
> > > > > > > 
> > > > > > This is true but this is only 1 part of the problem.
> > > > > > A partionned SG means also multiple PC with the same Id on 
> > > > > the same SS7
> > > > > > network.
> > > > > 
> > > > > It is the case in the SS7 network that we assign one point code
> > > > > to two STPs (alias point code for GTT).  It does not cause
problems
> > > > > in the SS7 network.
> > > > > 
> > > > > > And this last problem is not solved by M3UA.
> > > > > 
> > > > > But could easily.
> > > > I suppose that here we disagree on the level of quality the SG must
> > > provide.
> > > > And I think that this level will not be determined by you or me but
by
> > the
> > > 
> > > > future users of M3UA.
> > > > My position is that an SS7 platform (SG) partition does not work
> because
> > > > it could loose SS7 messages (1 or 1000 it cannot be acceptable, for
> me).
> > > > M3UA cannot do anything here, it is a pure SS7 problem.
> > > > > 
> > > > > > Well, such a problem is mitigated by some particular SS7 
> > > > > configurations, 
> > > > > > for instance, when SGPs are connected to one and only one
> adjacent,
> > > > > > but in this case, the configuration don't take advantage of the
> SS7
> > > > > > redundancy:
> > > > > > if one SGP fails, an entire route is lost...
> > > > > > So, I think that inter SGP communications must be designed 
> > > > > by SG vendors
> > > > > > and not by M3UA.
> > > > > > I really think that SG vendors could be creative in this 
> > > > > domain and provide
> > > > > > an inter SGP communication mechanism very reliable, or even 
> > > > > provide a 
> > > > > > mechanism (may be with another LAN dedicated to this 
> > > > > purpose) to "detect"
> > > > > > SG platform partition... and avoid, even when using "single 
> > > > > management
> > > > > > view",
> > > > > > to drop all the SGP associations to the ASPs. 
> > > > > 
> > > > > All this cost for guaranteed inter-SGP communication is not
> necessary.
> > > > Well, does everybody in this mailing list agree on this comment ?
> > > > > With just a little support from M3UA, the platform could run fully
> > > > > partitioned and happy.  Detailed discussion of this was provided
on
> > > > > other threads.  Aside from low volume changeover messages and
> routing
> > > > > messages there should never be a need to route user level 
> > > > > traffic between
> > > > > SGP.  A patition in that case only causes minor message loss
during
> > > > > changeovers and is acceptable because the probability of
> partitioning
> > > > > failure coupled with the probability of changeover can be 
> > > > > engineered to
> > > > > meet message lost requirements quite economically.
> > > > What means carrier-grade then ? 
> > > > Anyway, I think that truth here depends on the quality level the
final
> > > > user wants ... and each future user will have its own definition of
> > > > "carrier-grade" level.
> > > 
> > > Don't be ridiculous.  The arrangement only loses messages when
> > > failures occur.  This is permitted.  Just as long as the failure
> > > rate is controlled to within those bounds which are acceptable by
> > > the message loss requirements of MTP.
> > > 
> > > Compare this to how may messages your fancy inter-SGP arrangement
> > > is going to lose when (not "if") it partitions.
> > > 
> > > > > 
> > > > > I have handled the problem, it just needs minor support from M3UA.
> > > > > 
> > > > On the IP side, may be. Not on the SS7 side (IMHO).
> > > 
> > > M3UA is not responsible for the SS7 side, the SG implementation
> > > is.  M3UA need only provide the mechanisms reqruired by the SG
> > > to perform its function.  I do not have to prove to _you_ that
> > > the SS7 side works.
> > > 
> > > I am not shutting off my customer's $1M/hr cash flow just to
> > > satisfy a "MAY" in the spec.
> > > 
> > > > > > 
> > > > > > 
> > > > > > > There is only one arrangement of SG/SGP in my mind that 
> > > > > can keep this
> > > > > > > from happening:  Make every SG consist of only one SGP, 
> > > > > and have each
> > > > > > > SG support only one SS7 link, like this:
> > > > > > > 
> > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > >                 | SG                    | Associations     
> > > > > > >        SS7             __________                          
> > > > > > >        Link     |     |          |------|-----------       
> > > > > > >    -------------------|   SGP1   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >                                                            
> > > > > > >                 |                       |                  
> > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > >                 | SG                    | Associations     
> > > > > > >        SS7             __________                          
> > > > > > >        Link     |     |          |------|-----------       
> > > > > > >    -------------------|   SGP2   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >                                                            
> > > > > > >                 |                       |                  
> > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > >                 | SG                    | Associations     
> > > > > > >        SS7             __________                          
> > > > > > >        Link     |     |          |------|-----------       
> > > > > > >    -------------------|   SGP3   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >                                                            
> > > > > > >                 |                       |                  
> > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > >                             .                              
> > > > > > >                             .                              
> > > > > > >                             .                              
> > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > >                 | SG                    | Associations     
> > > > > > >        SS7             __________                          
> > > > > > >        Link     |     |          |------|-----------       
> > > > > > >    -------------------|   SGPn   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >                                                            
> > > > > > >                 |                       |                  
> > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > 
> > > > > > > This is possible, however, it pretty much reduces M3UA to
M2UA.
> > > > > > > 
> > > > > > > I would rather see the SGP be provided with some 
> > > > > mechanism by way of
> > > > > > > which it can be assured that the ASPs will respond properly to
> > > > > > > partitioned SGP.
> > > > > > > 
> > > > > > > Until they do, I cannot see that M3UA can be implemented in a
> > > > > > > carrier-class arrangement with ASPs which treat the SG with a 
> > > > > > > "single management view".
> > > > > > Well, no, I think it is possible but requires a lot of
experience
> > > > > > in distributed computing (at least for the SGP vendors..). 
> > > > > > > 
> > > > > > > 
> > > > > > > --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]
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ---
> > > > > > 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]
> > > 
> > > -- 
> > > 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]
> > 
> > -- 
> > 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]
> 
> -- 
> 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]

-- 
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: "Desiderio, Didier" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv7: SG redundancy
Date: Wed, 25 Jul 2001 16:13:48 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zcamail04.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zcamail04.zca.compaq.com [161.114.32.104]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Bryan,
Aren't they same concept?

DUNA(Global): -> Destination Unavailable Permanent Condition (No route in
routing tables)
DUNA(Local) : -> Destination Unavailable Transient Condition (Received TFP
for destination)
                 -->> TFP is one of the possible SS7 event...

On ASP point of view the only thing that ASP needs is to have an efficiant
routing...
Why does ASP need to know that SGP receive TFP for one destination?

The only thing that ASP needs is to know that one SGP: * can not reach one
destination (No route in routing tables).
->DUNA(Global).
* can reach one destination but not directly (because this SGP receive TFP,
or 
  one of its link fail or whatever else, implementation dependant).
->DUNA(Local)

/Didier

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Wednesday,
July 25, 2001 3:11 PM
To: sigtran
Subject: Re: M3UAv7: SG redundancy

Didier,

Now that you mention different kinds of DUNA, there is another distrinction
which needs to be made:

-> Destination Unavailable Permanent Condition (No route in routing tables)
-> Destination Unavailable Transient Condition (Received TFP for
destination)

--Brian

Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
14:51:36)
> Brian,
> 
> Perhaps we need 2 levels for the DUNA (same for DAVA, DRST, SCON...):
> 
> -> Destination Unavailable for the SG  (-> GLOBAL, DUNA).
> -> Destination Unavailable for the SGP (-> LOCAL, DUNA).
> 
> Endeed in the sample bellow... SGP2 can send a DUNA(LOCAL)... So the
> destination
> is still accessible by SGP2 but it is not the more "efficiant way" to send

> the message.
> 
> /Didier
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 2:28 PM
> To: sigtran
> Subject: Re: M3UAv7: SG redundancy
> 
> 
> Didier,
> 
> Yes, it would send DUNAs iff it was a permitted way of
> getting the ASP to stop traffic to the SGP.
> 
> These examples show the need for SGP management.  If
> not DUNAs then something else...
> 
> --Brian
> 
> Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
> 14:17:20)
> > Brian,
> > Thanks for your answer and sorry to insist but in your diagram,
> > does SGP2 send (or not) the DUNAs? 
> > and if no, 
> > you have only one "single management point of view" of ss7 destinations
> per
> > SG
> > that change a lot of things...
> > 
> > /Didier
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, July 25, 2001 1:50 PM
> > To: sigtran
> > Subject: Re: M3UAv7: SG redundancy
> > 
> > 
> > Didier,
> > 
> > I have answered this before, but, again: If I can modify your
> > diagram sligtly:
> >   
> >                           SG
> >                + - - - - - - - - - - - +
> >        SS7     |Switch                 |
> >       Links       |   __________            SCTP
> >    ------------|--|  |          |      | Associations   __________
> >    ------------ --|--|   SGP1   |-X-X-X-X-X-X-X-X-X-X--|          |
> >    ------------|--|  |__________|      |               |   ASP    |
> >                   |   __________                  +----|__________|
> >    -X-X-X-X-X--|--|  |          |      |          |
> >    -X-X-X-X-X-- --|--|   SGP2   |-----------------+
> >    -X-X-X-X-X--|--|  |__________|      |
> >                   |
> >                |                       |
> >                + - - - - - - - - - - - +
> >   
> > If there is another degree of freedom between the SGP
> > and the SS7 Links (H.100 bus, M2UA) then in your scenario
> > I would have SGP2 take over the SS7 links from SGP1.
> > There is still no need to route user level traffic
> > between SGP.  Depending on the architecture, it might
> > be too drastic a measure off the start.
> > 
> > --Brian
> > 
> > 
> > > 2/ all destinations in SGP1 are UP.
> > > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for
all
> > > destinations...
> > > 3/ The SCTP asso SGP1-ASP just falling.
> > 
> > Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
> > 13:38:22)
> > > Brian,
> > > Can you explain that, consider the following :
> > > 
> > > 1/ SGP in the same SG do not have a "single management point of view"
> that
> > > is
> > > to say they are sharing the same ss7 destinations but each SGP has its
> own
> > 
> > > management view...
> > > 
> > >                         SG
> > >              + - - - - - - - - - - - +
> > >      SS7     |                       |
> > >     Links           __________            SCTP
> > >  ------------|     |          |      | Associations   __________
> > >  ------------      |   SGP1   |----------------------|          |
> > >  ------------|     |__________|      |               |   ASP    |
> > >                     __________                  +----|__________|
> > >  ------------|     |          |      |          |
> > >  ------------      |   SGP2   |-----------------+
> > >  ------------|     |__________|      |
> > > 
> > >              |                       |
> > >              + - - - - - - - - - - - +
> > > 
> > > 2/ all destinations in SGP1 are UP.
> > > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for
all
> > > destinations...
> > > 3/ The SCTP asso SGP1-ASP just falling.
> > > 4/ ASP has to send data to one destination and this SG is the priority
> > > route.
> > > 
> > > Does the ASP not send this data? 
> > > Does the ASP choose another SG to send this DATA?
> > > >> even if the destination is not considered as DOWN from SS7 point of
> > view
> > > and
> > >    this SG is the priority route!!!!
> > > 
> > > And is it aceptable on the M3UA point of view?
> > > 
> > > /Didier
> > > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, July 25, 2001 12:09 PM
> > > To: sigtran
> > > Subject: Re: M3UAv7: SG redundancy
> > > 
> > > 
> > > Pierre,
> > > 
> > > Please see more comments below...
> > > 
> > > Garnero, Pierre wrote:                    (Wed, 25 Jul 2001 11:43:56)
> > > > Brian,
> > > > 
> > > > just some comments below:
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Wednesday, July 25, 2001 11:20 AM
> > > > > To: sigtran
> > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > 
> > > > > 
> > > > > Pierre,
> > > > > 
> > > > > Please see comments below...
> > > > > 
> > > > > Garnero, Pierre wrote:                                   
> > > > > (Wed, 25 Jul 2001 10:33:34)
> > > > > > Hello Hong,
> > > > > > 
> > > > > > please find another point of view, included in Brians
comments...
> > > > > > 
> > > > > > Cheers,
> > > > > > 
> > > > > > PiG
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > Sent: Wednesday, July 25, 2001 8:28 AM
> > > > > > > To: sigtran
> > > > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > > > 
> > > > > > > 
> > > > > > > Hong,
> > > > > > > 
> > > > > > > You bring up some good questions.
> > > > > > > 
> > > > > > > Hong Liu wrote:                              (Wed, 25 Jul 
> > > > > > > 2001 08:08:07)
> > > > > > > > Hi, Brian,
> > > > > > > > 
> > > > > > > > I am also confused by the notion of SG vs. SGP in the 
> > > > > > > current M3UA spec.
> > > > > > > > Maybe you can help me to understand the concepts better. I 
> > > > > > > noticed that
> > > > > > > > there was a long thread of discussions on the list a few 
> > > > > > > months ago on
> > > > > > > > this topic. So I apologize in advance if I bring up 
> > > > > > > something that has
> > > > > > > > already been clarified.
> > > > > > > > 
> > > > > > > > According to the current spec, an SG is a logical 
> > > > > entity if it is
> > > > > > > > composed of more than one SGP. From the SS7 network point 
> > > > > > > of view, SG is
> > > > > > > > the one that acts as an SS7 signaling point and is thus 
> > > > > > > assigned a point
> > > > > > > > code. Does it imply that all the SGPs of an SG will bear 
> > > > > > > the same point
> > > > > > > > code even if they are geographically separated? Is that 
> > > > > > > what it means in
> > > > > > > > the spec regarding a single management view to the SS7
> network?
> > > > > > > > 
> > > > > > > > On the IP side, is it required that an ASP set up an M3UA 
> > > > > > > association
> > > > > > > > with each of the active SGPs? Or in other words, is it 
> > > > > > > allowed by the
> > > > > > > > spec that an ASP only sets up M3UA associations to a 
> > > > > > > (non-empty) subset
> > > > > > > > of the active SGPs?
> > > > > > > > 
> > > > > > > > Cheers,
> > > > > > > > 
> > > > > > > > --Hong
> > > > > > > > 
> > > > > > > [snip]
> > > > > > > 
> > > > > > > I believe that there are several points in the draft 
> > > > > which lead to a
> > > > > > > definition of an SG.  These are:
> > > > > > > 
> > > > > > >    o   An SGP is a unique transport (SCTP) endpoint.
> > > > > > > 
> > > > > > >    o   An SG is a collection or set of one or more SGPs.
> > > > > > > 
> > > > > > >    o   An SG terminates SS7 signalling links from the SS7
> network.
> > > > > > > 
> > > > > > >    o   An SG has one set of Routing Keys which are shared 
> > > > > by all the
> > > > > > >        SGPs which make up the SG.
> > > > > > > 
> > > > > > >    o   Each SGP in an SG offers identical connectivity to the
> SS7
> > > > > > >        network.
> > > > > > > 
> > > > > > > There are no restrictions placed on what point codes an SG 
> > > > > > > does or does
> > > > > > > not represent.  There are no restrictions placed on how many 
> > > > > > > SGP a Host
> > > > > > > represents.  There are no restrictions in terms of the 
> > > > > geographical
> > > > > > > positioning of SGP within an SG.
> > > > > > > 
> > > > > > 
> > > > > > The draft stats: "An SG appears to the SS7 network as an 
> > > > > SS7 Signalling 
> > > > > > Point". 
> > > > > > So, for a specific SS7 network, an SG has a unique point code.
> > > > > 
> > > > > An SG appears to the SS7 network as having a point code,
> > > > > but it doen't have to have one of its own.  This was clearly
> > > > > intended in the draft from the start: that the SG can just
> > > > > represent the SPMC point code which "belongs" to the ASPs.
> > > > > If the SG has a point code separate from the ASP, then it
> > > > > would have to be an STP.  That is not required by the spec.
> > > > > 
> > > > Yes, an SG has a point code from the SS7 point of view ...
> > > > We are in sync here !!! :-)
> > > 
> > > No we are not in sync.  The SG "represents" one or more point
> > > codes to the SS7 network.  It does not necessarily "have" one.
> > > I though that the draft made this crystal clear.  The SG may
> > > or may not have local MTP-Users.  If it has no local MTP-Users
> > > and is not equipped with the transfer function, then it does
> > > not "have" a point code.
> > > 
> > > > > > 
> > > > > > > When your consider these points, an SG, in principle, 
> > > > > looks like the
> > > > > > > following:
> > > > > > > 
> > > > > > >                                                            
> > > > > > >                            SG                              
> > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > >                 |                       | Associations     
> > > > > > >                        __________                          
> > > > > > >                 |     |          |------|-----------       
> > > > > > >                       |   SGP1   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >         SS7            __________                          
> > > > > > >        Links    |     |          |------|-----------       
> > > > > > >     ------------      |   SGP2   |------------------       
> > > > > > >     ------------|     |__________|------|-----------       
> > > > > > >     ------------       __________                       To 
> > > > > > >     ------------|     |          |------|-----------   ASPs
> > > > > > >     ------------      |   SGP3   |------------------       
> > > > > > >     ------------|     |__________|------|-----------       
> > > > > > >     ------------       __________                          
> > > > > > >     ------------|     |          |------|-----------       
> > > > > > >     ------------      |   SGP4   |------------------       
> > > > > > >     ------------|     |__________|------|-----------       
> > > > > > >     ------------                                           
> > > > > > >                 |           .           |                  
> > > > > > >                             .                              
> > > > > > >                 |           .           |                  
> > > > > > >                        __________                          
> > > > > > >                 |     |          |------|-----------       
> > > > > > >                       |   SGPn   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >                                                            
> > > > > > >                 |                       |                  
> > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > 
> > > > > > > Where the argument, errr.., discussion errupts centers around
> the
> > > > > > > restriction that all SGP in an SG must have identical
> connectivity
> > > > > > > to the SS7 network and SHOULD be able to transfer traffic
> between
> > > > > > > them to accomplish that feat.
> > > > > > > 
> > > > > > > My position is that, while in principle this sounds good, in 
> > > > > > > practice it
> > > > > > > does not:
> > > > > > > 
> > > > > > 
> > > > > > My position is the opposite... :-)
> > > > > 
> > > > > Uhmm.
> > > > > 
> > > > > > 
> > > > > > > On of the purposes of allowing multple SGP is to allow 
> > > > > the SG to be a
> > > > > > > collection of multiple hosts for redudancy and scaling.  
> > > > > > > Unfortunately,
> > > > > > > when SGPs are multiple hosts, the possibility of a 
> > > > > "partitioned" SG
> > > > > > > due to internal failures is possible.  That could look like
> this:
> > > > > > > 
> > > > > > >                                                            
> > > > > > >                            SG                              
> > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > >                 |                       | Associations     
> > > > > > >                        __________                          
> > > > > > >                 |     |          |------|-----------       
> > > > > > >                       |   SGP1   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >         SS7            __________                          
> > > > > > >        Links    |     |          |------|-----------       
> > > > > > >     ------------      |   SGP2   |------------------       
> > > > > > >     ------------|     |__________|------|-----------       
> > > > > > >    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
> > > > > > >     ------------       __________                       To 
> > > > > > >     ------------|     |          |------|-----------   ASPs
> > > > > > >     ------------      |   SGP3   |------------------       
> > > > > > >     ------------|     |__________|------|-----------       
> > > > > > >     ------------       __________                          
> > > > > > >     ------------|     |          |------|-----------       
> > > > > > >     ------------      |   SGP4   |------------------       
> > > > > > >     ------------|     |__________|------|-----------       
> > > > > > >     ------------                                           
> > > > > > >                 |           .           |                  
> > > > > > >                             .                              
> > > > > > >                 |           .           |                  
> > > > > > >                        __________                          
> > > > > > >                 |     |          |------|-----------       
> > > > > > >                       |   SGPn   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >                                                            
> > > > > > >                 |                       |                  
> > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > 
> > > > > > > In some of the above "partitioned" scenarios, the SGPs 
> > > > > need to be able
> > > > > > > to tell the ASPs that they can no longer service specific 
> > > > > > > traffic flows
> > > > > > > towards the SS7 newtork.  In the current draft this can be 
> > > > > > > accomplished
> > > > > > > in two ways, both which are problematic.
> > > > > > > 
> > > > > > >   1.  The SGP can use DUNA, DAVA, and DRST independently from 
> > > > > > > each of the
> > > > > > >       SGP to indicate the difference in availability of 
> > > > > > > routesets to the
> > > > > > >       SS7 newtork above the partition and below the 
> > > > > partition in the
> > > > > > >       diagram.
> > > > > > > 
> > > > > > >       With the way that keeping DUNA, DAVA, DRST and SCON 
> > > > > on a per-SGP
> > > > > > >       basis at the ASP has been "watered down", however, in 
> > > > > > > the M3UA-08
> > > > > > >       draft, the SG cannot be guaranteed that the ASPs 
> > > > > will respond
> > > > > > >       properly to these partitioned indications.  If the 
> > > > > ASPs respond
> > > > > > >       under the "single management view", as is their 
> > > > > option in the
> > > > > > >       latest draft, this case will reduce to case (2) below.
> > > > > > > 
> > > > > > >   2.  The SGP drop their associations to the ASPs.  That is, 
> > > > > > > The entire
> > > > > > >       SG goes off-line.
> > > > > > > 
> > > > > > This is true but this is only 1 part of the problem.
> > > > > > A partionned SG means also multiple PC with the same Id on 
> > > > > the same SS7
> > > > > > network.
> > > > > 
> > > > > It is the case in the SS7 network that we assign one point code
> > > > > to two STPs (alias point code for GTT).  It does not cause
problems
> > > > > in the SS7 network.
> > > > > 
> > > > > > And this last problem is not solved by M3UA.
> > > > > 
> > > > > But could easily.
> > > > I suppose that here we disagree on the level of quality the SG must
> > > provide.
> > > > And I think that this level will not be determined by you or me but
by
> > the
> > > 
> > > > future users of M3UA.
> > > > My position is that an SS7 platform (SG) partition does not work
> because
> > > > it could loose SS7 messages (1 or 1000 it cannot be acceptable, for
> me).
> > > > M3UA cannot do anything here, it is a pure SS7 problem.
> > > > > 
> > > > > > Well, such a problem is mitigated by some particular SS7 
> > > > > configurations, 
> > > > > > for instance, when SGPs are connected to one and only one
> adjacent,
> > > > > > but in this case, the configuration don't take advantage of the
> SS7
> > > > > > redundancy:
> > > > > > if one SGP fails, an entire route is lost...
> > > > > > So, I think that inter SGP communications must be designed 
> > > > > by SG vendors
> > > > > > and not by M3UA.
> > > > > > I really think that SG vendors could be creative in this 
> > > > > domain and provide
> > > > > > an inter SGP communication mechanism very reliable, or even 
> > > > > provide a 
> > > > > > mechanism (may be with another LAN dedicated to this 
> > > > > purpose) to "detect"
> > > > > > SG platform partition... and avoid, even when using "single 
> > > > > management
> > > > > > view",
> > > > > > to drop all the SGP associations to the ASPs. 
> > > > > 
> > > > > All this cost for guaranteed inter-SGP communication is not
> necessary.
> > > > Well, does everybody in this mailing list agree on this comment ?
> > > > > With just a little support from M3UA, the platform could run fully
> > > > > partitioned and happy.  Detailed discussion of this was provided
on
> > > > > other threads.  Aside from low volume changeover messages and
> routing
> > > > > messages there should never be a need to route user level 
> > > > > traffic between
> > > > > SGP.  A patition in that case only causes minor message loss
during
> > > > > changeovers and is acceptable because the probability of
> partitioning
> > > > > failure coupled with the probability of changeover can be 
> > > > > engineered to
> > > > > meet message lost requirements quite economically.
> > > > What means carrier-grade then ? 
> > > > Anyway, I think that truth here depends on the quality level the
final
> > > > user wants ... and each future user will have its own definition of
> > > > "carrier-grade" level.
> > > 
> > > Don't be ridiculous.  The arrangement only loses messages when
> > > failures occur.  This is permitted.  Just as long as the failure
> > > rate is controlled to within those bounds which are acceptable by
> > > the message loss requirements of MTP.
> > > 
> > > Compare this to how may messages your fancy inter-SGP arrangement
> > > is going to lose when (not "if") it partitions.
> > > 
> > > > > 
> > > > > I have handled the problem, it just needs minor support from M3UA.
> > > > > 
> > > > On the IP side, may be. Not on the SS7 side (IMHO).
> > > 
> > > M3UA is not responsible for the SS7 side, the SG implementation
> > > is.  M3UA need only provide the mechanisms reqruired by the SG
> > > to perform its function.  I do not have to prove to _you_ that
> > > the SS7 side works.
> > > 
> > > I am not shutting off my customer's $1M/hr cash flow just to
> > > satisfy a "MAY" in the spec.
> > > 
> > > > > > 
> > > > > > 
> > > > > > > There is only one arrangement of SG/SGP in my mind that 
> > > > > can keep this
> > > > > > > from happening:  Make every SG consist of only one SGP, 
> > > > > and have each
> > > > > > > SG support only one SS7 link, like this:
> > > > > > > 
> > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > >                 | SG                    | Associations     
> > > > > > >        SS7             __________                          
> > > > > > >        Link     |     |          |------|-----------       
> > > > > > >    -------------------|   SGP1   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >                                                            
> > > > > > >                 |                       |                  
> > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > >                 | SG                    | Associations     
> > > > > > >        SS7             __________                          
> > > > > > >        Link     |     |          |------|-----------       
> > > > > > >    -------------------|   SGP2   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >                                                            
> > > > > > >                 |                       |                  
> > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > >                 | SG                    | Associations     
> > > > > > >        SS7             __________                          
> > > > > > >        Link     |     |          |------|-----------       
> > > > > > >    -------------------|   SGP3   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >                                                            
> > > > > > >                 |                       |                  
> > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > >                             .                              
> > > > > > >                             .                              
> > > > > > >                             .                              
> > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > >                 | SG                    | Associations     
> > > > > > >        SS7             __________                          
> > > > > > >        Link     |     |          |------|-----------       
> > > > > > >    -------------------|   SGPn   |------------------       
> > > > > > >                 |     |__________|------|-----------       
> > > > > > >                                                            
> > > > > > >                 |                       |                  
> > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > 
> > > > > > > This is possible, however, it pretty much reduces M3UA to
M2UA.
> > > > > > > 
> > > > > > > I would rather see the SGP be provided with some 
> > > > > mechanism by way of
> > > > > > > which it can be assured that the ASPs will respond properly to
> > > > > > > partitioned SGP.
> > > > > > > 
> > > > > > > Until they do, I cannot see that M3UA can be implemented in a
> > > > > > > carrier-class arrangement with ASPs which treat the SG with a 
> > > > > > > "single management view".
> > > > > > Well, no, I think it is possible but requires a lot of
experience
> > > > > > in distributed computing (at least for the SGP vendors..). 
> > > > > > > 
> > > > > > > 
> > > > > > > --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]
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ---
> > > > > > 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]
> > > 
> > > -- 
> > > 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]
> > 
> > -- 
> > 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]
> 
> -- 
> 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]

-- 
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: Wed, 25 Jul 2001 09:27:22 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv7: SG redundancy
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Didier,

It was completely unrelated, but the MTP-User at the ASP needs to know
whether it has attempted to send a message to a DPC which it can never reach
because the SGP has not been configured with a route to that destination.
The proscribed SS7 behavior is for the SGP to silently discard the message
if it comes from one of its own MTP-Users.  There is no reason for the
MTP-User at the ASP to continue sending messages into a black hole.  It
should be informed.  Otherwise, the MTP-User may attempt to resend to that
destination periodically.

--Brian

Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
16:13:48)
> Bryan,
> Aren't they same concept?
> 
> DUNA(Global): -> Destination Unavailable Permanent Condition (No route in
> routing tables)
> DUNA(Local): -> Destination Unavailable Transient Condition (Received TFP
> for destination)
>                  -->> TFP is one of the possible SS7 event...
> 
> On ASP point of view the only thing that ASP needs is to have an efficiant
> routing...
> Why does ASP need to know that SGP receive TFP for one destination?
> 
> The only thing that ASP needs is to know that one SGP:
> * can not reach one destination (No route in routing tables).
> ->DUNA(Global).
> * can reach one destination but not directly (because this SGP receive
TFP,
> or 
>   one of its link fail or whatever else, implementation dependant).
> ->DUNA(Local)
> 
> /Didier
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 3:11 PM
> To: sigtran
> Subject: Re: M3UAv7: SG redundancy
> 
> 
> Didier,
> 
> Now that you mention different kinds of DUNA, there is another
> distrinction which needs to be made:
> 
> -> Destination Unavailable Permanent Condition (No route in routing
tables)
> -> Destination Unavailable Transient Condition (Received TFP for
> destination)
> 
> --Brian
> 
> 
> Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
> 14:51:36)
> > Brian,
> > 
> > Perhaps we need 2 levels for the DUNA (same for DAVA, DRST, SCON...):
> > 
> > -> Destination Unavailable for the SG  (-> GLOBAL, DUNA).
> > -> Destination Unavailable for the SGP (-> LOCAL, DUNA).
> > 
> > Endeed in the sample bellow... SGP2 can send a DUNA(LOCAL)... So the
> > destination
> > is still accessible by SGP2 but it is not the more "efficiant way" to
send
> 
> > the message.
> > 
> > /Didier
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, July 25, 2001 2:28 PM
> > To: sigtran
> > Subject: Re: M3UAv7: SG redundancy
> > 
> > 
> > Didier,
> > 
> > Yes, it would send DUNAs iff it was a permitted way of
> > getting the ASP to stop traffic to the SGP.
> > 
> > These examples show the need for SGP management.  If
> > not DUNAs then something else...
> > 
> > --Brian
> > 
> > Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
> > 14:17:20)
> > > Brian,
> > > Thanks for your answer and sorry to insist but in your diagram,
> > > does SGP2 send (or not) the DUNAs? 
> > > and if no, 
> > > you have only one "single management point of view" of ss7
destinations
> > per
> > > SG
> > > that change a lot of things...
> > > 
> > > /Didier
> > > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, July 25, 2001 1:50 PM
> > > To: sigtran
> > > Subject: Re: M3UAv7: SG redundancy
> > > 
> > > 
> > > Didier,
> > > 
> > > I have answered this before, but, again: If I can modify your
> > > diagram sligtly:
> > >   
> > >                           SG
> > >                + - - - - - - - - - - - +
> > >        SS7     |Switch                 |
> > >       Links       |   __________            SCTP
> > >    ------------|--|  |          |      | Associations   __________
> > >    ------------ --|--|   SGP1   |-X-X-X-X-X-X-X-X-X-X--|          |
> > >    ------------|--|  |__________|      |               |   ASP    |
> > >                   |   __________                  +----|__________|
> > >    -X-X-X-X-X--|--|  |          |      |          |
> > >    -X-X-X-X-X-- --|--|   SGP2   |-----------------+
> > >    -X-X-X-X-X--|--|  |__________|      |
> > >                   |
> > >                |                       |
> > >                + - - - - - - - - - - - +
> > >   
> > > If there is another degree of freedom between the SGP
> > > and the SS7 Links (H.100 bus, M2UA) then in your scenario
> > > I would have SGP2 take over the SS7 links from SGP1.
> > > There is still no need to route user level traffic
> > > between SGP.  Depending on the architecture, it might
> > > be too drastic a measure off the start.
> > > 
> > > --Brian
> > > 
> > > 
> > > > 2/ all destinations in SGP1 are UP.
> > > > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for
> all
> > > > destinations...
> > > > 3/ The SCTP asso SGP1-ASP just falling.
> > > 
> > > Desiderio, Didier wrote:                               (Wed, 25 Jul
2001
> > > 13:38:22)
> > > > Brian,
> > > > Can you explain that, consider the following :
> > > > 
> > > > 1/ SGP in the same SG do not have a "single management point of
view"
> > that
> > > > is
> > > > to say they are sharing the same ss7 destinations but each SGP has
its
> > own
> > > 
> > > > management view...
> > > > 
> > > >                         SG
> > > >              + - - - - - - - - - - - +
> > > >      SS7     |                       |
> > > >     Links           __________            SCTP
> > > >  ------------|     |          |      | Associations   __________
> > > >  ------------      |   SGP1   |----------------------|          |
> > > >  ------------|     |__________|      |               |   ASP    |
> > > >                     __________                  +----|__________|
> > > >  ------------|     |          |      |          |
> > > >  ------------      |   SGP2   |-----------------+
> > > >  ------------|     |__________|      |
> > > > 
> > > >              |                       |
> > > >              + - - - - - - - - - - - +
> > > > 
> > > > 2/ all destinations in SGP1 are UP.
> > > > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for
> all
> > > > destinations...
> > > > 3/ The SCTP asso SGP1-ASP just falling.
> > > > 4/ ASP has to send data to one destination and this SG is the
priority
> > > > route.
> > > > 
> > > > Does the ASP not send this data? 
> > > > Does the ASP choose another SG to send this DATA?
> > > > >> even if the destination is not considered as DOWN from SS7 point
of
> > > view
> > > > and
> > > >    this SG is the priority route!!!!
> > > > 
> > > > And is it aceptable on the M3UA point of view?
> > > > 
> > > > /Didier
> > > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Wednesday, July 25, 2001 12:09 PM
> > > > To: sigtran
> > > > Subject: Re: M3UAv7: SG redundancy
> > > > 
> > > > 
> > > > Pierre,
> > > > 
> > > > Please see more comments below...
> > > > 
> > > > Garnero, Pierre wrote:                    (Wed, 25 Jul 2001
11:43:56)
> > > > > Brian,
> > > > > 
> > > > > just some comments below:
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Wednesday, July 25, 2001 11:20 AM
> > > > > > To: sigtran
> > > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > > 
> > > > > > 
> > > > > > Pierre,
> > > > > > 
> > > > > > Please see comments below...
> > > > > > 
> > > > > > Garnero, Pierre wrote:                                   
> > > > > > (Wed, 25 Jul 2001 10:33:34)
> > > > > > > Hello Hong,
> > > > > > > 
> > > > > > > please find another point of view, included in Brians
> comments...
> > > > > > > 
> > > > > > > Cheers,
> > > > > > > 
> > > > > > > PiG
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > Sent: Wednesday, July 25, 2001 8:28 AM
> > > > > > > > To: sigtran
> > > > > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hong,
> > > > > > > > 
> > > > > > > > You bring up some good questions.
> > > > > > > > 
> > > > > > > > Hong Liu wrote:                              (Wed, 25 Jul 
> > > > > > > > 2001 08:08:07)
> > > > > > > > > Hi, Brian,
> > > > > > > > > 
> > > > > > > > > I am also confused by the notion of SG vs. SGP in the 
> > > > > > > > current M3UA spec.
> > > > > > > > > Maybe you can help me to understand the concepts better. I

> > > > > > > > noticed that
> > > > > > > > > there was a long thread of discussions on the list a few 
> > > > > > > > months ago on
> > > > > > > > > this topic. So I apologize in advance if I bring up 
> > > > > > > > something that has
> > > > > > > > > already been clarified.
> > > > > > > > > 
> > > > > > > > > According to the current spec, an SG is a logical 
> > > > > > entity if it is
> > > > > > > > > composed of more than one SGP. From the SS7 network point 
> > > > > > > > of view, SG is
> > > > > > > > > the one that acts as an SS7 signaling point and is thus 
> > > > > > > > assigned a point
> > > > > > > > > code. Does it imply that all the SGPs of an SG will bear 
> > > > > > > > the same point
> > > > > > > > > code even if they are geographically separated? Is that 
> > > > > > > > what it means in
> > > > > > > > > the spec regarding a single management view to the SS7
> > network?
> > > > > > > > > 
> > > > > > > > > On the IP side, is it required that an ASP set up an M3UA 
> > > > > > > > association
> > > > > > > > > with each of the active SGPs? Or in other words, is it 
> > > > > > > > allowed by the
> > > > > > > > > spec that an ASP only sets up M3UA associations to a 
> > > > > > > > (non-empty) subset
> > > > > > > > > of the active SGPs?
> > > > > > > > > 
> > > > > > > > > Cheers,
> > > > > > > > > 
> > > > > > > > > --Hong
> > > > > > > > > 
> > > > > > > > [snip]
> > > > > > > > 
> > > > > > > > I believe that there are several points in the draft 
> > > > > > which lead to a
> > > > > > > > definition of an SG.  These are:
> > > > > > > > 
> > > > > > > >    o   An SGP is a unique transport (SCTP) endpoint.
> > > > > > > > 
> > > > > > > >    o   An SG is a collection or set of one or more SGPs.
> > > > > > > > 
> > > > > > > >    o   An SG terminates SS7 signalling links from the SS7
> > network.
> > > > > > > > 
> > > > > > > >    o   An SG has one set of Routing Keys which are shared 
> > > > > > by all the
> > > > > > > >        SGPs which make up the SG.
> > > > > > > > 
> > > > > > > >    o   Each SGP in an SG offers identical connectivity to
the
> > SS7
> > > > > > > >        network.
> > > > > > > > 
> > > > > > > > There are no restrictions placed on what point codes an SG 
> > > > > > > > does or does
> > > > > > > > not represent.  There are no restrictions placed on how many

> > > > > > > > SGP a Host
> > > > > > > > represents.  There are no restrictions in terms of the 
> > > > > > geographical
> > > > > > > > positioning of SGP within an SG.
> > > > > > > > 
> > > > > > > 
> > > > > > > The draft stats: "An SG appears to the SS7 network as an 
> > > > > > SS7 Signalling 
> > > > > > > Point". 
> > > > > > > So, for a specific SS7 network, an SG has a unique point code.
> > > > > > 
> > > > > > An SG appears to the SS7 network as having a point code,
> > > > > > but it doen't have to have one of its own.  This was clearly
> > > > > > intended in the draft from the start: that the SG can just
> > > > > > represent the SPMC point code which "belongs" to the ASPs.
> > > > > > If the SG has a point code separate from the ASP, then it
> > > > > > would have to be an STP.  That is not required by the spec.
> > > > > > 
> > > > > Yes, an SG has a point code from the SS7 point of view ...
> > > > > We are in sync here !!! :-)
> > > > 
> > > > No we are not in sync.  The SG "represents" one or more point
> > > > codes to the SS7 network.  It does not necessarily "have" one.
> > > > I though that the draft made this crystal clear.  The SG may
> > > > or may not have local MTP-Users.  If it has no local MTP-Users
> > > > and is not equipped with the transfer function, then it does
> > > > not "have" a point code.
> > > > 
> > > > > > > 
> > > > > > > > When your consider these points, an SG, in principle, 
> > > > > > looks like the
> > > > > > > > following:
> > > > > > > > 
> > > > > > > >                                                            
> > > > > > > >                            SG                              
> > > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > > >                 |                       | Associations     
> > > > > > > >                        __________                          
> > > > > > > >                 |     |          |------|-----------       
> > > > > > > >                       |   SGP1   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >         SS7            __________                          
> > > > > > > >        Links    |     |          |------|-----------       
> > > > > > > >     ------------      |   SGP2   |------------------       
> > > > > > > >     ------------|     |__________|------|-----------       
> > > > > > > >     ------------       __________                       To 
> > > > > > > >     ------------|     |          |------|-----------   ASPs
> > > > > > > >     ------------      |   SGP3   |------------------       
> > > > > > > >     ------------|     |__________|------|-----------       
> > > > > > > >     ------------       __________                          
> > > > > > > >     ------------|     |          |------|-----------       
> > > > > > > >     ------------      |   SGP4   |------------------       
> > > > > > > >     ------------|     |__________|------|-----------       
> > > > > > > >     ------------                                           
> > > > > > > >                 |           .           |                  
> > > > > > > >                             .                              
> > > > > > > >                 |           .           |                  
> > > > > > > >                        __________                          
> > > > > > > >                 |     |          |------|-----------       
> > > > > > > >                       |   SGPn   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >                                                            
> > > > > > > >                 |                       |                  
> > > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > > 
> > > > > > > > Where the argument, errr.., discussion errupts centers
around
> > the
> > > > > > > > restriction that all SGP in an SG must have identical
> > connectivity
> > > > > > > > to the SS7 network and SHOULD be able to transfer traffic
> > between
> > > > > > > > them to accomplish that feat.
> > > > > > > > 
> > > > > > > > My position is that, while in principle this sounds good, in

> > > > > > > > practice it
> > > > > > > > does not:
> > > > > > > > 
> > > > > > > 
> > > > > > > My position is the opposite... :-)
> > > > > > 
> > > > > > Uhmm.
> > > > > > 
> > > > > > > 
> > > > > > > > On of the purposes of allowing multple SGP is to allow 
> > > > > > the SG to be a
> > > > > > > > collection of multiple hosts for redudancy and scaling.  
> > > > > > > > Unfortunately,
> > > > > > > > when SGPs are multiple hosts, the possibility of a 
> > > > > > "partitioned" SG
> > > > > > > > due to internal failures is possible.  That could look like
> > this:
> > > > > > > > 
> > > > > > > >                                                            
> > > > > > > >                            SG                              
> > > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > > >                 |                       | Associations     
> > > > > > > >                        __________                          
> > > > > > > >                 |     |          |------|-----------       
> > > > > > > >                       |   SGP1   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >         SS7            __________                          
> > > > > > > >        Links    |     |          |------|-----------       
> > > > > > > >     ------------      |   SGP2   |------------------       
> > > > > > > >     ------------|     |__________|------|-----------       
> > > > > > > >    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
> > > > > > > >     ------------       __________                       To 
> > > > > > > >     ------------|     |          |------|-----------   ASPs
> > > > > > > >     ------------      |   SGP3   |------------------       
> > > > > > > >     ------------|     |__________|------|-----------       
> > > > > > > >     ------------       __________                          
> > > > > > > >     ------------|     |          |------|-----------       
> > > > > > > >     ------------      |   SGP4   |------------------       
> > > > > > > >     ------------|     |__________|------|-----------       
> > > > > > > >     ------------                                           
> > > > > > > >                 |           .           |                  
> > > > > > > >                             .                              
> > > > > > > >                 |           .           |                  
> > > > > > > >                        __________                          
> > > > > > > >                 |     |          |------|-----------       
> > > > > > > >                       |   SGPn   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >                                                            
> > > > > > > >                 |                       |                  
> > > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > > 
> > > > > > > > In some of the above "partitioned" scenarios, the SGPs 
> > > > > > need to be able
> > > > > > > > to tell the ASPs that they can no longer service specific 
> > > > > > > > traffic flows
> > > > > > > > towards the SS7 newtork.  In the current draft this can be 
> > > > > > > > accomplished
> > > > > > > > in two ways, both which are problematic.
> > > > > > > > 
> > > > > > > >   1.  The SGP can use DUNA, DAVA, and DRST independently
from 
> > > > > > > > each of the
> > > > > > > >       SGP to indicate the difference in availability of 
> > > > > > > > routesets to the
> > > > > > > >       SS7 newtork above the partition and below the 
> > > > > > partition in the
> > > > > > > >       diagram.
> > > > > > > > 
> > > > > > > >       With the way that keeping DUNA, DAVA, DRST and SCON 
> > > > > > on a per-SGP
> > > > > > > >       basis at the ASP has been "watered down", however, in 
> > > > > > > > the M3UA-08
> > > > > > > >       draft, the SG cannot be guaranteed that the ASPs 
> > > > > > will respond
> > > > > > > >       properly to these partitioned indications.  If the 
> > > > > > ASPs respond
> > > > > > > >       under the "single management view", as is their 
> > > > > > option in the
> > > > > > > >       latest draft, this case will reduce to case (2) below.
> > > > > > > > 
> > > > > > > >   2.  The SGP drop their associations to the ASPs.  That is,

> > > > > > > > The entire
> > > > > > > >       SG goes off-line.
> > > > > > > > 
> > > > > > > This is true but this is only 1 part of the problem.
> > > > > > > A partionned SG means also multiple PC with the same Id on 
> > > > > > the same SS7
> > > > > > > network.
> > > > > > 
> > > > > > It is the case in the SS7 network that we assign one point code
> > > > > > to two STPs (alias point code for GTT).  It does not cause
> problems
> > > > > > in the SS7 network.
> > > > > > 
> > > > > > > And this last problem is not solved by M3UA.
> > > > > > 
> > > > > > But could easily.
> > > > > I suppose that here we disagree on the level of quality the SG
must
> > > > provide.
> > > > > And I think that this level will not be determined by you or me
but
> by
> > > the
> > > > 
> > > > > future users of M3UA.
> > > > > My position is that an SS7 platform (SG) partition does not work
> > because
> > > > > it could loose SS7 messages (1 or 1000 it cannot be acceptable,
for
> > me).
> > > > > M3UA cannot do anything here, it is a pure SS7 problem.
> > > > > > 
> > > > > > > Well, such a problem is mitigated by some particular SS7 
> > > > > > configurations, 
> > > > > > > for instance, when SGPs are connected to one and only one
> > adjacent,
> > > > > > > but in this case, the configuration don't take advantage of
the
> > SS7
> > > > > > > redundancy:
> > > > > > > if one SGP fails, an entire route is lost...
> > > > > > > So, I think that inter SGP communications must be designed 
> > > > > > by SG vendors
> > > > > > > and not by M3UA.
> > > > > > > I really think that SG vendors could be creative in this 
> > > > > > domain and provide
> > > > > > > an inter SGP communication mechanism very reliable, or even 
> > > > > > provide a 
> > > > > > > mechanism (may be with another LAN dedicated to this 
> > > > > > purpose) to "detect"
> > > > > > > SG platform partition... and avoid, even when using "single 
> > > > > > management
> > > > > > > view",
> > > > > > > to drop all the SGP associations to the ASPs. 
> > > > > > 
> > > > > > All this cost for guaranteed inter-SGP communication is not
> > necessary.
> > > > > Well, does everybody in this mailing list agree on this comment ?
> > > > > > With just a little support from M3UA, the platform could run
fully
> > > > > > partitioned and happy.  Detailed discussion of this was provided
> on
> > > > > > other threads.  Aside from low volume changeover messages and
> > routing
> > > > > > messages there should never be a need to route user level 
> > > > > > traffic between
> > > > > > SGP.  A patition in that case only causes minor message loss
> during
> > > > > > changeovers and is acceptable because the probability of
> > partitioning
> > > > > > failure coupled with the probability of changeover can be 
> > > > > > engineered to
> > > > > > meet message lost requirements quite economically.
> > > > > What means carrier-grade then ? 
> > > > > Anyway, I think that truth here depends on the quality level the
> final
> > > > > user wants ... and each future user will have its own definition
of
> > > > > "carrier-grade" level.
> > > > 
> > > > Don't be ridiculous.  The arrangement only loses messages when
> > > > failures occur.  This is permitted.  Just as long as the failure
> > > > rate is controlled to within those bounds which are acceptable by
> > > > the message loss requirements of MTP.
> > > > 
> > > > Compare this to how may messages your fancy inter-SGP arrangement
> > > > is going to lose when (not "if") it partitions.
> > > > 
> > > > > > 
> > > > > > I have handled the problem, it just needs minor support from
M3UA.
> > > > > > 
> > > > > On the IP side, may be. Not on the SS7 side (IMHO).
> > > > 
> > > > M3UA is not responsible for the SS7 side, the SG implementation
> > > > is.  M3UA need only provide the mechanisms reqruired by the SG
> > > > to perform its function.  I do not have to prove to _you_ that
> > > > the SS7 side works.
> > > > 
> > > > I am not shutting off my customer's $1M/hr cash flow just to
> > > > satisfy a "MAY" in the spec.
> > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > There is only one arrangement of SG/SGP in my mind that 
> > > > > > can keep this
> > > > > > > > from happening:  Make every SG consist of only one SGP, 
> > > > > > and have each
> > > > > > > > SG support only one SS7 link, like this:
> > > > > > > > 
> > > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > > >                 | SG                    | Associations     
> > > > > > > >        SS7             __________                          
> > > > > > > >        Link     |     |          |------|-----------       
> > > > > > > >    -------------------|   SGP1   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >                                                            
> > > > > > > >                 |                       |                  
> > > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > > >                 | SG                    | Associations     
> > > > > > > >        SS7             __________                          
> > > > > > > >        Link     |     |          |------|-----------       
> > > > > > > >    -------------------|   SGP2   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >                                                            
> > > > > > > >                 |                       |                  
> > > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > > >                 | SG                    | Associations     
> > > > > > > >        SS7             __________                          
> > > > > > > >        Link     |     |          |------|-----------       
> > > > > > > >    -------------------|   SGP3   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >                                                            
> > > > > > > >                 |                       |                  
> > > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > >                             .                              
> > > > > > > >                             .                              
> > > > > > > >                             .                              
> > > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > > >                 | SG                    | Associations     
> > > > > > > >        SS7             __________                          
> > > > > > > >        Link     |     |          |------|-----------       
> > > > > > > >    -------------------|   SGPn   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >                                                            
> > > > > > > >                 |                       |                  
> > > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > > 
> > > > > > > > This is possible, however, it pretty much reduces M3UA to
> M2UA.
> > > > > > > > 
> > > > > > > > I would rather see the SGP be provided with some 
> > > > > > mechanism by way of
> > > > > > > > which it can be assured that the ASPs will respond properly
to
> > > > > > > > partitioned SGP.
> > > > > > > > 
> > > > > > > > Until they do, I cannot see that M3UA can be implemented in
a
> > > > > > > > carrier-class arrangement with ASPs which treat the SG with
a 
> > > > > > > > "single management view".
> > > > > > > Well, no, I think it is possible but requires a lot of
> experience
> > > > > > > in distributed computing (at least for the SGP vendors..). 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > --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]
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ---
> > > > > > > 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]
> > > > 
> > > > -- 
> > > > 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]
> > > 
> > > -- 
> > > 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]
> > 
> > -- 
> > 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]
> 
> -- 
> 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]

-- 
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, 25 Jul 2001 10:24:00 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: m3ua status
X-SMTP-HELO: netmail2.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail2.alcatel.com [128.251.168.51]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Lyndon,

I understand that other organizations want to use M3UA and are anxious to
have something firm that they can use.  They are also waiting on resolution
of SCTP (last I checked).  I think we need to address their concerns, BUT, I
think we also need to put out a standard that will be interpretted in just
one way.  I would think that those organizations wanting a standard would
prefer one without so many unresolved issues (and no, I didn't make a list).

There are so many threads on M3UA regarding different interpretations that
it is difficult keep up with them.  All the conversation is good with
respect to working the issues, but how can we call M3UA ready for last call
with so many issues?

Jeff

Lyndon Ong wrote:
> 
> Folks,
> 
> There continue to be numerous comments on M3UA v7, at the same time I have
been getting messages from people or groups who are interested in using M3UA
for their protocols and would like very much to have it completed.  In other
words, we really need to get this finalized, so we should be focusing on
actual errors, and pushing new functions or fine points into extension
drafts.  Otherwise we may end up losing our "customers".
> 
> This being the case, can I poll the group to see if there are objections
to moving M3UA v7 to IESG review/IETF Last Call?  Keep in mind that during
IETF Last Call, you will have another opportunity to comment.
> 
> 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] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\Jeff.Copley9.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 25 Jul 2001 17:27:28 +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], [email-masked], 
    [email-masked]
Subject: Re: comments on <draft-ietf-sigtran-sctp-mib-04.txt>
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]>
List-Unsubscribe: <mailto:[email-masked]>

Hi John,

See some small comments embedded (with a [MIB] mark). All of the bullets not
commented have been included in version 05. Some rewording issues have not
been considered since they were changed previously, agreed by the WG,

thanks a lot for your comments,
Javier&MCarmen

John Linton wrote:

> 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

[MIB] The table showed is just an example, it's not worthy to write down all
the lookup tables to see how they works, and it will increase the document
with no advantages.

>
>
> 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)."

[MIB] Take into account that the receiver doesn't know about retransmission
but about duplications. This applies to all related comments.

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

[MIB] It refers to DATA chunks.

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

[MIB] These tables were requested in a editing session by the IESG. Also,
they will help some other people to collect information.

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

Attachment Converted: "c:\program files\qualcomm\eudora
pro\attach\emecbv4.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 25 Jul 2001 17:31:46 +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], [email-masked]
Subject: Re: comment on <draft-ietf-sigtran-sctp-mib-04.txt>
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]>
List-Unsubscribe: <mailto:[email-masked]>

Hi Kusum,

    Actually there is no local primary address concept in SCTP.

regards,
Javier&MCarmen

kusum wrote:

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

Attachment Converted: "c:\program files\qualcomm\eudora
pro\attach\emecbv5.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Desiderio, Didier" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv7: SG redundancy
Date: Wed, 25 Jul 2001 18:01:47 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zmamail04.zma.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zmamail04.zma.compaq.com [161.114.64.104]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,
I'm 100% ok with you, I don't catch it this way...
/Didier

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Wednesday,
July 25, 2001 4:27 PM
To: sigtran
Subject: Re: M3UAv7: SG redundancy

Didier,

It was completely unrelated, but the MTP-User at the ASP needs to know
whether it has attempted to send a message to a DPC which it can never reach
because the SGP has not been configured with a route to that destination.
The proscribed SS7 behavior is for the SGP to silently discard the message
if it comes from one of its own MTP-Users.  There is no reason for the
MTP-User at the ASP to continue sending messages into a black hole.  It
should be informed.  Otherwise, the MTP-User may attempt to resend to that
destination periodically.

--Brian

Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
16:13:48)
> Bryan,
> Aren't they same concept?
> 
> DUNA(Global): -> Destination Unavailable Permanent Condition (No route in
> routing tables)
> DUNA(Local): -> Destination Unavailable Transient Condition (Received TFP
> for destination)
>                  -->> TFP is one of the possible SS7 event...
> 
> On ASP point of view the only thing that ASP needs is to have an efficiant
> routing...
> Why does ASP need to know that SGP receive TFP for one destination?
> 
> The only thing that ASP needs is to know that one SGP:
> * can not reach one destination (No route in routing tables).
> ->DUNA(Global).
> * can reach one destination but not directly (because this SGP receive
TFP,
> or 
>   one of its link fail or whatever else, implementation dependant).
> ->DUNA(Local)
> 
> /Didier
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 3:11 PM
> To: sigtran
> Subject: Re: M3UAv7: SG redundancy
> 
> 
> Didier,
> 
> Now that you mention different kinds of DUNA, there is another
> distrinction which needs to be made:
> 
> -> Destination Unavailable Permanent Condition (No route in routing
tables)
> -> Destination Unavailable Transient Condition (Received TFP for
> destination)
> 
> --Brian
> 
> 
> Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
> 14:51:36)
> > Brian,
> > 
> > Perhaps we need 2 levels for the DUNA (same for DAVA, DRST, SCON...):
> > 
> > -> Destination Unavailable for the SG  (-> GLOBAL, DUNA).
> > -> Destination Unavailable for the SGP (-> LOCAL, DUNA).
> > 
> > Endeed in the sample bellow... SGP2 can send a DUNA(LOCAL)... So the
> > destination
> > is still accessible by SGP2 but it is not the more "efficiant way" to
send
> 
> > the message.
> > 
> > /Didier
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, July 25, 2001 2:28 PM
> > To: sigtran
> > Subject: Re: M3UAv7: SG redundancy
> > 
> > 
> > Didier,
> > 
> > Yes, it would send DUNAs iff it was a permitted way of
> > getting the ASP to stop traffic to the SGP.
> > 
> > These examples show the need for SGP management.  If
> > not DUNAs then something else...
> > 
> > --Brian
> > 
> > Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
> > 14:17:20)
> > > Brian,
> > > Thanks for your answer and sorry to insist but in your diagram,
> > > does SGP2 send (or not) the DUNAs? 
> > > and if no, 
> > > you have only one "single management point of view" of ss7
destinations
> > per
> > > SG
> > > that change a lot of things...
> > > 
> > > /Didier
> > > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, July 25, 2001 1:50 PM
> > > To: sigtran
> > > Subject: Re: M3UAv7: SG redundancy
> > > 
> > > 
> > > Didier,
> > > 
> > > I have answered this before, but, again: If I can modify your
> > > diagram sligtly:
> > >   
> > >                           SG
> > >                + - - - - - - - - - - - +
> > >        SS7     |Switch                 |
> > >       Links       |   __________            SCTP
> > >    ------------|--|  |          |      | Associations   __________
> > >    ------------ --|--|   SGP1   |-X-X-X-X-X-X-X-X-X-X--|          |
> > >    ------------|--|  |__________|      |               |   ASP    |
> > >                   |   __________                  +----|__________|
> > >    -X-X-X-X-X--|--|  |          |      |          |
> > >    -X-X-X-X-X-- --|--|   SGP2   |-----------------+
> > >    -X-X-X-X-X--|--|  |__________|      |
> > >                   |
> > >                |                       |
> > >                + - - - - - - - - - - - +
> > >   
> > > If there is another degree of freedom between the SGP
> > > and the SS7 Links (H.100 bus, M2UA) then in your scenario
> > > I would have SGP2 take over the SS7 links from SGP1.
> > > There is still no need to route user level traffic
> > > between SGP.  Depending on the architecture, it might
> > > be too drastic a measure off the start.
> > > 
> > > --Brian
> > > 
> > > 
> > > > 2/ all destinations in SGP1 are UP.
> > > > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for
> all
> > > > destinations...
> > > > 3/ The SCTP asso SGP1-ASP just falling.
> > > 
> > > Desiderio, Didier wrote:                               (Wed, 25 Jul
2001
> > > 13:38:22)
> > > > Brian,
> > > > Can you explain that, consider the following :
> > > > 
> > > > 1/ SGP in the same SG do not have a "single management point of
view"
> > that
> > > > is
> > > > to say they are sharing the same ss7 destinations but each SGP has
its
> > own
> > > 
> > > > management view...
> > > > 
> > > >                         SG
> > > >              + - - - - - - - - - - - +
> > > >      SS7     |                       |
> > > >     Links           __________            SCTP
> > > >  ------------|     |          |      | Associations   __________
> > > >  ------------      |   SGP1   |----------------------|          |
> > > >  ------------|     |__________|      |               |   ASP    |
> > > >                     __________                  +----|__________|
> > > >  ------------|     |          |      |          |
> > > >  ------------      |   SGP2   |-----------------+
> > > >  ------------|     |__________|      |
> > > > 
> > > >              |                       |
> > > >              + - - - - - - - - - - - +
> > > > 
> > > > 2/ all destinations in SGP1 are UP.
> > > > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP for
> all
> > > > destinations...
> > > > 3/ The SCTP asso SGP1-ASP just falling.
> > > > 4/ ASP has to send data to one destination and this SG is the
priority
> > > > route.
> > > > 
> > > > Does the ASP not send this data? 
> > > > Does the ASP choose another SG to send this DATA?
> > > > >> even if the destination is not considered as DOWN from SS7 point
of
> > > view
> > > > and
> > > >    this SG is the priority route!!!!
> > > > 
> > > > And is it aceptable on the M3UA point of view?
> > > > 
> > > > /Didier
> > > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Wednesday, July 25, 2001 12:09 PM
> > > > To: sigtran
> > > > Subject: Re: M3UAv7: SG redundancy
> > > > 
> > > > 
> > > > Pierre,
> > > > 
> > > > Please see more comments below...
> > > > 
> > > > Garnero, Pierre wrote:                    (Wed, 25 Jul 2001
11:43:56)
> > > > > Brian,
> > > > > 
> > > > > just some comments below:
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Wednesday, July 25, 2001 11:20 AM
> > > > > > To: sigtran
> > > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > > 
> > > > > > 
> > > > > > Pierre,
> > > > > > 
> > > > > > Please see comments below...
> > > > > > 
> > > > > > Garnero, Pierre wrote:                                   
> > > > > > (Wed, 25 Jul 2001 10:33:34)
> > > > > > > Hello Hong,
> > > > > > > 
> > > > > > > please find another point of view, included in Brians
> comments...
> > > > > > > 
> > > > > > > Cheers,
> > > > > > > 
> > > > > > > PiG
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > Sent: Wednesday, July 25, 2001 8:28 AM
> > > > > > > > To: sigtran
> > > > > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hong,
> > > > > > > > 
> > > > > > > > You bring up some good questions.
> > > > > > > > 
> > > > > > > > Hong Liu wrote:                              (Wed, 25 Jul 
> > > > > > > > 2001 08:08:07)
> > > > > > > > > Hi, Brian,
> > > > > > > > > 
> > > > > > > > > I am also confused by the notion of SG vs. SGP in the 
> > > > > > > > current M3UA spec.
> > > > > > > > > Maybe you can help me to understand the concepts better. I

> > > > > > > > noticed that
> > > > > > > > > there was a long thread of discussions on the list a few 
> > > > > > > > months ago on
> > > > > > > > > this topic. So I apologize in advance if I bring up 
> > > > > > > > something that has
> > > > > > > > > already been clarified.
> > > > > > > > > 
> > > > > > > > > According to the current spec, an SG is a logical 
> > > > > > entity if it is
> > > > > > > > > composed of more than one SGP. From the SS7 network point 
> > > > > > > > of view, SG is
> > > > > > > > > the one that acts as an SS7 signaling point and is thus 
> > > > > > > > assigned a point
> > > > > > > > > code. Does it imply that all the SGPs of an SG will bear 
> > > > > > > > the same point
> > > > > > > > > code even if they are geographically separated? Is that 
> > > > > > > > what it means in
> > > > > > > > > the spec regarding a single management view to the SS7
> > network?
> > > > > > > > > 
> > > > > > > > > On the IP side, is it required that an ASP set up an M3UA 
> > > > > > > > association
> > > > > > > > > with each of the active SGPs? Or in other words, is it 
> > > > > > > > allowed by the
> > > > > > > > > spec that an ASP only sets up M3UA associations to a 
> > > > > > > > (non-empty) subset
> > > > > > > > > of the active SGPs?
> > > > > > > > > 
> > > > > > > > > Cheers,
> > > > > > > > > 
> > > > > > > > > --Hong
> > > > > > > > > 
> > > > > > > > [snip]
> > > > > > > > 
> > > > > > > > I believe that there are several points in the draft 
> > > > > > which lead to a
> > > > > > > > definition of an SG.  These are:
> > > > > > > > 
> > > > > > > >    o   An SGP is a unique transport (SCTP) endpoint.
> > > > > > > > 
> > > > > > > >    o   An SG is a collection or set of one or more SGPs.
> > > > > > > > 
> > > > > > > >    o   An SG terminates SS7 signalling links from the SS7
> > network.
> > > > > > > > 
> > > > > > > >    o   An SG has one set of Routing Keys which are shared 
> > > > > > by all the
> > > > > > > >        SGPs which make up the SG.
> > > > > > > > 
> > > > > > > >    o   Each SGP in an SG offers identical connectivity to
the
> > SS7
> > > > > > > >        network.
> > > > > > > > 
> > > > > > > > There are no restrictions placed on what point codes an SG 
> > > > > > > > does or does
> > > > > > > > not represent.  There are no restrictions placed on how many

> > > > > > > > SGP a Host
> > > > > > > > represents.  There are no restrictions in terms of the 
> > > > > > geographical
> > > > > > > > positioning of SGP within an SG.
> > > > > > > > 
> > > > > > > 
> > > > > > > The draft stats: "An SG appears to the SS7 network as an 
> > > > > > SS7 Signalling 
> > > > > > > Point". 
> > > > > > > So, for a specific SS7 network, an SG has a unique point code.
> > > > > > 
> > > > > > An SG appears to the SS7 network as having a point code,
> > > > > > but it doen't have to have one of its own.  This was clearly
> > > > > > intended in the draft from the start: that the SG can just
> > > > > > represent the SPMC point code which "belongs" to the ASPs.
> > > > > > If the SG has a point code separate from the ASP, then it
> > > > > > would have to be an STP.  That is not required by the spec.
> > > > > > 
> > > > > Yes, an SG has a point code from the SS7 point of view ...
> > > > > We are in sync here !!! :-)
> > > > 
> > > > No we are not in sync.  The SG "represents" one or more point
> > > > codes to the SS7 network.  It does not necessarily "have" one.
> > > > I though that the draft made this crystal clear.  The SG may
> > > > or may not have local MTP-Users.  If it has no local MTP-Users
> > > > and is not equipped with the transfer function, then it does
> > > > not "have" a point code.
> > > > 
> > > > > > > 
> > > > > > > > When your consider these points, an SG, in principle, 
> > > > > > looks like the
> > > > > > > > following:
> > > > > > > > 
> > > > > > > >                                                            
> > > > > > > >                            SG                              
> > > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > > >                 |                       | Associations     
> > > > > > > >                        __________                          
> > > > > > > >                 |     |          |------|-----------       
> > > > > > > >                       |   SGP1   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >         SS7            __________                          
> > > > > > > >        Links    |     |          |------|-----------       
> > > > > > > >     ------------      |   SGP2   |------------------       
> > > > > > > >     ------------|     |__________|------|-----------       
> > > > > > > >     ------------       __________                       To 
> > > > > > > >     ------------|     |          |------|-----------   ASPs
> > > > > > > >     ------------      |   SGP3   |------------------       
> > > > > > > >     ------------|     |__________|------|-----------       
> > > > > > > >     ------------       __________                          
> > > > > > > >     ------------|     |          |------|-----------       
> > > > > > > >     ------------      |   SGP4   |------------------       
> > > > > > > >     ------------|     |__________|------|-----------       
> > > > > > > >     ------------                                           
> > > > > > > >                 |           .           |                  
> > > > > > > >                             .                              
> > > > > > > >                 |           .           |                  
> > > > > > > >                        __________                          
> > > > > > > >                 |     |          |------|-----------       
> > > > > > > >                       |   SGPn   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >                                                            
> > > > > > > >                 |                       |                  
> > > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > > 
> > > > > > > > Where the argument, errr.., discussion errupts centers
around
> > the
> > > > > > > > restriction that all SGP in an SG must have identical
> > connectivity
> > > > > > > > to the SS7 network and SHOULD be able to transfer traffic
> > between
> > > > > > > > them to accomplish that feat.
> > > > > > > > 
> > > > > > > > My position is that, while in principle this sounds good, in

> > > > > > > > practice it
> > > > > > > > does not:
> > > > > > > > 
> > > > > > > 
> > > > > > > My position is the opposite... :-)
> > > > > > 
> > > > > > Uhmm.
> > > > > > 
> > > > > > > 
> > > > > > > > On of the purposes of allowing multple SGP is to allow 
> > > > > > the SG to be a
> > > > > > > > collection of multiple hosts for redudancy and scaling.  
> > > > > > > > Unfortunately,
> > > > > > > > when SGPs are multiple hosts, the possibility of a 
> > > > > > "partitioned" SG
> > > > > > > > due to internal failures is possible.  That could look like
> > this:
> > > > > > > > 
> > > > > > > >                                                            
> > > > > > > >                            SG                              
> > > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > > >                 |                       | Associations     
> > > > > > > >                        __________                          
> > > > > > > >                 |     |          |------|-----------       
> > > > > > > >                       |   SGP1   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >         SS7            __________                          
> > > > > > > >        Links    |     |          |------|-----------       
> > > > > > > >     ------------      |   SGP2   |------------------       
> > > > > > > >     ------------|     |__________|------|-----------       
> > > > > > > >    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
> > > > > > > >     ------------       __________                       To 
> > > > > > > >     ------------|     |          |------|-----------   ASPs
> > > > > > > >     ------------      |   SGP3   |------------------       
> > > > > > > >     ------------|     |__________|------|-----------       
> > > > > > > >     ------------       __________                          
> > > > > > > >     ------------|     |          |------|-----------       
> > > > > > > >     ------------      |   SGP4   |------------------       
> > > > > > > >     ------------|     |__________|------|-----------       
> > > > > > > >     ------------                                           
> > > > > > > >                 |           .           |                  
> > > > > > > >                             .                              
> > > > > > > >                 |           .           |                  
> > > > > > > >                        __________                          
> > > > > > > >                 |     |          |------|-----------       
> > > > > > > >                       |   SGPn   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >                                                            
> > > > > > > >                 |                       |                  
> > > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > > 
> > > > > > > > In some of the above "partitioned" scenarios, the SGPs 
> > > > > > need to be able
> > > > > > > > to tell the ASPs that they can no longer service specific 
> > > > > > > > traffic flows
> > > > > > > > towards the SS7 newtork.  In the current draft this can be 
> > > > > > > > accomplished
> > > > > > > > in two ways, both which are problematic.
> > > > > > > > 
> > > > > > > >   1.  The SGP can use DUNA, DAVA, and DRST independently
from 
> > > > > > > > each of the
> > > > > > > >       SGP to indicate the difference in availability of 
> > > > > > > > routesets to the
> > > > > > > >       SS7 newtork above the partition and below the 
> > > > > > partition in the
> > > > > > > >       diagram.
> > > > > > > > 
> > > > > > > >       With the way that keeping DUNA, DAVA, DRST and SCON 
> > > > > > on a per-SGP
> > > > > > > >       basis at the ASP has been "watered down", however, in 
> > > > > > > > the M3UA-08
> > > > > > > >       draft, the SG cannot be guaranteed that the ASPs 
> > > > > > will respond
> > > > > > > >       properly to these partitioned indications.  If the 
> > > > > > ASPs respond
> > > > > > > >       under the "single management view", as is their 
> > > > > > option in the
> > > > > > > >       latest draft, this case will reduce to case (2) below.
> > > > > > > > 
> > > > > > > >   2.  The SGP drop their associations to the ASPs.  That is,

> > > > > > > > The entire
> > > > > > > >       SG goes off-line.
> > > > > > > > 
> > > > > > > This is true but this is only 1 part of the problem.
> > > > > > > A partionned SG means also multiple PC with the same Id on 
> > > > > > the same SS7
> > > > > > > network.
> > > > > > 
> > > > > > It is the case in the SS7 network that we assign one point code
> > > > > > to two STPs (alias point code for GTT).  It does not cause
> problems
> > > > > > in the SS7 network.
> > > > > > 
> > > > > > > And this last problem is not solved by M3UA.
> > > > > > 
> > > > > > But could easily.
> > > > > I suppose that here we disagree on the level of quality the SG
must
> > > > provide.
> > > > > And I think that this level will not be determined by you or me
but
> by
> > > the
> > > > 
> > > > > future users of M3UA.
> > > > > My position is that an SS7 platform (SG) partition does not work
> > because
> > > > > it could loose SS7 messages (1 or 1000 it cannot be acceptable,
for
> > me).
> > > > > M3UA cannot do anything here, it is a pure SS7 problem.
> > > > > > 
> > > > > > > Well, such a problem is mitigated by some particular SS7 
> > > > > > configurations, 
> > > > > > > for instance, when SGPs are connected to one and only one
> > adjacent,
> > > > > > > but in this case, the configuration don't take advantage of
the
> > SS7
> > > > > > > redundancy:
> > > > > > > if one SGP fails, an entire route is lost...
> > > > > > > So, I think that inter SGP communications must be designed 
> > > > > > by SG vendors
> > > > > > > and not by M3UA.
> > > > > > > I really think that SG vendors could be creative in this 
> > > > > > domain and provide
> > > > > > > an inter SGP communication mechanism very reliable, or even 
> > > > > > provide a 
> > > > > > > mechanism (may be with another LAN dedicated to this 
> > > > > > purpose) to "detect"
> > > > > > > SG platform partition... and avoid, even when using "single 
> > > > > > management
> > > > > > > view",
> > > > > > > to drop all the SGP associations to the ASPs. 
> > > > > > 
> > > > > > All this cost for guaranteed inter-SGP communication is not
> > necessary.
> > > > > Well, does everybody in this mailing list agree on this comment ?
> > > > > > With just a little support from M3UA, the platform could run
fully
> > > > > > partitioned and happy.  Detailed discussion of this was provided
> on
> > > > > > other threads.  Aside from low volume changeover messages and
> > routing
> > > > > > messages there should never be a need to route user level 
> > > > > > traffic between
> > > > > > SGP.  A patition in that case only causes minor message loss
> during
> > > > > > changeovers and is acceptable because the probability of
> > partitioning
> > > > > > failure coupled with the probability of changeover can be 
> > > > > > engineered to
> > > > > > meet message lost requirements quite economically.
> > > > > What means carrier-grade then ? 
> > > > > Anyway, I think that truth here depends on the quality level the
> final
> > > > > user wants ... and each future user will have its own definition
of
> > > > > "carrier-grade" level.
> > > > 
> > > > Don't be ridiculous.  The arrangement only loses messages when
> > > > failures occur.  This is permitted.  Just as long as the failure
> > > > rate is controlled to within those bounds which are acceptable by
> > > > the message loss requirements of MTP.
> > > > 
> > > > Compare this to how may messages your fancy inter-SGP arrangement
> > > > is going to lose when (not "if") it partitions.
> > > > 
> > > > > > 
> > > > > > I have handled the problem, it just needs minor support from
M3UA.
> > > > > > 
> > > > > On the IP side, may be. Not on the SS7 side (IMHO).
> > > > 
> > > > M3UA is not responsible for the SS7 side, the SG implementation
> > > > is.  M3UA need only provide the mechanisms reqruired by the SG
> > > > to perform its function.  I do not have to prove to _you_ that
> > > > the SS7 side works.
> > > > 
> > > > I am not shutting off my customer's $1M/hr cash flow just to
> > > > satisfy a "MAY" in the spec.
> > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > There is only one arrangement of SG/SGP in my mind that 
> > > > > > can keep this
> > > > > > > > from happening:  Make every SG consist of only one SGP, 
> > > > > > and have each
> > > > > > > > SG support only one SS7 link, like this:
> > > > > > > > 
> > > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > > >                 | SG                    | Associations     
> > > > > > > >        SS7             __________                          
> > > > > > > >        Link     |     |          |------|-----------       
> > > > > > > >    -------------------|   SGP1   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >                                                            
> > > > > > > >                 |                       |                  
> > > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > > >                 | SG                    | Associations     
> > > > > > > >        SS7             __________                          
> > > > > > > >        Link     |     |          |------|-----------       
> > > > > > > >    -------------------|   SGP2   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >                                                            
> > > > > > > >                 |                       |                  
> > > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > > >                 | SG                    | Associations     
> > > > > > > >        SS7             __________                          
> > > > > > > >        Link     |     |          |------|-----------       
> > > > > > > >    -------------------|   SGP3   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >                                                            
> > > > > > > >                 |                       |                  
> > > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > >                             .                              
> > > > > > > >                             .                              
> > > > > > > >                             .                              
> > > > > > > >                 / - - - - - - - - - - - \    SCTP          
> > > > > > > >                 | SG                    | Associations     
> > > > > > > >        SS7             __________                          
> > > > > > > >        Link     |     |          |------|-----------       
> > > > > > > >    -------------------|   SGPn   |------------------       
> > > > > > > >                 |     |__________|------|-----------       
> > > > > > > >                                                            
> > > > > > > >                 |                       |                  
> > > > > > > >                 \ - - - - - - - - - - - /                  
> > > > > > > > 
> > > > > > > > This is possible, however, it pretty much reduces M3UA to
> M2UA.
> > > > > > > > 
> > > > > > > > I would rather see the SGP be provided with some 
> > > > > > mechanism by way of
> > > > > > > > which it can be assured that the ASPs will respond properly
to
> > > > > > > > partitioned SGP.
> > > > > > > > 
> > > > > > > > Until they do, I cannot see that M3UA can be implemented in
a
> > > > > > > > carrier-class arrangement with ASPs which treat the SG with
a 
> > > > > > > > "single management view".
> > > > > > > Well, no, I think it is possible but requires a lot of
> experience
> > > > > > > in distributed computing (at least for the SGP vendors..). 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > --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]
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ---
> > > > > > > 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]
> > > > 
> > > > -- 
> > > > 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]
> > > 
> > > -- 
> > > 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]
> > 
> > -- 
> > 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]
> 
> -- 
> 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]

-- 
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: Wed, 25 Jul 2001 11:03:43 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: M3UAv8: Missing Status Information
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

In section 3.8.2. Notify, the ASP Identifier has been added, but the Status
Information value to which it applies is missing.
Please add:

   If the Status Type is Other, then the following Status Information 
   values are defined:

         1    Insufficient ASP Resources Active in AS
         2    Alternate ASP Active
+ ---->  3    ASP Failure

--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: Wed, 25 Jul 2001 11:06:53 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: John Loughney <[email-masked]>
Subject: SUAv7: Missing Status Information
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

SUA is also missing the Status Information "ASP Failure" to which the
addition of ASP Id applies.  Please add.

--Brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
Date: Wed, 25 Jul 2001 11:03:43 -0500
From: "Brian F. G. Bidulock" <[email-masked]> To:
[email-masked] Cc: Greg Sidebottom <[email-masked]>
Bcc: [email-masked]
Subject: M3UAv8: Missing Status Information Message-ID:
<20010725110343.A9806@bfgbhome> Reply-To: [email-masked]
Content-Disposition: inline
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]> Return-Receipt-To:
<[email-masked]> Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1

Greg,

In section 3.8.2. Notify, the ASP Identifier has been added, but the Status
Information value to which it applies is missing.
Please add:

   If the Status Type is Other, then the following Status Information 
   values are defined:

         1    Insufficient ASP Resources Active in AS
         2    Alternate ASP Active
+ ---->  3    ASP Failure

--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: Wed, 25 Jul 2001 11:16:00 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv7: SG redundancy
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Didler,

It may seem neither here nor there, but there has been a configuration error
in an MTP-User on the ASP.  But, the management notification that a message
has arrived for a non-existent route on the SGP.  Management indications on
a node other than the one which has the problem are not too useful (and can
be embarassing).  If the SGP notifies the ASP of this situation, then the
ASP can suppress further attempts and inform management at the ASP.

--Brian

Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
18:01:47)
> Brian,
> I'm 100% ok with you, I don't catch it this way...
> /Didier
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 4:27 PM
> To: sigtran
> Subject: Re: M3UAv7: SG redundancy
> 
> 
> Didier,
> 
> It was completely unrelated, but the MTP-User at the ASP needs
> to know whether it has attempted to send a message to a DPC
> which it can never reach because the SGP has not been configured
> with a route to that destination.  The proscribed SS7 behavior
> is for the SGP to silently discard the message if it comes from
> one of its own MTP-Users.  There is no reason for the MTP-User
> at the ASP to continue sending messages into a black hole.  It
> should be informed.  Otherwise, the MTP-User may attempt to resend
> to that destination periodically.
> 
> --Brian
> 
> 
> Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
> 16:13:48)
> > Bryan,
> > Aren't they same concept?
> > 
> > DUNA(Global): -> Destination Unavailable Permanent Condition (No route
in
> > routing tables)
> > DUNA(Local): -> Destination Unavailable Transient Condition (Received
TFP
> > for destination)
> >                  -->> TFP is one of the possible SS7 event...
> > 
> > On ASP point of view the only thing that ASP needs is to have an
efficiant
> > routing...
> > Why does ASP need to know that SGP receive TFP for one destination?
> > 
> > The only thing that ASP needs is to know that one SGP:
> > * can not reach one destination (No route in routing tables).
> > ->DUNA(Global).
> > * can reach one destination but not directly (because this SGP receive
> TFP,
> > or 
> >   one of its link fail or whatever else, implementation dependant).
> > ->DUNA(Local)
> > 
> > /Didier
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, July 25, 2001 3:11 PM
> > To: sigtran
> > Subject: Re: M3UAv7: SG redundancy
> > 
> > 
> > Didier,
> > 
> > Now that you mention different kinds of DUNA, there is another
> > distrinction which needs to be made:
> > 
> > -> Destination Unavailable Permanent Condition (No route in routing
> tables)
> > -> Destination Unavailable Transient Condition (Received TFP for
> > destination)
> > 
> > --Brian
> > 
> > 
> > Desiderio, Didier wrote:                               (Wed, 25 Jul 2001
> > 14:51:36)
> > > Brian,
> > > 
> > > Perhaps we need 2 levels for the DUNA (same for DAVA, DRST, SCON...):
> > > 
> > > -> Destination Unavailable for the SG  (-> GLOBAL, DUNA).
> > > -> Destination Unavailable for the SGP (-> LOCAL, DUNA).
> > > 
> > > Endeed in the sample bellow... SGP2 can send a DUNA(LOCAL)... So the
> > > destination
> > > is still accessible by SGP2 but it is not the more "efficiant way" to
> send
> > 
> > > the message.
> > > 
> > > /Didier
> > > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, July 25, 2001 2:28 PM
> > > To: sigtran
> > > Subject: Re: M3UAv7: SG redundancy
> > > 
> > > 
> > > Didier,
> > > 
> > > Yes, it would send DUNAs iff it was a permitted way of
> > > getting the ASP to stop traffic to the SGP.
> > > 
> > > These examples show the need for SGP management.  If
> > > not DUNAs then something else...
> > > 
> > > --Brian
> > > 
> > > Desiderio, Didier wrote:                               (Wed, 25 Jul
2001
> > > 14:17:20)
> > > > Brian,
> > > > Thanks for your answer and sorry to insist but in your diagram,
> > > > does SGP2 send (or not) the DUNAs? 
> > > > and if no, 
> > > > you have only one "single management point of view" of ss7
> destinations
> > > per
> > > > SG
> > > > that change a lot of things...
> > > > 
> > > > /Didier
> > > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Wednesday, July 25, 2001 1:50 PM
> > > > To: sigtran
> > > > Subject: Re: M3UAv7: SG redundancy
> > > > 
> > > > 
> > > > Didier,
> > > > 
> > > > I have answered this before, but, again: If I can modify your
> > > > diagram sligtly:
> > > >   
> > > >                           SG
> > > >                + - - - - - - - - - - - +
> > > >        SS7     |Switch                 |
> > > >       Links       |   __________            SCTP
> > > >    ------------|--|  |          |      | Associations   __________
> > > >    ------------ --|--|   SGP1   |-X-X-X-X-X-X-X-X-X-X--|          |
> > > >    ------------|--|  |__________|      |               |   ASP    |
> > > >                   |   __________                  +----|__________|
> > > >    -X-X-X-X-X--|--|  |          |      |          |
> > > >    -X-X-X-X-X-- --|--|   SGP2   |-----------------+
> > > >    -X-X-X-X-X--|--|  |__________|      |
> > > >                   |
> > > >                |                       |
> > > >                + - - - - - - - - - - - +
> > > >   
> > > > If there is another degree of freedom between the SGP
> > > > and the SS7 Links (H.100 bus, M2UA) then in your scenario
> > > > I would have SGP2 take over the SS7 links from SGP1.
> > > > There is still no need to route user level traffic
> > > > between SGP.  Depending on the architecture, it might
> > > > be too drastic a measure off the start.
> > > > 
> > > > --Brian
> > > > 
> > > > 
> > > > > 2/ all destinations in SGP1 are UP.
> > > > > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP
for
> > all
> > > > > destinations...
> > > > > 3/ The SCTP asso SGP1-ASP just falling.
> > > > 
> > > > Desiderio, Didier wrote:                               (Wed, 25 Jul
> 2001
> > > > 13:38:22)
> > > > > Brian,
> > > > > Can you explain that, consider the following :
> > > > > 
> > > > > 1/ SGP in the same SG do not have a "single management point of
> view"
> > > that
> > > > > is
> > > > > to say they are sharing the same ss7 destinations but each SGP has
> its
> > > own
> > > > 
> > > > > management view...
> > > > > 
> > > > >                         SG
> > > > >              + - - - - - - - - - - - +
> > > > >      SS7     |                       |
> > > > >     Links           __________            SCTP
> > > > >  ------------|     |          |      | Associations   __________
> > > > >  ------------      |   SGP1   |----------------------|          |
> > > > >  ------------|     |__________|      |               |   ASP    |
> > > > >                     __________                  +----|__________|
> > > > >  ------------|     |          |      |          |
> > > > >  ------------      |   SGP2   |-----------------+
> > > > >  ------------|     |__________|      |
> > > > > 
> > > > >              |                       |
> > > > >              + - - - - - - - - - - - +
> > > > > 
> > > > > 2/ all destinations in SGP1 are UP.
> > > > > 3/ all SS7 links of the SGP2 are down. DUNAs are sent to the ASP
for
> > all
> > > > > destinations...
> > > > > 3/ The SCTP asso SGP1-ASP just falling.
> > > > > 4/ ASP has to send data to one destination and this SG is the
> priority
> > > > > route.
> > > > > 
> > > > > Does the ASP not send this data? 
> > > > > Does the ASP choose another SG to send this DATA?
> > > > > >> even if the destination is not considered as DOWN from SS7
point
> of
> > > > view
> > > > > and
> > > > >    this SG is the priority route!!!!
> > > > > 
> > > > > And is it aceptable on the M3UA point of view?
> > > > > 
> > > > > /Didier
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Wednesday, July 25, 2001 12:09 PM
> > > > > To: sigtran
> > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > 
> > > > > 
> > > > > Pierre,
> > > > > 
> > > > > Please see more comments below...
> > > > > 
> > > > > Garnero, Pierre wrote:                    (Wed, 25 Jul 2001
> 11:43:56)
> > > > > > Brian,
> > > > > > 
> > > > > > just some comments below:
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > Sent: Wednesday, July 25, 2001 11:20 AM
> > > > > > > To: sigtran
> > > > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > > > 
> > > > > > > 
> > > > > > > Pierre,
> > > > > > > 
> > > > > > > Please see comments below...
> > > > > > > 
> > > > > > > Garnero, Pierre wrote:                                   
> > > > > > > (Wed, 25 Jul 2001 10:33:34)
> > > > > > > > Hello Hong,
> > > > > > > > 
> > > > > > > > please find another point of view, included in Brians
> > comments...
> > > > > > > > 
> > > > > > > > Cheers,
> > > > > > > > 
> > > > > > > > PiG
> > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > > Sent: Wednesday, July 25, 2001 8:28 AM
> > > > > > > > > To: sigtran
> > > > > > > > > Subject: Re: M3UAv7: SG redundancy
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Hong,
> > > > > > > > > 
> > > > > > > > > You bring up some good questions.
> > > > > > > > > 
> > > > > > > > > Hong Liu wrote:                              (Wed, 25 Jul 
> > > > > > > > > 2001 08:08:07)
> > > > > > > > > > Hi, Brian,
> > > > > > > > > > 
> > > > > > > > > > I am also confused by the notion of SG vs. SGP in the 
> > > > > > > > > current M3UA spec.
> > > > > > > > > > Maybe you can help me to understand the concepts better.
I
> 
> > > > > > > > > noticed that
> > > > > > > > > > there was a long thread of discussions on the list a few

> > > > > > > > > months ago on
> > > > > > > > > > this topic. So I apologize in advance if I bring up 
> > > > > > > > > something that has
> > > > > > > > > > already been clarified.
> > > > > > > > > > 
> > > > > > > > > > According to the current spec, an SG is a logical 
> > > > > > > entity if it is
> > > > > > > > > > composed of more than one SGP. From the SS7 network
point 
> > > > > > > > > of view, SG is
> > > > > > > > > > the one that acts as an SS7 signaling point and is thus 
> > > > > > > > > assigned a point
> > > > > > > > > > code. Does it imply that all the SGPs of an SG will bear

> > > > > > > > > the same point
> > > > > > > > > > code even if they are geographically separated? Is that 
> > > > > > > > > what it means in
> > > > > > > > > > the spec regarding a single management view to the SS7
> > > network?
> > > > > > > > > > 
> > > > > > > > > > On the IP side, is it required that an ASP set up an
M3UA 
> > > > > > > > > association
> > > > > > > > > > with each of the active SGPs? Or in other words, is it 
> > > > > > > > > allowed by the
> > > > > > > > > > spec that an ASP only sets up M3UA associations to a 
> > > > > > > > > (non-empty) subset
> > > > > > > > > > of the active SGPs?
> > > > > > > > > > 
> > > > > > > > > > Cheers,
> > > > > > > > > > 
> > > > > > > > > > --Hong
> > > > > > > > > > 
> > > > > > > > > [snip]
> > > > > > > > > 
> > > > > > > > > I believe that there are several points in the draft 
> > > > > > > which lead to a
> > > > > > > > > definition of an SG.  These are:
> > > > > > > > > 
> > > > > > > > >    o   An SGP is a unique transport (SCTP) endpoint.
> > > > > > > > > 
> > > > > > > > >    o   An SG is a collection or set of one or more SGPs.
> > > > > > > > > 
> > > > > > > > >    o   An SG terminates SS7 signalling links from the SS7
> > > network.
> > > > > > > > > 
> > > > > > > > >    o   An SG has one set of Routing Keys which are shared 
> > > > > > > by all the
> > > > > > > > >        SGPs which make up the SG.
> > > > > > > > > 
> > > > > > > > >    o   Each SGP in an SG offers identical connectivity to
> the
> > > SS7
> > > > > > > > >        network.
> > > > > > > > > 
> > > > > > > > > There are no restrictions placed on what point codes an SG

> > > > > > > > > does or does
> > > > > > > > > not represent.  There are no restrictions placed on how
many
> 
> > > > > > > > > SGP a Host
> > > > > > > > > represents.  There are no restrictions in terms of the 
> > > > > > > geographical
> > > > > > > > > positioning of SGP within an SG.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > The draft stats: "An SG appears to the SS7 network as an 
> > > > > > > SS7 Signalling 
> > > > > > > > Point". 
> > > > > > > > So, for a specific SS7 network, an SG has a unique point
code.
> > > > > > > 
> > > > > > > An SG appears to the SS7 network as having a point code,
> > > > > > > but it doen't have to have one of its own.  This was clearly
> > > > > > > intended in the draft from the start: that the SG can just
> > > > > > > represent the SPMC point code which "belongs" to the ASPs.
> > > > > > > If the SG has a point code separate from the ASP, then it
> > > > > > > would have to be an STP.  That is not required by the spec.
> > > > > > > 
> > > > > > Yes, an SG has a point code from the SS7 point of view ...
> > > > > > We are in sync here !!! :-)
> > > > > 
> > > > > No we are not in sync.  The SG "represents" one or more point
> > > > > codes to the SS7 network.  It does not necessarily "have" one.
> > > > > I though that the draft made this crystal clear.  The SG may
> > > > > or may not have local MTP-Users.  If it has no local MTP-Users
> > > > > and is not equipped with the transfer function, then it does
> > > > > not "have" a point code.
> > > > > 
> > > > > > > > 
> > > > > > > > > When your consider these points, an SG, in principle, 
> > > > > > > looks like the
> > > > > > > > > following:
> > > > > > > > > 
> > > > > > > > >

> > > > > > > > >                            SG

> > > > > > > > >                 / - - - - - - - - - - - \    SCTP

> > > > > > > > >                 |                       | Associations

> > > > > > > > >                        __________

> > > > > > > > >                 |     |          |------|-----------

> > > > > > > > >                       |   SGP1   |------------------

> > > > > > > > >                 |     |__________|------|-----------

> > > > > > > > >         SS7            __________

> > > > > > > > >        Links    |     |          |------|-----------

> > > > > > > > >     ------------      |   SGP2   |------------------

> > > > > > > > >     ------------|     |__________|------|-----------

> > > > > > > > >     ------------       __________                       To

> > > > > > > > >     ------------|     |          |------|-----------
ASPs
> > > > > > > > >     ------------      |   SGP3   |------------------

> > > > > > > > >     ------------|     |__________|------|-----------

> > > > > > > > >     ------------       __________

> > > > > > > > >     ------------|     |          |------|-----------

> > > > > > > > >     ------------      |   SGP4   |------------------

> > > > > > > > >     ------------|     |__________|------|-----------

> > > > > > > > >     ------------

> > > > > > > > >                 |           .           |

> > > > > > > > >                             .

> > > > > > > > >                 |           .           |

> > > > > > > > >                        __________

> > > > > > > > >                 |     |          |------|-----------

> > > > > > > > >                       |   SGPn   |------------------

> > > > > > > > >                 |     |__________|------|-----------

> > > > > > > > >                 |                       |

> > > > > > > > >                 \ - - - - - - - - - - - /

> > > > > > > > > 
> > > > > > > > > Where the argument, errr.., discussion errupts centers
> around
> > > the
> > > > > > > > > restriction that all SGP in an SG must have identical
> > > connectivity
> > > > > > > > > to the SS7 network and SHOULD be able to transfer traffic
> > > between
> > > > > > > > > them to accomplish that feat.
> > > > > > > > > 
> > > > > > > > > My position is that, while in principle this sounds good,
in
> 
> > > > > > > > > practice it
> > > > > > > > > does not:
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > My position is the opposite... :-)
> > > > > > > 
> > > > > > > Uhmm.
> > > > > > > 
> > > > > > > > 
> > > > > > > > > On of the purposes of allowing multple SGP is to allow 
> > > > > > > the SG to be a
> > > > > > > > > collection of multiple hosts for redudancy and scaling.  
> > > > > > > > > Unfortunately,
> > > > > > > > > when SGPs are multiple hosts, the possibility of a 
> > > > > > > "partitioned" SG
> > > > > > > > > due to internal failures is possible.  That could look
like
> > > this:

> > > > > > > > >                            SG

> > > > > > > > >                 / - - - - - - - - - - - \    SCTP

> > > > > > > > >                 |                       | Associations

> > > > > > > > >                        __________

> > > > > > > > >                 |     |          |------|-----------

> > > > > > > > >                       |   SGP1   |------------------

> > > > > > > > >                 |     |__________|------|-----------

> > > > > > > > >         SS7            __________

> > > > > > > > >        Links    |     |          |------|-----------

> > > > > > > > >     ------------      |   SGP2   |------------------

> > > > > > > > >     ------------|     |__________|------|-----------

> > > > > > > > >    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
> > > > > > > > >     ------------       __________                       To

> > > > > > > > >     ------------|     |          |------|-----------
ASPs
> > > > > > > > >     ------------      |   SGP3   |------------------

> > > > > > > > >     ------------|     |__________|------|-----------

> > > > > > > > >     ------------       __________

> > > > > > > > >     ------------|     |          |------|-----------

> > > > > > > > >     ------------      |   SGP4   |------------------

> > > > > > > > >     ------------|     |__________|------|-----------

> > > > > > > > >     ------------

> > > > > > > > >                 |           .           |

> > > > > > > > >                             .

> > > > > > > > >                 |           .           |

> > > > > > > > >                        __________

> > > > > > > > >                 |     |          |------|-----------

> > > > > > > > >                       |   SGPn   |------------------

> > > > > > > > >                 |     |__________|------|-----------

> > > > > > > > >                 |                       |

> > > > > > > > >                 \ - - - - - - - - - - - /

> > > > > > > > > 
> > > > > > > > > In some of the above "partitioned" scenarios, the SGPs 
> > > > > > > need to be able
> > > > > > > > > to tell the ASPs that they can no longer service specific 
> > > > > > > > > traffic flows
> > > > > > > > > towards the SS7 newtork.  In the current draft this can be

> > > > > > > > > accomplished
> > > > > > > > > in two ways, both which are problematic.
> > > > > > > > > 
> > > > > > > > >   1.  The SGP can use DUNA, DAVA, and DRST independently
> from 
> > > > > > > > > each of the
> > > > > > > > >       SGP to indicate the difference in availability of 
> > > > > > > > > routesets to the
> > > > > > > > >       SS7 newtork above the partition and below the 
> > > > > > > partition in the
> > > > > > > > >       diagram.
> > > > > > > > > 
> > > > > > > > >       With the way that keeping DUNA, DAVA, DRST and SCON 
> > > > > > > on a per-SGP
> > > > > > > > >       basis at the ASP has been "watered down", however,
in 
> > > > > > > > > the M3UA-08
> > > > > > > > >       draft, the SG cannot be guaranteed that the ASPs 
> > > > > > > will respond
> > > > > > > > >       properly to these partitioned indications.  If the 
> > > > > > > ASPs respond
> > > > > > > > >       under the "single management view", as is their 
> > > > > > > option in the
> > > > > > > > >       latest draft, this case will reduce to case (2)
below.
> > > > > > > > > 
> > > > > > > > >   2.  The SGP drop their associations to the ASPs.  That
is,
> 
> > > > > > > > > The entire
> > > > > > > > >       SG goes off-line.
> > > > > > > > > 
> > > > > > > > This is true but this is only 1 part of the problem.
> > > > > > > > A partionned SG means also multiple PC with the same Id on 
> > > > > > > the same SS7
> > > > > > > > network.
> > > > > > > 
> > > > > > > It is the case in the SS7 network that we assign one point
code
> > > > > > > to two STPs (alias point code for GTT).  It does not cause
> > problems
> > > > > > > in the SS7 network.
> > > > > > > 
> > > > > > > > And this last problem is not solved by M3UA.
> > > > > > > 
> > > > > > > But could easily.
> > > > > > I suppose that here we disagree on the level of quality the SG
> must
> > > > > provide.
> > > > > > And I think that this level will not be determined by you or me
> but
> > by
> > > > the
> > > > > 
> > > > > > future users of M3UA.
> > > > > > My position is that an SS7 platform (SG) partition does not work
> > > because
> > > > > > it could loose SS7 messages (1 or 1000 it cannot be acceptable,
> for
> > > me).
> > > > > > M3UA cannot do anything here, it is a pure SS7 problem.
> > > > > > > 
> > > > > > > > Well, such a problem is mitigated by some particular SS7 
> > > > > > > configurations, 
> > > > > > > > for instance, when SGPs are connected to one and only one
> > > adjacent,
> > > > > > > > but in this case, the configuration don't take advantage of
> the
> > > SS7
> > > > > > > > redundancy:
> > > > > > > > if one SGP fails, an entire route is lost...
> > > > > > > > So, I think that inter SGP communications must be designed 
> > > > > > > by SG vendors
> > > > > > > > and not by M3UA.
> > > > > > > > I really think that SG vendors could be creative in this 
> > > > > > > domain and provide
> > > > > > > > an inter SGP communication mechanism very reliable, or even 
> > > > > > > provide a 
> > > > > > > > mechanism (may be with another LAN dedicated to this 
> > > > > > > purpose) to "detect"
> > > > > > > > SG platform partition... and avoid, even when using "single 
> > > > > > > management
> > > > > > > > view",
> > > > > > > > to drop all the SGP associations to the ASPs. 
> > > > > > > 
> > > > > > > All this cost for guaranteed inter-SGP communication is not
> > > necessary.
> > > > > > Well, does everybody in this mailing list agree on this comment
?
> > > > > > > With just a little support from M3UA, the platform could run
> fully
> > > > > > > partitioned and happy.  Detailed discussion of this was
provided
> > on
> > > > > > > other threads.  Aside from low volume changeover messages and
> > > routing
> > > > > > > messages there should never be a need to route user level 
> > > > > > > traffic between
> > > > > > > SGP.  A patition in that case only causes minor message loss
> > during
> > > > > > > changeovers and is acceptable because the probability of
> > > partitioning
> > > > > > > failure coupled with the probability of changeover can be 
> > > > > > > engineered to
> > > > > > > meet message lost requirements quite economically.
> > > > > > What means carrier-grade then ? 
> > > > > > Anyway, I think that truth here depends on the quality level the
> > final
> > > > > > user wants ... and each future user will have its own definition
> of
> > > > > > "carrier-grade" level.
> > > > > 
> > > > > Don't be ridiculous.  The arrangement only loses messages when
> > > > > failures occur.  This is permitted.  Just as long as the failure
> > > > > rate is controlled to within those bounds which are acceptable by
> > > > > the message loss requirements of MTP.
> > > > > 
> > > > > Compare this to how may messages your fancy inter-SGP arrangement
> > > > > is going to lose when (not "if") it partitions.
> > > > > 
> > > > > > > 
> > > > > > > I have handled the problem, it just needs minor support from
> M3UA.
> > > > > > > 
> > > > > > On the IP side, may be. Not on the SS7 side (IMHO).
> > > > > 
> > > > > M3UA is not responsible for the SS7 side, the SG implementation
> > > > > is.  M3UA need only provide the mechanisms reqruired by the SG
> > > > > to perform its function.  I do not have to prove to _you_ that
> > > > > the SS7 side works.
> > > > > 
> > > > > I am not shutting off my customer's $1M/hr cash flow just to
> > > > > satisfy a "MAY" in the spec.
> > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > There is only one arrangement of SG/SGP in my mind that 
> > > > > > > can keep this
> > > > > > > > > from happening:  Make every SG consist of only one SGP, 
> > > > > > > and have each
> > > > > > > > > SG support only one SS7 link, like this:
> > > > > > > > > 
> > > > > > > > >                 / - - - - - - - - - - - \    SCTP

> > > > > > > > >                 | SG                    | Associations

> > > > > > > > >        SS7             __________

> > > > > > > > >        Link     |     |          |------|-----------

> > > > > > > > >    -------------------|   SGP1   |------------------

> > > > > > > > >                 |     |__________|------|-----------

> > > > > > > > >                 |                       |

> > > > > > > > >                 \ - - - - - - - - - - - /

> > > > > > > > >                 / - - - - - - - - - - - \    SCTP

> > > > > > > > >                 | SG                    | Associations

> > > > > > > > >        SS7             __________

> > > > > > > > >        Link     |     |          |------|-----------

> > > > > > > > >    -------------------|   SGP2   |------------------

> > > > > > > > >                 |     |__________|------|-----------

> > > > > > > > >                 |                       |

> > > > > > > > >                 \ - - - - - - - - - - - /

> > > > > > > > >                 / - - - - - - - - - - - \    SCTP

> > > > > > > > >                 | SG                    | Associations

> > > > > > > > >        SS7             __________

> > > > > > > > >        Link     |     |          |------|-----------

> > > > > > > > >    -------------------|   SGP3   |------------------

> > > > > > > > >                 |     |__________|------|-----------

> > > > > > > > >                 |                       |

> > > > > > > > >                 \ - - - - - - - - - - - /

> > > > > > > > >                             .

> > > > > > > > >                             .

> > > > > > > > >                             .

> > > > > > > > >                 / - - - - - - - - - - - \    SCTP

> > > > > > > > >                 | SG                    | Associations

> > > > > > > > >        SS7             __________

> > > > > > > > >        Link     |     |          |------|-----------

> > > > > > > > >    -------------------|   SGPn   |------------------

> > > > > > > > >                 |     |__________|------|-----------

> > > > > > > > >                 |                       |

> > > > > > > > >                 \ - - - - - - - - - - - /

> > > > > > > > > 
> > > > > > > > > This is possible, however, it pretty much reduces M3UA to
> > M2UA.
> > > > > > > > > 
> > > > > > > > > I would rather see the SGP be provided with some 
> > > > > > > mechanism by way of
> > > > > > > > > which it can be assured that the ASPs will respond
properly
> to
> > > > > > > > > partitioned SGP.
> > > > > > > > > 
> > > > > > > > > Until they do, I cannot see that M3UA can be implemented
in
> a
> > > > > > > > > carrier-class arrangement with ASPs which treat the SG
with
> a 
> > > > > > > > > "single management view".
> > > > > > > > Well, no, I think it is possible but requires a lot of
> > experience
> > > > > > > > in distributed computing (at least for the SGP vendors..). 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > --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]
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ---
> > > > > > > > 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]
> > > > > 
> > > > > -- 
> > > > > 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]
> > > > 
> > > > -- 
> > > > 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]
> > > 
> > > -- 
> > > 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]
> > 
> > -- 
> > 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]
> 
> -- 
> 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]

-- 
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: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA, SUA]: SGP Management (was: [M3UA, SUA]: Gracefull shut
down 
         of SGP)
Date: Wed, 25 Jul 2001 09:23:59 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zcamail05.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zcamail05.zca.compaq.com [161.114.32.105]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Why Brian, I didn't expect you to give me "in the box" answers.

Comments below.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Tuesday, July
24, 2001 10:56 PM
To: sigtran
Subject: [M3UA, SUA]: SGP Management (was: [M3UA, SUA]: Gracefull shutdown
of SGP)

John,

Please see comments below...

Schantz, John wrote:                                     (Tue, 24 Jul 2001
11:19:58)
> Brian,
> 
> 	No it is not.  Sending DUNAs, DAVAs, etc. from each SGP to each ASP
> is not like how it is done in SS7.

Of course not.  SS7 does not define DUNA, DAVA, etc...

[John]  SS7 has TFP, TFA, etc.  Note that TFP ~ DUNA, different name but the
same purpose.  The point was that in SS7, each link interface does not send
a TFP to move traffic away from it self.  Hence, you have moved away from
the basic SS7 philosophy.

> A linkset is defined as ALL the links
> (in our case associations) between two signaling points (in our case an SG
> and an AS);

An SG can represent more than one signalling point.  So can an AS.
That is not the general case.  In the general case, the AS has the
equivalent of multiple linksets to the SG.

[John]  Basic signalling points are defined by their point code.  If a
signalling point supports another point code, it can support another linkset
to a remote node, but the remote node sees the 2 point codes as defining
separate signalling points.

> and it doesn't matter how many SGPs or ASPs are involved.

Yes it does: particularly for the multiple point code SG/AS case above.
Each SGP's ability to transfer messages is independent of the other SGPs.
The same is true for ASPs.  By nature a process is independent of other
processes.

[John]  Stick to the base topic.  We talking about the single point code
case.  In the communication from an AS to an SG, the number of SGPs or ASPs
are not an issue, especially at the network management level (SS7).

The ASP currently has a procedure for managing routing in the SG->AS
direction: Routing Keys, Routing Contexts and ASP Management procedures.

[John]  You're dragging ASP management to a higher level than it deserves.
ASP management only establishes whether communication (messages) can occur
on a specific path (the association).  Hence, it is really only a complex
way of bringing a "link" in service.

The SGP lack this ability.  It is required.  I don't care whether it is
DUNA, DAVA, ... which are used or reverse Routing Keys, Routing Context and
SGP Management procedures.  They could be identical to those already defined
for the ASP, as they may be in an IPSP case.

[John]  What do you think the layer management is for.  We really are only
talking about a link.

> An
> SS7 point code normally has more than one linkset BUT they are to
different
> nodes as defined by an SS7 point code.

That is not completely true.  It is normal to assign multiple point codes to
large switches.  Linksets may go to multiple point codes which are really
the same node.  In this case SS7 network management procedures treat the
switch as multiple SS7 signalling points (one per point code) when it is
really only one node.

[John]  No this is completely true.  A pair of point codes defines the end
points of a linkset.  Multiple linksets is only possible via multiple
physical points codes.  Please stop trying to cloud the issue with multiple
point codes.  This all degenerates down to a signaling point is a point
code.

It is also not true for alias point codes assigned to GTT function in STP
pairs.  When alias point codes are assigned to STPs in this fashion, an SS7
signalling point does not directly correspond to a signalling node.  It is a
virtual signalling point which "appears" to be behind the STPs.  MTP network
management procedures have no difficulty in accomodating this concept.  Your
statements only really apply to adjacent signalling points, a severe subset
of the MTP network and traffic management behavior.

[John]  Its always nice to hear your own inventions quoted.  You missed the
point that an alias point code is a virtual point code not a physical point
code.

> Therefore a SGP which gets its point
> code from the SG does qualify as a node and therefore it can not have a
> linkset (unless it is the only one) and therefore it can have no route by
> SS7 definition.

On the SS7 side.  On the IP side we are splitting traffic flows from various
linksets by routing key.  Unless RK == linkset, those traffic flows are
independent of linkset.  The ASP is managing those traffic flows using ASP
Management procedures.  The SGP needs to manage those traffic flows from its
end with similar procedures.  In the M3UA spec, the SGP can use DUNA, DAVA,
... to achieve that mangement at least on a per point code basis, per ASP.

[John]  I don't agree with this usage of the DUNA, DAVA, ...  These are
message equivalents to the SS7 network management messages, TFP, TFA, ...
They should not be used for double duty.  Only in the cases where you are
break up the RK to be finer than a point code might you need something BUT
you should not reuse the network management level messages to do it.  My
node will not require a RK that is finer than a PC, therefore it does not
require this link-level management.  I would think that for most existing
SS7 nodes, a RK = PC is sufficient.

Separate SGP management procedures which had more granular control than a
whole point code would be better.

[John]  I think I already made my case above.  Define some other option
message set to cover the case where RKs are finer than a PC (or are we now
stepping on SCCP's toes).

> 
> John
> 
> PS.  I am very familiar with SS7.  I was one of the original people that
> started defining the ANSI SS7 protocol in 1984.  I have served as
> editor/author of T1.111.5, T1.111.6, and T1.111.8.  I have been the
convener
> of SCCP and I now serve as the editor for T1.112.4.

You had the easy part.  I had to make it work in a national telephone
network.  There are a lot of people who contribute to this WG who have
extensive experience with SS7.  I am sure that most of our achievements in
that respect pale in comparison to the likes of Al Varney.

[John]  Maybe and maybe not.  Al, I'm sorry that Brian used your name in
vain.

> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 11:41 AM
> To: sigtran
> Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> 
> 
> John,
> 
> The way we do it in SS7 is to keep track of routing on
> an individual linkset basis.  An SS7 point code normally
> has more than one linkset, and so must keep track of
> routeset available on a per-linkset basis.  Because
> TFP, TFA and TFR are always sent only to adjacent SPs,
> they only apply to the linkset upon which they are
> received.
> 
> There is nothing different between the M3UA-07 approach
> and that of normal MTP routing within a Siganlling Point.
> 
> --Brian
> 
> Schantz, John wrote:                                     (Tue, 24 Jul 2001
> 09:27:41)
> > Brian,
> > 
> > 	NO, its an "all or nothing" concept.  This is the way it works in
> > SS7.  We do not give network management controls to individual links.
> > 
> > John
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Tuesday, July 24, 2001 10:46 AM
> > To: sigtran
> > Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> > 
> > 
> > John,
> > 
> > While we're on the subject, if the SGP is permitted to
> > send ASP Inactive, why should it not also be permitted
> > to send ASP Inactive for a restricted set of routing
> > contexts?
> > 
> > --Brian
> > 
> > Schantz, John wrote:                             (Tue, 24 Jul 2001
> 08:17:34)
> > > Dan,
> > > 
> > > 	I like the idea of a symmetric protocol.  Sending ASP-INACTIVE is
> > > better than trying to use NTFY to do it.
> > > 
> > > John
> > > 
> > > -----Original Message-----
> > > From: Dan Brendes [mailto:[email-masked]]
> > > Sent: Monday, July 23, 2001 5:51 PM
> > > To: sigtran
> > > Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> > > 
> > > 
> > > 
> > > 
> > > I definitely agree that both sides need to be able to allow/prohibit
> > traffic
> > > and
> > > support graceful shutdown as per local management.
> > > 
> > > I think there are multiple messages the SGP could send to the ASP to
> > inform
> > > it
> > > that an association is being locally inhibited/blocked, and it doesn't
> > > really
> > > matter which we pick as long as it is clearly described in the spec.
> > > Notify(blocking) will work, but not necessarily any better or worse
than
> > > ASP-INACTIVE-ACK(blocked) or ASP-INACTIVE(blocked) in my opinion.
Since
> > the
> > > SGP
> > > is restricted from sending ASP-INACTIVE according to the current
wording
> > in
> > > section 3.7.3 of m3ua-07 it could send ASP-INACTIVE-ACK(blocking) to
> > notify
> > > the
> > > ASP that the state of the connection is moving from ASP-ACTIVE to
> > > ASP-INACTIVE.
> > > Better yet, why not create a symmetric protocol where either side of
the
> > > connection can send ASP-INACTIVE (change the wording of the 1st
sentence
> > in
> > > 3.7.3).
> > > 
> > > Allowing the SGP to prohibit traffic will also have implications on
> > > processing
> > > ASP-ACTIVE messages when locally prohibited.  I would propose that the
> SGP
> > > returns ASP-INACTIVE-ACK(blocked) in response to an ASP-ACTIVE message
> in
> > > that
> > > situation.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > "Brian F. G. Bidulock" <[email-masked]> on 07/23/2001 05:42:45
PM
> > > 
> > > Please respond to [email-masked]
> > > 
> > > To:   "sigtran" <[email-masked]>
> > > cc:   [email-masked] (bcc: Dan
Brendes/Raleigh/TEKELEC)
> > > Subject:  Re: [M3UA, SUA]: Gracefull shutdown of SGP
> > > 
> > > 
> > > 
> > > 
> > > All,
> > > 
> > > Does anyone object to this procedure?
> > > 
> > > Kurt Kite wrote:                                             (Mon, 23
> Jul
> > > 2001
> > > 15:08:28)
> > > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > > Kurt,
> > > > >
> > > > > I take it from your comments that you would advocate such
> > > > > a procedure?  With all these drafts moving forward, maybe
> > > > > it's time to take another kick at this can.
> > > >
> > > > Yes, I think that such a procedure would be nice to have.
> > > >
> > > > /Kurt
> > > >
> > > >
> > > > >
> > > > >
> > > > > --Brian
> > > > >
> > > > > Kurt Kite wrote:                                     (Mon, 23 Jul
> 2001
> > > 10:36:33)
> > > > > > Hi,
> > > > > >
> > > > > > A similar subject has been discussed in the list. See the thread
> > > > > > "Management Blocking at the SG." The issue was can the SG
> > > > > > remove an AS from its configuration (static configuration case)?
> > > > > > Nothing was added to the draft to accomodate that kind of
> > > functionality.
> > > > > > The draft contends that the ASPs control the management of the
> ASs.
> > > > >
> > > > > Thanks for the pointer to the thread.  I read the thread and
> > > > > the discussion seemed to center around whether the SGP should
> > > > > be permitted to control ASP state.
> > > > >
> > > > > If the card has smoking components on it, I'm not going to call
> > > > > downtown to the MGC to get the card management inhibited at the
> > > > > control center.
> > > > >
> > > > > In my mind there is no question about it, when I go to pull an
> > > > > SG card the ASPs have two choices:
> > > > >
> > > > >         1)  they can either be forwarned of the impending loss
> > > > >             of associations between the SGP and them, or,
> > > > >
> > > > >         2)  they can go for a scurry after I pull the card.
> > > > >
> > > > > What the NTFY(SGP Blocking Pending) (or whatever) would accomplish
> > > > > is letting the ASPs know that they have the above choice.  The
> > > > > SGP would wait for a moment (while blinking the light on the
> > > > > cPCI card) and either the ASPs comply and go inactive on their
> > > > > own, or they can kiss goodbye to their associations.
> > > > >
> > > > > It will certainly be easier on ASP implementations if the
> > > > > ASP takes this NTFY as strong advice.
> > > > >
> > > > > >
> > > > > > More below.
> > > > > >
> > > > > > /Kurt
> > > > > >
> > > > > > "Brian F. G. Bidulock" wrote:
> > > > > >
> > > > > > > Maria,
> > > > > > >
> > > > > > > Given the SIGTRAN architecture, performing these functions at
> > > > > > > the AS might not be practical in the field.  Because the SG
> > > > > > > could be colocated with the MG and distributed at several
> > > > > > > locations (and a central MGC), it might not make too much
> > > > > > > sense to have to peform a (highly secure!) action on the
> > > > > > > remote MGC when wanting to pull a card on the MG/SG.
> > > > > > >
> > > > > > > Wouldn't it be simpler to have a NTFY message which the SGP
> > > > > > > could send to connected ASPs to ask them to withdraw traffic?
> > > > > >
> > > > > > Proposed in the thread mentioned above. In a nutshell: the NTFY
> > would
> > > > > > force the ASP to the INACTIVE state for one or more RCs. A new
> > status
> > > > > > would indicate that the reason was due "management blocking" at
> the
> > > SG.
> > > > > > The procedure for reactiving the RCs needs to be defined as
well.
> I
> > > don't
> > > think
> > > > > > the SG needs to indicate when the RCs are no longer blocked. I
> > prefer
> > > to
> > > have the
> > > > > > ASPs just try to reactive the RCs periodically. If the RCs are
> going
> > > to be
> > > down for
> > > > > > a long time then the proper procedure is to remove them from the
> > ASP.
> > > > >
> > > > > Agreed.  Sounds completely reasonable to me.
> > > > >
> > > > > Would anyone like to reiterate objections to this procedure?
> > > > >
> > > > > --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]
> > > >
> > > >
> > > >
> > > > ---
> > > > 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]
> > 
> > 
> > ---
> > 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]

-- 
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: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv7: SG redundancy
Date: Wed, 25 Jul 2001 09:33:47 -0700
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ztxmail04.ztx.compaq.com [161.114.1.208]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Maria,

	Redundant SGs provides a network level redundancy, an equivalent
concept to STPs.  A network reliability issue.

	Redundant SGP provides a "link" level redundancy, in this case,
multiple "links/associations" are needed for reliability and message
throughput.

John

-----Original Message-----
From: Srivats P. [mailto:[email-masked]] Sent: Wednesday, July 25,
2001 12:33 AM To: sigtran
Subject: Re: M3UAv7: SG redundancy

Maria,

Changing SG to SGP does not preclude SG level redundancy.
SG redundancy is still a valid option.

Srivats

At 7/24/01 7:11:00 PM, you wrote:
>Hi Greg,
>
>I think that from v.6 to v.7 with that 'change' from SG to SGP
>in many places, SG redundancy is not longer considered.
>
>However, I can still read in chapter 1.3.3, second parragraph:
>
>"...This can typically be achieved through the use of redundant SGPs or
>SGs, redundant hosts...."
>
>I think 'SGs' should be removed.
>
>
>Apart from that, in the same chapter it can be read:
>
>"..............................................A pair of signalling 
>gateway processes may represent, as an example, a single Signalling 
>Gateway, serving a signalling point management cluster."
>
>This doesn't correspond to the example in figure 1.
>
>/MCruz
>
>
>
>---
>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: Wed, 25 Jul 2001 09:33:54 -0700 (PDT)
From: Lyndon Ong <[email-masked]>
Subject: Re: m3ua status
To: "sigtran" <[email-masked]>
X-SMTP-HELO: web13903.mail.yahoo.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: web13903.mail.yahoo.com [216.136.175.29]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Jeff,

I fully agree with you that we need to put out a good specification, not
just A specification.  At the same time we need to resist the temptation to
keep tinkering
for the sake of incremental improvements.

I suppose what we ideally should do is focus down to what the critical
disagreements are and resolve those, at least to the level that we can
proceed ahead.

The issue of SGPs/SS7 NM seems to be one of these main disagreements, I'd
like to identify what others there are if any and focus on solely on
resolving these.

Cheers,

Lyndon

--- Jeff Copley <[email-masked]> wrote:
> Lyndon,
> 
> I understand that other organizations want to use
> M3UA and are anxious
> to have something firm that they can use.  They are
> also waiting on
> resolution of SCTP (last I checked).  I think we
> need to address their
> concerns, BUT, I think we also need to put out a
> standard that will be
> interpretted in just one way.  I would think that
> those organizations
> wanting a standard would prefer one without so many
> unresolved issues
> (and no, I didn't make a list).  
> 
> There are so many threads on M3UA regarding
> different interpretations
> that it is difficult keep up with them.  All the
> conversation is good
> with respect to working the issues, but how can we
> call M3UA ready for
> last call with so many issues?
> 
> Jeff
> 
> Lyndon Ong wrote:
> > 
> > Folks,
> > 
> > There continue to be numerous comments on M3UA v7,
> at the same time I have been getting messages from
> people or groups who are interested in using M3UA
> for their protocols and would like very much to have
> it completed.  In other words, we really need to get
> this finalized, so we should be focusing on actual
> errors, and pushing new functions or fine points
> into extension drafts.  Otherwise we may end up
> losing our "customers".
> > 
> > This being the case, can I poll the group to see
> if there are objections to moving M3UA v7 to IESG
> review/IETF Last Call?  Keep in mind that during
> IETF Last Call, you will have another opportunity to
> comment.
> > 
> > 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]> begin:vcard 
> n:Copley;Jeff
> tel;work:972.519.3758
> x-mozilla-html:FALSE
> org:Alcatel USA, Inc.
> version:2.1
> email;internet:[email-masked]
> adr;quoted-printable:;;1000 Coit Road=0D=0AMS
> NSGAP;Plano;Texas;75075-5813;USA
> x-mozilla-cpt:;20864
> fn:Jeff Copley
> end:vcard
> 
> 
> 
> > ---
> You are currently subscribed to sigtran as:
> [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
> 

__________________________________________________ Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Ong, Lyndon" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'"
<[email-masked]>,
        [email-masked]
Subject: Sigtran WG agenda
Date: Wed, 25 Jul 2001 09:47:15 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: wntcsdexg02.csd.ciena.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.96.78.12]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

Here's the agenda for the Sigtran WG
Meeting Tuesday, Aug. 7th 15:45-16:45 

Area: Transport (Scott Bradner, Allison Mankin, A-Ds) Chair: Lyndon Ong

-- Intro and Agenda Bash (5 min.)
-- Status of SCTP, M3UA, M2UA and AS (15 min.) -- Status of SUA and M2PA (10
min.)
-- V5UA Discussion (5 min.)
-- DUA (IUA extension) Discussion (5 min.) -- MIB Status Update (5 min.)
-- Bakeoff planning (10 min.)
-- Other issues (5 min.)

The documents are:
- draft-ietf-sigtran-m3ua-08.txt 
- draft-ietf-sigtran-m2ua-09.txt
- draft-ietf-sigtran-sua-07.txt
- draft-ietf-sigtran-m2pa-03.txt
- draft-ietf-sigtran-v5ua-01.txt
- draft-ietf-sigtran-dua-00.txt
- draft-ietf-sigtran-sctp-mib-04.txt
- draft-sigtran-m3ua-mib-01.txt

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 25 Jul 2001 12:03:09 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: [M3UA, SUA]: SGP Management (was: [M3UA, SUA]: Gracefull shut
down 
         of SGP)
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

Please see additional comments below...

Schantz, John wrote:                                     (Wed, 25 Jul 2001
09:23:59)
> Why Brian, I didn't expect you to give me "in the box" answers.
> 
> Comments below.
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 10:56 PM
> To: sigtran
> Subject: [M3UA, SUA]: SGP Management (was: [M3UA, SUA]: Gracefull
> shutdown of SGP)
> 
> 
> John,
> 
> Please see comments below...
> 
> Schantz, John wrote:                                     (Tue, 24 Jul 2001
> 11:19:58)
> > Brian,
> > 
> > 	No it is not.  Sending DUNAs, DAVAs, etc. from each SGP to each ASP
> > is not like how it is done in SS7.
> 
> Of course not.  SS7 does not define DUNA, DAVA, etc...
> 
> [John]  SS7 has TFP, TFA, etc.  Note that TFP ~ DUNA, different name but
the
> same purpose.  The point was that in SS7, each link interface does not
send
> a TFP to move traffic away from it self.  Hence, you have moved away from
> the basic SS7 philosophy.

Ahh, but DUNA, etc., are not just sent in response to TFP, they are also
sent when linksets go down.  They are sent internal to the SG/AS
architecture and that is what makes them different.

> 
> > A linkset is defined as ALL the links
> > (in our case associations) between two signaling points (in our case an
SG
> > and an AS);
> 
> An SG can represent more than one signalling point.  So can an AS.
> That is not the general case.  In the general case, the AS has
> the equivalent of multiple linksets to the SG.
> 
> [John]  Basic signalling points are defined by their point code.  If a
> signalling point supports another point code, it can support another
linkset
> to a remote node, but the remote node sees the 2 point codes as defining
> separate signalling points.

Although SS7 sees them as independent signalling points, they are not.
If TFP was like DUNA, the node could send 1 TFP with both point codes in it.

I notice that you skipped the alias signalling point assigned to two STPs.
Care to comment on that?

> 
> > and it doesn't matter how many SGPs or ASPs are involved.
> 
> Yes it does: particularly for the multiple point code SG/AS case above.
> Each SGP's ability to transfer messages is independent of the other
> SGPs.  The same is true for ASPs.  By nature a process is independent
> of other processes.
> 
> [John]  Stick to the base topic.  We talking about the single point code
> case.  In the communication from an AS to an SG, the number of SGPs or
ASPs
> are not an issue, especially at the network management level (SS7).

At the SGP/ASP management level the number is significant.  We are now
looking inside the SG/AS architecture, not out into the SS7 network.
The SGPs are not sending TFP to the network, they are sending DUNA internal
to the node.

> 
> The ASP currently has a procedure for managing routing in the
> SG->AS direction: Routing Keys, Routing Contexts and ASP Management
> procedures.
> 
> [John]  You're dragging ASP management to a higher level than it deserves.
> ASP management only establishes whether communication (messages) can occur
> on a specific path (the association).  Hence, it is really only a complex
> way of bringing a "link" in service.

No, the ASP has much finer control than a link: by becoming active or
inactive for a Routing Key/Context, it can precisely control the traffic it
receives from the SGP.  The SGP cannot do the same with traffic it receives
from the ASP.  The current situation is "Any Traffic" or "No Traffic".  This
is rather coarse and binary in comparison to Routing Keys which could get as
granular as the TCAP Transaction ID.

> 
> The SGP lack this ability.  It is required.  I don't care whether
> it is DUNA, DAVA, ... which are used or reverse Routing Keys, Routing
> Context and SGP Management procedures.  They could be identical to
> those already defined for the ASP, as they may be in an IPSP case.
> 
> [John]  What do you think the layer management is for.  We really are only
> talking about a link.

No, we are talking about a sequenced traffic flow from the ASP which may
only be part of an SLS stream, far less a link.

> 
> > An
> > SS7 point code normally has more than one linkset BUT they are to
> different
> > nodes as defined by an SS7 point code.
> 
> That is not completely true.  It is normal to assign multiple point
> codes to large switches.  Linksets may go to multiple point codes which
> are really the same node.  In this case SS7 network management procedures
> treat the switch as multiple SS7 signalling points (one per point code)
> when it is really only one node.
> 
> [John]  No this is completely true.  A pair of point codes defines the end
> points of a linkset.  Multiple linksets is only possible via multiple
> physical points codes.  Please stop trying to cloud the issue with
multiple
> point codes.  This all degenerates down to a signaling point is a point
> code.

Traffic management concerns point codes which are not adjacent.  The DUNA,
DAVA that we are talking about concerns remote point codes as well as
adjacent.  It is not clouding the issue.

> 
> It is also not true for alias point codes assigned to GTT function
> in STP pairs.  When alias point codes are assigned to STPs in this
> fashion, an SS7 signalling point does not directly correspond to a
> signalling node.  It is a virtual signalling point which "appears"
> to be behind the STPs.  MTP network management procedures have no
> difficulty in accomodating this concept.  Your statements only really
> apply to adjacent signalling points, a severe subset of the MTP network
> and traffic management behavior.
> 
> [John]  Its always nice to hear your own inventions quoted.  You missed
the
> point that an alias point code is a virtual point code not a physical
point
> code.

It is still involed in traffic management which is what we are talking
about.

> 
> > Therefore a SGP which gets its point
> > code from the SG does qualify as a node and therefore it can not have a
> > linkset (unless it is the only one) and therefore it can have no route
by
> > SS7 definition.
> 
> On the SS7 side.  On the IP side we are splitting traffic flows from
> various linksets by routing key.  Unless RK == linkset, those traffic
> flows are independent of linkset.  The ASP is managing those traffic flows
> using ASP Management procedures.  The SGP needs to manage those traffic
> flows from its end with similar procedures.  In the M3UA spec, the SGP
> can use DUNA, DAVA, ... to achieve that mangement at least on a per
> point code basis, per ASP.
> 
> [John]  I don't agree with this usage of the DUNA, DAVA, ...  These are
> message equivalents to the SS7 network management messages, TFP, TFA, ...
> They should not be used for double duty.  Only in the cases where you are
> break up the RK to be finer than a point code might you need something BUT
> you should not reuse the network management level messages to do it.  My
> node will not require a RK that is finer than a PC, therefore it does not
> require this link-level management.  I would think that for most existing
> SS7 nodes, a RK = PC is sufficient.

But M3UA supports RK < PC, and must accomodate this case or preclude it.

Ok.  Don't reuse the NM messages.  Add the ability for the SGP to perform
the symmetrical management functions to the ASP management functions.

> 
> Separate SGP management procedures which had more granular control
> than a whole point code would be better.
> 
> [John]  I think I already made my case above.  Define some other option
> message set to cover the case where RKs are finer than a PC (or are we now
> stepping on SCCP's toes).

Here they are:

	SGPUP
	SGPUP Ack
	SGPDN
	SGPDN Ack
	SGPAC
	SGPAC Ack
	SGPIA
	SGPIA Ack
	REG REQ
	REG RSP
	DEREG REQ
	DEREG RSP

> 
> > 
> > John
> > 
> > PS.  I am very familiar with SS7.  I was one of the original people that
> > started defining the ANSI SS7 protocol in 1984.  I have served as
> > editor/author of T1.111.5, T1.111.6, and T1.111.8.  I have been the
> convener
> > of SCCP and I now serve as the editor for T1.112.4.
> 
> You had the easy part.  I had to make it work in a national telephone
> network.  There are a lot of people who contribute to this WG who have
> extensive experience with SS7.  I am sure that most of our achievements
> in that respect pale in comparison to the likes of Al Varney.
> 
> [John]  Maybe and maybe not.  Al, I'm sorry that Brian used your name in
> vain.

I was saying that your and my accomplishments pale in comparison to Al's.

> 
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Tuesday, July 24, 2001 11:41 AM
> > To: sigtran
> > Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> > 
> > 
> > John,
> > 
> > The way we do it in SS7 is to keep track of routing on
> > an individual linkset basis.  An SS7 point code normally
> > has more than one linkset, and so must keep track of
> > routeset available on a per-linkset basis.  Because
> > TFP, TFA and TFR are always sent only to adjacent SPs,
> > they only apply to the linkset upon which they are
> > received.
> > 
> > There is nothing different between the M3UA-07 approach
> > and that of normal MTP routing within a Siganlling Point.
> > 
> > --Brian
> > 
> > Schantz, John wrote:                                     (Tue, 24 Jul
2001
> > 09:27:41)
> > > Brian,
> > > 
> > > 	NO, its an "all or nothing" concept.  This is the way it works in
> > > SS7.  We do not give network management controls to individual links.
> > > 
> > > John
> > > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Tuesday, July 24, 2001 10:46 AM
> > > To: sigtran
> > > Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> > > 
> > > 
> > > John,
> > > 
> > > While we're on the subject, if the SGP is permitted to
> > > send ASP Inactive, why should it not also be permitted
> > > to send ASP Inactive for a restricted set of routing
> > > contexts?
> > > 
> > > --Brian
> > > 
> > > Schantz, John wrote:                             (Tue, 24 Jul 2001
> > 08:17:34)
> > > > Dan,
> > > > 
> > > > 	I like the idea of a symmetric protocol.  Sending
ASP-INACTIVE is
> > > > better than trying to use NTFY to do it.
> > > > 
> > > > John
> > > > 
> > > > -----Original Message-----
> > > > From: Dan Brendes [mailto:[email-masked]]
> > > > Sent: Monday, July 23, 2001 5:51 PM
> > > > To: sigtran
> > > > Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> > > > 
> > > > 
> > > > 
> > > > 
> > > > I definitely agree that both sides need to be able to allow/prohibit
> > > traffic
> > > > and
> > > > support graceful shutdown as per local management.
> > > > 
> > > > I think there are multiple messages the SGP could send to the ASP to
> > > inform
> > > > it
> > > > that an association is being locally inhibited/blocked, and it
doesn't
> > > > really
> > > > matter which we pick as long as it is clearly described in the spec.
> > > > Notify(blocking) will work, but not necessarily any better or worse
> than
> > > > ASP-INACTIVE-ACK(blocked) or ASP-INACTIVE(blocked) in my opinion.
> Since
> > > the
> > > > SGP
> > > > is restricted from sending ASP-INACTIVE according to the current
> wording
> > > in
> > > > section 3.7.3 of m3ua-07 it could send ASP-INACTIVE-ACK(blocking) to
> > > notify
> > > > the
> > > > ASP that the state of the connection is moving from ASP-ACTIVE to
> > > > ASP-INACTIVE.
> > > > Better yet, why not create a symmetric protocol where either side of
> the
> > > > connection can send ASP-INACTIVE (change the wording of the 1st
> sentence
> > > in
> > > > 3.7.3).
> > > > 
> > > > Allowing the SGP to prohibit traffic will also have implications on
> > > > processing
> > > > ASP-ACTIVE messages when locally prohibited.  I would propose that
the
> > SGP
> > > > returns ASP-INACTIVE-ACK(blocked) in response to an ASP-ACTIVE
message
> > in
> > > > that
> > > > situation.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > "Brian F. G. Bidulock" <[email-masked]> on 07/23/2001 05:42:45
> PM
> > > > 
> > > > Please respond to [email-masked]
> > > > 
> > > > To:   "sigtran" <[email-masked]>
> > > > cc:   [email-masked] (bcc: Dan
> Brendes/Raleigh/TEKELEC)
> > > > Subject:  Re: [M3UA, SUA]: Gracefull shutdown of SGP
> > > > 
> > > > 
> > > > 
> > > > 
> > > > All,
> > > > 
> > > > Does anyone object to this procedure?
> > > > 
> > > > Kurt Kite wrote:                                             (Mon,
23
> > Jul
> > > > 2001
> > > > 15:08:28)
> > > > > "Brian F. G. Bidulock" wrote:
> > > > >
> > > > > > Kurt,
> > > > > >
> > > > > > I take it from your comments that you would advocate such
> > > > > > a procedure?  With all these drafts moving forward, maybe
> > > > > > it's time to take another kick at this can.
> > > > >
> > > > > Yes, I think that such a procedure would be nice to have.
> > > > >
> > > > > /Kurt
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > --Brian
> > > > > >
> > > > > > Kurt Kite wrote:                                     (Mon, 23
Jul
> > 2001
> > > > 10:36:33)
> > > > > > > Hi,
> > > > > > >
> > > > > > > A similar subject has been discussed in the list. See the
thread
> > > > > > > "Management Blocking at the SG." The issue was can the SG
> > > > > > > remove an AS from its configuration (static configuration
case)?
> > > > > > > Nothing was added to the draft to accomodate that kind of
> > > > functionality.
> > > > > > > The draft contends that the ASPs control the management of the
> > ASs.
> > > > > >
> > > > > > Thanks for the pointer to the thread.  I read the thread and
> > > > > > the discussion seemed to center around whether the SGP should
> > > > > > be permitted to control ASP state.
> > > > > >
> > > > > > If the card has smoking components on it, I'm not going to call
> > > > > > downtown to the MGC to get the card management inhibited at the
> > > > > > control center.
> > > > > >
> > > > > > In my mind there is no question about it, when I go to pull an
> > > > > > SG card the ASPs have two choices:
> > > > > >
> > > > > >         1)  they can either be forwarned of the impending loss
> > > > > >             of associations between the SGP and them, or,
> > > > > >
> > > > > >         2)  they can go for a scurry after I pull the card.
> > > > > >
> > > > > > What the NTFY(SGP Blocking Pending) (or whatever) would
accomplish
> > > > > > is letting the ASPs know that they have the above choice.  The
> > > > > > SGP would wait for a moment (while blinking the light on the
> > > > > > cPCI card) and either the ASPs comply and go inactive on their
> > > > > > own, or they can kiss goodbye to their associations.
> > > > > >
> > > > > > It will certainly be easier on ASP implementations if the
> > > > > > ASP takes this NTFY as strong advice.
> > > > > >
> > > > > > >
> > > > > > > More below.
> > > > > > >
> > > > > > > /Kurt
> > > > > > >
> > > > > > > "Brian F. G. Bidulock" wrote:
> > > > > > >
> > > > > > > > Maria,
> > > > > > > >
> > > > > > > > Given the SIGTRAN architecture, performing these functions
at
> > > > > > > > the AS might not be practical in the field.  Because the SG
> > > > > > > > could be colocated with the MG and distributed at several
> > > > > > > > locations (and a central MGC), it might not make too much
> > > > > > > > sense to have to peform a (highly secure!) action on the
> > > > > > > > remote MGC when wanting to pull a card on the MG/SG.
> > > > > > > >
> > > > > > > > Wouldn't it be simpler to have a NTFY message which the SGP
> > > > > > > > could send to connected ASPs to ask them to withdraw
traffic?
> > > > > > >
> > > > > > > Proposed in the thread mentioned above. In a nutshell: the
NTFY
> > > would
> > > > > > > force the ASP to the INACTIVE state for one or more RCs. A new
> > > status
> > > > > > > would indicate that the reason was due "management blocking"
at
> > the
> > > > SG.
> > > > > > > The procedure for reactiving the RCs needs to be defined as
> well.
> > I
> > > > don't
> > > > think
> > > > > > > the SG needs to indicate when the RCs are no longer blocked. I
> > > prefer
> > > > to
> > > > have the
> > > > > > > ASPs just try to reactive the RCs periodically. If the RCs are
> > going
> > > > to be
> > > > down for
> > > > > > > a long time then the proper procedure is to remove them from
the
> > > ASP.
> > > > > >
> > > > > > Agreed.  Sounds completely reasonable to me.
> > > > > >
> > > > > > Would anyone like to reiterate objections to this procedure?
> > > > > >
> > > > > > --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]
> > > > >
> > > > >
> > > > >
> > > > > ---
> > > > > 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]
> > > 
> > > 
> > > ---
> > > 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]
> 
> -- 
> 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]

-- 
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, 25 Jul 2001 12:06:14 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: m3ua status
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Lyndon,

(Before Barry jumps in...) you can certainly add correlation of Error
messages to the list.

(You _were_ making a list, weren't you?)

--Brian

Lyndon Ong wrote:                                          (Wed, 25 Jul 2001
09:33:54)
> Jeff,
> 
> I fully agree with you that we need to put out a good
> specification, not just A specification.  At the same
> time we need to resist the temptation to keep
> tinkering
> for the sake of incremental improvements.
> 
> I suppose what we ideally should do is focus down to 
> what the critical disagreements are and resolve those,
> at least to the level that we can proceed ahead.
> 
> The issue of SGPs/SS7 NM seems to be one of these
> main disagreements, I'd like to identify what others
> there are if any and focus on solely on resolving
> these.
> 
> Cheers,
> 
> Lyndon
> 
> --- Jeff Copley <[email-masked]> wrote:
> > Lyndon,
> > 
> > I understand that other organizations want to use
> > M3UA and are anxious
> > to have something firm that they can use.  They are
> > also waiting on
> > resolution of SCTP (last I checked).  I think we
> > need to address their
> > concerns, BUT, I think we also need to put out a
> > standard that will be
> > interpretted in just one way.  I would think that
> > those organizations
> > wanting a standard would prefer one without so many
> > unresolved issues
> > (and no, I didn't make a list).  
> > 
> > There are so many threads on M3UA regarding
> > different interpretations
> > that it is difficult keep up with them.  All the
> > conversation is good
> > with respect to working the issues, but how can we
> > call M3UA ready for
> > last call with so many issues?
> > 
> > Jeff
> > 
> > Lyndon Ong wrote:
> > > 
> > > Folks,
> > > 
> > > There continue to be numerous comments on M3UA v7,
> > at the same time I have been getting messages from
> > people or groups who are interested in using M3UA
> > for their protocols and would like very much to have
> > it completed.  In other words, we really need to get
> > this finalized, so we should be focusing on actual
> > errors, and pushing new functions or fine points
> > into extension drafts.  Otherwise we may end up
> > losing our "customers".
> > > 
> > > This being the case, can I poll the group to see
> > if there are objections to moving M3UA v7 to IESG
> > review/IETF Last Call?  Keep in mind that during
> > IETF Last Call, you will have another opportunity to
> > comment.
> > > 
> > > 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]>
> begin:vcard 
> > n:Copley;Jeff
> > tel;work:972.519.3758
> > x-mozilla-html:FALSE
> > org:Alcatel USA, Inc.
> > version:2.1
> > email;internet:[email-masked]
> > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
> > NSGAP;Plano;Texas;75075-5813;USA
> > x-mozilla-cpt:;20864
> > fn:Jeff Copley
> > end:vcard
> > 
> > 
> > 
> > > ---
> > You are currently subscribed to sigtran as:
> > [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
> 
> 
> ---
> 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, 25 Jul 2001 12:36:29 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Ken Morneault <[email-masked]>, Greg Sidebottom <[email-masked]>,
        John Loughney <[email-masked]>
Subject: M2UAv0, M3UAv8, SUAv7: Traffic Mode Type
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken, Greg, John,

Traffic Mode Type is a mandatory paramter of ASPAC and REG REQ in all the
UAs.  Because the Traffic Mode Type has only a restricted range of modes,
does it not make sense to permit ASPs and SGPs to use other traffic modes
other than those specified in the drafts?  In the case where SGP and ASP
have been configured for the traffic mode by other means, shouldn't the
Traffic Mode Type be Optional in these messages?

The text says that they MUST match, but if it is left out and the ASP and
SGP agree by prior arrangement, it doesn't need to be in the message at all.

--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]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: NTFY Insufficient ASP resources active in AS
Date: Wed, 25 Jul 2001 20:47:22 +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: mgw-x4.nokia.com [131.228.20.27]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

This could get complicated - what is the minimum ASP resources active in an
AS?  Could it be 1, 2, 3 ... I think that we should just engineer for the
worst case - let's say 1 remaining.

However, anyone want to contribute text for this?  We should make it common
to all the UAs.

John

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 23 July, 2001 12:12
> To: sigtran
> Cc: Greg Sidebottom; Ken Morneault; Loughney John (NRC/Helsinki)
> Subject: Re: NTFY Insufficient ASP resources active in AS
> 
> 
> Vikas,
> 
> I like your wording: "Minimum ASP resources active in AS".
> It is perfectly descriptive and fits the case I describe.
> 
> Any comments?
> 
> --Brian
> 
> Vikas wrote:                                 (Mon, 23 Jul 
> 2001 09:01:14)
> 
> > yeah brian,
> 
> > i was also seeing the need of another notify message: 
> NTFY("Minimum ASP
> > resources active in AS.").
> > 
> > Regards,
> > Vikas.
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Thursday, July 19, 2001 7:43 AM
> > Subject: NTFY Insufficient ASP resources active in AS
> > 
> > 
> > > All,
> > >
> > > I still cannot see the point in notifying the ASPs *after*
> > > there are not enough active ASPs to take the load.  This
> > > will just force the SG to buffer and possibly fail in all
> > > cases of inadvertent deactivation of an ASP.
> > >
> > > Why can we not notify *before*.  That is, notify when the
> > > AS is running with no protection (i.e. the "n+0" case instead
> > > of the "(n-1)+0" case).  This would permit an inactive ASP
> > > which has inadvertently gone inactive to bring itself back
> > > on-line without failure.
> > >
> > > I'm really struggling with this in implementation: because
> > > it is possible that the ASPs may lose communication with
> > > each other, they may no longer be aware of the number of
> > > ASPs which are running in an AS.  The SG(P) has this
> > > information.  Why can it not communicate the information
> > > to the ASPs for the AS for which they are configured (as part
> > > of the ASP Up Ack or a separate NTFY before the ASP Up Ack)
> > > or for which they are registered (as part of the REG RSP or
> > > in a separate NTFY before the REG RSP is sent).
> > >
> > > Also, often in telecommunications systems, going to one's
> > > knees is far preferrable to croaking.  Why cannot the SG
> > > report insufficient ASPs without shutting down traffic?
> > > Setting "n=1" is not a solution, because it does not
> > > indicate to the ASPs when they are vulnerable.
> > >
> > > It makes sense to me that the SG would communicate all the
> > > state information that it has at its disposal regarding the
> > > ASs and ASPs to the ASPs with which it communicates.
> > >
> > >
> > > --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]
> > >
> > 
> > 
> > 
> > ---
> > 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]
Date: Wed, 25 Jul 2001 13:02:53 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: NTFY Insufficient ASP resources active in AS
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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

"Minimum resources active in AS" is one more than the number that triggers
the existing "Insufficient ASP resources active in AS".
Following are the text changes (mostly borrowed from M2UA) to handle both
the ASP Failure and Minimum resources active in AS cases.

   If the Status Type is Other", then the following Status Information 
   values are defined: 
    
          1    Insufficient ASP resources active in AS 
          2    Alternate ASP Active 
+	  3    ASP Failure
+	  4    Minimum ASP resources active in AS
              
-  These notifications are not based on the SGP reporting the state -
change of an ASP or AS.  In the Insufficient ASP Resources case, the -  SGP
is indicating to an "Inactive" ASP(s) in the AS that another ASP -  is
required 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.   
    
+  In the Insufficient ASP Resources case, the SGP is indicating to an +
ASP-INACTIVE ASP(s) in the AS that another ASP is required to handle +  the
load of the AS (Load-sharing and Broadcast mode).  For the +  Alternate ASP
Active case, the formerly Active ASP is informed when +  an alternate ASP
transisions to the ASP Active state in Override mode.
+  The ASP ID (if available) of the Alternate ASP MUST be placed in the +
message.  For the ASP Failure case, the SGP is indicating to ASP(s) +  in
the AS that one of the ASPs has failed (i.e. the ASP Transition to +  Down
due to SCTP Communication Down Indication).  The ASP ID (if +  available) of
the failed ASP MUST be placed in the message.  In the +  Minimum ASP
resources active in AS case, the SGP is indicating to an +  ASP-INACTIVE
ASP(s) that the failure of one of the ASPs currently in +  the ASP-ACTIVE
state would result in the Insufficient ASP Resources +  case and that the AS
would enter the AS-PENDING state if such a +  failure occured.

--Brian

John Loughney wrote:                                         (Wed, 25 Jul
2001 20:47:22)
> This could get complicated - what is the minimum ASP resources
> active in an AS?  Could it be 1, 2, 3 ... I think that we should
> just engineer for the worst case - let's say 1 remaining.
> 
> However, anyone want to contribute text for this?  We should
> make it common to all the UAs.
> 
> John
> 
> > -----Original Message-----
> > From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: 23 July, 2001 12:12
> > To: sigtran
> > Cc: Greg Sidebottom; Ken Morneault; Loughney John (NRC/Helsinki)
> > Subject: Re: NTFY Insufficient ASP resources active in AS
> > 
> > 
> > Vikas,
> > 
> > I like your wording: "Minimum ASP resources active in AS".
> > It is perfectly descriptive and fits the case I describe.
> > 
> > Any comments?
> > 
> > --Brian
> > 
> > Vikas wrote:                                 (Mon, 23 Jul 
> > 2001 09:01:14)
> > 
> > > yeah brian,
> > 
> > > i was also seeing the need of another notify message: 
> > NTFY("Minimum ASP
> > > resources active in AS.").
> > > 
> > > Regards,
> > > Vikas.
> > > ----- Original Message -----
> > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > To: "sigtran" <[email-masked]>
> > > Sent: Thursday, July 19, 2001 7:43 AM
> > > Subject: NTFY Insufficient ASP resources active in AS
> > > 
> > > 
> > > > All,
> > > >
> > > > I still cannot see the point in notifying the ASPs *after*
> > > > there are not enough active ASPs to take the load.  This
> > > > will just force the SG to buffer and possibly fail in all
> > > > cases of inadvertent deactivation of an ASP.
> > > >
> > > > Why can we not notify *before*.  That is, notify when the
> > > > AS is running with no protection (i.e. the "n+0" case instead
> > > > of the "(n-1)+0" case).  This would permit an inactive ASP
> > > > which has inadvertently gone inactive to bring itself back
> > > > on-line without failure.
> > > >
> > > > I'm really struggling with this in implementation: because
> > > > it is possible that the ASPs may lose communication with
> > > > each other, they may no longer be aware of the number of
> > > > ASPs which are running in an AS.  The SG(P) has this
> > > > information.  Why can it not communicate the information
> > > > to the ASPs for the AS for which they are configured (as part
> > > > of the ASP Up Ack or a separate NTFY before the ASP Up Ack)
> > > > or for which they are registered (as part of the REG RSP or
> > > > in a separate NTFY before the REG RSP is sent).
> > > >
> > > > Also, often in telecommunications systems, going to one's
> > > > knees is far preferrable to croaking.  Why cannot the SG
> > > > report insufficient ASPs without shutting down traffic?
> > > > Setting "n=1" is not a solution, because it does not
> > > > indicate to the ASPs when they are vulnerable.
> > > >
> > > > It makes sense to me that the SG would communicate all the
> > > > state information that it has at its disposal regarding the
> > > > ASs and ASPs to the ASPs with which it communicates.
> > > >
> > > >
> > > > --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]
> > > >
> > > 
> > > 
> > > 
> > > ---
> > > 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]

-- 
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]>
Cc: [email-masked], [email-masked]
Subject: RE: Common ASP Management Procedures
Date: Wed, 25 Jul 2001 21:03: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,

> Is there any reason why there should not be a common set
> of ASP management procedures among the UAs?
> 
> If it was possible, I'd really like to write this stuff once.

I'd suggest that would be an honorable goal.  Maybe we can meet in London &
write it once :)

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Wed, 25 Jul 2001 13:20:11 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: m3ua status
X-SMTP-HELO: imr1.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr1.ericy.com [208.237.135.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi,

IMOH, I don't think issues 1 and 2 below should prevent moving M3UA to last
call. Issue 3 is more important but it only comes into play in error
situations and if not resolved would only probably result in repeated
attempts to activate/inactive ASs, i.e., just some extra "noise."

Regards,
Kurt

[email-masked] wrote:

> Lyndon,
>
> I object to moving M3UA v7 to IESG review/IETF Last Call.
>
> Please see below an excerpt from Kurt Kite's email from July 19 in which
> he lists three very important issues that were raised at the bakeoff in
> Madrid and were not addressed in v7:
>
> Issues Raised at the Interoperability Test in Madrid
> ----------------------------------------------------
>
> The following issues were raised an the interoperability
> test in Madrid and have not been addressed in version 7.
> I have not included the issue of sending SCON from an ASP to
> an SGP because you have already indicated that this was
> intentionally not addressed.
>
> 1.  One of the issues raised at the interoperability test in
>     Madrid was a lack of procedures for when an AS loses
>     connectivity with an SGP, similar to the MTP restart
>     procedures. It was also felt that the MTP restart
>     procedures would need to be coordinated with the "AS
>     restart" procedures.
>
> 2.  One of the issues raised at the interoperability test
>     in Madrid was multiple occurances of the same parameter
>     in a message. My recollection is that most participants
>     were not in favor of supporting this featuer. The draft
>     should clearly state whether this feature MUST, SHOULD,
>     or MUST NOT, be supported.
>
> 3.  One of the issues raised at the interoperability test
>     in Madrid was correlation of error messages. Version 7
>     has partially addressed the concerns by mandating
>     diagnostic information in some cases, e.g., invalid
>     network appearance. However, it does not mandate the
>     format of the diagnostic information. The draft should
>     clearly indicate the contents of the diagnostics
>     information. One proposal is that the error message always
>     includes the diagnostics which contains the offending
>     message (not just the first 40 bytes) and the offending
>     parameter when necessary. Here is some sample text:
>
>     The Error message contains the following parameters:
>
>          Error Code                 Mandatory
>          Offending Message          Mandatory
>          Offending Parameter        Optional
>          Diagnostic Information     Optional
>
>     The format for the Error message 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 = 0x0c           |            Length             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                          Error Code                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Tag = 0x??           |            Length             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        \                                                               \
>        /                     Offending Message                         /
>        \                                                               \
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Tag = 0x??           |            Length             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                     Offending Parameter Value                 |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Tag = 0x07           |            Length             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        \                                                               \
>        /                     Diagnostic Information                    /
>        \                                                               \
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Offending Message: variable length
>
>        The Offending Message parameter contains the entire erroneous
>        message.
>
>     Offending Parameter Value: 32-bits (unsigned integer)
>
>        The optional Offending Parameter Value parameter
>        contains the value of the erroneous parameter. The
>        Offending Parameter Value must be included when the
>        erroneous parameter can contain multiple values,
>        e.g., routing context.
>
>     Diagnostic Information: variable length
>
>        When included, the optional Diagnostic information can be any
>        information germane to the error condition, to assist in
>        identification of the error condition.
>
> Barry Nagelberg
> Software Engineer
> RadiSys, Corp.
> Signaling Products Design Center
> [email-masked]
> +1-856-642-9229 x237
>
> Lyndon Ong <[email-masked]>
> 07/24/01 04:43 PM
> Please respond to sigtran
>
>
>         To:     "sigtran" <[email-masked]>
>         cc:
>         Subject:        m3ua status
>
> Folks,
>
> There continue to be numerous comments on M3UA v7, at the same time I have
> been getting messages from people or groups who are interested in using
> M3UA for their protocols and would like very much to have it completed. In
> other words, we really need to get this finalized, so we should be
> focusing on actual errors, and pushing new functions or fine points into
> extension drafts.  Otherwise we may end up losing our "customers".
>
> This being the case, can I poll the group to see if there are objections
> to moving M3UA v7 to IESG review/IETF Last Call?  Keep in mind that during
> IETF Last Call, you will have another opportunity to comment.
>
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 25 Jul 2001 13:20:32 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UAv0, M3UAv8, SUAv7: Traffic Mode Type
Reply-To: [email-masked]
Mail-Followup-To: 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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken, Greg, John,

In addition, what is the purpose of a mandatory Traffic Mode Type in the ASP
Active Ack?  Was it expected that this Traffic Mode Type would reflect the
Traffic Mode of the SGP to the ASP?  (Which would be excellent!)  Or was it
just an echo of the ASP Active message?  What does an ASP do if the
mandatory Traffic Mode Type in the ASP Active Ack message does not match
what was sent?  Should not this parameter be Optional?

--Brian

Brian F. G. Bidulock wrote:                 (Wed, 25 Jul 2001 12:36:29)
> Ken, Greg, John,
> 
> Traffic Mode Type is a mandatory paramter of ASPAC and REG REQ in all
> the UAs.  Because the Traffic Mode Type has only a restricted range
> of modes, does it not make sense to permit ASPs and SGPs to use other
> traffic modes other than those specified in the drafts?  In the case
> where SGP and ASP have been configured for the traffic mode by other
> means, shouldn't the Traffic Mode Type be Optional in these messages?
> 
> The text says that they MUST match, but if it is left out and the
> ASP and SGP agree by prior arrangement, it doesn't need to be in the
> message at all.
> 
> --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]

-- 
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, 25 Jul 2001 13:56:36 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Ken Morneault <[email-masked]>, Greg Sidebottom <[email-masked]>,
        John Loughney <[email-masked]>
Subject: UAs: Parameters in Ack versions of ASP management messages
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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken, Greg, John,

Maybe this question has been asked before, but what is the purpose of the
returned mandatory parameters the Ack versions of these messages.  I can
understand that Routing Context and Interface Identifiers are used to
correlate the forward message with the Ack, but what is the purpose to
returning Traffic Mode Type, and (in SUA's case) ASP Id and ASP
Capabilities.

Was this intended to just allow the SGP to overwrite the message type for
the reply?  Or was it intended to reflect SGP traffic mode, id and
capabilities?  Or was it intended to allows the SGP to negotiate ASP mode,
id, and capabilities?

--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: Wed, 25 Jul 2001 14:11:36 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: John Loughney <[email-masked]>
Subject: SUAv7: ASP Capablities
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

What is the point of the ASP Capabilities parameter?  Certainly all of the
Routing Context information must be provisioned in the SGP and the ASPs
capabilities can be known to the SGP in the same fashion.  Is not the SS7
interworking situation and protocol class implicit in the Routing Context?
Is there some use for it?

ASP Capablities sounds like more of a registration item.  Which leads me to
my next question: Why doesn't SUA support a registration/ deregistration
procedure?  Certainly Subsystem Number and ASP Capabilities sound like
reasonable Routing Keys.  Even SRN ranges or TIDs make sense as well.

--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: Wed, 25 Jul 2001 14:27:15 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>,
        John Loughney <[email-masked]>
Subject: SUAv7, M3UAv8: Heartbeat Procedures
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg, John,

Were the heartbeat procedures going to be updated?  Certainly there is no
reason why an SGP should not be able to send BEAT and expect BEAT ACK, even
if it has not yet received ASP UP.  BEAT may be the only way that the SGP
has of identifying a "dead" ASP which is holding open an association but is
never going to send ASP UP.
The SGP could clearly drop the association if the BEAT Ack doesn't come back
per the procedure.

Was there some common text for this procedure?  Was it going to be included
in SUA and M3UA?

--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]
X-Lotus-FromDomain: TEKELEC
From: Dan Brendes <[email-masked]>
To: "sigtran" <[email-masked]>
Date: Wed, 25 Jul 2001 15:36:37 -0400
Subject: Re: M2UAv0, M3UAv8, SUAv7: Traffic Mode Type
X-SMTP-HELO: domino2.nc.tekelec.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [198.89.40.41]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

I like where Brian is going on this one.  If the SG receives an ASP-ACTIVE
with a traffic mode the SG does not support
I believe a valid and useful response would be to return ERROR(Invalid
traffic mode) followed by an acknowledgement
message that shows what traffic mode the SG does support and which state the
SG believes the ASP to be in.

ex:
from the ASP-INACTIVE state...
ASP->SGP  ASP-ACTIVE(Override)
SGP->ASP  ERROR(traffic mode)
          ASP-INACTIVE-ACK(Loadshare)         // SG is staying in
ASP-INACTIVE state
                                         // only mode supported is loadshare
The acknowledgement would need to be an ASP-INACTIVE-ACK since the
ASP-ACTIVE could not be executed at the SG.

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

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:    (bcc: Dan
Brendes/Raleigh/TEKELEC) Subject:  Re: M2UAv0, M3UAv8, SUAv7: Traffic Mode
Type

Ken, Greg, John,

In addition, what is the purpose of a mandatory Traffic Mode Type in the ASP
Active Ack?  Was it expected that this Traffic Mode Type would reflect the
Traffic Mode of the SGP to the ASP?  (Which would be excellent!)  Or was it
just an echo of the ASP Active message?  What does an ASP do if the
mandatory Traffic Mode Type in the ASP Active Ack message does not match
what was sent?  Should not this parameter be Optional?

--Brian

Brian F. G. Bidulock wrote:                 (Wed, 25 Jul 2001 12:36:29)
> Ken, Greg, John,
>
> Traffic Mode Type is a mandatory paramter of ASPAC and REG REQ in all
> the UAs.  Because the Traffic Mode Type has only a restricted range
> of modes, does it not make sense to permit ASPs and SGPs to use other
> traffic modes other than those specified in the drafts?  In the case
> where SGP and ASP have been configured for the traffic mode by other
> means, shouldn't the Traffic Mode Type be Optional in these messages?
>
> The text says that they MUST match, but if it is left out and the
> ASP and SGP agree by prior arrangement, it doesn't need to be in the
> message at all.
>
> --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]

--
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: Wed, 25 Jul 2001 14:37:06 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>,
        John Loughney <[email-masked]>
Subject: M3UAv8, SUAv7: SGP sending ASP Down/Ack
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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg, John,

The SUA draft still has the SGP capable of sending ASP Down to the ASP to
push the ASP to the down state.  This characteristic was (I believe) removed
from M3UA.  Shouldn't we strive for consistency here?

   4.4.2.2 ASP-Down 

   ...
    
   The IPSP will send an ASP DOWN message whenever it wants to take 
   down an ASP. Since it is possible for ASP DOWN and ASP DOWN Ack 
   messages to be lost (for example, during a node failover), the IPSP 
   can send ASP DOWN messages repeatedly until the path comes down 
   (i.e. until it receives a ASP-DOWN message from the remote peer or 
   the SCTP association goes down). 

--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: Wed, 25 Jul 2001 14:50:10 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: M3UAv8: loss/duplication of messages
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

When an association fails, how is the SGP or ASP to know which messages have
been successfully processed by the other end so that it does not lose or
duplicate messages?

Certainly the failure of only one association between SGP and ASP should not
result in message loss or duplication.

--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]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: m3ua status - proposal for moving forward
Date: Wed, 25 Jul 2001 15:24:48 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: zcamail05.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zcamail05.zca.compaq.com [161.114.32.105]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi everybody,

	I would like to make a proposal for moving M3UA forward.  I think we
should pull back and see what is required right now.  We need a version of
M3UA that will work with the existing SS7 networks (I am coming from an SS7
network point-of-view).    I am talking about replacing regular SS7
transport between 2 existing SS7 nodes with IP transport.  These nodes are
still supporting the current SS7 fundamentals.  We must do this without
affecting the SS7 network or changing how the signalling end-point views the
network.

	There have been many "enhancements" added or philosophical changes
made in the last several months that are not required to work with an
existing SS7 network.  IMHO, many of these should be reworked because their
solutions have broken basic SS7 fundamentals. 

	The M3UA that we need now must do the following:

1) We must be able to transport MTP-user messages.

2) We need to maintain MTP-level routing principles.  

Routing on PC between signalling points is all that is required now.  That
is, Routing Key/Context is only needed at the point code level right now.
DPC + ? and the associated procedures to support this are not needed now.
This can be added in a future version.  

Signalling point information is statically assigned, hence, the
registration/deregistration of RK/RC is not required now.  This can be added
in a future version.

3) We need to maintain the node/network level management philosophy.  

This means that network management messages (DUNA, DAVA, etc.) are
interpreted at the SG and AS level.  This is required so that we do not
create any interworking issues.  Network operators need to know that this
philosophy has not changed.  

Managing SGPs and ASP at a routing level is an enhancement that is not
required now.  Its solutions also must be solved without using the existing
network management messages.  This enhancement can be added in a future
version.

The bottom line:  Clean up the M3UA draft to contain what is required now.
Some of the enhancements can be marks as optional or for further study.  For
example, managing SGPs/ASPs at a routing level should be a topic marked for
further study since its solution is in question.  It may be easier to go
back to v5 draft and just update it with the new tags.

John

-----Original Message-----
From: Kurt Kite [mailto:[email-masked]] Sent: Wednesday, July 25,
2001 1:20 PM
To: sigtran
Subject: Re: m3ua status

Hi,

IMOH, I don't think issues 1 and 2 below should prevent moving M3UA to last
call. Issue 3 is more important but it only comes into play in error
situations and if not resolved would only probably result in repeated
attempts
to activate/inactive ASs, i.e., just some extra "noise."

Regards,
Kurt

[email-masked] wrote:

> Lyndon,
>
> I object to moving M3UA v7 to IESG review/IETF Last Call.
>
> Please see below an excerpt from Kurt Kite's email from July 19 in which
> he lists three very important issues that were raised at the bakeoff in
> Madrid and were not addressed in v7:
>
> Issues Raised at the Interoperability Test in Madrid
> ----------------------------------------------------
>
> The following issues were raised an the interoperability
> test in Madrid and have not been addressed in version 7.
> I have not included the issue of sending SCON from an ASP to
> an SGP because you have already indicated that this was
> intentionally not addressed.
>
> 1.  One of the issues raised at the interoperability test in
>     Madrid was a lack of procedures for when an AS loses
>     connectivity with an SGP, similar to the MTP restart
>     procedures. It was also felt that the MTP restart
>     procedures would need to be coordinated with the "AS
>     restart" procedures.
>
> 2.  One of the issues raised at the interoperability test
>     in Madrid was multiple occurances of the same parameter
>     in a message. My recollection is that most participants
>     were not in favor of supporting this featuer. The draft
>     should clearly state whether this feature MUST, SHOULD,
>     or MUST NOT, be supported.
>
> 3.  One of the issues raised at the interoperability test
>     in Madrid was correlation of error messages. Version 7
>     has partially addressed the concerns by mandating
>     diagnostic information in some cases, e.g., invalid
>     network appearance. However, it does not mandate the
>     format of the diagnostic information. The draft should
>     clearly indicate the contents of the diagnostics
>     information. One proposal is that the error message always
>     includes the diagnostics which contains the offending
>     message (not just the first 40 bytes) and the offending
>     parameter when necessary. Here is some sample text:
>
>     The Error message contains the following parameters:
>
>          Error Code                 Mandatory
>          Offending Message          Mandatory
>          Offending Parameter        Optional
>          Diagnostic Information     Optional
>
>     The format for the Error message 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 = 0x0c           |            Length             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                          Error Code                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Tag = 0x??           |            Length             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        \                                                               \
>        /                     Offending Message                         /
>        \                                                               \
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Tag = 0x??           |            Length             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                     Offending Parameter Value                 |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Tag = 0x07           |            Length             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        \                                                               \
>        /                     Diagnostic Information                    /
>        \                                                               \
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Offending Message: variable length
>
>        The Offending Message parameter contains the entire erroneous
>        message.
>
>     Offending Parameter Value: 32-bits (unsigned integer)
>
>        The optional Offending Parameter Value parameter
>        contains the value of the erroneous parameter. The
>        Offending Parameter Value must be included when the
>        erroneous parameter can contain multiple values,
>        e.g., routing context.
>
>     Diagnostic Information: variable length
>
>        When included, the optional Diagnostic information can be any
>        information germane to the error condition, to assist in
>        identification of the error condition.
>
> Barry Nagelberg
> Software Engineer
> RadiSys, Corp.
> Signaling Products Design Center
> [email-masked]
> +1-856-642-9229 x237
>
> Lyndon Ong <[email-masked]>
> 07/24/01 04:43 PM
> Please respond to sigtran
>
>
>         To:     "sigtran" <[email-masked]>
>         cc:
>         Subject:        m3ua status
>
> Folks,
>
> There continue to be numerous comments on M3UA v7, at the same time I have
> been getting messages from people or groups who are interested in using
> M3UA for their protocols and would like very much to have it completed. In
> other words, we really need to get this finalized, so we should be
> focusing on actual errors, and pushing new functions or fine points into
> extension drafts.  Otherwise we may end up losing our "customers".
>
> This being the case, can I poll the group to see if there are objections
> to moving M3UA v7 to IESG review/IETF Last Call?  Keep in mind that during
> IETF Last Call, you will have another opportunity to comment.
>
> 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]

---
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, 25 Jul 2001 18:11:34 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: m3ua status - proposal for moving forward
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

M3UA v5 does not support DRST.  M3UA v5 does not support multiple SGP per
SG.  M3UA v5 does not support carrier class redunancy.

To properly address multiple SGP per SG, multiple SG configurations, and
DRST will bring up all of the same management issues once again.

Carving functionality down to v5 levels would IMHO be a great leap backwards
and a big waste of effort.  We should work to move forwards, not backwards.

My $0.02

--Brian

Schantz, John wrote:                            (Wed, 25 Jul 2001 15:24:48)
>
> Hi everybody,
> 
> 	I would like to make a proposal for moving M3UA forward.  I think we
> should pull back and see what is required right now.  We need a version of
> M3UA that will work with the existing SS7 networks (I am coming from an
SS7
> network point-of-view).    I am talking about replacing regular SS7
> transport between 2 existing SS7 nodes with IP transport.  These nodes are
> still supporting the current SS7 fundamentals.  We must do this without
> affecting the SS7 network or changing how the signalling end-point views
the
> network.
> 
> 	There have been many "enhancements" added or philosophical changes
> made in the last several months that are not required to work with an
> existing SS7 network.  IMHO, many of these should be reworked because
their
> solutions have broken basic SS7 fundamentals. 
> 
> 	The M3UA that we need now must do the following:
> 
> 1) We must be able to transport MTP-user messages.
> 
> 2) We need to maintain MTP-level routing principles.  
> 
> Routing on PC between signalling points is all that is required now.  That
> is, Routing Key/Context is only needed at the point code level right now.
> DPC + ? and the associated procedures to support this are not needed now.
> This can be added in a future version.  
> 
> Signalling point information is statically assigned, hence, the
> registration/deregistration of RK/RC is not required now.  This can be
added
> in a future version.
> 
> 3) We need to maintain the node/network level management philosophy.  
> 
> This means that network management messages (DUNA, DAVA, etc.) are
> interpreted at the SG and AS level.  This is required so that we do not
> create any interworking issues.  Network operators need to know that this
> philosophy has not changed.  
> 
> Managing SGPs and ASP at a routing level is an enhancement that is not
> required now.  Its solutions also must be solved without using the
existing
> network management messages.  This enhancement can be added in a future
> version.
> 
> The bottom line:  Clean up the M3UA draft to contain what is required now.
> Some of the enhancements can be marks as optional or for further study.
For
> example, managing SGPs/ASPs at a routing level should be a topic marked
for
> further study since its solution is in question.  It may be easier to go
> back to v5 draft and just update it with the new tags.
> 
> 
> John
> 
> -----Original Message-----
> From: Kurt Kite [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 1:20 PM
> To: sigtran
> Subject: Re: m3ua status
> 
> 
> Hi,
> 
> IMOH, I don't think issues 1 and 2 below should prevent moving M3UA
> to last call. Issue 3 is more important but it only comes into play in
error
> situations and if not resolved would only probably result in repeated
> attempts
> to activate/inactive ASs, i.e., just some extra "noise."
> 
> Regards,
> Kurt
> 
> [email-masked] wrote:
> 
> > Lyndon,
> >
> > I object to moving M3UA v7 to IESG review/IETF Last Call.
> >
> > Please see below an excerpt from Kurt Kite's email from July 19 in which
> > he lists three very important issues that were raised at the bakeoff in
> > Madrid and were not addressed in v7:
> >
> > Issues Raised at the Interoperability Test in Madrid
> > ----------------------------------------------------
> >
> > The following issues were raised an the interoperability
> > test in Madrid and have not been addressed in version 7.
> > I have not included the issue of sending SCON from an ASP to
> > an SGP because you have already indicated that this was
> > intentionally not addressed.
> >
> > 1.  One of the issues raised at the interoperability test in
> >     Madrid was a lack of procedures for when an AS loses
> >     connectivity with an SGP, similar to the MTP restart
> >     procedures. It was also felt that the MTP restart
> >     procedures would need to be coordinated with the "AS
> >     restart" procedures.
> >
> > 2.  One of the issues raised at the interoperability test
> >     in Madrid was multiple occurances of the same parameter
> >     in a message. My recollection is that most participants
> >     were not in favor of supporting this featuer. The draft
> >     should clearly state whether this feature MUST, SHOULD,
> >     or MUST NOT, be supported.
> >
> > 3.  One of the issues raised at the interoperability test
> >     in Madrid was correlation of error messages. Version 7
> >     has partially addressed the concerns by mandating
> >     diagnostic information in some cases, e.g., invalid
> >     network appearance. However, it does not mandate the
> >     format of the diagnostic information. The draft should
> >     clearly indicate the contents of the diagnostics
> >     information. One proposal is that the error message always
> >     includes the diagnostics which contains the offending
> >     message (not just the first 40 bytes) and the offending
> >     parameter when necessary. Here is some sample text:
> >
> >     The Error message contains the following parameters:
> >
> >          Error Code                 Mandatory
> >          Offending Message          Mandatory
> >          Offending Parameter        Optional
> >          Diagnostic Information     Optional
> >
> >     The format for the Error message 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 = 0x0c           |            Length             |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |                          Error Code                           |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |          Tag = 0x??           |            Length             |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        \                                                               \
> >        /                     Offending Message                         /
> >        \                                                               \
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |          Tag = 0x??           |            Length             |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |                     Offending Parameter Value                 |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |          Tag = 0x07           |            Length             |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        \                                                               \
> >        /                     Diagnostic Information                    /
> >        \                                                               \
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >     Offending Message: variable length
> >
> >        The Offending Message parameter contains the entire erroneous
> >        message.
> >
> >     Offending Parameter Value: 32-bits (unsigned integer)
> >
> >        The optional Offending Parameter Value parameter
> >        contains the value of the erroneous parameter. The
> >        Offending Parameter Value must be included when the
> >        erroneous parameter can contain multiple values,
> >        e.g., routing context.
> >
> >     Diagnostic Information: variable length
> >
> >        When included, the optional Diagnostic information can be any
> >        information germane to the error condition, to assist in
> >        identification of the error condition.
> >
> > Barry Nagelberg
> > Software Engineer
> > RadiSys, Corp.
> > Signaling Products Design Center
> > [email-masked]
> > +1-856-642-9229 x237
> >
> > Lyndon Ong <[email-masked]>
> > 07/24/01 04:43 PM
> > Please respond to sigtran
> >
> >
> >         To:     "sigtran" <[email-masked]>
> >         cc:
> >         Subject:        m3ua status
> >
> > Folks,
> >
> > There continue to be numerous comments on M3UA v7, at the same time I
have
> > been getting messages from people or groups who are interested in using
> > M3UA for their protocols and would like very much to have it completed.
In
> > other words, we really need to get this finalized, so we should be
> > focusing on actual errors, and pushing new functions or fine points into
> > extension drafts.  Otherwise we may end up losing our "customers".
> >
> > This being the case, can I poll the group to see if there are objections
> > to moving M3UA v7 to IESG review/IETF Last Call?  Keep in mind that
during
> > IETF Last Call, you will have another opportunity to comment.
> >
> > 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]
> 
> 
> 
> ---
> 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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Wed, 25 Jul 2001 20:10:42 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA-09 comment #8
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]

Harsh, Brian,

Will change text to MUST send ASPIA before sending DEREG and add appropriate
error code "Error - ASP active for Interface Identifier(s)".

Regards,

Ken

At 04:58 AM 7/24/01 -0500, Brian F. G. Bidulock wrote:
>Harsh, Ken,
>
>In section 3.3.4.4 M2UA should adopt the M3UA section 3.6.4
>already defined Deregistration Result:
>
>       5       Error - ASP Currently Active for Routing Context
>
>M3UA does not describe the use of this result, but I
>think the error (and when to send it) is self-expanatory.
>
>--Brian
>
>[email-masked] wrote:                              (Tue, 24 Jul 2001
15:11:47)
> > 
> > 
> > Hi,
> > 
> > I think an ASP must send ASPIA before a de-reg request. If the SG/SGP
receives a
> > de-reg request for an active ASP,
> > it should send an error message back to the ASP with an error code of
0x6 or
> > 0x7.
> > 
> > I'm in favour of not treating the de-reg as an implicit ASPIA because of
the
> > following reasons:
> > 1.ASPIA allows things like not specifying any IIDs leading to ASPIA for
all
> > configured AS(s),
> > and has provisions for retransmissions which currently we do not have
> > for de-reg process.
> > 2.It is not in sync with the process of registration in which the steps
are
> > ASPUP, registration, ASPAC.
> > A corresponding sequence for de-reg is therefore ASPIA, de-reg, ASPDN.
> > 
> > 
> > regards
> > Harsh
> > 
> > 
> > 
> > 
> > Ken Morneault <[email-masked]> on 07/23/2001 10:19:50 PM
> > 
> > Please respond to [email-masked]
> > 
> > To:   "sigtran" <[email-masked]>
> > cc:    (bcc: Harsh Bhondwe/HSS)
> > 
> > Subject:  Re: M2UA-09 comment #8
> > 
> > 
> > 
> > 
> > 
> > 
> > Harsh,
> > 
> > Since that language in option 1 (below) contains SHOULD, the SG must
handle
> > the case of a receiving a DEREG while ASP is in an ASP-ACTIVE state.
> > 
> > If this condition occurs, the SG MUST transition the ASP to
ASP-INACTIVE.
> > (so, option 2 applies also unless we change option 1 to say MUST.)
> > 
> > Regards,
> > 
> > Ken
> > 
> > 
> > 
> > At 07:42 AM 7/23/01 -0500, you wrote:
> > >Harsh,
> > >
> > >I agree, the procedure needs to be clarified.
> > >
> > >Did you have a preference as to whether the DEREG is
> > >an implied ASPIA or not?
> > >
> > >--Brian
> > >
> > >[email-masked] wrote:               (Mon, 23 Jul 2001 09:17:39)
> > > >
> > > >
> > > > Hi,
> > > >
> > > > In context of deregistration, the draft needs to specify that an ASP
should
> > be
> > > > in an inactive state
> > > > (for the AS associated with the IIDs in th de-reg request) when
sending
> > de-reg
> > > > request.
> > > > If an ASP is active for an AS , then it must first send ASPIA for
the AS
> > before
> > > > sending a dereg-request
> > > > for any of the IIDs associated with the AS.
> > > >
> > > > I've made this comment because it is not clear from the draft
whether
> > > > 1.An ASP should de-register itself for an AS after first becoming
inactive
> > for
> > > > the AS(assuming it was active before)
> > > > or
> > > > 2.The SG/SGP should treat the de-register request itself as an
ASPIA.(which
> > > > seems to be possible)
> > > > If option 1 is taken, then the SG CANNOT delete the AS configuration
data
> > > > when there are no more ASP registered in an AS unless the ASPs have
also
> > become
> > > > inactive before.
> > > > In fact the confusion has arisen because para 4.4.2
> > > > mentions such an action on the SG.
> > > > "The deregistration procedure does not necessarily imply the
deletion
> > > > of Link Key and Application Server configuration data at the SG.
> > > > Other ASPs may continue to be associated with the Application
> > > > Server, in which case the Link Key data CANNOT be deleted.  If a
> > > > Deregistration results in no more ASPs in an Application Server, an
> > > > SG MAY delte the Link Key data."
> > > >
> > > > thanks
> > > > Harsh Bhondwe
> > > > Hughes Software Systems
> > > >
> > >
> > >--
> > >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] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: phillipconrad@mail
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 25 Jul 2001 23:44:50 -0400
To: "sigtran" <[email-masked]>
From: Phillip Conrad <[email-masked]>
Subject: Re: M3UA-08: Flow Control
Cc: [email-masked], Greg Sidebottom <[email-masked]>
X-SMTP-HELO: femail13.sdc1.sfba.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail13.sdc1.sfba.home.com [24.0.95.140]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>At 05:20 AM 7/25/2001 -0500, Brian F. G. Bidulock wrote:
>Greg,
>
>SCTP provides no per-stream user level flow control.  In practice,
>the advantages of circumventing hol blocking are defeated in SCTP
>by the lack of per-stream flow control.  I may be advisable to
>open a separate SCTP assocation per AS to accomodate this.
>
>--Brian

I agreed that the  current lack of per-stream flow control is a problem... 
however, it is being addressed in an extension proposed in the following
internet 
draft:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-02.txt

In addition to the dynamic configuration of IP addresses (not necessarily
relevant here), tucked away in this draft are also extensions for per-stream
flow control, on a "byte count" and/or "number of messages" basis.

The authors of the draft (of which I am one) would welcome your feedback... 
I'm current working with a grad student on getting the stream flow control
part of this draft added to a future release of the reference implementation
on Randall Stewart's site.  If what we are proposing is not what is needed,
speak up, so we can fix it.

Thanks,
Phill Conrad

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
Date: Thu, 26 Jul 2001 03:22:32 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Lyndon Ong <[email-masked]>
Subject: UAs: Multiple UAs per Association
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Lyndon,

I am trying to multiplex multiple UAs over the same SCTP Assocation based on
Payload Protocol Identifier.

Unfortunately, each UA defines its own unique well known port number,
requiring separate assocations per UA.

Doesn't this kind of defeat the purpose of the SCTP PPI?  Could we have an
additional common IANA port number for all the UAs?

--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]
From: Tuexen Michael <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Lyndon Ong <[email-masked]>, 
    "'Brian F. G. Bidulock'" <[email-masked]>
Subject: RE: Multiple UAs per Association
Date: Thu, 26 Jul 2001 11:13:22 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: beamer.mchh.siemens.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.138.158.163]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Dear all,

this comes back to an old discussion. The information about the ULP is twice
in the packet (PPI and port).

Therefore Brians idea having a generic port number where you will use the
PPI is not bad...

But you are not forced to use the well known port. The ethereal packet
analyzer looks first in the PPI. If it does not find a ULP for that number
it uses the source and destination port number. So PPI is given priority to
the ports.

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:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Thursday, July 26, 2001 10:23 AM
> To:	sigtran
> Cc:	Lyndon Ong
> Subject:	UAs: Multiple UAs per Association
> 
> 
> Lyndon,
> 
> I am trying to multiplex multiple UAs over the same
> SCTP Assocation based on Payload Protocol Identifier.
> 
> Unfortunately, each UA defines its own unique well
> known port number, requiring separate assocations
> per UA.
> 
> Doesn't this kind of defeat the purpose of the SCTP
> PPI?  Could we have an additional common IANA port
> number for all the UAs?
> 
> --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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 26 Jul 2001 04:47:39 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Ken Morneault <[email-masked]>, Greg Sidebottom <[email-masked]>,
        John Loughney <[email-masked]>
Subject: M2UAv9, M3UAv8, SUAv7: Common Parameters (again)
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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Problems with common parameter tag values:

	m2ua defines IID Range as 0x2
	iua  defines IID Range as 0x8

	sua  defines 0x3 as Data
	m2ua defines 0x3 as IID (Text)
	iua  defines 0x3 as IID (Text)

	sua  defines 0x5 as Affected Point Code
	iua  defines 0x5 as DLCI

	m2ua defines 0xe as ASP Identifier
	m3ua defines 0xe as ASP Identifier
	sua  defines 0xe as ASP Identifier
	iua  defines 0xe as Protocol Data

	sua  defines 0xf as Congestion Level
	iua  defines 0xf as Release Reason

The following changes are necessary:

M2UA: Change IID Range      to 0x08 to be consistent with RFC2057
      Change ASP Identifier to 0x11 to be consistent with RFC2057

M3UA: Change ASP Identifier to 0x11 to be consistent with RFC2057

SUA:  Change ASP Identifier to 0x11 to be consistent with RFC2057
      Change Data           to 0x0e to be consistent with RFC2057

      Change Affected PC    to an SUA defined parameter range
      Change Congestion Lev to an SUA defined parameter range

--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]
From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Thu, 26 Jul 2001 16:01:31 +0530
Subject: M3UA: Multiple SGPs per Host
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 ,

If we consider that  in a SGP-ASP configuration , ASP is a client and SGP is
a server.  Is it allowed to have multiple SGPs on a single Host ??
Can a Single ASP connect to multiple of these SGPs residing on the same Host
??
Does SGP have a unique SCTP transport address , if so will there be multiple
well known servers running on a Host if there are multiple SGPs  ??

Best Regards,
-Sandeep

---
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: Thu, 26 Jul 2001 08:48:34 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UAv9, M3UAv8, SUAv7: Common Parameters (again)
Cc: Greg Sidebottom <[email-masked]>, 
    John Loughney <[email-masked]>
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Done.

Ken

At 04:47 AM 7/26/01 -0500, Brian F. G. Bidulock wrote:

>Problems with common parameter tag values:
>
>         m2ua defines IID Range as 0x2
>         iua  defines IID Range as 0x8
>
>         sua  defines 0x3 as Data
>         m2ua defines 0x3 as IID (Text)
>         iua  defines 0x3 as IID (Text)
>
>         sua  defines 0x5 as Affected Point Code
>         iua  defines 0x5 as DLCI
>
>         m2ua defines 0xe as ASP Identifier
>         m3ua defines 0xe as ASP Identifier
>         sua  defines 0xe as ASP Identifier
>         iua  defines 0xe as Protocol Data
>
>         sua  defines 0xf as Congestion Level
>         iua  defines 0xf as Release Reason
>
>
>The following changes are necessary:
>
>M2UA: Change IID Range      to 0x08 to be consistent with RFC2057
>       Change ASP Identifier to 0x11 to be consistent with RFC2057
>
>M3UA: Change ASP Identifier to 0x11 to be consistent with RFC2057
>
>SUA:  Change ASP Identifier to 0x11 to be consistent with RFC2057
>       Change Data           to 0x0e to be consistent with RFC2057
>
>       Change Affected PC    to an SUA defined parameter range
>       Change Congestion Lev to an SUA defined parameter range
>
>--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] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Originating-IP: [193.35.135.154]
From: Amish Chana <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: m3ua status - proposal for moving forward
Date: Thu, 26 Jul 2001 14:08:00 +0100
X-OriginalArrivalTime: 26 Jul 2001 13:08:00.0789 (UTC) 
                       FILETIME=[FF421C50:01C115D3]
X-SMTP-HELO: hotmail.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [64.4.37.7]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>John,

Your requirements can be more easily addressed with M2PA.

Amish

> >
> > 	There have been many "enhancements" added or philosophical changes
> > made in the last several months that are not required to work with an
> > existing SS7 network.  IMHO, many of these should be reworked because 
>their
> > solutions have broken basic SS7 fundamentals.
> >
> > 	The M3UA that we need now must do the following:
> >
> > 1) We must be able to transport MTP-user messages.
> >
> > 2) We need to maintain MTP-level routing principles.
> >
> > Routing on PC between signalling points is all that is required now.  
>That
> > is, Routing Key/Context is only needed at the point code level right 
>now.
> > DPC + ? and the associated procedures to support this are not needed 
>now.
> > This can be added in a future version.
> >
> > Signalling point information is statically assigned, hence, the
> > registration/deregistration of RK/RC is not required now.  This can be 
>added
> > in a future version.
> >
> > 3) We need to maintain the node/network level management philosophy.
> >
> > This means that network management messages (DUNA, DAVA, etc.) are
> > interpreted at the SG and AS level.  This is required so that we do not
> > create any interworking issues.  Network operators need to know that 
>this
> > philosophy has not changed.
> >
> > Managing SGPs and ASP at a routing level is an enhancement that is not
> > required now.  Its solutions also must be solved without using the 
>existing
> > network management messages.  This enhancement can be added in a future
> > version.
> >

_________________________________________________________________ Get your
FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Thu, 26 Jul 2001 09:41:33 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: M2UAv9: Issue #7 - Invalid Interface Ids in ASP Active
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]

All:

Here is the proposal for changes to the Error message to reflect the Invalid
Interface Identifiers found in an ASP Active message back to the ASP. 

3.3.3.1  Error (ERR)

The Error (ERR) message is used to notify a peer of an error event
associated with an incoming message.  For example, the message type might be
unexpected given the current state, or a parameter value might be invalid.

The ERR message contains the following parameters:

      Error Code (mandatory)
      Interface Identifier (optional)
      Diagnostic Information (optional)

The format for the ERR message 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 (0xc)           |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Error Code                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Tag (0x1, 0x3, or 0x8)    |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               \
    \                     Interface Identifier(s)*                  /
    /                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Tag (0x7)           |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               \
    \                     Diagnostic Information*                   /
    /                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Error Code parameter indicates the reason for the Error Message.
The Error parameter value can be one of the following values:

      Invalid Version                        0x1
      Invalid Interface Identifier           0x2
      Unsupported Message Class              0x3
      Unsupported Message Type               0x4
      Unsupported Traffic Handling Mode      0x5
      Unexpected Message                     0x6
      Protocol Error                         0x7
      Unsupported Interface Identifier Type  0x8
      Invalid Stream Identifier              0x9
      Invalid Parameter Value                0xa
      Refused - Management Blocking          0xb
      Error - ASP Currently Active for       0xc
              Interface Identifier
      Reserved                               0xd
      Error - ASP Identifier Required        0xe 
      Error - Invalid ASP Identifier         0xf  
      Refused - ASP Identifier Required      0x10 

(snip) 

The "Invalid Interface Identifier" error would be sent by a SGP if an ASP
sends a message (i.e. an ASP Active message) with an invalid (unconfigured)
Interface Identifier value.  One of the optional Interface Identifier
parameters (Integer-based, text-based or integer range) MUST be used with
this error code to identify the invalid Interface Identifier(s).

The "Unsupported Traffic Handling Mode" error would be sent by a SGP if an
ASP sends an ASP Active with an unsupported Traffic Handling Mode.  An
example would be a case in which the SGP did not support load-sharing.  One
of the optional Interface Identifier parameters (Integer-based, text-based
or integer range) MAY be used with this error code to identify the Interface
Identifier(s).

(snip)

The "Unsupported Interface Identifier Type" error would be sent by a SGP if
an ASP sends a Text formatted Interface Identifier and the SGP only supports
Integer formatted Interface Identifiers.  When the ASP receives this error,
it will need to resend its message with an Integer formatted Interface
Identifier.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 26 Jul 2001 09:07:07 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UAv9: Issue #7 - Invalid Interface Ids in ASP Active
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Works for me...

--Brian

Ken Morneault wrote:                             (Thu, 26 Jul 2001 09:41:33)
> 
> 
> All:
> 
> Here is the proposal for changes to the Error message to reflect
> the Invalid Interface Identifiers found in an ASP Active message
> back to the ASP. 
> 
> 3.3.3.1  Error (ERR)
> 
> The Error (ERR) message is used to notify a peer of an error event
> associated with an incoming message.  For example, the message type
> might be unexpected given the current state, or a parameter value might
> be invalid.
> 
> The ERR message contains the following parameters:
> 
>       Error Code (mandatory)
>       Interface Identifier (optional)
>       Diagnostic Information (optional)
> 
> The format for the ERR message 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 (0xc)           |            Length             |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          Error Code                           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Tag (0x1, 0x3, or 0x8)    |            Length             |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     /                                                               \
>     \                     Interface Identifier(s)*                  /
>     /                                                               \
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |           Tag (0x7)           |            Length             |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     /                                                               \
>     \                     Diagnostic Information*                   /
>     /                                                               \
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> The Error Code parameter indicates the reason for the Error Message.
> The Error parameter value can be one of the following values:
> 
>       Invalid Version                        0x1
>       Invalid Interface Identifier           0x2
>       Unsupported Message Class              0x3
>       Unsupported Message Type               0x4
>       Unsupported Traffic Handling Mode      0x5
>       Unexpected Message                     0x6
>       Protocol Error                         0x7
>       Unsupported Interface Identifier Type  0x8
>       Invalid Stream Identifier              0x9
>       Invalid Parameter Value                0xa
>       Refused - Management Blocking          0xb
>       Error - ASP Currently Active for       0xc
>               Interface Identifier
>       Reserved                               0xd
>       Error - ASP Identifier Required        0xe 
>       Error - Invalid ASP Identifier         0xf  
>       Refused - ASP Identifier Required      0x10 
> 
> 
> (snip) 
> 
> The "Invalid Interface Identifier" error would be sent by a SGP if
> an ASP sends a message (i.e. an ASP Active message) with an invalid 
> (unconfigured) Interface Identifier value.  One of the optional 
> Interface Identifier parameters (Integer-based, text-based or integer
> range) MUST be used with this error code to identify the invalid
> Interface Identifier(s).
> 
> The "Unsupported Traffic Handling Mode" error would be sent by a SGP
> if an ASP sends an ASP Active with an unsupported Traffic Handling
> Mode.  An example would be a case in which the SGP did not support
> load-sharing.  One of the optional Interface Identifier parameters 
> (Integer-based, text-based or integer range) MAY be used with this error 
> code to identify the Interface Identifier(s).
> 
> (snip)
> 
> The "Unsupported Interface Identifier Type" error would be sent by
> a SGP if an ASP sends a Text formatted Interface Identifier and the
> SGP only supports Integer formatted Interface Identifiers.  When
> the ASP receives this error, it will need to resend its message with
> an Integer formatted Interface Identifier.
> 
> 
> 
> 
> ---
> 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: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: m3ua status - proposal for moving forward
Date: Thu, 26 Jul 2001 07:36:25 -0700
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ztxmail04.ztx.compaq.com [161.114.1.208]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

	Yes, DRST is not supported in v5 and it could be added.  It also a
procedure that only ANSI SS7 networks support.

	v5 does support multiple SGP, it just don't break it apart the why
you want it and the why I don't want or need it.

	Carrier class redundancy?  Since you can use multiple SGPs and ASPs
in v5 to define redundant associations, I would say that v5 can have the
same "carrier class redundancy" that a regular SS7 network has.

	IMHO many of the "enhancements" that have been added will not be
used by carrier class SS7 networks, at least not for many years to come.

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Wednesday,
July 25, 2001 6:12 PM
To: sigtran
Subject: Re: m3ua status - proposal for moving forward

John,

M3UA v5 does not support DRST.  M3UA v5 does not support multiple SGP per
SG.  M3UA v5 does not support carrier class redunancy.

To properly address multiple SGP per SG, multiple SG configurations, and
DRST will bring up all of the same management issues once again.

Carving functionality down to v5 levels would IMHO be a great leap backwards
and a big waste of effort.  We should work to move forwards, not backwards.

My $0.02

--Brian

Schantz, John wrote:                            (Wed, 25 Jul 2001 15:24:48)
>
> Hi everybody,
> 
> 	I would like to make a proposal for moving M3UA forward.  I think we
> should pull back and see what is required right now.  We need a version of
> M3UA that will work with the existing SS7 networks (I am coming from an
SS7
> network point-of-view).    I am talking about replacing regular SS7
> transport between 2 existing SS7 nodes with IP transport.  These nodes are
> still supporting the current SS7 fundamentals.  We must do this without
> affecting the SS7 network or changing how the signalling end-point views
the
> network.
> 
> 	There have been many "enhancements" added or philosophical changes
> made in the last several months that are not required to work with an
> existing SS7 network.  IMHO, many of these should be reworked because
their
> solutions have broken basic SS7 fundamentals. 
> 
> 	The M3UA that we need now must do the following:
> 
> 1) We must be able to transport MTP-user messages.
> 
> 2) We need to maintain MTP-level routing principles.  
> 
> Routing on PC between signalling points is all that is required now.  That
> is, Routing Key/Context is only needed at the point code level right now.
> DPC + ? and the associated procedures to support this are not needed now.
> This can be added in a future version.  
> 
> Signalling point information is statically assigned, hence, the
> registration/deregistration of RK/RC is not required now.  This can be
added
> in a future version.
> 
> 3) We need to maintain the node/network level management philosophy.  
> 
> This means that network management messages (DUNA, DAVA, etc.) are
> interpreted at the SG and AS level.  This is required so that we do not
> create any interworking issues.  Network operators need to know that this
> philosophy has not changed.  
> 
> Managing SGPs and ASP at a routing level is an enhancement that is not
> required now.  Its solutions also must be solved without using the
existing
> network management messages.  This enhancement can be added in a future
> version.
> 
> The bottom line:  Clean up the M3UA draft to contain what is required now.
> Some of the enhancements can be marks as optional or for further study.
For
> example, managing SGPs/ASPs at a routing level should be a topic marked
for
> further study since its solution is in question.  It may be easier to go
> back to v5 draft and just update it with the new tags.
> 
> 
> John
> 
> -----Original Message-----
> From: Kurt Kite [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 1:20 PM
> To: sigtran
> Subject: Re: m3ua status
> 
> 
> Hi,
> 
> IMOH, I don't think issues 1 and 2 below should prevent moving M3UA
> to last call. Issue 3 is more important but it only comes into play in
error
> situations and if not resolved would only probably result in repeated
> attempts
> to activate/inactive ASs, i.e., just some extra "noise."
> 
> Regards,
> Kurt
> 
> [email-masked] wrote:
> 
> > Lyndon,
> >
> > I object to moving M3UA v7 to IESG review/IETF Last Call.
> >
> > Please see below an excerpt from Kurt Kite's email from July 19 in which
> > he lists three very important issues that were raised at the bakeoff in
> > Madrid and were not addressed in v7:
> >
> > Issues Raised at the Interoperability Test in Madrid
> > ----------------------------------------------------
> >
> > The following issues were raised an the interoperability
> > test in Madrid and have not been addressed in version 7.
> > I have not included the issue of sending SCON from an ASP to
> > an SGP because you have already indicated that this was
> > intentionally not addressed.
> >
> > 1.  One of the issues raised at the interoperability test in
> >     Madrid was a lack of procedures for when an AS loses
> >     connectivity with an SGP, similar to the MTP restart
> >     procedures. It was also felt that the MTP restart
> >     procedures would need to be coordinated with the "AS
> >     restart" procedures.
> >
> > 2.  One of the issues raised at the interoperability test
> >     in Madrid was multiple occurances of the same parameter
> >     in a message. My recollection is that most participants
> >     were not in favor of supporting this featuer. The draft
> >     should clearly state whether this feature MUST, SHOULD,
> >     or MUST NOT, be supported.
> >
> > 3.  One of the issues raised at the interoperability test
> >     in Madrid was correlation of error messages. Version 7
> >     has partially addressed the concerns by mandating
> >     diagnostic information in some cases, e.g., invalid
> >     network appearance. However, it does not mandate the
> >     format of the diagnostic information. The draft should
> >     clearly indicate the contents of the diagnostics
> >     information. One proposal is that the error message always
> >     includes the diagnostics which contains the offending
> >     message (not just the first 40 bytes) and the offending
> >     parameter when necessary. Here is some sample text:
> >
> >     The Error message contains the following parameters:
> >
> >          Error Code                 Mandatory
> >          Offending Message          Mandatory
> >          Offending Parameter        Optional
> >          Diagnostic Information     Optional
> >
> >     The format for the Error message 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 = 0x0c           |            Length             |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |                          Error Code                           |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |          Tag = 0x??           |            Length             |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        \                                                               \
> >        /                     Offending Message                         /
> >        \                                                               \
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |          Tag = 0x??           |            Length             |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |                     Offending Parameter Value                 |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |          Tag = 0x07           |            Length             |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        \                                                               \
> >        /                     Diagnostic Information                    /
> >        \                                                               \
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >     Offending Message: variable length
> >
> >        The Offending Message parameter contains the entire erroneous
> >        message.
> >
> >     Offending Parameter Value: 32-bits (unsigned integer)
> >
> >        The optional Offending Parameter Value parameter
> >        contains the value of the erroneous parameter. The
> >        Offending Parameter Value must be included when the
> >        erroneous parameter can contain multiple values,
> >        e.g., routing context.
> >
> >     Diagnostic Information: variable length
> >
> >        When included, the optional Diagnostic information can be any
> >        information germane to the error condition, to assist in
> >        identification of the error condition.
> >
> > Barry Nagelberg
> > Software Engineer
> > RadiSys, Corp.
> > Signaling Products Design Center
> > [email-masked]
> > +1-856-642-9229 x237
> >
> > Lyndon Ong <[email-masked]>
> > 07/24/01 04:43 PM
> > Please respond to sigtran
> >
> >
> >         To:     "sigtran" <[email-masked]>
> >         cc:
> >         Subject:        m3ua status
> >
> > Folks,
> >
> > There continue to be numerous comments on M3UA v7, at the same time I
have
> > been getting messages from people or groups who are interested in using
> > M3UA for their protocols and would like very much to have it completed.
In
> > other words, we really need to get this finalized, so we should be
> > focusing on actual errors, and pushing new functions or fine points into
> > extension drafts.  Otherwise we may end up losing our "customers".
> >
> > This being the case, can I poll the group to see if there are objections
> > to moving M3UA v7 to IESG review/IETF Last Call?  Keep in mind that
during
> > IETF Last Call, you will have another opportunity to comment.
> >
> > 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]
> 
> 
> 
> ---
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 26 Jul 2001 09:43:33 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: John Loughney <[email-masked]>
Subject: SUAv7: COREF missing Flags parm
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

COREF needs a Flags parameter if for nothing else to select the SLS value
upon which to send the refusal.

--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: Thu, 26 Jul 2001 09:48:14 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: John Loughney <[email-masked]>
Subject: SUAv7: Flags Parameter
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

Actually, because a decoupled SG cannot keep state concerning the SLS value
to use towards the SS7 network, the Flags parameter should be mandatory on
all CONS and CLNS messages.  Given that Flags and Routing Context will then
be mandatory on all CONS CLNS messages, would it not be a good idea just to
make them a permanent header like the IID in M2UA?

--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: Thu, 26 Jul 2001 10:01:52 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: John Loughney <[email-masked]>
Subject: SUAv7: CODT Message
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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

The CODT message does not have enough information in it for the SG to
determine where it has to go.  It needs at least a Destination Address.  DRN
is not sufficient.

--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]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: m3ua status - proposal for moving forward
Date: Thu, 26 Jul 2001 08:05:42 -0700
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.114.1.208]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Amish,

	I don't want M2PA, it does not fit my needs and I don't like the
baggage that comes with it.  An M3UA that provides the equivalent
functionality of MTP3 is what I want.  We have implemented M3UA so that it
works hand-in-hand with our existing MTP3.  I don't think the industry needs
an MTP3 replacement that is now disregarding general SS7 philosophies.

	The industry needs a base M3UA that embraces the SS7 philosophies.
Further enhancements can be added as optional procedures to meet other
situations.

John

-----Original Message-----
From: Amish Chana [mailto:[email-masked]] Sent: Thursday, July 26,
2001 8:08 AM
To: sigtran
Subject: Re: m3ua status - proposal for moving forward

John,

Your requirements can be more easily addressed with M2PA.

Amish

> >
> > 	There have been many "enhancements" added or philosophical changes
> > made in the last several months that are not required to work with an
> > existing SS7 network.  IMHO, many of these should be reworked because 
>their
> > solutions have broken basic SS7 fundamentals.
> >
> > 	The M3UA that we need now must do the following:
> >
> > 1) We must be able to transport MTP-user messages.
> >
> > 2) We need to maintain MTP-level routing principles.
> >
> > Routing on PC between signalling points is all that is required now.  
>That
> > is, Routing Key/Context is only needed at the point code level right 
>now.
> > DPC + ? and the associated procedures to support this are not needed 
>now.
> > This can be added in a future version.
> >
> > Signalling point information is statically assigned, hence, the
> > registration/deregistration of RK/RC is not required now.  This can be 
>added
> > in a future version.
> >
> > 3) We need to maintain the node/network level management philosophy.
> >
> > This means that network management messages (DUNA, DAVA, etc.) are
> > interpreted at the SG and AS level.  This is required so that we do not
> > create any interworking issues.  Network operators need to know that 
>this
> > philosophy has not changed.
> >
> > Managing SGPs and ASP at a routing level is an enhancement that is not
> > required now.  Its solutions also must be solved without using the 
>existing
> > network management messages.  This enhancement can be added in a future
> > version.
> >

_________________________________________________________________ Get your
FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---
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, 26 Jul 2001 10:06:59 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: John Loughney <[email-masked]>
Subject: Re: SUAv7: CODT Message
Reply-To: [email-masked]
Mail-Followup-To: sigtran <[email-masked]>, John Loughney 
                  <[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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

Ignore that...

Brian F. G. Bidulock wrote:                (Thu, 26 Jul 2001 10:01:52)
> John,
> 
> The CODT message does not have enough information in it
> for the SG to determine where it has to go.  It needs
> at least a Destination Address.  DRN is not sufficient.
> 
> --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]
X-Originating-IP: [193.35.135.154]
From: Amish Chana <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA: Route-set congestion
Date: Thu, 26 Jul 2001 16:24:57 +0100
X-OriginalArrivalTime: 26 Jul 2001 15:24:57.0327 (UTC) 
                       FILETIME=[20B24FF0:01C115E7]
X-SMTP-HELO: hotmail.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: f162.pav2.hotmail.com [64.4.37.162]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>Hi all,

See, below for my questions.

          STP                                    SP

         **************                          **************
         *          __*__________________________*__          *
         *    STP1    *    A    _________________*__   SP1    *
         *            *        /     B           *            *
         **************       /                  **************
                             /
         **************     /
         *          __*____/
         *    STP2    *
         *            *   SCTP Associations
         **************
         Figure 1

          SG                                     MGC

  Host#1 **************                          ************** Host#3
     =   *  ********__*__________________________*__********  *   =
         *  * SGP1 *  *    A    _________________*__* ASP1 *  *  MGC1
         *  ********  *        /     B           *  ********  *
         **************       /                  **************
                             /
  Host#2 **************     /
     =   *  ********__*____/
         *  * SGP1 *  *
         *  ********  *   SCTP Associations
         **************
         Figure 2

1) In Figure 1, if a link in linkset A from SP1 is congested then MTP3 sends
a MTP-STATUS primitive with a congestion indication to the local user parts
with the DPC contained in every nth message (Q.704, 11.2.3.1). The local
user parts are expected to reduce their traffic to the expected destination.

Likewise congestion on an outgoing link of STP1 will generate TFCs to SP1. 
MTP3 will send MTP-STATUS primitives to the local user parts with the
afftected DPC (obtained from the TFCs).

If we consider analogous scenarios in Figure 2, for congestion on
association A or congestion on the outgoing SS7 links of Host#1, would it
not be more appropriate for M3UA to re-route traffic via association B and
Host#2? When congestion is detected on all possible routes, then only should
M3UA send the relevant MTP-STATUS primitive to the local user parts.

2) The M3UA draft states "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. In some cases, the SG itself may also be a
member of the SPMC."
If the National Option with Congestion Priorities is used, then should the
SPMC not be responsible for initiating the
signalling-route-set-congestion-test procedure? (There does not appear to be
any mention of this in the draft.) How do we test the congestion status of
congested route in the SS7 network from a point code that is distributed in
the IP network?

Amish

_________________________________________________________________ Get your
FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: m3ua status - proposal for moving forward
Date: Thu, 26 Jul 2001 08:25:41 -0700
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ztxmail04.ztx.compaq.com [161.114.1.208]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Why Brian, I didn't realize that it was SIGTRAN's goal to produce protocols
that are unusable by the existing SS7 industry.  Thanks for clarifying this
for me.

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Thursday,
July 26, 2001 10:16 AM
To: sigtran
Subject: Re: m3ua status - proposal for moving forward

John,

I agree with Amish: whay you need is M2PA.

What better way to force SS7 network philosophies onto an IP network?

--Brian

Schantz, John wrote:                                     (Thu, 26 Jul 2001
08:05:42)
> Amish,
> 
> 	I don't want M2PA, it does not fit my needs and I don't like the
> baggage that comes with it.  An M3UA that provides the equivalent
> functionality of MTP3 is what I want.  We have implemented M3UA so that it
> works hand-in-hand with our existing MTP3.  I don't think the industry
needs
> an MTP3 replacement that is now disregarding general SS7 philosophies.
> 
> 	The industry needs a base M3UA that embraces the SS7 philosophies.
> Further enhancements can be added as optional procedures to meet other
> situations.
> 
> John
> 
> -----Original Message-----
> From: Amish Chana [mailto:[email-masked]]
> Sent: Thursday, July 26, 2001 8:08 AM
> To: sigtran
> Subject: Re: m3ua status - proposal for moving forward
> 
> 
> John,
> 
> Your requirements can be more easily addressed with M2PA.
> 
> Amish
> 
> 
> > >
> > > 	There have been many "enhancements" added or philosophical changes
> > > made in the last several months that are not required to work with an
> > > existing SS7 network.  IMHO, many of these should be reworked because 
> >their
> > > solutions have broken basic SS7 fundamentals.
> > >
> > > 	The M3UA that we need now must do the following:
> > >
> > > 1) We must be able to transport MTP-user messages.
> > >
> > > 2) We need to maintain MTP-level routing principles.
> > >
> > > Routing on PC between signalling points is all that is required now.  
> >That
> > > is, Routing Key/Context is only needed at the point code level right 
> >now.
> > > DPC + ? and the associated procedures to support this are not needed 
> >now.
> > > This can be added in a future version.
> > >
> > > Signalling point information is statically assigned, hence, the
> > > registration/deregistration of RK/RC is not required now.  This can be

> >added
> > > in a future version.
> > >
> > > 3) We need to maintain the node/network level management philosophy.
> > >
> > > This means that network management messages (DUNA, DAVA, etc.) are
> > > interpreted at the SG and AS level.  This is required so that we do
not
> > > create any interworking issues.  Network operators need to know that 
> >this
> > > philosophy has not changed.
> > >
> > > Managing SGPs and ASP at a routing level is an enhancement that is not
> > > required now.  Its solutions also must be solved without using the 
> >existing
> > > network management messages.  This enhancement can be added in a
future
> > > version.
> > >
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> 
> 
> 
> ---
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Thu, 26 Jul 2001 10:32:16 -0500
From: Tom George <[email-masked]>
Organization: Alcatel USA, Inc. http://www.usa.alcatel.com /
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: m3ua status - proposal for moving forward
X-SMTP-HELO: netmail2.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [128.251.168.51]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

John,

What baggage?

tomG.

"Schantz, John" wrote:
> 
> Amish,
> 
>         I don't want M2PA, it does not fit my needs and I don't like the
> baggage that comes with it.  An M3UA that provides the equivalent
> functionality of MTP3 is what I want.  We have implemented M3UA so that it
> works hand-in-hand with our existing MTP3.  I don't think the industry
needs
> an MTP3 replacement that is now disregarding general SS7 philosophies.
> 
>         The industry needs a base M3UA that embraces the SS7 philosophies.
> Further enhancements can be added as optional procedures to meet other
> situations.
> 
> John
  [...]

-- 
* Tom George        972-519-3168         [email-masked]   * *
PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  * *
Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   * * I
actively disclaim speaking for Alcatel USA, Inc. I do not purport * * to
advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Originating-IP: [193.35.135.154]
From: Amish Chana <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: m3ua status - proposal for moving forward
Date: Thu, 26 Jul 2001 16:45:52 +0100
X-OriginalArrivalTime: 26 Jul 2001 15:45:52.0943 (UTC) 
                       FILETIME=[0D1A1BF0:01C115EA]
X-SMTP-HELO: hotmail.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: f80.pav2.hotmail.com [64.4.37.80]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>John,

You said, "An M3UA that provides the equivalent functionality of MTP3 is
what I want." and "I don't think the industry needs an MTP3 replacement that
is now disregarding general SS7 philosophies."

I don't think M3UA is meant to be MTP3 (or a replacement), instead it is a
"User Adaptation Layer" which allows us to interface seamlessly with MTP3 on
an SG via a NIF.

Please elaborate on the baggage associated with M2PA. There are alternatives
to M2PA, e.g. High speed ATM links, RFC 3094, etc...

Amish

>
>Why Brian, I didn't realize that it was SIGTRAN's goal to produce protocols
>that are unusable by the existing SS7 industry.  Thanks for clarifying this
>for me.
>
>John
>
>-----Original Message-----
>From: Brian F. G. Bidulock [mailto:[email-masked]]
>Sent: Thursday, July 26, 2001 10:16 AM
>To: sigtran
>Subject: Re: m3ua status - proposal for moving forward
>
>
>John,
>
>I agree with Amish: whay you need is M2PA.
>
>What better way to force SS7 network philosophies onto an IP network?
>
>--Brian
>
>Schantz, John wrote:                                     (Thu, 26 Jul 2001
>08:05:42)
> > Amish,
> >
> > 	I don't want M2PA, it does not fit my needs and I don't like the
> > baggage that comes with it.  An M3UA that provides the equivalent
> > functionality of MTP3 is what I want.  We have implemented M3UA so that 
>it
> > works hand-in-hand with our existing MTP3.  I don't think the industry
>needs
> > an MTP3 replacement that is now disregarding general SS7 philosophies.
> >
> > 	The industry needs a base M3UA that embraces the SS7 philosophies.
> > Further enhancements can be added as optional procedures to meet other
> > situations.
> >
> > John
> >
> > -----Original Message-----
> > From: Amish Chana [mailto:[email-masked]]
> > Sent: Thursday, July 26, 2001 8:08 AM
> > To: sigtran
> > Subject: Re: m3ua status - proposal for moving forward
> >
> >
> > John,
> >
> > Your requirements can be more easily addressed with M2PA.
> >
> > Amish
> >
> >
> > > >
> > > > 	There have been many "enhancements" added or philosophical
changes
> > > > made in the last several months that are not required to work with 
>an
> > > > existing SS7 network.  IMHO, many of these should be reworked 
>because
> > >their
> > > > solutions have broken basic SS7 fundamentals.
> > > >
> > > > 	The M3UA that we need now must do the following:
> > > >
> > > > 1) We must be able to transport MTP-user messages.
> > > >
> > > > 2) We need to maintain MTP-level routing principles.
> > > >
> > > > Routing on PC between signalling points is all that is required now.
> > >That
> > > > is, Routing Key/Context is only needed at the point code level right
> > >now.
> > > > DPC + ? and the associated procedures to support this are not needed
> > >now.
> > > > This can be added in a future version.
> > > >
> > > > Signalling point information is statically assigned, hence, the
> > > > registration/deregistration of RK/RC is not required now.  This can 
>be
>
> > >added
> > > > in a future version.
> > > >
> > > > 3) We need to maintain the node/network level management philosophy.
> > > >
> > > > This means that network management messages (DUNA, DAVA, etc.) are
> > > > interpreted at the SG and AS level.  This is required so that we do
>not
> > > > create any interworking issues.  Network operators need to know that
> > >this
> > > > philosophy has not changed.
> > > >
> > > > Managing SGPs and ASP at a routing level is an enhancement that is 
>not
> > > > required now.  Its solutions also must be solved without using the
> > >existing
> > > > network management messages.  This enhancement can be added in a
>future
> > > > version.
> > > >
> >
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
> >
> >
> >
> > ---
> > 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]
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to 
>[email-masked]

_________________________________________________________________ Get your
FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
To: "sigtran" <[email-masked]>
Date: Thu, 26 Jul 2001 08:46:42 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: RE: m3ua status - proposal for moving forward
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]>

All right, folks, before this gets too far...

It seems to me that there are two views being put forth, one being that we
should keep the protocol simpler and more easily compatible with existing
SS7 management, and the other being that we should add more functionality to
the protocol to allow more flexible and sophisticated implementations to be
developed.

This is a classic "standards" type issue, meaning we should try to find a
compromise to move forward, one that allows both possibilities.  There could
be a number of ways around this, such as perhaps defining a basic and then
extension set of management procedures.  Let's focus on finding such a
compromise.

Cheers,

L. Ong
--

On Thu, 26 Jul 2001 08:25:41   Schantz, John wrote:
>Why Brian, I didn't realize that it was SIGTRAN's goal to produce protocols
>that are unusable by the existing SS7 industry.  Thanks for clarifying this
>for me.
>
>John
>
>-----Original Message-----
>From: Brian F. G. Bidulock [mailto:[email-masked]]
>Sent: Thursday, July 26, 2001 10:16 AM
>To: sigtran
>Subject: Re: m3ua status - proposal for moving forward
>
>
>John,
>
>I agree with Amish: whay you need is M2PA.
>
>What better way to force SS7 network philosophies onto an IP network?
>
>--Brian
>
>Schantz, John wrote:                                     (Thu, 26 Jul 2001
>08:05:42)
>> Amish,
>> 
>> 	I don't want M2PA, it does not fit my needs and I don't like the
>> baggage that comes with it.  An M3UA that provides the equivalent
>> functionality of MTP3 is what I want.  We have implemented M3UA so that
it
>> works hand-in-hand with our existing MTP3.  I don't think the industry
>needs
>> an MTP3 replacement that is now disregarding general SS7 philosophies.
>> 
>> 	The industry needs a base M3UA that embraces the SS7 philosophies.
>> Further enhancements can be added as optional procedures to meet other
>> situations.
>> 
>> John
>> 
>> -----Original Message-----
>> From: Amish Chana [mailto:[email-masked]]
>> Sent: Thursday, July 26, 2001 8:08 AM
>> To: sigtran
>> Subject: Re: m3ua status - proposal for moving forward
>> 
>> 
>> John,
>> 
>> Your requirements can be more easily addressed with M2PA.
>> 
>> Amish
>> 
>> 
>> > >
>> > > 	There have been many "enhancements" added or philosophical changes
>> > > made in the last several months that are not required to work with an
>> > > existing SS7 network.  IMHO, many of these should be reworked because

>> >their
>> > > solutions have broken basic SS7 fundamentals.
>> > >
>> > > 	The M3UA that we need now must do the following:
>> > >
>> > > 1) We must be able to transport MTP-user messages.
>> > >
>> > > 2) We need to maintain MTP-level routing principles.
>> > >
>> > > Routing on PC between signalling points is all that is required now.

>> >That
>> > > is, Routing Key/Context is only needed at the point code level right 
>> >now.
>> > > DPC + ? and the associated procedures to support this are not needed 
>> >now.
>> > > This can be added in a future version.
>> > >
>> > > Signalling point information is statically assigned, hence, the
>> > > registration/deregistration of RK/RC is not required now.  This can
be
>
>> >added
>> > > in a future version.
>> > >
>> > > 3) We need to maintain the node/network level management philosophy.
>> > >
>> > > This means that network management messages (DUNA, DAVA, etc.) are
>> > > interpreted at the SG and AS level.  This is required so that we do
>not
>> > > create any interworking issues.  Network operators need to know that 
>> >this
>> > > philosophy has not changed.
>> > >
>> > > Managing SGPs and ASP at a routing level is an enhancement that is
not
>> > > required now.  Its solutions also must be solved without using the 
>> >existing
>> > > network management messages.  This enhancement can be added in a
>future
>> > > version.
>> > >
>> 
>> 
>> _________________________________________________________________
>> Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp
>> 
>> 
>> 
>> ---
>> 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]
>
>
>---
>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: "Adams, Russell" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUAv7, M3UAv8: Heartbeat Procedures
Date: Thu, 26 Jul 2001 08:50:38 -0700
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ztxmail04.ztx.compaq.com [161.114.1.208]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Why do we need another heartbeat here when a heartbeat is already being
performed at the SCTP level?  Doesn't the heartbeat at the SCTP level "keep
the association up" and "identify a dead" far end?

Russell Adams

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Wednesday,
July 25, 2001 14:27
To: sigtran
Cc: Greg Sidebottom; John Loughney
Subject: SUAv7, M3UAv8: Heartbeat Procedures

Greg, John,

Were the heartbeat procedures going to be updated?  Certainly there is no
reason why an SGP should not be able to send BEAT and expect BEAT ACK, even
if it has not yet received ASP UP.  BEAT may be the only way that the SGP
has of identifying a "dead" ASP which is holding open an association but is
never going to send ASP UP.
The SGP could clearly drop the association if the BEAT Ack doesn't come back
per the procedure.

Was there some common text for this procedure?  Was it going to be included
in SUA and M3UA?

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Guy Redmill <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SIGTRAN M3UA Proposals
Date: Thu, 26 Jul 2001 17:23:37 +0100
X-Mailer: Internet Mail Service (5.5.2448.0)
X-SMTP-HELO: ns.brooktrout.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [204.176.74.9]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [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.00.3211.1700" name=GENERATOR></HEAD> <BODY>
<DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN
class=242401423-26072001>If I understand&nbsp;<SPAN
class=123374223-26072001>John&nbsp;</SPAN>correctly,&nbsp;<SPAN
class=123374223-26072001>he</SPAN> see M3UA as (in the&nbsp;<SPAN
class=123374223-26072001>expanded</SPAN> form) offering a replacement for
MTP L3, and hence allowing SS7 over IP to act in true peer-to-peer fashion,
with all the appropriate link, linkset and routeset control that that
implies.&nbsp;<SPAN class=123374223-26072001>This is a logical extension
to&nbsp;the </SPAN>SIGTRAN architecture<SPAN class=123374223-26072001>,
which up to this point in time</SPAN> seemed to&nbsp;<SPAN
class=123374223-26072001>have been</SPAN> exclusively positioned as a
protocol to support decomposition of the protocol stack (i.e. between SG and
MGC<SPAN class=123374223-26072001>). If there are deficiencies with M2PA,
then we should look at this.</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=242401423-26072001></SPAN></FONT>&nbsp;</DIV> <DIV><FONT color=#0000ff
face=Arial size=2><SPAN class=242401423-26072001>In my view this is
essential and until we see this take place - and SS7 networks moving
securely into the IP domain, things like SIP won't take off properly
either.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff><SPAN class=242401423-26072001></SPAN></FONT><FONT
face=Arial size=2>&nbsp;</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=242401423-26072001>This makes perfect sense to me, as one of the
things I always found interesting about SS7&nbsp;are the routing
possibilities it offers MTP L3 is obviously fundamental to this and any
replacement must be at least as good - and offer some additional value.
Whilst I don't develop from the specifications, I do wonder if we aren't
rushing to replace something rather effective with something that doesn't
quite pass muster.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=242401423-26072001></SPAN></FONT>&nbsp;</DIV> <DIV><FONT
color=#0000ff><SPAN class=242401423-26072001></SPAN></FONT><FONT face=Arial
size=2>&nbsp;</FONT><FONT face="Times New Roman" size=2>Guy Redmill,</FONT>
<BR><B><FONT color=#000000 face="Times New Roman" size=2>Brooktrout
Technology</FONT></B><FONT face="Times New Roman" size=2>
</FONT><BR><U><FONT color=#000000 face="Times New Roman"
size=2>.brooktrout.com</FONT></U> <BR><B><I><FONT color=#008080 face="Times
New Roman" size=2>Your Hook into the New
Network<SUP>SM</SUP></FONT></I></B><I><FONT color=#008080 face="Times New
Roman" size=2></FONT></I> </DIV></DIV>
<DIV>&nbsp;</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>
Date: Thu, 26 Jul 2001 11:30:35 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Route-set congestion
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Amish,

Amish Chana wrote:                                          (Thu, 26 Jul
2001 16:24:57)
> Hi all,
> 
> See, below for my questions.
> 
> 
>           STP                                    SP
> 
>          **************                          **************
>          *          __*__________________________*__          *
>          *    STP1    *    A    _________________*__   SP1    *
>          *            *        /     B           *            *
>          **************       /                  **************
>                              /
>          **************     /
>          *          __*____/
>          *    STP2    *
>          *            *   SCTP Associations
>          **************
>          Figure 1
> 
> 
> 
>           SG                                     MGC
> 
>   Host#1 **************                          ************** Host#3
>      =   *  ********__*__________________________*__********  *   =
>          *  * SGP1 *  *    A    _________________*__* ASP1 *  *  MGC1
>          *  ********  *        /     B           *  ********  *
>          **************       /                  **************
>                              /
>   Host#2 **************     /
>      =   *  ********__*____/
>          *  * SGP1 *  *
>          *  ********  *   SCTP Associations
>          **************
>          Figure 2
> 
> 1) In Figure 1, if a link in linkset A from SP1 is congested then MTP3
sends 
> a MTP-STATUS primitive with a congestion indication to the local user
parts 
> with the DPC contained in every nth message (Q.704, 11.2.3.1). The local 
> user parts are expected to reduce their traffic to the expected
destination. 
> Likewise congestion on an outgoing link of STP1 will generate TFCs to SP1.

> MTP3 will send MTP-STATUS primitives to the local user parts with the 
> afftected DPC (obtained from the TFCs).
> 
> If we consider analogous scenarios in Figure 2, for congestion on 
> association A or congestion on the outgoing SS7 links of Host#1, would it 
> not be more appropriate for M3UA to re-route traffic via association B and

> Host#2? When congestion is detected on all possible routes, then only
should 
> M3UA send the relevant MTP-STATUS primitive to the local user parts.

In the SS7 network TFCs are responsive only to attempt to statistically hit
the true souce of the congestion.  While restricting routes on the basis of
congestion is possible in SS7 as well, is it is normally only performed when
the restricting signalling point suspects an alternate linkset which is not
congested (i.e, congestion detected on C-links).

Altering routes based on congestion at anything but an STP can have dire
consequences.  For example, if M3UA routes traffic to the SG from which it
has not received SCON, it could likely congest that STP next.
Thrashing back and forth between associations could be the result.

STP's are usually very good in the network of ensuring tight load balance.
It is better for the SG to signal DRST to the MGC, because it has more
information pertaining to failures in the network which might cause
congestion (e.g., the STP is routing over C-links) rather than the offered
load being just too high.  I don't think that it would be advisable to have
M3UA at the SP switch traffic on routes on the basis of SCON.

> 
> 2) The M3UA draft states "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. In some cases, the SG itself may also be a

> member of the SPMC."
> If the National Option with Congestion Priorities is used, then should the

> SPMC not be responsible for initiating the 
> signalling-route-set-congestion-test procedure? (There does not appear to
be 
> any mention of this in the draft.) How do we test the congestion status of

> congested route in the SS7 network from a point code that is distributed
in 
> the IP network?

The SG's, being respondible for the MGC SPMC will likely perform signalling-
routeset-congestion-test procedures towards the SS7 network on behalf of the
MGC, only signalling SCON when congestion status changes.  The MGC as
MTP-User model gets fuzzy when multiple SG/STPs are involved.

> 
> Amish
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> 
> 
> 
> ---
> 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, 26 Jul 2001 11:34:11 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUAv7, M3UAv8: Heartbeat Procedures
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Russell,

SCTP hearbeat only establishes that SCTP peers are alive, not M3UA peers.
The remote M3UA peer could have locked up even though its SCTP is alive and
well.  The M3UA heartbeat also has another purpose: when you stuff a BEAT
behind XFER messages on a stream you can be sure that the data has cleared
to the M3UA peer when you receive the BEAT ACK.  It works like CBD/CBA.

--brian

Adams, Russell wrote:                          (Thu, 26 Jul 2001 08:50:38)
> Why do we need another heartbeat here when a heartbeat is already being
> performed at the SCTP level?  Doesn't the heartbeat at the SCTP level
"keep
> the association up" and "identify a dead" far end?
> 
> Russell Adams
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 14:27
> To: sigtran
> Cc: Greg Sidebottom; John Loughney
> Subject: SUAv7, M3UAv8: Heartbeat Procedures
> 
> 
> Greg, John,
> 
> Were the heartbeat procedures going to be updated?  Certainly there
> is no reason why an SGP should not be able to send BEAT and expect
> BEAT ACK, even if it has not yet received ASP UP.  BEAT may be the
> only way that the SGP has of identifying a "dead" ASP which is
> holding open an association but is never going to send ASP UP.
> The SGP could clearly drop the association if the BEAT Ack doesn't
> come back per the procedure.
> 
> Was there some common text for this procedure?  Was it going to be
> included in SUA and M3UA?
> 
> --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]
> 
> 
> ---
> 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: "Ong, Lyndon" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: "'Brian F. G. Bidulock'" <[email-masked]>
Subject: RE: Multiple UAs per Association
Date: Thu, 26 Jul 2001 09:36:52 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: wntcsdexg02.csd.ciena.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.96.78.12]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

There's nothing that prevents us from reserving another port, we would need
to use the IANA form and probably would be good to explain what the
application is and why it's different from the existing UA ports.

Cheers,

L. Ong

-----Original Message-----
From: Tuexen Michael [mailto:[email-masked]] Sent: Thursday,
July 26, 2001 2:13 AM
To: [email-masked]'; sigtran Cc: Ong, Lyndon; 'Brian
F. G. Bidulock' Subject: RE: Multiple UAs per Association

Dear all,

this comes back to an old discussion. The information about the ULP is twice
in the packet (PPI and port).

Therefore Brians idea having a generic port number where you will use the
PPI is not bad...

But you are not forced to use the well known port. The ethereal packet
analyzer looks first in the PPI. If it does not find a ULP for that number
it uses the source and destination port number. So PPI is given priority to
the ports.

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:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Thursday, July 26, 2001 10:23 AM
> To:	sigtran
> Cc:	Lyndon Ong
> Subject:	UAs: Multiple UAs per Association
> 
> 
> Lyndon,
> 
> I am trying to multiplex multiple UAs over the same
> SCTP Assocation based on Payload Protocol Identifier.
> 
> Unfortunately, each UA defines its own unique well
> known port number, requiring separate assocations
> per UA.
> 
> Doesn't this kind of defeat the purpose of the SCTP
> PPI?  Could we have an additional common IANA port
> number for all the UAs?
> 
> --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]

---
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: Thu, 26 Jul 2001 12:56:00 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: M2UAv9 - Issue #6 - Correlation ID / Data Ack
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]

All:

This comment requested clarification in the text for handling a missed or
invalid Data Ack for a Correlation Id.  The following statement will be
added to the draft to clarify:

"If the Data Acknowledge is not sent for Correlation Id(s) or is sent with
Invalid Correlation Id(s), the SS7 link will eventually fail due to lack of
MTP Level 2 acknowledgements of the SS7 peer's MSUs."

Thus, there is no need for a timer or error response.

Regards,

Ken

---
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: M2UAv9 - Issue #6 - Correlation ID / Data Ack
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Date: Thu, 26 Jul 2001 13:48:35 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/26/2001 10:51:44 AM, Serialize 
             complete at 07/26/2001 10:51:44 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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ken,

Issue #6 deals not only with a missed or invalid data ack. It is broader and
requires additional text in the draft to explain:

a. What is the purpose of the data ack message?

b. What is the corresponding MTP Level 2 or MTP Level 3 layer primitives?
Q.703 doesn't suggest the use of a data ack primitive between layers 2 & 3.

c. Isn't there a contradiction between the fact that the correlation id
param is optional for the data message but mandatory for the data ack
message?

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

Ken Morneault <[email-masked]>
07/26/01 12:56 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        M2UAv9 - Issue #6 - Correlation ID / Data Ack

All:

This comment requested clarification in the text for handling a missed or
invalid Data Ack for a Correlation Id.  The following statement will be
added to the draft to clarify:

"If the Data Acknowledge is not sent for Correlation Id(s) or is sent with
Invalid Correlation Id(s), the SS7 link will eventually fail due to lack of
MTP Level 2 acknowledgements of the SS7 peer's MSUs."

Thus, there is no need for a timer or error response.

Regards,

Ken

---
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, 26 Jul 2001 13:17:50 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UAv9 - Issue #6 - Correlation ID / Data Ack
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Barry,

Please see comments below...

[email-masked] wrote:                (Thu, 26 Jul 2001
13:48:35)
> Ken,
> 
> Issue #6 deals not only with a missed or invalid data ack. It
> is broader and requires additional text in the draft to
> explain:
> 
> a. What is the purpose of the data ack message?

To ack data.

> 
> b. What is the corresponding MTP Level 2 or MTP Level 3 layer
> primitives? Q.703 doesn't suggest the use of a data ack
> primitive between layers 2 & 3.

Q.703 does not have primitives.  It has signals.  Nevertheless, if you look
at Figure 14/T1.111.3 Basic Reception Control (Sheet 3 of 4) you will see
that L2 sends the received MSU to L3 *before* incrementing FSNX and
signalling FSNX to TSC which gets turned around into an ack.  Proper
implementation of L2 requires that MSUs are delivered to L3 before
acknowledgement.  Otherwise a separation between L2 and L3 will "trap" MSUs
buffered to L3 which have been cleared from the L2 peer's retransmit buffer
through acknowledgement.  In M2UA's case, the MSUs can get trapped internal
to M2UA at the SG or in SCTP transmit buffers towards the ASP, both in the
case of association failure and in the case of SCTP congestion.

The Correlation Id and Ack provides a mechanism, for those SG
implementations capable for taking advantage of it, to obtain an
acknowledgement that the MSU has been transferred by M2UA to the M2UA peer
before acknowleding the MSU to the SS7 peer, removing the risk of losing
messages due to association failure or SCTP congestion.  The only reliance
that a so-inclined SG implementation has is that when Correlation Id is
sent, the remote M2UA must acknowledge with a Correlation Id Ack.

Depending on the implementation, failure to acknowledge will likely bring
down the link.

> 
> c. Isn't there a contradiction between the fact that the correlation id 
> param is optional for the data message but mandatory for the data ack 
> message?

No.  Invoking the procedure by sending Correlation Id is optional.
Acknowledging it when the procedure has been invoked is not.

> 
> Barry Nagelberg
> Software Engineer
> RadiSys, Corp.
> Signaling Products Design Center
> [email-masked]
> +1-856-642-9229 x237
> 
> 
> 
> 
> 
> Ken Morneault <[email-masked]>
> 07/26/01 12:56 PM
> Please respond to sigtran
> 
>  
>         To:     "sigtran" <[email-masked]>
>         cc: 
>         Subject:        M2UAv9 - Issue #6 - Correlation ID / Data Ack
> 
> 
> 
> 
> All:
> 
> This comment requested clarification in the text for handling a missed
> or invalid Data Ack for a Correlation Id.  The following statement will be
> added to the draft to clarify:
> 
> "If the Data Acknowledge is not sent for Correlation Id(s) 
> or is sent with Invalid Correlation Id(s), the SS7 link 
> will eventually fail due to lack of MTP Level 2 acknowledgements of the 
> SS7 peer's MSUs."
> 
> Thus, there is no need for a timer or error response.
> 
> Regards,
> 
> Ken
> 
> 
> ---
> 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]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Re: M2UAv9 - Issue #6 - Correlation ID / Data Ack
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Date: Thu, 26 Jul 2001 15:08:48 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/26/2001 12:11:55 PM, Serialize 
             complete at 07/26/2001 12:11:55 PM
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ken,

Based upon Brian's reply, I propose the following text changes and additions
to m2ua v9 so that we can close issue #6:

1. In order to clarify the purpose of the Correlation Id param in the Data
message, move the following sentence from section 4.3.3.4 (ASP Active) to
section 3.3.1.1 (Data):

"The purpose of the Correlation Id is to permit a newly active ASP in a
broadcast group to synchronize its processing of the traffic in each ordered
stream with other ASPs in the broadcast group."

2. In order to clarify the use and purpose of the Data Ack message, add the
following text to section 3.3.3  (Data Acknowledge Message):

"The Correlation Id parameter of the Data message and the Data Ack message
provide a mechanism, for those SG implementations capable for taking
advantage of them, to obtain an acknowledgement that the MSU has been
transferred to the M2UA peer before acknowleding the MSU to the SS7 peer,
removing the risk of losing messages due to association failure or SCTP
congestion.

The Data Ack message MUST be sent if a Correlation Id parameter is received
from the peer. Otherwise the Data Ack message SHOULD NOT be sent."

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

"Brian F. G. Bidulock" <[email-masked]> 07/26/01 02:17 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        Re: M2UAv9 - Issue #6 - Correlation ID / Data Ack

Barry,

Please see comments below...

[email-masked] wrote:                (Thu, 26 Jul 2001
13:48:35)
> Ken,
> 
> Issue #6 deals not only with a missed or invalid data ack. It
> is broader and requires additional text in the draft to
> explain:
> 
> a. What is the purpose of the data ack message?

To ack data.

> 
> b. What is the corresponding MTP Level 2 or MTP Level 3 layer
> primitives? Q.703 doesn't suggest the use of a data ack
> primitive between layers 2 & 3.

Q.703 does not have primitives.  It has signals.  Nevertheless, if you look
at Figure 14/T1.111.3 Basic Reception Control (Sheet 3 of 4) you will see
that L2 sends the received MSU to L3 *before* incrementing FSNX and
signalling FSNX to TSC which gets turned around into an ack.  Proper
implementation of L2 requires that MSUs are delivered to L3 before
acknowledgement.  Otherwise a separation between L2 and L3 will "trap" MSUs
buffered to L3 which have been cleared from the L2 peer's retransmit buffer
through acknowledgement.  In M2UA's case, the MSUs can get trapped internal
to M2UA at the SG or in SCTP transmit buffers towards the ASP, both in the
case of association failure and in the case of SCTP congestion.

The Correlation Id and Ack provides a mechanism, for those SG
implementations capable for taking advantage of it, to obtain an
acknowledgement that the MSU has been transferred by M2UA to the M2UA peer
before acknowleding the MSU to the SS7 peer, removing the risk of losing
messages due to association failure or SCTP congestion.  The only reliance
that a so-inclined SG implementation has is that when Correlation Id is
sent, the remote M2UA must acknowledge with a Correlation Id Ack.

Depending on the implementation, failure to acknowledge will likely bring
down the link.

> 
> c. Isn't there a contradiction between the fact that the correlation id 
> param is optional for the data message but mandatory for the data ack 
> message?

No.  Invoking the procedure by sending Correlation Id is optional.
Acknowledging it when the procedure has been invoked is not.

> 
> Barry Nagelberg
> Software Engineer
> RadiSys, Corp.
> Signaling Products Design Center
> [email-masked]
> +1-856-642-9229 x237
> 
> 
> 
> 
> 
> Ken Morneault <[email-masked]>
> 07/26/01 12:56 PM
> Please respond to sigtran
> 
> 
>         To:     "sigtran" <[email-masked]>
>         cc: 
>         Subject:        M2UAv9 - Issue #6 - Correlation ID / Data Ack
> 
> 
> 
> 
> All:
> 
> This comment requested clarification in the text for handling a missed
> or invalid Data Ack for a Correlation Id.  The following statement will be
> added to the draft to clarify:
> 
> "If the Data Acknowledge is not sent for Correlation Id(s) 
> or is sent with Invalid Correlation Id(s), the SS7 link 
> will eventually fail due to lack of MTP Level 2 acknowledgements of the 
> SS7 peer's MSUs."
> 
> Thus, there is no need for a timer or error response.
> 
> Regards,
> 
> Ken
> 
> 
> ---
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Originating-IP: [213.122.208.113]
From: Amish Chana <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Route-set congestion
Date: Thu, 26 Jul 2001 20:53:18 +0100
X-OriginalArrivalTime: 26 Jul 2001 19:53:18.0536 (UTC) 
                       FILETIME=[9DC3D480:01C1160C]
X-SMTP-HELO: hotmail.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [64.4.37.65]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>Brian,

> >           SG                                     MGC
> >
> >   Host#1 **************                          ************** Host#3
> >      =   *  ********__*__________________________*__********  *   =
> >          *  * SGP1 *  *    A    _________________*__* ASP1 *  *  MGC1
> >          *  ********  *        /     B           *  ********  *
> >          **************       /                  **************
> >                              /
> >   Host#2 **************     /
> >      =   *  ********__*____/
> >          *  * SGP1 *  *
> >          *  ********  *   SCTP Associations
> >          **************
> >          Figure 2
> >
>
>In the SS7 network TFCs are responsive only to attempt to statistically
>hit the true souce of the congestion.  While restricting routes on the
>basis of congestion is possible in SS7 as well, is it is normally only
>performed when the restricting signalling point suspects an alternate
>linkset which is not congested (i.e, congestion detected on C-links).
>
>Altering routes based on congestion at anything but an STP can have
>dire consequences.  For example, if M3UA routes traffic to the SG from
>which it has not received SCON, it could likely congest that STP next.
>Thrashing back and forth between associations could be the result.
>
>STP's are usually very good in the network of ensuring tight load
>balance.  It is better for the SG to signal DRST to the MGC, because
>it has more information pertaining to failures in the network which
>might cause congestion (e.g., the STP is routing over C-links) rather
>than the offered load being just too high.  I don't think that it would
>be advisable to have M3UA at the SP switch traffic on routes on the
>basis of SCON.

What about the scenario where the A-links are congested, or in this case
association-A? With traditional SS7 links the same number of links are
present between each STP and the SP, hence you have a fixed bandwidth
(assuming no failures)in each linkset. Congestion of the links may very well
be attributed to a high traffic volume to a DPC.

In an IP environment, association-A may traverse paths were the bandwidth is
shared with other systems. Congestion on association-A does not necessarily
imply that the MGC's traffic is responsible for the congestion (here the
local SCTP in the MGC would detect the congestion). In this scenario it may
be acceptable to carry all the traffic on association-B.

>
> >
> > 2) The M3UA draft states "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. In some cases, the SG itself may also be

>a
> > member of the SPMC."
> > If the National Option with Congestion Priorities is used, then should 
>the
> > SPMC not be responsible for initiating the
> > signalling-route-set-congestion-test procedure? (There does not appear 
>to be
> > any mention of this in the draft.) How do we test the congestion status 
>of
> > congested route in the SS7 network from a point code that is distributed

>in
> > the IP network?
>
>The SG's, being respondible for the MGC SPMC will likely perform 
>signalling-
>routeset-congestion-test procedures towards the SS7 network on behalf of
>the MGC, only signalling SCON when congestion status changes.  The MGC
>as MTP-User model gets fuzzy when multiple SG/STPs are involved.
>

Greg, could you please state that the SPMC is responsible for the
signalling-routeset-congestion-test procedure in section 4.3.1.

Thanks,
Amish

_________________________________________________________________ Get your
FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
From: "Benjamin J. Wilson" <[email-masked]>
Organization: Performance Technologies
To: "sigtran" <[email-masked]>
Subject: Re: SUAv7: ASP Capablities
Date: Thu, 26 Jul 2001 15:57:04 -0400
X-Mailer: KMail [version 1.0.29]
X-SMTP-HELO: ottawa.pt.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [206.191.2.130]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian / John,

Wouldn't we need to reintroduce Network Appearance to support dynamic
registration in SUA?

Ben

On Wed, 25 Jul 2001, you wrote:
> John,
> 
> What is the point of the ASP Capabilities parameter?  Certainly
> all of the Routing Context information must be provisioned in
> the SGP and the ASPs capabilities can be known to the SGP in
> the same fashion.  Is not the SS7 interworking situation and
> protocol class implicit in the Routing Context?  Is there some
> use for it?
> 
> ASP Capablities sounds like more of a registration item.  Which
> leads me to my next question: Why doesn't SUA support a registration/
> deregistration procedure?  Certainly Subsystem Number and ASP
> Capabilities sound like reasonable Routing Keys.  Even SRN ranges
> or TIDs make sense as well.
> 
> --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]

---
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: Thu, 26 Jul 2001 16:03:55 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UAv9 - Issue #6 - Correlation ID / Data Ack
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]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Agreed.

Ken

At 03:08 PM 7/26/01 -0400, you wrote:
>Ken,
>
>Based upon Brian's reply, I propose the following text changes and 
>additions to m2ua v9 so that we can close issue #6:
>
>1. In order to clarify the purpose of the Correlation Id param in the Data 
>message, move the following sentence from section 4.3.3.4 (ASP Active) to 
>section 3.3.1.1 (Data):
>
>"The purpose of the Correlation Id is to permit a newly active ASP in a 
>broadcast group to synchronize its processing of the traffic in each 
>ordered stream with other ASPs in the broadcast group."
>
>2. In order to clarify the use and purpose of the Data Ack message, add 
>the following text to section 3.3.3  (Data Acknowledge Message):
>
>"The Correlation Id parameter of the Data message and the Data Ack message 
>provide a mechanism, for those SG implementations capable for taking 
>advantage of them, to obtain an acknowledgement that the MSU has been 
>transferred to the M2UA peer before acknowleding the MSU to the SS7 peer, 
>removing the risk of losing messages due to association failure or SCTP 
>congestion.
>
>The Data Ack message MUST be sent if a Correlation Id parameter is 
>received from the peer. Otherwise the Data Ack message SHOULD NOT be 
>sent."
>
>Barry Nagelberg
>Software Engineer
>RadiSys, Corp.
>Signaling Products Design Center
>[email-masked]
>+1-856-642-9229 x237
>
>
>
>
>
>"Brian F. G. Bidulock" <[email-masked]>
>07/26/01 02:17 PM
>Please respond to sigtran
>
>  
>         To:     "sigtran" <[email-masked]>
>         cc: 
>         Subject:        Re: M2UAv9 - Issue #6 - Correlation ID / Data Ack
>
>
>Barry,
>
>Please see comments below...
>
>[email-masked] wrote:                (Thu, 26 Jul 2001 
>13:48:35)
> > Ken,
> > 
> > Issue #6 deals not only with a missed or invalid data ack. It
> > is broader and requires additional text in the draft to
> > explain:
> > 
> > a. What is the purpose of the data ack message?
>
>To ack data.
>
> > 
> > b. What is the corresponding MTP Level 2 or MTP Level 3 layer
> > primitives? Q.703 doesn't suggest the use of a data ack
> > primitive between layers 2 & 3.
>
>Q.703 does not have primitives.  It has signals.  Nevertheless, if you
>look at Figure 14/T1.111.3 Basic Reception Control (Sheet 3 of 4) you
>will see that L2 sends the received MSU to L3 *before* incrementing FSNX
>and signalling FSNX to TSC which gets turned around into an ack.  Proper
>implementation of L2 requires that MSUs are delivered to L3 before
>acknowledgement.  Otherwise a separation between L2 and L3 will "trap"
>MSUs buffered to L3 which have been cleared from the L2 peer's
>retransmit buffer through acknowledgement.  In M2UA's case, the MSUs can
>get trapped internal to M2UA at the SG or in SCTP transmit buffers
>towards the ASP, both in the case of association failure and in the case
>of SCTP congestion.
>
>The Correlation Id and Ack provides a mechanism, for those SG
>implementations capable for taking advantage of it, to obtain an
>acknowledgement that the MSU has been transferred by M2UA to the M2UA
>peer before acknowleding the MSU to the SS7 peer, removing the risk of
>losing messages due to association failure or SCTP congestion.  The only
>reliance that a so-inclined SG implementation has is that when
>Correlation Id is sent, the remote M2UA must acknowledge with a
>Correlation Id Ack.
>
>Depending on the implementation, failure to acknowledge will likely
>bring down the link.
>
> > 
> > c. Isn't there a contradiction between the fact that the correlation id 
> > param is optional for the data message but mandatory for the data ack 
> > message?
>
>No.  Invoking the procedure by sending Correlation Id is optional.
>Acknowledging it when the procedure has been invoked is not.
>
> > 
> > Barry Nagelberg
> > Software Engineer
> > RadiSys, Corp.
> > Signaling Products Design Center
> > [email-masked]
> > +1-856-642-9229 x237
> > 
> > 
> > 
> > 
> > 
> > Ken Morneault <[email-masked]>
> > 07/26/01 12:56 PM
> > Please respond to sigtran
> > 
> > 
> >         To:     "sigtran" <[email-masked]>
> >         cc: 
> >         Subject:        M2UAv9 - Issue #6 - Correlation ID / Data Ack
> > 
> > 
> > 
> > 
> > All:
> > 
> > This comment requested clarification in the text for handling a missed
> > or invalid Data Ack for a Correlation Id.  The following statement will 
>be
> > added to the draft to clarify:
> > 
> > "If the Data Acknowledge is not sent for Correlation Id(s) 
> > or is sent with Invalid Correlation Id(s), the SS7 link 
> > will eventually fail due to lack of MTP Level 2 acknowledgements of the 
> > SS7 peer's MSUs."
> > 
> > Thus, there is no need for a timer or error response.
> > 
> > Regards,
> > 
> > Ken
> > 
> > 
> > ---
> > 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]
>
>
>
>
>
>---
>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: Thu, 26 Jul 2001 16:47:50 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UAv0, M3UAv8, SUAv7: Traffic Mode Type
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I don't see a need for SGP to reflect the Traffic Mode of SGP to ASP.  The
ASP will be architected to support a single traffic mode.  Thus, we could
avoid having the Traffic Mode provisioned at the SG if the ASP sends it (of
course, it would be nice to clarify "loadsharing" arrangement since ASPs may
support different methods of loadsharing (i.e. on a CIC basis, on a MSU
basis).

Ken

At 01:20 PM 7/25/01 -0500, Brian F. G. Bidulock wrote:
>Ken, Greg, John,
>
>In addition, what is the purpose of a mandatory Traffic Mode Type in
>the ASP Active Ack?  Was it expected that this Traffic Mode Type would
>reflect the Traffic Mode of the SGP to the ASP?  (Which would be
>excellent!)  Or was it just an echo of the ASP Active message?  What
>does an ASP do if the mandatory Traffic Mode Type in the ASP Active Ack
>message does not match what was sent?  Should not this parameter be
>Optional?
>
>--Brian
>
>
>Brian F. G. Bidulock wrote:                 (Wed, 25 Jul 2001 12:36:29)
> > Ken, Greg, John,
> > 
> > Traffic Mode Type is a mandatory paramter of ASPAC and REG REQ in all
> > the UAs.  Because the Traffic Mode Type has only a restricted range
> > of modes, does it not make sense to permit ASPs and SGPs to use other
> > traffic modes other than those specified in the drafts?  In the case
> > where SGP and ASP have been configured for the traffic mode by other
> > means, shouldn't the Traffic Mode Type be Optional in these messages?
> > 
> > The text says that they MUST match, but if it is left out and the
> > ASP and SGP agree by prior arrangement, it doesn't need to be in the
> > message at all.
> > 
> > --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]
>
>-- 
>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, 26 Jul 2001 19:14:55 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Route-set congestion
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Amish,

Please see additional comments below...

Amish Chana wrote:                                          (Thu, 26 Jul
2001 20:53:18)
> Brian,
> 
> 
> > >           SG                                     MGC
> > >
> > >   Host#1 **************                          ************** Host#3
> > >      =   *  ********__*__________________________*__********  *   =
> > >          *  * SGP1 *  *    A    _________________*__* ASP1 *  *  MGC1
> > >          *  ********  *        /     B           *  ********  *
> > >          **************       /                  **************
> > >                              /
> > >   Host#2 **************     /
> > >      =   *  ********__*____/
> > >          *  * SGP1 *  *
> > >          *  ********  *   SCTP Associations
> > >          **************
> > >          Figure 2
> > >
> >
> >In the SS7 network TFCs are responsive only to attempt to statistically
> >hit the true souce of the congestion.  While restricting routes on the
> >basis of congestion is possible in SS7 as well, is it is normally only
> >performed when the restricting signalling point suspects an alternate
> >linkset which is not congested (i.e, congestion detected on C-links).
> >
> >Altering routes based on congestion at anything but an STP can have
> >dire consequences.  For example, if M3UA routes traffic to the SG from
> >which it has not received SCON, it could likely congest that STP next.
> >Thrashing back and forth between associations could be the result.
> >
> >STP's are usually very good in the network of ensuring tight load
> >balance.  It is better for the SG to signal DRST to the MGC, because
> >it has more information pertaining to failures in the network which
> >might cause congestion (e.g., the STP is routing over C-links) rather
> >than the offered load being just too high.  I don't think that it would
> >be advisable to have M3UA at the SP switch traffic on routes on the
> >basis of SCON.
> 
> What about the scenario where the A-links are congested, or in this case 
> association-A? With traditional SS7 links the same number of links are 
> present between each STP and the SP, hence you have a fixed bandwidth 
> (assuming no failures)in each linkset. Congestion of the links may very
well 
> be attributed to a high traffic volume to a DPC.
> 
> In an IP environment, association-A may traverse paths were the bandwidth
is 
> shared with other systems. Congestion on association-A does not
necessarily 
> imply that the MGC's traffic is responsible for the congestion (here the 
> local SCTP in the MGC would detect the congestion). In this scenario it
may 
> be acceptable to carry all the traffic on association-B.

The thing is that the SP is interworking into precisely the fixed bandwidth
constraints that you describe.  You are not going to escape the fact that
the congestion is being signalled from the SS7 network.

If we are talking about the MGC experiencing SCTP congestion (rather than
receiving SCON) then would be talking about something completely different.

> 
> >
> > >
> > > 2) The M3UA draft states "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. In some cases, the SG itself may also
be 
> >a
> > > member of the SPMC."
> > > If the National Option with Congestion Priorities is used, then should

> >the
> > > SPMC not be responsible for initiating the
> > > signalling-route-set-congestion-test procedure? (There does not appear

> >to be
> > > any mention of this in the draft.) How do we test the congestion
status 
> >of
> > > congested route in the SS7 network from a point code that is
distributed 
> >in
> > > the IP network?
> >
> >The SG's, being respondible for the MGC SPMC will likely perform 
> >signalling-
> >routeset-congestion-test procedures towards the SS7 network on behalf of
> >the MGC, only signalling SCON when congestion status changes.  The MGC
> >as MTP-User model gets fuzzy when multiple SG/STPs are involved.
> >
> 
> Greg, could you please state that the SPMC is responsible for the 
> signalling-routeset-congestion-test procedure in section 4.3.1.

Do you mean the SG instead of SPMC in this statement?

> 
> Thanks,
> Amish
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> 
> 
> 
> ---
> 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, 26 Jul 2001 19:15:42 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUAv7: ASP Capablities
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Benjamin,

Just optionally in the REG REQ message.

Benjamin J. Wilson wrote:                                (Thu, 26 Jul 2001
15:57:04)
> Brian / John,
> 
> Wouldn't we need to reintroduce Network Appearance to support 
> dynamic registration in SUA?
> 
> Ben
> 
> On Wed, 25 Jul 2001, you wrote:
> > John,
> > 
> > What is the point of the ASP Capabilities parameter?  Certainly
> > all of the Routing Context information must be provisioned in
> > the SGP and the ASPs capabilities can be known to the SGP in
> > the same fashion.  Is not the SS7 interworking situation and
> > protocol class implicit in the Routing Context?  Is there some
> > use for it?
> > 
> > ASP Capablities sounds like more of a registration item.  Which
> > leads me to my next question: Why doesn't SUA support a registration/
> > deregistration procedure?  Certainly Subsystem Number and ASP
> > Capabilities sound like reasonable Routing Keys.  Even SRN ranges
> > or TIDs make sense as well.
> > 
> > --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]
> 
> 
> ---
> 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, 26 Jul 2001 19:22:32 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UAv0, M3UAv8, SUAv7: Traffic Mode Type
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.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken, Greg, John,

Traffic Mode Type parameter should be optional in these messages.
Routing Context/Interface Identifier should be the only mandatory parameter
of the ASPAC/ASPAC Ack.  Traffic Mode Type parameter should be optional in
all messages, including REG REQ, because it can easily be obtained from
static configuration data when the AS are statically configured.

--Brian

Ken Morneault wrote:                        (Thu, 26 Jul 2001 16:47:50)
> 
> Brian,
> 
> I don't see a need for SGP to reflect the Traffic Mode of SGP to
> ASP.  The ASP will be architected to support a single traffic
> mode.  Thus, we could avoid having the Traffic Mode provisioned
> at the SG if the ASP sends it (of course, it would be nice
> to clarify "loadsharing" arrangement since ASPs may support
> different methods of loadsharing (i.e. on a CIC basis, on a MSU
> basis).
> 
> Ken
> 
> At 01:20 PM 7/25/01 -0500, Brian F. G. Bidulock wrote:
> >Ken, Greg, John,
> >
> >In addition, what is the purpose of a mandatory Traffic Mode Type in
> >the ASP Active Ack?  Was it expected that this Traffic Mode Type would
> >reflect the Traffic Mode of the SGP to the ASP?  (Which would be
> >excellent!)  Or was it just an echo of the ASP Active message?  What
> >does an ASP do if the mandatory Traffic Mode Type in the ASP Active Ack
> >message does not match what was sent?  Should not this parameter be
> >Optional?
> >
> >--Brian
> >
> >
> >Brian F. G. Bidulock wrote:                 (Wed, 25 Jul 2001 12:36:29)
> > > Ken, Greg, John,
> > > 
> > > Traffic Mode Type is a mandatory paramter of ASPAC and REG REQ in all
> > > the UAs.  Because the Traffic Mode Type has only a restricted range
> > > of modes, does it not make sense to permit ASPs and SGPs to use other
> > > traffic modes other than those specified in the drafts?  In the case
> > > where SGP and ASP have been configured for the traffic mode by other
> > > means, shouldn't the Traffic Mode Type be Optional in these messages?
> > > 
> > > The text says that they MUST match, but if it is left out and the
> > > ASP and SGP agree by prior arrangement, it doesn't need to be in the
> > > message at all.
> > > 
> > > --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]
> >
> >-- 
> >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]

-- 
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, 26 Jul 2001 23:47:10 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: Re: M3UA: Routing Context
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-202.dallas.net [209.44.42.202]
List-Unsubscribe: <mailto:[email-masked]>

Greg,

What can we do make M3UA adopt SUAv7's approach of replacing Network
Appearacnce with Routing Context?

Several points:

	John's objection is now clear.  He is assigning entire
	point code traffic to a routing context and the network
	appearance is sufficient for his demultiplexing purposes.
	I believe that is why he doesn "see a need".

	If network appearance is not swapped for routing context,
	there is nothing stopping an implementation from assigning
	network appearances in such a fashion that NA == RC.

--brian

BAND,RICHARD (HP-France,ex1) wrote:                  (Tue, 24 Jul 2001
17:11:40)
> Brian, all,
> 
> I like the idea of including the RC in a DATA. 
> I agree that it avoids redoing the routing work of the SGP at the ASP, and
> simplifies demultiplexing of traffic for multiple AS.
> So please, do include the RC in the DATA message.
> 
> Regards,
> 
> Richard Band
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: mardi 24 juillet 2001 00:08
> > To: sigtran
> > Cc: [email-masked]; Greg Sidebottom
> > Subject: Re: M3UA: Routing Context
> > 
> > 
> > John,
> > 
> > Please see comments below...
> > 
> > Schantz, John wrote:                                     
> > (Mon, 23 Jul 2001 13:04:29)
> > > Brian,
> > > 	This doesn't really make any sense and I don't see the need.
> > > 
> > > 	Why would you need a routing context in a DATA from SGP 
> > to ASP.  The
> > > ASP should be determining where the message goes locally in 
> > the AS(s) based
> > > on parameters from the SS7 message.
> > > 
> > > 	Requiring it in the DATA from the AS to SG doesn't make 
> > any sense.
> > > The SG should be determining how to forward route the 
> > message based on the
> > > SS7 message parameters (Routing Label).  Why would the 
> > responding AS even
> > > know the RC of a remote node.  Or are you proposing that a 
> > backward RC be
> > > included.  Forward routing should not be based on backward 
> > information.
> > > 
> > > 	Hence, the answer to your question of whether there is 
> > an objection
> > > to including the RC in the DATA message, YES I object.
> > 
> > Is your objection based on the fact that you don't see a need?
> > 
> > Certainly the Routing Context identifies the AS, because there is a
> > one to one correspondence between the AS and the Routing Context.
> > The AS is the basis on which all data traffic is managed.
> > 
> > If the ASP is going to forward messages based on anything other than
> > the AS for which it is configured/registered, there is no need to
> > have multiple AS per ASP supported at all and the Routing Context
> > can always be implied by the ASP Id (the instance of the SCTP
> > association).
> > 
> > In the current scheme, where an ASP can register for multiple AS,
> > it is convenient to organize the AS and RK such that each AS
> > corresponds to a demultiplexed stream.  It is then very efficient
> > to demultiplex by Routing Context which is what I (and it seems
> > others) would like to do.
> > 
> > For example, I have 4 processes running at my ASP.  These might
> > even be subtending processors.  I distribute ISUP CIC ranges over
> > the processes for load balancing.  I assign a Routing Key to each
> > of the 4 traffic flows by, say, OPC-DPC-CIC-range and either 
> > statically
> > configure or register them that way.  If the SGP places the RC in the
> > message when it sends the traffic, it will be saying "here's that
> > data AS-n asked for" and the ASP will not have to examine the contents
> > whatsoever to send it to the subtending process.  The examination of
> > the contents was done once in the SGP.
> > 
> > Should I go on?
> > 
> > --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]
> > 
> 
> 
> ---
> 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, 26 Jul 2001 23:51:01 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Routing Context
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-202.dallas.net [209.44.42.202]
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Adding Routing Context as an optional parameter to Data messages might
suffice.  Then at least the ASP could demux data without re-applying the
Routing Key.  Following are proposed text changes to accomplish that:

*** m3ua-08	Tue Jul 24 21:47:51 2001
--- m3ua-08.rcmods	Thu Jul 26 23:40:02 2001 ***************
*** 1789,1794 ****
--- 1789,1795 ----
  DATA message contains the following variable length parameters:
  
       Network Appearance       Optional +      Routing Context
Optional
       Protocol Data 1 or 2     Mandatory

***************
*** 1811,1816 ****
--- 1812,1821 ----
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Network Appearance                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|        Tag = 0x0006           |          Length = 8           | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +    |
Routing Context                        | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Tag = 0x0201 or 0x0202     |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
***************
*** 1846,1851 ****
--- 1851,1874 ----
     Where the optional Network Appearance parameter is present, it must 
     be the first parameter in the message as it defines the format of 
     the Protocol Data field
+ 
+ Routing Context: 32-bits (unsigned integer) + 
+    The optional Routing Context parameter identifies the Application +
Server to which this traffic corresponds, for the purposes of +    logically
separating the signalling traffic between the SGP and the +    ASP over a
common SCTP association.
+ 
+    Where the SG operates in the context of a single Application Server, +
or individual SCTP associations are dedicated to each Application +
Server, the Routing Context parameter is not required.  In other +    cases,
the parameter MUST be included.  When the Routing Context +    parameter is
included in the message, the Network Appearance MAY be +    excluded from
the message.
+ 
+    Where the optional Routing Context paramter is present, it must be +
placed ahead of the Protocol Data in the message as it defines the +
Application Server for the message.
  
     One of two possible Protocol Data parameters are included in a DATA 
     message: Protocol Data 1 or Protocol Data 2.  

--brian

Brian F. G. Bidulock wrote:                               (Thu, 26 Jul 2001
23:47:10)
> Greg,
> 
> What can we do make M3UA adopt SUAv7's approach of replacing
> Network Appearacnce with Routing Context?
> 
> Several points:
> 
> 	John's objection is now clear.  He is assigning entire
> 	point code traffic to a routing context and the network
> 	appearance is sufficient for his demultiplexing purposes.
> 	I believe that is why he doesn "see a need".
> 
> 	If network appearance is not swapped for routing context,
> 	there is nothing stopping an implementation from assigning
> 	network appearances in such a fashion that NA == RC.
> 
> --brian
> 
> BAND,RICHARD (HP-France,ex1) wrote:                  (Tue, 24 Jul 2001
17:11:40)
> > Brian, all,
> > 
> > I like the idea of including the RC in a DATA. 
> > I agree that it avoids redoing the routing work of the SGP at the ASP,
and
> > simplifies demultiplexing of traffic for multiple AS.
> > So please, do include the RC in the DATA message.
> > 
> > Regards,
> > 
> > Richard Band
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: mardi 24 juillet 2001 00:08
> > > To: sigtran
> > > Cc: [email-masked]; Greg Sidebottom
> > > Subject: Re: M3UA: Routing Context
> > > 
> > > 
> > > John,
> > > 
> > > Please see comments below...
> > > 
> > > Schantz, John wrote:                                     
> > > (Mon, 23 Jul 2001 13:04:29)
> > > > Brian,
> > > > 	This doesn't really make any sense and I don't see the need.
> > > > 
> > > > 	Why would you need a routing context in a DATA from SGP 
> > > to ASP.  The
> > > > ASP should be determining where the message goes locally in 
> > > the AS(s) based
> > > > on parameters from the SS7 message.
> > > > 
> > > > 	Requiring it in the DATA from the AS to SG doesn't make 
> > > any sense.
> > > > The SG should be determining how to forward route the 
> > > message based on the
> > > > SS7 message parameters (Routing Label).  Why would the 
> > > responding AS even
> > > > know the RC of a remote node.  Or are you proposing that a 
> > > backward RC be
> > > > included.  Forward routing should not be based on backward 
> > > information.
> > > > 
> > > > 	Hence, the answer to your question of whether there is 
> > > an objection
> > > > to including the RC in the DATA message, YES I object.
> > > 
> > > Is your objection based on the fact that you don't see a need?
> > > 
> > > Certainly the Routing Context identifies the AS, because there is a
> > > one to one correspondence between the AS and the Routing Context.
> > > The AS is the basis on which all data traffic is managed.
> > > 
> > > If the ASP is going to forward messages based on anything other than
> > > the AS for which it is configured/registered, there is no need to
> > > have multiple AS per ASP supported at all and the Routing Context
> > > can always be implied by the ASP Id (the instance of the SCTP
> > > association).
> > > 
> > > In the current scheme, where an ASP can register for multiple AS,
> > > it is convenient to organize the AS and RK such that each AS
> > > corresponds to a demultiplexed stream.  It is then very efficient
> > > to demultiplex by Routing Context which is what I (and it seems
> > > others) would like to do.
> > > 
> > > For example, I have 4 processes running at my ASP.  These might
> > > even be subtending processors.  I distribute ISUP CIC ranges over
> > > the processes for load balancing.  I assign a Routing Key to each
> > > of the 4 traffic flows by, say, OPC-DPC-CIC-range and either 
> > > statically
> > > configure or register them that way.  If the SGP places the RC in the
> > > message when it sends the traffic, it will be saying "here's that
> > > data AS-n asked for" and the ASP will not have to examine the contents
> > > whatsoever to send it to the subtending process.  The examination of
> > > the contents was done once in the SGP.
> > > 
> > > Should I go on?
> > > 
> > > --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]
> > > 
> > 
> > 
> > ---
> > 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/

-- 
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 status, revised
Date: Fri, 27 Jul 2001 01:21:05 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: peer1-va.mail.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [65.14.223.42]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings,

I got back from "time off" yesterday afternoon to see my inbox full of
sigtran messages.  I hope to get through them all by Friday night.  I'm not
sure why M3UA Issue 8 hasn't been announced on the list yet but I'll put out
later today the usual changes summary e-mail (Issue 7 to 8) and make
available the marked up MS-Word document.

There are a few (relatively minor) agreements that didn't make it in to
Issue 8, especially those late last week when I was busy trying to beat the
draft deadline.  There were other areas where I wasn't sure that there was
agreement yet.  I'll put together an issues list while I'm going through the
e-mails today - maybe I can number them like Ken did for M2UA, to facilitate
list discussion.

Thanks,

   Greg

----- Original Message -----
From: "Satish K" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Wednesday, July 25, 2001 12:24 AM
Subject: RE: m3ua status, revised

> Hi Lyndon,
>    when is the M3UA ver 8 expected to be posted in IETF, and what are
major
> issues addressed in ver 8 then previous ver's.
> Thanks
> Satish
>
> -----Original Message-----
> From: Lyndon Ong [mailto:[email-masked]]
> Sent: 25 July 2001 03:26
> To: sigtran
> Subject: m3ua status, revised
>
>
> Folks,
>
> Sorry, retract that previous message - we need to look at M3UAv8, which
has
> NOT yet appeared on the IETF server.  This is the latest version that Greg
> put out, incorporating comments from v7.
>
> (I had put v8 on my list of documents for London, but got confused
> with the number of comments people still had on v7.)
>
> Given that this is not yet out on the server and people have to take a
look
> at it, I will reask this question later in the week.
>
> If people are interested in having a look before it appears on the IETF
> server, I have posted a copy on the ftp site as well,
> ftp://standards.nortelnetworks.com/sigtran.  You should use the copy on
the
> IETF server, however, when this is posted.
>
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 27 Jul 2001 00:25:35 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: Re: M3UA: Packing of Routing Label into DATA Payload
Reply-To: [email-masked]
Mail-Followup-To: sigtran <[email-masked]>, Greg
Sidebottom 
                  <[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.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Perhaps we can hit a compromise on this issue.  Perhaps we could add a
Protocol Data 3 format (to the other 8 or so formats under Protocol Data 1)
which would be an "unpacked" format.  Then an SGP/ASP combination could use
the most efficient format given local implementation considerations.
Following is proposed text:

--brian

*** m3ua-08.rcmods	Thu Jul 26 23:40:02 2001 --- m3ua-08.plmods	Fri
Jul 27 00:17:56 2001 ***************
*** 1739,1744 ****
--- 1739,1745 ----
           0x020a        Local_Routing Key Identifier
           0x020b        Destination Point Code
           0x020c        Service Indicators +          0x020d
Protocol Data 3

  Sidebottom et al                                             [Page 31]
***************
*** 1790,1796 ****
  
       Network Appearance       Optional
       Routing Context          Optional !      Protocol Data 1 or 2
Mandatory

--- 1791,1797 ----
  
       Network Appearance       Optional
       Routing Context          Optional !      Protocol Data 1, 2 or 3
Mandatory

***************
*** 1879,1885 ****
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
  
! Protocol Data 1 or 2: variable length
   
     The Protocol Data 1 parameter contains the original SS7 MTP3 
     message, including the Service Information Octet and Routing Label. 
--- 1880,1886 ----
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
  
! Protocol Data 1, 2 or 3: variable length
   
     The Protocol Data 1 parameter contains the original SS7 MTP3 
     message, including the Service Information Octet and Routing Label. 
***************
*** 1971,1977 ****
--- 1972,2032 ----
  
      * marks LSB of each field;  @ = OPC SP MSB;  $ = OPC region MSB
  
+    The Protocol Data 3 parameter contains all the information in +
Protocol Data 1 and 2 as described above, but the Routing Label +
contents are unpacked and the Payload Data field contains the +    MTP-User
protocol data starting immediately after the Routing Label.
+ 
+    The Protocol Data 3 field format 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 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +     |
Originating Point Code                     | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +     |
Destination Point Code                     | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +     |
Service Ind.  | Msg. Priority |   Signalling Link Selection   | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +     /
/ +     \                           Protocol                            \ +
/                             Data                              / +     \
\ +     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 
+    Originating Point Code: 32 bits (unsigned integer) +    Destination
Point Code: 32 bits (unsigned integer)
  
+       The Originating and Destinration Point Code fields contains the +
OPC and DPC from the routing label of the original SS7 message in +
Network Byte Order, justified to the least significant bit.
+       Unused bits are coded `0'.
+ 
+    Service Indicator: 8 bits (unsigned integer) + 
+       The Service Indicator field contains the SI field from the +
original SS7 message justified to the least significant bit.
+       Unused bits are coded `0'.
+ 
+    Message Priority: 8 bits (unsigned integer) + 
+       The Message Priority field contains the MP bits (if any) from the +
original SS7 message, both for ANSI-style and TTC-style message +
priority bits.  The MP bits are aligned to the least significant +
bit.  Unused bits are coded `0'.
+ 
+    Signalling Link Selection: 16 bits (unsigned integer) + 
+       The Signalling Link Selection field contains the SLS bits from the +
original SS7 message justified to the least significant bit and in +
Network Byte Order.  Unused bits are coded `0'.
+ 
+    Protocol Data: (variable)
+ 
+       The Protocol Data field contains a byte string of MTP-User +
information from the original SS7 message starting with the first +
byte of the original SS7 message following the Routing Label.
+    
  
  3.4 SS7 Signalling Network Management (SSNM) Messages

Brian F. G. Bidulock wrote:                               (Mon, 23 Jul 2001
10:15:23)
> Benjamin,
> 
> Please see comments below...
> 
> Benjamin J. Wilson wrote:                (Mon, 23 Jul 2001 09:55:42)
> > Brian, Greg,
> > 
> > On Mon, 23 Jul 2001, Brian F. G. Bidulock wrote:
> > > Greg,
> > > 
> > > As this issue of packing routing labels into data payloads
> > > hasn't been resolved yet (I am staring incredulously at the code
> > > that I am writing), I would like to take another stab at NOT
> > > putting the routing label information in the DATA payload.
> > > 
> > > The reasons (with a number of new ones are):
> > > 
> > > 1.  The ASP must know the SS7 bit-coding of the routing label
> > >     for each variant of SS7 just so that it can send a DATA
> > >     message.  When a new one is created, all ASP code for M3UA
> > >     which supports the new variant will need to be updated.
> > 
> > Not disagreeing, but if you add RC to the DATA message wouldn't that
> > be enough to help the ASP interpret the encoding of the routing
> > label?
> 
> The ASP can interpret the encoding of the routing label implicitly
> or from the Network Appearance without Routing Context.  Routing
> Context is needed in DATA message for identifying and demultiplexing
> traffic flows.
> 
> What I was trying to get at here, was that with the RL in the payload,
> the ASP needs to know all these national variants of RL formats.
> Consider that if the routing label was in parameters, the draft would
> not even have to mention ANSI vs ETSI formats, and the ASP would not
> need to know either.  If the difference in variants can be removed
> from the ASP M3UA, variants information can be left to the MTP-User
> at the ASP (such as ISUP).  And the MTP-User is "outside" of the
> M3UA ASP.  Probably up in application space where code can be a
> little more flexible.
> 
> > 
> > (Thinking out loud).  I guess that is only true when 
> > Maria-Cruz's comment that "A RK cannot span more than one NA" is taken
> > into account".  I thought this fact was actually detailed in the
> > definition of a Routing Key in the latest M3UA spec.  If my
understanding
> > is correct ONE RC is associated with ONE RK which is associated
> > to ONE DPC which appears in ONE NA.  
> 
> It is start to seem like a strage restriction.  1:1:1:1 mappings are
> not terribly useful.  Can anyone think of a reason why this shouldn't
> be an k:l:m:n (or whatever) mapping?
> 
> > 
> > Once you allow a RK to span NAs (with potentially different MTP flavors)
> > and use a RC to describe this RK.  Then the ASP still has to understand
> > 2 different types of point codes.  The DPC/OPC parameters that are
> > created to support the new DATA message would need to contain some 
> > type id (24 bit, 16 bit, etc.).
> 
> This is the normal use of the Network Appearance.  When it is required
> in the DATA message, Nework Appearance could still be included.
> 
> -- 
> 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]

-- 
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]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Fri, 27 Jul 2001 11:59:29 +0530
Subject: M2UAv9: Link Key Management Procedures
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 ,

I have a query about Link Key Management Procedures in M2UA.

From Section 3.3.2.5 of draft
"If only a subset of Interface Identifiers are included, the ASP is noted as
Active for all the Interface Identifiers provisioned for that AS."

Is the same rule applicable to Registration Request (REG REQ) and
De-Registration Request (DEREG REQ)also ?
It is not clear from the current text in section 4.4.1 and 4.4.2.

From Section 4.4.1 of draft
"An ASP MAY dynamically register with an SG as an ASP within an Application
Server using the REG REQ message."

From Section 4.4.2 of draft
"An ASP MAY dynamically deregister with an SG as an ASP within an
Application Server for particular Interface Identifier(s) using the DEREG
REQ message. "

Best Regards,
-Sandeep

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 27 Jul 2001 02:26:48 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UAv9: Link Key Management Procedures
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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Sandeep,

It is possible to activate an AS which consists of multiple Interface
Identifiers by only specifying one of the Interface Identifier(s) in the ASP
Active message.  This makes sense for static configuration where the
application wishes to allocate chunks of links (e.g. linksets or multiple
linksets) to a single Application Server and then activate them all in a
single ASPAC message.  This makes sense for static configuration.

For dynamic registration it doesn't make sense to register multiple
Interface Identifier(s) with a single link key.  It is conceivable that one
could deregister a block of links with a single Interface Identifier but
could be confusing.

I suggest we reword Section 4.4.1 and 4.4.2 to read:

   An ASP MAY dynamically register with an SG as an ASP within an
   Application Service for individual Interface Identifiers(s) using
   the REG REQ message.

and

   An ASP MAY dynamically deregister with an SG as an ASP within an
   Application Service for individual Interface Identifiers(s) using
   the DEREG REQ message.

Would that clear up any confusion?

--brian

[email-masked] wrote:               (Fri, 27 Jul 2001 11:59:29)
> 
> 
> 
> Hi ,
> 
> I have a query about Link Key Management Procedures in M2UA.
> 
> >From Section 3.3.2.5 of draft
> "If only a subset of Interface Identifiers are
> included, the ASP is noted as Active for all the Interface Identifiers
> provisioned for that AS."
> 
> Is the same rule applicable to Registration Request (REG REQ) and
> De-Registration Request (DEREG REQ)also ?
> It is not clear from the current text in section 4.4.1 and 4.4.2.
> 
> >From Section 4.4.1 of draft
> "An ASP MAY dynamically register with an SG as an ASP within an
> Application Server using the REG REQ message."
> 
> >From Section 4.4.2 of draft
> "An ASP MAY dynamically deregister with an SG as an ASP within an
> Application Server for particular Interface Identifier(s) using
> the DEREG REQ message. "
> 
> 
> Best Regards,
> -Sandeep
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Fri, 27 Jul 2001 14:02:58 +0530
Subject: Re: M2UAv9: Link Key Management Procedures
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 Brian ,

The current specs (M2UAv9) without the dynamic registration/de-registration
procedures does not allow ASP to become Active for sub-set of interface
identifiers in an AS. There are some problems if we allow this .
ASP is considered to be a process instance of an AS,  this means ASP within
an AS is capable of handling any traffic for that AS. This changes then..
Implementations will not only have to maintain the list of serving/Active
ASPs per AS , but per interface identifier also . This effectively means we
have one interface Identifier per AS.

I think these were the reasons the restriction was added in section 3.3.2.5
(in version 5 of M2UA).

Best Regards,
-Sandeep

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

Please respond to [email-masked]

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

Subject:  Re: M2UAv9: Link Key Management Procedures

Sandeep,

It is possible to activate an AS which consists of multiple Interface
Identifiers by only specifying one of the Interface Identifier(s) in the ASP
Active message.  This makes sense for static configuration where the
application wishes to allocate chunks of links (e.g. linksets or multiple
linksets) to a single Application Server and then activate them all in a
single ASPAC message.  This makes sense for static configuration.

For dynamic registration it doesn't make sense to register multiple
Interface Identifier(s) with a single link key.  It is conceivable that one
could deregister a block of links with a single Interface Identifier but
could be confusing.

I suggest we reword Section 4.4.1 and 4.4.2 to read:

   An ASP MAY dynamically register with an SG as an ASP within an
   Application Service for individual Interface Identifiers(s) using
   the REG REQ message.

and

   An ASP MAY dynamically deregister with an SG as an ASP within an
   Application Service for individual Interface Identifiers(s) using
   the DEREG REQ message.

Would that clear up any confusion?

--brian

[email-masked] wrote:               (Fri, 27 Jul 2001 11:59:29)
>
>
>
> Hi ,
>
> I have a query about Link Key Management Procedures in M2UA.
>
> >From Section 3.3.2.5 of draft
> "If only a subset of Interface Identifiers are
> included, the ASP is noted as Active for all the Interface Identifiers
> provisioned for that AS."
>
> Is the same rule applicable to Registration Request (REG REQ) and
> De-Registration Request (DEREG REQ)also ?
> It is not clear from the current text in section 4.4.1 and 4.4.2.
>
> >From Section 4.4.1 of draft
> "An ASP MAY dynamically register with an SG as an ASP within an
> Application Server using the REG REQ message."
>
> >From Section 4.4.2 of draft
> "An ASP MAY dynamically deregister with an SG as an ASP within an
> Application Server for particular Interface Identifier(s) using
> the DEREG REQ message. "
>
>
> Best Regards,
> -Sandeep
>

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

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 27 Jul 2001 04:24:22 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: Re: M3UA: Routing Context
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John, Greg,

Some of these things aren't apparent until one tries to go and build the
thing.

Here is the problem:  architecturally, M3UA exports the MTP-Provider/User
interface, like so:

                                   Application      Application 
                                    Server #2        Server #1  
                                   ___________      ___________ 
                                  |           |    |           |
                                  |   MTP     |    |   MTP     |
                                  |   User    |    |   User    |
                                  |           |    |           |
                                  |___________|    |___________|
                                     |     ^          |     ^   
                          __         |     |          |     |   
              ___________/__\_______/     /           |     |   
             /   _______|____|___________/            |     |   
            /   /       |    |                       /     /    
           /   /        |    |           __         /     /     
          /   / ________|____|______<___/__\_______/     /      
          |   |/   _____|____|______>__|____|___________/       
          |   /   /      \__/           \__/                    
          |  /|  /         \              \                     
          | / | /           \              \                    
          ||  ||             \              \                   
        __vv__||__         One SCTP       Routing               
       |          |       Association     Context               
       |          |                                             
       |   MTP    |                                             
       | Provider |                                             
       |          |                                             
       |          |                                             
       |__________|                                             
                                                                
        Signalling                                              
         Gateway                                                
        (Process)                                               
                                                                
  Where, the MTP-SAP can be identified by the Routing Context.  The SG may
apply a "Routing Key" to find the MTP-SAP, but this is a function which is
performed *below* the MTP-User interface.  If M3UA would label all messages
with the Routing Context (where ambiguous, as shown), then there would be no
confusion as to which MTP-SAP is being used either for outgoing or incoming
messages.

For example, when the SG performs transfer-prohibited procedures and
discovers that an SPMC signalling point is prohibited off a routeset, it
informs the MTP-Users.  So, the MTP has a list of "Users" to which it sends
MTP-PAUSE primitives.  We have the same thing in the SG, a list of routing
contexts, each which represents an MTP-User bound to an MTP-SAP.  So
instead, of attaching a list of Routing Contexts to the DUNA (or sending
multiple DUNAs, each with its own routing context), we are throwing up a
DUNA with a "Network Appearance".  There are a number of cases where the
Network Appearance becomes ambiguous at the ASP unless Network Appearance ==
Routing Context. (And then what is the point of two names for the same
thing?)

For the ASP -> SGP direction, consider that the MTP at the SG cannot
determine the origin of the message (i.e, which MTP-SAP the message came
from.)  There is nothing stopping AS#2 from placing an OPC/SI in the message
which doesn't belong to it.  In fact, the MTP-User should not even be
putting the OPC/SI in the message: the SG should do this on the basis of the
DPC key associated with the Routing Context.  I don't think that the SG
should just blindly route messages based on DPC without any screening
whatsoever.

Now, I am fully aware that you do not believe in MTP-SAPs which are not the
"whole" point code.  But in the case where routing keys are "whole" point
codes, Network Appearance == Routing Context.  For sub-point code MTP-SAPs
(e.g., ISUP goes to AS#1, SCCP to AS#2), AS#1 needs to be screened off of
placing a non-ISUP SI in the routing label, and not using its own point
code.  AS#1 needs to have messages screend by DPC as well unless one wants
to try to replicate gateway screening above the MTP-User interface.

So, John, you should not care if Network Appearance is replaced with Routing
Context, because in your case Network Appearance == Routing Context, even
though you don't see the need, because it is not applicable in your cases.

--brian

Schantz, John wrote:                        (Mon, 23 Jul 2001 13:04:29)
> Brian,
> 	This doesn't really make any sense and I don't see the need.
> 
> 	Why would you need a routing context in a DATA from SGP to ASP.  The
> ASP should be determining where the message goes locally in the AS(s)
based
> on parameters from the SS7 message.
> 
> 	Requiring it in the DATA from the AS to SG doesn't make any sense.
> The SG should be determining how to forward route the message based on the
> SS7 message parameters (Routing Label).  Why would the responding AS even
> know the RC of a remote node.  Or are you proposing that a backward RC be
> included.  Forward routing should not be based on backward information.
> 
> 	Hence, the answer to your question of whether there is an objection
> to including the RC in the DATA message, YES I object.
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, July 23, 2001 6:07 AM
> To: sigtran
> Cc: Greg Sidebottom
> Subject: M3UA: Routing Context
> 
> 
> Greg,
> 
> I would like to propose that the Routing Context be added as an
> optional parameter to which SHOULD be included in the DATA
> messages from the SGP and MUST be included in DATA messages from
> the ASP when the ASP is active for more than one Application
> Server.
> 
> This is *not* a replace-Network-Appearance-with-Routing-
> Context-proposal.
> 
> The purpose of adding RC to DATA messages is to distinguish
> multiple traffic flows which are multiplexed over the
> association for use in:
> 
>     o   demultiplexing data traffic at the ASP without having to
> 	reapply the Routing Key to each message to determine
> 	routing context,
> 
>     o   distinguishing traffic flows for discarding data
>         messages during ASPAC and ASPIA procedures, both at
> 	the SG and the ASP (again without having to reapply
> 	the Routing Key to each message at each end),
> 
>     o   demultiplexing buffered data messages at the ASP and the
>         SG during failover or AS-PENDING, again, without having
> 	to reapply a complex Routing Key.
> 
>     o   assists in diagnostics by permitting monitoring
>         equipment to at least distinguish traffic flows without
> 	having to provision monitoring equipment with routing
> 	keys.
> 
> It sure simplifies a lot of places in the implementation where
> one would have to otherwise reapply the routing key.
> 
> I should point out that, for some routing keys (e.g, SCCP SSN)
> it is currently impossible for the SGP to distinguish between AS
> for *incoming* traffic when there are multiple AS on an
> association.  This is because the Routing Key-->Routing
> Context-->AS mapping is only valid for traffic from the SGP
> towards the ASP.
> 
> Any objections to including RC in DATA messages?
> 
> --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]
> 
> 
> ---
> 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: Fri, 27 Jul 2001 04:31:35 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UAv9: Link Key Management Procedures
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.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Sandeep,

Aside from being able to activate and deactivate them all by referencing one
of them, I see no difference between the 1:n case and the 1:1 case of
mapping between AS and IID.
An, of course, the 1:1 case is a subset of 1:n so the requirement to support
1:1 is implicit.

--brian

[email-masked] wrote:                            (Fri, 27 Jul 2001
14:02:58)
> 
> 
> 
> Hi Brian ,
> 
> The current specs (M2UAv9) without the dynamic
registration/de-registration
> procedures does not allow ASP to become Active for sub-set of interface
> identifiers in an AS. There are some problems if we allow this .
> ASP is considered to be a process instance of an AS,  this means ASP
within an
> AS is capable of handling any traffic for that AS. This changes then..
> Implementations will not only have to maintain the list of serving/Active
ASPs
> per AS , but per interface identifier also . This effectively means we
have one
> interface Identifier per AS.
> 
> I think these were the reasons the restriction was added in section
3.3.2.5 (in
> version 5 of M2UA).
> 
> Best Regards,
> -Sandeep
> 
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]> on 07/27/2001 01:56:48 PM
> 
> Please respond to [email-masked]
> 
> To:   "sigtran" <[email-masked]>
> cc:    (bcc: Sandeep Mahajan/HSS)
> 
> Subject:  Re: M2UAv9: Link Key Management Procedures
> 
> 
> 
> 
> Sandeep,
> 
> It is possible to activate an AS which consists of multiple
> Interface Identifiers by only specifying one of the Interface
> Identifier(s) in the ASP Active message.  This makes sense for
> static configuration where the application wishes to allocate
> chunks of links (e.g. linksets or multiple linksets) to a single
> Application Server and then activate them all in a single ASPAC
> message.  This makes sense for static configuration.
> 
> For dynamic registration it doesn't make sense to register multiple
> Interface Identifier(s) with a single link key.  It is conceivable
> that one could deregister a block of links with a single Interface
> Identifier but could be confusing.
> 
> I suggest we reword Section 4.4.1 and 4.4.2 to read:
> 
>    An ASP MAY dynamically register with an SG as an ASP within an
>    Application Service for individual Interface Identifiers(s) using
>    the REG REQ message.
> 
> and
> 
>    An ASP MAY dynamically deregister with an SG as an ASP within an
>    Application Service for individual Interface Identifiers(s) using
>    the DEREG REQ message.
> 
> 
> Would that clear up any confusion?
> 
> 
> --brian
> 
> 
> [email-masked] wrote:               (Fri, 27 Jul 2001 11:59:29)
> >
> >
> >
> > Hi ,
> >
> > I have a query about Link Key Management Procedures in M2UA.
> >
> > >From Section 3.3.2.5 of draft
> > "If only a subset of Interface Identifiers are
> > included, the ASP is noted as Active for all the Interface Identifiers
> > provisioned for that AS."
> >
> > Is the same rule applicable to Registration Request (REG REQ) and
> > De-Registration Request (DEREG REQ)also ?
> > It is not clear from the current text in section 4.4.1 and 4.4.2.
> >
> > >From Section 4.4.1 of draft
> > "An ASP MAY dynamically register with an SG as an ASP within an
> > Application Server using the REG REQ message."
> >
> > >From Section 4.4.2 of draft
> > "An ASP MAY dynamically deregister with an SG as an ASP within an
> > Application Server for particular Interface Identifier(s) using
> > the DEREG REQ message. "
> >
> >
> > Best Regards,
> > -Sandeep
> >
> 
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

-- 
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]
X-Originating-IP: [193.35.135.154]
From: Amish Chana <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Route-set congestion
Date: Fri, 27 Jul 2001 12:38:40 +0100
X-OriginalArrivalTime: 27 Jul 2001 11:38:40.0290 (UTC) 
                       FILETIME=[AE90A020:01C11690]
X-SMTP-HELO: hotmail.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [64.4.37.156]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>Brian,

> >
> > What about the scenario where the A-links are congested, or in this case
> > association-A? With traditional SS7 links the same number of links are
> > present between each STP and the SP, hence you have a fixed bandwidth
> > (assuming no failures)in each linkset. Congestion of the links may very 
>well
> > be attributed to a high traffic volume to a DPC.
> >
> > In an IP environment, association-A may traverse paths were the 
>bandwidth is
> > shared with other systems. Congestion on association-A does not 
>necessarily
> > imply that the MGC's traffic is responsible for the congestion (here the
> > local SCTP in the MGC would detect the congestion). In this scenario it 
>may
> > be acceptable to carry all the traffic on association-B.
>
>The thing is that the SP is interworking into precisely the fixed bandwidth
>constraints that you describe.  You are not going to escape the fact that
>the congestion is being signalled from the SS7 network.
>
>If we are talking about the MGC experiencing SCTP congestion (rather than
>receiving SCON) then would be talking about something completely different.

Yes.

I should have added the following in the email (from 1.4.6 in v7): "The M3UA
layer is informed of local and IP network congestion by means of an
implementation-dependent function (e.g., an implementation-dependent
indication from the SCTP of IP network congestion).

At an ASP or IPSP, the M3UA layer indicates congestion to local MTP3-Users
by means of an MTP-STATUS primitive, as per current MTP3 procedures, to
invoke appropriate upper layer responses."

With respect to the above paragraph, what I am getting at, is that I don't
think it is appropriate to indicate congestion to the MTP3-users unless IP
network congestion is detected on both associations. Congestion on one
association should allow for the traffic to be redirected to the 2nd
association. This could also result in the traffic swinging back and forth
between the two associations. A mechanism is therefore necessary to detect
how many associations reported congestion within someone time-period before
reporting congestion to the local MTP3-users.

> > > > 2) The M3UA draft states "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. In some cases, the SG itself may 
>also be
> > >a
> > > > member of the SPMC."
> > > > If the National Option with Congestion Priorities is used, then 
>should
> > >the
> > > > SPMC not be responsible for initiating the
> > > > signalling-route-set-congestion-test procedure? (There does not 
>appear
> > >to be
> > > > any mention of this in the draft.) How do we test the congestion 
>status
> > >of
> > > > congested route in the SS7 network from a point code that is 
>distributed
> > >in
> > > > the IP network?
> > >
> > >The SG's, being respondible for the MGC SPMC will likely perform
> > >signalling-
> > >routeset-congestion-test procedures towards the SS7 network on behalf 
>of
> > >the MGC, only signalling SCON when congestion status changes.  The MGC
> > >as MTP-User model gets fuzzy when multiple SG/STPs are involved.
> > >
> >
> > Greg, could you please state that the SPMC is responsible for the
> > signalling-routeset-congestion-test procedure in section 4.3.1.
>
>Do you mean the SG instead of SPMC in this statement?
>

No, I meant the SPMC responsible the point code to which the TFC was sent. I
will go with SG if you or someone can indicate what other functional element
on the SG could implement this procedure, when the point code resides in the
IP domain? The procedure cannot be implemented in the SG's own MTP3, as its
responsible for the SG's own point code. Any suggestions?

Amish

_________________________________________________________________ Get your
FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Mail archive.
Date: Fri, 27 Jul 2001 15:19:39 +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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

	Hi all!

	I would like to take a look to the SIGTRAN mail archive of 1999 (and
maybe also from the second half of 1998). I have been surfing the IETF page,
but even if it is supposed that there is an archive there, it is full of 0
bytes files to download (not that helpful :-)).

	I have also seen an archive in the Nortel pages, but they start in
April 1999...

	Does anybody know if I can find what I'm looking for somewhere in
Internet?

	Thanks!

	BR Iván Arias Rodríguez

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Fri, 27 Jul 2001 09:21:50 -0400
From: Warren Anthony Briggs <[email-masked]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: SUA - ASP CAPABILITIES
X-SMTP-HELO: ottawa.pt.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [206.191.2.130]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi All,

I hope this has not been discussed previously on the list.

Is there a need in  the SUA draft to include a specific error code to deal
with an unsupported protocol class at the SG?   For instance when receiving
an ASPUP at the SG with ASP CAPABILITIES  Protocol Class 3, the SG may want
to respond with "Error - Unsupported Protocol Class".

Regards,

Waren Briggs

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 27 Jul 2001 09:56:10 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Route-set congestion
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-202.dallas.net [209.44.42.202]
List-Unsubscribe: <mailto:[email-masked]>

Amish,

Amish Chana wrote:                                          (Fri, 27 Jul
2001 12:38:40)
> Brian,
> 
> > >
> > > What about the scenario where the A-links are congested, or in this
case
> > > association-A? With traditional SS7 links the same number of links are
> > > present between each STP and the SP, hence you have a fixed bandwidth
> > > (assuming no failures)in each linkset. Congestion of the links may
very 
> >well
> > > be attributed to a high traffic volume to a DPC.
> > >
> > > In an IP environment, association-A may traverse paths were the 
> >bandwidth is
> > > shared with other systems. Congestion on association-A does not 
> >necessarily
> > > imply that the MGC's traffic is responsible for the congestion (here
the
> > > local SCTP in the MGC would detect the congestion). In this scenario
it 
> >may
> > > be acceptable to carry all the traffic on association-B.
> >
> >The thing is that the SP is interworking into precisely the fixed
bandwidth
> >constraints that you describe.  You are not going to escape the fact that
> >the congestion is being signalled from the SS7 network.
> >
> >If we are talking about the MGC experiencing SCTP congestion (rather than
> >receiving SCON) then would be talking about something completely
different.
> 
> Yes.
> 
> I should have added the following in the email (from 1.4.6 in v7):
> "The M3UA layer is informed of local and IP network congestion by means of

> an implementation-dependent function (e.g., an implementation-dependent 
> indication from the SCTP of IP network congestion).
> 
> At an ASP or IPSP, the M3UA layer indicates congestion to local MTP3-Users

> by means of an MTP-STATUS primitive, as per current MTP3 procedures, to 
> invoke appropriate upper layer responses."
> 
> With respect to the above paragraph, what I am getting at, is that I don't

> think it is appropriate to indicate congestion to the MTP3-users unless IP

> network congestion is detected on both associations. Congestion on one 
> association should allow for the traffic to be redirected to the 2nd 
> association. This could also result in the traffic swinging back and forth

> between the two associations. A mechanism is therefore necessary to detect

> how many associations reported congestion within someone time-period
before 
> reporting congestion to the local MTP3-users.

Ah, that is different that SCON.  I suppose it is pretty much up to the
implementation to decide what to do with regard to SCTP congestion.
Some determination might be able to be made in specific IP network
configurations to determine whether SCTP congestion was due to too high and
offered load or whether a one or more associations is just "bad".
I would think that switching associations would only make sense in the case
that the SCTP association was "bad".

Switching traffic between SCTP associations which arrive a different
endpoints must be done quite carefully, because of the possibility of
mis-sequencing: i.e. the head of the traffic on the new association
overtaking the tail on the old past the SG/SGP.  Some sort of controlled
rerouting, changeover or other procedure could be necessary.  If an SCTP
assocation congests, there are a good number of messages in the SCTP
transmit buffers as well which might have to be collected to avoid holding
traffic too long in a time-controlled procedure before starting again on the
new association.  Such things as a successsful orderly shutdown of the old
association to clear buffers at both ends might be necessary before
restarting traffic on the new.

When these issues are considered, some implementations may very well choose
to inform their local MTP Users of congestion even though it is only on one
association.

Just some thoughts.  M3UA states these actions as "implementation-
dependent" because it would be very difficult to address these issues in all
configurations, and many factors rely upon the intervening IP network and
even the implementation architecture.

Did you think that some text needed changing to clarify this?  If so, could
you propose a paragraph?

--brian

> 
> > > > > 2) The M3UA draft states "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. In some cases, the SG itself may 
> >also be
> > > >a
> > > > > member of the SPMC."
> > > > > If the National Option with Congestion Priorities is used, then 
> >should
> > > >the
> > > > > SPMC not be responsible for initiating the
> > > > > signalling-route-set-congestion-test procedure? (There does not 
> >appear
> > > >to be
> > > > > any mention of this in the draft.) How do we test the congestion 
> >status
> > > >of
> > > > > congested route in the SS7 network from a point code that is 
> >distributed
> > > >in
> > > > > the IP network?
> > > >
> > > >The SG's, being respondible for the MGC SPMC will likely perform
> > > >signalling-
> > > >routeset-congestion-test procedures towards the SS7 network on behalf

> >of
> > > >the MGC, only signalling SCON when congestion status changes.  The
MGC
> > > >as MTP-User model gets fuzzy when multiple SG/STPs are involved.
> > > >
> > >
> > > Greg, could you please state that the SPMC is responsible for the
> > > signalling-routeset-congestion-test procedure in section 4.3.1.
> >
> >Do you mean the SG instead of SPMC in this statement?
> >
> 
> No, I meant the SPMC responsible the point code to which the TFC was sent.
I 
> will go with SG if you or someone can indicate what other functional
element 
> on the SG could implement this procedure, when the point code resides in
the 
> IP domain? The procedure cannot be implemented in the SG's own MTP3, as
its 
> responsible for the SG's own point code. Any suggestions?
> 
> Amish
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> 
> 
> 
> ---
> 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: Fri, 27 Jul 2001 10:00:29 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: m3ua status
X-SMTP-HELO: netmail.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail.alcatel.com [128.251.168.50]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Lyndon,

Let's do the obvious and use Greg's list as the official list of outstanding
issues.  We can use his list as a starting point and add any other issues to
it based on consensus mail list feedback.  I understand (from a similar
thread) that he's trying to publish a new list of issues later today.

Jeff

Lyndon Ong wrote:
> 
> Jeff,
> 
> I fully agree with you that we need to put out a good
> specification, not just A specification.  At the same
> time we need to resist the temptation to keep
> tinkering
> for the sake of incremental improvements.
> 
> I suppose what we ideally should do is focus down to
> what the critical disagreements are and resolve those,
> at least to the level that we can proceed ahead.
> 
> The issue of SGPs/SS7 NM seems to be one of these
> main disagreements, I'd like to identify what others
> there are if any and focus on solely on resolving
> these.
> 
> Cheers,
> 
> Lyndon
> 
> --- Jeff Copley <[email-masked]> wrote:
> > Lyndon,
> >
> > I understand that other organizations want to use
> > M3UA and are anxious
> > to have something firm that they can use.  They are
> > also waiting on
> > resolution of SCTP (last I checked).  I think we
> > need to address their
> > concerns, BUT, I think we also need to put out a
> > standard that will be
> > interpretted in just one way.  I would think that
> > those organizations
> > wanting a standard would prefer one without so many
> > unresolved issues
> > (and no, I didn't make a list).
> >
> > There are so many threads on M3UA regarding
> > different interpretations
> > that it is difficult keep up with them.  All the
> > conversation is good
> > with respect to working the issues, but how can we
> > call M3UA ready for
> > last call with so many issues?
> >
> > Jeff
> >
> > Lyndon Ong wrote:
> > >
> > > Folks,
> > >
> > > There continue to be numerous comments on M3UA v7,
> > at the same time I have been getting messages from
> > people or groups who are interested in using M3UA
> > for their protocols and would like very much to have
> > it completed.  In other words, we really need to get
> > this finalized, so we should be focusing on actual
> > errors, and pushing new functions or fine points
> > into extension drafts.  Otherwise we may end up
> > losing our "customers".
> > >
> > > This being the case, can I poll the group to see
> > if there are objections to moving M3UA v7 to IESG
> > review/IETF Last Call?  Keep in mind that during
> > IETF Last Call, you will have another opportunity to
> > comment.
> > >
> > > 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]>
> begin:vcard
> > n:Copley;Jeff
> > tel;work:972.519.3758
> > x-mozilla-html:FALSE
> > org:Alcatel USA, Inc.
> > version:2.1
> > email;internet:[email-masked]
> > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
> > NSGAP;Plano;Texas;75075-5813;USA
> > x-mozilla-cpt:;20864
> > fn:Jeff Copley
> > end:vcard
> >
> >
> >
> > > ---
> > You are currently subscribed to sigtran as:
> > [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> >
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\Jeff.Copley10.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 27 Jul 2001 10:00:52 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA - ASP CAPABILITIES
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Warren,

ASP Capabilities indicates the capabilities of the ASP, not the capabilities
of the SG.  The ASP must perform an ASPAC against a class 3 routing context
before class 3 capabilities are required.  As SUA has no dynamic
registration, all that the SG need do is not provision class 3 routing
contexts.
If the ASP is confused an performs an ASPAC on an invalid routing context,
the error "Error - Invalid Routing Context" will result.

I cannot imagine what the purpose of ASP CAPs are.  I had proposed that they
be removed.

--brian

Warren Anthony Briggs wrote:                               (Fri, 27 Jul 2001
09:21:50)
> Hi All,
> 
> I hope this has not been discussed previously on the list.
> 
> Is there a need in  the SUA draft to include a specific error code to
> deal with an unsupported protocol class at the SG?   For instance when
> receiving an ASPUP at the SG with ASP CAPABILITIES  Protocol Class 3,
> the SG may want to respond with "Error - Unsupported Protocol Class".
> 
> Regards,
> 
> Waren Briggs
> 
> 
> 
> ---
> 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: Fri, 27 Jul 2001 10:13:35 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: M3UAv8: Reason Parameter
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 
                      KAA27164
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-202.dallas.net [209.44.42.202]
List-Unsubscribe: <mailto:[email-masked]>

Greg,

You missed deleting the line:

--->	Reason		Mandatory
	INFO String	Optional

in section 3.5.4.

--brian

-- 
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]
To: "sigtran" <[email-masked]>
Date: Fri, 27 Jul 2001 08:18:47 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: Re: Mail archive.
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]
List-Unsubscribe: <mailto:[email-masked]>

Hi Ivan,

We've had some problems with synchronizing the IETF and Nortel mail
archives, we have gaps because of changes in mail servers, etc.  The Nortel
ftp site (ftp://standards.nortelnetworks.com) has some old message archives
if you are going so far back, that might be the best source for early mails.

Cheers,

Lyndon 
--

On Fri, 27 Jul 2001 15:19:39   Ivan.Arias-Rodriguez wrote:
>	Hi all!
>
>	I would like to take a look to the SIGTRAN mail archive of 1999 (and
>maybe also from the second half of 1998). I have been surfing the IETF
page,
>but even if it is supposed that there is an archive there, it is full of 0
>bytes files to download (not that helpful :-)).
>
>	I have also seen an archive in the Nortel pages, but they start in
>April 1999...
>
>	Does anybody know if I can find what I'm looking for somewhere in
>Internet?
>
>	Thanks!
>
>	BR Ivan Arias Rodrmguez
>
>	
>
>
>---
>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]
Date: Fri, 27 Jul 2001 10:35:01 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UAv8: Traffic Mode in Routing Key
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 
                      KAA27528
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

In section 3.6.1 it is unclear whether the Traffic Mode Type field of the
Routing Key parameter has a Tag and Length or not.  If not, why not?  All
the other fields have Tags and Lengths...

--Brian

-- 
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: Fri, 27 Jul 2001 10:39:35 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UAv8: REG RSP
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 
                      KAA27713
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Now I'm really confused.  Do Local-RK-Identifier Value, Registration Status
and Routing Context have Tags and Lenghts in the Registration Result
paramter?  Locak-RK-Identifier has tag and length in the Routing Key....
These are either very unclear or not consistent at all.

--Brian

-- 
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]
Sender: [email-masked]
Date: Fri, 27 Jul 2001 10:41:17 -0500
From: Tom George <[email-masked]>
Organization: Alcatel USA, Inc. http://www.USA.Alcatel.com/
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: M2PA changes for version 3
X-SMTP-HELO: netmail.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail.alcatel.com [128.251.168.50]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

M2PA Changes for version 3
07/20/2001

Here are the changes in draft-ietf-sigtran-m2pa-03.txt (M2PA version 3), and
a list of open issues.

If anyone wants to study the changes in detail, I have a "diff" file I can
send.

A short summary of the changes:
-------------------------------

1. Proving procedure added to alignment. It includes normal and
   emergency proving.

2. Changed header to the common header used by other adaptation
   layers.

3. SCTP association is now created "early", rather than waiting for
   MTP3 Start.

4. Added a section on version control.

5. Added extensibility text in section 7.2.

6. A lot of clarifying, rewording, and corrections.

A more detailed list of changes:
--------------------------------

This is not a complete list of changes. I did not include minor rewording.

1.7.4 SCTP Stream Management: The new Proving Data messages are sent on the
Data stream.

1.8.1 Definition of the M2PA / MTP Level 3 boundary: Added LPO and LPO
Recovered to the list of primitives.

1.8.1 Definition of the M2PA / MTP Level 3 boundary: Emergency and Emergency
Ceases are no longer ignored by M2PA.

1.9 Differences Between M2PA and M2UA: Added item (e) to the list of
differences.

2.1 Common Message Header: Changed to the common message header.

2.1.2 Spare: Added a description of the Spare field.

2.1.3 Message Class: Added description of Message Class.

2.1.4 Message Type: Added Proving Data to list of Message Types.

2.1.4 Message Length: (oops, there are two section 2.1.4's) Message Length
now INCLUDES the header.

2.2.1 User Data: Added some text to clarify the transmission order of the
Data in the User Data message. This is similar to the wording in the M3UA
draft.

2.2.2 Link Status: Changed the list of values, and added new ones.

2.2.3 Proving Data: Added the Proving Data message.

3.  M2PA Link State Control: Changed the state diagram section. Now there
are 2 diagrams. One shows the states of the M2PA link. The other shows the
states of M2PA's management of the association.

3.  M2PA Link State Control: Changed definition of AIP state.

3.  M2PA Link State Control: INS-LOCAL is replaced by ALIGNED READY.

3. Figure 6: various changes to the diagram

3. Figure 7: Added this new figure.

4.1.2 MTP and SCTP Entities: This information was in the Alignment section.
I separated it into its own section.

4.1.2: Changed the procedure to recommend that the SCTP association be
created early. M2PA does not have to wait for MTP3 Start.

4.1.2: Figure 10. Removed P2, since it is not used.

4.1.2: Table 3. Changed P2 to PW. There was no P2 in Figure 10.

4.1.2: Replaced "endpoint" with "IP address" in several places where it was
more accurate.

4.1.3 Link Alignment: Changed this section significantly. Added a proving
procedure. Added normal and emergency alignment.

4.1.3 Link Alignment: M2PA will attempt to complere alignment if there is a
processor outage.

4.1.4 Processor Outage: Removed the statement about discarding messages.

4.1.4 Processor Outage: PO causes timer T6 to stop.

4.1.6 Error Monitoring: Added more criteria for evaluating link performance.
Made this implementation dependent.

4.1.8 M2PA Version Control: Added this section. It is similar to wording in
the UA drafts.

4.2.5 MTP3 Signaling Link Congestion: Corrected the information that is sent
to MTP3.

4.2.6.1 Multiple User Data Streams and Changeover: Added this section. It
explores the possibility of links with multiple streams.

5.1 Link Initialization (Alignment): Changed the diagram to reflect the new
procedure.

7.2  M2PA Protocol Extensions: Added this section. It is similar to wording
in the UA drafts.

Mistakes I've already found:
----------------------------

2.1.4: Make the 2nd section 2.1.4 into 2.1.5.

2.2.2 Link Status: The phrase "Except as modified later in this section,"
should be deleted, since the format is not modified later.

Text in the paragraph above Figure 10: Should say "IP addresses", not
"endpoints".

-- 
* Tom George        972-519-3168         [email-masked]   * *
PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  * *
Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   * * I
actively disclaim speaking for Alcatel USA, Inc. I do not purport * * to
advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 27 Jul 2001 10:57:52 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2PA: Acknowledgement Problem
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 
                      KAA28223
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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Tom,

You did not address this issue in M2PAv3.  Why not?

--Brian

On Fri, 25 May 2001, Brian F. G. Bidulock wrote:

> Tom,
> 
> This is a separate note to attempt to address the acknowledgment
> problem in M2PA.  This problem occurs whenever M2PA attempts to
> give one of the following indications:
> 
>         Out of Service
>         Busy
>         Processor Outage
> 
> In the case of SS7 (SIOS, SIB, SIPO), the signalling link stops
> acknowledging received frames.  In the case of M2PA, SCTP
> continues acknowledging DATA chunks after these indications are
> sent.  This has the problem of clearing the MSUs from the sender's
> transmission and retransmission buffers and making them
> unavailable for retrieval should the link fail as a result of
> any of these indications (it always fails for "Out of Service").
> 
> This increases message loss due to failure.  At the SS7 link
> level, SS7 links DO NOT ACKNOWLEDGE MSUs UNTIL THEY ARE
> SUCCESSFULLY DELIVERABLE TO MTP LEVEL 3!
> 
> (Please excuse the caps.)
> 
> What is required for M2PA to bring message loss back down to
> acceptable levels is for M2PA to have a way of controlling when
> MSUs are acknowledged to the peer.  There are two ways of doing
> this:
> 
>         1)  Alter SCTP-ULP interaction to permit M2PA to tell
>             SCTP when to acknowledge DATA chunks and when not
>             to.
> 
>         2)  Put sequence numbers and acknolwedgement in the DATA
>             chunks with the MSUs themselves (i.e. put FSN/BSN in
>             the frame).
>             
> I prefer solution #2, because it will probably be a cold day
> before SCTP gets changed.
> 
> This is also a problem for M2UA.
> 
> 
> -- 
> 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 ¦

-- 
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]
To: "sigtran" <[email-masked]>
Subject: m2ua v9 - unclear text for ASPAC msg
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
From: [email-masked]
Date: Fri, 27 Jul 2001 14:57:14 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/27/2001 12:00:29 PM, Serialize 
             complete at 07/27/2001 12:00:29 PM
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ken,

Section 3.3.2.5 (ASPAC) states:

"If only a subset of Interface Identifiers are included, the ASP is noted as
Active for all the Interface Identifiers provisioned for _that_ AS."

It is not clear which AS is referred to by "that AS". This sentence must be
made more clear.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 27 Jul 2001 14:38:58 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: m2ua v9 - unclear text for ASPAC msg
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.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Barry,

 < ASP is provisioned.  If only a subset of Interface Identifiers are  <
included, the ASP is noted as Active for all the Interface Identifiers  <
provisioned for that AS.
 ---
 > ASP is provisioned.  If only a subset of Interface Identifiers for an AS
> are included, the ASP is noted as Active for all the Interface  >
Identifiers provisioned for that AS.

--brian

[email-masked] wrote:                (Fri, 27 Jul 2001
14:57:14)
> Ken,
> 
> Section 3.3.2.5 (ASPAC) states:
> 
> "If only a subset of Interface Identifiers are included, the ASP is noted 
> as Active for all the Interface Identifiers provisioned for _that_ AS."
> 
> It is not clear which AS is referred to by "that AS". This sentence must 
> be made more clear.
> 
> Barry Nagelberg
> Software Engineer
> RadiSys, Corp.
> Signaling Products Design Center
> [email-masked]
> +1-856-642-9229 x237
> 
> 
> 
> ---
> 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: [email-masked]
To: "sigtran" <[email-masked]>
Subject: m2ua v9 - ASP Up from an unregistered ASP
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Date: Fri, 27 Jul 2001 15:41:03 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/27/2001 12:44:10 PM, Serialize 
             complete at 07/27/2001 12:44:10 PM
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]

Ken,

Now that we have added dynamic registration to M2UA, the following text,
which I copied from m3ua v8, should be added to section 4.3.3.1 (ASP Up
Procedures). It relates to the case in which an ASP Up message is received
from an ASP which has not yet been configured in an AS:

"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."

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Routing Context
Date: Fri, 27 Jul 2001 12:44:42 -0700
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ztxmail04.ztx.compaq.com [161.114.1.208]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I think you need to step back for a moment and re-examine what you are
trying to solve.  I think you are trying to solve the case where an SS7 node
wants to have an appearance in more than one network, hence, the concept of
MTP-SAP.  But in your case you want all traffic to flow through the same
signalling path to the node.

Below is the SS7 scenario:
                              _________
                             (         )
                       _____(  Network  )
                      /     (     A     )
     +----------+    /       (_________)
     |          |___/
     | SS7 node |___
     |    S     |   \         _________
     +----------+    \       (         )
                      \_____(  Network  )
                            (     B     )
                             (_________)

Node S has separate links to Networks A & B.  Node S is identified by a
point code from each network, for now lets call them, x (from Network A) and
y (from Network B).  The MTP-SAP concept was added (a local concept) where
node S had to associate a network ID to Networks A & B, lets use A & B as
the Network IDs.  Hence, node S has to mark each message received with a
Network ID of A or B, based on the network it was received from.  Outbound
messages from the MTP-users also had to be marked with a network ID.
Logically, Node S could be viewed as have 2 SCCP/MTP protocol stacks.  The
network ID is used to discriminate which protocol stack handles which
message.  

For an applications point-of-view (SSN), the easy case is when the message
being sent is a reply, i.e., given the same network ID as the received
message.  If the message is being generated from the application, the
application would need to know which network it was destined for and mark
it.

Hence, Network ID + point code uniquely identified the destination.  The
network ID is used to select the protocol stack/links belonging a specific
network, and the PC to select the correct route to that network.

This same picture can be moved over to the SS7 over IP case.  If Node S has
separate connections to the different networks, it must locally keep track
of the networks.  The SGs that it connects to do not have to be involved.

Now what about the picture where you have the SGs connecting to the
different networks.  There are 2 cases in this situation: 1) traffic is
separated and 2) traffic is merged.  

Traffic is Separated:  The traffic could be kept separate by having Node S
establish connections to the different "sides" of the SG.  This would be in
line with the SS7 rules that the SG would have present a different
"appearance", actually a physical point code, for each network represented.
Look at the figure below:

                          +--------+        _________
                          |+------+|       (         )
                       ___||  SG  ||______(  Network  )
                      /   ||   A  ||      (     A     )
     +----------+    /    |+------+|       (_________)
     |          |___/     |        |
     | SS7 node |___      |   SG   |
     |    S     |   \     |        |        _________
     +----------+    \    |+------+|       (         )
                      \___||  SG  ||______(  Network  )
                          ||   B  ||      (     B     )
                          |+------+|       (_________)
                          +--------+

The A-side of the SG and of Node S requires a point code from network A.
The B-side of the SG and of Node S requires a  point code from network B.
Each node, S and SG, could internal keep track of the messages/networks by
using their own network ID.  They could also agree (network operator option)
to use the "network appearance" parameter so that node S and SG (and other
nodes) use a common ID for the networks.

Traffic is Merged:  IMHO, this is a more difficult case to visualize.  Below
is a figure.

                          +--------+        _________
                          |        |       (         )
                          |        |______(  Network  )
                          |        |      (     A     )
     +----------+         |        |       (_________)
     |          |         |        |
     | SS7 node |---------|   SG   |
     |    S     |         |        |        _________
     +----------+         |        |       (         )
                          |        |______(  Network  )
                          |        |      (     B     )
                          |        |       (_________)
                          +--------+

In this case Node S and the SG must share an agreed to "network appearance"
for each network that is involved (Network A & B).  I assume that this will
be network operator assigned (network operator that owns Node S and SG).
This will take care of the messaging and the network management. But what is
the basis for creating the connection between Node S and the SG.  It was the
adjacent physical point codes that both Node S and SG had (and must still
have), but what is it now?  I will have to think on how to eliminate the
adjacent PC in this.

But I still conclude that all that is required is the "network appearance"
defined as a network ID.

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Friday, July
27, 2001 4:24 AM
To: sigtran
Cc: Greg Sidebottom
Subject: Re: M3UA: Routing Context

John, Greg,

Some of these things aren't apparent until one tries to go and build the
thing.

Here is the problem:  architecturally, M3UA exports the MTP-Provider/User
interface, like so:

                                   Application      Application 
                                    Server #2        Server #1  
                                   ___________      ___________ 
                                  |           |    |           |
                                  |   MTP     |    |   MTP     |
                                  |   User    |    |   User    |
                                  |           |    |           |
                                  |___________|    |___________|
                                     |     ^          |     ^   
                          __         |     |          |     |   
              ___________/__\_______/     /           |     |   
             /   _______|____|___________/            |     |   
            /   /       |    |                       /     /    
           /   /        |    |           __         /     /     
          /   / ________|____|______<___/__\_______/     /      
          |   |/   _____|____|______>__|____|___________/       
          |   /   /      \__/           \__/                    
          |  /|  /         \              \                     
          | / | /           \              \                    
          ||  ||             \              \                   
        __vv__||__         One SCTP       Routing               
       |          |       Association     Context               
       |          |                                             
       |   MTP    |                                             
       | Provider |                                             
       |          |                                             
       |          |                                             
       |__________|                                             
                                                                
        Signalling                                              
         Gateway                                                
        (Process)                                               
                                                                
  Where, the MTP-SAP can be identified by the Routing Context.  The SG may
apply a "Routing Key" to find the MTP-SAP, but this is a function which is
performed *below* the MTP-User interface.  If M3UA would label all messages
with the Routing Context (where ambiguous, as shown), then there would be no
confusion as to which MTP-SAP is being used either for outgoing or incoming
messages.

For example, when the SG performs transfer-prohibited procedures and
discovers that an SPMC signalling point is prohibited off a routeset, it
informs the MTP-Users.  So, the MTP has a list of "Users" to which it sends
MTP-PAUSE primitives.  We have the same thing in the SG, a list of routing
contexts, each which represents an MTP-User bound to an MTP-SAP.  So
instead, of attaching a list of Routing Contexts to the DUNA (or sending
multiple DUNAs, each with its own routing context), we are throwing up a
DUNA with a "Network Appearance".  There are a number of cases where the
Network Appearance becomes ambiguous at the ASP unless Network Appearance ==
Routing Context. (And then what is the point of two names for the same
thing?)

For the ASP -> SGP direction, consider that the MTP at the SG cannot
determine the origin of the message (i.e, which MTP-SAP the message came
from.)  There is nothing stopping AS#2 from placing an OPC/SI in the message
which doesn't belong to it.  In fact, the MTP-User should not even be
putting the OPC/SI in the message: the SG should do this on the basis of the
DPC key associated with the Routing Context.  I don't think that the SG
should just blindly route messages based on DPC without any screening
whatsoever.

Now, I am fully aware that you do not believe in MTP-SAPs which are not the
"whole" point code.  But in the case where routing keys are "whole" point
codes, Network Appearance == Routing Context.  For sub-point code MTP-SAPs
(e.g., ISUP goes to AS#1, SCCP to AS#2), AS#1 needs to be screened off of
placing a non-ISUP SI in the routing label, and not using its own point
code.  AS#1 needs to have messages screend by DPC as well unless one wants
to try to replicate gateway screening above the MTP-User interface.

So, John, you should not care if Network Appearance is replaced with Routing
Context, because in your case Network Appearance == Routing Context, even
though you don't see the need, because it is not applicable in your cases.

--brian

Schantz, John wrote:                        (Mon, 23 Jul 2001 13:04:29)
> Brian,
> 	This doesn't really make any sense and I don't see the need.
> 
> 	Why would you need a routing context in a DATA from SGP to ASP.  The
> ASP should be determining where the message goes locally in the AS(s)
based
> on parameters from the SS7 message.
> 
> 	Requiring it in the DATA from the AS to SG doesn't make any sense.
> The SG should be determining how to forward route the message based on the
> SS7 message parameters (Routing Label).  Why would the responding AS even
> know the RC of a remote node.  Or are you proposing that a backward RC be
> included.  Forward routing should not be based on backward information.
> 
> 	Hence, the answer to your question of whether there is an objection
> to including the RC in the DATA message, YES I object.
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, July 23, 2001 6:07 AM
> To: sigtran
> Cc: Greg Sidebottom
> Subject: M3UA: Routing Context
> 
> 
> Greg,
> 
> I would like to propose that the Routing Context be added as an
> optional parameter to which SHOULD be included in the DATA
> messages from the SGP and MUST be included in DATA messages from
> the ASP when the ASP is active for more than one Application
> Server.
> 
> This is *not* a replace-Network-Appearance-with-Routing-
> Context-proposal.
> 
> The purpose of adding RC to DATA messages is to distinguish
> multiple traffic flows which are multiplexed over the
> association for use in:
> 
>     o   demultiplexing data traffic at the ASP without having to
> 	reapply the Routing Key to each message to determine
> 	routing context,
> 
>     o   distinguishing traffic flows for discarding data
>         messages during ASPAC and ASPIA procedures, both at
> 	the SG and the ASP (again without having to reapply
> 	the Routing Key to each message at each end),
> 
>     o   demultiplexing buffered data messages at the ASP and the
>         SG during failover or AS-PENDING, again, without having
> 	to reapply a complex Routing Key.
> 
>     o   assists in diagnostics by permitting monitoring
>         equipment to at least distinguish traffic flows without
> 	having to provision monitoring equipment with routing
> 	keys.
> 
> It sure simplifies a lot of places in the implementation where
> one would have to otherwise reapply the routing key.
> 
> I should point out that, for some routing keys (e.g, SCCP SSN)
> it is currently impossible for the SGP to distinguish between AS
> for *incoming* traffic when there are multiple AS on an
> association.  This is because the Routing Key-->Routing
> Context-->AS mapping is only valid for traffic from the SGP
> towards the ASP.
> 
> Any objections to including RC in DATA messages?
> 
> --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]
> 
> 
> ---
> 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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Fri, 27 Jul 2001 18:05:30 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: m2ua v9 - unclear text for ASPAC msg
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Sounds fine with me.  Thanks Brian. 

Ken

At 02:38 PM 7/27/01 -0500, Brian F. G. Bidulock wrote:
>Barry,
>
>
>  < ASP is provisioned.  If only a subset of Interface Identifiers are 
>  < included, the ASP is noted as Active for all the Interface Identifiers 
>  < provisioned for that AS.
>  ---
>  > ASP is provisioned.  If only a subset of Interface Identifiers for an
AS
>  > are included, the ASP is noted as Active for all the Interface
>  > Identifiers provisioned for that AS.
>
>--brian
>
>
>[email-masked] wrote:                (Fri, 27 Jul 2001
14:57:14)
> > Ken,
> > 
> > Section 3.3.2.5 (ASPAC) states:
> > 
> > "If only a subset of Interface Identifiers are included, the ASP is
noted 
> > as Active for all the Interface Identifiers provisioned for _that_ AS."
> > 
> > It is not clear which AS is referred to by "that AS". This sentence must

> > be made more clear.
> > 
> > Barry Nagelberg
> > Software Engineer
> > RadiSys, Corp.
> > Signaling Products Design Center
> > [email-masked]
> > +1-856-642-9229 x237
> > 
> > 
> > 
> > ---
> > 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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Fri, 27 Jul 2001 18:10:04 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: m2ua v9 - ASP Up from an unregistered ASP
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Yes, this text does need to be added.

Thanks,

Ken

At 03:41 PM 7/27/01 -0400, you wrote:
>Ken,
>
>Now that we have added dynamic registration to M2UA, the following text, 
>which I copied from m3ua v8, should be added to section 4.3.3.1 (ASP Up 
>Procedures). It relates to the case in which an ASP Up message is received 
>from an ASP which has not yet been configured in an AS:
>
>"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."
>
>Barry Nagelberg
>Software Engineer
>RadiSys, Corp.
>Signaling Products Design Center
>[email-masked]
>+1-856-642-9229 x237
>
>
>
>---
>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: Fri, 27 Jul 2001 18:21:58 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: M2UAv9 - Status of Comments
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

All:

So far, there have been 8 issues registered against M2UA v9.  There have
also been several minor grammar and spelling corrections.

Below is an update the registered issues:

Issue #1 - clarification of Correlation ID / Data Ack text, reason behind
REG and DEREG message

     Status:  CLOSED

     I'm closing this issue because the Correlation ID / Data Ack is now 
     Issue #6 and reason for REG / DEREG has been sent.

Issue #2 - ASP Identifier mandatory OR addition of new Error codes

     Status:  CLOSED

     Adopted text in SUAv7 to keep ASP Identifier optional with the
     addition of Error messages that can be used to request an ASP
     Identifier.

Issue #3 - re-add Heartbeat / Heartbeat Ack

     Status:  CLOSED

     Consensus to re-add and remove limitation that ASP side must 
     initiate.

Issue #4 - Remove Reason parameter in ASP Down (Down Ack) message

     Status:  CLOSED

     Consensus to remove because no justification for Reason parameter.

Issue #5  - Support for SG Processes in M2UA

     Status:  CLOSED

     Concept of SG Process was added to the document.  Text changes 
     were posted to list and reviewed.

Issue #6 - Text clarification to Correlation ID / Data Ack message

     Status:  CLOSED

     Text changes were posted to the list that discussed use of Correlation
     ID and Data Ack message.  In addition, error cases were discussed.

Issue #7 - how to handle Invalid Interface identifiers in ASP Active

      Status:  CLOSED

      Posted text changes to list 

Issue #8 - Need to clarify that ASP cannot send DEREG message while 
      in ASP-ACTIVE state

      Status:  CLOSED

      Text changes were posted to the list.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 27 Jul 2001 18:55:10 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Routing Context
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

I'm glad you broght this up.  Let me just modify your diagram slightly and
we can move to the next level:

                            _________  
                           (   Sub   ) 
                     _____(  Network  )_____
     5.255.3        /     (     A     )     \       _________
   +----------+    /       (_________)       \     (         )
   |          |___/                           \___(  Network  )
   | SS7 node |___                             ___(     Y     )
   |    S     |   \         _________         /    (_________)
   +----------+    \       (   Sub   )       /
     5.255.4        \_____(  Network  )_____/
                          (     B     )
                           (_________) 

The SS7 node S has two point codes (5.255.3 and 5.255.4) in Network Y which
are attached by subnetworks A and B which are disjoint at S.  One is, say, a
point code S uses to connect to SNET, the other is used to connect to AT&T.
They both belong to the same SS7 point code administrative domain.  (That
is, they both have the same Network Id.)

Following your diagrams through...
                                                              5.255.5
                                                              ________ 
                                                             |        |
                    +--------+        _________              |  Node  |
                    |        |       (         )             |    X   |
                    |        |______(  Network  )_____       |________|
     5.255.3        |        |      (     A     )     X       ____|____
   +----------+     |        |       (_________)       X     (         )
   |          |     |        |                          X___(  Network  )
   | SS7 node |-----|   SG   |                           ___(     Y     )
   |    S     |     |        |        _________         /    (_________)
   +----------+     |        |       (         )       /
     5.255.4        |        |______(  Network  )_____/
                    |        |      (     B     )
                    |        |       (_________)
                    +--------+

Because, as shown, point code X can be inaccessible from 5.255.3, but can
still be accessible from 5.255.4, these two point codes within the same
network need different Network Appearances to distinguish for which point
code the DUNA(X) applies.  If each SPMC behind the SG has its own physical
routes (links) to the SS7 network on the SS7 side of the SG, each will need
its own Network Appearance to distinguish signalling network management
menssages which are destined to it alone.

If the Routing Context for these point codes is the "whole" point code, then
each point codes requires both a Unique Routing Context and a Unique Network
Appearace.  Thus, Routing Context == Network Appearance.

Plus, as above, one Network Appearance can be required for each point code,
not each Network Id, as it might appear.  (Even if, as shown, the point
codes are even in the same block!) Because Routing Context is already
assigned on an MTP-User basis at the ASP, it uniquely determines which
MTP-User at the ASP to which the DUNA message applies.  There is no need for
messing around with Network Appearances.  Just use the Routing Context.  The
Routing Context is required for other purposes anyway (it uniquely
identifies an Application Server and a Routing Key).

--brian

> In this case Node S and the SG must share an agreed to "network
appearance"
> for each network that is involved (Network A & B).  I assume that this
will
> be network operator assigned (network operator that owns Node S and SG).
> This will take care of the messaging and the network management. But what
is
> the basis for creating the connection between Node S and the SG.  It was
the

Schantz, John wrote:                                     (Fri, 27 Jul 2001
12:44:42)
> Brian,
> 
> I think you need to step back for a moment and re-examine what you are
> trying to solve.  I think you are trying to solve the case where an SS7
node
> wants to have an appearance in more than one network, hence, the concept
of
> MTP-SAP.  But in your case you want all traffic to flow through the same
> signalling path to the node.
> 
> Below is the SS7 scenario:
>                               _________
>                              (         )
>                        _____(  Network  )
>                       /     (     A     )
>      +----------+    /       (_________)
>      |          |___/
>      | SS7 node |___
>      |    S     |   \         _________
>      +----------+    \       (         )
>                       \_____(  Network  )
>                             (     B     )
>                              (_________)
> 
> Node S has separate links to Networks A & B.  Node S is identified by a
> point code from each network, for now lets call them, x (from Network A)
and
> y (from Network B).  The MTP-SAP concept was added (a local concept) where
> node S had to associate a network ID to Networks A & B, lets use A & B as
> the Network IDs.  Hence, node S has to mark each message received with a
> Network ID of A or B, based on the network it was received from.  Outbound
> messages from the MTP-users also had to be marked with a network ID.
> Logically, Node S could be viewed as have 2 SCCP/MTP protocol stacks.  The
> network ID is used to discriminate which protocol stack handles which
> message.  
> 
> For an applications point-of-view (SSN), the easy case is when the message
> being sent is a reply, i.e., given the same network ID as the received
> message.  If the message is being generated from the application, the
> application would need to know which network it was destined for and mark
> it.
> 
> Hence, Network ID + point code uniquely identified the destination.  The
> network ID is used to select the protocol stack/links belonging a specific
> network, and the PC to select the correct route to that network.
> 
> This same picture can be moved over to the SS7 over IP case.  If Node S
has
> separate connections to the different networks, it must locally keep track
> of the networks.  The SGs that it connects to do not have to be involved.
> 
> Now what about the picture where you have the SGs connecting to the
> different networks.  There are 2 cases in this situation: 1) traffic is
> separated and 2) traffic is merged.  
> 
> Traffic is Separated:  The traffic could be kept separate by having Node S
> establish connections to the different "sides" of the SG.  This would be
in
> line with the SS7 rules that the SG would have present a different
> "appearance", actually a physical point code, for each network
represented.
> Look at the figure below:
> 
>                           +--------+        _________
>                           |+------+|       (         )
>                        ___||  SG  ||______(  Network  )
>                       /   ||   A  ||      (     A     )
>      +----------+    /    |+------+|       (_________)
>      |          |___/     |        |
>      | SS7 node |___      |   SG   |
>      |    S     |   \     |        |        _________
>      +----------+    \    |+------+|       (         )
>                       \___||  SG  ||______(  Network  )
>                           ||   B  ||      (     B     )
>                           |+------+|       (_________)
>                           +--------+
> 
> The A-side of the SG and of Node S requires a point code from network A.
> The B-side of the SG and of Node S requires a  point code from network B.
> Each node, S and SG, could internal keep track of the messages/networks by
> using their own network ID.  They could also agree (network operator
option)
> to use the "network appearance" parameter so that node S and SG (and other
> nodes) use a common ID for the networks.
> 
> Traffic is Merged:  IMHO, this is a more difficult case to visualize.
Below
> is a figure.
> 
>                           +--------+        _________
>                           |        |       (         )
>                           |        |______(  Network  )
>                           |        |      (     A     )
>      +----------+         |        |       (_________)
>      |          |         |        |
>      | SS7 node |---------|   SG   |
>      |    S     |         |        |        _________
>      +----------+         |        |       (         )
>                           |        |______(  Network  )
>                           |        |      (     B     )
>                           |        |       (_________)
>                           +--------+
> 
> In this case Node S and the SG must share an agreed to "network
appearance"
> for each network that is involved (Network A & B).  I assume that this
will
> be network operator assigned (network operator that owns Node S and SG).
> This will take care of the messaging and the network management. But what
is
> the basis for creating the connection between Node S and the SG.  It was
the
> adjacent physical point codes that both Node S and SG had (and must still
> have), but what is it now?  I will have to think on how to eliminate the
> adjacent PC in this.
> 
> But I still conclude that all that is required is the "network appearance"
> defined as a network ID.
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 4:24 AM
> To: sigtran
> Cc: Greg Sidebottom
> Subject: Re: M3UA: Routing Context
> 
> 
> John, Greg,
> 
> Some of these things aren't apparent until one tries to go
> and build the thing.
> 
> Here is the problem:  architecturally, M3UA exports the MTP-Provider/User
> interface, like so:
> 
>                                                                 
>                                                                 
>                                    Application      Application 
>                                     Server #2        Server #1  
>                                    ___________      ___________ 
>                                   |           |    |           |
>                                   |   MTP     |    |   MTP     |
>                                   |   User    |    |   User    |
>                                   |           |    |           |
>                                   |___________|    |___________|
>                                      |     ^          |     ^   
>                           __         |     |          |     |   
>               ___________/__\_______/     /           |     |   
>              /   _______|____|___________/            |     |   
>             /   /       |    |                       /     /    
>            /   /        |    |           __         /     /     
>           /   / ________|____|______<___/__\_______/     /      
>           |   |/   _____|____|______>__|____|___________/       
>           |   /   /      \__/           \__/                    
>           |  /|  /         \              \                     
>           | / | /           \              \                    
>           ||  ||             \              \                   
>         __vv__||__         One SCTP       Routing               
>        |          |       Association     Context               
>        |          |                                             
>        |   MTP    |                                             
>        | Provider |                                             
>        |          |                                             
>        |          |                                             
>        |__________|                                             
>                                                                 
>         Signalling                                              
>          Gateway                                                
>         (Process)                                               
>                                                                 
>                                                                 
> Where, the MTP-SAP can be identified by the Routing Context.  The SG may
> apply a "Routing Key" to find the MTP-SAP, but this is a function which
> is performed *below* the MTP-User interface.  If M3UA would label all
> messages with the Routing Context (where ambiguous, as shown), then
> there would be no confusion as to which MTP-SAP is being used either for
> outgoing or incoming messages.
> 
> For example, when the SG performs transfer-prohibited procedures and
> discovers that an SPMC signalling point is prohibited off a routeset, it
> informs the MTP-Users.  So, the MTP has a list of "Users" to which it
> sends MTP-PAUSE primitives.  We have the same thing in the SG, a list
> of routing contexts, each which represents an MTP-User bound to an
> MTP-SAP.  So instead, of attaching a list of Routing Contexts to the
> DUNA (or sending multiple DUNAs, each with its own routing context), we
> are throwing up a DUNA with a "Network Appearance".  There are a number
> of cases where the Network Appearance becomes ambiguous at the ASP
> unless Network Appearance == Routing Context. (And then what is the
> point of two names for the same thing?)
> 
> For the ASP -> SGP direction, consider that the MTP at the SG cannot
> determine the origin of the message (i.e, which MTP-SAP the message came
> from.)  There is nothing stopping AS#2 from placing an OPC/SI in the
> message which doesn't belong to it.  In fact, the MTP-User should not
> even be putting the OPC/SI in the message: the SG should do this on the
> basis of the DPC key associated with the Routing Context.  I don't think
> that the SG should just blindly route messages based on DPC without any
> screening whatsoever.
> 
> Now, I am fully aware that you do not believe in MTP-SAPs which are not
> the "whole" point code.  But in the case where routing keys are "whole"
> point codes, Network Appearance == Routing Context.  For sub-point code
> MTP-SAPs (e.g., ISUP goes to AS#1, SCCP to AS#2), AS#1 needs to be
> screened off of placing a non-ISUP SI in the routing label, and not
> using its own point code.  AS#1 needs to have messages screend by
> DPC as well unless one wants to try to replicate gateway screening above
> the MTP-User interface.
> 
> So, John, you should not care if Network Appearance is replaced with
> Routing Context, because in your case Network Appearance == Routing
> Context, even though you don't see the need, because it is not
> applicable in your cases.
> 
> --brian
> 
> 
> 
> Schantz, John wrote:                        (Mon, 23 Jul 2001 13:04:29)
> > Brian,
> > 	This doesn't really make any sense and I don't see the need.
> > 
> > 	Why would you need a routing context in a DATA from SGP to ASP.  The
> > ASP should be determining where the message goes locally in the AS(s)
> based
> > on parameters from the SS7 message.
> > 
> > 	Requiring it in the DATA from the AS to SG doesn't make any sense.
> > The SG should be determining how to forward route the message based on
the
> > SS7 message parameters (Routing Label).  Why would the responding AS
even
> > know the RC of a remote node.  Or are you proposing that a backward RC
be
> > included.  Forward routing should not be based on backward information.
> > 
> > 	Hence, the answer to your question of whether there is an objection
> > to including the RC in the DATA message, YES I object.
> > 
> > John
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Monday, July 23, 2001 6:07 AM
> > To: sigtran
> > Cc: Greg Sidebottom
> > Subject: M3UA: Routing Context
> > 
> > 
> > Greg,
> > 
> > I would like to propose that the Routing Context be added as an
> > optional parameter to which SHOULD be included in the DATA
> > messages from the SGP and MUST be included in DATA messages from
> > the ASP when the ASP is active for more than one Application
> > Server.
> > 
> > This is *not* a replace-Network-Appearance-with-Routing-
> > Context-proposal.
> > 
> > The purpose of adding RC to DATA messages is to distinguish
> > multiple traffic flows which are multiplexed over the
> > association for use in:
> > 
> >     o   demultiplexing data traffic at the ASP without having to
> > 	reapply the Routing Key to each message to determine
> > 	routing context,
> > 
> >     o   distinguishing traffic flows for discarding data
> >         messages during ASPAC and ASPIA procedures, both at
> > 	the SG and the ASP (again without having to reapply
> > 	the Routing Key to each message at each end),
> > 
> >     o   demultiplexing buffered data messages at the ASP and the
> >         SG during failover or AS-PENDING, again, without having
> > 	to reapply a complex Routing Key.
> > 
> >     o   assists in diagnostics by permitting monitoring
> >         equipment to at least distinguish traffic flows without
> > 	having to provision monitoring equipment with routing
> > 	keys.
> > 
> > It sure simplifies a lot of places in the implementation where
> > one would have to otherwise reapply the routing key.
> > 
> > I should point out that, for some routing keys (e.g, SCCP SSN)
> > it is currently impossible for the SGP to distinguish between AS
> > for *incoming* traffic when there are multiple AS on an
> > association.  This is because the Routing Key-->Routing
> > Context-->AS mapping is only valid for traffic from the SGP
> > towards the ASP.
> > 
> > Any objections to including RC in DATA messages?
> > 
> > --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]
> > 
> > 
> > ---
> > 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]

-- 
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: Michael "D." Metcalf <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: $20 Million Invested in Speech Activated Northern Telecom Solution
Reply-To: [email-masked]
X-OriginalArrivalTime: 28 Jul 2001 00:22:40.0260 (UTC) 
                       FILETIME=[6950F440:01C116FB]
Date: 27 Jul 2001 17:22:40 -0700
X-SMTP-HELO: SA-EXCH1.soundadvantage.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [64.94.218.3]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Sound Advantage has invested approximately $20 million to create a new
voice-activated call processing system designed specifically to work on
Northern Telecom systems.

The system is called SANDi, the Sound Advantage Natural Dialog Interface.

Just load the SANDi software into a  Windows NT based server and connect
SANDi to your Northern Telecom digital station ports using a Dialogic D82
station card.  Type in a list of employee names, enter the extension numbers
on your PBX, enter thier email addresses and a path command to your CRM
database.

Presto! You just voice-activated your entire office through your  Northern
Telecom switch and SANDi.

Now with one call to SANDi you can get your voice mail, fax, email and
access your CRM calendar all by voice command.  SANDi can even read your
email to you over the phone.

SANDi will know answer incoming calls and use voice-recognition to transfer
calls to employees located in or out of the office.  Each employee can now
redirect live calls and unified messages to any location.

SANDi saves every business money and every employee time.  The experts
agree.  SANDi has garned a record breaking 21 top industry awards during the
past 24 months.

Sound Advantage wants you to try install SANDi at your office - ASAP.

Please visit www.soundadvantage.com for more info or call me to set up an
installation time.

The competition is speechless.  The rest is all talk.

I look forward to speaking with you.

Sincerely,

Michael D. Metcalf
President

(949)655-1611 SANDi direct

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Sat, 28 Jul 2001 08:07:45 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Network Appearance
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-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

Perhaps now you can see (from our discussion on the thread "M3UA: Routing
Context") that to cover all configurations, a Network Appearance valud is
required per primary point code and network id, and that this proposal was a
natural extension of that fact.  Consider the case below:

                                     __________                  
                            ___     /          \     ___         
                           /   \   |            |   /   \        
                          | SEP |__|____________|__| SEP |       
                           \___/   |            |   \___/        
                          //       |            |                
                         / |       | Signalling |  5.255.3       
                        / /        |   Gateway  |                
                       /  |        |            |                
                      /  /         |            |                
              _____  /   |         |            |                
             |     |/   /          |            |                
        -----| STP |____|__________|______      |                
            /|_____|   /           |      \___  |  5.255.4       
           /    |      |           |          \_|_   ___         
        \ /     |     /            |            | \ /   \        
         X      |     |            |            |  | SEP |       
        / \     |    /             |           _|_/ \___/        
           \  __|__ /              |       ___/ |                
            \|     |_______________|______/     |       5.255.5  
        -----| STP |               |            |       (alias)  
             |_____|               |            |                
                                   |            |                
                                    \__________/                 

The signalling gateway needs two different Network Appearance parameters:
one per SPMC.  The bottom SPMC needs only one Network Appearance to cover
both the primary point code 5.255.4 and the alias point code 5.255.5 because
they are both treated as the same from an SS7 newtork management view.

Now, in general, a rational basis for assigning Network Apearance Id's is to
use the Network Id and Point Code of the node (the node *is* the network
appearance).  Therefore, the DUNA, DAVA, etc. that the SG sends concerning
the SPMC will be properly distinguish.

Note that if the proposed assignment of Network Appearances is used, the
SCON message no longer requires a Concerned Point Code parameter when the
SPMC is signalling congestion to the SG.  It need only use the Network
Appearance.

The definition of a Network Appearance becomes (effectively): "An unique
identifier indicating the Signalling Point Management Cluster (SPMC) to
which Signalling Network Management Messages apply."

--Brian

Schantz, John wrote:                         (Mon, 23 Jul 2001 13:37:00)
> Brian,
> 
> 	Why the need to include a concerned PC at all, the PC would be
> redundant to the one in the DPC.  Why not let the network appearance
> parameter be equal to the Network ID (all 32 bits).  Then Network
> Appearance(Network ID) + DPC will be unique and it will separate out the
> traffic into networks in both directions SG->AS and AS->SG(-> and beyond).
> 
> John 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, July 23, 2001 6:41 AM
> To: sigtran
> Cc: Greg Sidebottom
> Subject: M3UA07: Network Appearance
> 
> 
> Greg,
> 
> When an SG is has multiple point codes serving ASPs which are
> active in multiple SPMCs, it becomes necessary to label each
> SPMC with a unique Network Appearance parameter to demultiplex
> DUNA, DAVA, DRST and SCON.  Because a separate Network Appearance
> assignment is necessary for each SPMC and the adminstration of
> these assignments could get quite tedious for an SGP/ASP pool
> representing a large number of point codes, I would like to
> propose the following refinement to the Network Appearance
> Parameter:
> 
> (This is in fitting with the definition that a "Network Appearance
uniquely
> identifies an SS7 entity (Point Code) into an SS7 network.")
> 
> The format of the Network Appearance parameter 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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Network Id   |            Concerned Point Code               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Network Identifier: 8-bit (unsigned integer)
> 
>    The Network Identifier identifies the network in which the Concerned
>    Point Code can be considered unique, and distinguishes this Concerned
>    Point Code from an identical point code in any another network.
>    A Network Identifier identifying a specific adminsitrative domain for
>    the assignment of SS7 Signalling Point Codes MUST be global to all
>    SGPs in an SG.
> 
> Concerned Point Code:
> 
>    The Concerned Point Code identifies a point code within the
>    administrative domain as indicated by the Network Identifier.  The
>    Concerned Point Code is the one point code of a Signalling Point
>    Management Cluster (SPMC) which needs to receive updates concerning
>    the accessibility/restriction/congestion status of routesets from the
>    SPMC.
> 
> 
> 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]
> 
> 
> ---
> 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: Sat, 28 Jul 2001 09:56:35 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M3UA: Network Appearance and Routing Context
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 
                      JAA14738
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-202.dallas.net [209.44.42.202]
List-Unsubscribe: <mailto:[email-masked]>

Greg, John,

Perhaps we can settle this issue regarding Network Appearance and Routing
Context and make the text changes necessary to advance the draft.  Consider
the following network configuration:

                               Signalling         Application   
                                Gateway             Server      
                                Process      M3UA   Process     
                          _________|________      _____|____    
                         |   _____________  |    |  ______  |__ 
                            /             \        /       \   |
                           |  Signalling   | RC1  |   AS1   |  |
                           |  Gateway      | _____|         |  |
                           |               |/     | (ISUP)  |  |
                    ___    |        ___    /      |         |  |
                   /   \  F-link   /   \  /|       \_______/   |
                  | SEP |__|______| SEP |/ |       /       \   |__ SPMC1
                   \___/   |       \___/ \ | RC2  |   AS2   |  |
                  //    \  |              \|______|         |  |
   NID1          / | F-link|      5.255.3  |      | (SCCP)  |  |
                / /       \|               |      |         |  |
   National    /  |        \               |       \_______/ __|
   Network    /  / A-link  |\              |        _______  __ 
      _____  /   |         | \             |       /       \   |
     |     |/   /  A-link  |  \            | RC3  |         |  |  ----| STP
|____|________  |   \           |______|   AS3   |  |
    /|_____|   /         \_|_   \ 5.255.4  /      |         |  |
   /    |      |           | \___\  ___   /|      | (ISUP)  |  |
  /     |     /            |     \\/   \ / |      |         |  |  X      |
|            |      | SEP |  |       \_______/   |__ SPMC2
  \     |    /             |  ___/ \___/ \ |       /       \   |
   \  __|__ /      A-link _|_/            \| RC4  |         |  |
    \|     |_____________/ |      5.255.5  \______|   AS4   |  |  ----| STP
|               |      (alias)  |      |         |  |
     |_____|               |               |      | (SCCP)  |  |
                           |               |      |         |  |
                           |               |       \_______/ __|
                           |               |        _______  __ 
      _____                |               |       /       \   |
     |     |       A-link  |               | RC5  |         |  |  ----| STP
|_____________  |               |______|   AS5   |  |
    /|_____|             \_|_     40-12-3  /      |         |  |
   /    |                  | \___   ___   /|      | (ISUP)  |  |
  /     |                  |     \ /   \ / |      |         |  |  X      |
|      | SEP |  |       \_______/   |__ SPMC3
  \     |                  |  ___/ \___/ \ |       /       \   |
   \  __|__        A-link _|_/            \| RC6  |         |  |
    \|     |_____________/ |      40-12-0  \______|   AS6   |  |  ----| STP
|               |      (alias)  |      |         |  |
     |_____|               |               |      | (SCCP)  |  |
                           |               |      |         |  |
   International            \_____________/        \_______/ __|
   Network                                                      
                                                                
   NID2                                                         

The Signalling Gateway is connected with 2 F-link linksets and 2 A-link
conbined linksets to two networks: for example, the national network and the
international network.  (For those who would say: "Hey, this is 3 different
SGs!"--remember that an SG is permitted to support multiple SPMCs.)

The folowing is clear:

    o   There are two different SS7 network ids: NID1 and NID2, as
	labelled.  In the example,

	    -	NID1 corrresponds to the National Network.

	    -	NID2 Corresponds to the Internation Network.

    o	There are 3 different Signalling Point Management Clusters
	(SPMCs): SPMC1, SPMC2 and SPMC3, as labelled.  In the example,

	    -	SPMC1 corresponds to point code 5.255.3 in the National
		Network (NID1).

	    -	SPMC2 corresponds to point codes 5.255.4 and 5.255.5 in
		the National Network (NID1).

	    -	SPMC3 corresponds to point codes 40-12-3 and 40-12-0 in
		the International Network (NID2).

    o	There are 6 different Application Servers in the example:

	    -	AS1 and AS2 are the ISUP and SCCP users of SPMC1 and
		have Routing Contexts RC1 and RC2, respectively.

	    -	AS3 and AS4 are the ISUP and SCCP users of SPMC2 and
		have Routing Contexts RC3 and RC4, respectively.

	    -	AS5 and AS6 are the ISUP and SCCP users of SPMC3 and
		have Routing Contexts RC5 and RC6, respectively.

Now, when the SGP sends SNMM messages to the ASP, it must distinguish the
SPMC to which it applies.  If the SG assigns, as John would have it, Network
Appearance by Network Id (i.e. NA1 == NID1, NA2 == NID2) then the SGP would
not be able to distinguish for the ASP SNMM messages for SPMC1 from DUNAs
for SPMC2.

Therefore, either we can do one of two things:

    1.	We can assign Network Appearance by SPMC (i.e. NA1 == SPMC1, NA2
	== SPMC2, NA3 == SPMC3).  This means that Network Appearance
	takes on a new meaning and represents a combination of the
	Network Id and the point codes in the SPMC.  The NA then becomes
	an SPMC Identifier.

    2.	We use a list of Routing Contexts (in the SUAv7 fashion) to
	indicate SPMC (i.e. RC1,RC2-->SPMC1, RC3,RC4-->SPMC2,
	RC5,RC6-->SPMC3).  This would mean that Network Appearance is no
	longer required in an SNMM message and would be resplaced by a
	list of Routing Contexts.

When discriminating DATA messages, the ASP must determine the Application
Server to which the message corresponds.  To do this it needs the Routing
Context.  This can be done one of two ways:

    1.	We can assign Network Appearance by Network (i.e. NA1 == NID1,
	NA2 == NID2) to distinguish the form of the DPC in the routing
	lable in the data message and include it with the DATA message.
	This means that the APS must parse the RL in the message,
	interpret the DPC using the Network Id given by the Network
	Appearance, reapply the Routing Key to determine the Application
	Servers identity (that is, the Routing Context).

    2.	We can place the Routing Context in the DATA message and the
	ASP can index the Application Server by Routing Context.

The best way to accomodate both issues above is to simply remove the Network
Appearance parameter from DATA and SNMM messges and include Routing Context
instead.  The SNMM messages would require multiple Routing Contexts per
message, the DATA message would only require one Routing Context in the
message.

--brian

-- 
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]
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 28 Jul 2001 11:45:27 -0500
To: "sigtran" <[email-masked]>
From: Al Varney <[email-masked]>
Subject: Re: M3UA (V7) DRST question
X-SMTP-HELO: mtiwmhc25.worldnet.att.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mtiwmhc25.worldnet.att.net [204.127.131.50]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>At 04:32 PM 7/23/01 -0500, Jeff Copley wrote:
>John,
>
>Phew!  It took a bit to get through this thread....but I agree with your
>concept that the "single management view" needs to be expressed.  That
>is, if the SG receives a status change from the SS7 side of the network
>that we need to follow the same general philosophy on the IP side of the
>network. I think all SGPs on a SG should maintain the same received
>status and that the status needs to be sent once per SG to all
>interconnected ASPs.  Or here we go...How about just running an SG to
>the ASP in response mode?

Hi Jeff --  just throwing in some personal opinion:

    I don't think you really want this as the ONLY means of SG-to-ASP
notification, even without Brian's per-SGP status model.  Response-only mode
(with DUNA) usually implies loosing a message unnecessarily, if there are
other valid routes available (via another SG) for the messages eliciting the
response.  Unless there was an indication in DUNA of WHICH message was
dropped, the ASP can't really decide which messages to re-send via another
route.  This is a side-effect of the "MPT primitive" model that assumes MTP
is responsible for any message delivered to it -- it's either sent or
dropped, but the application is never informed about the dropping of
specific messages.

    Response mode for Restricted status implies repeating the notification
often (perhaps on every message), even if that's the only route -- and
notifying the ASP about Restricted isn't useful unless there's another SG
(not just SGP).  Managing MTP routing changeover/changeback between SGPs of
an SG and simultaneously informing ASPs to move traffic between SGPs would
be difficult without handshake messaging to avoid message loss/sequencing
problems.  How would you ever know an ASP really got the Restricted
notification?  How would the SGP taking over the new traffic know it was OK
to start transmitting this new ASP traffic, vs. waiting for the old SGP to
finish transmitting its messages?

    [The above is an issue regardless of response mode -- it's just that
response mode makes race conditions more likely by deferring action until
there's a message being handled by the old SGP.]

    Response mode for SS7 network Congestion derived from received TFCs is
reasonable -- it saves broadcasts for congestion levels that do not affect
current ASP traffic.  In the USA, many networks run ISUP IAMs and TCAP
queries at Priority 1 and thus generate only occasional Priority 0 messages.
Receipt of TFC with Cong.Level=1 occur much more frequently than any other
TFCs -- but there's often no messages affected during the interval before
the congestion event disappears.

    Unfortunately, the design of the TFC mechanism doesn't inform the sender
of WHERE the congestion occurred, nor is it necessarily routed back to the
sender over the route used by the message triggering the TFC.  That implies
TFC really has to be recognised as a NETWORK STATUS, not related to the
route being used by a specific SGP (or SG for that matter).  So ALL messages
to the affected destination need to be considered affected by TFC -- even if
there are higher-cost alternative routes available to the destination.  The
Route-Set-Congestion-Test messages that probe for continuing congestion may
also travel over a route that differs from the congestion point, but SS7
protocol applies congestion controls to the destination, not a route or a
link-set.  (Since the MTP-STATUS notification to MTP Users doesn't
distinguish between TFC receipt and congestion on a local link-set, anyone
advocating a strict following of the MTP primitive in M3UA can't have the
ASP re-routing traffic based on local link-set congestion either.)

    I had a big write-up on Brian's per-SGP (rather than per-SG) DUNA, etc. 
proposal included in the first attempt to respond to this e-mail.  But
Mother (Nature), Mr. Gates software and a big lightning storm intervened,
and I lost the file.  Since then, Brian has explained things more
completely, so I'll respond to that proposal in another message.  (By the
way, I like Brian's idea of having SGPs that aren't treated as a pool with a
single view of the SS7 network, but not the specific mechanism he proposed
for handling the concept.)

Al Varney  --  [email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUAv7: ASP Capablities
Date: Sun, 29 Jul 2001 23:02:06 +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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi guys,

Agreed - however I'm still iffy on the dynamic reg.  I thought that this is
not a necessary feature & adds complexity to the protocol.

If someone send me a nice procedure, all wrapped-up, t's crossed, i's
dotted, I can consider it - but I have not seen a consensus on this feature.

John

> Just optionally in the REG REQ message.
> 
> Benjamin J. Wilson wrote:                                
> (Thu, 26 Jul 2001 15:57:04)
> > Brian / John,
> > 
> > Wouldn't we need to reintroduce Network Appearance to support 
> > dynamic registration in SUA?
> > 
> > Ben
> > 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 30 Jul 2001 01:51:04 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: SUAv7: ASP Capablities
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-212.dallas.net [209.44.42.212]
List-Unsubscribe: <mailto:[email-masked]>

John,

Attached are the additions necessary to add registration to SUAv7.  They are
all wrapped-up with a bow tied around them. ;)

--brian

John Loughney wrote:                                 (Sun, 29 Jul 2001
23:02:06)
> Hi guys,
> 
> Agreed - however I'm still iffy on the dynamic reg.  I thought that this
> is not a necessary feature & adds complexity to the protocol.
> 
> If someone send me a nice procedure, all wrapped-up, t's crossed,
> i's dotted, I can consider it - but I have not seen a consensus on 
> this feature.
> 
> John
> 
> > Just optionally in the REG REQ message.
> > 
> > Benjamin J. Wilson wrote:                                
> > (Thu, 26 Jul 2001 15:57:04)
> > > Brian / John,
> > > 
> > > Wouldn't we need to reintroduce Network Appearance to support 
> > > dynamic registration in SUA?
> > > 
> > > Ben
> > > 
> 
> 
> ---
> 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/

Attachment Converted: "c:\program files\qualcomm\eudora
pro\attach\sua-07.regdiff" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Subject: SUAv7: Dynamic Registration
Date: Mon, 30 Jul 2001 11:30:21 +0200
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SUAv7: ASP Capablities
Thread-Index: AcEYw/MPdfdqnlCETSq2OaM0VShhmQAFf/wA
From: Bernard Kuc <[email-masked]>
To: "sigtran" <[email-masked]>
X-SMTP-HELO: mail3.azisa.co.za
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [196.14.124.214]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi John,

Just adding my vote to add dynamic registration. It may make things more
complicated, however (I believe) the benefits will out-weigh the effort.

Bernard

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: 30 July 2001
08:51
To: sigtran
Cc: [email-masked]
Subject: Re: SUAv7: ASP Capablities

John,

Attached are the additions necessary to add registration to SUAv7.  They are
all wrapped-up with a bow tied around them. ;)

--brian

John Loughney wrote:                                 (Sun, 29 Jul 2001
23:02:06)
> Hi guys,
> 
> Agreed - however I'm still iffy on the dynamic reg.  I thought that this
> is not a necessary feature & adds complexity to the protocol.
> 
> If someone send me a nice procedure, all wrapped-up, t's crossed,
> i's dotted, I can consider it - but I have not seen a consensus on 
> this feature.
> 
> 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: SUA-06: Signalling Link Selection Problems
Date: Mon, 30 Jul 2001 12:26:15 +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: viap090.atea.be [194.78.143.90]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian, John,

I have no problem with the addition of a sequence control parameter, but I
thought it was no issue : the SG could use the stream ID (and other
parameters) to determine a valid SLS, since the ASP is obliged to send class
1 messages over the same stream ID anyway (in-sequence-delivery guarantee at
ASP). The same is true in an all-IP case.

Will respond to other items later; just catching up with my mail-box ...

Regards,

____________________________

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent: vrijdag
20 juli 2001 11:31
To: sigtran
Subject: RE: SUA-06: Signalling Link Selection Problems

Hi Brian,

> In SUA O6 the CLDT message under Class 1 operation has no way
> for the AS to specify the SLS value associated with the message.
> This makes it impossible for SCCP at the SG to determine the
> proper SLS value to use in the MTP-TRANSFER primitive with which
> the N-UNITDATA is transfered.
> 
> Also, under Class 0 operation, the SCCP is still responsible for
> ensuring that SLS selection is properly performed.

Good catch.

> Therefore the CLDT message will require a "sequence control"
> parameter which is large enough to contain an SLS value.
> 
> Because this sequence control parameter is closely associated
> with the protocol class, I propose that the following changes be
> made to the "Flags" parameter in section 3.9.1:

Sounds very reasonable.  Thanks for the text.

John

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 30 Jul 2001 05:57:34 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA-06: Signalling Link Selection Problems
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.212]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gery,

What about other transports?

Also, what about when the SG is loadsharing and it loadshares by SLS, on
different SGP?

--Brian

Verwimp Gery wrote:                                       (Mon, 30 Jul 2001
12:26:15)
> Hi Brian, John,
> 
> I have no problem with the addition of a sequence control parameter, but I
> thought it was no issue : the SG could use the stream ID (and other
> parameters) to determine a valid SLS, since the ASP is obliged to send
class
> 1 messages over the same stream ID anyway (in-sequence-delivery guarantee
at
> ASP). The same is true in an all-IP case.
> 
> Will respond to other items later; just catching up with my mail-box ...
> 
> Regards,
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax: +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: vrijdag 20 juli 2001 11:31
> To: sigtran
> Subject: RE: SUA-06: Signalling Link Selection Problems
> 
> 
> Hi Brian,
> 
> > In SUA O6 the CLDT message under Class 1 operation has no way
> > for the AS to specify the SLS value associated with the message.
> > This makes it impossible for SCCP at the SG to determine the
> > proper SLS value to use in the MTP-TRANSFER primitive with which
> > the N-UNITDATA is transfered.
> > 
> > Also, under Class 0 operation, the SCCP is still responsible for
> > ensuring that SLS selection is properly performed.
> 
> Good catch.
> 
> > Therefore the CLDT message will require a "sequence control"
> > parameter which is large enough to contain an SLS value.
> > 
> > Because this sequence control parameter is closely associated
> > with the protocol class, I propose that the following changes be
> > made to the "Flags" parameter in section 3.9.1:
> 
> Sounds very reasonable.  Thanks for the text.
> 
> John
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

-- 
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: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SCCP Message Priority
Date: Mon, 30 Jul 2001 14:53:40 +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.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello Brian, all,

The SUA importance field in the Flags parameter is used to give an
indication of the priority of the message. This field should be enough to
derive :

- importance value in a.o. XUDT messages (the only indication of
priority/importance in ITU)
- message priority field in SIO in case of ANSI network - whatever else is
needed in another flavour of SS7 regarding priority/importance

and to allow SCCP on the SG to perform appropriate action in case of
congestion in the SS7 network.

Let the SG take care of as much of the SS7 flavours/specifics as possible !

____________________________

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: maandag 23
juli 2001 21:25
To: sigtran
Subject: Re: SCCP Message Priority

John,

The message priorities (that go in the MTP RL for congestion control)
associated with ANSI SCCP are set by the SCCP-User.
TCAP, for example, will up the MP on Conversation packages from 0 to 1.
Some critical connection sections in the connection-oriented procedures will
have some of the CO messages upped from 0 to 1.  OMAP uses 2.  Because these
values come from the SCCP-User and are communicated down to MTP through the
MTP-TRANSFER primitive, all messages which carry the Flags parameter may
need to have message priorities assigned (some CO messages do not).  The SUA
SHOULD police the setting of MP bits on messages which have a fixed priority
(to save an application from setting them by mistake).  Other messages will
use the value provided by the SCTP-User when formulating the MTP-TRANSFER
primitive at the SG.  The MP value needs to be communicated from ASP to SG
and visa versa.  Some times the SCCP needs to know the setting of MP for an
incoming message to know the setting what setting to use for an outgoing
message.

The message that is is definitely needed on is the CLDT.

John Loughney wrote:                (Mon, 23 Jul 2001 21:55:26)
> Hi Ray,
> 
> > Could someone please clarify whether SUA would allow ANSI 
> > message priority values to be conveyed between peer SUA/SUA 
> > Users.
> 
> I'm not so familiar with ANSI SCCP (though I bet a few folks on
> this list are).  Could you fill me in a little bit on what 
> you need?
> 
> John
> 

-- 
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: RE: SUA: SCCP Message Priority
Date: Mon, 30 Jul 2001 15:26:42 +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.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Al, Brian,

Good proposal. We should split the non-descriptive "Flags" parameter in it's
components. This would make it more clear why the Flags parameter is
mandatory in some messages now too.

Let's say :

1. Hop counter : mandatory in CLDT, CLDR, CORE.

2. Importance (or Priority) : mandatory in CLDT, CLDR, CORE, COAK, COREF,
RELRE.

3. Quality of Service, which contains Protocol Class and special options
depending on protocol class (i.e. for the moment, only a return-on-error
option bit is defined for connectionless protocol classes). Mandatory in
CLDT, CORE, COAK, COIT.

If need be, this QoS may contain a field for the sequence control parameter
in case of CLDT. You never know which transport protocols we're going to use
...

John, any tag values left ? ;)))

____________________________

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

-----Original Message-----
From: Al Varney [mailto:[email-masked]] Sent: maandag 23 juli 2001 22:49
To: sigtran
Cc: [email-masked]; John Loughney Subject: Re: SUA: SCCP Message
Priority

At 02:10 PM 7/23/01 -0500, Brian F. G. Bidulock wrote:
>Ray,
>
>Doesn't look like it.  It seems that we need to add a priority bit
>somewhere.  If for no other reason than to support ANSI (and other)
>TCAP Conversation.  Maybe in the Flags parameter.  SLS takes up 5
>bits of 8.

    Of course, if you REALLY want to support ANSI SS7 primitives, the Seq. 
control (Brian's SLS) has to be described as 8 bits, not 5, if T1.111-2000
(MTP) change to 8-bit SLS is to be totally supported.

    One could argue that Seq. Control is an SCCP primitive of undefined
number of bits -- and may not be directly mapped to MTP's 8-bit SLS field.
On the other hand, if SCCP/SUA is to support MTP's input requirements for
even SLS distribution, Seq. Control needs to have at least as many bits as
MTP's SLS.

    Note:  An SCCP Relay node is required to have a fixed mapping from
incoming SLS to Seq. Control of outgoing SCCP messages passed to MTP for
routing.  That mapping is not required to copy the SLS value literally.  A
Relay node is also presumed to map the other parts of the Quality of Service
Set (message priority and return option) from incoming message to outgoing.

---
   Other than the above comment, I agree with Brian.  It makes sense (sort
of) for SUA to put all of these "QoS" primitive items in the same FLAG
parameter.

    I'm not as happy about moving all the other SCCP optional parameters
into FLAG (Hop counter, Importance).  It makes SUA less transparent to new
optional parameters.  It seems the holy grail of "1 SUA" (mixing ANSI
message priorities and ITU-T importance) and the literal use of "primitives"
is more important than the simplicity of transparently carrying the messages
as seen by MTP Layer 3.  But hey -- I'm no protocol purist.

Al Varney  --  [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: "Hamel, Stephen [BCNR:7M40:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SCTP T Bit in Abort Message
Date: Mon, 30 Jul 2001 10:47:01 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>SCTP T Bit in Abort Message</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">Hello,</FONT> </P>

<P><FONT SIZE=2 FACE="Arial">in the SCTP spec, it mentions that a T bit must
be set regarding the TCB. (3.3.7)</FONT> <BR><FONT SIZE=2 FACE="Arial">But,
regarding the rules of an abort packet, there is no mention about what to do
with the T bit when receiving</FONT> <BR><FONT SIZE=2 FACE="Arial">the abort
packet (8.5.1 Section B).&nbsp; It is only mentioned in Section C when
handling a shutdown complete.</FONT> </P>

<P><FONT SIZE=2 FACE="Arial">Any ideas ? Thanks</FONT> </P>
<BR>

<P><FONT SIZE=2 FACE="Arial">Stephen Hamel</FONT> </P>
<BR>

---<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: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUAv7: ASP Capablities
Date: Mon, 30 Jul 2001 16:49:07 +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: viap090.atea.be [194.78.143.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi John, Brian,

Proposal to strike the ASP capabilities in the SUA draft, and fish it up
later in an SUA extension document when we want to tackle dynamic
registration in SUA (maybe in a common ASP management document) ?

Bye,

____________________________

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: woensdag 25
juli 2001 21:12
To: sigtran
Cc: John Loughney
Subject: SUAv7: ASP Capablities

John,

What is the point of the ASP Capabilities parameter?  Certainly all of the
Routing Context information must be provisioned in the SGP and the ASPs
capabilities can be known to the SGP in the same fashion.  Is not the SS7
interworking situation and protocol class implicit in the Routing Context?
Is there some use for it?

ASP Capablities sounds like more of a registration item.  Which leads me to
my next question: Why doesn't SUA support a registration/ deregistration
procedure?  Certainly Subsystem Number and ASP Capabilities sound like
reasonable Routing Keys.  Even SRN ranges or TIDs make sense as well.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 30 Jul 2001 09:54:36 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA: SCCP Message Priority
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.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gery,

Breaking them out might make some sense.  They don't all have to be included
all of the time.  But:

  Message priority should be at least optional in all messages.
  Not all variants using Message Priority choose the same
  priority scheme and may permit variations in different
  messages.

  Sequence control should be at least optional in all messages
  (decoupled and connectionless operation).  (Make it at least
  8-bits for ANSI, why not use all 32?)

  Hop counter should be optional in all messages in which it can
  be included, not mandatory.  Hop counting is optional.

  Protocol Class should be optional in all messages where it is
  required.  Protocol Class may be implied by Routing Context
  (decoupled or connectionless operation) or Source Reference
  Number (coupled operation).

--Brian

Verwimp Gery wrote:                                       (Mon, 30 Jul 2001
15:26:42)
> Hi Al, Brian,
> 
> Good proposal. We should split the non-descriptive "Flags" parameter in
it's
> components. This would make it more clear why the Flags parameter is
> mandatory in some messages now too.
> 
> Let's say :
> 
> 1. Hop counter : mandatory in CLDT, CLDR, CORE.
> 
> 2. Importance (or Priority) : mandatory in CLDT, CLDR, CORE, COAK, COREF,
> RELRE.
> 
> 3. Quality of Service, which contains Protocol Class and special options
> depending on protocol class (i.e. for the moment, only a return-on-error
> option bit is defined for connectionless protocol classes). Mandatory in
> CLDT, CORE, COAK, COIT.
> 
> If need be, this QoS may contain a field for the sequence control
parameter
> in case of CLDT. You never know which transport protocols we're going to
use
> ...
> 
> John, any tag values left ? ;)))
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax: +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> -----Original Message-----
> From: Al Varney [mailto:[email-masked]]
> Sent: maandag 23 juli 2001 22:49
> To: sigtran
> Cc: [email-masked]; John Loughney
> Subject: Re: SUA: SCCP Message Priority
> 
> 
> At 02:10 PM 7/23/01 -0500, Brian F. G. Bidulock wrote:
> >Ray,
> >
> >Doesn't look like it.  It seems that we need to add a priority bit
> >somewhere.  If for no other reason than to support ANSI (and other)
> >TCAP Conversation.  Maybe in the Flags parameter.  SLS takes up 5
> >bits of 8.
> 
>     Of course, if you REALLY want to support ANSI SS7 primitives, the Seq.

> control (Brian's SLS) has to be described as 8 bits, not 5, if T1.111-2000

> (MTP) change to 8-bit SLS is to be totally supported.
> 
>     One could argue that Seq. Control is an SCCP primitive of undefined 
> number of bits -- and may not be directly mapped to MTP's 8-bit SLS 
> field.  On the other hand, if SCCP/SUA is to support MTP's input 
> requirements for even SLS distribution, Seq. Control needs to have at
least 
> as many bits as MTP's SLS.
> 
>     Note:  An SCCP Relay node is required to have a fixed mapping from 
> incoming SLS to Seq. Control of outgoing SCCP messages passed to MTP for 
> routing.  That mapping is not required to copy the SLS value literally.  A

> Relay node is also presumed to map the other parts of the Quality of 
> Service Set (message priority and return option) from incoming message to 
> outgoing.
> 
> ---
>    Other than the above comment, I agree with Brian.  It makes sense (sort

> of) for SUA to put all of these "QoS" primitive items in the same FLAG 
> parameter.
> 
>     I'm not as happy about moving all the other SCCP optional parameters 
> into FLAG (Hop counter, Importance).  It makes SUA less transparent to new

> optional parameters.  It seems the holy grail of "1 SUA" (mixing ANSI 
> message priorities and ITU-T importance) and the literal use of 
> "primitives" is more important than the simplicity of transparently 
> carrying the messages as seen by MTP Layer 3.  But hey -- I'm no protocol 
> purist.
> 
> Al Varney  --  [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: Mon, 30 Jul 2001 10:08:27 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUAv7: ASP Capablities
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-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gery, John,

I second.  Strike ASP CAP.

Verwimp Gery wrote:                                       (Mon, 30 Jul 2001
16:49:07)
>
> Hi John, Brian,
> 
> Proposal to strike the ASP capabilities in the SUA draft, and fish it up
> later in an SUA extension document when we want to tackle dynamic
> registration in SUA (maybe in a common ASP management document) ?
> 
> Bye,
> 
> ____________________________
> 
> 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: woensdag 25 juli 2001 21:12
> To: sigtran
> Cc: John Loughney
> Subject: SUAv7: ASP Capablities
> 
> 
> John,
> 
> What is the point of the ASP Capabilities parameter?  Certainly
> all of the Routing Context information must be provisioned in
> the SGP and the ASPs capabilities can be known to the SGP in
> the same fashion.  Is not the SS7 interworking situation and
> protocol class implicit in the Routing Context?  Is there some
> use for it?
> 
> ASP Capablities sounds like more of a registration item.  Which
> leads me to my next question: Why doesn't SUA support a registration/
> deregistration procedure?  Certainly Subsystem Number and ASP
> Capabilities sound like reasonable Routing Keys.  Even SRN ranges
> or TIDs make sense as well.
> 
> --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]
> 
> 
> ---
> 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: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUAv7: CODT Message
Date: Mon, 30 Jul 2001 17:09: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: viap090.atea.be [194.78.143.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello Brian,

That's why we have coupling of connection sections in the SG. For one thing,
the DT1 received from the SS7 network also doesn't have enough information
(DPC yes, but no SSN which is needed for delivery/selection of correct AS).

Regards,

____________________________

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: donderdag 26
juli 2001 17:02
To: sigtran
Cc: John Loughney
Subject: SUAv7: CODT Message

John,

The CODT message does not have enough information in it for the SG to
determine where it has to go.  It needs at least a Destination Address.  DRN
is not sufficient.

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 30 Jul 2001 10:17:10 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
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 
                      KAA28554
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.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

I don't see that rational basis on which M3UA can apply routing keys based
on SCCP Subsystem number.  Can someone provide an example on just how this
was expected to work?  (Particularly how SCCP Management is handled and OMAP
SCCP Route Verification Tests.)  I think you need SUA here.

I propose that we strike SSN from the Routing Key in the REG REQ message.

Also, TCAP Transaction Id is used as an example of a Routing Key, although
there is no field for it in a REG REQ.  Distributing messages based on TCAP
Transaction Ids doesn't strike me as rational either.
I think you need TUA here.

I propose that we strike TCAP Transaction Id from the examples of Routing
Keys.

--Brian

-- 
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]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Routing Context
Date: Mon, 30 Jul 2001 08:19:39 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ztxmail04.ztx.compaq.com [161.114.1.208]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

	Comments below.

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Friday, July
27, 2001 6:55 PM
To: sigtran
Subject: Re: M3UA: Routing Context

John,

I'm glad you broght this up.  Let me just modify your diagram slightly and
we can move to the next level:

                            _________  
                           (   Sub   ) 
                     _____(  Network  )_____
     5.255.3        /     (     A     )     \       _________
   +----------+    /       (_________)       \     (         )
   |          |___/                           \___(  Network  )
   | SS7 node |___                             ___(     Y     )
   |    S     |   \         _________         /    (_________)
   +----------+    \       (   Sub   )       /
     5.255.4        \_____(  Network  )_____/
                          (     B     )
                           (_________) 

The SS7 node S has two point codes (5.255.3 and 5.255.4) in Network Y which
are attached by subnetworks A and B which are disjoint at S.  One is, say, a
point code S uses to connect to SNET, the other is used to connect to AT&T.
They both belong to the same SS7 point code administrative domain.  (That
is, they both have the same Network Id.)

[John]  SNET and AT&T is a bad example.  BUT this might occur if node S has
reached the 16 link per linkset limit in SS7.  Point codes 5.255.3 and
5.255.4 are physical point codes (Note, very few nodes, if any, can do this
at the moment).  In this situation, node S maintains an internal network ID
(network appearance?) for its multiple connections to network Y.  This all
that it needs.

Following your diagrams through...
                                                              5.255.5
                                                              ________ 
                                                             |        |
                    +--------+        _________              |  Node  |
                    |        |       (         )             |    X   |
                    |        |______(  Network  )_____       |________|
     5.255.3        |        |      (     A     )     X       ____|____
   +----------+     |        |       (_________)       X     (         )
   |          |     |        |                          X___(  Network  )
   | SS7 node |-----|   SG   |                           ___(     Y     )
   |    S     |     |        |        _________         /    (_________)
   +----------+     |        |       (         )       /
     5.255.4        |        |______(  Network  )_____/
                    |        |      (     B     )
                    |        |       (_________)
                    +--------+

Because, as shown, point code X can be inaccessible from 5.255.3, but can
still be accessible from 5.255.4, these two point codes within the same
network need different Network Appearances to distinguish for which point
code the DUNA(X) applies.  If each SPMC behind the SG has its own physical
routes (links) to the SS7 network on the SS7 side of the SG, each will need
its own Network Appearance to distinguish signalling network management
menssages which are destined to it alone.

[John]  You skipped a figure but lets fill in come of the gaps.  There are
network appearances (network IDs) assigned for network A connection and
network B connection.  Since node X is unavailable on the network A, a TFP
from the network A is sent to the SG.  Also note that node S and the SG are
handling networks A & B as INDEPENDENT networks and separate networks.
Since the SG can not reach node X from network A, it passes on a DUNA that
must contain the network appearance (network ID) for network A.  This is all
that node S needs to mark node X from network A prohibited.

If the Routing Context for these point codes is the "whole" point code, then
each point codes requires both a Unique Routing Context and a Unique Network
Appearace.  Thus, Routing Context == Network Appearance.

[John]  No, the routing context == network appearance + point code, but
these are derived from the network appearance parameter and the affect point
code parameter in the DUNA message.  A separate routing context parameter is
NOT needed, it is excess baggage especially if there are multiple nodes
contained in the DUNA.  Note, we need to clearly identify the affected point
codes.  I view routing context as a forward routing concept, not an
originating or affected point code.  By the way, DUNAs should be "clean",
i.e., should only contain affected point codes from one network (connection
in this case, network A).  

Plus, as above, one Network Appearance can be required for each point code,
not each Network Id, as it might appear.  (Even if, as shown, the point
codes are even in the same block!) Because Routing Context is already
assigned on an MTP-User basis at the ASP, it uniquely determines which
MTP-User at the ASP to which the DUNA message applies.  There is no need for
messing around with Network Appearances.  Just use the Routing Context.  The
Routing Context is required for other purposes anyway (it uniquely
identifies an Application Server and a Routing Key).

[John]  NO, I do not agree.  Only a single network appearance per network
connection is needed.  The single network appearance is all that is needed
to clearly identify the point codes and to what network they belong.

--brian

> In this case Node S and the SG must share an agreed to "network
appearance"
> for each network that is involved (Network A & B).  I assume that this
will
> be network operator assigned (network operator that owns Node S and SG).
> This will take care of the messaging and the network management. But what
is
> the basis for creating the connection between Node S and the SG.  It was
the

Schantz, John wrote:                                     (Fri, 27 Jul 2001
12:44:42)
> Brian,
> 
> I think you need to step back for a moment and re-examine what you are
> trying to solve.  I think you are trying to solve the case where an SS7
node
> wants to have an appearance in more than one network, hence, the concept
of
> MTP-SAP.  But in your case you want all traffic to flow through the same
> signalling path to the node.
> 
> Below is the SS7 scenario:
>                               _________
>                              (         )
>                        _____(  Network  )
>                       /     (     A     )
>      +----------+    /       (_________)
>      |          |___/
>      | SS7 node |___
>      |    S     |   \         _________
>      +----------+    \       (         )
>                       \_____(  Network  )
>                             (     B     )
>                              (_________)
> 
> Node S has separate links to Networks A & B.  Node S is identified by a
> point code from each network, for now lets call them, x (from Network A)
and
> y (from Network B).  The MTP-SAP concept was added (a local concept) where
> node S had to associate a network ID to Networks A & B, lets use A & B as
> the Network IDs.  Hence, node S has to mark each message received with a
> Network ID of A or B, based on the network it was received from.  Outbound
> messages from the MTP-users also had to be marked with a network ID.
> Logically, Node S could be viewed as have 2 SCCP/MTP protocol stacks.  The
> network ID is used to discriminate which protocol stack handles which
> message.  
> 
> For an applications point-of-view (SSN), the easy case is when the message
> being sent is a reply, i.e., given the same network ID as the received
> message.  If the message is being generated from the application, the
> application would need to know which network it was destined for and mark
> it.
> 
> Hence, Network ID + point code uniquely identified the destination.  The
> network ID is used to select the protocol stack/links belonging a specific
> network, and the PC to select the correct route to that network.
> 
> This same picture can be moved over to the SS7 over IP case.  If Node S
has
> separate connections to the different networks, it must locally keep track
> of the networks.  The SGs that it connects to do not have to be involved.
> 
> Now what about the picture where you have the SGs connecting to the
> different networks.  There are 2 cases in this situation: 1) traffic is
> separated and 2) traffic is merged.  
> 
> Traffic is Separated:  The traffic could be kept separate by having Node S
> establish connections to the different "sides" of the SG.  This would be
in
> line with the SS7 rules that the SG would have present a different
> "appearance", actually a physical point code, for each network
represented.
> Look at the figure below:
> 
>                           +--------+        _________
>                           |+------+|       (         )
>                        ___||  SG  ||______(  Network  )
>                       /   ||   A  ||      (     A     )
>      +----------+    /    |+------+|       (_________)
>      |          |___/     |        |
>      | SS7 node |___      |   SG   |
>      |    S     |   \     |        |        _________
>      +----------+    \    |+------+|       (         )
>                       \___||  SG  ||______(  Network  )
>                           ||   B  ||      (     B     )
>                           |+------+|       (_________)
>                           +--------+
> 
> The A-side of the SG and of Node S requires a point code from network A.
> The B-side of the SG and of Node S requires a  point code from network B.
> Each node, S and SG, could internal keep track of the messages/networks by
> using their own network ID.  They could also agree (network operator
option)
> to use the "network appearance" parameter so that node S and SG (and other
> nodes) use a common ID for the networks.
> 
> Traffic is Merged:  IMHO, this is a more difficult case to visualize.
Below
> is a figure.
> 
>                           +--------+        _________
>                           |        |       (         )
>                           |        |______(  Network  )
>                           |        |      (     A     )
>      +----------+         |        |       (_________)
>      |          |         |        |
>      | SS7 node |---------|   SG   |
>      |    S     |         |        |        _________
>      +----------+         |        |       (         )
>                           |        |______(  Network  )
>                           |        |      (     B     )
>                           |        |       (_________)
>                           +--------+
> 
> In this case Node S and the SG must share an agreed to "network
appearance"
> for each network that is involved (Network A & B).  I assume that this
will
> be network operator assigned (network operator that owns Node S and SG).
> This will take care of the messaging and the network management. But what
is
> the basis for creating the connection between Node S and the SG.  It was
the
> adjacent physical point codes that both Node S and SG had (and must still
> have), but what is it now?  I will have to think on how to eliminate the
> adjacent PC in this.
> 
> But I still conclude that all that is required is the "network appearance"
> defined as a network ID.
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 4:24 AM
> To: sigtran
> Cc: Greg Sidebottom
> Subject: Re: M3UA: Routing Context
> 
> 
> John, Greg,
> 
> Some of these things aren't apparent until one tries to go
> and build the thing.
> 
> Here is the problem:  architecturally, M3UA exports the MTP-Provider/User
> interface, like so:
> 
>                                                                 
>                                                                 
>                                    Application      Application 
>                                     Server #2        Server #1  
>                                    ___________      ___________ 
>                                   |           |    |           |
>                                   |   MTP     |    |   MTP     |
>                                   |   User    |    |   User    |
>                                   |           |    |           |
>                                   |___________|    |___________|
>                                      |     ^          |     ^   
>                           __         |     |          |     |   
>               ___________/__\_______/     /           |     |   
>              /   _______|____|___________/            |     |   
>             /   /       |    |                       /     /    
>            /   /        |    |           __         /     /     
>           /   / ________|____|______<___/__\_______/     /      
>           |   |/   _____|____|______>__|____|___________/       
>           |   /   /      \__/           \__/                    
>           |  /|  /         \              \                     
>           | / | /           \              \                    
>           ||  ||             \              \                   
>         __vv__||__         One SCTP       Routing               
>        |          |       Association     Context               
>        |          |                                             
>        |   MTP    |                                             
>        | Provider |                                             
>        |          |                                             
>        |          |                                             
>        |__________|                                             
>                                                                 
>         Signalling                                              
>          Gateway                                                
>         (Process)                                               
>                                                                 
>                                                                 
> Where, the MTP-SAP can be identified by the Routing Context.  The SG may
> apply a "Routing Key" to find the MTP-SAP, but this is a function which
> is performed *below* the MTP-User interface.  If M3UA would label all
> messages with the Routing Context (where ambiguous, as shown), then
> there would be no confusion as to which MTP-SAP is being used either for
> outgoing or incoming messages.
> 
> For example, when the SG performs transfer-prohibited procedures and
> discovers that an SPMC signalling point is prohibited off a routeset, it
> informs the MTP-Users.  So, the MTP has a list of "Users" to which it
> sends MTP-PAUSE primitives.  We have the same thing in the SG, a list
> of routing contexts, each which represents an MTP-User bound to an
> MTP-SAP.  So instead, of attaching a list of Routing Contexts to the
> DUNA (or sending multiple DUNAs, each with its own routing context), we
> are throwing up a DUNA with a "Network Appearance".  There are a number
> of cases where the Network Appearance becomes ambiguous at the ASP
> unless Network Appearance == Routing Context. (And then what is the
> point of two names for the same thing?)
> 
> For the ASP -> SGP direction, consider that the MTP at the SG cannot
> determine the origin of the message (i.e, which MTP-SAP the message came
> from.)  There is nothing stopping AS#2 from placing an OPC/SI in the
> message which doesn't belong to it.  In fact, the MTP-User should not
> even be putting the OPC/SI in the message: the SG should do this on the
> basis of the DPC key associated with the Routing Context.  I don't think
> that the SG should just blindly route messages based on DPC without any
> screening whatsoever.
> 
> Now, I am fully aware that you do not believe in MTP-SAPs which are not
> the "whole" point code.  But in the case where routing keys are "whole"
> point codes, Network Appearance == Routing Context.  For sub-point code
> MTP-SAPs (e.g., ISUP goes to AS#1, SCCP to AS#2), AS#1 needs to be
> screened off of placing a non-ISUP SI in the routing label, and not
> using its own point code.  AS#1 needs to have messages screend by
> DPC as well unless one wants to try to replicate gateway screening above
> the MTP-User interface.
> 
> So, John, you should not care if Network Appearance is replaced with
> Routing Context, because in your case Network Appearance == Routing
> Context, even though you don't see the need, because it is not
> applicable in your cases.
> 
> --brian
> 
> 
> 
> Schantz, John wrote:                        (Mon, 23 Jul 2001 13:04:29)
> > Brian,
> > 	This doesn't really make any sense and I don't see the need.
> > 
> > 	Why would you need a routing context in a DATA from SGP to ASP.  The
> > ASP should be determining where the message goes locally in the AS(s)
> based
> > on parameters from the SS7 message.
> > 
> > 	Requiring it in the DATA from the AS to SG doesn't make any sense.
> > The SG should be determining how to forward route the message based on
the
> > SS7 message parameters (Routing Label).  Why would the responding AS
even
> > know the RC of a remote node.  Or are you proposing that a backward RC
be
> > included.  Forward routing should not be based on backward information.
> > 
> > 	Hence, the answer to your question of whether there is an objection
> > to including the RC in the DATA message, YES I object.
> > 
> > John
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Monday, July 23, 2001 6:07 AM
> > To: sigtran
> > Cc: Greg Sidebottom
> > Subject: M3UA: Routing Context
> > 
> > 
> > Greg,
> > 
> > I would like to propose that the Routing Context be added as an
> > optional parameter to which SHOULD be included in the DATA
> > messages from the SGP and MUST be included in DATA messages from
> > the ASP when the ASP is active for more than one Application
> > Server.
> > 
> > This is *not* a replace-Network-Appearance-with-Routing-
> > Context-proposal.
> > 
> > The purpose of adding RC to DATA messages is to distinguish
> > multiple traffic flows which are multiplexed over the
> > association for use in:
> > 
> >     o   demultiplexing data traffic at the ASP without having to
> > 	reapply the Routing Key to each message to determine
> > 	routing context,
> > 
> >     o   distinguishing traffic flows for discarding data
> >         messages during ASPAC and ASPIA procedures, both at
> > 	the SG and the ASP (again without having to reapply
> > 	the Routing Key to each message at each end),
> > 
> >     o   demultiplexing buffered data messages at the ASP and the
> >         SG during failover or AS-PENDING, again, without having
> > 	to reapply a complex Routing Key.
> > 
> >     o   assists in diagnostics by permitting monitoring
> >         equipment to at least distinguish traffic flows without
> > 	having to provision monitoring equipment with routing
> > 	keys.
> > 
> > It sure simplifies a lot of places in the implementation where
> > one would have to otherwise reapply the routing key.
> > 
> > I should point out that, for some routing keys (e.g, SCCP SSN)
> > it is currently impossible for the SGP to distinguish between AS
> > for *incoming* traffic when there are multiple AS on an
> > association.  This is because the Routing Key-->Routing
> > Context-->AS mapping is only valid for traffic from the SGP
> > towards the ASP.
> > 
> > Any objections to including RC in DATA messages?
> > 
> > --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]
> > 
> > 
> > ---
> > 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]

-- 
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: RE: M3UAv8: SSN in Routing Key and TCAP TID in example.
Date: Mon, 30 Jul 2001 17:43:24 +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.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg,

I second that. Using TCAP transaction ID in SUA wouldn't be wise either.
With the exception of the CIC, RK parameters should in general not include
any of the upper layer's parameters (SSN, GT for M3UA; TID etc. for SUA).

Regards,

____________________________

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: maandag 30
juli 2001 17:17
To: sigtran
Cc: Greg Sidebottom
Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.

Greg,

I don't see that rational basis on which M3UA can apply routing keys based
on SCCP Subsystem number.  Can someone provide an example on just how this
was expected to work?  (Particularly how SCCP Management is handled and OMAP
SCCP Route Verification Tests.)  I think you need SUA here.

I propose that we strike SSN from the Routing Key in the REG REQ message.

Also, TCAP Transaction Id is used as an example of a Routing Key, although
there is no field for it in a REG REQ.  Distributing messages based on TCAP
Transaction Ids doesn't strike me as rational either.
I think you need TUA here.

I propose that we strike TCAP Transaction Id from the examples of Routing
Keys.

--Brian

-- 
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]
Date: Mon, 30 Jul 2001 11:14:20 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUAv7: CODT Message
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-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gery,

For decoupled operation, the CODT message only requires the information
necessary to complete the RL in the MTP message:  OPC can be derived from
Routing Context, SLS may be derivable from stream id if SCTP is used, but
DPC is necessary for decoupled operation.

Can we add a DPC as an optional parameter for decoupled operation?

As to the DT1's received from the SS7 network, the AS must not use the same
Source Local Reference Number, so the SLRN needs to be partitioned by AS.
This partitioning can be taken advantage of to identify the AS from the DLRN
in the received DT1's for decoupled operation.  The same approach cannot be
taken in the other direction: thus the need for a DPC parameter as an
optional parameter in all CO messages which do not contain a Destination
Address.

Coupling is not necessary; decoupled operation is more reliable and robust
to failures.

--Brian

Verwimp Gery wrote:                                       (Mon, 30 Jul 2001
17:09:52)

> Hello Brian,
> 
> That's why we have coupling of connection sections in the SG. For one
thing,
> the DT1 received from the SS7 network also doesn't have enough information
> (DPC yes, but no SSN which is needed for delivery/selection of correct
AS).
> 
> Regards,
> 
> ____________________________
> 
> 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: donderdag 26 juli 2001 17:02
> To: sigtran
> Cc: John Loughney
> Subject: SUAv7: CODT Message
> 
> 
> John,
> 
> The CODT message does not have enough information in it
> for the SG to determine where it has to go.  It needs
> at least a Destination Address.  DRN is not sufficient.
> 
> --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]
> 
> 
> ---
> 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]
To: "sigtran" <[email-masked]>
Date: Mon, 30 Jul 2001 09:21:13 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: M2UA Last Call Over
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: [209.185.123.82]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

Last Call on M2UA has now closed.  Thank you for your review and comments.
Ken will now be working on an updated version which hopefully will be in
condition to move forward to IESG review.

In the meantime, please hold any further comments until the next version.

Thanks,

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: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07: Network Appearance
Date: Mon, 30 Jul 2001 09:24:56 -0700
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ztxmail04.ztx.compaq.com [161.114.1.208]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

	NO, see response to "M3UA: Routing Context".  Only a single network
appearance is needed per network connection.

	More comments below.

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Saturday,
July 28, 2001 8:08 AM
To: sigtran
Subject: Re: M3UA07: Network Appearance

John,

Perhaps now you can see (from our discussion on the thread "M3UA: Routing
Context") that to cover all configurations, a Network Appearance valud is
required per primary point code and network id, and that this proposal was a
natural extension of that fact.  Consider the case below:

[John] NO.

                                     __________                  
                            ___     /          \     ___         
                           /   \   |            |   /   \        
                          | SEP |__|____________|__| SEP |       
                           \___/   |            |   \___/        
                          //       |            |                
                         / |       | Signalling |  5.255.3       
                        / /        |   Gateway  |                
                       /  |        |            |                
                      /  /         |            |                
              _____  /   |         |            |                
             |     |/   /          |            |                
        -----| STP |____|__________|______      |                
            /|_____|   /           |      \___  |  5.255.4       
           /    |      |           |          \_|_   ___         
        \ /     |     /            |            | \ /   \        
         X      |     |            |            |  | SEP |       
        / \     |    /             |           _|_/ \___/        
           \  __|__ /              |       ___/ |                
            \|     |_______________|______/     |       5.255.5  
        -----| STP |               |            |       (alias)  
             |_____|               |            |                
                                   |            |                
                                    \__________/                 

The signalling gateway needs two different Network Appearance parameters:
one per SPMC.  The bottom SPMC needs only one Network Appearance to cover
both the primary point code 5.255.4 and the alias point code 5.255.5 because
they are both treated as the same from an SS7 newtork management view.

[John]  NO.  Since a SINGLE network connection is in the figure above, NO
network appearance is needed at all.  What do you think the point code is
for??????  You seem to proposing that the network appearance replace the
point code for routing, NO.

Now, in general, a rational basis for assigning Network Apearance Id's is to
use the Network Id and Point Code of the node (the node *is* the network
appearance).  Therefore, the DUNA, DAVA, etc. that the SG sends concerning
the SPMC will be properly distinguish.

[John]  NO.  A single network appearance (== network ID) + affected point
code is all that is needed. 

Note that if the proposed assignment of Network Appearances is used, the
SCON message no longer requires a Concerned Point Code parameter when the
SPMC is signalling congestion to the SG.  It need only use the Network
Appearance.

[John] NO.

The definition of a Network Appearance becomes (effectively): "An unique
identifier indicating the Signalling Point Management Cluster (SPMC) to
which Signalling Network Management Messages apply."

[John]  NO.

--Brian

Schantz, John wrote:                         (Mon, 23 Jul 2001 13:37:00)
> Brian,
> 
> 	Why the need to include a concerned PC at all, the PC would be
> redundant to the one in the DPC.  Why not let the network appearance
> parameter be equal to the Network ID (all 32 bits).  Then Network
> Appearance(Network ID) + DPC will be unique and it will separate out the
> traffic into networks in both directions SG->AS and AS->SG(-> and beyond).
> 
> John 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, July 23, 2001 6:41 AM
> To: sigtran
> Cc: Greg Sidebottom
> Subject: M3UA07: Network Appearance
> 
> 
> Greg,
> 
> When an SG is has multiple point codes serving ASPs which are
> active in multiple SPMCs, it becomes necessary to label each
> SPMC with a unique Network Appearance parameter to demultiplex
> DUNA, DAVA, DRST and SCON.  Because a separate Network Appearance
> assignment is necessary for each SPMC and the adminstration of
> these assignments could get quite tedious for an SGP/ASP pool
> representing a large number of point codes, I would like to
> propose the following refinement to the Network Appearance
> Parameter:
> 
> (This is in fitting with the definition that a "Network Appearance
uniquely
> identifies an SS7 entity (Point Code) into an SS7 network.")
> 
> The format of the Network Appearance parameter 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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Network Id   |            Concerned Point Code               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Network Identifier: 8-bit (unsigned integer)
> 
>    The Network Identifier identifies the network in which the Concerned
>    Point Code can be considered unique, and distinguishes this Concerned
>    Point Code from an identical point code in any another network.
>    A Network Identifier identifying a specific adminsitrative domain for
>    the assignment of SS7 Signalling Point Codes MUST be global to all
>    SGPs in an SG.
> 
> Concerned Point Code:
> 
>    The Concerned Point Code identifies a point code within the
>    administrative domain as indicated by the Network Identifier.  The
>    Concerned Point Code is the one point code of a Signalling Point
>    Management Cluster (SPMC) which needs to receive updates concerning
>    the accessibility/restriction/congestion status of routesets from the
>    SPMC.
> 
> 
> 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]
> 
> 
> ---
> 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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 30 Jul 2001 11:26:05 -0500
To: "sigtran" <[email-masked]>
From: Al Varney <[email-masked]>
Subject: Re: M3UA: Route-set congestion
X-SMTP-HELO: mtiwmhc22.worldnet.att.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mtiwmhc22.worldnet.att.net [204.127.131.47]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>At 09:56 AM 7/27/01 -0500, Brian F. G. Bidulock wrote:
>Amish,
>
>Amish Chana wrote:                                          (Fri, 27 Jul 
>2001 12:38:40)
> > Brian,
> >
> > > >
> > > > What about the scenario where the A-links are congested, or in this 
> case
> > > > association-A? With traditional SS7 links the same number of links
are
> > > > present between each STP and the SP, hence you have a fixed
bandwidth
> > > > (assuming no failures)in each linkset. Congestion of the links may 
> very
> > >well
> > > > be attributed to a high traffic volume to a DPC.
    ....
> > With respect to the above paragraph, what I am getting at, is that I
don't
> > think it is appropriate to indicate congestion to the MTP3-users unless
IP
> > network congestion is detected on both associations. Congestion on one
> > association should allow for the traffic to be redirected to the 2nd
> > association. This could also result in the traffic swinging back and
forth
> > between the two associations. A mechanism is therefore necessary to
detect
> > how many associations reported congestion within someone time-period 
> before
> > reporting congestion to the local MTP3-users.

>Ah, that is different that SCON.  I suppose it is pretty much up to the
>implementation to decide what to do with regard to SCTP congestion.
>Some determination might be able to be made in specific IP network
>configurations to determine whether SCTP congestion was due to too high
>and offered load or whether a one or more associations is just "bad".
>I would think that switching associations would only make sense in the
>case that the SCTP association was "bad".

    I agree -- this would be a pretty implementation-specific decision
(waiting for multiple SCTP or IP associations to indicate congestion before
notifying MTP3-users).  In general, if SCTP is operating but congested, I
think most PSTN-signaling protocols (MTP, SCCP, Q.931) would be better off
either killing the congested association or continuing to use it (with
notification to the MTP3-user, etc.).  As Brian notes below, changing the
SCTP association (or stream) used for MTP/SCCP/ISDN presents the possibility
of mis-sequencing messages (or dropping all those still in the congested
queue).

    While I have no experience with SCTP in the field, much of SS7
congestion today is very short-lived and re-routing around such events could
often take longer than the events last.  Handshakes and message holding
while doing changeover/changeback or similar re-routing schemes also
increase the chance of congestion on other routes.  That's why SS7 operates
with the philosophy of just continuing as usual when congestion events occur
-- they're infrequent, short and assumed to apply to all traffic to a
TFC-producing destination.  In other words, the network overreacts to
congestion as a trade-off to avoiding large queues of messages internally.

    If SCTP carries MTP traffic over a transport sub-network with constant
congestion events, then it will provide its MTP-users with poor service.
But the messages that make it through should at least be timely ones, eh?

>Switching traffic between SCTP associations which arrive a different
>endpoints must be done quite carefully, because of the possibility of
>mis-sequencing: i.e. the head of the traffic on the new association
>overtaking the tail on the old past the SG/SGP.  Some sort of controlled
>rerouting, changeover or other procedure could be necessary.

    I'm waiting for completion of your meeting before commenting on Brian's
"per-SGP/per-ASP" proposal for dealing with DUNA, etc.  I like the idea, but
believe it suffers from exactly this same problem -- without an alternative
M3UA message mechanism (SGP management messages) mis-sequencing or unneeded
message loss will occur when an ASP re-directs traffic from one SGP to
another.  I don't believe you can have an ASP re-direct traffic away from or
back to an SGP without SGP/ASP management interaction.  DUNA, etc. 
are the wrong messages for that.

    I'm assuming the meeting will be more productive than some of the other
blather I've seen on the multi-SGP topic ("Mine is bigger than yours!!"
doesn't fit into this technical discussion).

Al Varney

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
Date: Mon, 30 Jul 2001 12:08:31 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Network Appearance
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-212.dallas.net [209.44.42.212]
List-Unsubscribe: <mailto:[email-masked]>

John,

Please see response inline...

John Schantz wrote:                               (Mon, 30 Jul 2001
09:24:56)
> Brian,
> 
> 	NO, see response to "M3UA: Routing Context".  Only a single network
> appearance is needed per network connection.
> 
> 	More comments below.
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Saturday, July 28, 2001 8:08 AM
> To: sigtran
> Subject: Re: M3UA07: Network Appearance
> 
> 
> John,
> 
> Perhaps now you can see (from our discussion on the thread "M3UA:
> Routing Context") that to cover all configurations, a Network Appearance
> valud is required per primary point code and network id, and that this
> proposal was a natural extension of that fact.  Consider the case below:
> 
> [John] NO.
> 

                           200.1.4    __________                  
                             ___     /          \     ___         
                            /   \   |            |   /   \        
                           | SEP |__|____________|__| SEP |  AS1  
                            \___/   |            |   \___/        
                           //       |            |                
                          / |       | Signalling |  5.255.3       
                         / /        |   Gateway  |                
                        /  |        |            |                
                       /  /         |            |                
               _____  /   |         |            |                
              |     |/   /          |            |                
         -----| STP |____|__________|______      |                
             /|_____|   /           |      \___  |  5.255.4       
            /    |      |           |          \_|_   ___         
         \ /     |     /            |            | \ /   \        
          X      |     |            |            |  | SEP |  AS2  
         / \     |    /             |           _|_/ \___/        
            \  __|__ /              |       ___/ |                
             \|     |_______________|______/     |       5.255.5  
         -----| STP |               |            |       (alias)  
              |_____|               |            |                
                                    |            |                
                                     \__________/                 

> 
> The signalling gateway needs two different Network Appearance
> parameters: one per SPMC.  The bottom SPMC needs only one Network
> Appearance to cover both the primary point code 5.255.4 and the alias
> point code 5.255.5 because they are both treated as the same from an SS7
> newtork management view.
> 
> [John]  NO.  Since a SINGLE network connection is in the figure above, NO
> network appearance is needed at all.  What do you think the point code is
> for??????  You seem to proposing that the network appearance replace the
> point code for routing, NO.

John, say I have one ASP serving two ASs and each AS serves and entire SEP
in the diagram as labelled.  They are served over 1 association to an ASP
which is configured and active for both ASs.  When the F-link fails from the
SG to SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).  Without
something (Routing Context/Network Appearance) to distinguish the DUNA, AS2
will also process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
200.1.4 via the STPs.

If the SG does not send DUNA(200.1.4) but attempts to route traffic from AS1
to 200.1.4 via the STPs, consider that STP Gateway Screening may throw these
messages in the garbage because 5.255.4 and 5.255.5 are the only point codes
allowed in the OPC on messages on the A-links.

So, again, there are two choices:  Make Network Appearance an identifier of
the SPMC and include it on all DUNA/DAVA/etc. where the ASP servers mutliple
SPMCs, or include Routing Context in DUNA/DAVA/etc.

> 
> Now, in general, a rational basis for assigning Network Apearance Id's
> is to use the Network Id and Point Code of the node (the node *is* the
> network appearance).  Therefore, the DUNA, DAVA, etc. that the SG sends
> concerning the SPMC will be properly distinguish.
> 
> [John]  NO.  A single network appearance (== network ID) + affected point
> code is all that is needed. 
> 
> Note that if the proposed assignment of Network Appearances is used,
> the SCON message no longer requires a Concerned Point Code parameter
> when the SPMC is signalling congestion to the SG.  It need only use
> the Network Appearance.
> 
> [John] NO.
> 
> The definition of a Network Appearance becomes (effectively): "An unique
> identifier indicating the Signalling Point Management Cluster (SPMC) to
> which Signalling Network Management Messages apply."
> 
> [John]  NO.
> 
> --Brian
> 
> 
> Schantz, John wrote:                         (Mon, 23 Jul 2001 13:37:00)
> > Brian,
> > 
> > 	Why the need to include a concerned PC at all, the PC would be
> > redundant to the one in the DPC.  Why not let the network appearance
> > parameter be equal to the Network ID (all 32 bits).  Then Network
> > Appearance(Network ID) + DPC will be unique and it will separate out the
> > traffic into networks in both directions SG->AS and AS->SG(-> and
beyond).
> > 
> > John 
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Monday, July 23, 2001 6:41 AM
> > To: sigtran
> > Cc: Greg Sidebottom
> > Subject: M3UA07: Network Appearance
> > 
> > 
> > Greg,
> > 
> > When an SG is has multiple point codes serving ASPs which are
> > active in multiple SPMCs, it becomes necessary to label each
> > SPMC with a unique Network Appearance parameter to demultiplex
> > DUNA, DAVA, DRST and SCON.  Because a separate Network Appearance
> > assignment is necessary for each SPMC and the adminstration of
> > these assignments could get quite tedious for an SGP/ASP pool
> > representing a large number of point codes, I would like to
> > propose the following refinement to the Network Appearance
> > Parameter:
> > 
> > (This is in fitting with the definition that a "Network Appearance
> uniquely
> > identifies an SS7 entity (Point Code) into an SS7 network.")
> > 
> > The format of the Network Appearance parameter 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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |  Network Id   |            Concerned Point Code               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Network Identifier: 8-bit (unsigned integer)
> > 
> >    The Network Identifier identifies the network in which the Concerned
> >    Point Code can be considered unique, and distinguishes this Concerned
> >    Point Code from an identical point code in any another network.
> >    A Network Identifier identifying a specific adminsitrative domain for
> >    the assignment of SS7 Signalling Point Codes MUST be global to all
> >    SGPs in an SG.
> > 
> > Concerned Point Code:
> > 
> >    The Concerned Point Code identifies a point code within the
> >    administrative domain as indicated by the Network Identifier.  The
> >    Concerned Point Code is the one point code of a Signalling Point
> >    Management Cluster (SPMC) which needs to receive updates concerning
> >    the accessibility/restriction/congestion status of routesets from the
> >    SPMC.
> > 
> > 
> > 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]
> > 
> > 
> > ---
> > 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]

-- 
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]
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Network Appearance
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
From: [email-masked]
Date: Mon, 30 Jul 2001 13:14:06 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/30/2001 10:17:07 AM, Serialize 
             complete at 07/30/2001 10:17:07 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]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Your attempt to redefine "Network Appearance" as the "SPMC identifier" is
unnecessary, confusing and incorrect.

The purpose of the Network Appearance is to allow the Sigtran stack to
differentiate in its handling of messages coming from different SS7 networks
to which the SG may be connected, particularly when the traffic from the
different networks is going over the same SCTP association.

The purpose of the SPMC is almost exactly opposite. Its purpose is to allow
the SS7 network to view the Sigtran network of SG's and AS's as a single
entity to which SS7 network management procedures can be applied.

I also object to the following sentence which was added to the Network
Appearance definition in v7:

"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."

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

"Brian F. G. Bidulock" <[email-masked]> 07/28/01 09:07 AM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        Re: M3UA07: Network Appearance

[snip]

The definition of a Network Appearance becomes (effectively): "An unique
identifier indicating the Signalling Point Management Cluster (SPMC) to
which Signalling Network Management Messages apply."

--Brian

Schantz, John wrote:                         (Mon, 23 Jul 2001 13:37:00)
> Brian,
> 
>                Why the need to include a concerned PC at all, the PC would
be
> redundant to the one in the DPC.  Why not let the network appearance
> parameter be equal to the Network ID (all 32 bits).  Then Network
> Appearance(Network ID) + DPC will be unique and it will separate out the
> traffic into networks in both directions SG->AS and AS->SG(-> and beyond).
> 
> John 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, July 23, 2001 6:41 AM
> To: sigtran
> Cc: Greg Sidebottom
> Subject: M3UA07: Network Appearance
> 
> 
> Greg,
> 
> When an SG is has multiple point codes serving ASPs which are
> active in multiple SPMCs, it becomes necessary to label each
> SPMC with a unique Network Appearance parameter to demultiplex
> DUNA, DAVA, DRST and SCON.  Because a separate Network Appearance
> assignment is necessary for each SPMC and the adminstration of
> these assignments could get quite tedious for an SGP/ASP pool
> representing a large number of point codes, I would like to
> propose the following refinement to the Network Appearance
> Parameter:
> 
> (This is in fitting with the definition that a "Network Appearance
uniquely
> identifies an SS7 entity (Point Code) into an SS7 network.")
> 
> The format of the Network Appearance parameter 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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Network Id   |            Concerned Point Code               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Network Identifier: 8-bit (unsigned integer)
> 
>    The Network Identifier identifies the network in which the Concerned
>    Point Code can be considered unique, and distinguishes this Concerned
>    Point Code from an identical point code in any another network.
>    A Network Identifier identifying a specific adminsitrative domain for
>    the assignment of SS7 Signalling Point Codes MUST be global to all
>    SGPs in an SG.
> 
> Concerned Point Code:
> 
>    The Concerned Point Code identifies a point code within the
>    administrative domain as indicated by the Network Identifier.  The
>    Concerned Point Code is the one point code of a Signalling Point
>    Management Cluster (SPMC) which needs to receive updates concerning
>    the accessibility/restriction/congestion status of routesets from the
>    SPMC.
> 
> 
> 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]
> 
> 
> ---
> 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: "Duhoon, Rajiv" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Multiple SGPs per Host
Date: Mon, 30 Jul 2001 10:39:44 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: calliope1.fm.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: fmfdns01.fm.intel.com [132.233.247.10]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Sandeep,
please see my comments below.......

-Rajiv
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent: Thursday,
July 26, 2001 3:32 AM
To: sigtran
Subject: M3UA: Multiple SGPs per Host

Hi ,

If we consider that  in a SGP-ASP configuration , ASP is a client and SGP is
a
server.  Is it allowed to have multiple SGPs on a single Host ??

Yes, Its possible to have multiple SGPs on a single Host.

Can a Single ASP connect to multiple of these SGPs residing on the same Host
??

Yss, A Single ASP can connect to multiple of these SGPs on the same Host.

Does SGP have a unique SCTP transport address , if so will there be multiple
well known servers running on a Host if there are multiple SGPs  ??

Yes each SGP need to have unique transport address which is basic
requirement of 
establishing an association between two end points, that way there will be
multiple
well known servers running on a Host.

Best Regards,
-Sandeep

---
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: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: FW: M3UA: Routing Context
Date: Mon, 30 Jul 2001 10:48:46 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.114.1.208]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

mailer must have ate the first one sent.

-----Original Message-----
From: Schantz, John 
Sent: Monday, July 30, 2001 10:20 AM
To: [email-masked]' Subject: RE: M3UA: Routing
Context

Brian,

	Comments below.

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Friday, July
27, 2001 6:55 PM
To: sigtran
Subject: Re: M3UA: Routing Context

John,

I'm glad you broght this up.  Let me just modify your diagram slightly and
we can move to the next level:

                            _________  
                           (   Sub   ) 
                     _____(  Network  )_____
     5.255.3        /     (     A     )     \       _________
   +----------+    /       (_________)       \     (         )
   |          |___/                           \___(  Network  )
   | SS7 node |___                             ___(     Y     )
   |    S     |   \         _________         /    (_________)
   +----------+    \       (   Sub   )       /
     5.255.4        \_____(  Network  )_____/
                          (     B     )
                           (_________) 

The SS7 node S has two point codes (5.255.3 and 5.255.4) in Network Y which
are attached by subnetworks A and B which are disjoint at S.  One is, say, a
point code S uses to connect to SNET, the other is used to connect to AT&T.
They both belong to the same SS7 point code administrative domain.  (That
is, they both have the same Network Id.)

[John]  SNET and AT&T is a bad example.  BUT this might occur if node S has
reached the 16 link per linkset limit in SS7.  Point codes 5.255.3 and
5.255.4 are physical point codes (Note, very few nodes, if any, can do this
at the moment).  In this situation, node S maintains an internal network ID
(network appearance?) for its multiple connections to network Y.  This all
that it needs.

Following your diagrams through...
                                                              5.255.5
                                                              ________ 
                                                             |        |
                    +--------+        _________              |  Node  |
                    |        |       (         )             |    X   |
                    |        |______(  Network  )_____       |________|
     5.255.3        |        |      (     A     )     X       ____|____
   +----------+     |        |       (_________)       X     (         )
   |          |     |        |                          X___(  Network  )
   | SS7 node |-----|   SG   |                           ___(     Y     )
   |    S     |     |        |        _________         /    (_________)
   +----------+     |        |       (         )       /
     5.255.4        |        |______(  Network  )_____/
                    |        |      (     B     )
                    |        |       (_________)
                    +--------+

Because, as shown, point code X can be inaccessible from 5.255.3, but can
still be accessible from 5.255.4, these two point codes within the same
network need different Network Appearances to distinguish for which point
code the DUNA(X) applies.  If each SPMC behind the SG has its own physical
routes (links) to the SS7 network on the SS7 side of the SG, each will need
its own Network Appearance to distinguish signalling network management
menssages which are destined to it alone.

[John]  You skipped a figure but lets fill in come of the gaps.  There are
network appearances (network IDs) assigned for network A connection and
network B connection.  Since node X is unavailable on the network A, a TFP
from the network A is sent to the SG.  Also note that node S and the SG are
handling networks A & B as INDEPENDENT networks and separate networks.
Since the SG can not reach node X from network A, it passes on a DUNA that
must contain the network appearance (network ID) for network A.  This is all
that node S needs to mark node X from network A prohibited.

If the Routing Context for these point codes is the "whole" point code, then
each point codes requires both a Unique Routing Context and a Unique Network
Appearace.  Thus, Routing Context == Network Appearance.

[John]  No, the routing context == network appearance + point code, but
these are derived from the network appearance parameter and the affect point
code parameter in the DUNA message.  A separate routing context parameter is
NOT needed, it is excess baggage especially if there are multiple nodes
contained in the DUNA.  Note, we need to clearly identify the affected point
codes.  I view routing context as a forward routing concept, not an
originating or affected point code.  By the way, DUNAs should be "clean",
i.e., should only contain affected point codes from one network (connection
in this case, network A).  

Plus, as above, one Network Appearance can be required for each point code,
not each Network Id, as it might appear.  (Even if, as shown, the point
codes are even in the same block!) Because Routing Context is already
assigned on an MTP-User basis at the ASP, it uniquely determines which
MTP-User at the ASP to which the DUNA message applies.  There is no need for
messing around with Network Appearances.  Just use the Routing Context.  The
Routing Context is required for other purposes anyway (it uniquely
identifies an Application Server and a Routing Key).

[John]  NO, I do not agree.  Only a single network appearance per network
connection is needed.  The single network appearance is all that is needed
to clearly identify the point codes and to what network they belong.

--brian

> In this case Node S and the SG must share an agreed to "network
appearance"
> for each network that is involved (Network A & B).  I assume that this
will
> be network operator assigned (network operator that owns Node S and SG).
> This will take care of the messaging and the network management. But what
is
> the basis for creating the connection between Node S and the SG.  It was
the

Schantz, John wrote:                                     (Fri, 27 Jul 2001
12:44:42)
> Brian,
> 
> I think you need to step back for a moment and re-examine what you are
> trying to solve.  I think you are trying to solve the case where an SS7
node
> wants to have an appearance in more than one network, hence, the concept
of
> MTP-SAP.  But in your case you want all traffic to flow through the same
> signalling path to the node.
> 
> Below is the SS7 scenario:
>                               _________
>                              (         )
>                        _____(  Network  )
>                       /     (     A     )
>      +----------+    /       (_________)
>      |          |___/
>      | SS7 node |___
>      |    S     |   \         _________
>      +----------+    \       (         )
>                       \_____(  Network  )
>                             (     B     )
>                              (_________)
> 
> Node S has separate links to Networks A & B.  Node S is identified by a
> point code from each network, for now lets call them, x (from Network A)
and
> y (from Network B).  The MTP-SAP concept was added (a local concept) where
> node S had to associate a network ID to Networks A & B, lets use A & B as
> the Network IDs.  Hence, node S has to mark each message received with a
> Network ID of A or B, based on the network it was received from.  Outbound
> messages from the MTP-users also had to be marked with a network ID.
> Logically, Node S could be viewed as have 2 SCCP/MTP protocol stacks.  The
> network ID is used to discriminate which protocol stack handles which
> message.  
> 
> For an applications point-of-view (SSN), the easy case is when the message
> being sent is a reply, i.e., given the same network ID as the received
> message.  If the message is being generated from the application, the
> application would need to know which network it was destined for and mark
> it.
> 
> Hence, Network ID + point code uniquely identified the destination.  The
> network ID is used to select the protocol stack/links belonging a specific
> network, and the PC to select the correct route to that network.
> 
> This same picture can be moved over to the SS7 over IP case.  If Node S
has
> separate connections to the different networks, it must locally keep track
> of the networks.  The SGs that it connects to do not have to be involved.
> 
> Now what about the picture where you have the SGs connecting to the
> different networks.  There are 2 cases in this situation: 1) traffic is
> separated and 2) traffic is merged.  
> 
> Traffic is Separated:  The traffic could be kept separate by having Node S
> establish connections to the different "sides" of the SG.  This would be
in
> line with the SS7 rules that the SG would have present a different
> "appearance", actually a physical point code, for each network
represented.
> Look at the figure below:
> 
>                           +--------+        _________
>                           |+------+|       (         )
>                        ___||  SG  ||______(  Network  )
>                       /   ||   A  ||      (     A     )
>      +----------+    /    |+------+|       (_________)
>      |          |___/     |        |
>      | SS7 node |___      |   SG   |
>      |    S     |   \     |        |        _________
>      +----------+    \    |+------+|       (         )
>                       \___||  SG  ||______(  Network  )
>                           ||   B  ||      (     B     )
>                           |+------+|       (_________)
>                           +--------+
> 
> The A-side of the SG and of Node S requires a point code from network A.
> The B-side of the SG and of Node S requires a  point code from network B.
> Each node, S and SG, could internal keep track of the messages/networks by
> using their own network ID.  They could also agree (network operator
option)
> to use the "network appearance" parameter so that node S and SG (and other
> nodes) use a common ID for the networks.
> 
> Traffic is Merged:  IMHO, this is a more difficult case to visualize.
Below
> is a figure.
> 
>                           +--------+        _________
>                           |        |       (         )
>                           |        |______(  Network  )
>                           |        |      (     A     )
>      +----------+         |        |       (_________)
>      |          |         |        |
>      | SS7 node |---------|   SG   |
>      |    S     |         |        |        _________
>      +----------+         |        |       (         )
>                           |        |______(  Network  )
>                           |        |      (     B     )
>                           |        |       (_________)
>                           +--------+
> 
> In this case Node S and the SG must share an agreed to "network
appearance"
> for each network that is involved (Network A & B).  I assume that this
will
> be network operator assigned (network operator that owns Node S and SG).
> This will take care of the messaging and the network management. But what
is
> the basis for creating the connection between Node S and the SG.  It was
the
> adjacent physical point codes that both Node S and SG had (and must still
> have), but what is it now?  I will have to think on how to eliminate the
> adjacent PC in this.
> 
> But I still conclude that all that is required is the "network appearance"
> defined as a network ID.
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 4:24 AM
> To: sigtran
> Cc: Greg Sidebottom
> Subject: Re: M3UA: Routing Context
> 
> 
> John, Greg,
> 
> Some of these things aren't apparent until one tries to go
> and build the thing.
> 
> Here is the problem:  architecturally, M3UA exports the MTP-Provider/User
> interface, like so:
> 
>                                                                 
>                                                                 
>                                    Application      Application 
>                                     Server #2        Server #1  
>                                    ___________      ___________ 
>                                   |           |    |           |
>                                   |   MTP     |    |   MTP     |
>                                   |   User    |    |   User    |
>                                   |           |    |           |
>                                   |___________|    |___________|
>                                      |     ^          |     ^   
>                           __         |     |          |     |   
>               ___________/__\_______/     /           |     |   
>              /   _______|____|___________/            |     |   
>             /   /       |    |                       /     /    
>            /   /        |    |           __         /     /     
>           /   / ________|____|______<___/__\_______/     /      
>           |   |/   _____|____|______>__|____|___________/       
>           |   /   /      \__/           \__/                    
>           |  /|  /         \              \                     
>           | / | /           \              \                    
>           ||  ||             \              \                   
>         __vv__||__         One SCTP       Routing               
>        |          |       Association     Context               
>        |          |                                             
>        |   MTP    |                                             
>        | Provider |                                             
>        |          |                                             
>        |          |                                             
>        |__________|                                             
>                                                                 
>         Signalling                                              
>          Gateway                                                
>         (Process)                                               
>                                                                 
>                                                                 
> Where, the MTP-SAP can be identified by the Routing Context.  The SG may
> apply a "Routing Key" to find the MTP-SAP, but this is a function which
> is performed *below* the MTP-User interface.  If M3UA would label all
> messages with the Routing Context (where ambiguous, as shown), then
> there would be no confusion as to which MTP-SAP is being used either for
> outgoing or incoming messages.
> 
> For example, when the SG performs transfer-prohibited procedures and
> discovers that an SPMC signalling point is prohibited off a routeset, it
> informs the MTP-Users.  So, the MTP has a list of "Users" to which it
> sends MTP-PAUSE primitives.  We have the same thing in the SG, a list
> of routing contexts, each which represents an MTP-User bound to an
> MTP-SAP.  So instead, of attaching a list of Routing Contexts to the
> DUNA (or sending multiple DUNAs, each with its own routing context), we
> are throwing up a DUNA with a "Network Appearance".  There are a number
> of cases where the Network Appearance becomes ambiguous at the ASP
> unless Network Appearance == Routing Context. (And then what is the
> point of two names for the same thing?)
> 
> For the ASP -> SGP direction, consider that the MTP at the SG cannot
> determine the origin of the message (i.e, which MTP-SAP the message came
> from.)  There is nothing stopping AS#2 from placing an OPC/SI in the
> message which doesn't belong to it.  In fact, the MTP-User should not
> even be putting the OPC/SI in the message: the SG should do this on the
> basis of the DPC key associated with the Routing Context.  I don't think
> that the SG should just blindly route messages based on DPC without any
> screening whatsoever.
> 
> Now, I am fully aware that you do not believe in MTP-SAPs which are not
> the "whole" point code.  But in the case where routing keys are "whole"
> point codes, Network Appearance == Routing Context.  For sub-point code
> MTP-SAPs (e.g., ISUP goes to AS#1, SCCP to AS#2), AS#1 needs to be
> screened off of placing a non-ISUP SI in the routing label, and not
> using its own point code.  AS#1 needs to have messages screend by
> DPC as well unless one wants to try to replicate gateway screening above
> the MTP-User interface.
> 
> So, John, you should not care if Network Appearance is replaced with
> Routing Context, because in your case Network Appearance == Routing
> Context, even though you don't see the need, because it is not
> applicable in your cases.
> 
> --brian
> 
> 
> 
> Schantz, John wrote:                        (Mon, 23 Jul 2001 13:04:29)
> > Brian,
> > 	This doesn't really make any sense and I don't see the need.
> > 
> > 	Why would you need a routing context in a DATA from SGP to ASP.  The
> > ASP should be determining where the message goes locally in the AS(s)
> based
> > on parameters from the SS7 message.
> > 
> > 	Requiring it in the DATA from the AS to SG doesn't make any sense.
> > The SG should be determining how to forward route the message based on
the
> > SS7 message parameters (Routing Label).  Why would the responding AS
even
> > know the RC of a remote node.  Or are you proposing that a backward RC
be
> > included.  Forward routing should not be based on backward information.
> > 
> > 	Hence, the answer to your question of whether there is an objection
> > to including the RC in the DATA message, YES I object.
> > 
> > John
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Monday, July 23, 2001 6:07 AM
> > To: sigtran
> > Cc: Greg Sidebottom
> > Subject: M3UA: Routing Context
> > 
> > 
> > Greg,
> > 
> > I would like to propose that the Routing Context be added as an
> > optional parameter to which SHOULD be included in the DATA
> > messages from the SGP and MUST be included in DATA messages from
> > the ASP when the ASP is active for more than one Application
> > Server.
> > 
> > This is *not* a replace-Network-Appearance-with-Routing-
> > Context-proposal.
> > 
> > The purpose of adding RC to DATA messages is to distinguish
> > multiple traffic flows which are multiplexed over the
> > association for use in:
> > 
> >     o   demultiplexing data traffic at the ASP without having to
> > 	reapply the Routing Key to each message to determine
> > 	routing context,
> > 
> >     o   distinguishing traffic flows for discarding data
> >         messages during ASPAC and ASPIA procedures, both at
> > 	the SG and the ASP (again without having to reapply
> > 	the Routing Key to each message at each end),
> > 
> >     o   demultiplexing buffered data messages at the ASP and the
> >         SG during failover or AS-PENDING, again, without having
> > 	to reapply a complex Routing Key.
> > 
> >     o   assists in diagnostics by permitting monitoring
> >         equipment to at least distinguish traffic flows without
> > 	having to provision monitoring equipment with routing
> > 	keys.
> > 
> > It sure simplifies a lot of places in the implementation where
> > one would have to otherwise reapply the routing key.
> > 
> > I should point out that, for some routing keys (e.g, SCCP SSN)
> > it is currently impossible for the SGP to distinguish between AS
> > for *incoming* traffic when there are multiple AS on an
> > association.  This is because the Routing Key-->Routing
> > Context-->AS mapping is only valid for traffic from the SGP
> > towards the ASP.
> > 
> > Any objections to including RC in DATA messages?
> > 
> > --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]
> > 
> > 
> > ---
> > 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]

-- 
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: "Gradischnig, Klaus" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07: Network Appearance
Date: Mon, 30 Jul 2001 13:11:41 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: pine.neustar.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pine.neustar.com [209.173.57.70]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

All:

I am getting increasingly confused by this discussion on NA. However, just
looking at its definition in M3UA08 alone would be enough to do the job:

"Network Appearance - The Network Appearance uniquely identifies an SS7
entity (Point Code) into an SS7 network, as presented by the SG.  It is used
for the purposes of logically separating the signalling traffic between the
SG and the Application Server Processes over a common SCTP association.
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.  It is also necessary when an SG is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[KDG] This clearly says to me that I need an NA if and only if I have
multiple networks. In this case I need an NA for every point code, however.
Why I would need this in the case of multiple networks only beats me. [KDG]

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.  An example is where an SG is
logically partitioned to appear as an element in four separate national SS7
networks.  A Network Appearance 
                                         ^^^^^^^^^^^^^^^^^^^^ implicitly
defines the SS7 Point Code(s), Network Indicator and MTP3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ protocol type/variant/version used
within a separate SS7 network.  

[KDG] In contrast, this last sentence now tells me that I need one and only
one
NA for each network. This is at least something I understand and it
corresponds
to NA's original definition. [KDG]"

And while I can see where Brian's example below is coming from, I can't
except his arguments:
In the general case OPC specific screening cannot be handled by MTP
network/route management functions and therefore OPC specific routing cannot
be supported without restrictions to either connectivity or network
management functionality. The example might start making sense if the SG
considered 5.255.3 and 5.255.4 to belong to "separate" networks using
different routing tables in the SG. In this case the SG may have to have
distinct point codes in these "separate" networks, provided then "separate"
networks are actually interconnected (seems not to be the case in this
example, though).
In any case, I fully support John's and Barry's view that NA identifies a
network (albeit from an SG internal view) and not an SPMC.

I am -- on an abstract level -- rather concerned about the unnecessary
complexity which has been introduced into m3ua and I have some indication
that a number of operators and manufacturers share this view. How much of
m3ua's functionality has actually been tested in Sophia? It seems to me that
without some extensive testing in a real or emulated SS7 network environment
going for last call is premature.

Klaus

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: July 30, 2001 1:09 PM
> To: sigtran
> Subject: Re: M3UA07: Network Appearance
> 
> 
> John,
> 
> Please see response inline...
> 
> John Schantz wrote:                               (Mon, 30 
> Jul 2001 09:24:56)
> > Brian,
> > 
> > 	NO, see response to "M3UA: Routing Context".  Only a 
> single network
> > appearance is needed per network connection.
> > 
> > 	More comments below.
> > 
> > John
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Saturday, July 28, 2001 8:08 AM
> > To: sigtran
> > Subject: Re: M3UA07: Network Appearance
> > 
> > 
> > John,
> > 
> > Perhaps now you can see (from our discussion on the thread "M3UA:
> > Routing Context") that to cover all configurations, a 
> Network Appearance
> > valud is required per primary point code and network id, 
> and that this
> > proposal was a natural extension of that fact.  Consider 
> the case below:
> > 
> > [John] NO.
> > 
>                                                                   
>                                                                   
>                            200.1.4    __________                  
>                              ___     /          \     ___         
>                             /   \   |            |   /   \        
>                            | SEP |__|____________|__| SEP |  AS1  
>                             \___/   |            |   \___/        
>                            //       |            |                
>                           / |       | Signalling |  5.255.3       
>                          / /        |   Gateway  |                
>                         /  |        |            |                
>                        /  /         |            |                
>                _____  /   |         |            |                
>               |     |/   /          |            |                
>          -----| STP |____|__________|______      |                
>              /|_____|   /           |      \___  |  5.255.4       
>             /    |      |           |          \_|_   ___         
>          \ /     |     /            |            | \ /   \        
>           X      |     |            |            |  | SEP |  AS2  
>          / \     |    /             |           _|_/ \___/        
>             \  __|__ /              |       ___/ |                
>              \|     |_______________|______/     |       5.255.5  
>          -----| STP |               |            |       (alias)  
>               |_____|               |            |                
>                                     |            |                
>                                      \__________/                 
>                                                                   
>                                                                   
> > 
> > The signalling gateway needs two different Network Appearance
> > parameters: one per SPMC.  The bottom SPMC needs only one Network
> > Appearance to cover both the primary point code 5.255.4 and 
> the alias
> > point code 5.255.5 because they are both treated as the 
> same from an SS7
> > newtork management view.
> > 
> > [John]  NO.  Since a SINGLE network connection is in the 
> figure above, NO
> > network appearance is needed at all.  What do you think the 
> point code is
> > for??????  You seem to proposing that the network 
> appearance replace the
> > point code for routing, NO.
> 
> John, say I have one ASP serving two ASs and each AS serves 
> and entire SEP in
> the diagram as labelled.  They are served over 1 association 
> to an ASP which
> is configured and active for both ASs.  When the F-link fails 
> from the SG to
> SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).  
> Without something
> (Routing Context/Network Appearance) to distinguish the DUNA, 
> AS2 will also
> process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP 
> 200.1.4 via
> the STPs.
> 
> If the SG does not send DUNA(200.1.4) but attempts to route 
> traffic from AS1
> to 200.1.4 via the STPs, consider that STP Gateway Screening 
> may throw these
> messages in the garbage because 5.255.4 and 5.255.5 are the 
> only point codes
> allowed in the OPC on messages on the A-links.
> 
> So, again, there are two choices:  Make Network Appearance an 
> identifier
> of the SPMC and include it on all DUNA/DAVA/etc. where the ASP servers
> mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> 
> > 
> > Now, in general, a rational basis for assigning Network 
> Apearance Id's
> > is to use the Network Id and Point Code of the node (the 
> node *is* the
> > network appearance).  Therefore, the DUNA, DAVA, etc. that 
> the SG sends
> > concerning the SPMC will be properly distinguish.
> > 
> > [John]  NO.  A single network appearance (== network ID) + 
> affected point
> > code is all that is needed. 
> > 
> > Note that if the proposed assignment of Network Appearances is used,
> > the SCON message no longer requires a Concerned Point Code parameter
> > when the SPMC is signalling congestion to the SG.  It need only use
> > the Network Appearance.
> > 
> > [John] NO.
> > 
> > The definition of a Network Appearance becomes 
> (effectively): "An unique
> > identifier indicating the Signalling Point Management 
> Cluster (SPMC) to
> > which Signalling Network Management Messages apply."
> > 
> > [John]  NO.
> > 
> > --Brian
> > 
> > 
> > Schantz, John wrote:                         (Mon, 23 Jul 
> 2001 13:37:00)
> > > Brian,
> > > 
> > > 	Why the need to include a concerned PC at all, the PC would be
> > > redundant to the one in the DPC.  Why not let the network 
> appearance
> > > parameter be equal to the Network ID (all 32 bits).  Then Network
> > > Appearance(Network ID) + DPC will be unique and it will 
> separate out the
> > > traffic into networks in both directions SG->AS and 
> AS->SG(-> and beyond).
> > > 
> > > John 
> > > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Monday, July 23, 2001 6:41 AM
> > > To: sigtran
> > > Cc: Greg Sidebottom
> > > Subject: M3UA07: Network Appearance
> > > 
> > > 
> > > Greg,
> > > 
> > > When an SG is has multiple point codes serving ASPs which are
> > > active in multiple SPMCs, it becomes necessary to label each
> > > SPMC with a unique Network Appearance parameter to demultiplex
> > > DUNA, DAVA, DRST and SCON.  Because a separate Network Appearance
> > > assignment is necessary for each SPMC and the adminstration of
> > > these assignments could get quite tedious for an SGP/ASP pool
> > > representing a large number of point codes, I would like to
> > > propose the following refinement to the Network Appearance
> > > Parameter:
> > > 
> > > (This is in fitting with the definition that a "Network Appearance
> > uniquely
> > > identifies an SS7 entity (Point Code) into an SS7 network.")
> > > 
> > > The format of the Network Appearance parameter 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
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |  Network Id   |            Concerned Point Code      
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > 
> > > Network Identifier: 8-bit (unsigned integer)
> > > 
> > >    The Network Identifier identifies the network in which 
> the Concerned
> > >    Point Code can be considered unique, and distinguishes 
> this Concerned
> > >    Point Code from an identical point code in any another network.
> > >    A Network Identifier identifying a specific 
> adminsitrative domain for
> > >    the assignment of SS7 Signalling Point Codes MUST be 
> global to all
> > >    SGPs in an SG.
> > > 
> > > Concerned Point Code:
> > > 
> > >    The Concerned Point Code identifies a point code within the
> > >    administrative domain as indicated by the Network 
> Identifier.  The
> > >    Concerned Point Code is the one point code of a 
> Signalling Point
> > >    Management Cluster (SPMC) which needs to receive 
> updates concerning
> > >    the accessibility/restriction/congestion status of 
> routesets from the
> > >    SPMC.
> > > 
> > > 
> > > 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]
> > > 
> > > 
> > > ---
> > > 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]
> 
> -- 
> 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: Mon, 30 Jul 2001 13:24:29 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Network Appearance
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.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Barry,

The only reason is because of lack of an SPMC Identifier in the DUNA/DAVA/..
messages.  The only parameter at my disposal in M3UAv8 is the Network
Apperance.  As anything less that an SPMC Identifier, Network Appearance is
insufficient for discriminating the SPMC on DUNA/DAVA/... messages.

The proposal to replace Network Appearance with Routing Context to solve
this problem, while readily adopted by SUAv7, has met with resistance from
those that do not understand that STP Gateway screening can completely
"partitions" an SS7 network by end-point.

In practice, the owner of an M3UA platform who needs to interconnect to
existing SS7 networks, has little choice whether the network provider
performs gateway screening.  Gateway screening is permitted in ITU models as
well and is even permitted on the International Network.

Here is one more illustrative example:

                |                                                      
                      /----------------\                               
                |     |      SG        |                               
                      |                |                               
        GWS     |     |    5.255.1     |                               
       _____          |A1    ___       |  _____|     |___|_____|____ /   \
|                               
      | STP |         |  __| SEP |     |                               
     /|_____|\  |A-links/   \___/      |                               
    /    |    \       |/ A2     \      |          /----------------\   
   /     |     \|     /          \ RC1 |     __   |      ASP       |   
  /      |      \    /|           \    |    /  \  |                |  /
C-links   |\  / |            \___|___|____|_|____ AS1        |  B/D     |
\/  |                |   |    | |                |  links   |      | /\  |
___|___|____|_|____ AS2        |  \       |       /  \ |            /   |
|    | |                |   
  \      |      |    \|           /    |    \__/  |                |   
   \     |     /      \          / RC2 |     \    |                |   
    \  __|__  / |     |\ A3  ___/      |      \   \----------------/   
     \|     |/   A-links\__ /   \      |       \  _____| STP
|___|_____|____| SEP |     |        \                      
      |_____|         |     \___/      |         \                     
                |     |A4              |       1 Association           
        GWS           |    5.255.2     |                               
                |     |                |                               
                      |                |                               
                |     \----------------/                               
                                                                       
                |                                                      
           Demarcation                                                 

Consider that I have one signalling point with two "real" point codes.
By "real" I mean that each point code has A-links associated with it as
illustrated.  There are several reasons for doing this: a) CIC range
exhaustion on large switches; b) A-link exhaustion on large databases.
Because I interconnect to a network provider (I don't own my own SS7
network) my network provider applies Gateway Screening on their side of the
Demarcation.

What gateway screening means at an access point is that the network
provider's STPs will only allow MSUs on A-links A1 and A2 in the diagram
which have OPC = 5.255.1.  Any other OPC and the MSUs will be thrown on the
floor without warning.  The STPs will only allow MSUs on A-links A3 and A4
which have OPC = 5.255.2.

So Gateway screening has effectively partitioned access into the network so
that SEP 5.255.1 can only access the network from A-links A1 and A2, and SEP
5.255.2 can only access the network from A-links A3 and A4.

I stress: this is real world example.  This happens all the time at
interconnect points.  Even between carriers.

Now, because I have one big switch or one big database, I serve each entire
point code into two Routing Contexts: RC1 and RC2.  I have a pool of ASPs
each serving AS1(RC1) and AS2(RC2).  To separate this from a multiple
SGP/ASP issue, I have only drawn one SG/SGP and one ASP.  The ASP is
connected over a single association to the SG/SGP.

Now, through a combination of conditions in the network and of the A-links
connecting the SG to the SS7 network, it is possible that a routeset becomes
prohibited, restricted or congested to SEP 5.255.1, but is it not
prohibited, restticted nor congested to SEP 5.255.2.

Consider isolation:  Say, for example, we lose A-links A1 and A2.
SEP 5.255.1 is isolated from the SS7 network and goes into MTP-RESTART.  We
want to send DUNA(-1) to the ASP to tell it that SEP 5.255.1 is isolated
from the network.  If I follow your view of Network Appearance, I do not
include a Network Appearance parameter in the DUNA message, so I send it to
the ASP.

The ASP receives DUNA(-1).  It does not know which SPMC is isolated from the
newtork, so it is forced to apply it to all ASs.  As a result, it has
effectively disconnected SEP 5.255.2 from the network.

If the SG were permitted to put RC in the DUNA message, it would label it
with RC1 and the DUNA(-1) would only be applied to AS1 at the ASP.

If Network Appearance followed the initial recommendation on this thread, it
would identify SPMC 5.255.1 and the ASP would only apply the DUNA(-1) to
AS1/SPMC1.

If RC is included in the SNMM messages, Network Appearance as you define it
would become redundant.

So you pick: which way are you going to keep a 50% link failure somewhere in
the network from turning into a 100% failure at the ASP.

--Brian

[email-masked] wrote:           (Mon, 30 Jul 2001 13:14:06)
>
> Brian,
> 
> Your attempt to redefine "Network Appearance" as the "SPMC identifier" is 
> unnecessary, confusing and incorrect.
> 
> The purpose of the Network Appearance is to allow the Sigtran stack to 
> differentiate in its handling of messages coming from different SS7 
> networks to which the SG may be connected, particularly when the traffic 
> from the different networks is going over the same SCTP association.
> 
> The purpose of the SPMC is almost exactly opposite. Its purpose is to 
> allow the SS7 network to view the Sigtran network of SG's and AS's as a 
> single entity to which SS7 network management procedures can be applied.
> 
> I also object to the following sentence which was added to the Network 
> Appearance definition in v7:
> 
> "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."
> 
> Barry Nagelberg
> Software Engineer
> RadiSys, Corp.
> Signaling Products Design Center
> [email-masked]
> +1-856-642-9229 x237
> 
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]>
> 07/28/01 09:07 AM
> Please respond to sigtran
> 
>  
>         To:     "sigtran" <[email-masked]>
>         cc: 
>         Subject:        Re: M3UA07: Network Appearance
> 
> 
> [snip]
> 
> The definition of a Network Appearance becomes (effectively): "An unique
> identifier indicating the Signalling Point Management Cluster (SPMC) to
> which Signalling Network Management Messages apply."
> 
> --Brian
> 
> 
> Schantz, John wrote:                         (Mon, 23 Jul 2001 13:37:00)
> > Brian,
> > 
> >                Why the need to include a concerned PC at all, the PC 
> would be
> > redundant to the one in the DPC.  Why not let the network appearance
> > parameter be equal to the Network ID (all 32 bits).  Then Network
> > Appearance(Network ID) + DPC will be unique and it will separate out the
> > traffic into networks in both directions SG->AS and AS->SG(-> and 
> beyond).
> > 
> > John 
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Monday, July 23, 2001 6:41 AM
> > To: sigtran
> > Cc: Greg Sidebottom
> > Subject: M3UA07: Network Appearance
> > 
> > 
> > Greg,
> > 
> > When an SG is has multiple point codes serving ASPs which are
> > active in multiple SPMCs, it becomes necessary to label each
> > SPMC with a unique Network Appearance parameter to demultiplex
> > DUNA, DAVA, DRST and SCON.  Because a separate Network Appearance
> > assignment is necessary for each SPMC and the adminstration of
> > these assignments could get quite tedious for an SGP/ASP pool
> > representing a large number of point codes, I would like to
> > propose the following refinement to the Network Appearance
> > Parameter:
> > 
> > (This is in fitting with the definition that a "Network Appearance 
> uniquely
> > identifies an SS7 entity (Point Code) into an SS7 network.")
> > 
> > The format of the Network Appearance parameter 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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |  Network Id   |            Concerned Point Code               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Network Identifier: 8-bit (unsigned integer)
> > 
> >    The Network Identifier identifies the network in which the Concerned
> >    Point Code can be considered unique, and distinguishes this Concerned
> >    Point Code from an identical point code in any another network.
> >    A Network Identifier identifying a specific adminsitrative domain for
> >    the assignment of SS7 Signalling Point Codes MUST be global to all
> >    SGPs in an SG.
> > 
> > Concerned Point Code:
> > 
> >    The Concerned Point Code identifies a point code within the
> >    administrative domain as indicated by the Network Identifier.  The
> >    Concerned Point Code is the one point code of a Signalling Point
> >    Management Cluster (SPMC) which needs to receive updates concerning
> >    the accessibility/restriction/congestion status of routesets from the
> >    SPMC.
> > 
> > 
> > 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]
> > 
> > 
> > ---
> > 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]

-- 
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: Mon, 30 Jul 2001 13:32:52 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Network Appearance
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-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Klaus,

Please see comments below...

Gradischnig, Klaus wrote:                            (Mon, 30 Jul 2001
13:11:41)
> All:
> 
> I am getting increasingly confused by this discussion on NA. However, just
> looking at its definition in M3UA08 alone would be enough to do the job:
> 
> 
> "Network Appearance - The Network Appearance uniquely identifies an SS7 
> entity (Point Code) into an SS7 network, as presented by the SG.  It is 
> used for the purposes of logically separating the signalling traffic 
> between the SG and the Application Server Processes over a common SCTP 
> association.  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.  It is also necessary when an SG is 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> [KDG] This clearly says to me that I need an NA if and only if I have 
> multiple networks. In this case I need an NA for every point code,
however.
> Why I would need this in the case of multiple networks only beats me.
[KDG]

I'm the one that asked Greg to remove "SS7 network parition" from the
wording of the definition.

> 
> 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.  An 
> example is where an SG is logically partitioned to appear as an element 
> in four separate national SS7 networks.  A Network Appearance 
>                                          ^^^^^^^^^^^^^^^^^^^^
> implicitly defines the SS7 Point Code(s), Network Indicator and MTP3 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> protocol type/variant/version used within a separate SS7 network.  
> 
> [KDG] In contrast, this last sentence now tells me that I need one and
only
> one
> NA for each network. This is at least something I understand and it
> corresponds
> to NA's original definition. [KDG]"
> 
> And while I can see where Brian's example below is coming from, I can't
> except his arguments:
> In the general case OPC specific screening cannot be handled by MTP
> network/route management functions and therefore OPC specific routing
cannot
> be supported without restrictions to either connectivity or network
> management functionality. The example might start making sense if the SG
> considered 5.255.3 and 5.255.4 to belong to "separate" networks using
> different routing tables in the SG. In this case the SG may have to have
> distinct point codes in these "separate" networks, provided then
"separate"
> networks are actually interconnected (seems not to be the case in this
> example, though).
> In any case, I fully support John's and Barry's view that NA identifies a
> network (albeit from an SG internal view) and not an SPMC.

Then Routing Context is required in all SNMM messages (and NA is not).  See
the example in my other note on this thread.

> 
> I am -- on an abstract level -- rather concerned about the unnecessary
> complexity which has been introduced into m3ua and I have some indication
> that a number of operators and manufacturers share this view. How much of
> m3ua's functionality has actually been tested in Sophia? It seems to me
that
> without some extensive testing in a real or emulated SS7 network
environment
> going for last call is premature.

That is exactly why last call is required.  Only after M3UA stops becoming a
moving target will it ever be tested in a real or emulated SS7 network.
Otherwise, the testing will always be two draft versions behind.  The draft
is changing at a faster rate than the code.

--Brian

> 
> Klaus
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: July 30, 2001 1:09 PM
> > To: sigtran
> > Subject: Re: M3UA07: Network Appearance
> > 
> > 
> > John,
> > 
> > Please see response inline...
> > 
> > John Schantz wrote:                               (Mon, 30 
> > Jul 2001 09:24:56)
> > > Brian,
> > > 
> > > 	NO, see response to "M3UA: Routing Context".  Only a 
> > single network
> > > appearance is needed per network connection.
> > > 
> > > 	More comments below.
> > > 
> > > John
> > > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Saturday, July 28, 2001 8:08 AM
> > > To: sigtran
> > > Subject: Re: M3UA07: Network Appearance
> > > 
> > > 
> > > John,
> > > 
> > > Perhaps now you can see (from our discussion on the thread "M3UA:
> > > Routing Context") that to cover all configurations, a 
> > Network Appearance
> > > valud is required per primary point code and network id, 
> > and that this
> > > proposal was a natural extension of that fact.  Consider 
> > the case below:
> > > 
> > > [John] NO.
> > > 
> >                                                                   
> >                                                                   
> >                            200.1.4    __________                  
> >                              ___     /          \     ___         
> >                             /   \   |            |   /   \        
> >                            | SEP |__|____________|__| SEP |  AS1  
> >                             \___/   |            |   \___/        
> >                            //       |            |                
> >                           / |       | Signalling |  5.255.3       
> >                          / /        |   Gateway  |                
> >                         /  |        |            |                
> >                        /  /         |            |                
> >                _____  /   |         |            |                
> >               |     |/   /          |            |                
> >          -----| STP |____|__________|______      |                
> >              /|_____|   /           |      \___  |  5.255.4       
> >             /    |      |           |          \_|_   ___         
> >          \ /     |     /            |            | \ /   \        
> >           X      |     |            |            |  | SEP |  AS2  
> >          / \     |    /             |           _|_/ \___/        
> >             \  __|__ /              |       ___/ |                
> >              \|     |_______________|______/     |       5.255.5  
> >          -----| STP |               |            |       (alias)  
> >               |_____|               |            |                
> >                                     |            |                
> >                                      \__________/                 
> >                                                                   
> >                                                                   
> > > 
> > > The signalling gateway needs two different Network Appearance
> > > parameters: one per SPMC.  The bottom SPMC needs only one Network
> > > Appearance to cover both the primary point code 5.255.4 and 
> > the alias
> > > point code 5.255.5 because they are both treated as the 
> > same from an SS7
> > > newtork management view.
> > > 
> > > [John]  NO.  Since a SINGLE network connection is in the 
> > figure above, NO
> > > network appearance is needed at all.  What do you think the 
> > point code is
> > > for??????  You seem to proposing that the network 
> > appearance replace the
> > > point code for routing, NO.
> > 
> > John, say I have one ASP serving two ASs and each AS serves 
> > and entire SEP in
> > the diagram as labelled.  They are served over 1 association 
> > to an ASP which
> > is configured and active for both ASs.  When the F-link fails 
> > from the SG to
> > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).  
> > Without something
> > (Routing Context/Network Appearance) to distinguish the DUNA, 
> > AS2 will also
> > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP 
> > 200.1.4 via
> > the STPs.
> > 
> > If the SG does not send DUNA(200.1.4) but attempts to route 
> > traffic from AS1
> > to 200.1.4 via the STPs, consider that STP Gateway Screening 
> > may throw these
> > messages in the garbage because 5.255.4 and 5.255.5 are the 
> > only point codes
> > allowed in the OPC on messages on the A-links.
> > 
> > So, again, there are two choices:  Make Network Appearance an 
> > identifier
> > of the SPMC and include it on all DUNA/DAVA/etc. where the ASP servers
> > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> > 
> > > 
> > > Now, in general, a rational basis for assigning Network 
> > Apearance Id's
> > > is to use the Network Id and Point Code of the node (the 
> > node *is* the
> > > network appearance).  Therefore, the DUNA, DAVA, etc. that 
> > the SG sends
> > > concerning the SPMC will be properly distinguish.
> > > 
> > > [John]  NO.  A single network appearance (== network ID) + 
> > affected point
> > > code is all that is needed. 
> > > 
> > > Note that if the proposed assignment of Network Appearances is used,
> > > the SCON message no longer requires a Concerned Point Code parameter
> > > when the SPMC is signalling congestion to the SG.  It need only use
> > > the Network Appearance.
> > > 
> > > [John] NO.
> > > 
> > > The definition of a Network Appearance becomes 
> > (effectively): "An unique
> > > identifier indicating the Signalling Point Management 
> > Cluster (SPMC) to
> > > which Signalling Network Management Messages apply."
> > > 
> > > [John]  NO.
> > > 
> > > --Brian
> > > 
> > > 
> > > Schantz, John wrote:                         (Mon, 23 Jul 
> > 2001 13:37:00)
> > > > Brian,
> > > > 
> > > > 	Why the need to include a concerned PC at all, the PC would
be
> > > > redundant to the one in the DPC.  Why not let the network 
> > appearance
> > > > parameter be equal to the Network ID (all 32 bits).  Then Network
> > > > Appearance(Network ID) + DPC will be unique and it will 
> > separate out the
> > > > traffic into networks in both directions SG->AS and 
> > AS->SG(-> and beyond).
> > > > 
> > > > John 
> > > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > To: sigtran
> > > > Cc: Greg Sidebottom
> > > > Subject: M3UA07: Network Appearance
> > > > 
> > > > 
> > > > Greg,
> > > > 
> > > > When an SG is has multiple point codes serving ASPs which are
> > > > active in multiple SPMCs, it becomes necessary to label each
> > > > SPMC with a unique Network Appearance parameter to demultiplex
> > > > DUNA, DAVA, DRST and SCON.  Because a separate Network Appearance
> > > > assignment is necessary for each SPMC and the adminstration of
> > > > these assignments could get quite tedious for an SGP/ASP pool
> > > > representing a large number of point codes, I would like to
> > > > propose the following refinement to the Network Appearance
> > > > Parameter:
> > > > 
> > > > (This is in fitting with the definition that a "Network Appearance
> > > uniquely
> > > > identifies an SS7 entity (Point Code) into an SS7 network.")
> > > > 
> > > > The format of the Network Appearance parameter 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
> > > >    
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    |  Network Id   |            Concerned Point Code      
> >          |
> > > >    
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > 
> > > > Network Identifier: 8-bit (unsigned integer)
> > > > 
> > > >    The Network Identifier identifies the network in which 
> > the Concerned
> > > >    Point Code can be considered unique, and distinguishes 
> > this Concerned
> > > >    Point Code from an identical point code in any another network.
> > > >    A Network Identifier identifying a specific 
> > adminsitrative domain for
> > > >    the assignment of SS7 Signalling Point Codes MUST be 
> > global to all
> > > >    SGPs in an SG.
> > > > 
> > > > Concerned Point Code:
> > > > 
> > > >    The Concerned Point Code identifies a point code within the
> > > >    administrative domain as indicated by the Network 
> > Identifier.  The
> > > >    Concerned Point Code is the one point code of a 
> > Signalling Point
> > > >    Management Cluster (SPMC) which needs to receive 
> > updates concerning
> > > >    the accessibility/restriction/congestion status of 
> > routesets from the
> > > >    SPMC.
> > > > 
> > > > 
> > > > 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]
> > > > 
> > > > 
> > > > ---
> > > > 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]
> > 
> > -- 
> > 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]

-- 
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: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07: Network Appearance
Date: Mon, 30 Jul 2001 11:45:33 -0700
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ztxmail04.ztx.compaq.com [161.114.1.208]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

	I do not agree with your views on this.  Why are you adding
additional complexity?

	A Network Appearance (== Network ID) is more than sufficient to
uniquely discriminate the affected point codes in the DUNA/DAVA/...
Anything more is re-inventing a round wheel but with many flat sides.

	"Readily adopted by SUAv7", could it be that current real SS7 node
implementers may not have been interest and have not been paying attention.
I have not been that interested in SUA, so I have not been paying attention.

	I understand gateway screening, but who cares, it is an external
function separate from the protocol.  It does not drive the protocol.

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Monday, July
30, 2001 1:24 PM
To: sigtran
Subject: Re: M3UA07: Network Appearance

Barry,

The only reason is because of lack of an SPMC Identifier in the DUNA/DAVA/..
messages.  The only parameter at my disposal in M3UAv8 is the Network
Apperance.  As anything less that an SPMC Identifier, Network Appearance is
insufficient for discriminating the SPMC on DUNA/DAVA/... messages.

The proposal to replace Network Appearance with Routing Context to solve
this problem, while readily adopted by SUAv7, has met with resistance from
those that do not understand that STP Gateway screening can completely
"partitions" an SS7 network by end-point.

In practice, the owner of an M3UA platform who needs to interconnect to
existing SS7 networks, has little choice whether the network provider
performs gateway screening.  Gateway screening is permitted in ITU models as
well and is even permitted on the International Network.

Here is one more illustrative example:

                |                                                      
                      /----------------\                               
                |     |      SG        |                               
                      |                |                               
        GWS     |     |    5.255.1     |                               
       _____          |A1    ___       |  _____|     |___|_____|____ /   \
|                               
      | STP |         |  __| SEP |     |                               
     /|_____|\  |A-links/   \___/      |                               
    /    |    \       |/ A2     \      |          /----------------\   
   /     |     \|     /          \ RC1 |     __   |      ASP       |   
  /      |      \    /|           \    |    /  \  |                |  /
C-links   |\  / |            \___|___|____|_|____ AS1        |  B/D     |
\/  |                |   |    | |                |  links   |      | /\  |
___|___|____|_|____ AS2        |  \       |       /  \ |            /   |
|    | |                |   
  \      |      |    \|           /    |    \__/  |                |   
   \     |     /      \          / RC2 |     \    |                |   
    \  __|__  / |     |\ A3  ___/      |      \   \----------------/   
     \|     |/   A-links\__ /   \      |       \  _____| STP
|___|_____|____| SEP |     |        \                      
      |_____|         |     \___/      |         \                     
                |     |A4              |       1 Association           
        GWS           |    5.255.2     |                               
                |     |                |                               
                      |                |                               
                |     \----------------/                               
                                                                       
                |                                                      
           Demarcation                                                 

Consider that I have one signalling point with two "real" point codes.
By "real" I mean that each point code has A-links associated with it as
illustrated.  There are several reasons for doing this: a) CIC range
exhaustion on large switches; b) A-link exhaustion on large databases.
Because I interconnect to a network provider (I don't own my own SS7
network) my network provider applies Gateway Screening on their side of the
Demarcation.

What gateway screening means at an access point is that the network
provider's STPs will only allow MSUs on A-links A1 and A2 in the diagram
which have OPC = 5.255.1.  Any other OPC and the MSUs will be thrown on the
floor without warning.  The STPs will only allow MSUs on A-links A3 and A4
which have OPC = 5.255.2.

So Gateway screening has effectively partitioned access into the network so
that SEP 5.255.1 can only access the network from A-links A1 and A2, and SEP
5.255.2 can only access the network from A-links A3 and A4.

I stress: this is real world example.  This happens all the time at
interconnect points.  Even between carriers.

Now, because I have one big switch or one big database, I serve each entire
point code into two Routing Contexts: RC1 and RC2.  I have a pool of ASPs
each serving AS1(RC1) and AS2(RC2).  To separate this from a multiple
SGP/ASP issue, I have only drawn one SG/SGP and one ASP.  The ASP is
connected over a single association to the SG/SGP.

Now, through a combination of conditions in the network and of the A-links
connecting the SG to the SS7 network, it is possible that a routeset becomes
prohibited, restricted or congested to SEP 5.255.1, but is it not
prohibited, restticted nor congested to SEP 5.255.2.

Consider isolation:  Say, for example, we lose A-links A1 and A2.
SEP 5.255.1 is isolated from the SS7 network and goes into MTP-RESTART.  We
want to send DUNA(-1) to the ASP to tell it that SEP 5.255.1 is isolated
from the network.  If I follow your view of Network Appearance, I do not
include a Network Appearance parameter in the DUNA message, so I send it to
the ASP.

The ASP receives DUNA(-1).  It does not know which SPMC is isolated from the
newtork, so it is forced to apply it to all ASs.  As a result, it has
effectively disconnected SEP 5.255.2 from the network.

If the SG were permitted to put RC in the DUNA message, it would label it
with RC1 and the DUNA(-1) would only be applied to AS1 at the ASP.

If Network Appearance followed the initial recommendation on this thread, it
would identify SPMC 5.255.1 and the ASP would only apply the DUNA(-1) to
AS1/SPMC1.

If RC is included in the SNMM messages, Network Appearance as you define it
would become redundant.

So you pick: which way are you going to keep a 50% link failure somewhere in
the network from turning into a 100% failure at the ASP.

--Brian

[email-masked] wrote:           (Mon, 30 Jul 2001 13:14:06)
>
> Brian,
> 
> Your attempt to redefine "Network Appearance" as the "SPMC identifier" is 
> unnecessary, confusing and incorrect.
> 
> The purpose of the Network Appearance is to allow the Sigtran stack to 
> differentiate in its handling of messages coming from different SS7 
> networks to which the SG may be connected, particularly when the traffic 
> from the different networks is going over the same SCTP association.
> 
> The purpose of the SPMC is almost exactly opposite. Its purpose is to 
> allow the SS7 network to view the Sigtran network of SG's and AS's as a 
> single entity to which SS7 network management procedures can be applied.
> 
> I also object to the following sentence which was added to the Network 
> Appearance definition in v7:
> 
> "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."
> 
> Barry Nagelberg
> Software Engineer
> RadiSys, Corp.
> Signaling Products Design Center
> [email-masked]
> +1-856-642-9229 x237
> 
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]>
> 07/28/01 09:07 AM
> Please respond to sigtran
> 
>  
>         To:     "sigtran" <[email-masked]>
>         cc: 
>         Subject:        Re: M3UA07: Network Appearance
> 
> 
> [snip]
> 
> The definition of a Network Appearance becomes (effectively): "An unique
> identifier indicating the Signalling Point Management Cluster (SPMC) to
> which Signalling Network Management Messages apply."
> 
> --Brian
> 
> 
> Schantz, John wrote:                         (Mon, 23 Jul 2001 13:37:00)
> > Brian,
> > 
> >                Why the need to include a concerned PC at all, the PC 
> would be
> > redundant to the one in the DPC.  Why not let the network appearance
> > parameter be equal to the Network ID (all 32 bits).  Then Network
> > Appearance(Network ID) + DPC will be unique and it will separate out the
> > traffic into networks in both directions SG->AS and AS->SG(-> and 
> beyond).
> > 
> > John 
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Monday, July 23, 2001 6:41 AM
> > To: sigtran
> > Cc: Greg Sidebottom
> > Subject: M3UA07: Network Appearance
> > 
> > 
> > Greg,
> > 
> > When an SG is has multiple point codes serving ASPs which are
> > active in multiple SPMCs, it becomes necessary to label each
> > SPMC with a unique Network Appearance parameter to demultiplex
> > DUNA, DAVA, DRST and SCON.  Because a separate Network Appearance
> > assignment is necessary for each SPMC and the adminstration of
> > these assignments could get quite tedious for an SGP/ASP pool
> > representing a large number of point codes, I would like to
> > propose the following refinement to the Network Appearance
> > Parameter:
> > 
> > (This is in fitting with the definition that a "Network Appearance 
> uniquely
> > identifies an SS7 entity (Point Code) into an SS7 network.")
> > 
> > The format of the Network Appearance parameter 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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |  Network Id   |            Concerned Point Code               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Network Identifier: 8-bit (unsigned integer)
> > 
> >    The Network Identifier identifies the network in which the Concerned
> >    Point Code can be considered unique, and distinguishes this Concerned
> >    Point Code from an identical point code in any another network.
> >    A Network Identifier identifying a specific adminsitrative domain for
> >    the assignment of SS7 Signalling Point Codes MUST be global to all
> >    SGPs in an SG.
> > 
> > Concerned Point Code:
> > 
> >    The Concerned Point Code identifies a point code within the
> >    administrative domain as indicated by the Network Identifier.  The
> >    Concerned Point Code is the one point code of a Signalling Point
> >    Management Cluster (SPMC) which needs to receive updates concerning
> >    the accessibility/restriction/congestion status of routesets from the
> >    SPMC.
> > 
> > 
> > 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]
> > 
> > 
> > ---
> > 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]

-- 
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: Mon, 30 Jul 2001 13:55:31 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Network Appearance
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-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Klaus,

Gradischnig, Klaus wrote:                            (Mon, 30 Jul 2001
13:11:41)

[snip]

> And while I can see where Brian's example below is coming from, I can't
> except his arguments:
> In the general case OPC specific screening cannot be handled by MTP
> network/route management functions and therefore OPC specific routing
cannot
> be supported without restrictions to either connectivity or network
> management functionality.
[snip]

Because it appears that you have a problem understanding how gateway
screening works in the SS7 network, here is a repeat example without gateway
screening:

                |                                                      
                      /----------------\                               
                |     |      SG        |                               
                      |                |                               
                |     |    5.255.1     |                               
       _____          |A1    ___       |  _____|     |___|_____|____ /   \
|                               
      | STP |         |  __| SEP |     |                               
     /|_____|\  |A-links/   \___/      |                               
    /    |    \       |/ A2     \      |          /----------------\   
   /     |     \|     /          \ RC1 |     __   |      ASP       |   
  /      |      \    /|           \    |    /  \  |                |  /
C-links   |\  / |            \___|___|____|_|____ AS1        |  B/D     |
\/  |                |   |    | |                |  links   |      | /\  |
___|___|____|_|____ AS2        |  \       |       /  \ |            /   |
|    | |                |   
  \      |      |    \|           /    |    \__/  |                |   
   \     |     /      \          / RC2 |     \    |                |   
    \  __|__  / |     |\ A3  ___/      |      \   \----------------/   
     \|     |/   A-links\__ /   \      |       \  _____| STP
|___|_____|____| SEP |     |        \                      
      |_____|         |     \___/      |         \                     
                |     |A4              |       1 Association           
                      |    5.255.2     |                               
                |     |                |                               
                      |                |                               
                |     \----------------/                               
                                                                       
                |                                                      
           Demarcation                                                 

Same example as my other note, but no gateway screening.

We lose A-links A1 and A2.  If we send DUNA(-1) to the ASP, we lose both
point codes.  If don't send DUNA(-1) to the ASP, but try to reroute traffic
via A-Links A3 and A4 then, even without GWS we have a problem.  We can send
MSUs from 5.255.1 to the network, but the network will not send MSUs *to*
5.255.1.  This is because the STPs have already broadcasted TFP(5.255.1) to
the network because A-links A1 and A2 were the networks only route to SEP
5.255.1.
(These are A-links remember.)

As a matter of fact, the STPs will also send TFP(5.255.1) to SEP 5.255.2.
and the ASP will receive DUNA(5.255.1) stopping AS2 from routing traffic
through the SG to AS1.

This is completely unworkable.  The simple solution is to replace Network
Apperance with Routing Context in the SNMM and XFER messages.

--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: Mon, 30 Jul 2001 14:03:10 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: FW: M3UA: Routing Context
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-212.dallas.net [209.44.42.212]
List-Unsubscribe: <mailto:[email-masked]>

John,

Please see comments inline....

John Schantz wrote:                                          (Mon, 30 Jul
2001 10:48:46)
> 
> mailer must have ate the first one sent.
> 
> -----Original Message-----
> From: Schantz, John 
> Sent: Monday, July 30, 2001 10:20 AM
> To: [email-masked]'
> Subject: RE: M3UA: Routing Context
> 
> 
> Brian,
> 
> 	Comments below.
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 6:55 PM
> To: sigtran
> Subject: Re: M3UA: Routing Context
> 
> 
> John,
> 
> I'm glad you broght this up.  Let me just modify your diagram
> slightly and we can move to the next level:
> 
>                             _________  
>                            (   Sub   ) 
>                      _____(  Network  )_____
>      5.255.3        /     (     A     )     \       _________
>    +----------+    /       (_________)       \     (         )
>    |          |___/                           \___(  Network  )
>    | SS7 node |___                             ___(     Y     )
>    |    S     |   \         _________         /    (_________)
>    +----------+    \       (   Sub   )       /
>      5.255.4        \_____(  Network  )_____/
>                           (     B     )
>                            (_________) 
> 
> The SS7 node S has two point codes (5.255.3 and 5.255.4) in Network Y
> which are attached by subnetworks A and B which are disjoint at S.  One
> is, say, a point code S uses to connect to SNET, the other is used to
> connect to AT&T.  They both belong to the same SS7 point code
> administrative domain.  (That is, they both have the same Network Id.)
> 
> [John]  SNET and AT&T is a bad example.  BUT this might occur if node S
has
> reached the 16 link per linkset limit in SS7.  Point codes 5.255.3 and
> 5.255.4 are physical point codes (Note, very few nodes, if any, can do
this
> at the moment).  In this situation, node S maintains an internal network
ID
> (network appearance?) for its multiple connections to network Y.  This all
> that it needs.

Yes, and it needs 1 Network Appearance per point code.  Thus the proposal to
embed point code in Network Apperance and be done with it.

> 
> Following your diagrams through...
>                                                               5.255.5
>                                                               ________ 
>                                                              |        |
>                     +--------+        _________              |  Node  |
>                     |        |       (   Sub   )             |    X   |
>                     |        |______(  Network  )_____       |________|
>      5.255.3        |        |      (     A     )     X       ____|____
>    +----------+     |        |       (_________)       X     (         )
>    |          |     |        |                          X___(  Network  )
>    | SS7 node |-----|   SG   |                           ___(     Y     )
>    |    S     |     |        |        _________         /    (_________)
>    +----------+     |        |       (   Sub   )       /
>      5.255.4        |        |______(  Network  )_____/
>                     |        |      (     B     )
>                     |        |       (_________)
>                     +--------+
> 
> Because, as shown, point code X can be inaccessible from 5.255.3, but
> can still be accessible from 5.255.4, these two point codes within the
> same network need different Network Appearances to distinguish for which
> point code the DUNA(X) applies.  If each SPMC behind the SG has its own
> physical routes (links) to the SS7 network on the SS7 side of the SG,
> each will need its own Network Appearance to distinguish signalling
> network management menssages which are destined to it alone.
> 
> [John]  You skipped a figure but lets fill in come of the gaps.  There are
> network appearances (network IDs) assigned for network A connection and
> network B connection. ...

There is only one Network Id.  These are subnetworks of the same network.

> ... Since node X is unavailable on the network A, a TFP
> from the network A is sent to the SG.  Also note that node S and the SG
are
> handling networks A & B as INDEPENDENT networks and separate networks.
> Since the SG can not reach node X from network A, it passes on a DUNA that
> must contain the network appearance (network ID) for network A.  This is
all
> that node S needs to mark node X from network A prohibited.

But these subnetwork have the same Network Id and point code structure.
This is not the Network Appearance == Network Id situation.

> 
> If the Routing Context for these point codes is the "whole" point code,
> then each point codes requires both a Unique Routing Context and a
> Unique Network Appearace.  Thus, Routing Context == Network Appearance.
> 
> [John]  No, the routing context == network appearance + point code, but
> these are derived from the network appearance parameter and the affect
point
> code parameter in the DUNA message.  A separate routing context parameter
is
> NOT needed, it is excess baggage especially if there are multiple nodes
> contained in the DUNA.  Note, we need to clearly identify the affected
point
> codes.  I view routing context as a forward routing concept, not an
> originating or affected point code.  By the way, DUNAs should be "clean",
> i.e., should only contain affected point codes from one network
(connection
> in this case, network A).  

They also need to contain implicit information about the concerned point
code.  TFPs have both OPC and DPC in the message.

> 
> Plus, as above, one Network Appearance can be required for each point
> code, not each Network Id, as it might appear.  (Even if, as shown, the
> point codes are even in the same block!) Because Routing Context is
> already assigned on an MTP-User basis at the ASP, it uniquely determines
> which MTP-User at the ASP to which the DUNA message applies.  There is
> no need for messing around with Network Appearances.  Just use the
> Routing Context.  The Routing Context is required for other purposes
> anyway (it uniquely identifies an Application Server and a Routing Key).
> 
> [John]  NO, I do not agree.  Only a single network appearance per network
> connection is needed.  The single network appearance is all that is needed
> to clearly identify the point codes and to what network they belong.

See above.

--brian

> 
> --brian
> 
> 
> 
> 
> > In this case Node S and the SG must share an agreed to "network
> appearance"
> > for each network that is involved (Network A & B).  I assume that this
> will
> > be network operator assigned (network operator that owns Node S and SG).
> > This will take care of the messaging and the network management. But
what
> is
> > the basis for creating the connection between Node S and the SG.  It was
> the
> 
> Schantz, John wrote:                                     (Fri, 27 Jul 2001
> 12:44:42)
> > Brian,
> > 
> > I think you need to step back for a moment and re-examine what you are
> > trying to solve.  I think you are trying to solve the case where an SS7
> node
> > wants to have an appearance in more than one network, hence, the concept
> of
> > MTP-SAP.  But in your case you want all traffic to flow through the same
> > signalling path to the node.
> > 
> > Below is the SS7 scenario:
> >                               _________
> >                              (         )
> >                        _____(  Network  )
> >                       /     (     A     )
> >      +----------+    /       (_________)
> >      |          |___/
> >      | SS7 node |___
> >      |    S     |   \         _________
> >      +----------+    \       (         )
> >                       \_____(  Network  )
> >                             (     B     )
> >                              (_________)
> > 
> > Node S has separate links to Networks A & B.  Node S is identified by a
> > point code from each network, for now lets call them, x (from Network A)
> and
> > y (from Network B).  The MTP-SAP concept was added (a local concept)
where
> > node S had to associate a network ID to Networks A & B, lets use A & B
as
> > the Network IDs.  Hence, node S has to mark each message received with a
> > Network ID of A or B, based on the network it was received from.
Outbound
> > messages from the MTP-users also had to be marked with a network ID.
> > Logically, Node S could be viewed as have 2 SCCP/MTP protocol stacks.
The
> > network ID is used to discriminate which protocol stack handles which
> > message.  
> > 
> > For an applications point-of-view (SSN), the easy case is when the
message
> > being sent is a reply, i.e., given the same network ID as the received
> > message.  If the message is being generated from the application, the
> > application would need to know which network it was destined for and
mark
> > it.
> > 
> > Hence, Network ID + point code uniquely identified the destination.  The
> > network ID is used to select the protocol stack/links belonging a
specific
> > network, and the PC to select the correct route to that network.
> > 
> > This same picture can be moved over to the SS7 over IP case.  If Node S
> has
> > separate connections to the different networks, it must locally keep
track
> > of the networks.  The SGs that it connects to do not have to be
involved.
> > 
> > Now what about the picture where you have the SGs connecting to the
> > different networks.  There are 2 cases in this situation: 1) traffic is
> > separated and 2) traffic is merged.  
> > 
> > Traffic is Separated:  The traffic could be kept separate by having Node
S
> > establish connections to the different "sides" of the SG.  This would be
> in
> > line with the SS7 rules that the SG would have present a different
> > "appearance", actually a physical point code, for each network
> represented.
> > Look at the figure below:
> > 
> >                           +--------+        _________
> >                           |+------+|       (         )
> >                        ___||  SG  ||______(  Network  )
> >                       /   ||   A  ||      (     A     )
> >      +----------+    /    |+------+|       (_________)
> >      |          |___/     |        |
> >      | SS7 node |___      |   SG   |
> >      |    S     |   \     |        |        _________
> >      +----------+    \    |+------+|       (         )
> >                       \___||  SG  ||______(  Network  )
> >                           ||   B  ||      (     B     )
> >                           |+------+|       (_________)
> >                           +--------+
> > 
> > The A-side of the SG and of Node S requires a point code from network A.
> > The B-side of the SG and of Node S requires a  point code from network
B.
> > Each node, S and SG, could internal keep track of the messages/networks
by
> > using their own network ID.  They could also agree (network operator
> option)
> > to use the "network appearance" parameter so that node S and SG (and
other
> > nodes) use a common ID for the networks.
> > 
> > Traffic is Merged:  IMHO, this is a more difficult case to visualize.
> Below
> > is a figure.
> > 
> >                           +--------+        _________
> >                           |        |       (         )
> >                           |        |______(  Network  )
> >                           |        |      (     A     )
> >      +----------+         |        |       (_________)
> >      |          |         |        |
> >      | SS7 node |---------|   SG   |
> >      |    S     |         |        |        _________
> >      +----------+         |        |       (         )
> >                           |        |______(  Network  )
> >                           |        |      (     B     )
> >                           |        |       (_________)
> >                           +--------+
> > 
> > In this case Node S and the SG must share an agreed to "network
> appearance"
> > for each network that is involved (Network A & B).  I assume that this
> will
> > be network operator assigned (network operator that owns Node S and SG).
> > This will take care of the messaging and the network management. But
what
> is
> > the basis for creating the connection between Node S and the SG.  It was
> the
> > adjacent physical point codes that both Node S and SG had (and must
still
> > have), but what is it now?  I will have to think on how to eliminate the
> > adjacent PC in this.
> > 
> > But I still conclude that all that is required is the "network
appearance"
> > defined as a network ID.
> > 
> > John
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Friday, July 27, 2001 4:24 AM
> > To: sigtran
> > Cc: Greg Sidebottom
> > Subject: Re: M3UA: Routing Context
> > 
> > 
> > John, Greg,
> > 
> > Some of these things aren't apparent until one tries to go
> > and build the thing.
> > 
> > Here is the problem:  architecturally, M3UA exports the
MTP-Provider/User
> > interface, like so:
> > 
> >                                                                 
> >                                                                 
> >                                    Application      Application 
> >                                     Server #2        Server #1  
> >                                    ___________      ___________ 
> >                                   |           |    |           |
> >                                   |   MTP     |    |   MTP     |
> >                                   |   User    |    |   User    |
> >                                   |           |    |           |
> >                                   |___________|    |___________|
> >                                      |     ^          |     ^   
> >                           __         |     |          |     |   
> >               ___________/__\_______/     /           |     |   
> >              /   _______|____|___________/            |     |   
> >             /   /       |    |                       /     /    
> >            /   /        |    |           __         /     /     
> >           /   / ________|____|______<___/__\_______/     /      
> >           |   |/   _____|____|______>__|____|___________/       
> >           |   /   /      \__/           \__/                    
> >           |  /|  /         \              \                     
> >           | / | /           \              \                    
> >           ||  ||             \              \                   
> >         __vv__||__         One SCTP       Routing               
> >        |          |       Association     Context               
> >        |          |                                             
> >        |   MTP    |                                             
> >        | Provider |                                             
> >        |          |                                             
> >        |          |                                             
> >        |__________|                                             
> >                                                                 
> >         Signalling                                              
> >          Gateway                                                
> >         (Process)                                               
> >                                                                 
> >                                                                 
> > Where, the MTP-SAP can be identified by the Routing Context.  The SG may
> > apply a "Routing Key" to find the MTP-SAP, but this is a function which
> > is performed *below* the MTP-User interface.  If M3UA would label all
> > messages with the Routing Context (where ambiguous, as shown), then
> > there would be no confusion as to which MTP-SAP is being used either for
> > outgoing or incoming messages.
> > 
> > For example, when the SG performs transfer-prohibited procedures and
> > discovers that an SPMC signalling point is prohibited off a routeset, it
> > informs the MTP-Users.  So, the MTP has a list of "Users" to which it
> > sends MTP-PAUSE primitives.  We have the same thing in the SG, a list
> > of routing contexts, each which represents an MTP-User bound to an
> > MTP-SAP.  So instead, of attaching a list of Routing Contexts to the
> > DUNA (or sending multiple DUNAs, each with its own routing context), we
> > are throwing up a DUNA with a "Network Appearance".  There are a number
> > of cases where the Network Appearance becomes ambiguous at the ASP
> > unless Network Appearance == Routing Context. (And then what is the
> > point of two names for the same thing?)
> > 
> > For the ASP -> SGP direction, consider that the MTP at the SG cannot
> > determine the origin of the message (i.e, which MTP-SAP the message came
> > from.)  There is nothing stopping AS#2 from placing an OPC/SI in the
> > message which doesn't belong to it.  In fact, the MTP-User should not
> > even be putting the OPC/SI in the message: the SG should do this on the
> > basis of the DPC key associated with the Routing Context.  I don't think
> > that the SG should just blindly route messages based on DPC without any
> > screening whatsoever.
> > 
> > Now, I am fully aware that you do not believe in MTP-SAPs which are not
> > the "whole" point code.  But in the case where routing keys are "whole"
> > point codes, Network Appearance == Routing Context.  For sub-point code
> > MTP-SAPs (e.g., ISUP goes to AS#1, SCCP to AS#2), AS#1 needs to be
> > screened off of placing a non-ISUP SI in the routing label, and not
> > using its own point code.  AS#1 needs to have messages screend by
> > DPC as well unless one wants to try to replicate gateway screening above
> > the MTP-User interface.
> > 
> > So, John, you should not care if Network Appearance is replaced with
> > Routing Context, because in your case Network Appearance == Routing
> > Context, even though you don't see the need, because it is not
> > applicable in your cases.
> > 
> > --brian
> > 
> > 
> > 
> > Schantz, John wrote:                        (Mon, 23 Jul 2001 13:04:29)
> > > Brian,
> > > 	This doesn't really make any sense and I don't see the need.
> > > 
> > > 	Why would you need a routing context in a DATA from SGP to ASP.  The
> > > ASP should be determining where the message goes locally in the AS(s)
> > based
> > > on parameters from the SS7 message.
> > > 
> > > 	Requiring it in the DATA from the AS to SG doesn't make any sense.
> > > The SG should be determining how to forward route the message based on
> the
> > > SS7 message parameters (Routing Label).  Why would the responding AS
> even
> > > know the RC of a remote node.  Or are you proposing that a backward RC
> be
> > > included.  Forward routing should not be based on backward
information.
> > > 
> > > 	Hence, the answer to your question of whether there is an objection
> > > to including the RC in the DATA message, YES I object.
> > > 
> > > John
> > > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Monday, July 23, 2001 6:07 AM
> > > To: sigtran
> > > Cc: Greg Sidebottom
> > > Subject: M3UA: Routing Context
> > > 
> > > 
> > > Greg,
> > > 
> > > I would like to propose that the Routing Context be added as an
> > > optional parameter to which SHOULD be included in the DATA
> > > messages from the SGP and MUST be included in DATA messages from
> > > the ASP when the ASP is active for more than one Application
> > > Server.
> > > 
> > > This is *not* a replace-Network-Appearance-with-Routing-
> > > Context-proposal.
> > > 
> > > The purpose of adding RC to DATA messages is to distinguish
> > > multiple traffic flows which are multiplexed over the
> > > association for use in:
> > > 
> > >     o   demultiplexing data traffic at the ASP without having to
> > > 	reapply the Routing Key to each message to determine
> > > 	routing context,
> > > 
> > >     o   distinguishing traffic flows for discarding data
> > >         messages during ASPAC and ASPIA procedures, both at
> > > 	the SG and the ASP (again without having to reapply
> > > 	the Routing Key to each message at each end),
> > > 
> > >     o   demultiplexing buffered data messages at the ASP and the
> > >         SG during failover or AS-PENDING, again, without having
> > > 	to reapply a complex Routing Key.
> > > 
> > >     o   assists in diagnostics by permitting monitoring
> > >         equipment to at least distinguish traffic flows without
> > > 	having to provision monitoring equipment with routing
> > > 	keys.
> > > 
> > > It sure simplifies a lot of places in the implementation where
> > > one would have to otherwise reapply the routing key.
> > > 
> > > I should point out that, for some routing keys (e.g, SCCP SSN)
> > > it is currently impossible for the SGP to distinguish between AS
> > > for *incoming* traffic when there are multiple AS on an
> > > association.  This is because the Routing Key-->Routing
> > > Context-->AS mapping is only valid for traffic from the SGP
> > > towards the ASP.
> > > 
> > > Any objections to including RC in DATA messages?
> > > 
> > > --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]
> > > 
> > > 
> > > ---
> > > 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]
> 
> -- 
> 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]

-- 
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: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: FW: M3UA: Routing Context
Date: Mon, 30 Jul 2001 12:48:04 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: ztxmail04.ztx.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ztxmail04.ztx.compaq.com [161.114.1.208]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

See comments below.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Monday, July
30, 2001 2:03 PM
To: sigtran
Subject: Re: FW: M3UA: Routing Context

John,

Please see comments inline....

John Schantz wrote:                                          (Mon, 30 Jul
2001 10:48:46)
> 
> mailer must have ate the first one sent.
> 
> -----Original Message-----
> From: Schantz, John 
> Sent: Monday, July 30, 2001 10:20 AM
> To: [email-masked]'
> Subject: RE: M3UA: Routing Context
> 
> 
> Brian,
> 
> 	Comments below.
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 6:55 PM
> To: sigtran
> Subject: Re: M3UA: Routing Context
> 
> 
> John,
> 
> I'm glad you broght this up.  Let me just modify your diagram
> slightly and we can move to the next level:
> 
>                             _________  
>                            (   Sub   ) 
>                      _____(  Network  )_____
>      5.255.3        /     (     A     )     \       _________
>    +----------+    /       (_________)       \     (         )
>    |          |___/                           \___(  Network  )
>    | SS7 node |___                             ___(     Y     )
>    |    S     |   \         _________         /    (_________)
>    +----------+    \       (   Sub   )       /
>      5.255.4        \_____(  Network  )_____/
>                           (     B     )
>                            (_________) 
> 
> The SS7 node S has two point codes (5.255.3 and 5.255.4) in Network Y
> which are attached by subnetworks A and B which are disjoint at S.  One
> is, say, a point code S uses to connect to SNET, the other is used to
> connect to AT&T.  They both belong to the same SS7 point code
> administrative domain.  (That is, they both have the same Network Id.)
> 
> [John]  SNET and AT&T is a bad example.  BUT this might occur if node S
has
> reached the 16 link per linkset limit in SS7.  Point codes 5.255.3 and
> 5.255.4 are physical point codes (Note, very few nodes, if any, can do
this
> at the moment).  In this situation, node S maintains an internal network
ID
> (network appearance?) for its multiple connections to network Y.  This all
> that it needs.

Yes, and it needs 1 Network Appearance per point code.  Thus the proposal to
embed point code in Network Apperance and be done with it.

[John2]  NO, it requires two network IDs internal to Node S to keep the
network connections separate so that the node can support 2 - 16 link
linksets.  This is a real scenario.

> 
> Following your diagrams through...
>                                                               5.255.5
>                                                               ________ 
>                                                              |        |
>                     +--------+        _________              |  Node  |
>                     |        |       (   Sub   )             |    X   |
>                     |        |______(  Network  )_____       |________|
>      5.255.3        |        |      (     A     )     X       ____|____
>    +----------+     |        |       (_________)       X     (         )
>    |          |     |        |                          X___(  Network  )
>    | SS7 node |-----|   SG   |                           ___(     Y     )
>    |    S     |     |        |        _________         /    (_________)
>    +----------+     |        |       (   Sub   )       /
>      5.255.4        |        |______(  Network  )_____/
>                     |        |      (     B     )
>                     |        |       (_________)
>                     +--------+
> 
> Because, as shown, point code X can be inaccessible from 5.255.3, but
> can still be accessible from 5.255.4, these two point codes within the
> same network need different Network Appearances to distinguish for which
> point code the DUNA(X) applies.  If each SPMC behind the SG has its own
> physical routes (links) to the SS7 network on the SS7 side of the SG,
> each will need its own Network Appearance to distinguish signalling
> network management menssages which are destined to it alone.
> 
> [John]  You skipped a figure but lets fill in come of the gaps.  There are
> network appearances (network IDs) assigned for network A connection and
> network B connection. ...

There is only one Network Id.  These are subnetworks of the same network.

[John2]  NO, if this is the continuation of the first figure, a network ID
is for each connection since they are maintained separately.  If they are
not then, node does not have 2 point codes and it does not care if the SG is
communicating via sub-networks A & B.  The SG should not and does not need
to send a DUNA since it can reach node X via sub-network B. 

> ... Since node X is unavailable on the network A, a TFP
> from the network A is sent to the SG.  Also note that node S and the SG
are
> handling networks A & B as INDEPENDENT networks and separate networks.
> Since the SG can not reach node X from network A, it passes on a DUNA that
> must contain the network appearance (network ID) for network A.  This is
all
> that node S needs to mark node X from network A prohibited.

But these subnetwork have the same Network Id and point code structure.
This is not the Network Appearance == Network Id situation.

[John2]  Oh yes it is, if it was done for capacity reasons.  Also this is
very real for ITU networks because of their limited point code addressing
ability.  Why do you think the ITU introduced the MTP-SAP and SCCP-SAP
concept?  That is because each ITU network must use the same addresses that
his neighbor is using, hence, a network ID (SAP) had to be introduced for a
node sitting on these networks could keep the traffic separate.  If SS7
could keep things straight with network IDs why can't M3UA??????

> 
> If the Routing Context for these point codes is the "whole" point code,
> then each point codes requires both a Unique Routing Context and a
> Unique Network Appearace.  Thus, Routing Context == Network Appearance.
> 
> [John]  No, the routing context == network appearance + point code, but
> these are derived from the network appearance parameter and the affect
point
> code parameter in the DUNA message.  A separate routing context parameter
is
> NOT needed, it is excess baggage especially if there are multiple nodes
> contained in the DUNA.  Note, we need to clearly identify the affected
point
> codes.  I view routing context as a forward routing concept, not an
> originating or affected point code.  By the way, DUNAs should be "clean",
> i.e., should only contain affected point codes from one network
(connection
> in this case, network A).  

They also need to contain implicit information about the concerned point
code.  TFPs have both OPC and DPC in the message.

[John2]  Having a network appearance (== network ID) helps but I would like
to see the OPC and DPC in the DUNA/DAVA/...  If we have the network
appearance (== network ID) we can at least derive what the DPC from the
point code that the node has for the network connection.  We can derive the
OPC from the point code of the SG that we know that that network connection
has.  In your hurry to make things better, you have made things worse. 

> 
> Plus, as above, one Network Appearance can be required for each point
> code, not each Network Id, as it might appear.  (Even if, as shown, the
> point codes are even in the same block!) Because Routing Context is
> already assigned on an MTP-User basis at the ASP, it uniquely determines
> which MTP-User at the ASP to which the DUNA message applies.  There is
> no need for messing around with Network Appearances.  Just use the
> Routing Context.  The Routing Context is required for other purposes
> anyway (it uniquely identifies an Application Server and a Routing Key).
> 
> [John]  NO, I do not agree.  Only a single network appearance per network
> connection is needed.  The single network appearance is all that is needed
> to clearly identify the point codes and to what network they belong.

See above.

--brian

> 
> --brian
> 
> 
> 
> 
> > In this case Node S and the SG must share an agreed to "network
> appearance"
> > for each network that is involved (Network A & B).  I assume that this
> will
> > be network operator assigned (network operator that owns Node S and SG).
> > This will take care of the messaging and the network management. But
what
> is
> > the basis for creating the connection between Node S and the SG.  It was
> the
> 
> Schantz, John wrote:                                     (Fri, 27 Jul 2001
> 12:44:42)
> > Brian,
> > 
> > I think you need to step back for a moment and re-examine what you are
> > trying to solve.  I think you are trying to solve the case where an SS7
> node
> > wants to have an appearance in more than one network, hence, the concept
> of
> > MTP-SAP.  But in your case you want all traffic to flow through the same
> > signalling path to the node.
> > 
> > Below is the SS7 scenario:
> >                               _________
> >                              (         )
> >                        _____(  Network  )
> >                       /     (     A     )
> >      +----------+    /       (_________)
> >      |          |___/
> >      | SS7 node |___
> >      |    S     |   \         _________
> >      +----------+    \       (         )
> >                       \_____(  Network  )
> >                             (     B     )
> >                              (_________)
> > 
> > Node S has separate links to Networks A & B.  Node S is identified by a
> > point code from each network, for now lets call them, x (from Network A)
> and
> > y (from Network B).  The MTP-SAP concept was added (a local concept)
where
> > node S had to associate a network ID to Networks A & B, lets use A & B
as
> > the Network IDs.  Hence, node S has to mark each message received with a
> > Network ID of A or B, based on the network it was received from.
Outbound
> > messages from the MTP-users also had to be marked with a network ID.
> > Logically, Node S could be viewed as have 2 SCCP/MTP protocol stacks.
The
> > network ID is used to discriminate which protocol stack handles which
> > message.  
> > 
> > For an applications point-of-view (SSN), the easy case is when the
message
> > being sent is a reply, i.e., given the same network ID as the received
> > message.  If the message is being generated from the application, the
> > application would need to know which network it was destined for and
mark
> > it.
> > 
> > Hence, Network ID + point code uniquely identified the destination.  The
> > network ID is used to select the protocol stack/links belonging a
specific
> > network, and the PC to select the correct route to that network.
> > 
> > This same picture can be moved over to the SS7 over IP case.  If Node S
> has
> > separate connections to the different networks, it must locally keep
track
> > of the networks.  The SGs that it connects to do not have to be
involved.
> > 
> > Now what about the picture where you have the SGs connecting to the
> > different networks.  There are 2 cases in this situation: 1) traffic is
> > separated and 2) traffic is merged.  
> > 
> > Traffic is Separated:  The traffic could be kept separate by having Node
S
> > establish connections to the different "sides" of the SG.  This would be
> in
> > line with the SS7 rules that the SG would have present a different
> > "appearance", actually a physical point code, for each network
> represented.
> > Look at the figure below:
> > 
> >                           +--------+        _________
> >                           |+------+|       (         )
> >                        ___||  SG  ||______(  Network  )
> >                       /   ||   A  ||      (     A     )
> >      +----------+    /    |+------+|       (_________)
> >      |          |___/     |        |
> >      | SS7 node |___      |   SG   |
> >      |    S     |   \     |        |        _________
> >      +----------+    \    |+------+|       (         )
> >                       \___||  SG  ||______(  Network  )
> >                           ||   B  ||      (     B     )
> >                           |+------+|       (_________)
> >                           +--------+
> > 
> > The A-side of the SG and of Node S requires a point code from network A.
> > The B-side of the SG and of Node S requires a  point code from network
B.
> > Each node, S and SG, could internal keep track of the messages/networks
by
> > using their own network ID.  They could also agree (network operator
> option)
> > to use the "network appearance" parameter so that node S and SG (and
other
> > nodes) use a common ID for the networks.
> > 
> > Traffic is Merged:  IMHO, this is a more difficult case to visualize.
> Below
> > is a figure.
> > 
> >                           +--------+        _________
> >                           |        |       (         )
> >                           |        |______(  Network  )
> >                           |        |      (     A     )
> >      +----------+         |        |       (_________)
> >      |          |         |        |
> >      | SS7 node |---------|   SG   |
> >      |    S     |         |        |        _________
> >      +----------+         |        |       (         )
> >                           |        |______(  Network  )
> >                           |        |      (     B     )
> >                           |        |       (_________)
> >                           +--------+
> > 
> > In this case Node S and the SG must share an agreed to "network
> appearance"
> > for each network that is involved (Network A & B).  I assume that this
> will
> > be network operator assigned (network operator that owns Node S and SG).
> > This will take care of the messaging and the network management. But
what
> is
> > the basis for creating the connection between Node S and the SG.  It was
> the
> > adjacent physical point codes that both Node S and SG had (and must
still
> > have), but what is it now?  I will have to think on how to eliminate the
> > adjacent PC in this.
> > 
> > But I still conclude that all that is required is the "network
appearance"
> > defined as a network ID.
> > 
> > John
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Friday, July 27, 2001 4:24 AM
> > To: sigtran
> > Cc: Greg Sidebottom
> > Subject: Re: M3UA: Routing Context
> > 
> > 
> > John, Greg,
> > 
> > Some of these things aren't apparent until one tries to go
> > and build the thing.
> > 
> > Here is the problem:  architecturally, M3UA exports the
MTP-Provider/User
> > interface, like so:
> > 
> >                                                                 
> >                                                                 
> >                                    Application      Application 
> >                                     Server #2        Server #1  
> >                                    ___________      ___________ 
> >                                   |           |    |           |
> >                                   |   MTP     |    |   MTP     |
> >                                   |   User    |    |   User    |
> >                                   |           |    |           |
> >                                   |___________|    |___________|
> >                                      |     ^          |     ^   
> >                           __         |     |          |     |   
> >               ___________/__\_______/     /           |     |   
> >              /   _______|____|___________/            |     |   
> >             /   /       |    |                       /     /    
> >            /   /        |    |           __         /     /     
> >           /   / ________|____|______<___/__\_______/     /      
> >           |   |/   _____|____|______>__|____|___________/       
> >           |   /   /      \__/           \__/                    
> >           |  /|  /         \              \                     
> >           | / | /           \              \                    
> >           ||  ||             \              \                   
> >         __vv__||__         One SCTP       Routing               
> >        |          |       Association     Context               
> >        |          |                                             
> >        |   MTP    |                                             
> >        | Provider |                                             
> >        |          |                                             
> >        |          |                                             
> >        |__________|                                             
> >                                                                 
> >         Signalling                                              
> >          Gateway                                                
> >         (Process)                                               
> >                                                                 
> >                                                                 
> > Where, the MTP-SAP can be identified by the Routing Context.  The SG may
> > apply a "Routing Key" to find the MTP-SAP, but this is a function which
> > is performed *below* the MTP-User interface.  If M3UA would label all
> > messages with the Routing Context (where ambiguous, as shown), then
> > there would be no confusion as to which MTP-SAP is being used either for
> > outgoing or incoming messages.
> > 
> > For example, when the SG performs transfer-prohibited procedures and
> > discovers that an SPMC signalling point is prohibited off a routeset, it
> > informs the MTP-Users.  So, the MTP has a list of "Users" to which it
> > sends MTP-PAUSE primitives.  We have the same thing in the SG, a list
> > of routing contexts, each which represents an MTP-User bound to an
> > MTP-SAP.  So instead, of attaching a list of Routing Contexts to the
> > DUNA (or sending multiple DUNAs, each with its own routing context), we
> > are throwing up a DUNA with a "Network Appearance".  There are a number
> > of cases where the Network Appearance becomes ambiguous at the ASP
> > unless Network Appearance == Routing Context. (And then what is the
> > point of two names for the same thing?)
> > 
> > For the ASP -> SGP direction, consider that the MTP at the SG cannot
> > determine the origin of the message (i.e, which MTP-SAP the message came
> > from.)  There is nothing stopping AS#2 from placing an OPC/SI in the
> > message which doesn't belong to it.  In fact, the MTP-User should not
> > even be putting the OPC/SI in the message: the SG should do this on the
> > basis of the DPC key associated with the Routing Context.  I don't think
> > that the SG should just blindly route messages based on DPC without any
> > screening whatsoever.
> > 
> > Now, I am fully aware that you do not believe in MTP-SAPs which are not
> > the "whole" point code.  But in the case where routing keys are "whole"
> > point codes, Network Appearance == Routing Context.  For sub-point code
> > MTP-SAPs (e.g., ISUP goes to AS#1, SCCP to AS#2), AS#1 needs to be
> > screened off of placing a non-ISUP SI in the routing label, and not
> > using its own point code.  AS#1 needs to have messages screend by
> > DPC as well unless one wants to try to replicate gateway screening above
> > the MTP-User interface.
> > 
> > So, John, you should not care if Network Appearance is replaced with
> > Routing Context, because in your case Network Appearance == Routing
> > Context, even though you don't see the need, because it is not
> > applicable in your cases.
> > 
> > --brian
> > 
> > 
> > 
> > Schantz, John wrote:                        (Mon, 23 Jul 2001 13:04:29)
> > > Brian,
> > > 	This doesn't really make any sense and I don't see the need.
> > > 
> > > 	Why would you need a routing context in a DATA from SGP to ASP.  The
> > > ASP should be determining where the message goes locally in the AS(s)
> > based
> > > on parameters from the SS7 message.
> > > 
> > > 	Requiring it in the DATA from the AS to SG doesn't make any sense.
> > > The SG should be determining how to forward route the message based on
> the
> > > SS7 message parameters (Routing Label).  Why would the responding AS
> even
> > > know the RC of a remote node.  Or are you proposing that a backward RC
> be
> > > included.  Forward routing should not be based on backward
information.
> > > 
> > > 	Hence, the answer to your question of whether there is an objection
> > > to including the RC in the DATA message, YES I object.
> > > 
> > > John
> > > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Monday, July 23, 2001 6:07 AM
> > > To: sigtran
> > > Cc: Greg Sidebottom
> > > Subject: M3UA: Routing Context
> > > 
> > > 
> > > Greg,
> > > 
> > > I would like to propose that the Routing Context be added as an
> > > optional parameter to which SHOULD be included in the DATA
> > > messages from the SGP and MUST be included in DATA messages from
> > > the ASP when the ASP is active for more than one Application
> > > Server.
> > > 
> > > This is *not* a replace-Network-Appearance-with-Routing-
> > > Context-proposal.
> > > 
> > > The purpose of adding RC to DATA messages is to distinguish
> > > multiple traffic flows which are multiplexed over the
> > > association for use in:
> > > 
> > >     o   demultiplexing data traffic at the ASP without having to
> > > 	reapply the Routing Key to each message to determine
> > > 	routing context,
> > > 
> > >     o   distinguishing traffic flows for discarding data
> > >         messages during ASPAC and ASPIA procedures, both at
> > > 	the SG and the ASP (again without having to reapply
> > > 	the Routing Key to each message at each end),
> > > 
> > >     o   demultiplexing buffered data messages at the ASP and the
> > >         SG during failover or AS-PENDING, again, without having
> > > 	to reapply a complex Routing Key.
> > > 
> > >     o   assists in diagnostics by permitting monitoring
> > >         equipment to at least distinguish traffic flows without
> > > 	having to provision monitoring equipment with routing
> > > 	keys.
> > > 
> > > It sure simplifies a lot of places in the implementation where
> > > one would have to otherwise reapply the routing key.
> > > 
> > > I should point out that, for some routing keys (e.g, SCCP SSN)
> > > it is currently impossible for the SGP to distinguish between AS
> > > for *incoming* traffic when there are multiple AS on an
> > > association.  This is because the Routing Key-->Routing
> > > Context-->AS mapping is only valid for traffic from the SGP
> > > towards the ASP.
> > > 
> > > Any objections to including RC in DATA messages?
> > > 
> > > --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]
> > > 
> > > 
> > > ---
> > > 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]
> 
> -- 
> 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]

-- 
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]
Reply-To: [email-masked]
From: Sandy Smart <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
Date: Mon, 30 Jul 2001 15:56:03 -0400
Organization: Cisco Systems
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIME-Autoconverted: from 8bit to quoted-printable by
rtp-msg-core-1.cisco.com 
                      id f6UK1v513233
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]>

Brian,

Are you suggesting to remove these possible routing keys entirely from the
draft or only from the dynamic registration section? They have existed in
the routing key overview section since early in its development so I'm
curious as to the objection late in the review process. M3UA is only using
them to make a routing decision and wouldn't it be up to the implementation
of the application at the ASP to handle the issues you describe?

Sandy

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Cc: "Greg Sidebottom" <[email-masked]>
Sent: Monday, July 30, 2001 11:17 AM
Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.

Greg,

I don't see that rational basis on which M3UA can apply routing keys based
on SCCP Subsystem number.  Can someone provide an example on just how this
was expected to work?  (Particularly how SCCP Management is handled and OMAP
SCCP Route Verification Tests.)  I think you need SUA here.

I propose that we strike SSN from the Routing Key in the REG REQ message.

Also, TCAP Transaction Id is used as an example of a Routing Key, although
there is no field for it in a REG REQ.  Distributing messages based on TCAP
Transaction Ids doesn't strike me as rational either.
I think you need TUA here.

I propose that we strike TCAP Transaction Id from the examples of Routing
Keys.

--Brian

--
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]
Date: Mon, 30 Jul 2001 14:59:22 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Network Appearance
X-SMTP-HELO: netmail2.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail2.alcatel.com [128.251.168.51]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Klaus,

I agree with you that the discussions are getting increasingly confusing.
This multiple networks business is getting increasingly confusing.  I look
at the SS7 side of an SG like an STP.  An STP connects to multiple networks
with no problems, so this must not be the problem trying to be solved.  

Given the above thought, I go to the next thought which is that perhaps an
attempt is being made to make the SG(STP) appear as if it belongs to
different networks rather than just one.  In such a case, the SG(STP) would
need to have a multiple unique point code for identifying itself, one for
each network that it belongs to.  In such a case, if I'm forwarding a
message to some other element such as an ASP, then I would need something
like an NA to represent each SS7 network to the ASPs. 
Doing this though would be a pain in the .... thought processs.

Jeff

"Gradischnig, Klaus" wrote:
> 
> All:
> 
> I am getting increasingly confused by this discussion on NA. However, just
> looking at its definition in M3UA08 alone would be enough to do the job:
> 
> "Network Appearance - The Network Appearance uniquely identifies an SS7
> entity (Point Code) into an SS7 network, as presented by the SG.  It is
> used for the purposes of logically separating the signalling traffic
> between the SG and the Application Server Processes over a common SCTP
> association.  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.  It is also necessary when an SG is
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> [KDG] This clearly says to me that I need an NA if and only if I have
> multiple networks. In this case I need an NA for every point code,
however.
> Why I would need this in the case of multiple networks only beats me.
[KDG]
> 
> 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.  An
> example is where an SG is logically partitioned to appear as an element
> in four separate national SS7 networks.  A Network Appearance
>                                          ^^^^^^^^^^^^^^^^^^^^
> implicitly defines the SS7 Point Code(s), Network Indicator and MTP3
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> protocol type/variant/version used within a separate SS7 network.
> 
> [KDG] In contrast, this last sentence now tells me that I need one and
only
> one
> NA for each network. This is at least something I understand and it
> corresponds
> to NA's original definition. [KDG]"
> 
> And while I can see where Brian's example below is coming from, I can't
> except his arguments:
> In the general case OPC specific screening cannot be handled by MTP
> network/route management functions and therefore OPC specific routing
cannot
> be supported without restrictions to either connectivity or network
> management functionality. The example might start making sense if the SG
> considered 5.255.3 and 5.255.4 to belong to "separate" networks using
> different routing tables in the SG. In this case the SG may have to have
> distinct point codes in these "separate" networks, provided then
"separate"
> networks are actually interconnected (seems not to be the case in this
> example, though).
> In any case, I fully support John's and Barry's view that NA identifies a
> network (albeit from an SG internal view) and not an SPMC.
> 
> I am -- on an abstract level -- rather concerned about the unnecessary
> complexity which has been introduced into m3ua and I have some indication
> that a number of operators and manufacturers share this view. How much of
> m3ua's functionality has actually been tested in Sophia? It seems to me
that
> without some extensive testing in a real or emulated SS7 network
environment
> going for last call is premature.
> 
> Klaus
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: July 30, 2001 1:09 PM
> > To: sigtran
> > Subject: Re: M3UA07: Network Appearance
> >
> >
> > John,
> >
> > Please see response inline...
> >
> > John Schantz wrote:                               (Mon, 30
> > Jul 2001 09:24:56)
> > > Brian,
> > >
> > >     NO, see response to "M3UA: Routing Context".  Only a
> > single network
> > > appearance is needed per network connection.
> > >
> > >     More comments below.
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Saturday, July 28, 2001 8:08 AM
> > > To: sigtran
> > > Subject: Re: M3UA07: Network Appearance
> > >
> > >
> > > John,
> > >
> > > Perhaps now you can see (from our discussion on the thread "M3UA:
> > > Routing Context") that to cover all configurations, a
> > Network Appearance
> > > valud is required per primary point code and network id,
> > and that this
> > > proposal was a natural extension of that fact.  Consider
> > the case below:
> > >
> > > [John] NO.
> > >
> >
> >
> >                            200.1.4    __________
> >                              ___     /          \     ___
> >                             /   \   |            |   /   \
> >                            | SEP |__|____________|__| SEP |  AS1
> >                             \___/   |            |   \___/
> >                            //       |            |
> >                           / |       | Signalling |  5.255.3
> >                          / /        |   Gateway  |
> >                         /  |        |            |
> >                        /  /         |            |
> >                _____  /   |         |            |
> >               |     |/   /          |            |
> >          -----| STP |____|__________|______      |
> >              /|_____|   /           |      \___  |  5.255.4
> >             /    |      |           |          \_|_   ___
> >          \ /     |     /            |            | \ /   \
> >           X      |     |            |            |  | SEP |  AS2
> >          / \     |    /             |           _|_/ \___/
> >             \  __|__ /              |       ___/ |
> >              \|     |_______________|______/     |       5.255.5
> >          -----| STP |               |            |       (alias)
> >               |_____|               |            |
> >                                     |            |
> >                                      \__________/
> >
> >
> > >
> > > The signalling gateway needs two different Network Appearance
> > > parameters: one per SPMC.  The bottom SPMC needs only one Network
> > > Appearance to cover both the primary point code 5.255.4 and
> > the alias
> > > point code 5.255.5 because they are both treated as the
> > same from an SS7
> > > newtork management view.
> > >
> > > [John]  NO.  Since a SINGLE network connection is in the
> > figure above, NO
> > > network appearance is needed at all.  What do you think the
> > point code is
> > > for??????  You seem to proposing that the network
> > appearance replace the
> > > point code for routing, NO.
> >
> > John, say I have one ASP serving two ASs and each AS serves
> > and entire SEP in
> > the diagram as labelled.  They are served over 1 association
> > to an ASP which
> > is configured and active for both ASs.  When the F-link fails
> > from the SG to
> > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
> > Without something
> > (Routing Context/Network Appearance) to distinguish the DUNA,
> > AS2 will also
> > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
> > 200.1.4 via
> > the STPs.
> >
> > If the SG does not send DUNA(200.1.4) but attempts to route
> > traffic from AS1
> > to 200.1.4 via the STPs, consider that STP Gateway Screening
> > may throw these
> > messages in the garbage because 5.255.4 and 5.255.5 are the
> > only point codes
> > allowed in the OPC on messages on the A-links.
> >
> > So, again, there are two choices:  Make Network Appearance an
> > identifier
> > of the SPMC and include it on all DUNA/DAVA/etc. where the ASP servers
> > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> >
> > >
> > > Now, in general, a rational basis for assigning Network
> > Apearance Id's
> > > is to use the Network Id and Point Code of the node (the
> > node *is* the
> > > network appearance).  Therefore, the DUNA, DAVA, etc. that
> > the SG sends
> > > concerning the SPMC will be properly distinguish.
> > >
> > > [John]  NO.  A single network appearance (== network ID) +
> > affected point
> > > code is all that is needed.
> > >
> > > Note that if the proposed assignment of Network Appearances is used,
> > > the SCON message no longer requires a Concerned Point Code parameter
> > > when the SPMC is signalling congestion to the SG.  It need only use
> > > the Network Appearance.
> > >
> > > [John] NO.
> > >
> > > The definition of a Network Appearance becomes
> > (effectively): "An unique
> > > identifier indicating the Signalling Point Management
> > Cluster (SPMC) to
> > > which Signalling Network Management Messages apply."
> > >
> > > [John]  NO.
> > >
> > > --Brian
> > >
> > >
> > > Schantz, John wrote:                         (Mon, 23 Jul
> > 2001 13:37:00)
> > > > Brian,
> > > >
> > > >   Why the need to include a concerned PC at all, the PC would be
> > > > redundant to the one in the DPC.  Why not let the network
> > appearance
> > > > parameter be equal to the Network ID (all 32 bits).  Then Network
> > > > Appearance(Network ID) + DPC will be unique and it will
> > separate out the
> > > > traffic into networks in both directions SG->AS and
> > AS->SG(-> and beyond).
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > To: sigtran
> > > > Cc: Greg Sidebottom
> > > > Subject: M3UA07: Network Appearance
> > > >
> > > >
> > > > Greg,
> > > >
> > > > When an SG is has multiple point codes serving ASPs which are
> > > > active in multiple SPMCs, it becomes necessary to label each
> > > > SPMC with a unique Network Appearance parameter to demultiplex
> > > > DUNA, DAVA, DRST and SCON.  Because a separate Network Appearance
> > > > assignment is necessary for each SPMC and the adminstration of
> > > > these assignments could get quite tedious for an SGP/ASP pool
> > > > representing a large number of point codes, I would like to
> > > > propose the following refinement to the Network Appearance
> > > > Parameter:
> > > >
> > > > (This is in fitting with the definition that a "Network Appearance
> > > uniquely
> > > > identifies an SS7 entity (Point Code) into an SS7 network.")
> > > >
> > > > The format of the Network Appearance parameter 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
> > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    |  Network Id   |            Concerned Point Code
> >          |
> > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >
> > > > Network Identifier: 8-bit (unsigned integer)
> > > >
> > > >    The Network Identifier identifies the network in which
> > the Concerned
> > > >    Point Code can be considered unique, and distinguishes
> > this Concerned
> > > >    Point Code from an identical point code in any another network.
> > > >    A Network Identifier identifying a specific
> > adminsitrative domain for
> > > >    the assignment of SS7 Signalling Point Codes MUST be
> > global to all
> > > >    SGPs in an SG.
> > > >
> > > > Concerned Point Code:
> > > >
> > > >    The Concerned Point Code identifies a point code within the
> > > >    administrative domain as indicated by the Network
> > Identifier.  The
> > > >    Concerned Point Code is the one point code of a
> > Signalling Point
> > > >    Management Cluster (SPMC) which needs to receive
> > updates concerning
> > > >    the accessibility/restriction/congestion status of
> > routesets from the
> > > >    SPMC.
> > > >
> > > >
> > > > 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]
> > > >
> > > >
> > > > ---
> > > > 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]
> >
> > --
> > 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] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\Jeff.Copley11.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 30 Jul 2001 15:17:22 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv8: SSN in Routing Key and TCAP TID in example.
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 
                      PAA02048
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-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Sandy,

They don't make sense.  For example, SCCP classes 2 and 3 have no SSN in
messages after the connection establishment phase.  So that means classes 2
and 3 are out.  Class 0 and 1 are connectionless and have SSN in the
message, but SCCP management messages are also sent Class 0 with SSN=0 and
needs to be sent to all concerned SCCP subsytems.  By the time your done
with this, you are doing SUA classes 0 and 1 anyways.  To get the class 2
and 3 support requires full blown SUA.

Note that SUA supports all the SNMM messages that M3UA does.  In effect, for
classes 0 and 1 they are very similar.

Unless someone can come up with a practical use for SSN routing keys in M3UA
I think that they make a bad example.

Why this late in the review process?  I commented on these before...
But in longer notes.

Transaction ID is absurd.  It makes a foolish example.

--brian

Sandy Smart wrote:                              (Mon, 30 Jul 2001 15:56:03)
> Brian,
> 
> Are you suggesting to remove these possible routing keys entirely from the
> draft or only from the dynamic registration section? They have existed in
> the routing key overview section since early in its development so I'm
> curious as to the objection late in the review process. M3UA is only using
> them to make a routing decision and wouldn't it be up to the
implementation
> of the application at the ASP to handle the issues you describe?
> 
> Sandy
> 
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Cc: "Greg Sidebottom" <[email-masked]>
> Sent: Monday, July 30, 2001 11:17 AM
> Subject: M3UAv8: SSN in Routing Key and TCAP TID in example.
> 
> 
> Greg,
> 
> I don't see that rational basis on which M3UA can apply routing keys
> based on SCCP Subsystem number.  Can someone provide an example on just
> how this was expected to work?  (Particularly how SCCP Management is
> handled and OMAP SCCP Route Verification Tests.)  I think you need SUA
> here.
> 
> I propose that we strike SSN from the Routing Key in the REG REQ
> message.
> 
> Also, TCAP Transaction Id is used as an example of a Routing Key,
> although there is no field for it in a REG REQ.  Distributing messages
> based on TCAP Transaction Ids doesn't strike me as rational either.
> I think you need TUA here.
> 
> I propose that we strike TCAP Transaction Id from the examples of
> Routing Keys.
> 
> --Brian
> 
> --
> 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]

-- 
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: Mon, 30 Jul 2001 15:23:23 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: FW: M3UA: Routing Context
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.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

I think that we are starting to agree (maybe not on terminology for Network
Id, but in that two Network Appearance values are required here).

So, a unique Network Appearance is required for each connection (combined
linkset) that the SG provides to any network.

I will number them with Network Id + the primary point code of the network
connection as proposed, you number them your way.

--Brian

John Schantz wrote:                            (Mon, 30 Jul 2001 12:48:04)
> Brian,
> 
> See comments below.
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, July 30, 2001 2:03 PM
> To: sigtran
> Subject: Re: FW: M3UA: Routing Context
> 
> 
> John,
> 
> Please see comments inline....
> 
> John Schantz wrote:                                          (Mon, 30 Jul
> 2001 10:48:46)
> > 
> > mailer must have ate the first one sent.
> > 
> > -----Original Message-----
> > From: Schantz, John 
> > Sent: Monday, July 30, 2001 10:20 AM
> > To: [email-masked]'
> > Subject: RE: M3UA: Routing Context
> > 
> > 
> > Brian,
> > 
> > 	Comments below.
> > 
> > John
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Friday, July 27, 2001 6:55 PM
> > To: sigtran
> > Subject: Re: M3UA: Routing Context
> > 
> > 
> > John,
> > 
> > I'm glad you broght this up.  Let me just modify your diagram
> > slightly and we can move to the next level:
> > 
> >                             _________  
> >                            (   Sub   ) 
> >                      _____(  Network  )_____
> >      5.255.3        /     (     A     )     \       _________
> >    +----------+    /       (_________)       \     (         )
> >    |          |___/                           \___(  Network  )
> >    | SS7 node |___                             ___(     Y     )
> >    |    S     |   \         _________         /    (_________)
> >    +----------+    \       (   Sub   )       /
> >      5.255.4        \_____(  Network  )_____/
> >                           (     B     )
> >                            (_________) 
> > 
> > The SS7 node S has two point codes (5.255.3 and 5.255.4) in Network Y
> > which are attached by subnetworks A and B which are disjoint at S.  One
> > is, say, a point code S uses to connect to SNET, the other is used to
> > connect to AT&T.  They both belong to the same SS7 point code
> > administrative domain.  (That is, they both have the same Network Id.)
> > 
> > [John]  SNET and AT&T is a bad example.  BUT this might occur if node S
> has
> > reached the 16 link per linkset limit in SS7.  Point codes 5.255.3 and
> > 5.255.4 are physical point codes (Note, very few nodes, if any, can do
> this
> > at the moment).  In this situation, node S maintains an internal network
> ID
> > (network appearance?) for its multiple connections to network Y.  This
all
> > that it needs.
> 
> Yes, and it needs 1 Network Appearance per point code.  Thus the
> proposal to embed point code in Network Apperance and be done with
> it.
> 
> [John2]  NO, it requires two network IDs internal to Node S to keep the
> network connections separate so that the node can support 2 - 16 link
> linksets.  This is a real scenario.
> 
> > 
> > Following your diagrams through...
> >                                                               5.255.5
> >                                                               ________ 
> >                                                              |        |
> >                     +--------+        _________              |  Node  |
> >                     |        |       (   Sub   )             |    X   |
> >                     |        |______(  Network  )_____       |________|
> >      5.255.3        |        |      (     A     )     X       ____|____
> >    +----------+     |        |       (_________)       X     (         )
> >    |          |     |        |                          X___(  Network
)
> >    | SS7 node |-----|   SG   |                           ___(     Y
)
> >    |    S     |     |        |        _________         /    (_________)
> >    +----------+     |        |       (   Sub   )       /
> >      5.255.4        |        |______(  Network  )_____/
> >                     |        |      (     B     )
> >                     |        |       (_________)
> >                     +--------+
> > 
> > Because, as shown, point code X can be inaccessible from 5.255.3, but
> > can still be accessible from 5.255.4, these two point codes within the
> > same network need different Network Appearances to distinguish for which
> > point code the DUNA(X) applies.  If each SPMC behind the SG has its own
> > physical routes (links) to the SS7 network on the SS7 side of the SG,
> > each will need its own Network Appearance to distinguish signalling
> > network management menssages which are destined to it alone.
> > 
> > [John]  You skipped a figure but lets fill in come of the gaps.  There
are
> > network appearances (network IDs) assigned for network A connection and
> > network B connection. ...
> 
> There is only one Network Id.  These are subnetworks of the same network.
> 
> [John2]  NO, if this is the continuation of the first figure, a network ID
> is for each connection since they are maintained separately.  If they are
> not then, node does not have 2 point codes and it does not care if the SG
is
> communicating via sub-networks A & B.  The SG should not and does not need
> to send a DUNA since it can reach node X via sub-network B. 
> 
> > ... Since node X is unavailable on the network A, a TFP
> > from the network A is sent to the SG.  Also note that node S and the SG
> are
> > handling networks A & B as INDEPENDENT networks and separate networks.
> > Since the SG can not reach node X from network A, it passes on a DUNA
that
> > must contain the network appearance (network ID) for network A.  This is
> all
> > that node S needs to mark node X from network A prohibited.
> 
> But these subnetwork have the same Network Id and point code structure.
> This is not the Network Appearance == Network Id situation.
> 
> [John2]  Oh yes it is, if it was done for capacity reasons.  Also this is
> very real for ITU networks because of their limited point code addressing
> ability.  Why do you think the ITU introduced the MTP-SAP and SCCP-SAP
> concept?  That is because each ITU network must use the same addresses
that
> his neighbor is using, hence, a network ID (SAP) had to be introduced for
a
> node sitting on these networks could keep the traffic separate.  If SS7
> could keep things straight with network IDs why can't M3UA??????
> 
> > 
> > If the Routing Context for these point codes is the "whole" point code,
> > then each point codes requires both a Unique Routing Context and a
> > Unique Network Appearace.  Thus, Routing Context == Network Appearance.
> > 
> > [John]  No, the routing context == network appearance + point code, but
> > these are derived from the network appearance parameter and the affect
> point
> > code parameter in the DUNA message.  A separate routing context
parameter
> is
> > NOT needed, it is excess baggage especially if there are multiple nodes
> > contained in the DUNA.  Note, we need to clearly identify the affected
> point
> > codes.  I view routing context as a forward routing concept, not an
> > originating or affected point code.  By the way, DUNAs should be
"clean",
> > i.e., should only contain affected point codes from one network
> (connection
> > in this case, network A).  
> 
> They also need to contain implicit information about the concerned point
> code.  TFPs have both OPC and DPC in the message.
> 
> [John2]  Having a network appearance (== network ID) helps but I would
like
> to see the OPC and DPC in the DUNA/DAVA/...  If we have the network
> appearance (== network ID) we can at least derive what the DPC from the
> point code that the node has for the network connection.  We can derive
the
> OPC from the point code of the SG that we know that that network
connection
> has.  In your hurry to make things better, you have made things worse. 
> 
> > 
> > Plus, as above, one Network Appearance can be required for each point
> > code, not each Network Id, as it might appear.  (Even if, as shown, the
> > point codes are even in the same block!) Because Routing Context is
> > already assigned on an MTP-User basis at the ASP, it uniquely determines
> > which MTP-User at the ASP to which the DUNA message applies.  There is
> > no need for messing around with Network Appearances.  Just use the
> > Routing Context.  The Routing Context is required for other purposes
> > anyway (it uniquely identifies an Application Server and a Routing Key).
> > 
> > [John]  NO, I do not agree.  Only a single network appearance per
network
> > connection is needed.  The single network appearance is all that is
needed
> > to clearly identify the point codes and to what network they belong.
> 
> See above.
> 
> 
> --brian
> 
> > 
> > --brian
> > 
> > 
> > 
> > 
> > > In this case Node S and the SG must share an agreed to "network
> > appearance"
> > > for each network that is involved (Network A & B).  I assume that this
> > will
> > > be network operator assigned (network operator that owns Node S and
SG).
> > > This will take care of the messaging and the network management. But
> what
> > is
> > > the basis for creating the connection between Node S and the SG.  It
was
> > the
> > 
> > Schantz, John wrote:                                     (Fri, 27 Jul
2001
> > 12:44:42)
> > > Brian,
> > > 
> > > I think you need to step back for a moment and re-examine what you are
> > > trying to solve.  I think you are trying to solve the case where an
SS7
> > node
> > > wants to have an appearance in more than one network, hence, the
concept
> > of
> > > MTP-SAP.  But in your case you want all traffic to flow through the
same
> > > signalling path to the node.
> > > 
> > > Below is the SS7 scenario:
> > >                               _________
> > >                              (         )
> > >                        _____(  Network  )
> > >                       /     (     A     )
> > >      +----------+    /       (_________)
> > >      |          |___/
> > >      | SS7 node |___
> > >      |    S     |   \         _________
> > >      +----------+    \       (         )
> > >                       \_____(  Network  )
> > >                             (     B     )
> > >                              (_________)
> > > 
> > > Node S has separate links to Networks A & B.  Node S is identified by
a
> > > point code from each network, for now lets call them, x (from Network
A)
> > and
> > > y (from Network B).  The MTP-SAP concept was added (a local concept)
> where
> > > node S had to associate a network ID to Networks A & B, lets use A & B
> as
> > > the Network IDs.  Hence, node S has to mark each message received with
a
> > > Network ID of A or B, based on the network it was received from.
> Outbound
> > > messages from the MTP-users also had to be marked with a network ID.
> > > Logically, Node S could be viewed as have 2 SCCP/MTP protocol stacks.
> The
> > > network ID is used to discriminate which protocol stack handles which
> > > message.  
> > > 
> > > For an applications point-of-view (SSN), the easy case is when the
> message
> > > being sent is a reply, i.e., given the same network ID as the received
> > > message.  If the message is being generated from the application, the
> > > application would need to know which network it was destined for and
> mark
> > > it.
> > > 
> > > Hence, Network ID + point code uniquely identified the destination.
The
> > > network ID is used to select the protocol stack/links belonging a
> specific
> > > network, and the PC to select the correct route to that network.
> > > 
> > > This same picture can be moved over to the SS7 over IP case.  If Node
S
> > has
> > > separate connections to the different networks, it must locally keep
> track
> > > of the networks.  The SGs that it connects to do not have to be
> involved.
> > > 
> > > Now what about the picture where you have the SGs connecting to the
> > > different networks.  There are 2 cases in this situation: 1) traffic
is
> > > separated and 2) traffic is merged.  
> > > 
> > > Traffic is Separated:  The traffic could be kept separate by having
Node
> S
> > > establish connections to the different "sides" of the SG.  This would
be
> > in
> > > line with the SS7 rules that the SG would have present a different
> > > "appearance", actually a physical point code, for each network
> > represented.
> > > Look at the figure below:
> > > 
> > >                           +--------+        _________
> > >                           |+------+|       (         )
> > >                        ___||  SG  ||______(  Network  )
> > >                       /   ||   A  ||      (     A     )
> > >      +----------+    /    |+------+|       (_________)
> > >      |          |___/     |        |
> > >      | SS7 node |___      |   SG   |
> > >      |    S     |   \     |        |        _________
> > >      +----------+    \    |+------+|       (         )
> > >                       \___||  SG  ||______(  Network  )
> > >                           ||   B  ||      (     B     )
> > >                           |+------+|       (_________)
> > >                           +--------+
> > > 
> > > The A-side of the SG and of Node S requires a point code from network
A.
> > > The B-side of the SG and of Node S requires a  point code from network
> B.
> > > Each node, S and SG, could internal keep track of the
messages/networks
> by
> > > using their own network ID.  They could also agree (network operator
> > option)
> > > to use the "network appearance" parameter so that node S and SG (and
> other
> > > nodes) use a common ID for the networks.
> > > 
> > > Traffic is Merged:  IMHO, this is a more difficult case to visualize.
> > Below
> > > is a figure.
> > > 
> > >                           +--------+        _________
> > >                           |        |       (         )
> > >                           |        |______(  Network  )
> > >                           |        |      (     A     )
> > >      +----------+         |        |       (_________)
> > >      |          |         |        |
> > >      | SS7 node |---------|   SG   |
> > >      |    S     |         |        |        _________
> > >      +----------+         |        |       (         )
> > >                           |        |______(  Network  )
> > >                           |        |      (     B     )
> > >                           |        |       (_________)
> > >                           +--------+
> > > 
> > > In this case Node S and the SG must share an agreed to "network
> > appearance"
> > > for each network that is involved (Network A & B).  I assume that this
> > will
> > > be network operator assigned (network operator that owns Node S and
SG).
> > > This will take care of the messaging and the network management. But
> what
> > is
> > > the basis for creating the connection between Node S and the SG.  It
was
> > the
> > > adjacent physical point codes that both Node S and SG had (and must
> still
> > > have), but what is it now?  I will have to think on how to eliminate
the
> > > adjacent PC in this.
> > > 
> > > But I still conclude that all that is required is the "network
> appearance"
> > > defined as a network ID.
> > > 
> > > John
> > > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Friday, July 27, 2001 4:24 AM
> > > To: sigtran
> > > Cc: Greg Sidebottom
> > > Subject: Re: M3UA: Routing Context
> > > 
> > > 
> > > John, Greg,
> > > 
> > > Some of these things aren't apparent until one tries to go
> > > and build the thing.
> > > 
> > > Here is the problem:  architecturally, M3UA exports the
> MTP-Provider/User
> > > interface, like so:
> > > 
> > >                                                                 
> > >                                                                 
> > >                                    Application      Application 
> > >                                     Server #2        Server #1  
> > >                                    ___________      ___________ 
> > >                                   |           |    |           |
> > >                                   |   MTP     |    |   MTP     |
> > >                                   |   User    |    |   User    |
> > >                                   |           |    |           |
> > >                                   |___________|    |___________|
> > >                                      |     ^          |     ^   
> > >                           __         |     |          |     |   
> > >               ___________/__\_______/     /           |     |   
> > >              /   _______|____|___________/            |     |   
> > >             /   /       |    |                       /     /    
> > >            /   /        |    |           __         /     /     
> > >           /   / ________|____|______<___/__\_______/     /      
> > >           |   |/   _____|____|______>__|____|___________/       
> > >           |   /   /      \__/           \__/                    
> > >           |  /|  /         \              \                     
> > >           | / | /           \              \                    
> > >           ||  ||             \              \                   
> > >         __vv__||__         One SCTP       Routing               
> > >        |          |       Association     Context               
> > >        |          |                                             
> > >        |   MTP    |                                             
> > >        | Provider |                                             
> > >        |          |                                             
> > >        |          |                                             
> > >        |__________|                                             
> > >                                                                 
> > >         Signalling                                              
> > >          Gateway                                                
> > >         (Process)                                               
> > >                                                                 
> > >                                                                 
> > > Where, the MTP-SAP can be identified by the Routing Context.  The SG
may
> > > apply a "Routing Key" to find the MTP-SAP, but this is a function
which
> > > is performed *below* the MTP-User interface.  If M3UA would label all
> > > messages with the Routing Context (where ambiguous, as shown), then
> > > there would be no confusion as to which MTP-SAP is being used either
for
> > > outgoing or incoming messages.
> > > 
> > > For example, when the SG performs transfer-prohibited procedures and
> > > discovers that an SPMC signalling point is prohibited off a routeset,
it
> > > informs the MTP-Users.  So, the MTP has a list of "Users" to which it
> > > sends MTP-PAUSE primitives.  We have the same thing in the SG, a list
> > > of routing contexts, each which represents an MTP-User bound to an
> > > MTP-SAP.  So instead, of attaching a list of Routing Contexts to the
> > > DUNA (or sending multiple DUNAs, each with its own routing context),
we
> > > are throwing up a DUNA with a "Network Appearance".  There are a
number
> > > of cases where the Network Appearance becomes ambiguous at the ASP
> > > unless Network Appearance == Routing Context. (And then what is the
> > > point of two names for the same thing?)
> > > 
> > > For the ASP -> SGP direction, consider that the MTP at the SG cannot
> > > determine the origin of the message (i.e, which MTP-SAP the message
came
> > > from.)  There is nothing stopping AS#2 from placing an OPC/SI in the
> > > message which doesn't belong to it.  In fact, the MTP-User should not
> > > even be putting the OPC/SI in the message: the SG should do this on
the
> > > basis of the DPC key associated with the Routing Context.  I don't
think
> > > that the SG should just blindly route messages based on DPC without
any
> > > screening whatsoever.
> > > 
> > > Now, I am fully aware that you do not believe in MTP-SAPs which are
not
> > > the "whole" point code.  But in the case where routing keys are
"whole"
> > > point codes, Network Appearance == Routing Context.  For sub-point
code
> > > MTP-SAPs (e.g., ISUP goes to AS#1, SCCP to AS#2), AS#1 needs to be
> > > screened off of placing a non-ISUP SI in the routing label, and not
> > > using its own point code.  AS#1 needs to have messages screend by
> > > DPC as well unless one wants to try to replicate gateway screening
above
> > > the MTP-User interface.
> > > 
> > > So, John, you should not care if Network Appearance is replaced with
> > > Routing Context, because in your case Network Appearance == Routing
> > > Context, even though you don't see the need, because it is not
> > > applicable in your cases.
> > > 
> > > --brian
> > > 
> > > 
> > > 
> > > Schantz, John wrote:                        (Mon, 23 Jul 2001
13:04:29)
> > > > Brian,
> > > > 	This doesn't really make any sense and I don't see the need.
> > > > 
> > > > 	Why would you need a routing context in a DATA from SGP to
ASP.  The
> > > > ASP should be determining where the message goes locally in the
AS(s)
> > > based
> > > > on parameters from the SS7 message.
> > > > 
> > > > 	Requiring it in the DATA from the AS to SG doesn't make any
sense.
> > > > The SG should be determining how to forward route the message based
on
> > the
> > > > SS7 message parameters (Routing Label).  Why would the responding AS
> > even
> > > > know the RC of a remote node.  Or are you proposing that a backward
RC
> > be
> > > > included.  Forward routing should not be based on backward
> information.
> > > > 
> > > > 	Hence, the answer to your question of whether there is an
objection
> > > > to including the RC in the DATA message, YES I object.
> > > > 
> > > > John
> > > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Monday, July 23, 2001 6:07 AM
> > > > To: sigtran
> > > > Cc: Greg Sidebottom
> > > > Subject: M3UA: Routing Context
> > > > 
> > > > 
> > > > Greg,
> > > > 
> > > > I would like to propose that the Routing Context be added as an
> > > > optional parameter to which SHOULD be included in the DATA
> > > > messages from the SGP and MUST be included in DATA messages from
> > > > the ASP when the ASP is active for more than one Application
> > > > Server.
> > > > 
> > > > This is *not* a replace-Network-Appearance-with-Routing-
> > > > Context-proposal.
> > > > 
> > > > The purpose of adding RC to DATA messages is to distinguish
> > > > multiple traffic flows which are multiplexed over the
> > > > association for use in:
> > > > 
> > > >     o   demultiplexing data traffic at the ASP without having to
> > > > 	reapply the Routing Key to each message to determine
> > > > 	routing context,
> > > > 
> > > >     o   distinguishing traffic flows for discarding data
> > > >         messages during ASPAC and ASPIA procedures, both at
> > > > 	the SG and the ASP (again without having to reapply
> > > > 	the Routing Key to each message at each end),
> > > > 
> > > >     o   demultiplexing buffered data messages at the ASP and the
> > > >         SG during failover or AS-PENDING, again, without having
> > > > 	to reapply a complex Routing Key.
> > > > 
> > > >     o   assists in diagnostics by permitting monitoring
> > > >         equipment to at least distinguish traffic flows without
> > > > 	having to provision monitoring equipment with routing
> > > > 	keys.
> > > > 
> > > > It sure simplifies a lot of places in the implementation where
> > > > one would have to otherwise reapply the routing key.
> > > > 
> > > > I should point out that, for some routing keys (e.g, SCCP SSN)
> > > > it is currently impossible for the SGP to distinguish between AS
> > > > for *incoming* traffic when there are multiple AS on an
> > > > association.  This is because the Routing Key-->Routing
> > > > Context-->AS mapping is only valid for traffic from the SGP
> > > > towards the ASP.
> > > > 
> > > > Any objections to including RC in DATA messages?
> > > > 
> > > > --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]
> > > > 
> > > > 
> > > > ---
> > > > 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]
> > 
> > -- 
> > 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]
> 
> -- 
> 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]

-- 
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: Mon, 30 Jul 2001 15:36:40 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Network Appearance
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-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jeff,

If the SG is connected to the network with A-links, E-links or F-links, you
cannot look at it as an STP.  Restricting M3UA to an STP model would rule
out many non-quasi-associated (F-link connected) networks in places such as
Europe.

--Brian

Jeff Copley wrote:                           (Mon, 30 Jul 2001 14:59:22)
> Klaus,
> 
> I agree with you that the discussions are getting increasingly
> confusing.  This multiple networks business is getting increasingly
> confusing.  I look at the SS7 side of an SG like an STP.  An STP
> connects to multiple networks with no problems, so this must not be the
> problem trying to be solved.  
> 
> Given the above thought, I go to the next thought which is that perhaps
> an attempt is being made to make the SG(STP) appear as if it belongs to
> different networks rather than just one.  In such a case, the SG(STP)
> would need to have a multiple unique point code for identifying itself,
> one for each network that it belongs to.  In such a case, if I'm
> forwarding a message to some other element such as an ASP, then I would
> need something like an NA to represent each SS7 network to the ASPs. 
> Doing this though would be a pain in the .... thought processs.
> 
> Jeff
> 
> 
> "Gradischnig, Klaus" wrote:
> > 
> > All:
> > 
> > I am getting increasingly confused by this discussion on NA. However,
just
> > looking at its definition in M3UA08 alone would be enough to do the job:
> > 
> > "Network Appearance - The Network Appearance uniquely identifies an SS7
> > entity (Point Code) into an SS7 network, as presented by the SG.  It is
> > used for the purposes of logically separating the signalling traffic
> > between the SG and the Application Server Processes over a common SCTP
> > association.  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.  It is also necessary when an SG is
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > [KDG] This clearly says to me that I need an NA if and only if I have
> > multiple networks. In this case I need an NA for every point code,
however.
> > Why I would need this in the case of multiple networks only beats me.
[KDG]
> > 
> > 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.  An
> > example is where an SG is logically partitioned to appear as an element
> > in four separate national SS7 networks.  A Network Appearance
> >                                          ^^^^^^^^^^^^^^^^^^^^
> > implicitly defines the SS7 Point Code(s), Network Indicator and MTP3
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > protocol type/variant/version used within a separate SS7 network.
> > 
> > [KDG] In contrast, this last sentence now tells me that I need one and
only
> > one
> > NA for each network. This is at least something I understand and it
> > corresponds
> > to NA's original definition. [KDG]"
> > 
> > And while I can see where Brian's example below is coming from, I can't
> > except his arguments:
> > In the general case OPC specific screening cannot be handled by MTP
> > network/route management functions and therefore OPC specific routing
cannot
> > be supported without restrictions to either connectivity or network
> > management functionality. The example might start making sense if the SG
> > considered 5.255.3 and 5.255.4 to belong to "separate" networks using
> > different routing tables in the SG. In this case the SG may have to have
> > distinct point codes in these "separate" networks, provided then
"separate"
> > networks are actually interconnected (seems not to be the case in this
> > example, though).
> > In any case, I fully support John's and Barry's view that NA identifies
a
> > network (albeit from an SG internal view) and not an SPMC.
> > 
> > I am -- on an abstract level -- rather concerned about the unnecessary
> > complexity which has been introduced into m3ua and I have some
indication
> > that a number of operators and manufacturers share this view. How much
of
> > m3ua's functionality has actually been tested in Sophia? It seems to me
that
> > without some extensive testing in a real or emulated SS7 network
environment
> > going for last call is premature.
> > 
> > Klaus
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: July 30, 2001 1:09 PM
> > > To: sigtran
> > > Subject: Re: M3UA07: Network Appearance
> > >
> > >
> > > John,
> > >
> > > Please see response inline...
> > >
> > > John Schantz wrote:                               (Mon, 30
> > > Jul 2001 09:24:56)
> > > > Brian,
> > > >
> > > >     NO, see response to "M3UA: Routing Context".  Only a
> > > single network
> > > > appearance is needed per network connection.
> > > >
> > > >     More comments below.
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Saturday, July 28, 2001 8:08 AM
> > > > To: sigtran
> > > > Subject: Re: M3UA07: Network Appearance
> > > >
> > > >
> > > > John,
> > > >
> > > > Perhaps now you can see (from our discussion on the thread "M3UA:
> > > > Routing Context") that to cover all configurations, a
> > > Network Appearance
> > > > valud is required per primary point code and network id,
> > > and that this
> > > > proposal was a natural extension of that fact.  Consider
> > > the case below:
> > > >
> > > > [John] NO.
> > > >
> > >
> > >
> > >                            200.1.4    __________
> > >                              ___     /          \     ___
> > >                             /   \   |            |   /   \
> > >                            | SEP |__|____________|__| SEP |  AS1
> > >                             \___/   |            |   \___/
> > >                            //       |            |
> > >                           / |       | Signalling |  5.255.3
> > >                          / /        |   Gateway  |
> > >                         /  |        |            |
> > >                        /  /         |            |
> > >                _____  /   |         |            |
> > >               |     |/   /          |            |
> > >          -----| STP |____|__________|______      |
> > >              /|_____|   /           |      \___  |  5.255.4
> > >             /    |      |           |          \_|_   ___
> > >          \ /     |     /            |            | \ /   \
> > >           X      |     |            |            |  | SEP |  AS2
> > >          / \     |    /             |           _|_/ \___/
> > >             \  __|__ /              |       ___/ |
> > >              \|     |_______________|______/     |       5.255.5
> > >          -----| STP |               |            |       (alias)
> > >               |_____|               |            |
> > >                                     |            |
> > >                                      \__________/
> > >
> > >
> > > >
> > > > The signalling gateway needs two different Network Appearance
> > > > parameters: one per SPMC.  The bottom SPMC needs only one Network
> > > > Appearance to cover both the primary point code 5.255.4 and
> > > the alias
> > > > point code 5.255.5 because they are both treated as the
> > > same from an SS7
> > > > newtork management view.
> > > >
> > > > [John]  NO.  Since a SINGLE network connection is in the
> > > figure above, NO
> > > > network appearance is needed at all.  What do you think the
> > > point code is
> > > > for??????  You seem to proposing that the network
> > > appearance replace the
> > > > point code for routing, NO.
> > >
> > > John, say I have one ASP serving two ASs and each AS serves
> > > and entire SEP in
> > > the diagram as labelled.  They are served over 1 association
> > > to an ASP which
> > > is configured and active for both ASs.  When the F-link fails
> > > from the SG to
> > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
> > > Without something
> > > (Routing Context/Network Appearance) to distinguish the DUNA,
> > > AS2 will also
> > > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
> > > 200.1.4 via
> > > the STPs.
> > >
> > > If the SG does not send DUNA(200.1.4) but attempts to route
> > > traffic from AS1
> > > to 200.1.4 via the STPs, consider that STP Gateway Screening
> > > may throw these
> > > messages in the garbage because 5.255.4 and 5.255.5 are the
> > > only point codes
> > > allowed in the OPC on messages on the A-links.
> > >
> > > So, again, there are two choices:  Make Network Appearance an
> > > identifier
> > > of the SPMC and include it on all DUNA/DAVA/etc. where the ASP servers
> > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> > >
> > > >
> > > > Now, in general, a rational basis for assigning Network
> > > Apearance Id's
> > > > is to use the Network Id and Point Code of the node (the
> > > node *is* the
> > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
> > > the SG sends
> > > > concerning the SPMC will be properly distinguish.
> > > >
> > > > [John]  NO.  A single network appearance (== network ID) +
> > > affected point
> > > > code is all that is needed.
> > > >
> > > > Note that if the proposed assignment of Network Appearances is used,
> > > > the SCON message no longer requires a Concerned Point Code parameter
> > > > when the SPMC is signalling congestion to the SG.  It need only use
> > > > the Network Appearance.
> > > >
> > > > [John] NO.
> > > >
> > > > The definition of a Network Appearance becomes
> > > (effectively): "An unique
> > > > identifier indicating the Signalling Point Management
> > > Cluster (SPMC) to
> > > > which Signalling Network Management Messages apply."
> > > >
> > > > [John]  NO.
> > > >
> > > > --Brian
> > > >
> > > >
> > > > Schantz, John wrote:                         (Mon, 23 Jul
> > > 2001 13:37:00)
> > > > > Brian,
> > > > >
> > > > >   Why the need to include a concerned PC at all, the PC would be
> > > > > redundant to the one in the DPC.  Why not let the network
> > > appearance
> > > > > parameter be equal to the Network ID (all 32 bits).  Then Network
> > > > > Appearance(Network ID) + DPC will be unique and it will
> > > separate out the
> > > > > traffic into networks in both directions SG->AS and
> > > AS->SG(-> and beyond).
> > > > >
> > > > > John
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > > To: sigtran
> > > > > Cc: Greg Sidebottom
> > > > > Subject: M3UA07: Network Appearance
> > > > >
> > > > >
> > > > > Greg,
> > > > >
> > > > > When an SG is has multiple point codes serving ASPs which are
> > > > > active in multiple SPMCs, it becomes necessary to label each
> > > > > SPMC with a unique Network Appearance parameter to demultiplex
> > > > > DUNA, DAVA, DRST and SCON.  Because a separate Network Appearance
> > > > > assignment is necessary for each SPMC and the adminstration of
> > > > > these assignments could get quite tedious for an SGP/ASP pool
> > > > > representing a large number of point codes, I would like to
> > > > > propose the following refinement to the Network Appearance
> > > > > Parameter:
> > > > >
> > > > > (This is in fitting with the definition that a "Network Appearance
> > > > uniquely
> > > > > identifies an SS7 entity (Point Code) into an SS7 network.")
> > > > >
> > > > > The format of the Network Appearance parameter 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
> > > > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >    |  Network Id   |            Concerned Point Code
> > >          |
> > > > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >
> > > > > Network Identifier: 8-bit (unsigned integer)
> > > > >
> > > > >    The Network Identifier identifies the network in which
> > > the Concerned
> > > > >    Point Code can be considered unique, and distinguishes
> > > this Concerned
> > > > >    Point Code from an identical point code in any another network.
> > > > >    A Network Identifier identifying a specific
> > > adminsitrative domain for
> > > > >    the assignment of SS7 Signalling Point Codes MUST be
> > > global to all
> > > > >    SGPs in an SG.
> > > > >
> > > > > Concerned Point Code:
> > > > >
> > > > >    The Concerned Point Code identifies a point code within the
> > > > >    administrative domain as indicated by the Network
> > > Identifier.  The
> > > > >    Concerned Point Code is the one point code of a
> > > Signalling Point
> > > > >    Management Cluster (SPMC) which needs to receive
> > > updates concerning
> > > > >    the accessibility/restriction/congestion status of
> > > routesets from the
> > > > >    SPMC.
> > > > >
> > > > >
> > > > > 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]
> > > > >
> > > > >
> > > > > ---
> > > > > 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]
> > >
> > > --
> > > 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] Content-Description: Card for
Jeff Copley
> begin:vcard 
> n:Copley;Jeff
> tel;work:972.519.3758
> x-mozilla-html:FALSE
> org:Alcatel USA, Inc.
> version:2.1
> email;internet:[email-masked]
> adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> x-mozilla-cpt:;20864
> fn:Jeff Copley
> end:vcard

Content-Description: footer
> ---
> 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: M3UA Issue 8 Change Summary
Date: Mon, 30 Jul 2001 16:53:44 -0400
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-SMTP-HELO: femail48.sdc1.sfba.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail48.sdc1.sfba.home.com [24.254.60.42]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings,

A (working) day late but here is a list of changes that I promised.  Once
again I have a marked up MS-Word version of issue 8 with most of the changes
- if you want a copy, please send me an e-mail off-line ( [email-masked]
).  As I mentioned before, some late list discussion in the last 24/36 hours
before the draft cut-off (July 20th) was missed, also a couple of previous
"smaller" agreements (e.g., reponse timer on REG REQ).
All the Issue 7 comments after the draft cut-off (!) are of course not all
covered off yet.  And-all-of-the-hyphens-are-still-there  2;^)

Based on the explosion of comments on the M3UA and the reconsideration of
some older agreements I am assuming that there will be an Issue 9 - we
should shoot for a new draft right after the draft "moratorium".  I'll try
to get an M3UA Issues summary out to facilitate resolution by later
tomorrow, after wading through all the e-mail - This newfound interest is
really starting to cut into my golf game!

Cheers,

   Greg

Issue 8 Changes:

- Added Broadcast Traffic Mode and procedures.  Changed Traffic Mode
assignments to accommodate this new mode and align with M2UA - this resulted
in a shifting of the values for Over-ride (Standby) and Loadshare (Standby)

- Changed parameter tag assignments to have common and M3UA-specific ranges
of values

- Added optional ASP Identifier parameter to ASP Up and Notify messages.
Added Error code "Refused - missing, duplicated or invalid ASP Identifier".

- Removed the mandatory Reason parameter from the ASP Down and ASP Down Ack
message.  No procedures were in place to describe how the individual reasons
would be used differently.

- Removed ASP-to-SG restriction on optional Heartbeat procedures to allow
them to be initiated by any process.

- Correction of the message flows in 5.1.3 and 5.1.4 (Missing Notifies)

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 30 Jul 2001 16:03:29 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
CC: [email-masked]
Subject: Re: M3UA07: Network Appearance
X-SMTP-HELO: netmail.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [128.251.168.50]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I see an SG as receiving many SS7 links from the network and packaging the
SS7 user for delivery into the IP network.  I really don't care what type of
links they are as it shouldn't matter.

A SG receives an SS7 message and relays it to some node in the IP network.  

Jeff

"Brian F. G. Bidulock" wrote:
> 
> Jeff,
> 
> If the SG is connected to the network with A-links, E-links or
> F-links, you cannot look at it as an STP.  Restricting M3UA to
> an STP model would rule out many non-quasi-associated (F-link
> connected) networks in places such as Europe.
> 
> --Brian
> 
> Jeff Copley wrote:                           (Mon, 30 Jul 2001 14:59:22)
> > Klaus,
> >
> > I agree with you that the discussions are getting increasingly
> > confusing.  This multiple networks business is getting increasingly
> > confusing.  I look at the SS7 side of an SG like an STP.  An STP
> > connects to multiple networks with no problems, so this must not be the
> > problem trying to be solved.
> >
> > Given the above thought, I go to the next thought which is that perhaps
> > an attempt is being made to make the SG(STP) appear as if it belongs to
> > different networks rather than just one.  In such a case, the SG(STP)
> > would need to have a multiple unique point code for identifying itself,
> > one for each network that it belongs to.  In such a case, if I'm
> > forwarding a message to some other element such as an ASP, then I would
> > need something like an NA to represent each SS7 network to the ASPs.
> > Doing this though would be a pain in the .... thought processs.
> >
> > Jeff
> >
> >
> > "Gradischnig, Klaus" wrote:
> > >
> > > All:
> > >
> > > I am getting increasingly confused by this discussion on NA. However,
just
> > > looking at its definition in M3UA08 alone would be enough to do the
job:
> > >
> > > "Network Appearance - The Network Appearance uniquely identifies an
SS7
> > > entity (Point Code) into an SS7 network, as presented by the SG.  It
is
> > > used for the purposes of logically separating the signalling traffic
> > > between the SG and the Application Server Processes over a common SCTP
> > > association.  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.  It is also necessary when an SG is
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > [KDG] This clearly says to me that I need an NA if and only if I have
> > > multiple networks. In this case I need an NA for every point code,
however.
> > > Why I would need this in the case of multiple networks only beats me.
[KDG]
> > >
> > > 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.  An
> > > example is where an SG is logically partitioned to appear as an
element
> > > in four separate national SS7 networks.  A Network Appearance
> > >                                          ^^^^^^^^^^^^^^^^^^^^
> > > implicitly defines the SS7 Point Code(s), Network Indicator and MTP3
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > protocol type/variant/version used within a separate SS7 network.
> > >
> > > [KDG] In contrast, this last sentence now tells me that I need one and
only
> > > one
> > > NA for each network. This is at least something I understand and it
> > > corresponds
> > > to NA's original definition. [KDG]"
> > >
> > > And while I can see where Brian's example below is coming from, I
can't
> > > except his arguments:
> > > In the general case OPC specific screening cannot be handled by MTP
> > > network/route management functions and therefore OPC specific routing
cannot
> > > be supported without restrictions to either connectivity or network
> > > management functionality. The example might start making sense if the
SG
> > > considered 5.255.3 and 5.255.4 to belong to "separate" networks using
> > > different routing tables in the SG. In this case the SG may have to
have
> > > distinct point codes in these "separate" networks, provided then
"separate"
> > > networks are actually interconnected (seems not to be the case in this
> > > example, though).
> > > In any case, I fully support John's and Barry's view that NA
identifies a
> > > network (albeit from an SG internal view) and not an SPMC.
> > >
> > > I am -- on an abstract level -- rather concerned about the unnecessary
> > > complexity which has been introduced into m3ua and I have some
indication
> > > that a number of operators and manufacturers share this view. How much
of
> > > m3ua's functionality has actually been tested in Sophia? It seems to
me that
> > > without some extensive testing in a real or emulated SS7 network
environment
> > > going for last call is premature.
> > >
> > > Klaus
> > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: July 30, 2001 1:09 PM
> > > > To: sigtran
> > > > Subject: Re: M3UA07: Network Appearance
> > > >
> > > >
> > > > John,
> > > >
> > > > Please see response inline...
> > > >
> > > > John Schantz wrote:                               (Mon, 30
> > > > Jul 2001 09:24:56)
> > > > > Brian,
> > > > >
> > > > >     NO, see response to "M3UA: Routing Context".  Only a
> > > > single network
> > > > > appearance is needed per network connection.
> > > > >
> > > > >     More comments below.
> > > > >
> > > > > John
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Saturday, July 28, 2001 8:08 AM
> > > > > To: sigtran
> > > > > Subject: Re: M3UA07: Network Appearance
> > > > >
> > > > >
> > > > > John,
> > > > >
> > > > > Perhaps now you can see (from our discussion on the thread "M3UA:
> > > > > Routing Context") that to cover all configurations, a
> > > > Network Appearance
> > > > > valud is required per primary point code and network id,
> > > > and that this
> > > > > proposal was a natural extension of that fact.  Consider
> > > > the case below:
> > > > >
> > > > > [John] NO.
> > > > >
> > > >
> > > >
> > > >                            200.1.4    __________
> > > >                              ___     /          \     ___
> > > >                             /   \   |            |   /   \
> > > >                            | SEP |__|____________|__| SEP |  AS1
> > > >                             \___/   |            |   \___/
> > > >                            //       |            |
> > > >                           / |       | Signalling |  5.255.3
> > > >                          / /        |   Gateway  |
> > > >                         /  |        |            |
> > > >                        /  /         |            |
> > > >                _____  /   |         |            |
> > > >               |     |/   /          |            |
> > > >          -----| STP |____|__________|______      |
> > > >              /|_____|   /           |      \___  |  5.255.4
> > > >             /    |      |           |          \_|_   ___
> > > >          \ /     |     /            |            | \ /   \
> > > >           X      |     |            |            |  | SEP |  AS2
> > > >          / \     |    /             |           _|_/ \___/
> > > >             \  __|__ /              |       ___/ |
> > > >              \|     |_______________|______/     |       5.255.5
> > > >          -----| STP |               |            |       (alias)
> > > >               |_____|               |            |
> > > >                                     |            |
> > > >                                      \__________/
> > > >
> > > >
> > > > >
> > > > > The signalling gateway needs two different Network Appearance
> > > > > parameters: one per SPMC.  The bottom SPMC needs only one Network
> > > > > Appearance to cover both the primary point code 5.255.4 and
> > > > the alias
> > > > > point code 5.255.5 because they are both treated as the
> > > > same from an SS7
> > > > > newtork management view.
> > > > >
> > > > > [John]  NO.  Since a SINGLE network connection is in the
> > > > figure above, NO
> > > > > network appearance is needed at all.  What do you think the
> > > > point code is
> > > > > for??????  You seem to proposing that the network
> > > > appearance replace the
> > > > > point code for routing, NO.
> > > >
> > > > John, say I have one ASP serving two ASs and each AS serves
> > > > and entire SEP in
> > > > the diagram as labelled.  They are served over 1 association
> > > > to an ASP which
> > > > is configured and active for both ASs.  When the F-link fails
> > > > from the SG to
> > > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
> > > > Without something
> > > > (Routing Context/Network Appearance) to distinguish the DUNA,
> > > > AS2 will also
> > > > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
> > > > 200.1.4 via
> > > > the STPs.
> > > >
> > > > If the SG does not send DUNA(200.1.4) but attempts to route
> > > > traffic from AS1
> > > > to 200.1.4 via the STPs, consider that STP Gateway Screening
> > > > may throw these
> > > > messages in the garbage because 5.255.4 and 5.255.5 are the
> > > > only point codes
> > > > allowed in the OPC on messages on the A-links.
> > > >
> > > > So, again, there are two choices:  Make Network Appearance an
> > > > identifier
> > > > of the SPMC and include it on all DUNA/DAVA/etc. where the ASP
servers
> > > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> > > >
> > > > >
> > > > > Now, in general, a rational basis for assigning Network
> > > > Apearance Id's
> > > > > is to use the Network Id and Point Code of the node (the
> > > > node *is* the
> > > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
> > > > the SG sends
> > > > > concerning the SPMC will be properly distinguish.
> > > > >
> > > > > [John]  NO.  A single network appearance (== network ID) +
> > > > affected point
> > > > > code is all that is needed.
> > > > >
> > > > > Note that if the proposed assignment of Network Appearances is
used,
> > > > > the SCON message no longer requires a Concerned Point Code
parameter
> > > > > when the SPMC is signalling congestion to the SG.  It need only
use
> > > > > the Network Appearance.
> > > > >
> > > > > [John] NO.
> > > > >
> > > > > The definition of a Network Appearance becomes
> > > > (effectively): "An unique
> > > > > identifier indicating the Signalling Point Management
> > > > Cluster (SPMC) to
> > > > > which Signalling Network Management Messages apply."
> > > > >
> > > > > [John]  NO.
> > > > >
> > > > > --Brian
> > > > >
> > > > >
> > > > > Schantz, John wrote:                         (Mon, 23 Jul
> > > > 2001 13:37:00)
> > > > > > Brian,
> > > > > >
> > > > > >   Why the need to include a concerned PC at all, the PC would be
> > > > > > redundant to the one in the DPC.  Why not let the network
> > > > appearance
> > > > > > parameter be equal to the Network ID (all 32 bits).  Then
Network
> > > > > > Appearance(Network ID) + DPC will be unique and it will
> > > > separate out the
> > > > > > traffic into networks in both directions SG->AS and
> > > > AS->SG(-> and beyond).
> > > > > >
> > > > > > John
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > > > To: sigtran
> > > > > > Cc: Greg Sidebottom
> > > > > > Subject: M3UA07: Network Appearance
> > > > > >
> > > > > >
> > > > > > Greg,
> > > > > >
> > > > > > When an SG is has multiple point codes serving ASPs which are
> > > > > > active in multiple SPMCs, it becomes necessary to label each
> > > > > > SPMC with a unique Network Appearance parameter to demultiplex
> > > > > > DUNA, DAVA, DRST and SCON.  Because a separate Network
Appearance
> > > > > > assignment is necessary for each SPMC and the adminstration of
> > > > > > these assignments could get quite tedious for an SGP/ASP pool
> > > > > > representing a large number of point codes, I would like to
> > > > > > propose the following refinement to the Network Appearance
> > > > > > Parameter:
> > > > > >
> > > > > > (This is in fitting with the definition that a "Network
Appearance
> > > > > uniquely
> > > > > > identifies an SS7 entity (Point Code) into an SS7 network.")
> > > > > >
> > > > > > The format of the Network Appearance parameter 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
> > > > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >    |  Network Id   |            Concerned Point Code
> > > >          |
> > > > > >
> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >
> > > > > > Network Identifier: 8-bit (unsigned integer)
> > > > > >
> > > > > >    The Network Identifier identifies the network in which
> > > > the Concerned
> > > > > >    Point Code can be considered unique, and distinguishes
> > > > this Concerned
> > > > > >    Point Code from an identical point code in any another
network.
> > > > > >    A Network Identifier identifying a specific
> > > > adminsitrative domain for
> > > > > >    the assignment of SS7 Signalling Point Codes MUST be
> > > > global to all
> > > > > >    SGPs in an SG.
> > > > > >
> > > > > > Concerned Point Code:
> > > > > >
> > > > > >    The Concerned Point Code identifies a point code within the
> > > > > >    administrative domain as indicated by the Network
> > > > Identifier.  The
> > > > > >    Concerned Point Code is the one point code of a
> > > > Signalling Point
> > > > > >    Management Cluster (SPMC) which needs to receive
> > > > updates concerning
> > > > > >    the accessibility/restriction/congestion status of
> > > > routesets from the
> > > > > >    SPMC.
> > > > > >
> > > > > >
> > > > > > 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]
> > > > > >
> > > > > >
> > > > > > ---
> > > > > > 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]
> > > >
> > > > --
> > > > 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]
> Content-Description: Card for Jeff Copley
> > begin:vcard
> > n:Copley;Jeff
> > tel;work:972.519.3758
> > x-mozilla-html:FALSE
> > org:Alcatel USA, Inc.
> > version:2.1
> > email;internet:[email-masked]
> > adr;quoted-printable:;;1000 Coit Road=0D=0AMS
NSGAP;Plano;Texas;75075-5813;USA
> > x-mozilla-cpt:;20864
> > fn:Jeff Copley
> > end:vcard
> >
> >
> >
> 
> Content-Description: footer
> > ---
> > 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] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\Jeff.Copley12.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Gradischnig, Klaus" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07: Network Appearance
Date: Mon, 30 Jul 2001 16:10:02 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: pine.neustar.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pine.neustar.com [209.173.57.70]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Jeff,

ah, yes, the German language has a nice expression for things which try to
do/be everything at once:
Eierlegende Wollmilchsau == egg, wool, and milk producing pig ;-)

Seriously though: on the one hand we have RKs which address sub-destination
point code handling ASes, on the other we have ASPs spanning multiple
networks. This is quite a spectrum. Now we do not allow RKs to cover more
than one SPMC, IMHO a restriction with little if any practical relevance.
Why do we not (instead?) restrict ASPs (and consequently ASes) to a single
SS7 network and the pain might go away? What do you say?

Klaus

> -----Original Message-----
> From: Jeff Copley [mailto:[email-masked]]
> Sent: July 30, 2001 3:59 PM
> To: sigtran
> Subject: Re: M3UA07: Network Appearance
> 
> 
> Klaus,
> 
> I agree with you that the discussions are getting increasingly
> confusing.  This multiple networks business is getting increasingly
> confusing.  I look at the SS7 side of an SG like an STP.  An STP
> connects to multiple networks with no problems, so this must 
> not be the
> problem trying to be solved.  
> 
> Given the above thought, I go to the next thought which is 
> that perhaps
> an attempt is being made to make the SG(STP) appear as if it 
> belongs to
> different networks rather than just one.  In such a case, the SG(STP)
> would need to have a multiple unique point code for 
> identifying itself,
> one for each network that it belongs to.  In such a case, if I'm
> forwarding a message to some other element such as an ASP, 
> then I would
> need something like an NA to represent each SS7 network to the ASPs. 
> Doing this though would be a pain in the .... thought processs.
> 
> Jeff
> 
> 
> "Gradischnig, Klaus" wrote:
> > 
> > All:
> > 
> > I am getting increasingly confused by this discussion on 
> NA. However, just
> > looking at its definition in M3UA08 alone would be enough 
> to do the job:
> > 
> > "Network Appearance - The Network Appearance uniquely 
> identifies an SS7
> > entity (Point Code) into an SS7 network, as presented by 
> the SG.  It is
> > used for the purposes of logically separating the signalling traffic
> > between the SG and the Application Server Processes over a 
> common SCTP
> > association.  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.  It is also necessary when an SG is
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > [KDG] This clearly says to me that I need an NA if and only 
> if I have
> > multiple networks. In this case I need an NA for every 
> point code, however.
> > Why I would need this in the case of multiple networks only 
> beats me. [KDG]
> > 
> > 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.  An
> > example is where an SG is logically partitioned to appear 
> as an element
> > in four separate national SS7 networks.  A Network Appearance
> >                                          ^^^^^^^^^^^^^^^^^^^^
> > implicitly defines the SS7 Point Code(s), Network Indicator and MTP3
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > protocol type/variant/version used within a separate SS7 network.
> > 
> > [KDG] In contrast, this last sentence now tells me that I 
> need one and only
> > one
> > NA for each network. This is at least something I understand and it
> > corresponds
> > to NA's original definition. [KDG]"
> > 
> > And while I can see where Brian's example below is coming 
> from, I can't
> > except his arguments:
> > In the general case OPC specific screening cannot be handled by MTP
> > network/route management functions and therefore OPC 
> specific routing cannot
> > be supported without restrictions to either connectivity or network
> > management functionality. The example might start making 
> sense if the SG
> > considered 5.255.3 and 5.255.4 to belong to "separate" 
> networks using
> > different routing tables in the SG. In this case the SG may 
> have to have
> > distinct point codes in these "separate" networks, provided 
> then "separate"
> > networks are actually interconnected (seems not to be the 
> case in this
> > example, though).
> > In any case, I fully support John's and Barry's view that 
> NA identifies a
> > network (albeit from an SG internal view) and not an SPMC.
> > 
> > I am -- on an abstract level -- rather concerned about the 
> unnecessary
> > complexity which has been introduced into m3ua and I have 
> some indication
> > that a number of operators and manufacturers share this 
> view. How much of
> > m3ua's functionality has actually been tested in Sophia? It 
> seems to me that
> > without some extensive testing in a real or emulated SS7 
> network environment
> > going for last call is premature.
> > 
> > Klaus
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: July 30, 2001 1:09 PM
> > > To: sigtran
> > > Subject: Re: M3UA07: Network Appearance
> > >
> > >
> > > John,
> > >
> > > Please see response inline...
> > >
> > > John Schantz wrote:                               (Mon, 30
> > > Jul 2001 09:24:56)
> > > > Brian,
> > > >
> > > >     NO, see response to "M3UA: Routing Context".  Only a
> > > single network
> > > > appearance is needed per network connection.
> > > >
> > > >     More comments below.
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Saturday, July 28, 2001 8:08 AM
> > > > To: sigtran
> > > > Subject: Re: M3UA07: Network Appearance
> > > >
> > > >
> > > > John,
> > > >
> > > > Perhaps now you can see (from our discussion on the 
> thread "M3UA:
> > > > Routing Context") that to cover all configurations, a
> > > Network Appearance
> > > > valud is required per primary point code and network id,
> > > and that this
> > > > proposal was a natural extension of that fact.  Consider
> > > the case below:
> > > >
> > > > [John] NO.
> > > >
> > >
> > >
> > >                            200.1.4    __________
> > >                              ___     /          \     ___
> > >                             /   \   |            |   /   \
> > >                            | SEP |__|____________|__| SEP |  AS1
> > >                             \___/   |            |   \___/
> > >                            //       |            |
> > >                           / |       | Signalling |  5.255.3
> > >                          / /        |   Gateway  |
> > >                         /  |        |            |
> > >                        /  /         |            |
> > >                _____  /   |         |            |
> > >               |     |/   /          |            |
> > >          -----| STP |____|__________|______      |
> > >              /|_____|   /           |      \___  |  5.255.4
> > >             /    |      |           |          \_|_   ___
> > >          \ /     |     /            |            | \ /   \
> > >           X      |     |            |            |  | SEP |  AS2
> > >          / \     |    /             |           _|_/ \___/
> > >             \  __|__ /              |       ___/ |
> > >              \|     |_______________|______/     |       5.255.5
> > >          -----| STP |               |            |       (alias)
> > >               |_____|               |            |
> > >                                     |            |
> > >                                      \__________/
> > >
> > >
> > > >
> > > > The signalling gateway needs two different Network Appearance
> > > > parameters: one per SPMC.  The bottom SPMC needs only 
> one Network
> > > > Appearance to cover both the primary point code 5.255.4 and
> > > the alias
> > > > point code 5.255.5 because they are both treated as the
> > > same from an SS7
> > > > newtork management view.
> > > >
> > > > [John]  NO.  Since a SINGLE network connection is in the
> > > figure above, NO
> > > > network appearance is needed at all.  What do you think the
> > > point code is
> > > > for??????  You seem to proposing that the network
> > > appearance replace the
> > > > point code for routing, NO.
> > >
> > > John, say I have one ASP serving two ASs and each AS serves
> > > and entire SEP in
> > > the diagram as labelled.  They are served over 1 association
> > > to an ASP which
> > > is configured and active for both ASs.  When the F-link fails
> > > from the SG to
> > > SEP 200.1.4 in the network, the SG will send DUNA(200.1.4).
> > > Without something
> > > (Routing Context/Network Appearance) to distinguish the DUNA,
> > > AS2 will also
> > > process the DUNA(200.1.4).  Yet, AS2 still has a route to SEP
> > > 200.1.4 via
> > > the STPs.
> > >
> > > If the SG does not send DUNA(200.1.4) but attempts to route
> > > traffic from AS1
> > > to 200.1.4 via the STPs, consider that STP Gateway Screening
> > > may throw these
> > > messages in the garbage because 5.255.4 and 5.255.5 are the
> > > only point codes
> > > allowed in the OPC on messages on the A-links.
> > >
> > > So, again, there are two choices:  Make Network Appearance an
> > > identifier
> > > of the SPMC and include it on all DUNA/DAVA/etc. where 
> the ASP servers
> > > mutliple SPMCs, or include Routing Context in DUNA/DAVA/etc.
> > >
> > > >
> > > > Now, in general, a rational basis for assigning Network
> > > Apearance Id's
> > > > is to use the Network Id and Point Code of the node (the
> > > node *is* the
> > > > network appearance).  Therefore, the DUNA, DAVA, etc. that
> > > the SG sends
> > > > concerning the SPMC will be properly distinguish.
> > > >
> > > > [John]  NO.  A single network appearance (== network ID) +
> > > affected point
> > > > code is all that is needed.
> > > >
> > > > Note that if the proposed assignment of Network 
> Appearances is used,
> > > > the SCON message no longer requires a Concerned Point 
> Code parameter
> > > > when the SPMC is signalling congestion to the SG.  It 
> need only use
> > > > the Network Appearance.
> > > >
> > > > [John] NO.
> > > >
> > > > The definition of a Network Appearance becomes
> > > (effectively): "An unique
> > > > identifier indicating the Signalling Point Management
> > > Cluster (SPMC) to
> > > > which Signalling Network Management Messages apply."
> > > >
> > > > [John]  NO.
> > > >
> > > > --Brian
> > > >
> > > >
> > > > Schantz, John wrote:                         (Mon, 23 Jul
> > > 2001 13:37:00)
> > > > > Brian,
> > > > >
> > > > >   Why the need to include a concerned PC at all, the 
> PC would be
> > > > > redundant to the one in the DPC.  Why not let the network
> > > appearance
> > > > > parameter be equal to the Network ID (all 32 bits).  
> Then Network
> > > > > Appearance(Network ID) + DPC will be unique and it will
> > > separate out the
> > > > > traffic into networks in both directions SG->AS and
> > > AS->SG(-> and beyond).
> > > > >
> > > > > John
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Monday, July 23, 2001 6:41 AM
> > > > > To: sigtran
> > > > > Cc: Greg Sidebottom
> > > > > Subject: M3UA07: Network Appearance
> > > > >
> > > > >
> > > > > Greg,
> > > > >
> > > > > When an SG is has multiple point codes serving ASPs which are
> > > > > active in multiple SPMCs, it becomes necessary to label each
> > > > > SPMC with a unique Network Appearance parameter to demultiplex
> > > > > DUNA, DAVA, DRST and SCON.  Because a separate 
> Network Appearance
> > > > > assignment is necessary for each SPMC and the adminstration of
> > > > > these assignments could get quite tedious for an SGP/ASP pool
> > > > > representing a large number of point codes, I would like to
> > > > > propose the following refinement to the Network Appearance
> > > > > Parameter:
> > > > >
> > > > > (This is in fitting with the definition that a 
> "Network Appearance
> > > > uniquely
> > > > > identifies an SS7 entity (Point Code) into an SS7 network.")
> > > > >
> > > > > The format of the Network Appearance parameter 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
> > > > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >    |  Network Id   |            Concerned Point Code
> > >          |
> > > > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >
> > > > > Network Identifier: 8-bit (unsigned integer)
> > > > >
> > > > >    The Network Identifier identifies the network in which
> > > the Concerned
> > > > >    Point Code can be considered unique, and distinguishes
> > > this Concerned
> > > > >    Point Code from an identical point code in any 
> another network.
> > > > >    A Network Identifier identifying a specific
> > > adminsitrative domain for
> > > > >    the assignment of SS7 Signalling Point Codes MUST be
> > > global to all
> > > > >    SGPs in an SG.
> > > > >
> > > > > Concerned Point Code:
> > > > >
> > > > >    The Concerned Point Code identifies a point code within the
> > > > >    administrative domain as indicated by the Network
> > > Identifier.  The
> > > > >    Concerned Point Code is the one point code of a
> > > Signalling Point
> > > > >    Management Cluster (SPMC) which needs to receive
> > > updates concerning
> > > > >    the accessibility/restriction/congestion status of
> > > routesets from the
> > > > >    SPMC.
> > > > >
> > > > >
> > > > > 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]
> > > > >
> > > > >
> > > > > ---
> > > > > 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]
> > >
> > > --
> > > 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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: John Loughney <[email-masked]>
Subject: Re: SUAv7, M3UAv8: Heartbeat Procedures
Date: Mon, 30 Jul 2001 17:13:13 -0400
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-SMTP-HELO: femail42.sdc1.sfba.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail42.sdc1.sfba.home.com [24.254.60.36]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

John and I exchanged some Heartbeat text before sending out M3UA and SUA, to
reflect the agreement on the list that the Heartbeat could be in either
direction.  The M3UA/SUA text now says in M3UA Issue 8 that either side can
send the Heartbeat.  Actually I notice now that the latest SUA text says
that "either M3UA peer MAY
optionally send Heartbeat messages periodically" so there is a typo there
2;^)

We left alone the current restriction that the ASP Up / ASP Up Ack must
occur first (i.e., the ASP must be out of the ASP-DOWN state), but we can
easily remove this restriction.  We would just need to remove the first
clause of the first sentance in the second paragraph of Section 4.2.3.7.  We
should also add a small statement in
4.2.1.1 (the ASP-Down paragraph) to point out that a Heartbeat should be
responded to.  Right now it says that "An ASP in this state SHOULD NOT be
sent any M3UA messages"

Are there any objections to this small change out there?  If not I will make
the change for Issue 9.  John and I can "editorially-speaking" line up the
text a little better as well.

Thanks,

   Greg Sidebottom

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Cc: "Greg Sidebottom"
<[email-masked]>; "John Loughney" <[email-masked]>
Sent: Wednesday, July 25, 2001 3:27 PM
Subject: SUAv7, M3UAv8: Heartbeat Procedures

> Greg, John,
>
> Were the heartbeat procedures going to be updated?  Certainly there
> is no reason why an SGP should not be able to send BEAT and expect
> BEAT ACK, even if it has not yet received ASP UP.  BEAT may be the
> only way that the SGP has of identifying a "dead" ASP which is
> holding open an association but is never going to send ASP UP.
> The SGP could clearly drop the association if the BEAT Ack doesn't
> come back per the procedure.
>
> Was there some common text for this procedure?  Was it going to be
> included in SUA and M3UA?
>
> --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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
To: "sigtran" <[email-masked]>
Subject: m2pa query
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
From: [email-masked]
Date: Mon, 30 Jul 2001 17:25:32 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Deepa 
             Tonse/Radisys_Corporation/US(Release 5.0.7 |March 21, 2001) at 
             07/30/2001 05:30:06 PM, Serialize by Notes Client on Deepa 
             Tonse/Radisys_Corporation/US(Release 5.0.7 |March 21, 2001) at 
             07/30/2001 05:30:06 PM, Serialize complete at 07/30/2001
05:30:06 
             PM, S/MIME Sign failed at 07/30/2001 05:30:06 PM: The 
             cryptographic key was not found, Serialize by Router on 
             HQ_ACS_1/Radisys_Corporation/US(Release 5.0.8 |June 18, 2001)
at 
             07/30/2001 02:28:42 PM, Serialize complete at 07/30/2001
02:28:42 
             PM
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>

<br><font size=2 face="Courier New"><br> As reflected by the changes in
m2pa-03.txt section 4.1.2, SCTP association is now created
&quot;early&quot;, rather than waiting for MTP3 Start.</font><font size=3
face="Times New Roman"> </font> <p><font size=2 face="Courier New">But the
example message flow in the section of 5.1 still waits for the &quot;start
request&quot; from MTP3 before sending &quot;associate&quot; primitive to
SCTP;</font><font size=3 face="Times New Roman"> </font> <p><font size=2
face="Courier New">Can someone clarify this?</font><font size=3 face="Times
New Roman"> </font> <p><font size=2 face="Courier New">Thanks,</font><font
size=3 face="Times New Roman"> </font> <p><font size=2 face="Courier
New">Deepa Tonse,</font><font size=3 face="Times New Roman"> </font>
<p><font size=2 face="Courier New">RADISYS Corporation,</font><font size=3
face="Times New Roman"> </font> <p><font size=2 face="Courier New"><br>
</font>

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-html>
Date: Mon, 30 Jul 2001 16:31:00 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07: Network Appearance
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-212.dallas.net [209.44.42.212]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Klaus,

In Section 1.3.3 Signalling Network Architecture, M3UAv8 states:

    "... M3UA imposes no restrictions as to the exact layout of
    the network elements, the message distribution algorithms
    and the distribution of the signalling processes.  Instead,
    it provides a framework and a set of messages that allow for
    a flexible and scalable signalling network architecture,
    aiming to provide reliability and performance."

Were you wanting to place restrictions?

--Brian

Gradischnig, Klaus wrote:                            (Mon, 30 Jul 2001
16:10:02)
> Jeff,
> 
> ah, yes, the German language has a nice expression for things which try to
> do/be everything at once:
> Eierlegende Wollmilchsau == egg, wool, and milk producing pig ;-)
> 
> Seriously though: on the one hand we have RKs which address
sub-destination
> point code handling ASes, on the other we have ASPs spanning multiple
> networks. This is quite a spectrum. Now we do not allow RKs to cover more
> than one SPMC, IMHO a restriction with little if any practical relevance.
> Why do we not (instead?) restrict ASPs (and consequently ASes) to a single
> SS7 network and the pain might go away? What do you say?
> 
> Klaus
> 
> > -----Original Message-----
> > From: Jeff Copley [mailto:[email-masked]]
> > Sent: July 30, 2001 3:59 PM
> > To: sigtran
> > Subject: Re: M3UA07: Network Ap