[RPRWG] Why are current RPR proposals too complicated to be deplyed and maintained by service providers????
All
This is 1st of 2 mails on this topic The 2nd mail will be generated next week, after I review the various RPR proposals in depth
Please understand, that as an industry analyst/ consultant, I am not in any camp and have "no axe to grind." I do have 23 years of relevant datacom/ telecom stds experience, however.
Over the past 12 years, I have witnessed three previous attempts to define integrated services MANs that were either still born or DOA They were: FDDI-II (with added isochronous mode), IEEE 802.6 DQDB, ATM Virtual Path Rings. In IEEE 802.17, we are trying to solve the same set of problems that 802.6 (Jim Mollenauer's group) was trying to solve in 1989-1990!
-->Have we learned anything from the commercial MAN failures that have preceded RPR? Can service providers/ network operatiors deploy and maintain RPR without fork lift upgrades and dispatches due to unsoved trouble tickets? Based on two meetings I attended, I am quite skeptical
Here is my prioritized list of functions that I view as too complicated. A follow on mail will elaborate on these.
1. Bridging- too many proposals, with some being too complicated and none tested against failure scenarios
In a public network, it is crucial to separate customer traffic and keep it private/secure. Additionally, flooding/ broadcast storms (when encountering packets with unknown addreses) can not be tolerated and hence must be minimized.
Suggest a single, strightfoward proposal for 1st RPR spec, which does transparent bridging on a sinle ring (use routing for inter ring communciations). has been tested or simulated under various failure scenarios, and minimizes flooding, while separating customer traffic
2. Congestion management. In my opinion, sending a lot of messages around the ring to avoid congestion is not a good idea. It is complicated to administer/ maintain, and takes up bandwdth that could be used for other traffic.
Precursor: A lot of work went into ABR closed loop congestion control, but it was never deployed in any public ATM network that I am aware of!
3. Protection/ restoration.
a] Too much disagreement of when to use Wrapping and when to use Steering. Must precisely specify the preferred RPR protection method and the optional method. Do not require every RPR node to implement both. Also need to cover reversion/ non-reversion conditions. What if one of the protection mechanisms fails- is the other than invoked?
b] When operating over SONET/SDH, an operator may decide to use L1 protection with hold off timers before invoiking RPR protection. It is crucial to accurately determine the value of the hold off timers to prevent escalation. Alternatively, L1 protection could be disabled on an RPR path. What are the condidtions where operator would use multi-layer protection vs only RPR protection? For example, consider the case of 1+1 path or 1:1 line protection in conjunction with RPR (L2) protection
-->Guidleines for Multi-level protection should be specified in an Appendix/ ANnex of the RPR standard, in my opinion
c] Note that "Re-routing based Restoration" may also be used (GMPLS or other scheme) on top of RPR, so that all the L2 protection work done will be muted. Restoration is being specified by IETF and ITU SG 15. It may also be part of OIF NNI project
4. Topology Discovery protocol
Note that failure to agree on this function is one reason BLSRs are single vendor rings. SIF tried to specify a Topology Discovery protocol, for a multi-vendor BLSR, but I don't think it was ever impemented by any NE vendor.
a] Need Topology Discovery at initialization time and whenever there is a topology change. Can a simple update be used instead of operating the whole topology discovery process?
Suggest looking at OSPF and PNNI link state/ resource staus updates (commercially successful)
b] Topology discovery and subsequent updates must be robust to failure scenarios and could even trigger re-routing restoration on reporting of a failed resource (not subject to RPR/L2 standard)
c] How do off ring nodes learn of the topology change within a given ring- NM or routing data base updates?
5. Access Control Algorithms/ Mechanisms
This is perhaps the most tricky aspect of the RPR standard, due to being PHY aganostic. If operating over 1/10GigE or a SONET/SDH concatenated payload, then Real time traffic/TDM becomes important. If operating only over channelized SONET/SDH payloads, then real time/TDM traffic can be mapped to other time slots/paths.
THE ADMIRAL GOAL OF HIGH BANDWIDTH UTILIZATION/ BANDWIDTH MULTIPLICATION/ STATISTICAL GAIN combined with QOS/SLAs for BOUNDED DELAY, JITTER, THRUPUT, PACKET LOSS RATE, etc can only be realized after the mechanisms have undergone extensive simulations and some amount of field testing. Congestion during peak periods also needs to be considered in the simulations. Only after evaluating simulation results can voting members make a choice amongst competing proposals, i.e. gut feel just won't due here!
--> Does IEEE 802.17 have the necessary reources and the time needed to construct simulation models, run the simulations, and present the results as contributions?
Note: the far less complicated proposals for ATM congestion control mechanisms were subject of numerous models and simulations within the ATM Forum. That work took over 1 1/2 years!
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Need to sign off now. Back to you next week some time
alan
Alan J Weissberger
DCT
PO Box 3441
Santa Clara, CA 95055-3441
1 408 330 0564 voice
1 408 565 0335 fax