Subject: TDM types and their implications

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 17 Sep 2002 10:54:52 +0300

Sasha, Shahram, Tim, Tom, Andy, Bob, etc.

I would like to suggest a possible division of the TDM space,
on the basis of which reasonable recommendations
regarding the non-SONET case can be made.

In the past, e.g. the riegel-requirements draft,
the break-down of TDM types has not been completely satisfactory,
so I would like to propose the following classification.

The list represents an "inclusion" relationship,
with each item being a superset of the following ones.

A) (simple) bit stream
B) framed TDM
C) channelized (AKA structured) TDM
D) structured with CAS

Explanations:

A) A (simple) bit stream is a serial signal conforming to G.702/G.703.
For example a T1 is considered a raw 1.544 Mbps bit stream,
with no special meaning to the framing bit. 
There is thus no meaning to bit alignment in bytes or in frames.
This is the only meaningful characterization for "unframed" lead-line services, 
but any TDM stream, even a completely structured one, 
could be considered a bit stream of this type.

B) A framed TDM stream is one which has synchronization
(e.g. the framing bit of the T1 and timeslot 0 of an E1)
as described in G.704 sections 1 and 2,
but not necessarily any other structure.
A framed T1 has only 24*8*8Kbps = 1.536 Mbps
and a framed E1 has only 31*8*8Kbps = 1.984 Mbps
available for data.
For framed TDM there is meaning to bit alignment in bytes
and byte alignment in frames.

C) A channelized/structured TDM stream 
is framed AND has defined 8-bit channels,
as defined in G.704 sections 3-6.
When there are voice channels this is the natural representation,
although for PW transport even voice-carrying TDM
could be considered to be a framed TDM stream 
or even a simple bit stream.

D) The most complex structure is called "structured with CAS"
in the ATM literature. It is similar to channelized/structured, but
in addition to the frame structure there is multiframe
(or superframe) structure as well.

With these definitions in hand, 
we can now try to map the various TDM types to PW transport mechanisms.
My suggestion is to ensure robustness by requiring a transport method
that matches the most specific level of the particular TDM stream,
but to allow more general methods.

Hence, for A) general bit stream, we can do no better than to 
chop the bit stream into segments of an arbitrary (but constant) number of bytes
and encapsulate these. No bit alignment or frame integrity is needed,
but the packets MUST contain a constant number of bits
for timing recovery in the presence of packet loss.
The number of bytes per packet may be required to match
the capabilities of end-use equipment, e.g. 32, 47, 783, etc.
We will call this method BIToPSN from here on.
Although it has been suggested several times
there is as yet no I.D. officially proposing it.

For B) framed bit streams, one MUST be able to chop the bit stream
into segments of integral multiples of frames,
and maintain frame integrity. This is CESoPSN.
Of course, one MAY use BIToPSN,
but one loses the ability to distinguish frame-start,
which is useful in this context.

For C) channelized (structured ) TDM, there are two methods
based on whether the timeslots are dynamically allocated.
The TDMoIP draft supports both and MUST be available for this case.
Of course one MAY use CESoPSN or even BIToPSN,
but one loses the ability to quickly extract individual timeslots,
which is useful during packet loss, or if other NSP functions
are required (e.g. monitoring of in-band signaling).
If CESoPSN is used for T1 one SHOULD use
initial-padding rather than T1-in-E1 according to G.802
(unless interfacing with G.802-compliant equipment).

One exception to the above statement is framed T3/E3 signals.
These, although having structure,
SHOULD always be handled using CESoPSN.
This is because in PDH signals
the incorporated channels have different clocks,
the handling of which is beyond the scope of PWE.

Finally, for "structured with CAS" TDMoIP MUST be available,
but CESoPSN MAY be used - in which case one SHOULD
use the entire multiframe as the packet length
(unless the latency is intolerable).
Of course, BIToPSN MAY be used as well.

Any comments?

Y(J)S

Yaakov (Jonathan) Stein        [email-masked] 
Chief Scientist                        +972 3 6455389   +972 2 5889159
RAD Data Communications   24 Raoul Wallenburg St., Tel-Aviv 69719, Israel 
Have you read my book yet ? <http://www.dspcsp.com/> <http://www.amazon.com/exec/obidos/ASIN/0471295469/>

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 17 Sep 2002 12:03:25 +0200

Yaakov and all,
Taking aside (for the moment) the partitioning proposal (i.e., various
MUSTs, SHOULDs etc.), I'd like to point to what looks to me a
misunderstanding of what CESoPSN does or does not. So please see some
comments (inline) that refer to specific cases of such a misunderstanding.
Hopefully, these comments wil be helpful.
 
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: Yaakov Stein [mailto:[email-masked]]
Sent: Tuesday, September 17, 2002 9:55 AM
To: [email-masked]
Subject: [PWE3] TDM types and their implications

A) (simple) bit stream

B) framed TDM

D) structured with CAS

Explanations:

This is the only meaningful characterization for "unframed" lead-line
services, 

available for data.

chop the bit stream into segments of an arbitrary (but constant) number of
bytes

[[Sasha]] If you put aside the (IMHO, rather vague) requirement to keep the
number of bytes per packet so that they "match the capabilities of the
end-use equipment", this is exactly what the CESoPSN does for unstructured
E1, E3 and DS3 . It imposes only one limitation - keep the number of bytes a
multiple of what the bit-stream contains within 125 microseconds (without
any requirement for alignment with the frame structure if it exists within
the stream). Since T1 contains 193 bits within the 125 microseconds, it
requires some padding but still no alignment. 

I also do not understand what do you mean by "end-use equipment" - there is
no such element in the PWE3 reference model

