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]