Subject: SUAv7: Usage of Flag Parameters

From: [email-masked]
Date: Thu, 9 Aug 2001 14:11:57 +0530

Hi,

Please see following two comments for Section 3.9.1.

1.

?Hop Counter (3.18/Q.713)
The value of the hop counter is decremented with each global title translation,
and should be in the range 15 to 1?

Above statement is true for SCCP but not for SUA. As in SCCP only when Routing
Indicator is Route on GT, Relay node functionality can be invoked. While in SUA
(as per section 1.5.3), it can be invoked in other cases also , route on
Hostname for example.
Definition of Hop Counter should be changed to say that hop counter be
decremented at each relay node rather than saying after each global title
translation.

2. ?Sequence Control (1.1.2/Q.714)
Bits 1-5 are coded with the value of the sequence control parameter associated
with a group of messages and are chosen so as to ensure proper loadsharing of
message groups over SLS values while ensuring that sequence control values
within message groups have the sequence control value coded with the same value
as the initial message of the message group. ?

Usage of Sequence Control parameter is not clear from the above text. My
understanding of this parameter is as follows. Please comment.
In Connectionless Data Transfer at originating SUA node, SUA user can optionally
pass "sequence control" parameter to SUA in N-UNITDATA request primitive
(Protocol Class 1). If passed, SUA at Originating Node use this parameter for
stream selection and copy the same in CLDT message. While processing CLDT
message for protocol Class 1 at relay node , sequence control parameter received
in the CLDT message should be used for stream selection. For any other message
like CORE, COAK and RELRE ,this parameter is ignored.

Regards,
-Sandeep

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 11:50:34 -0500

Sandeep,

[email-masked] wrote:                            (Thu, 09 Aug 2001 14:11:57)
> decremented at each relay node rather than saying after each global title

Hop counter is also changed by an originating or terminating node
when it performs translation on GT only.  The hop counter counts the
number of GT translations performed, not the number of relay nodes
traversed.  If a node performs multiple GT on the same message, it
changes the hop counter multiple times.  This is evidenced by the
SCCP SDLs Figure 2/T1.112.4 in the ANSI 2000 spec which shows hop
counter being handled as part of the translation function without
determination of whether the message has originated or is destined
for the local node.

Hop counter is not a time-to-live parameter.  It is meant to detect
GTT loops between nodes.  As such it is changed with each
translation.  It is also permitted to change hop counter to detect
GTT loops for successive GTT translations within a node.

> like CORE, COAK and RELRE ,this parameter is ignored.

It is the responsibility of the MTP-User to select SLS.  The current
draft says 1-5 bits, but for ANSI compatibility that has been
changed to 8 bits.  There is no reason why all 32 bits cannot be
used as long as the distribution performs load-sharing over the
least significant 4 bits.

Sequence control must be selected by SCCP for CLDT (protocol class
0) and CORE, COAK.  For coupled CO operation where the connection
sections are associated at the SG, selection is required on CLDT,
CORE and COAK, and may be performed by SCCP at the SG, or by SUA at
the ASP.  For decoupled operation, where the final connection
section is not associated at the SG, sequence control is required on
all CO messages and it is the responsibility of SUA to set the value
(whether by user input or not).  For CL class 1 operation, the
sequence control value must be selected by the SCCP-User and, as
such, must be communicated from the SCCP-User to the SUA at the ASP.

Hopefully this clarifies your questions.  Would you like to see text
to this effect in SUA?

--brian

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

---

---

From: [email-masked]
Date: Fri, 10 Aug 2001 12:59:41 +0530

Brian ,

Please see my comments below.

Thanks and Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/09/2001 11:20:34 PM

Please respond to [email-masked]

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

Subject:  Re: SUAv7: Usage of Flag Parameters

Sandeep,

[email-masked] wrote:                            (Thu, 09 Aug 2001
14:11:57)

Hop counter is also changed by an originating or terminating node
Sandeep >> I do not think that hop counter is decremented at originating Node.
It should be set (initialised) at originating Node.
when it performs translation on GT only.  The hop counter counts the number of
GT translations performed, not the number of relay nodes traversed.  If a node
performs multiple GT on the same message, it
changes the hop counter multiple times.  This is evidenced by the
SCCP SDLs Figure 2/T1.112.4 in the ANSI 2000 spec which shows hop
counter being handled as part of the translation function without
determination of whether the message has originated or is destined
for the local node.
Sandeep>> As per section 2.3.1 (point 3) of SCCP, hop counter is only
decremented for message transferred to SCRC via MTP and not messages transferred
to SCRC via SCLC or SCOC.

