Subject: Re: IPSP proposed text (1st approach)

From: [email-masked]
Date: Thu, 1 Nov 2001 20:49:12 +0530

Hi Brian,

Pls see comments...

Anshoo.

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 31, 2001 8:13 PM
Subject: Re: IPSP proposed text (1st approach)

> anssharma,
>
> [email-masked] wrote:                            (Wed, 31 Oct 2001
19:54:40)
> >
> >
> > Brian,
> >
> > Pls see comments inline...
> >
> > Anshoo.
> >
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Wednesday, October 31, 2001 7:24 PM
> > Subject: Re: IPSP proposed text (1st approach)
> >
> >
> > > Vaibhav,
> > >
> > > [email-masked] wrote:                      (Wed, 31 Oct 2001
> > 19:20:12)
> > >
> > > > >
> > > > > Here's a third: the ASP keeps track of the AS and knows which
> > > > > messages are coming from which AS.  Then RC is an attribute of
> > > > > the AS and no RK analysis or DPC examination (which is just a
> > > > > different RK analysis) is required.
> >
> > How can the M3UA at ASP know which AS the DATA to be sent belongs to
> > without analysing the Routing Label. Do you mean to say that the
> > AS Identifier would be given by MTP3 User Part??? Pls clarify...
>
> It is implicit to the interface to the MTP3 User.

Can you pls explain as to how the interface defines the AS Identifier.
An AS of basic RK Type like DPC+SIO might be identified by the Interface.
But what do we do for AS of the type DPC + OPC. Here the User cannot give
the AS Identifier by itself. Consider the following situation.

      +------+     +--------+  IP   +-----+
      | SEP  | SS7 |        +------/       \
      | PC=10+-----|  SG1   |      | AS1   |     +------+
      |      |     |  "STP" +      \  RK1  /- - -+      |  +-----+
      +------+     +--------+       +-----+      | ASP  |  |     |
                                                 | 200  |--|ISUP |
      +------+     +--------+       +-----+      |      |  |     |
      | SEP  | SS7 |        |      /       \- - -+      |  +-----+
      | PC=20+-----|  SG2   |  IP  | AS2   |     +------+
      |      |     | "STP"  +------\ RK2   /
      +------+     +--------+       +-----+

Now
 RK1 is DPC = 200, OPC = 10, SIO = 5
 RK2 is DPC = 200, OPC = 20, SIO = 5

So now when ISUP on ASP gives DATA to M3UA how do you expect it to
know to through which AS this DATA would be routed unless you want
ISUP to know about the ASs. In this scenario how can Analysis of the
Routing Label in the Data be avoided.

>
> > and even after knowing the AS there would be a considerable amount of
> > processing involved in finding the SGPs in which this AS is Active.
>
> Depends if there are more than one.
>
> > I do not understand why we need to know whether the RC is Active
> > while sending DATA from the ASP to SG. Is the SG Reachability Status
> > of the DPC not sufficient?
>
> No.  It was decided that SNMM needed to be on a per-SG basis rather
> than a per SGP basis.  ASPTM is on a per ASP/AS basis and is the best
> way for the SG can control traffic.  SNMM becomes insufficient for
> controlling traffic between SGP and ASP when the RC is more granular
> than DUPU (e.g. CIC Range).

SNMM being on a per SG basis is fine and ASPTM is the best way for controlling
traffic from SG to ASP but my question is that still why do we need to use the
RC
from ASP to SG.
About DUPU granularity do you mean to say that the SG will send Active Ack only
when a particular CIC range on SS7 is available? pls clarify.

>
> --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: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 1 Nov 2001 10:40:07 -0600

anssharma,

[email-masked] wrote:                            (Thu, 01 Nov 2001 20:49:12)
>       +------+     +--------+       +-----+      | ASP  |  |     |

The AS is an MTP-User.  ISUP is an MTP-User.  Why would you not want
ISUP to know that it is an MTP-User?

