Subject: RE: [Megaco] Continuity tests

From: "Alf Heidermark (AS/EAB)" <[email-masked]>
Date: Mon, 3 May 2004 08:41:11 +0200

Hello Alexandr

Continuity check is in service on many old exchanges. Do you really mean that they shall change their impleentations to be able to interwork with the dumb switch. Normally it is up to new equipment to interwork existing network nodes. From this resoning I cannot see any reason to change anything in H.248 to continuity check.

alf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Aleksandr Ryabin
Sent: den 30 april 2004 16:39
To: Christian Groves (MC/EPA); [email-masked]
Cc: Kevin Boyle; Tom-PT Taylor
Subject: Re: [Megaco] Continuity tests

Hi Christian,

There could be "dumb" switches in the middle of the path
(for example DACS) which are not capable of any testing/signalling.
Their only role is to split/redirect links and as such the nature
of a circuit can change, and thus the type of COT test.

Regards,
         Aleks

At 08:17 PM 4/29/2004, Christian Groves wrote:
>Hello Aleksandr,
>
>Is this really a problem? The Continuity test is a link by link procedure 
>not an end to end procedure. I tend to support Kevin and Tom on this one.
>
>Regards, Christian
>
>Aleksandr Ryabin wrote:
>>Kevin, exactly, the type of COT test does not only depend on the physical
>>details of a termination the MGC controls, but also on physical
>>details of circuit which *eventually* is connected to that termination.
>>My point is that the final far-end *final* connection can change without
>>a change to immediate connection to MG termination and only MGC
>>would know about it.
>>For example, if MG is digital trunking gateway, it does not mean that
>>only pure 4-wire tests will be used all the time. If the other side connected
>>trough set of intermediate switches and finally lands at the time of the test
>>say on analog 2-wire circuit then the test to be executed is 2-wire test.
>>I guess it is possible to somehow tie up configuration of MG termination
>>dynamically to changes which happens to those intermediate switches,
>>but it does not seem right. On the contrary, that information would come to
>>MGC naturally, since it is a controlling element.
>>Also putting a burden of configuring of a test type per every single
>>termination seems to be too much for MG, especially if we are talking
>>about high density MGs which handle hundred thousands terminations.
>>BTW This is a real problem we run into in our MGC implementation and
>>are trying to solve. I thought that instead of having a proprietary package
>>I might as well give it a shot to see if there is any interest to make the
>>solution public instead.
>>Thanks.
>>         Aleks
>>At 11:23 AM 4/29/2004, Kevin Boyle wrote:
>>
>>>I agree with Tom.  The fact that the circuit is connected to a single 
>>>entity means that only a single type of continuity test is actually 
>>>valid.  MGs are expected to know how to handle their terminations.
>>>Who the termination is connected to is certainly part of that 
>>>handling.  Because the far-end connection changes the nature of the 
>>>termination, this becomes an MG-knowledge problem.
>>>
>>>I believe the package is fine as it stands, and the MG should know what 
>>>"run a continuity test" means for its terminations.
>>>
>>>Kevin
>>>
>>>-----Original Message-----
>>>From: Taylor, Tom-PT [CAR:5N00:EXCH]
>>>Sent: Thursday, April 29, 2004 11:19 AM
>>>To: Aleksandr Ryabin
>>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
>>>Subject: Re: [Megaco] Continuity tests
>>>
>>>I for one disagree with your philosophy.  I think the physical details 
>>>of the termination should be provisioned in the MG rather than the the 
>>>MGC.  However, I have no direct implementation responsibility, so I 
>>>should let those who do speak up.
>>>
>>>Aleksandr Ryabin wrote:
>>>
>>> > Packages defined in H.248.17 do not cover continuity tests.
>>> >
>>> > If the experts agree that MGC should be able to control type of
>>> > continuity test then ether basic ct package needs to be amended to
>>> > include new functionality, or H.248.17 needs to be amended to include
>>> > new "extended" continuity package Commends? Suggestions?
>>> >
>>> >         Aleks
>>> >
>>> > At 01:14 AM 4/29/2004, Zhao Bo wrote:
>>> >
>>> >> Can H.248.17 "line test packages"  be used to test these circuits?
>>> >>
>>> >>     ----- Original Message -----
>>> >>     From: Aleksandr Ryabin <mailto:[email-masked]>
>>> >>     To: Kevin Boyle <mailto:[email-masked]> ;
>>> >>     [email-masked] <mailto:[email-masked]>
>>> >>     Sent: Thursday, April 29, 2004 2:11 AM
>>> >>     Subject: RE: [Megaco] Continuity tests
>>> >>
>>> >>     Yes, the type of test depends on what a circuit is connected to.
>>> >>
>>> >>     But, I was actually coming from the view that MGC "controls" MG
>>> >>     and as such only MGC should have knowledge on what test to execute
>>> >>     (i.e. what is connected to the other side of a circuit).
>>> >>
>>> >>     If this information is left in MG, then each circuit has to be
>>> >>     provisioned
>>> >>     with that information such that MG can make intelligent decision
>>> >>     on what
>>> >>     type of test to execute. Thus every time a circuit connection is
>>> >>     changed,
>>> >>     directly or indirectly, MG circuit needs to be re-provisioned.
>>> >>
>>> >>     I think that configuration should  be kept on MGC and the decision
>>> >>     should
>>> >>     come from MGC instead.
>>> >>
>>> >>             Aleks
>>> >>
>>> >>     At 02:30 PM 4/28/2004, Kevin Boyle wrote:
>>> >>
>>> >>>         Is it possible to run more than one kind of continuity test
>>> >>>         on a particular circuit?  If no, then the provisioning model
>>> >>>         holds and there is no need for a change.  If yes, then we may
>>> >>>         need to add something to the package to allow selection of a
>>> >>>         ct test type.
>>> >>>
>>> >>>         Kevin
>>> >>>
>>> >>>         -----Original Message-----
>>> >>>         From: Aleksandr Ryabin [mailto:[email-masked]]
>>> >>>         Sent: Wednesday, April 28, 2004 1:21 PM
>>> >>>         To: [email-masked]
>>> >>>         Subject: [Megaco] Continuity tests
>>> >>>
>>> >>>         Hi,
>>> >>>
>>> >>>         There are several continuity test types (i.e 2-wire, 4-wire,
>>> >>>         etc) While provisioning of physical test parameters (i.e.
>>> >>>         frequencies, sequence, timeouts, etc) in MG makes sense, IMHO
>>> >>>         choosing a type of continuity test seem logical to be left to
>>> >>>         MGC.
>>> >>>
>>> >>>         Basic Continuity Package (ct) does not allow to choose the
>>> >>>         type of a test.
>>> >>>         It implies that type of a test is provisioned on MG (per
>>> >>>         termination?)
>>> >>>
>>> >>>         Is there another (extended) continuity test package which
>>> >>>         allows MGC to choose the type of a continuity test to be
>>> >>>         performed?
>>> >>>
>>> >>>         If not, does anyone see a need to have such a package?
>>> >>>         Comments?
>>> >>>
>>> >>>         Thanks
>>> >>>                 Aleks
>>> >>>
>>> >>>         _______________________________________________
>>> >>>         Megaco mailing list
>>> >>>         [email-masked]
>>> >>>         https://www1.ietf.org/mailman/listinfo/megaco
>>> >>

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

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

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 03 May 2004 10:11:21 -0400

