ForCES Xiaoyi Guo draft-guo-forces-routing-02.txt Huawei Technologies Expires: September 6 March 6, 2006 ForCES Intra-NE Routing Mechanism draft-guo-forces-routing-02.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 This Internet-Draft will expire on September 6, 2006. 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. Xiaoyi September 6, 2006 [Page 1] Internet-Draft ForCES routing Oct March 2006 Table of Contents 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..........................................9 5. Security Considerations........................................9 6. References.....................................................9 6.1. Normative.................................................9 6.2. Informative...............................................10 7. Author's Addresses.............................................10 8. Intellectual Property Statement................................10 9. Copyright Statement............................................10 10.Acknowledgments................................................10 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. Edge FE: edge FE which has 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). It describes the ForCES post-association phase protocol working across the Fp reference point between CE and Xiaoyi September 6, 2006 [Page 2] Internet-Draft ForCES routing Oct March 2006 FE. This document describes an important aspect of the ForCES operational infrastructure - that of routing mechanism for forwarding packets in the Intra-NE topology. 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 Inter-NE forwarding 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 An 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 Figure(1) 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 to calculate the correct routing path for Intra-NE. Xiaoyi September 6, 2006 [Page 3] Internet-Draft ForCES routing Oct March 2006 3. Routing Mechanism ----------------- | 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 (2) illustrates the internal/external links and topology within a NE. We define the Intra-NE routing mechanism of ForCES system. This mechanism can direct the packet to forwarding to the correct FEs. 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 include one FE and sometime include many FEs. An 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. An NE can contain FEs that have zero or more internal/external links e.g. in Fig. 2, FE3 has two internal links and no external links while FE1 and FE2 have two internal links and one external link each. It is important to note that the type definition for given for a link is only logical, because a given physical link may be a combination of more than one type - e.g. it could simultaneously be a control link and an internal link at the same time. Based on this link definition, an FE can be considered to be an internal FE if it only contains internal links and an edge FE if it contains external links (and may also contain internal links). There are two kinds of tables: routing table and intra-NE routing table in the NE. The two tables are all generated by the CE. The intra-NE forwarding table is generated from the full topology information of the FE, while the inter-NE forwarding table is Xiaoyi September 6, 2006 [Page 4] Internet-Draft ForCES routing Oct March 2006 constructed in the normal way by the routing protocols such as OSPF, BGP etc. The CE publishes the two forwarding tables to the FEs (depending on security and policy). The intra-FE only contains the intra-NE forwarding table while the Edge-FE contains both the tables. And it keeps update with other routers or NEs. This is out of our scope. 3.1. Minimum requirements In order for the protocol to work as described, the following assumptions are made. . 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 From the topology discovery mechanism in Figure 2, the CE component will get the full topology of the NE. About how to generate the full topology of FEs will be found at the ForCES discovery draft [4]. It will be shown as below: CE Topology View ----------------------------------- FE1 B FE2 D FE2 E FE3 D FE1 B FE2 C ----------------------------------- Xiaoyi September 6, 2006 [Page 5] Internet-Draft ForCES routing Oct March 2006 After the CE computes the full topology, we can use this information to generate the intra-NE forwarding table. The CE then publishes (or notifies, if subscribed) this forwarding table information to the FEs. Depending on the policy, only partial forwarding table needs to be sent to any particular FE, rather than the full forwarding table that consists of both intra-NE and inter-NE forwarding entries. When all the FEs has received the inter-NE forwarding table, they can forward data packets from the ingress to the egress FE. The CE side component will calculate the routing table, 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: when a packet enters one of the Edge-FE ports, the FE will first search/lookup the external (inter-NE) forwarding table to determine the nexthop and the nexthop port of the egress FE. When it obtains the next FE/FEID and the destination port, it will now consult the internal forwarding table to determine the path to reach the destination FE/FEID. This mechanism is similar to the push/pop label forwarding process in an MPLS network. Please refer section 3.4 for more details. 3.2.2. Update and Maintenance The CE aggregates the partial topology information received from each FE and generates the inter-FE topology. With this complete knowledge of the inter-FE topology, it can now make appropriate updates to the LFB tables and routing table on each FE to move packets inside the NE from ingress FE to egress FE, assuming that the destination of the packet is not the current NE itself. Any changes in the internal link states (and hence the topology) requires that the CE reconfigure the LFB tables on the FEs based on the most up-to-date Xiaoyi September 6, 2006 [Page 6] Internet-Draft ForCES routing Oct March 2006 information to ensure that the packets do not end up in a black hole or enter a loop. 3.2.3 Multi-Path Selection When multiple paths are available for traversing from the ingress to the egress FE, an appropriate forwarding path needs to be selected. Policies can be configured to perform appropriate path selection. An attribute such as link cost or metric can be defined for the internal links as in OSPF protocol. We can now calculate and select the path with the lowest cost. ----------------- | 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 (3) illustrates the two paths exist in one NE From figure 3, just add all the data path metric together, we can generate the first path FE1---FE2 metric is 5, and the path FE1--- FE3---FE2 metric equal 3, so the latter path is selected by CE. 3.3. Routing table structure The intra-NE forwarding table contains the following types of structures. Additional structures such as VlanID can be added in the future. Example: ------------------------------------------------------------------- FE1 B FE3 D FE2 D Xiaoyi September 6, 2006 [Page 7] Internet-Draft ForCES routing Oct March 2006 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 packet forwarding within the NE. We use figure 3 as the NE topology. The topology provides the cost of traversing particular links as well. Once the CE constructs the full topology, it needs to construct the forwarding table based on the best available path for a particular internal destination. In our example, two paths exist from FE1 and FE2: Path 1 => FE1---FE3---FE2 => Cost 3 Path 2 => FE1---FE2 => Cost 5 Based on the above information, it can be seen that the total path cost for path 1 is better than that for path 2 and hence CE picks the first path as the best path for forwarding and installs it into the forwarding tables of the FEs. In FE1 and FE2, partial forwarding table show as below: FE1: ---------------------------------------------------------------- FE1 B FE3 D FE2 D ----------------------------------------------------------------- FE2 ------------------------------------------------------------------ FE3 E FE2 D FE2 D ------------------------------------------------------------------ Xiaoyi September 6, 2006 [Page 8] Internet-Draft ForCES routing Oct March 2006 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 Internal FIB in FE1, the 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 Internal FIB 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, which is the procedure of forwarding data mechanism in the NE. Note in each edge FE, it must search internal and external forwarding tables, but in internal FEs, it searches internal forwarding table only. The TTL of the packet should be decremented only once as it traverses the NE regardless of how many FEs through which it passes. 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] 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 is defined in ForCES neighbor 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. Xiaoyi September 6, 2006 [Page 9] Internet-Draft ForCES routing Oct March 2006 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. 7. 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 Email: xiaotian@huawei.com 8. IANA Considerations There are no IANA considerations at this point since the protocol completely operates within an NE. 9. Full Copyright Notice "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." "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." 10. Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society. Xiaoyi September 6, 2006 [Page 10]