idnits 2.17.1 draft-ietf-forces-interop-02.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 2 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 -- The document date (July 11, 2011) is 4671 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 154, but not defined == Missing Reference: 'FORCES-LFBLIB' is mentioned on line 391, but not defined == Missing Reference: 'RFC2404' is mentioned on line 436, but not defined == Missing Reference: 'ForCES-CEHA' is mentioned on line 441, but not defined == Missing Reference: 'ForCES-LFBLIB' is mentioned on line 514, but not defined == Unused Reference: 'RFC5813' is defined on line 1207, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 1230, but no explicit reference was found in the text == Unused Reference: 'RFC3654' is defined on line 1233, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-forces-ceha-01 == Outdated reference: A later version (-12) exists of draft-ietf-forces-lfb-lib-05 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 12 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: January 12, 2012 NTT Corporation 6 E. Haleplidis 7 University of Patras 8 M. Gao 9 Hangzhou BAUD Networks 10 J. Hadi Salim 11 Mojatatu Networks 12 July 11, 2011 14 Interoperability Report for Forwarding and Control Element Separation 15 (ForCES) 16 draft-ietf-forces-interop-02 18 Abstract 20 This document captures test results from the second Forwarding and 21 control Element Separation (ForCES) interoperability test which took 22 place on February 24-25, 2011 in the Internet Technology Lab (ITL) of 23 Zhejiang Gongshang University, 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 January 12, 2012. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. ForCES FE Model . . . . . . . . . . . . . . . . . . . . . 3 62 1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 3 63 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 64 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 65 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.1. Date, Location, and Participants . . . . . . . . . . . . . 7 68 3.2. Testbed Configuration . . . . . . . . . . . . . . . . . . 7 69 3.2.1. Participants Access . . . . . . . . . . . . . . . . . 7 70 3.2.2. Testbed Configuration . . . . . . . . . . . . . . . . 8 71 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . . 11 73 4.2. Scenario 2 - TML with IPSec . . . . . . . . . . . . . . . 11 74 4.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 12 75 4.4. Scenario 4 - Packet forwarding . . . . . . . . . . . . . . 14 76 5. Test Results . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 5.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . . 17 78 5.2. TML with IPSec Test . . . . . . . . . . . . . . . . . . . 22 79 5.3. CE High Availability Test . . . . . . . . . . . . . . . . 23 80 5.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . . 24 81 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 6.1. On Data Encapsulation Format . . . . . . . . . . . . . . . 27 83 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 92 1. Introduction 94 This document captures the results of the second interoperability 95 test of the Forwarding and control Element Separation (ForCES) 96 Framework which took place February 24-25, 2011 in the Internet 97 Technology Lab (ITL) of Zhejiang Gongshang University, China. The 98 test involved several documents namely: ForCES protocol [RFC5810], 99 ForCES FE model [RFC5812], ForCES TML [RFC5811], ForCES LFB Library 100 [I-D.ietf-forces-lfb-lib] and ForCES CE HA specification 101 [I-D.ietf-forces-ceha] Three independent ForCES implementations 102 participated in the test. 104 Scenarios of ForCES LFB Operation, TML with IPSec, CE High 105 Availability, and Packet Forwarding are constructed. Series of 106 testing items for every scenario are carried out and interoperability 107 results are achieved. Extended Wireshark and extended tcpdump are 108 used to verify the results. 110 The first interoperability test on ForCES was held in July 2008 at 111 the University of Patras, Greece. The test focussed on validating 112 the basic semantics of the ForCES protocol and ForCES FE model. The 113 test results were captured by RFC 6053[RFC6053]. 115 1.1. ForCES Protocol 117 The ForCES protocol works in a master-slave mode in which FEs are 118 slaves and CEs are masters. The protocol includes commands for 119 transport of Logical Function Block (LFB) configuration information, 120 association setup, status, and event notifications, etc. The reader 121 is encouraged to read the ForCES protocol specification RFC 5810 122 [RFC5810] for further information. 124 1.2. ForCES FE Model 126 The ForCES FE modelRFC 5812 [RFC5812] presents a formal way to define 127 FE Logical Function Blocks (LFBs) using XML. LFB configuration 128 components, capabilities, and associated events are defined when the 129 LFB is formally created. The LFBs within the FE are accordingly 130 controlled in a standardized way by the ForCES protocol. 132 1.3. Transport Mapping Layer 134 The ForCES Transport Mapping Layer (TML) transports the ForCES 135 Protocol Layer (PL) messages. The TML is where the issues of how to 136 achieve transport level reliability, congestion control, multicast, 137 ordering, etc are handled. It is expected that more than one TML 138 will be standardized. The various possible TMLs could vary their 139 implementations based on the capabilities of underlying media and 140 transport. However, since each TML is standardized, interoperability 141 is guaranteed as long as both endpoints support the same TML. All 142 ForCES Protocol Layer implementations MUST be portable across all 143 TMLs. Although more than one TML may be standardized for the ForCES 144 Protocol, for the purposes of the interoperability test, the mandated 145 MUST IMPLEMENT SCTP TML [RFC5811] will be used. 147 2. Terminology and Conventions 149 2.1. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 2.2. Definitions 157 This document follows the terminology defined by ForCES related 158 documents, including RFC3654, RFC3746, RFC5810, RFC5811, RFC5812, 159 RFC5813, etc. Some definitions are repeated below for clarity. 161 Control Element (CE) - A logical entity that implements the ForCES 162 protocol and uses it to instruct one or more FEs on how to process 163 packets. CEs handle functionality such as the execution of 164 control and signaling protocols. 166 Forwarding Element (FE) - A logical entity that implements the 167 ForCES protocol. FEs use the underlying hardware to provide per- 168 packet processing and handling as directed/controlled by one or 169 more CEs via the ForCES protocol. 171 LFB (Logical Functional Block) - The basic building block that is 172 operated on by the ForCES protocol. The LFB is a well defined, 173 logically separable functional block that resides in an FE and is 174 controlled by the CE via the ForCES protocol. The LFB may reside 175 at the FE's datapath and process packets or may be purely an FE 176 control or configuration entity that is operated on by the CE. 177 Note that the LFB is a functionally accurate abstraction of the 178 FE's processing capabilities, but not a hardware-accurate 179 representation of the FE implementation. 181 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. 182 An LFB Instance represents an LFB Class (or Type) existence. 183 There may be multiple instances of the same LFB Class (or Type) in 184 an FE. An LFB Class is represented by an LFB Class ID, and an LFB 185 Instance is represented by an LFB Instance ID. As a result, an 186 LFB Class ID associated with an LFB Instance ID uniquely specifies 187 an LFB existence. 189 LFB Metadata - Metadata is used to communicate per-packet state 190 from one LFB to another, but is not sent across the network. The 191 FE model defines how such metadata is identified, produced, and 192 consumed by the LFBs. It defines the functionality but not how 193 metadata is encoded within an implementation. 195 LFB Components - Operational parameters of the LFBs that must be 196 visible to the CEs are conceptualized in the FE model as the LFB 197 components. The LFB components include, for example, flags, 198 single-parameter arguments, complex arguments, and tables that the 199 CE can read and/or write via the ForCES protocol. 201 ForCES Protocol - While there may be multiple protocols used 202 within the overall ForCES architecture, the term "ForCES protocol" 203 and "protocol" refer to the "Fp" reference points in the ForCES 204 framework in [RFC3746]. This protocol does not apply to CE-to-CE 205 communication, FE-to-FE communication, or to communication between 206 FE and CE managers. Basically, the ForCES protocol works in a 207 master-slave mode in which FEs are slaves and CEs are masters. 209 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 210 ForCES protocol architecture that uses the capabilities of 211 existing transport protocols to specifically address protocol 212 message transportation issues, such as how the protocol messages 213 are mapped to different transport media (like TCP, IP, ATM, 214 Ethernet, etc.), and how to achieve and implement reliability, 215 multicast, ordering, etc. The ForCES TML specifications are 216 detailed in separate ForCES documents, one for each TML. 218 3. Overview 220 3.1. Date, Location, and Participants 222 The second ForCES interoperability test meeting was held by IETF 223 ForCES Working Group on February 24-25, 2011, and was chaired by 224 Jamal Hadi Salim, the current ForCES Working Group co-chair. Three 225 independent ForCES implementations participated in the test: 227 * Zhejiang Gongshang University/Hangzhou BAUD Corparation of 228 Inforamtion and Networks Technology (Hangzhou BAUD Networks), China. 229 This implementation is referred to as "China" or in some cases "C" in 230 the document for the sake of brevity. 231 * NTT Corporation, Japan. This implementation is referred to as 232 "Japan" or in some cases "J" in the document for the sake of brevity. 233 * The University of Patras, Greece. This implementation is referred 234 to as "Greece" or in some cases "G" in the document for the sake of 235 brevity. 237 Two other organizations, Mojatatu Networks and Hangzhou BAUD Networks 238 Corporation, which independently extended two different well known 239 public domain protocol analyzers, Ethereal/Wireshark [Ethereal] and 240 Tcpdump [Tcpdump], also participated in the interop test. During the 241 interoperability test, the two protocol analyzers were used to verify 242 the validity of ForCES protocol messages and in some cases semantics. 244 Some issues related to interoperability among implementations were 245 discovered. Most of the issues were solved on site during the test. 246 The most contentious issue found was on the format of encapsulation 247 for protocol TLV (Refer to Section 6.1). 249 Some errata related to ForCES document were found by the 250 interoperability test. The errata has been reported to related IETF 251 RFCs. 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. Participants 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 as the monitoring tool. The approach is as shown in 268 Figure 1. In the figure, FE/CE refers to FE or CE that the 269 implementor may act alternatively. 271 +---------+ +----+ +----------+ 272 | FE/CE | | | +---|Monitoring| 273 | China |-----| | /\/\/\/\/\ | |(TeamViewer) 274 +---------+ | | \Internet/ | | Canada | 275 |LAN |----/ \--| +----------+ 276 +---------+ | | \/\/\/\/\/ | +----------+ 277 | FE/CE |-----| | | | FE/CE | 278 | Japan | | | +---| Greece | 279 +---------+ +----+ +----------+ 281 Figure 1: Access for Participants 283 All CEs and FEs SHALL implement IPSec security in the TML. For 284 security, firewalls MUST be used that will allow only the specific 285 IPs and the SCTP ports defined in the ForCES SCTP-TML [RFC5811]. 287 3.2.2. Testbed Configuration 289 Hardwares and softwares including CEs and FEs from China and Japan 290 implementions that were located within the ITL Lab of Zhejiang 291 Gongshang University, were connected together using Ethernet 292 switches. The configuration can be seen in Figure 2. In the figure, 293 the SmartBits is a third-party supplied routing protocol testing 294 machine, which acts as a router running OSPF and RIP and exchanges 295 routing protocol messages with ForCES routers in the network. The 296 Internet is connected via an ADSL channel. 298 /\/\/\/\/\ 299 \Internet/ 300 / \ 301 \/\/\/\/\/ 302 | 303 |124.90.146.218 (ADSL) 304 | 305 +------------------------------------------------------------------+ 306 | LAN (10.20.0.0/24) | 307 +------------------------------------------------------------------+ 308 | | | | | | 309 | | | | | | 310 |.222 |.230 |.221 |.179 |.231 |.220 311 +-----+ +-----+ +-----+ +-----+ +-----+ +---------+ 312 | CE | | CE | | | | | | | | Protocol| 313 |China| |Japan| | FE1 |.1 .2| FE |.1 .2| FE2 | | Analyzer| 314 +-----+ +-----+ |China|---------|Japan|----------|China| +---------+ 315 +---------| |192.169. | | 192.168. | |-------+ 316 | .2 +-----+ 20.0.24 +-----+ 30.0/24 +-----+ .2 | 317 | .12| |.12 | 318 | | | | 319 192.168.50.0/24 | | 192.168.60.0/24 320 | 192.168.10.0/24 192.168.40.0/24 | 321 .1 | |.11 |.11 |.1 322 +--------+ +---------------------------------------+ +--------+ 323 |Terminal| | Smartbits | |Terminal| 324 +--------+ +---------------------------------------+ +--------+ 326 Figure 2: Testbed Configuration Located in ITL Lab,China 328 Hardwares and Softwares (CE and FE) of Greece that were located 329 within the University of Patras, Greece, were connected together 330 using LAN as shown in Figure 3. The Internet is connected via a VPN 331 channel. 333 /\/\/\/\/\ 334 \Internet/ 335 / \ 336 \/\/\/\/\/ 337 | 338 |150.140.254.110(VPN) 339 | 340 +------------------------------------+ 341 | LAN | 342 +------------------------------------+ 343 | | | 344 | | | 345 +------+ +--------+ +------+ 346 | FE | |Protocol| | CE | 347 |Greece| |Analyzer| |Greece| 348 +------+ +--------+ +------+ 350 Figure 3: Testbed Configuration Located in the University of 351 Patras,Greece 353 Above Testbed configuations can satisfy requirements of all the 354 interoperability test scenarios that are mentioned in this document. 356 4. Scenarios 358 4.1. Scenario 1 - LFB Operation 360 This scenario is to test the interoperability on LFB operations among 361 the participants. The connection diagram for the participants is as 362 shown in Figure 4. 364 +------+ +------+ +------+ +------+ +------+ +------+ 365 | CE | | CE | | CE | | CE | | CE | | CE | 366 | China| | Japan| | China| |Greece| | Japan| |Greece| 367 +------+ +------+ +------+ +------+ +------+ +------+ 368 | | | | | | 369 | | | | | | 370 +------+ +------+ +------+ +------+ +------+ +------+ 371 | FE | | FE | | FE | | FE | | FE | | FE | 372 |Japan | |China | |Greece| |China | |Greece| |Japan | 373 +------+ +------+ +------+ +------+ +------+ +------+ 375 Figure 4: Scenario for LFB Operation 377 In order to make interoperability more credible,the three 378 implementors carried out the test in an alternative way acting as a 379 CE or an FE. As a result, every operation should be tested with 6 380 combinations all three participants, as shown in Figure 4. 382 The test scenario is designed with the following purposes: 384 Firstly, the scenario is designed to verify all kinds of protocol 385 messages with their complex data formats, which are defined in RFC 386 5810. Specially, we try to verify the data format of a PATH-DATA 387 with nested PATH-DATAs, and the operation(SET, GET, DEL) of an array 388 or an array with a nested array. 390 Second,the scenario is designed to verify the definition of ForCES 391 LFB Library[FORCES-LFBLIB], which defines a base set of ForCES LFB 392 classes for typical router functions. Successful test under this 393 scenario also means the validity of the LFB definitions. 395 4.2. Scenario 2 - TML with IPSec 397 This scenario is designed to implement a TML with IPSec, which is the 398 requirement by RFC 5811. TML with IPSec was not implemented in the 399 first ForCES interoperability test as reported by RFC 6053. For this 400 reason, in the second interoperability test, we specificially 401 designed the test scenario to verify the TML over IPSec channel. 403 In this scenario, tests on LFB operations for Scenario 1 were just 404 repeated only with the difference that the IPSec TML was adopted. In 405 this way, we try to verify whether all interactions between CE and FE 406 can be made correctly under an IPSec TML enviroment. 408 The connection diagram for this scenario is shown as Figure 5. 409 Because of system difficulty to deploy IPSec over TML in Greece, the 410 text only took place between China and Japan. 412 +------+ +------+ 413 | CE | | CE | 414 | China| | Japan| 415 +------+ +------+ 416 | | 417 |TML over IPSec |TML over IPSec 418 +------+ +------+ 419 | FE | | FE | 420 |Japan | |China | 421 +------+ +------+ 423 Figure 5: Scenario for LFB Operation with TML over IPSec 425 In this scenario, ForCES TML was run over IPSec channel. 426 Implementors joined in this interoperability have used the same 427 third-party software 'racoon' to have established the IPSec channel. 429 China and Japan have made a successful test with the scenario, and 430 the following items have been realized: 432 o Internet Key Exchange (IKE) with certificates for endpoint 433 authentication. 435 o Transport Mode Encapsulating Security Payload (ESP). HMAC-SHA1-96 436 [RFC2404] for message integrity protection. 438 4.3. Scenario 3 - CE High Availability 440 CE High Availability (CEHA) was also tested in this interoperability 441 test based on the ForCES CEHA document [ForCES-CEHA]. 443 The design of the setup and the scenario for the CEHA are as simple 444 as possible to focus mostly on the mechanics of the CEHA, which are: 446 o Associating with more than one CEs. 448 o Switching to backup CE on master CE fail. 450 The connection diagram for the scenario is as shown in Figure 6. 452 master standby master standby 453 +------+ +------+ +------+ +------+ 454 | CE | | CE | | CE | | CE | 455 | China| |Greece| |Japan | |Greece| 456 +------+ +------+ +------+ +------+ 457 | | | | 458 +----------+ +-----------+ 459 | | 460 +------+ +------+ 461 | FE | | FE | 462 |Greece| |Greece| 463 +------+ +------+ 464 (a) (b) 466 Figure 6: Scenario for CE High Availability 468 In this scenario one FE would be connected and associated with a 469 master CE and a backup CE. In the pre-association phase, the FE 470 would be configured to have China's or Japan's CE as master CE and 471 Greece's CE as standby CE. The CEFailoverPolicy component of the FE 472 Protocol Object LFB that specifies whether the FE is in High 473 Availability mode (value 2 or 3) would either be set in the pre- 474 association phase or in post-association phase by the master CE. 476 Once the FE is associated with the master CE it will move to the 477 post-association phase. Then when the CEFailoverPolicy value is set 478 to 2 or 3, then it will then attempt to connect and associate with 479 the standby CE. 481 When the master CE is considered disconnected, either by TearDown, 482 Loss of Heartbeats or Disconnected, FE would assume that the standby 483 CE is now the master CE. FE will then send an Event Notification, 484 Primary CE Down,to all associated CEs, only the standby CE in this 485 case with the value of the new master CEID. The standby CE will then 486 respond by setting with a configuration message the CEID of the FE 487 Protocol Object with it's own ID, the same value, to confirm that the 488 CE considers itself as the master as well. 490 The steps of the CEHA scenario were the following: 492 1. In the pre-association phase, setup of FE with master CE and 493 backup CE 495 2. FE connecting and associating with master CE. 497 3. When CEFailoverPolicy is set to 2 or 3, the FE will connect and 498 associate with backup CE. 500 4. Once the master CE is considered disconnected then the FE chooses 501 the first Associated backup CE. 503 5. It sends an Event Notification specifying that the master CE is 504 down and who is now the master CE. 506 6. The new master CE sends a SET Configuration message to the FE 507 setting the CEID value to who is now the new master CE completing 508 the switch. 510 4.4. Scenario 4 - Packet forwarding 512 This test scenario is to verify LFBs like RedirectIn, RedirectOut, 513 IPv4NextHop, IPv4UcastLPM defined by the ForCES LFB library 514 document[ForCES-LFBLIB], and more importantly, to verify the 515 combination of the LFBs to implement IP packet forwarding. 517 The connection diagram for this scenario is as Figure 7. 519 +------+ 520 | CE | 521 | Japan| 522 +------+ 523 | ^ 524 | | OSPF 525 | +-------> 526 +------+ +------+ 527 +--------+ | FE | | OSPF | +--------+ 528 |Terminal|------|China |-------|Router|------|Terminal| 529 +--------+ +------+ +------+ +--------+ 531 <--------------------------------------------> 532 Packet Forwarding 534 (a) 536 +------+ 537 | CE | 538 | China| 539 +------+ 540 ^ | ^ 541 OSPF | | | OSPF 542 <-----+ | +-----> 543 +-------+ +------+ +------+ 544 +--------+ | OSPF | | FE | | OSPF | +--------+ 545 |Terminal|----|Router |----|Japan |-----|Router|----|Terminal| 546 +--------+ +-------+ +------+ +------+ +--------+ 547 <--------------------------------------------> 548 Packet Forwarding 550 (b) 552 +------+ +------+ 553 | CE | | CE | 554 | Japan| | China| 555 +------+ +------+ 556 | ^ ^ | 557 | | OSPF | | 558 | +----------+ | 559 +------+ +------+ 560 +--------+ | FE | | FE | +--------+ 561 |Terminal|------|China |-------|Japan |------|Terminal| 562 +--------+ +------+ +------+ +--------+ 564 <--------------------------------------------> 565 Packet Forwarding 567 (c) 569 Figure 7: Scenario for IP Packet forwarding 571 In case (a), a CE by Japan is connected to an FE by China to form a 572 ForCES router. A Smartbits test machine with its routing protocol 573 software are used to simulate an OSPF router and are connected with 574 the ForCES router to try to exchange OSPF hello packets and LSA 575 packets among them. Terminals are simulated by Smartbits to send and 576 receive packets. As a result, the CE in the ForCES router need to be 577 configured to run and support OSPF routing protocol. 579 In case (b), a CE by China is connected to an FE by Japan to form a 580 ForCES router. Two routers running OSPF are simulated and coneected 581 to the ForCES router to test if the ForCES router can support OSPF 582 protocol and support packet forwarding. 584 In case (c), two ForCES rotuers are constructed. One is with CE by 585 Japan and FE by China and the other is opposite. OSPF and packet 586 forwarding are tested in the enviroment. 588 Testing proccess for this scenario is as below: 590 1. Boot terminals and routers, and set IP addresses of their 591 interfaces. 593 2. Boot CE and FE. 595 3. Establish association between CE and FE, and set IP addresses of 596 FE__s interfaces. 598 4. Start OSPF among CE and routers, and set FIB on FE. 600 5. Send packets between terminals. 602 5. Test Results 604 5.1. LFB Operation Test 606 The test result is as reported by Figure 8. For the convinience 607 sake, as mentioned earlier, abbreviations of 'C' in the table means 608 implementation from China,'J'Japan implementaion, and 'G' Greece 609 implemenation. 611 +-----+----+-----+-----+--------------+-------------------+---------+ 612 |Test#| CE |FE(s)|Oper | LFB | Component | Result | 613 | | | | | | /Capability | | 614 +-----+----+-----+-----+--------------+-------------------+---------+ 615 | 1 | C | J | | | | Success | 616 | | J | C | | | | Success | 617 | | G | C | GET | FEObject | LFBTopology | Success | 618 | | J | G | | | | Success | 619 | | G | J | | | | Success | 620 | | | | | | | | 621 | 2 | C | J | | | | Success | 622 | | J | C | | | | Success | 623 | | C | G | | | | Success | 624 | | G | C | GET | FEObject | LFBSelector | Success | 625 | | J | G | | | | Success | 626 | | G | J | | | | Success | 627 | | | | | | | | 628 | 3 | C | J | | | | Success | 629 | | J | C | | | | Success | 630 | | C | G | | | | Success | 631 | | G | C | GET | EtherPHYCop | PHYPortID | Success | 632 | | J | G | | | | Success | 633 | | G | J | | | | Success | 634 | | | | | | | | 635 | 4 | C | J | | | | Success | 636 | | J | C | | | | Success | 637 | | C | G | | | | Success | 638 | | G | C | GET | EtherPHYCop | AdminStatus | Success | 639 | | J | G | | | | Success | 640 | | G | J | | | | Success | 641 | | | | | | | | 642 | 5 | C | J | | | | Success | 643 | | J | C | | | | Success | 644 | | C | G | | | | Success | 645 | | G | C | GET | EtherPHYCop | OperStatus | Success | 646 | | J | G | | | | Success | 647 | | G | J | | | | Success | 648 | | | | | | | | 649 | 6 | C | J | | | | Success | 650 | | J | C | | | | Success | 651 | | C | G | | | | Success | 652 | | G | C | GET | EtherPHYCop | AdminLinkSpeed | Success | 653 | | J | G | | | | Success | 654 | | G | J | | | | Success | 655 | | | | | | | | 656 | 7 | C | J | | | | Success | 657 | | J | C | | | | Success | 658 | | C | G | | | | Success | 659 | | G | C | GET | EtherPHYCop | OperLinkSpeed | Success | 660 | | J | G | | | | Success | 661 | | G | J | | | | Success | 662 | | | | | | | | 663 | 8 | C | J | | | | Success | 664 | | J | C | | | | Success | 665 | | C | G | | | | Success | 666 | | G | C | GET | EtherPHYCop | AdminDuplexSpeed | Success | 667 | | J | G | | | | Success | 668 | | G | J | | | | Success | 669 | | | | | | | | 670 | 9 | C | J | | | | Success | 671 | | J | C | | | | Success | 672 | | C | G | | | | Success | 673 | | G | C | GET | EtherPHYCop | OperDuplexSpeed | Success | 674 | | J | G | | | | Success | 675 | | G | J | | | | Success | 676 | | | | | | | | 677 | 10 | C | J | | | | Success | 678 | | J | C | | | | Success | 679 | | C | G | | | | Success | 680 | | G | C | GET | EtherPHYCop | CarrierStatus | Success | 681 | | J | G | | | | Success | 682 | | G | J | | | | Success | 683 | | | | | | | | 684 | 11 | C | J | | | | Success | 685 | | J | C | | | | Success | 686 | | C | G | | | | Success | 687 | | G | C | GET | EtherMACIn | AdminStatus | Success | 688 | | J | G | | | | Success | 689 | | G | J | | | | Success | 690 | | | | | | | | 691 | 12 | C | J | | | | Success | 692 | | J | C | | | | Success | 693 | | C | G | | | | Success | 694 | | G | C | GET | EtherMACIn | LocalMacAddresses | Success | 695 | | J | G | | | | Success | 696 | | G | J | | | | Success | 697 | | | | | | | | 698 | 13 | C | J | | | | Success | 699 | | J | C | | | | Success | 700 | | C | G | | | | Success | 701 | | G | C | GET | EtherMACIn | L2Bridging | Success | 702 | | J | G | | | PathEnable | Success | 703 | | G | J | | | | Success | 704 | | | | | | | | 705 | 14 | C | J | | | | Success | 706 | | J | C | | | | Success | 707 | | C | G | | | | Success | 708 | | G | C | GET | EtherMACIn | PromiscuousMode | Success | 709 | | J | G | | | | Success | 710 | | G | J | | | | Success | 711 | | | | | | | | 712 | 15 | C | J | | | | Success | 713 | | J | C | | | | Success | 714 | | C | G | | | | Success | 715 | | G | C | GET | EtherMACIn | TxFlowControl | Success | 716 | | J | G | | | | Success | 717 | | G | J | | | | Success | 718 | | | | | | | | 719 | 16 | C | J | | | | Success | 720 | | J | C | | | | Success | 721 | | C | G | | | | Success | 722 | | G | C | GET | EtherMACIn | RxFlowControl | Success | 723 | | J | G | | | | Success | 724 | | G | J | | | | Success | 725 | | | | | | | | 726 | 17 | C | J | | | | Success | 727 | | J | C | | | | Success | 728 | | C | G | | | | Success | 729 | | G | C | GET | EtherMACIn | MACInStats | Success | 730 | | J | G | | | | Success | 731 | | G | J | | | | Success | 732 | | | | | | | | 733 | 18 | C | J | | | | Success | 734 | | J | C | | | | Success | 735 | | C | G | | | | Success | 736 | | G | C | GET | EtherMACOut | AdminStatus | Success | 737 | | J | G | | | | Success | 738 | | G | J | | | | Success | 739 | | | | | | | | 740 | 19 | C | J | | | | Success | 741 | | J | C | | | | Success | 742 | | C | G | | | | Success | 743 | | G | C | GET | EtherMACOut | MTU | Success | 744 | | J | G | | | | Success | 745 | | G | J | | | | Success | 746 | | | | | | | | 747 | 20 | C | J | | | | Success | 748 | | J | C | | | | Success | 749 | | C | G | | | | Success | 750 | | G | C | GET | EtherMACOut | TxFlowControl | Success | 751 | | J | G | | | | Success | 752 | | G | J | | | | Success | 753 | | | | | | | | 754 | 21 | C | J | | | | Success | 755 | | J | C | | | | Success | 756 | | C | G | | | | Success | 757 | | G | C | GET | EtherMACOut | TxFlowControl | Success | 758 | | J | G | | | | Success | 759 | | G | J | | | | Success | 760 | | | | | | | | 761 | 22 | C | J | | | | Success | 762 | | J | C | | | | Success | 763 | | C | G | | | | Success | 764 | | G | C | GET | EtherMACOut | MACOutStats | Success | 765 | | J | G | | | | Success | 766 | | G | J | | | | Success | 767 | | | | | | | | 768 | 23 | C | J | | | | Success | 769 | | J | C | | | | Success | 770 | | C | G | | | | Success | 771 | | G | C | GET | ARP |PortV4AddrInfoTable| Success | 772 | | J | G | | | | Success | 773 | | G | J | | | | Success | 774 | | | | | | | | 775 | 24 | C | J | | | | Success | 776 | | J | C | | | | Success | 777 | | C | G | | | | Success | 778 | | G | C | SET | ARP |PortV4AddrInfoTable| Success | 779 | | J | G | | | | Success | 780 | | G | J | | | | Success | 781 | | | | | | | | 782 | 25 | C | J | | | | Success | 783 | | J | C | | | | Success | 784 | | C | G | | | | Success | 785 | | G | C | DEL | ARP |PortV4AddrInfoTable| Success | 786 | | J | G | | | | Success | 787 | | G | J | | | | Success | 788 | | | | | | | | 789 | 26 | C | J | | | | Success | 790 | | J | C | | | | Success | 791 | | C | G | | | | Success | 792 | | G | C | SET | EtherMACIn | LocalMACAddresses | Success | 793 | | J | G | | | | Success | 794 | | G | J | | | | Success | 795 | | | | | | | | 796 | 27 | C | J | | | | Success | 797 | | J | C | | | | Success | 798 | | C | G | | | | Success | 799 | | G | C | SET | EtherMACIn | MTU | Success | 800 | | J | G | | | | Success | 801 | | G | J | | | | Success | 802 | | | | | | | | 803 | 28 | C | J | | | | Success | 804 | | J | C | | | | Success | 805 | | C | G | | | | Success | 806 | | G | C | SET | IPv4NextHop | IPv4NextHopTable | Success | 807 | | J | G | | | | Success | 808 | | G | J | | | | Success | 809 | | | | | | | | 810 | 29 | C | J | | | | Success | 811 | | J | C | | | | Success | 812 | | C | G | | | | Success | 813 | | G | C | SET | IPv4UcastLPM | IPv4PrefixTable | Success | 814 | | J | G | | | | Success | 815 | | G | J | | | | Success | 816 | | | | | | | | 817 | 30 | C | J | | | | Success | 818 | | J | C | | | | Success | 819 | | C | G | | | | Success | 820 | | G | C | DEL | IPv4NextHop | IPv4NextHopTable | Success | 821 | | J | G | | | | Success | 822 | | G | J | | | | Success | 823 | | | | | | | | 824 | 31 | C | J | | | | Success | 825 | | J | C | | | | Success | 826 | | C | G | | | | Success | 827 | | G | C | DEL | IPv4UcastLPM | IPv4PrefixTable | Success | 828 | | J | G | | | | Success | 829 | | G | J | | | | Success | 830 | | | | | | | | 831 | 32 | C | J | | | | Success | 832 | | J | C | | | | Success | 833 | | C | G | | | | Success | 834 | | G | C | SET | EtherPHYCop | AdminStatus | Success | 835 | | J | G | | | | Success | 836 | | G | J | | | | Success | 837 | | | | | | | | 838 | 33 | C | J | | | | Success | 839 | | J | C | | | | Success | 840 | | C | G | | | | Success | 841 | | G | C | SET | Ether | VlanInputTable | Success | 842 | | J | G | | Classifier | | Success | 843 | | G | J | | | | Success | 844 | | | | | | | | 845 | 34 | C | J | | | | Success | 846 | | J | C | | | | Success | 847 | | C | G | | | | Success | 848 | | G | C | DEL | Ether | VlanInputTable | Success | 849 | | J | G | | Classifier | | Success | 850 | | G | J | | | | Success | 851 | | | | | | | | 852 | 35 | C | J | | | | Success | 853 | | J | C | | | | Success | 854 | | C | G | | | | Success | 855 | | G | C | SET | Ether | VlanOutputTable | Success | 856 | | J | G | | Encapsulator | | Success | 857 | | G | J | | | | Success | 858 | | | | | | | | 859 | 36 | C | J | | | | Success | 860 | | J | C | | | | Success | 861 | | C | G | | | | Success | 862 | | G | C | DEL | Ether | VlanOutputTable | Success | 863 | | J | G | | Encapsulator | | Success | 864 | | G | J | | | | Success | 865 +-----+----+-----+-----+--------------+-------------------+---------+ 867 Figure 8: LFB Operation Test Results 869 5.2. TML with IPSec Test 871 In this scenario, ForCES TML will run over IPSec channel. 872 Implementors joined this interoperability test use the same third- 873 party tool software 'racoon' to establish IPSec channel. Some 874 typical LFB operation tests as in Scenario 1 have been repeated with 875 the new security TML. 877 A note on this test is, because of the system difficulty to implement 878 IPSec over TML, Greece did not join in the test. Therefore, this 879 scenario only successfully took place between C and J. However, it is 880 still valid to make the interoperability test among two participants. 882 The TML with IPSec test results are reported by Figure 9. 884 +-----+----+-----+-----+--------------+-------------------+---------+ 885 |Test#| CE |FE(s)|Oper | LFB | Component/ | Result | 886 | | | | | | Capability | | 887 +-----+----+-----+-----+--------------+-------------------+---------+ 888 | 1 | C | J | GET | FEObject | LFBTopology | Success | 889 | | J | C | | | | Success | 890 | | | | | | | | 891 | 2 | C | J | GET | FEObject | LFBSelectors | Success | 892 | | J | C | | | | Success | 893 | | | | | | | | 894 | 3 | C | J | SET | Ether | VlanInputTable | Success | 895 | | J | C | | Classifier | | Success | 896 | | | | | | | | 897 | 4 | C | J | DEL | Ether | VlanInputTable | Success | 898 | | J | C | | Classifier | | Success | 899 +-----+----+-----+-----+--------------+-------------------+---------+ 901 Figure 9: TML with IPSec Test Results 903 5.3. CE High Availability Test 905 In this scenario one FE will connect and associate with a master CE 906 and a backup CE. When the master CE is considered disconnected the 907 FE would attempt to find another associated CE to become the master 908 CE. 910 The CEHA scenario as is described in Scenario 3 was completed 911 successfully for both setups. 913 Due to a bug in the FE, a possible issue was caught. The bug in the 914 FE introduced a delay in message handling of 1 second. The master CE 915 was sending Heartbeats at a rate of one in 500milliseconds (2 per 916 second). As heartbeats are of very low priority, the FE was working 917 fine with associated only with the master CE. However when the FE 918 attempted to associate with the backup CE the following issue 919 occured. 921 The FE was checking first for messages from all priorities from the 922 master CE and if the master CE hasn't sent any messages then it would 923 check the backup CE. So, when the FE was ordered to begin 924 associating with the backup CE , it sent the Association setup 925 message, the backup CE received it, responded back with an 926 Association Setup result, but the FE never processed managed to 927 process it. 929 While the bug was fixed and the CEHA scenario was completed 930 successfully, the issue still remains. This is actually an 931 implementation issue of how the FE prioritizes incoming messages from 932 multiple CEs. The recommended approach is the following: 934 o The FE SHOULD receive and handle messages first from the master CE 935 on all priority channels to maintain proper functionality and then 936 receive and handle messages from the backup CEs. 938 o Only when the FE is attempting to associate with the backup CEs, 939 then the FE SHOULD receive and handle messages per priority 940 channel from all CEs. When all backup CEs are associated with or 941 deemed unreachable, then the FE SHOULD return to receiving and 942 handling messages first from the master CE. 944 5.4. Packet Forwarding Test 946 As described in the ForCES LFB library [I-D.ietf-forces-lfb-lib], 947 packet forwarding is implemented by a set of LFB classes that compose 948 a processing path for packets. In this test scenario, as shown in 949 Figure 7, a ForCES router running OSPF protocol should be construted. 950 Moreover, a set of LFBs including RedirectIn, RedirectOut, 951 IPv4UcastLPM, and IPv4NextHop LFBs should be constructed and be 952 joined in a processing data path. RedirectIn and RedirectOut LFBs 953 redirect OSPF hello and LSA packets from and to CE. Smartbits test 954 machine is used to simulate an OSPF router and try to exchange the 955 OSPF hello packet and LSA packet with CE in ForCES router. 957 Cases (a) and (b) in Figure 7 both need a RedirectIn LFB to send OSPF 958 packets generated by CE to FE by use of ForCES packet redirect 959 messages. The OSPF packets are futher sent to an outside OSPF Router 960 by the FE via forwarding LFBs including IPv4NextHop and IPv4UcastLPM 961 LFBs. A RedirectOut LFB in FE is used to send OSPF packets received 962 from outside OSPF Router to CE by ForCES packet redirect messages. 964 By running OSPF protocol, CE in the ForCES router then can generate 965 new routes and load them to routing table in FE. FE is then able to 966 forward packets according to the routing table. 968 The test is reported with the results in Figure 10 970 +-----+----+-----+-------------------------+--------------+---------+ 971 |Test#| CE |FE(s)| Item | LFBs Related | Result | 972 +-----+----+-----+-------------------------+--------------+---------+ 973 | 1 | J | C | IPv4NextHopTable SET | IPv4NextHop | Success | 974 | | | | | | | 975 | 2 | J | C | IPv4PrefixTable SET | IPv4UcastLPM | Success | 976 | | | | | | | 977 | 3 | J | C |Redirect ospf packet from| RedirectIn | Success | 978 | | | | CE to SmartBits | | | 979 | | | | | | | 980 | 4 | J | C |Redirect ospf packet from| RedirectOut | Success | 981 | | | | SmartBits to CE | | | 982 | | | | | | | 983 | 5 | J | C | Metadata in | RedirectOut | Success | 984 | | | | redirect message | RedirectIn | | 985 | | | | | | | 986 | 6 | J | C |OSPF neiborhood discovery| RedirectOut | Success | 987 | | | | | RedirectIn | | 988 | | | | | | | 989 | 7 | J | C | OSPF DD exchange | RedirectOut | Success | 990 | | | | | RedirectIn | | 991 | | | | | IPv4NextHop | | 992 | | | | | | | 993 | 8 | J | C | OSPF LSA exchange | RedirectOut | Success | 994 | | | | | RedirectIn | | 995 | | | | | IPv4NextHop | | 996 | | | | | IPv4UcastLPM| | 997 | | | | | | | 998 | 9 | J | C | Data Forwarding | RedirectOut | | 999 | | | | | RedirectIn | Success | 1000 | | | | | IPv4NextHop | | 1001 | | | | | IPv4UcastLPM| | 1002 | | | | | | | 1003 | 10 | C | J | IPv4NextHopTable SET | IPv4NextHop | Success | 1004 | | | | | | | 1005 | 11 | C | J | IPv4PrefixTable SET | IPv4UcastLPM| Success | 1006 | | | | | | | 1007 | 12 | C | J |Redirect ospf packet from| RedirectIn | Success | 1008 | | | | CE to other OSPF router | | | 1009 | | | | | | | 1010 | 13 | C | J |Redirect ospf packet from| RedirectOut | Success | 1011 | | | |other OSPF router to CE | | | 1012 | | | | | | | 1013 | 14 | C | J | Metadata in | RedirectOut | Success | 1014 | | | | redirect message | RedirectIn | | 1015 | | | | | | | 1016 | 15 | C | J |OSPF neiborhood discovery| RedirectOut | Success | 1017 | | | | | RedirectIn | | 1018 | | | | | | | 1019 | | | | | RedirectOut | | 1020 | 16 | C | J | OSPF DD exchange | RedirectIn | Failure | 1021 | | | | | IPv4NextHop | | 1022 | | | | | | | 1023 | 17 | C | J | OSPF LSA exchange | RedirectOut | | 1024 | | | | | RedirectIn | Failure | 1025 | | | | | IPv4NextHop | | 1026 | | | | | IPv4UcastLPM| | 1027 +-----+----+-----+-------------------------+--------------+---------+ 1028 Figure 10: Packet Forwarding Test Results 1030 Comment on Test #16 and #17: 1032 The two test items failed. Note that Test #7 and #8 are exactly the 1033 same as these tests, only with CE and FE implementors are exchanged, 1034 and Test #12 and #13 show the redirect channel works well. As a 1035 result, it can be infered that the problem caused the test failure 1036 was almost certainly from the implementation of the related LFBs 1037 rather than from the ForCES protocol design problem, therefore the 1038 failure does not lead to the interoperability problem on ForCES. 1040 6. Discussions 1042 6.1. On Data Encapsulation Format 1044 In the first day of the test, it was found that the LFB inter- 1045 operations about tables all failed. The reason is found to be the 1046 different ForCES protocol data encapsulation method among different 1047 implementations. The encapsulation issues are detailed as below: 1049 Assuming that an LFB has two components, one a struct with ID 1 and 1050 an array with ID 2 with two components of u32 both per row. 1052 struct1: type struct, ID=1 1053 components are: 1054 a, type u32, ID=1 1055 b, type u32, ID=2 1057 table1: type array, ID=2 1058 components for each row are (a struct of): 1059 x, type u32, ID=1 1060 y, type u32, ID=2 1062 1. On response of PATH-DATA format 1064 When a CE sends a config/query ForCES protocol message to an FE from 1065 a different implementor, the CE probably receives response from the 1066 FE with different PATH-DATA encaplation format. For example, if a CE 1067 sends a query message with a path of 1 to a third party FE to 1068 manipulate struct 1 as defined above, the FE is probable to generate 1069 response with two different PATH-DATA encaplation format: one is the 1070 value with FULL/SPARSE-DATA and the other is the value with many 1071 parallel PATH-DATA TLV and nested PATH-DATA TLV, as below: 1073 format 1: 1074 OPER = GET-RESPONSE-TLV 1075 PATH-DATA-TLV: 1076 IDs=1 1077 FULLDATA-TLV containing valueof(a),valueof(b) 1078 format 2: 1079 OPER = GET-RESPONSS-TLV 1080 PATH-DATA-TLV: 1081 IDs=1 1082 PATH-DATA-TLV: 1083 IDs=1 1084 FULLDATA-TLV containing valueof(a) 1085 PATH-DATA-TLV: 1086 IDs=2 1087 FULLDATA-TLV containing valueof(b) 1089 The interoperability test shows that an ForCES element (CE or FE) 1090 sender is free to choose whatever data structure that IETF ForCES 1091 documents define and best suits the element, while an ForCES element 1092 (CE or FE) is preferable to accept and process information (requests 1093 and responses) that use any legitimate structure defined by IETF 1094 ForCES documents. While in the case an ForCES element is free to 1095 choose any legitimate data structure as a response, it is preferred 1096 the ForCES element responds in the same format that the request was 1097 made, as it is most probably the data structure is the request sender 1098 looks forward to receive. 1100 2. On operation to array 1102 An array operation may also have several different data encaplation 1103 formats. For instance, if a CE sends a config message to table 1 1104 with a path of (2.1), which refers to component with ID=2, which is 1105 an array, and the second ID is the row, so row 1, it may be 1106 encapsulated with three formats as below: 1108 format 1: 1109 OPER = SET-TLV 1110 PATH-DATA-TLV: 1111 IDs=2.1 1112 FULLDATA-TLV conaining valueof(x),valueof(y) 1113 format 2: 1114 OPER = SET-TLV 1115 PATH-DATA-TLV: 1116 IDs=2.1 1117 PATH-DATA-TLV: 1118 IDs=1 1119 FULLDATA-TLV containing valueof(x) 1120 PATH-DATA-TLV 1121 IDs=2 1122 FULLDATA-TLV containing valueof(y) 1124 Moreover, if CE is targeting the whole array, for example if the 1125 array is empty and CE wants to add the first row to the table, it 1126 could also adopt another format: 1128 format 3: 1129 OPER = SET-TLV 1130 PATH-DATA-TLV: 1131 IDs=2 1132 FULLDATA-TLV containing rowindex=1,valueof(x),valueof(y) 1134 The interoperability test experience shows that format 1 and format 1135 3, which take full advantage of multiple data elements description in 1136 one TLV of FULLDATA-TLV, get more efficiency, although format 2 can 1137 also get the same operating goal. 1139 7. Contributors 1141 Contributors who have made major contributions to the 1142 interoperability test are as below: 1144 Hirofumi Yamazaki 1145 NTT Corporation 1146 Tokyo 1147 Japan 1148 Email: yamazaki.horofumi@lab.ntt.co.jp 1150 Rong Jin 1151 Zhejiang Gongshang University 1152 Hangzhou 1153 P.R.China 1154 Email: jinrong@zjgsu.edu.cn 1156 Yuta Watanabe 1157 NTT Corporation 1158 Tokyo 1159 Japan 1160 Email: yuta.watanabe@ntt-at.co.jp 1162 Xiaochun Wu 1163 Zhejiang Gongshang University 1164 Hangzhou 1165 P.R.China 1166 Email: spring-403@zjgsu.edu.cn 1168 8. Acknowledgements 1170 The authors would also like thank the following test participants: 1172 Chuanhuang Li, Hangzhou BAUD Networks 1173 Ligang Dong, Zhejiang Gongshang University 1174 Jingjing Zhou, Zhejiang Gongshang Unviersity 1175 Liaoyuan Ke, Hangzhou BAUD Networks 1176 Kelei Jin,Hangzhou BAUD Networks 1178 9. IANA Considerations 1180 This memo includes no request to IANA. 1182 10. Security Considerations 1184 Developers of ForCES FEs and CEs must take the security 1185 considerations of the ForCES Framework [RFC3746] and the ForCES 1186 Protocol [RFC5810] into account. Also, as specified in the security 1187 considerations section of the SCTP-Based TML for the ForCES Protocol 1188 [RFC5811] the transport-level security, has to be ensured by IPsec. 1190 11. References 1192 11.1. Normative References 1194 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 1195 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 1196 Control Element Separation (ForCES) Protocol 1197 Specification", RFC 5810, March 2010. 1199 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 1200 Layer (TML) for the Forwarding and Control Element 1201 Separation (ForCES) Protocol", RFC 5811, March 2010. 1203 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 1204 Element Separation (ForCES) Forwarding Element Model", 1205 RFC 5812, March 2010. 1207 [RFC5813] Haas, R., "Forwarding and Control Element Separation 1208 (ForCES) MIB", RFC 5813, March 2010. 1210 11.2. Informative References 1212 [Ethereal] 1213 "Ethereal is a protocol analyzer. The specific Ethereal 1214 that was used is an updated Ethereal, by Fenggen Jia, that 1215 can analyze and decode the ForCES protocol messages", http 1216 ://www.ietf.org/mail-archive/web/forces/current/ 1217 msg03687.html . 1219 [I-D.ietf-forces-ceha] 1220 Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES 1221 Intra-NE High Availability", draft-ietf-forces-ceha-01 1222 (work in progress), February 2011. 1224 [I-D.ietf-forces-lfb-lib] 1225 Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. 1226 Halpern, "ForCES Logical Function Block (LFB) Library", 1227 draft-ietf-forces-lfb-lib-05 (work in progress), 1228 July 2011. 1230 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1231 June 1999. 1233 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 1234 of IP Control and Forwarding", RFC 3654, November 2003. 1236 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 1237 "Forwarding and Control Element Separation (ForCES) 1238 Framework", RFC 3746, April 2004. 1240 [RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim, 1241 "Implementation Report for Forwarding and Control Element 1242 Separation (ForCES)", RFC 6053, November 2010. 1244 [Tcpdump] "Tcpdump is a Linux protocol analyzer. The specific 1245 tcpdump that was used is a modified tcpdump, by Jamal Hadi 1246 Salim, that can analyze and decode the ForCES protocol 1247 messages", http://www.ietf.org/mail-archive/web/forces/ 1248 current/msg03811.html . 1250 Authors' Addresses 1252 Weiming Wang 1253 Zhejiang Gongshang University 1254 18 Xuezheng Str., Xiasha University Town 1255 Hangzhou, 310018 1256 P.R.China 1258 Phone: +86-571-28877721 1259 Email: wmwang@zjgsu.edu.cn 1261 Kentaro Ogawa 1262 NTT Corporation 1263 Tokyo, 1264 Japan 1266 Email: ogawa.kentaro@lab.ntt.co.jp 1268 Evangelos Haleplidis 1269 University of Patras 1270 Patras, 1271 Greece 1273 Email: ehalep@ece.upatras.gr 1275 Ming Gao 1276 Hangzhou BAUD Networks 1277 408 Wen-San Road 1278 Hangzhou, 310012 1279 P.R.China 1281 Phone: +86-571-28877751 1282 Email: gmyyqno1@pop.zjgsu.edu.cn 1284 Jamal Hadi Salim 1285 Mojatatu Networks 1286 Ottawa 1287 Canada 1289 Email: hadi@mojatatu.com