Network Working Group Huaiyuan Ma Internet Draft Zengjie Kou Expires: July 2007 Huawei Technologies Co., Ltd Weiming Wang Zhejiang Gongshang University January 16, 2007 A Framework Migrating Legacy Routers to ForCES Architecture draft-ma-forces-proxy-framework-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 16, 2007. Abstract The forwarding and Control Element Separation (ForCES) working group is defining a protocol by which control elements (CEs) can communicate with forwarding elements (FEs) and control the behaviors of FEs. It is well known that ForCES based solutions have good scalability. Therefore, it Ma,Kou&Wang Expires July 16, 2007 [Page 1] Internet-Draft draft-ma-forces-proxy-framework-02.txt January 2007 makes sense to adopt ForCES to better integrate existing physical routers with ForCES routers. Plus, someone may want going forward to be able to use the developed hardware and software from existing routers as a part of ForCES based solutions. This draft presents a framework in which some possible migration solutions are discussed in details and some security implications are considered. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Introduction................................................2 2. Solution....................................................3 2.1. Solution I.............................................3 2.2. Solution II............................................6 3. Security Considerations.....................................8 4. Acknowledgments.............................................8 5. References..................................................8 5.1. Normative References...................................8 5.2. Informative References.................................8 Author's Addresses.............................................9 Intellectual Property Statement................................9 Disclaimer of Validity.........................................10 Copyright Statement............................................10 Acknowledgment.................................................10 1. Introduction ForCES working group is defining a protocol by which control elements (CEs) can manipulate the behaviors of forwarding elements (FEs). Ma,Kou&Wang Expires July 16, 2007 [Page 2] Internet-Draft draft-ma-forces-proxy-framework-02.txt January 2007 ForCES protocol is open and routers using ForCES have good scalability, therefore, it makes sense to adopt ForCES to better integrate existing physical routers with ForCES routers. Plus, someone may want going forward to be able to use the developed hardware and software from existing routers as a part of ForCES based solutions. As we know, in existing routers vendor-specific communication mechanisms are used between physical control processors and physical forwarding processors; and physical control processors are normally general-purpose CPU, many compilers and debugging tools are available. However, the software in physical forwarding processors is developed in low-level language which is difficult to maintain. Plus, physical forwarding processors have some other constraints in memory, processing rate etc. Based on the above facts, in order to achieve our goals, an obvious principle is that the modifications to legacy routers should be minimum. The original communication mechanism between physical control processors and physical forwarding processors should be reused. Hence, one tractable place in existing routers is physical control processors. This document discusses the feasible ways to upgrade the physical control processors and security implications are considered. 2. Solution 2.1. Solution I In this solution a legacy router is rebuilt and works as a composite forwarding element (FE). In particular, due to the widely known fact that it is difficult to upgrade the software in physical forwarding processors directly, one feasible choice is to upgrade the control software in physical control processor of that router and make it function as a FE proxy. The original routing control functionalities in that router are disabled. A control element (CE) in a separate physical box can communicate with that FE proxy using ForCES protocol while the FE proxy can control that composite forwarding element using original vendor-specific communication mechanisms. Forwarding elements (FEs) in separate physical boxes can interconnect with such a composite FE using topologies suggested in [2]. Ma,Kou&Wang Expires July 16, 2007 [Page 3] Internet-Draft draft-ma-forces-proxy-framework-02.txt January 2007 +---------+ |Physical | +--------------------------------------------+ |Control |<=======>| Switch fabric | |Processor| +--------------------------------------------+ +---------+ /|\ /|\ /|\ | | | | | | | | | \|/ \|/ \|/ +---------+ +---------+ +---------+ |Physical | |Physical | |Physical | |Control | |Control | |Control | |Processor| |Processor| |Processor| +---------+ +---------+ +---------+ | | | | | | \|/ \|/ \|/ Figure 1 In order to illustrate this idea, figure 1 is a graphic description to the structure of legacy routers. In that router, physical control processor not only performs the normal routing control functionalities but also controls the forwarding behaviors of physical forwarding processors through a nonstandard communication mechanism. If the approach described in the above paragraph is applied to that router, the structure of a resulted router using ForCES protocol is depicted as below. Ma,Kou&Wang Expires July 16, 2007 [Page 4] Internet-Draft draft-ma-forces-proxy-framework-02.txt January 2007 +---------+ +----------+ +-----------------------+ | CE |<======>| FE Proxy |<=======>| Switch fabric | +---------+ +----------+ +-----------------------+ /\ /|\ /|\ /||\ | | || \|/ \|/ || +---------+ +---------+ || |Physical | |Physical | || |Control | |Control | || |Processor| |Processor| || +---------+ +---------+ || | /|\ | /|\ || \|/ | \|/ | || | | ++===============================++===== | ============++ | || | || | || | || | || | || | \||/ | \||/ | \/ \|/ \/ \|/ +----------+ +---------+ | FE |<------>| FE | +----------+ +---------+ | | | | \|/ \|/ Figure 2 Notice that in figure 2 the physical control processor in a legacy router is upgraded into a FE Proxy. After reconstruction a legacy router behaves as a composite. A control element will download appropriate forwarding-related information into that FE proxy which will in turn undertake the task translating ForCES messages into vendor-specific messages. That forwarding-related information can be organized in terms of a table to ensure the forwarding process can progress smoothly. The content in that table is specified in other ForCES protocols. The merit of this approach is scalability problem does not exist. Ma,Kou&Wang Expires July 16, 2007 [Page 5] Internet-Draft draft-ma-forces-proxy-framework-02.txt January 2007 2.2. Solution II +---------+ +-----------------------+ | CE |<=============>| Switch fabric | +---------+ +-----------------------+ /\ /|\ /|\ /||\ | | || \|/ \|/ || +---------+ +---------+ || |Physical | |Physical | || |Control | |Control | || |Processor| |Processor| || +---------+ +---------+ || | /|\ | /|\ || \|/ | \|/ | || | ++====================++===== | ============++ | || | || | || | || | \||/ | \||/ | \/ \|/ \/ \|/ +----------+ +---------+ | FE |<------>| FE | +----------+ +---------+ | | | | \|/ \|/ Figure 3 Another choice is not only to upgrade physical control processors in a legacy router into perfect control elements. The decision whether physical forwarding processors in a legacy router needs updating to support ForCES will be made by router vendors. If those physical forwarding processors are not updated, a forwarding element proxy must be mounted in CE to perform the conversion between ForCES messages and vendor-specific messages. Otherwise, such a proxy will not be used. Those control elements continue to perform normal routing control functionalities. And, of course, they also can control forwarding elements in separate physical boxes. However, this solution results in a scalability issue due to the limited amount of available interfaces in those control elements, illustrated in figure 3. In order to walk around this problem forwarding elements located in separate physical boxes can interconnect with external interfaces in legacy routers so that control element in a legacy router can control those forwarding elements through its physical forwarding processors as relay to forward messages from control elements to forwarding elements in separate physical boxes. This is a typical situation the distance between control elements and forwarding Ma,Kou&Wang Expires July 16, 2007 [Page 6] Internet-Draft draft-ma-forces-proxy-framework-02.txt January 2007 elements are two hops away, this case will be left for further consideration. The actual idea is illustrated in figure 4. +---------+ +-----------------------+ | CE |<=============>| Switch fabric | +---------+ +-----------------------+ /|\ /|\ | | \|/ \|/ +---------+ +---------+ |Physical | |Physical | |Control | |Control | |Processor| |Processor| +---------+ +---------+ | /|\ | /|\ \|/ | \|/ | | | | | \|/ \|/ +----------+ +---------+ | FE |<------>| FE | +----------+ +---------+ | | | | \|/ \|/ Figure 4 It is same as the solution I that forwarding-related information will be downloaded and mounted into physical forwarding processors in a legacy router in terms of a table appropriately. Ma,Kou&Wang Expires July 16, 2007 [Page 7] Internet-Draft draft-ma-forces-proxy-framework-02.txt January 2007 3. Security Considerations No more new security implications rather than those security issues discussed in [2] are introduced into reconstructed routers using ForCES through approaches described above. 4. Acknowledgments Sincere thanks should be given to Joel M. Halpern for his invaluable comments. 5. References 5.1. Normative References [1] Khosravi, et al. Requirements for Separation of IP Control and Forwarding, RFC 3654, November 2003. [2] L. Yang, et al. ForCES Architectural Framework, RFC 3746, April 2004. [3] Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., and S. Blake, "ForCES Forwarding Element Model", Feb. 2005. [4] A. Doria, et al. ForCES Protocol Specification, draft-ietf- forces- protocol-06.txt, December 2005. 5.2. Informative References Ma,Kou&Wang Expires July 16, 2007 [Page 8] Internet-Draft draft-ma-forces-proxy-framework-02.txt January 2007 Author's Addresses Huanyuan Ma Huawei Technologies Co., Ltd mahuaiyuan@huawei.com Zengjie Kou Huawei Technologies Co., Ltd kouzengjie@huawei.com Weiming Wang Zhejiang Gongshang University 149 Jiaogong Road Hangzhou 310035 P.R.China Phone: +86-571-88057712 Email: wmwang@mail.zjgsu.edu.cn Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Ma,Kou&Wang Expires July 16, 2007 [Page 9] Internet-Draft draft-ma-forces-proxy-framework-02.txt January 2007 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ma,Kou&Wang Expires July 16, 2007 [Page 10]