& cplSiteName &

IEEE and ITU Get Chummy on RPR

Light Reading
News Analysis
Light Reading
12/13/2001

The Institute of Electrical and Electronics Engineers Inc. (IEEE) resilient packet ring (RPR) working group could be getting a shot in the arm from its global buddies at the International Telecommunication Union (ITU). The two groups are now officially working together to standardize a solution for data-optimized rings.

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

(9)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
bell-head
bell-head
12/4/2012 | 7:26:42 PM
re: IEEE and ITU Get Chummy on RPR
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:

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...
Confucius
Confucius
12/4/2012 | 7:26:37 PM
re: IEEE and ITU Get Chummy on RPR
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?

I don't get it either. What's the need to add a different method of mapping packets into the SONET payload? I'm not seeing the value add here. Byte synchronous HDLC encapsulation (aka POS) seems to work fine and is dead easy. Why add another interface to have to support? KISS.
jshuler
jshuler
12/4/2012 | 7:26:36 PM
re: IEEE and ITU Get Chummy on RPR
GFP is a layer between RPR and the "existing SONET Phy" that allows variable-length RPR packets to be mapped efficiently over the SONET physical layer so, for example, you can use a concatenated OC48/STM16 pipe to carry TDM CES, native Ethernet and transparent LAN services.

Individual flows can be protected in both directions on the ring -- no rigidly reserved bandwidth channels and protection. This simplifies management tremendously (configure the service ONLY, not the pipe and THEN the service) and makes bandwidth utilization much more efficient.

Even TDM circuits are more efficient in RPR under most conditions because they take only exactly their Bw, whereas an entire STS-1 (at least, if not more) must be allocated to the first T1 in a traditional SONET ADM, and it is only when that STS1 is completely full that the Bw is efficient. Then, the next T1 requires yet another entire STS, etc.

Does this help?
bell-head
bell-head
12/4/2012 | 7:26:35 PM
re: IEEE and ITU Get Chummy on RPR
well I understand the ability to more efficiently encapsulate variable length framed protocols (like ethernet and GbE) into a synchronous SONET frame, and how virtual concatenation can do this even down to the VT1.5 level. however, not sure I understand the need to duplicate all of the transport and protection features in RPR that already exist in SONET overhead. and there seems to be a great deal of debate about exactly what those would be anyway.

I seem to hear about this duality of function for RPR that it is both a MAC layer protocol (PHY-agnostic) and a physical layer transport mechanism with protection features, etc that can operate over dark fiber. kind of like the wave-particle dual nature of light. not to digress into quantum theory, but I don't understand how you can have a carrier class, resilient packet ring transport protocol yet maintain simple, low cost optical ethernet devices. it doesn't add up for me.

and will all do respect, I have to say that I think transporting TDM services via TDM CES over RPR over SONET sounds totally ridiculous.

wouldn't virtual concatenation be a much better way to mux TDM services? maybe I'm off the mark...
Litewave
Litewave
12/4/2012 | 7:26:30 PM
re: IEEE and ITU Get Chummy on RPR
and will all do respect, I have to say that I think transporting TDM services via TDM CES over RPR over SONET sounds totally ridiculous.

It is totally ridiculous.

I think the RPR players are getting a little ahead of themselves. They need to keep it simple, but open. And let the market evolve it to the right function.
FiberFan
FiberFan
12/4/2012 | 7:26:29 PM
re: IEEE and ITU Get Chummy on RPR
"I think the RPR players are getting a little ahead of themselves. They need to keep it simple, but open. And let the market evolve it to the right function."

Litewave,
I would agree with you IF the matter was just a wholesale swap out of SONET for RPR based gear. I believe it's going to be an evolutionary process. Probably the only place where CES would be used as the primary TDM type service (over RPR) is in greenfields. The point is that DATA is THE major growing, in demand service. Very few customers ordering OC-3/12 are using it for TDM (voice) applications. It seems that in the future there will be T-1 (for the diehard PBX folks), perhaps a few DS-3s (for the aggregation/muxing crowd) and the rest will be various classes of ethernet-like services. I can see two or three types.
1. Low latency (VOIP, Video)
2. Regular (ethernet private line, TLS/VPN & high end internet access)
3. Oversubscribed internet access (think of it as "frame relay" ethernet for the masses) You could pay for your required CIR and get what you pay for.

The bottom line is SONET is exteremely inefficient with regard to handling data.
I agree with your one point:
"And let the market evolve it to the right function."
I believe the SONET will be the transport of choice for TDM circuits in the near term and RPR's main role will be handling the data piece. The evolution will come when TDM demands further diminish and RPR could fill the void.

Your thoughts?
FiberFan
gea
gea
12/4/2012 | 7:26:22 PM
re: IEEE and ITU Get Chummy on RPR
The generic framing procedure is able to operate over a SONET physical layer or over the G.709 digital wrapper (or other physical layers, theoretically).
Now I have looked a little bit into GFP vs POS, and I admit I don't fully understand the advantages of GFP, though smart people like James Manchester have touted its usefulness.

One thing I do know about POS is that it uses "PPP-encapsulated HDLC frames". But there is actually not much use to the PPP part, except for the possiblity of running the Link Control Protocol (LCP) over it for things like loop detection (via magic numbers). Supposedly, GFP bundles all of what you need from POS into a nicer package, as well as giving it some ATM-like features (like headers that say how long the message is, I think).

As for J Shuler's comments (from Luminous, I suspect), he's got some things a little wrong: a DS3 maps into an STS-1. If you have VT1.5-mapped STS-1s and only need to move a few STS-1s, you'll probably waste bandwidth with traditional SONET. But virtual concatenation can recalim that bandwidth.

RPR's real power is going to be bringing a true shared medium into the Metro & transport domains. This could all be done with POS, (combined with IntServe and DiffServe) over big fat concatenated pipes, but that is a layer 3 approach. Metro cariers seem to want the simplicity of a layer 2 approach, and with built-in plug-and-play...no need to load all sort of crazy extra protocols.
signmeup
signmeup
12/4/2012 | 7:26:21 PM
re: IEEE and ITU Get Chummy on RPR
Just one observation: As we all know, most RBOCs have 2 sides of the business; regulated and unregulated. Usually this is defined by the transport side and the services side. Most people on the transport side like GFP because it allows them to manipulate traffic WITHOUT having to look at L3 which is VERBOTEN due to regulation.
Most carriers I have talked with feel that GFP is a cleaner solution - seeing as they are trying to keep a simplistic L2 approach.
turismo
turismo
12/4/2012 | 7:26:12 PM
re: IEEE and ITU Get Chummy on RPR
Yes, GFP is defined not only for SONET but for G.709 Digital Wrapper as well. The question is "when will the router folks be ready to map data onto OTN" ? Perhaps RPR applications will be one of the first to adopt this ?!?

Secondly, I believe the idea of GFP is the "generic" or unified mechanism in multi-service environment for transport. Invision Ethernet, POS, and transparent FICON, ESCON, FC, all sharing the same pipe in the transport network with some form of class of service. Something that some RPR camps are trying to solve. POS is only one service it needs to facilitate.

My 2 cents ...
Featured Video
Upcoming Live Events
November 5, 2019, London, England
November 7, 2019, London, UK
November 14, 2019, Maritim Hotel, Berlin
December 3-5, 2019, Vienna, Austria
December 3, 2019, New York, New York
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events