No Token, Just RPR w/ provisioned traffic engineering
I agree.
Now that we got most of the philosophical discussions out of the way,
let's focus on the objectives list of this new Ring Access MAC. I see
no reasons for active end-to-end source-and-destination control mechanism
today.
The utility of RPR is only as good as the provisioned traffic offered
to it. Traffic engineering is in two parts, classification and scheduling/queuing. Since some of this work belongs to layer 3 and
above, lets focus on the layer 2 services and primitives that allows for
the ultimate application that would run on RPR (e.g. carrier services,
ISP, ASP, etc). This may be a good point for someone to dig up the list
of the objectives regarding this Ring MAC and work toward refining it.
Does someone have a list to get us kick-started?
regards,
Yong.
-----Original Message-----
From: BJ Lee [SMTP:bjlee@xxxxxxxxxxxxxxxxxx]
Sent: Monday, November 20, 2000 7:47 AM
To: RDLove; Yongbum Kim; pazy@xxxxxxxxxxxxxxxxxx; stds-802-rprsg@xxxxxxxx
Subject: RE: Will we use tokens or not?
I would also consider the term "token" as strictly associated with the ring
access
control mechanism. Stretching my imagination a bit, the spatial reuse
property
of RPR (which enables multiple concurrent transmissions on the ring) is
effectively
equivalent to employing multiple tokens.
The second type of "token" Offer referred to should be categorized as
"control frames"
for the purposes such as topology discovery, (un)fairness enforcement, and
link failure
detection, etc.
Regards,
BJ
-----Original Message-----
From: owner-stds-802-rprsg@xxxxxxxx
[mailto:owner-stds-802-rprsg@xxxxxxxx]On Behalf Of RDLove
Sent: November 20, 2000 10:03 AM
To: Yongbum Kim; pazy@xxxxxxxxxxxxxxxxxx; stds-802-rprsg@xxxxxxxx
Subject: Re: Will we use tokens or not?
Offer, Yong, in tweny years of working with token ring I never heard of your
"second type of token" referred to as a token. It certainly would not be
called that by old IEEE 802.5 participants.
I realize that my answer begs the question as to whether this type of frame
will be used. I will leave that question to be answered in the Working
Group.
Best regards,
Robert D. Love
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@xxxxxxxx Fax: 720 222-0900
----- Original Message -----
From: Yongbum Kim <ybkim@xxxxxxxxxxx>
To: <pazy@xxxxxxxxxxxxxxxxxx>; <stds-802-rprsg@xxxxxxxx>
Sent: Monday, November 20, 2000 9:15 AM
Subject: RE: Will we use tokens or not?
>
> Dear Offer,
>
> As far as I am concerned, the second type of "token" you mentioned
> is rolled in to Ring Access method and is in the same context as Ethernet
> MAC control frame (802.3x). Would I call it a token? No. But someone
> could argue this to be some sort of token.
>
> regards,
>
> Yong.
>
> -----Original Message-----
> From: Offer Pazy [SMTP:pazy@xxxxxxxxxxxxxxxxxx]
> Sent: Thursday, November 16, 2000 10:14 PM
> To: stds-802-rprsg@xxxxxxxx
> Subject: Will we use tokens or not?
>
> In the email discussion about RPR Vs Ethernet positioning, Yong had made
> the claim that RPR does not use tokens. I would like to get a
> clarification on this.
>
> There are two types of tokens in a ring architecture. One is used as a
> "ring master" which grants the permission for a node to transmit.
> Clearly, RPR will not have such a token since the whole idea of spatial
> reuse is that more than one node can transmit at the same time.
>
> There is a second type of a token, a "control token" which is passed
> between the ring nodes carrying all sorts of control information
> (health, BW demands, and so forth). Are we saying that we won't have
> such a token in RPR? If so, and being a new comer, I would appreciate
> getting a pointer to any previous contribution to the group discussing
> this issue (or one which documents this decision).
>
> Thanks,
>
> Offer Pazy
> Sr. Product Manager
> Native Networks
>
> 15 Gonen St.
> Petah Tikva 49170
> Israel
> Tel: +972 3 921-0010 Ext. 229
> Fax: +972 3 921-0080
> pazy@xxxxxxxxxxxxxxxxxx
> http://www.nativenetworks.com
> << File: ATT00014.htm; charset = Windows-1252 >>