Subject: RE: (no subject) TDM implementation

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

Sasha,

> -----Original Message-----
> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: Tuesday, September 10, 2002 2:11 PM
> To: Shahram Davari
> Cc: [email-masked]'; [email-masked]
> Subject: RE: [PWE3] (no subject) TDM implementation
> 
> 
> 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.)
>  
> 
> 
> > -----Original Message-----
> > From: Shahram Davari [mailto:[email-masked]]
> > Sent: Tuesday, September 10, 2002 5:18 PM
> > To: [email-masked]'; [email-masked]
> > Cc: Sasha Vainshtein
> > Subject: RE: [PWE3] (no subject) TDM implementation
> > 
> > 
> > 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.
> >
> 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.

No, the logic is different. In the case of TDM emulation you actually need lots more than pure encapsulation needed for HDLC, Ethernet, etc. TDM Emulation includes SARing, CAS 
signaling transportation, compensating for loss packets/cells (loss concealment), 
structure awareness, etc. These functions are all defined in AAL1/2 and we don't
need to reinvent them.

Yours,
-Shahram

> >
> > 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. 
> >
> > Yours,
> > -Shahram 
> > 
>

---

From: [email-masked]
Date: Wed, 11 Sep 2002 15:46:23 +0100

Shahram,

> 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?

To be honest, no. TDMoIP is not a single interworking function, it is a 
double. TDM->AAL1/2, followed by AAL1/2->TDMoIP. Hence I would restate 
your table as follows:

(AAL1/2 + TDMoIP)   TDM ---- TDM   (TDMoIP + AAL1/2)
       (SONET-VT) SONET ---- SONET (SONET-VT)
         (TDMoIP)   ATM ---- ATM   (TDMoIP)
(AAL1/2 + TDMoIP)   TDM ---- SONET (TDMoIP + AAL1/2 + SONET)
(AAL1/2 + TDMoIP)   TDM ---- ATM   (TDMoIP)
         (TDMoIP)   ATM ---- SONET (TDMoIP + AAL1/2 + SONET)

This gives 8 interworking functions, including at least two multiple stage 
conversions (TDMoIP into AAL1/2 into TDM into SONET).

The nice part about CESoPSN is that if you don't want to handoff into ATM, 
you don't need to pay for the ATM function. If you don't want to handoff 
into SONET, you don't need to pay for the SONET function. 
If you do, either of these handoffs can be achieved with truly 
off-the-shelf existing offerings, connected as an NSP function in the PE. 
And nobody needs to do a triple conversion, since there is at most a 
single intermediate format.

Regards,
Tim

---

From: Shahram Davari <[email-masked]>
Date: Wed, 11 Sep 2002 08:08:59 -0700

Tim,

I think you missed my point. My point was that when you have 
implemented TDMoIP, then with the same HW/SW you could support ATM (AAL1/2)
and TDM, while if you choose CESoSPN, you can't and you need other functions
such as AAL1/2.

In other words with TDMoIP you need only 3 types of PEs:

- TDMoIP
- SONET-VT
- TDMoIP + SONET

Which results to 6 possible ingress/egress combinations.

While with CESoPSN you need 4 type of PEs:

- CESoPSN
- SONET-VT
- CESoPSN + AAL1/2
- CESoPSN + SONET

Which results to 10 possible ingress/egress combinations.

I leave it to the readers to decide which one creates more
interworking nightmare.

Yours,
-Shahram 

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 10:46 AM
> To: Shahram Davari
> Cc: [email-masked]; [email-masked]; Sasha Vainshtein

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 12 Sep 2002 12:13:07 +0300

> To be honest, no. TDMoIP is not a single interworking 
> function, it is a double. 
> TDM->AAL1/2, followed by AAL1/2->TDMoIP. Hence I 
> would restate your table as follows:

I think that this distinction is rather artificial.
The AAL1/2->TDMoIP "conversion" you mention 
is the adding of the header to the packet that you just prepared.

Why not call it 5 protocols.
One that does the AAL1/2, 
and one each for adding each byte in the control word?

For that matter setting each of the flags should really be counted as well.

I just hope that you aren't going to count up the
number of protocols involved in SONET-VT :)

