Subject: Re: Washington Issue 7 - Generic Error Event

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Nov 1999 10:52:48 -0500

This is simply an observation that having each package that
can generate such an error have to declare a separate event
leads to a lot of events in the event descriptor.  Better
to have one parameterized event.  There are at least one per
bearer type, as well as the NAS one.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, November 17, 1999 10:20 AM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: Washington Issue 7 - Generic Error Event
>
>
> G'Day all,
>
> I think this should be added to a specific package for NAS.
>
> As it stands below it is too general. The MGC should do the subtract
> based on an event depending on an application.
>
> Cheers, Christian
>
> Brian Rosen wrote:
> >
> > A number of issues were raised in the Washington meeting that
> > were "send to the list".  This is one of these issues, with the
> > problem and my suggested fix.
> >
> > Problem:
> > There needs to be an event which the MG can send that indicates
> > that a failure has occurred that is less significant than
> > a ServiceChange would warrant, but the MGC needs to respond
> > to with a Subtract.   This event should have a parameter
> > which indicates why it was invoked.
> >
> > Proposed Solution:
> >
> > Package Termination Failure
> > PackageID tfail (0x00??)
> > Provides a general purpose error code for a failure which
> > requires that the MGC subtract the termination, but does not
> > require the Termination be taken out of service
> >
> > Properties:
> > None
> >
> > Events:
> > TerminationFailure
> >         EventID: tfail, 0x0001
> >         Detects an non recoverable error on a termination that does
> >         not require the termination be taken out of service
> >
> >         EventDescriptor parameters:
> >                 None
> >         Notify parameters:
> >                 Termination Failure Error Code
> >                         ParameterID: Error (0x0001)
> >                         Type: integer
> >                         Possible values: entry in an IANA registered
> >                                 list of error codes
> >                 Additional Information
> >                         ParameterID: AddlInfo (0x0002)
> >                         Type: string
> >                         Possible Values: additional diagnostic
> >                                 information.
> >
> > Brian
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 18 Nov 1999 11:48:34 -0600

[[TomT]]  ...  Maybe
> we could define that 'FP' causes a subtract?
        [[TomT]]
        This is a variant on Matt Holdrege's SubtractRequest proposal.  As
such, it's an item for future consideration.  Just now the basic principle
is that the MGC is responsible for all cleanup.

> Cheers, christian
>
> 3.1 General Cause Package
> EventID:                cause
>
> Event Parameters:
>
> generalcause
> Possible values:        Enumerated,
>                         "NR" Normal Release
>                         "UR" Unavailable Resources
>                         "FT" Failure, Temporary
>                         "FP" Failure, Permanent
>                         "IW" Interworking Error
>                         "UN" Unsupported
>
> Description: This parameter groups the failures into six groups, which
> the MGC act upon.
> failurecause
>
> Possible Values:        BIT STRING
>
> Description:    The Release Cause is the value generated by the released
> equipment, i.e. a released network connection. The concerned value is
> defined in the appropriate bearer control protocol.
>
>
>
>
>
> Brian Rosen wrote:
> >
> > Yep - nearly every bearer I know about can "die" for one reason
> > or another.  If the bearer goes down, it's not (necessarily) an
> > "out of service" thing, but it's definitely something the MGC
> > needs to know, and respond with a Subtract for.
> >
> > Brian
> >
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Thursday, November 18, 1999 5:14 AM
> > > To: [email-masked]
> > > Putting it an a package would make it specific. I wouldn't call it
> > > Generic Error event in the NAS package. I would make it
> > > specific to the
> > > event detect/generated by the MG.
> > >
> > > We already have a method for the MG to raise a Red flag its called the
> > > 'servicechange'. Perhaps a new reason/method here is more appropriate.
> > >
> > > I'm not sure we want to continue to proliferate IANA
> > > maintained lists in
> > > the H248. We have IANA lists for: packages, command error
> > > codes, service
> > > change reasons and then there will be multiple IANA lists defined in
> > > packags. A question: are there other protocols that generate so many
> > > IANA registered lists? What is IANA's view?
> > >
> > > Tom: Do we need to approach IANA to let them know what we are doing?
> > >
> > > Brian: you mentioned that each transport would a generic error event?
> > > What do you have in mind here? Sending up the cause code from a bearer
> > > failure?
> > >
> > > Cheers, Christian
> > >
> > > Matt Holdrege wrote:
> > > >
> > > > If it's too general, why would you add it to the NAS
> > > package? It doesn't
> > > > hurt to have a general error event. Having one doesn't stop you from
> > > > defining applications specific error events. It meets a
> > > basic requirement
> > > > to have a simple interoperable way for the MG to raise a red flag.
> > > >
> > > > At 04:19 PM 11/17/99 +0100, Christian Groves wrote:
> > > > >G'Day all,
> > > > >

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Nov 1999 09:48:27 -0500

I basically like it, although I don't want "normal release",
which is not an error.  Maybe we can have a mask on
what classes you want the event for.

Brian

> Sent: Thursday, November 18, 1999 10:25 AM
> To: Brian Rosen
> G'Day Brian,
> OK. Then its something like we proposed the Redbank meeting
> with generic
> cause events were we map individual causes to several causes.
> We didn't
> have the IANA definition point. The two proposals could be
> merged. Maybe