Subject: RE: TDM draft consolidation

From: "Bob Barrett" <[email-masked]>
Date: Fri, 5 Apr 2002 19:26:17 +0100

Dear all

I was unable to make the March meeting, as I was at the 802 meeting the week
before and had to be back in the UK.

For E1 / T1 (about 99.999% of the market) why not treat everything as
unstructured, because a structured payload can exist within an unstructured
emulated circuit and always work.

Saving a DS0 of bandwidth incrementally is hardly an issue on a 1GE uplink,
and not much of an issue on a 100M uplink.

It was an issue in ATM over E1 or E2, and is an issue for Ethernet over
Copper, but if one is using Ethernet over copper chances are that there is
copper to carry the circuit native anyway.

There is no need (other than the nebulous benefit of saving less than a DS0)
to extract signalling within the transport. There is only a need to access
signalling if one is going to optimise the DS0 channels (for something like
GR303), so the whole circuit has to be recovered anyway. Saving bandwidth
when a circuit is down is valid but that's about as far as I would go.
Saving bandwidth just when the circuit is idle may have response
implications.

If I were building a circuit over Ethernet system (which I am) I wouldn't
start from ATM (which I didn't).

Why make this more complicated than it needs to be? It adds a lot of cost.

Circuit emulation over Ethernet with clock recovery can be put in a single
PLD, if it is just simple clear channel, and as I opened this email, a
structured payload can exist within an unstructured emulated circuit and
always work (if you do it right).

I will try to get to the next meeting, and I will be reading the minutes of
the last meeting in detail tonight. Thanks.

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Yaakov
Stein
Sent: 29 March 2002 07:47
To: [email-masked]'
Subject: [PWE3] TDM draft consolidation

I would like to reiterate the proposal I made at the meeting
regarding the applicability of the various TDM drafts.

I proposed to agree on a TDM control word and to allow all three payload
types.

Of course, although one MAY use any of the payload types,
there will be required availability depending on the application at hand.

My last slide was:

*	MUST use SONET/SDH for high rate
*	For low rate (E3/T3 and below) :
*	MUST use raw frames for unstructured
*	MUST use AAL1 for structured / static timeslot with CAS
*	MUST use AAL2 when dynamic timeslot allocation required
*	MAY use either raw or AAL1 for structured w/o CAS

I would like to hear comments from the list regarding such a proposal.
I realize that others may think differently regarding the precise placement
of the MUSTs and MAYs.

If there is agreement regarding the general idea,
we could either proceed to put everything into one draft (which would
probably be difficult)
or could continue to have three drafts, with Applicability Statements
differentiating
between them.

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

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

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 7 Apr 2002 16:00:26 +0200

Bob and all,
I may be completely mistaken, but it seems to me
that you have interpreted "structured" circuits in
Yaakov's message as 31*DS0 (for E1) or 24*DS0 (for T1).
In fact, the intention was for N*DS0, 1<=N<=30.
And carrying, say, 8*DS0 as an unstructured E1 (or T1) 
involves 300% (200%) overhead. 

CAS and CCS are also considered in conjunction with
N*DS0 circuits.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: Bob Barrett [mailto:[email-masked]]
> Sent: Friday, April 05, 2002 8:26 PM
> To: Yaakov Stein; [email-masked]
> Subject: RE: [PWE3] TDM draft consolidation
> 
> 
> Dear all
>

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 7 Apr 2002 16:57:55 +0300

Hi Bob,

My comments are interleaved below.

Y(J)S

> From: Bob Barrett [ mailto:[email-masked]
<mailto:[email-masked]> ]
> Sent: Friday, April 05, 2002 9:26 PM
> unstructured, because a structured payload can exist within
> an unstructured emulated circuit and always work.

Everything will indeed work if there is no packet loss,
which is NOT a valid assumption in many PWE scenarios.

>
> Saving a DS0 of bandwidth incrementally is hardly an issue on
> a 1GE uplink, and not much of an issue on a 100M uplink.

Why do you assume that we are speaking of Gigabit Ethernet links?
PWE is supposed to be PSN-agnostic, and should work even over relatively
low bandwidth infrastructures.

>
> It was an issue in ATM over E1 or E2, and is an issue for
> Ethernet over Copper, but if one is using Ethernet over copper chances are
> that there is copper to carry the circuit native anyway.

Same comment as above.

>
> There is no need (other than the nebulous benefit of saving
> less than a DS0) to extract signalling within the transport. There is only
a
> need to access signalling if one is going to optimise the DS0 channels
(for
> something like GR303), so the whole circuit has to be recovered anyway.

I agree. Not only is there no need to extract signaling, 
I think it goes against the spirit of tunneling
and against the principles of transparent transport.
It also requires more computation and can introduce various errors.
That was exactly the point of my question to Sasha at the meeting.

> Saving bandwidth when a circuit is down is valid but that's about as far
as I would go.
> If I were building a circuit over Ethernet system (which I
> am) I wouldn't start from ATM (which I didn't).
>

