| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 USA 1700
Alma Drive, Plano TX 75075 Cell
(908) 670 3889 Office/Home
(732) 625 3001 |