The ISUP state machine that receives 200/10/5/CIC=3 is the same
one that sends 10/200/5/CIC=3.  All that the ISUP state machine
need do is identify itself in messages to the ASP for the ASP to
know to which AS it belongs.  This is trivial.

> RC from ASP to SG.

So that the SG knows to which AS the traffic belongs so that it too
can control traffic.  See long discussions on Routing Context.

> when a particular CIC range on SS7 is available? pls clarify.

The following is a valid routing key:
	
	RK3 is DPC = 200, OPC = 30, SIO = 5, CIC = 0 to 1023

--brian

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

---

---

From: [email-masked]
Date: Thu, 1 Nov 2001 23:28:23 +0530

Brian,

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 01, 2001 10:10 PM
Subject: Re: IPSP proposed text (1st approach)

> know to which AS it belongs.  This is trivial.

This is not trivial because ISUP would need to know about the ASs.

> RK3 is DPC = 200, OPC = 30, SIO = 5, CIC = 0 to 1023

RK is fine... but do you mean to say that on receiving
ASPAC from the ASP the SG tests the availability of the RC on SS7 side,
in this case whether ISUP on PC 30 is available for CIC Range 0 to 1023,
and returns an ASPAC-Ack only if RC is reachable on SS7 ??
This doesn't seem acceptable.

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Thu, 1 Nov 2001 15:39:26 -0800 (PST)

Brian, 

See below...

--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> Javier,
> 
> Javier Pastor-Balbas wrote:                                (Wed, 31
> Oct 2001 12:18:45)
> > Hi Brian, 
> > 
> > See comments below...
> > 
> > --- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > > anssharma,
> > > 
> > > [email-masked] wrote:                            (Wed, 31
> Oct
> > > 2001 19:54:40)
> > > > 
> > > > 
> > > > Brian,
> > > > 
> > > > > [email-masked] wrote:                      (Wed, 31
> Oct
> > > 2001
> > > > 19:20:12)
> > > > >
> > > > > > >
> > > > > > > messages are coming from which AS.  Then RC is an
> attribute
> > > of
> > > > How can the M3UA at ASP know which AS the DATA to be sent
> belongs
> > > to
> > One of the reasons of including RC in DATA mesgs, was to be able in
> the
> > ASP to differenciate data flows to different ASs. With single-ended
> you
> > lose this capability since RC is like a connection identifier. It
> loses
> > its meaning of being a different value for each AS. Therefore RC in
> > DATA msgs can not make sense...
> 
> Wrong.  RC is still used to identify the AS at the local end of an
> association.  All that is needed.  With double ended you would like
> to force the AS to be associated wtih two RCs (one for each
> direction)
> meaning that existin ASP code cannot be reused.  It makes perfect
> sense
> to use one RC to represent the local AS and traffic in both
> directions
> to and from it just as in the SG/AS case.  Your proposal wants to
> change
> all that and require the ASP to attach one RC for outgoing messages
> and another to incoming for the same AS.  This is positively
> different
> from the SG/AS case, and my primary objection to the double-ended
> proposal.
> 

Brian, some questions

Question 1: how can you differenciate two communications that are held
at the same time by two ASPs serving to two different ASs (each one)
with your model?? You want to have over the same association traffic
from AS-1a to AS-2a and from AS-1b to AS-2b. Of course ASP-1 serves
AS-1x and ASP-2 serves AS-2x. Note again that you only have one
association between two ASPs. It would help to see the information that
ASPAC(s) sends and how each node reacts.

Question 2: Do you have to predefine an RC for all the possible
combinations of ASs communications, taking into account all the ASs
served by two specific ASPs?? 

Question 3: If AS-1a wants to communicate with AS-2b, do you need to
set a new RC for this communication apart from the defined ones in
Question 1?

