idnits 2.17.1 draft-ietf-forces-interop-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 937 has weird spacing: '...edirect ospf ...' -- The document date (March 7, 2011) is 4798 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 166, but not defined == Missing Reference: 'RFC2404' is mentioned on line 461, but not defined == Unused Reference: 'RFC3654' is defined on line 1077, but no explicit reference was found in the text == Unused Reference: 'RFC5813' is defined on line 1097, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 1106, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. Wang 3 Internet-Draft Zhejiang Gongshang University 4 Intended status: Informational K. Ogawa 5 Expires: September 8, 2011 NTT Corporation 6 E. Haleplidis 7 University of Patras 8 M. Gao 9 Hangzhou BAUD Networks 10 J. Hadi Salim 11 Mojatatu Networks 12 March 7, 2011 14 Interoperability Report for Forwarding and Control Element Separation 15 (ForCES) 16 draft-ietf-forces-interop-00 18 Abstract 20 This document captures test results from the second Forwarding and 21 control Element Separation (ForCES) interop testing which took place 22 March 24-25, 2011 at the Internet Technology Lab (ITL) of Zhejiang 23 Gongshang University in China. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 8, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 4 63 1.4. CE HA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 65 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 66 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.1. Date, Location, and Participants . . . . . . . . . . . . . 8 69 3.2. Testbed configuration . . . . . . . . . . . . . . . . . . 8 70 3.2.1. Access . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.2.2. Local Configuration . . . . . . . . . . . . . . . . . 9 72 3.2.3. Distributed Configuration . . . . . . . . . . . . . . 10 73 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . . 12 75 4.1.1. Connection Diagram . . . . . . . . . . . . . . . . . . 12 76 4.1.2. Design Considerations . . . . . . . . . . . . . . . . 12 77 4.1.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 12 78 4.2. Scenario 2 - TML with IPSec . . . . . . . . . . . . . . . 12 79 4.2.1. Connection Diagram . . . . . . . . . . . . . . . . . . 13 80 4.2.2. Design Considerations . . . . . . . . . . . . . . . . 13 81 4.2.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 14 82 4.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 14 83 4.3.1. Connection Diagram . . . . . . . . . . . . . . . . . . 14 84 4.3.2. Design Considerations . . . . . . . . . . . . . . . . 14 85 4.3.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 15 86 4.4. Scenario 4 - Packet forwarding . . . . . . . . . . . . . . 15 87 4.4.1. Connection Diagram . . . . . . . . . . . . . . . . . . 16 88 4.4.2. Design Considerations . . . . . . . . . . . . . . . . 16 89 4.4.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 17 90 5. Test Results . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 5.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . . 18 92 5.2. TML with IPSec Test . . . . . . . . . . . . . . . . . . . 23 93 5.3. CE High Availability Test . . . . . . . . . . . . . . . . 24 94 5.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . . 25 95 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 27 96 6.1. On Data Encapsulation Format . . . . . . . . . . . . . . . 27 97 6.2. On ... . . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 103 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 104 11.2. Informative References . . . . . . . . . . . . . . . . . . 33 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 107 1. Introduction 109 This document captures the results of the second interoperability 110 test of the Forwarding and control Element Separation (ForCES) 111 Framework which took place March 24-25, 2011 in the Internet 112 Technology Lab (ITL) of Zhejiang Gongshang University in China. The 113 tests involved several documents namely: ForCES protocol [RFC5810], 114 ForCES FE model [RFC5812], ForCES TML [RFC5811], ForCES LFB Library [ 115 ] and ForCES CE HA specification[]. Three independent ForCES 116 implementations participated in the test. 118 Scenarios of ForCES LFB Operation, TML with IPSec, CE High 119 Availability, and Packet Forwarding are constructed. Series of 120 testing items for every scenario are carried out and interoperability 121 results are achieved. Extended Wireshark and extended tcpdump are 122 used to verify the results. 124 The first interop test held in July 2008 at the University of Patras, 125 Greece, focussed on validating the basic semantics of the protocol 126 and model[RFC6053]. 128 1.1. ForCES Protocol 130 The ForCES protocol works in a master-slave mode in which FEs are 131 slaves and CEs are masters. The protocol includes commands for 132 transport of Logical Function Block (LFB) configuration information, 133 association setup, status, and event notifications, etc. The reader 134 is encouraged to read FE-protocol [RFC5810] for further information. 136 1.2. ForCES Model 138 The FE-MODEL [RFC5811] presents a formal way to define FE Logical 139 Function Blocks (LFBs) using XML. LFB configuration components, 140 capabilities, and associated events are defined when the LFB is 141 formally created. The LFBs within the FE are accordingly controlled 142 in a standardized way by the ForCES protocol. 144 1.3. Transport Mapping Layer 146 The TML transports the PL messages. The TML is where the issues of 147 how to achieve transport level reliability, congestion control, 148 multicast, ordering, etc. are handled. It is expected that more than 149 one TML will be standardized. The various possible TMLs could vary 150 their implementations based on the capabilities of underlying media 151 and transport. However, since each TML is standardized, 152 interoperability is guaranteed as long as both endpoints support the 153 same TML. All ForCES Protocol Layer implementations MUST be portable 154 across all TMLs. Although more than one TML may be standardized for 155 the ForCES Protocol, for the purposes of the interoperability test, 156 the mandated MUST IMPLEMENT SCTP TML [RFC5811] will be used. 158 1.4. CE HA 159 2. Terminology and Conventions 161 2.1. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 2.2. Definitions 169 This document follows the terminology defined by ForCES related 170 documents of RFC3654, RFC3746, RFC5810,RFC5811,RFC5812,RFC5812. The 171 definitions are repeated below for clarity. 173 Control Element (CE) - A logical entity that implements the ForCES 174 protocol and uses it to instruct one or more FEs on how to process 175 packets. CEs handle functionality such as the execution of 176 control and signaling protocols. 178 Forwarding Element (FE) - A logical entity that implements the 179 ForCES protocol. FEs use the underlying hardware to provide per- 180 packet processing and handling as directed/controlled by one or 181 more CEs via the ForCES protocol. 183 LFB (Logical Functional Block) - The basic building block that is 184 operated on by the ForCES protocol. The LFB is a well defined, 185 logically separable functional block that resides in an FE and is 186 controlled by the CE via the ForCES protocol. The LFB may reside 187 at the FE's datapath and process packets or may be purely an FE 188 control or configuration entity that is operated on by the CE. 189 Note that the LFB is a functionally accurate abstraction of the 190 FE's processing capabilities, but not a hardware-accurate 191 representation of the FE implementation. 193 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. 194 An LFB Instance represents an LFB Class (or Type) existence. 195 There may be multiple instances of the same LFB Class (or Type) in 196 an FE. An LFB Class is represented by an LFB Class ID, and an LFB 197 Instance is represented by an LFB Instance ID. As a result, an 198 LFB Class ID associated with an LFB Instance ID uniquely specifies 199 an LFB existence. 201 LFB Metadata - Metadata is used to communicate per-packet state 202 from one LFB to another, but is not sent across the network. The 203 FE model defines how such metadata is identified, produced, and 204 consumed by the LFBs. It defines the functionality but not how 205 metadata is encoded within an implementation. 207 LFB Components - Operational parameters of the LFBs that must be 208 visible to the CEs are conceptualized in the FE model as the LFB 209 components. The LFB components include, for example, flags, 210 single-parameter arguments, complex arguments, and tables that the 211 CE can read and/or write via the ForCES protocol (see below). 213 ForCES Protocol - While there may be multiple protocols used 214 within the overall ForCES architecture, the term "ForCES protocol" 215 and "protocol" refer to the "Fp" reference points in the ForCES 216 framework in [RFC3746]. This protocol does not apply to CE-to-CE 217 communication, FE-to-FE communication, or to communication between 218 FE and CE managers. Basically, the ForCES protocol works in a 219 master-slave mode in which FEs are slaves and CEs are masters. 221 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 222 ForCES protocol architecture that uses the capabilities of 223 existing transport protocols to specifically address protocol 224 message transportation issues, such as how the protocol messages 225 are mapped to different transport media (like TCP, IP, ATM, 226 Ethernet, etc.), and how to achieve and implement reliability, 227 multicast, ordering, etc. The ForCES TML specifications are 228 detailed in separate ForCES documents, one for each TML. 230 3. Overview 232 3.1. Date, Location, and Participants 234 The ForCES interoperability test meeting was held by IETF ForCES 235 working group on March 24-25, 2011, and was chaired by Jamal Hadi 236 Salim, the current ForCES working group co-chair. Three independent 237 ForCES implementations participated in the test: 239 * Zhejiang Gongshang University/Hangzhou BAUD Networks, China. This 240 implementation is reffered to as "China" in the document for the sake 241 of brevity. 242 * NTT Corporation, Japan. This implementation is referred to as 243 "Japan" in the document for the sake of brevity. 244 * The University of Patras, Greece. This implementation is referred 245 to as "Greece" in the document for the sake of brevity. 247 During the interoperability test, protocol analyzers Wireshark and 248 tcpdump were used to verify the validity of ForCES protocol messages 249 and in some cases semantics. Some issues related to interoperability 250 among implementations were discovered. Most of the issues were 251 solved on site during the test. The most contentious issue found was 252 on the format of encapsulation for protocol TLV (Refer to Section 6). 253 At times, interoperability testing was exercised between 2 instead of 254 all three representative implementations due to the third one lacking 255 a specific feature; however, in ensuing discussions, all implementors 256 mentioned they will be implementing any missing features in the 257 future. 259 3.2. Testbed configuration 261 3.2.1. Access 263 Japan and China physically attended on site at the Internet 264 Technology Lab (ITL) of Zhejiang Gongshang University in China. The 265 University of Patras implementation joined remotely from Greece. The 266 chair, Jamal Hadi Salim, joined remotely from Canada by using the 267 teamviewer tool [ref XXX]. The approach is as shown in the following 268 figure. 270 +---------+ +----+ +----------+ 271 | FE/CE | | | +---|TeamViewer| 272 | China |-----| | /\/\/\/\/\ | | Canada | 273 +---------+ | | \Internet/ | +----------+ 274 |LAN |----/ \--| 275 +---------+ | | \/\/\/\/\/ | +----------+ 276 | FE/CE |-----| | | | FE/CE | 277 | Japan | | | +---| Greece | 278 +---------+ +----+ +----------+ 280 Figure 1: The Approach for all Participants 282 For interoperability test items, all CEs and FEs SHALL implement 283 IPSEC security in the TML. For security, firewalls MUST be used that 284 will allow only the specific IPs and the SCTP ports defined in the 285 ForCES SCTP-TML [RFC5811]. 287 3.2.2. Local Configuration 289 Hardware/Software (CEs and FEs) of China and Japan that were located 290 within the ITL Lab of Zhejiang Gongshang University, were connected 291 together using ethernet switches.The detailed configuration can be 292 seen in the following figure. 294 /\/\/\/\/\ 295 \Internet/ 296 / \ 297 \/\/\/\/\/ 298 | 299 |124.90.146.218 (ADSL) 300 | 301 +------------------------------------------------------------------+ 302 | LAN (10.20.0.0/24) | 303 +------------------------------------------------------------------+ 304 | | | | | | 305 | | | | | | 306 |.222 |.230 |.221 |.179 |.231 |.220 307 +-----+ +-----+ +-----+ +-----+ +-----+ +---------+ 308 | CE | | CE | | | | | | | | Protocol| 309 |China| |Japan| | FE1 |.1 .2| FE |.1 .2| FE2 | | Analyzer| 310 +-----+ +-----+ |China|---------|Japan|----------|China| +---------+ 311 +---------| | | | | |-------+ 312 | .2 +-----+ ^ +-----+ ^ +-----+ .2 | 313 | .12|192.168.20.0/24 192.168.30.0/24 |.12 | 314 | | | | 315 192.168.50.0/24 | | 192.168.50.0/24 316 | 192.168.10.0/24 192.168.40.0/24 | 317 .1 | |.11 |.11 |.1 318 +--------+ +---------------------------------------+ +--------+ 319 |Terminal| | Smartbits | |Terminal| 320 +--------+ +---------------------------------------+ +--------+ 322 Figure 2: Testbed Configuration Located in ITL Lab,China 324 3.2.3. Distributed Configuration 326 Hardware/Software (CE and FE) of Greece that were located within the 327 University of Patras premises,were connected together using LAN as 328 shown in the following figure. 330 Such configuation can satisfy all scenarios that are mentioned in 331 this document. Specially for the scenario of CE High Availability,in 332 which CE of Greece will be the backup one. 334 /\/\/\/\/\ 335 \Internet/ 336 / \ 337 \/\/\/\/\/ 338 | 339 |150.140.254.110(VPN) 340 | 341 +------------------------------------+ 342 | LAN | 343 +------------------------------------+ 344 | | | 345 | | | 346 +------+ +--------+ +------+ 347 | CE | |Protocol| | CE | 348 |Greece| |Analyzer| |Greece| 349 +------+ +--------+ +------+ 351 Figure 3: Testbed Configuration Located in the University of 352 Patras,Greece 354 4. Scenarios 356 4.1. Scenario 1 - LFB Operation 358 4.1.1. Connection Diagram 360 +------+ +------+ +------+ +------+ +------+ +------+ 361 | CE | | CE | | CE | | CE | | CE | | CE | 362 | China| | Japan| | China| |Greece| | Japan| |Greece| 363 +------+ +------+ +------+ +------+ +------+ +------+ 364 | | | | | | 365 | | | | | | 366 +------+ +------+ +------+ +------+ +------+ +------+ 367 | FE | | FE | | FE | | FE | | FE | | FE | 368 |Japan | |China | |Greece| |China | |Greece| |Japan | 369 +------+ +------+ +------+ +------+ +------+ +------+ 371 Figure 4: Scenario for LFB Operation 373 4.1.2. Design Considerations 375 First, the scenario of LFB Operation shown in Figure 4 is designed to 376 verify all kinds of messages which are defined in RFC 5810. 377 Different implementor may have different choices on implemeting RFC 378 5810 using cases in the protocol messages. However as long as it 379 complies with the RFC 5810, the interoperating peer must have the 380 ability to decode and handle it. Specially, what we want to verify 381 th most is the format of encasulation for PATHDATA with nested 382 PATHDATA and the operation(SET, GET,DEL) of array, as well as array 383 with nested array(This case can be seen in ARP LFB's component of 384 PortV4AddrInfoTable). 386 Second,the scenario is designed to verify the definition of ForCES 387 LFB Lib[ ]. A succeeded operation in this scenario means all the 388 meeting joining implementor follow the instruction given by the 389 ForCES LFB Lib. 391 4.1.3. Testing Proccess 393 In order to make interoperability more credible,these three 394 implementors carry out the test alternately. As shown in figure 4, 395 every side's CE or FE must connect with the other two sides's FE or 396 CE. So that, we shall have 6 cases in this Scenario. 398 4.2. Scenario 2 - TML with IPSec 399 4.2.1. Connection Diagram 401 +------+ +------+ 402 | CE | | CE | 403 | China| | Japan| 404 +------+ +------+ 405 | | 406 |TML over IPSec |TML over IPSec 407 +------+ +------+ 408 | FE | | FE | 409 |Japan | |China | 410 +------+ +------+ 411 (a) 413 +------+ +------+ 414 | CE | | CE | 415 | China| |Greece| 416 +------+ +------+ 417 | | 418 |TML over IPSec |TML over IPSec 419 +------+ +------+ 420 | FE | | FE | 421 |Greece| |China | 422 +------+ +------+ 423 (b) 425 +------+ +------+ 426 | CE | | CE | 427 | Japan| |Greece| 428 +------+ +------+ 429 | | 430 |TML over IPSec |TML over IPSec 431 +------+ +------+ 432 | FE | | FE | 433 |Greece| |Japan | 434 +------+ +------+ 435 (c) 437 Figure 5: Scenario for LFB Operation with TML over IPSec 439 4.2.2. Design Considerations 441 This scenario is designed to implement the requirement that stated in 442 the section "7. Security Considerations" in RFC 5811. For this 443 reason, we design the scenario to make TML to run over the IPSec 444 channel that is pre-established. In this scenario all operations for 445 Scenario 1 will be repeated. In this way, we try to verify whether 446 the interaction between CE and FE can be done normally under such 447 IPSec enviroment. 449 4.2.3. Testing Proccess 451 In this scenario, ForCES TML will run over IPSec channel. All the 452 implementors who joined in this interoperability testing use the same 453 third-party tool software 'racoon' to establish IPSec channel. By 454 this tool, China and Japan had a successful test, and the following 455 items have been realized: 457 o Internet Key Exchange (IKE) with certificates for endpoint 458 authentication. 460 o Transport Mode Encapsulating Security Payload (ESP). HMAC-SHA1-96 461 [RFC2404] for message integrity protection 463 4.3. Scenario 3 - CE High Availability 465 4.3.1. Connection Diagram 467 master standby master standby 468 +------+ +------+ +------+ +------+ 469 | CE | | CE | | CE | | CE | 470 | China| |Greece| |Japan | |Greece| 471 +------+ +------+ +------+ +------+ 472 | | | | 473 +----------+ +-----------+ 474 | | 475 +------+ +------+ 476 | FE | | FE | 477 |Greece| |Greece| 478 +------+ +------+ 479 (a) (b) 481 Figure 6: Scenario for CE High Availability 483 4.3.2. Design Considerations 485 CE High Availability was also tested in this interoperability test 486 based on the the CEHA draft [draft-ietf-forces-ceha-01]. 488 The design of the setup and the scenario for the CEHA are as simple 489 as possible to focus mostly on the mechanics of the CEHA. 491 4.3.3. Testing Proccess 493 In this scenario one FE would be connected with two CEs. In pre- 494 association setup, the FE would be configured to have CE1 as master 495 CE and CE2 as standby CE and CEFailoverPolicy to High Availability (2 496 or 3). The FE once associated with the master CE it would then 497 attempt to connect and associate with the standby CE. 499 When master CE is considered disconnected, either by TearDown, Loss 500 of Heartbeats or Disconnected, FE would assume that the standby CE is 501 now the master CE. FE will then send an Event Notification, Primary 502 CE Down,to all associated CEs, only the standby CE in this case with 503 the value of the new master CEID. The standby CE will then respond 504 by setting with a configuration message the CEID of the FE Protocol 505 Object with it's own ID, the same value, to confirm that the CE 506 considers itself as the master as well. 508 4.4. Scenario 4 - Packet forwarding 509 4.4.1. Connection Diagram 511 +------+ 512 | CE | 513 | Japan| 514 +------+ 515 | ^ 516 | | OSPF 517 | +-------> 518 +------+ +------+ 519 +--------+ | FE | | OSPF | +--------+ 520 |Terminal|------|China |-------|Router|------|Terminal| 521 +--------+ +------+ +------+ +--------+ 522 <--------------------------------------------> 523 Packet Forwarding 524 (a) 526 +------+ +------+ 527 | CE | | CE | 528 | Japan| | China| 529 +------+ +------+ 530 | ^ ^ | 531 | | OSPF | | 532 | +----------+ | 533 +------+ +------+ 534 +--------+ | FE | | FE | +--------+ 535 |Terminal|------|China |-------|Japan |------|Terminal| 536 +--------+ +------+ +------+ +--------+ 537 <--------------------------------------------> 538 Packet Forwarding 539 (b) 541 Figure 7: Scenario for IP Packet forwarding 543 4.4.2. Design Considerations 545 This Scenario can be used to verify some LFBs such as RedirectIn, 546 RedirectOut, IPv4NextHop, IPv4UcastLPM.Cases of (a) and (b) in Figure 547 7 both need RedirectIn LFB send CE's OSPF packet to FE futher to the 548 outside OSPF Router as Packet Redirect Message, RedirectOut LFB send 549 OSPF packet received from the outside OSPF Router to CE as well as 550 Packet Redirect Message.In such procedure, META DATA that included in 551 Packet Redirect Message should be coded and decoded for both CE and 552 FE. 554 If the above can be done with no issue, then the whole NE including 555 FE and CE will work like an OSPF router exchanging OSPF protocol 556 information with other OSPF router. As for CE, after finishing OSPF 557 exchanging, some routes maybe generated by OSPF and need to be added 558 to FE. So, IPv4NextHop and Ipv4UcastLPM must be working to support 559 such operation. 561 By sending packet to the destination through the FE, FE should 562 forward packet according to the route generate by OSPF. so, the data 563 path in FE can be tested and LFBs such as EtherPHYCop, EtherMacIn, 564 IPv4Classifier, IPv4Validator, EtherEncasulator, EtherMacOut also be 565 verified. 567 4.4.3. Testing Proccess 569 First,Boot terminals and routers, and set IP addresses of their 570 interfaces. 572 Second, Boot CE and FE. 574 Third, Establish association between CE and FE, and set IP addresses 575 of FE__s interfaces. 577 Fifth, Start OSPF among CE and routers, and set FIB on FE. 579 Sixth, Send packets between terminals. 581 5. Test Results 583 5.1. LFB Operation Test 585 For the convinience of stating,abbreviation is used here.So 'C' means 586 China ,'J' - Japan,'G'Greece and all testing results of this scenario 587 are listed in the following figure as well.(Note: other Scenarios 588 will follow the definition) 590 +----+----+-----+----+-----------+-----------+--------+-------------+ 591 |Test| CE |FE(s)|Oper| LFB |Component/ | Result | Comment | 592 |# | | | | |Capability | | | 593 +----+----+-----+----+-----------+-----------+--------+-------------+ 594 | 1 | C | J | | | |Success |As for the | 595 | | J | C | | | |Success | format of | 596 | | C | G | | | |TBD |encapsulation| 597 | | G | C | GET| FEObject |LFBTopology|Success |about array | 598 | | J | G | | | |Success |Only the case| 599 | | G | J | | | |Success |of FULLDATA- | 600 | | | | | | | |-in-FULLDATA | 601 | 2 | C | J | | | |Success |is spupported| 602 | | J | C | | | |Success |for everyone.| 603 | | C | G | | | |TBD |Howerver more| 604 | | G | C | GET| FEObject |LFBSelector|Success |types such as| 605 | | J | G | | | s |Success |SPARSEDATA | 606 | | G | J | | | |Success |should be | 607 | | | | | | | |supported for| 608 | 3 | C | J | | | |Success |every party. | 609 | | J | C | | | |Success | | 610 | | C | G | | | |TBD | | 611 | | G | C | GET|EtherPHYCop|PHYPortID |Success | | 612 | | J | G | | | |Success | | 613 | | G | J | | | |Success | | 614 | | | | | | | | | 615 | 4 | C | J | | | |Success | | 616 | | J | C | | | |Success | | 617 | | C | G | | | |TBD | | 618 | | G | C | GET|EtherPHYCop|AdminStatus|Success | | 619 | | J | G | | | |Success | | 620 | | G | J | | | |Success | | 621 | | | | | | | | | 622 | 5 | C | J | | | |Success | | 623 | | J | C | | | |Success | | 624 | | C | G | | | |TBD | | 625 | | G | C | GET|EtherPHYCop|OperStatus |Success | | 626 | | J | G | | | |Success | | 627 | | G | J | | | |Success |As for the | 628 | | | | | | | |format of | 629 | 6 | C | J | | | |Success |PATHDATA, | 630 | | J | C | | | |Success |J use the | 631 | | C | G | | | |TBD |case of | 632 | | G | C | GET|EtherPHYCop|AdminLink |Success |PATHDATA in | 633 | | J | G | | | Speed |Success |PATHDATA,C | 634 | | G | J | | | |Success |uses | 635 | | | | | | | |only one | 636 | 7 | C | J | | | |Success |PATHDATA with| 637 | | J | C | | | |Success |mutiple IDs. | 638 | | C | G | | | |TBD |G uses ... | 639 | | G | C | GET|EtherPHYCop| OperLink |Success | | 640 | | J | G | | | Speed |Success | | 641 | | G | J | | | |Success | | 642 | | | | | | | | | 643 | 8 | C | J | | | |Success | | 644 | | J | C | | | |Success | | 645 | | C | G | | | |TBD | | 646 | | G | C | GET|EtherPHYCop|AdminDuplex|Success | | 647 | | J | G | | | Speed |Success | | 648 | | G | J | | | |Success | | 649 | | | | | | | |The side of | 650 | 9 | C | J | | | |Success |C think that | 651 | | J | C | | | |Success |CE SHOULD get| 652 | | C | G | | | |TBD |LFB instance | 653 | | G | C | GET|EtherPHYCop|OperDuplex |Success |data | 654 | | J | G | | | Speed |Success |according to | 655 | | G | J | | | |Success |LFBSelectors.| 656 | | | | | | | | | 657 | 10 | C | J | | | |Success | | 658 | | J | C | | | |Success | | 659 | | C | G | | | |TBD | | 660 | | G | C | GET|EtherPHYCop| Carrier |Success | | 661 | | J | G | | | Status |Success | | 662 | | G | J | | | |Success | | 663 | | | | | | | | | 664 | 11 | C | J | | | |Success | | 665 | | J | C | | | |Success | | 666 | | C | G | | | |TBD | | 667 | | G | C | GET| EtherMACIn|AdminStatus|Success | | 668 | | J | G | | | |Success | | 669 | | G | J | | | |Success | | 670 | | | | | | | | | 671 | 12 | C | J | | | |Success | | 672 | | J | C | | | |Success | | 673 | | C | G | | | |TBD | | 674 | | G | C | GET|EtherMACIn | LocalMac |Success | | 675 | | J | G | | | Addresses |Success | | 676 | | G | J | | | |Success | | 677 | | | | | | | | | 678 | 13 | C | J | | | |Success | | 679 | | J | C | | | |Success | | 680 | | C | G | | | |TBD | | 681 | | G | C | GET|EtherMACIn |L2Bridging |Success | | 682 | | J | G | | |PathEnable |Success | | 683 | | G | J | | | |Success | | 684 | | | | | | | | | 685 | 14 | C | J | | | |Success | | 686 | | J | C | | | |Success | | 687 | | C | G | | | |TBD | | 688 | | G | C | GET|EtherMACIn |Promiscuous|Success | | 689 | | J | G | | | Mode |Success | | 690 | | G | J | | | |Success | | 691 | | | | | | | | | 692 | 15 | C | J | | | |Success | | 693 | | J | C | | | |Success | | 694 | | C | G | | | |TBD | | 695 | | G | C | GET|EtherMACIn | TxFlow |Success | | 696 | | J | G | | | Control |Success | | 697 | | G | J | | | |Success | | 698 | | | | | | | | | 699 | 16 | C | J | | | |Success | | 700 | | J | C | | | |Success | | 701 | | C | G | | | |TBD | | 702 | | G | C | GET|EtherMACIn | RxFlow |Success | | 703 | | J | G | | | Control |Success | | 704 | | G | J | | | |Success | | 705 | | | | | | | | | 706 | 17 | C | J | | | |Success | | 707 | | J | C | | | |Success | | 708 | | C | G | | | |TBD | | 709 | | G | C | GET|EtherMACIn |MACInStats |Success | | 710 | | J | G | | | |Success | | 711 | | G | J | | | |Success | | 712 | | | | | | | | | 713 | 18 | C | J | | | |Success | | 714 | | J | C | | | |Success | | 715 | | C | G | | | |TBD | | 716 | | G | C | GET|EtherMACOut|AdminStatus|Success | | 717 | | J | G | | | |Success | | 718 | | G | J | | | |Success | | 719 | | | | | | | | | 720 | 19 | C | J | | | |Success | | 721 | | J | C | | | |Success | | 722 | | C | G | | | |TBD | | 723 | | G | C | GET|EtherMACOut| MTU |Success | | 724 | | J | G | | | |Success | | 725 | | G | J | | | |Success | | 726 | | | | | | | | | 727 | 20 | C | J | | | |Success | | 728 | | J | C | | | |Success | | 729 | | C | G | | | |TBD | | 730 | | G | C | GET|EtherMACOut| TxFlow |Success | | 731 | | J | G | | | Control |Success | | 732 | | G | J | | | |Success | | 733 | | | | | | | | | 734 | 21 | C | J | | | |Success | | 735 | | J | C | | | |Success | | 736 | | C | G | | | |TBD | | 737 | | G | C | GET|EtherMACOut| TxFlow |Success | | 738 | | J | G | | | Control |Success | | 739 | | G | J | | | |Success | | 740 | | | | | | | | | 741 | 22 | C | J | | | |Success | | 742 | | J | C | | | |Success | | 743 | | C | G | | | |TBD | | 744 | | G | C | GET|EtherMACOut|MACOutStats|Success | | 745 | | J | G | | | |Success | | 746 | | G | J | | | |Success | | 747 | | | | | | | | | 748 | 23 | C | J | | | |Success | | 749 | | J | C | | | |Success | | 750 | | C | G | | | |TBD | | 751 | | G | C | GET| ARP |PortV4Addr |Success | | 752 | | J | G | | | InfoTable |Success | | 753 | | G | J | | | |Success | | 754 | | | | | | | | | 755 | 24 | C | J | | | |Success | | 756 | | J | C | | | |Success | | 757 | | C | G | | | |TBD | | 758 | | G | C | SET| ARP |PortV4Addr |TBD | | 759 | | J | G | | | InfoTable |Success | | 760 | | G | J | | | |Success | | 761 | | | | | | | | | 762 | 25 | C | J | | | |Success |C's misunder-| 763 | | J | C | | | |Success |standing of | 764 | | C | G | | | |TBD |the PATHDATA | 765 | | G | C | DEL| ARP |PortV4Addr |Failure |in DEL | 766 | | J | G | | | InfoTable |Success |Operation. | 767 | | G | J | | | |Success |Later C fixed| 768 | | | | | | | |the problem | 769 | 26 | C | J | | | |Success |and make it | 770 | | J | C | | | |Success |successful | 771 | | C | G | | | |TBD |in testing | 772 | | G | C | SET|EtherMACIn | LocalMAC |Success |with J. | 773 | | J | G | | | Addresses |Success | | 774 | | G | J | | | |Success | | 775 | | | | | | | | | 776 | 27 | C | J | | | |Success | | 777 | | J | C | | | |Success | | 778 | | C | G | | | |TBD | | 779 | | G | C | SET|EtherMACIn | MTU |Success | | 780 | | J | G | | | |Success | | 781 | | G | J | | | |Success | | 782 | | | | | | | | | 783 | 28 | C | J | | | |Success |By setting | 784 | | J | C | | | |Success |new reachable| 785 | | C | G | | | |TBD |network,Route| 786 | | G | C | SET|IPv4NextHop|IPv4NextHop|TBD |entry can be | 787 | | J | G | | | Table |Success |add into | 788 | | G | J | | | |Success |system. | 789 | | | | | | | | | 790 | 29 | C | J | | | |Success | | 791 | | J | C | | | |Success | | 792 | | C | G | | | |TBD | | 793 | | G | C | SET| IPv4Ucast |IPv4Prefix |TBD | | 794 | | J | G | | LPM | Table |Success | | 795 | | G | J | | | |Success | | 796 | | | | | | | | | 797 | 30 | C | J | | | |Success | | 798 | | J | C | | | |Success |Corresponding| 799 | | C | G | | | |TBD |nexthop entry| 800 | | G | C | DEL|IPv4NextHop|IPv4NextHop|TBD |MUST delete | 801 | | J | G | | | Table |Success |before prefix| 802 | | G | J | | | |Success |entry. | 803 | | | | | | | | | 804 | 31 | C | J | | | |Success | | 805 | | J | C | | | |Success | | 806 | | C | G | | | |TBD | | 807 | | G | C | DEL| IPv4Ucast |IPv4Prefix |TBD | | 808 | | J | G | | LPM | Table |Success | | 809 | | G | J | | | |Success | | 810 | | | | | | | | | 811 | 32 | C | J | | | |Success | | 812 | | J | C | | | |Success | | 813 | | C | G | | | |TBD | | 814 | | G | C | SET|EtherPHYCop|AdminStatus|Success | | 815 | | J | G | | | |Success | | 816 | | G | J | | | |Success | | 817 | | | | | | | | | 818 | 33 | C | J | | | |Success | | 819 | | J | C | | | |Success | | 820 | | C | G | | | |TBD | | 821 | | G | C | SET| Ether | VlanInput |Success | | 822 | | J | G | | Classifier| Table |Success | | 823 | | G | J | | | |Success | | 824 | | | | | | | | | 825 | 34 | C | J | | | |Success | | 826 | | J | C | | | |Success | | 827 | | C | G | | | |TBD | | 828 | | G | C | DEL| Ether | VlanInput |Failure | | 829 | | J | G | | Classifier| Table |Success | | 830 | | G | J | | | |Success | | 831 | | | | | | | | | 832 | 35 | C | J | | | |Success | | 833 | | J | C | | | |Success | | 834 | | C | G | | | |TBD | | 835 | | G | C | SET| Ether |VlanOutput |Success | | 836 | | J | G | |Encapsulato| Table |Success | | 837 | | G | J | | r | |Success | | 838 | | | | | | | | | 839 | 36 | C | J | | | |Success | | 840 | | J | C | | | |Success | | 841 | | C | G | | | |TBD | | 842 | | G | C | DEL| Ether |VlanOutput |Failure | | 843 | | J | G | |Encapsulato| Table |Success | | 844 | | G | J | | r | |Success | | 845 +----+----+-----+----+-----------+-----------+--------+-------------+ 847 5.2. TML with IPSec Test 849 In this scenario, ForCES TML will run over IPSec channel.All the 850 implementors who joined this interoperability test use the same 851 third-party tool software 'racoon' to establish IPSec channel.To be 852 mentioned is that we have not repeat all the operations listed in 853 Scenario 1,only some typical operations have been done. During the 854 test following results as shown in figure occured. 856 +----+----+-----+----+-----------+-----------+--------+-------------+ 857 |Test| CE |FE(s)|Oper| LFB |Component/ | Result | Comment | 858 |# | | | | |Capability | | | 859 +----+----+-----+----+-----------+-----------+--------+-------------+ 860 | 1 | C | J | | | |Success |For unkown | 861 | | J | C | | | |Success |error in | 862 | | C | G | | | |TBD |configuration| 863 | | G | C | GET| FEObject |LFBTopology|TBD |with racoon, | 864 | | J | G | | | |TBD |Greece still | 865 | | G | J | | | |TBD |need some | 866 | | | | | | | |time to fix | 867 | 2 | C | J | | | |Success |the issue. | 868 | | J | C | | | |Success |So,this | 869 | | C | G | | | |TBD |scenario only| 870 | | G | C | GET| FEObject |LFBSelector|TBD |took place | 871 | | J | G | | | s |TBD |between C and| 872 | | G | J | | | |TBD |J. | 873 | | | | | | | | | 874 | 3 | C | J | | | |Success | | 875 | | J | C | | | |Success | | 876 | | C | G | | | |TBD | | 877 | | G | C | SET| Ether | VlanInput |TBD | | 878 | | J | G | | Classifier| Table |TBD | | 879 | | G | J | | | |TBD | | 880 | | | | | | | | | 881 | 4 | C | J | | | |Success | | 882 | | J | C | | | |Success | | 883 | | C | G | | | |TBD | | 884 | | G | C | DEL| Ether | VlanInput |TBD | | 885 | | J | G | | Classifier| Table |TBD | | 886 | | G | J | | | |TBD | | 887 +----+----+-----+----+-----------+-----------+--------+-------------+ 889 5.3. CE High Availability Test 891 In this scenario one FE would be connected with two CEs. In pre- 892 association setup, the FE would be configured to have CE1 as master 893 CE and CE2 as standby CE and CEFailoverPolicy to High Availability (2 894 or 3). The FE once associated with the master CE it would then 895 attempt to connect and associate with the standby CE. 897 When master CE is considered disconnected, either by TearDown, Loss 898 of Heartbeats or Disconnected, FE would assume that the standby CE is 899 now the master CE. FE will then send an Event Notification, Primary 900 CE Down,to all associated CEs, only the standby CE in this case with 901 the value of the new master CEID. The standby CE will then respond 902 by setting with a configuration message the CEID of the FE Protocol 903 Object with it's own ID, the same value, to confirm that the CE 904 considers itself as the master as well. 906 5.4. Packet Forwarding Test 908 The Scenario of packet forwading is the most complex one because it 909 need the Scenario 1 must be completed.In this scenario testing,the 910 pattern of J-CE C-FE was carried out. Smartbits's 2 testing ports 911 connect to FE's 2 data-forwarding ports,meanwhile smartbits simulate 912 ospf router and try to exchange the OSPF hello packet and LSA packet 913 with CE,because CE also has an OSPF process in it so that the whole 914 NE including FE and CE looks like an OSPF router. 916 In this scenario,RedirectIn,RedirectOut,IPv4NextHop,IPv4UcastLPM LFB 917 should join the data path.First, it must be sured that IPv4NextHop 918 and IPv4UcastLPM can work normally so that route entry can be added 919 to FE.Second,RedirectIn and RedirectOut LFB MUST work,only that can 920 FE redirect out OSPF hello and LSA packets to CE received from 921 smartBits,FE redirect in OSPF hello and LSA packets to smartBits 922 received from CE's OSPF process. 924 During the test, results as shown in the following figure are 925 recorded. 927 +----+----+-----+----------------+-----------+--------+-------------+ 928 |Test| CE |FE(s)| Item | LFB | Result | Comment | 929 |# | | | | | | | 930 +----+----+-----+----------------+-----------+--------+-------------+ 931 | 1 | J | C |IPv4NextHopTable|IPv4NextHop|success | Muticast | 932 | | | | SET | | | route is | 933 | | | | | | | added by | 934 | 2 | J | C |IPv4PrefixTable | IPv4Ucast |success |manual,this | 935 | | | | SET | LPM | |problem still| 936 | | | | | | |need to be | 937 | | | |Redirect ospf | | |fixed in the | 938 | 3 | J | C |packet from CE |RedirectIn |failure | future. | 939 | | | |to SmartBits | | | | 940 | | | | | | | As for | 941 | | | |Redirect ospf | | | redirect | 942 | 4 | J | C |packet from |RedirectOut|success | message, | 943 | | | |SmartBits to CE | | |ospf hello | 944 | | | | | | |packet in 2 | 945 | | | |Metadata in |RedirectOut| |direction can| 946 | 5 | J | C |redirect message|RedirectIn |success |be wathed by | 947 | | | | | | | wireshark. | 948 | | | | | | |however ospf | 949 | | | |OSPF neiborhood |RedirectOut| | packet | 950 | 6 | J | C | discovery |RedirectIn |failure |received from| 951 | | | | | | |CE have an | 952 | | | | |RedirectOut| |error with | 953 | | | | OSPF LSA |RedirectIn | |checksum,so | 954 | 6 | J | C | exchange |IPv4NextHop|TBD |smartBits | 955 | | | | | IPv4Ucast | |will drop it | 956 | | | | | LPM | |with no | 957 | | | | | | |neighborhood | 958 | | | | | | |discovered. | 959 +----+----+-----+----------------+-----------+--------+-------------+ 961 6. Discussions 963 6.1. On Data Encapsulation Format 965 In the first day of the test, it was found that the LFB inter- 966 operations about tables all failed. The reason is found to be the 967 different ForCES protocol data encapsulation method among different 968 implementations. The encapsulation issues are detailed as below: 970 1. On response of PATH-DATA format When a CE sends a config/query 971 ForCES protocol message to an FE with a different implementor, the CE 972 is probable to receive response from the FE with different PATH-DATA 973 encaplation format. For example, if a CE sends a query message with 974 a path (1.1.1) to a third party FE, the FE is probable to generate 975 response with two different PATH-DATA encaplation format: the value 976 with FULL/SPARSE-DATA, and the format of many parallel PATHDATA TLV 977 and nested PATHDATA TLV, as below: 979 format 1: 980 GET-RESPONSE: 981 PATH DATA (id:1.2) 982 FULL DATA(a,b) 984 format 2: 985 GET-RESPONSE: 986 PATH DATA 987 PATH DATA 988 FULL DATA 989 PATH DATA 990 FULL DATA 991 ...... 993 The interoperability test shows that an ForCES element (CE or FE) 994 sender is free to choose whatever data structure that IETF ForCES 995 documents define and best suits the element, while an ForCES element 996 (CE or FE) MUST be prepared to accept and process information 997 (requests and responses) that use any legitimate structure defined by 998 IETF ForCES documents. 1000 2. On operation to array 1002 An array operation may also have several different data encaplation 1003 formats. For example, a component of array with two elements (a and 1004 b) in one entry, CE may encapsulate a SET message in two format: 1006 format 1: 1007 SET: 1008 PATH DATA (id:1.2) 1009 FULL DATA(a,b) 1010 format 2: 1011 SET: 1012 PATH DATA 1013 PATH DATA (id:1) 1014 FULL DATA (a) 1015 PATH DATA (id:2) 1016 FULL DATA (b) 1018 Via the interoperability test experience, this document recommends 1019 that format 1 be used for all array data format encapsulations. It 1020 is purely because format 1 can achieve the best efficiency. 1022 6.2. On ... 1024 TBD 1026 7. Contributors 1028 Contributors who have made major contributions to the 1029 interoperability test are as below: 1031 Hirofumi Yamazaki 1032 NTT Corporation 1033 Tokyo 1034 Japan 1035 Email: yamazaki.horofumi@lab.ntt.co.jp 1037 Rong Jin 1038 Zhejiang Gongshang University 1039 Hangzhou 1040 P.R.China 1041 Email: jinrong@zjgsu.edu.cn 1043 Yuta Watanabe 1044 NTT Corporation 1045 Tokyo 1046 Japan 1047 Email: yuta.watanabe@ntt-at.co.jp 1049 Xiaochun Wu 1050 Zhejiang Gongshang University 1051 Hangzhou 1052 P.R.China 1053 Email: spring-403@zjgsu.edu.cn 1055 8. Acknowledgements 1057 The authors would also like thank the following test participants: 1059 Chuanhuang Li, Hangzhou BAUD Networks 1060 Ligang Dong, Zhejiang Gongshang University 1061 Jingjing Zhou, Zhejiang Gongshang Unviersity 1062 Liaoyuan Ke, Hangzhou BAUD Networks 1063 Kelei Jin,Hangzhou BAUD Networks 1065 9. IANA Considerations 1067 (TBD) 1069 10. Security Considerations 1071 TBD 1073 11. References 1075 11.1. Normative References 1077 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 1078 of IP Control and Forwarding", RFC 3654, November 2003. 1080 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 1081 "Forwarding and Control Element Separation (ForCES) 1082 Framework", RFC 3746, April 2004. 1084 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 1085 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 1086 Control Element Separation (ForCES) Protocol 1087 Specification", RFC 5810, March 2010. 1089 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 1090 Layer (TML) for the Forwarding and Control Element 1091 Separation (ForCES) Protocol", RFC 5811, March 2010. 1093 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 1094 Element Separation (ForCES) Forwarding Element Model", 1095 RFC 5812, March 2010. 1097 [RFC5813] Haas, R., "Forwarding and Control Element Separation 1098 (ForCES) MIB", RFC 5813, March 2010. 1100 [RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim, 1101 "Implementation Report for Forwarding and Control Element 1102 Separation (ForCES)", RFC 6053, November 2010. 1104 11.2. Informative References 1106 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1107 June 1999. 1109 Authors' Addresses 1111 Weiming Wang 1112 Zhejiang Gongshang University 1113 18 Xuezheng Str., Xiasha University Town 1114 Hangzhou, 310018 1115 P.R.China 1117 Phone: +86-571-28877721 1118 Email: wmwang@zjgsu.edu.cn 1120 Kentaro Ogawa 1121 NTT Corporation 1122 Tokyo, 1123 Japan 1125 Email: ogawa.kentaro@lab.ntt.co.jp 1127 Evangelos Haleplidis 1128 University of Patras 1129 Patras, 1130 Greece 1132 Email: ehalep@ece.upatras.gr 1134 Ming Gao 1135 Hangzhou BAUD Networks 1136 408 Wen-San Road 1137 Hangzhou, 310012 1138 P.R.China 1140 Phone: +86-571-28877751 1141 Email: gmyyqno1@pop.zjgsu.edu.cn 1143 Jamal Hadi Salim 1144 Mojatatu Networks 1145 Ottawa 1146 Canada 1148 Email: hadi@mojatatu.com