Subject: draft-ietf-pwe3-atm-encap-01.txt

From: [email-masked]
Date: Tue, 17 Jun 2003 14:28:10 -0400

Hi, Luca,

This is Joey Zhong from Mindspeed System Inc (My site was known as Maker 
systems before it's aquired by Mindspeed). We are implementing 
draft-ietf-pwe3-atm-encap-01.txt on our OC-48 network processor. The 
engineering group here found couple of potential enhancement for the draft 
during implementation. Please see following proposal for the details. 

We've been reviewing draft-ietf-pwe3-atm-encap-01.txt. As it seems this 
document is settling down for overall functionality, it might be time to 
look at advantages of different codings and positions of fields in the 
frames.

The draft shows several different positions and orders of the Length, 
Sequence Number, and Flags fields partially copied herein:

in section 4.1 (general):
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rsvd  | Flags |Res|   Length  |     Sequence Number           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

in section 6.6 (VCC service):
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Pseudo Wire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Optional Length and Sequence Number        |M|V|Res| PTI |C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

in section 6.7.1 (VPC service):
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Pseudo Wire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Optional Length and Sequence Number        |M|V|Res| PTI |C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

in section 7.1 (N-to-1 service):
   implied usage of the section 4.1 control word.

in section 8.2 (SDU service):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Res  |T|E|C|U|Res|  Length   |   Sequence Number (Optional)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

in section 9.2 (PDU service):
   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Optional Length and Sequence Number        |M|V| Res |U|E|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Looking at them all together, you can see there are several locations for 
the length, sequence, and flags fields. It would make more sense to have 
these fields have a normal position or at least relative ordering across 
all of the service modes while some fields would vary. Notice in the 
"Optional Length and Sequence Number" field (assuming this states order of 
the two), the Sequence number is not on a half word boundary. Notice the 
major differences for the SDU and PDU mode which are otherwise very 
similar by function. As we consider moving the fields and bits around, we 
should do so in a way that simplifies the bit and byte banging needed by 
both hardware and software solutions.

I would recommend something like:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Sequence Number         |    Length     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This construct has the 16 bit sequence number aligned on a half word, the 
length aligned on a byte boundary, and has the flags in the least 
significant byte to allow the best availability of bit manipulation 
instructions. Not also that in the VPC and VCC modes, the flag field of 
the first cell in the packet has to follow the Sequence and Length fields 
allowing the offered ordering to be similar throughout the PWE3 ATM modes. 
I understand that this doesn't take into account the possibility of 
cramming a PID into the control word.

Then looking at the flags, it make little sense to have a different 
ordering of the E, C, and U bits in each encoding and there is an ideal 
order.

I would recommend:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Sequence Number         |    Length     |M|V|Res|O|E|U|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I've swapped the E and U bits from the PDU service mode as the E, U, C 
ordering aligns with the corresponding meaning from the ATM cell header. 
Even though work needs to be done across many cells to determine the ATM 
control word setting of E and C, the alignment will help with 
calculations.

Other possibilities shown in the encoding is to have a bit 'O' to indicate 
OAM cells. For the 'T' bit meaning in the SDU service mode, the 'O' bit 
could be used for that meaning. Note the alignment with the ATM cell 
header and now a perfect match between the VCC/VPC service flags (PTI/C) 
and the O, E, U, and C ordering.

The M and V bits are not required in all modes as presently defined, but 
their meaning could be carried throughout. Interesting that the SDU mode 
currently defined doesn't indicate "packet" or "cell". This is one service 
where carrying the meaning through would help.

The U bit has different meanings that are non-overlapping. In the SDU 
mode, U is the CPCS-UU bit while in PDU mode it is the ATM user-to-user 
bit. One limitation is that the SDU mode cannot indicate a continuation or 
end of a fragmented SDU. This wasn't presently specified anyway.

comments?

Joey Zhong

------------------------------------------------
Joey Zhong
Firmware Engineer
Mindspeed Technologies (TM), a Conexant business
8 Technology Drive             508-621-0794 desk
Westborough, MA  01581-1756    508-621-0605 fax
------------------------------------------------