Re: [CCAMP] draft-ietf-ccamp-flexi-grid-fwk-01

[[e-mail]]

Hi Maarten,

I CC the mail to CCAMP. 
I aggree with you. PCE should compute the path for a group of network 
media channel. 
If all of them meet performance requirement, they should be signaled and 
recovery together.
When we recall the connection management of ODUk, a group of network media 
channels which must be managed as a single entity is similar as an ODUk 
connection. 
An ODUk connection is composed of multiple time slots (e.g., 1.25G).

Thanks,

Xihua




Maarten vissers <[e-mail]> 
2014-03-05 上午 06:55

收件人
"[e-mail]" <[e-mail]>
抄送
Daniele Ceccarelli <[e-mail]>, Iftekhar Hussain 
<[e-mail]>, "[e-mail]" 
<[e-mail]>, Oscar González de Dios <[e-mail]>, Ramon 
Casellas <[e-mail]>, "Zhangxian (Xian)" 
<[e-mail]>, Fatai Zhang <[e-mail]>
主题
RE: slides for draft-ietf-ccamp-flexi-grid-fwk-01






Hi Xihua,
 
Indeed, as you describe an OTUCn is carried in its entirety over one 
optical channel layer connection. 
A complete or partial failure of this one connection will be represented 
as a signal fail condition of the connection.
This approach keeps things simple and thus manageable. It also keeps the 
set up of this connection in network elements very similar to the set up 
of an ODUk connection. Main difference between the two is the 
configuration of timeslots versus frequency slots. But this is not a real 
functional difference.
 
Path computation of this connection and an ODUk connection are very, very 
different… Path computation for this optical channel layer connection 
demands that the connection is considered to contain multiple network 
media channels and performance for each network media channel must be 
checked; i.e. compute one (or more) potential paths through the optical 
channel layer for this connection and then check the performance in every 
network media channel within each of the potential connections. If one or 
more of these potential connections provide the required performance, then 
select one of these and configure the optical channel layer cross connects 
in the network elements in the selected path.
An ODUk connection on the other hand can be treated as one entity; i.e. no 
need to consider the performance in the individual timeslot channels.
 
I expect that the above method (i.e. compute the path for the optical 
channel layer connection) is simpler than when you try to compute the path 
for individual network media channels and then have to check which of 
these channels are co-routed.
 
Regards,
Maarten
 
From: [e-mail] [mailto:[e-mail]] 
Sent: dinsdag 4 maart 2014 14:34
To: Maarten vissers
Cc: Daniele Ceccarelli; Iftekhar Hussain; [e-mail]; Oscar 
González de Dios; Ramon Casellas; Zhangxian (Xian); Fatai Zhang
Subject: RE: slides for draft-ietf-ccamp-flexi-grid-fwk-01
 

Hi Maarten, 

Thanks you for your detailed information. From the perspective of control 
plane, there are several aspects to consider. 
1. Path Computation: PCE needs to compute and end-to-end route which is 
composed of several network media channels. 
    These network media channels must be co-routed (i.e., go across same 
fibers and nodes). 
    Non co-routed requirement is not supported by Q11. This is an 
assumption in Q11, but no body want to challenge it until now. The main 
reason is delay issues. 
2. These network media channels must be created or deleted in atomic way. 
    That part of network media channels are successfully created or 
deleted should be considered as single entity connection creation or 
deletion failure. 
3. As part of failures are not supported in Q11, all of network media 
channels must be recovered (i.e., protection switching or restoration) 
together. 
    For example, if there is LOS alarm in one of network media channel due 
to optical module failure, all of media channel must be switched or 
re-routed together. 

Thanks, 

Xihua 



Maarten vissers <[e-mail]> 
2014-03-03 下午 05:31 


收件人
"[e-mail]" <[e-mail]>, Fatai Zhang <
[e-mail]> 
抄送
Daniele Ceccarelli <[e-mail]>, Iftekhar Hussain <
[e-mail]>, Oscar González de Dios <[e-mail]>, Ramon 
Casellas <[e-mail]>, "Zhangxian (Xian)" <
[e-mail]>, "[e-mail]" <
[e-mail]> 
主题
RE: slides for draft-ietf-ccamp-flexi-grid-fwk-01
 