Sandeep>> Can you please give an example for the case where for the same message
, translation function is invoked twice in the same Node. I always thought it is
never done.

From Section 2.19, Q.712
2.19 hop counter: The "hop counter" parameter field is used in the CR, XUDT,
XUDTS, LUDT and LUDTS messages to detect excessively long routes at the SCCP
layer.
This definition does suggest that the purpose of Hop counter is similar to time
to live. As such procedures does say that decrement hop counter after each GTT
and if it reaches Zero invoke message return or connection refusal procedure.
This of course is to avoid larger than permitted routes for the same message.
Also in SCCP if a incoming message is received with Routing Indicator == Route
on SSN, this message can only be for local user and can not be relayed further.
This effectively means that Relay Node == GTT translation in SCCP.

My doubt about SUA was , let us say we are using Routing Indicator "Route on
Hostname" . This message reaches a relay node and relay node selects next node
and transmit message without decrementing Hop Counter. This way there is a
danger that this message will live infinitely in the network. Should this not be
avoided ?

Sandeep>> Brain , Reason for my doubt was because of difference of behaviour
between SCCP and SUA.
Sequence Control parameter is not there in any of SCCP messages and SCCP does
not specify any rules on how SLS should be chosen/calculated at relay node. For
example , if a SCCP receives UDT message and Routing Indicator is set to Route
on GT, message is sent to next node resulting out of GT translation. In this
case SCCP does not enforce that SLS received in MTP-Transfer indication
primitive be used as SLS for sending message to next Node, implementation can
choose any method of selecting SLS. But SUA includes sequence control parameter
in messages. I wanted to see some text on how to handle this parameter in
incoming message in relay node.

--brian

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

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 12:01:49 -0500

Sandeep,

Please see comments below...

[email-masked] wrote:                            (Fri, 10 Aug 2001 12:59:41)

[snip]

> Sandeep >> I do not think that hop counter is decremented at originating Node.

In the ANSI SDLs it appears that the hop counter is decremented "with each
global title translation."

> It should be set (initialised) at originating Node.

I believe it is set (initialized) by the user.  It is a QOS parameter.

> to SCRC via SCLC or SCOC.

That's not what I read.  Section 2.3.2 refers to the translation function
being performed and doesn't dig down to the level of hop counter, but
the SDLs show messages from SCLS or SCOC passing through the same GTT
function which handles hop counter if present.  I agree with the statement
that it is decremented with each GTT (for ANSI).  Where's Al when you
need him?

> , translation function is invoked twice in the same Node. I always thought it is

Loops, either within or between platforms.  Successive GTT which
traverse the same node twice.  GTT which results in a different
TT but re-enters GTT for implementation purposes.

> not specify any rules on how SLS should be chosen/calculated at relay node.

SCCP does specify rules for SLS at relay node.  For coupled connection
sections, the SCCP must choose an SLS value per discription in CO
procedures.   For non-coupled or CL relay function the SLS value is
based on the SLS value (maybe even the same) in the incoming message.
For ANSI rotation rules should be followed.

> For
> choose any method of selecting SLS.

Not for protocol class 1.  For protocol class 1 the same received SLS must
alway yield the same sent SLS.  It is wise to follow SLS rotation rules for
ANSI.  (I think Al went over this on the thread which introducted the
Sequence control parameter into SUA).

>  But SUA includes sequence control parameter

That is up to SCCP to provide for, not SUA.  It is not SUA's place to dictate
SLS rules for each variant.  It is up to the implementation to meet the SLS
requirements for local SCCP interworking.  (I.e. it is part of the NIF.)
SUA need only provide the parameter "package" to carry the parameter from
ASP to SGP when required.

--brian

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

---

---

From: [email-masked]
Date: Tue, 14 Aug 2001 20:32:34 +0530

Brian ,

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/10/2001 11:31:49 PM

Sandeep,

[email-masked] wrote:                            (Fri, 10 Aug 2001
12:59:41)

 .. [cut].

Sandeep >> Please see Figure C.1/Q.714 (sheet 8 of 11)

? SCCP routing control
procedures (SCRC) of Q.714 , For me it clearly say decrement hop counter only
for messages from MTP.

Sandeep>> Please see Figure C.1/Q.714 (sheet 8 of 11) ? SCCP routing control
procedures (SCRC) of Q.714, it is at place within SCCP (as per ITU specs) that
Hop Counter value should be set.

