Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

From: "Amnon Ilan" <[email-masked]>
Date: Tue, 24 Jun 2003 14:37:32 +0200

Tim,

Please see my comments inline.

Regards,
Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tue 24 June 2003 12:56
To: [email-masked]
Cc: 'Nurit Sprecher'; [email-masked]; [email-masked]
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Amnon,
I'm curious about your assertion here "The only way to support silence
suppression
is by using the AAL2 mode of TDMoIP". That is a very bold statement!

There are several ways to support silence suppression, of which AAL2 is
one. What about VoIP, for example? AAL2 may be a good method, however, it
is not the _only_ way.

[Amnon Ilan] My wording was not so good. By the word 'only' I meant within
   the scope of E1/T1 over PSN current suggestions (i.e. CESoPSN and
TDMoIP).

Clearly CESoPSN does not have a mode for silence suppression. However, it
does not compete with the AAL2 mode from TDMoIP. There may be an argument
why we shouldn't support both TDMoIP's AAL1 mode and CESoPSN, since both
do basically the same thing, but AAL2 has a clear differentiating reason
for its existence, as you have pointed out.

Therefore the presence of an AAL2 mode in TDMoIP is not an argument
against adopting CESoPSN.

[Amnon Ilan] IMHO it is an argument, and even a good one. If you go with the
   concept of adopting VoATM to PSNs why break it in the middle? (the basic
   reason for adopting VoATM was that VoIP is not designed for trunking and
   CES). There should be some very clear and dramatic technical advantage in
   favor of CESoPSN in order to do it (and by doing it loose the market
   acceptance advantages of VoATM which I've mentioned before). IMHO there
is
   no such an advantage for CESoPSN (TDMoIP and CESoPSN are more or less the
   same on the AAL1 level).

Regards,
Tim

"Amnon Ilan" <[email-masked]>
Sent by: [email-masked]
23-Jun-2003 04:23 PM
Please respond to ailan

        To:     "'Nurit Sprecher'" <[email-masked]>,
<[email-masked]>
        cc:
        Subject:        RE: [PWE3] Re: I-D
ACTION:draft-vainshtein-cesopsn-06.txt

Hi,

I agree with Nurit that there is no need for the CESoPSN draft.
We can have only two basic solutions:
1. The simple (simplistic) one: unstructured bitstream.
2. The more sophisticated one: TDMoIP.

The simple approach is limited since it requires a very good PSN
(very low packet loss and PDV): small frame loss may cause the loss
of frame alignment (and many E1\T1 applications are not robust
enough to minimize the effect of such a problem). This approach
is also very sensitive to loss of timing synchronization.
However, it is simple, easy to implement, and may be used on cases
where the PSN is good enough, or when the E1\T1 line itself is
unstructured.
The more sophisticated approach is much more robust: having framers
at the edge prevents loss of frame alignment (the effect of corrupted
data inside some of the time-slots is much less severe then the one
caused by loss of frame alignment). The structured modes of both
TDMoIP and CESoPSN address these issues.
However, IMO, TDMoIP is much more comprehensive: for example
see the issue of silence suppression. Most of E1\T1 lines are voice
trunks and for such trunks silence suppression may save more then
50% of network traffic. The only way to support silence suppression
is by using the AAL2 mode of TDMoIP. That is to add on the issues
of market acceptance and chances for compatible standards (ITU,
MPLS-Forum) mentioned in my previous email.

Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Nurit
Sprecher
Sent: Sun 22 June 2003 10:19
To: [email-masked]'
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Hi,
I have been passively following the debate over draft-vainshtein vs.
draft-anavi for some time, and still don't understand one thing.
draft-anavi uses techniques borrowed from ATM, in order to maintain
compatibility to existing CES systems. It thus a pointer to maintains
frame
alignment.
draft-vainshtein maintains TDM frame alignment by always sending an
integral
number of frames in a packet.
Why do we need to maintain frame alignment at all?
>From the TDM reconstruction point of view, all we need is to play out the
bits that are in the receive buffer, and the TDM switch will take care of
all the rest.
If a packet is lost, all we need to know is how many bits it contained -
so
all we need is to have a constant size packet!1
I vote against accepting draft-vainshtein.
For the unstructured case we need a simpler method - just constant size
packets!
For those complex cases where we need structured (especially with CAS) we
might as well use draft-anavi.
Nurit.

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

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

---

From: Max Riegel <[email-masked]>
Date: Thu, 26 Jun 2003 00:47:49 +0200

It seems silence compression is considered an important feature of the 
TDM emulation. During the discussion on Tom's prposal for TDM emulation 
we agreed to keep silence compression out of the basic specification for 
TDM emulation.

Is there a reason to add silence compression as an additional 
requirement in the TDM requirements I-D?

Just silence compression, or should we go for some kind of generic data 
compression with reasonable efficiency for voice signals?

Should payload compression be available for all kind of emulated 
circuits, or is it sufficient to limit it to some particular cases, e.g. 
n x DS0?

What is the opinion of the working group?

Bye
Max

[email-masked] wrote:

> I'm curious about your assertion here "The only way to support silence suppression