Subject: Re: [Sigtran] SUA implementor's guide

From: Cullen Jennings <[email-masked]>
Date: Tue, 3 Oct 2006 21:09:00 -0700

Glad to hear this is still moving forward. I got some promises when  
we reading earlier documents that some things I was concerned about  
"would be in the implementors guide" so I do want to hold folks to  
finishing that sooner or later :-) More importantly, I think some of  
this stuff if sufficiently complicated that outside a somewhat small  
group of folks, an implementor guide will really help this work be  
successful.

On Sep 29, 2006, at 8:46 AM, Ong, Lyndon wrote:

> Hi Guys,
>
> I suspect that Loede and John have been too busy to keep this
> updated.  Is there still interest in this?
>
> Cheers,
>
> Lyndon
>
> -----Original Message-----
> From: Barry Nagelberg [mailto:[email-masked]]
> Sent: Friday, September 29, 2006 8:30 AM
> To: [email-masked]
> Subject: RE: [Sigtran] SUA implementor's guide
>
> Lincoln,
>
> It has apparently expired and been deleted. It was issued on March 6.
>
> <snip>
> Signalling Transport Working group                              L.  
> Coene
> Internet-Draft                                                    
> Siemens
> Expires: September 7, 2006                                   J.  
> Loughney
>                                                                     
> Nokia
>                                                            March 6,  
> 2006
>
>
>                         SUA Implementor's guide
>            <draft-ietf-sigtran-sua-implementor-guide-03.txt>
> <snip>
>
> Barry Nagelberg
> Adax, Inc.
>
> -----Original Message-----
> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Friday, September 29, 2006 11:16 AM
> To: [email-masked]
> Subject: [Sigtran] SUA implementor's guide
>
>
>
> Just out of curiosity, what happened to the SUA implementer's guide?
>
> Was there any intention to update the SUA RFC in a similar manner  
> as was
> done to the M3UA RFC?
>
> Regards,
> Lincoln
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 3 Oct 2006 22:58:38 -0600

Cullen,

Cullen Jennings wrote:                   (Tue, 03 Oct 2006 21:09:00)
> 
> More importantly, I think some of  

Well, the implementor's guide is really a specification
errata document and not a guide to the uninitiated.  It
assumes, as does the specification, that the reader has
a very solid understanding of the thing being transported.

--brian

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Sat, 7 Oct 2006 17:22:20 -0400

Hi Folks,

Now that the SUA Implementor's Guide has been reissued, I'd like to
see if people are ready to do a WG Last Call on it.  If so, we can
start this up next week.

Cheers,

L. Ong 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, October 03, 2006 9:59 PM
To: Cullen Jennings
Cc: [email-masked]; Barry Nagelberg; Ong, Lyndon
Subject: Re: [Sigtran] SUA implementor's guide

Cullen,

> group of folks, an implementor guide will really help this work be 

Well, the implementor's guide is really a specification errata document
and not a guide to the uninitiated.  It assumes, as does the
specification, that the reader has a very solid understanding of the
thing being transported.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 10 Oct 2006 11:29:26 -0400

I'm curious about this section in the Implementor's Guide:

2.10.3.  Solution description

.........

   Improving the clarity of the use of the TID and DRM label parameters:
   Redundancy - The label values are fixed length (16 bits).  So why do
   we need both a "Start" and an "End" position for applying the mask?
   One or the other would seem to be enough.

   Simplicity - Why bother with a partial-sized mask at a specified
   "start" bit.  Why not just specify a "full-sized" 32-bit (TID) or 23-
   bit (DRM) mask?  Then we do not need a "start" and "end" position.

   Contradictions - Section 4.7.2.1 states that "All the ASPs within the
   AS _must_ specify a unique label at a fixed position in the TID or
   DRN parameter."  The "must" here contradicts that fact the the TID
   and DRM parameters are listed as Optional in the ASPAC msg.  Thus if
   a label is present, then all ASP's belonging to that AS, must
   specifiy a label in the ASPAC msg. 

Should the implementor's Guide being asking questions?  I thought this
was an attempt to clarify, not to ask questions.  I would answer the
questions as follows:

So why do we need both a "Start" and an "End" position for applying the
mask?

You don't need to use all 16 bits.  So in that case, the start and end
give some flexibility as to how you want to use the TID.

Why bother with a partial-sized mask at a specified "start" bit.  Why
not just specify a "full-sized" 32-bit (TID) or 23-bit (DRM) mask?

Again...flexibility.

With regards to the contradictions, I imagine this could be clarified
with something like "If the ASPs are using the TID parameter, then....

Regards,
Lincoln

-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]] 
Sent: Saturday, October 07, 2006 5:22 PM
To: [email-masked]; Cullen Jennings
Cc: Barry Nagelberg; [email-masked]
Subject: RE: [Sigtran] SUA implementor's guide

Hi Folks,

Now that the SUA Implementor's Guide has been reissued, I'd like to see
if people are ready to do a WG Last Call on it.  If so, we can start
this up next week.

Cheers,

L. Ong 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, October 03, 2006 9:59 PM
To: Cullen Jennings
Cc: [email-masked]; Barry Nagelberg; Ong, Lyndon
Subject: Re: [Sigtran] SUA implementor's guide

Cullen,

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Oct 2006 11:46:52 -0600

Lincoln,

Worrying about start and stop bits and masks just detracts from the
fact that the DRN/TID range mechanism is broken, and is best removed.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 10 Oct 2006 13:50:11 -0400

Brian,

I'm not sure why you say it is broken.  We have deployed it and it is
working quite nicely.  Can you be more specific?

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, October 10, 2006 1:47 PM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] SUA implementor's guide

Lincoln,

Worrying about start and stop bits and masks just detracts from the fact
that the DRN/TID range mechanism is broken, and is best removed.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Oct 2006 11:52:44 -0600

Haresign,

There are ample messages on the archive explaining the problems.

--brian

Haresign Lincoln wrote:                       (Tue, 10 Oct 2006 13:50:11)

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

---

From: <[email-masked]>
Date: Tue, 10 Oct 2006 20:57:05 +0300

Hi Lincoln,

I agree.  I think we should use your text on this.

John

>From: ext Haresign Lincoln [mailto:[email-masked]] 
>Sent: 10 October, 2006 18:29
>To: Ong, Lyndon; [email-masked]; Cullen Jennings
>Should the implementor's Guide being asking questions?  I 
>thought this was an attempt to clarify, not to ask questions.  
>I would answer the questions as follows:
>
>
>So why do we need both a "Start" and an "End" position for 
>applying the mask?
>
>You don't need to use all 16 bits.  So in that case, the start 
>and end give some flexibility as to how you want to use the TID.
>
>Why bother with a partial-sized mask at a specified "start" 
>bit.  Why not just specify a "full-sized" 32-bit (TID) or 
>23-bit (DRM) mask?
>
>Again...flexibility.
>
>
>With regards to the contradictions, I imagine this could be 
>clarified with something like "If the ASPs are using the TID 
>parameter, then....
>
>Regards,
>Lincoln
>
>
>
>Now that the SUA Implementor's Guide has been reissued, I'd 
>like to see if people are ready to do a WG Last Call on it.  
>If so, we can start this up next week.
>
>Cheers,
>
>L. Ong 
>
>Well, the implementor's guide is really a specification errata 
>document and not a guide to the uninitiated.  It assumes, as 
>does the specification, that the reader has a very solid 
>understanding of the thing being transported.
>
>--brian
>
>
>--
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Oct 2006 11:57:14 -0600

Licoln,

Also, there is this document:

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

that describes a mechanism that works for all protocol classes
and in all network configurations.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 10 Oct 2006 13:58:00 -0400

Bidulock,

That's not very helpful.

--Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, October 10, 2006 1:53 PM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] SUA implementor's guide

Haresign,

--brian

Haresign Lincoln wrote:                       (Tue, 10 Oct 2006
13:50:11)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 10 Oct 2006 13:59:00 -0400

Brian,

I'm not opposed to discussing a new draft.  But first, I'd like to get
the SUA issues resolved.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, October 10, 2006 1:57 PM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] SUA implementor's guide

Licoln,

http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-loadsel-04.tx
t

that describes a mechanism that works for all protocol classes and in
all network configurations.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Oct 2006 12:01:25 -0600

Lincoln,

This issue and that draft go back 4 years.  It is not going to go away
so easily.

--brian

Haresign Lincoln wrote:                     (Tue, 10 Oct 2006 13:59:00)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 10 Oct 2006 12:17:08 -0600

Lincoln,

These questions come directly from Barry Nagleberg's note of
Feb 18, 2004: "SUA v16: TID and DRM labels".  In fact, see that
thread for more information in the issues.  And for the general
agreement that the mechanism must be fixed or removed.

Also see the thread, "SUA-09: SCCP Connections and TCAP Transactions"
from Dec 2001/Jan 2002.

There has been repeated agreement in the WG that the mechanism must
either be fixed or removed.  Neither has ocurred.  It will likely be
2008 before a fix is made.  Or perhaps my prediction of 2006 from
Message-ID: <[email-masked]> will be correct.

--brian

Haresign Lincoln wrote:                            (Tue, 10 Oct 2006 11:29:26)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 09:02:09 -0400

