The IEEE 802.17 Resilient Packet Ring Working Group held its first Plenary Meeting March 12-15, 2001 in Hilton Head, South Carolina. In a remarkably high turnout for a new standard, 166 people attended the meeting, and 123 participants were granted full voting rights. During the course of the 4-day meeting, 21 motions defining requirements for RPR were passed. An additional 45 were developed and submitted for future discussion, review, and approval. The high level of interest seen at this meeting, together with the rapid agreement on an initial set of objectives, offer encouragement that the Resilient Packet Ring standard will proceed along a rapid timeline to completion.
More than 60 companies participated in the meeting, 50 percent more than had participated in the study group that led to the formation of 802.17. Companies represented at the meeting ranged from semiconductor and optical component vendors to systems vendors and carriers. Each category appeared to be well represented.
In a significant development for an IEEE standard, the main users of the technology -- service providers -- were significant participants in the meeting. Since RPR technology is being developed for public data networks, service providers will be the primary beneficiaries of the standard. Aware of the benefits RPR will bring to their current operations, the carrier community delivered a number of presentations. Representatives from SBC, Global Crossing, Sprint, Excite@Home, Bell South, and WorldCom addressed the group with their requirements and objectives, providing insight into their need for RPR networks.
Common themes in the service providers' presentations included the need for a more cost-effective infrastructure and the optimization of RPR for Ethernet services. Service Level Agreements (SLAs) and security were top priorities for most of the service providers. Interoperability with SONET and Ethernet and the need for fast and comprehensive management and provisioning tools were discussed. These service providers plan on continuing their contributions and active participation in 802.17 as it develops the RPR standard.
The meeting's agenda was packed with technical contributions from over 30 companies. Topics presented included: MAC Requirements, Datapath Approaches, TDM Traffic Support, GFP Proposals, Multiple MAC Rings, Transit Path Requirements, Topology and Fault Discovery, Wrapping and Steering, Protection Switching, Congestion Control, Bandwidth Management, QoS Requirements, Arbitration Protocols, Dynamic Bandwidth Control, Simulations, Fairness Index, and MAC Interfaces.
Summary of IEEE 802.17 requirements agreed to at the March meeting
This summary of the Motions and Objectives is designed to give interested parties a brief overview of the RPR standard as it develops. As with any standards effort at this initial stage the detailed proposals and specific implementations that embody these objectives have yet to be approved. The objectives are grouped, summarized, and paraphrased below for clarity. The full list of Motions can be found at the IEEE web site at www.IEEE802.org/rprsg.
The following list summarizes the 21 requirements that achieved the 75 percent level of consensus. Over 40 additional requirements developed at the meeting will be refined and discussed via the working group over the next two months, and will then be voted on during the May interim meeting. The number of objectives proposed and the number of objectives approved represent a significant achievement for the Working Group. After the May meeting, 802.17 will have a list of objectives for evaluating proposals and developing the new RPR MAC.
(1) Dual counter rotating rings: The RPR standard will support a dual counter-rotating ring topology.
(2) Destination stripping of unicast traffic: The destination node will remove packets from the ring that are destined for it. Destination stripping will increase the effective capacity of the ring by freeing the downstream segments from carrying these packets, thereby making them available to carry additional data traffic.
(3) Support for multi-cast traffic: The RPR standard will support multicast traffic. Ring topologies are efficient for multicast traffic. Multicast packets traverse the ring once to reach every node and client on the network. This contrasts with mesh topologies that must replicate multicast traffic and transmit it on every port resulting in inefficient bandwidth utilization.
(4) Support for at least 1 Gb/s through 10 Gb/s data rates and above: While no upper bound for data rate was specified, speeds between 1Gbps and 10Gbps will be supported in the first release of the standard.
(5) Support SONET/SDH PHY (physical layers), as well as 1 and 10 Gb/s Ethernet PHY: The reuse of existing PHY layer devices obviates the need for 802.17 to define another PHY, speeding the standard's development. This support will also allow RPR products to make use of widely available components, thereby lowering component costs and assisting with interoperability.
(6) RPR vendor interoperability: A major objective of the standard will be vendor interoperability. SONET never achieved this interoperability leading to balkanization within service provider networks. This requirement insures that RPR equipment from different vendors will interoperate on the same ring.
(7) Protection switching shall be complete in less than 50 ms: Rapid restoration of service is an important characteristic of existing service provider networks. Today's LAN data switching equipment does not have the ability to complete a restoration event within this time window. Further the Spanning Tree protocol is insufficient for carrier requirements. With the development of RPR networks, carriers will have a packet switching platform that provides the resilience their customers demand.
(8) The RPR standard will support multiple service types: Packet networks serve many needs today and will support even more in the future. The RPR standard will be flexible enough to adapt to the packet requirements of today's and future applications.
(9) The RPR MAC will be both PHY and payload agnostic: The benefits of the RPR standard will be available to many types of networks and network services. Independence from the PHY layer ensures that vendors can build networks with either existing PHY layers and/or new PHY layers that may better meet their customer needs. Also the RPR standard will not interfere with or change the customer payload. This requirement is important for a number of reasons: (a) It has a bearing on security, and (b) it ensures that RPR transports packets independent of the content or type of customer traffic.
(10) RPR will support a fully distributed access method without a master node: This requirement ensures that each node on a ring is capable of functioning without the presence of any other particular node on the ring. Operational complexity is reduced when only one type of node is required for proper ring operation.
(11) The standard will define managed objects: Carrier networks have traditionally been provisioned and managed within the OAM&P regime. This functionality is mirrored in the data world by FCAPS. Managed objects provide the initial management data definitions. These will subsequently provide vendors with standards based building blocks for the management systems used in carrier-class public data network equipment.
About the RPR Alliance:
It is the mission of the Resilient Packet Ring Alliance to educate the community regarding progress on the RPR standard. The RPR Alliance supports the efforts of the IEEE 802.17 and is comprised of many of the primary contributors to the Working Group. The RPR Alliance had nine members at the beginning of the plenary meeting and, by the end, the group had grown to 13. A number of other companies have indicated their intention to join the Alliance in the near future.