Subject: [Sigtran] Re: IUA/V5UA: Use of Notify Mgmt message

From: Eva Weilandt <[email-masked]>
Date: Tue, 29 Jan 2002 11:17:50 +0100

The overload notification shall indicate that the SG is not able to process the messages it receives/sends on a specific c-channel. This situation may arise out of the special configurations that are supported for V5: that one V5 interface may be distributed over more than on SG
(linkwise), and that several interface may be located on one SG.

For V5, every c-channel is protected by an additional c-channel on another link that serves as a standby. A likely configuration would be to configure this standby on a different SG. Note that active and standby c-channel may interchange there status at any situation were protection
switching occures.

Out of this the situation may arise that all c-channels (from one MGC) are located on one SG, the other SG just gets the standby (this could be due to an outage of the SG). The V5 protocol may now be able to handle this situation by protection switching some of the c-channels. For
doing this, the MGC needs to know. The SG itself has no means to handle this situation, it has no knowledge about the location of any standby c-channel.

The SG may detect this overload situation in the handover between its V5UA stack and its Layer 2/Layer 1, or whereever it seems appropriate.

This situation is more a V5 protocol problem than a V5UA protocol problem. In the MGC, the message would not be handled by the V5UA stack but by the V5 management. Thus it sounds inappropriate to use a V5UA message for this kind of messaging.
It is also true that the configuration with splitted V5 interfaces is not a necessary one (the disadvantate is that this kind of problem may occure). But we still believe that it is much safer on behalf of redundancy.

On the other hand this problem is V5UA specific since it just occures because the V5 stack is splitted between two entities, with V5UA in between. The V5 standard is not made for such a situation.

This is the reason why we want to implement such an 'overload' message. We first thought that it may be a way to check the 'backpressure' of the SCTP/V5UA stack (if the ASP can not send any more messages because it receives SACK messages with rwnd=0), but to us it seems a little late.
Since the MGC is able to take an action on detection of the problem, it may be advantagerous to detect the problem a little earlier.

Regards,

Eva

Ken Morneault wrote:

> Eva,
>
> Can you provide some background as to how you plan to use
> "overload" notification.  What does "overload" mean for V5? How does
> SG determine overload.  What is expected of the ASP?
>
> Regards,
>
> Ken
>
> At 03:01 PM 1/25/2002 +0100, you wrote:
> >Hi everybody,
> >
> >for V5UA I'm currently looking for a way for the SG to indicate an overload condition (on a per InterfaceID basis) to the MGC. We were considering to use a Mgmt message: Notify, maybe with a new defined reason 'overload' for this (the Mgmt messages are shared between IUA and V5UA).
> >
> >Would this be an acceptable approach? Or has anybody a better idea to communicate this?
> >
> >Regards,
> >
> >Eva
> >--
> >------------------------------------------------
> >
> >Dr. Eva Weilandt
> >
> >V5.2 Platform Architect / V5.2 Development
> >
> >Nortel Networks Germany
> >88039 Friedrichshafen / Germany
> >
> >Tel. +49-7545-96-7267     Fax +49-7545-96-8160
> >
> >ESN 565-7267
> >
> >
> >  ---
> >You are currently subscribed to sigtran as: [email-masked]
> >To unsubscribe send a blank email to [email-masked]
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Ken Morneault <[email-masked]>
Date: Tue, 29 Jan 2002 20:08:01 -0500

Eva,

Since the "overload" indication is V5 specific, it would probably be
best to create a new message instead of using Notify.

Ken

---

From: Eva Weilandt <[email-masked]>
Date: Wed, 30 Jan 2002 14:49:15 +0100

Then I would propose I'll define a new V5 Boundary Primitives Transport
Messages (V5PTM):

       12       MDL-Error Indication    (SG -> MGC)

what would somehow be in accordance to the V5 standard that defines a
primitive like this, even if 'overload' is not a defined reason in the
standard.

This message should contain a parameter 'reason' defined like:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x13)           |             Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Error Reason                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Error Reason:

     Define          Value      Description

     OVERLOAD         0x1       C-Channel is in overload state

Does this sound reasonable?

Regards,

Eva

Ken Morneault wrote:

> >The overload notification shall indicate that the SG is not able to
> process the messages it receives/sends on a specific c-channel. This
> situation may arise out of the special configurations that are
> supported for V5: that one V5 interface may be distributed over more
> than on SG
> >For V5, every c-channel is protected by an additional c-channel on
> another link that serves as a standby. A likely configuration would be
> to configure this standby on a different SG. Note that active and
> standby c-channel may interchange there status at any situation were
> protection
> >switching occures.
> >
> >Out of this the situation may arise that all c-channels (from one
> MGC) are located on one SG, the other SG just gets the standby (this
> could be due to an outage of the SG). The V5 protocol may now be able
> to handle this situation by protection switching some of the
> c-channels. For
> >doing this, the MGC needs to know. The SG itself has no means to
> handle this situation, it has no knowledge about the location of any
> standby c-channel.
> >
> >The SG may detect this overload situation in the handover between its
> V5UA stack and its Layer 2/Layer 1, or whereever it seems appropriate.
> >
> >This situation is more a V5 protocol problem than a V5UA protocol
> problem. In the MGC, the message would not be handled by the V5UA
> stack but by the V5 management. Thus it sounds inappropriate to use a
> V5UA message for this kind of messaging.
> >It is also true that the configuration with splitted V5 interfaces is
> not a necessary one (the disadvantate is that this kind of problem may
> occure). But we still believe that it is much safer on behalf of
> redundancy.
> >
> >On the other hand this problem is V5UA specific since it just occures
> because the V5 stack is splitted between two entities, with V5UA in
> between. The V5 standard is not made for such a situation.
> >
> >This is the reason why we want to implement such an 'overload'
> message. We first thought that it may be a way to check the
> 'backpressure' of the SCTP/V5UA stack (if the ASP can not send any
> more messages because it receives SACK messages with rwnd=0), but to
> us it seems a little late.
> >Since the MGC is able to take an action on detection of the problem,
> it may be advantagerous to detect the problem a little earlier.
> >
> >Regards,
> >
> >Eva
> >
> >Ken Morneault wrote:
> >
> >> Eva,
> >>
> >> >for V5UA I'm currently looking for a way for the SG to indicate an
> overload condition (on a per InterfaceID basis) to the MGC. We were
> considering to use a Mgmt message: Notify, maybe with a new defined
> reason 'overload' for this (the Mgmt messages are shared between IUA
> and V5UA).
> >> >
> >> >To unsubscribe send a blank email to
> [email-masked]
> >>
> >> ---
> >> To unsubscribe send a blank email to
> [email-masked]
> >
> >

Dr. Eva Weilandt

Nortel Networks Germany

ESN 565-7267