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

Date: Sat, 21 Jul 2001 04:17:05 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Dynamic Registration in M3UA
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.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Satish,

Well... ASPs are really registering "into" one or more AS.

I thought of another interesting spin on registration.  It is completely
possible to have the ASP, when it comes up with ASPUP have a "default"
routing.  But the ASP could then do a DEREG REQ against that "default"
routing context and REG REQ against a different one.  If things were set up
well, the ASP could use some special value of RC to indicate "my default
AS", say, 0.

What's the value in this?  What it permits is provisioning a platform so
that when it goes down hard, it comes up with a default configuration (BOCs
would love it) which does not require any dynamic registration to get
started.  That is it would come up static.  Once the platform had stablized,
it would be possible for ASPs to DEREG and REG to "move" traffic around here
and there to optimize the platform to current conditions (i.e, available
processors, load balance, time of day/day of week, etc.)

This would work really well for M2UA where the Signalling Data Link
allocations at restart need to be fixed at both ends of the signalling
links, but dynamic allocation of Signalling Data Links can do its job after
that.

--Brian

Satish K wrote:                            (Sat, 21 Jul 2001 14:00:13)
> Brain,
>    I agree with you, I just wanted to confirm this as it was not clear in
> the Draft in terms of implementation wise of AS side. as the Draft always
> talks about dynamic registration of ASPs.
> Thanks
> Satish
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 21 July 2001 13:37
> To: sigtran
> Subject: Re: Dynamic Registration in M3UA
> 
> 
> Satish,
> 
> I think I get what you're driving at, but I don't think that
> the M3UA makes any restrictions here.  It is pretty much up
> to the SGP/ASP to agree.  That said, here's how I think that
> it `could' work:
> 
> If, as you say, the Routing Key is not already configured in
> the SGP, and if the AS is not provisioned in the SGP, then
> what will the SGP do when it gets a registration request for
> this "new" Routing Key?
> 
> Well, if the Routing Key is supported by the SGP (i.e, the
> SGP is capable of providing traffic and routing on that key)
> and the key doesn't cause a problem for the SGP by overlappping
> with other keys; then, it is possible for the SGP to store
> the key and assign a Routing Context to the key to return
> in the REG RSP.
> 
> If, as you say, the AS has not been provisioned, there exists
> no AS object at this time.  The SGP is not really forced to
> create one yet.
> 
> Now, say the ASP performs an ASPAC for the Routing Context
> which corresponds to our new Routing Key.  The SGP can create
> an AS object at this time.  The only information that the SGP
> really needs to create the AS object is the Traffic Mode.
> 
> The SGP implementation *could* either simply accept the the
> Traffic Mode type presented in the ASPAC, if it is capable
> of supporting that mode, or, the SGP/ASP could have agreed
> `a priori' (that is, they were configured to agree on what
> traffic modes and precise distribution algorithms to use for
> "new" routing keys of this sort).
> 
> So, I don't believe that there is anything stopping an SGP
> from dynamically creating an AS based on the Routing Key
> information and local configuration information.  I don't
> think that the SGP needs to be statically configured for all
> the AS that it will support, regardless of the registration
> procedure.
> 
> 
> There is another way to look at this too.  There is nothing
> stopping the SGP from statically provisioning *all* Routing
> Keys and associating Routing Context and AS information with
> them at provisioning time.  What the registration procedure
> affords in this scenario is being relieved from having to
> match Routing Contexts provisioning in the ASP with that
> of the SGP.
> 
> M3UA really doesn't restrict things here.  Kudos to whoever
> proposed it!
> 
> --Brian
> 
> 
> Satish K wrote:                                            (Sat, 21 Jul
2001
> 10:56:53)
> > Brain,
> >    I just wated to confirm one thing ie, we talk about dynamic
> Registration
> > ie Registering new ASPs with New routing key with the AS does it mean we
> can
> > only register the ASPs dynamically and AS are registered Stactically?
> >    What happens when new ASP in New AS tries to register with the SGP?
by
> > new AS i mean this Routing Key is not yet registered in SGP.
> > Thanks
> > Satish
> >
> >
> >
> > ---
> > 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: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Dynamic Registration in M3UA
Date: Sat, 21 Jul 2001 15:52:14 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,
   I feel this sought of dynamic registration(first come up with default key
and later dynamically register with another key) might be required in m3ua.
    This might come in use when the AS has data to be carried to other
destined SGP, which it has not registered now it can register and with the
default key and send data it need not wait for another new reigstraion.
Later if required depending on the Traffic it can continue with the new
Registration key.
Thanks
Satish

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: 21 July 2001
14:47
To: sigtran
Subject: Re: Dynamic Registration in M3UA

Satish,

Well... ASPs are really registering "into" one or more AS.

I thought of another interesting spin on registration.  It is completely
possible to have the ASP, when it comes up with ASPUP have a "default"
routing.  But the ASP could then do a DEREG REQ against that "default"
routing context and REG REQ against a different one.  If things were set up
well, the ASP could use some special value of RC to indicate "my default
AS", say, 0.

What's the value in this?  What it permits is provisioning a platform so
that when it goes down hard, it comes up with a default configuration (BOCs
would love it) which does not require any dynamic registration to get
started.  That is it would come up static.  Once the platform had stablized,
it would be possible for ASPs to DEREG and REG to "move" traffic around here
and there to optimize the platform to current conditions (i.e, available
processors, load balance, time of day/day of week, etc.)

This would work really well for M2UA where the Signalling Data Link
allocations at restart need to be fixed at both ends of the signalling
links, but dynamic allocation of Signalling Data Links can do its job after
that.

--Brian

Satish K wrote:                            (Sat, 21 Jul 2001 14:00:13)
> Brain,
>    I agree with you, I just wanted to confirm this as it was not clear in
> the Draft in terms of implementation wise of AS side. as the Draft always
> talks about dynamic registration of ASPs.
> Thanks
> Satish
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 21 July 2001 13:37
> To: sigtran
> Subject: Re: Dynamic Registration in M3UA
>
>
> Satish,
>
> I think I get what you're driving at, but I don't think that
> the M3UA makes any restrictions here.  It is pretty much up
> to the SGP/ASP to agree.  That said, here's how I think that
> it `could' work:
>
> If, as you say, the Routing Key is not already configured in
> the SGP, and if the AS is not provisioned in the SGP, then
> what will the SGP do when it gets a registration request for
> this "new" Routing Key?
>
> Well, if the Routing Key is supported by the SGP (i.e, the
> SGP is capable of providing traffic and routing on that key)
> and the key doesn't cause a problem for the SGP by overlappping
> with other keys; then, it is possible for the SGP to store
> the key and assign a Routing Context to the key to return
> in the REG RSP.
>
> If, as you say, the AS has not been provisioned, there exists
> no AS object at this time.  The SGP is not really forced to
> create one yet.
>
> Now, say the ASP performs an ASPAC for the Routing Context
> which corresponds to our new Routing Key.  The SGP can create
> an AS object at this time.  The only information that the SGP
> really needs to create the AS object is the Traffic Mode.
>
> The SGP implementation *could* either simply accept the the
> Traffic Mode type presented in the ASPAC, if it is capable
> of supporting that mode, or, the SGP/ASP could have agreed
> `a priori' (that is, they were configured to agree on what
> traffic modes and precise distribution algorithms to use for
> "new" routing keys of this sort).
>
> So, I don't believe that there is anything stopping an SGP
> from dynamically creating an AS based on the Routing Key
> information and local configuration information.  I don't
> think that the SGP needs to be statically configured for all
> the AS that it will support, regardless of the registration
> procedure.
>
>
> There is another way to look at this too.  There is nothing
> stopping the SGP from statically provisioning *all* Routing
> Keys and associating Routing Context and AS information with
> them at provisioning time.  What the registration procedure
> affords in this scenario is being relieved from having to
> match Routing Contexts provisioning in the ASP with that
> of the SGP.
>
> M3UA really doesn't restrict things here.  Kudos to whoever
> proposed it!
>
> --Brian
>
>
> Satish K wrote:                                            (Sat, 21 Jul
2001
> 10:56:53)
> > Brain,
> >    I just wated to confirm one thing ie, we talk about dynamic
> Registration
> > ie Registering new ASPs with New routing key with the AS does it mean we
> can
> > only register the ASPs dynamically and AS are registered Stactically?
> >    What happens when new ASP in New AS tries to register with the SGP?
by
> > new AS i mean this Routing Key is not yet registered in SGP.
> > Thanks
> > Satish
> >
> >
> >
> > ---
> > 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: Sat, 21 Jul 2001 05:56:29 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: Dynamic Registration in M3UA
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Satish,

It might make a good extension draft.

Satish K wrote:                                            (Sat, 21 Jul 2001
15:52:14)
> Brian,
>    I feel this sought of dynamic registration(first come up with default
key
> and later dynamically register with another key) might be required in
m3ua.
>     This might come in use when the AS has data to be carried to other
> destined SGP, which it has not registered now it can register and with the
> default key and send data it need not wait for another new reigstraion.
> Later if required depending on the Traffic it can continue with the new
> Registration key.
> Thanks
> Satish
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 21 July 2001 14:47
> To: sigtran
> Subject: Re: Dynamic Registration in M3UA
> 
> 
> Satish,
> 
> Well... ASPs are really registering "into" one or more AS.
> 
> I thought of another interesting spin on registration.  It
> is completely possible to have the ASP, when it comes up
> with ASPUP have a "default" routing.  But the ASP could
> then do a DEREG REQ against that "default" routing context
> and REG REQ against a different one.  If things were set
> up well, the ASP could use some special value of RC to
> indicate "my default AS", say, 0.
> 
> What's the value in this?  What it permits is provisioning
> a platform so that when it goes down hard, it comes up with
> a default configuration (BOCs would love it) which does not
> require any dynamic registration to get started.  That is
> it would come up static.  Once the platform had stablized,
> it would be possible for ASPs to DEREG and REG to "move"
> traffic around here and there to optimize the platform to
> current conditions (i.e, available processors, load
> balance, time of day/day of week, etc.)
> 
> This would work really well for M2UA where the Signalling
> Data Link allocations at restart need to be fixed at both
> ends of the signalling links, but dynamic allocation of
> Signalling Data Links can do its job after that.
> 
> --Brian
> 
> Satish K wrote:                            (Sat, 21 Jul 2001 14:00:13)
> > Brain,
> >    I agree with you, I just wanted to confirm this as it was not clear
in
> > the Draft in terms of implementation wise of AS side. as the Draft
always
> > talks about dynamic registration of ASPs.
> > Thanks
> > Satish
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: 21 July 2001 13:37
> > To: sigtran
> > Subject: Re: Dynamic Registration in M3UA
> >
> >
> > Satish,
> >
> > I think I get what you're driving at, but I don't think that
> > the M3UA makes any restrictions here.  It is pretty much up
> > to the SGP/ASP to agree.  That said, here's how I think that
> > it `could' work:
> >
> > If, as you say, the Routing Key is not already configured in
> > the SGP, and if the AS is not provisioned in the SGP, then
> > what will the SGP do when it gets a registration request for
> > this "new" Routing Key?
> >
> > Well, if the Routing Key is supported by the SGP (i.e, the
> > SGP is capable of providing traffic and routing on that key)
> > and the key doesn't cause a problem for the SGP by overlappping
> > with other keys; then, it is possible for the SGP to store
> > the key and assign a Routing Context to the key to return
> > in the REG RSP.
> >
> > If, as you say, the AS has not been provisioned, there exists
> > no AS object at this time.  The SGP is not really forced to
> > create one yet.
> >
> > Now, say the ASP performs an ASPAC for the Routing Context
> > which corresponds to our new Routing Key.  The SGP can create
> > an AS object at this time.  The only information that the SGP
> > really needs to create the AS object is the Traffic Mode.
> >
> > The SGP implementation *could* either simply accept the the
> > Traffic Mode type presented in the ASPAC, if it is capable
> > of supporting that mode, or, the SGP/ASP could have agreed
> > `a priori' (that is, they were configured to agree on what
> > traffic modes and precise distribution algorithms to use for
> > "new" routing keys of this sort).
> >
> > So, I don't believe that there is anything stopping an SGP
> > from dynamically creating an AS based on the Routing Key
> > information and local configuration information.  I don't
> > think that the SGP needs to be statically configured for all
> > the AS that it will support, regardless of the registration
> > procedure.
> >
> >
> > There is another way to look at this too.  There is nothing
> > stopping the SGP from statically provisioning *all* Routing
> > Keys and associating Routing Context and AS information with
> > them at provisioning time.  What the registration procedure
> > affords in this scenario is being relieved from having to
> > match Routing Contexts provisioning in the ASP with that
> > of the SGP.
> >
> > M3UA really doesn't restrict things here.  Kudos to whoever
> > proposed it!
> >
> > --Brian
> >
> >
> > Satish K wrote:                                            (Sat, 21 Jul
> 2001
> > 10:56:53)
> > > Brain,
> > >    I just wated to confirm one thing ie, we talk about dynamic
> > Registration
> > > ie Registering new ASPs with New routing key with the AS does it mean
we
> > can
> > > only register the ASPs dynamically and AS are registered Stactically?
> > >    What happens when new ASP in New AS tries to register with the SGP?
> by
> > > new AS i mean this Routing Key is not yet registered in SGP.
> > > Thanks
> > > Satish
> > >
> > >
> > >
> > > ---
> > > 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: Sat, 21 Jul 2001 06:02:27 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Ken Morneault <[email-masked]>
Subject: M2UA-09: Traffic Mode
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 
                      GAA07644
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-205.dallas.net [209.44.42.205]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Not really an issue, but since Traffic Mode is a common parameter could we
line up the UAs on codepoints, even if all the values are not used?  The
only conflicting codepoint is M2UA with Broadcast as 0x3.  If Broadcast mode
is made 0x5 then there is no conflicts.

Suggest we change:

	0x3	    Broadcast
to 
	0x5	    Broadcast

--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: Sat, 21 Jul 2001 07:45:40 -0700 (PDT)
From: selvam veeraraghavan <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: subscribe SIGTRAN
X-Mailer: Excite Inbox
X-Sender-Ip: 198.205.33.111
X-SMTP-HELO: fortune.excite.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [198.3.99.203]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

      subscribe SIGTRAN
v.selvam
Software Engineer,
Axes Technologies (I) Pvt. Ltd,
822,20-A,Main Road,
8th Block,Koramangla,
Banglore-95.

_______________________________________________________ Send a cool gift
with your E-Card
http://www.bluemountain.com/giftcenter/

---
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: M3UA (V7) DRST question
Date: Sun, 22 Jul 2001 15:35:51 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: oak.neustar.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.173.53.70]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

John,

you are making a very valid point. 

Klaus

> -----Original Message-----
> From: Schantz, John [mailto:[email-masked]]
> Sent: July 20, 2001 5:38 PM
> To: sigtran
> Subject: FW: M3UA (V7) DRST question
> 
> 
> 
> 
> -----Original Message-----
> From: Schantz, John 
> Sent: Friday, July 20, 2001 9:53 AM
> To: [email-masked]'
> Subject: RE: M3UA (V7) DRST question
> 
> 
> Brian,
> 	I don't think I am reading a lot into "single management view".
> This is the view that all SS7 nodes have today and if any SG wants to
> connect into an SS7 network will need to abide by the same management
> philosophy (it is built into the SS7 protocol).
> 
> 	So you're telling me that a partitioned SG will have a "single
> management view" towards the SS7 network but it will not 
> maintain this view
> for its' SGPs.  You are basically forcing the AS to have more 
> complicated
> management structure because you are not willing to build a 
> node that abides
> by the general philosophy that all other nodes in the network 
> must abide by.
> So you are asking the AS to collect management messages from 
> each SGP, as
> though they are independent nodes, before the AS can then 
> determine the true
> state of a remote destination.  When are you going to stop 
> pushing all of
> your dirty work onto the ASs?  Why is a limited node 
> architecture driving
> the standard?  Who do you think will buy a SG like this 
> (cheap but almost no
> network management functions)?  A small protocol converter 
> per link would be
> better than this, at least it blindly convert the management 
> message and not
> make its presence known.
> 
> 	You can make it OPTIONAL but thank goodness my node will be in
> networks with real SGs.
> 
> John
> 
>  -----Original Message-----
> From: 	Brian F. G. Bidulock [mailto:[email-masked]] 
> Sent:	Thursday, July 19, 2001 4:38 PM
> To:	sigtran
> Subject:	Re: M3UA (V7) DRST question
> 
> John,
> 
> I think that you are reading alot into the "single management view"
> statement, as it is not really defined what this means; but, I
> understand what you are getting at.  Certainly the fact that it is
> possible that an ASP may receive conflicting information from
> individual SGP, it does not preclude building a system which assumes
> this single management view.
> 
> Perhaps a resolution to the situation, for the sake of 
> interoperability,
> is to say the the SG SHOULD present such a single view of 
> availability/
> congestion/restriction status, but that the ASP SHOULD keep 
> track of that
> status on a per-SGP basis.
> 
> Then, if an ASP implementation chooses to rely heavily on a single
> management view from the SG, it must do so with the full understanding
> that it might not interoperate as well with a partionable SG
> implementation.  And, if the SGP implementation chooses to not present
> such a single management view to the ASP, that it might not 
> interoperate
> as well with ASPs which rely upon it.
> 
> That way due warning is given, nothing is precluded, and maximum
> interoperability may result.  Let the implementations solve the
> details.
> 
> Plus, this takes the least amount of text changes, right Greg?
> 
> Comments?
> 
> --Brian
> 
> Schantz, John wrote:                           (Thu, 19 Jul 
> 2001 13:41:44)
> > Brian,
> > 	I will need to read what the changes are but availability and
> > congestion would show up in the status of the 
> 'links/associations', hence
> it
> > is already taken care of.  There is no parallel for 
> restricted for an
> > interface.
> > 
> > 	If you look at the definition of a SG from the M3UA document:
> > 
> > Signalling Gateway - An SG is a signaling agent that 
> receives/sends SCN 
> > native signaling at the edge of the IP network [1].  An SG 
> appears to 
> > the SS7 network as an SS7 Signalling Point.  An SG contains 
> a set of one 
> > or more unique Signalling Gateway Processes, of which one 
> or more is 
> > normally actively processing traffic.  Where an SG contains 
> more than 
> > one SGP, the SG is a logical entity and the contained SGPs must be 
> > coordinated into a single management view to the SS7 
> network and to the 
> > supported Application Servers.
> > 
> > 	Notice the highlighted "single management view", this 
> states to me
> > that the SG has a single management function even if it is 
> composed of
> > multiple SGPs.  We will be supporting multiple ASPs and we 
> will also have
> a
> > single management view of the system and it interfaces.  
> Therefore, if a
> PC
> > is prohibited, allowed, congested, or restricted, only 
> single management
> > message should be sent to its adjacent nodes.  You can not 
> use DUNA, DAVA,
> > SCON, DRST, etc. to manage a single SGP, they are the 
> "single management
> > view" of the SG for destinations.
> > 
> > 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]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Reply-To: [email-masked]
From: Vikas <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: NTFY Insufficient ASP resources active in AS
Date: Mon, 23 Jul 2001 09:01:14 +0530
Organization: Mercury Corporation
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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]
X-Lotus-FromDomain: HSS
From: [email-masked]
To: "sigtran" <[email-masked]>
Date: Mon, 23 Jul 2001 09:17:39 +0530
Subject: M2UA-09 comment #8
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

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

---
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: Updated SUA sent out
Date: Mon, 23 Jul 2001 06:58:50 +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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

> We're not in Last Call yet on SUA!  John is "priming the pump",
> I think.  

Exactly - only Lyndon can make the call for last call.  

Thanks,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 23 Jul 2001 02:04:51 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M3UA and M2UA: ASPTM or BEAT on Stream other than `0'
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, Ken,

The M3UA draft seems to require that ASPSM and ASPTM messages be only sent
on stream `0'.  M2UA has a "SHOULD".

For ASP Inactive Ack messages, however, it is advisable to do just the
opposite: to send them on the stream that corresponds to the Application
Server traffic which is going inactive.  This is because the SGP must ensure
that no traffic to the ASP for the AS going inactive arrives after the ASP
Inactive Ack or it will risk message loss.

One way for an SGP to ensure that no Data messages for the AS after the ASP
Inactive Ack is to stop traffic and send the ASP Inactive Ack on the same
stream as the Data.

This is one case where an ASPTM message need not be sent on stream `0'.

It is also possible for the ASP to ensure that the ASP Inactive message does
not arrive before AS Data by doing the same: placing the ASPIA on the same
stream as it sends AS data.

The same is true for ASP Active Ack from the SGP.  When the SGP sends an ASP
Active Ack on stream `0' immediately followed by Data on the AS stream, the
Data may beat the ASP Active Ack to the ASP, resulting in message loss (the
ASP is required to discard).

The only way to ensure that the ASP Active Ack arrives at the ASP ahead of
the Data, is to place the ASP Active Ack ordered on the same stream with the
Data.

There can be an avantage to putting BEAT messages on an AS Data stream after
witholding traffic on that stream as a way of ensuring that data for the
stream has "cleared" to the UA peer.

I might also point out that all the UAs refer to a "sequenced stream".
There is no such thing in SCTP: any message can be sent for either sequence
or out-of-order delivery.  The stream itself is neither sequenced nor
unsequenced.

M3UA Changes:

    Section 4.2.3

    Change:     "All M3UA Management and ASP State and Traffic
                 Maintenance messages are sent on a sequenced stream to
                 ensure ordering.  SCTP stream `0' is used."

    To:         "All M3UA Management and ASP State and Traffic
                 Maintenance messages, with the exception of BEAT and
                 BEAT Ack messages, SHOULD be sent using sequenced
                 delivery to ensure ordering.  All M3UA Management and
                 ASP State Maintenance messages, with the exception of
                 BEAT and BEAT ACK messages, SHOULD be sent on SCTP
                 stream `0'.  All ASP Traffic Maintenance messages
                 SHOULD be sent on the stream which normally carries the
                 data traffic to which the message applies.  BEAT and
                 BEAT Ack messages MAY be sent using out-of-order
                 delivery, and MAY be sent on any stream."

M2UA Changes:

    Section 4.2.2

    Change:     "All MGMT messages are sent on a sequenced stream to
                 ensure ordering.  SCTP stream '0' SHOULD be used."

    To:         (Note also that the above paragraph is duplicated just
                 before the 4.2.2 section header and then again just
                 before the 4.3 section header.  Delete the first
                 occurence.)

                "All MGMT messages, except BEAT and BEAT Ack, SHOULD be
                 sent with sequenced delivery to ensure ordering.  All
                 MGMT messages, with the exception of ASPTM, BEAT and
                 BEAT Ack messages, SHOULD be sent on SCTP stream `0'.
                 All ASPTM messages SHOULD be sent on the stream which
                 normally carries the data traffic to which the message
                 applies.  BEAT and BEAT Ack messages MAY be sent using
                 out-of-order delivery, and MAY be sent on any stream."

    Section 4.3.3

    Change:     "All ASPM messages are sent on a sequenced stream to
                 ensure ordering.  SCTP stream '0' SHOULD be used."

    To:         "All ASPM messages, except BEAT and BEAT Ack, SHOULD be
                 sent using sequenced delivery to ensure ordering.  All
                 ASPSM messages, except BEAT and BEAT Ack, SHOULD be
                 sent on SCTP stream `0'.  All ASPTM messages SHOULD be
                 sent on the stream which normally carries the data
                 traffic to which the message applies.  BEAT and BEAT
                 Ack messages MAY be sent using out-of-order delivery,
                 and MAY be sent on any stream."

Actually, ERR or NTFY messages which do not indicate AS State Change SHOULD
be sent using out-of-order delivery, if the use of out-of-order delivery
will expedite the message.

Perhaps it would be an idea to split these recommendations up and place them
in the sections closer to the actual messages.  Pehaps where they are
defined.  To summarize:

    Msg         Delivery Option      Stream

    NTFY(AS)    sequenced (SHOULD)   Stream `0' (SHOULD)
    ASPUP       sequenced (SHOULD)   Stream `0' (SHOULD)
    ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
    ASPDN       sequenced (SHOULD)   Stream `0' (SHOULD)
    ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)

    ERR         out-of-order (MAY)   Stream `0' (SHOULD)
    NTFY(Fail)  out-of-order (MAY)   Stream `0' (SHOULD)

    BEAT        out-of-order (MAY)   Any Stream (MAY)
    BEAT Ack    out-of-order (MAY)   Any Stream (MAY)

    NTFY(Alt)   sequenced (SHOULD)   Stream with DATA (SHOULD)
    ASPAC       sequenced (SHOULD)   Stream with DATA (SHOULD)
    ASPAC Ack   sequenced (SHOULD)   Stream with DATA (SHOULD)
    ASPIA       sequenced (SHOULD)   Stream with DATA (SHOULD)
    ASPIA Ack   sequenced (SHOULD)   Stream with DATA (SHOULD)

--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, 23 Jul 2001 02:33:18 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M3UA: Ordering of DUNA, DAVA, SCON
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 
                      CAA20638
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]>

Greg,

While on the topic of ordering and stream numbers, lets attack this issue
again:

Section 4.3.1:

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

    To:         "DUPU, DAUD, DUNA, DAVA, SCON, and DRST messages MAY be
		 sent using SCTP Unordered delivery, and SHOULD be sent
		 on SCTP stream `0'."

These messages TFA, TFP, TFR and TFC to which these M3UA messages correspond
are sent unordered in the SS7 network.  (Yes, there is an OPTION to send
them all on SLS 0, but it is not required.) Because TFA, TFP, TFR and TFC
may arrive in the wrong order at the SG, the SG should be prepared to deal
with ASPs that receive them in the wrong order in the same way that it deals
with other Signalling Points in the SS7 network that get them in the wrong
order: responsive methods and routeset tests.

There is nothing in the specification stopping an ASP which is concerned
with out of order delivery from performing periodic DAUD inquiries of routes
which are prohibited, restricted or congested to assure itself of the state
of route.  In addition, the MTP even expects this of its Users.

--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: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Mon, 23 Jul 2001 13:18:58 +0530
Subject: Re: SUA-06: Segmentation/Reassembly/Sequencing
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 ,

Please see some comments below ..

With Regards,
-Sandeep

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

Please respond to [email-masked]

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

Subject:  Re: SUA-06: Segmentation/Reassembly/Sequencing

Sandeep,

Please see comments below...

[email-masked] wrote:                            (Sat, 21 Jul 2001
11:44:17)
> Hi Brian ,
    .. [chip]
>
>
> However, for DT1 and DT2, N-DATA does support
> partial delivery (with a more flag, much like
> the use of MSG_EOR in SCTP socket).
>
>
> Sandeep>> I am copying text from section 3.5.3 of Q.714 where
> segmentation/reassembly procedures of connection oriented protocol classes
are
> listed. It does not state any where that SCCP connection control procedure
can
> pass data to SCCP-User without completely reassembling it.
>
> "3.5.3  Segmenting and reassembly ( Q.714)
> During the data transfer phase, the N-DATA request primitive is used to
request
> transfer of octet-aligned data (NSDUs) on a signalling connection. NSDUs
longer
> than 255 octets must be segmented before insertion into the "data" field
of a DT
> message.
>
> The  more-data  indicator  (M-bit)  is  used to reassemble an NSDU that
has been
> segmented  for  conveyance in multiple DT messages. The M-bit is set to 1
in all
> DT  messages  except  the  last message whose data field relates to a
particular
> NSDU. In this way, the SCCP can reassemble the NSDU by combining the data
fields
> of  all  DT  messages with the M-bit set to 1 with the following DT
message with
> the M-bit set to 0. The NSDU is then delivered to the SCCP user using the
N-DATA
> indication.  DT  messages in which the M-bit is set to 1 do not
necessarily have
> the maximum length.
>
> Segmentation  and  reassembly are not required if the length of the NSDU
is less
> than or equal to 255 octets."
> I wonder what is that I am missing ??

Ok.  Now go read the normative reference ITU-Q.713 (ISO/IEC 8348) Section 9,
which describes the partial-delivery interface for the NSD and pay
particular attention to the queue model objects "Octets of NS-user-data" and
"End-of-NSDU".  The NPI implements this as (drum roll) the N_MORE_DATA_FLAG
in the N_DATA_IND primitive.

Sandeep >> I copied the follwing text from section 1, recommendation Q.711
"1   Scope and field of application

   ..[chip]

The combination of the MTP and the SCCP is called "network service part"
(NSP).

The  network  service  part follows the principles of the OSI-reference
model as defined  in  Recommendation  X.200,  providing  a subset of the
layer 3 services defined in Recommendation X.213."

Considering point a) and b) below

a) SCCP primitives and procedures does not support partial data delivery

b) SCCP only aims to provides a subset of layer 3 services as per x.213

I  am  assuming  that  not  many  implementation  would  have built partial
data delivery option. What do you think ?? Can you also share what all
SCCP-Users are using or are planning to use this feature??

The necessity of partial delivery of NSDUs in the queueing model is so that
an "Expedited NSDU" object can be, indeed, expedited ahead of "Octets of
NS-user-data".  It would not be expeditious to force an "Expedited NSDU" to
wait for all of the "Octets of NS-user-data" and the "End-of-NSDU" events to
be processed before servicing the ENSDU.

On delivery, most interfaces (e.g. NPI) do not reassemble.  They just copy
the MORE bit right out of the packet into the N_DATA_IND primitive.  Not
only is this efficient, but the connection-oriented procedures provide a
primitive to permit the NS-Provider (SCCP in this case), to "call back"
partial NSDUs: the N-RESET primitive.

This is in full support of the concept of "stream" data, where the
"End-of-NSDU" event may not occur until some arbitrary time in the future.
You can see that this is somewhat TCP-like.  TCP inserts urgent data
mid-stream and most implementations will advance it ahead of waiting data
segments in the write queue.

On the other hand the N-UNITDATA (see Section 19, ISO/IEC 8348) for the
connection-less service has no such partial delivery interface.

The addition to SCCP of secmented NSDU for connection-less service will not
permit a partial-delivery interface to the SCCP-User: because of the "Return
on Error" features of SCCP.  The NSP/NSU interface (N-UNITDATA Request,
N-UNITDATA Indication) provides no mechanism for SCCP to call any partial
pieces back if an error occurs in the reassembly process and an XUDTS needs
be sent.
Because of this NSDUs for connection-less network service have an absolute
maximum and the transfer of larger NSDUs is discouraged because of its
impact on transfer throughput.  You can see that this is somewhat UDP-like.

>
> BTW SCTP can only deliver partial data to its user when it detects that it
has
> run out of buffers while re-assembling a SINGLE message. I can not think
of a
> SS7 application that will ever be sending such a big message that will
consume
> all receiver buffer space !!

That is simply not true.  There is nothing in RFC 2960 precluding an
implementation from from delivering segmented chunks to the user as they
arrive.
Sandeep >> Sectioin 6.9 of RFC 2960
"   Note: If the data receiver runs out of buffer space while still
   waiting for more fragments to complete the re-assembly of the
   message, it should dispatch part of its inbound message through a
   partial delivery API (see Section 10), freeing some of its receive
   buffer space so that the rest of the message may be received."

This is the only place in RFC, where something is being written about
partial delivery mechanism. For me this seems to suggest that only when SCTP
is out of buffers it CAN/SHOULD use partial delivery option.

Even the socket interface provide for this with the MSG_EOR (read:
"End-of-NSDU") flag.  In my socket implementation of SCTP, this is exactly
what it does.  A call to readmsg() can return partial data for the stream,
subsequent reads return more data until the last partial read returns
MSG_EOR.  An full or partial out-of-order chunks can also be delivered
intermingled with the sequenced stream data by using the MSG_URGENT flag to
tell the caller of recvmsg() which partial chunk is returned.  MSG_EOR and
MSG_URGENT indicates the last partial read of out-of-order data.

Sandeep>> Section 3.3 of socket APIs specs ,
draft-ietf-tsvwg-sctpsocket-00.txt "    If the application does not provide
enough buffer space to
    completely receive a data message, MSG_EOR will not be set in
    msg_flags.  Successive reads will consume more of the same message
    until the entire message has been delievered, and MSG_EOR will be
    set.

    If the SCTP stack is running low on buffers, it may partially
    deliver a message. In this case, MSG_EOR will not be set, and more
    calls to recvmsg() will be necessary to completely consume the
    message. Only one message at a time can be partially delivered"

These two paragraphs put more restriction on implementor as per the usage of
MSG_EOR flag. Current specs say nothing about MSG_URGENT flag , flag
MSG_UNORDERED is used to differentiate between ordered and un-ordered
delivery.

The same approach is taken to sendmsg() where a partial write of data does
not set MSG_EOR, and the final partial write does.
Out of order data can be expedited around normal data by moving to setting
MSG_URGENT and advancing partial writes of out-of-order data around normal
data.  The socket semantic even permits expediting out-of-order data around
normal data when multiple writers (processes) share the same socket
descriptor.  Once a partial MSG_URGENT write begins, the implementation
refuses all subsequent ~MSG_URGENT writes with EAGAIN or blocking until the
final MSG_URGENT|MSG_EOR segment is written.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send 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: Mon, 23 Jul 2001 01:01:41 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 i86pc)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M3UA and M2UA: ASPTM or BEAT on Stream other than `0'
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

For M2UA, an ASP will typically handle more than one data stream.
Which non-zero (excuse the hyphen) data stream should be used ?

"Brian F. G. Bidulock" wrote:
> 
> Greg, Ken,
> 
> The M3UA draft seems to require that ASPSM and ASPTM messages be only
> sent on stream `0'.  M2UA has a "SHOULD".
> 
> For ASP Inactive Ack messages, however, it is advisable to do just the
> opposite: to send them on the stream that corresponds to the Application
> Server traffic which is going inactive.  This is because the SGP must
> ensure that no traffic to the ASP for the AS going inactive arrives
> after the ASP Inactive Ack or it will risk message loss.
> 
> One way for an SGP to ensure that no Data messages for the AS after the
> ASP Inactive Ack is to stop traffic and send the ASP Inactive Ack on the
> same stream as the Data.
> 
> This is one case where an ASPTM message need not be sent on stream `0'.
> 
> It is also possible for the ASP to ensure that the ASP Inactive message
> does not arrive before AS Data by doing the same: placing the ASPIA on
> the same stream as it sends AS data.
> 
> The same is true for ASP Active Ack from the SGP.  When the SGP sends an
> ASP Active Ack on stream `0' immediately followed by Data on the AS
> stream, the Data may beat the ASP Active Ack to the ASP, resulting in
> message loss (the ASP is required to discard).
> 
> The only way to ensure that the ASP Active Ack arrives at the ASP ahead
> of the Data, is to place the ASP Active Ack ordered on the same stream
> with the Data.
> 
> There can be an avantage to putting BEAT messages on an AS Data stream
> after witholding traffic on that stream as a way of ensuring that data
> for the stream has "cleared" to the UA peer.
> 
> I might also point out that all the UAs refer to a "sequenced stream".
> There is no such thing in SCTP: any message can be sent for either
> sequence or out-of-order delivery.  The stream itself is neither
> sequenced nor unsequenced.
> 
> M3UA Changes:
> 
>     Section 4.2.3
> 
>     Change:     "All M3UA Management and ASP State and Traffic
>                  Maintenance messages are sent on a sequenced stream to
>                  ensure ordering.  SCTP stream `0' is used."
> 
>     To:         "All M3UA Management and ASP State and Traffic
>                  Maintenance messages, with the exception of BEAT and
>                  BEAT Ack messages, SHOULD be sent using sequenced
>                  delivery to ensure ordering.  All M3UA Management and
>                  ASP State Maintenance messages, with the exception of
>                  BEAT and BEAT ACK messages, SHOULD be sent on SCTP
>                  stream `0'.  All ASP Traffic Maintenance messages
>                  SHOULD be sent on the stream which normally carries the
>                  data traffic to which the message applies.  BEAT and
>                  BEAT Ack messages MAY be sent using out-of-order
>                  delivery, and MAY be sent on any stream."
> 
> M2UA Changes:
> 
>     Section 4.2.2
> 
>     Change:     "All MGMT messages are sent on a sequenced stream to
>                  ensure ordering.  SCTP stream '0' SHOULD be used."
> 
>     To:         (Note also that the above paragraph is duplicated just
>                  before the 4.2.2 section header and then again just
>                  before the 4.3 section header.  Delete the first
>                  occurence.)
> 
>                 "All MGMT messages, except BEAT and BEAT Ack, SHOULD be
>                  sent with sequenced delivery to ensure ordering.  All
>                  MGMT messages, with the exception of ASPTM, BEAT and
>                  BEAT Ack messages, SHOULD be sent on SCTP stream `0'.
>                  All ASPTM messages SHOULD be sent on the stream which
>                  normally carries the data traffic to which the message
>                  applies.  BEAT and BEAT Ack messages MAY be sent using
>                  out-of-order delivery, and MAY be sent on any stream."
> 
>     Section 4.3.3
> 
>     Change:     "All ASPM messages are sent on a sequenced stream to
>                  ensure ordering.  SCTP stream '0' SHOULD be used."
> 
>     To:         "All ASPM messages, except BEAT and BEAT Ack, SHOULD be
>                  sent using sequenced delivery to ensure ordering.  All
>                  ASPSM messages, except BEAT and BEAT Ack, SHOULD be
>                  sent on SCTP stream `0'.  All ASPTM messages SHOULD be
>                  sent on the stream which normally carries the data
>                  traffic to which the message applies.  BEAT and BEAT
>                  Ack messages MAY be sent using out-of-order delivery,
>                  and MAY be sent on any stream."
> 
> 
> Actually, ERR or NTFY messages which do not indicate AS State Change
> SHOULD be sent using out-of-order delivery, if the use of out-of-order
> delivery will expedite the message.
> 
> Perhaps it would be an idea to split these recommendations up and place
> them in the sections closer to the actual messages.  Pehaps where they
> are defined.  To summarize:
> 
>     Msg         Delivery Option      Stream
> 
>     NTFY(AS)    sequenced (SHOULD)   Stream `0' (SHOULD)
>     ASPUP       sequenced (SHOULD)   Stream `0' (SHOULD)
>     ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
>     ASPDN       sequenced (SHOULD)   Stream `0' (SHOULD)
>     ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
> 
>     ERR         out-of-order (MAY)   Stream `0' (SHOULD)
>     NTFY(Fail)  out-of-order (MAY)   Stream `0' (SHOULD)
> 
>     BEAT        out-of-order (MAY)   Any Stream (MAY)
>     BEAT Ack    out-of-order (MAY)   Any Stream (MAY)
> 
>     NTFY(Alt)   sequenced (SHOULD)   Stream with DATA (SHOULD)
>     ASPAC       sequenced (SHOULD)   Stream with DATA (SHOULD)
>     ASPAC Ack   sequenced (SHOULD)   Stream with DATA (SHOULD)
>     ASPIA       sequenced (SHOULD)   Stream with DATA (SHOULD)
>     ASPIA Ack   sequenced (SHOULD)   Stream with DATA (SHOULD)
> 
> --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, 23 Jul 2001 03:20:50 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA and M2UA: ASPTM or BEAT on Stream other than `0'
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]>

