Subject: Protocol Action: 'PWE3 Fragmentation and Reassembly' to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 24 Mar 2006 12:03:53 -0500

The IESG has approved the following document:

- 'PWE3 Fragmentation and Reassembly '
   <draft-ietf-pwe3-fragmentation-10.txt> as a Proposed Standard

This document is the product of the Pseudo Wire Emulation Edge to Edge Working Group. 

The IESG contact persons are Margaret Wasserman and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-10.txt

Technical Summary
 
    This document defines a generalized method of performing 
    fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3) 
    protocols and services. 
 
Working Group Summary
 
    This document is a work item of the PWE3 WG.
 
Protocol Quality
 
    This document was reviewed for the IESG by Margaret Wasserman.

Note to RFC Editor
 
Please replace:

     A PE's native service processing (NSP) MAY choose to fragment a
     packet before allowing it to enter a PW. For example, if an IP
     packet arrives from a CE with an MTU which will yield a PW packet
     which is greater than the PSN MTU, the PE NSP may perform IP
     fragmentation on the packet, also replicating the L2 header for the
     IP fragments. This effectively creates two (or more) packets, each
     carrying an IP fragment preceded by an L2 header, for transport
     individually across the PW. The receiving PE is unaware that the
     originating host did not perform the IP fragmentation, and as such
     does not treat the PW packets in any special way. This ultimately
     has the affect of placing the burden of fragmentation on the PE
     NSP, and reassembly on the IP destination host.

With:

In some cases, a PE may be able to fragment an IP version 4 (IPv4) [RFC791]
packet before it enters a PW.  For example, if the PE can fragment and forward 
IPv4 packets with the DF bit clear in a manner that is identical to an IPv4
router, it may fragment packets arriving from a CE, forwarding the IPv4
fragments with associated framing for that attachment circuit (AC) over the
PW.Architecturally, the IPv4 fragmentation happens before reaching the PW,
presenting multiple frames to the PW to forward in the normal manner for that PWType. Thus, this method is entirely transparent to the PW encapsulation and to
the remote end of the PW itself. Packet fragments are ultimately reassembled on
the destination IPv4 host in the normal way. IPv6 packets are not to be
fragmented in this manner.

There are 4 ASCII pictograms that need modifying in the following sections.
Thetechnical sense is exactly the same, these versions simply depict more
context
graphically:

Section 5.3:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |M|H|0|0|0|0|    Length         |              0                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              MRU              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Section 5.4

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |M|H|0|0|0|0|    Length         |              0                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              MRRU             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Section 5.5

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |M|H|0|0|0|0|    Length         |              0                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |x|S|B|E|x|x|x|x|              Sequence Number                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Section 5.6

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |M|H|0|0|0|0|    Length         |              0                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T|L|x|x|S|x|O|P|B|E|x|x|  Ver  |          Length (opt)         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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