Subject: RE: draft-davari-pwe3-aal12-over-psn-01

From: Shahram Davari <[email-masked]>
Date: Thu, 13 Mar 2003 06:46:42 -0800

Sasha,

Thanks for your good comments. Please see some observations in line.

Thanks,
Shahram

>> 1) One could use packets with less than 8 cells in them. This 
>> could handle
>> random packet loss, but can't handle burst packet loss.
>>
>Looks like the simplest thing to do and does not require any change in
>Martini.
>BTW, if, in addition to keeping less than 8 cells per packet, 
>you keep the
>number of 
>cells per packet ODD, you (more or less) can be sure that loss 
>of up to 
>7 consecutive packets will be detected at the egress of the 
>AAL1 path (even
>if the handling may be not quite accurate).

Agree. I could add this to the draft.

>>
>> 2) One could generate ATM cells with pre-configured value 
>> such as "All 1's"
>>
>I am not sure I follow you here. Do you mean "ATM cells", ATM cells'
>payload"
>or AAL1 frames' payload"? 
>And why not to generate (if you can) some ATM AIS?

I meant a fixed ATM payload. Generation of ATM AIS is also an appropriate menas 
of informing ATM termination node that there is a failure and would enter AIS state. 
After receiving a CC cell or a user cell the ATM node would trigger out of AIS state.
However, if there is a single packet loss every second, then the ATM termination node
will toggle between AIS state and non-AIS state. I could add this to the draft, but I
think ATM-ENCAP should also add this as an option. 

>> 
>> 3) One could use interpolation, but this requires detailed 
>> knowledge of the ATM traffic
>>
>Agreed. This is why I do not think it is compatible with [ATM-ENCAP].
>>
>> 4) If ATM/AAL1 and PW function are all implemented in the 
>> same box, then the PW block
>> could use a local means of communicating the packet loss to 
>> the AAL1/ATM block, such as what is described in anavi-draft.
>> 
>See above.
>>
>... snipped to the end of the original message #1 ...
>> -----Original Message #2----
>> From: Shahram Davari [mailto:[email-masked]]
>> Sent: Wednesday, March 12, 2003 8:44 PM
>> To: Sasha Vainshtein; 'Yaakov Stein'
>> Cc: [email-masked]
>> Subject: RE: [PWE3] draft-davari-pwe3-aal12-over-psn-01
>> 
>... snipped...
>> >AFAIK, draft-anavi does not discuss treatment of OAM/RM cells.
>> >But [ATM-ENCAP] and, by implication, draft-davari define such
>> >treatment in detail. As a consequence neither the cell transport 
>> >modes nor  the PDU mode defined in [ATM-ENCAP] and referenced 
>> >in draft-davari can guarantee a fixed number of  cells per 
>> >packet due to 
>> >the [ATM-ENCAP] requirement to send OAM/RM cells "in order" 
>> >and in separate packets. IMO, this makes [ATM-ENCAP]-compatible 
>> >"interpolation for lost packets" somewhat problematic - unless 
>> >you always send a single cell per packet.
>> >Did I miss something?
>> >>
>> Your comment is valid, however, it is valid only for PDU 
>> mode. Cell modes don't send OAM cells in separate packet.
>>
>Correct. Sell modes do not fragment packets, but they
>do not guarantee fixed number of USER (in your case AAL1) cells 
>per packet either. So this does not really help.

Why Can't the ingress PE be configured to send fixed number of cells
in a packet? From ATM-ENCAP it seems that the egress PE should be able to receive
any packet size up to the configured max number of concatenated cells, including
fixed size packets that are smaller than the MTU.

>>
>> I guess one of the restrictions of PDU mode would be as following:
>>
>> If the PEs don't have a synchronized clock (i.e, use adpative 
>> clock), then to transport AAL1 traffic, OAM cells should not 
>> be transmitted at ingress PE, or they may be transmitted 
>> between PW packets ( which could cause misordering of OAM cells).
><
>I do not follow you. IMO, the PEs carrying AAL1 traffic over a 
>PW do not
>care
>about clock.

The reason for requiring fixed size packets is adaptive clock recovery.
However, if both PEs have the same clock, then there is no need to have fixed size packets.

>Once more: using an odd, less than 8 number of cells per 
>packet looks like
>the
>simplest precaution that provides for reasonable behavior and is fully
>compatible
>with the existing [ATM-encap]-compatible equipment "as is".

Agree.

>... snipped to the end of the original message #2 ...
>