I agree that one shouldn't make a system more complicated than it has to be.
We simply don't agree on what one can expect from the PSN here.
You are making assumptions of an extremely wideband and reliable underlying
PSN.
Under these conditions indeed one could get away with arbitrarily
encapsulating
any number of bytes one wanted and still be ensured of proper recovery.
Under more realistic assumptions this "simplistic" approach simply doesn't
work.
 
All  I suggested is to borrow the work of he ATM people to some extent,
and exploit their 10+ years of field experience. You may claim that this
is more computationally expensive (although it simply requires the placing
of a single pointer byte here and there - not really much computation),
but the added trouble is well worth the effort.

>
> Circuit emulation over Ethernet with clock recovery can be
> put in a single PLD, if it is just simple clear channel, and as I opened
this email, a
> structured payload can exist within an unstructured emulated
> circuit and always work (if you do it right).

Once again you are making a lot of assumptions, including Ethernet
infrastructure,
bandwidth to waste, no packet loss, etc. 

>
> I will try to get to the next meeting, and I will be reading
> the minutes of the last meeting in detail tonight. Thanks.
>
> Best regards
>
> Bob
>
> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]On
> Behalf Of Yaakov
<https://www1.ietf.org/mailman/listinfo/pwe3> 
<https://www1.ietf.org/mailman/listinfo/pwe3>

---

From: "Bob Barrett" <[email-masked]>
Date: Mon, 8 Apr 2002 08:21:28 +0100

Sasha et al

Actually I meant all structured circuits, keeping it really simple. I have
not seen that many factional E1s being used for telephony, and my belief is
that data will move to native Ethernet at fractional Ethernet rates within
the 3-5 year window, as and when the circuits move from copper delivery to
'over packet' delivery. If a service is on copper today it is likely to stay
on copper. I can't see FT1 FR going to FT1 FR over Ethernet, no matter what
the ILECs say today. They don't want to cannibalise their existing services
and they don't want to spend money changing something that on the outside
will look the same as the current case. The main issues are lowering cost by
byte sent, and increasing revenues. The ILECs have learnt that VoIP did not
save them any money. If there is Ethernet in the first mile I think the
likely switch is to a native Ethernet service that is equivalent to the FR
service, and upgrades it (say 10x bandwidth for 2x price increase).

Not sure I agree with your sums (but I am too lazy today to do the numbers).
Saving 24 bytes in an Ethernet frame, even with multiple savings of 24 bytes
per Ethernet frame, saves bandwidth for sure, but it doesn't save a lot in
terms of the processing power needed to switch / route the frames. Saving
bandwidth at this level is not a big issue in my vision of the future
network infrastructure (I may be wrong) ;-).

I saw an email the other day that was suggesting a degenerate case
compromise in order to resolve the multiple drafts. In my view the
degenerate case is the really simple case that I have outlined i.e. clear
channel only. Anything more complex than that can be done by a single
company or groups of companies forming strategic alliances. I can't see any
other way of getting agreement between the ATM orientated draft and your
draft. You are unlikely to concede theirs, and they are unlikely to concede
yours.

Thanks

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Sasha
Vainshtein
Sent: 07 April 2002 15:00
To: [email-masked]'
Cc: Yaakov Stein; [email-masked]
Subject: RE: [PWE3] TDM draft consolidation

Bob and all,

With best regards,
                                   Sasha Vainshtein

> a 1GE uplink,
> Ethernet over
> less than a DS0)
> put in a single
> the minutes of

---

From: "Bob Barrett" <[email-masked]>
Date: Mon, 8 Apr 2002 08:21:30 +0100

My comments also interleaved:

Bob
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Yaakov
Stein
  Sent: 07 April 2002 14:58
  To: [email-masked]'; [email-masked]
  Subject: RE: [PWE3] TDM draft consolidation

  Hi Bob,

  Y(J)S

  This applies whatever method is used based on datagrams. A low packet loss
rate will have an affect on any of the drafts. A high packet loss and they
all die anyway.

  I guess I am looking at the 95% case two years out. I am assuming we are
talking about Ethernet links over fiber, and my belief is that the business
case for 1GE is so compelling that 100M over fiber will be dead within two
years. Furthermore if we are talking about Ethernet over copper I think that
the circuit services will be carried over copper as native services and not
as circuit emulation.

  Same comment as above.

  Ditto - there is a lack of capital in the SP market place and therefore
the old adage of 'don't fix it if it ain't broke' applies. I can't see a
sound business case for moving circuits to circuit over packet unless there
is a fiber link.

  > less than a DS0) to extract signalling within the transport. There is
