RE: [RPRWG] Why are current RPR proposals too complicated to be deplyed and maintained by service providers????
Alan,
I'm sorry that you were confused by the bridging presentation on Thursday.
The intent of the presentation was to give the 802.1 group
an overview of the various bridging methods that could be
deployed using 802.17. We were looking for feedback from
802.1WG as to whether any of the methods posed a compatibility
issue with 802 / 802.1 architecture, and to answer scope questions
in areas of overlap. Please keep in mind that the proposal
which is considered to be the simplest in meeting
transparent bridging compliance does not minimize flooding,
which you also indicate is an important requirement.
All of the proposals specify flooding of unknown/broadcast
traffic on the 802.17 ring, which is fundamental to maintaining
transparent bridging operation. However; the simple bridging proposal
which was presented as part of bridging compliance floods
not only the unknown/broadcast, but the unicast traffic as
well. If spatial reuse of the 802.17 ring is lost by virtue
of flooding traffic on every segment of the ring, there is
a serious deficiency with the standard. No one is going
to deploy 802.17 in a network environment where every
frame is flooded on the ring. If that is the case with
bridging, then why bother demonstrating compatibility
for something nobody is going to deploy. Also, if every
frame is flooded on the ring, steering/wrapping don't
really matter because frames are transmitted to every station.
We also don't need to standardize the sophisticated access control methods
which are being proposed or solve any head-line blocking problems.
Without spatial reuse, the ring is blocking.
The 802.17 standard must define transmission/reception
procedures when operating with a transparent bridging
MAC client such that compatibility with transparent
bridging is preserved, and retaining all the spatial
reuse properties of the ring.
The only standard way today of employing customer separation for
transparent bridging is through 802.1Q VLANs. The scope of
customer IDs is beyond the scope of 802.17 because it is used to govern
the behaviour of how packets are switched across multiple interfaces.
802.17 is a MAC not a switching protocol. As such, it may have
to support a customer_ID parameter as part of its client interface
in the future, but it wouldn't define it.
If there is enough impetus to standardize customer separation IDs
then a new PAR should be raised.
My understanding is that ABR is deployed in carrier networks. There
are some ATM switches which map other ATM traffic classes to ABR at
the edge to maintain tighter controls over traffic in the core of
the network. The ABR flow control reduces buffering requirements
in the core and moves the buffering out to the edge where traffic
is dynamically shaped based on the ABR flow control. In that case
ABR is not used as an end user service, but as a control technology
for the other more popular traffic classes. Just because it's
not visible as a service, doesn't mean that it's not hard at work
for you.
Finally, 802.17 is defining a ring access protocol, not an end-end
protocol. Many of the examples, you cited with ATM had to do with
ATM having to work across very large-scale networks and
topologies. The scope is much more restricted for RPR and there
are several examples in operation today. If we don't do
RPR, what do you recommend as the technology for building a ring?
thanks,
bob
Robert Castellano
Jedai Broadband Networks
rc@xxxxxxxxx <mailto:rc@xxxxxxxxx>
(732) 758-9900 x236
-----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Alan
Weissberger
Sent: Saturday, November 17, 2001 3:29 PM
To: 'stds-802-17@xxxxxxxx'
Subject: [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