Y(J)S

---

From: "Daniel Feldman" <[email-masked]>
Date: Thu, 12 Sep 2002 12:16:12 +0200

Hello Amnon,
	I fail to understand two things:
1) You say that in order to support silence suppression in TDM sources,
AAL2 must be used. Why? VoIP (with CRTP) can be used as well.
2) If indeed AAL2 is used, then the PSN does not see TDM traffic at all!
It sees ATM traffic, in which case an ATMoPSN encapsulation is
necessary. BTW, AAL2 is used in other scenarios, not only TDM. For
example, 3G networks. I think the issue of AAL2oATMoPSN should be dealt
by other drafts. The fact that the TDMoIP can deal with this issue is a
"bonus".

	Let's try to compare apples with apples, i.e., TDM traffic
(i.e., Nx64Kb/s or Unstructured TDM) being transported over PSN. 

	Regards,
		Daniel Feldman.

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

Tim,

AFAIK the most common link is a voice connection (PBX-PBX or PBX-PSTN).
In such a connection the required solution is AAL2 (mainly in order to
support
silence-suppression and per-voice-channel muxing/switching).
Processing using TDMoIP takes (TDM->PSN):
       TDM + AAL2 + TDMoIP
Processing using CESoPSN is problematic here:
       TDM + AAL2 + ...
How do you go from AAL1/2 packets to CESoPSN (it can only take TDM), so
you
need:
       TDM + AAL2 + restructured-TDM + CESoPSN

These extra steps may also add delay, since you are actually sampling
the
TDM twice.

Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Wed 11 September 2002 16:46
To: Shahram Davari
Cc: [email-masked]; [email-masked]; Sasha Vainshtein
Subject: RE: [PWE3] (no subject) TDM implementation

Shahram,

This gives 8 interworking functions, including at least two multiple
stage
conversions (TDMoIP into AAL1/2 into TDM into SONET).

The nice part about CESoPSN is that if you don't want to handoff into
ATM,
you don't need to pay for the ATM function. If you don't want to handoff
into SONET, you don't need to pay for the SONET function.
If you do, either of these handoffs can be achieved with truly
off-the-shelf existing offerings, connected as an NSP function in the
PE.
And nobody needs to do a triple conversion, since there is at most a
single intermediate format.

Regards,
Tim

_______________________________________________
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: "Yaakov Stein" <[email-masked]>
Date: Thu, 12 Sep 2002 12:22:30 +0300

> 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.

I think that you summed it up quite nicely.
In fact, I believe (and Sasha can correct me if I am wrong)
that Axerra is geared as much towards DS3 as DS1,
where the argument for unstructured transfer is much stronger.

The problem is that with the market situation today,
everyone is running after opportunities that might not
be in the sector for which his solution is optimized.

Y(J)S

---

From: [email-masked] (Amnon Ilan)
Date: Thu, 12 Sep 2002 12:47:31 +0200

Daniel, 
 
Please see my answers inline.
 
-----Original Message-----
From: Daniel Feldman [mailto:[email-masked]]
Sent: Thu 12 September 2002 12:16
To: [email-masked]; [email-masked]; Shahram Davari
Cc: [email-masked]; [email-masked]; Sasha Vainshtein
Subject: RE: [PWE3] (no subject) TDM implementation
 
AAL2 must be used. Why? VoIP (with CRTP) can be used as well.
VoIP does that as well. However, as I wrote in my previous email, AAL2 is
better for voice trunking applications and “emulation” (which is the 
case in PEW3).
 
> 2) If indeed AAL2 is used, then the PSN does not see TDM traffic at all!
It sees ATM traffic, 
This is not ATM traffic, but AAL2 traffic (no need for ATM cells).
> in which case an ATMoPSN encapsulation is necessary. BTW, AAL2 is used in
other scenarios, not only TDM. For example, 3G networks. 
That is exactly the issue of interoperability and market-acceptance that
makes the use of AAL2 in PWE3 a good solution.
> I think the issue of AAL2oATMoPSN should be dealt by other drafts. The
fact that the TDMoIP can deal with this issue is a "bonus".
>        Let's try to compare apples with apples, i.e., TDM traffic (i.e.,
Nx64Kb/s or Unstructured TDM) being transported over PSN. 
Are you suggesting here that the PWE3 will support only unstructured and
N*64 applications?
AFAIK the most common TDM links are the voice links (and not N*64 or
unstructured).
These are the real apples you need to support over PSN, and that’s why AAL2
is required.

        Regards, 
                Daniel Feldman. 