only a
(for

  Hey, we agree on something, that's got to be good. As I said in an earlier
email, I am a newbie so I have some catching up to do.
as I would go.
  > Why make this more complicated than it needs to be? It adds a

  I agree that one shouldn't make a system more complicated than it has to
be.
  We simply don't agree on what one can expect from the PSN here.
  You are making assumptions of an extremely wideband and reliable
underlying PSN.
  Under these conditions indeed one could get away with arbitrarily
encapsulating
  any number of bytes one wanted and still be ensured of proper recovery.
  Under more realistic assumptions this "simplistic" approach simply doesn't
work.

  What benefit does the ATM overhead provide?
this email, a

  Yes, I am making these assumptions based on what I believe the major SPs
will want to do with Circuit Emulation. The CLECs are dead in the water and
the ILECs have all the circuits they need over copper and Sonet/SDH. The
business case for circuit emulation is linked to the business case for an
all packet metro (imho and experience of talking to prospects and partners
over the past year or two). It only takes 3M to carry an E1, even with one
256bit frame per Ethernet frame, that's only a 33% overhead. I don't think
of that as wasteful. Packet loss is likely to tend to zero until a
restoration event happens, and then it is going to be multi-packet loss over
milli-seconds. Packet loss of 1 in 10-6 is easily tolerated from a content
and a clock point of view in the mechanisms that I may propose. I need to
work out how I should make these submission formally I guess. I'll address
that question to the new chair.

  Thanks

  Bob

---

From: [email-masked]
Date: Mon, 8 Apr 2002 10:21:31 +0100

Yaakov

I have added some comments, see below:

Cheers
   Geoff

Hi Bob,

Y(J)S

> Subject: RE: [PWE3] TDM draft consolidation

<snip>

Geoff Floyd's Comment:
I do not know the details of Bob's simple scheme therefore I will make the
following assumptions:
- Each packet has a sequence number
- Each packet holds the same amount of TDM data
- Each packet holds and integer number of TDM frames. (Some padding will be
required for T1 to handle the extra bit.)
If my assumptions are correct then a "simple" system will continue to
operate even if packets are lost.

<snip>

as I would go.

I agree that a system is required to recover the TDM stream if packets are
lost. Both the simple scheme outlined above and the use of  pointer bytes
will achieve this.

I am not convinced that the ATM pointer scheme is well suited to a packet
based network. ATM networks are more robust with cells delivered in order
and few cells lost. The pointer scheme is well suited to an ATM environment
where cells are small and overheads must be minimised. In a packet
environment a more robust scheme is required as more packets are lost or
delivered output of order. I believe the "simple" scheme outline above is
easier to implement and provides more protection from lost packets.

<snip>

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 8 Apr 2002 16:24:16 +0300

> Geoff Floyd's Comment:
> I do not know the details of Bob's simple scheme therefore I 
> will make the following assumptions:
> - Each packet holds and integer number of TDM frames. (Some 
> padding will be required for T1 to handle the extra bit.)

This is precisely Sasha's scheme, and holds well for TDM systems
where the single frame is the only structure of importance.
It does not work well for cases where there are superframes or multiframes,
such as the important case of CAS signaling. 

The appropriate generalization of the "simple" system 
would be packets that hold an integer number of superframes,
but that would involve very long latency.

A much more flexible alternative is to allow encapsulation of different byte
lengths,
and include a pointer to where the appropriate structure commences. 
This is called AAL1.

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 8 Apr 2002 16:38:42 +0300

Comments interleaved.

> Sent: Monday, April 08, 2002 10:21 AM
> To: Sasha Vainshtein
> Actually I meant all structured circuits, keeping it really 
> simple. I have not seen that many factional E1s being used for telephony, 

This may be a valid statement of what you have seen, 
but has little relevance to what has been deployed.

> and my belief is that data will move to native Ethernet at fractional
Ethernet 
> rates within the 3-5 year window, as and when the circuits move from 
> copper delivery to 'over packet' delivery. 
> If a service is on copper today it is likely to stay on copper. 
> I can't see FT1 FR going to FT1 FR over Ethernet, 
> no matter what the ILECs say today. They don't want to cannibalise their 
> existing services and they don't want to spend money changing something
that on 
> the outside will look the same as the current case. The main issues are 
> lowering cost by byte sent, and increasing revenues. The ILECs have learnt

> that VoIP did not save them any money. 

I agree with the last sentence, but not the previous few.
All I can say is that we are selling a lot of TDMoIP to real customers
who are only doing it because it reduces their costs NOW.
Yes, maybe in 3-5 years, assuming that the high-tech world 
leaves it present recession and returns to the heady times 
prior to the decline of 2000, there will be universal fiber connectivity
at Gbit rates. But there are people who want to reduce their
operational costs TODAY.

<snip>

> Not sure I agree with your sums (but I am too lazy today to 

The authors of the three drafts went over the efficiencies
at length before the IETF52 meeting, and we all agree.

<snip>

> degenerate case is the really simple case that I have 
> outlined i.e. clear channel only. 
> Anything more complex than that can be done by a single
> company or groups of companies forming strategic alliances. I 
> can't see any other way of getting agreement between the ATM orientated 
> draft and your draft. You are unlikely to concede theirs, and they are 
> unlikely to concede yours.

I have suggested a compromise (where I am willing to concede
in several areas) and am patiently awaiting its serious consideration.

---

From: [email-masked]
Date: Tue, 9 Apr 2002 15:50:56 +0100

Yaakov

See comments below:

Geoff

>where the single frame is the only structure of importance.

I agree. Sasha's scheme works well for the transmission of unstructured T1
and E1s.

>but that would involve very long latency.

Options to use the "simple" system to handle superframes or multiframes:
Option 1) Send the whole T1/E1 as unstructured data. The signaling and
framing bits are sent "as is" with the rest of the data and replayed at the
far end. Using this option there is no requirement to align the start of a
packet with a multiframe or to include a complete multiframe in a single
packet.
Option 2) Use a framer to unscramble the T1/E1 bit stream into its separate
components as follows:
- The framing bits are removed.
- The signalling bits are extracted and passed to the control CPU.
- The data bits are placed onto a TDM bus (e.g. H100 or ST BUS)
Transmit the data bits from the TDM bus as "simple" data packets as
described above. There is no requirement to include a complete multiframe
or superframe in each packet.
Transmit the CAS signalling bits in separate packets.

