Subject: Re: [SUA Issue] Hop Counter

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 Aug 2001 04:15:43 -0500

Gery,

Please see additional comments below...

Verwimp Gery wrote:                                (Fri, 31 Aug 2001 10:54:21)
[snip]
> 
> > Klaus,
> > 
> > I agree with your arguments. There's no reason why SUA couldn't adopt hop
> > counter as mandatory.
> 
> It is optional in SS7.
> 
> [GV]: mandatory for XUDT and LUDT.

But XUDT and LUDT are not mandatory (UDT can be used).

> 
> > The SCCP-user has no control over it, so there's no interface issue with
> > existing applications on either SG or AS.
> 
> SCCP-User has control over hop counter in QoS Parameter Set.
> 
> [GV]: What's contained in this parameter set in nowhere specified.

QoS Parameter Set is well defined for OSI network protocols and is
informative for the NSD which is normative.  It is clearly specified.
The pertinent QoS parameters are transit delay (connectionless) and
probability of unsuccessful connection establishement (connection-
oriented).

> Anyway, if the user provides it, SUA must surely be able to handle it.

The user can provide it, that doesn't mean that it always provides it.

> > Also, when hop counter is not used in the SS7 network (strictly UDT) the NIF
> > just strips it off.
> 
> How does the NIF know to strip it off?  We will need a codepoint for
> hop counter which indicates that it was not provided.  It is more consistent
> with other parameters in SUA to make the parameter optional rather than
> provide a code point to indicate that it was not provided.
> 
> [GV]: the NIF (SCCP/SUA interworking) would know when to send UDT, wouldn't
> it ?

If it has not been specified whether hop counter was provided or not,
the NIF would not know whether it could use UDT or should use XUDT
(assuming that the variant allows XUDT).

> There is no place for a hop counter in UDT, so strip it off.

It is the presence or absence of hop counter which can be the
deciding factor at the NIF as to whether UDT or XUDT is used.

> Second, if the hop counter is there it MUST be populated.

Not for protocol variants which do not use it.  You assume alot.  Check TTC.

> But hey, I said I agree with the optional part.

To be honest, you said you wouldn't object to optional.  You said
you disagreed that it needed to be optional.

> 
> '0' cannot be used to indicate that the hop counter was not present, because
> the hop counter may have been provided, but coded to 0.  What would we use?
> 0xff ?
> 
> [GV]: why would anyone need a codepoint for "not provided" ??

Because someone made the parameter mandatory when it is not always
required.

> 
> > If no hop counter is received (UDT), the NIF populates it
> > with zero or any value it deems fit before sending CLDT to the ASP.
> 
> Because the hop counter is never provided to the SCCP-User, the SG
> never has to provide hop counter to the ASP.
> 
> [GV]: that's only true in the simple backhaul case.

What is true in the IPSP case has not been defined.  We are still waiting
on some definition there.  After peer behavior is defined, then maybe we
can talk about when hop counter might or might not be required.

> 
> > However, I could live with this parameter being optional, since the "simple"
> > architectures (backhaul etc.) do not really need it. At least it's there and
> > it must be handled when received !
>      ^^^^ could
> 
> Please make the parameter optional for transparency and increased
> interoperability.
> 
> [GV]: no beef here. Issue resolved ?

I suppose if Klaus doesn't object.

--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]