idnits 2.17.1 draft-ietf-forces-interoperability-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2009) is 5414 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 585, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-forces-sctptml-02 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Haleplidis 3 Internet-Draft University of Patras 4 Intended status: Informational K. Ogawa 5 Expires: December 31, 2009 NTT Corporation 6 X. Wang 7 Huawei Technologies Co., Ltd. 8 C. Li 9 Zhejiang Gongshang University 10 June 29, 2009 12 ForCES Interoperability Draft 13 draft-ietf-forces-interoperability-02 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 31, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document describes the details of the interoperability test of 52 the Forward and Control Element Separation (ForCES) protocol that 53 will take place in the University of Patras in Rio, Greece, in the 54 third week of July 2009. This informational draft provides necessary 55 information, for all parties who wish to participate in the 56 interoperability test. 58 Table of Contents 60 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Transport mapping layer . . . . . . . . . . . . . . . . . 4 66 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Date, Location and Access . . . . . . . . . . . . . . . . . . 8 68 4.1. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.2. Location . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.3. Access . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Testbed architecture . . . . . . . . . . . . . . . . . . . . . 10 72 5.1. Local configuration . . . . . . . . . . . . . . . . . . . 10 73 5.2. Distributed configuration . . . . . . . . . . . . . . . . 11 74 6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6.1. Scenario 1 - Pre-association Setup . . . . . . . . . . . . 12 76 6.2. Scenario 2 - TML priority channels connection . . . . . . 13 77 6.3. Scenario 3 - Association Setup - Association Complete . . 13 78 6.4. Scenario 4 - CE query . . . . . . . . . . . . . . . . . . 13 79 6.5. Scenario 5 - Heartbeat monitoring . . . . . . . . . . . . 14 80 6.6. Scenario 6 - Simple Config Command . . . . . . . . . . . . 14 81 6.7. Scenario 7 - Association Teardown . . . . . . . . . . . . 14 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Terminology and Conventions 92 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Introduction 100 Forwarding and Control Element Separation (ForCES) defines an 101 architectural framework and associated protocols to standardize 102 information exchange between the control plane and the forwarding 103 plane in a ForCES Network Element (ForCES NE). [RFC3654] has defined 104 the ForCES requirements, and [RFC3746] has defined the ForCES 105 framework. 107 2.1. ForCES Protocol 109 The ForCES protocol works in a master-slave mode in which FEs are 110 slaves and CEs are masters. The protocol includes commands for 111 transport of Logical Function Block (LFB) configuration information, 112 association setup, status, and event notifications, etc. The reader 113 is encouraged to read FE-protocol [I-D.ietf-forces-protocol] for 114 further information. 116 2.2. ForCES Model 118 The FE-MODEL [I-D.ietf-forces-model] presents a formal way to define 119 FE Logical Function Blocks (LFBs) using XML. LFB configuration 120 components, capabilities, and associated events are defined when the 121 LFB is formally created. The LFBs within the FE are accordingly 122 controlled in a standardized way by the ForCES protocol. 124 2.3. Transport mapping layer 126 The TML transports the PL messages. The TML is where the issues of 127 how to achieve transport level reliability, congestion control, 128 multicast, ordering, etc. are handled. It is expected that more than 129 one TML will be standardized. The various possible TMLs could vary 130 their implementations based on the capabilities of underlying media 131 and transport. However, since each TML is standardized, 132 interoperability is guaranteed as long as both endpoints support the 133 same TML. All ForCES Protocol Layer implementations MUST be portable 134 across all TMLs. Although more than one TML may be standardized for 135 the ForCES Protocol, for the purposes of the interoperability test, 136 the mandated MUST IMPLEMENT SCTP TML [RFC3654] will be used. 138 3. Definitions 140 This document follows the terminology defined by the ForCES 141 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 142 The definitions below are repeated below for clarity. 144 Control Element (CE) - A logical entity that implements the ForCES 145 protocol and uses it to instruct one or more FEs on how to process 146 packets. CEs handle functionality such as the execution of 147 control and signaling protocols. 149 CE Manager (CEM) - A logical entity responsible for generic CE 150 management tasks. It is particularly used during the pre- 151 association phase to determine with which FE(s) a CE should 152 communicate. This process is called FE discovery and may involve 153 the CE manager learning the capabilities of available FEs. 155 Forwarding Element (FE) - A logical entity that implements the 156 ForCES protocol. FEs use the underlying hardware to provide per- 157 packet processing and handling as directed/controlled by one or 158 more CEs via the ForCES protocol. 160 FE Manager (FEM) - A logical entity responsible for generic FE 161 management tasks. It is used during pre-association phase to 162 determine with which CE(s) an FE should communicate. This process 163 is called CE discovery and may involve the FE manager learning the 164 capabilities of available CEs. An FE manager may use anything 165 from a static configuration to a pre-association phase protocol 166 (see below) to determine which CE(s) to use. Being a logical 167 entity, an FE manager might be physically combined with any of the 168 other logical entities such as FEs. 170 ForCES Network Element (NE) - An entity composed of one or more 171 CEs and one or more FEs. To entities outside an NE, the NE 172 represents a single point of management. Similarly, an NE usually 173 hides its internal organization from external entities. 175 LFB (Logical Function Block) - The basic building block that is 176 operated on by the ForCES protocol. The LFB is a well defined, 177 logically separable functional block that resides in an FE and is 178 controlled by the CE via ForCES protocol. The LFB may reside at 179 the FE's datapath and process packets or may be purely an FE 180 control or configuration entity that is operated on by the CE. 181 Note that the LFB is a functionally accurate abstraction of the 182 FE's processing capabilities, but not a hardware-accurate 183 representation of the FE implementation. 185 FE Topology - A representation of how the multiple FEs within a 186 single NE are interconnected. Sometimes this is called inter-FE 187 topology, to be distinguished from intra-FE topology (i.e., LFB 188 topology). 190 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. 191 An LFB Instance represents an LFB Class (or Type) existence. 192 There may be multiple instances of the same LFB Class (or Type) in 193 an FE. An LFB Class is represented by an LFB Class ID, and an LFB 194 Instance is represented by an LFB Instance ID. As a result, an 195 LFB Class ID associated with an LFB Instance ID uniquely specifies 196 an LFB existence. 198 LFB Metadata - Metadata is used to communicate per-packet state 199 from one LFB to another, but is not sent across the network. The 200 FE model defines how such metadata is identified, produced and 201 consumed by the LFBs. It defines the functionality but not how 202 metadata is encoded within an implementation. 204 LFB Component - Operational parameters of the LFBs that must be 205 visible to the CEs are conceptualized in the FE model as the LFB 206 components. The LFB components include, for example, flags, 207 single parameter arguments, complex arguments, and tables that the 208 CE can read and/or write via the ForCES protocol (see below). 210 LFB Topology - Representation of how the LFB instances are 211 logically interconnected and placed along the datapath within one 212 FE. Sometimes it is also called intra-FE topology, to be 213 distinguished from inter-FE topology. 215 Pre-association Phase - The period of time during which an FE 216 Manager and a CE Manager are determining which FE(s) and CE(s) 217 should be part of the same network element. 219 Post-association Phase - The period of time during which an FE 220 knows which CE is to control it and vice versa. This includes the 221 time during which the CE and FE are establishing communication 222 with one another. 224 ForCES Protocol - While there may be multiple protocols used 225 within the overall ForCES architecture, the term "ForCES protocol" 226 and "protocol" refer to the Fp reference points in the ForCES 227 Framework in [RFC3746]. This protocol does not apply to CE-to-CE 228 communication, FE-to-FE communication, or to communication between 229 FE and CE managers. Basically, the ForCES protocol works in a 230 master- slave mode in which FEs are slaves and CEs are masters. 231 This document defines the specifications for this ForCES protocol. 233 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 234 ForCES protocol architecture that uses the capabilities of 235 existing transport protocols to specifically address protocol 236 message transportation issues, such as how the protocol messages 237 are mapped to different transport media (like TCP, IP, ATM, 238 Ethernet, etc), and how to achieve and implement reliability, 239 multicast, ordering, etc. The ForCES TML specifications are 240 detailed in separate ForCES documents, one for each TML. 242 4. Date, Location and Access 244 4.1. Date 246 The date that the Interoperability draft will take place has been 247 specified at 15-16/07/2009, one and a half week before IETF 75, in 248 Stockholm. 250 4.2. Location 252 Patras is a major harbor of Greece connecting it with Italy. 254 The University of Patras is located in Rio, 10km east out of Patras. 256 The following coordinates mark the Electrical Engineering building in 257 the University. 259 o North: 38o17'15.99" 261 o East: 21o47'19.28" 263 4.3. Access 265 The best way to come to Greece is by plane to the Athens 266 International Airport. 268 From there there are three ways to arrive in the University of 269 Patras. 271 1. Renting a car and driving to the University. It is a maximum 272 2:30 hours drive from the aiport. 274 2. Via coach station. Get from the airport to the coach station via 275 X93 bus towards the Kifissos Coach Station. At the Coach Station 276 there are buses to Patras every 30 minutes. The Bus to Patras 277 may take about 2:30 - 3:00 hours, and the ride of the X93 bus may 278 take about 30 mins - 1hour depending on the traffic, so it's 279 about 3:30 - 4:30 hours away with the wait at the Coach Station. 281 3. Via Train. It is recommended you already have booked your ticket 282 beforehand as there are not many trains going to Patras, and 283 mostly are booked in advanced. It is not recommended that you 284 take the train to Patras, as you have to change at least 2 285 trains. In order to reach Patras from the Athens International 286 Airport you need to take the Suburban Rail to Neratziotissa. 287 From there you must take ISAP to Pireaus. There you must change 288 again to Suburban Rail to reach Kiato. From Kiato you can catch 289 a train to Patras. It will take you at least 5 hours to reach 290 Patras. 292 5. Testbed architecture 294 Most FEs and CEs should be located locally at the University of 295 Patras premises. But if some parties would like to participate but 296 cannot attend the interoperability test locally a connection over the 297 internet MAY be created. 299 The actual test will take place between FEs and CEs of different 300 implementors with different permutations. 302 All protocol messages of each scenario will be monitored using a 303 protocol network analyzer to test validity. Two tools shall be used: 305 o A modified tcpdump [tcpdump]. 307 o A modified Ethereal [ethereal]. 309 All NE's in all the scenarios will be comprised of one CE and one FE 310 from different implementors. 312 5.1. Local configuration 314 Hardware/Software (CEs and FEs) that will be located within the 315 University of Patras premises, will be connected together using 316 switches. 318 The scenarios will be tested with only one CE associated with one or 319 multiple FEs from different implementors. The CE and the FE(s) will 320 be connected in one LAN as shown in the following figure. 322 +-----+ 323 | CE1 | 324 |Impl1| 325 +-----+ 326 | 327 | 328 +------------------------------------+ 329 | LAN | 330 +------------------------------------+ 331 | | | | 332 | | ... | | 333 +-----+ +-----+ +-----+ +--------+ 334 | FE1 | | FE2 | | FEn | |Protocol| 335 |Impl1| |Impl2| |Impln| |Analyzer| 336 +-----+ +-----+ +-----+ +--------+ 338 All scenarios will be tested more than once with permutation of the 339 CE from different implementors. In the next permutation, the setup 340 will be as shown in the following figure. 342 +-----+ 343 | CE2 | 344 |Impl2| 345 +-----+ 346 | 347 | 348 +------------------------------------+ 349 | LAN | 350 +------------------------------------+ 351 | | | | 352 | | ... | | 353 +-----+ +-----+ +-----+ +--------+ 354 | FE1 | | FE2 | | FEn | |Protocol| 355 |Impl1| |Impl2| |Impln| |Analyzer| 356 +-----+ +-----+ +-----+ +--------+ 358 5.2. Distributed configuration 360 For parties that cannot participate, public IPs can be provided and 361 associations can be achieved over the internet as seen in the 362 following figure. 364 +-----+ +------------+ /\/\/\/\/\ +----------+ +-----+ 365 |FE/CE| |Implementor | \Internet/ |University| |FE/CE| 366 |ImplX|---| Router |---/ \---| Router |---|ImplY| 367 +-----+ +------------+ \/\/\/\/\/ +----------+ +-----+ 369 For interoperability issues, all CEs and FEs MUST implement no 370 security even in the TML. For security, firewalls MUST be used that 371 will allow only the specific IPs and the SCTP ports defined in the 372 SCTP-TML draft [I-D.ietf-forces-sctptml]. 374 6. Scenarios 376 Since the main goal of this interoperability test is to test the 377 basic protocol functionality, we will limit the test parameters. 378 Therefore: 380 1. In the Association Setup Message, all report messages will be 381 ignored. 383 2. In the Association Setup Phase, the messages, FEO OperEnable 384 Event (FE to CE), Config FEO Adminup (CE to FE) and FEO Config- 385 Resp (FE to CE) will be ignored. The CE will assume that the FE 386 is enabled once the LFBSelectors has been queried. 388 3. Only FullDataTLVs are going to be used and not SparseData TLV's. 390 4. There will be no transaction operations. 392 5. Each message shall have only one LFBSelector TLV, one Operation 393 TLV and one PathDataTLV per message when these are used. 395 6.1. Scenario 1 - Pre-association Setup 397 While the Pre-association setup is not in the ForCES current scope it 398 is an essential step before CEs and FEs communicate. As the first 399 part in a successfull CE-FE connection the participating CEs and FEs 400 should be able to be configured. 402 In the Pre-association Phase the following configuration items MUST 403 be setup regarding the CEs: 405 o The CE ID. 407 o The FE IDs that will be connected to this CE 409 o The IP of the FEs that will connect 411 o The TML priority ports. 413 In the Pre-association Phase the following configuration items MUST 414 be setup regarding the FEs: 416 o The FE ID. 418 o The CE ID that this FE will be connecting to. 420 o The IP of the CE that will connect to 421 o The TML priority ports. 423 Once each element is setup and configured, Scenario 1 is successful. 425 6.2. Scenario 2 - TML priority channels connection 427 For the current interoperability test, the SCTP will be used as TML. 428 The TML connection with the associating element is needed for the 429 scenario 2 to be successful. 431 The SCTP-TML draft [I-D.ietf-forces-sctptml] defines 3 priority 432 channels, with specific ports: 434 o High priority - Port number: 6700 436 o Medium priority - Port number: 6701 438 o Lower priority - Port number: 6702 440 Once these channels have been established with each associated 441 element, will the Scenario 2 be successful. 443 6.3. Scenario 3 - Association Setup - Association Complete 445 Once the Pre-association phase has been complete in the previous 2 446 scenarios, CEs and FEs are ready to communicate using the ForCES 447 protocol, and enter the Association Setup stage. In this stage the 448 FEs attempts to join the NE. The following ForCES protocol messages 449 will be exchanged for each CE-FE pair in the specified order: 451 o Association Setup Message (from FE to CE) 453 o Association Setup Response Message (from CE to FE) 455 o Query Message: FEO LFBSelectors(from CE to FE) 457 o Query Response: FEO LFBSelectors response (from FE to CE) 459 Once the associations has been initialized scenario 3 will have been 460 successful. 462 6.4. Scenario 4 - CE query 464 Once the Association Phase stage has been complete, the FEs and CEs 465 will enter the Established stage. In this stage the FE is 466 continuously updated or queried. The CE should query the FE a 467 specific value from the FE Object LFB and from the FE Protocol LFB. 468 An example from the FE Protocol LFB is the HeartBeat Timer (FEHI) and 469 from the FE Object LFB is the State of the LFB (FEState) 471 The following ForCES protocol messages will be exchanged: 473 o Query Message 475 o Query Response Message 477 6.5. Scenario 5 - Heartbeat monitoring 479 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 480 to asynchronously notify one or more other ForCES elements in the 481 same ForCES NE on its liveness. The default configuration of the 482 Heartbeat Policy of the FE is set to 0 which means, that the FE 483 should not generate any Heartbeat messages. the CE is responsible for 484 checking FE liveness by setting the PL header ACK flag of the message 485 it sends to AlwaysACK. In this Scenario the CE should send a 486 Heartbeat message with the ACK flag set to AlwaysACK and the FE 487 should respond. 489 The following ForCES protocol messages will be exchanged: 491 o Heartbeat Message 493 6.6. Scenario 6 - Simple Config Command 495 A config message is sent by the CE to the FE to configure LFB 496 components in the FE. A simple config command easily visible and 497 metered would be to change the Heartbeat configuration. This will be 498 done in two steps: 500 1. Change the FE Heartbeat Policy (FEHBPolicy) to value 1, to force 501 the FE to send heartbeats. 503 2. After some heartbeats from the FE, the FE Heartbeat Interval 504 (FEHI) will be changed. 506 The following ForCES protocol messages will be exchanged: 508 o Config Message 510 o Config Response Message 512 6.7. Scenario 7 - Association Teardown 514 In the end, the association must be terminated. There are two 515 scenarios by which the association maybe terminated: 517 1. Normal tear down by exchanging Association Teardown Message 519 2. Irregular tear down by stopping heartbeats from a FE or a CE. 521 3. Irregular tear down by externally shutting down/rebooting a FE or 522 a CE. 524 All scenarios may be tested in the interoperability test. 526 The following ForCES protocol messages will be exchanged: 528 o Association Teardown Message 530 7. Acknowledgements 532 The authors of this draft would like to acknowledge and thank the 533 chair of the ForCES working group Jamal Hadi Salim. 535 8. IANA Considerations 537 This memo includes no request to IANA. 539 9. Security Considerations 541 Section 9 of the FE-protocol [I-D.ietf-forces-protocol] specifies 542 security considerations of the ForCES protocol. For this 543 interoperability test, no security MUST be chosen even for the 544 distributed architecture. 546 10. References 548 10.1. Normative References 550 [I-D.ietf-forces-model] 551 Halpern, J. and J. Salim, "ForCES Forwarding Element 552 Model", draft-ietf-forces-model-16 (work in progress), 553 October 2008. 555 [I-D.ietf-forces-protocol] 556 Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., 557 Khosravi, H., and W. Wang, "ForCES Protocol 558 Specification", draft-ietf-forces-protocol-22 (work in 559 progress), March 2009. 561 [I-D.ietf-forces-sctptml] 562 Salim, J. and K. Ogawa, "SCTP based TML (Transport Mapping 563 Layer) for ForCES protocol", draft-ietf-forces-sctptml-02 564 (work in progress), January 2009. 566 10.2. Informative References 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 572 June 1999. 574 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 575 Text on Security Considerations", BCP 72, RFC 3552, 576 July 2003. 578 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 579 of IP Control and Forwarding", RFC 3654, November 2003. 581 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 582 "Forwarding and Control Element Separation (ForCES) 583 Framework", RFC 3746, April 2004. 585 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 586 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 587 May 2008. 589 [ethereal] 590 "Ethereal is a protocol analyzer. The specific ethereal 591 that will be used is an updated Ethereal, by Fenggen Jia, 592 that can analyze and decode the ForCES protocol 593 messages.", . 596 [tcpdump] "Tcpdump is a linux protocol analyzer. The specific 597 tcpdump that will be used is a modified tcpdump, by Jamal 598 Hadi Salim, that can analyze and decode the ForCES 599 protocol messages.", . 602 Authors' Addresses 604 Evangelos Haleplidis 605 University of Patras 606 Patras, 607 Greece 609 Email: ehalep@ece.upatras.gr 611 Kentaro Ogawa 612 NTT Corporation 613 Tokyo, 614 Japan 616 Email: ogawa.kentaro@lab.ntt.co.jp 618 Xin-ping Wang 619 Huawei Technologies Co., Ltd. 620 China 622 Email: carly.wang@huawei.com 624 Chuanhuang Li 625 Zhejiang Gongshang University 626 18, Xuezheng Str., Xiasha University Town 627 Hangzhou, 310018 628 P.R.China 630 Phone: +86-571-28877751 631 Email: chuanhuang_li@pop.zjgsu.edu.cn