I believe both options should be supported. The required option will depend
on the application.

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 9 Apr 2002 18:34:29 +0300

As usual, see my comments below.

Y(J)S

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2002 5:51 PM
> To: [email-masked]
> Cc: [email-masked]; Yaakov Stein
> >> If my assumptions are correct then a "simple" system will 
> >> continue to operate even if packets are lost.
> >>
> >
> I agree. Sasha's scheme works well for the transmission of 
> unstructured T1 and E1s.

Right - that is precisely what I suggested in my compromise!

> 
> >It does not work well for cases where there are superframes or
> > multiframes,such as the important case of CAS signaling.
> >
> framing bits are sent "as is" with the rest of the data and 
> replayed at the far end. Using this option there is no requirement to
align 
> the start of a packet with a multiframe or to include a complete
multiframe 
> in a single packet.

Yes, this will work as long as there is no packet loss.
But let's assume a few packets go astray;
we will detect this by noting the sequence numbers.
Now let's further assume for simplicity that there are an arbitrary number
of octets per packet,
but the same number in every packet.

The only thing one could do to keep the TDM equipment happy from the
bit-timing
point of view would be to replicate the previous packet (which I will assume
that you store)
a number of times.
The TDM equipment now sees these frames coming in with incorrect sync.
It counts one or two incorrect syncs and gives a red alarm.
Typically it will then stop all traffic for 10 seconds and then try to
resync.

So using this method with standard TDM equipment, losing a packet or two
causes complete system failure!
That's not the kind of protocol I would recommend that we adopt.

You may respond by saying that we should also know what the sync bits should
be,
and keep track of the phase in each packet, and then send fake packets with
reconstituted sync. This WOULD work from the point of view of avoiding the
TDM
equipment from closing down for 10 seconds, but requires the edge device to
know
an awful lot about TDM (the different types of T1 and E1, the way the syncs
are used,
and the precise phase of the sync). I do not think we want that either.

> Option 2) Use a framer to unscramble the T1/E1 bit stream 
> into its separate components as follows:
> described above. There is no requirement to include a 
> complete multiframe or superframe in each packet.

This is a considerable deviation from what Stewart has been calling
"minimal intervention", and is exactly what I don't like about Sasha's
handling of CAS in his new draft. It also, once again, requires the edge
devices
to know a lot about TDM, although you hide this knowledge in the framers
(e.g. we need different framers or to configure the framers for various
types of T1 and E1 sync and different signaling schemes (SF, extended SF, 
CAS cadence-toleration R2, Chinese R1.5, etc).

Isn't it a lot easier to leave the TDM stream alone?
Leave the bits where they are and forget about all the details.
Just tell me where the structure starts!!! That's all that is needed!!!

> 
> I believe both options should be supported. The required 
> option will depend on the application.

I believe that neither of these options is correct for structured E1/T1.
Neither is needed for unstructured.

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 9 Apr 2002 20:01:20 +0200

Geoff and all,
Please see some comments inline.	
Hopefully they will be of some interest to (ate last some) of you.
With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2002 4:51 PM
> To: [email-masked]
> unstructured T1
> multiframes,
> replayed at the
Of course this will always work - provided that BW in the PSN is free.
(So far, unfortunately, I still have to pay for mine ;-)
It is a nice example of usage of the NSP construct in the latest protocol 
layering document - use a TDM cross-connect as an NSP (and fill unused
timeslots with idle code. )
It is also a very nice illustration of one of the Fundamental Networking 
Truths from RFC 1925 - it is always easier  to move the problem to 
another place in the newtork (or, in this case, in the PE device)
than to solve it!
> Transmit the CAS signalling bits in separate packets.
Leaving aside implementation issues and terms (control CPU, TDM bus etc.),
I'd like to 
point out that:
1. The option that uses signaling packets is more modular than the
AAL1-based one
    (this is a politically correct way to describe Geoff's proposal to
process
    signaling in the control CPU and the TDM data in some other device):
    a) Format of the TDM data packets does not depend upon the specific