> danger that this message will live infinitely in the network. Should this not
be

Sandeep >> What I simply wanted say was that text in section 3.9.1 of SUA be
changed to be in sync with the text in 1.5.3 of SUA. Please see that in section
1.5.3 of SUA it is clearly written that hop counter be decremented each time a
relay function is invoked.

> not specify any rules on how SLS should be chosen/calculated at relay node.

SCCP does specify rules for SLS at relay node.  For coupled connection sections,
the SCCP must choose an SLS value per discription in CO procedures.

Sandeep >> In my understanding (please correct me ), neither the ANSI nor ITU
specs have any rules for maping incoming SLS to outgoing SLS in case of CO
Procedures. I looked at section 3.1.5 and SDLs in Figure C.7/Q.714  of Q.714.
They just say if coupling is required at relay Node, assign some SLS values for
incoming and outgoing connection sections.

For non-coupled or CL relay function the SLS value is based on the SLS value
(maybe even the same) in the incoming message.For ANSI rotation rules should be
followed.

Sandeep  >> Again Above is true only for CL relay operation (and Protocol Class
1) and not for non-coupled CO operation. For non-coupled CO operation, SCCP
(Either ANSI or ITU ) does not specify any rules for using incoming SLS.

Sandeep >> I still suggest sequence control parameter be used in following way.
In Connectionless Data Transfer at originating SUA node, SUA user can optionally
pass "sequence control" parameter to SUA in N-UNITDATA request primitive
(Protocol Class 1). If passed, SUA at Originating Node use this parameter for
stream selection and copy the same in CLDT message. While processing CLDT
message for protocol Class 1 at relay node , sequence control parameter received
in the CLDT message should be used for stream selection. While processing CLDT
message the terminating end SUA passes the sequence control parameter received
in CLDT message to SUA-USER using N-UNITDATA indication primitive. For any other
message like CORE, COAK and RELRE ,this parameter is ignored.

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 11:39:47 -0500

Sandeep,

[email-masked] wrote:                            (Tue, 14 Aug 2001 20:32:34)
> procedures (SCRC) of Q.714 , For me it clearly say decrement hop counter only

I said in the "ANSI" SDLs.  Why are you referring me to an ITU-T SDL?
Check T1.114 SDLs.  They are different.

> Hop Counter value should be set.

Again, not in the ANSI SDLs.

> relay function is invoked.

That is not what appears to be the case from the ANSI SDLs.  From the ASNI
SDLs it appears that the hop counter is decremented each time that a GTT
is performed, regardless of whether it is a relay node or not.

> incoming and outgoing connection sections.

That is all that is required.  Certainly loadsharing at MTP must also be taken
into account per Q.704.

> (Either ANSI or ITU ) does not specify any rules for using incoming SLS.

Q.704 specifies requirements for MTP-Users in their selection of SLS values.
SCCP, as an SCCP-User, is subject to the requirements on SLS selection
provided in Q.704.

> message like CORE, COAK and RELRE ,this parameter is ignored.

Won't work for decoupled operation.  The SCCP-User must select the sequence
control parameter.  How the SCCP ultimately changes this into an SLS is
implementation specific, and which stream the SUA uses is completely
implementation specific.

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

---

---

From: [email-masked]
Date: Thu, 16 Aug 2001 14:56:03 +0530

Brian ,

Some comments below ..

"Brian F. G. Bidulock" <[email-masked]> on 08/14/2001 11:09:47 PM

Sandeep,

[email-masked] wrote:                            (Tue, 14 Aug 2001
20:32:34)

> > danger that this message will live infinitely in the network. Should this
not

Sandeep >> Brain , Please have a look at section 3.17 of ANSI T1.112 where hop
counter is defined. It says
The SCCP hop Counter parameter is one octet parameter that contains counter that
is decremented each time message is processed by SCCP relay point.
I do not know at what exact place in ANSI SDLs are you referring , I could not
find even mention of hop counter at any place in ANSI SDL (I have version  dated
1996). Besides how it is done in SCCP ( and more specifically in ANSI SCCP) is
not what I was concerned about. My point was and I restate , it is allowed in
SUA for a message to be relayed without GTT being performed. If that happens and
we only decrement hop counter after performing GTT , there is a danger of this
message staying in network for excessively long time ( may be infinitely). In
all IP network this will be a bigger issue. So I am against such behaviour of
SUA. What is your opinion , do you think this should be avoided or not?

