Subject: T1 frame format in draft-vain-stein-pwe3-satop-00

From: "Yaron Raz" <[email-masked]>
Date: Tue, 16 Sep 2003 10:09:14 +0300

The default (and mandatory) T1 frame format in draft-vain-stein-pwe3-satop-00 is set for 192 bytes of TDM payload.
However, since T1 is 193 bits and not 192 bits, this means that a SAToP packet carries a little less than 8 frames of T1.
This is regardless of whether the T1 is carrying any framing.

Carrying 192 bytes causes the following issues:
1.	In some applications, although the T1 is carried inside the network regardless of the framing (Structure Agnostic), T1 PM is done at the entry to the network, in order to be able to do fault localization. This is equivalent to SONET/SDH devices doing T1 PM, but carrying the T1 in bit-asynchronous mapping. In this case, a T1 framer would normally hand-of 193 bits (including F bit) each time. It is therefore easier to pack the 193 bits, and not do any bit shifting between frames. Note that both SONET and SDH chose to carry 193 bits (24 bytes + 1 bit carried in additional byte) inside the VTs, when facing the same question.
2.	Another important application of SAToP is aggregating multiple T1s on different locations in the network to a central site, and handing off an OC-3. On the OC-3 side, a VT mapper would normally have a byte interface, where the 193th bit will carried in a an additional bye, and not sharing this byte with 7 bits of the next frame. In this case, you would need like 84 shift registers for aligning this to SAToP format. This will drive the implementations to be more complex and expensive.
3.	Although it is not specifically mentioned in the draft, it is common practice to use the sequence number as a “timestamp” for clock recovery. This is one of the reasons why RTP header is optional. However, if a packet is sent every 192 bytes, then the clock frequency conveyed through this sequence number is not 8K (or more exactly 1K), but rather 193/192 of this frequency. So the clock recovery mechanism becomes more complicated, having to adjust this recovered frequency to 8K.

I believe the original frame format proposed in CESoPSN and uCESoPSN for T1, namely carrying each 193 bits in 25 bytes including 7 bit padding solves all the above issues. It has been on the table for about 3 years now, and has been generally agreed upon (most of the debate was on the structured mode). In that case the mandatory mode for T1 should be 200 bytes (25 x 8).

Yaron

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 16 Sep 2003 15:05:18 +0300

Yaron, 

My remarks are interleaved below.

Y(J)S

> The default (and mandatory) T1 frame format in 
> draft-vain-stein-pwe3-satop-00 is set for 192 bytes of TDM payload.
> However, since T1 is 193 bits and not 192 bits, this means 
> that a SAToP packet carries a little less than 8 frames of T1.

The emphasis is on the "regardless".
It doesn't make sense to say that 192 bytes is
"a little less than 8 frames of T1"
for "regardless" SAToP.
SAToP is only transporting an arbitrary 1.544 Mbps
bit-stream. By definition it doesn't know anything about frames.

If you want to maintain frame integrity
then you should use one of the STRUCTURED drafts,
which will be submitted as soon as SAToP becomes
a WG item.

> 1.	In some applications, although the T1 is carried inside 
> the network regardless of the framing (Structure Agnostic), 
> T1 PM is done at the entry to the network, in order to be 
> able to do fault localization. This is equivalent to 
> SONET/SDH devices doing T1 PM, but carrying the T1 in 
> bit-asynchronous mapping. In this case, a T1 framer would 
> normally hand-of 193 bits (including F bit) each time. It is 
> therefore easier to pack the 193 bits, and not do any bit 
> shifting between frames. Note that both SONET and SDH chose 
> to carry 193 bits (24 bytes + 1 bit carried in additional 
> byte) inside the VTs, when facing the same question.

Once again you are talking about T1 framers.
SAToP doesn't require the use of a framer,
nor do we deal with the effects of using one.
If the framer and/or its functionality are important
to you, please use one of the structured drafts.

> 2.	Another important application of SAToP is aggregating 
> multiple T1s on different locations in the network to a 
> central site, and handing off an OC-3. On the OC-3 side, a VT 
> mapper would normally have a byte interface, where the 193th 
> bit will carried in a an additional bye, and not sharing this 
> byte with 7 bits of the next frame. In this case, you would 
> need like 84 shift registers for aligning this to SAToP 
> format. This will drive the implementations to be more 
> complex and expensive.

If this logic were true then you would need 84 shift 
registers to extract the T1 towards a regular TDM interface.
All you have to do is to extract the 1.544 Mbps bit-stream
(i.e. extract the original T1 which was sent over the OC-3)
and encapsulate it as explained in the draft.

