All,
To answer Jeff’s question: I believe that
the proposed application of the OAM extension messages is indeed aiming at just
carrying the OMCI datagrams over the link. This seemed to fit, given that
the OMCI carries OAM information, and the extension mechanism is sitting right
there... But, since this is a slow protocol, we inherit the 10 frame
limit (except for this link critical thing.)
To Jeff’s third point, there are many ways
that the OMCI information could be carried over the point to point Ethernet
link… Just from a purely practical viewpoint, nearly any field in the Ethernet
frame could be used as a multiplexing method: MAC address, Ethertype, Slow-protocol
type, OAM-sub-type, LLID (for EPON), or whatever… But, what the decision comes
down to is what method “fits best” with the overall architecture, and that is a
subjective question. I would be interested to hear more opinions on this
matter.
Actually, here is a different question I
just thought about: OAM is a slow protocol, right? So, it is supposed to live
within the restrictions of the slow protocol. But, the link critical
behavior would seem to enable the OAM protocol to violate the 10 frames per
second restriction. How can this be allowed?
If such “bending of the rules” is allowed,
then would it be possible to define a similarly bent “Slow protocol for OMCI”
that is not so slow? J
In reality, the 10 frames per second rule
is not relevant for the systems that we are talking about here ? so all of this
is really just window-dressing.
I think we should keep that in mind.
Sincerely,
Frank E.
From: Jeff Mandin
[mailto:Jeff_Mandin@xxxxxxxxxxxxxx]
Sent: Sunday, February 22, 2009
3:18 AM
To: Frank Effenberger
Cc:
STDS-802-3-10GEPON@xxxxxxxxxxxxxxxxx; STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: RE: [8023-10GEPON]
Discussion of the liaison from ITU Q2/15 regarding P2P optical access links
Frank hi,
1. I agree with Mr. Yokomoto's
characterization of the alarm issue. More specifically:
* The
"critical" parameter in figure 57-6 is explicity associated with the
3 OAM events/PDUs that are listed in 57.2.10.1.
* These
events are generated by the control entity depicted in 57.3 and not by an OAM
client
Consequently using the
"critical" parameter together w/ OMCI alarms would unavoidably entail
a modification to clause 57.
2. It would be helpful to receive
clarification on what aspects of OAM are of benefit to Q2/15. Is
there a desire to use features such as Discovery, remote loopback,
active/passive mode etc.? Or Is OAM merely a way of encapsulating the
OMCI messages?
3. If the latter, then an
alternative approach is to simply define OMCI as a management application
above the MAC layer (ie. parallel to OAM rather than on top of it).
To do this it is likely sufficient to define only an ethertype
and encapsulation format.
Regards,
- Jeff Mandin
From: Frank
Effenberger [mailto:feffenberger@xxxxxxxxxx]
Sent: Wednesday, February 18, 2009
7:03 PM
To:
STDS-802-3-10GEPON@xxxxxxxxxxxxxxxxx
Subject: [8023-10GEPON] Discussion
of the liaison from ITU Q2/15 regarding P2P optical access links
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