Re: DRN and TID Label Issues -- Issue #3
"Brian F. G. Bidulock" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Organization | http://www.openss7.org/ |
| Message-ID | <[email protected]> |
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/