Brian,

With regards to Barry's comments.  If I'm reading this correctly, Barry
seemed to be concerned that the ASP would send a TID range in the
ASP_ACK message and, if the SG did not support this optional parameter,
then there would be no way of handling this.  (Barry/Brian, please
correct me if I have not interpretted your concern correctly).

I would suggest that in this case, the SG should send an error with
"Unsupported Traffic Handling Mode".  This error is sent in response to
an ASP Active message with a Traffic Mode Type that is not supported.
We can update the SUA text to indicate this.  If this is acceptable,
then I will propose some text.  If this is unacceptable, then we can
create a new error code and I will propose some text.  In any case, I
don't see this as a big problem that can't be solved.

With regards to the "SUA-09:..." thread, I don't see the problem.  You
seem to be saying that the ASP has no control over what TID is assigned.
If that is the case, then I agree that this won't work.  But if the ASP
does have control (and I don't see why it wouldn't), then the ASP can
send TIDs that match the range that it has specified.  It should send
the same TID value in the ASP_ACTIVE message to all SGPs in the SG that
it is connecting to.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, October 10, 2006 2:17 PM
To: Haresign Lincoln
Cc: Ong, Lyndon; Cullen Jennings; Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] SUA implementor's guide

Lincoln,

These questions come directly from Barry Nagleberg's note of Feb 18,
2004: "SUA v16: TID and DRM labels".  In fact, see that thread for more
information in the issues.  And for the general agreement that the
mechanism must be fixed or removed.

--brian

11:29:26)

> So why do we need both a "Start" and an "End" position for applying 
> the mask?
> 

> document and not a guide to the uninitiated.  It assumes, as does the 

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 11 Oct 2006 09:34:03 -0400

Lincoln,

Seamus Gilchrist and I asked some questions, and made some suggested solutions regarding TID and DRM labels back in
Feb-Apr of 2004, but they weren't limited only to the ASP_ACK msg. I am equally puzzled as to why the questions were put
in the IG. I agree that the solutions should have been inserted instead of the questions.

After some email exchanges on the mailing list, I made the following proposal for the IG on Apr 27, 2004:

<snip>
Here is some updated suggested text for the SUA IG, regarding the usage of
TID labels.

I suggest that we have some mailing list discussion, or poll, or something
on this issue, even prior to publication of the SUA IG. In spite of the fact
that SUA v16 is very unclear on the use of these labels, we're apparently
moving towards the RFC stage, and companies are moving ahead on SUA
implementation. If we're not careful, we run the risk of ending up with
incompatible implementations.

In section 4.7.2.1 (Association Setup, ASP going active):

<snip>
In the ASPAC message, the ASP optionally includes a TID and/or DRN Label
Parameter for each AS. If more than one ASP in a given AS includes a TID
and/or DRN Label Parameter, then these ASPs must specify a unique label at a
fixed position in the TID or DRN parameter. The same ASPAC message is sent
to each SG used for interworking with the SS7 network.

If an ASP does not include a TID and/or DRN Label Parameter in the ASPAC
message, then the SG MAY send a TCAP message with any TID or DRN to this
ASP.
<snip>

In section 4.7.3.1 (Routing and message distribution at the SG - TCAP
traffic):

<snip>
   a. The SG examines the bits between the 'Start' bit and the 'End' bit
   of the received TCAP transaction ID (TID). The 'Start' and 'End' bits
   are defined in the 'TID Label' parameter that was sent in the ASPAC
   message for this AS.

   b. If these bits exactly match the 'Label' field of the 'TID Label'
   parameter that was sent in the ASPAC message, then the message is sent
   to the ASP that registered for this label via the ASPAC msg.

   c. If these bits do not match the label field of any ASP in this AS,
   then the SG may discard the message.
<snip>

Barry Nagelberg

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Wednesday, October 11, 2006 9:02 AM
To: [email-masked]
Cc: Ong, Lyndon; Cullen Jennings; Barry Nagelberg; [email-masked]
Subject: RE: [Sigtran] SUA implementor's guide

Brian,

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, October 10, 2006 2:17 PM
To: Haresign Lincoln
Cc: Ong, Lyndon; Cullen Jennings; Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] SUA implementor's guide

Lincoln,

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 09:48:50 -0400

Barry,

This all looks fine with me.

Regards,
Lincoln 

-----Original Message-----
From: Barry Nagelberg [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 9:34 AM
To: [email-masked]
Subject: RE: [Sigtran] SUA implementor's guide

Lincoln,

Seamus Gilchrist and I asked some questions, and made some suggested
solutions regarding TID and DRM labels back in Feb-Apr of 2004, but they
weren't limited only to the ASP_ACK msg. I am equally puzzled as to why
the questions were put in the IG. I agree that the solutions should have
been inserted instead of the questions.

After some email exchanges on the mailing list, I made the following
proposal for the IG on Apr 27, 2004:

<snip>
Here is some updated suggested text for the SUA IG, regarding the usage
of TID labels.

I suggest that we have some mailing list discussion, or poll, or
something on this issue, even prior to publication of the SUA IG. In
spite of the fact that SUA v16 is very unclear on the use of these
labels, we're apparently moving towards the RFC stage, and companies are
moving ahead on SUA implementation. If we're not careful, we run the
risk of ending up with incompatible implementations.

<snip>
In the ASPAC message, the ASP optionally includes a TID and/or DRN Label
Parameter for each AS. If more than one ASP in a given AS includes a TID
and/or DRN Label Parameter, then these ASPs must specify a unique label
at a fixed position in the TID or DRN parameter. The same ASPAC message
is sent to each SG used for interworking with the SS7 network.

<snip>

   b. If these bits exactly match the 'Label' field of the 'TID Label'
   parameter that was sent in the ASPAC message, then the message is
sent
   to the ASP that registered for this label via the ASPAC msg.

Barry Nagelberg

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Wednesday, October 11, 2006 9:02 AM
To: [email-masked]
Cc: Ong, Lyndon; Cullen Jennings; Barry Nagelberg; [email-masked]
Subject: RE: [Sigtran] SUA implementor's guide

Brian,

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, October 10, 2006 2:17 PM
To: Haresign Lincoln
Cc: Ong, Lyndon; Cullen Jennings; Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] SUA implementor's guide

Lincoln,

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 09:21:56 -0600

Barry,

Yes that went some ways; however, it does not address the conflict
between Traffic Mode Type and DRN/TID label.  It seems that when
DRN/TID label is used, that the traffic mode for the AS is somehow
overridden by the label.  Now, while traffic modes are well defined
as to how traffic is distributed over the available ASPs, and what to
do when an ASP fails, the same is not true for DRN/TID labels.

To get this clear, one needs to modify ASP Up, ASP Down, ASP Active,
ASP Inactive, Notify and even Registration procedures.

Also, DLR and TID only uniquely identify a connection or transaction
within the scope of a point code.  Unlike M3UA, SUA supports relay and
can support multiple point code per AS.  Therefore, an address must be
associated with the labels.

Also, the current document is unclear as to how to handle messages
with no DLR and no TID.

The list goes on.

This is the reason that I wrote the draft:

  ftp://ftp.ietf.org/internet-drafts/draft-bidulock-sigtran-loadsel-04.txt

If you look at the draft, you will see that these issues and more, as
well as a more general mechanism to handle CIC Ranges for M3UA, SLS
Ranges for M2UA, and address/DLR/TID labels for SUA with a general
purpose load selector are addressed.

Changes necessary to get the SUA label mechanism working in a proper
fashion requires changes to the RFC that are likely outside the scope
of the IG, which should really just be Errata.

It would probably be better to strike DRN/TID Labels from the RFC with
the IG and follow along with an extension draft such as the LOADSEL
draft to put a proper mechanism in place.

--brian

Barry Nagelberg wrote:                        (Wed, 11 Oct 2006 09:34:03)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 11:31:30 -0400

Brian,

I certainly don't think we should strike it since it has a valid use for
some applications.  We are successfully using this mechanism for a
number of different applications and it works perfectly for it's
intended use.  It is part of an already agreed upon RFC.  

I believe that the TID/DLR is associated with an RC and not a point
code.

I think the TID/DLR mechanism should only be used for applications that
are working with DLRs or TIDs.  If that is not the type of application,
don't use it.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 11:22 AM
To: Barry Nagelberg
Cc: [email-masked]
Subject: Re: [Sigtran] SUA implementor's guide

Barry,

Yes that went some ways; however, it does not address the conflict
between Traffic Mode Type and DRN/TID label.  It seems that when DRN/TID
label is used, that the traffic mode for the AS is somehow overridden by
the label.  Now, while traffic modes are well defined as to how traffic
is distributed over the available ASPs, and what to do when an ASP
fails, the same is not true for DRN/TID labels.

To get this clear, one needs to modify ASP Up, ASP Down, ASP Active, ASP
Inactive, Notify and even Registration procedures.

Also, the current document is unclear as to how to handle messages with
no DLR and no TID.

The list goes on.

Changes necessary to get the SUA label mFrom [email-masked] Wed Oct 11 11:45:16 2006
Content-class: urn:content-classes:message
Subject: RE: [Sigtran] SUA implementor's guide
Date: Wed, 11 Oct 2006 11:31:30 -0400
From: "Haresign Lincoln" <[email-masked]>
To: <[email-masked]>, "Barry Nagelberg" <[email-masked]>
Cc: [email-masked]

