Subject: issue with frame fragmentation

From: "Claude Kawa"<[email-masked]>
Date: Wed, 17 Apr 2002 13:34:56 -0400

We need a separate thread on this one it is a general issue.

The protocol issue about frame fragmentation is whether we put the
fragmentation indicators (bits I and L) in the FRoPW header as in draft
kamapabhava figure 3 shown below:

 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 |P|B|F|D|C|I|L|  Length   | Sequence Number               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3 - FRoPW header structure

or in the payload packet field as in Figure 2 shown below and use FRF.12 (on
frame relay fragmentation) to do the fragmentation by a PE:

       +-------------------------------+
       |                               |
       |       Delivery Header         |
       |                               |
       +-------------------------------+
       |                               |
       |       FRoPW Header            |
       |                               |
       +-------------------------------+
       |                               |
       |       Payload packet          |
       |                               |
       +-------------------------------+

     Figure 2 - General format of FRoPW packet

One question asked (by Danny) was if there is a compelling reason NOT to use
FRF.12. Here is my initial analysis: 

FRF.12 requires that we configure a device to determine whether FRF.12 is
supported or not. FRF.12 is either supported per port or not. If it is
supported the first few bytes of the payload have to be processed because
they contain the fragmentation header. A context look-up has to be performed
by a device (a PE in our case) to determine whether to look into the payload
or not. This clearly slows the processing.

With the fragmentation encoding as proposed in kamapabhava, the control
information about fragmentation is in the PW header. This results in faster
operation. 

Secondly FRF.12 requires to use a sequence number field to ensure that the
receiver got all the fragments to re-assemble them properly. We already have
a sequence number field in the FRoPW header. This use of fragmentation based
on FRF.12 results in additional protocol design and implementation
inefficiencies.

The fragmentation proposed for frame relay is general enough. It is
applicable to other frame based technologies such as Ethernet over PW. It
makes more sense to put the fragmentation control information in the PW
header.

Claude Kawa

---

From: "Claude Kawa"<[email-masked]>
Date: Wed, 17 Apr 2002 16:45:05 -0400

George
This is the first time we discuss the frame fragmentation issue. If we want
a general solution it should be in a general document, I agree with this
point.

The issue is where do we put the fragmentation indicators, the solution we
proposed for frame relay puts them in the PW frame header. I compared this
solution with the other solution where fragmentation is done at the "NSP"
level and found two reasons why the proposed solution using FR/PW header is
better. 

claude

-----Original Message-----
From: George Wilkie [mailto:[email-masked]]
Sent: Wednesday, April 17, 2002 2:05 PM
To: Kawa, Claude [CAR:CS49:EXCH]
Cc: [email-masked]'
Subject: Re: [PWE3] issue with frame fragmentation

I think the last point needs to be answered first.
Are we looking for a general fragmentation scheme which is used for all
attachment circuit types: FR, ethernet, hdlc, etc,
or a FR specific fragmentation scheme?

If it is the former, which the last point implies, then why is it part of
the FR draft? - shouldn't it be part of a common document?
For IP PSN, IP fragmentation could be a candidate for this functionality.

If it is the latter, architecturally it is outside the PW and
attachment circuit specific so should take place in the "NSP" rather
than the PW.

Cheers.

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 18 Apr 2002 12:23:13 +0200

Andy and all,
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.

What is not clear to me is how important this additional overhead
really is. IMHO, its effect depends on the statistics of size of the
FR frames carried over a PW. In particular:
* if most FR frames are as long as you have mentioned (say, 4K),
  the additional overhead will be between 0.1 to 0.15% 
* if most FR frames are about 400 octets long, the additional
   overhead is 1 to 1.5% (if you are afraid of potential fragmentation
   issues) and 0.5 to 1% (if you are not - probably you can
   allow it with shuch short frames).

