RE: DRN and TID Label Issues -- Issue #3

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 protected]] 
Sent: Wednesday, October 11, 2006 4:40 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email protected]
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

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
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Wednesday, October 11, 2006 3:47 PM
> To: Haresign Lincoln
> Cc: Barry Nagelberg; [email protected]
> Subject: DRN and TID Label Issues -- Issue #3
> 
> Lincoln,
> 
> RFC 3868 says:
> 
> 4.1.1.  Receipt of Primitives from SCCP
> 
>    ...
> 
>    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 may generate (X)UDTS "routing
>    failure", if the return option is used.
> 
> 4.7.3.2.  SCCP Connection Oriented 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 protected]
> http://www.openss7.org/

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