Brian,

I certainly don't think we should strike it since it has a valid use for
some applications.  We are successfully using this mechanism for a
number of different applications and it works perfectly for it's
intended use.  It is part of an already agreed upon RFC.  

I believe that the TID/DLR is associated with an RC and not a point
code.

I think the TID/DLR mechanism should only be used for applications that
are working with DLRs or TIDs.  If that is not the type of application,
don't use it.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 11:22 AM
To: Barry Nagelberg
Cc: [email-masked]
Subject: Re: [Sigtran] SUA implementor's guide

Barry,

Yes that went some ways; however, it does not address the conflict
between Traffic Mode Type and DRN/TID label.  It seems that when DRN/TID
label is used, that the traffic mode for the AS is somehow overridden by
the label.  Now, while traffic modes are well defined as to how traffic
is distributed over the available ASPs, and what to do when an ASP
fails, the same is not true for DRN/TID labels.

To get this clear, one needs to modify ASP Up, ASP Down, ASP Active, ASP
Inactive, Notify and even Registration procedures.

Also, the current document is unclear as to how to handle messages with
no DLR and no TID.

The list goes on.

Changes necessary to get the SUA label mechanism working in a proper
fashion requires changes to the RFC that are likely outside the scope of
the IG, which should really just be Errata.

--brian

Barry Nagelberg wrote:                        (Wed, 11 Oct 2006
09:34:03)
> solutions regarding TID and DRM labels back in Feb-Apr of 2004, but 
> they weren't limited only to the ASP_ACK msg. I am equally puzzled as
to why the questions were put in the IG. I agree that the solutions
should have been inserted instead of the questions.
proposal for the IG on Apr 27, 2004:
> 
> <snip>
> Here is some updated suggested text for the SUA IG, regarding the 
> usage of TID labels.
> 
> labels, we're apparently moving towards the RFC stage, and companies 
> are moving ahead on SUA implementation. If we're not careful, we run 
> the risk of ending up with incompatible implementations.
> 
> In the ASPAC message, the ASP optionally includes a TID and/or DRN 
> Label Parameter for each AS. If more than one ASP in a given AS 
> includes a TID and/or DRN Label Parameter, then these ASPs must 
> specify a unique label at a fixed position in the TID or DRN 
> parameter. The same ASPAC message is sent to each SG used for
interworking with the SS7 network.
> 
> If an ASP does not include a TID and/or DRN Label Parameter in the 
> ASPAC message, then the SG MAY send a TCAP message with any TID or DRN

> to this ASP.
sent
> With regards to Barry's comments.  If I'm reading this correctly, 
> Barry seemed to be concerned that the ASP would send a TID range in 
> the ASP_ACK message and, if the SG did not support this optional 
> parameter, then there would be no way of handling this.  (Barry/Brian,

> please correct me if I have not interpretted your concern correctly).
> 
> "Unsupported Traffic Handling Mode".  This error is sent in response 
> to an ASP Active message with a Traffic Mode Type that is not
supported.

> seem to be saying that the ASP has no control over what TID is
assiechanism working in a proper
fashion requires changes to the RFC that are likely outside the scope of
the IG, which should really just be Errata.

--brian

Barry Nagelberg wrote:                        (Wed, 11 Oct 2006
09:34:03)
> solutions regarding TID and DRM labels back in Feb-Apr of 2004, but 
> they weren't limited only to the ASP_ACK msg. I am equally puzzled as
to why the questions were put in the IG. I agree that the solutions
should have been inserted instead of the questions.
proposal for the IG on Apr 27, 2004:
> 
> <snip>
> Here is some updated suggested text for the SUA IG, regarding the 
> usage of TID labels.
> 
> labels, we're apparently moving towards the RFC stage, and companies 
> are moving ahead on SUA implementation. If we're not careful, we run 
> the risk of ending up with incompatible implementations.
> 
> In the ASPAC message, the ASP optionally includes a TID and/or DRN 
> Label Parameter for each AS. If more than one ASP in a given AS 
> includes a TID and/or DRN Label Parameter, then these ASPs must 
> specify a unique label at a fixed position in the TID or DRN 
> parameter. The same ASPAC message is sent to each SG used for
interworking with the SS7 network.
> 
> If an ASP does not include a TID and/or DRN Label Parameter in the 
> ASPAC message, then the SG MAY send a TCAP message with any TID or DRN

> to this ASP.
sent
> With regards to Barry's comments.  If I'm reading this correctly, 
> Barry seemed to be concerned that the ASP would send a TID range in 
> the ASP_ACK message and, if the SG did not support this optional 
> parameter, then there would be no way of handling this.  (Barry/Brian,

> please correct me if I have not interpretted your concern correctly).
> 
> "Unsupported Traffic Handling Mode".  This error is sent in response 
> to an ASP Active message with a Traffic Mode Type that is not
supported.

> If that is the case, then I agree that this won't work.  But if the 
> ASP does have control (and I don't see why it wouldn't), then the ASP 
> can send TIDs that match the range that it has specified.  It should 
> send the same TID value in the ASP_ACTIVE message to all SGPs in the 
> SG that it is connecting to.
> 
> Regards,
> Lincoln
> 
> 
> 
> 2004: "SUA v16: TID and DRM labels".  In fact, see that thread for 
> more information in the issues.  And for the general agreement that 
> the mechanism must be fixed or removed.
> 

> > Why bother with a partial-sized mask at a specified "start" bit.  
> > Why not just specify a "full-sized" 32-bit (TID) or 23-bit (DRM)
mask?
parameter, then....
> > Cullen Jgned.
> If that is the case, then I agree that this won't work.  But if the 
> ASP does have control (and I don't see why it wouldn't), then the ASP 
> can send TIDs that match the range that it has specified.  It should 
> send the same TID value in the ASP_ACTIVE message to all SGPs in the 
> SG that it is connecting to.
> 
> Regards,
> Lincoln
> 
> 
> 
> 2004: "SUA v16: TID and DRM labels".  In fact, see that thread for 
> more information in the issues.  And for the general agreement that 
> the mechanism must be fixed or removed.
> 

> > Why bother with a partial-sized mask at a specified "start" bit.  
> > Why not just specify a "full-sized" 32-bit (TID) or 23-bit (DRM)
mask?
parameter, then....

> > document and not a guide to the uninitiated.  It assumes, as does 
> > the specification, that the reader has a very solid understanding of

> > the thing being transported.
> >
> > --brian
> >
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> >

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 10:30:28 -0600

Haresign,

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 11:31:30)
> intended use.

It cannot be used in a interoperable way as the specification is too
unclear about too many things.  You certainly can't be using it for
DRN, for which it is most broken.

Previous discussion on this list tend to make be believe that you are
only using TID Label for a highly restricted class of transactions and
even then in a non-interoperable way.

> It is part of an already agreed upon RFC.  

Check the archive, we didn't agree on it and wanted to change the
document before it became an RFC but were unable to.  That the TID/DRN
label mechanism was broken was the first documented item in the IG
and it even appeared there before a formal RFC number was assigned to
SUA.

You should have known from the start that TID/DRN Label was broken and
thought twice before implementing it so.

> I believe that the TID/DLR is associated with an RC and not a point

In SS7, both are assigned locally by a signalling point.  The assignment
for one signalling point might be the same as another.  So, for example,
a Terminating Transaction ID identifies a transaction at the destination
point code.  A Destination Local Reference identifies a connection at the
destination point code.

As an RC can cover multiple point code, your statement is incorrect.

> are working with DLRs or TIDs.  If that is not the type of application,

What is your point here?  I did not suggest that an application not using
TID/DLR Label should somehow use it.

Oh, and BTW, it has to be changed to DLR label and not DRN label.  DRN is
arbitrarily assigned by the SG (an assignment of which the other SG in an
associated STP pair cannot have knowledge of).

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 14:18:52 -0400

Bidulock,

With regards to TID, I think we are only talking the locally assigned
TID for continuation of a dialog.  For example, when a BEGIN arrives at
the SG, there is yet no locally assigned TID, so the message can be sent
to any ASP in the AS (if loadsharing is being used).  When a CONTINUE,
END, or ABORT arrives, it has a locally assigned TID as part of the
complete Transaction ID and the message can be routed to the correct ASP
that is handling the dialog.  In this way, we can receive two BEGINs
with the exact same "originating TID from two different point codes".
The originating TID is irrelevant.  The Destination TID (as is the DRN)
is used determine which application (which ASP) to route to.

I would assume the same logic would be applied for the reference number
when working with Class 2 messages.  The SG would want to examine the
locally assigned reference number, not the number assigned by a remote
switch.

We are not currently using the DRN Label.  We are successfully using the
TID label and don't find it broken at all for the applications in which
we are both initiating BEGINS/QUERYs and responding to them.  You keep
saying that things are broken or won't work.  I'm not sure why.  I
examined the references you gave in an earlier email and responded to
them.  If you have some specific points that you'd like to bring
forward, I believe that they can be resolved and/or clarified through
the IG.  If not, then the consensus seems to move forward with what we
have as it seems to work for everyone else.

