Subject: [CCAMP] OTN control drafts

From: Fatai Zhang <[email-masked]>
Date: Fri, 23 Oct 2009 17:31:40 +0800

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:
(1) draft-zhang-ccamp-gmpls-g709-framework-00.txt 
(2) draft-zhang-ccamp-gmpls-evolving-g709-03.txt 
(3) draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt 
(4) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt 
(5) draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt 

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

Thanks

Authors of these drafts

---

From: Yechiel Rosengarten <[email-masked]>
Date: Sun, 25 Oct 2009 10:23:24 +0200

Hi,
Some questions about draft-zhang-ccamp-gmpls-g709-framework-00.txt<http://tools.ietf.org/html/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<http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-g709-framework-00#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<http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-g709-framework-00#ref-ITUT-G709>], [Gsup43<http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-g709-framework-00#ref-Gsup43>] and [G709-V3<http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-g709-framework-00#ref-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: [email-masked]<mailto:[email-masked]>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Friday, October 23, 2009 11:32 AM
To: CCAMP
Subject: [CCAMP] OTN control drafts

Hi CCAMPers,

Up to now, we have five drafts about OTN control:
(1) draft-zhang-ccamp-gmpls-g709-framework-00.txt<http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-g709-framework-00.txt>
(2) draft-zhang-ccamp-gmpls-evolving-g709-03.txt<http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-03.txt>
(3) draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt<http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt>
(4) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt<http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt>
(5) draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt <http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt>

Thanks

Authors of these drafts

---

From: Yechiel Rosengarten <[email-masked]>
Date: Sun, 25 Oct 2009 11:05:12 +0200

Hi,

>From Paragraph 3.2 of the draft:
"
3.2.  Verify Transport Mechanism

      . . . . .
      Capability of transmitting Test messages using ODUk Trail Trace
      Identifier (TTI) overhead with frame length of 64 bytes.  See ITU
      G.709 Section 15.2<http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01#section-15.2> and Section 15.8<http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01#section-15.8> for the structure and
      definition.  The Test message is sent according to [RFC4204<http://tools.ietf.org/html/rfc4204>].

      - 0x04 GCC0: Test Message over the GCC0

      Capability of transmitting Test messages using the OTUk Overhead
      General Communications Channel (GCC0).  See ITU G.709 Section 15.7<http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01#section-15.7>
      for the structure and definition.  The Test message is sent
      according to [RFC4204<http://tools.ietf.org/html/rfc4204>] using bit-oriented HDLC framing format
      [RFC1662<http://tools.ietf.org/html/rfc1662>].

      - 0x08 GCC1/2: Test Message over the GCC1/2

      Capability of transmitting Test messages using the ODUk Overhead
      General Communications Channels (GCC1/2).  See ITU G.709 Section
      15.8 for the structure and definition.  The Test message is sent
      according to [RFC4204<http://tools.ietf.org/html/rfc4204>] using bit-oriented HDLC framing format
      [RFC1662<http://tools.ietf.org/html/rfc1662>].
"

In the draft there is no distinguishing between transmitting the test message over GCC1 or GCC2 while the other endpoint of the link may be capable of terminating one of them but not both. Thus I would suggest to allocate separate bit for each.

Best Regards,

     Yechiel Rosengarten
     System Engineering
     ECI Telecom Ltd
     30 Hasivim St. Petach Tikva 49517 Israel

Hi CCAMPers,

Thanks

Authors of these drafts

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 26 Oct 2009 17:35:40 +0800

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 ----- 
  From: Yechiel Rosengarten 
  To: Fatai Zhang ; CCAMP 
  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.

  "

     is described in section 3.2.2.

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

  "

  2. 

    "

     LO ODU Matrix A

     LO ODU Matrix B

     LO ODU Matrix C

     LO ODU Matrix D

     LO ODU Matrix E

  "

  Best Regards,

       Yechiel Rosengarten
       System Engineering
       ECI Telecom Ltd
       e-mail: [email-masked]

  Hi CCAMPers,

   

  Thanks

  Authors of these drafts

---

From: Yechiel Rosengarten <[email-masked]>
Date: Mon, 26 Oct 2009 14:10:27 +0200

Hi Fatai
I appreciate your prompt answer

Best Regards,

     Yechiel

From: Fatai Zhang [mailto:[email-masked]]
Sent: Monday, October 26, 2009 11:36 AM
To: Yechiel Rosengarten
Cc: CCAMP
Subject: Re: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-framework-00.txt:

Hi  Yechiel,

(1) ODU4 as Lo ODU

Thanks

Fatai

----- Original Message -----
From: Yechiel Rosengarten<mailto:[email-masked]>
To: Fatai Zhang<mailto:[email-masked]> ; CCAMP<mailto:[email-masked]>
Sent: Sunday, October 25, 2009 4:23 PM
Subject: RE: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-framework-00.txt:

Hi,

2.
  "

   LO ODU Matrix A

   LO ODU Matrix B

   LO ODU Matrix C

   LO ODU Matrix D

   LO ODU Matrix E
"

Best Regards,

     Yechiel Rosengarten
     System Engineering
     ECI Telecom Ltd

Hi CCAMPers,

Thanks

Authors of these drafts

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Mon, 26 Oct 2009 15:03:54 +0100

Hi Yechiel,
 
thank you very much for your suggestion, it is worth distinguishing
between GCC1 and GCC2.
We'll introduce the modification in the next version of the ID.
 
Best regards
Daniele

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yechiel Rosengarten
Sent: domenica 25 ottobre 2009 10.05
To: Fatai Zhang; CCAMP
Subject: Re: [CCAMP] OTN control drafts:
draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt

Hi,

"

      . . . . .      

      G.709 Section 15.2
<http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-g709-lmp-test-0
1#section-15.2>  and Section 15.8
<http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-g709-lmp-test-0
1#section-15.8>  for the structure and

      definition.  The Test message is sent according to [RFC4204
<http://tools.ietf.org/html/rfc4204> ].

      General Communications Channel (GCC0).  See ITU G.709 Section 15.7
<http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-g709-lmp-test-0
1#section-15.7> 

      according to [RFC4204 <http://tools.ietf.org/html/rfc4204> ] using
bit-oriented HDLC framing format

      [RFC1662 <http://tools.ietf.org/html/rfc1662> ].

      according to [RFC4204 <http://tools.ietf.org/html/rfc4204> ] using
bit-oriented HDLC framing format

      [RFC1662 <http://tools.ietf.org/html/rfc1662> ].

"

In the draft there is no distinguishing between transmitting the test
message over GCC1 or GCC2 while the other endpoint of the link may be
capable of terminating one of them but not both. Thus I would suggest to
allocate separate bit for each. 

Best Regards,

     Yechiel Rosengarten
     System Engineering
     ECI Telecom Ltd

     e-mail: [email-masked]
<mailto:[email-masked]> 

From: [email-masked] [mailto:[email-masked]] 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.

(1) draft-zhang-ccamp-gmpls-g709-framework-00.txt
<http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-g709-framework-00.tx
t>  

(2) draft-zhang-ccamp-gmpls-evolving-g709-03.txt
<http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-03.txt

(3) draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt
<http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-00.tx
t>  

(4) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt
<http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-g709-lmp-test-0
1.txt>  

(5) draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt
<http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-g709-lmp-discovery-0
2.txt> 

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

Thanks

Authors of these drafts