-----Original Message----- 
From: Amnon Ilan [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, September 12, 2002 11:06 AM 
To: [email-masked]; 'Shahram Davari' 
Cc: [email-masked]; [email-masked]; 'Sasha Vainshtein' 
Subject: RE: [PWE3] (no subject) TDM implementation 
 
Tim, 
AFAIK the most common link is a voice connection (PBX-PBX or PBX-PSTN). 
In such a connection the required solution is AAL2 (mainly in order to 
support 
silence-suppression and per-voice-channel muxing/switching). 
Processing using TDMoIP takes (TDM->PSN): 
       TDM + AAL2 + TDMoIP 
Processing using CESoPSN is problematic here: 
       TDM + AAL2 + .... 
How do you go from AAL1/2 packets to CESoPSN (it can only take TDM), so you 
need: 
       TDM + AAL2 + restructured-TDM + CESoPSN 
These extra steps may also add delay, since you are actually sampling the 
TDM twice. 
Amnon. 
 
-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of 
[email-masked] 
Sent: Wed 11 September 2002 16:46 
To: Shahram Davari 
Cc: [email-masked]; [email-masked]; Sasha Vainshtein 
Subject: RE: [PWE3] (no subject) TDM implementation 
Shahram, 
 
_______________________________________________ 
pwe3 mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/pwe3
<https://www1.ietf.org/mailman/listinfo/pwe3>  
 
_______________________________________________ 
pwe3 mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/pwe3
<https://www1.ietf.org/mailman/listinfo/pwe3>

---

From: Shahram Davari <[email-masked]>
Date: Thu, 12 Sep 2002 08:30:55 -0700

Bob,

> I am 100% in agreement with your last paragraph.
> 
> This is pseudo wire after all, and therefore imho functions 
> for optimising
> things at sub-wire level e.g. silence suppression etc., and 
> payload hand-off
> mappings / NSP functions are out of scope within PWE3.
> 

This is like closing your eyes and not seeing the big picture.

Yours,
-Shahram

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 12 Sep 2002 11:58:54 -0400

Shahram,

	No, it is not like closing your eyes and not seeing the
big picture.  It is like realizing that the purpose of a lens
is _not_ to interpret color...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> Sent: Thursday, September 12, 2002 11:31 AM
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]; Sasha Vainshtein

---

From: Shahram Davari <[email-masked]>
Date: Thu, 12 Sep 2002 09:06:22 -0700

Eric,

What If I invent a lens that can also interpret color?

-Shahram

> From: Gray, Eric [mailto:[email-masked]]
> Sent: Thursday, September 12, 2002 11:59 AM
> To: Shahram Davari
> Cc: [email-masked]; Sasha Vainshtein; [email-masked]';
> [email-masked]

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 12 Sep 2002 12:13:07 -0400

Shahram,

	It will perhaps be useful in some applications - possibly 
not very interesting to me (distorted cinematography?) - and a 
lot more than I need (or even want) in any other application.
But I suspect you realized this as you were asking the question.

	:-)

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> Sent: Thursday, September 12, 2002 12:06 PM
> To: 'Gray, Eric'

---

From: "Bob Barrett" <[email-masked]>
Date: Fri, 13 Sep 2002 14:17:51 +0100

Shahram

You would make a lot of money on the patent, but it would be out of scope
for the CCD detector study group ;-). I wouldn't want that type of lens in
my spectacles.

I prefer to think of my approach more as separating the variables (selective
squint) so that individual functions can be standardised / optimised and
then the blocks fitted together by implementers to make application specific
systems / products.

Bob

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: 12 September 2002 17:06
To: 'Gray, Eric'
Cc: [email-masked]; Sasha Vainshtein; [email-masked]';
[email-masked]

Eric,

-Shahram