Personally I would say that even an overhead of 1 - 1.5% can
be justified if this simplifies the PW processing; and - this is
also quite a personal feeling - I do not see saving of 1.5% as a
compelling reason Danny has mentioned (e.g., this is more or less
the additional overhead of draft-brayley vs. draft-fisher, isn't it?)
But may be I am just missing something critical?
  
With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Thursday, April 18, 2002 1:05 AM
> To: [email-masked]
> Cc: Claude Kawa; [email-masked]'
> Stewart,
> This fragmentation is ONLY to get across the PW.  It is 
> completely separate 
> from end-to-end FRF.12 that may be contained in the frames.  Any 
> pre-existing FRF.12 fragmentation is just data to the PW, 
> just like any 
> other FR frame.  You don't need to do anything special at all.
> 
> The main issue to me is whether you need two bits or six octets when 
> fragmenting long FR frames to go across the PW, since FR frames are 
> commonly as long as 4K octets and sometimes up to 8K octets.  
> Don't know 
> many IP networks with an MTU that large.
> 
> Cheers,
> Andy
> 
> --------
> 
> At 4/17/2002 07:41 PM +0100, Stewart Bryant wrote:
> 
> >Are you planning to map FRF12 fragmentation onto PWE3
> >fragmentation, or are you planning to mandate that FRF
> >fragmented packets cannot be transported?
> >
> >If you are planning to carry them, then a mapping function
> >needs to be specified, as well as a methof of refragmenting
> >fragments.
> >
> >If we carry the full FR header we do not have to worry
> >about how to carry pre-fragmented packets. If we need to
> >fragment in the  PE, running FRF.12 in the NSP means that
> >we do not have to define the fragmentation operation in PWE3.
> >Isn't this simpler and more general?
> >
> >
> > > Claude Kawa wrote:
> > >
> > fragmentation indicators (bits
> > > I and L) in the FRoPW header as in draft kamapabhava 
> figure 3 shown below:
> > >
> > >  0                   1                   2                   3
> > > or in the payload packet field as in Figure 2 shown below and use 
> > FRF.12 (on frame relay
> > > fragmentation) to do the fragmentation by a PE:
> > >
> > > One question asked (by Danny) was if there is a 
> compelling reason NOT 
> > to use FRF.12. Here is my
> > > initial analysis:
> > >
> > > FRF.12 requires that we configure a device to determine 
> whether FRF.12 
> > is supported or not. FRF.12
> > > is either supported per port or not. If it is supported 
> the first few 
> > bytes of the payload have to
> > > be processed because they contain the fragmentation header.
> > > A context look-up has to be performed
> > > by a device (a PE in our case) to determine whether to 
> look into the 
> > payload or not. This clearly
> > > slows the processing.
> >
> >You have to do this anyway, because you are going to have to 
> check whether 
> >the
> >underlying frame has already been FRF.12 interface 
> fragmented, and then to 
> >map all
> >the bits.
> >
> > >
> > information about
> > > fragmentation is in the PW header. This results in faster 
> operation.
> >
> >This is only a one bit lookup. Bit 1 of the first octet says 
> whether the
> >frame is fragmented, and on encapsulation you have to do this anyway.
> >
> > >
> > > Secondly FRF.12 requires to use a sequence number field 
> to ensure that 
> > the receiver got all the
> > > fragments to re-assemble them properly. We already have a 
> sequence 
> > number field in the FRoPW
> > > header. This use of fragmentation based on FRF.12 results 
> in additional 
> > protocol design and
> > > implementation inefficiencies.
> >
> >On the contrart, its well defined in FRF.12 and out of scope 
> in PWE3. You 
> >have to make the
> >check or mandate unpredictable behaviour if the user sends 
> FRF12 traffic 
> >to you.
> >
> > >
> > applicable to other frame
> > > based technologies such as Ethernet over PW. It makes 
> more sense to put 
> > the fragmentation control
> > > information in the PW header.
> >
> >If we have to have a fragmenation scheme, agreed this is a 
> generic one. I 
> >am not
> >convinced that you need to have one within the PWE3 context.
> >
> > >
> > > Claude Kawa
> >
> >Stewart
> >
> >_______________________________________________
> >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: Thu, 18 Apr 2002 07:35:53 -0400

Sasha,

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

>    allow it with shuch short frames).

You have to look at the overhead on each fragment, not on the entire 
frame.  So if we're chopping long frames into 576-octet fragments (the MTU 
that all routers must support), then the overhead is 1.4%.  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.

>But may be I am just missing something critical?

No, just having been there and done that with FRF.12 I don't see much 
complexity at all in having it as part of the PW process, and 6 octets IS 6 
octets.

Thanks,
Andy

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 18 Apr 2002 15:11:42 +0200

Andy,
Thank you for a prompt response. Please see
some comments inline.

With best regards,
                                   Sasha Vainshtein

> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Thursday, April 18, 2002 1:36 PM
> To: Sasha Vainshtein
> Cc: 'Andrew G. Malis'; Claude Kawa; [email-masked]'; 
> [email-masked]; Danny McPherson (E-mail)
> Subject: RE: [PWE3] issue with frame fragmentation
> 
> 
> Sasha,
> 
> >Andy and all,
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?
> that all routers must support), then the overhead is 1.4%.  
>
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%.
>
> 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:-).
... snipped ...

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 18 Apr 2002 11:23:07 -0400

Sasha,

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

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

>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

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 18 Apr 2002 18:25:10 +0200

Andy,
Thanks for a prompt response. Just one short
question inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Thursday, April 18, 2002 5:23 PM
> To: Sasha Vainshtein
> Cc: 'Andrew G. Malis'; Sasha Vainshtein; Claude Kawa; 
> [email-masked]'; [email-masked]; Danny McPherson (E-mail)
> confined to an actual local access line.  
>
Can NNI fragmentation be used in conjunction with the port-to-port mode?
... snipped...