> SCCP does specify rules for SLS at relay node.  For coupled connection
sections,

That is all that is required.  Certainly loadsharing at MTP must also be taken
into account per Q.704.
Sandeep >> But there is no point using incoming SLS as key for the loadsharing
algorithm as SLS you choose can be independent of this value.

> message like CORE, COAK and RELRE ,this parameter is ignored.

Won't work for decoupled operation.
Sandeep >> Can you please explain , why not ?

The SCCP-User must select the sequence
control parameter.  How the SCCP ultimately changes this into an SLS is
implementation specific, and which stream the SUA uses is completely
implementation specific.

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Aug 2001 12:07:43 -0500

Sandeep,

[email-masked] wrote:                            (Thu, 16 Aug 2001 14:56:03)
> Sandeep >> Brain , Please have a look at section 3.17 of ANSI T1.112 where
> hop counter is defined. It says The SCCP hop Counter parameter is one octet
> parameter that contains counter that is decremented each time message is
> processed by SCCP relay point.  I do not know at what exact place in ANSI
> SDLs are you referring , I could not find even mention of hop counter at any
> place in ANSI SDL (I have version  dated 1996). Besides how it is done in
> SCCP ( and more specifically in ANSI SCCP) is not what I was concerned
> about. My point was and I restate , it is allowed in SUA for a message to be
> relayed without GTT being performed. If that happens and we only decrement
> hop counter after performing GTT , there is a danger of this message staying
> in network for excessively long time ( may be infinitely). In all IP network
> this will be a bigger issue. So I am against such behaviour of SUA. What is
> your opinion , do you think this should be avoided or not?

I'm looking at Figure 2/T1.112.4-2000.  The only place that hop counter is
handled is directly associated with the GTT function and the only place that
hop counter violation is checked is immediately following GTT.

Note that if GTT is not performed, then the message is set to route on
DPC/SSN and the message will not be "processed by an SCCP relay point,"
(it will be transferred at the MTP), no hop counter treatment is performed
without GTT.

Also, if SUA allows a message to be transferred without GTT being performed,
SUA would be performing the MTP transfer function.  I don't think that it
is intended that SUA perform the MTP transfer function.

I would just let SCCP GTT handle the hop counter.  I don't think the AMF
needs get involved in hop counters at all.

[snip]
> algorithm as SLS you choose can be independent of this value.

Implementation-dependent.  It is the MTP-User's responsibiltiy to set SLS in
such a fashion as to ensure proper SLS loadsharing.  If the message is
transferred at SCCP using GTT in an ANSI network, normal SLS rotation rules
will suffice.  If you want to generate a new SLS value, go right ahead: just
remember that generating a balanced SLS load over multiple SGP/ASPs is not a
trivial function.  On the other hand, SLS rotation or any other algorithm
based on the incoming SLS value is rather trivial.

But these are implementation specifics which do not impact SUA.

--brian

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

---

---

From: [email-masked]
Date: Fri, 17 Aug 2001 19:54:55 +0530

Brian ,

Please see some comments below ..

"Brian F. G. Bidulock" <[email-masked]> on 08/16/2001 11:37:43 PM

Sandeep,

[email-masked] wrote:                            (Thu, 16 Aug 2001
14:56:03)

I'm looking at Figure 2/T1.112.4-2000.  The only place that hop counter is
handled is directly associated with the GTT function and the only place that
hop counter violation is checked is immediately following GTT.
Sandeep >> Ok, may be it has changed between ANSI 1996 and 2000 specs then.

Sandeep >> The same is not true for SUA. Please see
From section 1.5.3 Address Mapping Function at a Relay Node
   The relay function is invoked when:
     -    Routing is on Global Title
     -    Routing is on Hostname
     -    Routing is on SSN+PC or SSN+IP Address and the address
          presented is not the one of the relay node
So SUA does recommend that message to be relayed even for NON GTT case. This
infact was the reason of my concern.

Sandeep >> Again, SUA does recommend this.

.. [cut]

Sandeep >> I am not very well verse with the SLS rotation rules in ANSI SCCP,
but it now seems reasonable to me to use incoming SLS for loadsharing algorithm.