> 3.	Although it is not specifically mentioned in the draft, 
> it is common practice to use the sequence number as a 
> “timestamp” for clock recovery. This is one of the reasons 
> why RTP header is optional. However, if a packet is sent 
> every 192 bytes, then the clock frequency conveyed through 
> this sequence number is not 8K (or more exactly 1K), but 
> rather 193/192 of this frequency. So the clock recovery 
> mechanism becomes more complicated, having to adjust this 
> recovered frequency to 8K.

The only clock frequency of meaning in structure-agnostic
T1 transport os 1.544 Mbps. There is no complication in
locking on to this frequency using the suggested default
payload size.
 
> I believe the original frame format proposed in CESoPSN and 
> uCESoPSN for T1, namely carrying each 193 bits in 25 bytes 
> including 7 bit padding solves all the above issues. It has 
> been on the table for about 3 years now, and has been 
> generally agreed upon (most of the debate was on the 
> structured mode). In that case the mandatory mode for T1 
> should be 200 bytes (25 x 8).

I think you are missing the main point of SAToP.

By suggesting that we identify units of 193 bits in 
the continuous bit-stream, and then pad them to 
25 bytes before encapsulating them,
is structure-processing! This is NOT a valid
suggestion for SAToP.

Let me put this a different way:
You suggest that the default behavior for raw 1.544 Mbps
bit stream extraction would require building a complex routine
which performs the following functions:
   Perform 8 times:
      1) take 193 bits (an unexplained prime number) of bits 
      2) append 7 (a smaller prime number) zeros
      3) arrive at the magic number of 25 bytes
   
while the default behavior for E1 is
    1) take 256 bytes

Can you explain the logic of this dichotomy
and the details of the first routine in a STRUCTURE AGNOSTIC way?

Remember, the only mention of G.704 in SAToP
is the sentence that states that we don't use any concepts
from it in any way here.
  
I think that it should be understood that SAToP
isn't a solution for everything. 

It is a common denominator that we believed everyone could agree upon. 
When structure becomes important (as in ALL of your examples) 
the two camps have significant differences of opinion 
as to how to handle it (whether by padding and keeping multiples, 
or removing the extra bit and managing pointers). 
SAToP purposely avoids these issues.

I really do not believe that trying to import one of the 
structured transport mechanisms (the CESoPSN one) 
through the back-door
is a fruitful thing to do at this point.

---

From: "Yaron Raz" <[email-masked]>
Date: Wed, 17 Sep 2003 11:21:39 +0300

Yakov,

I'm not trying to turn this draft into a structured draft.
However, it is wrong to assume that a T1 that does not carry framing inside, has nothing to do with 193 bits.
SONET and SDH have defined two modes for carrying E1s and T1s in a similar way:
SAToP is the analogy for bit-asynchronous mapping.
Structured is the analogy for byte-synchronous mapping.
I suggest we consider what this proven technology has chosen for mapping.
I would also not raise any objection after these 3 long years, if there weren't some technical complexities we are inserting by this new approach. This draft is not a hypothetical exercise, but hopefully a base for many real implementations to follow.

See some additional answers in the text.

Yaron

 -----Original Message-----
From: 	Yaakov Stein [mailto:[email-masked]] 
Sent:	Tuesday, September 16, 2003 3:05 PM
To:	Yaron Raz; PWE3 group (E-mail)
Subject:	RE: [PWE3] T1 frame format in draft-vain-stein-pwe3-satop-00

Yaron, 

Y(J)S

The emphasis is on the "regardless".
It doesn't make sense to say that 192 bytes is
"a little less than 8 frames of T1"
for "regardless" SAToP.
SAToP is only transporting an arbitrary 1.544 Mbps
bit-stream. By definition it doesn't know anything about frames.
[Yaron Raz] T1 carries 193 bits in 125uSec. This is regardless of whether this T1 carries framing or not.
If you want to overlook this fact then why do you propose 256 bytes for E1 and 192 for T1? Why not another payload size to fit both modes?

If you want to maintain frame integrity
then you should use one of the STRUCTURED drafts,
which will be submitted as soon as SAToP becomes
a WG item.
[Yaron Raz] We don't know how the structured draft will look like, and if there'll be one. In any case, we should make our best effort for the structure agnostic one to cover as much grounds as possible, so long as we don't contradict its internal logic.

Once again you are talking about T1 framers.
SAToP doesn't require the use of a framer,
nor do we deal with the effects of using one.
If the framer and/or its functionality are important
to you, please use one of the structured drafts.
[Yaron Raz] The incentive for using a structured draft is in cases where you need to terminate the framing of the PDH signal, like carrying partial T1s/E1s etc. There is no need to do it in other cases.
Note that most of the SONET/SDH world is working in bit-asynchronous mapping mode which is the exact analogy to Structure Agnostic. SONET/SDH bit-asynchronous mapping chose 193 bits for T1, and 256 for E1 x 4.