> > Anyway, a model has to be good enough to not change the previously
> > agreed defined parameters...
> 
> That's why single-ended is the way to go.  Double ended changes
> conditions at the ASP by requiring two RCs (count 'em) to be
> associated with one AS for a single bidirectional traffic flow.
> In both the single-ended and SG/AS models only one RC value (count
> 'em) need be associated with an AS at an ASP to represent a single
> bidirectional traffic flow.
> 
> Can you count?  Count the RCs for us...
> 

Well, I think I can still remember the last Sesame Street chapters...
After counting twice I just see: 
- 1 RC per AS in double-ended
- 1/2 RC per AS in single-ended

As we have 1 RC per AS in SG-AS communication, it seems that double
ended follows the same philosophy...

Cheers // Javier.

> --brian

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 1 Nov 2001 18:30:39 -0600

Anssharma,

> > > > > without analysing the Routing Label. Do you mean to say that the AS
> > > > > Identifier would be given by MTP3 User Part??? Pls clarify...
> > > >
> > > An AS of basic RK Type like DPC+SIO might be identified by the
> > > Interface.  But what do we do for AS of the type DPC + OPC. Here the
> > > User cannot give the AS Identifier by itself. Consider the following
> > > situation.
> > >
> > > So now when ISUP on ASP gives DATA to M3UA how do you expect it to know
> > > to through which AS this DATA would be routed unless you want ISUP to
> > > know about the ASs. In this scenario how can Analysis of the Routing
> > > Label in the Data be avoided.
> >
> > The AS is an MTP-User.  ISUP is an MTP-User.  Why would you not want ISUP
> > to know that it is an MTP-User?
> >
> > The ISUP state machine that receives 200/10/5/CIC=3 is the same one that
> > sends 10/200/5/CIC=3.  All that the ISUP state machine need do is identify
> > itself in messages to the ASP for the ASP to know to which AS it belongs.
> > This is trivial.
> 

The ISUP as MTP-User *is* the AS.  So, it is trivial.

> 
> >
> > > > > and even after knowing the AS there would be a considerable amount
> > > > > of processing involved in finding the SGPs in which this AS is
> > > > > Active.
> > > >
> > > SNMM being on a per SG basis is fine and ASPTM is the best way for
> > > controlling traffic from SG to ASP but my question is that still why do
> > > we need to use the RC from ASP to SG.
> >
> > So that the SG knows to which AS the traffic belongs so that it too can
> > control traffic.  See long discussions on Routing Context.
> >
> > > About DUPU granularity do you mean to say that the SG will send Active
> > > Ack only when a particular CIC range on SS7 is available? pls clarify.
> >

No, when SIO=5 becomes unavailable on SS7 (UPU) the SG can send
DUPU(5) to RC3 (AS3/RK3).

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 2 Nov 2001 00:27:54 -0600

Javier,

Javier Pastor-Balbas wrote:                                (Thu, 01 Nov 2001 15:39:26)
> ASPAC(s) sends and how each node reacts.

For what routing keys?  (It is important.)

> served by two specific ASPs?? 

An RC has a one-to-one relationship to an RK used to direct
traffic at an AS.  One RC value is required for each RK,
just as in the AS/SG case.

Point-to-point communications (I didn't write it) limits the
range of routing keys supportable in IPSP.

Interestingly enough, our architectural framework RFC 2719
shows what we are now calling the IPSP case as SG to SG
communication.

It comes back to whether you view the IPSP as having SG state
machines or not.

> set a new RC for this communication apart from the defined ones in

That would follow what is usually meant by "point-to-point".  For
true "point-to-point" a separate association might be required.

> - 1/2 RC per AS in single-ended

Can you multiply by 2?

> ended follows the same philosophy...

Two RCs per traffic flow for double ended (two half-duplex).
One for single ended (one full-duplex).

Count again.  (This time with Count Dracula).

--brian

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

---

---

From: [email-masked]
Date: Fri, 2 Nov 2001 12:26:47 +0530

Brian,

"Brian F. G. Bidulock" <[email-masked]> on 11/02/2001 06:00:39 AM

Please respond to [email-masked]

To:   Anshoo Sharma/HSS@HSS
cc:   sigtran <[email-masked]>

Anssharma,

[Anshoo]
This is non-trivial because you are proposing a change in ISUP
to accomodate M3UA. This is against the genral convention that
SS7 protocols should not be affected. So, there should be some
text in the Draft to indicate that modification in User Parts
might be required to for using M3UA.
However if everyone is comfortable...I think that you need to
provide the relevant text?

[Anshoo]
This is brings us back to square one. Now that you say you will use DUPU,
this means the RC State is does not signify whether the Dest (the whole RK)
is reachable on the SS7 side. So why the need to check it at all while
sending Data and why not use only use the Reachability Status of the DPC
for sending the Data from ASP.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 2 Nov 2001 02:48:23 -0600

anssharma,

[email-masked] wrote:                            (Fri, 02 Nov 2001 12:26:47)
> provide the relevant text?

I propose nothing.  You asked how ASP could generate RC to SGP
without doing reverse RK analysis.  I told you one (trivial) way.
Use it or don't.   That's implementation option.

> for sending the Data from ASP.

You pick.  Don't expect the draft to force one view or the other.

--brian

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

---

---

From: [email-masked]
Date: Fri, 2 Nov 2001 14:55:23 +0530

"Brian F. G. Bidulock" <[email-masked]> on 11/02/2001 02:18:23 PM

anssharma,

[Anshoo]
Fine.

[Anshoo]
In that case drop the words "SHOULD NOT" in the draft from the following lines
and please reword it as an option. So that the Draft does not force one view
on the other (Just as you said).

M3UA Draft Ver 9
Sec 4.3.4.4
"The ASP SHOULD NOT send Data messages for the related Routing Context(s) before

receiving an ASP Active Ack message, or it will risk message loss."

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 2 Nov 2001 03:49:04 -0600

anssharma,

> receiving an ASP Active Ack message, or it will risk message loss."

Your proposed wording change is unacceptable.  The SHOULD NOT is required
for interoperability.  An SGP must be permitted to discard messages for
INACTIVE AS.  An implementer should carefully consider that sending messages
for INACTIVE AS can easily result in message loss.

--brian

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

---

---

From: [email-masked]
Date: Fri, 2 Nov 2001 15:23:36 +0530

Hi

    I am sorry for my ignorance but can somebody please clarify as to what
do we mean by a message loss? From M3UA point of view will it include
messages which are lost because the M3UA User is not available or will it
only include messages which are lost because of M3UA failure?

Regards
Vaibhav

----- Original Message -----
From: <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Friday, November 02, 2001 2:55 PM
Subject: Re: IPSP proposed text (1st approach)

> > > > The AS is an MTP-User.  ISUP is an MTP-User.  Why would you not want
ISUP
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: [email-masked]
Date: Sat, 3 Nov 2001 14:49:25 +0530

Brian,

"Brian F. G. Bidulock" <[email-masked]> on 11/02/2001 03:19:04 PM

anssharma,

[Anshoo]
This is not True...
Keeping the discussion up till now in mind, sending DATA for an ACTIVE AS in
no way prevents Message Loss.
This is because an RC being ACTIVE does not mean that the RK is reachable on
SS7.
So the "Message Loss risk" should be dropped from the Draft.

--brian

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

Anshoo.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 3 Nov 2001 04:06:14 -0600

anssharma,

You have it backwards.  The draft does not say that message loss will
not result from sending DATA from an ACTIVE AS.  It says that the ASP
will risk message loss if it sends from an INACTIVE AS.  Which is true.

This passage has been discussed previosly.  I don't think that you
will find that anyone else is interested in striking the paragraph.

--brian

[email-masked] wrote:                            (Sat, 03 Nov 2001 14:49:25)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Sun, 4 Nov 2001 11:23:06 -0800 (PST)

Brian, 

See my comments below...

> For what routing keys?  (It is important.)

Lets say:
- AS-1a serves RK-1a
- AS-2a serves RK-2a
- AS-1b serves RK-1b
- AS-2b serves RK-2b

> It comes back to whether you view the IPSP as having SG state

Did you answer yes or not...? 

> true "point-to-point" a separate association might be required.

Do you mean that your single-ended will need another association for
this purpose? If not, please explain how you solve this scenario...

> > - 1/2 RC per AS in single-ended

That was not included in my Sesame Street lessons.

> One for single ended (one full-duplex).

This leads to me to the same conclussion I got some mails before:

- single-ended model -> try to keep the same messages going through the
network (at least for ASPAC, I'm still looking forward seeing your
Registration example). And for that purpose, you change the behaviour
of nodes: Not all the ASPs send ASPAC to activate their ASs !!

- double ended model -> try to keep the same meaning of concepts and
the same philosophy in nodes: All ASPs send ASPAC to activate their
ASs, as in the SG-AS model.

> Count again.  (This time with Count Dracula).

He did it for me the first time and I rely on his big experience in
counting, What about you...?   ;-)

Cheers // Javier.

> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 4 Nov 2001 13:46:49 -0600

Javier,

Javier Pastor-Balbas wrote:                                (Sun, 04 Nov 2001 11:23:06)
> > For what routing keys?  (It is important.)

Those are not routing keys.

> Did you answer yes or not...? 

I said "one RC value is required for each RK, just as in the AS/SG case".

> this purpose? If not, please explain how you solve this scenario...

Depends on routing keys.  What routing keys are you using for your
example.  I showed this in my "simple" example that the double-ended
does not seem to work for.  (3 AS).  How do you intend to solve that
problem with double-ended?

> Registration example).

I'm looking forward to seeing your registration for my simple example
as the RK table is stuffed as it is.

> And for that purpose, you change the behaviour

In my simple example, double-ended approach cannot even activate the AS
because of RC/RK ambiguity.

> ASs, as in the SG-AS model.

double-ended: break the RC/RK/AS relationship by makeing a 1:1:1 relationship
a 2:2:1 relationship.

--brian

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

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Sun, 4 Nov 2001 12:04:43 -0800 (PST)

--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > > Javier Pastor-Balbas wrote:                                (Thu,
> 01
> > > Nov 2001 15:39:26)
> > > > 
> > > > Brian, some questions
> > > > 
> > > > Question 1: how can you differenciate two communications that
> are
> > > held
> > > > association between two ASPs. It would help to see the
> information
> > > that

They are general RKs... Maths work like that... But anyway let's try if
you can answer with specific ones...

 - AS-1a serves RK-1a = {DPC=100}
 - AS-2a serves RK-2a = {DPC=200}
 - AS-1b serves RK-1b = {DPC=300}
 - AS-2b serves RK-2b = {DPC=400}

> I said "one RC value is required for each RK, just as in the AS/SG

But you didn't answer how your model works... At least in another
simple example that I've just send to you it seems not to be compliance
with your statement...

> problem with double-ended?

You didn't show that. You showed that you don't know how the
double-ended works (read the text I sent). In double-ended there is a
relationship 1:1 in RK-RC as in SG-AS. If one ASP registrate for two
RKs it will get two RCs as a response. If it registrate for three it
will obtain three RCs and so on...

On the other hand, I showed you an example where your model don't
follow the previous statement...

Cheers // Javier.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 4 Nov 2001 15:03:14 -0600

Javier,

Javier Pastor-Balbas wrote:                                (Sun, 04 Nov 2001 12:04:43)
>  - AS-2b serves RK-2b = {DPC=400}

There is no need to use RCs or registration at all in this case.
Each ASP activates implicitly.  DUNA/DAVA is used to manage which
point codes are reachable.  You need RK's more granular than
DPC/SI in a point-to-point configuration to even require RCs.

--brian

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

---