And I'm not really sure what your last paragraph is referring to.  The
locally assigned reference number in a class 2 connection is like the
locally assigned transaction ID.  When the ASP sends the ASP_ACTIVE
message, it tells the SG what value (range) of TIDs/Reference Numbers
should be routed to that ASP.  If the ASP is connecting to multiple SGs,
it should provide the same parameter value.

Regards,
Lincoln Haresign

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 12:30 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] SUA implementor's guide

Haresign,

Haresign Lincoln wrote:                                           (Wed,
11 Oct 2006 11:31:30)
> Brian,
> 
> I certainly don't think we should strike it since it has a valid use 
> for some applications.  We are successfully using this mechanism for a

It cannot be used in a interoperable way as the specification is too
unclear about too many things.  You certainly can't be using it for DRN,
for which it is most broken.

Check the archive, we didn't agree on it and wanted to change the
document before it became an RFC but were unable to.  That the TID/DRN
label mechanism was broken was the first documented item in the IG and
it even appeared there before a formal RFC number was assigned to SUA.

In SS7, both are assigned locally by a signalling point.  The assignment
for one signalling point might be the same as another.  So, for example,
a Terminating Transaction ID identifies a transaction at the destination
point code.  A Destination Local Reference identifies a connection at
the destination point code.

> 
> I think the TID/DLR mechanism should only be used for applications 
> that are working with DLRs or TIDs.  If that is not the type of 
> application, don't use it.

What is your point here?  I did not suggest that an application not
using TID/DLR Label should somehow use it.

Oh, and BTW, it has to be changed to DLR label and not DRN label.  DRN
is arbitrarily assigned by the SG (an assignment of which the other SG
in an associated STP pair cannot have knowledge of).

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 12:38:42 -0600

Haresign,

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 14:18:52)
> is used determine which application (which ASP) to route to.

And for linked transactions?

> locally assigned reference number, not the number assigned by a remote

DRNs are assigned by the SG not the ASP.

> have as it seems to work for everyone else.

Lets start with one.  Transaction ID in ITU is a Universal Integer.
This is a number of arbitrary length.  It has no maximum.  Unlike ANSI,
it is not a number that has bits from 0 to 31.

Which bits is the SG to match and mask?

> it should provide the same parameter value.

When a connection is made through one SG, the other SG in an STP pair
has no knowledge of the DRN assigned by the ASP.

The DRN is a 32-bit field.  DLR is a 24-bit field.  The ASP is not
restricted in its assignment of DRNs and can assign any 32-bit value.
The SG must make a 24-bit value out of this.  How the SG does this is
not specified.  One SG can do it differently than another.

When an SG in a mated STP pair receives a DLR for a connection that
it is not privy to (it was made through the opposite SG), it has no
mapping of DLR to DRN and therefore has no mechanism to determine to
which ASP it should be passed.

I can go on.  Perhaps you can solve those two to being with.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 12:58:20 -0600

Lincoln,

Another issue:

RFC 3868 says:

4.7.3.1.  TCAP traffic

   ....

   If an ASP is not available, the SG may generate (X)UDTS "routing
   failure", if the return option is used.

But when I look at Q.713 (07/96) Section 3.13 Return Cause, my choices are:

   0 0 0 0 0 0 0 0   no translation for an address of such nature
   0 0 0 0 0 0 0 1   no translation for this specific address
   0 0 0 0 0 0 1 0   sybsystem congestion
   0 0 0 0 0 0 1 1   subsystem failure
   0 0 0 0 0 1 0 0   unequipped user
   0 0 0 0 0 1 0 1   MTP failure
   0 0 0 0 0 1 1 0   network congestion
   0 0 0 0 0 1 1 1   unqualified
   0 0 0 0 1 0 0 0   error in message transport (Note)
   0 0 0 0 1 0 0 1   error in local processing (Note)
   0 0 0 0 1 0 1 0   destination cannot perform reassembly (Note)
   0 0 0 0 1 0 1 1   SCCP failure
   0 0 0 0 1 1 0 0   hop counter violation
   0 0 0 0 1 1 0 1   segmentation not supported
   0 0 0 0 1 1 1 0   segmentation failure
   0 0 0 0 1 1 1 1   |
         to          |  spare
   1 1 1 1 1 1 1 1   |

   Note - Only applicable to XUDT(S) message.

I don't see "routing failure" on the list.

Which one did you use?

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 13:05:19 -0600

Lincoln,

Linked transactions.  An ASP generates a query to a remote SEP.  The remote
SEP generates a linked transaction back to the ASP.  The linked transaction
has the ASPs TID as a correlation ID, but because it begins a query, it has
no destination TID.

RFC 3868 says:

4.7.3.1.  TCAP traffic

   Messages not containing a destination (or "responding") TID, i.e.,
   Query, Begin, Unidirectional, are loadshared among the available
   ASPs.  Any scheme permitting a fair load distribution among the ASPs
   is allowed (e.g., round robin).

But that is not going to work as the linked transaction will likely go
to the wrong ASP.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 13:22:18 -0600

Lincoln,

The SG receives an ASP Active with a TM = Override and  TID Label.

What should be done?  Where does it say that in the RFC?

ASP Active TM = Broadcast and TID Label?

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 13:26:33 -0600

Lincoln,

Here is the DLR/DRN problem restated:

RFC 3868 says:

4.7.3.2.  SCCP Connection Oriented traffic

   Messages not containing a destination reference number (DRN), i.e., a
   Connection Request, MAY be loadshared among the available ASPs.  The
   load distribution mechanism is an implementation issue.  When a DRN
   is present, the SG extracts the label and selects the ASP that
   corresponds with it.  If an ASP is not available, the SG discards the
   message.

But messages arriving from the SS7 network do no have DRNs.  They have
DLRs.  There is no 1:1 mapping requirement between a DLR and a DRN.
Therefore, because no CO SCCP SS7 message has a DRN in it, I assume that
all messages can be loadshared and that DRN Label is completely ineffective.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 13:33:54 -0600

Lincoln,

RFC 3868 says:

   ...  If an ASP is not available, the SG discards the message.

SCCP does not discard connection-oriented messages, it sends an
ERR message with an Error Cause: particularly when the messae is
an Inativity Test message.  Discarding an Inactivity Test message
will break the SCCP protocol.

The choices for error cause from Q.713 (07/96) Section 3.14 are:

   0 0 0 0 0 0 0 0  Local Reference Number (LRN) mismatch - unassigned
                    destination LRN
   0 0 0 0 0 0 0 1  Local Reference Number (LRN) mismatch - inconsistent
                    source LRN
   0 0 0 0 0 0 1 0  pointcode mismatch
   0 0 0 0 0 0 1 1  service class mismatch
   0 0 0 0 0 1 0 0  unqualified
   0 0 0 0 0 1 0 1  |
          to        |  spare
   1 1 1 1 1 1 1 1  |

The first one looks like a good choice; however, is an very bad idea
to go telling an SG what it is supposed to do with SS7 messages.  It
is the responsibility of the SG to maintain a correctly functioning
SS7 protocol towards the SS7 network.

Do you thing the message should be discarded?

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 13:38:27 -0600

Lincoln,

RFC 3868 says:

4.1.1.  Receipt of Primitives from SCCP

   The SUA message distribution function determines the Application
   Server (AS) based on comparing the information in the N-UNITDATA
   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.  ...

This statement is in conflict with the use of TID and DRN label.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 13:42:53 -0600

Lincoln,

RFC 3868 says:

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

These last to sentences are in conflict with the use of DRN/TID label.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 13:46:44 -0600

Lincoln,

RFC 3868 says:

   ...

   When there is no Routing Key match, or only a partial match, for an
   incoming SS7 message, a default treatment MAY 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 message and provide a notification to Layer Management in an
   M-ERROR indication primitive.  The treatment of unallocated traffic
   is implementation dependent.

4.7.3.1.  TCAP traffic

   ...

   ...

   If an ASP is not available, the SG discards the message.

The application of DRN/TID label is inconsistent with the concept of a
"default ASP" and the principle that the SG implementation is in the
best position to decide the treatment of unallocated traffic.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 13:50:09 -0600

Lincoln,

RFC 3868 says:

4.3.4.3.  ASP Active Procedures

   ...

   In the case of a Loadshare mode AS, reception of an ASP Active
   message at an SGP or IPSP causes 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
   loadsharing traffic within an AS to all the active ASPs is
   implementation dependent.  The algorithm could, for example, be round
   robin or based on information in the Data message (e.g., the SLS or
   SSN).

This paragraph is inconsistent with the application of DRN/TID label.
It tells me that the algorithm for loadsharing is implementation dependent.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 13:55:55 -0600

Lincoln,

RFC 3868 says:

   ...

   All ASPs within a load-sharing mode AS must be able to process any
   Data message received for the AS, to accommodate any potential fail-
   over or rebalancing of the offered load.

Application of DRN/TID labels is inconsistent with the above requirement
for ASP in a loadshared AS.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 15:57:34 -0400

Brian,

I don't believe that the SUA spec handles this at all.  We have designed
a proprietary mechansim that works with Correlation Ids within the
message.  

