Working Group: ForCES Xiaoyi Guo Internet Draft Huawei Technologies Expires: April 12 2006 12 October 2005 ForCES Intra-NE Routing Mechanism draft-guo-forces-routing-01.txt 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.. 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. Abstract This document describes a routing mechanism for intra-NE packet transfer path and routing table maintenance. The routing mechanism only operates during post-association phase of ForCES protocol. 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 [i]. Table of Contents Xiaoyi Expires - April 12 2006 [Page 1] Internet-Draft ForCES Routing Mechanism October 2005 1. Definitions....................................................2 2. Introduction...................................................2 2.1 Motivation .................................................3 3. Routing Mechanism..............................................4 3.1. Minimum requirements.....................................5 3.2. Routing Mechanism........................................5 3.2.1 Protocol Details....................................5 3.2.2 Update and Maintenance..............................6 3.2.3 Multi-Path Selection................................7 3.3. Routing Table Structures.................................7 3.4. Inter-FE Data Forwarding Examples........................8 4. Routing path Security.........................................10 5. Security Considerations.......................................11 6. References....................................................11 Author's Addresses...............................................11 Intellectual Property Statement..................................12 Copyright Statement..............................................12 Acknowledgments..................................................12 1.Definitions Inter-FE topology maintenance: Once the inter-FE topology has been discovered, it has to be continuously monitored to ensure that any changes to the topology are reported to the corresponding CE. This represents the steady state and final phase of the protocol. IFIB: Intra-FIB Intra-Forward Information Base, it is a partial table of a Intra-NE routing table. Edge FE: edge FE which have a port connected to other NEs or routers outside of this NE, and also connects to intra-NE FE port. Intra-NE: It describes the connection and status in a NE, these status do not contact with outside NEs or other routers. Intra-NE routing table: It describes the table contains the routing path information of Intra-NE. 2.Introduction The ForCES architecture describes how a set of control elements (CEs) and forwarding elements (FEs) interact with each other to form a single network element (NE). This document describes a routing mechanism for transferring packets in the Intra-NE topology. Xiaoyi Expires 12 April 2006 [Page 2] Internet-Draft ForCES Routing Mechanism October 2005 The mechanism is divided into two distinct operational pieces: The CE side component that uses the Intra-NE/Inter-FE topology information to compute the NE routing path and CE set the routing table to FE. The FE side component receives the IFIB table and uses it to forwarding data. As noted above, both phases occur during the post-association phases of the ForCES protocol. In other words, the ForCES protocol association between the CEs and the FEs should already have taken place. And the CE component side has computed the topology of the Intra-NE. 2.1. Motivation FE topology consideration: One NE may include many CEs and FEs, FEs may have many kinds of topology, but all can be divided into two kinds of topology: 1) One hop forwarding: all the FEs only one nexthop to arrive the edge FE, the figure is as below: ----------------- | CE | ----------------- A ^ C ^ -------B | |E ------- | FE1 |<-+ +->| FE2 | | |<--------------->| | ------- C D ------- E ^ D| C ^ | B | V | v If only one hop to the edge FE, we can use the normal routing table instead of the Intra-NE routing table. In other words, we will finish all the forwarding process even we just use the normal routing table. 2) Multi hop forwarding In this type of NE architecture, the NE will always contains more than 2 FEs and maybe one of the forwarding paths will cross several FEs. So as a multi-hop system, we need new mechanism to calculate the routing path for Intra-NE. 3.Routing Mechanism We define the Intra-NE routing mechanism of ForCES system. This mechanism can direct the packet to forwarding to the correct FEs. Xiaoyi Expires 12 April 2006 [Page 3] Internet-Draft ForCES Routing Mechanism October 2005 In a ForCES NE system, when a packet enters into one of FE port and forwarding out from another FE port, it must cross the NE intra- topology, the path something include only one FE, but sometime may include many FEs. But the packet doesn't care the NE topology and how to forwarding, we must define a correct mechanism to forwarding data packet. One NE may include many CEs and FEs, but only one CE acts as master CE. So we can only consider the table in main CE, other CE may exchange the data with the main CE, it's out of our scope. There are two kinds of tables routing table and intra-NE routing table in the NE and they are separately computed and created by CE: As we all known, CE must have a routing table which is computed by CE and have the path includes other routers or NEs together, it's computed and generated by the routing protocols such as OSPF, RIP and so on. And it keeps update with other routers or NEs. This is out of our scope. So we focus on intra-NE routing mechanism. The intra-NE routing table is for forwarding packets in intra-NE. CE will compute and update it with the full topology table in CE, because main CE can achieve the full topology of FEs. So the routing table can be easily computed in CE by using some algorithm such as SPF tree algorithm. There are two kinds of FEs in NE: Edge FE has two kinds of ports: one is out/in ports connect to other routers or NEs, the other is connect to intra FEs. Intra-FEs only connect to the edge FEs. Correspond to the edge FE routing table, the edge FE must storage two kinds of tables: FIB, for forwarding packet; IFIB, for forwarding packet in Intra-NE. For in Intra-NE routing, no other outside routing information is pertinent. In order to route to destination outside of this NE, we must create a new table ----Intra-FIB (IFIB) for forwarding within the NE. Other FEs which only connect to the same kind of FEs or edge FEs, it should not have the FIB but only IFIB table. 3.1. Minimum requirements In order for the protocol to work as described, the following assumptions are made. Xiaoyi Expires 12 April 2006 [Page 4] Internet-Draft ForCES Routing Mechanism October 2005 . Each element has been configured with their respective IDs (CEID, FEID) . Element binding's process has already taken place. In other words, the CE know all the FEs it wants to control and each FE knows which CE is allowed to control it. . The ForCES protocol association has already taken place between the CE and the FE in question. . The discovery topology protocol has already taken place. . The full topology had already computed by CE. Note that these are configuration requirements and are satisfied by the respective managers (CEM/FEM). 3.2. Routing mechanism 3.2.1. Protocol Details When main CE calculates the full topology of the NE, then we can use this topology to generate the Intra-NE routing table. ----------------- | CE | ----------------- A ^ B ^ C ^ / | \ / A v \ / ------- B \ / +->| FE3 |<-+ \ / |C | | | \ A v | ------- | v A -------B | |E ------- | FE1 |<-+ +->| FE2 | | |<--------------->| | ------- C D ------- E ^ D| C ^ | B | | | | | v | v Figure 1 From the topology discovery mechanism in Figure 1, the CE component will get the full topology of the NE. About how to generate the full topology of FEs will be found at other ForCES draft (draft-ietf- forces-discovery-00.txt)[4]. It will be shown as below: CE Topology View ----------------------------------- FE1 B FE2 D FE2 E FE3 D Xiaoyi Expires 12 April 2006 [Page 5] Internet-Draft ForCES Routing Mechanism October 2005 FE1 B FE2 C --------------------------------- The CE side component will calculate the routing table, it is easy to generate by using some algorithm, as an example, it's like the table as below: FE1 --------------------------------------------------------------- * FE1 B FE2 E FE3 C 5 FE1 C FE2 D FE2 D 6 --------------------------------------------------------------- Note: there maybe have other structures in the table, but they are not relevant to this discussion. The route which mark * is the preferred route path for forwarding. After the routing table has generated, it sends each of corresponding table to separate FEs. Note: what the routing table sends to FE is only a partial table, not the full table. It depends on the policy. When all the FEs have received the IFIB table, each FE will know how to forwarding data packet, so it will work as a small routing system. Note: when a packet enters in one of the FE ports, the FE will search the FIB first to find the nexthop and the nextport to out the NE. When it gets the next FE FEID, it will search the IFIB which is able to find how to arrive the destination FE with the FEID. This mechanism will be a forwarding process push / pop label as in an MPLS network. 3.2.2. Update and Maintenance As the figure 2 topology, since the CE needs to maintain consistent and up-to-date view of the inter-FE topology, it needs to obtain real-time information of the status of the internal links connecting the FEs. We use the topology discovery mechanism to obtain the real- time topology, so the intra-NE routing table can remain up-to-date with the real-time topology. 3.2.3 Multi-Path Selection Xiaoyi Expires 12 April 2006 [Page 6] Internet-Draft ForCES Routing Mechanism October 2005 In figure 1, we can find there are two paths to arrive the FE2 from FE1, so we need some mechanisms to select the better way for forwarding data packet. We can use some policies to select better path as below: 1) define metric as mentioned in OSPF protocol. It will calculate the cost of each data line. 2) Compute each cost of the data path, then we can get every metric in this NE topology. We still use the figure 1 to calculate the metric as below: ----------------- | CE | ----------------- A ^ B ^ C ^ / | \ / A v \ / ------- B \ / +->| FE3 |<-+ \ / |C | | | \ A v 2| ------- |1 v A -------B | |E ------- | FE1 |<-+ +->| FE2 | | |<--------------->| | ------- C 5 D ------- E ^ D| C ^ | B | | | | | V | v Figure 2 We can find each metric of data path. At the CE side component, if there exist two more paths form FE1 to FE2, we can select the better path which the metric is smaller. From figure 2, just add all the data path metric together, we can generate the first path FE1---FE2 metric is 5, and FE1---FE3---FE2 metric equal 3, so the latter path is selected by CE. 3.3. Routing table structure IFIB (intra-NE FIB) must include these necessary types of structures, but we can add additional structures later. Example: ------------------------------------------------------------------- FE1 B FE3 D FE2 D Xiaoyi Expires 12 April 2006 [Page 7] Internet-Draft ForCES Routing Mechanism October 2005 o Node is original FE Node ID of receive packet. o Port is port which connect to other intra-NE 's FE. o DstNode is the destination FE ID of data path. o DstPort is the destination FE port should be forwarded o NextNode is the Next hop FE ID that the packet should be forwarding to. o NextPort is the next port in Next hop FE. 3.4. Inter-FE Data Forwarding Examples The following example illustrates the routing mechanism of ForCES architecture. For sake of simplicity, we assume that there is only one CE per NE. The FEIDs of the FEs in the topology below are FE1, FE2, and FE3. Each FE has port IDs labeled alphabetically. This is also the case with the CE. ----------------- | CE | ----------------- A ^ B ^ C ^ / | \ / A v \ / ------- B \ / +->| FE3 |<-+ \ / |C | | | \ A v | ------- | v A -------B | |E ------- | FE1 |<-+ +->| FE2 | | |<--------------->| | ------- C D ------- E ^ D| C ^ | B | | | | | v | v Figure 3 1) During the FE neighbor discovery period, each FE sends hello packet to its neighbor, and create its own neighbor connection table, and then each FE sends its topology information to CE. 2) At the CE side component,the master CE computes the topology for NE. This reference can be found at NE topology discovery mechanism, so the Xiaoyi Expires 12 April 2006 [Page 8] Internet-Draft ForCES Routing Mechanism October 2005 master CE can easily construct the full topology from individual partial topologies reported by each FE. 3) Once the CE constructs the full topology, CE will generate Intra- NE routing table for NE. Such information can be sent to the FEs, if needed (depends on policy). As an example from the figure, one data packet comes from E port of FE1, and it should go out from B port of FE2, if FE1 and FE2 all know the full topology, it can easily go through the port FE1-C to FE2-D then forward by FE2 port B. In this NE topology, we can see there exists two paths from FE1 to FE2: 1, FE1---FE3---FE2 2, FE1---FE2 Because there existsed two more paths, we must select one, and we should select the better one. From Figure 2, we can easily calculate the first path metric is 3 which is smaller than the second path metric, 5. The master CE will prefer the first data path for forwarding: FE1--FE3--FE2 4) CE will send the IFIB to each FE, the format of IFIB has been mentioned in 3.2 sections. In FE1 and FE2, partial IFIB show as below: FE1: ---------------------------------------------------------------- FE1 B FE3 D FE2 D ------------------------------------------------------------------- FE2 ------------------------------------------------------------------- FE3 E FE2 D FE2 D -------------------------------------------------------------------- 5) Forwarding process When a packet arrives at FE1 port E, FE1 will search in the routing table or FIB table to find nexthop, FE1 can determine the packet should forward to FE2 and nexthop is FE2 port B, now the packet forwarding in the Intra-NE, FE1 then search the IFIB in FE1, the Xiaoyi Expires 12 April 2006 [Page 9] Internet-Draft ForCES Routing Mechanism October 2005 destination is FE2, so the nexthop is FE3 port D, then this packet forwarding to FE3 port D. In FE3, the destination is FE2, so this packet is forwarding from FE3 port E to FE2 port D by using IFIB nexthop FE2 and Next port D. When this packet arrives at FE2, FE2 will search the FIB table of FE2, now this packet is forwarding to the outside router or NE from FE2 port B, that is the procedure of forwarding data mechanism in the NE. Note in each edge FE, it must search the FIB and IFIB, but in other FEs, it searches IFIB only. 4. Routing path Security It is important to note that each FE only maintains partial topology information. The partial topology view seen by each FE is only the neighbor connectivity information. So the CE may not send the full routing table to each FE, it may send a partial table to separate FEs (its depend on policy) [1] The FE, at a minimum, must know all the information of its neighbour, and it also know some non-ajacent FEs topology. In figure 3, for example, FE1 should know FE2 and FE3's topology, that is to say, all of the FE know all the topology. But we can see in figure 5 below: -------------- | CE | -------------- A ^ ^ B ^ ^ D / | \ \ /------ | --\ -------\ A v A v v A v A -------B -------B -------B ---------- | FE1 |<--->| FE2 |<--->| FE3 |<--->| FE4 | ------- E------- E------- D---------- D ^ |C | | C^ |B | | | -------B | | | | V |-------->| FE5 |<------ | v E------- Figure 5 FE3 knows the topology of FE1, FE2, FE4, but not understand FE5. So each FE only knows partial topology. Xiaoyi Expires 12 April 2006 [Page 10] Internet-Draft ForCES Routing Mechanism October 2005 5. Security Considerations The ForCES protocol should ensure the communication security between CEs and FEs. FEs should ensure that only properly authenticated ForCES protocol participants are performing such manipulations. The security of neighbor discovery issues are defined in ForeCES neigbor discovery mechanism[4]. 6. References 6.1. Normative 1, [RFC3746] Yang, L., Dantu, R., Anderson, T. and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. 2, [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003. 3, [ForCESP] F P Team, "ForCES protocol specification", draft-ietf-forces-protocol-00.txt, Sept 2004. 4, [ForCES] "ForCES Intra-NE Topology Discovery ", draft-ietf-forces-discovery-00.txt, October , 2004. 6.2. Informative [OSPF] J. Moy, OSPF Version 2 1998, RFC 2328. Author's Addresses Xiaoyi Guo Huawei Technologies Co., Ltd. HuaWei Bld., No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing P.R.China Phone: +86-010-82882290 Email: xiaotian@huawei.com 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 Xiaoyi Expires 12 April 2006 [Page 11] Internet-Draft ForCES Routing Mechanism October 2005 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 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 (2005). 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. Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society. Xiaoyi Expires 12 April 2006 [Page 12]