[[Sasha]] Unstructured CESoPSN does not maintain frame integrity (i.e., an
unstructured CESoPSN packet does not contain an integral multiple of frames,
just an integral multiple of 125 microsecond samples (even if these are
called native service frames in the text).

[[Sasha]]  Structured CESoPSN allows to access individual timeslots easy
enough, since the first timeslot in the bundel is locked to the packet
payload boundary. However, it does not handle dynamic allocation of
timeslots.

[[Sasha]]  From my point of view, G.802 is performed in the PE, not in the
CE. And i do not understand what your reference to the G.802-compliant
equipment means. And it is used for carrying unstructured = unframed T1, so
I do not understand your reference to it at this point.

[[Sasha]]  Sorry, I do not understand you. You have just introduced the
difference between framed and structured in this very message, and now you
mention structured = channelized E3 and DS3 under the headline framed. And
CESoPSN does not handle framed E3 and DS3 either (for better or worse).
IMHO, no specific handling of structured E3 or DS3 is required (for the
reason you have mentioned). Handling of bundles of asynchronous E1 or T1 in
a single PW can be done using SONET-VT.

Any comments?

Y(J)S

Have you read my book yet ? < http://www.dspcsp.com/
<http://www.dspcsp.com/> > <
http://www.amazon.com/exec/obidos/ASIN/0471295469/
<http://www.amazon.com/exec/obidos/ASIN/0471295469/> >

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 17 Sep 2002 14:00:26 +0300

Sasha, 
 
I don't see any misunderstanding,
just a slightly different interpretation of what to do with the various modes.
 
[Sasha] If you put aside the (IMHO, rather vague) requirement to keep the number of bytes per packet so that they "match the capabilities of the end-use equipment", this is exactly what the CESoPSN does for unstructured E1, E3 and DS3 . It imposes only one limitation - keep the number of bytes a multiple of what the bit-stream contains within 125 microseconds (without any requirement for alignment with the frame structure if it exists within the stream). Since T1 contains 193 bits within the 125 microseconds, it requires some padding but still no alignment.  
 
The BIToPSN is slightly more general - it doesn't require the number of bytes to be a multiple
of the frame size. Of course, CESoPSN is a special case of BIToPSN. 
 
[Sasha]  I also do not understand what do you mean by "end-user  equipment" - there is no such element in the PWE3 reference model 
 
Yes, but end-users have it anyway.

[Sasha] Unstructured CESoPSN does not maintain frame integrity (i.e., an unstructured CESoPSN packet does not contain an integral multiple of frames, just an integral multiple of 125 microsecond samples (even if these are called native service frames in the text). 
 
Once again we are simply using different terms.
What you are calling here "unstructured" is what I defined as unframed.
What you call "integral multiple of 125 microseconds"
is what I called "an integer multiple of frames".
 
We do not disagree.
 
[Sasha]  Structured CESoPSN allows to access individual timeslots easy enough, since the first timeslot in the bundel is locked to the packet payload boundary. However, it does not handle dynamic allocation of timeslots.
which is useful during packet loss, or if other NSP functions
are required (e.g. monitoring of in-band signaling). 
 
This has been the subject of several recent emails,
and I do not want to go into it again.
 
[Sasha]  From my point of view, G.802 is performed in the PE, not in the CE. And i do not understand what your reference to the G.802-compliant equipment means.  
And it is used for carrying unstructured = unframed T1, so I do not understand your reference to it at this point. 
 
Once again, please read my email and see how I am usnig unframed
vs unstructured. By G.802-compliant equipment I mean that your end user
is doing G.802 T1-in-E1 and so you should too.
I would gladly remove this and use initial-padding instead !
 
[ Sasha]  Sorry, I do not understand you. You have just introduced the difference between framed and structured in this very message, and now you mention structured = channelized E3 and DS3 under the headline framed. And CESoPSN does not handle framed E3 and DS3 either (for better or worse).  
 
I was giving you this one, and you seem not to want to take it.
Yes, E3/T3 can be unframed, or framed or framed and structured.
I just said that even if structured=channelized, I think CESoPSN
is OK.
 
[Sasha]  IMHO, no specific handling of structured E3 or DS3 is required (for the reason you have mentioned).  
 
Fine, we agree.
 
[Sasha] Handling of bundles of asynchronous E1 or T1 in a single PW can be done using SONET-VT. 
 
At a very high expense for someone who doesn't have SONET equipment.
 
Y(J)S

---

From: [email-masked]
Date: Tue, 17 Sep 2002 15:03:24 +0100

Let's not get lost in the detail here, we seem to be so close to a real 
compromise.

The general tenor of the proposal is:

                   Preferred method   Alternatives
Unstructured          BIToPSN
Unframed              CESoPSN           BIToPSN
Channelized           TDMoIP (AAL1)     CESoPSN, BIToPSN
Structured with CAS   TDMoIP (AAL1)     CESoPSN, BIToPSN
Dynamic Channelized   TDMoIP (AAL2)     none
  (with/without CAS)

I've discussed these options with various people during the course of last 
week, and I believe this is a reasonable compromise. I see two main 
classes of applications: 

1. Those that only send complete T1/E1/T3/E3 over the PSN. These will use 
either the unstructured or unframed approach, and hence the preferred 
method is BIT/CESoPSN. Most probably this will be central office 
equipment, and therefore high density, high performance.

2. Those that are concerned with individual DS0s, and these will use 
TDMoIP as the preferred method. Much of this will be customer premise 
equipment, and hence fairly low density.

As I see it, much equipment concerned with emulation of entire T1/E1/T3/E3 
will not do channelized/structured emulation at all, and therefore will 
not need to handle TDMoIP. The reverse will also be true. This leaves only 
a small subset of equipment that will have to handle both.

Of course there are details to sort out, and I'm sure people will quibble 
over these. But if we lose the big picture for the sake of the detail, we 
will never get a standard, and this will seriously inhibit the market for 
this type of service.

Regards,
Tim

"Yaakov Stein" <[email-masked]>
Sent by: [email-masked]
17-Sep-2002 12:00 PM

        To:     "Alexander Vainshtein" <[email-masked]>
        cc:     "PWE3 WG (E-mail)" <[email-masked]>
        Subject:        RE: [PWE3] TDM types and their implications

Sasha, 
 
I don't see any misunderstanding,
just a slightly different interpretation of what to do with the various 
modes.
 
[Sasha] If you put aside the (IMHO, rather vague) requirement to keep the 
number of bytes per packet so that they "match the capabilities of the 
end-use equipment", this is exactly what the CESoPSN does for unstructured E1, E3 and DS3 . It imposes only one limitation - keep the number of bytes a multiple of 
what the bit-stream contains within 125 microseconds (without any 
requirement for alignment with the frame structure if it exists within the 
stream). Since T1 contains 193 bits within the 125 microseconds, it 
requires some padding but still no alignment. 
 
The BIToPSN is slightly more general - it doesn't require the number of 
bytes to be a multiple
of the frame size. Of course, CESoPSN is a special case of BIToPSN. 
 
[Sasha]  I also do not understand what do you mean by "end-user equipment" 
- there is no such element in the PWE3 reference model 

[Sasha] Unstructured CESoPSN does not maintain frame integrity (i.e., an unstructured CESoPSN 
packet does not contain an integral multiple of frames, just an integral multiple of 125 microsecond samples (even if these are called native service frames in the text). 

We do not disagree.
 
[Sasha]  Structured CESoPSN allows to access individual timeslots easy enough, since the first 
timeslot in the bundel is locked to the packet payload boundary. However, 
it does not handle dynamic allocation of timeslots.
which is useful during packet loss, or if other NSP functions
are required (e.g. monitoring of in-band signaling). 

[Sasha]  From my point of view, G.802 is performed in the PE, not in the 
CE. And i do not understand what your reference to the G.802-compliant 
equipment means. 
And it is used for carrying unstructured = unframed T1, so I do not understand your reference to it at this point. 

[ Sasha]  Sorry, I do not understand you. You have just introduced the 
difference between framed and structured in this very message, and now you mention structured = channelized E3 and DS3 under the headline framed. And CESoPSN does not handle framed E3 and DS3 either (for better or worse). 

 
Fine, we agree.

 
Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 17 Sep 2002 17:28:23 +0300

Tim, 

I am glad that you think that this is a reasonable compromise.

I am interested in knowing how many people are interested 
in the "BIToPSN" method.
If interest is low we may choose to use only CESoPSN
(although this will require zero-padding of T1s).

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 18 Sep 2002 09:30:48 +0200

Yaakov,
Please see more comments inline.
The bottom line: I do not think that "unframed" vs. "unstructured" is
justified in any way. And, unfortunately, your responses do not help to
understand the difference between the two - assuming that it exists, which I
doubt.
 
With best regards,
                                   Sasha Vainshtein

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Tuesday, September 17, 2002 1:00 PM
To: Alexander Vainshtein
Cc: PWE3 WG (E-mail)
Subject: RE: [PWE3] TDM types and their implications

Sasha, 

 
The BIToPSN is slightly more general - it doesn't require the number of
bytes to be a multiple
of the frame size. Of course, CESoPSN is a special case of BIToPSN. 
 [Sasha] What is the added value of an arbitrary size of bytes per packet? I
do not see any.

Yes, but end-users have it anyway.
[Sasha] No one argues with that. However, it would be nice to understand the
place of this element in the general picture. One of your comments below
suggests that the "end-user" equipment is a CE, in which case the size of
the packet payload on the PW should be of no interest. Can you please
clarify?  
 
[Sasha] Unstructured CESoPSN does not maintain frame integrity (i.e., an
unstructured CESoPSN packet does not contain an integral multiple of frames,
just an integral multiple of 125 microsecond samples (even if these are
called native service frames in the text). 

We do not disagree.
 [Sasha] I think we do. You have said - in your original message - that
there is some meaning in "bit alignment to bytes and byte alighnment to
frames". Which frames do you mean here? Since you mention G.704 in your
definition, I would assume G.704 frames and not any consecutive 125
microseconds' samples. 
[Sasha]  Structured CESoPSN allows to access individual timeslots easy
enough, since the first timeslot in the bundel is locked to the packet
payload boundary. However, it does not handle dynamic allocation of
timeslots.
which is useful during packet loss, or if other NSP functions
are required (e.g. monitoring of in-band signaling). 

[Sasha]  From my point of view, G.802 is performed in the PE, not in the CE.
And i do not understand what your reference to the G.802-compliant equipment
means.  
And it is used for carrying unstructured = unframed T1, so I do not
understand your reference to it at this point. 
 
Once again, please read my email and see how I am usnig unframed
vs unstructured. By G.802-compliant equipment I mean that your end user
is doing G.802 T1-in-E1 and so you should too.
I would gladly remove this and use initial-padding instead !
 [Sasha] If your "framed" definition means "carry the entire E1 (32
timeslots) or T1 (the F-bit and 24 timeslots) but provide some kind of
alignment between these structures and the packets, this is what CESoPSN
does not do, nor intends to. I do not see any "added value" in such a
service when compared to what you call "unframed". Can you please explain
(assuming that my interpretation of your text is correct), why is it ever
needed? 
[ Sasha]  Sorry, I do not understand you. You have just introduced the
difference between framed and structured in this very message, and now you
mention structured = channelized E3 and DS3 under the headline framed. And
CESoPSN does not handle framed E3 and DS3 either (for better or worse).  

 
[Sasha]  IMHO, no specific handling of structured E3 or DS3 is required (for
the reason you have mentioned).  
 
Fine, we agree.
 
[Sasha] Handling of bundles of asynchronous E1 or T1 in a single PW can be
done using SONET-VT. 
 
 [Sasha] Which equipment?
Y(J)S

---

From: "Bob Barrett" <[email-masked]>
Date: Wed, 18 Sep 2002 15:07:30 +0100

Sasha

You'll see my reply to Yaakov. My thinking is pretty much aligned with yours
except that I see the clear channel mechanism being the same as the
structured, except that the start of the sampling window is at an arbitary
point in the TDM stream. The base standard and therefore the base
implementation is identical, except that the frame recognition function is
disabled for clear channel.

Knowing that the TDM streams (particularly the clear channel ones) can be
using a clock of +/-50ppm (not all circuits are voice sync'd to a stratum
clock, some can be private circuits with user clocks), I prefer to think not
in terms of 125us, but in terms of 256 bits times or 193 bit times. This
aligns with what Yaakov calls "an integer multiple of frames".

SV> Handling of bundles of asynchronous E1 or T1 in a single PW can be done
using SONET-VT.

This can also be done using standard M13 functions e.g. G.747 for 3xE1 into
virtual T2. There are other G.7nn specs for 7xT2 into T3 (where the virtual
T2s can be carrying 3xE1 or 4xT1). ICs exist that do all of this, and these
have been used in many M13 multiplexers. However, I think the granularity is
limited i.e. the virtual T2s cannot be extracted and sent over a PSN. It has
to be the whole T3. The T3 can be treated as unstructured with the bits just
re-assembled at the egress, with the hand-off being the T3 or recovered
T1/E1, either of which could interface to Sonet via an NSP function.

Thanks

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Sasha
Vainshtein
Sent: 17 September 2002 11:03
To: 'Yaakov Stein'
Cc: Alik Shimelmits; Akiva Sadovski; Israel Sasson; PWE3 WG (E-mail)
Subject: RE: [PWE3] TDM types and their implications

Yaakov and all,

With best regards,
                                   Sasha Vainshtein
email:     [email-masked]

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Tuesday, September 17, 2002 9:55 AM
To: [email-masked]
Subject: [PWE3] TDM types and their implications

Have you read my book yet ? <http://www.dspcsp.com/>
<http://www.amazon.com/exec/obidos/ASIN/0471295469/>

---

From: [email-masked] (Amnon Ilan)
Date: Thu, 19 Sep 2002 10:43:07 +0200

Hi all,

I still cannot see why we should mess the operators with several different
protocols. AAL1 is designed to support unstructured streams as well.
Having said that, I do agree with Tim that this is a reasonable compromise.
IMHO there is no need to define the new "unframed" category. CESoPSN can
handle any unstructured stream (so can AAL1, but a compromise is a
compromise...).
In order to make the picture simple, CESoPSN should not define any
support for the structured cases (should support unstructured mode only).
Regarding the use of AAL2: even in cases where the dynamic nature supported
by AAL2 signaling is not required, AAL2 trunking (without signaling) can be
a much better solution in terms of bandwidth efficiency (mainly because it
supports silence-compression and integrates low-bit-rate codecs support).
Hence, even for the "Channelized" and "Structured with CAS" cases, AAL2 can
be better: it is more complicated (and expensive), but it saves costs on the
network infrastructure, making it a more cost-effective solution for large
projects.

To summarize, the picture as I see it:

                      Preferred method
Unstructured          CESoPSN
Channelized           TDMoIP(AAL1 or AAL2) or CESoPSN
Structured with CAS   TDMoIP(AAL1 or AAL2) or CESoPSN
Dynamic Channelized   TDMoIP(AAL2)
  (with/without CAS)

Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Tue 17 September 2002 16:03
To: Yaakov Stein
Cc: PWE3 WG (E-mail); [email-masked]; Alexander Vainshtein
Subject: RE: [PWE3] TDM types and their implications

Regards,
Tim

Sasha,

multiple of

[Sasha] Unstructured CESoPSN does not maintain frame integrity (i.e., an
unstructured CESoPSN
packet does not contain an integral multiple of frames, just an integral
multiple of 125 microsecond samples (even if these are called native service
frames in the text).

We do not disagree.

enough, since the first

Fine, we agree.

Y(J)S

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

---

From: [email-masked]
Date: Thu, 19 Sep 2002 10:07:06 +0100

Amnon,

I agree that there is no need for a separate "unframed" category, I was 
merely trying to represent in a simple table what Yaakov had already 
proposed. The use of CESoPSN will cover the unframed case perfectly well.

As a side note, you state that AAL2 will cover the structured static 
cases, which it will. However, AAL2 requires sending CAS packets in the 
same way as proposed for CESoPSN, so the same criticism would apply to it: 
large software overhead to generate the signalling packets, and reduced 
robustness in the presence of high packet loss. This to my mind is the 
only TECHNICAL advantage AAL1 has over the use of CESoPSN, and an argument 
Yaakov made much of in our discussions at Yokohama.  Therefore I would be 
loathe to give up CESoPSN for the static, structured case to replace it 
with a protocol with no inherent technical advantage, especially one with 
the considerable added complexity of AAL2.

Regards,
Tim

[email-masked] (Amnon Ilan)
19-Sep-2002 09:43 AM
Please respond to ailan

        To:     <[email-masked]>, "'Yaakov Stein'" <[email-masked]>
        cc:     "'PWE3 WG \(E-mail\)'" <[email-masked]>, <[email-masked]>, "'Alexander 
Vainshtein'" <[email-masked]>
        Subject:        RE: [PWE3] TDM types and their implications

Hi all,

I still cannot see why we should mess the operators with several different
protocols. AAL1 is designed to support unstructured streams as well.
Having said that, I do agree with Tim that this is a reasonable 
compromise.
IMHO there is no need to define the new "unframed" category. CESoPSN can
handle any unstructured stream (so can AAL1, but a compromise is a
compromise...).
In order to make the picture simple, CESoPSN should not define any
support for the structured cases (should support unstructured mode only).
Regarding the use of AAL2: even in cases where the dynamic nature 
supported
by AAL2 signaling is not required, AAL2 trunking (without signaling) can 
be
a much better solution in terms of bandwidth efficiency (mainly because it
supports silence-compression and integrates low-bit-rate codecs support).
Hence, even for the "Channelized" and "Structured with CAS" cases, AAL2 
can
be better: it is more complicated (and expensive), but it saves costs on 
the
network infrastructure, making it a more cost-effective solution for large
projects.

                      Preferred method
Unstructured          CESoPSN

Amnon.

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 19 Sep 2002 13:54:34 +0200

Bob and all,
Please see some comments inline.

> From: Bob Barrett [mailto:[email-masked]]
> Sent: Wednesday, September 18, 2002 4:08 PM
> To: Sasha Vainshtein; 'Yaakov Stein'
As far as I understand Yaakov has suggested to consider 
two different "TDM types"  - unframed and unstructured. 
But IMHO these two types do not exist in the TDM application
space. On the other hand, the PW-based implementations 
may differ, and one may consider specific merits and de-merits 
of approaches based upon alignment of the packetizer 
to the 8 KHz clock ("unstructured?") and lack thereof 
("unframed?")
> aligns with what Yaakov calls "an integer multiple of frames".
IMHO, the 8KHz clock (or a 125 microsecond sample) is the basic
notion of all the TDM technologies starting from DS0 and up to SONET.
The fact that the clock frequencies may actually differ requires
special justification mechanisms for the situations when you want
to "bundle" streams with different clocks, but does not change the basic
nature of the notion. This is why packetization mechanisms that are 
"aligned" with the 8KHz clock have certain advantages. 
... skipped to the end ...

With best regards,
                                   Sasha Vainshtein

---

From: "Bob Barrett" <[email-masked]>
Date: Mon, 23 Sep 2002 14:19:03 +0100

Sasha Vainshtein wrote in response to Bob Barrett:

RB: In my experience the private circuits are almost always point to point,
so there is little to be gained by bundling them. If they are to be bundled
for trunking long haul then the trunk is likely not to be over PSN, more
likely Sonet / SDH or PDH. If over PSN then some NSP equipment will probably
be used for grooming and aggregation.

Putting a 125us constraint on a private circuit over PSN (forcing the use of
justification bits) looks line an unnecessary complication of CESoPSN to me.
For circuits that are carrying voice 125us is there by default, the 8kHz
being derived from the sync pattern which is linked directly to 'bit rate'
of the received stream. My suggestion is to use the 256xbit rate of the
stream (193x for T1) for the time base, which, for a PSTN is 125us, but for
a private circuit is +/- 50ppm of the line rate (E1).

This eliminates the complication of justification bits which are a legacy of
PDH bundling and don't really have a place in circuit over packet (imho). I
am of the school of thought that sees bundling / aggregation as an NSP issue
and not a PWE3 issue (and justification etc. is a bundling issue).

Best regards

Bob

-----Original Message-----
From: Sasha Vainshtein [mailto:[email-masked]]
Sent: 19 September 2002 12:55
To: [email-masked]'; 'Yaakov Stein'
Cc: Alik Shimelmits; Akiva Sadovski; Israel Sasson; PWE3 WG (E-mail)
Subject: RE: [PWE3] TDM types and their implications

Bob and all,

With best regards,
                                   Sasha Vainshtein

---

From: "Ron Cohen" <[email-masked]>
Date: Mon, 23 Sep 2002 18:23:21 +0200

Bob

> I am of the school of thought 
> that sees bundling / aggregation as an NSP issue and not a 
> PWE3 issue (and justification etc. is a bundling issue).

Along your line of thought, if you want to bundle, have an NSP function
that bundle the T1s into SONET and do SONET emulation across the PSN.

Ron

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bob Barrett
> Sent: Monday, September 23, 2002 3:19 PM
> IMHO, the 8KHz clock (or a 125 microsecond sample) is the 
> basic notion of all the TDM technologies starting from DS0 
> and up to SONET. The fact that the clock frequencies may 
> actually differ requires special justification mechanisms for 
> the situations when you want to "bundle" streams with 
> different clocks, but does not change the basic nature of the 
> notion. This is why packetization mechanisms that are 
> RB: In my experience the private circuits are almost always 
> point to point, so there is little to be gained by bundling 
> them. If they are to be bundled for trunking long haul then 
> the trunk is likely not to be over PSN, more likely Sonet / 
> SDH or PDH. If over PSN then some NSP equipment will probably 
> Putting a 125us constraint on a private circuit over PSN 
> (forcing the use of justification bits) looks line an 
> unnecessary complication of CESoPSN to me. For circuits that 
> are carrying voice 125us is there by default, the 8kHz being 
> derived from the sync pattern which is linked directly to 
> 'bit rate' of the received stream. My suggestion is to use 
> the 256xbit rate of the stream (193x for T1) for the time 
> base, which, for a PSTN is 125us, but for a private circuit 
> is +/- 50ppm of the line rate (E1).
> 
> This eliminates the complication of justification bits which 
> are a legacy of PDH bundling and don't really have a place in 
> circuit over packet (imho). I am of the school of thought 
> that sees bundling / aggregation as an NSP issue and not a 
> PWE3 issue (and justification etc. is a bundling issue).
> 
> Best regards
> 
> Bob
> 
> > You'll see my reply to Yaakov. My thinking is pretty much 
> aligned with 
> > yours except that I see the clear channel mechanism being 
> the same as 
> > the structured, except that the start of the sampling window is
> > at an arbitary
> space. On the other hand, the PW-based implementations may 
> differ, and one may consider specific merits and de-merits of 
> approaches based upon alignment of the packetizer to the 8 
> KHz clock ("unstructured?") and lack thereof
> ("unframed?")
> >
> > using a clock of +/-50ppm (not all circuits are voice sync'd to a 
> > stratum clock, some can be private circuits with user clocks), I
> > prefer to think not
> IMHO, the 8KHz clock (or a 125 microsecond sample) is the 
> basic notion of all the TDM technologies starting from DS0 
> and up to SONET. The fact that the clock frequencies may 
> actually differ requires special justification mechanisms for 
> the situations when you want to "bundle" streams with 
> different clocks, but does not change the basic nature of the 
> notion. This is why packetization mechanisms that are

---

From: "Bob Barrett" <[email-masked]>
Date: Mon, 23 Sep 2002 20:23:13 +0100

Ron

I agree with you wrt to bundling using Sonet (or the carrier's preferred
method) across the metro/core PSN, if bundling is justified by the cost
model.

My calculations don't show a significant saving in PSN bandwidth for
aggregated PWE3 traffic against individual circuits (less than 10%), and
when the bearer is 1GE (or greater) saving a few megs is hard to cost
justify against the scalability argument of carrying a circuit per PWE3
stream. The only benefit of aggregation (imho) is to simplify the
interconnect / hand-off back to circuits, and that can be done with the NSP
function.

My concern (regarding the 'use justification or not' issue) is keeping it
simple in the access / metro edge, where the physical topology is likely to
be hub and spoke (even if it is logical ring) and the number of circuits per
PSN span/spoke is typically low i.e. from one circuit upward. The NSP
aggregation function can sit at the hub site, or the SP can choose to carry
all the Circuit Em. traffic in the same PWE3 format as it originates back to
some more central NSP aggregation point or CO switch.

I guess the SP 'last mile' topologies in Europe differ from the US. We don't
have the same high proportion of business located in MTU TSBs, and we have a
lot of fiber in the last mile already.

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Ron
Cohen
Sent: 23 September 2002 17:23
To: [email-masked]; 'Sasha Vainshtein'; 'Yaakov Stein'
Cc: 'Alik Shimelmits'; 'Akiva Sadovski'; 'Israel Sasson'; 'PWE3 WG
(E-mail)'
Subject: RE: [PWE3] TDM types and their implications

Bob

Ron

---

From: "tom k. johnson" <[email-masked]>
Date: Mon, 23 Sep 2002 18:15:25 -0400

Tim - 

(Sorry, for joining in late, I was on travel and couldn't keep up on the thread...)

My preference would be one very simple way to carry this type of traffic as a bare minimum, and then add optional modes of operation as necessary.  How can you have interoperability without an agreed upon baseline of functionality?

The simplist thing I can think of is just to take every bit as it comes in off the line and put it in a packet.  Add a header with a sequence number, a PSN header, and ship it.  No need to know anything about the bit-stream.

We can use RTP if we need to do timing recovery.

Obviously, we can add special modes on top of that to take advantage of the underlying structure (DS1, E1, DS3, E3, J2, etc.) as described by the Sasha, Yaakov, and others, but why not just agree on something like that as a baseline?

What do you think?

-Tom

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, September 17, 2002 10:03 AM
> To: Yaakov Stein
> end-use equipment", this is exactly what the CESoPSN does for 
> unstructured E1, E3 and DS3 . It imposes only one limitation 
> - keep the number of bytes a multiple of 
> packet does not contain an integral multiple of frames, just 
> an integral multiple of 125 microsecond samples (even if 
> these are called native service frames in the text). 
>  
> And it is used for carrying unstructured = unframed T1, so I 
> do not understand your reference to it at this point. 
>  
> difference between framed and structured in this very 
> message, and now you mention structured = channelized E3 and 
> DS3 under the headline framed. And CESoPSN does not handle 
> framed E3 and DS3 either (for better or worse). 
>  
> [Sasha]  IMHO, no specific handling of structured E3 or DS3 
> is required (for the reason you have mentioned). 
>  
> Fine, we agree.
>

---

From: Shahram Davari <[email-masked]>
Date: Mon, 23 Sep 2002 15:33:55 -0700

Tom,

> From: tom k. johnson [mailto:[email-masked]]
> Sent: Monday, September 23, 2002 6:15 PM
> To: [email-masked]; Yaakov Stein
> My preference would be one very simple way to carry this type 
> of traffic as a bare minimum, and then add optional modes of 
> operation as necessary.  How can you have interoperability 
> without an agreed upon baseline of functionality?
> 
> The simplist thing I can think of is just to take every bit 
> as it comes in off the line and put it in a packet.  Add a 
> header with a sequence number, a PSN header, and ship it.  No 
> need to know anything about the bit-stream.

This is what Yaakov calls as unframed mode. I suspect not many
people want this mode, since it has very poor performance under
packet loss.

> Obviously, we can add special modes on top of that to take 
> advantage of the underlying structure (DS1, E1, DS3, E3, J2, 
> etc.) as described by the Sasha, Yaakov, and others, but why 
> not just agree on something like that as a baseline?

Other methods are completely different. There is nothing to add on top
that to achieve structured transport mode. It is a whole new ball game.

Yours,
-Shahram

---

From: "Bob Barrett" <[email-masked]>
Date: Tue, 24 Sep 2002 09:09:26 +0100

Tom

That's more or less my thinking, with no RTP in the baseline.

However, then we have to implement a negotiation protocol to enable any
mutual features above the baseline spec., but this can be simple to do in
implementations that only meet the baseline spec., e.g. sending back a fixed
'dumb' ack. packet in response to an enquiry packet.

Bob

snip ...

The simplist thing I can think of is just to take every bit as it comes in
off the line and put it in a packet.  Add a header with a sequence number, a
PSN header, and ship it.  No need to know anything about the bit-stream.

Obviously, we can add special modes on top of that to take advantage of the
underlying structure (DS1, E1, DS3, E3, J2, etc.) as described by the Sasha,
Yaakov, and others, but why not just agree on something like that as a
baseline?

What do you think?

-Tom

---

From: "Bob Barrett" <[email-masked]>
Date: Tue, 24 Sep 2002 09:09:27 +0100

Shahram

I fundamentally disagree with you statement:

'I suspect not many people want this mode, since it has very
poor performance under packet loss.'

Unframed mode can have exactly the same performance under packet loss as
framed mode. It all depends on the payload. If the unframed mode is carrying
framed voice traffic transparently it behaves the same as framed mode under
packet loss. If framed mode is carrying long HDLC frames in 31 time slots,
it behaves more or less the same as unframed mode carrying the same length
of HDLC frame (actually unframed mode is slightly better than framed as the
HDLC frame takes 31/32 as many CES packets to send, but now I am being
picky).

Thanks

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Shahram Davari
Sent: 23 September 2002 23:34
To: 'tom k. johnson'; [email-masked]; Yaakov Stein
Cc: PWE3 WG (E-mail); [email-masked]; Alexander Vainshtein
Subject: RE: [PWE3] TDM types and their implications

Tom,

Yours,
-Shahram

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 24 Sep 2002 14:11:55 +0300

> I agree that there is no need for a separate "unframed" 
> category, I was merely trying to represent in a simple table what Yaakov had already 

There is no NEED, since CESoPSN covers it as a special case.
However, it is somewhat simpler (no need for a framer that frame-syncs)
and it seems that some people have already implemented this mode.

I suggest that we all go with CESoPSN as base-line ( a SHOULD )
for unframed transport, and allow a mode ( a MAY ) without constraints
on payload size.
> cases, which it will. However, AAL2 requires sending CAS 
> packets in the same way as proposed for CESoPSN, so the same criticism would 
> apply to it: 
> large software overhead to generate the signalling packets, 
> and reduced robustness in the presence of high packet loss. This to my 
> mind is the only TECHNICAL advantage AAL1 has over the use of CESoPSN, 
> and an argument Yaakov made much of in our discussions at Yokohama.  
> Therefore I would be loathe to give up CESoPSN for the static, structured case to 
> replace it with a protocol with no inherent technical advantage, 
> especially one with the considerable added complexity of AAL2.
 
For reasons I have stated in the past, I do NOT recommend AAL2
for all cases, only when the additional computation and bandwidth efficiency
is justified.

Y(J)S

---

From: Shahram Davari <[email-masked]>
Date: Tue, 24 Sep 2002 06:13:55 -0700

Bob,

> framed voice traffic transparently it behaves the same as 

In a packet loss situation if you have framing you could 
repeat the previous frame, but if there is no framing you can't do that.

-Shahram

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 24 Sep 2002 16:25:05 +0200

Shahram and all,
A brief comment inline.

With best regards,
                                   Sasha Vainshtein

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, September 24, 2002 3:14 PM
> To: [email-masked]'; 'tom k. johnson'; 
> [email-masked]; Yaakov Stein
If each packet contains an integral multiple of 125 microseconds' samples of
the unframed service, you can do exactly the same.

---

From: "tom k. johnson" <[email-masked]>
Date: Tue, 24 Sep 2002 10:20:24 -0400

But, as I think Max pointed out, duplicating the last frame may not always the best plan.

-Tom

> Sent: Tuesday, September 24, 2002 10:25 AM
> To: 'Shahram Davari'; [email-masked]'; tom 
> k. johnson;
> Cc: PWE3 WG (E-mail); [email-masked]; Sasha Vainshtein

---

From: Shahram Davari <[email-masked]>
Date: Tue, 24 Sep 2002 07:19:50 -0700

Sasha,

> the unframed service, you can do exactly the same.

Doing so will also repeat the framing-bits, which will cause the
user's framer to go out of sync.

-Shahram

---

From: "Bob Barrett" <[email-masked]>
Date: Tue, 24 Sep 2002 17:31:57 +0100

Shahram

You are correct, but, who defined that the frame used for substitution was
the last frame?  The frame playout has to take account of the two frame
superframe of E1, 16 for T1 and CAS, and whatever the CRC4 superframe length
is (I must look that up in the ITU specs. ;-) ).

If the buffer management is flexible enough to handle all of the various
superframe lengths then the externally observable behaviour will be correct
for sync and robust enough not to break the signalling protocols. This
implies having a jitter buffer latency of a minimum of the superframe size
in terms of bit times.

Some CAS/CCS protocols may need to re-send or even re-initialise under
certain packet loss conditions. What the implementations need to avoid is
locking up the signalling protocol so that manual intervention is required
(U.K. DASS-2 was notorious for this). The need for manual intervention just
will not wash in the market. Personally I see robustness of the signalling
protocols as the biggest issue for PWE3 in terms of market acceptance.

Best regards

Bob

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: 24 September 2002 15:20
To: 'Sasha Vainshtein'; [email-masked]'; 'tom k.
johnson'; [email-masked]; Yaakov Stein
Cc: PWE3 WG (E-mail); [email-masked]
Subject: RE: [PWE3] TDM types and their implications

Sasha,

-Shahram

---

From: "Bob Barrett" <[email-masked]>
Date: Tue, 24 Sep 2002 17:31:56 +0100

Tom

'may not always' is not a very quantitative expression :-).

There are applications where keeping the output 'up' irrespective of content
is of value. I'll put a figure on this and say five percent of applications.

There are also cases where duplicating a frame could kill the signalling
protocol on the CPE, causing a lock-up and requiring a manual re-set at one
or both ends of the circuit. For the sake of argument let's say that's five
percent of case too.

If my 5%'s are correct that leaves 90% of cases as 'don't care'.

For my part I like the 95% to cover 'the duplicate the frame case', as that
is a simpler of the two implementations, then cater for the other 5% of
cases as a configurable option, may be at extra cost.

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of tom
k. johnson
Sent: 24 September 2002 15:20
To: Sasha Vainshtein; Shahram Davari; [email-masked];
[email-masked]; Yaakov Stein
Cc: PWE3 WG (E-mail); [email-masked]
Subject: RE: [PWE3] TDM types and their implications

But, as I think Max pointed out, duplicating the last frame may not always
the best plan.

-Tom

---

From: [email-masked]
Date: Tue, 24 Sep 2002 19:29:50 +0100

Bob...please see below.  regards, Neil

Bob Barrett observed 24 September 2002 17:32
<snip>
> The frame playout has to take account of the 
> two frame
NH=> To save you the trouble.....when I designed the E1 CRC4 stuff (a long
time ago now) it was based on a 16 frame multiframe (2ms)...I assume nothing
has changed.
<snipped>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 24 Sep 2002 12:54:05 -0700

Bob,

If you mean that one could repeat the same packet from the previous multiframe,
then you are correct that the framing will be fine, but since the data sample from the previous multiframe is 2-3 ms old, it cause annoying disturbance in the speech.

Yours,
-Shahram

> Sent: Tuesday, September 24, 2002 12:32 PM
> To: Shahram Davari; 'Sasha Vainshtein'; 'tom k. johnson';

---

From: "Bob Barrett" <[email-masked]>
Date: Tue, 24 Sep 2002 23:29:53 +0100

Shahram

I read draft-stein-pwe3-tdm-packetloss-00.txt regarding voice quality. I
would be interested to hear the authors views on what the impact of
repeating a multiframe has on speech quality using the non-human test
methodology. I don't have direct access to that level of test equipment to
try it for myself.

Thanks

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Shahram Davari
Sent: 24 September 2002 20:54
To: [email-masked]'; 'Sasha Vainshtein'; 'tom k.
johnson'; [email-masked]; Yaakov Stein
Cc: PWE3 WG (E-mail)
Subject: RE: [PWE3] TDM types and their implications

Bob,

If you mean that one could repeat the same packet from the previous
multiframe,
then you are correct that the framing will be fine, but since the data
sample from the previous multiframe is 2-3 ms old, it cause annoying
disturbance in the speech.

Yours,
-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Tue, 24 Sep 2002 15:33:05 -0700

Hi Bob,

May be Yaakov can answer this. 

-Shahram.

> Sent: Tuesday, September 24, 2002 6:30 PM

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 25 Sep 2002 09:51:48 +0200

Neil and all,
Of course nothing has changed, and most (if not all) E1 MF structures are
based on a
2 ms (= 16 frames) MF.
But, taking the numbers aside, repetition of the last MF is what I have had
in mind
- and it is  easy if your packet carries an integral multiple of 125
microsecond
samples. (Dead easy if the number of 125 micorsecond samples in the packet
is an integral divisor of the number of frames per MF). 

Please note that you do not need alignment of the packet payload with the
frame
boundary for that because the phase of the frame boundary in the packet
payload
is constant.

Please note also that different types of CE may benefit from different
mechanisms for
compensating lost packets (as Max has said). IMHO the actual compensation
mechanism
is a local matter - provided that the encapsulation supports several
reasonable ones.

With best regards,
                                   Sasha Vainshtein

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, September 24, 2002 8:30 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: [email-masked]
Date: Wed, 25 Sep 2002 09:34:10 +0100

Thanks Sasha....Few remarks (quite general) in-line.  my regards, Neil

Sasha Vainshtein wrote 25 September 2002 08:52
<snip> 
> is a local matter - provided that the encapsulation supports several
NH=>

-	I have a concern regarding the size of the 16 bit seq no.
field.....I beleive this is not an issue here (voice application say) but it
is in the general case.  That is, this field should not wrap at worst case
pkt loss and at highest bit rate considered in <10s.  This is to provide the
ability to carry out QoS measurements (ie verify SLAs), and these must be
distinguished from unavailability events (where the traditional
availability/unavailability integration period is based on 10s.....this
aspect is recognised in Y.1710/1711 for the case of MPLS and where simple
up/down state processing algorithms are provided).  So any seq no.
processing must be able to stand-up for at least 10s under worst case loss
conditions at higest rate.  Can someone provide me some evidence that this
aspect has been considered somewhere?

-	The E1 FAS has 2 forms in odd/even frames....so any 'slip' should be
an even frame integer to avoid loss of E1 framing.  Further, to avoid loss
of CRC4 (confirmation of correct framing) slip needs to be integer of 8
frames...so this is the key requirement in E1 case.  Again assuming no
change from my original CRC4 framing algorithm (though I am relying on
nearly 20 year old memory here), I made the (16 frame) MFAS alignment
algorithm a '1-shot' process, ie not checked after alignment.....once MFAS
aligned CRC4 verification is used to maintain/verify no change.

-	I have a minor observation in the case of supplying unstructured CBR
services regarding application behaviour in the face of data slips.  TDM
hierarchies use justification techniques to cater for clock differences.
These can cause uncontrolled bit slips to be passed to applications if used
at E1/T1 or higher rates.  Trad nx64k TDM network layers are synchronous to
their server  E1/T1 layer and so such slips are 'removed' by the E1/T1 frame
in a fast/known manner, ie the re-frame behaviour is always consistent
(albeit different in the 2 cases).  Although a long time ago now, I have
seen customers apply PRBS testers to E1 services (unstructured) and process
an apparently infinite error burst due to data slips...which a proper E1
frame would have removed in about 1.5ms.  So, in the case of unstructured
TDM services it will be critical that whatever CPE is used has a robust
framing procedure.  If everyone uses E1/T1 framing the results are
predictable/consistent for all concerned, but this will not be true if any
proprietary framing is used....so providing meaningful SLAs in the case of
supplying unstructered TDM services may not be possible....and this is why
we always strongly recommended using E1 frames structures to such customers.
With PSNs we will also get data slips, so its just something to be aware of.
Of course this does not apply to a voice application, since the brain
corrects such slips.

regards, Neil
<snipped to end NH>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 25 Sep 2002 06:36:54 -0700

Tom,

Please check Yaakov's latest draft on the effect of packet loss
on call quality. Here is an excerpt from that draft:

   If MOS>3.5 (cell-phone quality) is sufficient, then the following
   packet losses are allowable:

      zero insertion - 0.4 %

      previous sample -  2 %

      linear interpolation -  8 %

      statistical interpolation -  14 %

As you can see Playing a configurable byte (zero)
can tolerate only 0.4 % packet loss, while repeating
the previous sample can tolerate 5 times more loss.

Yours,
-Shahram

> Sent: Wednesday, September 25, 2002 8:46 AM
> To: [email-masked]; Shahram Davari; Sasha Vainshtein;
> Bob/Shahram - 
> In other Circuit Emulation approaches (such as AAL1), my 
> recollection is that the response to dropped packets/cells 
> was to play out a configurable byte pattern. 
> 
> Playing out the previous frame would require implementations 
> to store the previous frame for each circuit just in case the 
> next frame is dropped.  Or worse still, having to store and 
> keep track of entire super-frames, and trying to figure out 
> which stored packet to play-out in place of the dropped packet, etc.
> 
> Are you guys sure the theoretical performance improvement is 
> worth the added complexity and storage requirements for the base case?
> 
> Thanks
> 
> -Tom
> 
> > To: Shahram Davari; 'Sasha Vainshtein'; tom k. johnson;

---

From: Max Riegel <[email-masked]>
Date: Wed, 25 Sep 2002 16:40:55 +0200

It sounds reasonable for me to structure TDM emulation in a way adding more 
protection for framing and signalling bits on top of a basic mode.

In draft-riegel-pwe3-tdm-requirements we just distinguished between 
unstructured and structured modes. I agree with Yaakov that this 
classification is not satisfactory and we might need more levels of 
functionality.
The structured mode can be seen as the unstructured mode with the added 
functionality to have direct access to (and more protection for) the 
framing bits. This allows not only for direct access to individual channels 
but also for more enhanced error behaviour in the case of packet loss on 
the PSN.
As Yaakov pointed out, there might be additionally the requirement to have 
direct access to the superframe information to get higher protection for 
the CAS bits.

I can imagine that we are able to structure the TDM requirements in a way 
that we start with a basic functionality and add enhanced modes as needed 
for particular applications.

Bye
Max

At 24.09.2002 00:15 +0200, tom k. johnson wrote:
>My preference would be one very simple way to carry this type of traffic
>as a bare minimum, and then add optional modes of operation as
>necessary.  How can you have interoperability without an agreed upon
>baseline of functionality?
>
>The simplist thing I can think of is just to take every bit as it comes
>in off the line and put it in a packet.  Add a header with a sequence
>number, a PSN header, and ship it.  No need to know anything about the
>bit-stream.
>
>Obviously, we can add special modes on top of that to take advantage of
>the underlying structure (DS1, E1, DS3, E3, J2, etc.) as described by
>the Sasha, Yaakov, and others, but why not just agree on something like
>that as a baseline?
>
>What do you think?
>
>-Tom
>

---

From: "tom k. johnson" <[email-masked]>
Date: Wed, 25 Sep 2002 17:56:09 -0400

Shahram.

Thanks, I hadn't seen that. 

Let me look it over and get back to you.

-Tom

> Sent: Wednesday, September 25, 2002 9:37 AM
> To: tom k. johnson; [email-masked]; Sasha Vainshtein;

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 26 Sep 2002 11:47:56 +0200

Tom and Shahram,
IMHO it is worth combining the data to which Yaakov and Shahram refer 
with data provided by Tim regarding observerd packet loss in the SP networks
(attached).
If I remember correctly, the average packet loss varied between 0.04% 
and 0.12% - i.e., 3 to 10 times less than the limit for 
Cell Phone quality with zero insertion. And these numbers did not take
into account prioritization of traffic.
Doesn't it make the discussion somewhat theoretic?

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, September 25, 2002 11:56 PM
> To: Shahram Davari; [email-masked]; Sasha 
> Vainshtein; [email-masked]; Yaakov Stein
> Cc: PWE3 WG (E-mail)
> > > > To: 'Sasha Vainshtein'; 
> [email-masked]'; 'tom k.
> > > > > > > framed mode. It all depends on the payload. If 
> the unframed
> > > > > > > mode is carrying

---

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

Tom / all

On the complexity of playout (or re-playout) - not a big deal if the
implementation is designed from the ground up to work like this. There has
to be a buffer for jitter, so the implementation just keeps the frame data
for a few milliseconds longer before overwriting it.

On robustness in the event of packet loss - there is a balance to be struck
between latency and robustness. Latency is likely to be within a range
depending on the deployment topology. There are ITU specs for end to end and
for access 'loops'.

On packet loss patterns - the distribution function of packet loss and
latency is likely to be very different between IP networks and MPLS / layer
two networks, I am loath to make the direct link between these and
enterprise class and carrier class PSNs. The figures / stats for VoIP can be
applied to the former, but imho I don't think the packet loss / latency
distribution on layer two networks will be the same. More likely to be lower
latency and very low packet loss under normal operating conditions, and a
big hit of 20-200ms when there is an outage followed by a restoration event,
depending on the PSN capabilities. Has any contributor got packet latency
and packet loss stats for a reasonable scale layer two PSN as yet?

Thanks

Bob

-----Original Message-----
From: tom k. johnson [mailto:[email-masked]]
Sent: 25 September 2002 13:46
To: [email-masked]; Shahram Davari; Sasha Vainshtein;

Bob/Shahram -

In other Circuit Emulation approaches (such as AAL1), my recollection is
that the response to dropped packets/cells was to play out a configurable
byte pattern.

Playing out the previous frame would require implementations to store the
previous frame for each circuit just in case the next frame is dropped.  Or
worse still, having to store and keep track of entire super-frames, and
trying to figure out which stored packet to play-out in place of the dropped
packet, etc.

Are you guys sure the theoretical performance improvement is worth the added
complexity and storage requirements for the base case?

Thanks

-Tom

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 26 Sep 2002 16:56:40 +0300

Bob, 

> implementation is designed from the ground up to work like 
> this. There has to be a buffer for jitter, so the implementation just keeps 
> the frame data for a few milliseconds longer before overwriting it.

I agree - we found that a pointer into the jitter buffer representing
the structure start is sufficient.
 
> On robustness in the event of packet loss - there is a 
> balance to be struck between latency and robustness. 
> Latency is likely to be within a range
> depending on the deployment topology. There are ITU specs for 
> end to end and for access 'loops'.

The are several relevant ITU standards, 
but the most applicable one for end-to-end is G.114 which states:

-     0 to 150 ms: Acceptable for most user applications.
- 150 to 400 ms: Acceptable provided that Administrations are aware of the transmission time
                         impact on the transmission quality of user applications.
- above 400 ms: Unacceptable for general network planning purposes; 
                         however, it is recognized that in some exceptional cases this limit will be exceeded.

> latency is likely to be very different between IP networks 
> and MPLS / layer two networks, I am loath to make the direct link between these and
> enterprise class and carrier class PSNs. The figures / stats 
> for VoIP can be applied to the former, but imho I don't think the packet loss 
> / latency distribution on layer two networks will be the same.

Definitely different, but I never did a good statistical analysis.

> More likely to be lower latency and very low packet loss under normal operating 
> conditions, and a big hit of 20-200ms when there is an outage followed by a 
> restoration event, depending on the PSN capabilities. 

Where did you get the "big hit" figures?
I think they are underestimates.
Certainly, to have a PSN respond to an outage faster
than the 50 ms that SONET guarrantees is overly optimistic.

The only place I have seen figures for recovery of Ethernet networks
is in 802.3ad (link aggregation). There the "rapid reconfiguration" mode
that kicks in when physical connectivity changes is typically on the
order of 1 sec! 

Y(J)S

---

From: "Bob Barrett" <[email-masked]>
Date: Fri, 27 Sep 2002 14:11:36 +0100

Yaakov

On latency in the local loop, which I take to mean between the PBX port and
the switch port - someone quoted 2.5ms at me the other day for the latency
of the loop. Isn't 150ms the ITU spec. budget for end-to-end PBX port to PBX
port, with the target being 100ms? And this includes all the trunk
transmission and switching delays.

The 2.5ms was their need may be, rather than a spec., but it makes jitter
buffer management rather interesting. This particular user may be using a
large part of the latency budget for other processing requirements.

On restoration speed - my understanding is that the MEF and MPLS guys are
working to be at least as good as 50ms. Personally I think this is a
recognition of the fact that the market is unlikely to buy into a PSN
technology for voice transmission with a worse performance on this critical
parameter than the existing infrastructure, irrespective of cost and other
nominal benefits. If the network is 100% reliable the restoration time is
irrelevant. The more frequent the restoration events the more relevant it
becomes.

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Yaakov Stein
Sent: 26 September 2002 14:57
To: [email-masked]
Cc: PWE3 WG (E-mail)
Subject: RE: [PWE3] TDM types and their implications

Bob,

-     0 to 150 ms: Acceptable for most user applications.
- 150 to 400 ms: Acceptable provided that Administrations are aware of the
transmission time
                         impact on the transmission quality of user
applications.
- above 400 ms: Unacceptable for general network planning purposes;
                         however, it is recognized that in some exceptional
cases this limit will be exceeded.

Y(J)S

---

From: [email-masked]
Date: Fri, 27 Sep 2002 15:39:14 +0100

Bob...one observation below.  regards, Neil

> Sent: 27 September 2002 14:12
> To: Yaakov Stein
> Cc: PWE3 WG (E-mail)
> working to be at least as good as 50ms.
NH=> This is barking mad as I have tried to point out before.  50ms is based
on SDH rings and the physics of 'the best that was achievable at L1 at that
time'.....it is *not* driven by any application needs.  So IMO its absolute
madness to try and equal/beat this at the MPLS level just to compete with
SDH.  Further, I suspect this will cause many unecessary prot-switching
actions due to error events that would otherwise simply 'go away'.

> Personally I think this is a
> > this. There has to be a buffer for jitter, so the 
> implementation just
> keeps
> > and MPLS / layer two networks, I am loath to make the 
> direct link between
> these and
> > for VoIP can be applied to the former, but imho I don't 
> think the packet
> loss
> > More likely to be lower latency and very low packet loss 
> under normal
> operating
> > conditions, and a big hit of 20-200ms when there is an 
> outage followed by
> a

---

From: [email-masked]
Date: Fri, 27 Sep 2002 11:39:18 -0500

Neil,

	A reason why 50 ms is now a requirement is that there are 
dependcies that have been created.

e.g. when ATM protection switching was being worked on it was taken as 
arequirement that the protection switching had to be fast but not so 
fast that it would not allow for the physical layer to correct the 
problem. And of course it was assumed that the physical layer would 
correct the problem within 50 ms.

Robert Dianda

-----Original Message-----
From: neil.2.harrison [mailto:[email-masked]]
Sent: Friday, September 27, 2002 9:39 AM
To: bob.barrett
Cc: pwe3
Subject: RE: [PWE3] TDM types and their implications

> working to be at least as good as 50ms.
NH=> This is barking mad as I have tried to point out before.  50ms is 
based
on SDH rings and the physics of 'the best that was achievable at L1 at 
that
time'.....it is *not* driven by any application needs.  So IMO its 
absolute
madness to try and equal/beat this at the MPLS level just to compete 
with
SDH.  Further, I suspect this will cause many unecessary prot-switching
actions due to error events that would otherwise simply 'go away'.

---

From: [email-masked]
Date: Fri, 27 Sep 2002 22:41:22 +0100

Thanks Robert.....OK, but if we do something like this I'd hope we do so
with open eyes and an understanding of 'why' and not just simple
dogma....and its the latter feeling I get, ie if SDH does it in 50ms we need
to match this.....this is a view which has no foundations of common sense
just 'I've got a bigger one than you have'. 

But when I look at some of the stuff being generated thesedays in general, I
see common sense as a missing ingredient anyway...I hesitate to give
examples ;-)

regards, Neil 

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: 27 September 2002 17:39
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: Akiva Sadovski <[email-masked]>
Date: Sun, 29 Sep 2002 14:51:27 +0200

Neil,
  in reply to one of your previous messages ... see inline

> Sent: Wednesday, September 25, 2002 10:34 AM
> To: [email-masked]
> Cc: [email-masked]

  So we should have the ability to distinguish pkt loss from unavailability
... Unavailability of what ?
Since the unavailability of naitive service (AIS, Idle) is signalled via
bits in the Control Word (CESoPSN, TDMoIP), we always can distinguish
between PSN problems and naitive service problems. 

> an apparently infinite error burst due to data slips...

If my understanding is correct, the slip is repetition of the whole E1 frame
or throwing the whole E1 frame away. And bit slip - what is it ?
What generates such slip ? Suppose we're demapping E1 from VC. If
asynchronous mapping is used, then demapper may include / not include the
stuffing bits into the outgoing E1 signal... But these bits were present in
the incoming E1 which was mapped to VC. What problem may they cause ?

> a proper E1

 If we're providing an unframed service, it's up to customer to decide
whether to use framing or not. Framed E1 will pass thru the PW transparently
and CE connected to the PW's egress may use E1 frames...

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 29 Sep 2002 16:36:12 +0200

Neil and all,
Regarding your concern for the 16-bit sequence number:
The CESoPSN proposal (that covers rates up to DS3) defines 
that a packet contains an integer multiple of the 125 microsecond sampe.
This means that the wrap-around of a 16-bit sequence number 
would occur in 8" in the worst case (if each packet contains exactly one
sample) - close enough to your limit of 10". 
In the more realistic situations (when a packet contains several frames),
the wrap-around time would exceed this limit by far. Even for DS3,
two frames can be delivered in a single packet if you deal with an
Ethernet-like Path MTU (1.5K). 

The situation for higher rates may be different.

With best regards,
                                   Sasha Vainshtein

> To: [email-masked]

---

From: [email-masked]
Date: Mon, 30 Sep 2002 09:02:12 +0100

Thanks Akiva for your comments, my response is below.

regards, Neil

Akiva Sadovski awrote 29 September 2002 13:51
<snip>
>   So we should have the ability to distinguish pkt loss from 
NH=> Yes you should IMO....assuming you understand what I am meaning by the
difference between QoS (actually Network Performance, NP) metrics/objectives
and availability metrics/objectives.

> ... Unavailability of what ?
NH=> The trail you are attempting to emulate.  I assume one is trying to
sell some service here, ie there are commercial issues at stake and its not
purely an academic technical exercise?....and it which case its not a bad
idea to be able to be able to specify its behaviour in agreed/consistent
terms.

> between PSN problems and naitive service problems. 
NH=> I suspect you are missing my point.  Service providers and customers
usually require some performance  criteria to be met. It makes a great deal
of sense if the metrics of such performance parameters are consistently
specified.  Further, there are client/server relationships between layers
(where the server layers my be leased from a different SP entity) and also
peer relationships (ie where tandemed partitions of the network service are
provided by co-operating SPs, ie across a well defined NNI).  In both cases
its obvious (at least I hope it is) that one requires consistent methods of
defining NP and availability metrics....else how are we going to define
methods of partitioning objectives on a fair basis, and how can one compare
apples with apples?  These are not simply issues of technical curiousity,
they have important commercial implications.
The ordering of specification is important, and I would suggest it goes like
this:
-	define/agree/specify defects...entry/exit criteria and methods of
handling wrt consequent actions for technology considered;
-	define/agree up/down states of trail based of defect persistencies
(this give the availability metric);
-	based on up-time define/agree the appropriate set of NP metrics;
-	now define/agree end-end objectives for some reference trail and
method of apportioning to smaller partitions....for both availability and NP
metrics.

Please see Y.1711 for how this has been done for MPLS.....at least to the
stage where the 1st two bullets above are completed.
> or throwing the whole E1 frame away.
NH=> Yes this is appropriate here, because it is controlled as such.

> And bit slip - what is it ?
> What generates such slip ?
NH=> This depends on what server layers there are below the one of interest.
Uncontrolled bit slips can occur in PDH hierarchies (it's a consequence of
the justification schemes used).  I believe you can also get similar effects
in SDH with some asynchronous Virtual Container mappings.  If you don't have
such server layers then these issues are not relevent.....PSN network will
give pkt loss and 'slips' will be controlled (as opposed to uncontrolled).

> Suppose we're demapping E1 from VC. If
NH=> It's not an issue at this point as one is using controlled slips (due
to pkt loss).
> and CE connected to the PW's egress may use E1 frames...
NH=> So let's hope such customers use 'sensible' framing to recover the
controlled slips they will get.
BTW - You may want to specify such a NP metric and its objectives as I noted
above....I would for sure want to understand just what I was getting here if
I bought/leased such a service.