idnits 2.17.1 draft-ietf-forces-interop-08.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 (May 23, 2013) is 3989 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5813' is defined on line 1187, but no explicit reference was found in the text == Unused Reference: 'RFC3654' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: 'RFC6053' is defined on line 1226, 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: November 24, 2013 E.H. Haleplidis 7 University of Patras 8 M. Gao 9 Hangzhou BAUD Networks 10 J. Hadi Salim 11 Mojatatu Networks 12 May 23, 2013 14 Interoperability Report for Forwarding and Control Element Separation 15 (ForCES) 16 draft-ietf-forces-interop-08 18 Abstract 20 This document captured 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 has reported the results of 24 the 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 November 24, 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 . . . . . . . . . . . . . 10 76 4. Test Results . . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . 12 78 4.2. TML with IPSec Test . . . . . . . . . . . . . . . . . . . 18 79 4.3. CE High Availability Test . . . . . . . . . . . . . . . . 19 80 4.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . 19 81 5. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 5.1. On Data Encapsulation Format . . . . . . . . . . . . . . 22 83 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 89 10.2. Informative References . . . . . . . . . . . . . . . . . 26 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 92 1. Introduction 94 This document captured 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 Up to date, the 'ForCES Logical Function Block (LFB) Library' 115 document has been publilshed 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 was a third-party routing 245 protocol testing machine, which acted as a router running OSPF and 246 RIP and exchanged routing protocol messages with ForCES routers in 247 the 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 is to test the interoperability on LFB operations among 312 the participants. The connection diagram for the participants is as 313 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 is designed with the following purposes: 335 Firstly, the scenario is designed to verify all kinds of protocol 336 messages with their complex data formats, which are defined in RFC 337 5810. Specially, we try 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 is designed to verify the definition of ForCES 342 LFB Library [I-D.ietf-forces-lfb-lib-03], which define a base set of 343 ForCES LFB classes for typical router functions. Successful test 344 under this scenario will help the validity of the LFB definitions. 346 3.2. Scenario 2 - TML with IPSec 348 This scenario is designed to implement a TML with IPSec, which is the 349 requirement by RFC 5811. TML with IPSec was not implemented and 350 tested in the first ForCES interoperability test as reported by RFC 351 6053. For this reason, in this interoperability test, we 352 specifically designed the test scenario to verify the TML over IPSec 353 channel. 355 In this scenario, tests on LFB operations for Scenario 1 are repeated 356 with the difference that TML is secured via IPSec. This setup 357 scenario allows us to verify whether all interactions between CE and 358 FE can be made correctly under an IPSec TML environment. 360 The connection diagram for this scenario is shown as Figure 5. 361 Because an unfortunate problem with the test system in UoP prevented 362 the deployment of IPSec over TML, this test only took place between 363 the test systems in ZJSU and NTT. 365 +------+ +------+ 366 | CE | | CE | 367 | ZJSU | | NTT | 368 +------+ +------+ 369 | | 370 |TML over IPSec |TML over IPSec 371 +------+ +------+ 372 | FE | | FE | 373 | NTT | | ZJSU | 374 +------+ +------+ 376 Figure 5: Scenario for LFB Operation with TML over IPSec 378 In this scenario, ForCES TML is run over the IPSec channel. 379 Implementers joined in this interoperability used the same third- 380 party software 'Racoon' [Racoon] to establish the IPSec channel. The 381 'Racoon' in NetBSD is an IKE daemon performing the IPsec Key Exchange 382 (IKE) with the peers. 384 ZJSU and NTT made a successful test with the scenario, and the 385 following items were realized: 387 o Internet Key Exchange (IKE) with certificates for endpoint 388 authentication. 390 o Transport Mode Encapsulating Security Payload (ESP). HMAC-SHA1-96 391 for message integrity protection. 393 3.3. Scenario 3 - CE High Availability 395 CE High Availability (CEHA) is tested based on the ForCES CEHA 396 document [I-D.ietf-forces-ceha-00] 398 The design of the setup and the scenario for the CEHA are simplified 399 so as to focus mostly on the mechanics of the CEHA, which are: 401 o Associating with more than one CE. 403 o Switching to backup CE on master CE failure. 405 The connection diagram for the scenario is as shown in Figure 6. 407 master standby master standby 408 +------+ +------+ +------+ +------+ 409 | CE | | CE | | CE | | CE | 410 | ZJSU | | UoP | | NTT | | UoP | 411 +------+ +------+ +------+ +------+ 412 | | | | 413 +----------+ +-----------+ 414 | | 415 +------+ +------+ 416 | FE | | FE | 417 | UoP | | UoP | 418 +------+ +------+ 419 (a) (b) 421 Figure 6: Scenario for CE High Availability 423 In this scenario one FE is connected and associated to a master CE 424 and a backup CE. In the pre-association phase, the FE will be 425 configured to have ZJSU's or NTT's CE as master CE and UoP's CE as 426 standby CE. The CEFailoverPolicy component of the FE Protocol Object 427 LFB that specifies whether the FE is in High Availability mode (value 428 2 or 3) will either be set in the pre-association phase by the FEM 429 interface or in post-association phase by the master CE. 431 If the CEFailoverPolicy value is set to 2 or 3, the FE (in the post- 432 association phase) will attempt to connect and associate with the 433 standby CE. 435 When the master CE is deemed disconnected, either by a TearDown, Loss 436 of Heartbeats or physically disconnected, the FE will assume that the 437 standby CE is now the master CE. The FE will then send an Event 438 Notification, Primary CE Down, to all associated CEs, only the 439 standby CE in this case, with the value of the new master CEID. The 440 standby CE will then respond by sending a configuration message to 441 the CEID component of the FE Protocol Object with its own ID to 442 confirm that the CE considers itself as the master as well. 444 The steps of the CEHA test scenario are as follows: 446 1. In the pre-association phase, setup of FE with master CE and 447 backup CE 449 2. FE connecting and associating with master CE. 451 3. When CEFailoverPolicy is set to 2 or 3, the FE will connect and 452 associate with backup CE. 454 4. Once the master CE is considered disconnected then the FE chooses 455 the first Associated backup CE. 457 5. It sends an Event Notification specifying that the master CE is 458 down and who is now the master CE. 460 6. The new master CE sends a SET Configuration message to the FE 461 setting the CEID value to who is now the new master CE completing 462 the switch. 464 3.4. Scenario 4 - Packet forwarding 466 This test scenario is to verify LFBs like RedirectIn, RedirectOut, 467 IPv4NextHop, IPv4UcastLPM defined by the ForCES LFB library document 468 [I-D.ietf-forces-lfb-lib-03], and more importantly, to verify the 469 combination of the LFBs to implement IP packet forwarding. 471 The connection diagram for this scenario is as Figure 7. 473 +------+ 474 | CE | 475 | NTT | 476 +------+ 477 | ^ 478 | | OSPF 479 | +-------> 480 +------+ +------+ 481 +--------+ | FE | | OSPF | +--------+ 482 |Terminal|------| ZJSU |-------|Router|------|Terminal| 483 +--------+ +------+ +------+ +--------+ 485 <--------------------------------------------> 486 Packet Forwarding 488 (a) 490 +------+ 491 | CE | 492 | ZJSU | 493 +------+ 494 ^ | ^ 495 OSPF | | | OSPF 496 <-----+ | +-----> 497 +-------+ +------+ +------+ 498 +--------+ | OSPF | | FE | | OSPF | +--------+ 499 |Terminal|----|Router |----| NTT |-----|Router|--|Terminal| 500 +--------+ +-------+ +------+ +------+ +--------+ 502 <--------------------------------------------> 503 Packet Forwarding 505 (b) 507 +------+ +------+ 508 | CE | | CE | 509 | NTT | | ZJSU | 510 +------+ +------+ 511 | ^ ^ | 512 | | OSPF | | 513 | +----------+ | 514 +------+ +------+ 515 +--------+ | FE | | FE | +--------+ 516 |Terminal|------| ZJSU |-------| NTT |------|Terminal| 517 +--------+ +------+ +------+ +--------+ 519 <--------------------------------------------> 520 Packet Forwarding 522 (c) 524 Figure 7: Scenario for IP Packet forwarding 526 In case (a), a CE by NTT was connected to an FE by ZJSU to form a 527 ForCES router. A Smartbits test machine with its routing protocol 528 software were used to simulate an OSPF router and were connected with 529 the ForCES router to try to exchange OSPF hello packets and LSA 530 packets among them. Terminals were simulated by Smartbits to send 531 and receive packets. As a result, the CE in the ForCES router need 532 to be configured to run and support OSPF routing protocol. 534 In case (b), a CE by ZJSU was connected to an FE by NTT to form a 535 ForCES router. Two routers running OSPF were simulated and connected 536 to the ForCES router to test if the ForCES router could support OSPF 537 protocol and support packet forwarding. 539 In case (c), two ForCES routers were constructed. One was with CE by 540 NTT and FE by ZJSU and the other was opposite. OSPF and packet 541 forwarding were tested in the environment. 543 Testing process for this scenario is as below: 545 1. Boot terminals and routers, and set IP addresses of their 546 interfaces. 548 2. Boot CE and FE. 550 3. Establish association between CE and FE, and set IP addresses of 551 FEs interfaces. 553 4. Start OSPF among CE and routers, and set FIB on FE. 555 5. Send packets between terminals. 557 4. Test Results 559 4.1. LFB Operation Test 561 The test result is as reported by Figure 8. For the convenience 562 sake, as mentioned earlier, abbreviations of 'Z' in the table means 563 implementation from ZJSU ,'N' implementation from NTT, and 564 'P'implementation from UoP. 566 +-----+----+-----+-----+--------------+-------------------+---------+ 567 |Test#| CE |FE(s)|Oper | LFB | Component | Result | 568 | | | | | | /Capability | | 569 +-----+----+-----+-----+--------------+-------------------+---------+ 570 | 1 | Z | N | GET | FEObject | LFBTopology | Success | 571 | | N | Z | | | | Success | 572 | | P | Z | | | | Success | 573 | | N | P | | | | Success | 574 | | P | N | | | | Success | 575 | | | | | | | | 576 | 2 | Z | N | GET | FEObject | LFBSelector | Success | 577 | | N | Z | | | | Success | 578 | | Z | P | | | | Success | 579 | | P | Z | | | | Success | 580 | | N | P | | | | Success | 581 | | P | N | | | | Success | 582 | | | | | | | | 583 | 3 | Z | N | GET | EtherPHYCop | PHYPortID | Success | 584 | | N | Z | | | | Success | 585 | | Z | P | | | | Success | 586 | | P | Z | | | | Success | 587 | | N | P | | | | Success | 588 | | P | N | | | | Success | 589 | | | | | | | | 590 | 4 | Z | N | GET | EtherPHYCop | AdminStatus | Success | 591 | | N | Z | | | | Success | 592 | | Z | P | | | | Success | 593 | | P | Z | | | | Success | 594 | | N | P | | | | Success | 595 | | P | N | | | | Success | 596 | | | | | | | | 597 | 5 | Z | N | GET | EtherPHYCop | OperStatus | Success | 598 | | N | Z | | | | Success | 599 | | Z | P | | | | Success | 600 | | P | Z | | | | Success | 601 | | N | P | | | | Success | 602 | | P | N | | | | Success | 603 | | | | | | | | 604 | 6 | Z | N | GET | EtherPHYCop | AdminLinkSpeed | Success | 605 | | N | Z | | | | Success | 606 | | Z | P | | | | Success | 607 | | P | Z | | | | Success | 608 | | N | P | | | | Success | 609 | | P | N | | | | Success | 610 | | | | | | | | 611 | 7 | Z | N | GET | EtherPHYCop | OperLinkSpeed | Success | 612 | | N | Z | | | | Success | 613 | | Z | P | | | | Success | 614 | | P | Z | | | | Success | 615 | | N | P | | | | Success | 616 | | P | N | | | | Success | 617 | | | | | | | | 618 | 8 | Z | N | GET | EtherPHYCop | AdminDuplexSpeed | Success | 619 | | N | Z | | | | Success | 620 | | Z | P | | | | Success | 621 | | P | Z | | | | Success | 622 | | N | P | | | | Success | 623 | | P | N | | | | Success | 624 | | | | | | | | 625 | 9 | Z | N | GET | EtherPHYCop | OperDuplexSpeed | Success | 626 | | N | Z | | | | Success | 627 | | Z | P | | | | Success | 628 | | P | Z | | | | Success | 629 | | N | P | | | | Success | 630 | | P | N | | | | Success | 631 | | | | | | | | 632 | 10 | Z | N | GET | EtherPHYCop | CarrierStatus | Success | 633 | | N | Z | | | | Success | 634 | | Z | P | | | | Success | 635 | | P | Z | | | | Success | 636 | | N | P | | | | Success | 637 | | P | N | | | | Success | 638 | | | | | | | | 639 | 11 | Z | N | GET | EtherMACIn | AdminStatus | Success | 640 | | N | Z | | | | Success | 641 | | Z | P | | | | Success | 642 | | P | Z | | | | Success | 643 | | N | P | | | | Success | 644 | | P | N | | | | Success | 645 | | | | | | | | 646 | 12 | Z | N | GET | EtherMACIn | LocalMacAddresses | Success | 647 | | N | Z | | | | Success | 648 | | Z | P | | | | Success | 649 | | P | Z | | | | Success | 650 | | N | P | | | | Success | 651 | | P | N | | | | Success | 652 | | | | | | | | 653 | 13 | Z | N | GET | EtherMACIn | L2Bridging | Success | 654 | | N | Z | | | PathEnable | Success | 655 | | Z | P | | | | Success | 656 | | P | Z | | | | Success | 657 | | N | P | | | | Success | 658 | | P | N | | | | Success | 659 | | | | | | | | 660 | 14 | Z | N | GET | EtherMACIn | PromiscuousMode | Success | 661 | | N | Z | | | | Success | 662 | | Z | P | | | | Success | 663 | | P | Z | | | | Success | 664 | | N | P | | | | Success | 665 | | P | N | | | | Success | 666 | | | | | | | | 667 | 15 | Z | N | GET | EtherMACIn | TxFlowControl | Success | 668 | | N | Z | | | | Success | 669 | | Z | P | | | | Success | 670 | | P | Z | | | | Success | 671 | | N | P | | | | Success | 672 | | P | N | | | | Success | 673 | | | | | | | | 674 | 16 | Z | N | GET | EtherMACIn | RxFlowControl | Success | 675 | | N | Z | | | | Success | 676 | | Z | P | | | | Success | 677 | | P | Z | | | | Success | 678 | | N | P | | | | Success | 679 | | P | N | | | | Success | 680 | | | | | | | | 681 | 17 | Z | N | GET | EtherMACIn | MACInStats | Success | 682 | | N | Z | | | | Success | 683 | | Z | P | | | | Success | 684 | | P | Z | | | | Success | 685 | | N | P | | | | Success | 686 | | P | N | | | | Success | 687 | | | | | | | | 688 | 18 | Z | N | GET | EtherMACOut | AdminStatus | Success | 689 | | N | Z | | | | Success | 690 | | Z | P | | | | Success | 691 | | P | Z | | | | Success | 692 | | N | P | | | | Success | 693 | | P | N | | | | Success | 694 | | | | | | | | 695 | 19 | Z | N | GET | EtherMACOut | MTU | Success | 696 | | N | Z | | | | Success | 697 | | Z | P | | | | Success | 698 | | P | Z | | | | Success | 699 | | N | P | | | | Success | 700 | | P | N | | | | Success | 701 | | | | | | | | 702 | 20 | Z | N | GET | EtherMACOut | TxFlowControl | Success | 703 | | N | Z | | | | Success | 704 | | Z | P | | | | Success | 705 | | P | Z | | | | Success | 706 | | N | P | | | | Success | 707 | | P | N | | | | Success | 708 | | | | | | | | 709 | 21 | Z | N | GET | EtherMACOut | TxFlowControl | Success | 710 | | N | Z | | | | Success | 711 | | Z | P | | | | Success | 712 | | P | Z | | | | Success | 713 | | N | P | | | | Success | 714 | | P | N | | | | Success | 715 | | | | | | | | 716 | 22 | Z | N | GET | EtherMACOut | MACOutStats | Success | 717 | | N | Z | | | | Success | 718 | | Z | P | | | | Success | 719 | | P | Z | | | | Success | 720 | | N | P | | | | Success | 721 | | P | N | | | | Success | 722 | | | | | | | | 723 | 23 | Z | N | GET | ARP |PortV4AddrInfoTable| Success | 724 | | N | Z | | | | Success | 725 | | Z | P | | | | Success | 726 | | P | Z | | | | Success | 727 | | N | P | | | | Success | 728 | | P | N | | | | Success | 729 | | | | | | | | 730 | 24 | Z | N | SET | ARP |PortV4AddrInfoTable| Success | 731 | | N | Z | | | | Success | 732 | | Z | P | | | | Success | 733 | | P | Z | | | | Success | 734 | | N | P | | | | Success | 735 | | P | N | | | | Success | 736 | | | | | | | | 737 | 25 | Z | N | DEL | ARP |PortV4AddrInfoTable| Success | 738 | | N | Z | | | | Success | 739 | | Z | P | | | | Success | 740 | | P | Z | | | | Success | 741 | | N | P | | | | Success | 742 | | P | N | | | | Success | 743 | | | | | | | | 744 | 26 | Z | N | SET | EtherMACIn | LocalMACAddresses | Success | 745 | | N | Z | | | | Success | 746 | | Z | P | | | | Success | 747 | | P | Z | | | | Success | 748 | | N | P | | | | Success | 749 | | P | N | | | | Success | 750 | | | | | | | | 751 | 27 | Z | N | SET | EtherMACIn | MTU | Success | 752 | | N | Z | | | | Success | 753 | | Z | P | | | | Success | 754 | | P | Z | | | | Success | 755 | | N | P | | | | Success | 756 | | P | N | | | | Success | 757 | | | | | | | | 758 | 28 | Z | N | SET | IPv4NextHop | IPv4NextHopTable | Success | 759 | | N | Z | | | | Success | 760 | | Z | P | | | | Success | 761 | | P | Z | | | | Success | 762 | | N | P | | | | Success | 763 | | P | N | | | | Success | 764 | | | | | | | | 765 | 29 | Z | N | SET | IPv4UcastLPM | IPv4PrefixTable | Success | 766 | | N | Z | | | | Success | 767 | | Z | P | | | | Success | 768 | | P | Z | | | | Success | 769 | | N | P | | | | Success | 770 | | P | N | | | | Success | 771 | | | | | | | | 772 | 30 | Z | N | DEL | IPv4NextHop | IPv4NextHopTable | Success | 773 | | N | Z | | | | Success | 774 | | Z | P | | | | Success | 775 | | P | Z | | | | Success | 776 | | N | P | | | | Success | 777 | | P | N | | | | Success | 778 | | | | | | | | 779 | 31 | Z | N | DEL | IPv4UcastLPM | IPv4PrefixTable | Success | 780 | | N | Z | | | | Success | 781 | | Z | P | | | | Success | 782 | | P | Z | | | | Success | 783 | | N | P | | | | Success | 784 | | P | N | | | | Success | 785 | | | | | | | | 786 | 32 | Z | N | SET | EtherPHYCop | AdminStatus | Success | 787 | | N | Z | | | | Success | 788 | | Z | P | | | | Success | 789 | | P | Z | | | | Success | 790 | | N | P | | | | Success | 791 | | P | N | | | | Success | 792 | | | | | | | | 793 | 33 | Z | N | SET | Ether | VlanInputTable | Success | 794 | | N | Z | | Classifier | | Success | 795 | | Z | P | | | | Success | 796 | | P | Z | | | | Success | 797 | | N | P | | | | Success | 798 | | P | N | | | | Success | 799 | | | | | | | | 800 | 34 | Z | N | DEL | Ether | VlanInputTable | Success | 801 | | N | Z | | Classifier | | Success | 802 | | Z | P | | | | Success | 803 | | P | Z | | | | Success | 804 | | N | P | | | | Success | 805 | | P | N | | | | Success | 806 | | | | | | | | 807 | 35 | Z | N | SET | Ether | VlanOutputTable | Success | 808 | | N | Z | | Encapsulator | | Success | 809 | | Z | P | | | | Success | 810 | | P | Z | | | | Success | 811 | | N | P | | | | Success | 812 | | P | N | | | | Success | 813 | | | | | | | | 814 | 36 | Z | N | DEL | Ether | VlanOutputTable | Success | 815 | | N | Z | | Encapsulator | | Success | 816 | | Z | P | | | | Success | 817 | | P | Z | | | | Success | 818 | | N | P | | | | Success | 819 | | P | N | | | | Success | 820 +-----+----+-----+-----+--------------+-------------------+---------+ 822 Figure 8: LFB Operation Test Results 824 Note on test #1 and #2: 826 On the wire format of encapsulation on array, only the case of 827 FULLDATA vs SPARSEDATA was tested. 829 It is very common for CE to get information of FEobject LFB in FE so 830 as to know status on all active LFBs in the FE. Hence, the two tests 831 were specifically designed. 833 4.2. TML with IPSec Test 835 In this scenario, the ForCES TML was run over IPSec. Implementers 836 joined this interoperability test used the same third-party tool 837 software 'Racoon' [Racoon] to establish IPSec channel. Typical LFB 838 operation tests as in Scenario 1 were repeated with the IPSec enabled 839 TML. 841 As mentioned, this scenario only took place between implementers of 842 ZJSU and NTT. 844 The TML with IPSec test results are reported by Figure 9. 846 +-----+----+-----+-----+--------------+-------------------+---------+ 847 |Test#| CE |FE(s)|Oper | LFB | Component/ | Result | 848 | | | | | | Capability | | 849 +-----+----+-----+-----+--------------+-------------------+---------+ 850 | 1 | Z | N | GET | FEObject | LFBTopology | Success | 851 | | N | Z | | | | Success | 852 | | | | | | | | 853 | 2 | Z | N | GET | FEObject | LFBSelectors | Success | 854 | | N | Z | | | | Success | 855 | | | | | | | | 856 | 3 | Z | N | SET | Ether | VlanInputTable | Success | 857 | | N | Z | | Classifier | | Success | 858 | | | | | | | | 859 | 4 | Z | N | DEL | Ether | VlanInputTable | Success | 860 | | N | Z | | Classifier | | Success | 861 +-----+----+-----+-----+--------------+-------------------+---------+ 863 Figure 9: TML with IPSec Test Results 865 4.3. CE High Availability Test 867 In this scenario, one FE connected and associated with a master CE 868 and a backup CE. When the master CE was deemed disconnected, the FE 869 would attempt to find another associated CE to become the master CE. 871 The CEHA scenario as was described by Scenario 3 was completed 872 successfully for both setups. 874 Due to a bug in one of the FEs, an interesting issue was caught: it 875 was observed that the buggy FE took up to a second to failover. It 876 was eventually found that the issue was due to the FE's 877 prioritization of the different CEs. All messages from the backup CE 878 were being ignored unless the master CE was disconnected. 880 While the bug was fixed and the CEHA scenario was completed 881 successfully, the authors felt it was important to capture the 882 implementation issue in this document. The recommended approach is 883 the following: 885 o The FE should receive and handle messages first from the master CE 886 on all priority channels to maintain proper functionality and then 887 receive and handle messages from the backup CEs. 889 o Only when the FE is attempting to associate with the backup CEs, 890 then the FE should receive and handle messages per priority 891 channel from all CEs. When all backup CEs are associated with or 892 deemed unreachable, then the FE should return to receiving and 893 handling messages first from the master CE. 895 4.4. Packet Forwarding Test 897 As described in the ForCES LFB library [I-D.ietf-forces-lfb-lib-03], 898 packet forwarding is implemented by a set of LFB classes that compose 899 a processing path for packets. In this test scenario, as shown in 900 Figure 7, a ForCES router running OSPF protocol was constructed. In 901 addition, a set of LFBs including RedirectIn, RedirectOut, 902 IPv4UcastLPM, and IPv4NextHop LFBs were used. RedirectIn and 903 RedirectOut LFBs redirected OSPF hello and LSA packets from and to 904 CE. A Smartbits test machine was used to simulate an OSPF router and 905 exchange the OSPF hello and LSA packets with CE in ForCES router. 907 In Figure 7, case (a) and case (b) both needed a RedirectIn LFB to 908 send OSPF packets generated by CE to FE by use of ForCES packet 909 redirect messages. The OSPF packets were further sent to an outside 910 OSPF Router by the FE via forwarding LFBs including IPv4NextHop and 911 IPv4UcastLPM LFBs. A RedirectOut LFB in the FE was used to send OSPF 912 packets received from outside OSPF Router to CE by ForCES packet 913 redirect messages. 915 By running OSPF, the CE in the ForCES router could generate new 916 routes and load them to routing table in FE. The FE was then able to 917 forward packets according to the routing table. 919 The test results are as shown in Figure 10 921 +-----+----+-----+-------------------------+--------------+---------+ 922 |Test#| CE |FE(s)| Item | LFBs Related | Result | 923 +-----+----+-----+-------------------------+--------------+---------+ 924 | 1 | N | Z | IPv4NextHopTable SET | IPv4NextHop | Success | 925 | | | | | | | 926 | 2 | N | Z | IPv4PrefixTable SET | IPv4UcastLPM | Success | 927 | | | | | | | 928 | 3 | N | Z |Redirect OSPF packet from| RedirectIn | Success | 929 | | | | CE to SmartBits | | | 930 | | | | | | | 931 | 4 | N | Z |Redirect OSPF packet from| RedirectOut | Success | 932 | | | | SmartBits to CE | | | 933 | | | | | | | 934 | 5 | N | Z | Metadata in | RedirectOut | Success | 935 | | | | redirect message | RedirectIn | | 936 | | | | | | | 937 | 6 | N | Z | OSPF neighbor discovery | RedirectOut | Success | 938 | | | | | RedirectIn | | 939 | | | | | | | 940 | 7 | N | Z | OSPF DD exchange | RedirectOut | Success | 941 | | | | | RedirectIn | | 942 | | | | | IPv4NextHop | | 943 | | | | | | | 944 | 8 | N | Z | OSPF LSA exchange | RedirectOut | Success | 945 | | | | | RedirectIn | | 946 | | | | | IPv4NextHop | | 947 | | | | | IPv4UcastLPM| | 948 | | | | | | | 949 | 9 | N | Z | Data Forwarding | RedirectOut | Success | 950 | | | | | RedirectIn | | 951 | | | | | IPv4NextHop | | 952 | | | | | IPv4UcastLPM| | 953 | | | | | | | 954 | 10 | Z | N | IPv4NextHopTable SET | IPv4NextHop | Success | 955 | | | | | | | 956 | 11 | Z | N | IPv4PrefixTable SET | IPv4UcastLPM| Success | 957 | | | | | | | 958 | 12 | Z | N |Redirect OSPF packet from| RedirectIn | Success | 959 | | | | CE to other OSPF router | | | 960 | | | | | | | 961 | 13 | Z | N |Redirect OSPF packet from| RedirectOut | Success | 962 | | | |other OSPF router to CE | | | 963 | | | | | | | 964 | 14 | Z | N | Metadata in | RedirectOut | Success | 965 | | | | redirect message | RedirectIn | | 966 | | | | | | | 967 | 15 | Z | N |OSPF neighbor discovery | RedirectOut | Success | 968 | | | | | RedirectIn | | 969 | | | | | | | 970 | 16 | Z | N | OSPF DD exchange | RedirectOut | Failure | 971 | | | | | RedirectIn | | 972 | | | | | IPv4NextHop | | 973 | | | | | | | 974 | 17 | Z | N | OSPF LSA exchange | RedirectOut | Failure | 975 | | | | | RedirectIn | | 976 | | | | | IPv4NextHop | | 977 | | | | | IPv4UcastLPM| | 978 +-----+----+-----+-------------------------+--------------+---------+ 980 Figure 10: Packet Forwarding Test Results 982 Note on test #1 and #2: 984 The implementer found a multicast route pointing to localhost had to 985 be manually set before a redirect channel could work normally. 987 Note on test #3 to #9: 989 During the test, OSPF packets received from CE were found by Ethereal 990 /Wireshark with checksum errors in FE. Because the test time was 991 quite limited, implementer of the CE did not try to make efforts to 992 find and solve the checksum error, instead, the FE had tried to 993 correct the checksum not to let the Smartbits drop the packets. Note 994 that such solution does not affect the test results for this 995 scenario. 997 Comment on Test #16 and #17: 999 The two test items failed. Note that Test #7 and #8 were identical 1000 to the tests, only with CE and FE implementers were exchanged. 1001 Moreover, test #12 and #13 showed that the redirect channel worked 1002 well. Therefore, it can be reasonably inferred that the problem 1003 caused the failure was from the implementations, rather than from the 1004 ForCES protocol itself or from misunderstanding of implementations on 1005 the protocol specification. Although the failure made the OSPF 1006 interoperability test incomplete, it did not show interoperability 1007 problem. More test work is needed to verify the OSPF 1008 interoperability. 1010 5. Discussions 1012 5.1. On Data Encapsulation Format 1014 In the first day of the test, it was found that the LFB inter- 1015 operations about tables all failed. It was eventually found the 1016 failure was because that different data encapsulation methods for 1017 ForCES protocol messages were taken by different implementations. 1018 The issue is described in detail as below: 1020 Assuming that an LFB has two components, one is a struct with ID 1 1021 and the other an array with ID 2, further with two components of u32 1022 both inside, as below: 1024 struct1: type struct, ID=1 1025 components are: 1026 a, type u32, ID=1 1027 b, type u32, ID=2 1029 table1: type array, ID=2 1030 components for each row are (a struct of): 1031 x, type u32, ID=1 1032 y, type u32, ID=2 1034 1. On response of PATH-DATA format 1036 When a CE sends a config/query ForCES protocol message to an FE from 1037 a different implementer, the CE probably receives response from the 1038 FE with different PATH-DATA encapsulation format. For example, if a 1039 CE sends a query message with a path of 1 to a third party FE to 1040 manipulate struct 1 as defined above, the FE is probable to generate 1041 response with two different PATH-DATA encapsulation format: one is 1042 the value with FULL/SPARSE-DATA and the other is the value with many 1043 parallel PATH-DATA TLV and nested PATH-DATA TLV, as below: 1045 format 1: 1046 OPER = GET-RESPONSE-TLV 1047 PATH-DATA-TLV: 1048 IDs=1 1049 FULLDATA-TLV containing valueof(a),valueof(b) 1050 format 2: 1051 OPER = GET-RESPONSE-TLV 1052 PATH-DATA-TLV: 1053 IDs=1 1054 PATH-DATA-TLV: 1055 IDs=1 1056 FULLDATA-TLV containing valueof(a) 1057 PATH-DATA-TLV: 1058 IDs=2 1059 FULLDATA-TLV containing valueof(b) 1061 The interoperability testers witnessed that a ForCES element (CE or 1062 FE) sender is free to choose whatever data structure that IETF ForCES 1063 documents define and best suits the element, while a ForCES element 1064 (CE or FE) should be able to accept and process information (requests 1065 and responses) that use any legitimate structure defined by IETF 1066 ForCES documents. While in the case a ForCES element is free to 1067 choose any legitimate data structure as a response, it is preferred 1068 the ForCES element responds in the same format that the request was 1069 made, as it is most probably the data structure is the request sender 1070 looks forward to receive. 1072 2. On operation to array 1074 An array operation may also have several different data encapsulation 1075 formats. For instance, if a CE sends a config message to table 1 1076 with a path of (2.1), which refers to component with ID=2, which is 1077 an array, and the second ID is the row, so row 1, it may be 1078 encapsulated with three formats as below: 1080 format 1: 1081 OPER = SET-TLV 1082 PATH-DATA-TLV: 1083 IDs=2.1 1084 FULLDATA-TLV containing valueof(x),valueof(y) 1085 format 2: 1086 OPER = SET-TLV 1087 PATH-DATA-TLV: 1088 IDs=2.1 1089 PATH-DATA-TLV: 1090 IDs=1 1091 FULLDATA-TLV containing valueof(x) 1093 PATH-DATA-TLV 1094 IDs=2 1095 FULLDATA-TLV containing valueof(y) 1097 Moreover, if CE is targeting the whole array, for example if the 1098 array is empty and CE wants to add the first row to the table, it 1099 could also adopt another format: 1101 format 3: 1102 OPER = SET-TLV 1103 PATH-DATA-TLV: 1104 IDs=2 1105 FULLDATA-TLV containing rowindex=1,valueof(x),valueof(y) 1107 The interoperability test experience showed that format 1 and format 1108 3, which take full advantage of multiple data elements description in 1109 one TLV of FULLDATA-TLV, get more efficiency, although format 2 can 1110 also get the same operating goal. 1112 6. Contributors 1114 Contributors who have made major contributions to the 1115 interoperability test are as below: 1117 Hirofumi Yamazaki 1118 NTT Corporation 1119 Tokyo 1120 Japan 1121 Email: yamazaki.horofumi@lab.ntt.co.jp 1123 Rong Jin 1124 Zhejiang Gongshang University 1125 Hangzhou 1126 P.R.China 1127 Email: jinrong@zjsu.edu.cn 1129 Yuta Watanabe 1130 NTT Corporation 1131 Tokyo 1132 Japan 1133 Email: yuta.watanabe@ntt-at.co.jp 1135 Xiaochun Wu 1136 Zhejiang Gongshang University 1137 Hangzhou 1138 P.R.China 1139 Email: spring-403@zjsu.edu.cn 1141 7. Acknowledgements 1143 The authors thank the following test participants: 1145 Chuanhuang Li, Hangzhou BAUD Networks 1146 Ligang Dong, Zhejiang Gongshang University 1147 Bin Zhuge, Zhejiang Gongshang University 1148 Jingjing Zhou, Zhejiang Gongshang University 1149 Liaoyuan Ke, Hangzhou BAUD Networks 1150 Kelei Jin, Hangzhou BAUD Networks 1152 The authors also thank very much to Adrian Farrel, Joel Halpern, Ben 1153 Campbell, and Nevil Brownlee for their important help in the document 1154 publication process. 1156 8. IANA Considerations 1158 This memo includes no request to IANA. 1160 9. Security Considerations 1162 Developers of ForCES FEs and CEs must take the security 1163 considerations of the ForCES Framework [RFC3746] and the ForCES 1164 Protocol [RFC5810] into account. Also, as specified in the security 1165 considerations section of the SCTP-Based TML for the ForCES Protocol 1166 [RFC5811], the transport-level security has to be ensured by IPsec. 1167 Test results of TML with IPsec supported have been shown in 1168 Section 4.2 in this document. 1170 10. References 1172 10.1. Normative References 1174 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 1175 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 1176 Control Element Separation (ForCES) Protocol 1177 Specification", RFC 5810, March 2010. 1179 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 1180 Layer (TML) for the Forwarding and Control Element 1181 Separation (ForCES) Protocol", RFC 5811, March 2010. 1183 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 1184 Element Separation (ForCES) Forwarding Element Model", RFC 1185 5812, March 2010. 1187 [RFC5813] Haas, R., "Forwarding and Control Element Separation 1188 (ForCES) MIB", RFC 5813, March 2010. 1190 10.2. Informative References 1192 [Ethereal] 1193 , "Ethereal, also named Wireshark, is a protocol analyzer. 1194 The specific Ethereal that was used is an updated 1195 Ethereal, by Fenggen Jia, that can analyze and decode the 1196 ForCES protocol messages", http://www.ietf.org/mail- 1197 archive/web/forces/current/msg03687.html , . 1199 [I-D.ietf-forces-ceha-00] 1200 Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES 1201 Intra-NE High Availability", draft-ietf-forces-ceha-00 1202 (work in progress) [RFC Editor Note: This reference is 1203 intended to indicate a specific version of an Internet- 1204 Draft that was used during interop testing. Please Do NOT 1205 update this reference to a more recent version of the 1206 draft or to an RFC. Please remove this note before 1207 publication] , October 2010. 1209 [I-D.ietf-forces-lfb-lib-03] 1210 Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. 1211 Halpern, "ForCES Logical Function Block (LFB) Library", 1212 draft-ietf-forces-lfb-lib-03 (work in progress) [RFC 1213 Editor Note: This reference is intended to indicate a 1214 specific version of an Internet-Draft that was used during 1215 interop testing. Please Do NOT update this reference to a 1216 more recent version of the draft or to an RFC. Please 1217 remove this note before publication] , December 2010. 1219 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 1220 of IP Control and Forwarding", RFC 3654, November 2003. 1222 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 1223 "Forwarding and Control Element Separation (ForCES) 1224 Framework", RFC 3746, April 2004. 1226 [RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim, 1227 "Implementation Report for Forwarding and Control Element 1228 Separation (ForCES)", RFC 6053, November 2010. 1230 [Racoon] , "Racoon in NetBSD is a well-known IKE daemon performing 1231 the IPsec Key Exchange (IKE) with the peers", 1232 http://www.netbsd.org/docs/network/ipsec/rasvpn.html , . 1234 [Tcpdump] , "Tcpdump is a Linux protocol analyzer. The specific 1235 tcpdump that was used is a modified tcpdump, by Jamal Hadi 1236 Salim, that can analyze and decode the ForCES protocol 1237 messages", http://www.ietf.org/mail-archive/web/forces/ 1238 current/msg03811.html , . 1240 [Teamviewer] 1241 , "TeamViewer connects to any PC or server around the 1242 world within a few seconds. ", http://www.teamviewer.com/ 1243 , . 1245 Authors' Addresses 1247 Weiming Wang 1248 Zhejiang Gongshang University 1249 18 Xuezheng Str., Xiasha University Town 1250 Hangzhou 310018 1251 P.R.China 1253 Phone: +86-571-28877721 1254 Email: wmwang@zjsu.edu.cn 1256 Kentaro Ogawa 1257 NTT Corporation 1258 Tokyo 1259 Japan 1261 Email: ogawa.kentaro@lab.ntt.co.jp 1263 Evangelos Haleplidis 1264 University of Patras 1265 Department of Electrical & Computer Engineering 1266 Patras 26500 1267 Greece 1269 Email: ehalep@ece.upatras.gr 1271 Ming Gao 1272 Hangzhou BAUD Networks 1273 408 Wen-San Road 1274 Hangzhou 310012 1275 P.R.China 1277 Email: gmyyqno1@zjsu.edu.cn 1278 Jamal Hadi Salim 1279 Mojatatu Networks 1280 Ottawa 1281 Canada 1283 Email: hadi@mojatatu.com