Subject: Re: issue with frame fragmentation

From: George Wilkie <[email-masked]>
Date: Fri, 19 Apr 2002 11:02:52 +0100 (BST)

On Fri, 19 Apr 2002, Stewart Bryant wrote:

>
>
> George Wilkie wrote:
> >
> > On Thu, 18 Apr 2002, Andrew G. Malis wrote:
> >
> > > Sasha,
> > >
> > > > > >I agree that using FRF.12 NNI fragmentation outside the PW
> > > > > (e.g., in the
> > > > > >NSP) will increase the size of each packet carried over the PW
> > > > > >by 4 (if the FR header is 2 octets) or 6 (if it is 4 octets) octets.
> > > > >
> > > > > Actually, it's 6 or 8 octets, depending on the size of the
> > > > > NLPID.  See
> > > > > figures 5-2 and 9-2 in FRF.12.
> > > > >
> > > >I did. Both refer to end-to-end fragmentation, and I have been
> > > >talking about NNI fragmentation because I assumed that this
> > > >would be the proper mode between a pair of NSPs an two ends
> > > >of the PW. Has I been wrong?
> > >
> > > Yeah, you can't use UNI or NNI fragmentation because those are local to the
> > > interface, and use the fragmentation header in front of the FR header - it
> > > doesn't look "standard" to anything expecting a FR header.  It's best
> > > confined to an actual local access line.  End-to-end fragmentation uses
> > > true FR headers, and can pass through any intermediary FR network, so using
> > > end-to-end fragmentation makes the most sense and makes the fragmentation
> > > interoperable with anything that may be along the path.
> >
> > Andy,
> >
> > I don't see why UNI/NNI frag cannot be used across the PW.
> > The PW is the "interface" and the NSPs are the UNI/NNI fragmentation peers.
> > With UNI/NNI, every packet has a 2 byte frag header stuck on the front
> > just prior to handing to the PW and removed by the receiving NSP just after
> > getting it from the PW.
> > Of course, the frag header is needed on all packets, not just those which
> > need fragmented, however you do get sequencing thrown in ;)
>
> I had missed that extreamly bizare part of FRF12. The UNI/NNI header
> has a bit explicitly included to allow the receiver to discriminate
> between fragmented and unfragmented packets, and yet it requires
> all packets to include the fragmentation header. Any idea why this
> is?

The text implies it is to detect misconfiguration of the peer.
I guess this is easier if all packets are thrown away rather than just those
needing fragmentation.

Andy?

Cheers.

>
> Stewart
>
> >
> > Cheers.
> >
> > >
> > > >I have looked into RFC 1122 to check what exactly 576 means.
> > > >Unless I am mistaken, it includes both IP header and data.
> > > >Hence if you take this as a reference, max. payload size
> > > >of an MPLS packet carrying FR would be 564 bytes, while
> > > >max. payload size of an IP packet carrying FR would be
> > > >552 bytes. Additional overhead resulting from doing FRF.12 NNI
> > > >fragmentation in NSP would trequire 4 or 6 octets in the packet
> > > >(depending on usage or non-usage of the extended FR header), i.e.
> > > >something between 0.7 to 1.1%. 8 octets (which I still do not
> > > >understand) would give 1.4%.
> > >
> > > Thanks for the more detailed analysis.  The 8 octets is derived from a
> > > four-octet NLPID, UI octet, NLPID octet, and two octets of fragmentation
> > > header.  This is figure 5-2 with a four-octet NLPID rather than a two-octet
> > > NLPID as pictured.
> > >
> > > > >
> > > > > Granted, it's still not all that much in the big picture, but I would
> > > >posit
> > > > > that in an implementation, since you ALREADY have a sequence number in
> > > > > the header,  it's at worst equivalent, and perhaps even easier to just do
> > > >the
> > > > > fragmentation as you're transmitting long frames into the PW
> > > > > than it is to have a completely separate fragmentation process preceding
> > > > > the PW transmission.
> > > > >
> > > >IMHO the question here is interoperability.
> > > >If fragmentation is done in the PW you can either define the fragmentation
> > > >support as MUST (the draft does not say that)
> > > >or allow negotiation of fragmentation capabilities during
> > > >the PW establishment.
> > > >If you leave fragmentation to NSP, then the problem is moved to the FR
> > > >domain (in full agreement with RFC 1925:-).
> > >
> > > Even in that case, the two endpoints would need some sort of agreement as
> > > to whether FRF.12 was in use or not across the PW.  So it's really the same
> > > either way.
> > >
> > > Thanks,
> > > Andy
> > >
> > >
> > > _______________________________________________
> > > 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: "Andrew G. Malis" <[email-masked]>
Date: Fri, 19 Apr 2002 10:53:49 -0400

George,

>I guess this is easier if all packets are thrown away rather than just those

At the time when we were working on FRF.12, we discussed whether or not we 
should allow a mix of frames with and without the fragmentation header when 
using UNI/NNI fragmentation, or have the header on all frames.  The 
consensus at the time was that it made implementation easier if either all 
frames had the fragmentation header or not.  Also, if you allowed a mix, 
misconfiguration might not be detected until the first time a large frame 
came though some time after the interface came up.  This way, you know 
instantly (on the first incoming frame) if the two sides of the interface 
don't have consistent configurations, which we figured is more convenient 
operationally.

Cheers,
Andy