Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Next Steps toward an RPR Draft Standard



As I read over William Dai's remarks, and then went to our web site to check on our existing documentation, it seems that another area we need to work on is a firm requirements statement, or list of objectives/requirements.  Nader did a great job listing requirements in a presentation.  However, we will need an itemized list that everyone votes on.  I believe Nader's presentation is a good place to start, but cannot be considered a stake in the ground until there has been a study group vote. I believe that this is one subject that is best addressed in a live meeting, rather than deciding by e-mail.  However, e-mail input in preparation for that meeting would be helpful.
 
 
To reitirate Nader's requirements presented in July, here they are.  Comments now will help us get closer to a list we can agree to in November.
 
Nader's presented list of requiremetnts:
 
Ring aware MAC
Define RPR MAC sublayer to address packet distribution and collection in a ring network
- Define RPR MAC sublayer interfaces to MAC and MAC Client as well as management entity
- Fast Transit Path
Fast response to link failures without the need for layer 3
re-route
Support Full Duplex 1000Base-x and 10GBase-x media
- Support Ethernet packets
Support SONET media
 
Predictable Performance
Fair and dynamic distribution of available bandwidth
- Unused bandwidth reclaimed and distributed fairly (proportionally) to active conversations
Traffic Management
- Predictable bandwidth and delay characteristics per conversation
Distributed Congestion Management
- Each node represents a congestion point
- Manage over-subscription
Efficient Multicast and Broadcast support
Plug and play
- Topology discovery
- Automatic configuration
- Fast response to node (end station) insertion and removal
 
Best regards,
 
Robert D. Love
President, LAN Connect Consultants
7105 Leveret Circle
Raleigh, NC 27615
Phone: 919 848-6773
Fax: 720 222-0900
email: rdlove@xxxxxxxx
----- Original Message -----
Sent: Wednesday, September 06, 2000 3:21 PM
Subject: Re: Next Steps toward an RPR Draft Standard

I think we should limit the scope of the statement #2 to emphasize
that RPR is defined for "packet" transport only, as the name indicates.
In that sense, GBE, XGBE, SONET(Concatenated) is of the same
packet nature, but not the SONET(TDM), unless we define a TDM
channel as the physical layer.
 
In terms of Voice and Video service support, I assume you mean the
RealTime version of it. Latency and jitter control is critical. In the variable
sized packet transport environment, using unused code group as "escape"
to insert RT message in the middle of a data packet is a nice way to control
the latency and jitter for the RT transport. I remember Raj had a presentation
on this during August meeting. The question is whether this method is physical
layer independent.
 
William Dai
----- Original Message -----
From: Raj Sharma
Sent: Wednesday, September 06, 2000 10:11 AM
Subject: RE: Next Steps toward an RPR Draft Standard

Bob,
 
Thanks for taking the initiative to pull things together.
 
Here is question/concern/issue:
 
1. RPR - A layer 2 protocol is defined for multiservices:
Voice, Video and Data. That mulitmedia traffic carried in Layer 2.
2. RPR is defined independent of physical layers.
3. Existing physical layers considered are GBE and SONET.
 
Q. How will voice be supported by GBE physical layer?
If it cannot than statement #1 and #2 are not satisfied.
 
This is a problem
 
raj
 
-----Original Message-----
From: RDLove [mailto:rdlove@xxxxxxxxx]
Sent: Tuesday, September 05, 2000 8:19 AM
To: stds-802-rprsg@xxxxxxxx
Subject: Next Steps toward an RPR Draft Standard

As we plan to meet our aggressive RPR Standards development
schedule, we need to be taking our first steps developing the draft.
 
One critical first step is generating a comprehensive list of issues
that need to be solved before the draft goes out for Working Group ballot. 
 
They say "A problem well defined is half solved". 
 
For some of our problems it will likely not be that easy.  However, until
the problems are defined we will have almost no hope of solving them. 
The issues list we will develop as a result of this input will be a living
document, complete with issue description, an estimate of what it will
take to resolve (i.e. presentation of technical data, agreement from
competing proposals, etc.) along with a time frame for resolution. 
 
Some of the issues will require a leader to be named to drive the issue
and develop a recommended resolution for the working group to consider. 
 
For others, we may need a small ad-hoc group composed of the
competing factions.  They will either develop a recommendation
for the working group to consider, or, if unable to do so, develop a
proposed set of criteria for the working group to assign weights to
in rating the competing proposals. 
 
As a working group we will need to evaluate the issues to decide if
the group believes they are relevant, and if so, when we should be in a
position to resolve them. 
 
Ideally, we should have a fairly comprehensive set of issues by the start
of the November meeting.  If the group does not already have an issues
list and owner, I volunteer to develop and maintain the list based on
concerns expressed by anyone in the group.
 
Here is a suggested format for that list:
 
 
  

#

Description

Status

 

Short Title: Detailed description including problem statement, plans for resolution, decisions and approval level (Editor, Ad-Hoc Group, Task Force, or Working Group) with plans, checkpoints, responsibility, and planned closing date.

Date opened, short status, Close date - planned and actual

 

 

 

Initially, issues should be submitted with an abbreviated title and a description of the problem in sufficient detail for us to begin to develop plans to resolve it.  As the issues come in, they will be assigned a number and placed in the table of issues, which should be prominently posted on our web site.  As we progress on the issues we will update the chart. 

I request of each of you to begin compiling your own issues lists - areas that need addressing.  Please send them to the reflector.  I will create a "master" table with all issues on it.  At the November meeting we should have some time to scrub the table, combining some of the issues and dropping others.  Following November meeting we will be in a position to publish on the web our first issues list.Best regards,

 

Best regards,
 
Robert D. Love
President, LAN Connect Consultants
7105 Leveret Circle
Raleigh, NC 27615
Phone: 919 848-6773
Fax: 720 222-0900
email: rdlove@xxxxxxxx