Hi Alf,

I'm not talking about old networks. With old networks everything stays the 
same.
In order to maintain backward compatibility there always will be "intelligent"
switches sitting on border with old networks, which are capable of doing COT.

But new networks can utilize new (cheap) solutions and as such new
"intelligent" switches need to be capable of the functionality in question.

Regards,
         Aleks

At 02:41 AM 5/3/2004, Alf Heidermark (AS/EAB) wrote:
>Hello Alexandr
>
>Continuity check is in service on many old exchanges. Do you really mean 
>that they shall change their impleentations to be able to interwork with 
>the dumb switch. Normally it is up to new equipment to interwork existing 
>network nodes. From this resoning I cannot see any reason to change 
>anything in H.248 to continuity check.
>
>alf
>

---

From: "Alf Heidermark (AS/EAB)" <[email-masked]>
Date: Mon, 3 May 2004 08:41:11 +0200

Hello Alexandr

alf

-----Original Message-----

Hi Christian,

Regards,
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 03 May 2004 10:11:21 -0400

Hi Alf,

Regards,
         Aleks

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 3 May 2004 18:23:54 -0400

Right.  New switches need to be able to provide the same function as the old
switches.

I am still not seeing the problem here. If the new switches need to provide
the same function as the old switches, then that implies that these
"middleswitches" have to do COT.  Customers are not going to tolerate lack
of basic function.

It seems to me that the inability to do COT will limit the deployment of any
of these "new cheap" boxes.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]] 
Sent: Monday, May 03, 2004 10:11 AM
To: Alf Heidermark (AS/EAB); [email-masked]
Subject: RE: [Megaco] Continuity tests

Hi Alf,

I'm not talking about old networks. With old networks everything stays the
same.
In order to maintain backward compatibility there always will be
"intelligent"
switches sitting on border with old networks, which are capable of doing
COT.

Regards,
         Aleks

At 02:41 AM 5/3/2004, Alf Heidermark (AS/EAB) wrote:
>Hello Alexandr
>
>Continuity check is in service on many old exchanges. Do you really 
>mean that they shall change their impleentations to be able to 
>interwork with the dumb switch. Normally it is up to new equipment to 
>interwork existing network nodes. From this resoning I cannot see any 
>reason to change anything in H.248 to continuity check.
>
>alf
>
>There could be "dumb" switches in the middle of the path (for example 
>DACS) which are not capable of any testing/signalling.
>Their only role is to split/redirect links and as such the nature of a 
>circuit can change, and thus the type of COT test.
>
>Regards,
>          Aleks
>

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 3 May 2004 18:23:54 -0400

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]] 
Sent: Monday, May 03, 2004 10:11 AM
To: Alf Heidermark (AS/EAB); [email-masked]
Subject: RE: [Megaco] Continuity tests

