Internet DRAFT - draft-guan-router-federation

draft-guan-router-federation





                                                                        
   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]