idnits 2.17.1 draft-ietf-forces-interop-09.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 (June 02, 2013) is 3978 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5813' is defined on line 1200, but no explicit reference was found in the text == Unused Reference: 'RFC3654' is defined on line 1232, but no explicit reference was found in the text == Unused Reference: 'RFC6053' is defined on line 1239, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-forces-ceha-00 == Outdated reference: A later version (-12) exists of draft-ietf-forces-lfb-lib-03 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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 Updates: 6053 (if approved) K. Ogawa 5 Intended status: Informational NTT Corporation 6 Expires: December 04, 2013 E.H. Haleplidis 7 University of Patras 8 M. Gao 9 Hangzhou BAUD Networks 10 J. Hadi Salim 11 Mojatatu Networks 12 June 02, 2013 14 Interoperability Report for Forwarding and Control Element Separation 15 (ForCES) 16 draft-ietf-forces-interop-09 18 Abstract 20 This document captures results of the second Forwarding and Control 21 Element Separation (ForCES) interoperability test which took place on 22 February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang 23 Gongshang University, China. RFC 6053 reported the results of the 24 first ForCES interoperability test, and this document updates RFC 25 6053 by providing further interoperability results. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 04, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. ForCES FE Model . . . . . . . . . . . . . . . . . . . . . 4 64 1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 4 65 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Date, Location, and Participants . . . . . . . . . . . . 4 68 2.2. Testbed Configuration . . . . . . . . . . . . . . . . . . 5 69 2.2.1. Participants Access . . . . . . . . . . . . . . . . . 5 70 2.2.2. Testbed Configuration . . . . . . . . . . . . . . . . 6 71 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . 7 73 3.2. Scenario 2 - TML with IPsec . . . . . . . . . . . . . . . 8 74 3.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 9 75 3.4. Scenario 4 - Packet forwarding . . . . . . . . . . . . . 11 76 4. Test Results . . . . . . . . . . . . . . . . . . . . . . . . 13 77 4.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . 13 78 4.2. TML with IPsec Test . . . . . . . . . . . . . . . . . . . 19 79 4.3. CE High Availability Test . . . . . . . . . . . . . . . . 19 80 4.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . 20 81 5. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 5.1. On Data Encapsulation Format . . . . . . . . . . . . . . 22 83 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 89 10.2. Informative References . . . . . . . . . . . . . . . . . 26 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 92 1. Introduction 94 This document captures results of the second interoperability test of 95 the Forwarding and Control Element Separation (ForCES) which took 96 place February 24-25, 2011 in the Internet Technology Lab (ITL) of 97 Zhejiang Gongshang University, China. The test involved protocol 98 elements described in several documents namely: 100 - ForCES Protocol [RFC5810] 101 - ForCES Forwarding Element (FE) Model [RFC5812] 102 - ForCES Transport Mapping Layer (TML) [RFC5811] 104 The test also involved protocol elements described in the then- 105 current versions of two Internet-Drafts. Although these documents 106 have subsequently been revised and advanced, it is important to 107 understand which versions of the work were used during this test. 108 The then-current Internet-Drafts are: 110 - ForCES Logical Function Block (LFB) Library 111 [I-D.ietf-forces-lfb-lib-03]. 112 - ForCES Intra-NE High Availability [I-D.ietf-forces-ceha-00]. 114 The 'ForCES Logical Function Block (LFB) Library' document has 115 advanced and been published by IETF as RFC 6956. 117 Three independent ForCES implementations participated in the test. 119 Scenarios of ForCES LFB Operation, TML with IPsec, CE High 120 Availability, and Packet Forwarding were constructed. Series of 121 testing items for every scenario were carried out and 122 interoperability results were achieved. Popular packet analyzers 123 Ethereal/Wireshark[Ethereal] and Tcpdump[Tcpdump] were used to verify 124 the wire results. 126 This document is an update to RFC 6053, which captured the results of 127 the first ForCES interoperability test. The first test on ForCES was 128 held in July 2008 at the University of Patras, Greece. That test 129 focused on validating the basic semantics of the ForCES protocol and 130 ForCES FE model. 132 1.1. ForCES Protocol 134 The ForCES protocol works in a master-slave mode in which Forwarding 135 Elements (FEs) are slaves and Control Elements (CEs) are masters. 136 The protocol includes commands for transport of Logical Function 137 Block (LFB) configuration information, association setup, status, and 138 event notifications, etc. The reader is encouraged to read the 139 ForCES protocol specification [RFC5810] for further information. 141 1.2. ForCES FE Model 143 The ForCES Forwarding Element (FE) model [RFC5812] presents a formal 144 way to define FE Logical Function Blocks (LFBs) using XML. LFB 145 configuration components, capabilities, and associated events are 146 defined when the LFB is formally created. The LFBs within the FE are 147 accordingly controlled in a standardized way by the ForCES protocol. 149 1.3. Transport Mapping Layer 151 The ForCES Transport Mapping Layer (TML) transports the ForCES 152 Protocol Layer (PL) messages. The TML is where the issues of how to 153 achieve transport level reliability, congestion control, multicast, 154 ordering, etc are handled. It is expected that more than one TML 155 will be standardized. RFC 5811 specifies an SCTP-Based Transport 156 Mapping Layer (TML) for ForCES protocol, which is a mandated TML for 157 ForCES. See RFC 5811 for more details. 159 1.4. Definitions 161 This document follows the terminology defined by ForCES related 162 documents, including RFC3654, RFC3746, RFC5810, RFC5811, RFC5812, 163 RFC5813, etc. 165 2. Overview 167 2.1. Date, Location, and Participants 169 The second ForCES interoperability test meeting was held by IETF 170 ForCES Working Group on February 24-25, 2011, and was chaired by 171 Jamal Hadi Salim. Three independent ForCES implementations 172 participated in the test: 174 o Zhejiang Gongshang University/Hangzhou BAUD Corporation of 175 Information and Networks Technology (Hangzhou BAUD Networks), 176 China. This implementation is referred to as "ZJSU" or in some 177 cases "Z" in the document for the sake of brevity. 179 o NTT Corporation, Japan. This implementation is referred to as 180 "NTT" or in some cases "N" in the document for the sake of 181 brevity. 183 o The University of Patras, Greece. This implementation is referred 184 to as "UoP" or in some cases "P" in the document for the sake of 185 brevity. 187 Two other organizations, Mojatatu Networks and Hangzhou BAUD Networks 188 Corporation, which independently extended two different well known 189 public domain protocol analyzers, Ethereal/Wireshark [Ethereal] and 190 Tcpdump [Tcpdump], also participated in the interop test. During the 191 interoperability test, the two protocol analyzers were used to verify 192 the validity of ForCES protocol messages and in some cases semantics. 194 Some issues related to interoperability among implementations were 195 discovered. Most of the issues were solved on site during the test. 196 The most contentious issue found was on the format of encapsulation 197 for protocol TLV (Refer to Section 5.1 ). 199 Some errata related to ForCES document were found by the 200 interoperability test. The errata has been reported to related IETF 201 RFCs. 203 At times, interoperability testing was exercised between two instead 204 of all three representative implementations due to a third one 205 lacking a specific feature; however, in ensuing discussions, all 206 implementers mentioned they would be implementing any missing 207 features in the future. 209 2.2. Testbed Configuration 211 2.2.1. Participants Access 213 NTT and ZJSU physically attended on site at the Internet Technology 214 Lab (ITL) of Zhejiang Gongshang University in China. The University 215 of Patras implementation joined remotely from Greece. The chair, 216 Jamal Hadi Salim, joined remotely from Canada by using the Teamviewer 217 as the monitoring tool[Teamviewer]. The approach is as shown in 218 Figure 1. In the figure, FE/CE refers to FE or CE that the 219 implementer may act alternatively. 221 +---------+ +----+ +----------+ 222 | FE/CE | | | +---|Monitoring| 223 | ZJSU |-----| | /\/\/\/\/\ | |(TeamViewer) 224 +---------+ | | \Internet/ | | Mojatatu | 225 |LAN |----/ \--| +----------+ 226 +---------+ | | \/\/\/\/\/ | +----------+ 227 | FE/CE |-----| | | | FE/CE | 228 | NTT | | | +---| UoP | 229 +---------+ +----+ +----------+ 231 Figure 1: Access for Participants 233 As specified in RFC 5811, all CEs and FEs shall implement IPsec 234 security in the TML. 236 On the internet boundary, gateways used must allow for IPsec, SCTP 237 protocol and SCTP ports as defined in the ForCES SCTP-TML [RFC5811] . 239 2.2.2. Testbed Configuration 241 CEs and FEs from ZJSU and NTT implementations were physically located 242 within the ITL Lab of Zhejiang Gongshang University and connected 243 together using Ethernet switches. The configuration can be seen in 244 Figure 2. In the figure, the SmartBits is a third-party routing 245 protocol testing machine, which acts as a router running OSPF and RIP 246 and exchanged routing protocol messages with ForCES routers in the 247 network. Connection to the Internet was via an ADSL channel. 249 /\/\/\/\/\ 250 \Internet/ 251 / \ 252 \/\/\/\/\/ 253 | 254 |(ADSL) 255 | 256 +------------------------------------------------------------------+ 257 | LAN (10.20.0.0/24) | 258 +------------------------------------------------------------------+ 259 | | | | | | 260 | | | | | | 261 |.222 |.230 |.221 |.179 |.231 |.220 262 +-----+ +-----+ +-----+ +-----+ +-----+ +---------+ 263 | CE | | CE | | | | | | | | Protocol| 264 |ZJSU | | NTT | | FE1 |.1 .2| FE |.1 .2| FE2 | | Analyzer| 265 +-----+ +-----+ |ZJSU |---------| NTT |---------|ZJSU | +---------+ 266 +---------| |192.169. | | 192.168.| |------+ 267 | .2 +-----+ 20.0.24 +-----+ 30.0/24+-----+ .2 | 268 | .12| |.12 | 269 | | | | 270 192.168.50.0/24 | |192.168.60.0/24 271 | 192.168.10.0/24 192.168.40.0/24 | 272 .1 | |.11 |.11 |.1 273 +--------+ +--------------------------------------+ +--------+ 274 |Terminal| | Smartbits | |Terminal| 275 +--------+ +--------------------------------------+ +--------+ 277 Figure 2: Testbed Configuration Located in ITL Lab, China 279 CE and FE from the UoP implementation were located within the 280 University of Patras, Greece, and were connected together using LAN 281 as shown in Figure 3. Connection to the Internet was via a VPN 282 channel. 284 /\/\/\/\/\ 285 \Internet/ 286 / \ 287 \/\/\/\/\/ 288 | 289 |(VPN) 290 | 291 +------------------------------------+ 292 | LAN | 293 +------------------------------------+ 294 | | | 295 | | | 296 +------+ +--------+ +------+ 297 | FE | |Protocol| | CE | 298 | UoP | |Analyzer| | UoP | 299 +------+ +--------+ +------+ 301 Figure 3: Testbed Configuration Located in the University of 302 Patras,Greece 304 The testbeds above were then able to satisfy requirements of all 305 interoperability test scenarios in this document. 307 3. Scenarios 309 3.1. Scenario 1 - LFB Operation 311 This scenario was to test the interoperability on LFB operations 312 among the participants. The connection diagram for the participants 313 is as shown in Figure 4. 315 +------+ +------+ +------+ +------+ +------+ +------+ 316 | CE | | CE | | CE | | CE | | CE | | CE | 317 | ZJSU | | NTT | | ZJSU | | UoP | | NTT | | UoP | 318 +------+ +------+ +------+ +------+ +------+ +------+ 319 | | | | | | 320 | | | | | | 321 +------+ +------+ +------+ +------+ +------+ +------+ 322 | FE | | FE | | FE | | FE | | FE | | FE | 323 | NTT | | ZJSU | | UoP | | ZJSU | | UoP | | NTT | 324 +------+ +------+ +------+ +------+ +------+ +------+ 326 Figure 4: Scenario for LFB Operation 328 In order to make interoperability more credible, the three 329 implementers were required to carry out the test in a way acting as 330 CE or FE alternatively. As a result, every LFB operation was 331 combined with 6 scenarios, as shown by Figure 4. 333 The test scenario was designed with the following purposes: 335 Firstly, the scenario was designed to verify all kinds of protocol 336 messages with their complex data formats, which were defined in RFC 337 5810. Specially, we tried to verify the data format of a PATH-DATA 338 with nested PATH-DATAs, and the operation(SET, GET, DEL) of an array 339 or an array with a nested array. 341 Secondly, the scenario was designed to verify the definition of 342 ForCES LFB Library [I-D.ietf-forces-lfb-lib-03], which defined a base 343 set of ForCES LFB classes for typical router functions. Successful 344 test under this scenario would help the validity of the LFB 345 definitions. 347 3.2. Scenario 2 - TML with IPsec 349 This scenario was designed to implement a TML with IPsec, which was 350 the requirement by RFC 5811. TML with IPsec was not implemented and 351 tested in the first ForCES interoperability test as reported by RFC 352 6053. For this reason, in this interoperability test, we 353 specifically designed the test scenario to verify the TML over IPsec 354 channel. 356 In this scenario, tests on LFB operations for Scenario 1 were 357 repeated with the difference that TML was secured via IPsec. This 358 setup scenario allowed us to verify whether all interactions between 359 CE and FE could be made correctly under an IPsec TML environment. 361 The connection diagram for this scenario is shown as Figure 5. 362 Because an unfortunate problem with the test system in UoP prevented 363 the deployment of IPsec over TML, this test only took place between 364 the test systems in ZJSU and NTT. 366 +------+ +------+ 367 | CE | | CE | 368 | ZJSU | | NTT | 369 +------+ +------+ 370 | | 371 |TML over IPsec |TML over IPsec 372 +------+ +------+ 373 | FE | | FE | 374 | NTT | | ZJSU | 375 +------+ +------+ 377 Figure 5: Scenario for LFB Operation with TML over IPsec 379 In this scenario, ForCES TML was run over the IPsec channel. 380 Implementers joined in this interoperability used the same third- 381 party software 'Racoon' [Racoon] to establish the IPsec channel. 383 The Racoon in NetBSD is an IKE daemon performing the IPsec Key 384 Exchange (IKE) with the peers. Both IKE v1 and v2 are supported by 385 Racoon in linux 2.6, and the v2 was adopted in the interop test. SAD 386 and SPD were necessary for the test, setups of which were in the 387 Racoon configuration file. ESP was specified in SAD and SPD in the 388 Racoon configuration file. 390 ZJSU and NTT made a successful test with the scenario, and the 391 following items were realized: 393 o Internet Key Exchange (IKE) with certificates for endpoint 394 authentication. 396 o Transport Mode Encapsulating Security Payload (ESP), HMAC-SHA1-96 397 for message integrity protection. 399 3.3. Scenario 3 - CE High Availability 401 CE High Availability (CEHA) was tested based on the ForCES CEHA 402 document [I-D.ietf-forces-ceha-00] 404 The design of the setup and the scenario for the CEHA were simplified 405 so as to focus mostly on the mechanics of the CEHA, which were: 407 o Associating with more than one CE. 409 o Switching to backup CE on master CE failure. 411 The connection diagram for the scenario is as shown in Figure 6. 413 master standby master standby 414 +------+ +------+ +------+ +------+ 415 | CE | | CE | | CE | | CE | 416 | ZJSU | | UoP | | NTT | | UoP | 417 +------+ +------+ +------+ +------+ 418 | | | | 419 +----------+ +-----------+ 420 | | 421 +------+ +------+ 422 | FE | | FE | 423 | UoP | | UoP | 424 +------+ +------+ 425 (a) (b) 427 Figure 6: Scenario for CE High Availability 429 In this scenario one FE was connected and associated to a master CE 430 and a backup CE. In the pre-association phase, the FE would be 431 configured to have ZJSU's or NTT's CE as master CE and UoP's CE as 432 standby CE. The CEFailoverPolicy component of the FE Protocol Object 433 LFB that specified whether the FE was in High Availability mode 434 (value 2 or 3) would either be set in the pre-association phase by 435 the FEM interface or in post-association phase by the master CE. 437 If the CEFailoverPolicy value was set to 2 or 3, the FE (in the post- 438 association phase) would attempt to connect and associate with the 439 standby CE. 441 When the master CE was deemed disconnected, either by a TearDown, 442 Loss of Heartbeats or physically disconnected, the FE would assume 443 that the standby CE was now the master CE. The FE would then send an 444 Event Notification, Primary CE Down, to all associated CEs, only the 445 standby CE in this case, with the value of the new master CEID. The 446 standby CE would then respond by sending a configuration message to 447 the CEID component of the FE Protocol Object with its own ID to 448 confirm that the CE considered itself as the master as well. 450 The steps of the CEHA test scenario were as follows: 452 1. In the pre-association phase, setup of FE with master CE and 453 backup CE 455 2. FE connecting and associating with master CE. 457 3. When CEFailoverPolicy is set to 2 or 3, the FE will connect and 458 associate with backup CE. 460 4. Once the master CE is considered disconnected then the FE chooses 461 the first Associated backup CE. 463 5. It sends an Event Notification specifying that the master CE is 464 down and who is now the master CE. 466 6. The new master CE sends a SET Configuration message to the FE 467 setting the CEID value to who is now the new master CE completing 468 the switch. 470 3.4. Scenario 4 - Packet forwarding 472 This test scenario was to verify LFBs like RedirectIn, RedirectOut, 473 IPv4NextHop, IPv4UcastLPM defined by the ForCES LFB library document 474 [I-D.ietf-forces-lfb-lib-03], and more importantly, to verify the 475 combination of the LFBs to implement IP packet forwarding. 477 The connection diagram for this scenario is as Figure 7. 479 +------+ 480 | CE | 481 | NTT | 482 +------+ 483 | ^ 484 | | OSPF 485 | +-------> 486 +------+ +------+ 487 +--------+ | FE | | OSPF | +--------+ 488 |Terminal|------| ZJSU |-------|Router|------|Terminal| 489 +--------+ +------+ +------+ +--------+ 491 <--------------------------------------------> 492 Packet Forwarding 494 (a) 496 +------+ 497 | CE | 498 | ZJSU | 499 +------+ 500 ^ | ^ 501 OSPF | | | OSPF 502 <-----+ | +-----> 503 +-------+ +------+ +------+ 504 +--------+ | OSPF | | FE | | OSPF | +--------+ 505 |Terminal|----|Router |----| NTT |-----|Router|--|Terminal| 506 +--------+ +-------+ +------+ +------+ +--------+ 507 <--------------------------------------------> 508 Packet Forwarding 510 (b) 512 +------+ +------+ 513 | CE | | CE | 514 | NTT | | ZJSU | 515 +------+ +------+ 516 | ^ ^ | 517 | | OSPF | | 518 | +----------+ | 519 +------+ +------+ 520 +--------+ | FE | | FE | +--------+ 521 |Terminal|------| ZJSU |-------| NTT |------|Terminal| 522 +--------+ +------+ +------+ +--------+ 524 <--------------------------------------------> 525 Packet Forwarding 527 (c) 529 Figure 7: Scenario for IP Packet forwarding 531 In case (a), a CE by NTT was connected to an FE by ZJSU to form a 532 ForCES router. A Smartbits test machine with its routing protocol 533 software were used to simulate an OSPF router and were connected with 534 the ForCES router to try to exchange OSPF hello packets and LSA 535 packets among them. Terminals were simulated by Smartbits to send 536 and receive packets. As a result, the CE in the ForCES router need 537 to be configured to run and support OSPF routing protocol. 539 In case (b), a CE by ZJSU was connected to an FE by NTT to form a 540 ForCES router. Two routers running OSPF were simulated and connected 541 to the ForCES router to test if the ForCES router could support OSPF 542 protocol and support packet forwarding. 544 In case (c), two ForCES routers were constructed. One was with CE by 545 NTT and FE by ZJSU and the other was opposite. OSPF and packet 546 forwarding were tested in the environment. 548 Testing process for this scenario is as below: 550 1. Boot terminals and routers, and set IP addresses of their 551 interfaces. 553 2. Boot CE and FE. 555 3. Establish association between CE and FE, and set IP addresses of 556 FEs interfaces. 558 4. Start OSPF among CE and routers, and set FIB on FE. 560 5. Send packets between terminals. 562 4. Test Results 564 4.1. LFB Operation Test 566 The test result is as reported by Figure 8. For the convenience 567 sake, as mentioned earlier, abbreviations of 'Z' in the table means 568 implementation from ZJSU ,'N' implementation from NTT, and 569 'P'implementation from UoP. 571 +-----+----+-----+-----+--------------+-------------------+---------+ 572 |Test#| CE |FE(s)|Oper | LFB | Component | Result | 573 | | | | | | /Capability | | 574 +-----+----+-----+-----+--------------+-------------------+---------+ 575 | 1 | Z | N | GET | FEObject | LFBTopology | Success | 576 | | N | Z | | | | Success | 577 | | P | Z | | | | Success | 578 | | N | P | | | | Success | 579 | | P | N | | | | Success | 580 | | | | | | | | 581 | 2 | Z | N | GET | FEObject | LFBSelector | Success | 582 | | N | Z | | | | Success | 583 | | Z | P | | | | Success | 584 | | P | Z | | | | Success | 585 | | N | P | | | | Success | 586 | | P | N | | | | Success | 587 | | | | | | | | 588 | 3 | Z | N | GET | EtherPHYCop | PHYPortID | Success | 589 | | N | Z | | | | Success | 590 | | Z | P | | | | Success | 591 | | P | Z | | | | Success | 592 | | N | P | | | | Success | 593 | | P | N | | | | Success | 594 | | | | | | | | 595 | 4 | Z | N | GET | EtherPHYCop | AdminStatus | Success | 596 | | N | Z | | | | Success | 597 | | Z | P | | | | Success | 598 | | P | Z | | | | Success | 599 | | N | P | | | | Success | 600 | | P | N | | | | Success | 601 | | | | | | | | 602 | 5 | Z | N | GET | EtherPHYCop | OperStatus | Success | 603 | | N | Z | | | | Success | 604 | | Z | P | | | | Success | 605 | | P | Z | | | | Success | 606 | | N | P | | | | Success | 607 | | P | N | | | | Success | 608 | | | | | | | | 609 | 6 | Z | N | GET | EtherPHYCop | AdminLinkSpeed | Success | 610 | | N | Z | | | | Success | 611 | | Z | P | | | | Success | 612 | | P | Z | | | | Success | 613 | | N | P | | | | Success | 614 | | P | N | | | | Success | 615 | | | | | | | | 616 | 7 | Z | N | GET | EtherPHYCop | OperLinkSpeed | Success | 617 | | N | Z | | | | Success | 618 | | Z | P | | | | Success | 619 | | P | Z | | | | Success | 620 | | N | P | | | | Success | 621 | | P | N | | | | Success | 622 | | | | | | | | 623 | 8 | Z | N | GET | EtherPHYCop | AdminDuplexSpeed | Success | 624 | | N | Z | | | | Success | 625 | | Z | P | | | | Success | 626 | | P | Z | | | | Success | 627 | | N | P | | | | Success | 628 | | P | N | | | | Success | 629 | | | | | | | | 630 | 9 | Z | N | GET | EtherPHYCop | OperDuplexSpeed | Success | 631 | | N | Z | | | | Success | 632 | | Z | P | | | | Success | 633 | | P | Z | | | | Success | 634 | | N | P | | | | Success | 635 | | P | N | | | | Success | 636 | | | | | | | | 637 | 10 | Z | N | GET | EtherPHYCop | CarrierStatus | Success | 638 | | N | Z | | | | Success | 639 | | Z | P | | | | Success | 640 | | P | Z | | | | Success | 641 | | N | P | | | | Success | 642 | | P | N | | | | Success | 643 | | | | | | | | 644 | 11 | Z | N | GET | EtherMACIn | AdminStatus | Success | 645 | | N | Z | | | | Success | 646 | | Z | P | | | | Success | 647 | | P | Z | | | | Success | 648 | | N | P | | | | Success | 649 | | P | N | | | | Success | 650 | | | | | | | | 651 | 12 | Z | N | GET | EtherMACIn | LocalMacAddresses | Success | 652 | | N | Z | | | | Success | 653 | | Z | P | | | | Success | 654 | | P | Z | | | | Success | 655 | | N | P | | | | Success | 656 | | P | N | | | | Success | 657 | | | | | | | | 658 | 13 | Z | N | GET | EtherMACIn | L2Bridging | Success | 659 | | N | Z | | | PathEnable | Success | 660 | | Z | P | | | | Success | 661 | | P | Z | | | | Success | 662 | | N | P | | | | Success | 663 | | P | N | | | | Success | 664 | | | | | | | | 665 | 14 | Z | N | GET | EtherMACIn | PromiscuousMode | Success | 666 | | N | Z | | | | Success | 667 | | Z | P | | | | Success | 668 | | P | Z | | | | Success | 669 | | N | P | | | | Success | 670 | | P | N | | | | Success | 671 | | | | | | | | 672 | 15 | Z | N | GET | EtherMACIn | TxFlowControl | Success | 673 | | N | Z | | | | Success | 674 | | Z | P | | | | Success | 675 | | P | Z | | | | Success | 676 | | N | P | | | | Success | 677 | | P | N | | | | Success | 678 | | | | | | | | 679 | 16 | Z | N | GET | EtherMACIn | RxFlowControl | Success | 680 | | N | Z | | | | Success | 681 | | Z | P | | | | Success | 682 | | P | Z | | | | Success | 683 | | N | P | | | | Success | 684 | | P | N | | | | Success | 685 | | | | | | | | 686 | 17 | Z | N | GET | EtherMACIn | MACInStats | Success | 687 | | N | Z | | | | Success | 688 | | Z | P | | | | Success | 689 | | P | Z | | | | Success | 690 | | N | P | | | | Success | 691 | | P | N | | | | Success | 692 | | | | | | | | 693 | 18 | Z | N | GET | EtherMACOut | AdminStatus | Success | 694 | | N | Z | | | | Success | 695 | | Z | P | | | | Success | 696 | | P | Z | | | | Success | 697 | | N | P | | | | Success | 698 | | P | N | | | | Success | 699 | | | | | | | | 700 | 19 | Z | N | GET | EtherMACOut | MTU | Success | 701 | | N | Z | | | | Success | 702 | | Z | P | | | | Success | 703 | | P | Z | | | | Success | 704 | | N | P | | | | Success | 705 | | P | N | | | | Success | 706 | | | | | | | | 707 | 20 | Z | N | GET | EtherMACOut | TxFlowControl | Success | 708 | | N | Z | | | | Success | 709 | | Z | P | | | | Success | 710 | | P | Z | | | | Success | 711 | | N | P | | | | Success | 712 | | P | N | | | | Success | 713 | | | | | | | | 714 | 21 | Z | N | GET | EtherMACOut | TxFlowControl | Success | 715 | | N | Z | | | | Success | 716 | | Z | P | | | | Success | 717 | | P | Z | | | | Success | 718 | | N | P | | | | Success | 719 | | P | N | | | | Success | 720 | | | | | | | | 721 | 22 | Z | N | GET | EtherMACOut | MACOutStats | Success | 722 | | N | Z | | | | Success | 723 | | Z | P | | | | Success | 724 | | P | Z | | | | Success | 725 | | N | P | | | | Success | 726 | | P | N | | | | Success | 727 | | | | | | | | 728 | 23 | Z | N | GET | ARP |PortV4AddrInfoTable| Success | 729 | | N | Z | | | | Success | 730 | | Z | P | | | | Success | 731 | | P | Z | | | | Success | 732 | | N | P | | | | Success | 733 | | P | N | | | | Success | 734 | | | | | | | | 735 | 24 | Z | N | SET | ARP |PortV4AddrInfoTable| Success | 736 | | N | Z | | | | Success | 737 | | Z | P | | | | Success | 738 | | P | Z | | | | Success | 739 | | N | P | | | | Success | 740 | | P | N | | | | Success | 741 | | | | | | | | 742 | 25 | Z | N | DEL | ARP |PortV4AddrInfoTable| Success | 743 | | N | Z | | | | Success | 744 | | Z | P | | | | Success | 745 | | P | Z | | | | Success | 746 | | N | P | | | | Success | 747 | | P | N | | | | Success | 748 | | | | | | | | 749 | 26 | Z | N | SET | EtherMACIn | LocalMACAddresses | Success | 750 | | N | Z | | | | Success | 751 | | Z | P | | | | Success | 752 | | P | Z | | | | Success | 753 | | N | P | | | | Success | 754 | | P | N | | | | Success | 755 | | | | | | | | 756 | 27 | Z | N | SET | EtherMACIn | MTU | Success | 757 | | N | Z | | | | Success | 758 | | Z | P | | | | Success | 759 | | P | Z | | | | Success | 760 | | N | P | | | | Success | 761 | | P | N | | | | Success | 762 | | | | | | | | 763 | 28 | Z | N | SET | IPv4NextHop | IPv4NextHopTable | Success | 764 | | N | Z | | | | Success | 765 | | Z | P | | | | Success | 766 | | P | Z | | | | Success | 767 | | N | P | | | | Success | 768 | | P | N | | | | Success | 769 | | | | | | | | 770 | 29 | Z | N | SET | IPv4UcastLPM | IPv4PrefixTable | Success | 771 | | N | Z | | | | Success | 772 | | Z | P | | | | Success | 773 | | P | Z | | | | Success | 774 | | N | P | | | | Success | 775 | | P | N | | | | Success | 776 | | | | | | | | 777 | 30 | Z | N | DEL | IPv4NextHop | IPv4NextHopTable | Success | 778 | | N | Z | | | | Success | 779 | | Z | P | | | | Success | 780 | | P | Z | | | | Success | 781 | | N | P | | | | Success | 782 | | P | N | | | | Success | 783 | | | | | | | | 784 | 31 | Z | N | DEL | IPv4UcastLPM | IPv4PrefixTable | Success | 785 | | N | Z | | | | Success | 786 | | Z | P | | | | Success | 787 | | P | Z | | | | Success | 788 | | N | P | | | | Success | 789 | | P | N | | | | Success | 790 | | | | | | | | 791 | 32 | Z | N | SET | EtherPHYCop | AdminStatus | Success | 792 | | N | Z | | | | Success | 793 | | Z | P | | | | Success | 794 | | P | Z | | | | Success | 795 | | N | P | | | | Success | 796 | | P | N | | | | Success | 797 | | | | | | | | 798 | 33 | Z | N | SET | Ether | VlanInputTable | Success | 799 | | N | Z | | Classifier | | Success | 800 | | Z | P | | | | Success | 801 | | P | Z | | | | Success | 802 | | N | P | | | | Success | 803 | | P | N | | | | Success | 804 | | | | | | | | 805 | 34 | Z | N | DEL | Ether | VlanInputTable | Success | 806 | | N | Z | | Classifier | | Success | 807 | | Z | P | | | | Success | 808 | | P | Z | | | | Success | 809 | | N | P | | | | Success | 810 | | P | N | | | | Success | 811 | | | | | | | | 812 | 35 | Z | N | SET | Ether | VlanOutputTable | Success | 813 | | N | Z | | Encapsulator | | Success | 814 | | Z | P | | | | Success | 815 | | P | Z | | | | Success | 816 | | N | P | | | | Success | 817 | | P | N | | | | Success | 818 | | | | | | | | 819 | 36 | Z | N | DEL | Ether | VlanOutputTable | Success | 820 | | N | Z | | Encapsulator | | Success | 821 | | Z | P | | | | Success | 822 | | P | Z | | | | Success | 823 | | N | P | | | | Success | 824 | | P | N | | | | Success | 825 +-----+----+-----+-----+--------------+-------------------+---------+ 827 Figure 8: LFB Operation Test Results 829 Note on test #1 and #2: 831 On the wire format of encapsulation on array, only the case of 832 FULLDATA vs SPARSEDATA was tested. 834 It is very common for CE to get information of FEobject LFB in FE so 835 as to know status on all active LFBs in the FE. Hence, the two tests 836 were specifically designed. 838 4.2. TML with IPsec Test 840 In this scenario, the ForCES TML was run over IPsec. Implementers 841 joined this interoperability test used the same third-party tool 842 software 'Racoon' [Racoon] to establish IPsec channel. Typical LFB 843 operation tests as in Scenario 1 were repeated with the IPsec enabled 844 TML. 846 As mentioned, this scenario only took place between implementers of 847 ZJSU and NTT. 849 The TML with IPsec test results are reported by Figure 9. 851 +-----+----+-----+-----+--------------+-------------------+---------+ 852 |Test#| CE |FE(s)|Oper | LFB | Component/ | Result | 853 | | | | | | Capability | | 854 +-----+----+-----+-----+--------------+-------------------+---------+ 855 | 1 | Z | N | GET | FEObject | LFBTopology | Success | 856 | | N | Z | | | | Success | 857 | | | | | | | | 858 | 2 | Z | N | GET | FEObject | LFBSelectors | Success | 859 | | N | Z | | | | Success | 860 | | | | | | | | 861 | 3 | Z | N | SET | Ether | VlanInputTable | Success | 862 | | N | Z | | Classifier | | Success | 863 | | | | | | | | 864 | 4 | Z | N | DEL | Ether | VlanInputTable | Success | 865 | | N | Z | | Classifier | | Success | 866 +-----+----+-----+-----+--------------+-------------------+---------+ 868 Figure 9: TML with IPsec Test Results 870 4.3. CE High Availability Test 872 In this scenario, one FE connected and associated with a master CE 873 and a backup CE. When the master CE was deemed disconnected, the FE 874 would attempt to find another associated CE to become the master CE. 876 The CEHA scenario as was described by Scenario 3 was completed 877 successfully for both setups. 879 Due to a bug in one of the FEs, an interesting issue was caught: it 880 was observed that the buggy FE took up to a second to failover. It 881 was eventually found that the issue was due to the FE's 882 prioritization of the different CEs. All messages from the backup CE 883 were being ignored unless the master CE was disconnected. 885 While the bug was fixed and the CEHA scenario was completed 886 successfully, the authors felt it was important to capture the 887 implementation issue in this document. The recommended approach is 888 the following: 890 o The FE should receive and handle messages first from the master CE 891 on all priority channels to maintain proper functionality and then 892 receive and handle messages from the backup CEs. 894 o Only when the FE is attempting to associate with the backup CEs, 895 then the FE should receive and handle messages per priority 896 channel from all CEs. When all backup CEs are associated with or 897 deemed unreachable, then the FE should return to receiving and 898 handling messages first from the master CE. 900 4.4. Packet Forwarding Test 902 As described in the ForCES LFB library [I-D.ietf-forces-lfb-lib-03], 903 packet forwarding is implemented by a set of LFB classes that compose 904 a processing path for packets. In this test scenario, as shown in 905 Figure 7, a ForCES router running OSPF protocol was constructed. In 906 addition, a set of LFBs including RedirectIn, RedirectOut, 907 IPv4UcastLPM, and IPv4NextHop LFBs were used. RedirectIn and 908 RedirectOut LFBs redirected OSPF hello and LSA packets from and to 909 CE. A Smartbits test machine was used to simulate an OSPF router and 910 exchange the OSPF hello and LSA packets with CE in ForCES router. 912 In Figure 7, case (a) and case (b) both need a RedirectIn LFB to send 913 OSPF packets generated by CE to FE by use of ForCES packet redirect 914 messages. The OSPF packets were further sent to an outside OSPF 915 Router by the FE via forwarding LFBs including IPv4NextHop and 916 IPv4UcastLPM LFBs. A RedirectOut LFB in the FE was used to send OSPF 917 packets received from outside OSPF Router to CE by ForCES packet 918 redirect messages. 920 By running OSPF, the CE in the ForCES router could generate new 921 routes and load them to routing table in FE. The FE was then able to 922 forward packets according to the routing table. 924 The test results are as shown in Figure 10 926 +-----+----+-----+-------------------------+--------------+---------+ 927 |Test#| CE |FE(s)| Item | LFBs Related | Result | 928 +-----+----+-----+-------------------------+--------------+---------+ 929 | 1 | N | Z | IPv4NextHopTable SET | IPv4NextHop | Success | 930 | | | | | | | 931 | 2 | N | Z | IPv4PrefixTable SET | IPv4UcastLPM | Success | 932 | | | | | | | 933 | 3 | N | Z |Redirect OSPF packet from| RedirectIn | Success | 934 | | | | CE to SmartBits | | | 935 | | | | | | | 936 | 4 | N | Z |Redirect OSPF packet from| RedirectOut | Success | 937 | | | | SmartBits to CE | | | 938 | | | | | | | 939 | 5 | N | Z | Metadata in | RedirectOut | Success | 940 | | | | redirect message | RedirectIn | | 941 | | | | | | | 942 | 6 | N | Z | OSPF neighbor discovery | RedirectOut | Success | 943 | | | | | RedirectIn | | 944 | | | | | | | 945 | 7 | N | Z | OSPF DD exchange | RedirectOut | Success | 946 | | | | | RedirectIn | | 947 | | | | | IPv4NextHop | | 948 | | | | | | | 949 | 8 | N | Z | OSPF LSA exchange | RedirectOut | Success | 950 | | | | | RedirectIn | | 951 | | | | | IPv4NextHop | | 952 | | | | | IPv4UcastLPM| | 953 | | | | | | | 954 | 9 | N | Z | Data Forwarding | RedirectOut | Success | 955 | | | | | RedirectIn | | 956 | | | | | IPv4NextHop | | 957 | | | | | IPv4UcastLPM| | 958 | | | | | | | 959 | 10 | Z | N | IPv4NextHopTable SET | IPv4NextHop | Success | 960 | | | | | | | 961 | 11 | Z | N | IPv4PrefixTable SET | IPv4UcastLPM| Success | 962 | | | | | | | 963 | 12 | Z | N |Redirect OSPF packet from| RedirectIn | Success | 964 | | | | CE to other OSPF router | | | 965 | | | | | | | 966 | 13 | Z | N |Redirect OSPF packet from| RedirectOut | Success | 967 | | | |other OSPF router to CE | | | 968 | | | | | | | 969 | 14 | Z | N | Metadata in | RedirectOut | Success | 970 | | | | redirect message | RedirectIn | | 971 | | | | | | | 972 | 15 | Z | N |OSPF neighbor discovery | RedirectOut | Success | 973 | | | | | RedirectIn | | 974 | | | | | | | 975 | 16 | Z | N | OSPF DD exchange | RedirectOut | Failure | 976 | | | | | RedirectIn | | 977 | | | | | IPv4NextHop | | 978 | | | | | | | 979 | 17 | Z | N | OSPF LSA exchange | RedirectOut | Failure | 980 | | | | | RedirectIn | | 981 | | | | | IPv4NextHop | | 982 | | | | | IPv4UcastLPM| | 983 +-----+----+-----+-------------------------+--------------+---------+ 985 Figure 10: Packet Forwarding Test Results 987 Note on test #1 and #2: 989 The implementer found a multicast route pointing to localhost had to 990 be manually set before a redirect channel could work normally. 992 Note on test #3 to #9: 994 During the test, OSPF packets received from CE were found by Ethereal 995 /Wireshark with checksum errors in FE. Because the test time was 996 quite limited, implementer of the CE did not try to make efforts to 997 find and solve the checksum error, instead, the FE had tried to 998 correct the checksum in order not to let the Smartbits drop the 999 packets. Note that such solution does not affect the test results. 1001 Comment on Test #16 and #17: 1003 The two test items failed. Note that Test #7 and #8 were identical 1004 to the two tests, only with CE and FE implementers were exchanged. 1005 Moreover, test #12 and #13 showed that the redirect channel worked 1006 well. Therefore, it can be reasonably inferred that the problem 1007 caused the failure was from the implementations, rather than from the 1008 ForCES protocol itself or from misunderstanding of implementations on 1009 the protocol specification. Although the failure made the OSPF 1010 interoperability test incomplete, it did not show interoperability 1011 problem. More test work is needed to verify the OSPF 1012 interoperability. 1014 5. Discussions 1016 5.1. On Data Encapsulation Format 1018 In the first day of the test, it was found that the LFB inter- 1019 operations about tables all failed. It was eventually found the 1020 failure was because that different data encapsulation methods for 1021 ForCES protocol messages were taken by different implementations. 1022 The issue is described in detail as below: 1024 Assuming that an LFB has two components, one is a struct with ID 1 1025 and the other an array with ID 2, further with two components of u32 1026 both inside, as below: 1028 struct1: type struct, ID=1 1029 components are: 1030 a, type u32, ID=1 1031 b, type u32, ID=2 1033 table1: type array, ID=2 1034 components for each row are (a struct of): 1035 x, type u32, ID=1 1036 y, type u32, ID=2 1038 1. On response of PATH-DATA format 1040 When a CE sends a config/query ForCES protocol message to an FE from 1041 a different implementer, the CE probably receives response from the 1042 FE with different PATH-DATA encapsulation format. For example, if a 1043 CE sends a query message with a path of 1 to a third party FE to 1044 manipulate struct 1 as defined above, the FE is probable to generate 1045 response with two different PATH-DATA encapsulation format: one is 1046 the value with FULL/SPARSE-DATA and the other is the value with many 1047 parallel PATH-DATA TLV and nested PATH-DATA TLV, as below: 1049 format 1: 1050 OPER = GET-RESPONSE-TLV 1051 PATH-DATA-TLV: 1052 IDs=1 1053 FULLDATA-TLV containing valueof(a),valueof(b) 1054 format 2: 1055 OPER = GET-RESPONSE-TLV 1056 PATH-DATA-TLV: 1057 IDs=1 1058 PATH-DATA-TLV: 1059 IDs=1 1060 FULLDATA-TLV containing valueof(a) 1061 PATH-DATA-TLV: 1062 IDs=2 1063 FULLDATA-TLV containing valueof(b) 1065 The interoperability testers witnessed that a ForCES element (CE or 1066 FE) sender is free to choose whatever data structure that IETF ForCES 1067 documents define and best suits the element, while a ForCES element 1068 (CE or FE) should be able to accept and process information (requests 1069 and responses) that use any legitimate structure defined by IETF 1070 ForCES documents. While in the case a ForCES element is free to 1071 choose any legitimate data structure as a response, it is preferred 1072 the ForCES element responds in the same format that the request was 1073 made, as it is most probably the data structure is the request sender 1074 looks forward to receive. 1076 2. On operation to array 1078 An array operation may also have several different data encapsulation 1079 formats. For instance, if a CE sends a config message to table 1 1080 with a path of (2.1), which refers to component with ID=2, which is 1081 an array, and the second ID is the row, so row 1, it may be 1082 encapsulated with three formats as below: 1084 format 1: 1085 OPER = SET-TLV 1086 PATH-DATA-TLV: 1087 IDs=2.1 1088 FULLDATA-TLV containing valueof(x),valueof(y) 1089 format 2: 1090 OPER = SET-TLV 1091 PATH-DATA-TLV: 1092 IDs=2.1 1093 PATH-DATA-TLV: 1094 IDs=1 1095 FULLDATA-TLV containing valueof(x) 1096 PATH-DATA-TLV 1097 IDs=2 1098 FULLDATA-TLV containing valueof(y) 1100 Moreover, if CE is targeting the whole array, for example if the 1101 array is empty and CE wants to add the first row to the table, it 1102 could also adopt another format: 1104 format 3: 1105 OPER = SET-TLV 1106 PATH-DATA-TLV: 1107 IDs=2 1108 FULLDATA-TLV containing rowindex=1,valueof(x),valueof(y) 1110 The interoperability test experience has shown that format 1 and 1111 format 3, which take full advantage of multiple data elements 1112 description in one TLV of FULLDATA-TLV, get more efficiency, although 1113 format 2 can also get the same operating goal. 1115 6. Contributors 1117 Contributors who have made major contributions to the 1118 interoperability test are as below: 1120 Hirofumi Yamazaki 1121 NTT Corporation 1122 Tokyo 1123 Japan 1124 Email: yamazaki.horofumi@lab.ntt.co.jp 1126 Rong Jin 1127 Zhejiang Gongshang University 1128 Hangzhou 1129 P.R.China 1130 Email: jinrong@zjsu.edu.cn 1132 Yuta Watanabe 1133 NTT Corporation 1134 Tokyo 1135 Japan 1136 Email: yuta.watanabe@ntt-at.co.jp 1138 Xiaochun Wu 1139 Zhejiang Gongshang University 1140 Hangzhou 1141 P.R.China 1142 Email: spring-403@zjsu.edu.cn 1144 7. Acknowledgements 1146 The authors thank the following test participants: 1148 Chuanhuang Li, Hangzhou BAUD Networks 1149 Ligang Dong, Zhejiang Gongshang University 1150 Bin Zhuge, Zhejiang Gongshang University 1151 Jingjing Zhou, Zhejiang Gongshang University 1152 Liaoyuan Ke, Hangzhou BAUD Networks 1153 Kelei Jin, Hangzhou BAUD Networks 1155 The authors also thank very much to Adrian Farrel, Joel Halpern, Ben 1156 Campbell, Nevil Brownlee, and Sean Turner for their important help in 1157 the document publication process. 1159 8. IANA Considerations 1161 This memo includes no request to IANA. 1163 9. Security Considerations 1165 Developers of ForCES FEs and CEs must take the security 1166 considerations of the ForCES Framework [RFC3746] and the ForCES 1167 Protocol [RFC5810] into account. Also, as specified in the security 1168 considerations section of the SCTP-Based TML for the ForCES Protocol 1169 [RFC5811], the transport-level security has to be ensured by IPsec. 1170 Test results of TML with IPsec supported have been shown in 1171 Section 4.2 in this document. 1173 The tests described in this document used only simple password 1174 security mode. Testing using more sophisticated security is for 1175 future study. 1177 Further testing using key agility is encouraged. The tests reported 1178 here used SCTP TML running over an IPsec tunnel which was established 1179 by Racoon. Key negotiation formed part of this process, but we 1180 believe that the SCTP TML used does not include key agility or 1181 renegotiation. 1183 10. References 1185 10.1. Normative References 1187 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 1188 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 1189 Control Element Separation (ForCES) Protocol 1190 Specification", RFC 5810, March 2010. 1192 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 1193 Layer (TML) for the Forwarding and Control Element 1194 Separation (ForCES) Protocol", RFC 5811, March 2010. 1196 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 1197 Element Separation (ForCES) Forwarding Element Model", RFC 1198 5812, March 2010. 1200 [RFC5813] Haas, R., "Forwarding and Control Element Separation 1201 (ForCES) MIB", RFC 5813, March 2010. 1203 10.2. Informative References 1205 [Ethereal] 1206 , "Ethereal, also named Wireshark, is a protocol analyzer. 1207 The specific Ethereal that was used is an updated 1208 Ethereal, by Fenggen Jia, that can analyze and decode the 1209 ForCES protocol messages", http://www.ietf.org/mail- 1210 archive/web/forces/current/msg03687.html , . 1212 [I-D.ietf-forces-ceha-00] 1213 Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES 1214 Intra-NE High Availability", draft-ietf-forces-ceha-00 1215 (work in progress) [RFC Editor Note: This reference is 1216 intended to indicate a specific version of an Internet- 1217 Draft that was used during interop testing. Please Do NOT 1218 update this reference to a more recent version of the 1219 draft or to an RFC. Please remove this note before 1220 publication] , October 2010. 1222 [I-D.ietf-forces-lfb-lib-03] 1223 Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. 1224 Halpern, "ForCES Logical Function Block (LFB) Library", 1225 draft-ietf-forces-lfb-lib-03 (work in progress) [RFC 1226 Editor Note: This reference is intended to indicate a 1227 specific version of an Internet-Draft that was used during 1228 interop testing. Please Do NOT update this reference to a 1229 more recent version of the draft or to an RFC. Please 1230 remove this note before publication] , December 2010. 1232 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 1233 of IP Control and Forwarding", RFC 3654, November 2003. 1235 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 1236 "Forwarding and Control Element Separation (ForCES) 1237 Framework", RFC 3746, April 2004. 1239 [RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim, 1240 "Implementation Report for Forwarding and Control Element 1241 Separation (ForCES)", RFC 6053, November 2010. 1243 [Racoon] , "Racoon in NetBSD is a well-known IKE daemon performing 1244 the IPsec Key Exchange (IKE) with the peers", 1245 http://www.netbsd.org/docs/network/ipsec/rasvpn.html , . 1247 [Tcpdump] , "Tcpdump is a Linux protocol analyzer. The specific 1248 tcpdump that was used is a modified tcpdump, by Jamal Hadi 1249 Salim, that can analyze and decode the ForCES protocol 1250 messages", http://www.ietf.org/mail-archive/web/forces/ 1251 current/msg03811.html , . 1253 [Teamviewer] 1254 , "TeamViewer connects to any PC or server around the 1255 world within a few seconds. ", http://www.teamviewer.com/ 1256 , . 1258 Authors' Addresses 1260 Weiming Wang 1261 Zhejiang Gongshang University 1262 18 Xuezheng Str., Xiasha University Town 1263 Hangzhou 310018 1264 P.R.China 1266 Phone: +86-571-28877721 1267 Email: wmwang@zjsu.edu.cn 1269 Kentaro Ogawa 1270 NTT Corporation 1271 Tokyo 1272 Japan 1274 Email: ogawa.kentaro@lab.ntt.co.jp 1276 Evangelos Haleplidis 1277 University of Patras 1278 Department of Electrical & Computer Engineering 1279 Patras 26500 1280 Greece 1282 Email: ehalep@ece.upatras.gr 1284 Ming Gao 1285 Hangzhou BAUD Networks 1286 408 Wen-San Road 1287 Hangzhou 310012 1288 P.R.China 1290 Email: gmyyqno1@zjsu.edu.cn 1292 Jamal Hadi Salim 1293 Mojatatu Networks 1294 Ottawa 1295 Canada 1297 Email: hadi@mojatatu.com