[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PWE3] draft-ietf-pwe3-atm-encap-01.txt
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
------------------------------------------------