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

RE: stds-80220-requirements: 802.1q/p

Title: Message
My original message was too long due to the graphics, so here it goes again, compressed.
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:



4.5.2 Traffic Switching


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).

-----Original Message-----
From: []On Behalf Of Park Vincent
Sent: Monday, February 23, 2004 8:55 AM
To: Wallace, Stewart J;
Subject: RE: stds-80220-requirements: 802.1q/p

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.
-----Original Message-----
From: [] On Behalf Of Wallace, Stewart J
Sent: Sunday, February 22, 2004 8:12 PM
Subject: RE: stds-80220-requirements: 802.1q/p

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.