[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-framework-00.txt:

Hi  Yechiel,
 
Thanks for your careful review and valuable comments.
 
I respond your questions one by one in the following:
 
(1) ODU4 as Lo ODU
 
This question is related to the concept of Ho ODU and Lo ODU.
 
"The current terminology in G.709 uses the term Higher Order ODU is used to identify an ODU that carries Lower Order ODU and is carried directly over an OTU.  The term Lower Order ODU is used to identify an ODU that is multiplex into a Higher Order ODU before it is carried by an OTU, or an ODU that carries a payload (other than a Lower Order ODU) and is carrier over an OTU."  ---- From the meeting report of ITU-T Q12 in June 2009.
 
So, we can understand when the ODU4 carries a 100GE service, then it is a LO ODU4. When the ODU4 carries a set of LO ODUs and the multiplexing is done in the carrier's network, then the ODU4 is a HO ODU4.
 
(2) Why link 4# and link 5# don't support ODU1
 
Here is just an example (You know the fact that a Ho ODU or OTU link may not support all the types of Lo ODU signals).
 
To be accurate and avoid confusion, I should modify the text as follows (To be updated in the next version):
 
   Link #1: Ho ODU2/OTU2, support transport of either LO ODU0 and LO ODU1 via HO ODU2/OTU2, or LO ODU2 via OTU2;
  
   Link #2: Ho ODU3/OTU3, support transport of either LO ODU0, LO ODU1, LO ODU2 via HO ODU3/OTU3, or LO ODU3 via OTU3;
  
   Link #3: Ho ODU2/OTU2, support transport of either LO ODU0, LO ODU1 via HO ODU2/OTU2, or LO ODU2 via OTU2;
 
   Link #4: Ho ODU1/OTU1, support transport of either LO ODU0 via HO ODU1/OTU1, or LO ODU1 via OTU1;
 
   Link #5: Ho ODU1/OTU1, support transport of either LO ODU0 via HO ODU1/OTU1, or LO ODU1 via OTU1;
 
 
 
 
 
Thanks
 
Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
----- Original Message -----
Sent: Sunday, October 25, 2009 4:23 PM
Subject: RE: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-framework-00.txt:

Hi,

Some questions about draft-zhang-ccamp-gmpls-g709-framework-00.txt:

1.

?

3.1.2.2. Optical channel data unit (ODUk)

   The optical channel data unit (ODUk) provides adaptation of client

   signals via the Optical Channel Payload Unit (OPUk) LO ODU (Lower

   order ODU) can be multiplexed into HO ODU (higher order ODU), which

   is described in section 3.2.2.

 

   Currently, the following ODUk types are defined: ODU0, ODU1, ODU2,

   ODU3, ODU4, ODU2e, ODUflex, ODU3e1, ODU3e2. ODUk has a bandwidth/bit

   rate BR and a bit rate tolerance T i.e. ODU(BR,T). The detailed bit

   rates and tolerance of the ODUk signals (except ODUflex) are defined

   in [ITUT-G709], [Gsup43] and [G709-V3]. The bitrate and tolerance of

   the ODUflex is dependent on the client signal.

 

   HO ODUk types are: ODU1, ODU2, ODU3, ODU4, ODU3e1, ODU3e2.

 

   LO ODUk types are: ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4, ODUflex.

   ODU3e1 and ODU3e2 can be treated as LO ODU signals outside the domain in which these signals terminate.

?

 

I wonder why ODU4 is included as LO ODUk type. It cannot be multiplexed to any higher order ODUk

 

2.

  ?

Take the following Figure 6 as an example, the single topology

   containing links and matrices can be illustrated as follows:

 

   LO ODU Link #1: HO ODU2, support transport of ODU0, ODU1, ODU2;

 

   LO ODU Link #2: HO ODU3, support transport of ODU0, ODU1, ODU2, ODU3;

 

   LO ODU Link #3: HO ODU2, support transport of ODU0, ODU1, ODU2;

 

   LO ODU Link #4: HO ODU1, support transport of ODU0;

 

   LO ODU Link #5: HO ODU1, support transport of ODU0;

 

   LO ODU Matrix A

 

   LO ODU Matrix B

 

   LO ODU Matrix C

 

   LO ODU Matrix D

 

   LO ODU Matrix E

?

Why link #4 and #5 do not support transport of ODU1? Is there any concept to do this exception compared to the other links?

 

Best Regards,

 

     Yechiel Rosengarten
     System Engineering
     ECI Telecom Ltd
     e-mail: yechiel.rosengarten at ecitele.com

 

From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] On Behalf Of Fatai Zhang
Sent: Friday, October 23, 2009 11:32 AM
To: CCAMP
Subject: [CCAMP] OTN control drafts

 

Hi CCAMPers,

 

You know that there are lots of interests from both a technical and organizational standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, since draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75th meeting.

 

You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consented by ITU-T SG15 in this October.  Therefore, in order to control and manage the OTN networks efficiently, OTN control is really important for the industry.

 

Up to now, we have five drafts about OTN control:

 

To promote better understanding or the discussions in Hiroshima meeting, we'd appreciate your review and comments.

 

 

Thanks

 

Authors of these drafts