Subject: Re: Washington Issue 7 - Generic Error Event

From: Brian Rosen <[email-masked]>
Date: Thu, 18 Nov 1999 09:46:09 -0500

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

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 5:14 AM
> To: [email-masked]
> Subject: Re: Washington Issue 7 - Generic Error Event
>
>
> 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,
> > >
> > >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: Christian Groves <[email-masked]>
Date: Thu, 18 Nov 1999 16:25:17 +0100

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
we could define that 'FP' causes a subtract?

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.

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 18 Nov 1999 12:57:52 -0800

Then we should specify ServiceChange with appropriate cause for whenever a
bearer dies. Let's be as clear as possible for interoperability sake.