Jacob,

That was my only reason for not saying MUST.  In M3UA it is quite possible
to be sending traffic for a single Routing Key over multiple streams to the
ASP as well.  Even if there are multiplex streasm, sending the message on
one of the data streams may serve to push the queue down to SCTP through the
SCTP-ULP interface.

How about MAY?

--Brian

Jacob Heitz wrote:                           (Mon, 23 Jul 2001 01:01:41)
>
> For M2UA, an ASP will typically handle more than one data stream.
> Which non-zero (excuse the hyphen) data stream should be used ?
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Greg, Ken,
> > 
> > The M3UA draft seems to require that ASPSM and ASPTM messages be only
> > sent on stream `0'.  M2UA has a "SHOULD".
> > 
> > For ASP Inactive Ack messages, however, it is advisable to do just the
> > opposite: to send them on the stream that corresponds to the Application
> > Server traffic which is going inactive.  This is because the SGP must
> > ensure that no traffic to the ASP for the AS going inactive arrives
> > after the ASP Inactive Ack or it will risk message loss.
> > 
> > One way for an SGP to ensure that no Data messages for the AS after the
> > ASP Inactive Ack is to stop traffic and send the ASP Inactive Ack on the
> > same stream as the Data.
> > 
> > This is one case where an ASPTM message need not be sent on stream `0'.
> > 
> > It is also possible for the ASP to ensure that the ASP Inactive message
> > does not arrive before AS Data by doing the same: placing the ASPIA on
> > the same stream as it sends AS data.
> > 
> > The same is true for ASP Active Ack from the SGP.  When the SGP sends an
> > ASP Active Ack on stream `0' immediately followed by Data on the AS
> > stream, the Data may beat the ASP Active Ack to the ASP, resulting in
> > message loss (the ASP is required to discard).
> > 
> > The only way to ensure that the ASP Active Ack arrives at the ASP ahead
> > of the Data, is to place the ASP Active Ack ordered on the same stream
> > with the Data.
> > 
> > There can be an avantage to putting BEAT messages on an AS Data stream
> > after witholding traffic on that stream as a way of ensuring that data
> > for the stream has "cleared" to the UA peer.
> > 
> > I might also point out that all the UAs refer to a "sequenced stream".
> > There is no such thing in SCTP: any message can be sent for either
> > sequence or out-of-order delivery.  The stream itself is neither
> > sequenced nor unsequenced.
> > 
> > M3UA Changes:
> > 
> >     Section 4.2.3
> > 
> >     Change:     "All M3UA Management and ASP State and Traffic
> >                  Maintenance messages are sent on a sequenced stream to
> >                  ensure ordering.  SCTP stream `0' is used."
> > 
> >     To:         "All M3UA Management and ASP State and Traffic
> >                  Maintenance messages, with the exception of BEAT and
> >                  BEAT Ack messages, SHOULD be sent using sequenced
> >                  delivery to ensure ordering.  All M3UA Management and
> >                  ASP State Maintenance messages, with the exception of
> >                  BEAT and BEAT ACK messages, SHOULD be sent on SCTP
> >                  stream `0'.  All ASP Traffic Maintenance messages
> >                  SHOULD be sent on the stream which normally carries the
> >                  data traffic to which the message applies.  BEAT and
> >                  BEAT Ack messages MAY be sent using out-of-order
> >                  delivery, and MAY be sent on any stream."
> > 
> > M2UA Changes:
> > 
> >     Section 4.2.2
> > 
> >     Change:     "All MGMT messages are sent on a sequenced stream to
> >                  ensure ordering.  SCTP stream '0' SHOULD be used."
> > 
> >     To:         (Note also that the above paragraph is duplicated just
> >                  before the 4.2.2 section header and then again just
> >                  before the 4.3 section header.  Delete the first
> >                  occurence.)
> > 
> >                 "All MGMT messages, except BEAT and BEAT Ack, SHOULD be
> >                  sent with sequenced delivery to ensure ordering.  All
> >                  MGMT messages, with the exception of ASPTM, BEAT and
> >                  BEAT Ack messages, SHOULD be sent on SCTP stream `0'.
> >                  All ASPTM messages SHOULD be sent on the stream which
> >                  normally carries the data traffic to which the message
> >                  applies.  BEAT and BEAT Ack messages MAY be sent using
> >                  out-of-order delivery, and MAY be sent on any stream."
> > 
> >     Section 4.3.3
> > 
> >     Change:     "All ASPM messages are sent on a sequenced stream to
> >                  ensure ordering.  SCTP stream '0' SHOULD be used."
> > 
> >     To:         "All ASPM messages, except BEAT and BEAT Ack, SHOULD be
> >                  sent using sequenced delivery to ensure ordering.  All
> >                  ASPSM messages, except BEAT and BEAT Ack, SHOULD be
> >                  sent on SCTP stream `0'.  All ASPTM messages SHOULD be
> >                  sent on the stream which normally carries the data
> >                  traffic to which the message applies.  BEAT and BEAT
> >                  Ack messages MAY be sent using out-of-order delivery,
> >                  and MAY be sent on any stream."
> > 
> > 
> > Actually, ERR or NTFY messages which do not indicate AS State Change
> > SHOULD be sent using out-of-order delivery, if the use of out-of-order
> > delivery will expedite the message.
> > 
> > Perhaps it would be an idea to split these recommendations up and place
> > them in the sections closer to the actual messages.  Pehaps where they
> > are defined.  To summarize:
> > 
> >     Msg         Delivery Option      Stream
> > 
> >     NTFY(AS)    sequenced (SHOULD)   Stream `0' (SHOULD)
> >     ASPUP       sequenced (SHOULD)   Stream `0' (SHOULD)
> >     ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
> >     ASPDN       sequenced (SHOULD)   Stream `0' (SHOULD)
> >     ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
> > 
> >     ERR         out-of-order (MAY)   Stream `0' (SHOULD)
> >     NTFY(Fail)  out-of-order (MAY)   Stream `0' (SHOULD)
> > 
> >     BEAT        out-of-order (MAY)   Any Stream (MAY)
> >     BEAT Ack    out-of-order (MAY)   Any Stream (MAY)
> > 
> >     NTFY(Alt)   sequenced (SHOULD)   Stream with DATA (SHOULD)
> >     ASPAC       sequenced (SHOULD)   Stream with DATA (SHOULD)
> >     ASPAC Ack   sequenced (SHOULD)   Stream with DATA (SHOULD)
> >     ASPIA       sequenced (SHOULD)   Stream with DATA (SHOULD)
> >     ASPIA Ack   sequenced (SHOULD)   Stream with DATA (SHOULD)
> > 
> > --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: Mon, 23 Jul 2001 03:43:54 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA-06: Segmentation/Reassembly/Sequencing
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]>

Sandeep,

Please see comments below...

[email-masked] wrote:             (Mon, 23 Jul 2001 13:18:58)

[snip]
> 
> Sandeep >> I copied the follwing text from section 1, recommendation Q.711
> "1   Scope and field of application
> 
>    ..[chip]
> 
> The combination of the MTP and the SCCP is called "network service part"
(NSP).
> 
> The  network  service  part follows the principles of the OSI-reference
model as
> defined  in  Recommendation  X.200,  providing  a subset of the layer 3
services
> defined in Recommendation X.213."
> 
> Considering point a) and b) below
> 
> a) SCCP primitives and procedures does not support partial data delivery
> 
> b) SCCP only aims to provides a subset of layer 3 services as per x.213
> 
> I  am  assuming  that  not  many  implementation  would  have built
partial data
> delivery option. What do you think ?? Can you also share what all
SCCP-Users are
> using or are planning to use this feature??
> 
[snip]

My SCCP implementation using the NPI supports partial delivery.
There is nothing in the SCCP spec which precludes it and the NSP supports
it.

I am anticipating the Wireless guys wanting to stream web pages over
connection-oriented SCCP any day now...

[snip]
>> 
>> That is simply not true.  There is nothing in RFC 2960 precluding
>> an implementation from from delivering segmented chunks to the user
>> as they arrive.
>>
> Sandeep >> Sectioin 6.9 of RFC 2960
> "   Note: If the data receiver runs out of buffer space while still
>    waiting for more fragments to complete the re-assembly of the
>    message, it should dispatch part of its inbound message through a
>    partial delivery API (see Section 10), freeing some of its receive
>    buffer space so that the rest of the message may be received."
> 
> This is the only place in RFC, where something is being written about
partial
> delivery mechanism. For me this seems to suggest that only when SCTP is
out of
> buffers it CAN/SHOULD use partial delivery option.
> 
[snip]

This is a note.  I see no "SHOULD MUST" words there.  My SCTP implementation
supports partial delivery.

[snip]
> 
> Sandeep>> Section 3.3 of socket APIs specs ,
draft-ietf-tsvwg-sctpsocket-00.txt
> "    If the application does not provide enough buffer space to
>     completely receive a data message, MSG_EOR will not be set in
>     msg_flags.  Successive reads will consume more of the same message
>     until the entire message has been delievered, and MSG_EOR will be
>     set.
> 
>     If the SCTP stack is running low on buffers, it may partially
>     deliver a message. In this case, MSG_EOR will not be set, and more
>     calls to recvmsg() will be necessary to completely consume the
>     message. Only one message at a time can be partially delivered"
> 
> These two paragraphs put more restriction on implementor as per the usage
of
> MSG_EOR flag. Current specs say nothing about MSG_URGENT flag , flag
> MSG_UNORDERED is used to differentiate between ordered and un-ordered
delivery.
[snip]

draft-ietf-tsvwg-sctpsocket-00.txt is an informational draft.  It is not
BSD, SVR4, POSIX, XPG4, OpenGroup, or anthing for that matter.

And, sorry, I meant "MSG_URG".  There is no defined flag named
MSG_UNORDERED.  That is a proposal.  I will deal with it at the POSIX
balloting.

Sandeep, if you are going to start reading "MUST NOT support partial
delivery" where an RFC or an information draft makes a note, I can't help
you.  If you want to make your application wait for 3964 bytes to play out
on a 56k link before even seeing the header, go right ahead.

-- 
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, 23 Jul 2001 04:12:12 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>, Ken Morneault <[email-masked]>,
        John Loughney <[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: tnt-dal-42-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv7 comments (OPC mask in RK)
Date: Mon, 23 Jul 2001 11:12:24 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: albatross-ext.wise.edt.ericsson.se [194.237.142.116]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

See comments below
/MCruz

-----Original Message-----
From: BAND,RICHARD (HP-France,ex1) [mailto:[email-masked]] Sent:
Monday, July 09, 2001 3:42 PM
To: sigtran
Subject: M3UAv7 comments

...

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

[MCruz]-------------------------------------------------------------

I think the mask was set to 0 because the RK was defined to 'do not extend
across more than a single SS7 DPC'. But now, according to Brian comment's
and Greg agreement (thread M3UA07 Comments, see below) I think any mask
value should be allowed.

-------------- [from M3UA07 Comments thread]---------------------------
Section 1.2 Terminology, eigth paragraph (Routing Key definition):

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

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

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

[Greg] Done.
]-------------------------------------------------------------

Best Regards,

Richard Band

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send 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, 23 Jul 2001 04:27:26 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv7 comments (OPC mask in RK)
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]>

Maria,

I think those are different "Clusters"... and different point codes.  The
restriction used to be on a DPC, not an OPC.  It makes perfect sense to
register with a routing key which has multiple OPCs (even an ANSI cluster).
I'm sure the mask was an oversight.  It makes even more sense to mask an
entire network for the OPC spec.

--brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 23 Jul 2001
11:12:24)
> Hi all,
> 
> See comments below
> /MCruz
> 
> -----Original Message-----
> From: BAND,RICHARD (HP-France,ex1) [mailto:[email-masked]]
> Sent: Monday, July 09, 2001 3:42 PM
> To: sigtran
> Subject: M3UAv7 comments
> 
> 
> ...
> 
> 2. OPC Masks in Routing Key.
> In the Routing Key format on page 48, the mask for OPC entries in the OPC
> list is always set to 0. Why not use masks to indicate e.g. that I want to
> receive all traffic from a given cluster in an ANSI network?
> 
> [MCruz]-------------------------------------------------------------
> 
> I think the mask was set to 0 because the RK was defined to 'do not
> extend across more than a single SS7 DPC'. But now, according to
> Brian comment's and Greg agreement (thread M3UA07 Comments, see below)
> I think any mask value should be allowed.
> 
> -------------- [from M3UA07 Comments thread]---------------------------
> Section 1.2 Terminology, eigth paragraph (Routing Key definition):
> 
> "Parameters within the Routing Key cannot extend across more
> than a single SS7 Destination Point Code."
> 
>     This statement is too restrictive as it precludes "alias" point
>     codes at the AS/ASP.  Suggest the following rewording:
> 
> Parameters within the Routing Key cannot extend across more
> than a single Signalling Point Management Cluster.
> 
> [Greg] Done.
> ]-------------------------------------------------------------
> 
> Best Regards,
> 
> Richard Band
> 
> 
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> To unsubscribe send 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, 23 Jul 2001 04:36:39 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA: Packing of Routing Label into DATA Payload
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,

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.

2.  The SGP will need to unpack the routing label again to
    perform the routing function on the message.  (Yes, I know,
    Al Varney said it just has to be "examined," but I'd like to
    see his code for "examining" the point codes in the routing
    lable without unpacking them--particularly for ITU point
    code.)

3.  When sending to the ASP, the SGP will have unpacked RL
    information upon which to apply the Routing Key.

4.  For IPSP operation where one of the ISPS has no direct
    interworking to the SS7 network, packing the routing label
    pushes the IPSP to be artificially assigned a "Point Code"
    and a routing label format.  That is, there is no defined
    routing label format for an IPSP.

5.  The packing/unpacking of RL information is in the
    performance critical data paths of both an SG and an ASP:
    leaving them unpacked in the message will improve SG
    performance.

6.  Monitoring boxes need to know the routing label format
    of each data message to display the message contents.  By
    placing them unpacked in parameters relieves the monitoring
    box of correlating the data message with static
    configuration data unknown to the monitoring box.

7.  M3UA DATA are the only UA messages in the entire set of
    drafts which packs the parameters of an SS7 Primitive into
    a rather arbitrarily bit-encoded field.  (SUA even pulls
    apart Global Title which is comparable to routing label
    and arguably less unpacked in the primitives.)

8.  Packing the RL into the data payload makes it difficult to
    implement M3UA over third-party commercial SS7 MTP stacks
    which unpack the RL in their user interfaces.

9.  Unpacked routing label information as parameters in the DATA
    message would obviate the need for distinguishing TTC data
    from other variants (MP carried in unpacked parameters).

I could go on ;) but that's a start.

I would like to propose, again, placing the parameters of the MTP-TRANSFER
primitive into parameters in the DATA message rather than packing them into
the DATA Payload.

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]
Date: Mon, 23 Jul 2001 06:06:33 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: 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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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]
From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Mon, 23 Jul 2001 17:00:33 +0530
Subject: Re: SUA-06: Segmentation/Reassembly/Sequencing
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]

Brian ,

Please see some comments below ..

With Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 07/23/2001 03:13:54 PM

Please respond to [email-masked]

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

Subject:  Re: SUA-06: Segmentation/Reassembly/Sequencing

Sandeep,

Please see comments below...

[email-masked] wrote:             (Mon, 23 Jul 2001 13:18:58)

[snip]
>
> Sandeep >> I copied the follwing text from section 1, recommendation Q.711
> "1   Scope and field of application
>
>    ..[chip]
>
> The combination of the MTP and the SCCP is called "network service part"
(NSP).
>
> The  network  service  part follows the principles of the OSI-reference
model as
> defined  in  Recommendation  X.200,  providing  a subset of the layer 3
services
> defined in Recommendation X.213."
>
> Considering point a) and b) below
>
> a) SCCP primitives and procedures does not support partial data delivery
>
> b) SCCP only aims to provides a subset of layer 3 services as per x.213
>
> I  am  assuming  that  not  many  implementation  would  have built
partial data
> delivery option. What do you think ?? Can you also share what all
SCCP-Users are
> using or are planning to use this feature??
>
[snip]

My SCCP implementation using the NPI supports partial delivery.
There is nothing in the SCCP spec which precludes it and the NSP supports
it.

I am anticipating the Wireless guys wanting to stream web pages over
connection-oriented SCCP any day now...

Sandeep >> Ok , Let me go back to the question I started with. The question
was why do we need segmentation/reassembly procedures in SUA. The argument
was that since SCCP can deliver partial data to its users at SG , SUA need
to support segmentation/reassembly procedures. From the above discussion,
can I conclude that
a) SCCP primitives and procedures does not support partial data delivery b)
No Current SCCP Users are using this feature ( Some may do it in future ) c)
SCCP does not disallow implementations to built this feature and taking
reference from X,213 some implementations MIGHT have built support for this
feature.

If above three conclusions are correct , I do not find a strong reason for
building a complicated segmentation/reassembly procedure in SUA. For
implementations that support partial delivery , SUA can pass those messages
as such to its users.
Comments !!

[snip]
>>
>> That is simply not true.  There is nothing in RFC 2960 precluding
>> an implementation from from delivering segmented chunks to the user
>> as they arrive.
>>
> Sandeep >> Sectioin 6.9 of RFC 2960
> "   Note: If the data receiver runs out of buffer space while still
>    waiting for more fragments to complete the re-assembly of the
>    message, it should dispatch part of its inbound message through a
>    partial delivery API (see Section 10), freeing some of its receive
>    buffer space so that the rest of the message may be received."
>
> This is the only place in RFC, where something is being written about
partial
> delivery mechanism. For me this seems to suggest that only when SCTP is
out of
> buffers it CAN/SHOULD use partial delivery option.
>
[snip]

This is a note.  I see no "SHOULD MUST" words there.  My SCTP implementation
supports partial delivery.

[snip]
>
> Sandeep>> Section 3.3 of socket APIs specs ,
draft-ietf-tsvwg-sctpsocket-00.txt
> "    If the application does not provide enough buffer space to
>     completely receive a data message, MSG_EOR will not be set in
>     msg_flags.  Successive reads will consume more of the same message
>     until the entire message has been delievered, and MSG_EOR will be
>     set.
>
>     If the SCTP stack is running low on buffers, it may partially
>     deliver a message. In this case, MSG_EOR will not be set, and more
>     calls to recvmsg() will be necessary to completely consume the
>     message. Only one message at a time can be partially delivered"
>
> These two paragraphs put more restriction on implementor as per the usage
of
> MSG_EOR flag. Current specs say nothing about MSG_URGENT flag , flag
> MSG_UNORDERED is used to differentiate between ordered and un-ordered
delivery.
[snip]

draft-ietf-tsvwg-sctpsocket-00.txt is an informational draft.  It is not
BSD, SVR4, POSIX, XPG4, OpenGroup, or anthing for that matter.

And, sorry, I meant "MSG_URG".  There is no defined flag named
MSG_UNORDERED.  That is a proposal.  I will deal with it at the POSIX
balloting.

Sandeep, if you are going to start reading "MUST NOT support partial
delivery" where an RFC or an information draft makes a note, I can't help
you.  If you want to make your application wait for 3964 bytes to play out
on a 56k link before even seeing the header, go right ahead.

Sandeep >> Brian , I am not arguing on the importance of partial delivery
option. This is certainly a very important feature for some applications.
But at the same time , in my understanding there will be applications (a lot
of them), which will require SCTP to hide these details from them. (like
Sigtran Udaptation layers, which expect SCTP to pass them the complete
message). For supporting these two types of applications at the same time,
some procedural support is needed from SCTP. For example SCTP need to know,
if an application is capable of reassembly, the reassembly timer for
application etc. In absence of this support, we have built the most obvious
thing, i.e. pass partial data to user when you have no other option ( you
are out of buffers ).

--
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, 23 Jul 2001 06:41:09 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: 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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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]
Date: Mon, 23 Jul 2001 06:57:22 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: M3UA07: Question: Routing Key/Context Restriction
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,

Is there any reason why a Routing Context needs to be restricted to
represent only one Routing Key?

I am thinking of the case where the MGC represents and international gateway
and has point codes in two Network Appearances, but still represents a
single Application Server from the viewpoint of AS_STATE.

Why, in this case, couldn't the ASP register against multiple Routing Keys
for the same Routing Context/Application Server?

--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, 23 Jul 2001 07:24:32 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA-06: Segmentation/Reassembly/Sequencing
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]>

Sandeep,

Comments below....

[email-masked] wrote:             (Mon, 23 Jul 2001 17:00:33)

[snip]
> 
> Sandeep >> Ok , Let me go back to the question I started with. The
question was
> why do we need segmentation/reassembly procedures in SUA. The argument was
that
> since SCCP can deliver partial data to its users at SG , SUA need to
support
> segmentation/reassembly procedures. From the above discussion, can I
conclude
> that
> a) SCCP primitives and procedures does not support partial data delivery
> b) No Current SCCP Users are using this feature ( Some may do it in future
)
> c) SCCP does not disallow implementations to built this feature and taking
> reference from X,213 some implementations MIGHT have built support for
this
> feature.
> 
> If above three conclusions are correct , I do not find a strong reason for
> building a complicated segmentation/reassembly procedure in SUA. For
> implementations that support partial delivery , SUA can pass those
messages as
> such to its users.
> Comments !!
[snip]

Please reference my orignal note on this thread.  There is no question that
SUA must support segementing/sequencing/reassembly.
It is required for all protocol classes.  The original issues was whether it
could be performed at the SGP as required by the 06 draft.  The analysis and
conclusions are summarized in the original note.

For class 2 and 3 operation (connection-oriented with more-bit), the ASP
MUST be responsible for segmentation/sequencing/reassembly when the SG is
acting as a relay node, regardless of how messages are actually delivered to
the SCCP-User.  This is because when acting as a relay node in multiple SG
configurations, the SG is incapable of properly performing reassembly for
class 2 and reassembly/sequencing for class 3.

This has *nothing* to do with how SCTP deliveres messages to ULP.

If the SCCP-User at the ASP supports partial delivery (as mine does), then
the SUA at the ASP will not have to perform reassembly.  If the SCCP-User at
the ASP does not support partial delivery, then the SUA at_the_ASP
(not_the_SGP) will have to support reassembly for classes 2 and 3.  The SUA
at the ASP will, regardless, have to support sequencing.

For class 0 and 1 operation the SGP MUST be responsible for segmentation/
reassembly as per the draft.  The SGP is required to support segementation
reassembly as a relay node anyway.  For classes 0 and 1 it does not matter
that changeovers in the network disrupt the reassembly.  Class 0 and 1 are
equipped with unitdata-service procedures for segmentation/reassembly which
is distrupted by changeovers.

However, for classes 0 and 1, the SGP is incapcable of generating a unique
source segmentation reference necessary for the process.  This must be
assigned at the source (in this case at the ASP).  Therefore, this must be
included in the CLDT message and generated by the ASP.

The only difference is:

	a)  Shifting responsibility from SGP to ASP for classes
	    2 and 3.

	b)  Adding source segementation reference parameter to
	    CLDT generated by ASP.

[snip]
> 
> Sandeep >> Brian , I am not arguing on the importance of partial delivery
> option. This is certainly a very important feature for some applications.
But at
> the same time , in my understanding there will be applications (a lot of
them),
> which will require SCTP to hide these details from them. (like Sigtran
> Udaptation layers, which expect SCTP to pass them the complete message).
For
> supporting these two types of applications at the same time, some
procedural
> support is needed from SCTP. For example SCTP need to know, if an
application is
> capable of reassembly, the reassembly timer for application etc. In
absence of
> this support, we have built the most obvious thing, i.e. pass partial data
to
> user when you have no other option ( you are out of buffers ).
> 
[snip]

Consider compatibility with TCP, which always delivers partial data:
streamed data is like one big record which doesn't end until the
communication ends.

--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, 23 Jul 2001 07:42:20 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA-09 comment #8
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]>

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]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07 Comments
Date: Mon, 23 Jul 2001 14:50:15 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: albatross-ext.wise.edt.ericsson.se [194.237.142.116]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

See comments below
/MCruz

-----Original Message-----
From: Greg Sidebottom [mailto:[email-masked]] Sent: Friday, July 20, 2001
12:12 PM
To: sigtran
Subject: Re: M3UA07 Comments

.
.
.

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

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

    What is this supposed to mean?

[Greg] Gone.

[MCruz] Didn't you mean that a RK can not extend across more than a single
Network Appearance?? If you agree, let's add this to the RK definition.

Section 1.2 Terminology, eighteenth paragraph (Host definition):

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

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

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

[Greg] Done.

[MCruz] Also IPSP. I think in most places IPSP is missed, it is actually not
that easy to understand from the draft IPSP tasks and behaviour.

Section 1.4.2.1

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

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

[Greg] OK.  I put brackets in to make this clearer:  "or MTP3-User specific
fields (such as the ISUP CIC, SCCP subsystem number) or TCAP transaction
ID."

[MCruz] TCAP transaction ID is not specified within the RK format. If those
parameters are only examples and some others could be valid, then there
should be the chance to have then included within the RK parameter format.

Regards
/MCruz

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 23 Jul 2001 07:50:56 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: [M3UA, SUA]: Gracefull shutdown 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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

All,

Is there any way in the existing M3UA, SUA procedures to peform a graceful
shutdown of an SGP which has active ASPs?

Say that, for maintenance purposes, I want to take one of a number of SGP
out of service.  Can this be performed at the SG?  Or, does one need to tell
the ASPs to remove traffic from the SGP first?

What would be advantageous would be a procedure whereby the SGP can notify
ASPs to which it has associations that it is about to go out of service.
That way, when a card is about to be pulled at the SG, the ASPs can
gracefully reconfigure themselves on the remaining SGP before the card is
pulled.

--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, 23 Jul 2001 14:55:09 +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]>
Subject: Re: agenda for London
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: albatross-ext.wise.edt.ericsson.se [194.237.142.116]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi Lyndon,
    I'm back from my vacation and I'm reading the emails. Regarding this one
related to the agenda, the M3UA MIB cannot be discussed since due to the
cost restriction, Antonio won't be abe to attend the meeting.

br,
MCarmen

Lyndon Ong wrote:

> Folks,
>
> Here's a proposed agenda for London, we meet on Tuesday afternoon, for 1
hour only.  Please send me your comments.
>
> -- Intro and Agenda Bash (5 min.)
> -- Status of SCTP, M3UA, M2UA and AS (10 min.)
> -- Status of SUA and M2PA (10 min.)
> -- V5UA Discussion (5 min.)
> -- DUA (IUA extension) Discussion (5 min.)
> -- MIB Status Update (10 min.)
> -- Bakeoff planning (10 min.)
> -- Other issues (5 min.)
>
> The documents are:
> - draft-ietf-sigtran-m3ua-08.txt (to be published)
> - draft-ietf-sigtran-m2ua-09.txt
> - draft-ietf-sigtran-sua-07.txt (to be published)
> - draft-ietf-sigtran-m2pa-03.txt (to be published)
> - draft-ietf-sigtran-v5ua-01.txt
> - draft-anil-sigtran-dua-01.txt (to be published)
> - draft-ietf-sigtran-sctp-mib-04.txt
> - draft-sigtran-m3ua-mib-01.txt
>
> 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\emecbv1.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Garnero, Pierre" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA (V7) DRST question
Date: Mon, 23 Jul 2001 14:56:42 +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]

Hello Brian,

first, thanks for your response.
It is very useful and we (Francois and myself) understand much better how
M3UA works.

Then, ... my comments below:

Cheers,

Pierre

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, July 20, 2001 10:28 PM
> To: sigtran
> Subject: Re: M3UA (V7) DRST question
> 
> 
> Francois,
> 
> I'm sorry, I didn't realize from the diagram that the SGPs had the
> same point code.  I suppose it was because R1/R2 looked like the
> way we normally draw B/D links and R3, A links.  If what you are
> saying is that all the links from the SG in the SS7 network are
> A-Links, then your drawing exactly fits the case we were discussing.
> 
> Please see comments below...
> 
> Zannin, Francois wrote:                                   
> (Fri, 20 Jul 2001 21:00:19)
> > Brian,
> > 
> > Thank's for your answer.
> > 
> > In my configuration, i'm talking about a SG seen as an 
> unique Signaling
> > point code by the ss7 network and distributed between 
> several SGP for high
> > availability of the SG.
> > 
> > The route's links are also distributed in all the SPG in 
> order to always
> > have some links available on all routes if one SGP fails.
> > 
> > Because the SG is seen as a single SP by the ss7 network, 
> all SGP are
> > managed as an unique SG entity.
> > This involve a communication between the several SGP.
> > 
> > What could be the behavior of this kind of configuration in case of
> > communication problem between the SGP?
> > 
> > Regards,
> > 
> > Francois Z.
> > 
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Friday, July 20, 2001 6:07 PM
> > To: sigtran
> > Subject: Re: M3UA (V7) DRST question
> > 
> > 
> > Francois,
> > 
> > I think from the discussion so far that the SGPs in your
> > diagram would be considered to be three separate SGs,
> > rather than a single SG as you have drawn it.
> > 
> > I believe the dicussion is focussing on multiple SGPs in
> > an SG which represents a single SPMC or a single point code.
> > 
> > --Brian
> > 
> > 
> > Zannin, Francois wrote:                                   
> (Fri, 20 Jul 2001
> > 16:31:31)
> > > Hello,
> > > 
> > > This is our understanding of the use of the DRST and 
> partitioning between
> > > the SGP.
> > > See below,
> > > Do you agree with this?
> > > 
> > >     Regards,
> > >     Francois Z.
> > > 
> > >
> > 
> 00000000011111111112222222222333333333344444444445555555555666
> 66666667777777
> > > 7778
> > >
> > 
> 12345678901234567890123456789012345678901234567890123456789012
> 34567890123456
> > > 7890
> > > 
> > >      SS7 World                              IP World
> > >  ============================          =================
> > >                                S.G.                       A.S.
> > >                           ..............
> > >  +----+     +-----+ R1    . +-------+  .               +-------+
> > >  |SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |
> > >  +----+     |     |---   ---|       |  .    ----[As1]--| ASP_1 |
> > >             +-----+   \ / . +---++--+  .   / ---[As2]--|       |
> > >                        \  .     ||     .  / /          +-------+
> > >  +----+     +-----+   / \ . +---++--+  . / /
> > >  |SP_2|-----|STP_B|---   ---| SGP_2 |---- /
> > >  +----+     |     |---------|       |  . /
> > >             +--+--+ R2    . +---++--+  ./
> > >           Clink|          .     ||     / 
> > >  +----+     +--+--+       . +---++--+ /.
> > >  |SP_3|-----|STP_C|---------| SGP_3 |- .
> > >  +----+     |     |---------|       |  .
> > >             +-----+ R3    . +-------+  .
> > >                           ..............
> > > 
> > > In this configuration,
> > > The destination SP_2 can be reached via R2 (STP_B) and if R2 
> > > fails, via R3 (STP_C).
> > > 
> > > ASP_1 is connected to SGP_1 by the association As0 
> > > ASP_1 is connected to SGP_2 by the association As1 
> > > ASP_1 is connected to SGP_3 by the association As2 
> > > 
> > > SP_2 can be reached via STP_B which is connected to SGP_1 and
> > > SGP_2 for redundancy perspective.  ASP_1 will use links As0 and
> > > As1 to send messages to SP_2 and only uses As2 if As0 and As1
> > > fail.
> 
> Ok.
> 
> > > 
> > > With this configuration the DAVA are sent from SGP_1, SGP_2 and
> > > SGP_3 BUT SGP_3 can also send a DRST to inform ASP_1 that it
> > > should use As0 and As1 in priority. This DRST is not the result
> > > of a TFR message.
> 
> Ok. This was what Greg was driving at: use of the DRST to allow
> the SGP to communicate internal inefficiencies to the ASPs.
> 
> > > 
> > > If a TFR is received from STP_B, this information is distributed
> > > to all the SGP and then all the SGP send a DRST to the ASP.
> > > These DRST can be used by the ASP to reroute the traffic on
> > > another SG if there is one available.
> 
> Ok. Makes sense.
> 
> > > 
> > > All the MTP3 information must be distributed to all the SGP
> > > because if the route R2 fails, all the messages already sent
> > > from the ASP to SGP_1 and SGP_2 before the receipt of a DRST
> > > must be forwarded to the SGP_3 for the time controlled diversion
> > > between R2 to R3 or R3 to R2 if R2 restarts.
> 
> I think you mean DUNA here instead of DRST.
> 
No. We means DRST because we think that if the association between ASP_1 and
SGP_3 fails, the ASP must still be able to send traffic to SGP_3 (via an
internal connection between SGP_1 , SGP_2 and SGP_3).
> Here I disagree SGP_1 still has a route to SP_2 and you told us
> that the ASP only uses As0 (until it fails) so the ASP can still
> route as normal.  If by "R2 fails" a double linkset failure at
> STP_B, I can tell you this (a) doesn't happen and (b) even the
> SS7 network is not designed to handle simultaneous double linkset
> failures.
No. Because R2 is prohibited, SGP_1 and SGP_2 are no more able to send
traffic to SP_2.
   R1 is not a route to reach SP_2.
   R2 is prohibited
   R3 is still available but the only links included in the 
   linkset to STP_C are owned by SGP_3 => only SGP_3 is able to send 
   traffic to SP_2.
> 
> Nevertheless, if there is this double link failure, SGP_1 (the
> only one receiving traffic) must transfer buffered and collected
> messages to SGP_3.
> 
> See below...
> 
> > > 
> > > If the platform is partitioned, message sequencing cannot be
> > > performed between the ASP and the ss7 SP. Another problem that
> > > occurs in a partitioned platform is that the network management
> > > messages concerning one route may be sent on another route
> > > because the ss7 network sees the SG as an unique point code.
> > > 
> > > If we chose to have a partitioned platform, we must be sure that
> > > we never will receive management messages on another route then
> > > the one it concerns and this depend of the ss7 network
> > > configuration. 
> > > 
> > > ==================================================================
> > >   ALL THIS BEHAVIOR IS TRUE IF THE SGP ARE DIRECTLY CONNECTED TO 
> > >   THE SS7 NETWORK WITHOUT INTERMEDIATE PROCESSES.
> > > ==================================================================
> > > 
> 
> Your rather artificial example shows excellent reasons why:
> 
> 	1.  We don't build SS7 network that way, and,
> 
> 	2.  We don't build Signalling Gateways that way.
> 
> 
> Here is a real example of a real SS7 network and an
> intelligent partitioned SS7 design: (I'll just borrow
> most of your diagram...)
You are 100% right concerning SS7 in operation but if one day you have the
chance
to go through a complete certification process with a big Telco, you will
see that 
scenarios used to validate an SS7 stack are sometimes tricky and sometimes
not "intelligent"....
... but whatever happens, the SS7 stack must works ... if you want to sell
it, of course :-)

For instance, I don't think that any configuration described in Q.782 are
used "as is" by any
operator in the world but ... if you fail to comply with this specification,
your stack is not
SS7 compliant...
As we would like to build a carrier grade M3UA stack, we need to be sure
that M3UA works
for all the cases.
More: if it is clear that some SS7 configurations are not allowed by SG, it
must be clearly 
indicated in the draft...then, we will save a lot of time :-)
> 
>      SS7 World                              IP World
>  ============================          =================
>                                S.G.                       A.S.
>                           ..............
>  +----+A0   +-----+  L0   . +-------+  .               +-------+
>  |SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |
>  +----+   / |     |-- L1  --|       |  .    ----[As0]--| ASP_1 |
>     A1 \ /  +-----+  \   /. +-------+  .   / ---[As0]--|       |
>      A2 X   /  |   \  \ / .     |      .  / /          +-------+
>  +----+/ \ /   | L2 \  X  . +-------+  . / /
>  |SP_2|   X C-links  \/ ----| SGP_2 |---- /
>  +----+\ / \   |     /\ ----|       |  . /
>      A3 X   \  | L3 /  X  . +-------+  ./
>     A4 / \   \ |   /  / \ .     |      / 
>  +----+   \ +--+--+  /   \. +-------+ /.
>  |SP_3|-----|STP_C|-- L4  --| SGP_3 |- .
>  +----+A5   |     |---------|       |  .
>             +-----+  L5   . +-------+  .
>                           ..............
> 
> 
> Now, in this example the SPs are connected full fishbone, as
> they should.  The links of the linksets between the STPs and the
> SGP are groomed across all SGP, but the SGP still represent a
> signle point code.  ASP_1 is configured/ registered against As0
> for all of the SGP.  ASP_1 uses a distribution algorithm which
> loadshares messages over the available SGP on the basis of SLS.
> 
>      SS7 World                              IP World
>  ============================          =================
>                                S.G.                       A.S.
>                           ..............
>  +----+A0            L0   . +-------+  .               +-------+
>  |SP_1|      STP_A       ---| SGP_1 |-----------[As0]--|       |
>  +----+               L1  --|       |  .    ----[As0]--| ASP_1 |
>     A1 \                 /. +-------+  .   / ---[As0]--|       |
>      A2 X      |        / .     |      .  / /          +-------+
>  +----+  \     | L2    X  . +-------+  . / /
>  |SP_2|   X C-links   /  ---| SGP_2 |---- /
>  +----+\   \   |     /  ----|       |  . /
>      A3 X   \  | L3 /  X  . +-------+  ./
>     A4   \   \ |   /  /   .     |      / 
>  +----+   \ +--+--+  /    . +-------+ /.
>  |SP_3|-----|STP_C|-- L4  --| SGP_3 |- .
>  +----+A5   |     |---------|       |  .
>             +-----+  L5   . +-------+  .
>                           ..............
> 
> 
> Now, let's get blue moon: STP_A fails completely as shown above.
> (Now this takes a natural disaster because STPs are built well.)
> Links L0, L1, and L2 vaporize.  The SG does not even tell the
> ASP.  It changes over traffic from L0->L3, L1->L4 and L2->L5
> without even consulting the ASP.  To perform normal changeover
> may require the transfer of COO/COA between SGP, but that's low
> traffic.  If SGP become partitioned, changeover will still
> complete as emergency changeover.
> 
> Ok, STP_A recovers and we change back.  We had a natural
> disaster and didn't lose a message.
> 
You always suppose that the 2 links on each SGP are available but (for a
carrier grade application of course) you cannot guarantee this.
And then, in the case where L1 is broken, in the previous scenario:
  => you could choose to loose all the messages sent to SGP_1 
     (and this is not a carrier grade behavior)
  => or reroute messages from SGP_1 to another SGP according to there SLS, 
     (but DATA messages must be exchanged between SGP, and here you
      could claim that you respect the SS7 protocol) It is true that if SG