I think the TID routing mechansim (like other options in the spec) are
designed for certain mechanisms.  More advanced features (like linked
transactions via a correlation ID or Billing ID) require either a
proprietary mechanism or a new RFC.

However for applications that don't have linked transactions, the TID
routing works quite well.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 3:05 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: TID Label Issues - Issue #2

Lincoln,

Linked transactions.  An ASP generates a query to a remote SEP.  The
remote SEP generates a linked transaction back to the ASP.  The linked
transaction has the ASPs TID as a correlation ID, but because it begins
a query, it has no destination TID.

RFC 3868 says:

4.7.3.1.  TCAP traffic

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 13:58:36 -0600

Lincoln,

RFC 3868 says:

4.3.4.4.  ASP Inactive Procedures

   ...

   In the case of a Loadshare mode AS, the SGP moves the ASP to the
   ASP-INACTIVE state and the AS traffic is reallocated across the
   remaining ASPs in the state ASP-ACTIVE, as per the loadsharing
   algorithm currently used within the AS.  A Notify message
   ("Insufficient ASP resources active in AS") MAY be sent to all
   inactive ASPs, if required.  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.

Application of DRN/TID label is inconsistent with this procedure for
loadshare AS.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 15:59:08 -0400

Brian,

I think this would be a poor use of the TID label.  The TID is mechanism
is used to share transaction processing across many ASPs.  It seemed
quite obvious to me, but if you believe we should clarify this in the
IG, that would be fine.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 3:22 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: TID Label Issues - Issue #3

Lincoln,

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:01:41 -0400

Brian,

I would assume that anyone who is implementing the DRN routing mechanism
will use a mechanism that assures a one to one routing between DRN and
DLR.  Otherwise the mechanism would be useless.  This seemed obvious to
me.  But if you feel that we need to clarify this in the IG, I'd be
happy to specify this.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 3:27 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: DRN Label Issues -- Issue #1

Lincoln,

RFC 3868 says:

But messages arriving from the SS7 network do no have DRNs.  They have
DLRs.  There is no 1:1 mapping requirement between a DLR and a DRN.
Therefore, because no CO SCCP SS7 message has a DRN in it, I assume that
all messages can be loadshared and that DRN Label is completely
ineffective.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:02:58 -0400

Brian,

I would think we would send with an Error Code of Zero.  I agree with
you that it is the best choice.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 3:34 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: DRN Label Issues - Issue #2

Lincoln,

RFC 3868 says:

SCCP does not discard connection-oriented messages, it sends an ERR
message with an Error Cause: particularly when the messae is an
Inativity Test message.  Discarding an Inactivity Test message will
break the SCCP protocol.

The first one looks like a good choice; however, is an very bad idea to
go telling an SG what it is supposed to do with SS7 messages.  It is the
responsibility of the SG to maintain a correctly functioning
SS7 protocol towards the SS7 network.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:04:06 -0400

Brian,

I guess I don't see the conflict.

Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 3:38 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: TID and DRN Label Issues - Issue #1

Lincoln,

RFC 3868 says:

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:04:31 -0600

Lincoln,

RFC 3868 says:

4.3.4.5.  Notify Procedures

   A Notify message reflecting a change in the AS state MUST be sent to
   all ASPs in the AS, except those in the ASP-DOWN state, with
   appropriate Status Information and any ASP Identifier of the failed
   ASP.  At the ASP, Layer Management is informed with an M-NOTIFY
   indication primitive.  The Notify message must be sent whether the AS
   state change was a result of an ASP failure or reception of an ASP
   State management (ASPSM) / ASP Traffic Management (ASPTM) message.
   In the second case, the Notify message MUST be sent after any ASP
   State or Traffic Management related acknowledgement messages  (e.g.,
   ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack).

Application of DRN/TID label is inconsistent with the adopted
notification procedures.  The SG always notifies the ASPs with
a Notify message when traffic is pending or in danger of being
discarded.

DRN/TID has no notification procedure when a ASP Inactive is
received for a necessary label range, nor when an unsolicited
ASP Inactive Ack is sent.

(LOADSEL has a notification procedure BTW.)

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:06:36 -0600

Lincoln,

The issue is that it is already specified in the RFC as (X)UDTS "routing
failure".

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 15:54:06)
> Brian,
> 
> Good question.
> 
> In this case, I don't believe that "return on error" applies.
> Everything at the SCCP level is valid at this point and we are now doing
> TCAP processing.  There are really two options (and we have implemented
> them both).
> 
> 1) The SG can drop the message.  
> 
> 2) The SG can send and ABORT.
> 
> I would leave this issue as implementation specific.  However if you are
> interested in specifying this in the IG, I'd be happy to work on the
> wording.
> 
> Regards,
> Lincoln
> 
> 
> Sent: Wednesday, October 11, 2006 2:58 PM
> To: Haresign Lincoln
> Subject: TID Label Issues - Issue #1
> 
> Lincoln,
> 
> Another issue:
> 
> RFC 3868 says:
> 
> 4.7.3.1.  TCAP traffic
> 
>    ....
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:11:23 -0600

Haresign,

Haresign Lincoln wrote:                      (Wed, 11 Oct 2006 15:57:34)
> a proprietary mechansim that works with Correlation Ids within the

Not interoperable.

> routing works quite well.

My point, the mechanism is broken and does not work for any but
a restricted range of TID applications, and only then it seems
when proprietary deviations from the specification are in place.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:11:37 -0400

Brian,

I don't see a major issue here that prevents the use of TID routing.

Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:07 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: TID Label Issues - Issue #1

Lincoln,

--brian

11 Oct 2006 15:54:06)
> Everything at the SCCP level is valid at this point and we are now 
> doing TCAP processing.  There are really two options (and we have 
> implemented them both).
> 
> I would leave this issue as implementation specific.  However if you 
> are interested in specifying this in the IG, I'd be happy to work on 
> the wording.
> 
> Regards,
> Lincoln
> 
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:12:50 -0600

Lincoln,

My point is the spec does not say that DRN/TID label cannot be used
in conjunction with the other traffic modes, nor what the proper
error response is should a DRN/TID label arrive with one.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 15:59:08)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:15:29 -0600

Haresign,

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:01:41)
> DLR.

To ensure interoperability that needs to be made a requirement.

> Otherwise the mechanism would be useless.

And it is useless without the requirement.

> This seemed obvious to me.  But if you feel that we need to clarify
> this in the IG, I'd be happy to specify this.

Yes, it is obviously broken.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:16:39 -0600

Lincoln,

But that is not what the RFC says, not should it say anthing
that places a requirement on an SS7 implementation toward
the SS7 network.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:02:58)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:16:29 -0400

Bidulock,

There are many options in the SUA spec that are designed for a specific
solution in mind.  In some applications, we use override, some
loadshare, some route on GT, some route on TID.  Again, this is a
solution for a specific set of application and it works for those.  I
didn't say that TID should be used for everything.  I'm not going to use
DRN routing for Class 1 messages obviously.  And I'm not going to solve
use just TID routing to solve linked transactions.  

Since there is no RFC to solve linked transactions, right now we must
solve them on our own.  And we have.  We used TID routing with a
proprietary mechanism that ensure that the messages arrive at the
correct ASP.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:11 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: TID Label Issues - Issue #2

Haresign,

> Brian,
> 
> I don't believe that the SUA spec handles this at all.  We have 
> designed a proprietary mechansim that works with Correlation Ids 
> within the message.

Not interoperable.

> routing works quite well.

My point, the mechanism is broken and does not work for any but a
restricted range of TID applications, and only then it seems when
proprietary deviations from the specification are in place.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:17:53 -0600

Lincoln,

>    ...                              If more than one ASP is in the ASP-

There is no mention of applying DRN/TID label in the selection if DRN/TID
labels are in effect.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:04:06)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:18:47 -0600

Lincoln,

It is an issue that requres a modification to the RFC.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:11:37)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:21:34 -0600

Lincoln,

Perhaps you could contribute your procedure to solve the issue.

Otherwise, it needs to be state that TID labels are inapplicable
and must not be applied where linked transactions are involved.

--brian

Haresign Lincoln wrote:                      (Wed, 11 Oct 2006 16:16:29)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 15:54:06 -0400

Brian,

Good question.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 2:58 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: TID Label Issues - Issue #1

Lincoln,

Another issue:

RFC 3868 says:

4.7.3.1.  TCAP traffic

   ....

But when I look at Q.713 (07/96) Section 3.13 Return Cause, my choices
are:

Which one did you use?

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:38:57 -0600

Lincoln,

TID and DRN routing is not implementation dependent.  It is specified,
however poorly, in the RFC.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:28:42)
> Brian,
> 
> Yes, I agree.  The algorithm is implementation dependent.  If based upon
> all the registration parameters and (if used) TID or DRN routing.
> 
> Regards,
> Lincoln 
> 
> Sent: Wednesday, October 11, 2006 3:50 PM
> To: Haresign Lincoln
> Subject: [Sigtran] DRN and TID Issues - Issue #4
> 
> Lincoln,
> 
> RFC 3868 says:
> 

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:39:10 -0400

Brian,

Or, we can specify in the IG that if a message is received for an
unrecognized TID, the SG can either discard or send an ABORT in
response.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:19 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: TID Label Issues - Issue #1

