Network Working Group Huaiyuan Ma Internet Draft Zengjie Kou Expires: April 2007 Huawei Technologies Co., Ltd Weiming Wang Zhejiang Gongshang University October 17, 2006 A Framework Adapting Traditional Routers to ForCES Architecture draft-ma-forces-proxy-framework-01 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 April 17, 2007. Abstract In the future, in order to cut CAPex and OPex, it is desirable to integrate traditional routers into ForCES-based NEs. However, some in-service traditional routers may not implement ForCES protocol directly due to their inherent reasons. This document describes a Ma,Kou&Wang Expires April 17, 2007 [Page 1] Internet-Draft draft-ma-forces-proxy-framework-01.txt October 2006 framework where some mechanisms are specified to satisfy the above requirement 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. Motivation..................................................3 2.1. Traditional CE limit...................................3 2.2. Traditional FE limit...................................3 3. ForCES proxy................................................4 3.1. CE proxy...............................................4 3.2. FE proxy...............................................5 3.3. Interoperation.........................................7 4. Security Considerations.....................................7 5. Acknowledgments.............................................7 6. References..................................................7 6.1. Normative References...................................7 6.2. Informative References.................................8 Author's Addresses.............................................8 Intellectual Property Statement................................8 Disclaimer of Validity.........................................9 Copyright Statement............................................9 Acknowledgment.................................................9 1. Introduction ForCES is intended to separate control planes and forwarding planes through defining a standard communication protocol between CE (Control Element) and FE (Forwarding Element) such that CEs and FEs can communicate with each other seamlessly as long as they follow the protocol even if they are made by different equipment manufacturers. Ma,Kou&Wang Expires April 17, 2007 [Page 2] Internet-Draft draft-ma-forces-proxy-framework-01.txt October 2006 Thus, from this point of perspective, CEs and FEs can be separated really. This will accelerate the innovation of technologies greatly. In order to integrate traditional routers into ForCES-based NEs to reduce CAPex and OPex, this document presents a framework in which, to fulfill this goal, different restrictions on traditional routers are discussed and corresponding solutions are suggested. 2. Motivation 2.1. Traditional CE limit In traditional routers there exists a kind of CEs which use ASIC to implement certain control functionalities. These control functionalities include device management, which is responsible for the switchover of switch fabric and control plane, alarming when environment temperature or humidity exceeds specified threshold value or voltage is abnormal, resetting main board or IO card, launching instructions to load code etc. However, ForCES protocol is rather complex for such CEs compared with such functionalities as described above, and ASIC is incapable of implementing ForCES protocol. In the second case, to support ForCES protocol inside a traditional router needs a large mount of modifications to already existing private communication protocols and other functionality code consequently, which will take a high risk. 2.2. Traditional FE limit In the third case, now many different forwarding models are employed in industry, but none of them is perfect. One model may be preferable over other models regarding one or many aspects, for instance, resource consumption, forwarding performance, bandwidth requirement or stability etc. However, it may still have some inherent defects with regard to some other metrics. Now the fact that different manufacturers implement different forwarding models in their FEs will certainly lead to the inconsistency of data formats when a packet is forwarded from ingress FE to an egress FE. Consequently an ingress FE implementing one forwarding model cannot interoperate with an egress FE implementing another forwarding model. Ma,Kou&Wang Expires April 17, 2007 [Page 3] Internet-Draft draft-ma-forces-proxy-framework-01.txt October 2006 Last but not least, the same problem happens to the switch fabric. Now many different interface specifications of switch fabric have been defined. System packet Interface (SPI) and Common Switch Interface (CSIX) are these examples. However, in reality, not all FEs support many different kinds of interface at the same time. A consequent problem is how to guarantee that a FE with just one kind of interfaces (SPI or CSIX etc) can interoperate with a switch fabric with some other incompatible interface. 3. ForCES proxy 3.1. CE proxy With regard to the first two limits in traditional CEs in last section, a proxy CE can be used to terminate the Fp reference point instead of the physical CE. This allows the FE to communicate to the physical CE via the proxy CE by using ForCES protocol. A proxy CE can communicate to the corresponding physical CE by using private communication protocols rather than ForCES protocol. In such an implementation, the combination of the CE proxy and physical CE becomes one logical CE entity as shown in Figure 1. A CE proxy must implement ForCES protocol itself. At the same time, it can function as a translator of different message formats between ForCES protocol and original private communication protocols being used between physical CE and FE. With regard to the first limit described in the section 2, a CE proxy must work as a sole physical entity. Or a CE proxy can function as a logical entity which exists in some ForCES-based CE. In this case, it must differentiate a message destined to itself from one destined to the deputized physical CE. A CE proxy also can deputize multiple physical CEs at the same time. In this situation, the CE proxy can discover the functionalities of physical CEs through configurations or some kind of automatic discovery mechanism, and they must reach a consensus on the way used to differentiate messages from different physical CEs such that different messages from FEs can be delivered to the correct physical CEs and vice versa. A CE proxy can connect to CE manager. During the pre-association phrase, CE manager can decide if a CE proxy can join a NE. Ma,Kou&Wang Expires April 17, 2007 [Page 4] Internet-Draft draft-ma-forces-proxy-framework-01.txt October 2006 +------------------------------------------------------+ | switch fabric | +------------------------------------------------------+ | | | | +--------+ | | | | | CE | | | | | +--------+ | | | | | | | | | | | | +---------+ +---------+ +---------+ +--------+ | | | FE1 | | FE2 | | FE3 | | FE4 | | | +---------+ +---------+ +---------+ +--------+ | | | | | | | +----------------+ | | | | | | | | | +-----------------------------+ | | | | | | | +------------------------------------------+ | | | | | +-------------------------------------------------------+ | | +------------------------+ +---------| CE proxy | +------------------------+ | | | | | | +-----+ +-----+ +-----+ | CE1 | | CE2 | | CE3 | +-----+ +-----+ +-----+ Figure 1 3.2. FE proxy In the case where an ingress FE implementing one kind of forwarding model cannot communicate with an egress FE implementing another forwarding model, a FE proxy can be used to convert different message formats of different forwarding models. Alternately, ForCES protocol must be extended to define a forwarding-model-conversion LFB that can do the same work. In particular, a FE proxy (forwarding-model- conversion LFB) is responsible for converting the formats of head part of packets. In the case where the interface specifications of FE Ma,Kou&Wang Expires April 17, 2007 [Page 5] Internet-Draft draft-ma-forces-proxy-framework-01.txt October 2006 and switch fabric are incompatible, a physical FE proxy must be used to perform format conversion. At the same time, FE proxy must implement ForCES protocol so that it can communicate with its corresponding CE. And CE can configure FE proxy dynamically through ForCES protocol. A FE proxy either can only have the functionality of format conversion as a sole physical entity or it can function as a logical entity and coexist with some ForCES-based FE. A FE proxy can deputize one or many FEs at the same time. The combination of a FE proxy and its deputized FE can be thought of a logical FE to join a ForCES-based NE as shown in Figure 2. During the pre-association phrase, a FE proxy can contact a FE manager to determine which NE it should belong to and which CEs it should communicate with. FE proxy must have the knowledge of what forwarding model is used by its deputized FEs through negotiation. It is necessary for FE proxy to enable or disable some functionality according to the configuration specified by FE manager in a real-time fashion. +------------------------------------------------------+ | switch fabric | +------------------------------------------------------+ | /|\ | /|\ | /|\ | | | | | | | | | | | | \|/ | | | | | +------+ forCES +----------+ | | | | | CE | ------>| FE proxy | | | | | +------+ +----------+ | | | | | | /|\ | | | | | | | | | | | | | | | | | | | \|/ | \|/ | \|/ | | +----------+ +-----------+ +-----------+ +---------->| FE1 | | FE2 | | FE2 | | +----------+ +-----------+ +-----------+ | /|\ /|\ | | | +-----------------------------------+ | | | | | | | +------------------------------------------------------+ Figure 2 Ma,Kou&Wang Expires April 17, 2007 [Page 6] Internet-Draft draft-ma-forces-proxy-framework-01.txt October 2006 3.3. Interoperation In order to guarantee the interoperation between traditional routers and CE/FE proxy, it is required that private communication protocol inside traditional routers must be public. 4. Security Considerations A CE proxy and its corresponding physical CE can be located in two different physical boxes. In this situation, some security implications must be considered seriously, and corresponding security mechanisms must be applied to prevent malicious attacks. Candidate security mechanisms include all current available authorization and authentication mechanisms. Which mechanism will be applied eventually depends on the kind of attack and physical CE's potential supporting authorization and authentication. In the case where a FE proxy and its corresponding FEs also can be located in different physical boxes, security implication must be considered too. Some security authentication and authorization mechanism can be applied to the private communication mechanism to achieve dependability. All current available authentication mechanisms can be candidates to be chosen carefully, which security mechanism is fit for our purpose depends on the kind of attack and FE's potential supporting authorization and authentication. 5. Acknowledgments 6. References 6.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. Ma,Kou&Wang Expires April 17, 2007 [Page 7] Internet-Draft draft-ma-forces-proxy-framework-01.txt October 2006 [4] A. Doria, et al. ForCES Protocol Specification, draft-ietf- forces- protocol-06.txt, December 2005. 6.2. Informative References 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 Ma,Kou&Wang Expires April 17, 2007 [Page 8] Internet-Draft draft-ma-forces-proxy-framework-01.txt October 2006 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. 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 (2006). 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 April 17, 2007 [Page 9]