Subject: [SUA issue 4] ASP Capablities - CLOSED

From: [email-masked]
Date: Wed, 22 Aug 2001 12:50:06 +0300

Hi all,

The offending text has been removed from the document.

John

> -----Original Message-----
> From: ext [email-masked] 
> Sent: 14 August, 2001 09:37
> To: sigtran
> Subject: [SUA issue 4] ASP Capablities
> 
> 
> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 06 August, 2001 22:43
> To: Loughney John (NRC/Helsinki); Lyndon Ong
> Subject: Fwd: SUAv7: ASP Capablities
> 
> 
> Attached is an issue for SUA Last Call.
> 
> Removal of redundant ASP Capabilities parameter.
> 
> --brian
> 
> ------_=_NextPart_000_01C12488.2F77D24A
> From: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
> Cc: [email-masked]
> Subject: SUAv7: ASP Capablities
> Date: Wed, 25 Jul 2001 22:11:36 +0300
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2652.78)
> List-Unsubscribe: 
> <mailto:[email-masked]>
> Content-Type: text/plain
> 
> John,
> 
> What is the point of the ASP Capabilities parameter?  Certainly
> all of the Routing Context information must be provisioned in
> the SGP and the ASPs capabilities can be known to the SGP in
> the same fashion.  Is not the SS7 interworking situation and
> protocol class implicit in the Routing Context?  Is there some
> use for it?
> 
> ASP Capablities sounds like more of a registration item.  Which
> leads me to my next question: Why doesn't SUA support a registration/
> deregistration procedure?  Certainly Subsystem Number and ASP
> Capabilities sound like reasonable Routing Keys.  Even SRN ranges
> or TIDs make sense as well.
> 
> --Brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
> 
> ------_=_NextPart_000_01C12488.2F77D24A--
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

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

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 22 Aug 2001 16:01:11 +0200

Hi all,

In addition to the routing key parameters described by Brian, we should add
protocol class as well (although I'd not call it ASP capabilities). It might
be interesting to split CL and CO traffic, especially if you're going to
work without coupling of connection sections (CO) at the SG ...

Otherwise, the procedures look fine.

Any objections ?

____________________________

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 22 augustus 2001 11:50
To: sigtran
Subject: [SUA issue 4] ASP Capablities - CLOSED

Hi all,

John

> or TIDs make sense as well.

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 11:41:31 -0500

Gery,

It makes sense to me to split CO and CL, however, protocol class
might not be the best thing to do that with (because 0 and 1 are
CL and 2 and 3 are CO).  Because even class 0 has to send class 1
messages for UDT segmentation, I suppose it is less valuable to
separate class 0 from class 1.  The same is true of class 2 and 3,
there is little value in separating them.  If what one really
wants to do is separate CL from CO, perhaps a specific parameter
would be better than opening all the possibilities presented by
protocol class.

Short version: I agree with you that splitting CO and CL has
value, but don't believe that Protocol Class is the best way to
accomplish that.

--brian

Verwimp Gery wrote:                                       (Wed, 22 Aug 2001 16:01:11)
> Fax: +32 14 25 3212

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

---