|
My original
message was too long due to the graphics, so here it goes again,
compressed.
Branislav
-------------------------
Given
all the comments, there appear to be two alternative approaches that may be
agreeable to everybody:
1) An
802.16 style architectural solution with convergence sub-layers as below where
802.1q/p and other solutions are individual parallel
sub-layers:
[bran] -see compressed
attachments
2) A simpler
solution where we functionally require traffic classification and switching and
name as examples different alternatives. That would be my preference. So.
here is our proposal:
802.1q tagging, PPP,
MPLS or a functionally equivalent upper
layer solution must be supported by the system (such that network egress
traffic can be switched by a L2 device to the appropriate L2 termination device
for managing backbone traffic or distinguishing traffic for wholesale partners
in a wholesale environment).
Branislav
Your response seems to suggest
that flexibility in this area desirable, and on that point, I strongly agree.
I also agree that requirements must be worded carefully. My concern with the
proposed text is that it *reduces* flexibility by specifically
mandating particular solutions to a problem (it explicitly puts network-layer
awareness/assumptions in a link-layer specification). I find this to be
needless over-specification. All that is
needed in the MAC layer to support any of the proposed approaches to
wholesale/retail separation (or anything
else) is the equivalent of a "type" field or "next header" field
such that various types of payloads with different formats can be
multiplexed/demultiplexed over the air link. Then the MAC-layer payload
could carry IP, Bluetooth,
ATM, PPP, IP w/ 802.1Q tagging etc., as well as any other or future
payload formats that provide some yet unforeseen capability.
So, I would suggest that if a requirement on this issue is to be
included in the document, that it should simply state that
the system should include a
capability to enable *multi-protocol* support. Specifically, the air link
should be capable of multiplexing/demultiplexing payloads from
different higher layer protocols, where each such protocol may have a unique
formatting of the MAC layer payload.
This is a necessary (based on commercial requirements) and sufficient
(generic technical solution) requirement.
-Vince
Folks,
In
my view, carefully wording the Requirements Document text in such a way as
to allow any or all of these L2 switching mechanisms - such that vendors may
then make a commercial/competitive decision in regard to the extent of
compliance by their particular product - would certainly be preferred by
those network operators intending to offer wholesale carriage services, and
those wishing to offer self-provisioning to end users. I tend to agree
quite strongly with Dave's suggestions.
|