From: Jelle Borsje (borsjej@yahoo.dk)
Date: Wed Apr 13 2005 - 05:29:14 GMT-3
Hi,
In the FRF.16 standard, the "other end" is the service
providers equipment (DCE equipment), or carrier.
Basically, the physical connections are bundled on
data-link layer and you (and the frame-relay protocol)
will see the connection to the service provider as a
single pipe, over which LMI could be running. As long
as at least 1 physical connection is up, the
connection to the service provider will be active and
you will be receiving ALL DLCIs from the provider. It
is just the capacity that will go down, when a link
goes down.
I only know how it is configured on a Cisco router,
and have succesfully experimented with it. Since the
FRF.16 standard assumes that the bundled links are
seen as a single pipe, it should not be a question of
a provider advertising certain DLCIs over one physical
link, while others come over a second physical link.
All DLCIs come over a sinle 'pipe' that can exist of
multiple physical connections. The important thing
with FRF.16 is, that your frame-provider needs to
support and implement it on his switches. This is
different from the FRF.15 standard, which provides MFR
between DTE devices when a frame-relay provider won't
or can't provide FRF.16. In that case the
fragmentation and reassembling is done on the end
devices, while the frame-relay provider doesn't know
we have implemented MFR. I have done a quick search on
Cisco's website, and they don't appear to support this
type of MFR.
Hope this helps.
Greetz
Jelle
--- Sean C <Upp_and_Upp@hotmail.com> wrote:
> Hi Jelle,
>
> I appreciate the time you took at commenting on my
> post. I've understood
> the bundle and virtual interface on the CPE. But
> who are you considering is
> the 'other side' in your last comment "...and
> reconstructed in the correct
> order on the other side."? Is the 'other side' the
> carrier? From what you
> are suggesting in your last paragraph, the carrier
> does not advertise the
> DLCIs on their physical circuits but only on their
> virtual interface? IOW -
> the carrier not only has to configure the physical
> circuit but the carrier
> also has to a virtual-interface on their equipment.
> To take this further,
> since the carrier is utilizing a virtual-interface,
> the carrier would not
> need to advertise all DLCIs on each circuit as I
> originally asked.
>
> If my understanding is correct, pretty interesting.
> I appreciate the
> answers,
> Sean
> ----- Original Message -----
> From: "Jelle Borsje" <borsjej@yahoo.dk>
> To: <ccielab@groupstudy.com>
> Sent: Tuesday, April 12, 2005 9:55 AM
> Subject: Re: OT: Realworld use of Multilink Frame
> Relay
>
>
> > Hi,
> >
> > When configuring this, a virtual interface is
> created
> > on the router, called a bundle. The physical
> > interfaces that make up for the bundle, are called
> > bundle-links. The latter are invisible to the
> > frame-relay data-link layer, and the frame-relay
> > functionality is therefore not configured on the
> > bundle-links (or physical interface) but on the
> bundle
> > (the virtual interface).
> >
> > It appears that over the bundle-links, Link
> Integrity
> > Protocol Control Messages are exchanged. LMI (and
> with
> > that the advertisement of DLCIs) is configured on
> the
> > virtual interface. LMI is up, and the connection
> > active, as long as a single bundle-link is up and
> > running.
> >
> > Since LMI is not running on the bundle-links
> (physical
> > interfaces), the DLCIs are not advertised on the
> > physical links... but only on the virtual
> interface.
> > As far as your routing and connectivity is
> concerned,
> > you only have to worry about the virtual
> interface.
> > The FRF.16 standard will make sure that the
> packets
> > are divided over the multiple bundle-links
> (physical
> > interfaces) and reconstructed in the correct order
> on
> > the other side.
> >
> > Hope this helps.
> > Greetz
> > Jelle
> >
> >
> > --- Sean C <Upp_and_Upp@hotmail.com> wrote:
> >> Hello,
> >>
> >> When implementing Multilink Frame Relay (FRF.16)
> -
> >> I'm trying to understand
> >> how the carrier advertises PVCs. My question is
> >> this: does the carrier
> >> advertise all PVCs on each T1?
> >>
> >> IOW - if an original implementation of FR had 2
> T1s
> >> with the 1st T1 utilizing
> >> PVCs # 1, 2 & 3 and the 2nd T1 utilizing PVCs #
> 4, 5
> >> & 6. If wishing to
> >> utilize Multilink FR, does the carrier now need
> to
> >> advertise all PVCs on both
> >> T1s? IOW - will the 1st T1 now carry PVCs # 1,
> 2,
> >> 3, 4, 5 & 6 and the 2nd T1
> >> will carry the same PVCs #1, 2, 3, 4, 5, & 6?
> It's
> >> the only way I can see
> >> this happening because I can't figure out if the
> 2nd
> >> T1 fails, how the 1st T1
> >> will be able to support PVCs 4, 5 & 6.
> >>
> >> I appreciate any answer supplied. I hope my
> >> question is stated simply enough.
> >> I had searched on CCO:
> >>
> >
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t
> >> /122t8/ft_mfr.htm
> >> and Googled some but have not found the
> appropriate
> >> answer.
> >>
> >> Thanks in advance,
> >> Sean
> >>
> >>
> >
>
This archive was generated by hypermail 2.1.4 : Tue May 03 2005 - 07:54:57 GMT-3