Re: Overload Controls for IUA

Hi Hassan,
 
I'd been intending to get back to you with this procedural note: the
Sigtran WG is not chartered to 
start any new work items at this time.  The mailing list remains open
as a tool for the participants to review and comment on any
Sigtran-related drafts, but if new drafts are 
submitted at the present time they would be treated as individual
submissions rather than WG drafts.
 
Cheers,
 
L. Ong

________________________________

From: [email protected] [mailto:[email protected]] On
Behalf Of [email protected]
Sent: Tuesday, July 29, 2008 7:09 AM
To: [email protected]
Subject: [Sigtran] Overload Controls for IUA



Dear members of the SIGTRAN WG, 

There exists the possibility that there will be a number of AGWs
connected to a single MGC, in this architecture when a media stimulated
events (e.g. tele voting) or in the event of a disaster, there is often
a large step change in the level of call attempts. In this architecture,
such an event is likely to grossly overload the MGCs to a level where
service may cease completely.

With a number of AGWs connected to a single MGC it will be necessary to
efficiently, and quickly, propagate information relating to the MGC
overload back to the single dependant AGWs, thus allowing the AGW to
immediately take preventative action, and thus quickly reduce the level
of load that is being offered to the overloaded MGC. The figure below
shows that there may be two separate flows of  new call attempts from
users of the AGW;

[1] signalling from analogue terminations via the MEGACO(H.248)
interface, and 

[2] signalling from ISDN terminations that is presented to the MGC via
the IUA interface. 


            +---------------------+                +-------------------+

            |  +---------------+  |                |                   |

            |  | Media         |  |                |  +--------------+ |

+-------+   |  |Manipulation   |  |                |  |    H.248     | |

|  POTS |   |  | +-----------+ |  |                |  | Controller   | |

|  CPE  =======| |ETSI_nr    | |<-------H.248-------->| +----------+ | |

+-------+   |  | |(POTS only)| |  |                |  | | H.248.11 | | |

            |  | +-----------+ |  |                |  | |  OLC     | | |

            |  +---------------+  |                |  | +----------+ | |

            | +-----------------+ |                |  +--------------+ |

+-------+   | |+-------------+  | |                |                   |

| ISDN  =======|    L2       |  | |                |                   |

| CPE   |   | || Termination |  | |                |                   |

+-------+   | |+------||-----+  | |                |                   |

            | |+------||-----+  | |                |                   |

            | || Proposed    |  | |                |                   |

            | || L3 OLC      |  | |                |  +----------+     |

            | |+------||-----+  | |                |  |    ASP   |     |

            | |+------||-----+  | |                |  +----------+     |

            | || IUA/DUA     |<-------IUA/DUA-------->|  IUA/DUA |     |

            | |+-------------+  | |                |  +----------+     |

            | +-----------------+ |                |                   |

            +---------------------+                +-------------------+




The analogue call attempts may be effectively controlled using  etsi_nr,
however a similar mechanism is not available for ISDN call attempts. And
therefore a new mechanism to enable the MGC to regulate the number of
IUA (QPTM) messages is necessary in order to prevent congestion collapse
of the MGC.

For your information, etsi_nr is a rate based overload control mechanism
for H.248  which is described in ETSI ES 283 039-4 and is freely
available from ETSI website.

I would like to know that if there is any interest in this proposal to
produce an draft RFC to cover this rate based overload mechanism for
IUA, work has just started within ETSI and we would like to have a
single mechanism in this area as it does not make sense for multiple
solutions in this space so we would propose to maintain alignment of the
work in the two standards bodies.

Kind Regards, 

Hassan Malik 


************************* 
Hassan M Malik. 
E2 103A 
BT Brentwood WS2000
One London Road
Brentwood
Essex CM14 4QP 
Mobile: + 44 7931 787650 
************************* 

British Telecommunications plc 
Registered office: 81 Newgate Street London EC1A 7AJ 
Registered in England no. 1800000 
This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message
in error, please notify us by telephone or email (to the numbers or
address above) immediately. 

Activity and use of the British Telecommunications plc E-mail system is
monitored to secure its effective operation and for other lawful
business purposes. Communications using this system will also be
monitored and may be recorded to secure effective operation and for
other lawful business purposes.

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran