Subject: [CCAMP] FW: I-D Action:draft-zhang-ccamp-gmpls-evolving-g709-06.txt

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 28 Oct 2010 21:36:28 +0200

Hi,

Two comments from our side:

1.  ODUflex(CBR) is described clause 4 in a way that it could lead to
misunderstanding. 

As an example a client signal rate of 2.5G (+/-20ppm) is used. This
could be misunderstood that 2.5G signals will be mapped into an
ODUflex(CBR). In common language, 2.5G signals - especially with 20ppm -
are STM-16 or STS-48 signals, which really are 2.488 Gbit/s signals and
will be mapped into ODU2.

To avoid misunderstanding, it might be helpful to clearly state that
only signals with a bit rate >2.488Gbit/s will be mapped into
ODUflex(CBR).

2.  Clause 4.1 states at the end that ODUflex(GFP) is for further study
because G.709 would need to define the TS allocation. But the definition
is already there. ODUflex(GFP) can assume 1 TS up to 80 TS.

G.709 Table 7-8 defines the bandwidths.

In addition, clause 12.2.5 of G.709 states: The value of Cm should be
selected such that the ODUflex signal can be transported over "n" OPUk
tributary slots under worst-case conditions (i.e., maximum ODUflex bit
rate and minimum HO OPUk bit rates). This is shown more explicit in the
tables that follow.

But what it essentially means is that the number of occupied tributary
slots of an ODUflex(GFP) are and have to be constant over the entire
path (even in the case of restoration/protection). The number of
necessary TS is calculated out of the tributary slot bandwidth of the
smallest HO ODU in the path (i.e. with ODU2 as smallest HO container in
the path ODU2 TS bandwidth will determine the number of TS, with ODU3 as
smallest HO container in the path it will be ODU3, and with only HO ODU4
it will be ODU4).

Said all this, it might be helpful to already take this into account,
either by defining 2 different labels for the 2 types of ODUflexes, GFP
and CBR, or to reserve a field for the number of TS in the case the
ODUflex is an ODUflex(GFP). This new field would not be used in the case
of ODUflex(CBR)and/or would indicate that it is an ODUflex(CBR), e.g. by
using an invalid value "0" for the number of TS.

Best regards,

Nurit

-----Original Message-----

From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext
[email-masked]

Sent: Thursday, October 21, 2010 3:00 AM

To: [email-masked]

Subject: I-D Action:draft-zhang-ccamp-gmpls-evolving-g709-06.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

      Title           : Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Extensions for the evolving G.709 Optical Transport
Networks Control

      Author(s)       : F. Zhang, et al.

      Filename        : draft-zhang-ccamp-gmpls-evolving-g709-06.txt

      Pages           : 21

      Date            : 2010-10-20

Recent progress in ITU-T Recommendation G.709 standardization has 

introduced new ODU containers (ODU0, ODU4, ODU2e and ODUflex) and 

enhanced Optical Transport Networking (OTN) flexibility. Several 

 

<Zhang>

 

Expires April 2011

 

  [page 1] 

draft-zhang-ccamp-gmpls-evolving-g709-06.txt

 

October 2010 

recent documents have proposed ways to modify GMPLS signaling 

protocols to support these new OTN features.  

It is important that a single solution is developed for use in GMPLS 

signaling and routing protocols. This solution must support ODUk 

multiplexing capabilities, address all of the new features, be 

acceptable to all equipment vendors, and be extensible considering 

continued OTN evolution.  

This document describes the extensions to the Generalized Multi-

Protocol Label Switching (GMPLS) signaling to control the evolving 

Optical Transport Networks (OTN) addressing ODUk multiplexing and new 

features including ODU0, ODU4, ODU2e and ODUflex.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-evolving-g70
9-06.txt

Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader

implementation to automatically retrieve the ASCII version of the

Internet-Draft.

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 29 Oct 2010 11:08:25 +0800

Hi Nurit,

