ViewsLetter(SM) on Provisioning

Site Map



ViewsLetter on Provisioning          28 Sept 2004            #41
Provisioning automation--from chips to the business layer.


    By William Flanagan, Editor & Publisher

Ethernet, the hands-down winner for Local Area Networks, appeals for Metro and Wide Area connections as well.  Available bandwidth is high enough to overcome the inefficiency of using so many headers--Media Access Control as well as IP, TCP, and probably others--to carry even one byte of payload.  Simplicity and compatibility trump efficiency.

But wait!  What if you could have it all?  Not satisfied?  Want more for your money?  What if I could add the speedy recovery of a SONET ring when a cable is cut?  Tell 'ya what I'm gonna do!

No, not finish a hokey carnival pitch.  We will look at Resilient Packet Rings as a technology for the local loop.  No rocket science, so we'll stick with text.  For pictures, refer to and the sites of members listed there.


If you're reading this, you should know at least the basics of Synchronous Optical NETwork (SONET), a workhorse of local access and metro area networks (MANs).  The key concepts are:
--ring topology:  traffic between any two points on the ring may travel in either direction around the ring.
--add/drop multiplexing in the nodes:  any point on the ring can be the end of a connection, and bandwidth on the ring is assigned independently in each direction.
--self-healing:  when nodes on the ring detect a break (cable or node), they send traffic in the opposite direction to avoid the fault.

When T-1 multiplexers were new (the 1980's) the terms used were "drop and insert" and "alternate routing" but the effect was similar--Time Division Multiplexed (TDM) channels restored automatically.  Now we have a way to the job with almost-Ethernet packets:  RPR.

Again the terminology changes, but the functions are similar.  RPRs have dual fibers, one for each direction.  Nodes, up to 255 per ring, sit on both fibers and act as 2-port, bidirectional, store-and-forward switches (or routers).

By design, the RPR nodes receive and re-inject each packet passing through.  This gives each node the power to buffer a lower-priority packet as it arrives from another node, so a local packet of higher priority can be sent first. This ability prevents upstream nodes from hogging the bandwidth, but there is also a "fairness algorithm" by which the nodes allocate ring throughput to various users--every node understands the entire ring. 

"Fairness" and bandwidth allocation depend on a new Media Access Control (MAC) layer (yet another header).  RPR isn't pure Ethernet on the ring, but it is fully compatible and has been blessed by the IEEE (in June 2004) as 802.17.  All connections off the rings are standard Ehernet (unless a vendor has added TDM circuit emulation or some other feature in a node).

RPR frames travel from source node to destination node, not around the entire ring (as in Token Ring).  As a node removes packets addressed to it, downstream bandwidth is freed for other users--RPR calls it "spatial reuse" (drop & insert). 

Another function of the RPR MAC is to locate any break in the ring so the nodes can redirect packets in the opposite direction if necessary to avoid the break.  More than "sort of" like SONET, RPR corrects for the fault in under 50 ms, the same specification as for SONET.


Bandwidth allocation on each fiber in an RPR is as flexible as routing (or statistical multiplexing).  The configuration can allocate guaranteed capacity to some user connections, allow some of them to burst to higher average throughput, limit some via traffic shaping, and offer best-effort service to the rest.  Since each direction is independent, high priority connections on one fiber can have reserved back up paths on the other fiber.

Who gets what depends on standard routing functions:  source and destination addresses, physical ports, DiffServ code points, application IDs, etc.  Every choice is expressed in a software configuration, not a cable placement or fixed TDM allocation.  You could, for example, envision an RPR node on a dual-fiber ring that connects to all local devices (adds/drops) through a single GigEnet interface. 

A Local Exchange Carrier (LEC) could find it handy to aggregate all traffic at a site onto one access link to the central office or point of presence (POP).  What's downstream of that point could be anything:  DSL access mux (DSLAM), cable modem headend, another router, an Ethernet switch, etc.

Specific services (Internet access, remote storage, email links, etc.) could be provisioned in equipment removed from the RPR node or part of that node.  RPR offers three levels of priority, so most traffic engineering schemes map easily to the RPR format.  If existing devices shape traffic, convert Plain Old Telephone Service (POTS) to voice over IP (VoIP), etc., physically the RPR node could be very small.

Looking ahead to increasing demands for high availability and huge throughput, imagine a pair of RPR nodes on the customer premises.  Ideally, the "east" and "west" paths for the fibers would be routed diversely to other RPR nodes or POPs.

With another function of the RPR MAC header, multicasting, those two nodes would share one RPR MAC address (and by extension, would be reachable at the same IP address).  Then no matter what single failure occurred on the ring (loss of the local node excepted), the customer would never lose connectivity upstream. 

When the need for bandwidth increases, the same fiber ring will carry huge amounts by adding wavelengths.  Some RPR vendors have methods to add wavelength division multiplexing (WDM, not to be confused with WMD) very economically by letting some wavelengths "skip" nodes (the wavelength is passed through).  When traffic on that wavelength needs to be dropped or added at another node, install a WDM module there.

RPR supports convergence on IP services with Ethernet compatibility, quick recovery from faults, and traffic engineering features for prioritization and bandwidth allocation.  The top priority is good enough to offer low-jitter TDM circuit emulation. 

Want all the details?  IEEE waits six months to post new 802 standards for free download, so 802.17 should be available that way around December 2004.  Meantime, you can buy a copy from IEEE.  For not-quite-as-detailed information, refer to the many articles and white papers offered by vendors.

Write if you have a favorite access technology you'd like to see covered in ViewsLetter:

============ + ===== + ===== + ===== + ============
      For a close look at more than two dozen PON companies, you are invited to purchase the report, "PON Industry Players--2004" available from Flanagan Consulting.  Offered on paper and a PDF file via email, this 25-page document describes each company's products, shows which market segments they participate in, and provides current contact information.  Either form is priced at US$60.00, payable by check to Flanagan Consulting, 45472 Holiday Dr. #3, Sterling, VA 20166.
============ + ===== + ===== + ===== + ============

-- Call us for a vendor-neutral network architecture and strategy for expansion or convergence.  We know voice AND data--and how to avoid expensive bear traps on the migration path, such as security arrangements. 
--Working on product positioning or a marketing message for telecom?   Yes, we've done that--for hardware products and carrier services.
-- Need an Expert Witness?  Associates at Flanagan Consulting have aided in many legal proceedings involving telecom intellectual property and technology. 
--For RFP preparation, bid analysis, proposal evaluation--call us.  We have current experience in Federal network procurement processes.

"We Have the Experience."

-- Special thanks for supporting ViewsLetter to, your best source for communications tutorials and white papers.
============ + ===== + ===== + ===== + ============ 

"Flanagan Consulting" and "ViewsLetter" are Service Marks of W. A. Flanagan, Inc.

Flanagan ConsultingSM
W. A. Flanagan, Inc.
45472 Holiday Drive, Suite 3, Dulles, VA 20166
Ph:  +1.703.242.8381
Fx:  +1.703.242.8391

Editor(at )