| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I believe that the EFM-Copper effort should consider an approach to its Objectives that has been broadly hinted at by our Chairman, “maintain the IEEE tradition and ‘borrow’ someone else’s existing PHY.” Toward this end, I recommend that the TPS layers (PMD, etc.) be left aside for the standards bodies that have already done this work (ANSI, ITU, ETSI). These bodies, and the local regulatory agencies (FCC,...) will eventually dictate the band plans appropriate for the local loop, therefore we should be working on conformance, as stated already in our Objective #2, and initially concentrate on the adaptation layer and MAC. Included in this work should be collaboration with these other standards bodies in an attempt to extend their existing definitions of the Packet Transport Mode layer to enable better Ethernet functionality above it. Moreover, the EFM-Copper effort should not consider additional efforts that conflict with the band plans or line coding definitions already codified, as this may be in conflict with Objectives established and result in a standard that may not be accepted for use in bundles where regulated services exist.
John Egan
Regards,
Richard Brand
larry rennie wrote:
In listening to the presentations and responses at last weeks meeting, there was always the constant question of compliance. We need a structured methodology of dealing with this question. During the talks I sketched a very top level flow diagram approach. Copy attached. It is an iterative process. I believe we first need a strawman architecture that meets the criteria and objectives, always keeping 802.3 compliance as a goal in mind but not letting it control the initial architecture design to the point that prevents us from even getting to a strawman design that meets our criteria and objectives. After we have a strawman design that meets our criteria and objectives, we then look at 802.3 compliance. If not compliant we look at what modifications we could make to our objectives in order to get a viable 802.3 compliant architecture (and resulting EFM standard). If this is not possible, then we then have to look at the modifications needed to the existing 802.3stds (and other stds, such as 802.1) in order to come up with a viable EFM standard.Toward this end, I suggest that at the end of each presentation (particularly architecture related presentations) that an 802.3 compliance matrix be included with emphasis on what not is compliant and what existing standard changes are necessary for compliance of the subject matter in the presentation.
Regards,
Larry
Dolors Sala wrote:
We had a good discussion during the meeting on requirements. The
feedback on the forwarding rules was to present this problem to 802.1
for a possible incorporation of this functionality at the 802.1 layer.
Hence the discussion on this topic is put on hold in the requirements
effort. It will continue with the preparation of the presentation
to 802.1 group.The idea of this email is to define the objectives of the requirements,
both short term for the November meeting and longer term to capture the
general scope to be considered.Suggested list of issues is included below. Comments and modifications
are welcome. The focus of the effort can be modified accordingly.The suggestion is to focus first on 802.3x compliance. To start
the discussion, the first question on this topic is the following.
Both Pause and link aggregation are specified for full-duplex operation.
Is an 802.3 requirement to support them in PON since it is a shared
medium? If it is not, then this requirement is not a
compliance issue but rather a definition issue. In this case,
should they be supported?Dolors
Overall objectives of requirements effort:
------------------------------------------
1 Discussion of the remaining requirements
(see list below, and suggest additions
if list is not complete)
2 Polishing/agreement of existing requirements
The current document needs to be polished
to clean any concerns of out of scope
specification. So we have some work in
there to reduce the specification and
reach agreement.3 Peer-to-peer and bridging compliance
(in a separate presentation
in Nov meeting)General objectives for the requirements effort
----------------------------------------------
Pending topics for discussion:
1- 802.3 clause 31B (PAUSE mechanism)
2- 802.3 clause 43 (link aggregation)
3- Link security
3.1 yes/no
3.2 specific functionality
4- PON-specific OAMIt was a question during the requirements presentation on the
consideration of OAM requirements.
The initial idea was to leave item 4 for the OAM subgroup,
and concentrate on the system and protocol issues in this one. Any OAM
PON-protocol specific cannot be specified until the baseline protocol is
defined. Hence the idea was/is to only focus on this part of OAM in this
discussion. And hence leave it as the last topic for the discussion.
Comments on this are welcome.Objectives for Nov meeting
----------------------------
Given that there is only 3 weeks for next meeting, a good
objective could be to continue the discussion of the pending
requirements. The suggestion would be to focus first on 802.3x
compliance (pause, link aggregation) and then on the need (yes/no)
of security.
begin:vcard n:Brand;Richard C. tel;work:408 495 2462 x-mozilla-html:FALSE org:Advanced Technology Investments;Nortel Networks (408) 495 2462 adr:;;;;;; version:2.1 email;internet:rbrand@xxxxxxxxxxxxxxxxxx title:Director, Network Architecture & Applications fn:Richard C. Brand end:vcard