| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 |