| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Marek, [Incidentally, I copied this thread onto
the maintenance exploder also, since the original topic was also copied there.]
1) No, this has nothing to do with the MAC
control extension. Everybody seems to get that initial impression /
question, but it is not valid. The MAC control extension was to allow
certain TC-layer control messages to be carried, such as the functions that are
current carried in the PLOAM channel in G-PON systems. It is not meant to
carry OMCI, since OMCI is for management above the TC-layer. 2) The decision to add the MAC control
extension was to provide a channel for messages that have to do with the MAC
layer, such as protection switching, activation, and that kind of thing.
Basically, these are the functions that you find in the PLOAM channel.
Some of these are time critical, it is true; but, others are not.
The primary motivation was to follow the layering model. Sincerely, Frank E. From: Marek
Hajduczenia [mailto:marek_haj@xxxxxxx] Hi Frank, Two questions for
clarification for my (and hopefully not only my) education: (1)
Does
this have to do anything with EXTENSION MAC Control frames which we added in
Annex 31C? (2)
If
so, I believe the decision to add it was exactly guided by the lack of
limitation of the number of frames transmitted per second. Is that correct ? I am a little bit
confused about what they are trying to do, what this all has to do with GE
links (why not 10GE as well ??) and how is it all connected with EXTENSION MAC
Control frames from Annex 31C … Thanks Marek Hajduczenia ZTE
Corporation, Network Product Department Director of xPON Standardization, Rua Carlos Alberto da Mota Pinto 9, 6a Amoreiras Plaza, Lisbon, Portugal Telephone: +351 21 370 00 90 Fax: +351 21 381 33 49 Mobile: +351 961 121 851 From:
Frank Effenberger [mailto:feffenberger@xxxxxxxxxx] Dear All, The 802.3 group received a liaison from Q2/15 in the past
month. Please see: http://www.ieee802.org/3/minutes/mar09/0309_ITU_SG15_to_802_3_LS16.pdf I wanted to initiate an Email discussion of this liaison,
because it asks a question that we should try to answer. Specifically, the issue is presented in the following
passage from the liaison: “On the issue of OAM
specification, our basic approach is to implement a higher layer management
channel based on the “ONU management and control interface (OMCI)”
recommendations (G.984.4). The key issue here is how to carry the OMCI
messages across the GbE link. Various alternatives have been considered,
and the Slow Protocols channel was one possibility. However, we have
identified a possible issue that requires clarification, explained as follows: One of the functions of the OMCI channel is to carry alarms from the
ONU to the OLT. Many of these alarms are time critical, and should be
delivered as fast as possible. The first reading of the slow protocols
channel suggests that there is a restriction of 10 frames per second, which may
be limiting. But, on closer examination, we find that in the state
diagram of the OAM Transmit mechanism (Fig.57-6 in clause 57.3.2.2.4), it seems
that link critical events do not decrement the pdu_cnt variable, and therefore
do not count against the 10 frames per second limit. If we could
characterize our alarm messages as link critical events, then it seems that
this potential issue is resolved. We would like to confirm the
appropriateness of this characterization of alarms messages as critical link
events.” The 802.3av group reviewed the liaison at the January
interim. In the 802.3av group, I recall two basic opinions: 1) Sure, you
can call your alarms critical, if you want… Nobody is going to stop you.
2) This
question should be formulated as a request for interpretation, and input into
that process. That is where we left it. Just today, I received a side-communication from Mr. Tetsuya
Yokomoto, who mentioned the following: “This
is Tetsuya Yokomoto of Fujitsu. I would like to show my interpretation
regarding this matter. With respect to OMCI over
OAM/Ethernet, ideally it's better to use the Organization Specific OAMPDU (Code
field = 0xFE) with the Critical event flag set (Flags field bit2 = 1) to convey
an OMCI on the Ethernet frame. According to IEEE 802.3-2008
document, however, a critical event shall use an Information OAMPDU (Code field
= 0x00), not an Organization Specific OAM PDU. Sub-clause 57.2.5.1.2 says
that the indications corresponding to Flags field bits 2:0 are contained in the
OAM_CTL.request service primitive, which means the Critical event has to be
generated from an OAM_CTL.request. But in sub-clause 57.2.5.3.2
and 57.3.2.2.6 (or 57.7.3.1 OFS7), the OAM_ CTL.request with the
local_critical_event parameter set should cause a transmission of an
Information OAMPDU with the Critical Event bit of the Flags field set, not an
Organization Specific OAMPDU. I think that ITU-T can either go with an Information
OAMPDU to convey an OMCI (, which seems to me kind of unnatural though,) or ask
IEEE to modify 802.3 standard to allow the critical event to be transmitted on
an Organization Specific OAMPDU.” So, that is additional food for thought. In my own opinion, I think that as long as a proposed
behavior is not forbidden and does no harm, it can be allowed. And, the particular
application we are talking about here would be for a specific link-type (P2P
GbE optical access links) and the OAM messages are link-local, so it has a
controlled scope. I don’t think it could ever result in an
interoperability issue. I encourage all interested parties to comment on this
matter, so we can get all views on the table. Thank you for your time. Sincerely, Dr. Frank J. Effenberger 弗兰克 埃芬博格 Huawei Technologies Cell (908) 670 3889 Office/Home (732) 625 3001 |