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]