[802.3_MAINT] Draft of response liaison from the P2P ad-hoc

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Dear all,

I have drafted a short liaison that reviews the discussion we had in our ad-hoc meeting on the P2P liaison response.

Please give me your comments, so that I might have a chance to incorporate them.

If the schedule permits, we might get a chance to review this in the 802.3av meeting on Thursday morning.

Sincerely,

Frank Effenberger.

From: owner-stds-802-3-maint@xxxxxxxx [mailto:owner-stds-802-3-maint@xxxxxxxx] On Behalf Of Frank Effenberger
Sent: Wednesday, February 18, 2009 12:03 PM
To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: [802.3_MAINT] 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