Subject: RE: (no subject) TDM implementation

From: [email-masked]
Date: Tue, 10 Sep 2002 16:05:38 +0100

Shahram,

In response to your comments on implementation:

> > There are
> > off the shelf AAL1/2 and SONET-VT chips in the market.
> > In other 
> > words the SARing could be done with off the shelf available
> > HW, rather than writing SW for it in a CPU, which is also
> > rate limited to a few T1/E1/DS3s.

AAL1/2 SARs are commercially available, however, they don't do the whole 
job. You still need a CPU to strip off the ATM headers, pack the cells 
into packets and add the appropriate pseudo-wire headers.

Besides, are we suggesting that we fix the standard on the basis of which 
chips are commercially available now?
Simplicity of implementation should not be determined by what one can buy 
today, since tomorrow's performance requirements will outgrow today's 
solutions. Who says tomorrow's implementation will be software in a CPU?

> Plus, the fact that you are extracting the CAS bits and reinserting 
them,
> which is more complex than just encoding them with the TDM stream. 

I think the argument is more "why weigh down applications that don't need 
CAS signalling with the overhead, when they don't need it?"

The difference of approach is perhaps best explained by the target markets 
for RAD and Axerra. 
>From what I can tell (and I'm sure both parties will correct me if I'm 
wrong), RAD seem to sell more into the small installation, enterprise 
markets, where the main application is structured transfer with CAS, and 
Axerra sell into the central office environment and are more geared 
towards emulation of entire DS1's, using unstructured transfer.

Regards,
Tim

---

From: Shahram Davari <[email-masked]>
Date: Tue, 10 Sep 2002 08:17:32 -0700

Tim,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, September 10, 2002 11:06 AM
> To: Shahram Davari; [email-masked]
> Cc: Sasha Vainshtein
> Subject: RE: [PWE3] (no subject) TDM implementation
> 
> 
> Shahram,
> 

Correct.

> solutions. Who says tomorrow's implementation will be 

No, What I am suggesting is why invent a new protocol, when one already exists.
It is always possible to invent a new protocol for specific scenarios
that the original protocol was not optimized for. This logic ends in
numerous protocols and their interworking nightmare.

Also the time to market is of importance. Why invent a new protocol from
scratch, when already HW/SW is available for a similar protocol that does
the job.

Yours,
-Shahram

---

From: [email-masked]
Date: Tue, 10 Sep 2002 16:47:06 +0100

> scratch, when already HW/SW is available for a similar protocol that 
does

But that's the point, the hardware/software ISN'T readily available. The 
SAR is available, and presumably an API to program it, but you still need 
to write the software to strip off the ATM headers, pack the cells into 
packets and add the appropriate pseudo-wire headers.

I fail to see that TDMoIP is any less a new protocol than CESoPSN, since 
it is not plain AAL1/2, it is a new adaptation of it. Why does this make 
the interworking nightmare any less between, say, a SONET VT and TDMoIP 
connection?

TDMoIP facilitates interworking with ATM CES, but it doesn't make it any 
easier to interwork with anything else.
CESoPSN is a basic format that can be used as a common intermediary 
between two different service types, therefore it removes the additional 
complexity associated with either SONET VT or AAL1/2.

If you want to interwork with ATM, place the ATM functionality in a 
separate NSP block.
If you want to interwork with SONET, place the SONET functionality in a 
separate NSP block. 

Don't complicate the basic pseudo-wire specification by forcing it to 
include either ATM or SONET functionality when it is not required.

Regards,
Tim

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 10 Sep 2002 20:10:34 +0200

Shahram and all,
Please see a brief comment inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, September 10, 2002 5:18 PM
> To: [email-masked]'; [email-masked]
> Cc: Sasha Vainshtein
Following this logic, the PWE3 should drop all frame-oriented
services and concentrate entirely on emulation of ATM. Because
emulation Ethernet, Frame Relay and HDLC over ATM AAL5 is well
defined, and the chips are commerically available.
For some reason the PWE3 did not do that.
>
> Also the time to market is of importance. Why invent a new 
> protocol from scratch, when already HW/SW is available for 
> a similar protocol that does the job.
>
See above.

---

From: Shahram Davari <[email-masked]>
Date: Tue, 10 Sep 2002 10:39:05 -0700

Tim,

> Sent: Tuesday, September 10, 2002 11:47 AM
> To: Shahram Davari
> Cc: [email-masked]; [email-masked]; Sasha Vainshtein
> > No, What I am suggesting is why invent a new protocol, when 
> one already 
> exists.
> protocol from
> > scratch, when already HW/SW is available for a similar 
> protocol that 
> does
> > the job.
> 

My assumption is that Martini HW/SW will be available.

> the interworking nightmare any less between, say, a SONET VT 

Here is why:

Assume that SONET-VT is already accepted by the WG,
and the dilemma is to select between TDMoIP and CESoPSN.
Depending on the network on both sides of the PSN, there are
6 possible cases:

TDM   ---- TDM
SONET ---- SONET
ATM   ---- ATM
TDM   ---- SONET
TDM   ---- ATM
ATM   ---- SONET

Assume if the CESoPSN is selected rather than TDMoIP.
In that case the functions that are needed on each side are:

        (CESoPSN) TDM  ---- TDM (CESoPSN)
     (SONET-VT) SONET  ---- SONET (SONET-VT)
(AAL1/2 + CESoPSN)ATM  ---- ATM (CESoPSN + AAL1/2)
       (CESoPSN) TDM   ---- SONET (CESoPSN + SONET)
       (CESoPSN) TDM   ---- ATM (CESoPSN + AAL1/2)
(AAL1/2 +CESoSPN)ATM   ---- SONET (CESoPSN +SONET)

As you can see (in the 3rd, 4th, 5th and 6th case) you need a total
of 6 interworking functions.

Now assume the TDMoIP (AAL1/2) is selected rather than CESoPSN.
In that case the functions that are needed on each side are:

        (TDMoIP) TDM   ---- TDM (TDMoIP)
     (SONET-VT) SONET  ---- SONET (SONET-VT)
          (TDMoIP)ATM  ---- ATM (TDMoIP)
        (TDMoIP) TDM   ---- SONET (TDMoIP + SONET)
        (TDMoIP) TDM   ---- ATM (TDMoIP)
         (TDMoIP)ATM   ---- SONET (TDMoIP + SONET)

As you can see (in the 4th and 6th case) you need a total of
2 interworking functions.

Does that answer your question?

> complexity associated with either SONET VT or AAL1/2.

But it creates more complexity for interworking cases.

Yours,
-Shahram