[Yaron Raz] Correct. In the proposed frame format, you need to get back the bits, and then re-pack them to bytes for sending as SAToP frames. However, if you use 193 bits padded, you take the output from a SONET mapper byte by byte, and map it to SAToP. It makes the implementation much easier, and after all, the reason we are spending effort here is to make a standard that would promote efficient, simple and cheap transport of TDM of packet networks, right?

> "timestamp" for clock recovery. This is one of the reasons 

[Yaron Raz] If I can do this for an unframed T1, then it is certainly not structure-processing. There is no underlying assumption that the T1 is framed.

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 17 Sep 2003 11:51:48 +0300

> However, it is wrong to assume that a T1 that does not carry 
> framing inside, has nothing to do with 193 bits.
> I would also not raise any objection after these 3 long 
> years, if there weren't some technical complexities we are 
> inserting by this new approach. This draft is not a 
> hypothetical exercise, but hopefully a base for many real 
> implementations to follow.

I agree - we want this draft to be implemented,
but I don't agree that the implementation that you envision
is the only, or even the best, implementation.

I for one would have to build new and extremely difficult
logic to handle T1s the way you suggest - as I explained
at detail in my previous email. 

I suggest that Sasha, yourself and I take this issue
off-line, and return to the list with our findings.

<snip>

> [Yaron Raz] We don't know how the structured draft will look 
> like, and if there'll be one. In any case, we should make our 
> best effort for the structure agnostic one to cover as much 
> grounds as possible, so long as we don't contradict its 
> internal logic.

I think we do know.
There will be two, one CESoPSN and one TDMoIP.
These two methods are well known by now.

<snip>

> [Yaron Raz] The incentive for using a structured draft is in 
> cases where you need to terminate the framing of the PDH 
> signal, like carrying partial T1s/E1s etc. There is no need 
> to do it in other cases.

Why ?
I do not pull out of PDH signals,
and have many applications that require structured transport.

The most obvious reasons are 
  1) packet loss concealment techniques for the timeslots
  2) support for CAS signaling

<snip>

> Note that most of the SONET/SDH world is working in 
> bit-asynchronous mapping mode which is the exact analogy to 
> Structure Agnostic. SONET/SDH bit-asynchronous mapping chose 
> 193 bits for T1, and 256 for E1 x 4.

SONET/SDH proponents never claimed NOT to be experts in TDM,
but that is the PWE approach.
We do NOT want to invent methods of fiddling around 
with the payload. Here the payload is a continuous bit-stream
with absolutely no known structure.
What you are suggesting requires knowledge that SONET/SDH
designers have and exploit, and we want to leave beyond
the scope of our work.

<snip>

> [Yaron Raz] Correct. In the proposed frame format, you need 
> to get back the bits, and then re-pack them to bytes for 
> sending as SAToP frames. However, if you use 193 bits padded, 
> you take the output from a SONET mapper byte by byte, and map 
> it to SAToP. It makes the implementation much easier, and 
> after all, the reason we are spending effort here is to make 
> a standard that would promote efficient, simple and cheap 
> transport of TDM of packet networks, right?

In my implementation it would make the implementation
much harder, not easier.

<snip>

> [Yaron Raz] If I can do this for an unframed T1, then it is 
> certainly not structure-processing. There is no underlying 
> assumption that the T1 is framed.

Great. So if we are dealing with an arbitrary 1.544 Mbps bit stream,
why do we need the padding?

Y(J)S

---

From: "Ron Cohen" <[email-masked]>
Date: Wed, 17 Sep 2003 08:38:03 -0700

Yaakov,

> at detail in my previous email. 

Both Yaron and I made the following arguments related to T1 payload:

1. T1 payload format should support less than 1msec granularity
2. It is advantageous that T1 payload would have 125us granularity in
RTP timestamp
3. It is advantageous that T1 payload mapping to/from VT would be easier
4. It is advantageous that T1 payload mapping of structured/unstructured
would be similar. Working with TDM bus usually provides a mapping of 193
bits into a byte align bus. This would make 193 bits in 25 bytes an
easier implementation solution for both structured and unstructured
solution.

The argument I hear from you is that mapping 193 bits into 25 bytes
makes it harder to implement when connected directly to an LIU.

I'd like to hear opinions from other people on the list. 

Thanks
Ron

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yaakov Stein
> Sent: Wednesday, September 17, 2003 1:52 AM
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>