idnits 2.17.1 draft-ietf-forces-interoperability-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 == Line 777 has weird spacing: '... | it y ...' == Line 783 has weird spacing: '... | it y ...' == Line 789 has weird spacing: '... | it y ...' == Line 798 has weird spacing: '... | it y ...' == Line 804 has weird spacing: '... | it y ...' == (18 more instances...) -- The document date (August 7, 2009) is 5376 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 1081, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-forces-sctptml-02 -- 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 (~~), 11 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: February 8, 2010 NTT Corporation 6 X. Wang 7 Huawei Technologies Co., Ltd. 8 C. Li 9 Zhejiang Gongshang University 10 August 7, 2009 12 ForCES Interoperability Draft 13 draft-ietf-forces-interoperability-03 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on February 8, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document describes the details of the interoperability test of 52 the Forward and Control Element Separation (ForCES) protocol that 53 took place in the University of Patras in Rio, Greece, 15 and 16 July 54 2009. This informational draft provided necessary information, for 55 all parties who wish to participate in the interoperability test. 57 This update also includes the results of the test. 59 Table of Contents 61 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Transport mapping layer . . . . . . . . . . . . . . . . . 5 67 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Date, Location and Access . . . . . . . . . . . . . . . . . . 9 69 4.1. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.2. Location . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.3. Access . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 5. Testbed architecture . . . . . . . . . . . . . . . . . . . . . 10 73 5.1. Local configuration . . . . . . . . . . . . . . . . . . . 10 74 5.2. Distributed configuration . . . . . . . . . . . . . . . . 11 75 6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.1. Scenario 1 - Pre-association Setup . . . . . . . . . . . . 12 77 6.2. Scenario 2 - TML priority channels connection . . . . . . 13 78 6.3. Scenario 3 - Association Setup - Association Complete . . 13 79 6.4. Scenario 4 - CE query . . . . . . . . . . . . . . . . . . 13 80 6.5. Scenario 5 - Heartbeat monitoring . . . . . . . . . . . . 14 81 6.6. Scenario 6 - Simple Config Command . . . . . . . . . . . . 14 82 6.7. Scenario 7 - Association Teardown . . . . . . . . . . . . 14 83 7. Tested Features . . . . . . . . . . . . . . . . . . . . . . . 16 84 7.1. ForCES Protocol Features . . . . . . . . . . . . . . . . . 16 85 7.1.1. Protocol Messages . . . . . . . . . . . . . . . . . . 16 86 7.1.2. MainHeader Handling . . . . . . . . . . . . . . . . . 17 87 7.1.3. TLV Handling . . . . . . . . . . . . . . . . . . . . . 17 88 7.1.4. Operation Types Supported . . . . . . . . . . . . . . 18 89 7.2. ForCES Model Features . . . . . . . . . . . . . . . . . . 18 90 7.2.1. Basic Atomic Types Supported . . . . . . . . . . . . . 18 91 7.2.2. Compound Types Supported . . . . . . . . . . . . . . . 18 92 7.2.3. LFBs Supported . . . . . . . . . . . . . . . . . . . . 19 93 7.2.3.1. FE Protocol LFB . . . . . . . . . . . . . . . . . 19 94 7.2.3.2. FE Object LFB . . . . . . . . . . . . . . . . . . 19 95 7.3. ForCES SCTP-TML Features . . . . . . . . . . . . . . . . . 20 96 7.3.1. TML Priority Ports . . . . . . . . . . . . . . . . . . 20 97 7.3.2. Message Handling at specific priorities . . . . . . . 20 98 8. Test details . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 9. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 101 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 102 12. Security Considerations . . . . . . . . . . . . . . . . . . . 31 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 105 13.2. Informative References . . . . . . . . . . . . . . . . . . 32 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 108 1. Terminology and Conventions 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. Introduction 118 Forwarding and Control Element Separation (ForCES) defines an 119 architectural framework and associated protocols to standardize 120 information exchange between the control plane and the forwarding 121 plane in a ForCES Network Element (ForCES NE). [RFC3654] has defined 122 the ForCES requirements, and [RFC3746] has defined the ForCES 123 framework. 125 2.1. ForCES Protocol 127 The ForCES protocol works in a master-slave mode in which FEs are 128 slaves and CEs are masters. The protocol includes commands for 129 transport of Logical Function Block (LFB) configuration information, 130 association setup, status, and event notifications, etc. The reader 131 is encouraged to read FE-protocol [I-D.ietf-forces-protocol] for 132 further information. 134 2.2. ForCES Model 136 The FE-MODEL [I-D.ietf-forces-model] presents a formal way to define 137 FE Logical Function Blocks (LFBs) using XML. LFB configuration 138 components, capabilities, and associated events are defined when the 139 LFB is formally created. The LFBs within the FE are accordingly 140 controlled in a standardized way by the ForCES protocol. 142 2.3. Transport mapping layer 144 The TML transports the PL messages. The TML is where the issues of 145 how to achieve transport level reliability, congestion control, 146 multicast, ordering, etc. are handled. It is expected that more than 147 one TML will be standardized. The various possible TMLs could vary 148 their implementations based on the capabilities of underlying media 149 and transport. However, since each TML is standardized, 150 interoperability is guaranteed as long as both endpoints support the 151 same TML. All ForCES Protocol Layer implementations MUST be portable 152 across all TMLs. Although more than one TML may be standardized for 153 the ForCES Protocol, for the purposes of the interoperability test, 154 the mandated MUST IMPLEMENT SCTP TML [I-D.ietf-forces-sctptml] will 155 be used. 157 3. Definitions 159 This document follows the terminology defined by the ForCES 160 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 161 The definitions below are repeated below for clarity. 163 o Control Element (CE) - A logical entity that implements the ForCES 164 protocol and uses it to instruct one or more FEs on how to process 165 packets. CEs handle functionality such as the execution of 166 control and signaling protocols. 168 o CE Manager (CEM) - A logical entity responsible for generic CE 169 management tasks. It is particularly used during the pre- 170 association phase to determine with which FE(s) a CE should 171 communicate. This process is called FE discovery and may involve 172 the CE manager learning the capabilities of available FEs. 174 o Forwarding Element (FE) - A logical entity that implements the 175 ForCES protocol. FEs use the underlying hardware to provide per- 176 packet processing and handling as directed/controlled by one or 177 more CEs via the ForCES protocol. 179 o FE Manager (FEM) - A logical entity responsible for generic FE 180 management tasks. It is used during pre-association phase to 181 determine with which CE(s) an FE should communicate. This process 182 is called CE discovery and may involve the FE manager learning the 183 capabilities of available CEs. An FE manager may use anything 184 from a static configuration to a pre-association phase protocol 185 (see below) to determine which CE(s) to use. Being a logical 186 entity, an FE manager might be physically combined with any of the 187 other logical entities such as FEs. 189 o ForCES Network Element (NE) - An entity composed of one or more 190 CEs and one or more FEs. To entities outside an NE, the NE 191 represents a single point of management. Similarly, an NE usually 192 hides its internal organization from external entities. 194 o LFB (Logical Function Block) - The basic building block that is 195 operated on by the ForCES protocol. The LFB is a well defined, 196 logically separable functional block that resides in an FE and is 197 controlled by the CE via ForCES protocol. The LFB may reside at 198 the FE's datapath and process packets or may be purely an FE 199 control or configuration entity that is operated on by the CE. 200 Note that the LFB is a functionally accurate abstraction of the 201 FE's processing capabilities, but not a hardware-accurate 202 representation of the FE implementation. 204 o FE Topology - A representation of how the multiple FEs within a 205 single NE are interconnected. Sometimes this is called inter-FE 206 topology, to be distinguished from intra-FE topology (i.e., LFB 207 topology). 209 o LFB Class and LFB Instance - LFBs are categorized by LFB Classes. 210 An LFB Instance represents an LFB Class (or Type) existence. 211 There may be multiple instances of the same LFB Class (or Type) in 212 an FE. An LFB Class is represented by an LFB Class ID, and an LFB 213 Instance is represented by an LFB Instance ID. As a result, an 214 LFB Class ID associated with an LFB Instance ID uniquely specifies 215 an LFB existence. 217 o LFB Metadata - Metadata is used to communicate per-packet state 218 from one LFB to another, but is not sent across the network. The 219 FE model defines how such metadata is identified, produced and 220 consumed by the LFBs. It defines the functionality but not how 221 metadata is encoded within an implementation. 223 o LFB Component - Operational parameters of the LFBs that must be 224 visible to the CEs are conceptualized in the FE model as the LFB 225 components. The LFB components include, for example, flags, 226 single parameter arguments, complex arguments, and tables that the 227 CE can read and/or write via the ForCES protocol (see below). 229 o LFB Topology - Representation of how the LFB instances are 230 logically interconnected and placed along the datapath within one 231 FE. Sometimes it is also called intra-FE topology, to be 232 distinguished from inter-FE topology. 234 o Pre-association Phase - The period of time during which an FE 235 Manager and a CE Manager are determining which FE(s) and CE(s) 236 should be part of the same network element. 238 o Post-association Phase - The period of time during which an FE 239 knows which CE is to control it and vice versa. This includes the 240 time during which the CE and FE are establishing communication 241 with one another. 243 o ForCES Protocol - While there may be multiple protocols used 244 within the overall ForCES architecture, the term "ForCES protocol" 245 and "protocol" refer to the Fp reference points in the ForCES 246 Framework in [RFC3746]. This protocol does not apply to CE-to-CE 247 communication, FE-to-FE communication, or to communication between 248 FE and CE managers. Basically, the ForCES protocol works in a 249 master- slave mode in which FEs are slaves and CEs are masters. 250 This document defines the specifications for this ForCES protocol. 252 o ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 253 ForCES protocol architecture that uses the capabilities of 254 existing transport protocols to specifically address protocol 255 message transportation issues, such as how the protocol messages 256 are mapped to different transport media (like TCP, IP, ATM, 257 Ethernet, etc), and how to achieve and implement reliability, 258 multicast, ordering, etc. The ForCES TML specifications are 259 detailed in separate ForCES documents, one for each TML. 261 4. Date, Location and Access 263 4.1. Date 265 The date that the Interoperability test took place was 15-16/07/2009, 266 one and a half week before IETF 75, in Stockholm. 268 4.2. Location 270 Patras is a major harbor of Greece connecting it with Italy. 272 The University of Patras is located in Rio, 10km east out of Patras. 274 The following coordinates mark the Electrical and Computer 275 Engineering building in the University. 277 o North: 38o17'15.99" 279 o East: 21o47'19.28" 281 4.3. Access 283 The best way to come to Greece is by plane to the Athens 284 International Airport. 286 From there there are three ways to arrive in the University of 287 Patras. 289 1. Renting a car and driving to the University. It is a maximum 290 2:30 hours drive from the aiport. 292 2. Via coach station. Get from the airport to the coach station via 293 X93 bus towards the Kifissos Coach Station. At the Coach Station 294 there are buses to Patras every 30 minutes. The Bus to Patras 295 may take about 2:30 - 3:00 hours, and the ride of the X93 bus may 296 take about 30 mins - 1hour depending on the traffic, so it's 297 about 3:30 - 4:30 hours away with the wait at the Coach Station. 299 3. Via Train. It is recommended you already have booked your ticket 300 beforehand as there are not many trains going to Patras, and 301 mostly are booked in advanced. It is not recommended that you 302 take the train to Patras, as you have to change at least 2 303 trains. In order to reach Patras from the Athens International 304 Airport you need to take the Suburban Rail to Kiato. From Kiato 305 you can catch a train to Patras. It will take you at least 5 306 hours to reach Patras. 308 5. Testbed architecture 310 Most FEs and CEs were located locally at the University of Patras 311 premises. One party participated connecting over the internet. 313 The test took place between FEs and CEs of different implementors 314 with different permutations. 316 All protocol messages of each scenario were monitored using a 317 protocol network analyzer that tested validity. Two tools were used: 319 o A modified tcpdump [tcpdump]. 321 o A modified Ethereal [ethereal]. 323 All NE's in all the scenarios were comprised of one CE and one FE 324 from different implementors. 326 5.1. Local configuration 328 Hardware/Software (CEs and FEs) that were located within the 329 University of Patras premises, were connected together using 330 switches. 332 The scenarios were tested with only one CE associated with one or 333 multiple FEs from different implementors. The CE and the FE(s) were 334 connected in one LAN as shown in the following figure. 336 +-----+ 337 | CE1 | 338 |Impl1| 339 +-----+ 340 | 341 | 342 +------------------------------------+ 343 | LAN | 344 +------------------------------------+ 345 | | | | 346 | | ... | | 347 +-----+ +-----+ +-----+ +--------+ 348 | FE1 | | FE2 | | FEn | |Protocol| 349 |Impl1| |Impl2| |Impln| |Analyzer| 350 +-----+ +-----+ +-----+ +--------+ 352 All scenarios were tested more than once with permutation of the CE 353 from different implementors. In the next permutation, the setup were 354 as shown in the following figure. 356 +-----+ 357 | CE2 | 358 |Impl2| 359 +-----+ 360 | 361 | 362 +------------------------------------+ 363 | LAN | 364 +------------------------------------+ 365 | | | | 366 | | ... | | 367 +-----+ +-----+ +-----+ +--------+ 368 | FE1 | | FE2 | | FEn | |Protocol| 369 |Impl1| |Impl2| |Impln| |Analyzer| 370 +-----+ +-----+ +-----+ +--------+ 372 5.2. Distributed configuration 374 For parties that cannot participate, public IPs can be provided and 375 associations can be achieved over the internet as seen in the 376 following figure. 378 +-----+ +------------+ /\/\/\/\/\ +----------+ +-----+ 379 |FE/CE| |Implementor | \Internet/ |University| |FE/CE| 380 |ImplX|---| Router |---/ \---| Router |---|ImplY| 381 +-----+ +------------+ \/\/\/\/\/ +----------+ +-----+ 383 For interoperability issues, all CEs and FEs MUST implement no 384 security even in the TML. For security, firewalls MUST be used that 385 will allow only the specific IPs and the SCTP ports defined in the 386 SCTP-TML draft [I-D.ietf-forces-sctptml]. 388 6. Scenarios 390 Since the main goal of this interoperability test is to test the 391 basic protocol functionality, we will limit the test parameters. 392 Therefore: 394 1. In the Association Setup Message, all report messages will be 395 ignored. 397 2. In the Association Setup Phase, the messages, FEO OperEnable 398 Event (FE to CE), Config FEO Adminup (CE to FE) and FEO Config- 399 Resp (FE to CE) will be ignored. The CE will assume that the FE 400 is enabled once the LFBSelectors has been queried. 402 3. Only FullDataTLVs are going to be used and not SparseData TLV's. 404 4. There will be no transaction operations. 406 5. Each message shall have only one LFBSelector TLV, one Operation 407 TLV and one PathDataTLV per message when these are used. 409 6.1. Scenario 1 - Pre-association Setup 411 While the Pre-association setup is not in the ForCES current scope it 412 is an essential step before CEs and FEs communicate. As the first 413 part in a successfull CE-FE connection the participating CEs and FEs 414 should be able to be configured. 416 In the Pre-association Phase the following configuration items MUST 417 be setup regarding the CEs: 419 o The CE ID. 421 o The FE IDs that will be connected to this CE 423 o The IP of the FEs that will connect 425 o The TML priority ports. 427 In the Pre-association Phase the following configuration items MUST 428 be setup regarding the FEs: 430 o The FE ID. 432 o The CE ID that this FE will be connecting to. 434 o The IP of the CE that will connect to 435 o The TML priority ports. 437 Once each element is setup and configured, Scenario 1 is successful. 439 6.2. Scenario 2 - TML priority channels connection 441 For the current interoperability test, the SCTP will be used as TML. 442 The TML connection with the associating element is needed for the 443 scenario 2 to be successful. 445 The SCTP-TML draft [I-D.ietf-forces-sctptml] defines 3 priority 446 channels, with specific ports: 448 o High priority - Port number: 6700 450 o Medium priority - Port number: 6701 452 o Lower priority - Port number: 6702 454 Once these channels have been established with each associated 455 element, will the Scenario 2 be successful. 457 6.3. Scenario 3 - Association Setup - Association Complete 459 Once the Pre-association phase has been complete in the previous 2 460 scenarios, CEs and FEs are ready to communicate using the ForCES 461 protocol, and enter the Association Setup stage. In this stage the 462 FEs attempts to join the NE. The following ForCES protocol messages 463 will be exchanged for each CE-FE pair in the specified order: 465 o Association Setup Message (from FE to CE) 467 o Association Setup Response Message (from CE to FE) 469 o Query Message: FEO LFBSelectors(from CE to FE) 471 o Query Response: FEO LFBSelectors response (from FE to CE) 473 Once the associations has been initialized scenario 3 will have been 474 successful. 476 6.4. Scenario 4 - CE query 478 Once the Association Phase stage has been complete, the FEs and CEs 479 will enter the Established stage. In this stage the FE is 480 continuously updated or queried. The CE should query the FE a 481 specific value from the FE Object LFB and from the FE Protocol LFB. 482 An example from the FE Protocol LFB is the HeartBeat Timer (FEHI) and 483 from the FE Object LFB is the State of the LFB (FEState) 485 The following ForCES protocol messages will be exchanged: 487 o Query Message 489 o Query Response Message 491 6.5. Scenario 5 - Heartbeat monitoring 493 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 494 to asynchronously notify one or more other ForCES elements in the 495 same ForCES NE on its liveness. The default configuration of the 496 Heartbeat Policy of the FE is set to 0 which means, that the FE 497 should not generate any Heartbeat messages. the CE is responsible for 498 checking FE liveness by setting the PL header ACK flag of the message 499 it sends to AlwaysACK. In this Scenario the CE should send a 500 Heartbeat message with the ACK flag set to AlwaysACK and the FE 501 should respond. 503 The following ForCES protocol messages will be exchanged: 505 o Heartbeat Message 507 6.6. Scenario 6 - Simple Config Command 509 A config message is sent by the CE to the FE to configure LFB 510 components in the FE. A simple config command easily visible and 511 metered would be to change the Heartbeat configuration. This will be 512 done in two steps: 514 1. Change the FE Heartbeat Policy (FEHBPolicy) to value 1, to force 515 the FE to send heartbeats. 517 2. After some heartbeats from the FE, the FE Heartbeat Interval 518 (FEHI) will be changed. 520 The following ForCES protocol messages will be exchanged: 522 o Config Message 524 o Config Response Message 526 6.7. Scenario 7 - Association Teardown 528 In the end, the association must be terminated. There are two 529 scenarios by which the association maybe terminated: 531 1. Normal tear down by exchanging Association Teardown Message 533 2. Irregular tear down by stopping heartbeats from a FE or a CE. 535 3. Irregular tear down by externally shutting down/rebooting a FE or 536 a CE. 538 All scenarios may be tested in the interoperability test. 540 The following ForCES protocol messages will be exchanged: 542 o Association Teardown Message 544 7. Tested Features 546 The features that were tested are: 548 7.1. ForCES Protocol Features 550 +------------+ 551 | Feature | 552 +------------+ 553 | Batching | 554 | | 555 | HeartBeats | 556 +------------+ 558 ForCES Protocol Features 560 Although Batching was not initially designed to be tested, it was 561 tested during the interoperability test. 563 7.1.1. Protocol Messages 565 +----------------------------+ 566 | Protocol Message | 567 +----------------------------+ 568 | Association Setup | 569 | | 570 | Association Setup Response | 571 | | 572 | Association TearDown | 573 | | 574 | Configuration | 575 | | 576 | Configuration Response | 577 | | 578 | Query | 579 | | 580 | Query Response | 581 | | 582 | HeartBeat | 583 +----------------------------+ 585 ForCES Protocol Message 587 7.1.2. MainHeader Handling 589 +------------------+ 590 | Header Field | 591 +------------------+ 592 | Correlator | 593 | | 594 | Acknowledge Flag | 595 | | 596 | Priority Flag | 597 +------------------+ 599 MainHeader Handling 601 7.1.3. TLV Handling 603 +---------------------------------+ 604 | TLV | 605 +---------------------------------+ 606 | Association Setup Result TLV | 607 | | 608 | Association TearDown Reason TLV | 609 | | 610 | LFBSelector TLV | 611 | | 612 | Operation TLV | 613 | | 614 | PathData TLV | 615 | | 616 | FullData TLV | 617 | | 618 | Result TLV | 619 +---------------------------------+ 621 TLVs Supported 623 7.1.4. Operation Types Supported 625 +--------------+ 626 | Operation | 627 +--------------+ 628 | Set | 629 | | 630 | Set Response | 631 | | 632 | Get | 633 | | 634 | Get Response | 635 | | 636 | Report | 637 +--------------+ 639 Operation Type Supported 641 7.2. ForCES Model Features 643 7.2.1. Basic Atomic Types Supported 645 +-------------+ 646 | Atomic Type | 647 +-------------+ 648 | uchar | 649 | | 650 | uint32 | 651 +-------------+ 653 Basic Atomic Types Supported 655 7.2.2. Compound Types Supported 657 +---------------+ 658 | Compound Type | 659 +---------------+ 660 | structs | 661 | | 662 | arrays | 663 +---------------+ 665 Compound Types Supported 667 7.2.3. LFBs Supported 669 7.2.3.1. FE Protocol LFB 671 +--------------------+ 672 | Protocol DataTypes | 673 +--------------------+ 674 | CEHBPolicy | 675 | | 676 | FEHIBPolicy | 677 +--------------------+ 679 FE Protocol LFB Datatypes 681 +---------------------+ 682 | Protocol Components | 683 +---------------------+ 684 | FEID | 685 | | 686 | CEHBPolicy | 687 | | 688 | CEHDI | 689 | | 690 | FEHBPolicy | 691 | | 692 | FEHI | 693 | | 694 | CEID | 695 +---------------------+ 697 FE Protocol LFB Components 699 7.2.3.2. FE Object LFB 701 +------------------+ 702 | Object DataTypes | 703 +------------------+ 704 | FEStateValues | 705 | | 706 | LFBSelectorType | 707 +------------------+ 709 FE Object LFB Datatypes 710 +-------------------+ 711 | Object Components | 712 +-------------------+ 713 | LFBSelectors | 714 | | 715 | FEState | 716 +-------------------+ 718 FE Object LFB Components 720 7.3. ForCES SCTP-TML Features 722 7.3.1. TML Priority Ports 724 +------------------------+ 725 | Port | 726 +------------------------+ 727 | High priority (6700) | 728 | | 729 | Medium priority (6701) | 730 | | 731 | Low priority (6702) | 732 +------------------------+ 734 Priority Ports 736 7.3.2. Message Handling at specific priorities 738 +----------------------------+ 739 | ForCES Message | 740 +----------------------------+ 741 | Association Setup | 742 | | 743 | Association Setup Response | 744 | | 745 | Association Teardown | 746 | | 747 | Config | 748 | | 749 | Config Response | 750 | | 751 | Query | 752 | | 753 | Query Response | 754 +----------------------------+ 756 Message Handling at High priority (6700) Port 757 +----------------+ 758 | ForCES Message | 759 +----------------+ 760 | Heartbeats | 761 +----------------+ 763 Message Handling at Low priority (6702) Port 765 8. Test details 767 The following tests occured: 769 +------+----------+----------+-----------+-----------+--------------+ 770 | Test | CE | FE(s) | Teardown | Result | Comment | 771 | # | | | Option | | | 772 +------+----------+----------+-----------+-----------+--------------+ 773 | 1 | Zhejiang | NTT | Teardown | Success | | 774 | | Gongshan | | from FE | | | 775 | | g | | | | | 776 | | Univers | | | | | 777 | | it y | | | | | 778 | | | | | | | 779 | 2 | Zhejiang | NTT | Teardown | Success | | 780 | | Gongshan | | from CE | | | 781 | | g | | | | | 782 | | Univers | | | | | 783 | | it y | | | | | 784 | | | | | | | 785 | 3 | Zhejiang | NTT | Cable | Success | Nobody saw | 786 | | Gongshan | | disconnec | | the loss of | 787 | | g | | t | | cable. | 788 | | Univers | | | | Everybody | 789 | | it y | | | | found out | 790 | | | | | | from loss of | 791 | | | | | | PL-heartbeat | 792 | | | | | | s | 793 | | | | | | | 794 | 4 | Zhejiang | NTT | Loss of | Success | FE didn't | 795 | | Gongshan | | CE | | send | 796 | | g | | Heartbeat | | Teardown and | 797 | | Univers | | s | | closed | 798 | | it y | | | | connection | 799 | | | | | | | 800 | 5 | Zhejiang | NTT | Loss of | Untestabl | | 801 | | Gongshan | | FE | e | | 802 | | g | | Heartbeat | | | 803 | | Univers | | s | | | 804 | | it y | | | | | 805 | | | | | | | 806 | 6 | NTT | Zhejiang | Teardown | Initial | CE couldn't | 807 | | | Gongshan | from CE | Failure | handle Query | 808 | | | g | | | Result for | 809 | | | Univers | | | unknown | 810 | | | it y | | | LFBSelects. | 811 | | | | | | | 812 | 7 | Zhejiang | Universi | Teardown | Success | Problems | 813 | | Gongshan | t y of | from FE | | with | 814 | | g | Patras | | | retransmitti | 815 | | Univers | | | | o n | 816 | | it y | | | | | 817 | | | | | | | 818 | 8 | Zhejiang | Universi | Teardown | Success | Problems | 819 | | Gongshan | t y of | from CE | | with | 820 | | g | Patras | | | retransmitti | 821 | | Univers | | | | o n | 822 | | it y | | | | | 823 | | | | | | | 824 | 9 | Zhejiang | Universi | Cable | Success | Nobody saw | 825 | | Gongshan | t y of | disconnec | | the loss of | 826 | | g | Patras | t | | cable. | 827 | | Univers | | | | Everybody | 828 | | it y | | | | found out | 829 | | | | | | from loss of | 830 | | | | | | PL-heartbeat | 831 | | | | | | s | 832 | | | | | | | 833 | 10 | Zhejiang | Universi | Loss of | Success | | 834 | | Gongshan | t y of | CE | | | 835 | | g | Patras | Heartbeat | | | 836 | | Univers | | s | | | 837 | | it y | | | | | 838 | | | | | | | 839 | 11 | NTT | Zhejiang | Teardown | Success | Test# 6. | 840 | | | Gongshan | from CE | on Repeat | Problems | 841 | | | g | | | fixed | 842 | | | Univers | | | | 843 | | | it y | | | | 844 | | | | | | | 845 | 12 | NTT | Zhejiang | Teardown | Success | | 846 | | | Gongshan | from FE | | | 847 | | | g | | | | 848 | | | Univers | | | | 849 | | | it y | | | | 850 | | | | | | | 851 | 13 | NTT | Zhejiang | Cable | Success | Nobody saw | 852 | | | Gongshan | disconnec | | the loss of | 853 | | | g | t | | cable. | 854 | | | Univers | | | Everybody | 855 | | | it y | | | found out | 856 | | | | | | from loss of | 857 | | | | | | PL-heartbeat | 858 | | | | | | s . | 859 | | | | | | | 860 | 14 | NTT | Zhejiang | Loss of | Success | Problems | 861 | | | Gongshan | CE | | with | 862 | | | g | Heartbeat | | retransmitti | 863 | | | Univers | s | | o n | 864 | | | it y | | | | 865 | | | | | | | 866 | 15 | Universi | Zhejiang | Teardown | Success | CE didn't | 867 | | t y of | Gongshan | from FE | | terminat | 868 | | Patras | g | | | after | 869 | | | Univers | | | sending | 870 | | | it y | | | Teardown. | 871 | | | | | | FE did | 872 | | | | | | | 873 | 16 | Universi | Zhejiang | Teardown | Success | Problems | 874 | | t y of | Gongshan | from CE | | with | 875 | | Patras | g | | | retransmitti | 876 | | | Univers | | | o n | 877 | | | it y | | | | 878 | | | | | | | 879 | 17 | Universi | Zhejiang | Loss of | Success | FE didn't | 880 | | t y of | Gongshan | CE | | send | 881 | | Patras | g | Heartbeat | | Teardown and | 882 | | | Univers | s | | closed | 883 | | | it y | | | connection | 884 | | | | | | | 885 | 18 | Zhejiang | NTT & | Teardown | Success | | 886 | | Gongshan | Universi | from CE | | | 887 | | g | t y of | | | | 888 | | Univers | Patrasx | | | | 889 | | it y | 2 | | | | 890 | | | | | | | 891 | 19 | NTT | Zhejiang | Teardown | Success | | 892 | | | Gongshan | from CE | | | 893 | | | g | | | | 894 | | | Univers | | | | 895 | | | it y & | | | | 896 | | | Univer | | | | 897 | | | sit y o | | | | 898 | | | f Patra | | | | 899 | | | sx2 | | | | 900 | | | | | | | 901 | 20 | Universi | NTT & | Teardown | Success | | 902 | | t y of | Zhejiang | from CE | | | 903 | | Patras | Gongshan | | | | 904 | | | g | | | | 905 | | | Univers | | | | 906 | | | it y & | | | | 907 | | | Univer | | | | 908 | | | sit y o | | | | 909 | | | f Patra | | | | 910 | | | sx2 | | | | 911 | | | | | | | 912 | 21 | Universi | Zhejiang | Batching | Success | | 913 | | t y of | Gongshan | Query and | | | 914 | | Patras | g | Config | | | 915 | | | Univers | | | | 916 | | | it y | | | | 917 | | | | | | | 918 | 22 | Universi | NTT | Teardown | Success | | 919 | | t y of | | from FE | | | 920 | | Patras | | | | | 921 | | | | | | | 922 | 23 | Universi | NTT | Teardown | Success | | 923 | | t y of | | from CE | | | 924 | | Patras | | | | | 925 | | | | | | | 926 | 24 | Universi | NTT | Loss of | Success | FE didn't | 927 | | t y of | | CE | | send | 928 | | Patras | | Heartbeat | | Teardown and | 929 | | | | s | | closed | 930 | | | | | | connection | 931 | | | | | | | 932 | 25 | Universi | NTT | Cable | Success | Nobody saw | 933 | | t y of | | disconnec | | the loss of | 934 | | Patras | | t | | cable. | 935 | | | | | | Everybody | 936 | | | | | | found out | 937 | | | | | | from loss of | 938 | | | | | | PL-heartbeat | 939 | | | | | | s | 940 | | | | | | | 941 | 26 | NTT | Universi | Teardown | Success | | 942 | | | t y of | from FE | | | 943 | | | Patras | | | | 944 | | | | | | | 945 | 27 | NTT | Universi | Teardown | Success | | 946 | | | t y of | from CE | | | 947 | | | Patras | | | | 948 | | | | | | | 949 | 28 | NTT | Universi | Loss of | Success | FE didn't | 950 | | | t y of | CE | | send | 951 | | | Patras | Heartbeat | | Teardown and | 952 | | | | s | | closed | 953 | | | | | | connection | 954 | | | | | | | 955 | 29 | NTT | Universi | Cable | Success | Nobody saw | 956 | | | t y of | disconnec | | the loss of | 957 | | | Patras | t | | cable. | 958 | | | | | | Everybody | 959 | | | | | | found out | 960 | | | | | | from loss of | 961 | | | | | | PL-heartbeat | 962 | | | | | | s | 963 +------+----------+----------+-----------+-----------+--------------+ 965 Interoperability Tests 967 9. Results 969 All implementations were found to be interoperable with each other. 971 All scenarios were tested successfully. 973 The following issues were found and dealt with. 975 1. Some messages were sent to the wrong priority channels. There 976 was some ambiguities on the SCTP-TML draft that have been 977 corrected. 979 2. At some point, a CE sent a TearDown message to the FE. The CE 980 expected the FE to shut down the connection, and the FE waited 981 the CE to shut down the connection and were caught in a 982 deadlock. This was a code bug and was fixed. 984 3. Sometimes the association setup message, only on the remote 985 connection test, although sent, was not received by the other 986 end and made impossible the association. This was caused by 987 network problems. 989 4. An implementation did not take into account that the padding in 990 TLVs MUST NOT be included in the lenght of the TLV. This was a 991 code bug and was fixed. 993 5. EM Flag was set to reserved by a CE and was not ignored by the 994 FE. This was a code bug and was fixed. 996 6. After the FEHBPolicy was set to 1 the FE didn't send any 997 HeartBeats. This was a code bug and was fixed. 999 7. Some FE's sent HeartBeats with the ACK flag with a value other 1000 than NoACK. The CE responded. This was a code bug and was 1001 fixed. 1003 8. When a cable was disconnected, the TML didn't realize that. The 1004 association was dropped due to heartbeats, this was a success, 1005 but this is an implementation issue implementers should keep in 1006 mind. This is a SCTP options issue. Nothing was needed to be 1007 done. 1009 9. A CE crashed due to unknown LFBSelector values. This was a code 1010 bug and was fixed. 1012 10. With the remote connection there were a lot of forces packet 1013 retransmittion. The problem is that packets like Heartbeats 1014 were retransmitted. This is a SCTP issue. Perhaps SCTP-PR is 1015 needed to be used. 1017 The implementers went beyond the call of duty. The test was extended 1018 with another test for batching messages. This test was also done 1019 successfully. 1021 10. Acknowledgements 1023 The authors of this draft would like to acknowledge and thank the 1024 chair of the ForCES working group Jamal Hadi Salim. 1026 Also, the authors would like to acknowledge Professors Odysseas 1027 Koufopavlou and Spyros Denazis, as well as the Department of 1028 Electrical and Computer Engineering of the University of Patras for 1029 hosting the event. 1031 11. IANA Considerations 1033 This memo includes no request to IANA. 1035 12. Security Considerations 1037 Section 9 of the FE-protocol [I-D.ietf-forces-protocol] specifies 1038 security considerations of the ForCES protocol. For this 1039 interoperability test, no security MUST be chosen even for the 1040 distributed architecture. 1042 13. References 1044 13.1. Normative References 1046 [I-D.ietf-forces-model] 1047 Halpern, J. and J. Salim, "ForCES Forwarding Element 1048 Model", draft-ietf-forces-model-16 (work in progress), 1049 October 2008. 1051 [I-D.ietf-forces-protocol] 1052 Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., 1053 Khosravi, H., and W. Wang, "ForCES Protocol 1054 Specification", draft-ietf-forces-protocol-22 (work in 1055 progress), March 2009. 1057 [I-D.ietf-forces-sctptml] 1058 Salim, J. and K. Ogawa, "SCTP based TML (Transport Mapping 1059 Layer) for ForCES protocol", draft-ietf-forces-sctptml-02 1060 (work in progress), January 2009. 1062 13.2. Informative References 1064 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1065 Requirement Levels", BCP 14, RFC 2119, March 1997. 1067 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1068 June 1999. 1070 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1071 Text on Security Considerations", BCP 72, RFC 3552, 1072 July 2003. 1074 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 1075 of IP Control and Forwarding", RFC 3654, November 2003. 1077 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 1078 "Forwarding and Control Element Separation (ForCES) 1079 Framework", RFC 3746, April 2004. 1081 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1082 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1083 May 2008. 1085 [ethereal] 1086 "Ethereal is a protocol analyzer. The specific ethereal 1087 that will be used is an updated Ethereal, by Fenggen Jia, 1088 that can analyze and decode the ForCES protocol 1089 messages.", . 1092 [tcpdump] "Tcpdump is a linux protocol analyzer. The specific 1093 tcpdump that will be used is a modified tcpdump, by Jamal 1094 Hadi Salim, that can analyze and decode the ForCES 1095 protocol messages.", . 1098 Authors' Addresses 1100 Evangelos Haleplidis 1101 University of Patras 1102 Patras, 1103 Greece 1105 Email: ehalep@ece.upatras.gr 1107 Kentaro Ogawa 1108 NTT Corporation 1109 Tokyo, 1110 Japan 1112 Email: ogawa.kentaro@lab.ntt.co.jp 1114 Xin-ping Wang 1115 Huawei Technologies Co., Ltd. 1116 China 1118 Email: carly.wang@huawei.com 1120 Chuanhuang Li 1121 Zhejiang Gongshang University 1122 18, Xuezheng Str., Xiasha University Town 1123 Hangzhou, 310018 1124 P.R.China 1126 Phone: +86-571-28877751 1127 Email: chuanhuang_li@pop.zjgsu.edu.cn