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

From: John Fischer <[email-masked]>
Date: Wed, 18 Jun 2003 09:48:24 -0400

Hi Hoey,
There is a long history behind the bits/bytes and positioning
within the ATM information.

The ATM Forum and ITU worked on this problem in parallel with
the IETF and came to different outcomes based on somewhat
different design goals.  This draft is a merger of the two
approaches.  I believe the draft will shortly be updated.

I added some comments below.
John

[email-masked] wrote:
> 
> 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.

The soon to be uploaded ATM draft should show this:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0| Resvd |    Optional Sequence Number   | ATM Specific  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format was chosen to ensue that the first nibble following the
VC label cannot alias IPv4 or IPv6 (core ECMP issue).

> 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.

In the 1:1 modes, the meaning is carried throughout.
In the N:1 modes, the T bits is similar to the M bits.

> 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.

The PDU mode transports the whole AAL5 PDU - thats the SDU, the padding
and the AAL5 trailer.  The trailer contains the CPCS-UU bit already
so it is not copied to the flag bits.  PDU mode supports fragmentation.
At the egress LER, the device needs to know when to terminate the AAL5
PDU.  For fragments not containing EOP, the bit is 0, for fragments
containing EOP, the bit is 1.

In SDU mode, fragmentation is not supported.

> 
> 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
> ------------------------------------------------