Re: 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

Haresign Lincoln wrote:                                           (Wed, 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 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]] 
> Sent: Wednesday, October 11, 2006 4:35 PM
> To: Haresign Lincoln
> Cc: Barry Nagelberg; [email protected]
> Subject: Re: [Sigtran] DRN and TID Label Issues - Issue #8
> 
> 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
> > 
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email protected]]
> > Sent: Wednesday, October 11, 2006 4:05 PM
> > To: Haresign Lincoln
> > Cc: Barry Nagelberg; [email protected]
> > Subject: [Sigtran] DRN and TID Label Issues - Issue #8
> > 
> > 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 protected]
> > http://www.openss7.org/
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/

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