is partionned, emergency changeover will occurs and then you will loose
messages => clearly, this could be avoided if SGPs communicate....
> 
>      SS7 World                              IP World
>  ============================          =================
>                                S.G.                       A.S.
>                           ..............
>  +----+A0   +-----+  L0   . +-------+  .               +-------+
>  |SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |
>  +----+     |     |-- L1  --|       |  .    ----[As0]--| ASP_1 |
>     A1 \    +-----+  \   /. +-------+  .   / ---[As0]--|       |
>      A2 X   /  |   \  \ / .     |      .  / /          +-------+
>  +----+  \ /   | L2 \  X  . +-------+  . / /
>  |SP_2|   X C-links  \/ ----| SGP_2 |---- /
>  +----+\ / \   |     /\ ----|       |  . /
>      A3 X   \  | L3 /  X  . +-------+  ./
>     A4 / \   \ |   /  / \ .     |      / 
>  +----+   \ +--+--+  /   \. +-------+ /.
>  |SP_3|-----|STP_C|-- L4  --| SGP_3 |- .
>  +----+A5   |     |---------|       |  .
>             +-----+  L5   . +-------+  .
>                           ..............
> 
> 
> Now suppose that SP_2 loses link A2 as shown above.  STP_A will
> changeover traffic to SP_2 to its C-links and send a TFR with
> respect to SP_2 on, say, L0.  SGP_1 must communicate the TFR to
> the SGP_2 and SGP_3, but again, that is not traffic.  Then
> SGP_1, SGP_2 and SGP_3 perform controlled rerouting of traffic
> to SP_2 from L0, L1 and L2 to L3, L4 and L5.  The ASP does not
> need to be informed.
> 
> Link A2 recovers.  The SGP's controlled reroute SP_2 traffic
> back to all links.
> 
> 
> 
>      SS7 World                              IP World
>  ============================          =================
>                                S.G.                       A.S.
>                           ..............
>  +----+A0   +-----+  L0   . +-------+  .               +-------+
>  |SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |
>  +----+   / |     |-- L1  --|       |  .    ----[As0]--| ASP_1 |
>     A1 \ /  +-----+      /. +-------+  .   / ---[As0]--|       |
>      A2 X   /  |   \    / .     |      .  / /          +-------+
>  +----+/ \ /   | L2 \  X  . +-------+  . / /
>  |SP_2|   X C-links  \/    -| SGP_2 |---- /
>  +----+\ / \   |     /\    -|       |  . /
>      A3 X   \  | L3 /  X  . +-------+  ./
>     A4 / \   \ |   /    \ .     |      / 
>  +----+   \ +--+--+      \. +-------+ /.
>  |SP_3|-----|STP_C|-- L4  --| SGP_3 |- .
>  +----+A5   |     |---------|       |  .
>             +-----+  L5   . +-------+  .
>                           ..............
> 
> So, now, assume that SGP_2 loses both its links L1 and L4, as
> shown above.  This is a blue moon occurence because L1 and L4
> are space diverse and the probability of dual failure is
> extremely small (it is more likely that SGP_2 will fail).  SGP_2
> does not need to send anything to the ASP.  It ABORTs the
> association.  Because this is a blue moon occurence and the SG
> is acting as an SEP which does not necessarily have to be
> lossless, SGP_2 could optionally discard any collected or
> buffered messages.  It could also transfer half of them (by SLS)
> to SGP_1 and the other half to SGP_3.
Is it really reasonable to abort all the associations of an SGP when the SS7
connections of the SGP are out of service, maybe for a few seconds ? 
And in this case, you agree that this SG loose messages ...
> 
> If SGP_2 can access the link processors for L0, L1, L4 or L5,
> it can change over traffic onto the links without communicating
> with SGP_1 and SGP_3.
And in this case, sequencing will not be insured...
> 
> ASP_1 is forced to hold back traffic for a time (i.e., perform
> time-controlled changeover) before starting the old traffic on
> the new SGP.
> 
> L1 and L4 recover. SGP_2 now permits associations and/or ASPAC
> from ASP_1.  ASP_1 holds its traffic for a time and then resumes
> its load sharing with SGP_2 included.
> 
> 
>      SS7 World                              IP World
>  ============================          =================
>                                S.G.                       A.S.
>                           ..............
>  +----+A0   +-----+  L0   . +-------+  .               +-------+
>  |SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |
>  +----+     |     |-- L1   -|       |  .    ----[As0]--| ASP_1 |
>     A1 \    +-----+  \    . +-------+  .   / ---[As0]--|       |
>      A2 X   /  |   \  \   .     |      .  / /          +-------+
>  +----+  \ /   | L2 \  X  . +-------+  . / /
>  |SP_2|   X C-links  \  ----| SGP_2 |---- /
>  +----+\ / \   |      \    -|       |  . /
>      A3 X   \  | L3    X  . +-------+  ./
>     A4 / \   \ |        \ .     |      / 
>  +----+   \ +--+--+      \. +-------+ /.
>  |SP_3|-----|STP_C|-  L4  --| SGP_3 |- .
>  +----+A5   |     |-       -|       |  .
>             +-----+  L5   . +-------+  .
>                           ..............
> 
> So.  How does the ASP get a DRST? or a DUNA?
> 
> To send a DRST I would have to fail SP_2-A2, L3, L4, and L5,
> as shown above.  That's a quadruple simultaneous link failure.
> The SS7 network is having a hard time today!  STP_A will send
> TFR on, say, L0 and SGP_1 will distribute it to SGP_2 and SGP_3.
> Each SGP will realize that it has no other route and send DRST
> to ASP_1.  ASP_1, realizing that it has no other route, will do
> nothing.
> 
> 
>      SS7 World                              IP World
>  ============================          =================
>                                S.G.                       A.S.
>                           ..............
>  +----+A0   +-----+  L0   . +-------+  .               +-------+
>  |SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |
>  +----+     |     |-- L1   -|       |  .    ----[As0]--| ASP_1 |
>     A1 \    +-----+  \    . +-------+  .   / ---[As0]--|       |
>      A2 X   /      \  \   .     |      .  / /          +-------+
>  +----+  \ /     L2 \  X  . +-------+  . / /
>  |SP_2|   X C-links  \  ----| SGP_2 |---- /
>  +----+\ / \          \    -|       |  . /
>      A3 X   \    L3    X  . +-------+  ./
>     A4 / \   \          \ .     |      / 
>  +----+   \ +--+--+      \. +-------+ /.
>  |SP_3|-----|STP_C|-  L4  --| SGP_3 |- .
>  +----+A5   |     |-       -|       |  .
>             +-----+  L5   . +-------+  .
>                           ..............
> 
> Now, (even a worse day for the SS7 network), STP_A loses its
> C-links (all of them), as shown above.  Now the STP_A can no
> longer communicate with SP_2 and it sends TFP to the S.G.
> on, say, L2.  SGP_3 distributes routing updates to SGP_1
> and SGP_2.  All SGPs send DUNA to ASP_1.  ASP_1 stops traffic
> for SP_2 and delivers MTP-PAUSE(SP_2) to users which have
> a route to SP_2.
> 
>      SS7 World                              IP World
>  ============================          =================
>                                S.G.                       A.S.
>                           ..............
>  +----+A0   +-----+  L0   . +-------+  .               +-------+
>  |SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |
>  +----+     |     |-- L1   -|       |  .    ----[As0]--| ASP_1 |
>     A1 \    +-----+       . +-------+  .   / ---[As0]--|       |
>      A2 X   /      \      .     |      .  / /          +-------+
>  +----+  \ /     L2 \  X  . +-------+  . / /
>  |SP_2|   X C-links  \     -| SGP_2 |---- /
>  +----+\ / \          \ ----|       |  . /
>      A3 X   \    L3    X  . +-------+  ./
>     A4 / \   \        / \ .     |      / 
>  +----+   \ +--+--+  /   \. +-------+ /.
>  |SP_3|-----|STP_C|-- L4  --| SGP_3 |- .
>  +----+A5   |     |-       -|       |  .
>             +-----+  L5   . +-------+  .
>                           ..............
> 
> Now let's mix it up.  Let's recover link L3 and fail link L2
> resulting in the above.  ASP_1 is sent DAVA for SP_2 only
> from SGP_2.  ASP_1, because it is performing per-SGP routing
> restarts traffic to SP_2 to SGP_2 and sends MTP-RESUME(SP_2)
> to its users.
> 
> Now with all these links down, we have still not lost any
> messages and there has been no situation where we have needed
> to route DATA traffic between SGP.  Which is what I said:
> I don't want to have to route User Data traffic between SGP.
> 
Well, no, may be what you describe works for a small subset of
configurations and events (link failure etc...) but it does not conform to
the SS7 recommendation for all the cases.
With no SGP intercommunication mechanism:
   . you could loose a lot of messages
   . you cannot insure MTP3 sequencing
To really be SS7 compliant, SGP intercommunication mechanism must be
implemented and support both management and DATA communication.
> Note that this will only work if the ASP pays attention.
> 
> --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, 23 Jul 2001 08:05:24 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07 Comments
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Maria,

Please see comments below...

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 23 Jul 2001
14:50:15)

[snip]
> 
> Section 1.2 Terminology, second last sentence in first paragraph
> (Application Server definition):
> 
> "... An AS is contained within a single Network Appearance.
> ..."
> 
>     What is this supposed to mean?
> 
> [Greg] Gone.
> 
> [MCruz] Didn't you mean that a RK can not extend across more than
> a single Network Appearance?? If you agree, let's add this to the
> RK definition.

Why cannot an RK span more than one newtork appearance?

> 
> Section 1.2 Terminology, eighteenth paragraph (Host definition):
> 
> "Host - The computing platform that the ASP process is
> running on."
> 
>     This also applies to the SGP.  Also, there is a implication
>     throughout the document that a Host corresponds to a unique set
>     of SCTP endpoints.  Also "ASP process" repeats the "process"
>     designation.  Suggest the following:
> 
> Host - The computing platform that a process (SGP or ASP) is
> running on.
> 
> [Greg] Done.
> 
> [MCruz] Also IPSP. I think in most places IPSP is missed, it is
> actually not that easy to understand from the draft IPSP tasks
> and behaviour.

Yes.

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

> 
> Section 1.4.2.1
> 
> "Possible SS7 address/routing information that comprise a
> Routing Key entry includes, for example, the OPC, DPC, SIO
> found in the MTP3 routing label, or MTP3-User specific
> fields such as the ISUP CIC, SCCP subsystem number, or TCAP
> transaction ID."
> 
>     TCAP transaction ID is not an MTP-User specific field: it is an
>     SCCP-User specific field.
> 
> [Greg] OK.  I put brackets in to make this clearer:  "or MTP3-User
specific
> fields (such as the ISUP CIC, SCCP subsystem number) or TCAP
> transaction ID."
> 
> [MCruz] TCAP transaction ID is not specified within the RK format. If
those
> parameters are only examples and some others could be valid, then there
> should be the chance to have then included within the RK parameter format.
> 

I think TCAP transaction ID makes little sense as an example, and less sense
as a Routing Key field.  IMHO SCCP SSN doesn't make much sense either.

-- 
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: Songling Yang <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: RE: M3UA: Routing Context
Date: Mon, 23 Jul 2001 09:38:44 -0400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-SMTP-HELO: ss8mail1.ss8ott
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.87.228.147]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

I'm for sure like this idea. :)

Songling Yang
SS8 Networks Inc. http://www.ss8networks.com

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Monday, July
23, 2001 7: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]
Date: Mon, 23 Jul 2001 08:47:03 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
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]>

Garnero,,

Garnero, Pierre wrote:                                   (Mon, 23 Jul 2001
14:56:42)
> Hello Brian,
> 
> first, thanks for your response.
> It is very useful and we (Francois and myself) understand much better 
> how M3UA works.
> 
> Then, ... my comments below:
> 
> Cheers,
> 
> Pierre
> 
[snip]

> > 
> > Here is a real example of a real SS7 network and an
> > intelligent partitioned SS7 design: (I'll just borrow
> > most of your diagram...)
> You are 100% right concerning SS7 in operation but if one day you have the
> chance to go through a complete certification process with a big Telco,
you
> will see that scenarios used to validate an SS7 stack are sometimes tricky
> and sometimes not "intelligent"....  ... but whatever happens, the SS7
stack
> must works ... if you want to sell it, of course :-)

I have not only gone through certification, I have performed them.
The next thing after conformance, however, is the crush and destroy testing:
things like loading the platform to 1 Erlang on all links and pulling
processor cards...

> 
> For instance, I don't think that any configuration described in Q.782 are
> used "as is" by any operator in the world but ... if you fail to comply
with
> this specification, your stack is not SS7 compliant...  As we would like
to
> build a carrier grade M3UA stack, we need to be sure that M3UA works for
all
> the cases.  More: if it is clear that some SS7 configurations are not
> allowed by SG, it must be clearly indicated in the draft...then, we will
> save a lot of time :-)

I like to see it work for the real network (at least in theory) before
considering oddities such as the 781 IUT configuration.

     SS7 World                              IP World
============================          =================
                               S.G.                       A.S.
                          ..............
 +----+A0   +-----+  L0   . +-------+  .               +-------+
|SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |  +----+   /
|     |-- L1  --|       |  .    ----[As0]--| ASP_1 |
    A1 \ /  +-----+  \   /. +-------+  .   / ---[As0]--|       |
     A2 X   /  |   \  \ / .     |      .  / /          +-------+  +----+/ \
/   | L2 \  X  . +-------+  . / /  |SP_2|   X C-links  \/ ----| SGP_2 |----
/  +----+\ / \   |     /\ ----|       |  . /
     A3 X   \  | L3 /  X  . +-------+  ./
    A4 / \   \ |   /  / \ .     |      /  +----+   \ +--+--+  /   \.
+-------+ /.
 |SP_3|-----|STP_C|-- L4  --| SGP_3 |- .
 +----+A5   |     |---------|       |  .
            +-----+  L5   . +-------+  .
                          ..............

> You always suppose that the 2 links on each SGP are available but 
> (for a carrier grade application of course) you cannot guarantee this.
> And then, in the case where L1 is broken, in the previous scenario:
>   => you could choose to loose all the messages sent to SGP_1 
>      (and this is not a carrier grade behavior)
>   => or reroute messages from SGP_1 to another SGP according to there SLS,

>      (but DATA messages must be exchanged between SGP, and here you
>       could claim that you respect the SS7 protocol)
> It is true that if SG is partionned, emergency changeover will occurs 
> and then you will loose messages => clearly, this could be avoided if SGPs

> communicate....

Ok.  See folowing example:

     SS7 World                              IP World
============================          =================
                               S.G.                       A.S.
                          ..............
 +----+A0   +-----+  L0   . +-------+  .               +-------+
|SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |  +----+   /
|     |-  L1   -|       |  .    ----[As0]--| ASP_1 |
    A1 \ /  +-----+       . +-------+  .   / ---[As0]--|       |
     A2 X   /  |          .     |      .  / /          +-------+  +----+/ \
/   | L2       . +-------+  . / /  |SP_2|   X C-links        -| SGP_2 |----
/  +----+\ / \   |           -|       |  . /
     A3 X   \  | L3       . +-------+  ./
    A4 / \   \ |          .     |      /  +----+   \ +--+--+       .
+-------+ /.
 |SP_3|-----|STP_C|-  L4   -| SGP_3 |- .
 +----+A5   |     |---------|       |  .
            +-----+  L5   . +-------+  .
                          ..............

We lose links L1, L2, L3, and L4.  SGP_1 changes traffic over from L1->L0.
SGP_3 changes traffic over from L4->L5.  SGP_2 shuts down association with
ASP_1 and performs changeover (buffer updating, rerouting) via SGP_1 or
SGP_2.  There is still no need to route active traffic between SGP. (Just
buffer contents.)

> >      SS7 World                              IP World
> >  ============================          =================
> >                                S.G.                       A.S.
> >                           ..............
> >  +----+A0   +-----+  L0   . +-------+  .               +-------+
> >  |SP_1|-----|STP_A|---------| SGP_1 |-----------[As0]--|       |
> >  +----+   / |     |-- L1  --|       |  .    ----[As0]--| ASP_1 |
> >     A1 \ /  +-----+      /. +-------+  .   / ---[As0]--|       |
> >      A2 X   /  |   \    / .     |      .  / /          +-------+
> >  +----+/ \ /   | L2 \  X  . +-------+  . / /
> >  |SP_2|   X C-links  \/    -| SGP_2 |---- /
> >  +----+\ / \   |     /\    -|       |  . /
> >      A3 X   \  | L3 /  X  . +-------+  ./
> >     A4 / \   \ |   /    \ .     |      / 
> >  +----+   \ +--+--+      \. +-------+ /.
> >  |SP_3|-----|STP_C|-- L4  --| SGP_3 |- .
> >  +----+A5   |     |---------|       |  .
> >             +-----+  L5   . +-------+  .
> >                           ..............
> > 
> > So, now, assume that SGP_2 loses both its links L1 and L4, as
> > shown above.  This is a blue moon occurence because L1 and L4
> > are space diverse and the probability of dual failure is
> > extremely small (it is more likely that SGP_2 will fail).  SGP_2
> > does not need to send anything to the ASP.  It ABORTs the
> > association.  Because this is a blue moon occurence and the SG
> > is acting as an SEP which does not necessarily have to be
> > lossless, SGP_2 could optionally discard any collected or
> > buffered messages.  It could also transfer half of them (by SLS)
> > to SGP_1 and the other half to SGP_3.

> Is it really reasonable to abort all the associations of an SGP 
> when the SS7 connections of the SGP are out of service, maybe for
> a few seconds ? 

Well, not ABORT.  We want to do an orderly SHUTDOWN (if possible) so that we
know which messages were received by the other end and which ones need to be
transferred to the other SGP.

No, I don't think that it is reasonable to have to do this.  I would like to
see a procedure between the SGP and the ASP in UAs where the SGP can force
or coerce the ASP inactive without having to shutdown the association.  See
previous threads regarding SGP management at the ASP.

> And in this case, you agree that this SG loose messages ...

No.  If you don't want to lose messages you don't have to.  Perform the
changeover via the other SGP.  It is still not necessary to route active
traffic between SGP.

[snip]
> > 
> > If SGP_2 can access the link processors for L0, L1, L4 or L5,
> > it can change over traffic onto the links without communicating
> > with SGP_1 and SGP_3.

> And in this case, sequencing will not be insured...

Yes, sequencing is ensured,  because the SLS for the traffic from SGP_2 is
not the same as the SLS of the traffic already on SGP_1 or SGP_3.
Sequencing is only required within an SLS, not between them.

[snip]
> > 
> > Now with all these links down, we have still not lost any
> > messages and there has been no situation where we have needed
> > to route DATA traffic between SGP.  Which is what I said:
> > I don't want to have to route User Data traffic between SGP.
> > 

> Well, no, may be what you describe works for a small subset of
> configurations and events (link failure etc...) but it does not 
> conform to the SS7 recommendation for all the cases.
> With no SGP intercommunication mechanism:
>    . you could loose a lot of messages
>    . you cannot insure MTP3 sequencing
> To really be SS7 compliant, SGP intercommunication mechanism 
> must be implemented and support both management and DATA 
> communication.

I think that you are confusing my statement.  I am referring to "User Data
traffic".  I have no problems with changeover commands and buffer contents.
I just won't route traffic.  The only arrangement in which you can try and
force me to route between processors is something like as follows:

     SS7 World                              IP World
============================          =================
                               S.G.                       A.S.
                          ..............
 +----+A0   +-----+  L0   . +-------+  .               +-------+
|SP_1|-----|STP_A|---------| SGP_1 |-         -[As0]- |       |  +----+   /
|     |-  L1   -|       |  .    ----[As0]--| ASP_1 |
    A1 \ /  +-----+       . +-------+  .   /   -[As0]- |       |
     A2 X   /  |          .     |      .  /            +-------+  +----+/ \
/   | L2       . +-------+  . /  |SP_2|   X C-links        -| SGP_2 |----
+----+\ / \   |           -|       |  .  
     A3 X   \  | L3       . +-------+  . 
    A4 / \   \ |          .     |  +----+   \ +--+--+       . +-------+  .
 |SP_3|-----|STP_C|-  L4   -| SGP_3 |- .
 +----+A5   |     |---------|       |  .
            +-----+  L5   . +-------+  .
                          ..............

In theory, you can arrange `n' SGP processors in this arrangement (evey even
one has an SS7 link, every odd one a link to one links to ASPs).  But the
way that I get around this is by having the SGP have access to all the links
across a TDM backplane, so that in the above diagram I can alway move links
L0 and L5 to processor SGP_2 (and would have long before it got to this
point).

I should also point out that this entire discussion has been about how to
design for the SS7 network (with little about M3UA).
Which was my point.  SGP to SGP communication is the SG's business as the
spec should not dictate the SS7 design to the SG implementor by telling it
what the SGP should or should not be capable of passing between them.
Certainly, for me, user data traffic is not one of the things that I deem
necessary.

--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: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07 Comments
Date: Mon, 23 Jul 2001 15:52:27 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.237.142.110]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

See comments below

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Monday, July
23, 2001 3:05 PM
To: sigtran
Subject: Re: M3UA07 Comments

Maria,

Please see comments below...

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 23 Jul 2001
14:50:15)

[snip]
> 
> Section 1.2 Terminology, second last sentence in first paragraph
> (Application Server definition):
> 
> "... An AS is contained within a single Network Appearance.
> ..."
> 
>     What is this supposed to mean?
> 
> [Greg] Gone.
> 
> [MCruz] Didn't you mean that a RK can not extend across more than
> a single Network Appearance?? If you agree, let's add this to the
> RK definition.

Why cannot an RK span more than one newtork appearance?

[MCruz] I just thought that one particular AS would process traffic for only
a single NA (let's think about MGC), I found that nearer to a probable
network configuration, but I think you are right, in fact we do not need to
impose that restriction...

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Benjamin J. Wilson" <[email-masked]>
Organization: Performance Technologies
To: "sigtran" <[email-masked]>
Subject: Re: M3UA: Packing of Routing Label into DATA Payload
Date: Mon, 23 Jul 2001 09:55:42 -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]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

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?

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

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

Hopefully this all makes sense, after all it is Monday morning.

Cheers,

Ben

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 23 Jul 2001 09:05:06 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07 Comments
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Maria,

I was thinking MGC.  I was thinking of an VoIP MGC which was used to do
International Bypass.  It would be configured as a single gateway switch
with point codes in both the national and international networks.  Or it
might even sit in the middle as a distributed switch with point codes in 37
national networks, but appear as one switching element.  I think the
restriction should be relaxed.

Perhaps the REG REQ could be changed to accept multiple network appearances
and multiple DPC.

Do you see any problems with doing that?

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 23 Jul 2001
15:52:27)

[snip]
> 
> Why cannot an RK span more than one newtork appearance?
> 
> [MCruz] I just thought that one particular AS would process traffic for
> only a single NA (let's think about MGC), I found that nearer to a
probable
> network configuration, but I think you are right, in fact we do not need
to 
> impose that restriction...
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA, SUA]: Gracefull shutdown of SGP
Date: Mon, 23 Jul 2001 16:25:05 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.237.142.110]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

See comments below
Regards
/MCruz

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Monday, July
23, 2001 2:51 PM
To: sigtran
Subject: [M3UA, SUA]: Gracefull shutdown of SGP

All,

Is there any way in the existing M3UA, SUA procedures to peform a graceful
shutdown of an SGP which has active ASPs?

[MCruz] For M3UA there isn't such possibility, it is not possible to stop
traffic for a particular SGP, neither locally from the layer management nor
from an ASP.

Say that, for maintenance purposes, I want to take one of a number of SGP
out of service.  Can this be performed at the SG?  Or, does one need to tell
the ASPs to remove traffic from the SGP first?

What would be advantageous would be a procedure whereby the SGP can notify
ASPs to which it has associations that it is about to go out of service.
That way, when a card is about to be pulled at the SG, the ASPs can
gracefully reconfigure themselves on the remaining SGP before the card is
pulled.

[MCruz] All traffic control resides in the AS side (Stop/Start), then I
think that all actions to allow an SGP removal should be triggered from
there. The ASP-to-ASP protocol could be in charge of requesting traffic
stopping from all involved ASPs to a particular SGP and reconfigure them on
the remaining SGPs. Once the traffic is stopped, the SGP could be removed.

--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: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07 Comments
Date: Mon, 23 Jul 2001 16:30:06 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: penguin-ext.wise.edt.ericsson.se [194.237.142.110]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Yes, better do not restrict that.

Then, the RK parameter format should be open up and admit an NA range.
About DPC in the RK parameter... it MUST be a range, otherwise a 'RK cannot
extend across more than one DPC', and it was concluded it is not the case.

/MCruz

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Monday, July
23, 2001 4:05 PM
To: sigtran
Subject: Re: M3UA07 Comments

Maria,

I was thinking MGC.  I was thinking of an VoIP MGC which was used to do
International Bypass.  It would be configured as a single gateway switch
with point codes in both the national and international networks.  Or it
might even sit in the middle as a distributed switch with point codes in 37
national networks, but appear as one switching element.  I think the
restriction should be relaxed.

Perhaps the REG REQ could be changed to accept multiple network appearances
and multiple DPC.

Do you see any problems with doing that?

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 23 Jul 2001
15:52:27)

[snip]
> 
> Why cannot an RK span more than one newtork appearance?
> 
> [MCruz] I just thought that one particular AS would process traffic for
> only a single NA (let's think about MGC), I found that nearer to a
probable
> network configuration, but I think you are right, in fact we do not need
to 
> impose that restriction...
> 

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

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Re: M2UA - Issue #7 - ASP Active procedures
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Date: Mon, 23 Jul 2001 10:38:14 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/23/2001 07:40:36 AM, Serialize 
             complete at 07/23/2001 07:40:36 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,

The consensus at the M3UA bakeoff was that error handling MUST be made more
robust. The 2 leading methods suggested were:

a. Add several mandatory and/or optional parameters to the ERROR msg. Kurt
Kite suggested some parameters in his "M3UA version 7 comments" email on
July 17.

b. Add a NACK message to the protocol.

I don't really care which method is chosen, but something must be done. A
protocol without extensive and mappable error reporting is not a robust
protocol.

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

Ken Morneault <[email-masked]>
07/20/01 11:59 AM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        Re: M2UA - Issue #7 - ASP Active procedures

Is there any interest in adding Routing Context (M3UA) / Interface
Identifier (M2UA) as optional parameters to the Error Message?
Then, the Error message could be explicit about the RC/IID it is referring
to with the "Invalid RC/IID" error without having to stuff something into
Diagnostic Information OR create a new message.

At 09:33 AM 7/20/01 -0400, you wrote:
>Ken,
>
>The proposal that was put forward at the M3UA "bay-cough" was to add to 
>the protocol a "NACK" (Negative Acknowledge) message. The advantage of the 
>NACK over the ERROR message is that there is clear and instant correlation 
>to the ASP Active Msg.
>
>Greg forgot about this proposal when he was editing M3UA v7. He is 
>considering adding it to the next version of M3UA.
>
>Barry Nagelberg
>Software Engineer
>RadiSys, Corp.
>Signaling Products Design Center
>[email-masked]
>+1-856-642-9229 x237
>
>
>
>
>
>Ken Morneault <[email-masked]>
>07/19/01 10:16 PM
>Please respond to sigtran
>
> 
>         To:     "sigtran" <[email-masked]>
>         cc: 
>         Subject:        M2UA - Issue #7 - ASP Active procedures
>
>
>
>
>Note:  This issue also impacts M3UA.  Just replace Interface Identifier
>with Routing Context.
>
>If an SG receives an ASP Active message (at the proper time)
>which has some Interface Ids indicating AS for which the ASP
>is not configured/registered, how does the SG respond?  The
>draft only allows for two situations that I can see:
>
>    1.  ASP Active is unexpected:  Error - Unexpected Message
>    2.  ASP Active is expected:    Must return ASP Active Ack.
>
>We need a procedure to tell the ASP that an interface id is
>incorrect or that some other failure has occured and which
>describes the disposition of valid IIDs in the ASP Active.
>
>The use of ERR (Invalid Interface Identifier) is appropriate, however,
>it should be mentioned in the ASP Active procedures section.
>
>Also, the disposition of other non-errored IIDs in the ASPAC
>needs to be addressed for interoperability sake.
>
>For example, the ASP sends an ASPAC with 5 IIDs which are
>representative of 5 ASs.  Two of them are invalid (i.e., there
>is no configured/registered AS which has these two IIDs on the
>SG).  The SG could respond with an ERR (Invalid Interface
>Identifier) and an ASPAC Ack for the 3 successful IIDs, but
>then how does the ASP know which IIDs the ERR corresponds to.
>
>Perhaps it is a general correspondence of ERR message problem
>similar to that posted for M3UA today.  The proposal there was
>to include a message and parameter diagnostic in the ERR
>message to permit the error to be correlated with the message
>and parameter causing the error.  If this proposal were to be
>adopted for M2UA, it would permit an ERR (Invalid Interface
>Identifier) with a parameter diagnostic listing the two IIDs
>which were at fault.  Then the ASP would know to stop any
>T(ack) timers with regard to those IIDs.
>
>Another approach would be to fail all 5 IIDs and only send
>one ERR message (and no ASPAC Ack).  This would be a better
>approach because the ASP may not want to start receiving
>traffic for a partly unsuccessful activation attempt.
>
>It gets worse for IID ranges.
>
>Otherwise, to get expected behavior, the ASP will need to send
>each IID in an individual ASPAC and wait for the ASPAC Ack or
>ERR message on each before sending the next and will have to
>be prepared to start messaging on a partially built group of
>AS.  This would severly reduce the value and usability of placing
>multiple IID in the ASPAC message at all.
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to 
>[email-masked]
>
>
>
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to 
[email-masked] 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "May, Howard" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA07 Comments
Date: Mon, 23 Jul 2001 15:55:31 +0100
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: odin.isw.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: swfdns01.isw.intel.com [192.55.37.143]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

The following scenario also makes it desirable for an AS to receive messages
for multiple NAs.

Consider a simple system:

An SG presenting two link-sets to an MTP Network, each with a different
local point code and hence two NAs.
An AS connecting to the SG servicing messages for a third point code.

In this situation we want the AS to receive messages arriving at the SG for
both NAs.

Howard

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: 23 July 2001
15:05
To: sigtran
Subject: Re: M3UA07 Comments

Maria,

I was thinking MGC.  I was thinking of an VoIP MGC which was used to do
International Bypass.  It would be configured as a single gateway switch
with point codes in both the national and international networks.  Or it
might even sit in the middle as a distributed switch with point codes in 37
national networks, but appear as one switching element.  I think the
restriction should be relaxed.

Perhaps the REG REQ could be changed to accept multiple network appearances
and multiple DPC.

Do you see any problems with doing that?

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 23 Jul 2001
15:52:27)

[snip]
> 
> Why cannot an RK span more than one newtork appearance?
> 
> [MCruz] I just thought that one particular AS would process traffic for
> only a single NA (let's think about MGC), I found that nearer to a
probable
> network configuration, but I think you are right, in fact we do not need
to 
> impose that restriction...
> 

-- 
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, 23 Jul 2001 09:55:50 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: [M3UA, SUA]: Gracefull shutdown 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: [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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?

It looks like we need a good way for an SGP to remove itself from service
for other reasons without just shutting down all associations.  Removing an
association seems a drastic thing to do, when the objective is temporary
removal of traffic.

Any more thoughts?

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 23 Jul 2001
16:25:05)
> Hi Brian,
> 
> See comments below
> Regards
> /MCruz
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, July 23, 2001 2:51 PM
> To: sigtran
> Subject: [M3UA, SUA]: Gracefull shutdown of SGP
> 
> 
> All,
> 
> Is there any way in the existing M3UA, SUA procedures to
> peform a graceful shutdown of an SGP which has active ASPs?
> 
> [MCruz] For M3UA there isn't such possibility, it is not
> possible to stop traffic for a particular SGP, neither 
> locally from the layer management nor from an ASP.
> 
> Say that, for maintenance purposes, I want to take one of a
> number of SGP out of service.  Can this be performed at the
> SG?  Or, does one need to tell the ASPs to remove traffic
> from the SGP first?
> 
> 
> What would be advantageous would be a procedure whereby the
> SGP can notify ASPs to which it has associations that it is
> about to go out of service.  That way, when a card is about
> to be pulled at the SG, the ASPs can gracefully reconfigure
> themselves on the remaining SGP before the card is pulled.
> 
> [MCruz] All traffic control resides in the AS side (Stop/Start),
> then I think that all actions to allow an SGP removal should
> be triggered from there. The ASP-to-ASP protocol could be
> in charge of requesting traffic stopping from all involved
> ASPs to a particular SGP and reconfigure them on the remaining
> SGPs. Once the traffic is stopped, the SGP could be removed.
> 
> 
> --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, 23 Jul 2001 10:12:56 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA07 Comments
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: 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]>

Howard,

Couldn't that be accomplished already by having two AS (one for each point
code) and having the ASP configured/register for both?  If each point code
is really independent, then independent AS state makes sense.

I was thinking the multiple point code switch case, where unified AS state
for the point codes makes sense.  If the ASP is incapable of processing
traffic for one point code, then it is incapable of processing for another.

We have this concept in M2UA where an AS can have multiple IIDs (a group of
links) which are either active together or down together.  This management
coupling has advantages in some circumstances.

--Brian

May, Howard wrote:                                           (Mon, 23 Jul
2001 15:55:31)
> The following scenario also makes it desirable for an AS to receive
messages
> for multiple NAs.
> 
> Consider a simple system:
> 
> An SG presenting two link-sets to an MTP Network, each with a different
> local point code and hence two NAs.
> An AS connecting to the SG servicing messages for a third point code.
> 
> In this situation we want the AS to receive messages arriving at the SG
for
> both NAs.
> 
> Howard
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 23 July 2001 15:05
> To: sigtran
> Subject: Re: M3UA07 Comments
> 
> 
> Maria,
> 
> I was thinking MGC.  I was thinking of an VoIP MGC which was used
> to do International Bypass.  It would be configured as a single
> gateway switch with point codes in both the national and international
> networks.  Or it might even sit in the middle as a distributed switch
> with point codes in 37 national networks, but appear as one switching
> element.  I think the restriction should be relaxed.
> 
> Perhaps the REG REQ could be changed to accept multiple network
> appearances and multiple DPC.
> 
> Do you see any problems with doing that?
> 
> --Brian
> 
> Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 23 Jul 2001
> 15:52:27)
> 
> [snip]
> > 
> > Why cannot an RK span more than one newtork appearance?
> > 
> > [MCruz] I just thought that one particular AS would process traffic for
> > only a single NA (let's think about MGC), I found that nearer to a
> probable
> > network configuration, but I think you are right, in fact we do not need
> to 
> > impose that restriction...
> > 
> 
> -- 
> 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, 23 Jul 2001 10:15:23 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA: Packing of Routing Label into DATA Payload
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]>

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]
Sender: [email-masked]
Date: Mon, 23 Jul 2001 10:36:33 -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, SUA]: Gracefull shutdown of SGP
X-SMTP-HELO: imr2.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr2.ericy.com [12.34.240.68]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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.

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.

>
>
> It looks like we need a good way for an SGP to remove itself
> from service for other reasons without just shutting down
> all associations.  Removing an association seems a drastic
> thing to do, when the objective is temporary removal of
> traffic.
>
> Any more thoughts?
>
> --Brian
>
> Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 23 Jul 2001
16:25:05)
> > Hi Brian,
> >
> > See comments below
> > Regards
> > /MCruz
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Monday, July 23, 2001 2:51 PM
> > To: sigtran
> > Subject: [M3UA, SUA]: Gracefull shutdown of SGP
> >
> >
> > All,
> >
> > Is there any way in the existing M3UA, SUA procedures to
> > peform a graceful shutdown of an SGP which has active ASPs?
> >
> > [MCruz] For M3UA there isn't such possibility, it is not
> > possible to stop traffic for a particular SGP, neither
> > locally from the layer management nor from an ASP.
> >
> > Say that, for maintenance purposes, I want to take one of a
> > number of SGP out of service.  Can this be performed at the
> > SG?  Or, does one need to tell the ASPs to remove traffic
> > from the SGP first?
> >
> >
> > What would be advantageous would be a procedure whereby the
> > SGP can notify ASPs to which it has associations that it is
> > about to go out of service.  That way, when a card is about
> > to be pulled at the SG, the ASPs can gracefully reconfigure
> > themselves on the remaining SGP before the card is pulled.
> >
> > [MCruz] All traffic control resides in the AS side (Stop/Start),
> > then I think that all actions to allow an SGP removal should
> > be triggered from there. The ASP-to-ASP protocol could be
> > in charge of requesting traffic stopping from all involved
> > ASPs to a particular SGP and reconfigure them on the remaining
> > SGPs. Once the traffic is stopped, the SGP could be removed.
> >
> >
> > --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: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA and M2UA: ASPTM or BEAT on Stream other than `0'
Date: Mon, 23 Jul 2001 17:57:23 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: penguin-ext.wise.edt.ericsson.se [194.237.142.110]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