Lincoln,

--brian

11 Oct 2006 16:11:37)
> The issue is that it is already specified in the RFC as (X)UDTS 
> "routing failure".
> 
> --brian
> 
> Haresign Lincoln wrote:
(Wed,
> 11 Oct 2006 15:54:06)
> > Brian,
> > 
> > Good question.
> > 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:37:13 -0600

Lincoln,

Why should it need to be a new ASP?  We don't have that requirement
currently.  Why not an existing ASP?  How does one of the existing
ASPs pick up the traffic of a failed ASP or one that is taken out
of service?

How are you going to upgrade a loadshare AS that has 2 ASPs?

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:26:08)
> Brian,
> 
> All new dialogs will be loadshared, obviously existing dialogs can not
> be routed unless another ASP becomes Active and takes over that range of
> TIDs.
> 
> Lincoln
> 
> Sent: Wednesday, October 11, 2006 3:59 PM
> To: Haresign Lincoln; Barry Nagelberg; [email-masked]
> Subject: DRN and TID Label Issues - Issue #7
> 
> Lincoln,
> 
> RFC 3868 says:
> 

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:34:42 -0400

Brian,

I agree.  Perhaps the IG should be more specific in this area.  I'll try
to come up with some wording.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:13 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: TID Label Issues - Issue #3

Lincoln,

My point is the spec does not say that DRN/TID label cannot be used in
conjunction with the other traffic modes, nor what the proper error
response is should a DRN/TID label arrive with one.

--brian

11 Oct 2006 15:59:08)
> Brian,
> 
> I think this would be a poor use of the TID label.  The TID is 
> mechanism is used to share transaction processing across many ASPs.  
> It seemed quite obvious to me, but if you believe we should clarify 
> this in the IG, that would be fine.
> 
> Regards,
> Lincoln
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:34:30 -0600

Lincoln,

And when an unsolicited ASP Inactive Ack is sent?

And when an ASP Inactive is received?

Both of these events will trigger "Insufficient ASPs" notification
in the case of Loadshare (which DRN/TID label presumably modifies).

Also when ASP failure occurs, the active ASPs have no mechanism to
pick up the traffic.  This is because their lables must start
and end at the same range and have a unique label.  They have no
way to pick up the traffic of a failed ASP that was active with
a DRN/TID label.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:24:36)
> Brian,
> 
> If an ASP dies, other ASP will be notified with a Notify message.
> That's exactly the scenario here.  An ASP sent a message with a
> particular local TID.  If it dies (so the response can not be routed), a
> Notify is sent when the ASP dies.
> 
> Regards,
> Lincoln
> 
> 
> Sent: Wednesday, October 11, 2006 4:05 PM
> To: Haresign Lincoln
> Subject: [Sigtran] DRN and TID Label Issues - Issue #8
> 
> Lincoln,
> 
> RFC 3868 says:
> 
> notification procedures.  The SG always notifies the ASPs with a Notify
> message when traffic is pending or in danger of being discarded.
> 
> DRN/TID has no notification procedure when a ASP Inactive is received
> for a necessary label range, nor when an unsolicited ASP Inactive Ack is
> sent.
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:40:03 -0600

Lincoln,

But as the RFC stands, it cannot be applied to DRN/TID labels and
is a defect of the DRN/TID label mechanism requiring a change to
the RFC.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:30:29)
> Brian,
> 
> I think that you could implement a default routing concept.  This is all
> "implementation dependent" and "MAY" be applied.  You could have an ASP
> within the AS that is designated to receive all TCAP messages if you
> can't route the TID/DRN.  I don't see the problem here.
> 
> Regards,
> Lincoln
> 
> Sent: Wednesday, October 11, 2006 3:47 PM
> To: Haresign Lincoln
> Subject: DRN and TID Label Issues -- Issue #3
> 
> Lincoln,
> 
> RFC 3868 says:
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:31:09 -0600

Lincoln,

I can continue, but IMO the following is clear:

 - DRN/TID labels was stuffed into the SUAv16 at the last moment
   without any WG consideration.

 - The mechanism did not receive sufficient review.

 - The text does not bear up to the least bit of scrutiny.

 - Those implementing a like mechanism have implemented it the
   way that they "think" it should work rather than the way that
   it is specified.

 - Resulting implementations are not interoperable.

As a result, IMO, it needs to be fixed or struck.  Fixed, to me,
means someone taking the time to change text across each of the
procedural sections and subject it to sufficient WG scrutinty
that it will not represent a big defect in the next RFC.

Striking, to me, could consist of a simple statement that the
DRN/TID mechanism SHOULD NOT be used, the "SHOULD NOT" justified
by the lack of interoperable solutions based on the current text.

If its fixed, who is going to do the work?  If its struck, it is
a one line change in the IG and deletion of several IG sections.

Realize that it will be over two years before the IG will make
it to an RFC.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:27:22 -0400

Brian,

I don't see any problem with the wording below.

Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 3:54 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: DRN and TID Label Issues - Issue #5

Lincoln,

RFC 3868 says:

   ...

   An SGP or IPSP, upon reception of an ASP Active message for the first
   ASP in a Loadshare 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).

4.7.3.1.  TCAP traffic

   Messages not containing a destination reference number (DRN), i.e., a
   Connection Request, MAY be loadshared among the available ASPs.

Application of the concept of "n" and DRN/TID labels is inconsistent.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 13:54:05 -0600

Lincoln,

RFC 3868 says:

   ...

4.7.3.1.  TCAP traffic

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:41:11 -0600

Lincoln,

The last two sentences speak to Loadshare as well.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:31:48)
> Brian,
> 
> Again, I don't believe Broadcast mode is relevant to TID routing.  It
> seemed obvious to me.  If you feel it is necessary to specify this in
> the IG, please indicate and I'm sure we can all agree on some wording.
> 
> Regards,
> Lincoln 
> 
> Sent: Wednesday, October 11, 2006 3:43 PM
> To: Haresign Lincoln
> Subject: DRN and TID Label Issues - Issue #2
> 
> Lincoln,
> 
> RFC 3868 says:
> 

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:36:06 -0400

Brian,

OK, then we can put something in the IG.

With regards to "towards the SS7 network", there are plenty of places in
the RFC that say what an SG should do towards the SS7 network.  Perhaps
I'm not understanding your point.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:17 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: [Sigtran] Re: DRN Label Issues - Issue #2

Lincoln,

But that is not what the RFC says, not should it say anthing that places
a requirement on an SS7 implementation toward the SS7 network.

--brian

11 Oct 2006 16:02:58)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:41:31 -0400

Brian,

Our proprietary solution rests on a layer above SUA and it not really
relevant.  I agree that TID routing will not solve problems related to
linked transactions and they need to be solve in another way.  There are
many problems that can occur with M3UA users and SUA users that are not
solved by the existing specifications.  That doesn't mean that we should
not use the specifications where appropriate.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:22 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: TID Label Issues - Issue #2

Lincoln,

Otherwise, it needs to be state that TID labels are inapplicable and
must not be applied where linked transactions are involved.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:24:36 -0400

Brian,

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:05 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: [Sigtran] DRN and TID Label Issues - Issue #8

Lincoln,

RFC 3868 says:

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:26:08 -0400

Brian,

Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 3:59 PM
To: Haresign Lincoln; Barry Nagelberg; [email-masked]
Subject: DRN and TID Label Issues - Issue #7

Lincoln,

RFC 3868 says:

   ...

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:31:48 -0400

Brian,

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 3:43 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: DRN and TID Label Issues - Issue #2

Lincoln,

RFC 3868 says:

   ...

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:30:29 -0400

Brian,

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 3:47 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: DRN and TID Label Issues -- Issue #3

Lincoln,

RFC 3868 says:

   ...

4.7.3.1.  TCAP traffic

   ...

   ...

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:28:42 -0400

Brian,

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 3:50 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: [Sigtran] DRN and TID Issues - Issue #4

Lincoln,

RFC 3868 says:

   ...

This paragraph is inconsistent with the application of DRN/TID label.
It tells me that the algorithm for loadsharing is implementation
dependent.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:43:32 -0600

Lincoln,

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:36:06)
> I'm not understanding your point.

There are no other places in the RFC that say what the implementation
must do towards the SS7 network.  I assure you, I removed them all in
last call.  There is mention of what the SG MAY do, but not what it
must except in the case of DRN/TID label (which didn't really go through
a last call).

If you see any place in the RFC that says what an SG must do toward
the SS7 network, please point it out, because it needs to go in the
IG too.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:44:09 -0400

Brian,

Since it is a feature that does solve a problem for some set of
applications (not all), I believe it should stay.  As far as I can tell
from the other people that did respond, they have no problem with it
either and seem to have solutions for all the problems that you are
pointing out.  I know that we do.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:31 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: DRN and TID Label Issues

Lincoln,

As a result, IMO, it needs to be fixed or struck.  Fixed, to me, means
someone taking the time to change text across each of the procedural
sections and subject it to sufficient WG scrutinty that it will not
represent a big defect in the next RFC.

Striking, to me, could consist of a simple statement that the DRN/TID
mechanism SHOULD NOT be used, the "SHOULD NOT" justified by the lack of
interoperable solutions based on the current text.

