RE: [RPRWG] OK, we heard them talk, but what did they SAY?
Anoop,
Thanks for your comments. I somehow missed
that presentation at the May meeting. That
was my first WG meeting, and had a
full dose of 802.17 to digest.
I am very interested in solving this problem,
and hoping we can get the needed support.
While support of CID processing could be
done by the MAC to demultiplex to multiple
clients, it radically impacts all three
MAC definition proposals. None of the 3
802.17 proposals, support multiple clients
on top of the MAC. It also introduces
a whole new set of issues in terms of managing
bandwidth of multiple clients contending for
access to the MAC, etc. It sounds like an architectural
problem for the MAC to terminate 100's of CID's
at a single station. How many clients should
the 802.17 MAC support 100, 1000, 10000? I don't
think you can build such a beast, unless the MAC
absorbs the complexity of a high speed switch fabric.
It is much more cleaner architecturally to perform
the CID resolution in the upper layer.
I look forward to working together.
thanks,
bob
Robert Castellano
Jedai Broadband Networks
rc@xxxxxxxxx <mailto:rc@xxxxxxxxx>
(732) 758-9900 x236
-----Original Message-----
From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
Sent: Thursday, November 29, 2001 6:39 PM
To: 'rc@xxxxxxxxx'; Anoop Ghanwani; Jeanne.De_Jaegher@xxxxxxxxxx; Albert
Herrera; 'Devendra Tripathi '
Cc: stds-802-17@xxxxxxxx; ''Dawkins, Spencer' '; ''Vinay Bannai' '
Subject: RE: [RPRWG] OK, we heard them talk, but what did they SAY?
Bob,
> There has not been 1 presentation made in the
> past 4 meetings(with the exception of the 1 made to 802.1)
> on the CID. In fact, this issue was brought
> forth for discussion at this meeting by someone
> who doesn't have an interest in defining a CID.
> It sounds like there is a lot of people who want
> talk about it, but no one willing to do the work.
That's not entirely accurate. There was one presentation
back in May that discussed one possible approach to customer
separation.
(http://www.ieee802.org/17/documents/presentations/may2001/nv_mac_02.pdf)
But that was before my time :-)
>
> Defining a few bits in an RPR frame that
> is processed by the client and not by the MAC
> is not going to mean very much to the 802.17WG.
> As far as the standard is concerned, if the MAC
> accepts the bits from the client, places on the
> ring and passes back up to destination client
> and separation is maintained on the ring by virtue
> of behavior in the client, then we have met that
> objective.
Agreed.
>
> If the semantics of this ID are
> transparent to the MAC and processed by the client,
> then we do not need to consume working group time.
> Someone needs to develop an entire framework
> of how this field affects the forwarding rules
> of the client and how this information is disseminated
> throughout the network. This is clearly outside
> the scope of 802.17 MAC definition and standard.
> That's not to say that many of the attendees
> are interested in this problem as it relates to
> supporting service provider networks.
I'm not entirely convinced that it's outside the
scope of 802.17. For example, if we introduce
the concept of multiple MAC clients sitting on
top of the MAC, then it is the MAC that must
forward it to the correct client based on the
Customer ID.
> I believe there is interest to solve this problem,
> but if no one is committed to sponsoring as a
> real project, we're wasting the working group's
> time.
>
> Are you supportive of the 802.17WG pursuing
> sponsorship for this and are you willing to help?
>
Yes & yes.
-Anoop