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

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 13 Mar 2003 09:42:02 +0200

Shahram, Yaakov and all,
Please see some answers to two separate messages on the subject.

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 #1-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Wednesday, March 12, 2003 5:12 PM
> To: Sasha Vainshtein
> Cc: [email-masked]'
> Subject: RE: [PWE3] draft-davari-pwe3-aal12-over-psn-01
> 
> 
> Hi Sasha,
... snipped ...
> 
> I will make it clear in the next revision that the payload could be
> omitted only if the ingress can set L-bit and the egress can 
> interpret it.
> 
Seems OK. Probably means that this capability (as well as other ATM-related
capabilities, e.g., generation of F5 AIS) should be exchanged between
the PEs at the PW setup.
... snipped ...
> 
> This is something that should be addressed by the 
> Martini-draft, since the
> 1:1 and N:1 cell modes are not specific to particular AAL 
> type. The R-bit is
> meant for complete PW break or long term congestion. However, 
> there are
> a couple of ways to handle packet loss due to short term congestion:
> 
> 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).
>
> 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?
> 
> 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.
>
> 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. 
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".
... snipped to the end of the original message #2 ...