Subject: RE: [PWE3] AAL5 N:1 cells mode issue

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 29 Sep 2005 12:14:05 +0300

Dong,
You have correctly noticed that the length field in the
control word is used to indicate potential padding
added to a short PW packet if it crosses an Ethernet-based
hop in the PSN. (This is why only 6 bits are allocated for
this field!)

Now, the shortest possible packet in the ATM N:1 encapsulation always
includes at least 52 bytes of one cell (you cannot have less than
one cell!) + 4 bytes of the CW + 4 bytes of the PW label.
Hence the minimal amount of data in an Ethernet frame containing
the shortest possible packet of an ATM N:1 PW is 60 bytes, and this,
of course, never will be padded.

Hopefully this helps.

Rgeards,
				Sasha

> -----Original Message-----
> From: Jixiong Dong [mailto:[email-masked]]
> Sent: Thursday, September 29, 2005 9:36 AM
> To: D, Ganesh (Ganesh)
> Cc: [email-masked]; 'Mustapha Aissaoui'; [email-masked]
> Subject: Re: [PWE3] AAL5 N:1 cells mode issue
> 
> 
> Ganesh,
> 
> If you know the packet length, you will determine how many 
> cells in the PW payload. You can get the packet length from 
> the underlying PSN or the Layer 2 packet process(e.g. 
> ethernet packet process), however, this function is out of 
> the scope of PWE3. As you know, the control word is optional 
> in some applications.
> 
> The length field in control word is mainly used to indicate 
> the payload padding field. However, the length field is also 
> used to indicate the length of PW payload. It is the simplest 
> way. I suggest we don't need to limit the use cases of length 
> field. Could anybody tell me why the length field must be set 
> to 0 in the ATM N-to-1 mode? We may provide two ways to be choose.
> 
> Dong
> 
> ----- Original Message ----- 
> From: "D, Ganesh (Ganesh)" <[email-masked]>
> To: "'Mustapha Aissaoui'" <[email-masked]>; 
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, September 28, 2005 11:01 PM
> Subject: RE: [PWE3] AAL5 N:1 cells mode issue
> 
> 
> > Hello Mustapha and Matthew,
> > 
> > Thanks a lot for the replay.
> > 
> > I agree with you and i also thought of going for timer, or 
> monitor for
> > EOF(end of frame).
> > But the problem i face here is. To my understanding once a 
> PW is configured
> > and if TX and RX agrees to have say 20 cell concatenation, 
> it is a MUST that
> > all the PW pkt have 20 cells.  And the Rx will simply 
> divide the payload
> > data by 20 and retrieve the cells.
> > 
> > If i send any thing less than 20 ( say 15 cells) there is 
> no means in
> > PW-control-word to mention that it has 15 cells not 20.
> > 
> > Matthew,
> > By using "sub-TLV" PW end points will(say) negotiate for 20 
> cells. Now you
> > mentioned that it is just a MTU so you can transmit 15 
> cells too. But in Rx
> > side how do i know it has 15 cells?. Do i have to divide 
> the PW-pkt pay load
> > by 48 and get the number of cells? 
> > 
> > Is there any disconnect in my understanding? or is it a 
> rite concern?.
> > 
> > -ganeshd 
> > 
> > -----Original Message-----
> > From: Mustapha Aissaoui [mailto:[email-masked]]
> > Sent: Wednesday, September 28, 2005 7:33 PM
> > To: [email-masked]; 'D, Ganesh (Ganesh)'
> > Cc: [email-masked]
> > Subject: RE: [PWE3] AAL5 N:1 cells mode issue
> > 
> > 
> > Ganesh,
> > One more suggestion below.
> > 
> > Mustapha.
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of [email-masked]
> > > Sent: Wednesday, September 28, 2005 7:38 AM
> > > To: D, Ganesh (Ganesh)
> > > Cc: [email-masked]; [email-masked]'
> > > Subject: Re: [PWE3] AAL5 N:1 cells mode issue
> > >
> > > Ganesh,
> > >
> > > Please see below.
> > >
> > > Matthew
> > >
> > >
> > >
> > > |---------+--------------------------->
> > > |         |           "D, Ganesh      |
> > > |         |           (Ganesh)"       |
> > > |         |           <ganeshd@lucent.|
> > > |         |           com>            |
> > > |         |           Sent by:        |
> > > |         |           pwe3-bounces@iet|
> > > |         |           f.org           |
> > > |         |                           |
> > > |         |                           |
> > > |         |           28/09/2005 11:12|
> > > |---------+--------------------------->
> > >
> > > >-------------------------------------------------------------
> > > 
> ------------------------------------------------------------------|
> > >   |
> > >                                                           
>           |
> > >   |        To:      "[email-masked]'" <[email-masked]>
> > >                                                           
>           |
> > >   |        cc:
> > >                                                           
>           |
> > >   |        Subject: [PWE3] AAL5 N:1 cells mode issue
> > >                                                           
>           |
> > >
> > > >-------------------------------------------------------------
> > > 
> ------------------------------------------------------------------|
> > >
> > >
> > >
> > >
> > > > hello all,
> > > >
> > > > I am facing peculiar problem.
> > > >
> > > > I am planning to use N:1 cell mode as specified in
> > > > "draft-ietf-pwe3-atm-encap-09" for AAL5 cell 
> encapsulation. I will
> > > > have
> > > 25
> > > > cells concatenation with in a Ethernet pkt. i.e. one
> > > Ethernet pkt will
> > > > have 25 AAL5 cells of same VPI/VCI. I know that this is 
> inefficient
> > > > and draft also talks about better ways like 1:1 and AAL5
> > > frame mode,
> > > > but I am limited by resource and forced to do so.
> > > >
> > > > Question 1. Is correct to have more than one cell of same
> > > VPI/VCI in a
> > > > PW pkt.
> > >
> > > MB> N:1 mode can be used to carry a single VCC (so each 
> cell hase the
> > > MB> same
> > > VCI/VPI) if you use cell concatenation, but as you say you
> > > have to repeat the VCI/VPI field in the encap for each cell.
> > >
> > > >
> > > > Question 2. If a AAL5 communication ends and produces a
> > > frame of say 4
> > > > cells. And in PW pkt preparation process, full 25 cells are
> > > not filled
> > > > what i will be doing?. I can't send it, as PW-pkt is less
> > > than 25 cells.
> > > I
> > > > cant keep waiting for next AAL5 frame because it may 
> come or it may
> > > > not come, if i wait for long time it will leak my buffers.
> > >
> > > MB> There is a sub-TLV in the interface parameters called "Maximum
> > > MB> Number
> > > of concatenated ATM cells sub-TLV". This is a maximum number
> > > that the sending PE can concatenate, not a minimum. You can
> > > use implementation specific constraints e.g. related to QoS,
> > > or the PTI bits, to decide when to stop concatenating cells,
> > > and send a PW packet.
> > 
> > MA> you may choose to abort the concatenation process once 
> the EOM cell
> > (last cell of an AAL5 PDU) is received. This way, you 
> always attempt to send
> > a complete Ethernet frame in a PW packet. Also, you will 
> probably need to
> > configure a timer to abort the concatenation process beyond 
> a maximum delay
> > limit. You cannot wait forever for the EOM cell or the 
> maximum number of
> > concat cells.
> > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

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

---

From: Jixiong Dong <[email-masked]>
Date: Thu, 29 Sep 2005 17:29:46 +0800

Sasha,

Yes, the tunnel label + pw label + ATM payload will exceed 64 bytes when you use ATM N-to-1 mode. But why we don't reserve the length function and you may process it or not process it. Thus we can solve the problem introduced by Ganesh in the PW module. Another advantage is that it can be used to check the length of PW packet.

Best Regards,
Dong