Subject: [Sigtran] M3UA and support for multiple SGs

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 29 Jun 2006 10:52:12 -0400

To whom it may concern:

In reviewing the M3UA RFC with a couple other members of the community,
it would appear that sub-PC routing granularity will not work if
connecting to more than one SG.  Let's take the following example:

      AS1:                    AS2:
     1-1-1  ISUP             1-1-1   SCCP
     +----+                  +----+
     |ASP1|                  |ASP2|
     ++--++                  +++--+
      |  |                    ||
      |  |                    ||
      |  |  +-----------------+|
      |  +--+------------------+-----+
      |     |                  |     |
      |     |                  |     |
    +-+-----+-------+       +--+-----+------+
    |    SG1        |       |    SG2        |
    |   PC = 2-2-2  |       |   PC = 3-3-3  |
    +------+--------+       +-------+-------+
           |                        |
           |                        |

In this case, AS1 has routing keys of DPC=1-1-1, SI=5.  AS2 has RK of
DPC=1-1-1, SI=3.  If, for some reason, ASP1 becomes inaccessible to SG1,
but not SG2, then SG1 might send a UPU for PC=1-1-1, User=ISUP to the
network.  However, this user is still accessible via SG=2.

The same problem might exist if the Rkeys were DPC/OPC rather than
DPC/SI

Couple questions:

1) Does anyone see any problems with this logic?

2) Do you think we should mention this in the new M3UA RFC bis document
(or some other RFC).  If so, I'd be happy to try to work on some wording
with others.  Or is this inherently obvious to all members of the
community and therefore doesn't require mention?

Regards,
Lincoln

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jun 2006 10:31:09 -0600

Licoln,

Haresign Lincoln wrote:                    (Thu, 29 Jun 2006 10:52:12)
> 1) Does anyone see any problems with this logic?

SCCP can work if the AS point code is the ANSI T1.112/2000+ "alias"
point code that is used to address the common GTT function of the
associated pair of STPs.  For these point codes the ANSI MTP routes
between STPs based on the availability of the GTT function (MTP user).

It is not too difficult to conceive of an M3UA NIF that can do the
same for ISUP.

> community and therefore doesn't require mention?

M3UA bis is long gone.  I think it is obvious from an SS7 perspective.

--brian

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 29 Jun 2006 11:32:01 -0500 (CDT)

comments inline.

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

> connecting to more than one SG.  Let's take the following example:
what do u mean by 'ASP1 becomes inaccessible to SG1'  ?
 1.if really ISUP user part is unavailable then it is the responsibility
   of ASP1 to broadcast UPU to all its adjecent nodes , in your case it is 
   SG1 and SG1. or in response mode ASP will send UPU.

 2.if ISUP user part is availble but there is a problem with association
   then your must not send UPU , you are supposed to send ASPSM/ASPSM
   message (say for ex ASP-INAC).

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jun 2006 11:10:12 -0600

Samuel,

Samuel Dur D. Jeyaseelan wrote:             (Thu, 29 Jun 2006 11:32:01)
>    SG1 and SG1. or in response mode ASP will send UPU.

ASPs cannot send UPU.  ASPTM messages are interpreted by the SG and the
SG decides whether to send UPU within the SS7 network.  Also, in SS7 UPU
is never broadcast: it is sent in response to a message received for an
inaccessible/unequipped user part.

>    message (say for ex ASP-INAC).

ASP Inactive is an ASPTM message, not an ASPSM message.  Also, it would be
very difficult for ASP1 to send an ASP Inactive on an association that no
longer exists.  If your meaning that ASP1 should send ASP Inactive to SG2,
it will turn a partial failure into a complete failure.  There is nothing
stoping SG1 from routing the traffic (e.g. via STP C-links ala ANSI
T1.111.4/2000) to SG2 avoiding effective user-part failure altogether.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 29 Jun 2006 13:19:47 -0400

Brian,

Just so I understand.  You agree, but you think it is obvious and
therefore no documentation is required.  Is that correct, or did I
misunderstand.

Also, the BIS document is dated Feb 2006 so it has a couple more months
before it expires.  Is it really long gone?

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, June 29, 2006 12:31 PM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA and support for multiple SGs

Licoln,

It is not too difficult to conceive of an M3UA NIF that can do the same
for ISUP.

> 2) Do you think we should mention this in the new M3UA RFC bis 
> document (or some other RFC).  If so, I'd be happy to try to work on 
> some wording with others.  Or is this inherently obvious to all 
> members of the community and therefore doesn't require mention?

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jun 2006 11:50:52 -0600

Lincoln,

Haresign Lincoln wrote:                      (Thu, 29 Jun 2006 13:19:47)
> therefore no documentation is required.  Is that correct, or did I

It is a function of the NIF and we don't document the NIF as it is
a largely SS7 matter, local to the SG, and outside the scope of the
protocol specification.

> before it expires.  Is it really long gone?

Try then ID-Tracker at https://datatracker.ietf.org/public/pidtracker.cgi