As you said, in M3UA is perfectly possible to be sending traffic to the ASP
for the same RK over multiple streams. Stream assignment for data messages
is implementation dependent, then several algorithms could apply. Let's say
as an example (ISUP traffic) that CIC value is used for the stream
assignment, CIC1 is assigned to stream1 and CIC2 is assigned to stream2.
Then, the problem is NOT solved with:

> >  			   All ASP Traffic Maintenance messages
> >                  SHOULD be sent on the stream which normally carries the
> >                  data traffic to which the message applies

Firstable, there is not such an stream which normally carries the data
traffic, both stream1 and stream2 are used. Secondly, if the ASPTM msg is
sent using stream1 (e.g.) then it can NOT be assured that this message
arrives before data messages sent using stream2.

Then, the only way to assure that data is not lost would be to assign an
stream per RC... not even so, because ASPTM msg could be valid for several
RCs... then the only solution I can see is to let a timer expire before
sending ASPTM msgs. This timer value could be pretty small because there is
not a reason to consider that an stream is significantly slower than other
(only retransmitions could somehow slow an stream traffic down).

/MCruz

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Monday, July
23, 2001 10:21 AM
To: sigtran
Subject: Re: M3UA and M2UA: ASPTM or BEAT on Stream other than `0'

Jacob,

That was my only reason for not saying MUST.  In M3UA it is quite possible
to be sending traffic for a single Routing Key over multiple streams to the
ASP as well.  Even if there are multiplex streasm, sending the message on
one of the data streams may serve to push the queue down to SCTP through the
SCTP-ULP interface.

How about MAY?

--Brian

Jacob Heitz wrote:                           (Mon, 23 Jul 2001 01:01:41)
>
> For M2UA, an ASP will typically handle more than one data stream.
> Which non-zero (excuse the hyphen) data stream should be used ?
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Greg, Ken,
> > 
> > The M3UA draft seems to require that ASPSM and ASPTM messages be only
> > sent on stream `0'.  M2UA has a "SHOULD".
> > 
> > For ASP Inactive Ack messages, however, it is advisable to do just the
> > opposite: to send them on the stream that corresponds to the Application
> > Server traffic which is going inactive.  This is because the SGP must
> > ensure that no traffic to the ASP for the AS going inactive arrives
> > after the ASP Inactive Ack or it will risk message loss.
> > 
> > One way for an SGP to ensure that no Data messages for the AS after the
> > ASP Inactive Ack is to stop traffic and send the ASP Inactive Ack on the
> > same stream as the Data.
> > 
> > This is one case where an ASPTM message need not be sent on stream `0'.
> > 
> > It is also possible for the ASP to ensure that the ASP Inactive message
> > does not arrive before AS Data by doing the same: placing the ASPIA on
> > the same stream as it sends AS data.
> > 
> > The same is true for ASP Active Ack from the SGP.  When the SGP sends an
> > ASP Active Ack on stream `0' immediately followed by Data on the AS
> > stream, the Data may beat the ASP Active Ack to the ASP, resulting in
> > message loss (the ASP is required to discard).
> > 
> > The only way to ensure that the ASP Active Ack arrives at the ASP ahead
> > of the Data, is to place the ASP Active Ack ordered on the same stream
> > with the Data.
> > 
> > There can be an avantage to putting BEAT messages on an AS Data stream
> > after witholding traffic on that stream as a way of ensuring that data
> > for the stream has "cleared" to the UA peer.
> > 
> > I might also point out that all the UAs refer to a "sequenced stream".
> > There is no such thing in SCTP: any message can be sent for either
> > sequence or out-of-order delivery.  The stream itself is neither
> > sequenced nor unsequenced.
> > 
> > M3UA Changes:
> > 
> >     Section 4.2.3
> > 
> >     Change:     "All M3UA Management and ASP State and Traffic
> >                  Maintenance messages are sent on a sequenced stream to
> >                  ensure ordering.  SCTP stream `0' is used."
> > 
> >     To:         "All M3UA Management and ASP State and Traffic
> >                  Maintenance messages, with the exception of BEAT and
> >                  BEAT Ack messages, SHOULD be sent using sequenced
> >                  delivery to ensure ordering.  All M3UA Management and
> >                  ASP State Maintenance messages, with the exception of
> >                  BEAT and BEAT ACK messages, SHOULD be sent on SCTP
> >                  stream `0'.  All ASP Traffic Maintenance messages
> >                  SHOULD be sent on the stream which normally carries the
> >                  data traffic to which the message applies.  BEAT and
> >                  BEAT Ack messages MAY be sent using out-of-order
> >                  delivery, and MAY be sent on any stream."
> > 
> > M2UA Changes:
> > 
> >     Section 4.2.2
> > 
> >     Change:     "All MGMT messages are sent on a sequenced stream to
> >                  ensure ordering.  SCTP stream '0' SHOULD be used."
> > 
> >     To:         (Note also that the above paragraph is duplicated just
> >                  before the 4.2.2 section header and then again just
> >                  before the 4.3 section header.  Delete the first
> >                  occurence.)
> > 
> >                 "All MGMT messages, except BEAT and BEAT Ack, SHOULD be
> >                  sent with sequenced delivery to ensure ordering.  All
> >                  MGMT messages, with the exception of ASPTM, BEAT and
> >                  BEAT Ack messages, SHOULD be sent on SCTP stream `0'.
> >                  All ASPTM messages SHOULD be sent on the stream which
> >                  normally carries the data traffic to which the message
> >                  applies.  BEAT and BEAT Ack messages MAY be sent using
> >                  out-of-order delivery, and MAY be sent on any stream."
> > 
> >     Section 4.3.3
> > 
> >     Change:     "All ASPM messages are sent on a sequenced stream to
> >                  ensure ordering.  SCTP stream '0' SHOULD be used."
> > 
> >     To:         "All ASPM messages, except BEAT and BEAT Ack, SHOULD be
> >                  sent using sequenced delivery to ensure ordering.  All
> >                  ASPSM messages, except BEAT and BEAT Ack, SHOULD be
> >                  sent on SCTP stream `0'.  All ASPTM messages SHOULD be
> >                  sent on the stream which normally carries the data
> >                  traffic to which the message applies.  BEAT and BEAT
> >                  Ack messages MAY be sent using out-of-order delivery,
> >                  and MAY be sent on any stream."
> > 
> > 
> > Actually, ERR or NTFY messages which do not indicate AS State Change
> > SHOULD be sent using out-of-order delivery, if the use of out-of-order
> > delivery will expedite the message.
> > 
> > Perhaps it would be an idea to split these recommendations up and place
> > them in the sections closer to the actual messages.  Pehaps where they
> > are defined.  To summarize:
> > 
> >     Msg         Delivery Option      Stream
> > 
> >     NTFY(AS)    sequenced (SHOULD)   Stream `0' (SHOULD)
> >     ASPUP       sequenced (SHOULD)   Stream `0' (SHOULD)
> >     ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
> >     ASPDN       sequenced (SHOULD)   Stream `0' (SHOULD)
> >     ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
> > 
> >     ERR         out-of-order (MAY)   Stream `0' (SHOULD)
> >     NTFY(Fail)  out-of-order (MAY)   Stream `0' (SHOULD)
> > 
> >     BEAT        out-of-order (MAY)   Any Stream (MAY)
> >     BEAT Ack    out-of-order (MAY)   Any Stream (MAY)
> > 
> >     NTFY(Alt)   sequenced (SHOULD)   Stream with DATA (SHOULD)
> >     ASPAC       sequenced (SHOULD)   Stream with DATA (SHOULD)
> >     ASPAC Ack   sequenced (SHOULD)   Stream with DATA (SHOULD)
> >     ASPIA       sequenced (SHOULD)   Stream with DATA (SHOULD)
> >     ASPIA Ack   sequenced (SHOULD)   Stream with DATA (SHOULD)
> > 
> > --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: Mon, 23 Jul 2001 11:08:03 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: [M3UA, SUA]: Gracefull shutdown 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: [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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.

--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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 23 Jul 2001 12:41:55 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: m2ua v9 - 3.3.1.7 Congestion Indication
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]

I will add enhance the current reference to:

"Refer to [2], [3] and [9] for more details on the congestion status of
signalling links."

That will be better than trying to repeat Section 3.8.2 of T1.111 and Q.704.

Regards,

Ken

At 04:52 PM 7/20/01 -0400, you wrote:
>Brian,
>
>If the referenced document sufficiently explains what these params mean 
>and when they should be used, then it is sufficient.
>
>Barry Nagelberg
>Software Engineer
>RadiSys, Corp.
>Signaling Products Design Center
>[email-masked]
>+1-856-642-9229 x237
>
>
>
>
>
>"Brian F. G. Bidulock" <[email-masked]>
>07/20/01 04:40 PM
>Please respond to sigtran
>
>  
>         To:     "sigtran" <[email-masked]>
>         cc: 
>         Subject:        Re: m2ua v9 - 3.3.1.7 Congestion Indication
>
>
>Barry,
>
>Would it suffice to reference, say, ANSI T1.111.4 Section 3.8.2. ?
>
>[email-masked] wrote:                (Fri, 20 Jul 2001 
>15:59:33)
> > Ken,
> > 
> > I think we need an issue number. 
> > 
> > If Brian is correct when he says that "Any of the remaining levels can 
>go in
> > either status parameter", then either
> > 
> > a. we don't need two separate parameters or 
> >
> > b. the values that go in each param, and the circumstances for using 
>them,
> >    have to be better explained.
>
>-- 
>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: Mon, 23 Jul 2001 12:49:50 -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,

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]
Date: Mon, 23 Jul 2001 12:54:43 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M3UA and M2UA: ASPTM or BEAT on Stream other than `0'
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Maria,

Timers are too slow and SCTP does not guarantee delivery or failure, 

I've got another method:  send BEAT down each stream that corresponds to the
ASPTM with a different Heartbeat data configuration.  Wait till you get all
the BEAT Acks.
Then send ASPTM on any stream.

Nevertheless, the implementation should not be forced to send ASPTM on
stream 0.  Change "SHOULD" to "MAY" and Stream with Data, to Any Stream.

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 23 Jul 2001
17:57:23)
> Brian,
> 
> As you said, in M3UA is perfectly possible to be sending traffic
> to the ASP for the same RK over multiple streams. Stream assignment
> for data messages is implementation dependent, then several
> algorithms could apply. Let's say as an example (ISUP traffic) 
> that CIC value is used for the stream assignment, CIC1 is assigned
> to stream1 and CIC2 is assigned to stream2. Then, the problem
> is NOT solved with:
> 
> > >  			   All ASP Traffic Maintenance messages
> > >                  SHOULD be sent on the stream which normally carries
the
> > >                  data traffic to which the message applies
> 
> Firstable, there is not such an stream which normally carries the
> data traffic, both stream1 and stream2 are used. Secondly, if the
> ASPTM msg is sent using stream1 (e.g.) then it can NOT be assured
> that this message arrives before data messages sent using stream2.
> 
> Then, the only way to assure that data is not lost would be to
> assign an stream per RC... not even so, because ASPTM msg could
> be valid for several RCs... then the only solution I can see is
> to let a timer expire before sending ASPTM msgs. This timer
> value could be pretty small because there is not a reason to 
> consider that an stream is significantly slower than other (only
> retransmitions could somehow slow an stream traffic down).
> 
> /MCruz

[snip]

> > >     Msg         Delivery Option      Stream
> > > 
> > >     NTFY(AS)    sequenced (SHOULD)   Stream `0' (SHOULD)
> > >     ASPUP       sequenced (SHOULD)   Stream `0' (SHOULD)
> > >     ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
> > >     ASPDN       sequenced (SHOULD)   Stream `0' (SHOULD)
> > >     ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
> > > 
> > >     ERR         out-of-order (MAY)   Stream `0' (SHOULD)
> > >     NTFY(Fail)  out-of-order (MAY)   Stream `0' (SHOULD)
> > > 
> > >     BEAT        out-of-order (MAY)   Any Stream (MAY)
> > >     BEAT Ack    out-of-order (MAY)   Any Stream (MAY)
> > > 
          NTFY(Alt)   sequenced (SHOULD)   Any Stream (MAY)
          ASPAC       sequenced (SHOULD)   Any Stream (MAY)
          ASPAC Ack   sequenced (SHOULD)   Any Stream (MAY)
          ASPIA       sequenced (SHOULD)   Any Stream (MAY)
          ASPIA Ack   sequenced (SHOULD)   Any Stream (MAY)

-- 
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]
Subject: SUA: SCCP Message Priority
To: "sigtran" <[email-masked]>
Date: Mon, 23 Jul 2001 14:01:56 -0400
X-MIMETrack: Serialize by Router on notes900/Telcordia(Release 5.0.6a
|January 
             17, 2001) at 07/23/2001 02:01:57 PM
X-SMTP-HELO: dnsmx1pya.telcordia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: dnsmx1pya.telcordia.com [128.96.20.31]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

Could someone please clarify whether SUA would allow ANSI message priority
values to be conveyed between peer SUA/SUA Users.

Thanks
Ray

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA and M2UA: ASPTM or BEAT on Stream other than `0'
Date: Mon, 23 Jul 2001 20:33:49 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.237.142.116]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

See comments
/MCruz

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Monday, July
23, 2001 7:55 PM
To: sigtran
Cc: [email-masked]
Subject: Re: M3UA and M2UA: ASPTM or BEAT on Stream other than `0'

Maria,

Timers are too slow and SCTP does not guarantee delivery or failure, 

I've got another method:  send BEAT down each stream that corresponds to the
ASPTM with a different Heartbeat data configuration.  Wait till you get all
the BEAT Acks.
Then send ASPTM on any stream.

[MCruz] It seems to work...

Nevertheless, the implementation should not be forced to send ASPTM on
stream 0.  Change "SHOULD" to "MAY" and Stream with Data, to Any Stream.

[MCruz] Fine.

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 23 Jul 2001
17:57:23)
> Brian,
> 
> As you said, in M3UA is perfectly possible to be sending traffic
> to the ASP for the same RK over multiple streams. Stream assignment
> for data messages is implementation dependent, then several
> algorithms could apply. Let's say as an example (ISUP traffic) 
> that CIC value is used for the stream assignment, CIC1 is assigned
> to stream1 and CIC2 is assigned to stream2. Then, the problem
> is NOT solved with:
> 
> > >  			   All ASP Traffic Maintenance messages
> > >                  SHOULD be sent on the stream which normally carries
the
> > >                  data traffic to which the message applies
> 
> Firstable, there is not such an stream which normally carries the
> data traffic, both stream1 and stream2 are used. Secondly, if the
> ASPTM msg is sent using stream1 (e.g.) then it can NOT be assured
> that this message arrives before data messages sent using stream2.
> 
> Then, the only way to assure that data is not lost would be to
> assign an stream per RC... not even so, because ASPTM msg could
> be valid for several RCs... then the only solution I can see is
> to let a timer expire before sending ASPTM msgs. This timer
> value could be pretty small because there is not a reason to 
> consider that an stream is significantly slower than other (only
> retransmitions could somehow slow an stream traffic down).
> 
> /MCruz

[snip]

> > >     Msg         Delivery Option      Stream
> > > 
> > >     NTFY(AS)    sequenced (SHOULD)   Stream `0' (SHOULD)
> > >     ASPUP       sequenced (SHOULD)   Stream `0' (SHOULD)
> > >     ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
> > >     ASPDN       sequenced (SHOULD)   Stream `0' (SHOULD)
> > >     ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
> > > 
> > >     ERR         out-of-order (MAY)   Stream `0' (SHOULD)
> > >     NTFY(Fail)  out-of-order (MAY)   Stream `0' (SHOULD)
> > > 
> > >     BEAT        out-of-order (MAY)   Any Stream (MAY)
> > >     BEAT Ack    out-of-order (MAY)   Any Stream (MAY)
> > > 
          NTFY(Alt)   sequenced (SHOULD)   Any Stream (MAY)
          ASPAC       sequenced (SHOULD)   Any Stream (MAY)
          ASPAC Ack   sequenced (SHOULD)   Any Stream (MAY)
          ASPIA       sequenced (SHOULD)   Any Stream (MAY)
          ASPIA Ack   sequenced (SHOULD)   Any Stream (MAY)

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

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SCCP Message Priority
Date: Mon, 23 Jul 2001 21:55:26 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 23 Jul 2001 14:10:55 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: John Loughney <[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.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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.
Importance takes up 3 of 8.  How about the top nibble of importance, such
as:

< 3.9.1  Flags
< 
<    The Flags parameter is a conglomerate of following parameters, <
described in ITU-T Recommendation Q.713 : < 
<       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 = 0x0101          |             Length = 8        | <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <      |
Seq. Control  | MP|Importance |  Hop Counter  |  Protocol Cl. | <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <
<  Message Priority/Importance
<
<  Importance (3.19/Q.713)
<
<  Bits 1-3 are coded to indicate the importance of the messages. The <
values are between 0 and 7, where the value of 0 indicates the least <
important and 7 indicates the most important.
<
<  Bits 4-6 are spare bits and should be coded zero.
<
<  Message Priority (T1.111.4/Table B4) <
<  Bits 7-8 are coded to indicate the message priority of the message in <
networks which support mutliple congestion level with message priority.
<  The values are between 0 and 2, where the value of 0 indicates the <
lowest priority and 2 indicates the most important.

[email-masked] wrote:                          (Mon, 23 Jul 2001
14:01:56)
>
> Hi,
> 
> Could someone please clarify whether SUA would allow ANSI message priority
> values to be conveyed between peer SUA/SUA Users.
> 
> Thanks
> Ray
> 

-- 
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, 23 Jul 2001 14:24:41 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: 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: tnt-dal-42-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: RE: M3UA: Routing Context
Date: Mon, 23 Jul 2001 13:04:29 -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: [161.114.32.105]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

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]
Sender: [email-masked]
Date: Mon, 23 Jul 2001 15:08:28 -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, SUA]: Gracefull shutdown of SGP
X-SMTP-HELO: imr2.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [12.34.240.68]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

"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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 23 Jul 2001 16:10:54 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M3UA and M2UA: ASPTM or BEAT on Stream other than `0'
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]

See comment below.

Ken

At 12:54 PM 7/23/01 -0500, you wrote:
>Maria,
>
>Timers are too slow and SCTP does not guarantee delivery
>or failure, 
>
>I've got another method:  send BEAT down each stream that
>corresponds to the ASPTM with a different Heartbeat
>data configuration.  Wait till you get all the BEAT Acks.
>Then send ASPTM on any stream.

It seems like you would want to send the ASP Inactive, wait for the ASP
Inactive Ack, then send the BEAT msgs.  Also, need to specify that BEAT Acks
MUST be sent on the stream on which the arrive?

>Nevertheless, the implementation should not be forced to
>send ASPTM on stream 0.  Change "SHOULD" to "MAY" and
>Stream with Data, to Any Stream.
>
>Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 23 Jul 2001
17:57:23)
> > Brian,
> > 
> > As you said, in M3UA is perfectly possible to be sending traffic
> > to the ASP for the same RK over multiple streams. Stream assignment
> > for data messages is implementation dependent, then several
> > algorithms could apply. Let's say as an example (ISUP traffic) 
> > that CIC value is used for the stream assignment, CIC1 is assigned
> > to stream1 and CIC2 is assigned to stream2. Then, the problem
> > is NOT solved with:
> > 
> > > >                      All ASP Traffic Maintenance messages
> > > >                  SHOULD be sent on the stream which normally carries
the
> > > >                  data traffic to which the message applies
> > 
> > Firstable, there is not such an stream which normally carries the
> > data traffic, both stream1 and stream2 are used. Secondly, if the
> > ASPTM msg is sent using stream1 (e.g.) then it can NOT be assured
> > that this message arrives before data messages sent using stream2.
> > 
> > Then, the only way to assure that data is not lost would be to
> > assign an stream per RC... not even so, because ASPTM msg could
> > be valid for several RCs... then the only solution I can see is
> > to let a timer expire before sending ASPTM msgs. This timer
> > value could be pretty small because there is not a reason to 
> > consider that an stream is significantly slower than other (only
> > retransmitions could somehow slow an stream traffic down).
> > 
> > /MCruz
>
>[snip]
>
> > > >     Msg         Delivery Option      Stream
> > > > 
> > > >     NTFY(AS)    sequenced (SHOULD)   Stream `0' (SHOULD)
> > > >     ASPUP       sequenced (SHOULD)   Stream `0' (SHOULD)
> > > >     ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
> > > >     ASPDN       sequenced (SHOULD)   Stream `0' (SHOULD)
> > > >     ASPUP Ack   sequenced (SHOULD)   Stream `0' (SHOULD)
> > > > 
> > > >     ERR         out-of-order (MAY)   Stream `0' (SHOULD)
> > > >     NTFY(Fail)  out-of-order (MAY)   Stream `0' (SHOULD)
> > > > 
> > > >     BEAT        out-of-order (MAY)   Any Stream (MAY)
> > > >     BEAT Ack    out-of-order (MAY)   Any Stream (MAY)
> > > > 
>           NTFY(Alt)   sequenced (SHOULD)   Any Stream (MAY)
>           ASPAC       sequenced (SHOULD)   Any Stream (MAY)
>           ASPAC Ack   sequenced (SHOULD)   Any Stream (MAY)
>           ASPIA       sequenced (SHOULD)   Any Stream (MAY)
>           ASPIA Ack   sequenced (SHOULD)   Any Stream (MAY)
>
>-- 
>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]>
Cc: Greg Sidebottom <[email-masked]>
Subject: RE: M3UA07: Network Appearance
Date: Mon, 23 Jul 2001 13:37:00 -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: [161.114.32.105]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

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]
To: "sigtran" <[email-masked]>
Subject: SCTP MIB Comments
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
From: [email-masked]
Date: Mon, 23 Jul 2001 16:46:24 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/23/2001 01:48:18 PM, Serialize 
             complete at 07/23/2001 01:48:18 PM
X-SMTP-HELO: radisys.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [206.102.10.35]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

To whom it may concern:

I have been reviewing the latest draft of the SCTP MIB, and I have a few
comments.

line 244: sctpCompliance is shown as a branch of sctpGroups. However, it is
defined in the MIB under sctpCompliances. I think that the extra level of
detail is not needed in the MIB structure diagram, so I would recommend
removing the sctpCompliance branch completely from here.

line 557: InetPortNumber does not exist in the version of INET-ADDRESS-MIB
defined in RFC 2851, but rather in a draft update to that MIB
(draft-ietf-ops-rfc2851-update-01.txt).

line 680: sctpMaxAssoc is defined with a syntax of Unsigned32, but the
description says that -1 should be used to indicate that the maximum number
of associations is dynamic. Either 0 should be used for this condition, or
else the syntax needs to be changed to Integer32(-1..2147483647).

line 982: The SCTP association table has object identifier sctpTables.2. 
There is no sctpTables.1. Either the association table should be
sctpTables.1 with the other tables also moved up, or else there should be a
comment stating that sctpTables.1 was intentionally not defined.

lines 1118 and 1253: Objects sctpAssocEntry.7 and sctpAssocEntry.16 are not
defined. Either the objects should be moved up, or else there should be a
comment stating that these objects were intentionally not defined.

line 1343: The size of sctpAssocLocalAddressIP should be restricted to be
between 1 and 64 characters, as shown in section 5 of RFC 2851. Thus, the
syntax should be InetAddress (SIZE (1..64)). I'm not sure if it is legal to
similarly restrict the enumeration list for sctpAssocLocalAddressIPType here
instead of in the compliance statement.

line 1350: The hyphen should be removed from "address-es" in the description
of sctpAssocLocalAddressIP.

line 1451: The size of sctpAssocRemAddressIP should be restricted to be
between 1 and 64 characters, as shown in section 5 of RFC 2851. Thus, the
syntax should be InetAddress (SIZE (1..64)). I'm not sure if it is legal to
similarly restrict the enumeration list for sctpAssocRemAddressIPType here
instead of in the compliance statement.

line 1573: I think that it would be better if the SCTP reverse lookup tables
had association somewhere in the object names (i.e.,
sctpLookupLocalPortTable should be renamed as
sctpAssocLookupLocalPortTable).

line 1593: This indexing scheme is considered illegal by some according to
the SMI definition (RFC 2578) section 7.8.1. An explanation for why can be
found in the document at this link: http://www.snmpinfo.com/tables.pdf. 
The table should be redefined as below. I think that it would be less of a
burden on the SNMP agent to leave out the time stamp and make the
association ID a read-only object (which is valid in SMIv2 for INDEX objects
in a table that would otherwise have no objects - see section 7.7 of the SMI
definition). The other reverse lookup tables should be similarly changed.
        sctpAssocLookupLocalPortTable OBJECT-TYPE
                SYNTAX SEQUENCE OF SctpAssocLookupLocalPortEntry
                MAX-ACCESS not-accessible
                STATUS current
                DESCRIPTION
                        "This table allows management stations to determine
the
                         associations that are using a local SCTP port
without
                         walking the entire sctpAssocTable table."
                ::= { sctpTables 5 }

        sctpAssocLookupLocalPortEntry OBJECT-TYPE
                SYNTAX SctpAssocLookupLocalPortEntry
                MAX-ACCESS not-accessible
                STATUS current
                DESCRIPTION
                        "This table is indexed by local port number and
association ID.
                        Management stations can determine which associations
are
                        using a particular local SCTP port by specifying a
particular
                        port number with no association ID and walking the
table until
                        the local port number changes its value."
                INDEX { sctpAssocLookupLocalPortNumber,
                                 sctpAssocLookupLocalPortAssocId }
                ::= { sctpAssocLookupLocalPortTable 1 }

        SctpAssocLookupLocalPortEntry ::= SEQUENCE {
                        sctpAssocLookupLocalPortNumber InetPortNumber,
                        sctpAssocLookupLocalPortAssocId Unsigned32
                }

        sctpAssocLookupLocalPortNumber OBJECT-TYPE
                SYNTAX InetPortNumber
                MAX-ACCESS not-accessible
                STATUS current
                DESCRIPTION
                        "A local SCTP port number used by one or more
associations."
                ::= { sctpAssocLookupLocalPortEntry 1 }

        sctpAssocLookupLocalPortAssocId OBJECT-TYPE
                SYNTAX Unsigned32
                MAX-ACCESS read-only
                STATUS current
                DESCRIPTION
                        "An association that is using the local SCTP port."
                ::= { sctpAssocLookupLocalPortEntry 2 }

line 2044: The description says that only IPv4 and IPv6 are required, but
the syntax includes unknown. If unknown is only permitted for the case of no
remote primary address, then it should state this in the description.

line 2049: If unknown is supported as an address type, then the InetAddress
size should not be restricted. If unknown is only included to support the
case of no remote primary address, then the size restriction can be made,
but 0 should be added as a valid size. 

line 2057: The description says that only IPv4 and IPv6 are required, but
the syntax includes unknown. I'm not sure what unknown could mean here,
since I wouldn't think that you could have an entry with no address in the
local address table because the address is part of the index (RFC 2851
prohibits the use of an empty InetAddress as an index).

line 2062: If unknown is supported as an address type, then the InetAddress
size should not be restricted.

line 2070: The description says that only IPv4 and IPv6 are required, but
the syntax includes unknown. I'm not sure what unknown could mean here,
since I wouldn't think that you could have an entry with no address in the
remote address table because the address is part of the index (RFC 2851
prohibits the use of an empty InetAddress as an index).

line 2075: If unknown is supported as an address type, then the InetAddress
size should not be restricted.

line 2204: As there is now one object with read-write access and no objects
with read-create access, the security considerations section should be
updated.

-- Michael

---
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, 23 Jul 2001 15:48:46 -0500
To: "sigtran" <[email-masked]>
From: Al Varney <[email-masked]>
Subject: Re: SUA: SCCP Message Priority
Cc: [email-masked], John Loughney <[email-masked]>
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]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>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] </x-flowed>
Date: Mon, 23 Jul 2001 16:32:56 -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 (V7) DRST question
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

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?

Jeff

"Gradischnig, Klaus" wrote:
> 
> John,
> 
> you are making a very valid point.
> 
> Klaus
> 
> > -----Original Message-----
> > From: Schantz, John [mailto:[email-masked]]
> > Sent: July 20, 2001 5:38 PM
> > To: sigtran
> > Subject: FW: M3UA (V7) DRST question
> >
> >
> >
> >
> > -----Original Message-----
> > From: Schantz, John
> > Sent: Friday, July 20, 2001 9:53 AM
> > To: [email-masked]'
> > Subject: RE: M3UA (V7) DRST question
> >
> >
> > Brian,
> >       I don't think I am reading a lot into "single management view".
> > This is the view that all SS7 nodes have today and if any SG wants to
> > connect into an SS7 network will need to abide by the same management
> > philosophy (it is built into the SS7 protocol).
> >
> >       So you're telling me that a partitioned SG will have a "single
> > management view" towards the SS7 network but it will not
> > maintain this view
> > for its' SGPs.  You are basically forcing the AS to have more
> > complicated
> > management structure because you are not willing to build a
> > node that abides
> > by the general philosophy that all other nodes in the network
> > must abide by.
> > So you are asking the AS to collect management messages from
> > each SGP, as
> > though they are independent nodes, before the AS can then
> > determine the true
> > state of a remote destination.  When are you going to stop
> > pushing all of
> > your dirty work onto the ASs?  Why is a limited node
> > architecture driving
> > the standard?  Who do you think will buy a SG like this
> > (cheap but almost no
> > network management functions)?  A small protocol converter
> > per link would be
> > better than this, at least it blindly convert the management
> > message and not
> > make its presence known.
> >
> >       You can make it OPTIONAL but thank goodness my node will be in
> > networks with real SGs.
> >
> > John
> >
> >  -----Original Message-----
> > From:         Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Thursday, July 19, 2001 4:38 PM
> > To:   sigtran
> > Subject:      Re: M3UA (V7) DRST question
> >
> > John,
> >
> > I think that you are reading alot into the "single management view"
> > statement, as it is not really defined what this means; but, I
> > understand what you are getting at.  Certainly the fact that it is
> > possible that an ASP may receive conflicting information from
> > individual SGP, it does not preclude building a system which assumes
> > this single management view.
> >
> > Perhaps a resolution to the situation, for the sake of
> > interoperability,
> > is to say the the SG SHOULD present such a single view of
> > availability/
> > congestion/restriction status, but that the ASP SHOULD keep
> > track of that
> > status on a per-SGP basis.
> >
> > Then, if an ASP implementation chooses to rely heavily on a single
> > management view from the SG, it must do so with the full understanding
> > that it might not interoperate as well with a partionable SG
> > implementation.  And, if the SGP implementation chooses to not present
> > such a single management view to the ASP, that it might not
> > interoperate
> > as well with ASPs which rely upon it.
> >
> > That way due warning is given, nothing is precluded, and maximum
> > interoperability may result.  Let the implementations solve the
> > details.
> >
> > Plus, this takes the least amount of text changes, right Greg?
> >
> > Comments?
> >
> > --Brian
> >
> > Schantz, John wrote:                           (Thu, 19 Jul
> > 2001 13:41:44)
> > > Brian,
> > >     I will need to read what the changes are but availability and
> > > congestion would show up in the status of the
> > 'links/associations', hence
> > it
> > > is already taken care of.  There is no parallel for
> > restricted for an
> > > interface.
> > >
> > >     If you look at the definition of a SG from the M3UA document:
> > >
> > > Signalling Gateway - An SG is a signaling agent that
> > receives/sends SCN
> > > native signaling at the edge of the IP network [1].  An SG
> > appears to
> > > the SS7 network as an SS7 Signalling Point.  An SG contains
> > a set of one
> > > or more unique Signalling Gateway Processes, of which one
> > or more is
> > > normally actively processing traffic.  Where an SG contains
> > more than
> > > one SGP, the SG is a logical entity and the contained SGPs must be
> > > coordinated into a single management view to the SS7
> > network and to the
> > > supported Application Servers.
> > >
> > >     Notice the highlighted "single management view", this
> > states to me
> > > that the SG has a single management function even if it is
> > composed of
> > > multiple SGPs.  We will be supporting multiple ASPs and we
> > will also have
> > a
> > > single management view of the system and it interfaces.
> > Therefore, if a
> > PC
> > > is prohibited, allowed, congested, or restricted, only
> > single management
> > > message should be sent to its adjacent nodes.  You can not
> > use DUNA, DAVA,
> > > SCON, DRST, etc. to manage a single SGP, they are the
> > "single management
> > > view" of the SG for destinations.
> > >
> > > 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]
> >
> 
> ---
> 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.Copley8.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 23 Jul 2001 16:41:56 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA and M2UA: ASPTM or BEAT on Stream other than `0'
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]>

Ken,

Ken Morneault wrote:            (Mon, 23 Jul 2001 16:10:54)
> 
> See comment below.
> 
> Ken
> 
> At 12:54 PM 7/23/01 -0500, you wrote:
> >Maria,
> >
> >Timers are too slow and SCTP does not guarantee delivery
> >or failure, 
> >
> >I've got another method:  send BEAT down each stream that
> >corresponds to the ASPTM with a different Heartbeat
> >data configuration.  Wait till you get all the BEAT Acks.
> >Then send ASPTM on any stream.
> 
> 
> It seems like you would want to send the ASP Inactive, wait
> for the ASP Inactive Ack, then send the BEAT msgs.  Also,
> need to specify that BEAT Acks MUST be sent on the stream
> on which the arrive?

No, other way around: I send the BEATs and wait for return _before_ sending
ASP Inactive.  That way one can ensure that the ASP Inactive won't overtake
Data can cause the receiver to discard the Data that arrives after the
ASPIA.

Same in the reverse direction.  Send BEATs and have them acked and then send
the ASPIA Ack.

BEATs can't be sent on the "same" stream because one end doesn't know what
stream is used for what on the other end.
(M2UA might have a better idea, but M3UA has less, and SUA has no idea).

It doesn't matter what stream the BEAT Ack comes on, the only thing verified
is that the Data has cleared on the stream towards which it was sent.

--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]
Subject: Re: SUA: SCCP Message Priority
To: "sigtran" <[email-masked]>
Date: Mon, 23 Jul 2001 17:42:19 -0400
X-MIMETrack: Serialize by Router on notes900/Telcordia(Release 5.0.6a
|January 
             17, 2001) at 07/23/2001 05:42:20 PM
X-SMTP-HELO: dnsmx1pya.telcordia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: dnsmx1pya.telcordia.com [128.96.20.31]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Since ANSI allows use of 5-bit and 8-bit SLS values using a part of the
importance field should work.

Ray

"Brian F. G. Bidulock" <[email-masked]> on 07/23/2001 03:10:55 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:   John Loughney
<[email-masked]> (bcc: Ray P. Singh/Telcordia) Subject:  Re: SUA:
SCCP Message Priority

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.
Importance takes up 3 of 8.  How about the top nibble of importance, such
as:

< 3.9.1  Flags
<
<    The Flags parameter is a conglomerate of following parameters, <
described in ITU-T Recommendation Q.713 : <
<       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 = 0x0101          |             Length = 8        | <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <      |
Seq. Control  | MP|Importance |  Hop Counter  |  Protocol Cl. | <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <
<  Message Priority/Importance
<
<  Importance (3.19/Q.713)
<
<  Bits 1-3 are coded to indicate the importance of the messages. The <
values are between 0 and 7, where the value of 0 indicates the least <
important and 7 indicates the most important.
<
<  Bits 4-6 are spare bits and should be coded zero.
<
<  Message Priority (T1.111.4/Table B4) <
<  Bits 7-8 are coded to indicate the message priority of the message in <
networks which support mutliple congestion level with message priority.
<  The values are between 0 and 2, where the value of 0 indicates the <
lowest priority and 2 indicates the most important.

[email-masked] wrote:                          (Mon, 23 Jul 2001
14:01:56)
>
> Hi,
>
> Could someone please clarify whether SUA would allow ANSI message priority
> values to be conveyed between peer SUA/SUA Users.
>
> Thanks
> Ray
>

--
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, 23 Jul 2001 16:42:45 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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]
Date: Mon, 23 Jul 2001 17:07:48 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked], Greg Sidebottom <[email-masked]>
Subject: Re: M3UA: Routing Context
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], 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: tnt-dal-42-202.dallas.net [209.44.42.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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]
To: "sigtran" <[email-masked]>
Date: Mon, 23 Jul 2001 15:20:26 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
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]>

Can this be done as a separate extension, rather than having to modify the
existing documents?  

Cheers,

L. Ong 
--

On Mon, 23 Jul 2001 16:42:45   Brian F. G. Bidulock wrote:
>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]

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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 23 Jul 2001 18:34:19 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
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]

Does an ASP take the NTFY(SGP Blocking Pending) as a DUNA for all DPCs
supported by that SGP?  Or, does the ASP have to wait for the SCTP
association to fail?

At 04:42 PM 7/23/01 -0500, you wrote:
>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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 23 Jul 2001 18:42:28 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M3UA and M2UA: ASPTM or BEAT on Stream other than `0'
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'm adding the text changes you suggested for M2UA.

R-

Ken

At 04:41 PM 7/23/01 -0500, you wrote:
>Ken,
>
>Ken Morneault wrote:            (Mon, 23 Jul 2001 16:10:54)
> > 
> > See comment below.
> > 
> > Ken
> > 
> > At 12:54 PM 7/23/01 -0500, you wrote:
> > >Maria,
> > >
> > >Timers are too slow and SCTP does not guarantee delivery
> > >or failure, 
> > >
> > >I've got another method:  send BEAT down each stream that
> > >corresponds to the ASPTM with a different Heartbeat
> > >data configuration.  Wait till you get all the BEAT Acks.
> > >Then send ASPTM on any stream.
> > 
> > 
> > It seems like you would want to send the ASP Inactive, wait
> > for the ASP Inactive Ack, then send the BEAT msgs.  Also,
> > need to specify that BEAT Acks MUST be sent on the stream
> > on which the arrive?
>
>No, other way around: I send the BEATs and wait for return
>_before_ sending ASP Inactive.  That way one can ensure that
>the ASP Inactive won't overtake Data can cause the receiver
>to discard the Data that arrives after the ASPIA.
>
>Same in the reverse direction.  Send BEATs and have them
>acked and then send the ASPIA Ack.
>
>BEATs can't be sent on the "same" stream because one end
>doesn't know what stream is used for what on the other end.
>(M2UA might have a better idea, but M3UA has less, and SUA
>has no idea).
>
>It doesn't matter what stream the BEAT Ack comes on, the
>only thing verified is that the Data has cleared on the stream
>towards which it was sent.
>
>--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-Lotus-FromDomain: TEKELEC
From: Dan Brendes <[email-masked]>
To: "sigtran" <[email-masked]>
Date: Mon, 23 Jul 2001 18:51:22 -0400
Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 23 Jul 2001 19:14:15 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA-09: Traffic Mode
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]

