Subject: RE: issue with frame fragmentation

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

Sasha,

 > Can NNI fragmentation be used in conjunction with the port-to-port mode?

Good question.  Since it is "Frame Relay port mode" I would say no, since 
FRF.12 interface fragmentation isn't Frame Relay as defined by Q.922 Annex 
A.  It's not even real HDLC, since it deliberately doesn't follow the HDLC 
conventions for the lower bit extension in the HDLC address octet(s) (so 
that FR port misconfiguration could be detected), so you can't use 
draft-martini-ppp-hdlc-encap-mpls-00.txt either.  The spec could be written 
to deliberately allow its use, but that would make the PW more complicated, 
so it's probably best to terminate it at the PE ingress.  That's certainly 
more in keeping with the spirit of FRF.12, anyway - interface fragmentation 
was meant to make it possible to support real-time services across a 
relatively low-speed access line at the cost of added overhead.  When going 
across the WAN, you want to optimize WAN bandwidth by getting rid of the 
fragmentation headers - there's certainly no concerns about clocking times 
at that point.

Cheers,
Andy

---

From: George Wilkie <[email-masked]>
Date: Fri, 19 Apr 2002 08:39:03 +0100 (BST)

Andy,

Maybe I misunderstand the question, but if the NNI fragmentation is being
done between the PE NSPs across the PW then it can work with DLCI and port
modes.

What exactly does port mode mean anyway?
1. port is raw hdlc, frames are sucked off and all sent down the same PW.
If CE is doing frame, the DLCIs will be on the packets.

2. port is frame. DLCIs are identified and sent to individual PWs.
DLCI remains on the packet.

In either case, if NSP is doing NNI frag, it can stick the 2 byte frag header
on front of every packet prior to transmission on the PW.
Sequencing is per-PW, not necessarily per-DLCI since the 1st case has all
DLCIs going to the same PW.

Cheers.

On Thu, 18 Apr 2002, Andrew G. Malis wrote:

> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: George Wilkie <[email-masked]>
Date: Fri, 19 Apr 2002 08:34:09 +0100 (BST)

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

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

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 19 Apr 2002 10:44:12 +0100

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

Stewart