Thanks for your comments. Please see response in-line below.

Best Regards
 
Fatai
 
  ----- Original Message ----- 
  From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
  To: CCAMP 
  Cc: Ouyang, Yong (NSN - CN/Shanghai) ; Clemens, Rainer (NSN - DE/Munich) 
  Sent: Friday, October 29, 2010 3:36 AM
  Subject: [CCAMP] FW: I-D Action:draft-zhang-ccamp-gmpls-evolving-g709-06.txt

  Hi,

  1.  ODUflex(CBR) is described clause 4 in a way that it could lead to misunderstanding. 

  As an example a client signal rate of 2.5G (+/-20ppm) is used. This could be misunderstood that 2.5G signals will be mapped into an ODUflex(CBR). In common language, 2.5G signals - especially with 20ppm - are STM-16 or STS-48 signals, which really are 2.488 Gbit/s signals and will be mapped into ODU2.

  To avoid misunderstanding, it might be helpful to clearly state that only signals with a bit rate >2.488Gbit/s will be mapped into ODUflex(CBR).

  [Fatai], Agree, good catch. Here is just an example. We will modify the description according to your suggestion.

  2.  Clause 4.1 states at the end that ODUflex(GFP) is for further study because G.709 would need to define the TS allocation. But the definition is already there. ODUflex(GFP) can assume 1 TS up to 80 TS.

  In addition, clause 12.2.5 of G.709 states: The value of Cm should be selected such that the ODUflex signal can be transported over "n" OPUk tributary slots under worst-case conditions (i.e., maximum ODUflex bit rate and minimum HO OPUk bit rates). This is shown more explicit in the tables that follow.

  But what it essentially means is that the number of occupied tributary slots of an ODUflex(GFP) are and have to be constant over the entire path (even in the case of restoration/protection). The number of necessary TS is calculated out of the tributary slot bandwidth of the smallest HO ODU in the path (i.e. with ODU2 as smallest HO container in the path ODU2 TS bandwidth will determine the number of TS, with ODU3 as smallest HO container in the path it will be ODU3, and with only HO ODU4 it will be ODU4).

  Said all this, it might be helpful to already take this into account, either by defining 2 different labels for the 2 types of ODUflexes, GFP and CBR, or to reserve a field for the number of TS in the case the ODUflex is an ODUflex(GFP). This new field would not be used in the case of ODUflex(CBR)and/or would indicate that it is an ODUflex(CBR), e.g. by using an invalid value "0" for the number of TS.

  [Fatai] Good point. You said "The number of necessary TS is calculated out of the tributary slot bandwidth of the smallest HO ODU in the path" , but I don't think so, because how to determine the number of TS for an ODUflex(GFP) is under discussion in ITU-T/SG15. The tables in clause 12.2.5 don't tell us how to determine it. 

  Actually,  this issue has been discussed in the recent ITU SG15/q11 meeting held in Vimercate in September 2010. From the meeting report, we can see that it was decided that a resizable ODUflex(GFP) occupies the same number of TS on every link of the path, independently of the High Order (HO) OPUk TS rate. That is:

   For   n = 1 … 8      ODUflex = n * TS(OPU2)
   For   n = 9 … 32    ODUflex = n * TS(OPU3)
   For   n = 33 … 80  ODUflex = n * TS(OPU4)

  Please see WD07 and the meeting report of this meeting for more information. This is why we added an editors note to say "for further study" and added an editors' note in section 3.1.1 of [OTN FWK]. 

  We will updated it as soon as G.709 is updated.

  Best regards,

  Nurit

  -----Original Message-----

  From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]

  A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control

        Pages           : 21

        Date            : 2010-10-20

   

  <Zhang>

   

  Expires April 2011

   

    [page 1] 

   

  October 2010 

  continued OTN evolution.  

  http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-evolving-g709-06.txt

  Internet-Draft.

------------------------------------------------------------------------------

  _______________________________________________
  CCAMP mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/ccamp