signaling 
       scheme used by the CE applications and hence can be implemented once
       o For telephony applications both Channel-Associated Signaling (CAS) 
         and Common Channel Signaling (CCS) can be supported. All that is
needed
         is to define the signaling packets' payload format 
      o What is more, new application-specific signaling schemes can be
introduced
         (e.g., for non-telephony applications) and supported without any
change in the 
         TDM data format or implementation of en/de-capsulators
    o draft-anavi uses (or so it seems to me - Yaakov, please correct me if
I am wrong)
       a similar scheme in conjunction with CCS ("HDLC frames") but not with
CAS. 
2. The option that uses signaling packets is more BW-effective
(approximately by 4.5 - 5.5%) 
    than the signaling packets-based one:
    a) Approximately 2.4% (9/376) go for the AAL1 headers and pointers
    b) Between 2 to 3% (1/48 to 1/32) go for transmission of (mostly
constant) CE application
       state with each multiframe structure (the number varies depending on
the multiframe size)
3. As Yaakov has mentioned, AAL1 allows to decouple the multiframe (MF) 
    structure size from the PW packetization latency. If carrying the MF
structure 
    across the PSN is pursued as a goal, AAL1 looks like a reasonable way to
achieve it. 
    I do not know, though, whether any application really requires this
4. AAL1 introduces a tight coupling between the (hard-coded) cell/subframe
size and the PW 
    packetization delay. E.g., if you carry 8*DS0 with CAS, your minimal
packetization
    delay would be 47/64 = 0.734375 ms and could be increased with
(approximately)
    the same granularity. I believe that this is acceptable for most
applications, but 
    working with fractions does not make the life of the IP network
operators easier.
5. The AAL1-based scheme is actually less robust than the scheme with the
    signaling packets:
    a) Loss of a single packet in the AAL1-based option may result in loss
of up to 329 bytes
        of TDM data in addition to whatever data has been contained in the
packet 
        - if the lost packet contained an AAL1 pointer for a 8-cell/subframe
chain that crossed the
        inter-packet boundary (7*47=329). Forcing alignment of
8-cell/subframe chains with the
        packet boundaries would solve this problem but at a price: it would
substantially increase 
        packetization delay (in the same example, it would be 47/8 = 5.875
ms) - more
        than in a "multiframe-per-packet" scheme mentioned by Yaakov
    b) Loss of a single data packet in the signaling packets-based option
results in loss of
       just the data it has contained - no more, no less
    c)  I assume that Yaakov's frequent refererences to high robustness of
the 
        AAL1-based scheme actually mean that (unchanged) CE application
state 
        is transmitted with the TDM data all the time. Of course this
guarantees 
        very good robustness of CE application state recovery, but carries a

        certain price tag in the terms of BW (see item 2b above)
    d) The troiple redundancy mechanism used in conjuction with the
signaling packets
        option is reasonably simple and effective. It has originated in the
ATM (AAL2 world),
        has been successfully used with IETF protocols and standardized in
RFC 2833.
       The timeouts can be configurable with the specified values as
defaults.
> >A much more flexible alternative is to allow encapsulation 
> of different byte lengths,

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 10 Apr 2002 08:23:05 +0200

Yaakov and all,
I do not understand some of your reasoning regarding loss of packets.
Please see comments/questions inline.
----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2002 5:34 PM
> To: [email-masked]'; [email-masked]
... snipped...
> but the same number in every packet.
We do not deal with "arbitrary number of octets per packet" -
a packet ALWAYS contains an integer multiple of the native
circuit frame. 
> point of view would be to replicate the previous packet 
Your assumption is not what has been definedin the draft.
 1) For unstructured TDM, AIS will be injected in the outgoing
    end service. Since Option 1 discussed here deals with unstructured
    TDM, this is the relevant case.
 2) For N*DS0, Idle Code will be inserted in the appropriate time slots
     of perfectly valid TDM frames.