I would prefer that M3UA renumber when it adopts the Broadcast mode so that
Broadcast has a value of 0x3.

R-

Ken

At 06:02 AM 7/21/01 -0500, you wrote:
>Ken,
>
>Not really an issue, but since Traffic Mode is a common parameter
>could we line up the UAs on codepoints, even if all the values are
>not used?  The only conflicting codepoint is M2UA with Broadcast as
>0x3.  If Broadcast mode is made 0x5 then there is no conflicts.
>
>Suggest we change:
>
>         0x3         Broadcast
>to 
>         0x5         Broadcast
>
>--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]
From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Tue, 24 Jul 2001 11:05:04 +0530
Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

The following is based on the assumption that an SG/SGP is about to
fail..'be pulled out'.

I'm not convinced about what value the ASP can derive from such a warning
message(ntfy).
Considering a case of multiple SGPs(maybe in load-share or override mode),
the ASP will have an option of routing traffic via other SGPs. So if
multiple SGPs are there, the ASP would already have established associations
to these alternate SGPs.
Unless we're saying that when this warning message arrives on the ASP, it is
supposed to establish association to alternate SGP(s), send the required
ASPAC messages and be ready to route traffic through it BEFORE the
association actually goes down to the about-to-fail SGP ! Would this not
defeat the purpose of SG/SGP redundancy if it is present?

In most likelihood, wouldn't the ASP have already activated itself(for
available AS(s)) in any available alternate SGPs?

The impact, IMHO, will be for messages already sent on the association with
the about-to-fail SGP. This can be prevented by simply doing a graceful
close of the SCTP association initiated from the about-to-fail SGP.

Also, NTFY will have to be sent to all connected ASPs, for all corresponding
active AS(s) associated with these ASPs.

regards,
Harsh

"Brian F. G. Bidulock" <[email-masked]> on 07/24/2001 03:12:45 AM

Please respond to [email-masked]

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

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]
From: "Jesske, R" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Question on M3UA07 -- Primitives from the M3UA User
Date: Tue, 24 Jul 2001 07:49:42 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: fw9.telekom.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [62.156.152.68]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,
I have a question on the below mentioned Paragraph: 4.1.1 Receipt of
Primitives from the M3UA-User On receiving an MTP-TRANSFER request primitive
from an upper layer at an ASP/IPSP, or the nodal inter-working function at
an SGP, the M3UA layer sends a corresponding DATA message (see Section 3) to
its M3UA peer. The M3UA peer receiving the DATA message sends an
MTP-TRANSFER indication primitive to the upper layer.

The paragraph confuses me, because I thought that in the above mentioned
scenario the peer M3UA in the SG has only the task to proceed the primitive
to or from the "lower layer Interface"(via the NIF to/from the MTP3).The
lower Interface is from my point of view the interface between M3UA and MTP3
in the SG. 
Therefore the M3UA proceeds a MTP-Transfer request primitive from the M3UA
to the MTP3 in the SG, then transferring the protocol elements to the MTP3
peer in the SEP,  the MTP3 Peer in the SEP proceeds the information via an
Indication primitive to the upper layer (MTP3 User in the SEP).  Below shown
picture shows what I think is correct. 

              +------------+
              |            |
              |  MTP-User  |
              |            |
              +------------+
                  ^    |
 MTP-TRANSFER-IND |    | MTP-TRANSFER-REQ
                  |    |
                  |    |
                  |    v
              +------------+
              |            |
              |  M3UA-ASP  |
              |            |
              +------------+
                  ^    |
                  |    |
             DATA |    | DATA
                  |    |
                  |    v
              +------------+
              |            |
              | M3UA in SG |
              |            |
              +------------+
                  ^    |
 MTP-TRANSFER-IND |    | MTP-TRANSFER-REQ
                  |    |
                  |    |
                  |    v
              +------------+
              |            |
              | MTP3 in SG |
              |            |
              +------------+
                  ^    |
                  |    |
Protocol elements |    | Protocol elements
                  |    |
                  |    |
                  |    |
                  |    v
              +------------+
              |            |
              |MTP3 in SEP |
              |            |
              +------------+
                  ^    |
                  |    |
                  |    |
 MTP-TRANSFER-REQ |    | MTP-TRANSFER-IND
                  |    v
              +------------+
              |            |
              |  MTP User  |
              |   in SEP   |
              |            |
              +------------+

If I'm correct with my view the paragraph should be changed, if not please
correct me. (Or did I read the Paragraph in the wrong way?)

Best regards

Roland

Roland Jesske 
Gateways and Signalling 
T-Nova Deutsche Telekom Innovationsgesellschaft mbH Technologiezentrum 
Section E36o 
Am Kavaleriesand 3 
64295 DARMSTADT, GERMANY 
Phone:  +49 6151 83-5940 
Fax:    +49 6151 83-4577 
mailto: [email-masked] 
http://www.t-nova.de 

Attachment Converted: "c:\program files\qualcomm\eudora pro\attach\Jesske,
Roland.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Question on M3UA07 -- Primitives from the M3UA User
Date: Tue, 24 Jul 2001 09:37:39 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.237.142.116]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Roland,

You are missing the point that the M3UA (at the SGP) does not have an
interface towards the MTPL3 (at the SGP), then the NIF should be included in
your diagram (see below).

In that parragraph you mentioned, what is not completely true is that the
M3UA receives an MTP-TRANSFER_req from the NIF at the SGP, it receives the
same information contained in MTP-TRANSFER_req but the primitive as such is
implementation dependent. Then, a slight rewording may be needed.

/MCruz

-----Original Message-----
From: Jesske, R [mailto:[email-masked]] Sent: Tuesday, July 24,
2001 7:50 AM
To: sigtran
Subject: Question on M3UA07 -- Primitives from the M3UA User

Hi all,
I have a question on the below mentioned Paragraph: 4.1.1 Receipt of
Primitives from the M3UA-User On receiving an MTP-TRANSFER request primitive
from an upper layer at an ASP/IPSP, or the nodal inter-working function at
an SGP, the M3UA layer sends a corresponding DATA message (see Section 3) to
its M3UA peer. The M3UA peer receiving the DATA message sends an
MTP-TRANSFER indication primitive to the upper layer.

The paragraph confuses me, because I thought that in the above mentioned
scenario the peer M3UA in the SG has only the task to proceed the primitive
to or from the "lower layer Interface"(via the NIF to/from the MTP3).The
lower Interface is from my point of view the interface between M3UA and MTP3
in the SG. 
Therefore the M3UA proceeds a MTP-Transfer request primitive from the M3UA
to the MTP3 in the SG, then transferring the protocol elements to the MTP3
peer in the SEP,  the MTP3 Peer in the SEP proceeds the information via an
Indication primitive to the upper layer (MTP3 User in the SEP).  Below shown
picture shows what I think is correct. 

              +------------+
              |            |
              |  MTP-User  |
              |            |
              +------------+
                  ^    |
 MTP-TRANSFER-IND |    | MTP-TRANSFER-REQ
                  |    |
                  |    |
                  |    v
              +------------+
              |            |
              |  M3UA-ASP  |
              |            |
              +------------+
                  ^    |
                  |    |
             DATA |    | DATA
                  |    |
                  |    v
              +------------+
              |            |
              | M3UA in SG |
              |            |
              +------------+
+                 ^    |
+                 |    |
+       DATA_REQ* |    | DATA_IND*
+                 |    |
+                 |    v
+             +------------+
+             |            |
+             | NIF* in SG |     *: implementation +             |
|		dependent +             +------------+
                  ^    |
 MTP-TRANSFER-IND |    | MTP-TRANSFER-REQ
                  |    |
                  |    |
                  |    v
              +------------+
              |            |
              | MTP3 in SG |
              |            |
              +------------+
                  ^    |
                  |    |
Protocol elements |    | Protocol elements
                  |    |
                  |    |
                  |    |
                  |    v
              +------------+
              |            |
              |MTP3 in SEP |
              |            |
              +------------+
                  ^    |
                  |    |
                  |    |
 MTP-TRANSFER-REQ |    | MTP-TRANSFER-IND
                  |    v
              +------------+
              |            |
              |  MTP User  |
              |   in SEP   |
              |            |
              +------------+

If I'm correct with my view the paragraph should be changed, if not please
correct me. (Or did I read the Paragraph in the wrong way?)

Best regards

Roland

Roland Jesske 
Gateways and Signalling 
T-Nova Deutsche Telekom Innovationsgesellschaft mbH Technologiezentrum 
Section E36o 
Am Kavaleriesand 3 
64295 DARMSTADT, GERMANY 
Phone:  +49 6151 83-5940 
Fax:    +49 6151 83-4577 
mailto: [email-masked] 
http://www.t-nova.de 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 24 Jul 2001 03:10:49 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Question on M3UA07 -- Primitives from the M3UA User
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]>

Roland,

According to normal OSI convention, a request on one peer turns into an
indication on the other.

Your diagram should look like this:

           ___________                           ___________ 
          |           |                         |           |
          |    MTP    |                         |    MTP    |
          |   User    |                         |   User    |
          |           |                         |           |
          |___________|                         |___________|
             ^     |                               ^     | MTP-TRANSFER |
| MTP-TRANSFER     MTP-TRANSFER |     | MTP-TRANSFER
  Indication |     | Request            Indication |     | Request
             |     |                               |     |   
             |     |                               |     |   
           __|_____v__                           __|_____v__ 
          |  |     |  |          DATA           |  |     |  |
          |  |     +--+------------------------>|--+     |  |
          |  |        |                         |        |  |
          |  | M3UA   |                         |   M3UA |  |
          |  |        |          DATA           |        |  |
          |  +--------|<------------------------+--------+  |
          |___________|                         |___________|

--Brian

Jesske, R wrote:                                          (Tue, 24 Jul 2001
07:49:42)
> Hi all,
> I have a question on the below mentioned Paragraph:
> 4.1.1 Receipt of Primitives from the M3UA-User
> On receiving an MTP-TRANSFER request primitive from an upper layer at 
> an ASP/IPSP, or the nodal inter-working function at an SGP, the M3UA 
> layer sends a corresponding DATA message (see Section 3) to its M3UA 
> peer. The M3UA peer receiving the DATA message sends an MTP-TRANSFER 
> indication primitive to the upper layer.
> 
> The paragraph confuses me, because I thought that in the above mentioned
scenario the peer M3UA in the SG has only the task to proceed the primitive
to or from the "lower layer Interface"(via the NIF to/from the MTP3).The
lower Interface is from my point of view the interface between M3UA and MTP3
in the SG. 
> Therefore the M3UA proceeds a MTP-Transfer request primitive from the M3UA
to the MTP3 in the SG, then transferring the protocol elements to the MTP3
peer in the SEP,  the MTP3 Peer in the SEP proceeds the information via an
Indication primitive to the upper layer (MTP3 User in the SEP).  Below shown
picture shows what I think is correct. 
> 
>               +------------+
>               |            |
>               |  MTP-User  |
>               |            |
>               +------------+
>                   ^    |
>  MTP-TRANSFER-IND |    | MTP-TRANSFER-REQ
>                   |    |
>                   |    |
>                   |    v
>               +------------+
>               |            |
>               |  M3UA-ASP  |
>               |            |
>               +------------+
>                   ^    |
>                   |    |
>              DATA |    | DATA
>                   |    |
>                   |    v
>               +------------+
>               |            |
>               | M3UA in SG |
>               |            |
>               +------------+
>                   ^    |
>  MTP-TRANSFER-IND |    | MTP-TRANSFER-REQ
>                   |    |
>                   |    |
>                   |    v
>               +------------+
>               |            |
>               | MTP3 in SG |
>               |            |
>               +------------+
>                   ^    |
>                   |    |
> Protocol elements |    | Protocol elements
>                   |    |
>                   |    |
>                   |    |
>                   |    v
>               +------------+
>               |            |
>               |MTP3 in SEP |
>               |            |
>               +------------+
>                   ^    |
>                   |    |
>                   |    |
>  MTP-TRANSFER-REQ |    | MTP-TRANSFER-IND
>                   |    v
>               +------------+
>               |            |
>               |  MTP User  |
>               |   in SEP   |
>               |            |
>               +------------+
> 
> If I'm correct with my view the paragraph should be changed, if not please
correct me. (Or did I read the Paragraph in the wrong way?)
> 
> Best regards
> 
> Roland
> 
> 
> 
> Roland Jesske 
> Gateways and Signalling 
> T-Nova Deutsche Telekom Innovationsgesellschaft mbH 
> Technologiezentrum 
> Section E36o 
> Am Kavaleriesand 3 
> 64295 DARMSTADT, GERMANY 
> Phone:  +49 6151 83-5940 
> Fax:    +49 6151 83-4577 
> mailto: [email-masked] 
> http://www.t-nova.de 
> 

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]
Subject: RE: [M3UA, SUA]: Gracefull shutdown of SGP
Date: Tue, 24 Jul 2001 11:25:28 +0200
Thread-Topic: [M3UA, SUA]: Gracefull shutdown of SGP
Thread-Index: AcEUBO2UMrICEqMDQFCvpBzbWTqaQQAG+pAw
From: Bernard Kuc <[email-masked]>
To: "sigtran" <[email-masked]>
X-SMTP-HELO: mail.azisa.co.za
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.azisa.co.za [196.14.124.43]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi

Being warned before the association goes down will always improve the
possibilities that the ASP has to mitigate any problems. I agree with Brian
that a NTFY would be appropriate. This NTFY could be only informational, in
that the ASP can ignore it, and await the assoc shutdown, or the ASP could
decide to go inactive and down before the shutdown.

One question is whether the ASP should assume that it has been taken to the
INACTIVE state when it receives the NTFY(SGP Blocking Pending), or that it
should itself now send the INACTIVE message to the SGP.

One performance enhancement that can be made is that the SGP only sends the
NTFY(SGP Blocking Pending) to ASPs that it receives messages from. 
This way if there was no traffic being exchanged between an ASP and a SGP at
the time that the SGP inhibits the association, then it most probably would
not harm to take association down without the NTFY.

I'd assume that all point codes that were only available at the ASP through
this SGP should be marked as unavailable, if there is no other route to
them.

Bernard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent: 24 July 2001
07:35
To: sigtran
Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP

Hi,

The following is based on the assumption that an SG/SGP is about to
fail..'be
pulled out'.

I'm not convinced about what value the ASP can derive from such a warning
message(ntfy).
Considering a case of multiple SGPs(maybe in load-share or override mode),
the
ASP will have an option of routing traffic via other SGPs. So if multiple
SGPs are there, the ASP would already have
established associations to these alternate SGPs.
Unless we're saying that when this warning message arrives on the ASP, it is
supposed to establish association to alternate SGP(s), send the required
ASPAC messages and be ready to route traffic through
it BEFORE the association actually goes down to the about-to-fail SGP !
Would this not  defeat the purpose of SG/SGP redundancy if it is present?

In most likelihood, wouldn't the ASP have already activated itself(for
available
AS(s)) in any available alternate SGPs?

The impact, IMHO, will be for messages already sent on the association with
the
about-to-fail SGP. This can be prevented by simply doing a graceful close of
the SCTP association initiated from the
about-to-fail SGP.

Also, NTFY will have to be sent to all connected ASPs, for all corresponding
active AS(s) associated with these ASPs.

regards,
Harsh

"Brian F. G. Bidulock" <[email-masked]> on 07/24/2001 03:12:45 AM

Please respond to [email-masked]

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

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]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA-07: Broadcast mode changes
Date: Tue, 24 Jul 2001 11:28:47 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: albatross-ext.wise.edt.ericsson.se [194.237.142.116]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I glanced over the mail below... I have a question, what is the need to have
this broadcast mode? What is the point to process one message in all active
ASPs for one AS?

You may have already talked about that in a previous thread... which one?

Thanks
/MCruz

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Friday, July
13, 2001 3:51 PM
To: sigtran
Subject: M3UA-07: Broadcast mode changes

Greg,

Here are the changes to include Broadcast mode.  They aren't really that bad
either.

---cut-here--------X-----------

*** m3ua-07.mods	Thu Jul 12 17:58:55 2001 --- m3ua-07.mods2	Fri
Jul 13 08:26:37 2001 ***************
*** 245,257 ****
  IP Server Process (IPSP) - A process instance of an IP-based 
  application.  An IPSP is essentially the same as an ASP, except that it
  uses M3UA in a point-to-point fashion.  Conceptually, an IPSP does not 
  use the services of a Signalling Gateway.
  
! Signalling Gateway Process (SGP) - A process instance of a Signalling !
Gateway.  It serves as an active, back-up or load-sharing process of a !
Signalling Gateway.
  
  Signalling Gateway - An SG is a signaling agent that receives/sends SCN 
  native signaling at the edge of the IP network [1].  An SG appears to 
  the SS7 network as an SS7 Signalling Point.  An SG contains a set of one 
  or more unique Signalling Gateway Processes, of which one or more is ---
245,257 ----
  IP Server Process (IPSP) - A process instance of an IP-based 
  application.  An IPSP is essentially the same as an ASP, except that it
  uses M3UA in a point-to-point fashion.  Conceptually, an IPSP does not 
  use the services of a Signalling Gateway.
  
! Signalling Gateway Process (SGP) - A process instance of a Signalling !
Gateway.  It serves as an active, back-up, load-sharing or broadcast !
process of a Signalling Gateway.
  
  Signalling Gateway - An SG is a signaling agent that receives/sends SCN 
  native signaling at the edge of the IP network [1].  An SG appears to 
  the SS7 network as an SS7 Signalling Point.  An SG contains a set of one 
  or more unique Signalling Gateway Processes, of which one or more is
***************
*** 625,635 ****
  signalling processes.  To support this, a signalling process must be 
  able to support distribution of M3UA messages to many simultaneous 
  active associations.  This message distribution function is based on 
  the status of provisioned routing keys, the availability of signalling 
  points in the SS7 network, and the redundancy model (active-standby, !
load-sharing, n+k) of the remote signalling processes.

  
  Sidebottom et al                                             [Page 11] ---
625,635 ----
  signalling processes.  To support this, a signalling process must be 
  able to support distribution of M3UA messages to many simultaneous 
  active associations.  This message distribution function is based on 
  the status of provisioned routing keys, the availability of signalling 
  points in the SS7 network, and the redundancy model (active-standby, !
load-sharing, broadcast, n+k) of the remote signalling processes.

  
  Sidebottom et al                                             [Page 11]
***************
*** 831,842 ****
  the individual ASPs in the list, as well as configuration changes and 
  possible fail-over mechanisms. 
  
  Normally, one or more ASPs are active in the AS (i.e., currently 
  processing traffic) but in certain failure and transition cases it is !
possible that there may be no active ASP available.  Both load-sharing ! and
backup scenarios are supported.
  
  When there is no matching Routing Key entry for an incoming SS7 
  message, a default treatment SHOULD be specified.  Possible solutions 
  are to provide a default Application Server at the SGP that directs all 
  unallocated traffic to a (set of) default ASP(s), or to drop the ---
831,842 ----
  the individual ASPs in the list, as well as configuration changes and 
  possible fail-over mechanisms. 
  
  Normally, one or more ASPs are active in the AS (i.e., currently 
  processing traffic) but in certain failure and transition cases it is !
possible that there may be no active ASP available.  Broadcast, !
load-sharing and backup scenarios are supported.
  
  When there is no matching Routing Key entry for an incoming SS7 
  message, a default treatment SHOULD be specified.  Possible solutions 
  are to provide a default Application Server at the SGP that directs all 
  unallocated traffic to a (set of) default ASP(s), or to drop the
***************
*** 996,1008 ****
  "k" ASPs are available to take over for a failed or unavailable ASP.  A 
  "1+1" active/back-up redundancy is a subset of this model. A simplex 
  "1+0" model is also supported as a subset, with no ASP redundancy.
  
  At the SGP, an Application Server list contains active and inactive ! ASPs
to support ASP load-sharing and fail-over procedures.  The list of ! ASPs
within a logical Application Server is kept updated in the SGP to ! reflect
the active Application Server Process(es).
  
  To avoid a single point of failure, it is recommended that a minimum of 
  two ASPs be in the list, resident in separate hosts and therefore 
  available over different SCTP Associations.  For example, in the 
  network shown in Figure 1, all messages to DPC x could be sent to ASP1 ---
996,1008 ----
  "k" ASPs are available to take over for a failed or unavailable ASP.  A 
  "1+1" active/back-up redundancy is a subset of this model. A simplex 
  "1+0" model is also supported as a subset, with no ASP redundancy.
  
  At the SGP, an Application Server list contains active and inactive ! ASPs
to support ASP broadcast, load-sharing and fail-over procedures.
! The list of ASPs within a logical Application Server is kept updated ! in
the SGP to reflect the active Application Server Process(es).
  
  To avoid a single point of failure, it is recommended that a minimum of 
  two ASPs be in the list, resident in separate hosts and therefore 
  available over different SCTP Associations.  For example, in the 
  network shown in Figure 1, all messages to DPC x could be sent to ASP1
***************
*** 1064,1084 ****
  Signalling Gateway is deployed as a cluster of hosts acting as a single 
  SG.  A primary/back-up redundancy model is possible, where the 
  unavailability of the SCTP association to a primary SGP could be used 
  to reroute affected traffic to an alternate SGP.  A load-sharing model 
  is possible, where the signalling messages are load-shared between !
multiple SGPs.  The distribution of the MTP3-user messages over the ! SGPs
should be done in such a way to minimize message mis-sequencing, ! as
required by the SS7 User Parts.
  
  It may also be possible for an ASP to use more than one SG to access a 
  specific SS7 end point, in a model that resembles an SS7 STP mated 
  pair.  Typically, SS7 STPs are deployed in mated pairs, with traffic 
  load-shared between them.  Other models are also possible, subject to 
  the limitations of the local SS7 network provisioning guidelines.
  
! >From the perspective of the M3UA layer at an ASP, a particular SG is 
  capable of transferring traffic to an SS7 destination if an SCTP 
  association with at least one SGP of the SG is established, the SGP has 
  returned an acknowledgement to the ASP to indicate that the ASP is 
  actively handling traffic for that destination, and the SGP has not 
  indicated that the destination is inaccessible.  When an ASP is ---
1064,1085 ----
  Signalling Gateway is deployed as a cluster of hosts acting as a single 
  SG.  A primary/back-up redundancy model is possible, where the 
  unavailability of the SCTP association to a primary SGP could be used 
  to reroute affected traffic to an alternate SGP.  A load-sharing model 
  is possible, where the signalling messages are load-shared between !
multiple SGPs.  A broadcast model is also possible, where signalling !
messages are sent to each active SGP in the SG.  The distribution of ! the
MTP3-user messages over the SGPs should be done in such a way to ! minimize
message mis-sequencing, as required by the SS7 User Parts.
  
  It may also be possible for an ASP to use more than one SG to access a 
  specific SS7 end point, in a model that resembles an SS7 STP mated 
  pair.  Typically, SS7 STPs are deployed in mated pairs, with traffic 
  load-shared between them.  Other models are also possible, subject to 
  the limitations of the local SS7 network provisioning guidelines.
  
! From the perspective of the M3UA layer at an ASP, a particular SG is 
  capable of transferring traffic to an SS7 destination if an SCTP 
  association with at least one SGP of the SG is established, the SGP has 
  returned an acknowledgement to the ASP to indicate that the ASP is 
  actively handling traffic for that destination, and the SGP has not 
  indicated that the destination is inaccessible.  When an ASP is
***************
*** 1090,1104 ****
  
  Sidebottom et al                                             [Page 19]
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
  
! both active/back-up and load-sharing model, in the event of failures, !
recovery and maintenance activities.  The ASP M3UA may also use this !
information for congestion avoidance purposes.  The distribution of the !
MTP3-user messages over the SGPs should be done in such a way to ! minimize
message mis-sequencing, as required by the SS7 User Parts.
  
  1.4.5 Flow Control
  Local Management at an ASP may wish to stop traffic across an SCTP 
  association in order to temporarily remove the association from service 
  or to perform testing and maintenance activity.  The function could ---
1091,1106 ----
  
  Sidebottom et al                                             [Page 19]
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
  
! active/back-up, load-sharing and broadcast models, in the event of !
failures, recovery and maintenance activities.  The ASP M3UA may also ! use
this information for congestion avoidance purposes.  The ! distribution of
the MTP3-user messages over the SGPs should be done in ! such a way to
minimize message mis-sequencing, as required by the SS7 ! User Parts.
  
  1.4.5 Flow Control
  Local Management at an ASP may wish to stop traffic across an SCTP 
  association in order to temporarily remove the association from service 
  or to perform testing and maintenance activity.  The function could
***************
*** 2746,2755 ****
--- 2748,2758 ----
     Server.  The valid values for Traffic Mode Type are shown in the 
     following table:
  
        1     Over-ride
        2     Load-share
+       3     Broadcast

  Sidebottom et al                                             [Page 48]
  
***************
*** 3184,3221 ****
     operation of the ASP within an AS. The valid values for Traffic Mode 
     Type are shown in the following table:
  
           1         Over-ride
           2         Load-share
!          3         Over-ride (Standby) !          4         Load-share
(Standby) ! 
!    Within a particular Routing Context, Over-ride and Load-share, !
either active or standby, MUST NOT be mixed.  The Over-ride value !
indicates that the ASP is operating in Over-ride mode, and the ASP !
takes over all traffic in an Application Server (i.e., primary/back- !    up
operation), over-riding any currently active ASPs in the AS.  In !
Load-share mode, the ASP will share in the traffic distribution with !
any other currently active ASPs.  The Standby versions of the Over- !
ride and Load-share Types indicate that the ASP is declaring itself !
ready to accept traffic but leaves it up to the sender as to when !    the
traffic is started.  Over-ride (Standby) indicates that the !    traffic
sender continues to use the currently active ASP until it !    can no longer
send/receive traffic (i.e., the currently active ASP !    transitions to
state ASP-DOWN or ASP-ACTIVE).  At this point the !    sender MUST move the
standby ASP to the ASP-ACTIVE state and !    commence traffic.  Load-share
(Standby) is similar - the sender !    continues to load-share to the
current ASPs until it is determined 

  Sidebottom et al                                             [Page 56]
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
  
!    that there is insufficient resources in the Load-share group.  When !
there are insufficient ASPs, the sender MUST move the ASP to state !
ASP-ACTIVE.
  
  Routing Context: n X 32-bit integers
  
     The optional Routing Context parameter contains (a list of) integers 
     indexing the Application Server traffic that the sending ASP is ---
3187,3230 ----
     operation of the ASP within an AS. The valid values for Traffic Mode 
     Type are shown in the following table:
  
           1         Over-ride
           2         Load-share
!          3         Broadcast
!          5         Over-ride (Standby) !          6         Load-share
(Standby) !          7         Broadcast (Standby) ! 
!    Within a particular Routing Context, Over-ride, Load-share  and !
Broadcast, either active or standby, MUST NOT be mixed.  The !    Over-ride
value indicates that the ASP is operating in Over-ride !    mode, and the
ASP takes over all traffic in an Application Server !    (i.e.,
primary/back- up operation), over-riding any currently !    active ASPs in
the AS.  In Load-share mode, the ASP will share in !    the traffic
distribution with any other currently active ASPs.  In !    the Broadcast
mode, the ASP will receive the same messages as any !    other currently
active ASP.  The Standby versions of the Over- !    ride, Load-share and
Broadcast Types indicate that the ASP is !    declaring itself ready to
accept traffic but leaves it up to the !    sender as to when the traffic is
started.  Over-ride (Standby) !    indicates that the traffic sender
continues to use the currently !    active ASP until it can no longer
send/receive traffic (i.e., the !    currently active ASP transitions to
state ASP-DOWN or ASP-ACTIVE).
!    At this point the sender MUST move the standby ASP to the !
ASP-ACTIVE state and commence traffic.  Load-share (Standby) and !
Broadcast (Standby) is similar - the sender continues to load-share !    or
broadcast to the current ASPs until it is determined that there

  Sidebottom et al                                             [Page 56]
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
  
!    is insufficient resources in the Load-share or Broadcast group.
!    When that there is insufficient resources in the Load-share or !
Broadcast group.  When there are insufficient ASPs, the sender MUST !
move the ASP to state ASP-ACTIVE.
  
  Routing Context: n X 32-bit integers
  
     The optional Routing Context parameter contains (a list of) integers 
     indexing the Application Server traffic that the sending ASP is
***************
*** 3240,3252 ****
  
  3.7.2 ASP Active Acknowledgement (ASP Active Ack)
  
  The ASP Active Ack message is used to acknowledge an ASP Active message 
  received from a remote M3UA peer.  In the case where an ASP Active !
(Over-ride (standby)) or ASP Active (Load-share (standby)) message is !
received, a second ASP Active Ack message is sent when the ASP is moved !
from the ASP-STANDBY to the ASP-ACTIVE state.
  
  The ASP Active Ack message contains the following parameters:
  
       Traffic Mode Type     Mandatory
       Routing Context       Optional
--- 3249,3262 ----
  
  3.7.2 ASP Active Acknowledgement (ASP Active Ack)
  
  The ASP Active Ack message is used to acknowledge an ASP Active message 
  received from a remote M3UA peer.  In the case where an ASP Active !
(Over-ride (standby)), ASP Active (Load-share (standby)) or ASP Active !
(Broadcast (standby)) message is received, a second ASP Active Ack ! message
is sent when the ASP is moved from the ASP-STANDBY to the ! ASP-ACTIVE
state.
  
  The ASP Active Ack message contains the following parameters:
  
       Traffic Mode Type     Mandatory
       Routing Context       Optional
***************
*** 3623,3635 ****
           2    Alternate ASP Active
  
  These notifications are not based on the SGP reporting the state change 
  of an ASP or AS.  In the Insufficent ASP Resources case, the SGP is 
  indicating to an ASP_INACTIVE ASP in the AS that another ASP is ! required
in order to handle the load of the AS (Load-sharing mode).  
! For the Alternate ASP Active case, an ASP is informed when an alternate !
ASP transitions to the ASP-ACTIVE state in Over-ride mode.  
  
  The format and description of the optional Routing Context and Info 
  String parameters is the same as for the ASP Active message (See 
  Section 
  3.5.5.)
--- 3633,3646 ----
           2    Alternate ASP Active
  
  These notifications are not based on the SGP reporting the state change 
  of an ASP or AS.  In the Insufficent ASP Resources case, the SGP is 
  indicating to an ASP_INACTIVE ASP in the AS that another ASP is ! required
in order to handle the load of the AS (Load-sharing or ! Broadcast mode).
For the Alternate ASP Active case, an ASP is ! informed when an alternate
ASP transitions to the ASP-ACTIVE state in ! Over-ride mode.  
  
  The format and description of the optional Routing Context and Info 
  String parameters is the same as for the ASP Active message (See 
  Section 
  3.5.5.)
***************
*** 3654,3673 ****
  
  The M3UA message distribution function (see Section 1.4.2.1) determines 
  the Application Server (AS) based on comparing the information in the 
  MTP-TRANSFER request primitive with a provisioned Routing Key. 
  
! >From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE 
  state is selected and a DATA message is constructed and issued on the 
  corresponding SCTP association.  If more than one ASP is in the ASP-
  ACTIVE state (i.e., traffic is to be load-shared across more than one 
  ASP), one of the ASPs in the ASP_ACTIVE state is selected from the ! list.
The selection algorithm is implementation dependent but could, ! for
example, be round-robin or based on, for example, the SLS or ISUP ! CIC.
The appropriate selection algorithm must be chosen carefully as ! it is
dependent on application assumptions and understanding of the ! degree of
state coordination between the ASP_ACTIVE ASPs in the AS. 

  Sidebottom et al                                             [Page 64]
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001 ---
3665,3686 ----
  
  The M3UA message distribution function (see Section 1.4.2.1) determines 
  the Application Server (AS) based on comparing the information in the 
  MTP-TRANSFER request primitive with a provisioned Routing Key. 
  
! From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE 
  state is selected and a DATA message is constructed and issued on the 
  corresponding SCTP association.  If more than one ASP is in the ASP-
  ACTIVE state (i.e., traffic is to be load-shared across more than one 
  ASP), one of the ASPs in the ASP_ACTIVE state is selected from the ! list.
If the ASPs are in Broadcast Mode, all active ASPs will be ! selected and
the message sent to each of the active ASPs.  The ! selection algorithm is
implementation dependent but could, for ! example, be round-robin or based
on, for example, the SLS or ISUP CIC.
! The appropriate selection algorithm must be chosen carefully as it is !
dependent on application assumptions and understanding of the degree ! of
state coordination between the ASP_ACTIVE ASPs in the AS. 

  Sidebottom et al                                             [Page 64]
  
  Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
***************
*** 4259,4280 ****
  default of 2 seconds.  Alternatively, retransmission of ASP Active 
  messages MAY be put under control of Layer Management.  In this method, 
  expiry of T(ack) results in an M-ASP_ACTIVE confirm primitive carrying 
  a negative indication.  
  
