Subject: Service State Property "Out of Service"

From: Hemant <[email-masked]>
Date: Mon, 17 Apr 2000 16:11:08 +0530

Hi Brian, list,

    I wish to discuss some issues with handling of service state property value "Out of Service" (OOS). The draft mentions "The state "out of service" indicates that the termination cannot be used for traffic" (sec 7.1.5 para 2). This is fine for the terminations which are made OOS in null context as terminations can only be Added with non "out of service" state. But what about the following : 

1) Is a command specifying Service State as OOS valid for a termination in a non null context ? 
If it is valid, what is the MG expected to do ? Should it stop traffic and deallocate all the resources allocated for that termination and let the termination remain in non null context? What will happen if this termination is made "in-service" again. The MG would have to allocate all the resources (according to the command in which the termination state change is specified as in service) for this termination and add it to the context. That is the MG would do all the handling that is required to "Add" the termination in the context. Then what is being gained by keeping a OOS termination in a non-NULL context ? 

Suggestion : I would suggest that operation should be made invalid. The MGC should first bring the termination out of context by explicitly subtracting the termination. Another option is specifying that setting state to OOS does an implicit subtract (just like mux results in an implicit Add). But in this option what would a command containing Stream desc. with non null Local or Remote mean ? Should resource reservation implied by these be neglected ? I don't know why one would like to make a temination OOS and then hold resources for that same termination. 

2) Assume that the state of a termination in null context is In service. An add command for that termination is received and in that command the termination state set to OOS. Is that a valid command ? 

Suggestion : I think this should also be considered invalid going by the logic which prevents an already OOS termination to be added to a context. 

Can it be said then that changing the state of a termination to OOS is valid only under following circumstances :    
    - In null context.    
    - By Modify command.    
    - Without any Local and Remote Descriptor. 

comments please .... 

Regards,
Hemant Kumar

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:[email-masked]
Web: http://www.ficon-tech.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Michael Brown <[email-masked]>
Date: Mon, 17 Apr 2000 18:37:29 -0400

Comments inserted inline with <MB>.

Hemant wrote:

> Hi Brian, list,     I wish to discuss some issues with handling of
> service state property value "Out of Service" (OOS). The draft
> mentions "The state "out of service" indicates that the termination
> cannot be used for traffic" (sec 7.1.5 para 2). This is fine for the
> terminations which are made OOS in null context as terminations can
> only be Added with non "out of service" state. But what about the
> following : 1) Is a command specifying Service State as OOS valid for
> a termination in a non null context ?If it is valid, what is the MG
> expected to do ? Should it stop traffic and deallocate all the
> resources allocated for that termination and let the termination
> remain in non null context? What will happen if this termination is
> made "in-service" again. The MG would have to allocate all the
> resources (according to the command in which the termination state
> change is specified as in service) for this termination and add it to
> the context. That is the MG would do all the handling that is required
> to "Add" the termination in the context. Then what is being gained by
> keeping a OOS termination in a non-NULL context ?
>
> <MB> Actually, I would expect that the MG would continue to do what it
> is told to do either through control of the MGC or perhaps a
> maintenance interface. The decision as to whether/when the termination
> would stop traffic and deallocate resources would be based on the type
> of service change requested (e.g., forced, etc.) The use for an OOS
> termination in a non-null context is that that there are a number of
> OOS tests which could be performed which would be easier modelled by
> placing the termination into a context and potentially adding test
> terminations to the context to perform those functions such as making
> a test call to or from the OOS termination. I do not believe that the
> operation should be made invalid.
>
>   Suggestion : I would suggest that operation should be made invalid.
> The MGC should first bring the termination out of context by
> explicitly subtracting the termination. Another option is specifying
> that setting state to OOS does an implicit subtract (just like mux
> results in an implicit Add). But in this option what would a command
> containing Stream desc. with non null Local or Remote mean ? Should
> resource reservation implied by these be neglected ? I don't know why
> one would like to make a temination OOS and then hold resources for
> that same termination. 2) Assume that the state of a termination in
> null context is In service. An add command for that termination is
> received and in that command the termination state set to OOS. Is that
> a valid command ? Suggestion : I think this should also be considered
> invalid going by the logic which prevents an already OOS termination
> to be added to a context. Can it be said then that changing the state
> of a termination to OOS is valid only under following circumstances
> :    - In null context.    - By Modify command.    - Without any Local
> and Remote Descriptor.
>
> <MB> I would say that the command you have suggested is indeed
> invalid. I think you meant to suggest that a transaction might contain
> both an ADD command and a ServiceChange command and that this
> combination should be invalid. I again do not agree that this should
> be considered invalid, although I would think it somewhat unlikely
> that one would want to do so.
>
>   comments please .... Regards,Hemant
> Kumar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Hemant Kumar
> Ficon Technology