> The TDM equipment now sees these frames coming in with incorrect sync.
This would not happen EVEN if the last received packet were repeated because
the sync structure would be reproduced.
> Typically it will then stop all traffic for 10 seconds and then try to
I seem to remember from my SDH days that TDM equipment withstands
up to 50 ms of "Red Alarm"/AIS before closing traffic and going to re-sync.
This is why 50 ms is defined as the upper limit for SONET/SDH protection
switch
duration. For a service using, say, 1 ms packetization delay, you should
loose
a better part of  50 consequtive packets - this is not what I would call an
occasional
loss of a single packet.
Of course, the PSN outages may result in loss of packets for much more than
50 ms.
But this is a common problem, and the solution lies with either MPLS-based
fast
reroute mechanisms or with fast rerouting using improved IS-IS/OSPF. Neither
is
within the scope of the PWE3.
> That's not the kind of protocol I would recommend that we adopt.
How is what you say specific to any one of the TDM proposals?
> reconstituted sync. 
There is no need to track the phase of the sync bits in each packet, since
thery would be always in the same position as long as tehir phase does
not change in the incoming end service.
Outage of the latter would result in shift of the phase in the packets, too.
I believe
that neither proposal provides protection against THAT!
>This WOULD work from the point of view of 
> avoiding the
> TDM
As I have noted in my previous email, Bob's option (always work with
unstructured TDM)
places a TDM cross-connect as an NSP block within the PE. TDM cross-connects
presumably must "know an awful lot about TDM" including all the things you
have
mentioned and more. E.g., if CAS is carried using "T1 robbed bits" they
spoil
quality by claiming some additional bits etc. 
> handling of CAS in his new draft. 
Personally I do not see why the ATM-CES structure you suggest to carry
using AAL1 is a lesser deviation. It does not exist in the native service!
In order to create it the device must "know an awful lot about TDM" (unless
you happen to get it ready if your end serviceis TDM over AAL1).
Our proposal separates data from signaling - such a separation involves
about the same TDM knowledge as is required for creation of the
ATM-CES structure. 
As I have mentionedin my previous mail, data handling is fully compliant
with the minimal intervention principle. Signals undergo a very simple
encoding,
and only changes are sent. It works equally well with ALL signaling systems
(as I have also noted in
> It also, once again, 
> requires the edge
Please elaborate on how does ATM-CES over AAL1 help to avoid
this knowledge
> Leave the bits where they are and forget about all the details.
That is NOT what your proposal says - the bits ARE moved when you build
the structure you carry, and when you interpret it as well. Getting them
from
the right palces and putting them to the right places back requires the same
amount of knowledge of TDM in the device. The only 
alternative is to map TDM to AAL1 beyond the device and to 
provide AAL1 over Packet PWs.

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 10 Apr 2002 09:05:51 +0300

Sasha, Geoff, and all, 

... and thick and fast they came at last, and more and more and more ...

I have taken the liberty to clean up the previous emails,
as the interleaving technique has become unwieldly.
I hope I am answering everything.

[Sasha] 1. The option that uses signaling packets is more modular than the
> AAL1-based one (this is a politically correct way to describe Geoff's
proposal to
> process signaling in the control CPU and the TDM data in some other
device):

Granted. But this modularity comes at a price I believe that we do not have
to pay.

[Sasha]   a) Format of the TDM data packets does not depend upon the
specific
> signaling scheme used by the CE applications and hence can be implemented
once

Almost true. The format obviously depends on the number of bits devoted to
each timeslot,
so that SF and extended SF need separate treatment, and E1 is different.
But I agree that there are only a limited number of cases.

[Sasha] For telephony applications both Channel-Associated Signaling (CAS) 
> and Common Channel Signaling (CCS) can be supported. All that is needed
> is to define the signaling packets' payload format.
<snip>
> draft-anavi uses (or so it seems to me - Yaakov, please correct me if I am
wrong)
> a similar scheme in conjunction with CCS ("HDLC frames") but not with CAS.

CCS in trunk associated mode simply occupies a standard timeslot
and so can be handled transparently, requiring no special treatment.
We added the HDLC mode for those purists who want to reduce the packet size
a bit by de-flagging the HDLC.

[Sasha] The option that uses signaling packets is more BW-effective <snip>

I agree. AAL1 and "special signaling bits packets" methods have about the
same efficiency.

[Sasha]  As Yaakov has mentioned, AAL1 allows to decouple the multiframe
(MF) 
structure 
achieve it. 
>  I do not know, though, whether any application really requires this

We have found this to be a definite advantage, although I admit that it
gives
even more flexibility that usually needed for the E1/T1 case. For E3/T3 size
frames
(assuming we use AAL1 as in my draft and not forego it as in my compromise
proposal)
this flexibility becomes much more advantageous.

[Sasha] 4. AAL1 introduces a tight coupling between the (hard-coded)
cell/subframe
size and the PW packetization delay. <snip>

Placing integer number of 48 byte cells into a packet is for implementation
simplicity.
We could really get along with any integer number of bytes, but then if a
packet were
to drop I would have to compute where the next pointer is. This is not a
difficult calculation
(it is simply a modulo) but I prefer to do without it.

[Sasha] Loss of a single packet in the AAL1-based option may result in loss
of up to 329 bytes of TDM data <snip>

True, although a very worst case scenario. In such cases the user will hear
a short click.
However, our priority is to not drop sync or on-hook active calls. That we
accomplish. 

<snip> I agree with the rest of Sasha's remarks here <snip>

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 10 Apr 2002 09:34:59 +0300

