Subject: use ideas from, but not true aal

From: Craig Barrack <[email-masked]>
Date: Sun, 14 Apr 2002 17:23:02 -0700

Hi,

I'm new to this, but it seems to me from my few days of studying the
drafts that
(1) a simple payload format is always a preferred idea, but
(2) payload size flexibility is also a good idea, so as to have complete
control over latency.

So what's wrong with the following?
(1) Use "simply formatted" payloads, but with no restriction on payload
size;
(2) Use one structure pointer per packet to deal with the framing issue
presented by the flexible payload size in 1;
(3) Put this structure pointer into the PW header.

Seems like the best of both worlds.  All this intrapayload formatting
complexity (dividing into units of 48, intrapayload sequencing, etc.)
seems unnecessary.   But on the other hand, the concept that we don't
want to restrict payloads to be integer multiples of structure lengths
is logical too.

I apologize if I'm missing something huge here.  Thank you for your
time.

-Craig Barrack

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 15 Apr 2002 11:34:58 +0300

size;
> (3) Put this structure pointer into the PW header.

There is basically nothing wrong with your proposal,
in fact there was some discussion along these lines
after the Minneapolis meeting.

There were three reasons we kept relatively close to the AAL formats
(although you will note that we didn't use anything exotic,
such as SRTS clocking, etc).

1) Service interworking with existing networks.
    In the case of AAL2 this means simple service interworking
    with cellular phone networks which is a major application.

2) The existence of AAL2 which enables significant
    bandwidth reduction when the timeslots are not all active.
    In fact when all the phones are on-hook the BW essentially
    goes down to zero, while all the other methods,
    including AAL1 hog the maximal BW all the time.

3) The fact that all the possible problems have been found
    and solved already. Although this main sound trivial,
    in fact there were several years of "tuning" of the CES
    and LES services over ATM before they got all the bugs out.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 15 Apr 2002 11:36:18 +0200

Craig,
Please see some comments inline.

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: Craig Barrack [mailto:[email-masked]]
> Sent: Monday, April 15, 2002 2:23 AM
> To: [email-masked]
> Subject: [PWE3] use ideas from, but not true aal
> 
> 
> Hi,
> 
Agreed,
> (2) payload size flexibility is also a good idea, so as to 
> have complete control over latency.
Agreed with a reservation: latency resolution below 0.125 ms 
does not make much sense. If you consider SONET/SDH 
for comparison, they provide only 0.5 ms resolution, and
this is universally perceived as sufficient; so why should
the emulated circuit be any better?
> (1) Use "simply formatted" payloads, but with no restriction 
> on payload size;
I would say that working with packets carrying fixed amount of
payload is an advantage. E.g.:
a) If you use RTP for synchronization purposes, 
    fixed payload size results in (approximately) fixed 
    increase in the RTP timestamp and hence improves
    the header compression 
b) Fixed payload size allows to predict (with reasonable accuracy)
    arrival time for the next packet and detect PW outages based
    on these prediction etc.
> (2) Use one structure pointer per packet to deal with the 
> framing issue presented by the flexible payload size in 1;
Several points here.
1. If you are dealing with unstructured E1 or T1, there is no framing to
preserve -
    the framing bits are carried as part of the payload. 
2. If you are dealing with N*DS0, you can consider the framer as a kind of
codec
    The following recommendations from RFC 2736 (which stem from the
     requirement to be able interpret all the data received in each packet 
     autonomously at egress) then apply:
    a) Packet boundaries should coincide with codec frame boundaries.
       Thus a packet should normally consist of one or more complete
       codec frames
    b) A codec's minimum unit of data should never be packetised so that
       it crosses a packet boundary unless it is larger than the MTU. 
       (Note that the "codec" frame boundary in our case in between 1 and 31

       octets, so you do not have to worry about path MTU.)
3. When it comes to combining N*DS0 with Channel-Associated Signaling (CAS),
    you can treat it in several ways:
    a) You can separate N*DS0 data from its accompanying N*ABCD state
vector.
        The data can then be carried "as is", and changes in the state
vector
        are carried using, say, RTP packets with a different RTP payload
type (PT).
        At egress the signaled state change is resynchronized  with the data
        using RTP timestamps. Note that this approach allows:
        o Use of the same data path in the PE device for all types of 
          CE application signaling (including no signaling at all). Common
          Channel Ciignaling (CCS) schemes for N*DS0 and proprietary
          application signaling schemes for other types of TDM circuits
          can all be handled in this way
        o BW saving - only changes in the CE application state are sent
           and these are relatively rare: e.g., duration of most states 
           in the telephony applications amounts to hundreds of ms 
           (see RFC 2833 for the reference)
   b) You can merge N*DS0 data for a single multiframe (whatever size it
happens to be)
       and the N*ABCD state vector for the same multiframe into a single
intermediate 
       structure (defined in ATM-CES) and try to carry this structure across
the PSN. 
       Please note that:
       o This structure does not natively exist in the ingress TDM stream -
it must
          be explicitly created at ingress
       o This structure is not simply copied into the egress TDM stream at
egress
          either - the latter has its own multiframe phase and methods of
carrying
          the ABCD state in the multiframe
       o The size of this structure varies from 17 to 588 octets depending
on the 
          type of multiframing and the number of timeslots. Hence some kind
of
          decoupling between the packet payload size and the structure size
          is indeed desirable. AAL1 is one of these methods; a single
structure
          pointer in the PW header that you have suggested is another
       o Carrying such a structure invariably adds some 2-3% overhead -
because
          the N*ABCD state vector does not change all that often
       o You must use different data path solutions for different signaling
schemes.           
> complexity (dividing into units of 48, intrapayload sequencing, etc.)
As mentioned above, there are two sources of complexity:
a) Creation of an intermediate structure to carry across the PSN at
    ingress and its interpretation at egress. IMHO your proposal
    does not address this problem
b) AAL1-specific complexity. I agree that if the structure must be
   carried, your proposal looks simpler. 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Bob Barrett" <[email-masked]>
Date: Tue, 16 Apr 2002 08:33:55 +0100

Dear all

Extracting CAS seems like an overly complicated mechanism for very little
benefit. The only benefit I can determine is in implementations that would
extract CAS at the point of egress anyway e.g. for aggregation. I guess if a
company already has that technology, coming out of the ATM / DSLAM world,
then there is logic in their proposal to continue that architecture.
Speaking as a person working on a green-field circuit emulation
implementation I would rather keep it really simple.

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Sasha
Vainshtein
Sent: 15 April 2002 10:36
To: 'Craig Barrack'
Cc: [email-masked]; Alik Shimelmits; Akiva Sadovski; Israel Sasson
Subject: RE: [PWE3] use ideas from, but not true aal

Craig,

With best regards,
                                   Sasha Vainshtein

Agreed,
Several points here.