Subject: Re: ServiceChange Reason Code

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 3 Feb 2000 15:42:48 -0500

We certainly allow the MGC to force handover by means of the ServiceChange
method.

You're wondering why the MGC would put terminations out of service.  One
typical example would be if someone requests test access to a termination by
way of a management interface into the MGC.  There is nothing wrong with the
termination itself, so the MG can't predict this ahead of time.

This sort of action has more than just book-keeping value: it prevents the
MG from choosing the termination concerned if it would otherwise be selected
as the result of a wildcard match on terminationID.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:[email-masked]]
> Sent: Thursday, February 03, 2000 2:54 PM
> To:   [email-masked]
> Subject:      ServiceChange Reason Code
>
> Hi
>
> Can someone look at the following and provide some inputs as whether it is
> correct or complete?
> Do we really need so many Reason Code?
> If we do, according to section 13.3 "A complete description of the
> condition under which the reason
> is used is detected shall ...."
>  ----------- (somekind of typo here)
>
> Thanks
> Chuong
>
>
> Direction               TermId           Method          Reason
> MG->MGC         ROOT            Restart          900 Service Restored ??
>
> 901 MG Cold Boot
>
> 902 MG Warm Boot
> MGC->MG         ROOT            Handoff         908 MGC Impending Failure
> ??
> MG->MGC         ROOT            Failover        903 MGC Directed Change
>
> 908 MG Impending Failure
>
> 909 MGC Impending Failure
> MG->MGC         termId(s)       Restart         900 Service Restored
>                                                       Forced          905
> Termination taken out
>                                                       of service
>                                                       Graceful       904
> Termination malfunctioning
>
> 906 Loss of lower layer connectivity
>
> 907 Transmission Failure
>
> 910 Media Capability Failure
>
> 911 Modem Capability Failure
>
> 912 Mux Capability Failure
>
> 913 Signal Capability Failure
>
> 914 Event Capability Failure
> MG->MGC        ROOT        Disconnected    915 State Loss
>
>
> ----------------------------------------------------------
>
> Direction               TermId           Method          Reason
> MGC->MG         ROOT            Forced or       Can we even allow this?
>                                                      Graceful         If
> yes,
>
> 901 MG Cold Boot or
>
> 902 MG Warm Boot or
>
> 903 MGC Directed Change or?
>                              termId(s)        Forced          905
> Termination taken out of service
>                              termId(s)        Graceful        same reasons
> as MG-MGC?
>
> Can't be right because MG would already know
>
> what is wrong w/term before MGC.
>                             termId(s)       Restart         900 Service
> Restored  ???
>
> 903 MGC Directed Change
>                             ROOT            Restart         Only if MG is
> up but out service.
>
> 900 MGC Service Restored ??
>
> 903 MGC Directed Change
>
> Why would MGC needs to take terminations out of service?
> For ephemeral, it does not make sense.
> For physical, MG would know something is wrong with the termination
> before MGC would.
> Regardless, this is useful in a sense it prevents the MG from CHOOSING
> a termination that MGC wants to be out of service.
> I don't quite understand the needs for both Forced and Graceful here.
> I would think that the MGC would have Subtract the terminations before
> taking them out of service.  This is because Force or Graceful does not
> take terminations out of context.
> So seems like it is always Forced.
>
>
> --
>   Alcatel USA, Inc             Internet: [email-masked]
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>

---

From: Chuong Nguyen <[email-masked]>
Date: Thu, 3 Feb 2000 16:33:56 -0600

Tom

My main goal was to verify if the reason code as shown was used
correctly.

>
> You're wondering why the MGC would put terminations out of service.
> One typical example would be if someone requests test access to a
> termination by way of a management interface into the MGC.  There is
> nothing wrong with the termination itself, so the MG can't predict
> this ahead of time.

This is an interesting scenario:
MGC takes termination out of service via ServiceChange.
MG marks termination as out of service.
Standard says
"Add SHALL NOT be used on a Termination with a serviceState of
"OutofService."
"Modify SHALL NOT be used on a Termination with a serviceState of
"OutofService."
Unless this test you are referring to is not accomplish via MGC command
or has anything to do
with Megaco, please disregard my comments.

>      Can someone look at the following and provide some inputs as
>      whether it is correct or complete?
>      If we do, according to section 13.3 "A complete description of
>      the condition under which the reason
>      MGC->MG         ROOT            Handoff         908 MGC Impending
>      Failure ??
>      Forced          905 Termination taken out
>                                                            of service
>
>      Graceful       904 Termination malfunctioning
>
>
>      Graceful         If yes,
>                                   termId(s)        Graceful
>      same reasons as MG-MGC?
>                                  termId(s)       Restart         900
>      Service Restored  ???
>                                  ROOT            Restart         Only
>      if MG is up but out service.
>
>