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

Re: [802.3_MAINT] [8023-10GEPON] Discussion of the liaison from ITU Q2/15 regarding P2P optical access links



Dear Marek,

 

[Incidentally, I copied this thread onto the maintenance exploder also, since the original topic was also copied there.]


That is a good question ? let me clarify it.

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]
Sent: Friday, February 20, 2009 2:08 PM
To: STDS-802-3-10GEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [8023-10GEPON] Discussion of the liaison from ITU Q2/15 regarding P2P optical access links

 

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

Email: mailto:marek.hajduczenia@xxxxxxxxxx

 

From: Frank Effenberger [mailto:feffenberger@xxxxxxxxxx]
Sent: quarta-feira, 18 de Fevereiro de 2009 17:03
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