Subject: [CCAMP] Comments about OTN control drafts

From: [email-masked]
Date: Sat, 31 Oct 2009 13:35:09 +0800

Hi All,

RFC3630 defines the Maximum Bandwidth and  Unreserved Bandwidth. RFC4202 
and RFC4203 define Interface Switching Capability Descriptor (ISCD) 
including Max LSP Bandwidth at priority p and Minimum LSP Bandwidth in the 
Switching Capability specific information field.

(1) Following comments are about 
draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt.
Switching Capability-specific information is infered by a new Switching 
Capability (i.e., "Evolved OTN" ) defined in 
draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt. This method lacks of 
general purpose.
Can we use the current extensions defined in RFC3630 and RFC4202 to meet 
the requirement which is pointed out in these drafts ?
One option is to advertise multiple ISCD sub-TLVs within a single Link TLV 
for the link. But information is repeated for each LO ODU signal type. 
Aslo there is not enough information for composed signal computation.
1. For example, in order to represent one interface port of the ODU4/OTU4 
TE link with 2.5G TS which only supports ODU3 or ODU2, there can be three 
ISCDs.
The size of tributary slot can be infered by the Min LSP Bandwidth in the 
ISCD 1. LO ODU signal types supported by the interface port can be infered 
by the ISCD 2 and ISCD 3.
     Maximum Bandwidth = Bandwidth of ODU4 (239/227 × 99 532 800 kbit/s 
+/- 20 ppm)/OTU4 (e.g 255/227 × 99 532 800 kbit/s +/-20 ppm)
     Interface Switching Capability Descriptor 1:
         Interface Switching Capability = TDM
         Encoding = G.709 ODUk (Digital Path)
         Min LSP Bandwidth = 2.5G TS
         Max LSP Bandwidth[p] = ODU4/OTU4, for all p
         ,
     Interface Switching Capability Descriptor 2:
         Interface Switching Capability = TDM
         Encoding = G.709 ODUk (Digital Path)
         Min LSP Bandwidth = ODU2
         Max LSP Bandwidth[p] = ODU2 , for all p

         Interface Switching Capability Descriptor 3:
         Interface Switching Capability = TDM
         Encoding = G.709 ODUk (Digital Path)
         Min LSP Bandwidth = ODU3
         Max LSP Bandwidth[p] = ODU3 , for all p

2. Another example, in order to represent one interface port of the 
ODU3/OTU3 TE link link with 1.25G TS which only supports ODU2, there can 
be two ISCDs.
The size of tributary slot can be infered by the Min LSP Bandwidth in the 
ISCD 1. LO ODU signal types supported by the interface port can be infered 
by the ISCD 2 and ISCD 3.
      Maximum Bandwidth = Bandwidth of ODU3 (239/236 × 39 813 120 kbit/s 
+/- 20 ppm)/OTU3 (e.g 255/236 × 39 813 120 kbit/s +/-20 ppm)
      Interface Switching Capability Descriptor 1:
         Interface Switching Capability = TDM
         Encoding = G.709 ODUk (Digital Path)
         Min LSP Bandwidth = 1.25G TS
         Max LSP Bandwidth[p] = ODU3/OTU3, for all p

      Interface Switching Capability Descriptor 2:
         Interface Switching Capability = TDM
         Encoding = G.709 ODUk (Digital Path)
         Min LSP Bandwidth = ODU2
         Max LSP Bandwidth[p] = ODU2 , for all p

Another option is defined in OIF  E-NNI 2.0. It defined the following 
extension for SDH and ODUk. But I thik there is not enough information for 
the preempt computation defined in [RFC3209].

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Type (EXP)             |        Length = 4 + n*4       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Switching Cap |   Encoding    |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Signal Type  |        Number of Unallocated Timeslots        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Signal Type  |        Number of Unallocated Timeslots        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                            . . .                             //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |  Signal Type  |        Number of Unallocated Timeslots        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I think all the above extensions are in order to carry enough information 
for bandwidth counting. But there should be a more general solution for 
TDM including SDH and ODUk.

(2) Follwoing comments are about 
draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt .
As bidirectional links with different Interface Switching Capabilities at 
its two ends are allowed, for a bidirectional link the node uses its TED 
to determine the Interface Switching Capability Descriptor(s) of the 
far-end of the link. The node can know the tributary slot size and the 
supporting LO ODU signal type in the the far-end of the link. 
This view point also is refered in 
draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt (i.e., ”Note that LO 
ODU type information can be, in principle, discovered by routing. Since in 
certain case, routing is not present (e.g. UNI case) we need to extend 
link management protocol capabilities to cover this aspect.“). 
According to G.709 Amd 3 (i.e., "Equipment supporting ODTUk.ts for OPU2 or 
OPU3 must be backward compatible with equipment which supports only the 
ODTUjk. ODTUk.ts capable equipment transmitting PT=21 which receives PT=20 
from the far end shall revert to PT=20 and operate in ODTUjk only mode. 
Refer to G.798 for the specification."
), for interworking between 1G25 and 2G5 capable equipment shoul be  an 
automatic adaptataion. So there is no necessary coordination for the TS 
size between two ends of one link in the network. Interworking between 
RFC4328 and new extension shoul also be an automatic adaptataion. 
Does it mean the extension defined in the draft-zhang-discovery only be 
used in the UNI ? Could you give a scenario where discovery is used in UNI 
?

Xihua Fu
ZTE Corporation

----- Original Message ----- 
From: [email-masked] 
To: [email-masked] ; CCAMP 
Sent: Wednesday, October 28, 2009 4:18 PM
Subject: RE:[CCAMP] OTN control drafts

Hi Fatai and All, 

There is also another draft about the ODUk extension which has been 
presented in IETF 75th meeting. It has been updated to 
draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-01.txt. Note: The name 
of this updated draft will be changed to 
draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-01.txt after 09, Nov. 
we'd appreciate your review and comments. 

Xihua Fu 
ZTE Corporation 

----- Original Message ----- 
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. 
  
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 
  
 _______________________________________________ 
CCAMP mailing list 
[email-masked] 
https://www.ietf.org/mailman/listinfo/ccamp