Now applying these rule for SUA,
For Class 1
At originating SUA node, SUA user will pass "sequence control" parameter to SUA
in N-UNITDATA request primitive  Originating Node use this parameter for stream
selection and copy the same in CLDT message. While processing CLDT message for
protocol Class 1 at relay node , sequence control parameter received in the CLDT
message should be used for stream selection. While processing CLDT message the
terminating end SUA passes the sequence control parameter received in CLDT
message to SUA-USER using N-UNITDATA indication primitive. This can be used to
insure sequencing of class 1 messages that are transferred between IP and SS7
networks.

For Class 0, 2 and 3
Originating SUA Node chooses sequence control parameter for using SCTP streams
in loadsharing manner. SUA copy this parameter in CORE, COAK and CLDT (class 0)
message respectively. At relay node SUA can use this sequence control parameter
for selecting next SCTP stream.

Note: There is no usage of this parameter for messages transferred between IP to
SS7 network, as for these protocol class this parameter can not be passed from
SCCP to SUA.

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 17 Aug 2001 11:05:35 -0500

Sandeep,

[email-masked] wrote:                            (Fri, 17 Aug 2001 19:54:55)
[cut]
> infact was the reason of my concern.

And what is the concern?  That SUA will have AMF loops?  I don't think so:
the AMF uses Routing Keys which are non-overlapping and result in a unique AS.
What is the problem?  Don't design your AMF with loops or excessive delays.
Even if an specific implementation of SUA needs some sort of loop detection,
it had better not mess with SCCP's hop counter which is a SCCP User/Network
QOS parameter.

> Sandeep >> Again, SUA does recommend this.

This is true, but so what?  Don't design your AMF with loops (excessive
delays): you are not required to and encouraged not to by the restrictions
placed on RK.

--brian

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

---

---

From: [email-masked]
Date: Mon, 20 Aug 2001 15:08:43 +0530

Hi ,

"Brian F. G. Bidulock" <[email-masked]> on 08/17/2001 10:35:35 PM

Sandeep,

[email-masked] wrote:                            (Fri, 17 Aug 2001
19:54:55)
[cut]

Sandeep >> Excessive delays can be (and thay are usually ) caused by malicious
AMF configurations.

Even if an specific implementation of SUA needs some sort of loop detection,
it had better not mess with SCCP's hop counter which is a SCCP User/Network QOS
parameter.

Sandeep >>  I am talking about SUA hop counter, not SCCP hop counter. SUA hop
counter is similar to SCCP hop counter but not same. SCCP hop counter is valid
within SS7 network and SUA hop counter is valid within IP network.

So you are saying SUA at relay node should not be decrementing hop counter if it
does not perform GTT at that node. It should rather be using this parameter to
keep a count of number of GTT being performed beween a starting and terminating
node and if number of GTT being performed increase some limit it should drop
message.
I do NOT agree with that view !! I firmly believe hop counter MUST be
decremented at each relay node regardless of GTT is performed at that node or
not !!

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 08:10:36 -0500

Sandeep,

[email-masked] wrote:                            (Mon, 20 Aug 2001 15:08:43)
[snip]
> > the AMF uses Routing Keys which are non-overlapping and result in a unique
> > AS.  What is the problem?  Don't design your AMF with loops or excessive
> > delays.
> 
> Sandeep >> Excessive delays can be (and thay are usually ) caused by
> malicious AMF configurations.

