Protocols over Frame Relay

Dino Farinacci <> Mon, 19 November 1990 17:43 UTC

Received: from bridge2.ESD.3Com.COM by NRI.NRI.Reston.VA.US id aa27636; 19 Nov 90 12:43 EST
Received: from buckeye.ESD.3Com.COM by bridge2.ESD.3Com.COM with SMTP id AA28241 (5.64+/IDA-1.3.4-901018 for; Mon, 19 Nov 90 09:42:12 -0800
Received: by buckeye.ESD.3Com.COM (4.0/SMI-3.0DEV3.900228) id AA04267 (for; Mon, 19 Nov 90 09:42:04 PST
Date: Mon, 19 Nov 90 09:42:04 PST
From: Dino Farinacci <>
Message-Id: <9011191742.AA04267@buckeye.ESD.3Com.COM>
Cc:, frame-relay@NRI.Reston.VA.US,
In-Reply-To: tmallory@BBN.COM's message of Mon, 19 Nov 90 12:13:32 -0500 <9011191716.AA27539@bridge2.ESD.3Com.COM>
Subject: Protocols over Frame Relay

>You ought to be able to negotiate a low rate of LQM traffic per link, if that
>is your only problem.  Or skip it, since LQM is negotiable.  You can just
>trust that the FR DCE will supply you with correct up/down indications for
>each PVC.  Note that routers typically have a higher layer protocol that
>ensures connectivity for routing purposes in any case.

    I don't want to assign an IP subnet per "virtual point-to-point" link.
    And the unnumbered point-to-point concept does not work for routing
    protocols that don't support it. I believe from a router standpoint,
    viewing the network as an multi-access network is the most flexible
    and pure PPP does not fit that model.

>I'll give in a little for limited multicast, where a well-known logical
>address is used to locate service that may be provided by several servers and
>also for duplication as a special service(for conferencing, for example), but
>the general case is clearly best suited to LAN's where everyone listens to the
>same bits.

    I agree that limited multicast capability is the best, but I believe
    that the Frame Relay offerings I'm aware of will not support this.
    Furthermore, if the FR network does not perform mulitcasting 
    efficiently, DTEs will have to use alternative methods.