If its fixed, who is going to do the work?  If its struck, it is a one
line change in the IG and deletion of several IG sections.

Realize that it will be over two years before the IG will make it to an
RFC.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:45:32 -0600

Lincoln,

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:39:10)
> unrecognized TID, the SG can either discard or send an ABORT in

MAY or MAY NOT.  It is useless to place statements like that in
the body of the specification.  Say that in the Appendix A under
the non-normative TID/DRN discussion.  That is the place to say
that the SG could send an Abort or could return error or could
do what it wants.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:45:39 -0400

Brian,

Either another ASP will have to take over the existing dialogs, or they
will be dropped/aborted.

Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:35 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] DRN and TID Label Issues - Issue #8

Lincoln,

Both of these events will trigger "Insufficient ASPs" notification in
the case of Loadshare (which DRN/TID label presumably modifies).

Also when ASP failure occurs, the active ASPs have no mechanism to pick
up the traffic.  This is because their lables must start and end at the
same range and have a unique label.  They have no way to pick up the
traffic of a failed ASP that was active with a DRN/TID label.

--brian

11 Oct 2006 16:24:36)
> particular local TID.  If it dies (so the response can not be routed),

> a Notify is sent when the ASP dies.
> 
> Regards,
> Lincoln
> 
> 
> notification procedures.  The SG always notifies the ASPs with a 
> Notify message when traffic is pending or in danger of being
discarded.
> for a necessary label range, nor when an unsolicited ASP Inactive Ack 
> is sent.
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:46:45 -0600

Lincoln,

But it needs to be stated where it is known that the mechanisms
are not appropriate or cannot hope to acheive interoperability.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:41:31)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:46:53 -0400

Brian,

I didn't say MUST, I said SHOULD.  You can change that to MAY.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:44 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] Re: DRN Label Issues - Issue #2

Lincoln,

11 Oct 2006 16:36:06)
> With regards to "towards the SS7 network", there are plenty of places 
> in the RFC that say what an SG should do towards the SS7 network.  
> Perhaps I'm not understanding your point.
> 

There are no other places in the RFC that say what the implementation
must do towards the SS7 network.  I assure you, I removed them all in
last call.  There is mention of what the SG MAY do, but not what it must
except in the case of DRN/TID label (which didn't really go through a
last call).

If you see any place in the RFC that says what an SG must do toward the
SS7 network, please point it out, because it needs to go in the IG too.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:47:37 -0600

Lincoln,

Then please contribute your solutions.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:47:56 -0400

Brian,

When dealing with loadshare, the ASPs are in control of the TID values.
I don't see the issue.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:41 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: DRN and TID Label Issues - Issue #2

Lincoln,

--brian

11 Oct 2006 16:31:48)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:49:19 -0400

Brian,

Again, it seems obvious to me that TID routing will not work when using
linked TIDs.  I don't believe it is necessary to specify this as it is
not necessary to specify many obvious things.

Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:47 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: [Sigtran] Re: TID Label Issues - Issue #2

Lincoln,

But it needs to be stated where it is known that the mechanisms are not
appropriate or cannot hope to acheive interoperability.

--brian

11 Oct 2006 16:41:31)

> linked transactions and they need to be solve in another way.  There 
> are many problems that can occur with M3UA users and SUA users that 
> are not solved by the existing specifications.  That doesn't mean that

> we should not use the specifications where appropriate.
> 
> Regards,
> Lincoln
> 
> > Since there is no RFC to solve linked transactions, right now we 
> > must solve them on our own.  And we have.  We used TID routing with 
> > a proprietary mechanism that ensure that the messages arrive at the 
> > correct ASP.
> > 
> 
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:49:35 -0600

Lincoln,

One of the active ASPs cannot take over the existing dialogs
because it not possible to ask the SG to route its dialogs
to it.  Each label is so partitioned and orthogonoal that one
ASP cannot activate for two ranges.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:45:39)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:51:07 -0600

Lincoln,

No you can't say what an SG SHOULD do toward the SS7 network
either.  Please point out any of those.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:46:53)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:52:38 -0400

Brian,

I agree.  Another Non-Active ASP would have to become Active to take
over those dialogs.

Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:50 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] DRN and TID Label Issues - Issue #8

Lincoln,

One of the active ASPs cannot take over the existing dialogs because it
not possible to ask the SG to route its dialogs to it.  Each label is so
partitioned and orthogonoal that one ASP cannot activate for two ranges.

--brian

11 Oct 2006 16:45:39)
> Brian,
> 
> Either another ASP will have to take over the existing dialogs, or 
> they will be dropped/aborted.
> 
> Lincoln
> 
> pick up the traffic.  This is because their lables must start and end 
> at the same range and have a unique label.  They have no way to pick 
> up the traffic of a failed ASP that was active with a DRN/TID label.
> 
> --brian
> 
> Haresign Lincoln wrote:
(Wed,
> 11 Oct 2006 16:24:36)
> > Brian,
> > 
> >    indication primitive.  The Notify message must be sent whether 
> > the
> AS
> > received for a necessary label range, nor when an unsolicited ASP 
> > Inactive Ack is sent.
> > 

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:54:00 -0400

Brian,

Sorry, but I lost the thread.  I'm not sure what solutions you are
referring to here.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:48 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: [Sigtran] Re: DRN and TID Label Issues

Lincoln,

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 16:54:42 -0400

Brian,

You can change that to MAY.

Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:51 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] Re: DRN Label Issues - Issue #2

Lincoln,

No you can't say what an SG SHOULD do toward the SS7 network either.
Please point out any of those.

--brian

11 Oct 2006 16:46:53)
> > With regards to "towards the SS7 network", there are plenty of 
> > places in the RFC that say what an SG should do towards the SS7
network.
> must except in the case of DRN/TID label (which didn't really go 
> through a last call).
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:55:50 -0600

Lincoln,

The two sentences state that the implementation must loadshare carefully
and according to its knowledge of the degree of state coordination between
ASPs in the AS.  DRN/TID label conflicts with that statement in that
is proscribed a specific method regardless of the knowledge that the
SG implementation has of the degree of state sharing between ASPs.

The sentence needs to be modified to note that this applies to loadshare
AS that do not have DRN/TID labels.  When DRN/TID labels are applied, the
SG must follow the proscribed procedures.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:47:56)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 14:59:09 -0600

Lincoln,

Yes is it important to state what obviously will not work.  When something
cannot work in a interoperable and it is well known that it cannot work
in an interoperable way, even obviously cannot work in an interoperable
way, way we counter-recommend it in the IETF.

For example, it is obvious that one should ignore the value of padding bits
when receiving them and that one should set them to a known value, say zero,
when sending them (in case they are later defined).  But we state it as a
requirement with big MUST letters anyway.

Where TID labels will not work in an interoperable fashion it deserves at
least the same level of care we take for padding bits.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:49:19)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 15:00:01 -0600

Lincoln,

It is a defect in the specification that needs to be fixed.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:52:38)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 15:00:31 -0600

Haresign,

Your proprietary ones.

--brian

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 16:54:00)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 15:01:22 -0600

Lincoln,

> > > places in the RFC that say what an SG should do towards the SS7 network.

Please point them out.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 17:02:48 -0400

Brian,

The default routing mechanism is not very well specified in the RFC.  It
basically states that it is implemenation specific.  Should we also
throw out that feature because it is not well described.  

I think that all the problems with TID are solvable (as we have solved
them) when working with a specific class of applications.

With regards to the DRN issue, since we have not implemented the DRN
mechanism, I have not studied it extensively to find out if there are
any holes.  

Personally, the only issue I see is that the IG/RFC should specify that
the range for the DRN is three bytes.  Otherwise connection oriented
would not work.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:40 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: DRN and TID Label Issues -- Issue #3

Lincoln,

But as the RFC stands, it cannot be applied to DRN/TID labels and is a
defect of the DRN/TID label mechanism requiring a change to the RFC.

--brian

11 Oct 2006 16:30:29)
> Brian,
> 
> I think that you could implement a default routing concept.  This is 
> all "implementation dependent" and "MAY" be applied.  You could have 
> an ASP within the AS that is designated to receive all TCAP messages 
> if you can't route the TID/DRN.  I don't see the problem here.
> 
> Regards,
> Lincoln
> 

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 17:07:16 -0400

Brian,

There are two options:

1) One AS/ASP is specified to receive messages that don't fit the the
existing routing criteria.  This is already discussed in the RFC.

2) A new non-ACTIVE ASP becomes ACTIVE.

How you pick up traffic for failed ASPs is implementation dependent.  I
can think of a number of solutions:

- dialog info saved in a redundant database
- information exchanged between ASPs

This is outside the scope of this discussion, but the same problem
exists in general for any solution whether using TID routing or not.

Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:37 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: DRN and TID Label Issues - Issue #7

Lincoln,

Why should it need to be a new ASP?  We don't have that requirement
currently.  Why not an existing ASP?  How does one of the existing ASPs
pick up the traffic of a failed ASP or one that is taken out of service?

--brian

11 Oct 2006 16:26:08)

> be routed unless another ASP becomes Active and takes over that range 
> of TIDs.
> 
> Lincoln
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 15:07:43 -0600

Lincoln,

