idnits 2.17.1 draft-ietf-forces-implementation-report-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2010) is 5168 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'N' is mentioned on line 525, but not defined == Unused Reference: 'RFC2629' is defined on line 1326, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1329, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 1340, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Haleplidis 3 Internet-Draft University of Patras 4 Intended status: Informational K. Ogawa 5 Expires: August 29, 2010 NTT Corporation 6 W. Wang 7 Zhejiang Gongshang University 8 J. Hadi Salim 9 Mojatatu Networks 10 February 25, 2010 12 Implementation Report for ForCES 13 draft-ietf-forces-implementation-report-01 15 Abstract 17 Forwarding and Control Element Separation (ForCES) defines an 18 architectural framework and associated protocols to standardize 19 information exchange between the control plane and the forwarding 20 plane in a ForCES Network Element (ForCES NE). RFC3654 has defined 21 the ForCES requirements, and RFC3746 has defined the ForCES 22 framework. 24 This document is an implementation report of the ForCES Protocol, 25 Model and SCTP-TML, including the report on interoperability testing 26 and the current state of ForCES implementations. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on August 29, 2010. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 Table of Contents 68 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 70 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 7 73 2.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 7 74 2.3. Transport mapping layer . . . . . . . . . . . . . . . . . 7 75 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Detail Section . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6.1. Implementation Experience . . . . . . . . . . . . . . . . 11 80 6.1.1. ForCES Protocol Features . . . . . . . . . . . . . . . 11 81 6.1.1.1. Protocol Messages . . . . . . . . . . . . . . . . 12 82 6.1.1.2. MainHeader Handling . . . . . . . . . . . . . . . 13 83 6.1.1.3. TLV Handling . . . . . . . . . . . . . . . . . . . 14 84 6.1.1.4. Operation Types Supported . . . . . . . . . . . . 15 85 6.1.1.5. ForCES Protocol Advanced Features . . . . . . . . 16 86 6.1.2. ForCES Model Features . . . . . . . . . . . . . . . . 16 87 6.1.2.1. Basic Atomic Types Supported . . . . . . . . . . . 17 88 6.1.2.2. Compound Types Supported . . . . . . . . . . . . . 18 89 6.1.2.3. LFBs Supported . . . . . . . . . . . . . . . . . . 18 90 6.1.3. ForCES SCTP-TML Features . . . . . . . . . . . . . . . 21 91 6.1.3.1. TML Priority Ports . . . . . . . . . . . . . . . . 21 92 6.1.3.2. Message Handling at specific priorities . . . . . 22 93 6.1.3.3. TML Security Feature . . . . . . . . . . . . . . . 23 94 6.2. Interoperability Report . . . . . . . . . . . . . . . . . 23 95 6.2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . 24 96 6.2.1.1. Scenario 1 - Pre-association Setup . . . . . . . . 24 97 6.2.1.2. Scenario 2 - TML priority channels connection . . 25 98 6.2.1.3. Scenario 3 - Association Setup - Association 99 Complete . . . . . . . . . . . . . . . . . . . . . 25 100 6.2.1.4. Scenario 4 - CE query . . . . . . . . . . . . . . 26 101 6.2.1.5. Scenario 5 - Heartbeat monitoring . . . . . . . . 26 102 6.2.1.6. Scenario 6 - Simple Config Command . . . . . . . . 26 103 6.2.1.7. Scenario 7 - Association Teardown . . . . . . . . 27 104 6.2.2. Tested Features . . . . . . . . . . . . . . . . . . . 27 105 6.2.2.1. ForCES Protocol Features . . . . . . . . . . . . . 27 106 6.2.2.2. ForCES Model Features . . . . . . . . . . . . . . 29 107 6.2.2.3. ForCES SCTP-TML Features . . . . . . . . . . . . . 32 108 6.2.3. Interoperability Results . . . . . . . . . . . . . . . 33 109 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 110 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 111 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 113 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 114 10.2. Informative References . . . . . . . . . . . . . . . . . . 38 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 117 1. Terminology and Conventions 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 1.2. Definitions 127 This document follows the terminology defined by the ForCES 128 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 129 The definitions below are repeated below for clarity. 131 Control Element (CE) - A logical entity that implements the ForCES 132 protocol and uses it to instruct one or more FEs on how to process 133 packets. CEs handle functionality such as the execution of 134 control and signaling protocols. 136 Forwarding Element (FE) - A logical entity that implements the 137 ForCES protocol. FEs use the underlying hardware to provide per- 138 packet processing and handling as directed/controlled by one or 139 more CEs via the ForCES protocol. 141 LFB (Logical Function Block) - The basic building block that is 142 operated on by the ForCES protocol. The LFB is a well defined, 143 logically separable functional block that resides in an FE and is 144 controlled by the CE via ForCES protocol. The LFB may reside at 145 the FE's datapath and process packets or may be purely an FE 146 control or configuration entity that is operated on by the CE. 147 Note that the LFB is a functionally accurate abstraction of the 148 FE's processing capabilities, but not a hardware-accurate 149 representation of the FE implementation. 151 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. 152 An LFB Instance represents an LFB Class (or Type) existence. 153 There may be multiple instances of the same LFB Class (or Type) in 154 an FE. An LFB Class is represented by an LFB Class ID, and an LFB 155 Instance is represented by an LFB Instance ID. As a result, an 156 LFB Class ID associated with an LFB Instance ID uniquely specifies 157 an LFB existence. 159 LFB Metadata - Metadata is used to communicate per-packet state 160 from one LFB to another, but is not sent across the network. The 161 FE model defines how such metadata is identified, produced and 162 consumed by the LFBs. It defines the functionality but not how 163 metadata is encoded within an implementation. 165 LFB Components - Operational parameters of the LFBs that must be 166 visible to the CEs are conceptualized in the FE model as the LFB 167 components. The LFB components include, for example, flags, 168 single parameter arguments, complex arguments, and tables that the 169 CE can read and/or Components write via the ForCES protocol (see 170 below). 172 ForCES Protocol - While there may be multiple protocols used 173 within the overall ForCES architecture, the term "ForCES protocol" 174 and "protocol" refer to the Fp reference points in the ForCES 175 Framework in [RFC3746]. This protocol does not apply to CE-to-CE 176 communication, FE-to-FE communication, or to communication between 177 FE and CE managers. Basically, the ForCES protocol works in a 178 master- slave mode in which FEs are slaves and CEs are masters. 179 This document defines the specifications for this ForCES protocol. 181 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 182 ForCES protocol architecture that uses the capabilities of 183 existing transport protocols to specifically address protocol 184 message transportation issues, such as how the protocol messages 185 are mapped to different transport media (like TCP, IP, ATM, 186 Ethernet, etc), and how to achieve and implement reliability, 187 multicast, ordering, etc. The ForCES TML specifications are 188 detailed in separate ForCES documents, one for each TML. 190 2. Introduction 192 This is an implementation report for the ForCES protocol, model and 193 SCTP-TML documents and includes an interoperability report. 195 It follows the outline suggested by [RFC5657]. 197 Forwarding and Control Element Separation (ForCES) defines an 198 architectural framework and associated protocols to standardize 199 information exchange between the control plane and the forwarding 200 plane in a ForCES Network Element (ForCES NE). [RFC3654] has defined 201 the ForCES requirements, and [RFC3746] has defined the ForCES 202 framework. 204 2.1. ForCES Protocol 206 The ForCES protocol works in a master-slave mode in which FEs are 207 slaves and CEs are masters. The protocol includes commands for 208 transport of Logical Function Block (LFB) configuration information, 209 association setup, status, and event notifications, etc. The reader 210 is encouraged to read FE-protocol [I-D.ietf-forces-protocol] for 211 further information. 213 2.2. ForCES Model 215 The FE-MODEL [I-D.ietf-forces-model] presents a formal way to define 216 FE Logical Function Blocks (LFBs) using XML. LFB configuration 217 components, capabilities, and associated events are defined when the 218 LFB is formally created. The LFBs within the FE are accordingly 219 controlled in a standardized way by the ForCES protocol. 221 2.3. Transport mapping layer 223 The TML transports the PL messages. The TML is where the issues of 224 how to achieve transport level reliability, congestion control, 225 multicast, ordering, etc. are handled. All ForCES Protocol Layer 226 implementations MUST be portable across all TMLs. Although more than 227 one TML may be standardized for the ForCES Protocol, all 228 implementations MUST IMPLEMENT the SCTP TML 229 [I-D.ietf-forces-sctptml]. 231 3. Summary 233 The authors attest that the ForCES Protocol, Model and SCTP-TML meet 234 the requirements for Draft Standard. 236 Three independent implementations, NTT Japan, University of Patras 237 and Zhejiang Gongshang University, were surveyed and found to already 238 implement all the major features. All implementors mentioned they 239 will be implementing all missing features in the future. 241 An interop test was conducted in July/2009 for all three 242 implementations. Two other organizations, Mojatatu Networks and 243 Hangzhou Baud Information and Networks Technology Corporation, which 244 independently extended two different well known public domain 245 protocol analyzers, Ethereal/Wireshark and tcpdump, also participated 246 in the interop for a total of five independent organizations 247 implementing. The two protocol analyzers were used to verify 248 validity of ForCEs protocol messages (and in some cases semantics). 250 There were no notable difficulties in the interoperability test and 251 almost all issues were code bugs that were dealt with mostly on site 252 and tests repeated successfully. 254 4. Methodology 256 This report has both an implementation experience survey as well as 257 the results of the interoperability test. 259 The survey information was gathered after implementors answered a 260 brief questionnaire with all ForCES Protocol, Model and SCTP-TML 261 features. The results can be seen in ForCES Features (Section 6.1) 263 The interoperability results were part of the interoperability test. 264 Extended Ethereal and extended Tcpdump were used to verify the 265 results. The results can be seen in Interoperability Report 266 (Section 6.2) 268 5. Exceptions 270 The core features of the ForCES Protocol, Model and SCTP-TML have 271 been implemented and tested in an interop in July, 2009. The 272 intention of the interop testing was to validate that all the main 273 features of the 3 core documents were inter-operable amongst 274 different implementations. The tested features can be seen in Tested 275 Features (Section 6.2.2). 277 Different organizations surveyed have implemented certain features 278 but not others. This approach is driven by presence of different 279 LFBs the different organizations have currently implemented. All 280 organizations surveyed have indicated intention to implement all 281 outstanding features in due time. The implemented features can be 282 seen in Section 6.1. 284 The mandated TML security requirement, IPSec, was not validated 285 during the interop and is not discussed in this document. Since 286 IPSec is well known and is widely deployed not testing in presence of 287 IPSec does not invalidate the tests done. 289 Although the SCTP priority ports have been changed since the 290 interoperability test with the latest SCTP-TML draft, the change has 291 no impact in the validity of the interoperability test. 293 6. Detail Section 295 6.1. Implementation Experience 297 Three different organizations have implemented the ForCES Protocol, 298 Model and SCTP-TML and answered a questionnaire. These are: 300 o NTT Japan. 302 o University of Patras. 304 o Zhejiang Gongshang University. 306 Also, not actual implementations, but extensions on protocol 307 analyzers capable of understanding ForCES protocol messages, also are 308 considered part of an implementation as they can offer validation of 309 exchanged protocol messages. Two such extensions have been created: 311 o Extension to Ethereal/Wireshark [ethereal]. 313 o Extension to Tcpdump [tcpdump]. 315 All implementors were asked regarding the ForCES features they have 316 implemented. For every item listed the respondents indicated whether 317 they had implemented, will implement, or won't implement at all. 319 6.1.1. ForCES Protocol Features 320 6.1.1.1. Protocol Messages 322 +------------------+-------------+---------------+------------------+ 323 | Protocol Message | NTT Japan | University of | Zhejiang | 324 | | | Patras | Gongshang | 325 | | | | University | 326 +------------------+-------------+---------------+------------------+ 327 | Association | Implemented | Implemented | Implemented | 328 | Setup | | | | 329 | | | | | 330 | Association | Implemented | Implemented | Implemented | 331 | Setup Response | | | | 332 | | | | | 333 | Association | Implemented | Implemented | Implemented | 334 | TearDown | | | | 335 | | | | | 336 | Configuration | Implemented | Implemented | Implemented | 337 | | | | | 338 | Configuration | Implemented | Implemented | Implemented | 339 | Response | | | | 340 | | | | | 341 | Query | Implemented | Implemented | Implemented | 342 | | | | | 343 | Query Response | Implemented | Implemented | Implemented | 344 | | | | | 345 | Event | Implemented | Will | Implemented | 346 | Notification | | Implement | | 347 | | | | | 348 | Packet Redirect | Implemented | Will | Implemented | 349 | | | Implement | | 350 | | | | | 351 | HeartBeat | Implemented | Implemented | Implemented | 352 +------------------+-------------+---------------+------------------+ 354 ForCES Protocol Message 356 6.1.1.2. MainHeader Handling 358 +---------------+-------------+----------------+--------------------+ 359 | Header Field | NTT Japan | University of | Zhejiang Gongshang | 360 | | | Patras | University | 361 +---------------+-------------+----------------+--------------------+ 362 | Correlator | Implemented | Implemented | Implemented | 363 | | | | | 364 | Acknowledge | Implemented | Implemented | Implemented | 365 | Flag | | | | 366 | | | | | 367 | Priority Flag | Will | Implemented | Implemented | 368 | | Implement | | | 369 | | | | | 370 | Execution | Will | Will Implement | Implemented | 371 | Mode Flag | Implement | | | 372 | | | | | 373 | Atomic Flag | Will | Will Implement | Implemented | 374 | | Implement | | | 375 | | | | | 376 | Transaction | Will | Will Implement | Implemented | 377 | Flag | Implement | | | 378 +---------------+-------------+----------------+--------------------+ 380 MainHeader Handling 382 6.1.1.3. TLV Handling 384 +------------------+-------------+--------------+-------------------+ 385 | TLV | NTT Japan | University | Zhejiang | 386 | | | of Patras | Gongshang | 387 | | | | University | 388 +------------------+-------------+--------------+-------------------+ 389 | Redirect TLV | Implemented | Will | Implemented | 390 | | | Implement | | 391 | | | | | 392 | Association | Implemented | Implemented | Implemented | 393 | Setup Result TLV | | | | 394 | | | | | 395 | Association | Implemented | Implemented | Implemented | 396 | TearDown Reason | | | | 397 | TLV | | | | 398 | | | | | 399 | LFBSelector TLV | Implemented | Implemented | Implemented | 400 | | | | | 401 | Operation TLV | Implemented | Implemented | Implemented | 402 | | | | | 403 | PathData TLV | Implemented | Implemented | Implemented | 404 | | | | | 405 | KeyInfo TLV | Will | Will | Implemented | 406 | | Implement | Implement | | 407 | | | | | 408 | FullData TLV | Implemented | Implemented | Implemented | 409 | | | | | 410 | SparseData TLV | Will | Will | Implemented | 411 | | Implement | Implement | | 412 | | | | | 413 | ILV | Will | Will | Implemented | 414 | | Implement | Implement | | 415 | | | | | 416 | Metadata TLV | Will | Will | Implemented | 417 | | Implement | Implement | | 418 | | | | | 419 | Result TLV | Implemented | Implemented | Implemented | 420 | | | | | 421 | Redirect Data | Implemented | Will | Implemented | 422 | TLV | | Implement | | 423 +------------------+-------------+--------------+-------------------+ 425 TLVs Supported 427 6.1.1.4. Operation Types Supported 429 +--------------+-------------+-----------------+--------------------+ 430 | Operation | NTT Japan | University of | Zhejiang Gongshang | 431 | | | Patras | University | 432 +--------------+-------------+-----------------+--------------------+ 433 | Set | Implemented | Implemented | Implemented | 434 | | | | | 435 | Set Prop | Will | Will Implement | Implemented | 436 | | Implement | | | 437 | | | | | 438 | Set Response | Implemented | Implemented | Implemented | 439 | | | | | 440 | Set Prop | Will | Will Implement | Implemented | 441 | Response | Implement | | | 442 | | | | | 443 | Del | Implemented | Will Implement | Implemented | 444 | | | | | 445 | Del Response | Implemented | Will Implement | Implemented | 446 | | | | | 447 | Get | Implemented | Implemented | Implemented | 448 | | | | | 449 | Get Prop | Will | Will Implement | Implemented | 450 | | Implement | | | 451 | | | | | 452 | Get Response | Implemented | Implemented | Implemented | 453 | | | | | 454 | Get Prop | Will | Will Implement | Implemented | 455 | Response | Implement | | | 456 | | | | | 457 | Report | Implemented | Implemented | Implemented | 458 | | | | | 459 | Commit | Will | Will Implement | Implemented | 460 | | Implement | | | 461 | | | | | 462 | Commit | Will | Will Implement | Implemented | 463 | Response | Implement | | | 464 | | | | | 465 | TRComp | Will | Will Implement | Implemented | 466 | | Implement | | | 467 +--------------+-------------+-----------------+--------------------+ 469 Operation Type Supported 471 6.1.1.5. ForCES Protocol Advanced Features 473 +---------------+-------------+----------------+--------------------+ 474 | Feature | NTT Japan | University of | Zhejiang Gongshang | 475 | | | Patras | University | 476 +---------------+-------------+----------------+--------------------+ 477 | Execute Mode | Will | Will Implement | Implemented | 478 | | Implement | | | 479 | | | | | 480 | Transaction | Will | Will Implement | Implemented | 481 | | Implement | | | 482 | | | | | 483 | Batching | Will | Implemented | Implemented | 484 | | Implement | | | 485 | | | | | 486 | Command | Will | Will Implement | Will Implement | 487 | Pipelining | Implement | | | 488 | | | | | 489 | HeartBeats | Implemented | Implemented | Implemented | 490 +---------------+-------------+----------------+--------------------+ 492 ForCES Protocol Advanced Features 494 6.1.2. ForCES Model Features 495 6.1.2.1. Basic Atomic Types Supported 497 +----------------+-------------+---------------+--------------------+ 498 | Atomic Type | NTT Japan | University of | Zhejiang Gongshang | 499 | | | Patras | University | 500 +----------------+-------------+---------------+--------------------+ 501 | char | Implemented | Implemented | Will Implement | 502 | | | | | 503 | uchar | Implemented | Implemented | Implemented | 504 | | | | | 505 | int16 | Implemented | Implemented | Will Implement | 506 | | | | | 507 | uint16 | Implemented | Implemented | Will Implement | 508 | | | | | 509 | int32 | Implemented | Implemented | Implemented | 510 | | | | | 511 | uint32 | Implemented | Implemented | Implemented | 512 | | | | | 513 | int16 | Implemented | Implemented | Will Implement | 514 | | | | | 515 | uint64 | Implemented | Implemented | Will Implement | 516 | | | | | 517 | boolean | Implemented | Implemented | Implemented | 518 | | | | | 519 | string[N] | Implemented | Implemented | Implemented | 520 | | | | | 521 | string | Implemented | Implemented | Implemented | 522 | | | | | 523 | byte[N] | Implemented | Implemented | Implemented | 524 | | | | | 525 | octetstring[N] | Implemented | Implemented | Will Implement | 526 | | | | | 527 | float32 | Implemented | Implemented | Will Implement | 528 | | | | | 529 | float64 | Implemented | Implemented | Will Implement | 530 +----------------+-------------+---------------+--------------------+ 532 Basic Atomic Types Supported 534 6.1.2.2. Compound Types Supported 536 +------------+-------------+-----------------+----------------------+ 537 | Compound | NTT Japan | University of | Zhejiang Gongshang | 538 | Type | | Patras | University | 539 +------------+-------------+-----------------+----------------------+ 540 | structs | Implemented | Implemented | Implemented | 541 | | | | | 542 | arrays | Implemented | Implemented | Implemented | 543 +------------+-------------+-----------------+----------------------+ 545 Compound Types Supported 547 6.1.2.3. LFBs Supported 549 6.1.2.3.1. FE Protocol LFB 551 +------------------+-------------+----------------+-----------------+ 552 | Protocol | NTT Japan | University of | Zhejiang | 553 | DataTypes | | Patras | Gongshang | 554 | | | | University | 555 +------------------+-------------+----------------+-----------------+ 556 | CEHBPolicy | Implemented | Implemented | Implemented | 557 | | | | | 558 | FEHIBPolicy | Implemented | Implemented | Implemented | 559 | | | | | 560 | FERestarPolicy | Implemented | Implemented | Implemented | 561 | | | | | 562 | CEFailoverPolicy | Implemented | Implemented | Implemented | 563 | | | | | 564 | FEHACapab | Implemented | Implemented | Will Implement | 565 +------------------+-------------+----------------+-----------------+ 567 FE Protocol LFB Datatypes 569 +-----------------------+-------------+-------------+---------------+ 570 | Protocol Components | NTT Japan | University | Zhejiang | 571 | | | of Patras | Gongshang | 572 | | | | University | 573 +-----------------------+-------------+-------------+---------------+ 574 | CurrentRunningVersion | Implemented | Implemented | Implemented | 575 | | | | | 576 | FEID | Implemented | Implemented | Implemented | 577 | | | | | 578 | MulticastFEIDs | Implemented | Implemented | Implemented | 579 | | | | | 580 | CEHBPolicy | Implemented | Implemented | Implemented | 581 | | | | | 582 | CEHDI | Implemented | Implemented | Implemented | 583 | | | | | 584 | FEHBPolicy | Implemented | Implemented | Implemented | 585 | | | | | 586 | FEHI | Implemented | Implemented | Implemented | 587 | | | | | 588 | CEID | Implemented | Implemented | Implemented | 589 | | | | | 590 | BackupCEs | Implemented | Will | Will | 591 | | | Implement | Implement | 592 | | | | | 593 | CEFailoverPolicy | Implemented | Implemented | Implemented | 594 | | | | | 595 | CEFTI | Implemented | Implemented | Implemented | 596 | | | | | 597 | FERestartPolicy | Implemented | Implemented | Will | 598 | | | | Implement | 599 | | | | | 600 | LastCEID | Implemented | Implemented | Will | 601 | | | | Implement | 602 +-----------------------+-------------+-------------+---------------+ 604 FE Protocol LFB Components 606 +---------------------+-------------+-------------+-----------------+ 607 | Capabilities | NTT Japan | University | Zhejiang | 608 | | | of Patras | Gongshang | 609 | | | | University | 610 +---------------------+-------------+-------------+-----------------+ 611 | SupportableVersions | Implemented | Implemented | Implemented | 612 | | | | | 613 | HACapabilities | Implemented | Implemented | Will Implement | 614 +---------------------+-------------+-------------+-----------------+ 616 Capabilities Supported 618 +---------------+------------+----------------+---------------------+ 619 | Events | NTT Japan | University of | Zhejiang Gongshang | 620 | | | Patras | University | 621 +---------------+------------+----------------+---------------------+ 622 | PrimaryCEDown | Will | Will Implement | Will Implement | 623 | | Implement | | | 624 +---------------+------------+----------------+---------------------+ 626 Events Supported 628 6.1.2.3.2. FE Object LFB 630 +-------------------------+-------------+-------------+-------------+ 631 | Object DataTypes | NTT Japan | University | Zhejiang | 632 | | | of Patras | Gongshang | 633 | | | | University | 634 +-------------------------+-------------+-------------+-------------+ 635 | LFBAdjacencyLimit | Implemented | Implemented | Implemented | 636 | | | | | 637 | PortGroupLimitType | Implemented | Implemented | Implemented | 638 | | | | | 639 | SupportedLFBType | Implemented | Implemented | Implemented | 640 | | | | | 641 | FEStateValues | Implemented | Implemented | Implemented | 642 | | | | | 643 | FEConfiguredeighborType | Implemented | Implemented | Implemented | 644 | | | | | 645 | FEConfiguredeighborType | Implemented | Implemented | Implemented | 646 | | | | | 647 | LFBSelectorType | Implemented | Implemented | Implemented | 648 | | | | | 649 | LFBLinkType | Implemented | Implemented | Implemented | 650 +-------------------------+-------------+-------------+-------------+ 652 FE Object LFB Datatypes 654 +--------------+-------------+----------------+---------------------+ 655 | Object | NTT Japan | University of | Zhejiang Gongshang | 656 | Components | | Patras | University | 657 +--------------+-------------+----------------+---------------------+ 658 | LFBTopology | Implemented | Implemented | Implemented | 659 | | | | | 660 | LFBSelectors | Implemented | Implemented | Implemented | 661 | | | | | 662 | FEName | Implemented | Implemented | Implemented | 663 | | | | | 664 | FEID | Implemented | Implemented | Implemented | 665 | | | | | 666 | FEVendor | Implemented | Implemented | Implemented | 667 | | | | | 668 | FEModel | Implemented | Implemented | Implemented | 669 | | | | | 670 | FEState | Implemented | Implemented | Implemented | 671 | | | | | 672 | FENeighbors | Implemented | Implemented | Implemented | 673 +--------------+-------------+----------------+---------------------+ 675 FE Object LFB Components 677 +-----------------------+-------------+-------------+---------------+ 678 | Capabilities | NTT Japan | University | Zhejiang | 679 | | | of Patras | Gongshang | 680 | | | | University | 681 +-----------------------+-------------+-------------+---------------+ 682 | ModifiableLFBTopology | Implemented | Implemented | Implemented | 683 | | | | | 684 | SupportedLFBs | Implemented | Implemented | Implemented | 685 +-----------------------+-------------+-------------+---------------+ 687 Capabilities Supported 689 6.1.3. ForCES SCTP-TML Features 691 6.1.3.1. TML Priority Ports 693 +----------------+-------------+---------------+--------------------+ 694 | Port | NTT Japan | University of | Zhejiang Gongshang | 695 | | | Patras | University | 696 +----------------+-------------+---------------+--------------------+ 697 | High priority | Implemented | Implemented | Implemented | 698 | (6700) | | | | 699 | | | | | 700 | Medium | Implemented | Implemented | Implemented | 701 | priority | | | | 702 | (6701) | | | | 703 | | | | | 704 | Low priority | Implemented | Implemented | Implemented | 705 | (6702) | | | | 706 +----------------+-------------+---------------+--------------------+ 708 Priority Ports 710 6.1.3.2. Message Handling at specific priorities 712 +------------------+-------------+---------------+------------------+ 713 | ForCES Message | NTT Japan | University of | Zhejiang | 714 | | | Patras | Gongshang | 715 | | | | University | 716 +------------------+-------------+---------------+------------------+ 717 | Association | Implemented | Implemented | Implemented | 718 | Setup | | | | 719 | | | | | 720 | Association | Implemented | Implemented | Implemented | 721 | Setup Response | | | | 722 | | | | | 723 | Association | Implemented | Implemented | Implemented | 724 | Teardown | | | | 725 | | | | | 726 | Config | Implemented | Implemented | Implemented | 727 | | | | | 728 | Config Response | Implemented | Implemented | Implemented | 729 | | | | | 730 | Query | Implemented | Implemented | Implemented | 731 | | | | | 732 | Query Response | Implemented | Implemented | Implemented | 733 +------------------+-------------+---------------+------------------+ 735 Message Handling at High priority (6700) Port 737 +---------------+-------------+----------------+--------------------+ 738 | ForCES | NTT Japan | University of | Zhejiang Gongshang | 739 | Message | | Patras | University | 740 +---------------+-------------+----------------+--------------------+ 741 | Event | Implemented | Implemented | Implemented | 742 | Notification | | | | 743 +---------------+-------------+----------------+--------------------+ 745 Message Handling at Medium priority (6701) Port 747 +-------------+-------------+-----------------+---------------------+ 748 | ForCES | NTT Japan | University of | Zhejiang Gongshang | 749 | Message | | Patras | University | 750 +-------------+-------------+-----------------+---------------------+ 751 | Packet | Implemented | Implemented | Implemented | 752 | Redirect | | | | 753 | | | | | 754 | Heartbeats | Implemented | Implemented | Implemented | 755 +-------------+-------------+-----------------+---------------------+ 757 Message Handling at Low priority (6702) Port 759 6.1.3.3. TML Security Feature 761 +--------------+------------+-----------------+---------------------+ 762 | Security | NTT Japan | University of | Zhejiang Gongshang | 763 | Feature | | Patras | University | 764 +--------------+------------+-----------------+---------------------+ 765 | IPSec | Will | Will Implement | Will Implement | 766 | | Implement | | | 767 +--------------+------------+-----------------+---------------------+ 769 Security Feature Support 771 6.2. Interoperability Report 773 The interoperability test took place at the University of Patras, in 774 the Department of Electrical and Computer Engineering. 776 There were two options to participate in the interoperability test. 778 1. Locally at the University of Patras premises. 780 2. Remotely via internet. 782 Implementations from NTT and University of Patras, were present 783 locally at the University of Patras premises in Greece, while the 784 implementation from Zhejiang Gongshang University, which was behind a 785 NAT, connected remotely from China. 787 The interoperability test, tested the basic functionality of the 788 ForCES protocol, mainly message exchanging and handling. 790 The following scenarios were tested. 792 6.2.1. Scenarios 794 The main goal of the interoperability test was to test the basic 795 protocol functionality, the test parameters were limited. 797 1. In the Association Setup Message, all report messages were 798 ignored. 800 2. In the Association Setup Phase, the messages, FEO OperEnable 801 Event (FE to CE), Config FEO Adminup (CE to FE) and FEO Config- 802 Resp (FE to CE) were ignored. The CEs assumed that the FEs were 803 enabled once the LFBSelectors had been queried. 805 3. Only FullDataTLVs were used and not SparseData TLVs. 807 4. There were no transaction operations. 809 5. Each message had only one LFBSelector TLV, one Operation TLV and 810 one PathDataTLV per message when these were used. 812 6.2.1.1. Scenario 1 - Pre-association Setup 814 While the Pre-association setup is not in the ForCES current scope it 815 is an essential step before CEs and FEs communicate. As the first 816 part in a successful CE-FE connection the participating CEs and FEs 817 had to be able to be configured. 819 In the Pre-association Phase the following configuration items were 820 setup regarding the CEs: 822 o The CE ID. 824 o The FE IDs that were connected to this CE 826 o The IP of the FEs that connected 828 o The TML priority ports. 830 In the Pre-association Phase the following configuration items were 831 setup regarding the FEs: 833 o The FE ID. 835 o The CE ID that this FE were connecting to. 837 o The IP of the CE that connected to 838 o The TML priority ports. 840 6.2.1.2. Scenario 2 - TML priority channels connection 842 For the interoperability test, the SCTP was used as TML. The TML 843 connection with the associating element was needed for the scenario 2 844 to be successful. 846 Although the latest SCTP-TML document [I-D.ietf-forces-sctptml] 847 defines 3 priority channels, with specific ports: 849 o High priority - Port number: 6704 851 o Medium priority - Port number: 6705 853 o Lower priority - Port number: 6706 855 At the time of the interoperability test, the sctp ports of the three 856 priority channels were the following: 858 o High priority - Port number: 6700 860 o Medium priority - Port number: 6701 862 o Lower priority - Port number: 6702 864 As specified in the exceptions section, this does not invalidate the 865 results of the interoperability test. 867 6.2.1.3. Scenario 3 - Association Setup - Association Complete 869 Once the Pre-association phase had been complete in the previous 2 870 scenarios, CEs and FEs would be ready to communicate using the ForCES 871 protocol, and enter the Association Setup stage. In this stage the 872 FEs would attempt to join the NE. The following ForCES protocol 873 messages would be exchanged for each CE-FE pair in the specified 874 order: 876 o Association Setup Message (from FE to CE) 878 o Association Setup Response Message (from CE to FE) 880 o Query Message: FEO LFBSelectors(from CE to FE) 882 o Query Response: FEO LFBSelectors response (from FE to CE) 884 6.2.1.4. Scenario 4 - CE query 886 Once the Association Phase stage has been complete, the FEs and CEs 887 would enter the Established stage. In this stage the FE will be 888 continuously updated or queried. The CE should query the FE a 889 specific value from the FE Object LFB and from the FE Protocol LFB. 890 An example from the FE Protocol LFB is the HeartBeat Timer (FEHI) and 891 from the FE Object LFB is the State of the LFB (FEState) 893 The following ForCES protocol messages were exchanged: 895 o Query Message 897 o Query Response Message 899 6.2.1.5. Scenario 5 - Heartbeat monitoring 901 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 902 to asynchronously notify one or more other ForCES elements in the 903 same ForCES NE on its liveness. The default configuration of the 904 Heartbeat Policy of the FE is set to 0 which means, that the FE 905 should not generate any Heartbeat messages. the CE is responsible for 906 checking FE liveness by setting the PL header ACK flag of the message 907 it sends to AlwaysACK. In this Scenario the CE will send a Heartbeat 908 message with the ACK flag set to AlwaysACK and the FE should respond. 910 The following ForCES protocol messages were exchanged: 912 o Heartbeat Message 914 6.2.1.6. Scenario 6 - Simple Config Command 916 A config message is sent by the CE to the FE to configure LFB 917 components in the FE. A simple config command easily visible and 918 metered would be to change the Heartbeat configuration. This was 919 done in two steps: 921 1. Change the FE Heartbeat Policy (FEHBPolicy) to value 1, to force 922 the FE to send heartbeats. 924 2. After some heartbeats from the FE, the FE Heartbeat Interval 925 (FEHI) was changed. 927 The following ForCES protocol messages were exchanged: 929 o Config Message 930 o Config Response Message 932 6.2.1.7. Scenario 7 - Association Teardown 934 In the end, the association must be terminated. There were three 935 scenarios by which the association was terminated: 937 1. Normal tear down by exchanging Association Teardown Message 939 2. Irregular tear down by stopping heartbeats from a FE or a CE. 941 3. Irregular tear down by externally shutting down/rebooting a FE or 942 a CE. 944 All scenarios were tested in the interoperability test. 946 The following ForCES protocol messages were exchanged: 948 o Association Teardown Message 950 6.2.2. Tested Features 952 The features that were tested are: 954 6.2.2.1. ForCES Protocol Features 956 6.2.2.1.1. Protocol Messages 958 +----------------------------+ 959 | Protocol Message | 960 +----------------------------+ 961 | Association Setup | 962 | | 963 | Association Setup Response | 964 | | 965 | Association TearDown | 966 | | 967 | Configuration | 968 | | 969 | Configuration Response | 970 | | 971 | Query | 972 | | 973 | Query Response | 974 | | 975 | HeartBeat | 976 +----------------------------+ 977 ForCES Protocol Message 979 o PASS: All implementations handled the protocol messages and all 980 protocol analyzers captured them. 982 6.2.2.1.2. MainHeader Handling 984 +------------------+ 985 | Header Field | 986 +------------------+ 987 | Correlator | 988 | | 989 | Acknowledge Flag | 990 | | 991 | Priority Flag | 992 +------------------+ 994 MainHeader Handling 996 o PASS: All implementations handled these main header flags and all 997 protocol analyzers captured them. 999 6.2.2.1.3. TLV Handling 1001 +---------------------------------+ 1002 | TLV | 1003 +---------------------------------+ 1004 | Association Setup Result TLV | 1005 | | 1006 | Association TearDown Reason TLV | 1007 | | 1008 | LFBSelector TLV | 1009 | | 1010 | Operation TLV | 1011 | | 1012 | PathData TLV | 1013 | | 1014 | FullData TLV | 1015 | | 1016 | Result TLV | 1017 +---------------------------------+ 1019 TLVs Supported 1021 o PASS: All implementations handled these TLVs and all protocol 1022 analyzers captured them. 1024 6.2.2.1.4. Operation Types Supported 1026 +--------------+ 1027 | Operation | 1028 +--------------+ 1029 | Set | 1030 | | 1031 | Set Response | 1032 | | 1033 | Get | 1034 | | 1035 | Get Response | 1036 | | 1037 | Report | 1038 +--------------+ 1040 Operation Type Supported 1042 o PASS: All implementations handled these Operations and all 1043 protocol analyzers captured them. 1045 6.2.2.1.5. ForCES Protocol Advanced Features 1047 +------------+ 1048 | Feature | 1049 +------------+ 1050 | Batching | 1051 | | 1052 | HeartBeats | 1053 +------------+ 1055 ForCES Protocol Advanced Features 1057 Although Batching was not initially designed to be tested, it was 1058 tested during the interoperability test. 1060 o PASS: Two implementations handled batching and all handled 1061 Heartbeats. The protocol analyzers captured both. 1063 6.2.2.2. ForCES Model Features 1064 6.2.2.2.1. Basic Atomic Types Supported 1066 +-------------+ 1067 | Atomic Type | 1068 +-------------+ 1069 | uchar | 1070 | | 1071 | uint32 | 1072 +-------------+ 1074 Basic Atomic Types Supported 1076 o PASS: All implementations handled these basic atomic types. 1078 6.2.2.2.2. Compound Types Supported 1080 +---------------+ 1081 | Compound Type | 1082 +---------------+ 1083 | structs | 1084 | | 1085 | arrays | 1086 +---------------+ 1088 Compound Types Supported 1090 o PASS: All implementations handled these compound types. 1092 6.2.2.2.3. LFBs Supported 1094 6.2.2.2.3.1. FE Protocol LFB 1096 +--------------------+ 1097 | Protocol DataTypes | 1098 +--------------------+ 1099 | CEHBPolicy | 1100 | | 1101 | FEHIBPolicy | 1102 +--------------------+ 1104 FE Protocol LFB Datatypes 1106 o PASS: All implementations handled these FE Protocol LFB Datatypes. 1108 +---------------------+ 1109 | Protocol Components | 1110 +---------------------+ 1111 | FEID | 1112 | | 1113 | CEHBPolicy | 1114 | | 1115 | CEHDI | 1116 | | 1117 | FEHBPolicy | 1118 | | 1119 | FEHI | 1120 | | 1121 | CEID | 1122 +---------------------+ 1124 FE Protocol LFB Components 1126 o PASS: All implementations handled these FE Protocol LFB 1127 Components. 1129 6.2.2.2.3.2. FE Object LFB 1131 +------------------+ 1132 | Object DataTypes | 1133 +------------------+ 1134 | FEStateValues | 1135 | | 1136 | LFBSelectorType | 1137 +------------------+ 1139 FE Object LFB Datatypes 1141 o PASS: All implementations handled these FE Object LFB Datatypes. 1143 +-------------------+ 1144 | Object Components | 1145 +-------------------+ 1146 | LFBSelectors | 1147 | | 1148 | FEState | 1149 +-------------------+ 1151 FE Object LFB Components 1153 o PASS: All implementations handled these FE Object LFB Components. 1155 6.2.2.3. ForCES SCTP-TML Features 1157 6.2.2.3.1. TML Priority Ports 1159 +------------------------+ 1160 | Port | 1161 +------------------------+ 1162 | High priority (6700) | 1163 | | 1164 | Medium priority (6701) | 1165 | | 1166 | Low priority (6702) | 1167 +------------------------+ 1169 Priority Ports 1171 o PASS: All implementations opened and connected to all the SCTP 1172 priority ports. The protocol analyzers captured all ports and 1173 corresponding priority. 1175 6.2.2.3.2. Message Handling at specific priorities 1177 +----------------------------+ 1178 | ForCES Message | 1179 +----------------------------+ 1180 | Association Setup | 1181 | | 1182 | Association Setup Response | 1183 | | 1184 | Association Teardown | 1185 | | 1186 | Config | 1187 | | 1188 | Config Response | 1189 | | 1190 | Query | 1191 | | 1192 | Query Response | 1193 +----------------------------+ 1195 Message Handling at High priority (6700) Port 1197 o PASS: All implementations handled these messages at this SCTP 1198 priority port. The protocol analyzers captured these messages at 1199 these priority ports. 1201 +----------------+ 1202 | ForCES Message | 1203 +----------------+ 1204 | Heartbeats | 1205 +----------------+ 1207 Message Handling at Low priority (6702) Port 1209 o PASS: All implementations handled these messages at this SCTP 1210 priority port. The protocol analyzers captured these messages at 1211 these priority ports. 1213 6.2.3. Interoperability Results 1215 All implementations were found to be interoperable with each other. 1217 All scenarios were tested successfully. 1219 The following issues were found and dealt with. 1221 1. Some messages were sent to the wrong priority channels. There 1222 was some ambiguities on the SCTP-TML document on what must be 1223 the correct response from the CE and FE. Should it respond in 1224 the same channel, should it respond in the correct channel, or 1225 should it drop the packet? This has been corrected by changing 1226 the word recommended to MUST in the SCTP-TML document regarding 1227 priority channel messaging . 1229 2. At some point, a CE sent a TearDown message to the FE. The CE 1230 expected the FE to shut down the connection, and the FE waited 1231 the CE to shut down the connection and were caught in a 1232 deadlock. This was a code bug and was fixed. 1234 3. Sometimes the association setup message, only on the remote 1235 connection test, although sent, was not received by the other 1236 end and made impossible the association. This was caused by 1237 network problems. 1239 4. An implementation did not take into account that the padding in 1240 TLVs MUST NOT be included in the length of the TLV. This was a 1241 code bug and was fixed. 1243 5. EM Flag was set to reserved by a CE and was not ignored by the 1244 FE. This was a code bug and was fixed. 1246 6. After the FEHBPolicy was set to 1 the FE didn't send any 1247 HeartBeats. This was a code bug and was fixed. 1249 7. Some FEs sent HeartBeats with the ACK flag with a value other 1250 than NoACK. The CE responded. This was a code bug and was 1251 fixed. 1253 8. When a cable was disconnected, all TML implementation didn't 1254 detect it. The association was eventually dropped due to 1255 heartbeats, this was a success, but this is an implementation 1256 issue implementers should keep in mind. This is a SCTP options 1257 issue. Nothing was needed to be done. 1259 9. A CE crashed due to unknown LFBSelector values. This was a code 1260 bug and was fixed. 1262 10. With the remote connection from China, which was behind a NAT, 1263 to Greece there were a lot of ForCES packet retransmission. The 1264 problem is that packets like Heartbeats were retransmitted. 1265 This was a SCTP issue. SCTP-PR was needed to be used. 1267 The interoperability test went so well that an additional extended 1268 test was added to test for batching messages. This test was also 1269 done successfully. 1271 7. Acknowledgements 1273 The authors like to give thanks to Professors Odysseas Koufopavlou 1274 and Spyros Denazis, and the Department of Electrical and Computer 1275 Engineering in the University of Patras who hosted the ForCES 1276 interoperability test. 1278 Also the authors would like to give thanks to Chuanhuang Li, Ming 1279 Gao, and other participants from Zhejiang Gongshang University which 1280 connected remotely. This allowed the discovery of a series of issues 1281 that would have been uncaught otherwise. 1283 The authors would like to thank also Hideaki Iwata and Yoshinobu 1284 Morimoto for participating locally at the interoperability test and 1285 also Hiroki Date and Hidefumi Otsuka all part of NTT Japan for 1286 contributing to the interoperability test. 1288 Additionally thanks are given to Xinping Wang for her help in writing 1289 the interoperability draft an Fenggen Jia for extending the Ethereal 1290 protocol analyzer. 1292 8. IANA Considerations 1294 This memo includes no request to IANA. 1296 9. Security Considerations 1298 For Security considerations please see [I-D.ietf-forces-protocol] and 1299 [I-D.ietf-forces-sctptml] 1301 10. References 1303 10.1. Normative References 1305 [I-D.ietf-forces-model] 1306 Halpern, J. and J. Salim, "ForCES Forwarding Element 1307 Model", draft-ietf-forces-model-16 (work in progress), 1308 October 2008. 1310 [I-D.ietf-forces-protocol] 1311 Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., 1312 Khosravi, H., and W. Wang, "ForCES Protocol 1313 Specification", draft-ietf-forces-protocol-22 (work in 1314 progress), March 2009. 1316 [I-D.ietf-forces-sctptml] 1317 Salim, J. and K. Ogawa, "SCTP based TML (Transport Mapping 1318 Layer) for ForCES protocol", draft-ietf-forces-sctptml-08 1319 (work in progress), January 2010. 1321 10.2. Informative References 1323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1324 Requirement Levels", BCP 14, RFC 2119, March 1997. 1326 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1327 June 1999. 1329 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1330 Text on Security Considerations", BCP 72, RFC 3552, 1331 July 2003. 1333 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 1334 of IP Control and Forwarding", RFC 3654, November 2003. 1336 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 1337 "Forwarding and Control Element Separation (ForCES) 1338 Framework", RFC 3746, April 2004. 1340 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1341 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1342 May 2008. 1344 [RFC5657] Dusseault, L. and R. Sparks, "Guidance on Interoperation 1345 and Implementation Reports for Advancement to Draft 1346 Standard", BCP 9, RFC 5657, September 2009. 1348 [ethereal] 1349 "Ethereal is a protocol analyzer. The specific ethereal 1350 that was used is an updated Ethereal, by Fenggen Jia, that 1351 can analyze and decode the ForCES protocol messages.", . 1355 [tcpdump] "Tcpdump is a linux protocol analyzer. The specific 1356 tcpdump that was used is a modified tcpdump, by Jamal Hadi 1357 Salim, that can analyze and decode the ForCES protocol 1358 messages.", . 1361 Authors' Addresses 1363 Evangelos Haleplidis 1364 University of Patras 1365 Patras, 1366 Greece 1368 Email: ehalep@ece.upatras.gr 1370 Kentaro Ogawa 1371 NTT Corporation 1372 Tokyo, 1373 Japan 1375 Email: ogawa.kentaro@lab.ntt.co.jp 1377 Weiming Wang 1378 Zhejiang Gongshang University 1379 18, Xuezheng Str., Xiasha University Town 1380 Hangzhou, 310018 1381 P.R.China 1383 Phone: +86-571-28877721 1384 Email: wmwang@mail.zjgsu.edu.cn 1386 Jamal Hadi Salim 1387 Mojatatu Networks 1388 Ottawa, Ontario, 1389 Canada 1391 Phone: 1392 Email: hadi@mojatatu.com