[CCAMP] Comments about OTN control drafts

[fu.xihua at zte.com.cn]

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: fu.xihua at zte.com.cn

To: zhangfatai at huawei.com
; 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: 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: 
(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 
CCAMP at ietf.org 
https://www.ietf.org/mailman/listinfo/ccamp