Haresign Lincoln wrote:                                                                                                                                                    (Wed, 11 Oct 2006 17:02:48)
> throw out that feature because it is not well described.  

Default ASP is a purely local matter (local to the SG and the SS7
network).  As such it does not have to be specific to permit
interoperability.  When requirements are placed on sending messages
to another implementation such as in the case of DRN/TID label, where
vagueness causes lack of interoperability, the issue appears.

> them) when working with a specific class of applications.

But in a proprietary way, it seems.

> the range for the DRN is three bytes.  Otherwise connection oriented

It must also specify a stateless mapping between DRN and DLR.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 17:08:46 -0400

Brian,

I agree, when DRN/TID routing is used, it is an extra level of routing.
Again, it seems obvious.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 4:56 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: DRN and TID Label Issues - Issue #2

Lincoln,

The two sentences state that the implementation must loadshare carefully
and according to its knowledge of the degree of state coordination
between ASPs in the AS.  DRN/TID label conflicts with that statement in
that is proscribed a specific method regardless of the knowledge that
the SG implementation has of the degree of state sharing between ASPs.

The sentence needs to be modified to note that this applies to loadshare
AS that do not have DRN/TID labels.  When DRN/TID labels are applied,
the SG must follow the proscribed procedures.

--brian

11 Oct 2006 16:47:56)
> > Again, I don't believe Broadcast mode is relevant to TID routing.  
> > It seemed obvious to me.  If you feel it is necessary to specify 
> > this in the IG, please indicate and I'm sure we can all agree on
some wording.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 15:10:26 -0600

Haresign,

Haresign Lincoln wrote:                                                                                                                                                    (Wed, 11 Oct 2006 17:07:16)
> exists in general for any solution whether using TID routing or not.

Not it does not.  In a loadshare AS, traffic is redistributed over
the remaining active ASP, automatically by specification.  This TID/DRN
label AS _is_ a loadshare AS, but traffic is not redistibuted under
failure.

The LOADSEL draft solves this problem by allowing the ASP to both register
and activate for multiple load selections.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 15:11:29 -0600

Lincoln,

But, because it affects interoperability, must be stated as a requirement;
requiring a change to the RFC.

--brian

Haresign Lincoln wrote:                      (Wed, 11 Oct 2006 17:08:46)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 17:12:06 -0400

Brian,

If you are referring to our proprietary mechansim for routing linked
dialog back to the correct ASP, I don't believe it is relevant.  It is
an implementation unique feature that we have designed to handle this
scenario and not relevant to this discussion.  

I agree with you that TID routing will not solve linked dialogs.  There
are many problems that the SUA spec does not explicity solve.  That
leaves room for companies to be innovative.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 5:01 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] Re: DRN and TID Label Issues

Haresign,

Your proprietary ones.

--brian

11 Oct 2006 16:54:00)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 15:15:21 -0600

Lincoln,

Then we must strike TID for linked dialogs.  Words to the effect:

  The TID Label mechanism MUST NOT be used where linked dialogues
  are involved.

--brian

Haresign Lincoln wrote:                   (Wed, 11 Oct 2006 17:12:06)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 17:15:45 -0400

Brian,

With the exception of linked dialogs (which I agree is not solved by TID
routing alone), nothing we are doing is proprietary with the exception
of sending ABORTs or discarding when unable to route.  This obviously
only applies to ongoing dialogs and is a temporary situation when an ASP
dies.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 5:08 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: DRN and TID Label Issues -- Issue #3

Lincoln,

Haresign Lincoln wrote:
(Wed, 11 Oct 2006 17:02:48)
> Brian,
> 
> The default routing mechanism is not very well specified in the RFC.  
> It basically states that it is implemenation specific.  Should we also

Default ASP is a purely local matter (local to the SG and the SS7
network).  As such it does not have to be specific to permit
interoperability.  When requirements are placed on sending messages to
another implementation such as in the case of DRN/TID label, where
vagueness causes lack of interoperability, the issue appears.

> Personally, the only issue I see is that the IG/RFC should specify 
> that the range for the DRN is three bytes.  Otherwise connection 
> oriented would not work.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 17:17:56 -0400

Brian,

On the SG, I have already described what I believe is the correct
behavior.

On the AS side, there are a number of answers:

- another ASP takes over.
- a default AS is available. 

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 5:10 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: DRN and TID Label Issues - Issue #7

Haresign,

Haresign Lincoln wrote:
(Wed, 11 Oct 2006 17:07:16)
> How you pick up traffic for failed ASPs is implementation dependent.  
> I can think of a number of solutions:
> 

Not it does not.  In a loadshare AS, traffic is redistributed over the
remaining active ASP, automatically by specification.  This TID/DRN
label AS _is_ a loadshare AS, but traffic is not redistibuted under
failure.

The LOADSEL draft solves this problem by allowing the ASP to both
register and activate for multiple load selections.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 15:18:29 -0600

Lincoln,

Haresign Lincoln wrote:                                                                                                                                                    (Wed, 11 Oct 2006 17:15:45)
> only applies to ongoing dialogs and is a temporary situation when an ASP

A temporary situation that, when 2 ASP are involved, is termed a "System
Failure", requiring an FCC outage report.  It would be best to use
LOADSEL's ability to pick up for the failed ASP.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 15:19:50 -0600

Lincoln,

Yes, TID label as specified impairs a loadshare AS's ability
to recover from an outage.

--brian

Haresign Lincoln wrote:               (Wed, 11 Oct 2006 17:17:56)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 17:23:55 -0400

Brian,

I think better wording might be:

  The TID label mechanism might not work in certain types of application
such
  as when there are two linked dialogues and the second one is initated
by 
  the network.  In this particular case, the SG may not know how to
route the 
  new dialog back to the correct ASP that was handling the first dialog.

Personally, I think this issue is solvable, although not trivial.  But I
think saying that it MUST NOT be used eliminates the possibility that a
vendor can solve it.  Why eliminate the possibility for innovation.  If
you point out to the users the dangers, I would have to assume that they
can understand that and take it in to consideration.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 5:15 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] Re: DRN and TID Label Issues

Lincoln,

--brian

> I agree with you that TID routing will not solve linked dialogs.  
> There are many problems that the SUA spec does not explicity solve.  
> That leaves room for companies to be innovative.
> 
> Regards,
> Lincoln
> 
(Wed,

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 17:26:41 -0400

Brian,

Personally, I have no problem with pushing LOADSEL as an RFC or addendum
to the SUA RFC.  However, right now, I think since TID routing is an
accepted, useful, and deployed solution, it is what we should resolve.
This does not exclude the presentation of new standards.  I also believe
that ASPCONG should become standard as it is plugging a hole in the
RFCs.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 5:18 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: DRN and TID Label Issues -- Issue #3

Lincoln,

Haresign Lincoln wrote:
(Wed, 11 Oct 2006 17:15:45)
> Brian,
> 
> With the exception of linked dialogs (which I agree is not solved by 
> TID routing alone), nothing we are doing is proprietary with the 
> exception of sending ABORTs or discarding when unable to route.  This 
> obviously only applies to ongoing dialogs and is a temporary situation

> when an ASP dies.

--brian

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

---

From: Aditya <[email-masked]>
Date: Tue, 17 Oct 2006 03:38:48 -0700 (PDT)

Hi all,
If a M3ua Peer receive a M3UA message with message length (in Header) less than the actual length (but a multiple of 4) [say for example; ASP Active Ack message received with Length in the Header field as 8; whereas the actual length is 16.]; then does RFC 3332 mandate sending an error message. The missing 8 bytes are not padding bytes (can't be). 

My question is also for the reverse case : actual message len is 8 but the length field in the header specify it as 16.

All I could find was 

Section 3.8.1
   The "Parameter Field Error" would be sent if a message is received
   with a parameter having a wrong length field.

but this talks about "parameter" and not the header.

Appreciate your help,

Aditya

---------------------------------------------------------------------------X----------------------------------------------------
 
Don't take life too seriously...
Nobody comes out alive anyway

---------------------------------
How low will we go? Check out Yahoo! Messenger’s low  PC-to-Phone call rates.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 17 Oct 2006 06:25:07 -0600

Aditya,

As long as the message is correct within the advertised length, there is no
need to send an error.  If it is too short in the header, it is because a
parameter is too long.

--brian

Aditya wrote:                                                                                                 (Tue, 17 Oct 2006 03:38:48)
> 
>    Hi all,
>    If  a M3ua Peer receive a M3UA message with message length (in Header)
>    less  than  the  actual length (but a multiple of 4) [say for example;
>    ASP  Active Ack message received with Length in the Header field as 8;
>    whereas  the actual length is 16.]; then does RFC 3332 mandate sending
>    an  error  message.  The  missing 8 bytes are not padding bytes (can't
>    be).
>    My question is also for the reverse case : actual message len is 8 but
>    the length field in the header specify it as 16.
>    All I could find was
>    Section 3.8.1
>    ----------------------------------------------------------------------
>    -----X----------------------------------------------------
> 
>      _________________________________________________________________
> 
>    How  low  will  we  go? Check out Yahoo! Messengers low [1]PC-to-Phone
>    call rates.
> 
> References
> 
>    1. http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com

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