Internet DRAFT - draft-guo-forces-routing
draft-guo-forces-routing
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
-----------------------------------
<Node> <Port> <Node> <Port>
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
---------------------------------------------------------------
<Node> <Port> <DstNode> <DstPort> <NextNode> <NextPort> <Cost>
* 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:
-------------------------------------------------------------------
<Node> <Port> <DstNode> <DstPort> <NextNode> <NextPort>
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:
----------------------------------------------------------------
<Node> <Port> <DstNode> <DstPort> <NextNode> <NextPort>
FE1 B FE3 D FE2 D
-----------------------------------------------------------------
FE2
------------------------------------------------------------------
<Node> <Port> <DstNode> <DstPort> <NextNode> <NextPort>
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]