Hi Alf,

Regards,
         Aleks

---

From: Ryabin Aleksandr-A19776 <[email-masked]>
Date: Tue, 4 May 2004 09:21:51 -0500

New switches need to be able to provide at least the same functions as old switches.
"At least" here is a key word. They also will have more functions.
One of the new functions is to be able to work with "dumb" switches not capable of COT.
 
The control protocol in use for these new switches is not there to address marketing needs,
but to address functional needs. As such it has to have the ability to allow MGC to solve 
this functional issue.
 
As I indicated before this is real life issue we run into and need to address.
My intent here is to simply bring the issue up to standartization community
such that no private extention created to address the issue.
If standartization community feels that this is an implementaion issue
then we will deal with it as such.
 
Regards,
    Aleks

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Monday, May 03, 2004 6:24 PM
To: Aleksandr Ryabin; Alf Heidermark (AS/EAB); [email-masked]
Subject: RE: [Megaco] Continuity tests

Right.  New switches need to be able to provide the same function as the old switches. 

I am still not seeing the problem here. If the new switches need to provide the same function as the old switches, then that implies that these "middleswitches" have to do COT.  Customers are not going to tolerate lack of basic function.

It seems to me that the inability to do COT will limit the deployment of any of these "new cheap" boxes. 

Kevin 

-----Original Message----- 
From: Aleksandr Ryabin [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Monday, May 03, 2004 10:11 AM 
To: Alf Heidermark (AS/EAB); [email-masked] 
Subject: RE: [Megaco] Continuity tests 

Hi Alf, 

I'm not talking about old networks. With old networks everything stays the same. 
In order to maintain backward compatibility there always will be "intelligent" 
switches sitting on border with old networks, which are capable of doing COT. 

But new networks can utilize new (cheap) solutions and as such new "intelligent" switches need to be capable of the functionality in question.

Regards, 
         Aleks 

At 02:41 AM 5/3/2004, Alf Heidermark (AS/EAB) wrote: 
>From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ]On Behalf Of 
>Aleksandr Ryabin

---

From: Ryabin Aleksandr-A19776 <[email-masked]>
Date: Tue, 4 May 2004 09:21:51 -0500

Regards,
    Aleks

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Monday, May 03, 2004 6:24 PM
To: Aleksandr Ryabin; Alf Heidermark (AS/EAB); [email-masked]
Subject: RE: [Megaco] Continuity tests

Kevin 

-----Original Message----- 
From: Aleksandr Ryabin [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Monday, May 03, 2004 10:11 AM 
To: Alf Heidermark (AS/EAB); [email-masked] 
Subject: RE: [Megaco] Continuity tests 

Hi Alf, 

Regards, 
         Aleks

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 4 May 2004 10:46:48 -0400

I think my key point has been misunderstood.  New switches include these
"dumb switches".  So, it seems to me that the "dumb switches" have a
compatibility requirement to support COT -- especially if they are changing
the physical aspects of the connections, which you have stated that they do.
 
This is not a marketing position -- this is an engineering position.  Telcos
that deploy equipment that make COT stop working will quickly remove that
equipment from their network as detrimental.  If we condone such behavior,
what is next?  Should we develop workarounds for all deficient equipment,
just on the position that it is "cheap" or "dumb" and therefore it is our
problem to solve?
 
COT has always been link-by-link.  Introducing a new "dumb" link does not
absolve that equipment of its responsibility to perform the same basic
function as every other link in the network.
 
Kevin

  _____  

From: Ryabin Aleksandr-A19776 [mailto:[email-masked]] 
Sent: Tuesday, May 04, 2004 10:22 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Alf Heidermark (AS/EAB); [email-masked]
Subject: RE: [Megaco] Continuity tests

New switches need to be able to provide at least the same functions as old
switches.
"At least" here is a key word. They also will have more functions.
One of the new functions is to be able to work with "dumb" switches not
capable of COT.
 
The control protocol in use for these new switches is not there to address
marketing needs,
but to address functional needs. As such it has to have the ability to allow
MGC to solve 
this functional issue.
 
As I indicated before this is real life issue we run into and need to
address.
 
Regards,
    Aleks

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Monday, May 03, 2004 6:24 PM
To: Aleksandr Ryabin; Alf Heidermark (AS/EAB); [email-masked]
Subject: RE: [Megaco] Continuity tests

Kevin 

-----Original Message----- 
From: Aleksandr Ryabin [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, May 03, 2004 10:11 AM 
To: Alf Heidermark (AS/EAB); [email-masked] 
Subject: RE: [Megaco] Continuity tests 

Hi Alf, 

Regards, 
         Aleks 

At 02:41 AM 5/3/2004, Alf Heidermark (AS/EAB) wrote: 
>From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 4 May 2004 10:46:48 -0400

Kevin

  _____  

 

Regards,
    Aleks

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Monday, May 03, 2004 6:24 PM
To: Aleksandr Ryabin; Alf Heidermark (AS/EAB); [email-masked]
Subject: RE: [Megaco] Continuity tests

Kevin 

-----Original Message----- 

Hi Alf, 

Regards, 
         Aleks