Internet Draft Jianbo Guan Zhigang Sun Document: draft-guan-router-federation-00.txt NUDT Expires: September 2006 March 2006 Requirements for Router Federation 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. Distribution of this document is unlimited. Comments should be sent to the author. 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document introduces router federation (RF) architecture that is used to optimize the Point of presence (POP). The document also defines a set of architectural and protocol requirements to construct a RF based on several existing routers from different vendors. 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]. Guan Expires - September 2006 [Page 1] INTERNET-DRAFT Requirements for Router Federation March 2006 Table of Contents 1. Introduction...................................................2 2. Definitions....................................................3 3. Architecture...................................................3 4. Architecture requirements......................................5 5. Protocol requirements..........................................6 5.1 Switch Fabric Aggregate Protocol...........................6 5.2 RFM Management Protocol....................................6 5.3 Lightweight Interconnection protocol.......................7 Security Considerations...........................................7 References........................................................7 Acknowledgments...................................................9 Author's Addresses................................................9 1. Introduction Traditional Point of Presence (POP) is constructed as a router cluster, which typically compose of two core routers, many aggregate routers and access routers. As the network expand and new services emerged, service providers find that this cluster architecture has many disadvantages, such as lack of scalability, sub-optimal performance, expensive but no revenue interconnections and complicated network management etc. To overcome these disadvantages, one method device vendors and service providers used is collapsing the cluster structure. They built and equip multi-shelf routers (MSR) in POP. MSR compliance all requirements for IP routers, it has tens or hundreds of line cards supporting any port type and any speed, which are connected by scalable high speed switching networks. Using MSR, all existing routers at POP can be replaced and high scalability, availability and easy management can be achieved. RF is another method to simplify the POP. Unlike collapsing cluster structure as MSR, RF optimizes the cluster. It use special protocols and dedicated hardwire to optimize performance and simplify management of the cluster. In the sight of network manager, RF looks like a router, it has only one access entry for configuration and management. But in the sight of other routers, there are more than one routers in RF. So RF is NOT a true router and SHOULD NOT compliance rules for IP routers. Using RF, service providers can achieve the same effect as MSR to optimize the edge, but it need no cost for complete new facilities. This require device vendors update their router software with RF protocols and provide dedicated line cards to interconnect each other with low cost and high performance. Guan Expires - September 2006 [Page 2] INTERNET-DRAFT Requirements for Router Federation March 2006 2. Definitions Router Cluster (RC) - A group of routers working together for the same propose, such as high performance switching and routing or high available core network access. Normally, these routers are connected directly by line cards, physically located nearly (always in one building) and managed by the same administrator. Router Federation (RF) – An optimized RC. Routers in RF are coupled more tightly than those in normal RC by using special RF protocols (see below) and dedicated lightweight interconnecting cards (see below), to achieve optimization in multiple aspects such as performance, management and availability. RF Protocol – Special protocols running on routers in RF. Main functions of RF protocols are RF switch fabric aggregation, RF manager (see below) control, inner-RF congestion elimination etc. Lightweight Interconnecting Card (LIC) – A special and low cost line card used to connect switch fabrics among different routers in RF. Through a pair of these cards, one packet arrived at an input port on one router can be directly switched to the output port on another router. So all routers’ switch fabric in RF are aggregated as one switch network logically. Normally, processing on LIC is cell based to short cut processing delay and the processing is lightweight so no complicated network processors or ASICs are needed. RF Manager (RFM) – A logic entity that implements all management and control functions in RF. Every time one and only one Master RF manager (MRFM) and one or more Slave RF managers (SRFM) can be running in RF. Once MRFM works abnormally, it will be replaced by one of the slave RF manager. MRFM Selection and management are controlled by RFMMP (see section 5.2). 3. Architecture RF is optimized router cluster. A visible change is all line cards used for interconnection within the cluster are replaced by dedicated lightweight interconnection cards. Each device vendor SHOULD provide its own LIC, which has a private interface connecting internal property switch fabric and a standard interface for inter-router connection. Below is a diagram illustrating a simple RF which contain four separate routers. In this example, four internal links, A3-C1, A4-D1, B3-C2 and B4-D2, are illustrated by plus sign lines. Each link is composed of a pair of LICs belonging to different routers. A point to point lightweight RF interconnection protocol (see section 4.1) is running on the internal links replacing now used Guan Expires - September 2006 [Page 3] INTERNET-DRAFT Requirements for Router Federation March 2006 standard data link protocol such as 802.3 Ethernet or Packet Over SONET. Because of lightweight protocol and short transmit length, LIC does not need high processing capacity and expensive laser modules. So it is much cheaper than normal line cards. A1 A2 B1 B2 | | | | ----------------------------------------- |RF | | | | | | | | | | | | ----------- ----------- | | |Router A | |Router B | | | ----------- ----------- | | + + + + | | A3 + A4 + + B3 + B4 | | + + + + | | + ++ + | | + + + + | | + + + + | | C1 + C2 + + D1 + D2 | | ----------- ----------- | | |Router C | |Router D | | | ----------- ----------- | | | | | | | | | | | | | | | | | ----------------------------------------- | | | | | | C3 C4 C5 D3 D4 D5 ---------- ---------- | RFM B | | RFM C | ---------- ---------- | | ----------- | | ---------- | RFM A | | | | RFM D | ----------- | | ---------- | | | | ---------------------------- A1-----| |-----A2 B1-----| RF |-----B2 C3-----| switch Fabric |-----C4 | | ---------------------------- | | | | | | | | | | | | C5 D3 D4 D5 Guan Expires - September 2006 [Page 4] INTERNET-DRAFT Requirements for Router Federation March 2006 Figure 1 A simple RF There may have four RFMs reside on each router, but only one can be MRFM and the others are SRFM. For example, MRFM resides on router A which has the most powerful control plane processing capability, and three SRFM runs on router B/C/D. But if MRFM on router fault, a new MRFM MUST be selected. In the view of network administrator, RF MUST work as a single router to achieve easy management. This means in each RFM’s sight, RF act as one router. Also use figure 1 as example, the POP is constructed by one router with ten line cards, marked as A1/A2/B1/B2/C3/C4/C5/D3/D4/D5, and eight line cards used for internal interconnection, marked as A3/A4/B3/B4/C1/C2/D1/D2, are invisible. To achieve single router view at control plane, a group of protocols MUST be implemented on every router in RF. This will be discussed in section 4. Routers in RF MAY come from different vendors, and each router MAY has its own software and hardware implementation, so it is hard to guarantee that IP header be changed (such as TTL modification) only once in RF scope. So RF is not a real router that compliance requirements in RFC1812 [ii]. To optimize performance in RF scope, flow control mechanism SHOULD be applied on internal links, so each router can collect all the congestion states in RF. Using these global states, each router can optimize its local forwarding decision and switch fabric scheduling priorities. 4. Architecture requirements The following are the architecture requirements: 1) Routers in RF MUST be connected by dedicated low delay LICs for performance and economical considerations. Lightweight processing on LIC MUST be simple so no complex Network processor or ASIC are needed. 2) LIC MUST be carefully standard, including fiber interface, Point to Point link layer Protocol and flow control mechanisms. So vendors can provide LICs with their existing or future router products for optimized interconnection with routers from other vendors in RF. 3) RF MUST NOT have any limits on router internal implementation detail. One example of internal implementation is switch fabric, Guan Expires - September 2006 [Page 5] INTERNET-DRAFT Requirements for Router Federation March 2006 which may be IO bus, crossbar, shared memory or other structures. Vendors can implement their own LIC internal interface to integrate with their private switch fabric. 4) RF MUST provide just one access point to clusters. That is, administrator can login to RF at an arbitrary router in the cluster, but different choices have the same access point to manage the system. 5) The instance of each routing or signaling protocols MUST be startup and running on at least one router. Different protocols MAY be running centralized or distributed among several routers. And even one protocol can be executed parallel in a few routers. 5. Protocol requirements This section specifies some protocols that MUST be implemented for routers in RF. 5.1 Switch Fabric Aggregate Protocol Switch Fabric Aggregate Protocol (SFAP) is used to aggregate all routers’ switch fabrics in RF to a big, virtual switch network. The following functions MUST be implemented. 1) Discover routers’ connectivity in RF through some kind of dynamic topology discovery mechanism. This is the base of switch fabric aggregation. Link state changes inside RF MUST be detected in time. 2) Collect some static properties of each switch fabric and interconnection links. Static properties about switch fabric include topology, buffer size and scheduling algorithm. Static properties about interconnection link include bandwidth and buffer size. 3) Construct a big virtual switch network based on switch fabrics in each router and some flow control mechanism MUST be used to optimize the performance. In RFM’s sight, this virtual switch network is the working switch fabric and details about its internal components and connection is invisible. 5.2 RFM Management Protocol RFM Management Protocol (RFMMP) is used to select MRFM in RF which implement all operations required from system administrator and network management protocols. The following functions MUST be implemented. Guan Expires - September 2006 [Page 6] INTERNET-DRAFT Requirements for Router Federation March 2006 1) Each router in RF can notify their control plane processing capacity, include CPU types, memory capacities etc. These information and a unique identifier are put in a selecting frame and the frame is flooded throughout. 2) MRFM is selected on some rules after all selecting frames are flooded. Select the most powerful RFM to be MRFM is a reasonable method. 3) if MRFM in RF fault, another MRFM selection process SHOULD be triggered and a new MRFM MUST be selected in time. 4) Each router MUST register its hardware description information to MRFM, such as, line card number, packet buffer size, LIC interfaces and their interconnection neighbors. SFAP uses these information to construct virtual switch network and guides the packets switching procedure. 5.3 Lightweight Interconnection protocol Lightweight Interconnection Protocol (LIP) defines the link level communication mechanism and cell formats between routers in RF, and also defines the behavior of function components on LIC. The following functions MUST be implemented. 1) Each router in RF can communicate with its neighbor router in RF through LIC. The interface type, link level transfer mechanism, and cell formats of LIC SHOULD be standardized so router can communicate with each other properly. Several classes of interface speed of LIC SHOULD also be specified and for OPTIONAL. 2) Function components on LIC MUST identify the cell type received and process cells properly. Some tags MAY be attached to cells for this purpose. 3) Cells containing control information SHOULD be redirect to the MRFM, while cells containing payload data SHOULD be switched to the destination output port. Tags on cells MAY be replaced by LIC during this process. Security Considerations The RF protocol should ensure the communication security between routers in RF. References Guan Expires - September 2006 [Page 7] INTERNET-DRAFT Requirements for Router Federation March 2006 i Bradner, S.,"Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 ii Baker, F., "Requirements for IP version 4 routers",RFC1812,1995. Guan Expires - September 2006 [Page 8] INTERNET-DRAFT Requirements for Router Federation March 2006 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. Acknowledgments Author's Addresses Jianbo Guan National University of Defense Technology Changsha China Phone: +86-731-4575815 Email: guanjb@nudt.edu.cn Zhigang Sun National University of Defense Technology Changsha China Phone: +86-731-4575815 Email: sunzhigang@263.net Guan Expires - September 2006 [Page 9]