! There are four modes of Application Server traffic handling in the SGP !
M3UA layer - Over-ride, Over-ride (Standby), Load-share and Load-share !
(Standby).  The Traffic Mode Type parameter in the ASP Active message !
indicates the traffic handling mode used in a particular Application !
Server. If the SGP determines that the mode indicated in an ASP Active !
message is unsupported or incompatible with the mode currently ! configured
for the AS, the SGP responds with an Error message ! ("Unsupported / Invalid
Traffic Handling Mode").  If the Traffic ! Handling mode of the Application
Server is not already known via ! configuration data, then the Traffic
Handling mode indicated in the ! first ASP Active message causing the
transition of the Application ! Server state to AS-ACTIVE MAY be used to set
the mode.
  
  In the case of an Over-ride mode AS, reception of an ASP Active message 
  at an SGP causes the (re)direction of all traffic for the AS to the ASP 
  that sent the ASP Active message.  Any previously active ASP in the AS 
  is now considered to be in state ASP-INACTIVE and SHOULD no longer ---
4272,4294 ----
  default of 2 seconds.  Alternatively, retransmission of ASP Active 
  messages MAY be put under control of Layer Management.  In this method, 
  expiry of T(ack) results in an M-ASP_ACTIVE confirm primitive carrying 
  a negative indication.  
  
! There are six modes of Application Server traffic handling in the SGP !
M3UA layer - Over-ride, Over-ride (Standby), Load-share, Load-share !
(Standby), Broadcast, and Broadcast (Standby).  The Traffic Mode Type !
parameter in the ASP Active message indicates the traffic handling ! mode
used in a particular Application Server. If the SGP determines ! that the
mode indicated in an ASP Active message is unsupported or ! incompatible
with the mode currently configured for the AS, the SGP ! responds with an
Error message ("Unsupported / Invalid Traffic ! Handling Mode").  If the
Traffic Handling mode of the Application ! Server is not already known via
configuration data, then the Traffic ! Handling mode indicated in the first
ASP Active message causing the ! transition of the Application Server state
to AS-ACTIVE MAY be used to ! set the mode.
  
  In the case of an Over-ride mode AS, reception of an ASP Active message 
  at an SGP causes the (re)direction of all traffic for the AS to the ASP 
  that sent the ASP Active message.  Any previously active ASP in the AS 
  is now considered to be in state ASP-INACTIVE and SHOULD no longer
***************
*** 4332,4346 ****
  
  If there is no currently active ASP, an ASP Active Ack message 
  ("Loadshare") is returned right away and the traffic is directed to the 
  ASP.
  
- 
  All ASPs within a load-sharing mode AS must be able to process any 
  Data message received for the AS, in order to accommodate any potential 
  fail-over or rebalancing of the offered load.
  
  4.2.3.5 ASP Inactive Procedures
  
  When an ASP wishes to withdraw from receiving traffic within an AS, the 
  ASP sends an ASP Inactive message to the SGP or IPSP.  This action MAY 
  be initiated at the ASP by an M-ASP_INACTIVE request primitive from ---
4346,4387 ----
  
  If there is no currently active ASP, an ASP Active Ack message 
  ("Loadshare") is returned right away and the traffic is directed to the 
  ASP.
  
  All ASPs within a load-sharing mode AS must be able to process any 
  Data message received for the AS, in order to accommodate any potential 
  fail-over or rebalancing of the offered load.
  
+ In the case of a Broadcast mode AS, reception of an ASP Active message +
at an SGP or IPSP cuases the direction of traffic to the ASP sending + the
ASP Active message, in addition to all the other ASPs that are + currently
active in the AS.  The algorithm at the SGP for broadcasting + traffic
within an AS to all the active ASPs is a simple braoadcast + algorithm,
where every message is sent to each of the active ASPs.
+ 
+ An SGP or IPSP, upon reception of an ASP Active message for the first +
ASP in a Broadcast AS, MAY choose not to direct traffic to a newly + active
ASP until it determines that there are sufficient resources to + handle the
expected load (e.g., until there are "n" ASPs in state + ASP-ACTIVE in the
AS).
+ 
+ In the case of Broadcast (Standby) mode AS, the traffic is not started +
to the ASP until the SGP or IPSP determines that there are sufficient +
resuorces available in the AS.  This is likely when one of the active +
broadcast ASPs transitions to either the ASP-INACTIVE or ASP-DOWN + state.
At this point the ASP that sent the ASP Active message + ("Broadcast
(Standby)") is moved to the ASP_ACTIVE state and traffic + is started.  A
second ASP Active Ack message with a new Traffic Mode + Type ("Broadcast" -
previously "Broadcast (Standby)") is sent to the + ASP.  A Notify message
("Insufficient ASP resources active in AS") is + not sent in this case.
+ 
+ If there is no currently active ASP, an ASP Active Ack message +
("Broadcast") is returned right away and the traffic is directed to + the
ASP.
+ 
  4.2.3.5 ASP Inactive Procedures
  
  When an ASP wishes to withdraw from receiving traffic within an AS, the 
  ASP sends an ASP Inactive message to the SGP or IPSP.  This action MAY 
  be initiated at the ASP by an M-ASP_INACTIVE request primitive from
***************
*** 4375,4384 ****
--- 4416,4435 ----
  immediately included in the loadshare group and a Notify message is not 
  sent.  An ASP Inactive Ack message is sent to the ASP after all traffic 
  is halted and Layer Management is informed with an M-ASP_INACTIVE 
  indication primitive.
  
+ In the case of a Broadcast mode AS, the SGP moves the ASP to the +
ASP-INACTIVE state and the AS traffic is broadcast only to the + remaining
ASPs in the state ASP-ACTIVE.  A Notify message + ("Insufficient ASP
resources active in AS") MAY be sent to all + inactive ASPs, if required.
However, if a Broadcast ("Standby") ASP + is available, it may be now
immediately included in the broadcast + group and a Notify message is not
sent.  An ASP Inactive Ack message + is sent to the ASP after all traffic is
halted and Layer Management is + informed with an M-ASP_INACTIVE indication
primitive.
+ 
  Multiple ASP Inactive Ack messages MAY be used in response to an ASP 
  Inactive message containing multiple Routing Contexts, allowing the SGP 
  or IPSP to independently acknowledge for different (sets of) Routing 
  Contexts.  The SGP or IPSP sends an Error message ("Invalid Routing 
  Context") message for each invalid or un-configured Routing Context
***************
*** 4426,4438 ****
  informed with an M-NOTIFY indication primitive.
  
  In the case where a Notify message("AS-Pending") message is sent by an 
  SGP that now has no ASPs active to service the traffic, or where a 
  Notify message("Insufficient ASP resources active in AS") is sent in ! the
Loadshare mode, the Notify message does not explicitly compel the ! ASP(s)
receiving the message to become active. The ASPs remain in ! control of what
(and when) traffic action is taken.
  
  In the case where a Notify message does not contain a Routing Context
  parameter, the receiver must know, via configuration data, of which
  Application Servers the ASP is a member and take the appropriate action
for
  the ASP in each AS.
--- 4477,4489 ----
  informed with an M-NOTIFY indication primitive.
  
  In the case where a Notify message("AS-Pending") message is sent by an 
  SGP that now has no ASPs active to service the traffic, or where a 
  Notify message("Insufficient ASP resources active in AS") is sent in ! the
Loadshare or Broadcast mode, the Notify message does not ! explicitly compel
the ASP(s) receiving the message to become active.
! The ASPs remain in control of what (and when) traffic action is taken.
  
  In the case where a Notify message does not contain a Routing Context
  parameter, the receiver must know, via configuration data, of which
  Application Servers the ASP is a member and take the appropriate action
for
  the ASP in each AS.
***************
*** 4940,4955 ****
  state and ASP2 is to be a "back-up" in the event of communication 
  failure or the withdrawal from service of ASP1.  ASP2 may act as a hot, 
  warm, or cold back-up depending on the extent to which ASP1 and ASP2 
  share call/transaction state or can communicate call state under 
  failure/withdrawal events.  The example message flow is the same ! whether
the ASP Active messages indicate "Over-ride" or "Load-share" ! mode,
although typically this example would use an Over-ride mode. The ! SGP MAY
start sending any relevant DUNA, DRST and SCON messages to ASPs ! as soon as
they enter the ASP-INACTIVE state. In the case of MTP ! Restart, the
ASP-Active Ack message is only sent after all relevant ! DUNA/DRST/SCON
messages have been transmitted to the concerned ASP.

         SGP                        ASP1                        ASP2
          |                         |                          |
          |<--------ASP Up----------|                          | ---
4991,5007 ----
  state and ASP2 is to be a "back-up" in the event of communication 
  failure or the withdrawal from service of ASP1.  ASP2 may act as a hot, 
  warm, or cold back-up depending on the extent to which ASP1 and ASP2 
  share call/transaction state or can communicate call state under 
  failure/withdrawal events.  The example message flow is the same ! whether
the ASP Active messages indicate "Over-ride", "Load-share" ! or "Broadcast"
mode, although typically this example would use an ! Over-ride mode. The SGP
MAY start sending any relevant DUNA, DRST and ! SCON messages to ASPs as
soon as they enter the ASP-INACTIVE state. In ! the case of MTP Restart, the
ASP-Active Ack message is only sent after ! all relevant DUNA/DRST/SCON
messages have been transmitted to the ! concerned ASP.

         SGP                        ASP1                        ASP2
          |                         |                          |
          |<--------ASP Up----------|                          | 

---cut-here--------X-----------

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

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 24 Jul 2001 04:32:25 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: [M3UA, SUA]: Gracefull shutdown 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]>

Harsh,

What is serves to do is to permit the MGC to initiate the action rather than
the SG.

It is no different than calling the control center and asking them to
inhibit SGP-33485903 please.  It is just quicker.

It also allows the SG Owner some autonomy from the MGC Owner in the matter:
permiting the administration of the SG, where supported, to manage their own
equipment without the oversight of the MGC administration, solely because of
IETF architectural choices.

The ASP does not need to honor the request.  It is an "OPTION" in the true
sense of the IETF meaning.

Also, see comment below...

--Brian

[email-masked] wrote:                              (Tue, 24 Jul 2001
11:05:04)
> 
> 
> Hi,
> 
> The following is based on the assumption that an SG/SGP is about to
fail..'be
> pulled out'.
> 
> I'm not convinced about what value the ASP can derive from such a warning
> message(ntfy).
> Considering a case of multiple SGPs(maybe in load-share or override mode),
the
> ASP will have an option of routing traffic
> via other SGPs. So if multiple SGPs are there, the ASP would already have
> established associations to these alternate SGPs.
> Unless we're saying that when this warning message arrives on the ASP, it
is
> supposed to establish association to alternate
> SGP(s), send the required ASPAC messages and be ready to route traffic
through
> it BEFORE the association actually goes down
> to the about-to-fail SGP ! Would this not  defeat the purpose of SG/SGP
> redundancy if it is present?

What is it that would defeat the purpose?

> 
> In most likelihood, wouldn't the ASP have already activated itself(for
available
> AS(s)) in any available alternate SGPs?

Maybe, maybe not.  The ASP could always refuse the procedure.

> 
> The impact, IMHO, will be for messages already sent on the association
with the
> about-to-fail SGP. This can be prevented
> by simply doing a graceful close of the SCTP association initiated from
the
> about-to-fail SGP.

The UAs do not describe the UA to SCTP interface in such detail.
It is quite possible that a UA implementation might suffer from the
inability to confirm the shutdown after it has started.
This is often the case for socket() sytle interfaces.

> 
> Also, NTFY will have to be sent to all connected ASPs, for all
corresponding
> active AS(s) associated with these ASPs.

Yes.

> 
> regards,
> Harsh
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]> on 07/24/2001 03:12:45 AM
> 
> Please respond to [email-masked]
> 
> To:   "sigtran" <[email-masked]>
> cc:   [email-masked] (bcc: Harsh Bhondwe/HSS)
> 
> 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]

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 24 Jul 2001 04:40:27 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: [M3UA, SUA]: Gracefull shutdown 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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Bernard,

Good points!

Bernard Kuc wrote:                                        (Tue, 24 Jul 2001
11:25:28)
> Hi
> 
> Being warned before the association goes down will always improve
> the possibilities that the ASP has to mitigate any problems. I agree
> with Brian that a NTFY would be appropriate. This NTFY could be only
> informational, in that the ASP can ignore it, and await the assoc
> shutdown, or the ASP could decide to go inactive and down before the
> shutdown.
> 
> One question is whether the ASP should assume that it has been taken
> to the INACTIVE state when it receives the NTFY(SGP Blocking Pending),
> or that it should itself now send the INACTIVE message to the SGP.

I would prefer the latter for two reasons:  the SGP can use the ASPIA as a
positive indication from the ASP.  If there is no positive indication, it
may choose to refuse a less critical management requrest for blocking.
Second, I believe that the SGP should NEVER change the ASP state except in
response to the ASPSM messages.  The chances for getting the ASP state out
of sync between the two will start to crop up otherwise.

> 
> One performance enhancement that can be made is that the SGP only sends
> the NTFY(SGP Blocking Pending) to ASPs that it receives messages from. 
> This way if there was no traffic being exchanged between an ASP and a
> SGP at the time that the SGP inhibits the association, then it most
> probably would not harm to take association down without the NTFY.

Now just how does the SGP know which ASPs it receives messages from?  It
doesn't.  It knows which ASPs it does not receive messages from: INACTIVE or
DOWN ASPs.  Following along your lines, the SGP should send the message only
to ASPs in the Active state.

> 
> I'd assume that all point codes that were only available at the ASP 
> through this SGP should be marked as unavailable, if there is no 
> other route to them.

That would result from the ASPs doing ASP Inactive.  If not all of the ASPs
go Inactive a short period after the NTFY, the SGP can assume that it might
disrupt things and inform management, (or blink that light faster, and red).

> 
> Bernard
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 24 July 2001 07:35
> To: sigtran
> Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> 
> 
> 
> 
> Hi,
> 
> The following is based on the assumption that an SG/SGP is about to
> fail..'be
> pulled out'.
> 
> I'm not convinced about what value the ASP can derive from such a
> warning
> message(ntfy).
> Considering a case of multiple SGPs(maybe in load-share or override
> mode), the
> ASP will have an option of routing traffic
> via other SGPs. So if multiple SGPs are there, the ASP would already
> have
> established associations to these alternate SGPs.
> Unless we're saying that when this warning message arrives on the ASP,
> it is
> supposed to establish association to alternate
> SGP(s), send the required ASPAC messages and be ready to route traffic
> through
> it BEFORE the association actually goes down
> to the about-to-fail SGP ! Would this not  defeat the purpose of SG/SGP
> redundancy if it is present?
> 
> In most likelihood, wouldn't the ASP have already activated itself(for
> available
> AS(s)) in any available alternate SGPs?
> 
> The impact, IMHO, will be for messages already sent on the association
> with the
> about-to-fail SGP. This can be prevented
> by simply doing a graceful close of the SCTP association initiated from
> the
> about-to-fail SGP.
> 
> Also, NTFY will have to be sent to all connected ASPs, for all
> corresponding
> active AS(s) associated with these ASPs.
> 
> regards,
> Harsh
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]> on 07/24/2001 03:12:45 AM
> 
> Please respond to [email-masked]
> 
> To:   "sigtran" <[email-masked]>
> cc:   [email-masked] (bcc: Harsh Bhondwe/HSS)
> 
> 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]
From: [email-masked]
X-Lotus-FromDomain: HSS
To: "sigtran" <[email-masked]>
Date: Tue, 24 Jul 2001 15:11:47 +0530
Subject: Re: M2UA-09 comment #8
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 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]
Date: Tue, 24 Jul 2001 04:58:31 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Ken Morneault <[email-masked]>
Subject: Re: M2UA-09 comment #8
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]>

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]
Subject: RE: [M3UA, SUA]: Gracefull shutdown of SGP
Date: Tue, 24 Jul 2001 12:04:29 +0200
Thread-Topic: [M3UA, SUA]: Gracefull shutdown of SGP
Thread-Index: AcEUJL477YKM9FPuT4yKTXVwyGyxggAAoDtg
From: Bernard Kuc <[email-masked]>
To: "sigtran" <[email-masked]>
X-SMTP-HELO: mail.azisa.co.za
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [196.14.124.43]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

Thanks. I also prefer the second method as it is the more stable option in
message loss scenarios. As to knowing which ASP an SGP has received data
from, it may be a by-product of our implementation, but from the association
that the data arrived on, we know the ASP from which it came. However as you
stated, sending the NTFY to all ACTIVE ASPs, is most probably the cleanest
solution.

Best Regards
Bernard

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: 24 July 2001
11:40
To: sigtran
Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP

Bernard,

Good points!

Bernard Kuc wrote:                                        (Tue, 24 Jul 2001
11:25:28)
> Hi
> 
> Being warned before the association goes down will always improve
> the possibilities that the ASP has to mitigate any problems. I agree
> with Brian that a NTFY would be appropriate. This NTFY could be only
> informational, in that the ASP can ignore it, and await the assoc
> shutdown, or the ASP could decide to go inactive and down before the
> shutdown.
> 
> One question is whether the ASP should assume that it has been taken
> to the INACTIVE state when it receives the NTFY(SGP Blocking Pending),
> or that it should itself now send the INACTIVE message to the SGP.

I would prefer the latter for two reasons:  the SGP can use the ASPIA as a
positive indication from the ASP.  If there is no positive indication, it
may choose to refuse a less critical management requrest for blocking.
Second, I believe that the SGP should NEVER change the ASP state except in
response to the ASPSM messages.  The chances for getting the ASP state out
of sync between the two will start to crop up otherwise.

> 
> One performance enhancement that can be made is that the SGP only sends
> the NTFY(SGP Blocking Pending) to ASPs that it receives messages from.

> This way if there was no traffic being exchanged between an ASP and a
> SGP at the time that the SGP inhibits the association, then it most
> probably would not harm to take association down without the NTFY.

Now just how does the SGP know which ASPs it receives messages from?  It
doesn't.  It knows which ASPs it does not receive messages from: INACTIVE or
DOWN ASPs.  Following along your lines, the SGP should send the message only
to ASPs in the Active state.

> 
> I'd assume that all point codes that were only available at the ASP 
> through this SGP should be marked as unavailable, if there is no 
> other route to them.

That would result from the ASPs doing ASP Inactive.  If not all of the ASPs
go Inactive a short period after the NTFY, the SGP can assume that it might
disrupt things and inform management, (or blink that light faster, and red).

> 
> Bernard
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 24 July 2001 07:35
> To: sigtran
> Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> 
> 
> 
> 
> Hi,
> 
> The following is based on the assumption that an SG/SGP is about to
> fail..'be
> pulled out'.
> 
> I'm not convinced about what value the ASP can derive from such a
> warning
> message(ntfy).
> Considering a case of multiple SGPs(maybe in load-share or override
> mode), the
> ASP will have an option of routing traffic
> via other SGPs. So if multiple SGPs are there, the ASP would already
> have
> established associations to these alternate SGPs.
> Unless we're saying that when this warning message arrives on the ASP,
> it is
> supposed to establish association to alternate
> SGP(s), send the required ASPAC messages and be ready to route traffic
> through
> it BEFORE the association actually goes down
> to the about-to-fail SGP ! Would this not  defeat the purpose of SG/SGP
> redundancy if it is present?
> 
> In most likelihood, wouldn't the ASP have already activated itself(for
> available
> AS(s)) in any available alternate SGPs?
> 
> The impact, IMHO, will be for messages already sent on the association
> with the
> about-to-fail SGP. This can be prevented
> by simply doing a graceful close of the SCTP association initiated from
> the
> about-to-fail SGP.
> 
> Also, NTFY will have to be sent to all connected ASPs, for all
> corresponding
> active AS(s) associated with these ASPs.
> 
> regards,
> Harsh
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]> on 07/24/2001 03:12:45 AM
> 
> Please respond to [email-masked]
> 
> To:   "sigtran" <[email-masked]>
> cc:   [email-masked] (bcc: Harsh Bhondwe/HSS)
> 
> 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]
Date: Tue, 24 Jul 2001 05:29:26 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA-07: Broadcast mode changes
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Maria,

It was discussed briefly in two threads (grep for "broadcast" and "Traffic
Modes").

The purpose of broadcast mode is to permit the a pool of ASPs to run fully
synchronized and Hot Standby.

The leader-follower synchronization afforded by override and load-share are
what I would call "Warm" Standby.

It also permits a loosely coupled synchronization for applications where
precise state syncrhonization between ASPs is neither necessary nor
economical.

The purpose of adding it was to support these modes, and because the UAs do
not permit any implementation-defined traffic modes.

Broadcasting could be accomplished between the ASPs instead; however,
broadcasting at the SG handles the situation (it is more efficient) where
ASPs are geographically diverse, particularly where loose synchronization is
permitted by the application.

Most SS7 applications (ISUP, TCAP) are robust against duplication and
ommission errors, permitting loose synchronization.

Consider that one ASP is in Madrid and the other is in Dallas.
It is efficient if the SGP sends messages to both and the ASPs coordinate on
who is actively processing which messages (although both process each, only
one reacts).  Say, one ASP is master for one traffic flow and the other is
slave.  Visa versa for other traffic flows.  When an ASP is informed of the
failure of the other, it starts active processing of slave messages.
This is just one possible arrangement with broadcast mode.

Certainly the SGP performs this simple little broadcast function and a wide
spectrum of redundancy arrangements become possible at the ASP.

Certainly the SCTP assocations permit the SGP to perform a time-bounded
reliable broadcast: the basis for all distributed atomic locking protocols.
Even hard and tight synchronization is possible.  ASPs can use a symmetrical
voting algorithm and better address babbling idiot and psychotic sister
syndromes.

For example the common 3 out of 4 voting performed between fault tolerant
processor quads is possible in a more distributed architecture.

These symmetrical voting algorithms depend upon the fact that there is no
one member of the vote who is responsible for calling for the vote ('cuase
if that guy failed, so would the whole voting process).  Implementing them
is easier when the incoming messages are broadcast over a bus (or network).

Is that enough detail?  (Or, should I draw diagrams...  ;)

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Tue, 24 Jul 2001
11:28:47)
>
> Brian,
> 
> I glanced over the mail below... I have a question,
> what is the need to have this broadcast mode? What is the
> point to process one message in all active ASPs for one AS?
> 
> You may have already talked about that in a previous 
> thread... which one?
> 
> Thanks
> /MCruz
> 

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 24 Jul 2001 05:46:32 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA-07: Broadcast mode changes
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]>

Maria,

I should have also noted:  I can't tell the difference between 1+n
load-shared
and override modes.  I think that override is really a subset of
load-shared.

With that said, there are really only two distinct modes:  load-share and
broadcast.

Think unicast and broadcast.
Think striped and mirrored.

--Brian

Brian F. G. Bidulock wrote:                               (Tue, 24 Jul 2001
05:29:26)
> Maria,
> 
> It was discussed briefly in two threads (grep for "broadcast"
> and "Traffic Modes").
> 
> The purpose of broadcast mode is to permit the a pool of ASPs to
> run fully synchronized and Hot Standby.
> 
> The leader-follower synchronization afforded by override and
> load-share are what I would call "Warm" Standby.
> 
> It also permits a loosely coupled synchronization for
> applications where precise state syncrhonization between ASPs is
> neither necessary nor economical.
> 
> The purpose of adding it was to support these modes, and because
> the UAs do not permit any implementation-defined traffic modes.
> 
> Broadcasting could be accomplished between the ASPs instead;
> however, broadcasting at the SG handles the situation (it is
> more efficient) where ASPs are geographically diverse,
> particularly where loose synchronization is permitted by the
> application.
> 
> Most SS7 applications (ISUP, TCAP) are robust against
> duplication and ommission errors, permitting loose
> synchronization.
> 
> Consider that one ASP is in Madrid and the other is in Dallas.
> It is efficient if the SGP sends messages to both and the ASPs
> coordinate on who is actively processing which messages
> (although both process each, only one reacts).  Say, one ASP is
> master for one traffic flow and the other is slave.  Visa versa
> for other traffic flows.  When an ASP is informed of the failure
> of the other, it starts active processing of slave messages.
> This is just one possible arrangement with broadcast mode.
> 
> Certainly the SGP performs this simple little broadcast function
> and a wide spectrum of redundancy arrangements become possible
> at the ASP.
> 
> Certainly the SCTP assocations permit the SGP to perform
> a time-bounded reliable broadcast: the basis for all distributed
> atomic locking protocols.  Even hard and tight synchronization
> is possible.  ASPs can use a symmetrical voting algorithm and
> better address babbling idiot and psychotic sister syndromes.
> 
> For example the common 3 out of 4 voting performed between
> fault tolerant processor quads is possible in a more distributed
> architecture.
> 
> These symmetrical voting algorithms depend upon the fact
> that there is no one member of the vote who is responsible
> for calling for the vote ('cuase if that guy failed, so would
> the whole voting process).  Implementing them is easier when
> the incoming messages are broadcast over a bus (or network).
> 
> Is that enough detail?  (Or, should I draw diagrams...  ;)
> 
> --Brian
> 
> Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Tue, 24 Jul 2001
11:28:47)
> >
> > Brian,
> > 
> > I glanced over the mail below... I have a question,
> > what is the need to have this broadcast mode? What is the
> > point to process one message in all active ASPs for one AS?
> > 
> > You may have already talked about that in a previous 
> > thread... which one?
> > 
> > Thanks
> > /MCruz
> > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 24 Jul 2001 06:06:17 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: John Loughney <[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: 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]>

Al,

Al Varney wrote:                              (Mon, 23 Jul 2001 15:48:46)
...
>
>     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.
> 

What?! You don't agree with the architectural vision of RFC 2719? ;)

For IPSP to IPSP operation, I agree: it would be far better to just
encapsulate the appropriate layer message.  But for the "exporting the upper
layer interface" architecture of MGC/SG operation it makes sense, in
general, to encapsulate primitives.
Where primitives map one-to-one to messages, the distinction, however, is
moot.

I echo your concerns that the upper level SS7 protocols (SCCP, TCAP) are
still "living" protocols.  Someone will have a job updating UA's in a few
years...  MTP is fairly stable so there should be few problems there.

For the TUA (which I think is still a valid concept) the approach should
definitely be to encapsulate messages rather the extract "primitives".
Perhaps that is one of the reasons why the draft looks so dry an unpalatable
as it stands.

-- 
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: "Benjamin J. Wilson" <[email-masked]>
Organization: Performance Technologies
To: "sigtran" <[email-masked]>
Subject: Re: M3UA-07: Broadcast mode changes
Date: Tue, 24 Jul 2001 09:31:03 -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]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I agree with your statement about override being a subset of loadshare.

With that said, why don't we just introduce a cost parameter?
When sending an ASPAC for a RC, the cost would determine it's state (rather
than traffic mode).  If it's cost were the lowest you achieve override.  If
it's cost were the same as the currently active ASP, you would achieve
loadshare.  This also allows for primary, secondary, etc. standby ASPs.

This wouldn't work for broadcast mode though unless you reserved some cost
value to indicate broadcast.  Is this a workable model?
Does it have any value?

Cheers,

Ben

On Tue, 24 Jul 2001, you wrote:
> Maria,
> 
> I should have also noted:  I can't tell
> the difference between 1+n load-shared
> and override modes.  I think that override
> is really a subset of load-shared.
> 
> With that said, there are really only two
> distinct modes:  load-share and broadcast.
> 
> Think unicast and broadcast.
> Think striped and mirrored.
> 
> --Brian
> 
> Brian F. G. Bidulock wrote:                               (Tue, 24 Jul
2001 05:29:26)
> > Maria,
> > 
> > It was discussed briefly in two threads (grep for "broadcast"
> > and "Traffic Modes").
> > 
> > The purpose of broadcast mode is to permit the a pool of ASPs to
> > run fully synchronized and Hot Standby.
> > 
> > The leader-follower synchronization afforded by override and
> > load-share are what I would call "Warm" Standby.
> > 
> > It also permits a loosely coupled synchronization for
> > applications where precise state syncrhonization between ASPs is
> > neither necessary nor economical.
> > 
> > The purpose of adding it was to support these modes, and because
> > the UAs do not permit any implementation-defined traffic modes.
> > 
> > Broadcasting could be accomplished between the ASPs instead;
> > however, broadcasting at the SG handles the situation (it is
> > more efficient) where ASPs are geographically diverse,
> > particularly where loose synchronization is permitted by the
> > application.
> > 
> > Most SS7 applications (ISUP, TCAP) are robust against
> > duplication and ommission errors, permitting loose
> > synchronization.
> > 
> > Consider that one ASP is in Madrid and the other is in Dallas.
> > It is efficient if the SGP sends messages to both and the ASPs
> > coordinate on who is actively processing which messages
> > (although both process each, only one reacts).  Say, one ASP is
> > master for one traffic flow and the other is slave.  Visa versa
> > for other traffic flows.  When an ASP is informed of the failure
> > of the other, it starts active processing of slave messages.
> > This is just one possible arrangement with broadcast mode.
> > 
> > Certainly the SGP performs this simple little broadcast function
> > and a wide spectrum of redundancy arrangements become possible
> > at the ASP.
> > 
> > Certainly the SCTP assocations permit the SGP to perform
> > a time-bounded reliable broadcast: the basis for all distributed
> > atomic locking protocols.  Even hard and tight synchronization
> > is possible.  ASPs can use a symmetrical voting algorithm and
> > better address babbling idiot and psychotic sister syndromes.
> > 
> > For example the common 3 out of 4 voting performed between
> > fault tolerant processor quads is possible in a more distributed
> > architecture.
> > 
> > These symmetrical voting algorithms depend upon the fact
> > that there is no one member of the vote who is responsible
> > for calling for the vote ('cuase if that guy failed, so would
> > the whole voting process).  Implementing them is easier when
> > the incoming messages are broadcast over a bus (or network).
> > 
> > Is that enough detail?  (Or, should I draw diagrams...  ;)
> > 
> > --Brian
> > 
> > Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Tue, 24 Jul 2001
11:28:47)
> > >
> > > Brian,
> > > 
> > > I glanced over the mail below... I have a question,
> > > what is the need to have this broadcast mode? What is the
> > > point to process one message in all active ASPs for one AS?
> > > 
> > > You may have already talked about that in a previous 
> > > thread... which one?
> > > 
> > > Thanks
> > > /MCruz
> > > 
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
[email-masked]
> 
> -- 
> 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: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UAv7: Client/Server Model (IPSP)
Date: Tue, 24 Jul 2001 15:38:31 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: penguin-ext.wise.edt.ericsson.se [194.237.142.110]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

Some comments about chapter 1.4.8 "Client/Server Model"

[snip]
"In the case of IPSP to IPSP communication, the peer endpoints using M3UA
SHOULD be configured so that one always takes on the role of client and the
other the role of server for initiating SCTP associations."

I presume that one IPSP could be as well configured to act as a client
towards a set of destination (then it should initiate SCTP associations) and
as a server towards a 'different' set of destinations. If you agree, then
this parragraph should be updated to reflect this possibility.

/MCruz

---
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 (V7) DRST question
Date: Tue, 24 Jul 2001 07:46:51 -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]

Hi Jeff,

	Having the SG respond to the "AS" (not per ASP) in response mode
would be better than having SS7 network management at the SGP-ASP level.

	I still think that M3UA can not change the SS7 network management
philosophy.  Other UAs will have to maintain the existing philosophy (M2PA,
M2UA, IUA, etc.), why should M3UA (and SUA) have the ability to change an
overall SS7 network philosophy.  It still must be done from a node's point
of view, NOT its individual network interfaces' point-of-view.

	You stated the SG case where both sides of the node should have the
same management philosophy.  This is true also for existing SS7 end nodes
that will be adding the "IP transport", they should not have to support 2
SS7 network management philosophies.  Their SS7 transport side will not go
away overnight.

John

-----Original Message-----
From: Jeff Copley [mailto:[email-masked]] Sent: Monday, July
23, 2001 4:33 PM
To: sigtran
Subject: Re: M3UA (V7) DRST question

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?

Jeff

"Gradischnig, Klaus" wrote:
> 
> John,
> 
> you are making a very valid point.
> 
> Klaus
> 
> > -----Original Message-----
> > From: Schantz, John [mailto:[email-masked]]
> > Sent: July 20, 2001 5:38 PM
> > To: sigtran
> > Subject: FW: M3UA (V7) DRST question
> >
> >
> >
> >
> > -----Original Message-----
> > From: Schantz, John
> > Sent: Friday, July 20, 2001 9:53 AM
> > To: [email-masked]'
> > Subject: RE: M3UA (V7) DRST question
> >
> >
> > Brian,
> >       I don't think I am reading a lot into "single management view".
> > This is the view that all SS7 nodes have today and if any SG wants to
> > connect into an SS7 network will need to abide by the same management
> > philosophy (it is built into the SS7 protocol).
> >
> >       So you're telling me that a partitioned SG will have a "single
> > management view" towards the SS7 network but it will not
> > maintain this view
> > for its' SGPs.  You are basically forcing the AS to have more
> > complicated
> > management structure because you are not willing to build a
> > node that abides
> > by the general philosophy that all other nodes in the network
> > must abide by.
> > So you are asking the AS to collect management messages from
> > each SGP, as
> > though they are independent nodes, before the AS can then
> > determine the true
> > state of a remote destination.  When are you going to stop
> > pushing all of
> > your dirty work onto the ASs?  Why is a limited node
> > architecture driving
> > the standard?  Who do you think will buy a SG like this
> > (cheap but almost no
> > network management functions)?  A small protocol converter
> > per link would be
> > better than this, at least it blindly convert the management
> > message and not
> > make its presence known.
> >
> >       You can make it OPTIONAL but thank goodness my node will be in
> > networks with real SGs.
> >
> > John
> >
> >  -----Original Message-----
> > From:         Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Thursday, July 19, 2001 4:38 PM
> > To:   sigtran
> > Subject:      Re: M3UA (V7) DRST question
> >
> > John,
> >
> > I think that you are reading alot into the "single management view"
> > statement, as it is not really defined what this means; but, I
> > understand what you are getting at.  Certainly the fact that it is
> > possible that an ASP may receive conflicting information from
> > individual SGP, it does not preclude building a system which assumes
> > this single management view.
> >
> > Perhaps a resolution to the situation, for the sake of
> > interoperability,
> > is to say the the SG SHOULD present such a single view of
> > availability/
> > congestion/restriction status, but that the ASP SHOULD keep
> > track of that
> > status on a per-SGP basis.
> >
> > Then, if an ASP implementation chooses to rely heavily on a single
> > management view from the SG, it must do so with the full understanding
> > that it might not interoperate as well with a partionable SG
> > implementation.  And, if the SGP implementation chooses to not present
> > such a single management view to the ASP, that it might not
> > interoperate
> > as well with ASPs which rely upon it.
> >
> > That way due warning is given, nothing is precluded, and maximum
> > interoperability may result.  Let the implementations solve the
> > details.
> >
> > Plus, this takes the least amount of text changes, right Greg?
> >
> > Comments?
> >
> > --Brian
> >
> > Schantz, John wrote:                           (Thu, 19 Jul
> > 2001 13:41:44)
> > > Brian,
> > >     I will need to read what the changes are but availability and
> > > congestion would show up in the status of the
> > 'links/associations', hence
> > it
> > > is already taken care of.  There is no parallel for
> > restricted for an
> > > interface.
> > >
> > >     If you look at the definition of a SG from the M3UA document:
> > >
> > > Signalling Gateway - An SG is a signaling agent that
> > receives/sends SCN
> > > native signaling at the edge of the IP network [1].  An SG
> > appears to
> > > the SS7 network as an SS7 Signalling Point.  An SG contains
> > a set of one
> > > or more unique Signalling Gateway Processes, of which one
> > or more is
> > > normally actively processing traffic.  Where an SG contains
> > more than
> > > one SGP, the SG is a logical entity and the contained SGPs must be
> > > coordinated into a single management view to the SS7
> > network and to the
> > > supported Application Servers.
> > >
> > >     Notice the highlighted "single management view", this
> > states to me
> > > that the SG has a single management function even if it is
> > composed of
> > > multiple SGPs.  We will be supporting multiple ASPs and we
> > will also have
> > a
> > > single management view of the system and it interfaces.
> > Therefore, if a
> > PC
> > > is prohibited, allowed, congested, or restricted, only
> > single management
> > > message should be sent to its adjacent nodes.  You can not
> > use DUNA, DAVA,
> > > SCON, DRST, etc. to manage a single SGP, they are the
> > "single management
> > > view" of the SG for destinations.
> > >
> > > 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]
> >
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send 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: SUA: SCCP Message Priority
Date: Tue, 24 Jul 2001 07:59:53 -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]

Ray,
	A 5-bit SLS has not been acceptable for 2 issues of the ANSI
standard.  All discussions about SLS (for ANSI) must use the 8-bit SLS.  Al
V. also pointed this out.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent: Monday, July
23, 2001 4:42 PM
To: sigtran
Subject: Re: SUA: SCCP Message Priority

Brian,

Since ANSI allows use of 5-bit and 8-bit SLS values using a part of the
importance field should work.

Ray

"Brian F. G. Bidulock" <[email-masked]> on 07/23/2001 03:10:55 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:   John Loughney
<[email-masked]> (bcc: Ray P. Singh/Telcordia) Subject:  Re: SUA:
SCCP Message Priority

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.
Importance takes up 3 of 8.  How about the top nibble of importance, such
as:

< 3.9.1  Flags
<
<    The Flags parameter is a conglomerate of following parameters, <
described in ITU-T Recommendation Q.713 : <
<       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 = 0x0101          |             Length = 8        | <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <      |
Seq. Control  | MP|Importance |  Hop Counter  |  Protocol Cl. | <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <
<  Message Priority/Importance
<
<  Importance (3.19/Q.713)
<
<  Bits 1-3 are coded to indicate the importance of the messages. The <
values are between 0 and 7, where the value of 0 indicates the least <
important and 7 indicates the most important.
<
<  Bits 4-6 are spare bits and should be coded zero.
<
<  Message Priority (T1.111.4/Table B4) <
<  Bits 7-8 are coded to indicate the message priority of the message in <
networks which support mutliple congestion level with message priority.
<  The values are between 0 and 2, where the value of 0 indicates the <
lowest priority and 2 indicates the most important.

[email-masked] wrote:                          (Mon, 23 Jul 2001
14:01:56)
>
> Hi,
>
> Could someone please clarify whether SUA would allow ANSI message priority
> values to be conveyed between peer SUA/SUA Users.
>
> Thanks
> Ray
>

--
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: "BAND,RICHARD (HP-France,ex1)" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Routing Context
Date: Tue, 24 Jul 2001 17:11:40 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: gremg1.net.external.hp.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: gremg1.net.external.hp.com [192.6.111.73]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

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]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA, SUA]: Gracefull shutdown of SGP
Date: Tue, 24 Jul 2001 08:12:50 -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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ken,

	From another thread you will see that I do not agree that SS7
network management view is valid on the SGP-ASP level.  Therefore a NTFY(SGP
Blocking Pending) can not be interpreted as a DUNA.

I would say that NTFY(SGP Blocking Pending) is an indication the SGP wants
to place an SGP-ASP(s) communication on the association(s) into an inactive
state (basically a management inhibit request in SS7 terms).

John

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]] Sent: Monday, July 23, 2001
5:34 PM
To: sigtran
Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP

Does an ASP take the NTFY(SGP Blocking Pending) as a DUNA for all DPCs
supported by that SGP?  Or, does the ASP have to wait for the SCTP
association to fail?

At 04:42 PM 7/23/01 -0500, you wrote:
>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]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA, SUA]: Gracefull shutdown of SGP
Date: Tue, 24 Jul 2001 08:17:34 -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]

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]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: IPSP-IPSP examples
Date: Tue, 24 Jul 2001 17:20:38 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-MIME-Autoconverted: from 8bit to quoted-printable by 
                      albatross.wise.edt.ericsson.se id f6OFKkN11060
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: albatross-ext.wise.edt.ericsson.se [194.237.142.116]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello Greg and Harsh,

I have slightly rewrite part of chapter 5 "Examples of M3UA Procedures" to
consider IPSP, I think this is what Harsh was requesting. Greg, you could
think about whether to take it as it is in your draft.

Most of ASP procedures could be consider as well IPSP procedures, this is
what I've done plus an small parragraph for 'SCTP assoc. establishment'.
Let's think if some important example are missed.

I made chapters 5.1, 5.2, 5.3 and 5.4.1.1 valid as well for IPSPs.
(I changed 5.4.1.1.3 to 5.4.1.2).

/MCruz

----------------------------------------------------------------------------
- 5. Examples of M3UA Procedures

+ 5.1 SCTP association establishment

+The default client/server model (see 1.4.8) says that the ASP should +take
on the role of a client, then it should initiate the SCTP association +to
the SGP.

+In case of IPSP to IPSP communication it should be configured which +one
takes on the client or server mode for initiating the SCTP association,
+later on, ASPSM and ASPTM could be equally interchanged regardless which
+one established initially the association.

5.1 Establishment of Traffic

These scenarios show the example M3UA message flows for the establishment of
traffic between an SGP and an ASP or between two IPSPs.
In all cases it is assumed that the SCTP association is already set-up.

5.1.1 Single ASP/IPSP in an AS/IPS ("1+0" sparing)

These scenarios show the example M3UA message flows for the establishment of
traffic between an SGP and an ASP or between two IPSPs, where only one
ASP/IPSP
is configured within an AS/IPS (no backup). 
 
5.1.1.1 Single ASP/IPSP in an AS/IPS ("1+0" sparing), No Registration

The sending of any DUNA/SCON messages by the SGP is not shown but is similar
to the case described in Section 5.1.2.

           SGP/IPSP                        ASP1/IPSP1
              |                                |
              |<-------------ASP Up------------|
              |-----------ASP Up Ack---------->|
              |                                | 
              |<------- ASP Active(RCn)--------|  RC: Routing Context 
              |-----ASP Active Ack (RCn)------>|      (optional)
              |                                |

Note: If the ASP Active message contains an optional Routing Context
parameter, The ASP Active message only applies for the specified RC
value(s). For an unknown RC value, the SGP/IPSP responds with an Error
message.

5.1.1.2 Single ASP/IPSP in AS/IPS ("1+0" sparing), Dynamic Registration

This scenario is the same as for 5.1.1.1 but with the optional exchange of
registration information.  In this case the Registration is accepted by the
SGP/IPSP.

           SGP/IPSP                        ASP1/IPSP1
              |                                |
              |<------------ASP Up-------------| 
              |----------ASP Up Ack----------->|
              |                                |
              |<----REGISTER REQ(LRCn,RKn)-----|  LRC: Local Routing

              |                                |       Context            
              |----REGISTER RESP(LRCn,RCn)---->|   RK: Routing Key        
              |                                |   RC: Routing Context    
              |                                | 
              |<------- ASP Active(RCn)--------| 
              |-----ASP Active Ack (RCn)------>|
              |                                |

Note: In the case of an unsuccessful registration attempt (e.g., Invalid
RKn), the Register Response message will contain an unsuccessful indication
and the ASP/IPSP will not subsequently send an ASP Active message.  

