IEEE and ITU Get Chummy on RPR
Last month, the ITU, an international organization within the United Nations system, officially announced that its standardization body had reached agreement on a series of new global standards for next-generation optical equipment and management equipment and software. One of these standards, called Generic Framing Procedure (GFP) -- or G.7041/Y.1303 -- will likely specify the final version of RPR for use in ring topologies.
Essentially, GFP is a new data encapsulation scheme for Layer 1 transport. It is an alternative to packet over Sonet (POS), which requires packets to be translated into different protocols before they are transported. The process is much simpler using GFP, according to Steve Gorshe, principal engineer at PMC-Sierra Inc. (Nasdaq: PMCS) and technical editor for the ITU GFP standard. Packets need not be translated at all, he says, but can simply be encapsulated into the GFP frame and transported across the network in their native formats:
“The outcome is a simplification in processing. It allows a native client signal to stay in its original format through the network, making the whole thing simpler and ultimately less expensive for end users.”
GFP in its current form supports linear point-to-point configurations, but there are plans for it to also include support for rings. This is where RPR comes into play.
“We wanted to get international consensus on this part,” says Gorshe. "We are expecting to address the ring aspects when the RPR group is further along."
In October, the ITU study group met and officially decided that it would wait to develop specifications for ringed networks until it could evaluate a finished proposal from the IEEE's RPR working group. The two organizations set up a formal liaison to keep each informed of the other's standards activities. Gorshe says this is not unusual for the ITU, which has worked with other standards bodies in the past to ensure that work is not duplicated.
Although the IEEE RPR draft (802.17) hasn’t been completed, the GFP standard has left a place in its payload indicator for RPR. Officially, RPR hasn’t been referred to in the document, since ITU rules preclude the mention of efforts that haven’t been standardized yet. But such works in progress may be included on what's called a "living list" -- comprising pre-standardized efforts that can be added to an ITU standard after it has been finalized. This is where RPR has been referenced in the GFP efforts, says Gorshe.
For its part, the RPR group is also planning to include GFP in its standards documents. Both of the two main proposals in the RPR working group have included GFP.
“It is complementary technology,” says Mike Takefman, chairman of the RPR working group. “802.17 will use GFP as one of our Sonet/PHY layers. The other will be Byte Synchronous HDLC.”
While the two groups seem to be working in cooperative bliss, there's always a chance they could hit a snag.
“It is unlikely, but not unconceivable, that the RPR group could go off in a direction the ITU doesn’t find appropriate,” says Gorshe. “In that case, we could define our own ring specifications. Right now, no one wants to say concretely that we will support 802.17 because it isn’t finished yet.”
— Marguerite Reardon, Senior Editor, Light Reading
http://www.lightreading.com
GÇ£The outcome is a simplification in processing. It allows a native client signal to stay in its original format through the network, making the whole thing simpler and ultimately less expensive for end users.GÇ¥
my understanding is that GFP specifies mapping for packets (and any other client protocol) into a SONET frame. I don't know about you, but to me this is basically optimized packet (or any other client protocol) over SONET. not sure how this simplifies processing. it does make for more efficient mapping of variable-length-framed protocols into SONET though.
GÇ£It is complementary technology,GÇ¥ says Mike Takefman, chairman of the RPR working group. GÇ£802.17 will use GFP as one of our Sonet/PHY layers. The other will be Byte Synchronous HDLC.GÇ¥
hmm, so the RPR WG wants to duplicate the PHY interfaces? why? why not just use existing SONET PHY if it works? what would be the advantage of this? what exactly are the problems you are trying to solve?
is this to save face or maybe I'm missing something. I'm probably missing something. to me it doesn't seem like you (RPR) can live in both worlds; transport and data link layers. I'm sure someone out there can clarify...