Protocols over Frame Relay

Dino Farinacci <> Sat, 17 November 1990 22:21 UTC

Received: from by NRI.NRI.Reston.VA.US id aa05944; 17 Nov 90 17:21 EST
Received: from buckeye.ESD.3Com.COM by bridge2.ESD.3Com.COM with SMTP id AA26209 (5.64+/IDA-1.3.4-901018 for frame-relay@NRI.Reston.VA.US); Sat, 17 Nov 90 14:18:25 -0800
Received: by buckeye.ESD.3Com.COM (4.0/SMI-3.0DEV3.900228) id AA03839 (for frame-relay@NRI.Reston.VA.US); Sat, 17 Nov 90 14:18:21 PST
Date: Sat, 17 Nov 90 14:18:21 PST
From: Dino Farinacci <>
Message-Id: <9011172218.AA03839@buckeye.ESD.3Com.COM>
Cc: frame-relay@NRI.Reston.VA.US
In-Reply-To: "k1io@FN42jk 16-Nov-1990 0944"'s message of Fri, 16 Nov 90 19:59:32 PST
Subject: Protocols over Frame Relay

>Mapping PPP over FR, on the other hand, is rather straightforward. 
>Beginning with the "control" field, after the DLCI, frame relay delivers 
>the PPP frame across a virtual point to point link.  It's quite simple.

    I believe the big win using PPP over FR networks is the ability
    to run multiple protocols over the same PVC. However, viewing the
    PVC subscribed as a "virtual point-to-point" link may have scaling
    problems. Specifically, I wouldn't want to run the LCP FSM n times.
    Furthermore, one may subscribe to n PVCs but not have frequent 
    traffic to all nodes. The PPP overhead (LQM packets) could consume
    the single-link bandwidth to the network.

    I believe a modification can be made to PPP to allow 16-bit addresses
    (as Drew states) as well as an option to disable LCP protocol processing.
    No great ideas come to mind how to do this dynamically. However, if
    a link is configured to be a Frame Relay link, only the PPP encapsulation
    part of the protocol would be used. Any comments?