Here's the next installment, in format similar to the previous.
[Sasha] We do not deal with "arbitrary number of octets per packet" -
> a packet ALWAYS contains an integer multiple of the native circuit frame. 

Yes, I know. I was refering to Geoff's suggestion!

[Sasha] Your assumption is not what has been definedin the draft.

See above.

[Sasha] I seem to remember from my SDH days that TDM equipment withstands
> up to 50 ms of "Red Alarm"/AIS before closing traffic and going to
re-sync.

Unfortunately, this tolerance is implementation and geographic dependent.
In the early days of our product we went according to your assumption as
well.
Then we got tired of explaining this assumption to customers around the
world
whose PBXs were resetting. 

[Sasha] Of course, the PSN outages may result in loss of packets for 
> much more than 50 ms.
> But this is a common problem, and the solution lies with 
> either MPLS-based fast reroute mechanisms or with fast rerouting using
improved 
> IS-IS/OSPF. Neither is within the scope of the PWE3.

Agreed.

[Sasha] There is no need to track the phase of the sync bits in each 
> packet, since thery would be always in the same position as long as tehir
phase does
> not change in the incoming end service.

Once again, I was refering to Geoff's suggestion.

[Sasha] As I have noted in my previous email, Bob's option (always work with
> unstructured TDM) places a TDM cross-connect as an NSP block within the
PE. TDM 
> cross-connects presumably must "know an awful lot about TDM" including all

> the things you have mentioned and more. 

I agree.  If we require some of their functionality maybe it would be a good
idea
to use NSPs (whether in separate boxes or integrated into the PWE edge).
But here I do not belive we need any of the extra functionality.

[Sasha] Personally I do not see why the ATM-CES structure you suggest to
carry
> using AAL1 is a lesser deviation. It does not exist in the native service!

True.

[Sasha] In order to create it the device must "know an awful lot about TDM"
(unless
> you happen to get it ready if your end serviceis TDM over AAL1).

Not true. 
Once again, the ONLY thing the AAL1 has to know is where the structure
starts,
and this can be easily acquired from the TDM equipment.
The AAL1 needn't know whether the TDM is SF extended SF, 1, 1.5 2, 3, or 4
bit signaling, 
wink or ground-start or E&M or etc. etc. etc. 
It doesn't really even care whether there is CAS or CCS signaling,
(although it is conventional in the AAL1 literature to separate the two
cases 
in order to better explain them) since exactly the same mechanism is used.
In fact, other than the obvious differences in rate and the "odd-bit-out"
the AAL1 doesn't even care if you feed it T1 or E1.

I don't call that "an awful lot about TDM".

[Sasha] Our proposal separates data from signaling - such a 
> separation involves about the same TDM knowledge as is required for
creation of the
> ATM-CES structure. 

Nope.

[Sasha] As I have mentionedin my previous mail, data handling is 
> fully compliant with the minimal intervention principle.

Have you checked the timing tolerances required for MFR2? 
Here the bits and in-band tones have specific time relations.
Are you sure that separating the signaling bits into message packets and
then replaying them
will not cause tones to apear before bit winks.
I know that some VoIP GWs have had this sort of problem.

All I'm trying to point out is that "special handling" of signaling bits
is AGAINST the minimal intervention principle, and hence can cause problems.

> Please elaborate on how does ATM-CES over AAL1 help to avoid

We leave the bits where they were (we don't even care whether they are there
or not).
So we don't get into all these problems.

[Sasha] > Isn't it a lot easier to leave the TDM stream alone?
> That is NOT what your proposal says - the bits ARE moved when 
> you build the structure you carry, and when you interpret it as well. 

Nothing is ever "moved" in the AAL1 method. 
We only chop the byte stream into constant length subfames
and insert a one byte header (the pointer).

In the AAL2 method we indeed "move" bytes around.
However, even this moving is trivial.
All we do is gather together the bytes that belong to each timeslot,
and tack on a header to this buffer. We then place the encapsulated
timeslot buffers one after another. This allows us to not transmit
a buffer which doesn't contain any data.

This is indeed "moving around", but it is a "moving around"
of a trivial sort. It certainly does require a little more knowledge about
TDM
(we have to know whether the channel is active)
but even this information can be gleaned from the TDM equipment
if you don't want to get your hands dirty.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 10 Apr 2002 10:14:38 +0200

