Subject: RE: Response to Ron Cohen's comments on control words

From: "Ron Cohen" <[email-masked]>
Date: Mon, 25 Nov 2002 16:14:29 +0200

Yaakov,

> Ron said that in his opinion there is no reason
> for layer-one and layer-two services to use the same control word.

Indeed.

The SONET emulation service has a different set of requirements, and
therefore the CW looks different from the Ethernet one. The current
defined CW provides all the required functionality and is efficient, has
been implemented by many vendors which are happy with its current
definition. There should be a stronger reason than "A single WG need a
single CW" or "The fields are not byte aligned" to do the change. 

Please see below for a more detailed answer to a selected set of the
finest points you raise. 

> In any case, people using SONET frames to transport
> single T1/E1 trunks as in the SONET-VT draft
> seem not to be overly worried about high overhead.

How should I answer this...  Well, first, the extended header is used
for fractional STS-1/VC-3/VC-4 encapsulation, were multiple T1/E1 are
carried within an STS-1/VC-3/VC-4 container, while the other unequipped
T1/E1s are suppressed. That is, this encapsulation is the most bandwidth
efficient encapsulation for carrying multiple T1/E1 across a PSN. If
there was no concern about high overhead, there was no need for this
encapsulation and one could always carry the entire STS-1 container.

> Why should a single WG suggest two different CWs?

Because there are different requirements. 

> The only case where the CEP header makes any sense is when
> there is a structure pointer, which is not all layer 1 services.
> However, CESoPSN and uCESoPSN (which do not have structure pointers)
> have adopted this CW as well, in order to unify implementations. 
> So this format is influencing non-SONET drafts as well.

Yes, we thought that it would be a good thing to have unified layer 1
CW, don't you think?  In layer 1 emulation logic, there are
commonalities in the way CW is handled. The sequence number is used for
insertion to the jitter buffer, the AIS and RDI indications are used to
indicate the status of the circuit (in/out of packet synchronization),
the DBA mode indicates that the payload is suppressed,  the layer 1
services use a constant length payload and therefore don't require a
length field, all this is different from layer 2 services. There are
people that do build common logic for layer 1 services, and it seems
appropriate to do a unified CW. A real need, not a philosophical one.

> Ron further stated that layer 1 services could NOT use the 
> Martini CW.  
> TDMoIP is a layer 1 transport service and DOES use the Martini CW.

I didn't hear myself say that, but I may be wrong, and to guard against
future mistakes, I hereby state that TDMoIP can do anything.

Regards
Ron

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 25 Nov 2002 13:06:47 -0500

Ron hit the nail on the head when he said:

>commonalities in the way CW is handled. ...
>  A real need, not a philosophical one.

I know the list is the final arbiter, but for the info of those of you not 
in Atlanta, I saw general consensus in the room to keep the control words 
intact.

Cheers,
Andy

---

From: Alex Conta <[email-masked]>
Date: Tue, 26 Nov 2002 14:26:15 -0500

This list is quite animated; I wish I had the time needed to follow it
closely. As I am interested in the TDM encapsulation, I was glad to see
at the IETF meeting -- Yaakov's presentation -- that finally a consensus
developed.

Ron Cohen wrote:
> therefore the CW looks different from the Ethernet one. [...]
>  

As I am interested and am looking at PWE3 as one technology, I think you
are in fact referring to a subset of requirements. In that regard, I
think you are right, that the several subsets may be distinct. But, I
think, there is an inherent set of requirements for the PWE3 WG,
inclusive of the distinct subsets, and the need to provide a
consistent/coherent architecture and set of mechanisms. 

> [...]

Regards,
Alex