Friends, Romans, countrymen....

Leonardo DaVinci wasn't the only forward-thinking guy of his era. It turns out that Marc Antony was making a plea for folks to have their frame relay PVCs use a common excess information rate bandwidth pool when he implored: "Friends, Romans, countrymen, lend me your EIRs!"

Ba-boom.

Last time, we discussed excess information rate (EIR), frame relay's newest three-letter acronym (TLA). We mentioned that so far, most of the services that we're aware of set the EIR plus the CIR to be equal to the port speed. But there's an important distinction between the sum of the CIR plus EIR and the port speed. A CIR/EIR is associated with each individual permanent virtual circuit (PVC), while a port speed is associated with the aggregated speeds of all PVCs connected to that port.

Theoretically, you could have a CIR+EIR that is different from your access speed. For instance, you could be connected to your service provider with a port speed of 1.536 Mbps (T1), with a committed information rate (CIR) for a given PVC of 256K bit/sec and an EIR for that PVC of 256K bit/sec. In this situation, traffic up to 256K bit/sec is assured the committed bandwidth, and traffic above 256K but less than 512K bit/sec would be transmitted on a discard-eligible basis. But transmission would not even be attempted for the traffic in a burst that exceeded 512K bit/sec.

For a port with a single PVC, the above situation makes no sense. Why pay for a T1 port (as opposed to a 512K bit/sec port) if you can only use 512K bit/sec? However, if you have many PVCs on a single port, you may decide that your traffic patterns may be sufficiently sporadic that you can live with - or even would desire - an explicit EIR less than the port speed.

For instance, you may have a T1-speed port at the host site serving 100 56K bit/sec remote ports, and each of the remote ports may have a CIR for the PVC to the host at 48K bit/sec. In this situation, bursting above 56K bit/sec on any particular PVC won't gain you anything, and, in fact, it could lead to buffer overflows. In this case, having an explicit EIR of 8K bit/sec could protect the network from having to transport information that will ultimately be discarded. Of course, the frame relay equipment that's generating the traffic at the T1 end of the circuit also must have sufficient traffic management to feed each PVC at a rate that doesn't exceed the EIR.

To discuss this and other WAN issues with Steven Taylor, Joanie Wexler, and your fellow frame relay newsletter subscribers, please visit the Webtorials.Com Public Forum at www.webtorials.com/forum.htm.

---

Steven Taylor, consultant and broadband packet evangelist, and Joanie Wexler, an independent networking technology editor and writer, team up to bring you this analysis and commentary. Taylor specializes in education and market analysis, and Wexler adds incisive reporting and research. For more detailed information on most of the topics discussed in this newsletter, connect to www.webtorials.com, the first Web site dedicated exclusively to market studies and technology tutorials in the Broadband Packet areas of Frame Relay, ATM, and IP. Feedback and additional topic ideas are welcome. Please contact taylor@webtorials.com or joanie_wexler@mindspring.com.

Managed WAN-a-phobia
Network World, 10/25/99

Voice over packet: But which packet?
Network World, 07/21/99

"Playing the averages" with oversubscription
Network World, 06/07/99

Bringing QoS and "any to any" connectivity to frame relay
Network World, 04/21/99

Archive of Network World on Frame Relay newsletters