Subject: What I like about draft-vainshtein-cesopsn-06

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 23 Jun 2003 17:34:02 +0300

I bet that subject line really got your attention!

Seriously now, I think that the latest version
has some very good features.

We have the option to send T1s without padding
(although we have to minor the minor price of 1 milli delay)

We finally have the option of suppressing RTP when it is not needed
(e.g. when both sides have good clocking).

I have thinking about this development for the past few days,
and believe we now have enough overlap between
CESoPSN, TDMoIP and simple raw bit-stream implementations,
to make a mode that everyone can accept.

I call this mode STPP for "Simple TDM Pseudowire Protocol".

Its basic definition is simple :

  1) no RTP (it's only for simple cases where clock is available)
  2) unstructured (no bit or byte alignment implied)
  3) default packet size
         T1: 8 frames (193 bytes)
         E1: 4 frames (128 bytes)
         E3: 1 frame (537 bytes)
         T3: 1 frame (699 bytes)
     MUST be supported, but ANY length may be used
     if both sides agree. 
     In particular, for interworking with existing 
     CES networks n*47 MAY be used.

This may not solve all TDM problems,
but it solves a good fraction of them - 
at least all those where we can assume
loop-back timing at the ends 
and very low packet loss and packet delay variation.

I haven't had much time to discuss this
with the sword of the IETF draft-xxx-00 deadline
over my head, but Amnon from MRV was kind enough to
help me with writing up a draft, and several
others, notably Alex from TranSwitch,
have contributed as well.

Until it makes it to the IETF site
you can see the STPP draft at 
http://www.dspcsp.com/tdmoip/draft-stein-pwe3-stpp-00.txt

(Technical) comments are welcome.

Y(J)S

---

From: Alik Shimelmits <[email-masked]>
Date: Mon, 23 Jun 2003 20:47:46 +0200

Yaakov,

I understand that you are OK with the CESoPSN approach 
with regard to emulation of unstructured services and your
objections are limited to emulation of structured services.
Thanks for clarifying your position.

Somehow I am not surprised since you are one of the co-editors 
of the old draft-vainshtein-pwe3-ucesopsn-00.txt (still available 
at the IETF Web site) that is almost identical to
the STTP proposal and has been incorporated with minimal changes 
into CESoPSN-06. 

To the best of my understanding the technical differences between
CESoPSN-06 and STTP drafts are limited to the following:

1. The STTP draft does not allow RTP header, while the CESoPSN one
introduces it but allows to suppress it if both sides agree.
Functionally this means that the CESoPSN draft supports more
synchronization scenarios at no cost.

2. The CW of the two drafts differs wrt bit positions and the
size of the sequence number.

3. CESoPSN defines the mandatory packet delay for E1 as 1 ms,
   STTP reduces it to 0.5 ms. It also makes the defaults mandatory

All these points can be easily addressed during the discussions in 
the working group towards a WG solution.

4. CESoPSN covers structured services, STTP does not.

With best regards
	Alik

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

---

From: Shahram Davari <[email-masked]>
Date: Mon, 23 Jun 2003 11:27:35 -0700

Alik,

>synchronization scenarios at no cost.

Are you saying that RTP processing is free?

>size of the sequence number.

But the STPP uses the same format as Martini, while CESoPSN doesn't.
To me having the same format as Martini is a positive factor. 

>   STTP reduces it to 0.5 ms. It also makes the defaults mandatory

Off course the default should be mandatory to support, otherwise what is the
point of any default value?

>4. CESoPSN covers structured services, STTP does not.

I think that is the MAIN idea. Yaakov and many others think there is
consensus on the unstructured service, while such consensus does not
exist for structured service. So why holdup the implementers that want
to implement unstructured service (some say it is the majority of service).

Yours,
Shahram

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 24 Jun 2003 08:22:48 +0300

Alik, 

> the STTP proposal and has been incorporated with minimal changes 

Exactly so.  
But uCESoPSN did not gain support for various reasons. 
I still think the basic ideas were right, 
but perhaps the details and presentation weren't.
 
> synchronization scenarios at no cost.

Allowing RTP and then allowing it to be suppressed
just adds more baggage, and when this advances
the RFC 2026 process will require interoperable 
implementations to either support RTP or to have
it removed from the draft. I chose the former.
As I have said on numerous occassions, RTP does
not help attain G.823/824 timing compliance
in the absence of loop-back timing,
and when there is loop-back timing it is certainly
not required. So let's leave excess baggage out.

> size of the sequence number.

I chose the standard PWE CW.
I understand that the SONET draft needs the extra
room in the CW for a structure pointer
and has been given indulgence on this matter.
Likewise, I went along with the nonstandard word
for the early stages of Johnson's draft,
since at the time he too used a structure poionter.
But when no pointer is needed, we should keep
to the standard CW.

>    STTP reduces it to 0.5 ms. It also makes the defaults mandatory

Using 1 ms is a reasonable compromise for T1, 
since less than that won't allow one to
sync bytes (for those who need to).
E1 is always bytes and there is no need for so long a delay.

> 4. CESoPSN covers structured services, STTP does not.

That is the MAIN difference, and an important one.

At this point I avoid the word unstructured
since it causes too much confusion - uCESoPSN
and STTP can transport structured TDM streams -
in fact it doesn't know what the streams are.
The difference is only whether the protocol
exploits the structure. Too many people have
misunderstood this issue. Let's call what
uCESoPSN and STTP do, BASIC TDM service.

As you will recall we had reached agreement
a while ago, that we would let people who only
needed basic service to do something simple.
I have simply taken this to the extreme.
Let people push raw bits (which is what most
implementations do anyway). In order to try
to get Axerra's support, I put in the defaults
that make you happy (from my point of view
I would have prefered defaulting to a constant
128 bytes).

> the working group towards a WG solution.

As long as we realize that this is ONLY
a basic mode, and not a complete solution,
then I am sure we can come up with a simple
solution that will satisfy most of the people.

We will still need the full solution for the
harder cases.

Y(J)S