It was approved as a Proposed Standard in March 2006, announced on this
list as such, and is sitting in the RFC Editor's queue awaiting assignment
of an RFC number.

That's pretty long gone as far as the RFC process is concerned.

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 29 Jun 2006 14:17:39 -0400

Brian,

OK...now I understand your "long gone" comment.

Thanks!
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, June 29, 2006 1:51 PM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA and support for multiple SGs

Lincoln,

> therefore no documentation is required.  Is that correct, or did I 

It is a function of the NIF and we don't document the NIF as it is a
largely SS7 matter, local to the SG, and outside the scope of the
protocol specification.

> Also, the BIS document is dated Feb 2006 so it has a couple more 
> months before it expires.  Is it really long gone?

Try then ID-Tracker at
https://datatracker.ietf.org/public/pidtracker.cgi

It was approved as a Proposed Standard in March 2006, announced on this
list as such, and is sitting in the RFC Editor's queue awaiting
assignment of an RFC number.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jun 2006 13:15:27 -0600

Lincoln,

http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-loadsel-04.txt

also addresses this problem as it permits a load selection based on SI.  Using
LOADSEL, ASP1 and ASP2 have the same RK:AS:RC but a different load selector.
When ASP1 fails to SG1, ASP2 is notified that that ASP1 has failed and SG1
pends messages waiting for another ASP to pick up the load.

(These problems were issues at last call that were solved a long time ago.  At
 that time, Lyndon told us that these items could be addressed in extension
 drafts.  rfc3332bis was far more concerned with arguing minor points and
 errata than correcting these identified fundamental gaps in the
 specification.  Immediately after letting the RFCs proceed, I wrote a set of
 six or so drafts to address each of the major issues.  Please read them: a
 significant amount of work and consideration went into their preparation.)

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 29 Jun 2006 15:26:51 -0400

OK, do you suggest that we read those drafts now....or wait for them to
filter through the IETF process?

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, June 29, 2006 3:15 PM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA and support for multiple SGs

Lincoln,

http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-loadsel-04
.txt

also addresses this problem as it permits a load selection based on SI.
Using LOADSEL, ASP1 and ASP2 have the same RK:AS:RC but a different load
selector.
When ASP1 fails to SG1, ASP2 is notified that that ASP1 has failed and
SG1 pends messages waiting for another ASP to pick up the load.

(These problems were issues at last call that were solved a long time
ago.  At  that time, Lyndon told us that these items could be addressed
in extension  drafts.  rfc3332bis was far more concerned with arguing
minor points and  errata than correcting these identified fundamental
gaps in the  specification.  Immediately after letting the RFCs proceed,
I wrote a set of  six or so drafts to address each of the major issues.
Please read them: a  significant amount of work and consideration went
into their preparation.)

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jun 2006 13:46:19 -0600

Haresign,

Haresign Lincoln wrote:                                           (Thu, 29 Jun 2006 15:41:36)
> 
> I am very interested in any that deal with congestion and/or
> distribution (especially regarding distribution for M3UA in the case of
> ISUP).
> 

LOADSEL and LOADGRP deal with distribution.  ASPCONG deals with congestion
(a we discussed on this reflector before), however it is a -00 revision and
the RFC Editor just threw it back at me (this is the second time).  I have
to manually resubmit it again after the meeting is over.   The ASPCONG draft
is sitting at

http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-aspcong-00.txt

and is on the list that I pointed you to at:

http://www.openss7.org/sigtran01.html

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jun 2006 13:36:06 -0600

Lincoln,

Haresign Lincoln wrote:                            (Thu, 29 Jun 2006 15:26:51)
> filter through the IETF process?

The only change is the date, referenced draft and RFC versions, and some minor
cosmetics to pass id-nits (and the RFC Editor missed a version number).  The
technical content is identical.  You can find most of them here:

where they have been for a few years now.  Lyndon asked whether we should
recharter to include these drafts.  Nobody repsonded.  It seems most of the
WG is interested in their immediate problems rather than building solutions.

Your comments and those of the WG are welcome on any or all of these drafts.

---brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 29 Jun 2006 15:41:36 -0400

Brian,

OK, I commit to going through some of them...I'll provide some feedback
after the US holidays.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, June 29, 2006 3:36 PM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA and support for multiple SGs

Lincoln,

Haresign Lincoln wrote:                            (Thu, 29 Jun 2006
15:26:51)
> OK, do you suggest that we read those drafts now....or wait for them 
> to filter through the IETF process?
> 

The only change is the date, referenced draft and RFC versions, and some
minor cosmetics to pass id-nits (and the RFC Editor missed a version
number).  The technical content is identical.  You can find most of them
here:

where they have been for a few years now.  Lyndon asked whether we
should recharter to include these drafts.  Nobody repsonded.  It seems
most of the WG is interested in their immediate problems rather than
building solutions.

Your comments and those of the WG are welcome on any or all of these
drafts.

---brian

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