idnits 2.17.1 draft-wang-forces-compare-openflow-forces-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2012) is 4426 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-forces-lfb-lib-08 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 forces Z. Wang 2 Internet Draft Tsinghua University 3 Intended status: Informational T. Tsou 4 Expires: September 2012 J. Huang 5 Huawei 6 X. Shi 7 X. Yin 8 Tsinghua University 9 March 11, 2012 11 Analysis of Comparisons between OpenFlow and ForCES 12 draft-wang-forces-compare-openflow-forces-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on September 11, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents carefully, 45 as they describe your rights and restrictions with respect to this 46 document. 48 Abstract 50 While both ForCES and OpenFlow follow the basic idea of separations 51 of forwarding plane and control plane in network elements, they have 52 some technical differences. This document analyzes the differences 53 between OpenFlow and ForCES technically from the aspects of goals, 54 architecture, forwarding model and protocol interface. The two 55 techniques can learn much from each other in their standardization 56 process. 58 Table of Contents 60 1. Introduction ................................................ 2 61 2. Definitions used in this document............................ 3 62 3. Comparisons between ForCES and OpenFlow...................... 4 63 3.1. Comparisons in Goals.................................... 5 64 3.2. Comparisons in Architecture............................. 5 65 3.3. Comparisons in Forwarding Model......................... 8 66 3.4. Comparisons in Protocol Interface....................... 9 67 4. Security Considerations..................................... 10 68 5. IANA Considerations ........................................ 10 69 6. Conclusions ................................................ 10 70 7. References ................................................. 11 71 7.1. Normative References................................... 11 72 7.2. Informative References................................. 11 73 8. Acknowledgments ............................................ 12 75 1. Introduction 77 ForCES (Forwarding and Control Element Separation) [RFC5810] defines 78 a framework and associated protocols to standardize information 79 exchange between the control and forwarding plane in a ForCES network 80 element (NE). 82 OpenFlow [McKeown2008][OpenFlow1.2] is a concrete implementation of 83 some components of so-called SDN (Software-Defined Networking), 84 including forwarding plane abstraction (i.e., OpenFlow switches) and 85 the standard protocol between forwarding plane and control plane 86 (i.e., controller). In network elements, i.e., OpenFlow switches, 87 control plane has been separated from forwarding plane and only 88 forwarding plane is retained. The centralized controller is used to 89 control the behavior of OpenFlow switches by adding, updating and 90 deleting flow table entries in switches. ONF (Open Networking 91 Foundation, Website: https://www.opennetworking.org/) has been 92 founded in March of 2011 to promote the SDN, and especially 93 Standardize OpenFlow protocol. The latest version of OpenFlow switch 94 specification is 1.2 [OpenFlow1.2]. 96 Both ForCES and OpenFlow follow the basic idea of forwarding plane 97 and control plane separation in network elements, and result in the 98 new architecture of network devices, e.g., routers and switches. 99 However, they are technically different in many aspects. It is 100 necessary to compare the two techniques so that they can learn much 101 from each other. This document gives an initial analysis of the 102 differences and similarities between ForCES and OpenFlow from design 103 goals, architecture, forwarding model and protocol interface. 105 2. Definitions used in this document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC-2119 [RFC2119]. 111 The following definitions related to ForCES and relevant to this 112 document are taken from [RFC3654][RFC3746][RFC5810]. 114 Forwarding Element (FE) - A logical entity that implements the ForCES 115 Protocol. FEs use the underlying hardware to provide per-packet 116 processing and handling as directed by a CE via the ForCES Protocol. 118 Control Element (CE) - A logical entity that implements the ForCES 119 Protocol and uses it to instruct one or more FEs on how to process 120 packets. CEs handle functionality such as the execution of control 121 and signaling protocols. 123 ForCES Network Element (NE) - An entity composed of one or more CEs 124 and one or more FEs. An NE usually hides its internal organization 125 from external entities and represents a single point of management to 126 entities outside the NE. 128 ForCES Protocol - While there may be multiple protocols used within 129 the overall ForCES architecture, the term "ForCES protocol" refers to 130 the Fp reference points in the ForCES framework in [RFC3746]. This 131 protocol does not apply to CE-to-CE communication, FE-to-FE 132 communication, or communication between FE and CE managers. 133 Basically, the ForCES protocol works in a master-slave mode in which 134 FEs are slaves and CEs are masters. 136 ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol 137 architecture that defines the ForCES protocol messages, the protocol 138 state transfer scheme, and the ForCES protocol architecture itself 139 (including requirements of ForCES TML as shown below). 140 Specifications of ForCES PL are defined by [RFC5810]. 142 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 143 ForCES protocol architecture that uses the capabilities of existing 144 transport protocols to specifically address protocol message 145 transportation issues, such as how the protocol messages are mapped 146 to different transport media (like TCP, IP, ATM, Ethernet, etc.), and 147 how to achieve and implement reliability, multicast, ordering, etc. 148 The ForCES TML specifications are detailed in separate ForCES 149 documents, one for each TML. 151 LFB (Logical Function Block) - The basic building block that is 152 operated on by the ForCES protocol. The LFB is a well-defined, 153 logically separable functional block that resides in an FE and is 154 controlled by the CE via the ForCES protocol. The LFB may reside at 155 the FE's data path and process packets or may be purely an FE control 156 or configuration entity that is operated on by the CE. Note that the 157 LFB is a functionally accurate abstraction of the FE's processing 158 capabilities, but not a hardware-accurate representation of the FE 159 implementation. 161 LFB Class and LFB Instance - LFBs are categorized by LFB classes. An 162 LFB instance represents an LFB class (or type) existence. There may 163 be multiple instances of the same LFB class (or type) in an FE. An 164 LFB class is represented by an LFB class ID, and an LFB instance is 165 represented by an LFB instance ID. As a result, an LFB class ID 166 associated with an LFB instance ID uniquely specifies an LFB 167 existence. 169 3. Comparisons between ForCES and OpenFlow 171 ForCES and OpenFlow are very similar in the following aspects: 173 o Both ForCES and OpenFlow are efforts to separate control plane 174 from forwarding plane; 176 o Both ForCES and OpenFlow protocols standardize information 177 exchange between the control and forwarding plane. 179 Although both ForCES and OpenFlow can be considered as the solutions 180 for forwarding and control plane separation, they are different in 181 many aspects. This section compares them in their goals, architecture, 182 forwarding model and protocol interface. 184 3.1. Comparisons in Goals 186 The goal of ForCES is to break the closed box of network elements. 187 After separation of forwarding elements and control elements, it is 188 natural to define the standard, open communication interface between 189 the two kinds of elements. By using ForCES, the two kinds of 190 functional elements can be developed independently, provided both of 191 them implement the standard ForCES protocol. In this way, innovations 192 of network devices can be speeded up. 194 In ForCES, there are two kinds of physical separations: blade level 195 and box level [RFC3746]. In blade level, current network devices, 196 e.g., routers, use proprietary interfaces for communication between 197 CEs and FEs, so "the goal of ForCES is to replace such proprietary 198 interfaces with a standard protocol" [RFC3746]. In box level, the CEs 199 and FEs in one NE can be in physically separated boxes, all of which 200 form one network element together. 202 The basic idea of OpenFlow is also separation of control plane and 203 forwarding plane. But the goal of OpenFlow is beyond the new 204 architecture of network devices. In the view of ONF, OpenFlow is a 205 concrete implementation of some components that can be used to build 206 SDN, and the goal is to separate control plane from network devices 207 and use a logically centralized controller to act as the control 208 plane of the whole network. The controller can provide open APIs for 209 users to add new features in the form of applications running on the 210 controller. Such a separation simplifies the control functions and 211 speeds up innovations in the network. That is just the idea of 212 software defined networking. OpenFlow provides the standard protocol 213 between OpenFlow controller and OpenFlow switches. 215 3.2. Comparisons in Architecture 217 ForCES proposes a new architecture for network devices (NEs). It 218 separates control plane and forwarding plane in one network element 219 and allows multiple instances of CEs and FEs inside one NE. ForCES 220 protocol defines the standard communication interface between CEs and 221 FEs. But in ForCES, network architecture remains unchanged [RFC3746]: 223 o The interfaces between two ForCES NEs are identical to the 224 interfaces between two conventional routers; 226 o ForCES NEs can connect to existing routers transparently; 228 o ForCES still uses distributed protocols for control functions, 229 e.g., routing protocols. 231 Figure 1 shows ForCES Architectural Diagram [RFC5810]. 233 --------------------------------------- 234 | ForCES Network Element | 235 -------------- Fc | -------------- -------------- | 236 | CE Manager |---------+-| CE 1 |------| CE 2 | | 237 -------------- | | | Fr | | | 238 | | -------------- -------------- | 239 | Fl | | | Fp / | 240 | | Fp| |----------| / | 241 | | | |/ | 242 | | | | | 243 | | | Fp /|----| | 244 | | | /--------/ | | 245 -------------- Ff | -------------- -------------- | 246 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 247 -------------- | | |------| | | 248 | -------------- -------------- | 249 | | | | | | | | | | 250 ----+--+--+--+----------+--+--+--+----- 251 | | | | | | | | 252 | | | | | | | | 253 Fi/f Fi/f 255 Fp: CE-FE interface 256 Fi: FE-FE interface 257 Fr: CE-CE interface 258 Fc: Interface between the CE manager and a CE 259 Ff: Interface between the FE manager and an FE 260 Fl: Interface between the CE manager and the FE manager 261 Fi/f: FE external interface 263 Figure 1: ForCES Architectural Diagram [RFC5810] 265 Compared to ForCES, OpenFlow aims to change the architecture of both 266 network devices and even network itself. OpenFlow switch 267 specification [OpenFlow1.2] defines two types of OpenFlow switches: 268 OpenFlow-Only, and OpenFlow-hybrid. OpenFlow-hybrid switches support 269 both OpenFlow switch specification and normal Ethernet switch 270 functionality. To use OpenFlow-only switch, the current Internet 271 architecture will be different. In "pure" OpenFlow, network elements 272 (OpenFlow-only Switches) only retain forwarding plane to forward 273 packets by using flow tables, and provide open interfaces to the 274 logically centralized controller. There is no need to run control 275 functions such as routing protocols, signaling protocols, etc., in 276 OpenFlow-only switches. The logically centralized controller serves 277 as the control plane in OpenFlow networking. It will 278 o Collect the network view and make decisions according to control 279 logics (or applications); 281 o Interact with OpenFlow switches to install their flow tables; 283 o Provide open APIs to users, and users can program by using these 284 APIs to implement new applications. 286 Using the terms NEs (Network Elements), FEs (Forwarding Elements) and 287 CEs (Control Elements), the "pure" OpenFlow architectural diagram can 288 be shown in Figure 2. In this architecture, it should be noted that 289 here NE is not the same concept in ForCES and we just borrow the term 290 from ForCES, rather it means a network element (device) located in 291 the network to forward data packets, i.e., OpenFlow-only switches, 292 which act as both FEs and NEs. The OpenFlow controllers can be 293 centralized or distributed with multiple ones, which form the CEs in 294 OpenFlow networking, although in most of current deployments, only 295 one controller is used. 297 ---------------- ---------------- 298 | Application1 | | Application2 | ...... 299 ---------------- ---------------- 300 | APIs | 301 ---------------------------------------- 302 CE | --------------- --------------- | 303 | | OpenFlow |------| OpenFlow | | 304 | | Controller | | Controller | | 305 | --------------- --------------- | 306 ---------------------------------------- 307 | | | 308 | OpenFlow Protocol | 309 | | | 310 NE&FE | | | NE&FE 311 -------------- | -------------- 312 | OpenFlow | | | OpenFlow | 313 | Switch | | | Switch | 314 -------------- | -------------- 315 | | | | | | | | | 316 | | | | | | | | | 317 | | | | | | | | | 318 Fi/f | NE&FE | | Fi/f 319 | -------------- | 320 | | OpenFlow | | 321 | | Switch | | 322 | -------------- | 323 | | | | | | 324 | | | | | | 325 -------- | | -------- 326 Fi/f 328 Fi/f: FE external interface 330 Figure 2: "Pure" OpenFlow Architectural Diagram 331 by Using the terms NEs, FEs, CEs 333 3.3. Comparisons in Forwarding Model 335 In ForCES, [RFC5812] defines the FE (Forwarding Element) model based 336 on an abstraction of Logical Functional Blocks (LFBs). In this model, 337 each FE is composed of multiple LFBs that are interconnected in a 338 directed graph, which is represented by the LFB topology model. Each 339 LFB defines a single action of how to handle the passing packets. For 340 example, typical LFBs include IPv4/IPv6 Longest Prefix Matching, etc. 341 XML is used to describe LFB model formally. 343 In current version of OpenFlow, the forwarding model is abstract to 344 flow table manipulations. The current OpenFlow specification (version 345 1.1.0) [OpenFlow1.1] defines multiple flow tables structure in one 346 OpenFlow Switch. Each flow entry contains three parts: match fields, 347 counters and a set of instructions. Match fields are used to match 348 packets. Counters are used for statistics of matching packets. If a 349 packet is matched, it will be processed according to the instructions 350 of the corresponding flow entry. 352 In OpenFlow networking, the controller controls the behavior of 353 OpenFlow switches by adding, updating and deleting flow table entries 354 in switches. OpenFlow switches process packets in the granularity of 355 "flow": Match fields contained in each flow entry, such as, Ethernet 356 source/destination addresses, IPv4 source/destination addresses, 357 TCP/UDP source/destination ports, etc. In the current OpenFlow 358 version, the possible actions can be output (which means forwarding a 359 packet to a specified port), Set-Queue (which is used for Quality-of- 360 Service support), Set-field, Push-Tag/Pop-Tag, Drop, etc. By 361 associating various actions in a given order with each flow, OpenFlow 362 controller can control the behavior of OpenFlow networking flexibly. 363 However, in ForCES, the combination of multiple LFB instances with 364 specified topology forms each FE. [LFB-Lib] has defined various LFB 365 classes in LFBs base library, which can be used to implement 366 functions of the current network devices. Compared to ForCES, in 367 OpenFlow, it is more difficult to implement some current typical 368 network functions in OpenFlow. OpenFlow can learn from ForCES to 369 predefine some functional blocks to simplify the implementation of 370 its applications. In fact, OpenFlow-Future working group in ONF is 371 working for providing a more generic forwarding model and something 372 similar with LFBs in the future version of OpenFlow. On the other 373 hand, by using ForCES architecture, one can also define LFBs whose 374 functions are similar with flow tables in OpenFlow, which reflects 375 the flexibility of ForCES forwarding model. 377 3.4. Comparisons in Protocol Interface 379 ForCES defines two layers of protocols: ForCES Protocol Layer (ForCES 380 PL) and ForCES Protocol Transport Mapping Layer (ForCES TML). ForCES 381 PL defines Protocol between FEs and CEs (Fp Reference Point). ForCES 382 Protocol Transport Mapping Layer (ForCES TML) is defined to transport 383 the PL messages. It is expected that more than one TML will be 384 standardized and interoperability is guaranteed as long as both 385 endpoints support the same TML. [RFC5811] has defined a SCTP-based 386 TML for ForCES. This means that there will be various standard ForCES 387 TML protocols with different weights, heavy or light, and vendors can 388 choose an appropriate one from them. 390 OpenFlow defines the protocol between controller and OpenFlow 391 switches, i.e. OpenFlow protocol. Like ForCES, OpenFlow protocols 392 also use TLVs (Type-Length-Value structure) formats for message 393 encapsulation. For massage transportation, OpenFlow controller and 394 switches communicate through a TLS/SSL connection or a TCP connection 395 in the current version. 397 ForCES has longer history and is more mature than OpenFlow. OpenFlow 398 can learn much from the protocol standardization of ForCES, for 399 example: 401 o Defining Capabilities negotiation and configuration mechanism, 402 just as ForCES can do by using LFBs, which is the OF-config and 403 OpenFlow-Future working group in ONF is trying to do; 405 o Defining Protocol Transport Mapping Layer to allow various 406 standard transportation protocols. 408 4. Security Considerations 410 TBD 412 5. IANA Considerations 414 No IANA considerations. 416 6. Conclusions 418 Both ForCES and OpenFlow follow the basic idea of separations of 419 forwarding plane and control plane in network elements. This document 420 gives an initial analysis of the comparisons between OpenFlow and 421 ForCES technically from the aspects of goals, architecture, 422 forwarding model and protocol interface. From goals and architecture, 423 OpenFlow has some differences than ForCES. ForCES results in a new 424 architecture of network devices, while "pure" OpenFlow aims to result 425 in a new NETWORK architecture. In forwarding model and protocol 426 interface, ForCES and OpenFlow are similar, but from the point of 427 view of protocol standardization, ForCES are more mature and well- 428 defined. OpenFlow can learn much from ForCES protocol in its 429 standardization process. 431 At last, we can point out the potentials of ForCES protocol in SDN. 432 Although ForCES is not designed for SDN, perhaps it can also be used 433 to design a new protocol in SDN, because it is a well-defined 434 communication protocol between CEs and FEs. 436 7. References 438 7.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., 444 Dong, L., Gopal, R., and J. Halpern, "Forwarding and 445 Control Element Separation (ForCES) Protocol Specification", 446 RFC 5810, March 2010. 448 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 449 Element Separation (ForCES) Forwarding Element Model", RFC 450 5812, March 2010. 452 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 453 Layer (TML) for the Forwarding and Control Element 454 Separation (ForCES) Protocol", RFC 5811, March 2010. 456 7.2. Informative References 458 [McKeown2008] 459 McKeown, N., Anderson, T., Balakrishnan, H., et al, 460 "Openflow: enabling innovation in campus networks", ACM 461 SIGCOMM Computer Communication Review. 2008, 38(2):69-74. 463 [OpenFlow1.2] 464 OpenFlow Switch Specification Version 1.2 (Wire Protocol 465 0x03). December 5, 2011. 466 (https://www.opennetworking.org/images/stories/downloads/op 467 enflow/openflow-spec-v1.2.pdf) 469 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 470 of IP Control and Forwarding", RFC 3654, November 2003. 472 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 473 "Forwarding and Control Element Separation (ForCES) 474 Framework", RFC 3746, April 2004. 476 [LFB-Lib] Wang W., Haleplidis E., Ogawa K., Li C., J. Halpern, 477 "ForCES Logical Function Block (LFB) Library", draft-ietf- 478 forces-lfb-lib-08, Work in Progress. 480 8. Acknowledgments 482 The authors would like to thank Susan Hares, who inspired us to write 483 a Draft to indicate how ForCES compares with OpenFlow. 485 Authors' Addresses 487 Zhiliang Wang 488 Network Research Center, Tsinghua University 489 Beijing 100084 490 P. R. China 492 Email: wzl@csnet1.cs.tsinghua.edu.cn 494 Tina Tsou (Ting Zou) 495 Huawei Technologies (USA) 496 2330 Central Expressway 497 Santa Clara, CA 95050 498 USA 500 Email: Tina.Tsou.Zouting@huawei.com 502 Jing Huang 503 Huawei 505 Email: james.huang@huawei.com 507 Xingang Shi 508 Network Research Center, Tsinghua University 509 Beijing 100084 510 P. R. China 512 Email: shixg@csnet1.cs.tsinghua.edu.cn 514 Xia Yin 515 Department of Computer Science and Technology 516 Tsinghua University 517 Beijing 100084 518 P. R. China 520 Email: yxia@csnet1.cs.tsinghua.edu.cn