5.1.1.3 Single ASP/IPSP in Multiple ASs/IPSs (each with "1+0" sparing),
Dynamic Registration (Case 1 û Multiple Registration Requests)

           SGP/IPSP                        ASP1/IPSP1
              |                                |
              |<------------ASP Up-------------| 
              |----------ASP Up Ack----------->|
              |                                |
              |<----REGISTER REQ(LRC1,RK1)-----|  LRC: Local Routing 
              |                                |       Context 
              |----REGISTER RESP(LRC1,RC1)---->|   RK: Routing Key 
              |                                |   RC: Routing Context 
              |                                | 
              |<------- ASP Active(RC1)--------| 
              |-----ASP Active Ack (RC1)------>|
              |                                |
              |                                |
              |<----REGISTER REQ(LRCn,RKn)-----|
              |                                |
              |----REGISTER RESP(LRCn,RCn)---->|
              |                                |
              |                                | 
              |<------- ASP Active(RCn)--------| 
              |-----ASP Active Ack (RCn)------>|
              |                                |

Note: In the case of an unsuccessful registration attempt (e.g., Invalid
RKn), the Register Response message will contain an unsuccessful indication
and the ASP/IPSP will not subsequently send an ASP Active message. Each
LRC/RK pair registration is considered independently. 

It is not necessary to follow a Registration Request/Response message pair
with an ASP Active message before sending the next Registration Request. The
ASP Active message can be sent at any time after the related successful
registration. 

5.1.1.4 Single ASP/IPSP in Multiple ASs/IPSs (each with "1+0" sparing),
Dynamic Registration (Case 2 û Single Registration Request)

           SGP/IPSP                        ASP1/IPSP1
              |                                |
              |<------------ASP Up-------------| 
              |----------ASP Up Ack----------->|
              |                                |
              |<---REGISTER REQ({LRC1,RK1},----| 
              |                   ...,         |
              |                 {LRCn,RKn}),---|
              |                                |
              |---REGISTER RESP({LRC1,RC1},--->|   
              |                  ...,          |
              |                 (LRCn,RCn})    |   
              |                                | 
              |<------- ASP Active(RC1)--------| 
              |-----ASP Active Ack (RC1)------>|
              |                                |
              :                                :
              :                                :
              |                                | 
              |<------- ASP Active(RCn)--------| 
              |-----ASP Active Ack (RCn)------>|
              |                                |

Note: In the case of an unsuccessful registration attempt (e.g., Invalid
RKn), the Register Response message will contain an unsuccessful indication
and the ASP/IPSP will not subsequently send an ASP Active message. Each
LRC/RK pair registration is considered independently. 

The ASP Active message can be sent at any time after the related successful
registration, and may have more than one RC.

5.1.2 Two ASPs/IPSPs in an AS/IPS ("1+1" sparing)

This scenario shows the example M3UA message flows for the establishment of
traffic between an SGP and two ASPs in the same Application Server, or
between an IPSP and two IPSPs in the same IPS, where ASP1/IPSP1 is
configured to be in the ASP-ACTIVE state and ASP2/IPSP2 is to be a "back-up"
in the event of communication failure or the withdrawal from service of
ASP1/IPSP1.  ASP2/IPSP2 may act as a hot, warm, or cold back-up depending on
the extent to which ASP1/IPSP1 and ASP2/IPSP2 share call/transaction state
or can communicate call state under failure/withdrawal events.  The example
message flow is the same whether the ASP Active messages indicate
"Over-ride" or "Load-share" mode, although typically this example would use
an Over-ride mode. The SGP MAY start sending any relevant DUNA, DRST and
SCON messages to ASPs as soon as they enter the ASP-INACTIVE state. In the
case of MTP Restart, the ASP-Active Ack message is only sent after all
relevant DUNA/DRST/SCON messages have been transmitted to the concerned ASP.

     SGP/IPSP                 ASP1/IPSP1                 ASP2/IPSP2
        |                         |                          |
        |<--------ASP Up----------|                          | 
        |-------ASP Up Ack------->|                          |
        |                         |                          |
        |<-----------------------------ASP Up----------------|
        |-----------------------------ASP Up Ack------------>|
        |                         |                          | 
        |                         |                          |
        |<-------ASP Active-------|                          | 
        |------ASP Active Ack---->|                          | 
        |                         |                          |

Note: It is also possible for ASP2/IPSP2 to send an ASP-Active ("Over-ride-
Standby") message after ASP1/IPSP1 goes ASP-ACTIVE  A similar sparing
arrangement is created, except that the SGP/IPSP may re-direct traffic to
ASP2/IPSP2 more quickly in certain fail-over cases.

5.1.3 Two ASPs in an AS/IPS ("1+1" sparing, load-sharing case)

This scenario shows a similar case to Section 5.1.2 but where the two
ASPs/IPSPs are brought to the state ASP-ACTIVE and subsequently load-share
the traffic.  In this case, one ASP/IPSP is sufficient to handle the total
traffic load. The sending of DUNA, DRST and SCON messages by the SGP is not
shown but is similar to the case described in Section 5.1.2.

     SGP/IPSP                 ASP1/IPSP1                 ASP2/IPSP2
        |                         |                          |
        |<---------ASP Up---------|                          | 
        |--------ASP Up Ack------>|                          |
        |                         |                          |
        |<------------------------------ASP Up---------------|
        |-----------------------------ASP Up Ack------------>|
        |                         |                          | 
        |                         |                          |
        |<--ASP Active (Ldshr)----|                          | 
        |-----ASP-Active Ack----->|                          | 
        |                         |                          |
        |<----------------------------ASP Active (Ldshr)-----| 
        |-------------------------------ASP Active Ack------>| 
        |                         |                          |

5.1.4 Three ASPs in an AS/IPS ("n+k" sparing, load-sharing case) 

This scenario shows the example M3UA message flows for the establishment of
traffic between an SGP and three ASPs in the same Application Server, or
between an IPSP and three IPSPs in the same IPS, where two of the ASPs/IPSPs
are brought to the state ASP- ACTIVE and subsequently share the load. In
this case, a minimum of two ASPs/IPSPs are required to handle the total
traffic load (2+1 sparing). The sending of DUNA, DRST and SCON messages by
the SGP is not shown but is similar to the case described in Section 5.1.2.

 SGP/IPSP            ASP1/IPSP1          ASP2/IPSP2          ASP3/IPSP3 
    |                    |                   |                   |
    |<------ASP Up-------|                   |                   | 
    |-----ASP Up Ack---->|                   |                   |
    |                    |                   |                   |
    |<--------------------------ASP Up-------|                   |
    |-------------------------ASP Up Ack---->|                   |
    |                    |                   |                   |
    |<---------------------------------------------ASP Up--------|
    |---------------------------------------------ASP Up Ack---->|
    |                    |                   |                   | 
    |                    |                   |                   |
    |<--ASP Act (Ldshr)--|                   |                   | 
    |----ASP Act Ack---->|                   |                   | 
    |                    |                   |                   |
    |<--------------------ASP Act. (Ldshr)---|                   | 
    |-----------------------ASP Act Ack----->|                   | 
    |                    |                   |                   |

Note: It is also possible for ASP3/IPSP3 to send an ASP Active message
("Loadshare-Standby") after ASP1/IPSP1 and ASP2/IPSP2 go to the ASP-ACTIVE
state.
A similar sparing arrangement is created, except that the SGP/IPSP may
redirect traffic to ASP3/IPSP3 more quickly in certain fail-over cases.

5.2 ASP/IPSP Traffic Fail-over Examples

5.2.1 (1+1 Sparing, Withdrawal of ASP/IPSP, Back-up Over-ride) 

Following on from the example in Section 5.1.2, the ASP1/IPSP1 withdraws
from service:

     SGP/IPSP                 ASP1/IPSP1                 ASP2/IPSP2 
        |                         |                          |
        |<-----ASP Inactive-------|                          |
        |----ASP Inactive Ack---->|                          |
        |------------------------NTFY(AS-Pending)----------->| 
        |                         |                          | 
        |<------------------------------ ASP Active----------| 
        |------------------------------ASP Active Ack------->| 
        |                                                    |

Note: If the SGP/IPSP M3UA layer detects the loss of the M3UA peer (M3UA
heartbeat loss or detection of SCTP failure), the initial ASP Inactive
message exchange (i.e., SGP/IPSP to ASP1/IPSP1) would not occur.
[MCruz] Greg, shouldn't it be: i.e., ASP1/IPSP1 to SGP/IPSP ??

5.2.2 (1+1 Sparing, Back-up Over-ride)

Following on from the example in Section 5.1.2, and ASP2/IPSP2 wishes to
over-ride ASP1/IPSP1 and take over the traffic:

     SGP/IPSP                 ASP1/IPSP1                 ASP2/IPSP2 
        |                         |                          | 
        |<------------------------------ ASP Active----------| 
        |-------------------------------ASP Active Ack------>|
        |----NTFY(Alt ASP-Act)--->| 
        |                         |                          | 

5.2.3 (n+k Sparing, Load-sharing case, Withdrawal of ASP/IPSP)

Following on from the example in Section 5.1.4, and ASP1/IPSP1 withdraws
from service:

  SG/IPS1						AS/IPS2
 --------
--------------------------------------------------  SGP/IPSP
ASP1/IPSP1          ASP2/IPSP2          ASP3/IPSP3 
    |                    |                   |                   |
    |<----ASP Inact.-----|                   |                   | 
    |---ASP Inact Ack--->|                   |                   |
    |                    |                   |                   | 
    |---------------------------------NTFY(Ins. ASPs)----------->| 
    |                    |                   |                   |
    |<-----------------------------------------ASP Act (Ldshr)---| 
    |-------------------------------------------ASP Act (Ack)--->|
    |                    |                   |                   |

For the Notify message to be sent, the SG/IPS1 maintains knowledge of the
minimum ASP/IPSP resources required (e.g., if the SG/IPS1 knows that "n+k" =
"2+1" for a load-share AS/IPS and "n" currently equals "1"). 

Note: If the SGP/IPSP detects loss of the ASP1/IPSP1 M3UA peer (M3UA
heartbeat loss or detection of SCTP failure), the initial ASP Inactive
message exchange (i.e., SGP/IPSP-ASP1/IPSP1) would not occur.  

5.3 Normal Withdrawal of an ASP/IPSP from an AS/IPS and Teardown of an
Association

An ASP/IPSP which is now confirmed in the state INACTIVE (i.e., the ASP/IPSP
has received an ASP Inactive Ack message) may now proceed to the DOWN state,
if it is to be removed from service.  Following on from Section 5.2.1 or
5.2.3, where ASP1/IPSP1 has moved to the "Inactive" state:

     SGP/IPSP                       ASP1/IPSP1 
        |                               |
        |<-----ASP Inactive (RCn)-------|    RC: Routing Context
        |----ASP Inactive Ack (RCn)---->|
        |                               |
        |<-----DEREGISTER REQ(RCn)------|    See Notes 
        |                               |        
        |---DEREGISTER RESP(LRCn,RCn)-->|
        |                               |   
        :                               :   
        |                               | 
        |<-----------ASP Down-----------| 
        |---------ASP Down Ack--------->|
        |                               |

Note: The Deregistration procedure MUST be used if the ASP/IPSP previously
used the Registration procedures for configuration within the AS/IPS.  ASP
Inactive and Deregister messages exchanges may contain multiple Routing
Contexts.

The ASP/IPSP SHOULD be INACTIVE and de-registered in all its Routing
Contexts before attempting to move to the DOWN state.  

5.4  M3UA/MTP3-User Boundary Examples

5.4.1 At an ASP/IPSP

This section describes the primitive mapping between the MTP3 User and the
M3UA layer at an ASP or IPSP.  

5.4.1.1 Support for MTP-TRANSFER Primitives

5.4.1.1.1 Support for MTP-TRANSFER Request Primitive

When the MTP3-User on the ASP/IPSP has data to send to a remote MTP3-User,
it uses the MTP-TRANSFER request primitive.  The M3UA layer at the ASP/IPSP
will do the following when it receives an MTP-TRANSFER request primitive
from the M3UA user:

  - Determine the correct SGP/IPSP;

  - Determine the correct association to the chosen SGP/IPSP;

  - Determine the correct stream in the association (e.g., based on  
    SLS);

  - Determine whether to complete the optional fields of the DATA  
    message;

  - Map the MTP-TRANSFER request primitive into the Protocol Data  
    field of a DATA message;

  - Send the DATA message to the remote M3UA peer at the SGP/IPSP, over the

    SCTP association.

     SGP/IPSP                  ASP/IPSP   
        |                         |                  
        |<-----DATA Message-------|<--MTP-TRANSFER req. 
        |                         | 

5.4.1.1.2 Support for the MTP-TRANSFER Indication Primitive

When the M3UA layer on the ASP/IPSP receives a DATA message from the remote
M3UA peer at the SGP/IPSP, it will do the following:

  - Evaluate the optional fields of the DATA message, if present;

  - Map the Protocol Data field of a DATA message into the MTP-TRANSFER
indication primitive;

  - Pass the MTP-TRANSFER indication primitive to the user part. In  
    case of multiple user parts, the optional fields of the Data
    message are used to determine the concerned user part.

     SGP/IPSP                  ASP/IPSP   
        |                         |
        |------Data Message------>|-->MTP-Transfer ind.
        |                         |          

5.4.1.2 Support for ASP Querying of SS7 Destination States

There are situations such as temporary loss of connectivity to the SGP that
may cause the M3UA layer at the ASP to audit SS7 destination
availability/congestion states.  Note: there is no primitive for the
MTP3-User to request this audit from the M3UA layer as this is initiated by
an internal M3UA management function.  

       SGP                        ASP   
        |                         |
        |<----------DAUD----------| 
        |<----------DAUD----------| 
        |<----------DAUD----------| 
        |                         | 
        |                         | 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent: Wednesday,
July 18, 2001 6:13 AM
To: sigtran
Subject: M3UA: IPSP-IPSP examples

Hello Greg,

It would be good if the draft could have  some examples for the IPSP-IPSP
scenario in section "5. Examples of M3UA Procedures".
I think it would help clarify things.

thanks and regards,
Harsh

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send 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: [M3UA, SUA]: Gracefull shutdown of SGP
Date: Tue, 24 Jul 2001 08:40:48 -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,

	I've seen you make the statement below several time: "Now just how
does the SGP know which ASPs it receives messages from?  It doesn't." 

	Is this an implementation limitation?  In our implementation, we
know which association a message came from, therefore we know the SGP (or
ASP if we are a SG) that sent it.  Why are we not assuming that the SGP (SG)
has more intelligence that what you are stating?

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Tuesday, July
24, 2001 4:40 AM
To: sigtran
Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP

Bernard,

Good points!

Bernard Kuc wrote:                                        (Tue, 24 Jul 2001
11:25:28)
> Hi
> 
> Being warned before the association goes down will always improve
> the possibilities that the ASP has to mitigate any problems. I agree
> with Brian that a NTFY would be appropriate. This NTFY could be only
> informational, in that the ASP can ignore it, and await the assoc
> shutdown, or the ASP could decide to go inactive and down before the
> shutdown.
> 
> One question is whether the ASP should assume that it has been taken
> to the INACTIVE state when it receives the NTFY(SGP Blocking Pending),
> or that it should itself now send the INACTIVE message to the SGP.

I would prefer the latter for two reasons:  the SGP can use the ASPIA as a
positive indication from the ASP.  If there is no positive indication, it
may choose to refuse a less critical management requrest for blocking.
Second, I believe that the SGP should NEVER change the ASP state except in
response to the ASPSM messages.  The chances for getting the ASP state out
of sync between the two will start to crop up otherwise.

> 
> One performance enhancement that can be made is that the SGP only sends
> the NTFY(SGP Blocking Pending) to ASPs that it receives messages from. 
> This way if there was no traffic being exchanged between an ASP and a
> SGP at the time that the SGP inhibits the association, then it most
> probably would not harm to take association down without the NTFY.

Now just how does the SGP know which ASPs it receives messages from?  It
doesn't.  It knows which ASPs it does not receive messages from: INACTIVE or
DOWN ASPs.  Following along your lines, the SGP should send the message only
to ASPs in the Active state.

> 
> I'd assume that all point codes that were only available at the ASP 
> through this SGP should be marked as unavailable, if there is no 
> other route to them.

That would result from the ASPs doing ASP Inactive.  If not all of the ASPs
go Inactive a short period after the NTFY, the SGP can assume that it might
disrupt things and inform management, (or blink that light faster, and red).

> 
> Bernard
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 24 July 2001 07:35
> To: sigtran
> Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> 
> 
> 
> 
> Hi,
> 
> The following is based on the assumption that an SG/SGP is about to
> fail..'be
> pulled out'.
> 
> I'm not convinced about what value the ASP can derive from such a
> warning
> message(ntfy).
> Considering a case of multiple SGPs(maybe in load-share or override
> mode), the
> ASP will have an option of routing traffic
> via other SGPs. So if multiple SGPs are there, the ASP would already
> have
> established associations to these alternate SGPs.
> Unless we're saying that when this warning message arrives on the ASP,
> it is
> supposed to establish association to alternate
> SGP(s), send the required ASPAC messages and be ready to route traffic
> through
> it BEFORE the association actually goes down
> to the about-to-fail SGP ! Would this not  defeat the purpose of SG/SGP
> redundancy if it is present?
> 
> In most likelihood, wouldn't the ASP have already activated itself(for
> available
> AS(s)) in any available alternate SGPs?
> 
> The impact, IMHO, will be for messages already sent on the association
> with the
> about-to-fail SGP. This can be prevented
> by simply doing a graceful close of the SCTP association initiated from
> the
> about-to-fail SGP.
> 
> Also, NTFY will have to be sent to all connected ASPs, for all
> corresponding
> active AS(s) associated with these ASPs.
> 
> regards,
> Harsh
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]> on 07/24/2001 03:12:45 AM
> 
> Please respond to [email-masked]
> 
> To:   "sigtran" <[email-masked]>
> cc:   [email-masked] (bcc: Harsh Bhondwe/HSS)
> 
> 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]
Date: Tue, 24 Jul 2001 10:43:31 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA (V7) DRST question
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,

The SG needs some way of indicating to the ASP to not route specific traffic
on specific SGP, aside from the on/off switch of dropping the association.

What prompted this whole discussion was statement of the need for SGP
mamagement.  M3UA-06 to -07 changes added all these statements contrary to
your position.

What will the SGP use to stop affected traffic flows otherwise?  (Shutting
itself off altogether is unacceptable.)

          PC A  ----------- SGP1 ------------ ASP
                              |            /
               internal ----->X           /
               failure        |          /
                              |         /
          PC B  ----------- SGP2 ------/