Yaakov and Geoff,
Please see some comments/questions inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, April 10, 2002 8:06 AM
> To: Alexander Vainshtein; [email-masked]'
> Cc: [email-masked]
Can you elaborate a bit?
> specific signaling scheme used by the CE applications and hence can 
> be implemented once
> 
> Almost true. The format obviously depends on the number of 
> bits devoted to each timeslot,
Nope. There are separate formats for unstructured E1, unstructured
T1 and N*DS0, but D4/SF, ESF etc. do not have to be taken into 
account.
> [Sasha] For telephony applications both Channel-Associated 
> Signaling (CAS)  and Common Channel Signaling (CCS) can be supported. All 
> that is needed is to define the signaling packets' payload format.
> <snip> 
And by saving BW by not transmitting idle code?
> I agree. AAL1 and "special signaling bits packets" methods 
> have about the same efficiency.
> 
Unless something is very wrong with my English, your first and
second statements are in direct contradiction with each other.
Can you please elaborate?
> 
> [Sasha]  As Yaakov has mentioned, AAL1 allows to decouple the 
> multiframe (MF)  structure size from the PW packetization latency. If 
> carrying the MF structure across the PSN is pursued as a goal, AAL1 looks
like a 
> reasonable way to achieve it. 
> We have found this to be a definite advantage, although I 
> admit that it gives even more flexibility that usually needed for the
E1/T1 case. 
> For E3/T3 size frames (assuming we use AAL1 as in my draft and not forego
it as in 
> my compromise proposal) this flexibility becomes much more advantageous.
> 
Why? Can you elaborate?
> cell/subframe size and the PW packetization delay. <snip>
> 
> Placing integer number of 48 byte cells into a packet is for 
> implementation simplicity.
And it just happens to be exactly the number of bytes in the ATM cell
payload?
> We could really get along with any integer number of bytes, 
In a packet? or in a cell?
> but then if a packet were to drop I would have to compute where the next
pointer is. 
> This is not a difficult calculation
The next pointer or the next AAL1 header? 
> True, although a very worst case scenario. In such cases the 
> user will hear a short click.
> However, our priority is to not drop sync or on-hook active 
> calls. That we accomplish. 
Packets can (and will) be dropped not only the the PE devices
that implement this or that proposal but also by the PSN routers
- and you do not have much control over THAT.

---

From: "Bob Barrett" <[email-masked]>
Date: Wed, 10 Apr 2002 09:09:21 +0100

Dear all,

This part .....

I don't think this matches ITU specifications on a frame slip, and multiple
lost packets are essentially multiple instances of frame slip.

There are good reasons to continue to send a stream on the output T1 / E1
that looks like a valid stream from the sync point of view, even if the data
is either repeated (ITU single frame slip spec.) or some other code (idle or
whatever) in the payload bearer channels.

All this can be done whilst carrying the complete E1 or T1 as a 'clear
channel' with an arbitrary clock (to support PE to PE private line). Just
because it is carried as clear channel doesn't preclude the implementation
from being aware of the content, specifically where the TS0 or 193 bit is
when the payload is voice.

It will be good to meet you all at the next meeting, so that we can discuss
all this over a class of water and a the back of an envelope.

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Sasha
Vainshtein
Sent: 10 April 2002 07:23
To: 'Yaakov Stein'
Cc: [email-masked]'; [email-masked]
Subject: RE: [PWE3] TDM draft consolidation

Yaakov and all,

... snipped...

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 10 Apr 2002 12:01:55 +0200

Bob,
Please see the comment inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, April 10, 2002 10:09 AM
> To: Sasha Vainshtein; 'Yaakov Stein'
I do not think that a lost packet is a multiple instance of a frame slip.
Compare this behavior with handling of a LO SONET/SDH defect
(say, TU AIS/LOP, LO VC Unequipped/TIM/PLM  etc.). In each case
the LO adaptation function sends out AIS of the carried service. 
IMHO, wheh it comes to carrying TDM circuits over PSN, whatever
is acceptable in a SONET/SDH network is good enough (with a spare)
for me. This also refers to Yaakov's comment regarding reaction
of TDM equipment to service disruptions under 50 ms.
 
> whatever) in the payload bearer channels.
... snipped ...
> all this over a class of water and a the back of an envelope.
Hope to mee you all in Yokohama then... 
> either MPLS-based
> you build

---

From: Akiva Sadovski <[email-masked]>
Date: Mon, 15 Apr 2002 12:11:32 +0200

Yaakov, Geoff and all:
  please see my question(s) inline:

<snip>
> Typically it will then stop all traffic for 10 seconds and then try to
   1. Yes, you may find components that it take them up to 30 (!) seconds to
settle into a state free 
of generating frame slips and bit errors after severe impairment. (Btw, such
behavior is considered to be a bug...) 
Hardware reset or reference clock phase hits are considered to be such
impairments, not LOF. However, typical systems regains frame alignment in
3-5 ms (few multiframes)
   2. In AT&T's ACCUNET T1.5 Service: Description abd Interface
Specification i've found the following clause:
"7.7 Conditions Causing The Initiation Of Carrier Failure Alarms (CFA)
 On detection of an LOS or OOF not caused by 'all  ones' or AIS, a rise
slope type integration process starts that declares a CFA after 2.5 seconds
of continuous LOS or OOF..."
 Does it mean that for *most* systems few incorrect frame syncs wouldn't
cause service disruption ?
 
     thanks,
          Akiva