All, 
  
Xihua is right with his notion that the transport of an OTUCn signal over 
one or more frequency slots is managed as one entity. 
The G.872 model does not reflect this management as single entity, but I 
expect that this management as single entity will be reflected in G.798 
and G.874.1. There is still a discussion necessary which of the entities 
shown in the G.872 model presented by Xihua map into the G.798 equipment 
termination and adaptation atomic functions and then into G.874.1 TTP and 
CTP managed objects. I have illustrated two alternative groupings in the 
figures below. I assume that the GMPLS extension however is agnostic to 
these alternatives. 
  
In the equipment functional model in G.798 I expect that we will have just 
the following atomic functions OCh/OTUCn_A, OChAG_TT (or simply OCh_TT) 
and OMSn/OCh_A and in the information model I expect that we will have the 
managed objects OTUCn CTP, OChAG TTP (or simply OCh TTP) and OCh CTP. This 
to describe that the various entities inside the G.872 model are managed 
as one entity and that there are other processes (e.g. defect correlation 
and consequent action) associated with the G.872 entities. 
There will be then one OCh_CI signal instance, which is mapped onto one or 
more frequency slots inside the OMSn/OCh_A function. In the information 
model this is reflected by means of the OCh TTP managed object connecting 
to the OCh CTP managed object. The OCh CTP managed object contains an 
attribute tributarySlotList, which holds the set of frequency slots that 
are occupied by the OCh_CI. See third figure below. 
  
Note that path computation needs to deal with the group of individual OTSi 
instances. Path computation should compute the path of the (multi-carrier) 
OCh_CI, and then check if the network media channel of each OTSi instance 
within the computed OCh network connection is able to provide the required 
performance. 
  
Regards, 
Maarten 
  


  
From: [e-mail] [mailto:[e-mail]] 
Sent: maandag 3 maart 2014 06:02
To: Fatai Zhang
Cc: Daniele Ceccarelli; Iftekhar Hussain; Oscar González de Dios; Ramon 
Casellas; Zhangxian (Xian); [e-mail]; Maarten vissers
Subject: Re: slides for draft-ietf-ccamp-flexi-grid-fwk-01 
  

Hi All, 

May I suggest we have a face to face meeting before Thursday CCAMP 
session? 
One of important requirement is not described in current framework. A 
group of frequency slots which supports a Beyond 100G OTN signal are 
managed as an entity. 
ZTE has one contribution of the management model for G.872 in March ITU-T 
meeting. This has been discussed several time in Q11. 
I add Malcolm and Maarten into this list. I suggest we add this 
requirement into next version. 




Thanks, 

Xihua 

Fatai Zhang <[e-mail]> 
2014-03-03 上午 04:28 
 


收件人
Ramon Casellas <[e-mail]>, "Zhangxian (Xian)" <
[e-mail]>, Daniele Ceccarelli <
[e-mail]>, Iftekhar Hussain <[e-mail]
>, "[e-mail]" <[e-mail]> 
抄送
Oscar González de Dios <[e-mail]> 
主题
答复: slides for draft-ietf-ccamp-flexi-grid-fwk-01

 
 









Hi Ramon,

Pretty good. Thanks for your work.


Thanks

Fatai


-----邮件原件-----
发件人: Ramon Casellas [mailto:[e-mail]] 
发送时间: 2014年2月27日 21:55
收件人: Fatai Zhang; Zhangxian (Xian); Daniele Ceccarelli; Iftekhar 
Hussain; [e-mail]
抄送: Oscar González de Dios
主题: slides for draft-ietf-ccamp-flexi-grid-fwk-01

Dear co-authors,

Attached a first set of slides to be presented during the 10 min slot.

Your comments are welcome.

Looking forward to seeing you in London, R.

PS: it would be a good opportunity to set another meeting as previously to 
go deeper into discussions

--
Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division 
Optical Networks and Systems Department -- http://wikiona.cttc.es CTTC - 
Centre Tecnològic de Telecomunicacions de Catalunya Parc Mediterrani de 
la Tecnologia (PMT) - Edifici B4 Av. Carl Friedrich Gauss, 7 - 08860 
Castelldefels (Barcelona) - Spain
Tel.: [phone] ext 2168-- Fax. [phone]