How does SGP2, for example, indicate that it can no longer route traffic to
remote point code `A' because of internal failure in the SG, whereas SGP1
can route easily to point code `A'.  Shutting off is not appropriate because
SGP2 would also have to do the same w.r.t. PC `B'.

Not only from an internal failure perspective, the SG must be permitted to
manage the load of ASPs over its SGP.  And requiring the SG to route any
necessary traffic over its backplane does not cut it.

So if one comes up with reverse Routing Contexts and pvoides a mechanism
which permits the SGP to identify traffic which they are or are not able to
handle, how would it be so different from DUNA/DAVA/DRST/SCON?

--Brian

P.S. There are a lot of places in the M3UA-07 draft that disagrees with your
position:

Most importantly, Section 4.3.2.2:

	4.3.2.2 Multiple SGP Configurations

	At an ASP, upon receiving a Signalling Network Management message
from 
	the remote M3UA Peer, the M3UA layer updates the status of the
affected 
	route(s) via the originating SGP and determines, whether or not the 
	overall availability or congestion status of the effected 
	destination(s) has changed. If so, the M3UA layer invokes the 
	appropriate primitive indications to the resident M3UA-Users.  Local

	management is informed.  

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

Section 1.3.2

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

And in Section 1.3.2.5:

	1.3.2.5 Support for the Management of Connections to Multiple SGPs

	As shown in Figure 1 an ASP may be connected to multiple SGPs. In
such 
	a case a particular SS7 destination may be reachable via more than
one 
	SGP, i.e., via more than one route. As MTP3 users only maintain
status 
	on a destination and not on a route basis, the M3UA layer must
maintain 
	the status (availability, restriction, and/or congestion of route to

	destination) of the individual routes, derive the overall
availability 
	or congestion status of the destination from the status of the 
	individual routes, and inform the MTP3 users of this derived status 
	whenever it changes.

(From which it would seem that the "single management view" is the ASPs
responsibility.)

Now in 1.4.1 we have:

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

But in 1.4.2.5:

	In order to direct messages to the SS7 network, the ASP must also 
	perform a message distribution function in order to choose the
proper 
	SGP for a given message.  This is accomplished by observing the 
	Destination Point Code (and possibly other elements of the outgoing
	message such as the SLS value).Where more than one route (or SGP) is

	possible for routing to the SS7 network, the ASP SHOULD maintain a 
	dynamic table of available SGP routes for the SS7 destinations,
taking 
	into account the SS7 destination availability/restricted/congestion 
	status received from the SGP(s), the availability status of the 
	individual SGPs and configuration changes and fail-over mechanisms. 
	There is, however, no M3UA messaging to manage the status of an SGP 
	(e.g., SGP-Up/Down/Active/Inactive messaging).  Whenever an SCTP 
	association to an SGP exists, the SGP is assumed to be ready for the

	purposes of responding to M3UA ASPSM messages.  

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

In 1.4.3.3:

	In the case where an ASP is connected to more than one SGP, the M3UA

	layer must maintain the status of configured SS7 destinations and
route 
	messages according to availability/congestion/restricted status of
the 
	routes to these SS7 destinations.

In Section 3.4.2 we have the SGP's broadcasting DAVA:

	The DAVA message is sent from the SGP to all concerned ASPs to
indicate 
	that the SG has determined that one or more SS7 destinations are now

	reachable (and not restricted), or in response to a DAUD message if 
	appropriate. The ASP MTP3-User protocol is informed and may now
resume 
	traffic to the affected destination.  The ASP M3UA layer routes the 
	MTP3_user traffic through the SGP(s) initiating the DAVA message. 

The DAUD is on the basis of per-SGP:

	3.4.3 Destination State Audit (DAUD)

	The DAUD message MAY be sent from the ASP to the SGP to audit the 
	availability/congestion state of SS7 routes to one or more affected 
	destinations.  

Schantz, John wrote:                          (Tue, 24 Jul 2001 07:46:51)
> Hi Jeff,
> 
> 	Having the SG respond to the "AS" (not per ASP) in response mode
> would be better than having SS7 network management at the SGP-ASP level.
> 
> 	I still think that M3UA can not change the SS7 network management
> philosophy.  Other UAs will have to maintain the existing philosophy
(M2PA,
> M2UA, IUA, etc.), why should M3UA (and SUA) have the ability to change an
> overall SS7 network philosophy.  It still must be done from a node's point
> of view, NOT its individual network interfaces' point-of-view.
> 
> 	You stated the SG case where both sides of the node should have the
> same management philosophy.  This is true also for existing SS7 end nodes
> that will be adding the "IP transport", they should not have to support 2
> SS7 network management philosophies.  Their SS7 transport side will not go
> away overnight.
> 
> John
> 
> -----Original Message-----
> From: Jeff Copley [mailto:[email-masked]]
> Sent: Monday, July 23, 2001 4:33 PM
> To: sigtran
> Subject: Re: M3UA (V7) DRST question
> 
> 
> 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?
> 
> Jeff
> 
> "Gradischnig, Klaus" wrote:
> > 
> > John,
> > 
> > you are making a very valid point.
> > 
> > Klaus
> > 
> > > -----Original Message-----
> > > From: Schantz, John [mailto:[email-masked]]
> > > Sent: July 20, 2001 5:38 PM
> > > To: sigtran
> > > Subject: FW: M3UA (V7) DRST question
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Schantz, John
> > > Sent: Friday, July 20, 2001 9:53 AM
> > > To: [email-masked]'
> > > Subject: RE: M3UA (V7) DRST question
> > >
> > >
> > > Brian,
> > >       I don't think I am reading a lot into "single management view".
> > > This is the view that all SS7 nodes have today and if any SG wants to
> > > connect into an SS7 network will need to abide by the same management
> > > philosophy (it is built into the SS7 protocol).
> > >
> > >       So you're telling me that a partitioned SG will have a "single
> > > management view" towards the SS7 network but it will not
> > > maintain this view
> > > for its' SGPs.  You are basically forcing the AS to have more
> > > complicated
> > > management structure because you are not willing to build a
> > > node that abides
> > > by the general philosophy that all other nodes in the network
> > > must abide by.
> > > So you are asking the AS to collect management messages from
> > > each SGP, as
> > > though they are independent nodes, before the AS can then
> > > determine the true
> > > state of a remote destination.  When are you going to stop
> > > pushing all of
> > > your dirty work onto the ASs?  Why is a limited node
> > > architecture driving
> > > the standard?  Who do you think will buy a SG like this
> > > (cheap but almost no
> > > network management functions)?  A small protocol converter
> > > per link would be
> > > better than this, at least it blindly convert the management
> > > message and not
> > > make its presence known.
> > >
> > >       You can make it OPTIONAL but thank goodness my node will be in
> > > networks with real SGs.
> > >
> > > John
> > >
> > >  -----Original Message-----
> > > From:         Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Thursday, July 19, 2001 4:38 PM
> > > To:   sigtran
> > > Subject:      Re: M3UA (V7) DRST question
> > >
> > > John,
> > >
> > > I think that you are reading alot into the "single management view"
> > > statement, as it is not really defined what this means; but, I
> > > understand what you are getting at.  Certainly the fact that it is
> > > possible that an ASP may receive conflicting information from
> > > individual SGP, it does not preclude building a system which assumes
> > > this single management view.
> > >
> > > Perhaps a resolution to the situation, for the sake of
> > > interoperability,
> > > is to say the the SG SHOULD present such a single view of
> > > availability/
> > > congestion/restriction status, but that the ASP SHOULD keep
> > > track of that
> > > status on a per-SGP basis.
> > >
> > > Then, if an ASP implementation chooses to rely heavily on a single
> > > management view from the SG, it must do so with the full understanding
> > > that it might not interoperate as well with a partionable SG
> > > implementation.  And, if the SGP implementation chooses to not present
> > > such a single management view to the ASP, that it might not
> > > interoperate
> > > as well with ASPs which rely upon it.
> > >
> > > That way due warning is given, nothing is precluded, and maximum
> > > interoperability may result.  Let the implementations solve the
> > > details.
> > >
> > > Plus, this takes the least amount of text changes, right Greg?
> > >
> > > Comments?
> > >
> > > --Brian
> > >
> > > Schantz, John wrote:                           (Thu, 19 Jul
> > > 2001 13:41:44)
> > > > Brian,
> > > >     I will need to read what the changes are but availability and
> > > > congestion would show up in the status of the
> > > 'links/associations', hence
> > > it
> > > > is already taken care of.  There is no parallel for
> > > restricted for an
> > > > interface.
> > > >
> > > >     If you look at the definition of a SG from the M3UA document:
> > > >
> > > > Signalling Gateway - An SG is a signaling agent that
> > > receives/sends SCN
> > > > native signaling at the edge of the IP network [1].  An SG
> > > appears to
> > > > the SS7 network as an SS7 Signalling Point.  An SG contains
> > > a set of one
> > > > or more unique Signalling Gateway Processes, of which one
> > > or more is
> > > > normally actively processing traffic.  Where an SG contains
> > > more than
> > > > one SGP, the SG is a logical entity and the contained SGPs must be
> > > > coordinated into a single management view to the SS7
> > > network and to the
> > > > supported Application Servers.
> > > >
> > > >     Notice the highlighted "single management view", this
> > > states to me
> > > > that the SG has a single management function even if it is
> > > composed of
> > > > multiple SGPs.  We will be supporting multiple ASPs and we
> > > will also have
> > > a
> > > > single management view of the system and it interfaces.
> > > Therefore, if a
> > > PC
> > > > is prohibited, allowed, congested, or restricted, only
> > > single management
> > > > message should be sent to its adjacent nodes.  You can not
> > > use DUNA, DAVA,
> > > > SCON, DRST, etc. to manage a single SGP, they are the
> > > "single management
> > > > view" of the SG for destinations.
> > > >
> > > > 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]
> > >
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send 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: Tue, 24 Jul 2001 10:46:12 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: [M3UA, SUA]: Gracefull shutdown 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: [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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]
Date: Tue, 24 Jul 2001 10:50:03 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: [M3UA, SUA]: Gracefull shutdown 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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

What I am referring to is that the SGP does not know which traffic flows in
terms of OPC-DPC-SLS is is going to receive from an ASP.  The ASP has been
allowed in the draft to send any XFER message to any SGP.

Therefore, the SGP (as stated below) does not know which ASPs will be
sending it traffic and cannot limit sending NTFY to "only those".

--Brian

Schantz, John wrote:                                     (Tue, 24 Jul 2001
08:40:48)
> Brian,
> 
> 	I've seen you make the statement below several time: "Now just how
> does the SGP know which ASPs it receives messages from?  It doesn't." 
> 
> 	Is this an implementation limitation?  In our implementation, we
> know which association a message came from, therefore we know the SGP (or
> ASP if we are a SG) that sent it.  Why are we not assuming that the SGP
(SG)
> has more intelligence that what you are stating?
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 4:40 AM
> To: sigtran
> Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> 
> 
> Bernard,
> 
> Good points!
> 
> Bernard Kuc wrote:                                        (Tue, 24 Jul
2001
> 11:25:28)
> > Hi
> > 
> > Being warned before the association goes down will always improve
> > the possibilities that the ASP has to mitigate any problems. I agree
> > with Brian that a NTFY would be appropriate. This NTFY could be only
> > informational, in that the ASP can ignore it, and await the assoc
> > shutdown, or the ASP could decide to go inactive and down before the
> > shutdown.
> > 
> > One question is whether the ASP should assume that it has been taken
> > to the INACTIVE state when it receives the NTFY(SGP Blocking Pending),
> > or that it should itself now send the INACTIVE message to the SGP.
> 
> I would prefer the latter for two reasons:  the SGP can use
> the ASPIA as a positive indication from the ASP.  If there
> is no positive indication, it may choose to refuse a less
> critical management requrest for blocking.  Second, I believe
> that the SGP should NEVER change the ASP state except in
> response to the ASPSM messages.  The chances for getting the
> ASP state out of sync between the two will start to crop up
> otherwise.
> 
> > 
> > One performance enhancement that can be made is that the SGP only sends
> > the NTFY(SGP Blocking Pending) to ASPs that it receives messages from. 
> > This way if there was no traffic being exchanged between an ASP and a
> > SGP at the time that the SGP inhibits the association, then it most
> > probably would not harm to take association down without the NTFY.
> 
> Now just how does the SGP know which ASPs it receives messages
> from?  It doesn't.  It knows which ASPs it does not receive
> messages from: INACTIVE or DOWN ASPs.  Following along your lines,
> the SGP should send the message only to ASPs in the Active state.
> 
> > 
> > I'd assume that all point codes that were only available at the ASP 
> > through this SGP should be marked as unavailable, if there is no 
> > other route to them.
> 
> That would result from the ASPs doing ASP Inactive.  If not all
> of the ASPs go Inactive a short period after the NTFY, the SGP
> can assume that it might disrupt things and inform management,
> (or blink that light faster, and red).
> 
> > 
> > Bernard
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: 24 July 2001 07:35
> > To: sigtran
> > Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> > 
> > 
> > 
> > 
> > Hi,
> > 
> > The following is based on the assumption that an SG/SGP is about to
> > fail..'be
> > pulled out'.
> > 
> > I'm not convinced about what value the ASP can derive from such a
> > warning
> > message(ntfy).
> > Considering a case of multiple SGPs(maybe in load-share or override
> > mode), the
> > ASP will have an option of routing traffic
> > via other SGPs. So if multiple SGPs are there, the ASP would already
> > have
> > established associations to these alternate SGPs.
> > Unless we're saying that when this warning message arrives on the ASP,
> > it is
> > supposed to establish association to alternate
> > SGP(s), send the required ASPAC messages and be ready to route traffic
> > through
> > it BEFORE the association actually goes down
> > to the about-to-fail SGP ! Would this not  defeat the purpose of SG/SGP
> > redundancy if it is present?
> > 
> > In most likelihood, wouldn't the ASP have already activated itself(for
> > available
> > AS(s)) in any available alternate SGPs?
> > 
> > The impact, IMHO, will be for messages already sent on the association
> > with the
> > about-to-fail SGP. This can be prevented
> > by simply doing a graceful close of the SCTP association initiated from
> > the
> > about-to-fail SGP.
> > 
> > Also, NTFY will have to be sent to all connected ASPs, for all
> > corresponding
> > active AS(s) associated with these ASPs.
> > 
> > regards,
> > Harsh
> > 
> > 
> > 
> > 
> > "Brian F. G. Bidulock" <[email-masked]> on 07/24/2001 03:12:45 AM
> > 
> > Please respond to [email-masked]
> > 
> > To:   "sigtran" <[email-masked]>
> > cc:   [email-masked] (bcc: Harsh Bhondwe/HSS)
> > 
> > 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]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv7: Client/Server Model (IPSP)
Date: Tue, 24 Jul 2001 08:58:46 -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]

Maria,

	We have already assumed this to be the case.  Do you really think
there needs to be a change.  The "one" in the statement only means that for
a specific local IPSP to remote IPSPi situation, one of them must be
configured as client and the other as server.  For a different local IPSP to
remote IPSPj situation, the configuration of client and server can be
different.

John

-----Original Message-----
From: Maria-Cruz Bartolome-Rodrigo (ECE)
[mailto:[email-masked]] Sent: Tuesday, July
24, 2001 8:39 AM
To: sigtran
Subject: M3UAv7: Client/Server Model (IPSP)

Hi all,

Some comments about chapter 1.4.8 "Client/Server Model"

[snip]
"In the case of IPSP to IPSP communication, the peer endpoints using M3UA
SHOULD be configured so that one always takes on the role of client and the
other the role of server for initiating SCTP associations."

I presume that one IPSP could be as well configured to act as a client
towards
a set of destination (then it should initiate SCTP associations) and as a
server towards a 'different' set of destinations. If you agree, then this
parragraph should be updated to reflect this possibility.

/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]
Date: Tue, 24 Jul 2001 11:10:25 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv7: Client/Server Model (IPSP)
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,

What's to stop both from taking the role of both client and server for the
same connections?
That is, whay cannot both sides initiate?

--Brian

Schantz, John wrote:                                     (Tue, 24 Jul 2001
08:58:46)
> Maria,
> 
> 	We have already assumed this to be the case.  Do you really think
> there needs to be a change.  The "one" in the statement only means that
for
> a specific local IPSP to remote IPSPi situation, one of them must be
> configured as client and the other as server.  For a different local IPSP
to
> remote IPSPj situation, the configuration of client and server can be
> different.
> 
> John
> 
> -----Original Message-----
> From: Maria-Cruz Bartolome-Rodrigo (ECE)
> [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 8:39 AM
> To: sigtran
> Subject: M3UAv7: Client/Server Model (IPSP)
> 
> 
> 
> Hi all,
> 
> Some comments about chapter 1.4.8 "Client/Server Model"
> 
> [snip]
> "In the case of IPSP to IPSP communication, the peer endpoints using 
> M3UA SHOULD be configured so that one always takes on the role of 
> client and the other the role of server for initiating SCTP 
> associations."
> 
> I presume that one IPSP could be as well configured to act as a client
> towards
> a set of destination (then it should initiate SCTP associations) and
> as a server towards a 'different' set of destinations. If you agree, then
> this parragraph should be updated to reflect this possibility.
> 
> /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]

-- 
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]: Gracefull shutdown of SGP
Date: Tue, 24 Jul 2001 09:27:41 -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]

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]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA, SUA]: Gracefull shutdown of SGP
Date: Tue, 24 Jul 2001 09:32:07 -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: [161.114.32.105]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

	WHY should an SGP care what OPC-SLS combination is in the message it
receives.  It is supposed to be a network-level router.  It should only care
about the information it needs to route the message towards its destination,
the DPC.  Are you trying to limit or destroy our loadsharing capabilities?

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Tuesday, July
24, 2001 10:50 AM
To: sigtran
Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP

John,

What I am referring to is that the SGP does not know which traffic flows in
terms of OPC-DPC-SLS is is going to receive from an ASP.  The ASP has been
allowed in the draft to send any XFER message to any SGP.

Therefore, the SGP (as stated below) does not know which ASPs will be
sending it traffic and cannot limit sending NTFY to "only those".

--Brian

Schantz, John wrote:                                     (Tue, 24 Jul 2001
08:40:48)
> Brian,
> 
> 	I've seen you make the statement below several time: "Now just how
> does the SGP know which ASPs it receives messages from?  It doesn't." 
> 
> 	Is this an implementation limitation?  In our implementation, we
> know which association a message came from, therefore we know the SGP (or
> ASP if we are a SG) that sent it.  Why are we not assuming that the SGP
(SG)
> has more intelligence that what you are stating?
> 
> John
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 4:40 AM
> To: sigtran
> Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> 
> 
> Bernard,
> 
> Good points!
> 
> Bernard Kuc wrote:                                        (Tue, 24 Jul
2001
> 11:25:28)
> > Hi
> > 
> > Being warned before the association goes down will always improve
> > the possibilities that the ASP has to mitigate any problems. I agree
> > with Brian that a NTFY would be appropriate. This NTFY could be only
> > informational, in that the ASP can ignore it, and await the assoc
> > shutdown, or the ASP could decide to go inactive and down before the
> > shutdown.
> > 
> > One question is whether the ASP should assume that it has been taken
> > to the INACTIVE state when it receives the NTFY(SGP Blocking Pending),
> > or that it should itself now send the INACTIVE message to the SGP.
> 
> I would prefer the latter for two reasons:  the SGP can use
> the ASPIA as a positive indication from the ASP.  If there
> is no positive indication, it may choose to refuse a less
> critical management requrest for blocking.  Second, I believe
> that the SGP should NEVER change the ASP state except in
> response to the ASPSM messages.  The chances for getting the
> ASP state out of sync between the two will start to crop up
> otherwise.
> 
> > 
> > One performance enhancement that can be made is that the SGP only sends
> > the NTFY(SGP Blocking Pending) to ASPs that it receives messages from. 
> > This way if there was no traffic being exchanged between an ASP and a
> > SGP at the time that the SGP inhibits the association, then it most
> > probably would not harm to take association down without the NTFY.
> 
> Now just how does the SGP know which ASPs it receives messages
> from?  It doesn't.  It knows which ASPs it does not receive
> messages from: INACTIVE or DOWN ASPs.  Following along your lines,
> the SGP should send the message only to ASPs in the Active state.
> 
> > 
> > I'd assume that all point codes that were only available at the ASP 
> > through this SGP should be marked as unavailable, if there is no 
> > other route to them.
> 
> That would result from the ASPs doing ASP Inactive.  If not all
> of the ASPs go Inactive a short period after the NTFY, the SGP
> can assume that it might disrupt things and inform management,
> (or blink that light faster, and red).
> 
> > 
> > Bernard
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: 24 July 2001 07:35
> > To: sigtran
> > Subject: Re: [M3UA, SUA]: Gracefull shutdown of SGP
> > 
> > 
> > 
> > 
> > Hi,
> > 
> > The following is based on the assumption that an SG/SGP is about to
> > fail..'be
> > pulled out'.
> > 
> > I'm not convinced about what value the ASP can derive from such a
> > warning
> > message(ntfy).
> > Considering a case of multiple SGPs(maybe in load-share or override
> > mode), the
> > ASP will have an option of routing traffic
> > via other SGPs. So if multiple SGPs are there, the ASP would already
> > have
> > established associations to these alternate SGPs.
> > Unless we're saying that when this warning message arrives on the ASP,
> > it is
> > supposed to establish association to alternate
> > SGP(s), send the required ASPAC messages and be ready to route traffic
> > through
> > it BEFORE the association actually goes down
> > to the about-to-fail SGP ! Would this not  defeat the purpose of SG/SGP
> > redundancy if it is present?
> > 
> > In most likelihood, wouldn't the ASP have already activated itself(for
> > available
> > AS(s)) in any available alternate SGPs?
> > 
> > The impact, IMHO, will be for messages already sent on the association
> > with the
> > about-to-fail SGP. This can be prevented
> > by simply doing a graceful close of the SCTP association initiated from
> > the
> > about-to-fail SGP.
> > 
> > Also, NTFY will have to be sent to all connected ASPs, for all
> > corresponding
> > active AS(s) associated with these ASPs.
> > 
> > regards,
> > Harsh
> > 
> > 
> > 
> > 
> > "Brian F. G. Bidulock" <[email-masked]> on 07/24/2001 03:12:45 AM
> > 
> > Please respond to [email-masked]
> > 
> > To:   "sigtran" <[email-masked]>
> > cc:   [email-masked] (bcc: Harsh Bhondwe/HSS)
> > 
> > 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]
From: "Maria-Cruz Bartolome-Rodrigo (ECE)" 
      <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv7: Client/Server Model (IPSP)
Date: Tue, 24 Jul 2001 18:36:52 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: penguin-ext.wise.edt.ericsson.se [194.237.142.110]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

If both IPSPs take on the client and server side, then there could be an
SCTP initialitation 'colision'. Taking into account this is solved by SCTP,
then your proposal could be fine. 

Anyway, do you think that would help? Each side would have to know the
transport addresses of the other, when only for the client one would be
needed...

/MCruz

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Tuesday, July
24, 2001 6:10 PM
To: sigtran
Subject: Re: M3UAv7: Client/Server Model (IPSP)

John,

What's to stop both from taking the role of both client and server for the
same connections?
That is, whay cannot both sides initiate?

--Brian

Schantz, John wrote:                                     (Tue, 24 Jul 2001
08:58:46)
> Maria,
> 
> 	We have already assumed this to be the case.  Do you really think
> there needs to be a change.  The "one" in the statement only means that
for
> a specific local IPSP to remote IPSPi situation, one of them must be
> configured as client and the other as server.  For a different local IPSP
to
> remote IPSPj situation, the configuration of client and server can be
> different.
> 
> John
> 
> -----Original Message-----
> From: Maria-Cruz Bartolome-Rodrigo (ECE)
> [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 8:39 AM
> To: sigtran
> Subject: M3UAv7: Client/Server Model (IPSP)
> 
> 
> 
> Hi all,
> 
> Some comments about chapter 1.4.8 "Client/Server Model"
> 
> [snip]
> "In the case of IPSP to IPSP communication, the peer endpoints using 
> M3UA SHOULD be configured so that one always takes on the role of 
> client and the other the role of server for initiating SCTP 
> associations."
> 
> I presume that one IPSP could be as well configured to act as a client
> towards
> a set of destination (then it should initiate SCTP associations) and
> as a server towards a 'different' set of destinations. If you agree, then
> this parragraph should be updated to reflect this possibility.
> 
> /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]

-- 
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]>
Date: Tue, 24 Jul 2001 09:37:24 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: London agenda
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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

So far, there has been only one comment on the London agenda, that the M3UA
MIB editor will not be able to make it so we'll have to have any discussion
on the M3UA MIB via the list.

Any problems with the agenda as revised below?  If not I'll send this in.

Also, anyone feel a need for scheduling any offline informal editing/working
discussions?

Thanks,

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

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]
To: "sigtran" <[email-masked]>
Date: Tue, 24 Jul 2001 09:40:12 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: Re: M3UAv7: Client/Server Model (IPSP)
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]>
List-Unsubscribe: <mailto:[email-masked]>

I believe the idea was to avoid setting up two parallel associations, e.g.,
if both sides initiate associations and use dynamic port assignment for the
source port.  You could have two legitimate associations set up for the same
stream.

Cheers,

Lyndon
 
--

On Tue, 24 Jul 2001 11:10:25   Brian F. G. Bidulock wrote:
>John,
>
>What's to stop both from taking the role of
>both client and server for the same connections?
>That is, whay cannot both sides initiate?
>
>--Brian
>
>Schantz, John wrote:                                     (Tue, 24 Jul 2001
08:58:46)
>> Maria,
>> 
>> 	We have already assumed this to be the case.  Do you really think
>> there needs to be a change.  The "one" in the statement only means that
for
>> a specific local IPSP to remote IPSPi situation, one of them must be
>> configured as client and the other as server.  For a different local IPSP
to
>> remote IPSPj situation, the configuration of client and server can be
>> different.
>> 
>> John
>> 
>> -----Original Message-----
>> From: Maria-Cruz Bartolome-Rodrigo (ECE)
>> [mailto:[email-masked]]
>> Sent: Tuesday, July 24, 2001 8:39 AM
>> To: sigtran
>> Subject: M3UAv7: Client/Server Model (IPSP)
>> 
>> 
>> 
>> Hi all,
>> 
>> Some comments about chapter 1.4.8 "Client/Server Model"
>> 
>> [snip]
>> "In the case of IPSP to IPSP communication, the peer endpoints using 
>> M3UA SHOULD be configured so that one always takes on the role of 
>> client and the other the role of server for initiating SCTP 
>> associations."
>> 
>> I presume that one IPSP could be as well configured to act as a client
>> towards
>> a set of destination (then it should initiate SCTP associations) and
>> as a server towards a 'different' set of destinations. If you agree, then
>> this parragraph should be updated to reflect this possibility.
>> 
>> /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]
>
>-- 
>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]

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: Tue, 24 Jul 2001 11:41:27 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: [M3UA, SUA]: Gracefull shutdown 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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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]
Date: Tue, 24 Jul 2001 11:45:15 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv7: Client/Server Model (IPSP)
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]>

Maria,

I have been told that ASP Id should not be mandatory because there are so
many implementations out there that will just statically configure all port
numbers.
If I have been told correctly, then there is no reason why any client/server
restriction need apply.

With an optional ASP Id, the ASP is capable of identifying itself to the
SGP, so it is possible that static configuration is not needed.  The
SGP/IPSP could connect to the well- known UA port number of the peer.  The
ASP/ISPS could do the same.  The ASP may need to identify itself on the ASP
Up with ASP Id, but that is no problem.

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Tue, 24 Jul 2001
18:36:52)
> 
> Brian,
> 
> If both IPSPs take on the client and server side, then
> there could be an SCTP initialitation 'colision'. Taking
> into account this is solved by SCTP, then your proposal
> could be fine. 
> 
> Anyway, do you think that would help? Each side would have
> to know the transport addresses of the other, when only
> for the client one would be needed...
> 
> /MCruz
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 6:10 PM
> To: sigtran
> Subject: Re: M3UAv7: Client/Server Model (IPSP)
> 
> 
> John,
> 
> What's to stop both from taking the role of
> both client and server for the same connections?
> That is, whay cannot both sides initiate?
> 
> --Brian
> 
> Schantz, John wrote:                                     (Tue, 24 Jul 2001
08:58:46)
> > Maria,
> > 
> > 	We have already assumed this to be the case.  Do you really think
> > there needs to be a change.  The "one" in the statement only means that
for
> > a specific local IPSP to remote IPSPi situation, one of them must be
> > configured as client and the other as server.  For a different local
IPSP to
> > remote IPSPj situation, the configuration of client and server can be
> > different.
> > 
> > John
> > 
> > -----Original Message-----
> > From: Maria-Cruz Bartolome-Rodrigo (ECE)
> > [mailto:[email-masked]]
> > Sent: Tuesday, July 24, 2001 8:39 AM
> > To: sigtran
> > Subject: M3UAv7: Client/Server Model (IPSP)
> > 
> > 
> > 
> > Hi all,
> > 
> > Some comments about chapter 1.4.8 "Client/Server Model"
> > 
> > [snip]
> > "In the case of IPSP to IPSP communication, the peer endpoints using 
> > M3UA SHOULD be configured so that one always takes on the role of 
> > client and the other the role of server for initiating SCTP 
> > associations."
> > 
> > I presume that one IPSP could be as well configured to act as a client
> > towards
> > a set of destination (then it should initiate SCTP associations) and
> > as a server towards a 'different' set of destinations. If you agree,
then
> > this parragraph should be updated to reflect this possibility.
> > 
> > /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]
> 
> -- 
> 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: Tue, 24 Jul 2001 11:50:35 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv7: Client/Server Model (IPSP)
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]>

Lyndon,

If the assertion (ASP == Host) is not true, (that is, there are multiple
ASPs on a Host) then setting up two associations is correct.

If there is one ASP per host, there is no need to dynamically allocate port
numbers: just use the UA well-known port number on both sides.  SCTP will
then guarantee that only one association results.

I still don't see a need for the SHOULD.

--brian

Lyndon Ong wrote:                                          (Tue, 24 Jul 2001
09:40:12)

> I believe the idea was to avoid setting up two parallel
> associations, e.g., if both sides initiate associations and
> use dynamic port assignment for the source port.  You could
> have two legitimate associations set up for the same stream.
> 
> Cheers,
> 
> Lyndon
>  
> --
> 
> On Tue, 24 Jul 2001 11:10:25   Brian F. G. Bidulock wrote:
> >John,
> >
> >What's to stop both from taking the role of
> >both client and server for the same connections?
> >That is, whay cannot both sides initiate?
> >
> >--Brian
> >
> >Schantz, John wrote:                                     (Tue, 24 Jul
2001 08:58:46)
> >> Maria,
> >> 
> >> 	We have already assumed this to be the case.  Do you really think
> >> there needs to be a change.  The "one" in the statement only means that
for
> >> a specific local IPSP to remote IPSPi situation, one of them must be
> >> configured as client and the other as server.  For a different local
IPSP to
> >> remote IPSPj situation, the configuration of client and server can be
> >> different.
> >> 
> >> John
> >> 
> >> -----Original Message-----
> >> From: Maria-Cruz Bartolome-Rodrigo (ECE)
> >> [mailto:[email-masked]]
> >> Sent: Tuesday, July 24, 2001 8:39 AM
> >> To: sigtran
> >> Subject: M3UAv7: Client/Server Model (IPSP)
> >> 
> >> 
> >> 
> >> Hi all,
> >> 
> >> Some comments about chapter 1.4.8 "Client/Server Model"
> >> 
> >> [snip]
> >> "In the case of IPSP to IPSP communication, the peer endpoints using 
> >> M3UA SHOULD be configured so that one always takes on the role of 
> >> client and the other the role of server for initiating SCTP 
> >> associations."
> >> 
> >> I presume that one IPSP could be as well configured to act as a client
> >> towards
> >> a set of destination (then it should initiate SCTP associations) and
> >> as a server towards a 'different' set of destinations. If you agree,
then
> >> this parragraph should be updated to reflect this possibility.
> >> 
> >> /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]
> >
> >-- 
> >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]
> >
> 
> 
> 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]

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

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

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]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA, SUA]: Gracefull shutdown of SGP
Date: Tue, 24 Jul 2001 11:19:58 -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]

Brian,

	No it is not.  Sending DUNAs, DAVAs, etc. from each SGP to each ASP
is not like how it is done in SS7.  A linkset is defined as ALL the links
(in our case associations) between two signaling points (in our case an SG
and an AS); and it doesn't matter how many SGPs or ASPs are involved.  An
SS7 point code normally has more than one linkset BUT they are to different
nodes as defined by an SS7 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.

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.

-----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]
To: "sigtran" <[email-masked]>
Date: Tue, 24 Jul 2001 13:43:24 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: m3ua status
X-Sender-Ip: 63.96.78.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]>
List-Unsubscribe: <mailto:[email-masked]>

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]
Date: Tue, 24 Jul 2001 14:01:33 -0700 (PDT)
From: Javier Kim <[email-masked]>
X-Sender: javier@fradax
To: "sigtran" <[email-masked]>
cc: [email-masked]
Subject: Re: m3ua status
X-SMTP-HELO: mail1.adax.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: dnai-207-181-233-242.cust.dnai.com [207.181.233.242]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

It is very true that there are many comments for M3UAv7 that require a
proper resolution, but it is more important for us to move toward the IETF
last call stage. We need the final RFC approved by the end of 2001.  
Besides, until the last call, many of us usually do not pay closer attention
to what are debated here.

Javier Kim

On Tue, 24 Jul 2001, 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]

---
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: m3ua status
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Date: Tue, 24 Jul 2001 17:08:50 -0400
X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 
             5.0.8 |June 18, 2001) at 07/24/2001 02:11:58 PM, Serialize 
             complete at 07/24/2001 02:11:58 PM
X-SMTP-HELO: radisys.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [206.102.10.35]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

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]
From: "Schantz, John" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: m3ua status
Date: Tue, 24 Jul 2001 14:09:38 -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: [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]

If the M3UA draft were updated to re-adopt the standard SS7 network
management philosophy, then I would support a last call.

John

PS.  I want the tag values to be nailed down also.

-----Original Message-----
From: Javier Kim [mailto:[email-masked]] Sent: Tuesday, July 24, 2001 4:02
PM
To: sigtran
Cc: [email-masked]
Subject: Re: m3ua status

Hi,

It is very true that there are many comments for M3UAv7 that require a
proper resolution, but it is more important for us to move toward the IETF
last call stage. We need the final RFC approved by the end of 2001.  
Besides, until the last call, many of us usually do not pay closer attention
to what are debated here.

Javier Kim

On Tue, 24 Jul 2001, 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]

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
To: "sigtran" <[email-masked]>
Date: Tue, 24 Jul 2001 14:56:03 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Expiredinmiddle: true
X-Mailer: MailCity Service
Subject: m3ua status, revised
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

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]
Date: Tue, 24 Jul 2001 22:55:30 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: [M3UA, SUA]: SGP Management (was: [M3UA, SUA]: Gracefull shutdown
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: [209.44.42.202]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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

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

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

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

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.

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

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.

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

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

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

> 
> -----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]
Date: Tue, 24 Jul 2001 22:58:43 -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]>

Maria-Cruz,

I don't think that we should remove SGs.  There is still the situation where
multiple SGs can act in the capacity of an STP pair, but still be connected
to the same group of ASPs with M3UA.  This is the principle configuration
which caused the necessity of providing DRST in the first place and is still
a valid situation.  The per-SGP procedures are just as applicable across SGs
as they are within SGs.

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Tue, 24 Jul 2001
19:11:47)
> 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]

-- 
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: "Tomar, Nitin" <[email-masked]>
To: "'Lyndon Ong'" <[email-masked]>,
        "'Ken Morneault'"
	 <[email-masked]>,
        "'Greg Sidebottom'" <[email-masked]>
Subject: M2UA: Interface ID Mgmt
Date: Tue, 24 Jul 2001 10:00:39 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)

Hi Ken, Lyndon, Greg,

 Based on the mailing list discussion on Dynamic registration of Routing Key
in M3UA, I think the following changes is required in  M2UA draft as well.

regards
Nitin

Section 1.6.4 Definition of Layer Management / M2UA Boundary, shall also
include following: 

If dynamic registration of Link Key(s) is supported by the M2UA layer, the
layer MAY support the following additional primitives M-Link Key_REG
Request
Direction : LM -> M2UA
Purpose: LM requests ASP to register Link Key with SG by sending REG REQ
message.

M-Link Key_REG  Confirm
Direction :  M2UA -> LM
Purpose: ASP reports to LM that it has successfully received a REG RSP
message from SG.

M-Link Key_REG  Indication
Direction : M2UA -> LM
Purpose: SG reports to LM that it has successfully processed an incoming REG
REQ message from ASP.

M-Link Key_DEREG  Request
Direction : LM -> M2UA
Purpose: LM requests ASP to de-register Link Key with SG by sending DEREG
REQ message.

M-Link Key_DEREG  Confirm
Direction : M2UA -> LM
Purpose: ASP reports to LM that it has successfully received a DEREG RSP
message from SG.

M-Link Key_DEREG  Indication
Direction : M2UA -> LM
Purpose: SG reports to LM that it has successfully processed an incoming
DEREG REQ message from ASP.

Section 4.4.1  contains:

" A unique method of Interface Identifier valid assignment at the SG/SGP is
implementation dependent but must be guaranteed to be unique across all SGPs
in an SG"
The above text require a change similar to the proposed change in M3UA
[refer thread : M3UA07: Routing Context assignment ] " A unique method of
Interface Identifier valid assignment at the SG/SGP is implementation
dependent but must be guaranteed to be unique for each Application server or
Link Key served by SGP"

Section 4.4.1 and 4.4.2

Add the timers related to the IIM messages, the text can be same as M3UA
[refer thread: M3UA06: Routing Key management procedure]

From: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: m3ua status, revised
Date: Wed, 25 Jul 2001 09:54:07 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi 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]
Date: Wed, 25 Jul 2001 10:32:38 +0500
From: "Srivats P." <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Re: M3UAv7: SG redundancy
Organization: Mercury Corporation, India
X-mailer: FoxMail 2.1 [en]
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

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]
Date: Wed, 25 Jul 2001 00:51:16 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Dynamic Registration in M3UA
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]>

Srivats,

Srivats P. wrote:                                         (Wed, 25 Jul 2001
11:03:48)
> Brian,
> 
> See one comment below ...
> 
> Srivats
> 
> At 7/21/01 3:07:00 AM, you wrote:
> >Satish,
> >
> >I think I get what you're driving at, but I don't think that
> >the M3UA makes any restrictions here.  It is pretty much up
> >to the SGP/ASP to agree.  That said, here's how I think that
> >it `could' work:
> >
> >If, as you say, the Routing Key is not already configured in
> >the SGP, and if the AS is not provisioned in the SGP, then
> >what will the SGP do when it gets a registration request for
> >this "new" Routing Key?
> >
> >Well, if the Routing Key is supported by the SGP (i.e, the
> >SGP is capable of providing traffic and routing on that key)
> >and the key doesn't cause a problem for the SGP by overlappping
> >with other keys; then, it is possible for the SGP to store
> >the key and assign a Routing Context to the key to return
> >in the REG RSP.
> >
> >If, as you say, the AS has not been provisioned, there exists
> >no AS object at this time.  The SGP is not really forced to
> >create one yet.
> >
> >Now, say the ASP performs an ASPAC for the Routing Context
> >which corresponds to our new Routing Key.  The SGP can create
> >an AS object at this time.  The only information that the SGP
> >really needs to create the AS object is the Traffic Mode.
> 
> What about the 'n' from the n+k model of the AS if it is loadshared ?
> The SGP also needs to know this value for a loadshared AS.

I don't think that it really needs to know `n'.  It could easily default to
1.  Actually, as there is only one ASP registering, is doesn't really need
to know traffic mode either, because Override(1+0), Load-share(1+0) and
Broadcast(1+0) are all the same mode.

The only difference in behavior at the SG if n != 1 would be whether there
were "sufficient ASP resources" or not.

It think that the `n' value should be communicated in the ASPAC message
along with the Traffic Mode anyway.

> 
> >
> >The SGP implementation *could* either simply accept the the
> >Traffic Mode type presented in the ASPAC, if it is capable
> >of supporting that mode, or, the SGP/ASP could have agreed
> >`a priori' (that is, they were configured to agree on what
> >traffic modes and precise distribution algorithms to use for
> >"new" routing keys of this sort).
> >
> >So, I don't believe that there is anything stopping an SGP
> >from dynamically creating an AS based on the Routing Key
> >information and local configuration information.  I don't
> >think that the SGP needs to be statically configured for all
> >the AS that it will support, regardless of the registration
> >procedure.
> >
> >
> >There is another way to look at this too.  There is nothing
> >stopping the SGP from statically provisioning *all* Routing
> >Keys and associating Routing Context and AS information with
> >them at provisioning time.  What the registration procedure
> >affords in this scenario is being relieved from having to
> >match Routing Contexts provisioning in the ASP with that
> >of the SGP.
> >
> >M3UA really doesn't restrict things here.  Kudos to whoever
> >proposed it!
> >
> >--Brian
> >
> >
> >Satish K wrote:                                            (Sat, 21 Jul
2001 10:56:53)
> >> Brain,
> >>    I just wated to confirm one thing ie, we talk about dynamic
Registration
> >> ie Registering new ASPs with New routing key with the AS does it mean
we can
> >> only register the ASPs dynamically and AS are registered Stactically?
> >>    What happens when new ASP in New AS tries to register with the SGP?
by
> >> new AS i mean this Routing Key is not yet registered in SGP.
> >> Thanks
> >> Satish
> >> 
> >> 
> >> 
> >> ---
> >> 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 11:3:48 +0500
From: "Srivats P." <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Re: Re: Dynamic Registration in M3UA
Organization: Mercury Corporation, India
X-mailer: FoxMail 2.1 [en]
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Brian,

See one comment below ...

Srivats

At 7/21/01 3:07:00 AM, you wrote:
>Satish,
>
>I think I get what you're driving at, but I don't think that
>the M3UA makes any restrictions here.  It is pretty much up
>to the SGP/ASP to agree.  That said, here's how I think that
>it `could' work:
>
>If, as you say, the Routing Key is not already configured in
>the SGP, and if the AS is not provisioned in the SGP, then
>what will the SGP do when it gets a registration request for
>this "new" Routing Key?
>
>Well, if the Routing Key is supported by the SGP (i.e, the
>SGP is capable of providing traffic and routing on that key)
>and the key doesn't cause a problem for the SGP by overlappping
>with other keys; then, it is possible for the SGP to store
>the key and assign a Routing Context to the key to return
>in the REG RSP.
>
>If, as you say, the AS has not been provisioned, there exists
>no AS object at this time.  The SGP is not really forced to
>create one yet.
>
>Now, say the ASP performs an ASPAC for the Routing Context
>which corresponds to our new Routing Key.  The SGP can create
>an AS object at this time.  The only information that the SGP
>really needs to create the AS object is the Traffic Mode.

What about the 'n' from the n+k model of the AS if it is loadshared ?
The SGP also needs to know this value for a loadshared AS.

>
>The SGP implementation *could* either simply accept the the
>Traffic Mode type presented in the ASPAC, if it is capable
>of supporting that mode, or, the SGP/ASP could have agreed
>`a priori' (that is, they were configured to agree on what
>traffic modes and precise distribution algorithms to use for
>"new" routing keys of this sort).
>
>So, I don't believe that there is anything stopping an SGP
>from dynamically creating an AS based on the Routing Key
>information and local configuration information.  I don't
>think that the SGP needs to be statically configured for all
>the AS that it will support, regardless of the registration
>procedure.
>
>
>There is another way to look at this too.  There is nothing
>stopping the SGP from statically provisioning *all* Routing
>Keys and associating Routing Context and AS information with
>them at provisioning time.  What the registration procedure
>affords in this scenario is being relieved from having to
>match Routing Contexts provisioning in the ASP with that
>of the SGP.
>
>M3UA really doesn't restrict things here.  Kudos to whoever
>proposed it!
>
>--Brian
>
>
>Satish K wrote:                                            (Sat, 21 Jul
2001 10:56:53)
>> Brain,
>>    I just wated to confirm one thing ie, we talk about dynamic
Registration
>> ie Registering new ASPs with New routing key with the AS does it mean we
can
>> only register the ASPs dynamically and AS are registered Stactically?
>>    What happens when new ASP in New AS tries to register with the SGP? by
>> new AS i mean this Routing Key is not yet registered in SGP.
>> Thanks
>> Satish
>> 
>> 
>> 
>> ---
>> 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]
Subject: RE: M3UAv7: SG redundancy
Date: Wed, 25 Jul 2001 08:08:07 +0200
Thread-Topic: M3UAv7: SG redundancy
Thread-Index: AcEUxpEvVAYndZU1SmaOSuxhxNvCjAABVmDg
From: Hong Liu <[email-masked]>
To: "sigtran" <[email-masked]>
X-OriginalArrivalTime: 25 Jul 2001 06:08:09.0329 (UTC) 
                       FILETIME=[2D909E10:01C114D0]
X-SMTP-HELO: mailslide.airslide.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [212.150.80.243]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

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

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: 2001Äê7ÔÂ24ÈÕ
23:59
To: sigtran
Subject: Re: M3UAv7: SG redundancy

Maria-Cruz,

I don't think that we should remove SGs.  There is still the situation where
multiple SGs can act in the capacity of an STP pair, but still be connected
to the same group of ASPs with M3UA.  This is the principle configuration
which caused the necessity of providing DRST in the first place and is still
a valid situation.  The per-SGP procedures are just as applicable across SGs
as they are within SGs.

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Tue, 24 Jul 2001
19:11:47)
> 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]

-- 
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 01:27: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: 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]>

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.

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:

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.

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

--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 01:29:03 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Dynamic Registration in M3UA
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]>

Srivats,

I was proposing (well proposed before already on another thread) that the
value `n' be added as an optional parameter to the ASPAC.

--Brian

Srivats P. wrote:                                         (Wed, 25 Jul 2001
11:42:28)
> Brian,
> 
> See below ...
> 
> Srivats
> 
> At 7/25/01 12:51:00 AM, you wrote:
> >Srivats,
> 
> [snip]
> 
> >> >Now, say the ASP performs an ASPAC for the Routing Context
> >> >which corresponds to our new Routing Key.  The SGP can create
> >> >an AS object at this time.  The only information that the SGP
> >> >really needs to create the AS object is the Traffic Mode.
> >> 
> >> What about the 'n' from the n+k model of the AS if it is loadshared ?
> >> The SGP also needs to know this value for a loadshared AS.
> >
> >I don't think that it really needs to know `n'.  It could easily
> >default to 1.  Actually, as there is only one ASP registering,
> >is doesn't really need to know traffic mode either, because
> >Override(1+0), Load-share(1+0) and Broadcast(1+0) are all the
> >same mode.
> But other ASPs are probably on their way towards registration.
> 
> >The only difference in behavior at the SG if n != 1 would be
> >whether there were "sufficient ASP resources" or not.
> I agree .. the "n" value is only needed to send the NTFY (Insufficient
> ASP Resources active in AS)
> 
> >It think that the `n' value should be communicated in the ASPAC
> >message along with the Traffic Mode anyway.
> Sorry didn't get that. Are you saying the SG will get the "n" value
> in the ASPAC ? How ? Or are you proposing we add a parameter
> to the ASPAC to pass "n" to the SG ?
> 
> [snip]
> 
> 
> 
> ---
> 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 11:42:28 +0500
From: "Srivats P." <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Re: Re: Dynamic Registration in M3UA
Organization: Mercury Corporation, India
X-mailer: FoxMail 2.1 [en]
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Brian,

See below ...

Srivats

At 7/25/01 12:51:00 AM, you wrote:
>Srivats,

[snip]

>> >Now, say the ASP performs an ASPAC for the Routing Context
>> >which corresponds to our new Routing Key.  The SGP can create
>> >an AS object at this time.  The only information that the SGP
>> >really needs to create the AS object is the Traffic Mode.
>> 
>> What about the 'n' from the n+k model of the AS if it is loadshared ?
>> The SGP also needs to know this value for a loadshared AS.
>
>I don't think that it really needs to know `n'.  It could easily
>default to 1.  Actually, as there is only one ASP registering,
>is doesn't really need to know traffic mode either, because
>Override(1+0), Load-share(1+0) and Broadcast(1+0) are all the
>same mode.
But other ASPs are probably on their way towards registration.

>The only difference in behavior at the SG if n != 1 would be
>whether there were "sufficient ASP resources" or not.
I agree .. the "n" value is only needed to send the NTFY (Insufficient ASP
Resources active in AS)

>It think that the `n' value should be communicated in the ASPAC
>message along with the Traffic Mode anyway.
Sorry didn't get that. Are you saying the SG will get the "n" value in the
ASPAC ? How ? Or are you proposing we add a parameter to the ASPAC to pass
"n" to the SG ?

[snip]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 25 Jul 2001 01:48:43 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Dynamic Registration in M3UA
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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Srivats,

No, it was the REG REQ.  Add the `n' parameter to the REG REG.  That was it.

--Brian

Brian F. G. Bidulock wrote:                               (Wed, 25 Jul 2001
01:29:03)
> Srivats,
> 
> I was proposing (well proposed before already on another
> thread) that the value `n' be added as an optional parameter
> to the ASPAC.
> 
> --Brian
> 
> Srivats P. wrote:                                         (Wed, 25 Jul
2001 11:42:28)
> > Brian,
> > 
> > See below ...
> > 
> > Srivats
> > 
> > At 7/25/01 12:51:00 AM, you wrote:
> > >Srivats,
> > 
> > [snip]
> > 
> > >> >Now, say the ASP performs an ASPAC for the Routing Context
> > >> >which corresponds to our new Routing Key.  The SGP can create
> > >> >an AS object at this time.  The only information that the SGP
> > >> >really needs to create the AS object is the Traffic Mode.
> > >> 
> > >> What about the 'n' from the n+k model of the AS if it is loadshared ?
> > >> The SGP also needs to know this value for a loadshared AS.
> > >
> > >I don't think that it really needs to know `n'.  It could easily
> > >default to 1.  Actually, as there is only one ASP registering,
> > >is doesn't really need to know traffic mode either, because
> > >Override(1+0), Load-share(1+0) and Broadcast(1+0) are all the
> > >same mode.
> > But other ASPs are probably on their way towards registration.
> > 
> > >The only difference in behavior at the SG if n != 1 would be
> > >whether there were "sufficient ASP resources" or not.
> > I agree .. the "n" value is only needed to send the NTFY (Insufficient
> > ASP Resources active in AS)
> > 
> > >It think that the `n' value should be communicated in the ASPAC
> > >message along with the Traffic Mode anyway.
> > Sorry didn't get that. Are you saying the SG will get the "n" value
> > in the ASPAC ? How ? Or are you proposing we add a parameter
> > to the ASPAC to pass "n" to the SG ?
> > 
> > [snip]
> > 
> > 
> > 
> > ---
> > 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]

-- 
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:13:10 +0500
From: "Srivats P." <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Re: Re: Dynamic Registration in M3UA
Organization: Mercury Corporation, India
X-mailer: FoxMail 2.1 [en]
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg, All,

Comments ?

Srivats

At 7/25/01 1:29:00 AM, you wrote:
>Srivats,
>
>I was proposing (well proposed before already on another
>thread) that the value `n' be added as an optional parameter
>to the ASPAC.
>
>--Brian
>
>Srivats P. wrote:                                         (Wed, 25 Jul 2001
11:42:28)
>> Brian,
>> 
>> See below ...
>> 
>> Srivats
>> 
>> At 7/25/01 12:51:00 AM, you wrote:
>> >Srivats,
>> 
>> [snip]
>> 
>> >> >Now, say the ASP performs an ASPAC for the Routing Context
>> >> >which corresponds to our new Routing Key.  The SGP can create
>> >> >an AS object at this time.  The only information that the SGP
>> >> >really needs to create the AS object is the Traffic Mode.
>> >> 
>> >> What about the 'n' from the n+k model of the AS if it is loadshared ?
>> >> The SGP also needs to know this value for a loadshared AS.
>> >
>> >I don't think that it really needs to know `n'.  It could easily
>> >default to 1.  Actually, as there is only one ASP registering,
>> >is doesn't really need to know traffic mode either, because
>> >Override(1+0), Load-share(1+0) and Broadcast(1+0) are all the
>> >same mode.
>> But other ASPs are probably on their way towards registration.
>> 
>> >The only difference in behavior at the SG if n != 1 would be
>> >whether there were "sufficient ASP resources" or not.
>> I agree .. the "n" value is only needed to send the NTFY (Insufficient
>> ASP Resources active in AS)
>> 
>> >It think that the `n' value should be communicated in the ASPAC
>> >message along with the Traffic Mode anyway.
>> Sorry didn't get that. Are you saying the SG will get the "n" value
>> in the ASPAC ? How ? Or are you proposing we add a parameter
>> to the ASPAC to pass "n" to the SG ?
>> 
>> [snip]
>> 
>> 
>> 
>> ---
>> 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 12:23:17 +0500
From: "Srivats P." <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Re: Re: Dynamic Registration in M3UA
Organization: Mercury Corporation, India
X-mailer: FoxMail 2.1 [en]
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

At 7/25/01 1:48:00 AM, you wrote:
>Srivats,
>
>No, it was the REG REQ.  Add the `n' parameter to the
>REG REG.  That was it.

That sounds better.

Greg, All : Comments ?

Srivats

>
>--Brian
>
>
>Brian F. G. Bidulock wrote:                               (Wed, 25 Jul 2001
01:29:03)
>> Srivats,
>> 
>> I was proposing (well proposed before already on another
>> thread) that the value `n' be added as an optional parameter
>> to the ASPAC.
>> 
>> --Brian
>> 
>> Srivats P. wrote:                                         (Wed, 25 Jul
2001 11:42:28)
>> > Brian,
>> > 
>> > See below ...
>> > 
>> > Srivats
>> > 
>> > At 7/25/01 12:51:00 AM, you wrote:
>> > >Srivats,
>> > 
>> > [snip]
>> > 
>> > >> >Now, say the ASP performs an ASPAC for the Routing Context
>> > >> >which corresponds to our new Routing Key.  The SGP can create
>> > >> >an AS object at this time.  The only information that the SGP
>> > >> >really needs to create the AS object is the Traffic Mode.
>> > >> 
>> > >> What about the 'n' from the n+k model of the AS if it is loadshared
?
>> > >> The SGP also needs to know this value for a loadshared AS.
>> > >
>> > >I don't think that it really needs to know `n'.  It could easily
>> > >default to 1.  Actually, as there is only one ASP registering,
>> > >is doesn't really need to know traffic mode either, because
>> > >Override(1+0), Load-share(1+0) and Broadcast(1+0) are all the
>> > >same mode.
>> > But other ASPs are probably on their way towards registration.
>> > 
>> > >The only difference in behavior at the SG if n != 1 would be
>> > >whether there were "sufficient ASP resources" or not.
>> > I agree .. the "n" value is only needed to send the NTFY (Insufficient
>> > ASP Resources active in AS)
>> > 
>> > >It think that the `n' value should be communicated in the ASPAC
>> > >message along with the Traffic Mode anyway.
>> > Sorry didn't get that. Are you saying the SG will get the "n" value
>> > in the ASPAC ? How ? Or are you proposing we add a parameter
>> > to the ASPAC to pass "n" to the SG ?
>> > 
>> > [snip]
>> > 
>> > 
>> > 
>> > ---
>> > 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]
>
>-- 
>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 02:36:00 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: M3UA-08: Correliation Id
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 
                      CAA32023
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,

Broadcast mode needs a Correlation Id to be sent to an ASP on one of the
first messages after the ASP goes active.  This is so that the broadcast ASP
can synchronize the incoming message stream with that of other ASPs in the
broadcast AS.   M2UA has this parameter and procedures defined for its use
in a broadcast AS.  The Correlation Id is only necessary on DATA messages.

The M2UA text reads for data message:

    Correlation ID (optional)

...

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x311)           |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Correlation Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

...

   The Correlation Id parameter uniquely identifies the MSU carried in the 
   Protocol Data within an AS.  This Correlation Id parameter is assigned 
   by the sending M2UA.

And under procedures:

   Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SG MUST
   tag the first DATA message broadcast in each SCTP stream with a
   unique Correlation Id parameter.  The purpose of this Correlation Id
   is to permit the newly active ASP to synchronize its processing of
   the traffic in each ordered stream with other ASPs in the broadcast
   group.

Without this parameter and procedure, an ASP coming newly active into an
already active Broadcast AS will find it impossible to synchronize itself
with other ASPs in the AS.

--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: Wed, 25 Jul 2001 02:39:19 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: M3UA-08: Typo
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]>

Top of page 32:

         0x02        Subsystem Numbers
         0x020e      Originating Point Code List
         0x020f      Circuit Range

SSN should be 0x020d.

--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 03:23: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: UAs: Common ASP 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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken, Greg, John,

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.

--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: "Garnero, Pierre" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv7: SG redundancy
Date: Wed, 25 Jul 2001 10:33:34 +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]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

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.

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

> 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. And this last problem is not solved by M3UA.
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. 

> 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]
Date: Wed, 25 Jul 2001 04:19:47 -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 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.

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

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

I have handled the problem, it just needs minor support from M3UA.

> 
> 
> > 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]
From: "Garnero, Pierre" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UAv7: SG redundancy
Date: Wed, 25 Jul 2001 11:43:56 +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: [161.114.32.104]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

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 !!! :-)
> > 
> > > 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.
> 
> I have handled the problem, it just needs minor support from M3UA.
> 
On the IP side, may be. Not on the SS7 side (IMHO).
> > 
> > 
> > > 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]
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