The word `usually' combined with `AMF' does not sound like an accurate
statement to me.  There is no `usual' case for AMF yet.  I might point
out that a "malicious" SG can do more damage than excessive delays.

Could you explain why excessive delays are "usually" due to "malicious"
AMF configurations?

> within SS7 network and SUA hop counter is valid within IP network.

There is no SUA hop counter.

> decremented at each relay node regardless of GTT is performed at that node or

GTT is performed at every relay node !!  Every node which performs GTT
is a relay node !!

--brian

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

---

---

From: [email-masked]
Date: Mon, 20 Aug 2001 19:07:59 +0530

Brian ,

Comments below  ..

"Brian F. G. Bidulock" <[email-masked]> on 08/20/2001 07:40:36 PM

Sandeep,

[email-masked] wrote:                            (Mon, 20 Aug 2001
15:08:43)

Could you explain why excessive delays are "usually" due to "malicious"
AMF configurations?
Sandeep >> I was refering to SCCP and just wanted to say that excessive delays
are caused by bad configuration.

There is no SUA hop counter.
Sandeep >> Is one present as part of Flag field not SUA hop counter?  what is it
then ?

 .. [cut]
> decremented at each relay node regardless of GTT is performed at that node or

GTT is performed at every relay node !!

Sandeep >> I am reading section 1.5.3 and it clearly says SUA message can be
relayed without GTT and you are saying GTT is performed at each relay node. What
is that I am not getting here ??
section 1.5.3
   The relay function is invoked when:
     -    Routing is on SSN+PC or SSN+IP Address and the address  presented is
not the one of the relay node

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 08:51:59 -0500

Sandeep,

[email-masked] wrote:                            (Mon, 20 Aug 2001 19:07:59)
[snip]
> are caused by bad configuration.

SCCP Translation and AMF are two different things.

> Sandeep >> Is one present as part of Flag field not SUA hop counter?  what is it

This on in the flag field is the SCCP-User setting of a SCCP QOS parameter.
That is the SCCP Hop Counter.  SUA does not have its own hop counter.

> not the one of the relay node

That is not an SCCP Relay Function.  That is an AMF function.  No GTT is
required, SCCP Relay is not performed and the SCCP hop counter should not
be decremented.

Perhaps "The relay function is invoked" should be changed to "the AMF is
invoked".

--brian

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

---

---

From: [email-masked]
Date: Mon, 20 Aug 2001 20:00:21 +0530

Brian ,

Comments below ..

"Brian F. G. Bidulock" <[email-masked]> on 08/20/2001 08:21:59 PM

Sandeep,

19:07:59)

This on in the flag field is the SCCP-User setting of a SCCP QOS parameter.
Sandeep >>  I do not see hop counter as parameter in QOS parameter set passed
from SCCP user to SCCP. I am looking at section 2.2.2.2.2 in ANSI (1996) ,
perhaps this also has changed in ANSI 2000. In ITU hop counter in clearly not
present at SCCP user to SCCP interface.

That is the SCCP Hop Counter.  SUA does not have its own hop counter.
Sandeep >> If you are saying that in all IP network , parameter hop counter
should not be used ? I disagree.

.. [cut]

That is not an SCCP Relay Function.  That is an AMF function.  No GTT is
required, SCCP Relay is not performed and the SCCP hop counter should not
be decremented.
Sandeep >> Well I will not argue on it beyond this point and will leave it to
author to decide. In my opinion hop counter should be used to guard against SUA
level loops caused by bad configuration in the network. For this reason whenever
processing a message from peer SUA (either at intermediate node or at
terminating node) hop counter parameter should be decremented, regardless of GTT
being performed or not.

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 10:08:51 -0500

Sandeep,

[email-masked] wrote:                            (Mon, 20 Aug 2001 20:00:21)
[snip]
> should not be used ? I disagree.

That is SUA Last Call Issue 17: Insufficient considerations for IPSP
to IPSP case.  How SUA deals with most parameters (not just hop
counter) in the IPSP case is unspecified in the draft.

Nevertheless, I see no need for hop counter in the SUA IPSP case
because there is no need for SCCP relay nodes (far less Translation)
in the IP domain.

[snip]
> Sandeep >> Well I will not argue on it beyond this point and will
> leave it to author to decide. In my opinion hop counter should be
> used to guard against SUA level loops caused by bad configuration
> in the network.

What SUA level loops?  The AMF has no loops: it always results in a
single and unique RC.  There is no need for SCCP relay nodes in the
IP domain.  Don't try to make an SS7 network out of the IP network.

> For this reason whenever processing a message from peer SUA
> (either at intermediate node or at terminating node) hop counter
> parameter should be decremented, regardless of GTT being performed
> or not.

There is no need for a relay node in the IP domain.  In the SS7
domain, or in the ASP case, hop counter is decremented by SCCP only,
not SUA.

--brian

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

---

---

From: Jeff Copley <[email-masked]>
Date: Tue, 21 Aug 2001 11:21:06 -0500

Sandeep,

A little comment regarding the hop counter and some of the comments in
this tread.

The hop counter was originally introduced into SCCP when the ISNI
discussions were going on.  There was concern that as a query traversed
mulitple networks that it may get caught up in a loop. The hop counter
was introduced so that the query could be automatically taken out of the
network once the counter was decremented to zero.  It is a mandatory
parameter of the XUDT and LUDT.

When reviewing ANSI standards, the SDLs are provided to assist you, but
the text takes precedence. The SDLs do not cover all cases. The text
says:

The "SCCP hop counter" parameter is used to count the number of SCCP
relay points (hops) a message
passes through, and can be used to detect the possible looping of
messages.

and in another section it says

The "SCCP hop counter" parameter is a one octet parameter that contains
a counter that is decremented each time the message is processed by an
SCCP relay point. Its structure is shown in Figure 11/T1.112.3. If
decrementing the counter results in the value of zero, the SCCP
initiates the appropriate error procedure. If "return on error" is
indicated, an "SCCP hop counter violation" return code is provided. The
initial value of the counter is set by the originator of the message. An
initial value of less than 16 is recommended.

The above text does not say that the hop counter is only associated with
GTT.  It says that the hop counter "is decremented each time the message
is processed by an SCCP relay point".  So if a message is delivered to
SCCP for purposes of determining the next destination, then the hop is
decremented.  If the message is delivered to a final destination, then
there is no point to check the hop counter.  The point I'm trying to
make is that the hop counter is decremented at SCCP relay points.  It
would not, for example, be decremented for MTP through-switched
messages.

The recommended value of the hop counter is set by the originator.  The
originator does not decrement the counter (no purpose).  Originally it
was recommended to use 15.  You may want to review your acrchitecture to
see if this value makes sense.

Regardless of interpretations of its use, I agree that using the hop
counter may be a good thing for SUA.  If you are doing multiple SCCP
AMF/GTT/whatever functions (i.e., intermediate relay processes), where
you do some processing to obtain an intermediate address, then it is
possible that somewhere an incorrect database entry could cause
looping.  Hop counter procedures would detect this, eliminate the
message, and provide notification back to the originator.

At an SCCP relay node, the hop counter should only be decremented once.

There was additional usage of the hop counter in ANSI-2000, but there
were no changes to its procedures.

I will stay away from the RC/IPSP/NA comments.

Oh. I almost forgot.  Sorry about this, but I must say that the
interpretations of the standard given above are provided as an
interpretation in my role as an employee of my employer.  It is not
intended to represent an opinion of any standards organization.  

Regards,

Jeff

[email-masked] wrote:
>   ------------------------------------------------------------------------
> 
>   ------------------------------------------------------------------------
> ---
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 14:26:03 -0500

Jeff,

I think the point is moot since one cannot relay
without performing Translation.  The SDLs are not
in error.  The AMF cannot have loops and has no
equivalent to the ISNI funcion.  Hop counting is
not required in SUA.

--brian

Jeff Copley wrote:                                           (Tue, 21 Aug 2001 11:21:06)
> > Please see following two comments for Section 3.9.1.
Content-Description: Card for Jeff Copley
> begin:vcard 
> n:Copley;Jeff
> tel;work:972.519.3758
> x-mozilla-html:FALSE
> org:Alcatel USA, Inc.
> version:2.1
> email;internet:[email-masked]
> adr;quoted-printable:;;1000 Coit Road=0D=0AMS NSGAP;Plano;Texas;75075-5813;USA
> x-mozilla-cpt:;20864
> fn:Jeff Copley
> end:vcard
> 
> 
> 

Content-Description: footer
> ---
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 22 Aug 2001 15:24:23 +0200

Hello Jeff,

I agree with you : this was exactly what the intention of the hop counter is
: whenever SUA draws on it's AMF function to determine the next hop, the
thing is decremented. The AMF is basically a database to translate GT,
hostnames, ... and loops are not excluded.

The SUA relay function draws on the AMF (for GTT, hostname resolution, IP
address mapping, why not). A signalling network overlay based on SCTP
associations is possible : 3GPP will adopt SUA for use within 3G mobile
networks. This will require a large scalability and use of SUA relay points
(gateways between mobile networks).

Regards,

____________________________

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

-----Original Message-----
From: Jeff Copley [mailto:[email-masked]]
Sent: dinsdag 21 augustus 2001 18:21
To: sigtran
Subject: Re: SUAv7: Usage of Flag Parameters

Sandeep,

Regards,

Jeff

---

---

From: [email-masked]
Date: Wed, 22 Aug 2001 19:45:36 +0530

Jef , Gery,

Thanks for reply.
I agree with both of you on the usage of hop counter. Just one more
clarification.
Hop counter parameter can not be passed across IP and SS7 networks, hence SCCP
hop counter parameter looses meaning once a SCCP message enters IP network.  So
in the following text originating node can only be IP node.

Section 1.5.3
To prevent looping, a hop counter is used. The originating end node (be it an
SS7 or an IP node) sets the value of the hop counter to the maximum value (15 or
less)

Best Regards,
-Sandeep

Verwimp Gery <[email-masked]> on 08/22/2001 07:54:23 PM

Subject:  RE: SUAv7: Usage of Flag Parameters

Hello Jeff,

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Jeff Copley [mailto:[email-masked]]
Sent: dinsdag 21 augustus 2001 18:21
To: sigtran
Subject: Re: SUAv7: Usage of Flag Parameters

Sandeep,

Regards,

Jeff

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 10:48:59 -0500

Sandeep, Jeff, Gery,

I still disagree.

John: can we enter "SUA: Hop Counter Usage" as an issue for
SUA Last Call?

--brian

[email-masked] wrote:                            (Wed, 22 Aug 2001 19:45:36)
> Fax: +32 14 25 3212

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

---

---

From: Jeff Copley <[email-masked]>
Date: Wed, 22 Aug 2001 10:54:05 -0500

I don't see it as an issue.

j

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 12:46:05 -0500

Jeff,

If you don't need or want SUA text changed, there
is no need to enter it as an issue.  If you do,
I take issue with it.  IMO current text is sufficient.

--brian

Jeff Copley wrote:                                           (Wed, 22 Aug 2001 10:54:05)

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

---

---

From: Jeff Copley <[email-masked]>
Date: Wed, 22 Aug 2001 16:40:55 -0500

Brian,

Ooops!  Did I accidentally agree with you?  Or did you agree with me?

I agree with the current text that says in both the AMF function and in
GTT that the hop counter functionality is operational.  I think it needs
to be active anytime a relay function is invoked. I call AMF and GTT
relay functions.

Jeff

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 17:07:37 -0500

Jeff, Sandeep,

SUAv7 says:

1.5.3 Address Mapping Function at a Relay Node 

   ...

   To prevent looping, a hop counter is used. The originating end node 
   (be it an SS7 or an IP node) sets the value of the hop counter to 
   the maximum value (15 or less). Each time the relay function is 
   invoked within an intermediate (relay) node, the hop counter MUST be 
   decremented. When the value reaches zero, the return or refusal 
   procedures are invoked with reason "Hop counter violation". 

and:

3.9.1 Flags 

   ...
         The value of the hop counter is decremented with each global 
         title translation, and should be in the range 15 to 1. 

That is all that is said about hop counter.
That's good enough for me.

Good enough for you, Jeff?

Sandeep?

--brian

Jeff Copley wrote:                                           (Wed, 22 Aug 2001 16:40:55)

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

---

---

From: [email-masked]
Date: Fri, 24 Aug 2001 09:53:24 +0530

resending ..
---------------------- Forwarded by Sandeep Mahajan/HSS on 08/24/2001 12:13 PM
---------------------------

Sandeep Mahajan
08/23/2001 11:20 AM

To:   [email-masked]
cc:

Subject:  Re: SUAv7: Usage of Flag Parameters  (Document link not converted)

Hi ,

I suggest following two text changes.

1. Hop counter should be decremented at each relay node , GTT may and may not be
performed at all relay nodes. To reflect this text in section 3.9.1 be changed
to say

3.9.1 Flags
Hop counter is decremented each time the relay function is invoked within an
intermediate (relay) node. The value of the hop counter is in the range 15 to 1.

2. Hop counter parameter can not be passed across IP and SS7 networks, hence
SCCP hop counter parameter looses meaning once a SCCP/SUA user message crosses
network boundary.  So in the following text originating node can only be IP
node.

Section 1.5.3

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/23/2001 04:37:37 AM

Jeff, Sandeep,

SUAv7 says:

   ...

and:

3.9.1 Flags

   ...

Sandeep?

--brian

Jeff Copley wrote:                                           (Wed, 22 Aug 2001
16:40:55)

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 23 Aug 2001 23:51:39 -0500

Sandeep,

[email-masked] wrote: (Fri, 24 Aug 2001 09:53:24)
> performed at all relay nodes. To reflect this text in section 3.9.1 be changed

Relay nodes perform GTT by definition.

> intermediate (relay) node. The value of the hop counter is in the range 15 to 1.

This is already stated in Section 1.5.3

> SS7 or an IP node) sets the value of the hop counter to the maximum value (15 or

This is already stated in Section 1.5.3.  An SS7 node (SG) can set the value
if the implementation wants to.

--brian

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

---

---

From: [email-masked]
Date: Fri, 24 Aug 2001 10:39:48 +0300

Hi Jeff,

> to be active anytime a relay function is invoked. I call AMF and GTT

Let's say you both agreed with each other (split the difference).
Anyhow, I think the text as in the SUAv7 is sufficient.  This
I am concluding.

John

---