draft-ietf-forces-framework-02.txt   draft-ietf-forces-framework-03.txt 
Internet Draft L. Yang Internet Draft L. Yang
Expiration: April 2003 Intel Corp. Expiration: April 2003 Intel Corp.
File: draft-ietf-forces-framework-02.txt R. Dantu File: draft-ietf-forces-framework-03.txt R. Dantu
Working Group: ForCES Univ. of Texas Dallas Working Group: ForCES Univ. of Texas Dallas
T. Anderson T. Anderson
Intel Corp. Intel Corp.
Oct 2002 Oct 2002
ForCES Architectural Framework ForCES Architectural Framework
draft-ietf-forces-framework-02.txt draft-ietf-forces-framework-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at line 36 skipping to change at line 36
progress.'' progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines the architectural framework for ForCES This document defines the architectural framework for the ForCES
(Forwarding and Control Element Separation) network elements (NE), (Forwarding and Control Element Separation) network elements (NE),
and identifies the associated entities and the interaction among and identifies the associated entities and the interaction among
them. This framework is intended to satisfy the requirements them. This framework is intended to satisfy the requirements
specified in the ForCES requirements draft [FORCES-REQ]. specified in the ForCES requirements draft [FORCES-REQ].
Table of Contents Table of Contents
1. Definitions.....................................................2 1. Definitions.....................................................2
2. Introduction to Forwarding and Control Element Separation 2. Introduction to Forwarding and Control Element Separation
(ForCES)...........................................................4 (ForCES)...........................................................4
3. Architecture....................................................7 3. Architecture....................................................7
3.1. Control Elements and Fr Reference Point....................8 3.1. Control Elements and Fr Reference Point....................8
3.2. Forwarding Elements and Fi reference point.................8 3.2. Forwarding Elements and Fi reference point.................9
3.3. CE Managers...............................................11 3.3. CE Managers...............................................11
3.4. FE Managers...............................................11 3.4. FE Managers...............................................11
4. Operational Phases.............................................11 4. Operational Phases.............................................12
4.1. Pre-association Phase.....................................12 4.1. Pre-association Phase.....................................12
4.1.1. Fl Reference Point...................................12 4.1.1. Fl Reference Point...................................12
4.1.2. Ff Reference Point...................................13 4.1.2. Ff Reference Point...................................13
4.1.3. Fc Reference Point...................................13 4.1.3. Fc Reference Point...................................13
4.2. Post-association Phase and Fp reference point.............14 4.2. Post-association Phase and Fp reference point.............14
4.2.1. Proximity and Interconnect between CEs and FEs.......14 4.2.1. Proximity and Interconnect between CEs and FEs.......14
4.2.2. Association Establishment............................14 4.2.2. Association Establishment............................14
4.2.3. Steady-state Communication...........................15 4.2.3. Steady-state Communication...........................15
4.2.4. Data Packets across Fp reference point...............16 4.2.4. Data Packets across Fp reference point...............16
4.2.5. Proxy FE.............................................17 4.2.5. Proxy FE.............................................17
4.3. Association Re-establishment..............................17 4.3. Association Re-establishment..............................17
5. Applicability to RFC1812.......................................18 5. Applicability to RFC1812.......................................18
5.1. General Router Requirements...............................18 5.1. General Router Requirements...............................19
5.2. Link Layer................................................19 5.2. Link Layer................................................20
5.3. Internet Layer Protocols..................................20 5.3. Internet Layer Protocols..................................20
5.4. Internet Layer Forwarding.................................20 5.4. Internet Layer Forwarding.................................21
5.5. Transport Layer...........................................21 5.5. Transport Layer...........................................21
5.6. Application Layer -- Routing Protocols....................21 5.6. Application Layer -- Routing Protocols....................22
5.7. Application Layer -- Network Management Protocol..........21 5.7. Application Layer -- Network Management Protocol..........22
6. Summary........................................................22 6. Summary........................................................22
7. Security Considerations........................................22 7. Security Considerations........................................23
8. Intellectual Property Right....................................22 8. Intellectual Property Right....................................23
9. References.....................................................22 9. References.....................................................23
9.1. Normative References......................................22 9.1. Normative References......................................23
9.2. Informative References....................................23 9.2. Informative References....................................23
10. Acknowledgments...............................................23 10. Acknowledgments...............................................24
11. Authors' Addresses............................................23 11. Authors' Addresses............................................24
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119]. this document are to be interpreted as described in [RFC-2119].
1. Definitions 1. Definitions
A set of terminology associated with the ForCES requirements is A set of terminology associated with the ForCES requirements is
skipping to change at line 111 skipping to change at line 111
and signaling protocols. and signaling protocols.
Yang, et. al. Expires April 2003 [Page 2] Yang, et. al. Expires April 2003 [Page 2]
ForCES Network Element (NE) - An entity composed of one or more CEs ForCES Network Element (NE) - An entity composed of one or more CEs
and one or more FEs. To entities outside a NE, the NE represents a and one or more FEs. To entities outside a NE, the NE represents a
single point of management. Similarly, a NE usually hides its single point of management. Similarly, a NE usually hides its
internal organization from external entities. internal organization from external entities.
Pre-association Phase - The period of time during which a FE Manager Pre-association Phase - The period of time during which a FE Manager
(see below) and a CE Manager (see below) are determining which FE (see below) and a CE Manager (see below) are determining which FE
and CE should be part of the same network element. Any partitioning and CE should be part of the same network element.
of PFEs and PCEs occurs during this phase.
Post-association Phase - The period of time during which a FE does Post-association Phase - The period of time during which a FE does
know which CE is to control it and vice versa, including the time know which CE is to control it and vice versa, including the time
during which the CE and FE are establishing communication with one during which the CE and FE are establishing communication with one
another. another.
ForCES Protocol - While there may be multiple protocols used within ForCES Protocol - While there may be multiple protocols used within
the overall ForCES architecture, the term "ForCES protocol" refers the overall ForCES architecture, the term "ForCES protocol" refers
only to the ForCES post-association phase protocol (see below). only to the ForCES post-association phase protocol (see below).
skipping to change at line 156 skipping to change at line 155
the CE manager learning the capabilities of available FEs. A CE the CE manager learning the capabilities of available FEs. A CE
manager may use anything from a static configuration to a pre- manager may use anything from a static configuration to a pre-
association phase protocol (see below) to determine which FE to use. association phase protocol (see below) to determine which FE to use.
Being a logical entity, a CE manager might be physically combined Being a logical entity, a CE manager might be physically combined
with any of the other logical entities mentioned in this section. with any of the other logical entities mentioned in this section.
Pre-association Phase Protocol - A protocol between FE managers and Pre-association Phase Protocol - A protocol between FE managers and
CE managers that is used to determine which CEs or FEs to use. A CE managers that is used to determine which CEs or FEs to use. A
pre-association phase protocol may include a CE and/or FE capability pre-association phase protocol may include a CE and/or FE capability
discovery mechanism. Note that this capability discovery process is discovery mechanism. Note that this capability discovery process is
wholly separate from (and does not replace) that used within the
Yang, et. al. Expires April 2003 [Page 3] Yang, et. al. Expires April 2003 [Page 3]
wholly separate from (and does not replace) that used within the
ForCES protocol. However, the two capability discovery mechanisms ForCES protocol. However, the two capability discovery mechanisms
may utilize the same FE model. may utilize the same FE model.
FE Model - A model that describes the logical processing functions FE Model - A model that describes the logical processing functions
of a FE. of a FE.
ForCES Protocol Element - A FE or CE. ForCES Protocol Element - A FE or CE.
2. Introduction to Forwarding and Control Element Separation (ForCES) 2. Introduction to Forwarding and Control Element Separation (ForCES)
skipping to change at line 189 skipping to change at line 188
are typically based on general-purpose processors that provide are typically based on general-purpose processors that provide
control functionality like routing and signaling protocols. control functionality like routing and signaling protocols.
ForCES aims to define a framework and associated protocol(s) to ForCES aims to define a framework and associated protocol(s) to
standardize information exchange between the control and forwarding standardize information exchange between the control and forwarding
plane. Having standard mechanisms allows CEs and FEs to become plane. Having standard mechanisms allows CEs and FEs to become
physically separated standard components. This physical separation physically separated standard components. This physical separation
accrues several benefits to the ForCES architecture. Separate accrues several benefits to the ForCES architecture. Separate
components would allow component vendors to specialize in one components would allow component vendors to specialize in one
component without having to become experts in all components. component without having to become experts in all components.
Standard protocol also allows CEs and FEs from different component Standard protocol also allows the CEs and FEs from different
vendors to interoperate with each other and hence it becomes component vendors to interoperate with each other and hence it
possible for system vendors to integrate together CEs and FEs from becomes possible for system vendors to integrate together the CEs
different component vendors. This interoperability translates into a and FEs from different component suppliers. This interoperability
lot more design choices and flexibility to the system vendors. translates into a lot more design choices and flexibility to the
Overall, ForCES will enable rapid innovation in both the control and system vendors. Overall, ForCES will enable rapid innovation in both
forwarding planes while maintaining interoperability. Scalability is the control and forwarding planes while maintaining
also easily provided by this architecture in that additional interoperability. Scalability is also easily provided by this
forwarding or control capacity can be added to existing network architecture in that additional forwarding or control capacity can
elements without the need for forklift upgrades. be added to existing network elements without the need for forklift
upgrades.
One example of such physical separation is at the blade level. One example of such physical separation is at the blade level.
Figure 1 shows such an example configuration of a router, with two Figure 1 shows such an example configuration of a router, with two
control blades and multiple router (forwarding) blades, all control blades and multiple router (forwarding) blades, all
interconnected into a switch fabric backplane. In such chassis interconnected into a switch fabric backplane. In such chassis
configuration, the control blades are the CEs while the router configuration, the control blades are the CEs while the router
blades are FEs, and the switch fabric backplane provides the blades are FEs, and the switch fabric backplane provides the
physical interconnect for all the blades. Control blade A may be the physical interconnect for all the blades. Control blade A may be the
primary CE while control blade B is the backup CE providing primary CE while control blade B is the backup CE providing
redundancy. It is also possible to have a redundant switch fabric redundancy. It is also possible to have a redundant switch fabric
skipping to change at line 316 skipping to change at line 316
include routing protocols like RIP, OSPF and BGP, control and include routing protocols like RIP, OSPF and BGP, control and
signaling protocols like CAC (Call Admission Control), LDP (Label signaling protocols like CAC (Call Admission Control), LDP (Label
Distribution Protocol) for MPLS, etc. Examples of forwarding Distribution Protocol) for MPLS, etc. Examples of forwarding
functions in FE include LPM (longest prefix match) forwarder, functions in FE include LPM (longest prefix match) forwarder,
classifiers, traffic shaper, meter, NAT, etc. Figure 3 shows a classifiers, traffic shaper, meter, NAT, etc. Figure 3 shows a
diagram with examples in both CE and FE. Any given NE may contain diagram with examples in both CE and FE. Any given NE may contain
one or many of these CE and FE functions in it. The diagram also one or many of these CE and FE functions in it. The diagram also
shows that ForCES protocol is used to transport both the control shows that ForCES protocol is used to transport both the control
messages for ForCES itself and the data packets that are messages for ForCES itself and the data packets that are
originated/destined from/to the control functions in CE (e.g., originated/destined from/to the control functions in CE (e.g.,
routing packets). Section 5.2.4 provides more detail on this. routing packets). Section 4.2.4 provides more detail on this.
A set of requirements for control and forwarding separation is A set of requirements for control and forwarding separation is
identified in [FORCES-REQ]. This document describes a ForCES identified in [FORCES-REQ]. This document describes a ForCES
Yang, et. al. Expires April 2003 [Page 6] Yang, et. al. Expires April 2003 [Page 6]
architecture that satisfies the architectural requirements of that architecture that satisfies the architectural requirements of that
document and defines a framework for ForCES network elements and document and defines a framework for ForCES network elements and the
associated entities to facilitate protocol definition. associated entities to facilitate protocol definition. Whenever
necessary, this document uses many examples to illustrate the issues
and/or possible solutions in ForCES. These examples are intended to
be just examples, and should not be taken as the only or definite
ways of doing certain things. It is expected that separate document
will be produced by the ForCES working group to specify the ForCES
protocol(s).
3. Architecture 3. Architecture
This section defines the ForCES architectural framework and the This section defines the ForCES architectural framework and the
associated logical components. This ForCES framework defines associated logical components. This ForCES framework defines
components of ForCES NEs including several ancillary components. components of ForCES NEs including several ancillary components.
These components may be connected in different kinds of topologies These components may be connected in different kinds of topologies
for flexible packet processing. for flexible packet processing.
--------------------------------------- ---------------------------------------
skipping to change at line 369 skipping to change at line 375
architecture and their relationships. There are two kinds of architecture and their relationships. There are two kinds of
components inside a ForCES network element: control element (CE) and components inside a ForCES network element: control element (CE) and
forwarding element (FE). The framework allows multiple instances of forwarding element (FE). The framework allows multiple instances of
CE and FE inside one NE. Each FE contains one or more physical media CE and FE inside one NE. Each FE contains one or more physical media
interfaces for receiving and transmitting packets from/to the interfaces for receiving and transmitting packets from/to the
external world. The aggregation of these FE interfaces becomes the external world. The aggregation of these FE interfaces becomes the
NEs external interfaces. In addition to the external interfaces, NEs external interfaces. In addition to the external interfaces,
there must also exist some kind of interconnect within the NE so there must also exist some kind of interconnect within the NE so
that the CE and FE can communicate with each other, and one FE can that the CE and FE can communicate with each other, and one FE can
forward packets to another FE. The diagram also shows two entities forward packets to another FE. The diagram also shows two entities
Yang, et. al. Expires April 2003 [Page 7]
outside of the ForCES NE: CE Manager and FE Manager. These two outside of the ForCES NE: CE Manager and FE Manager. These two
entities provide configuration to the corresponding CE or FE in the entities provide configuration to the corresponding CE or FE in the
pre-association phase (see Section 5.1). There is no defined role pre-association phase (see Section 5.1). There is no defined role
for FE Manager and CE Manager in post-association phase, thus these for FE Manager and CE Manager in post-association phase, thus these
logical components are not considered part of the ForCES NE. logical components are not considered part of the ForCES NE.
Yang, et. al. Expires April 2003 [Page 7]
For convenience, the logical interactions between these components For convenience, the logical interactions between these components
are labeled by reference points Fp, Fc, Ff, Fr, Fl, and Fi, as shown are labeled by reference points Fp, Fc, Ff, Fr, Fl, and Fi, as shown
in Figure 4. The FE external interfaces are labeled as Fi/f. More in Figure 4. The FE external interfaces are labeled as Fi/f. More
detail is provided in Section 4 and 5 for each of these reference detail is provided in Section 4 and 5 for each of these reference
points. All these reference points are important in understanding points. All these reference points are important in understanding
the ForCES architecture, however, the ForCES protocol is only the ForCES architecture, however, the ForCES protocol is only
defined over one reference point -- Fp. defined over one reference point -- Fp.
The interface between two ForCES NEs is identical to the interface The interface between two ForCES NEs is identical to the interface
between two conventional routers and these two NEs exchange the between two conventional routers and these two NEs exchange the
protocol packets through the external interfaces at Fi/f. ForCES NEs protocol packets through the external interfaces at Fi/f. ForCES NEs
connect to existing routers transparently. connect to existing routers transparently.
3.1. Control Elements and Fr Reference Point 3.1. Control Elements and Fr Reference Point
It is not necessary to define any protocols across the Fr reference It is not necessary to define any protocols across the Fr reference
point to enable control and forwarding separation for simple point to enable control and forwarding separation for simple
configurations like single CE and multiple FEs. However, this configurations like single CE and multiple FEs. However, this
architecture permits multiple CEs to be present in a network architecture permits multiple CEs to be present in a network
element. In cases where an implementation uses multiple CEs, it is element. In cases where an implementation uses multiple CEs, the
expected the invariant that the CEs and FEs together appear as a invariant that the CEs and FEs together appear as a single NE must
single NE MUST be maintained. be maintained.
Multiple CEs may be used for redundancy, load sharing, distributed Multiple CEs may be used for redundancy, load sharing, distributed
control, or other purposes. Redundancy is the case where one or control, or other purposes. Redundancy is the case where one or
more CEs are prepared to take over should an active CE fail. Load more CEs are prepared to take over should an active CE fail. Load
sharing is the case where two or more CEs are concurrently active sharing is the case where two or more CEs are concurrently active
and where any request that can be serviced by one of the CEs can and where any request that can be serviced by one of the CEs can
also be serviced by any of the other CEs. In both redundancy and also be serviced by any of the other CEs. For both redundancy and
load sharing, the CEs involved are equivalently capable. The only load sharing, the CEs involved are equivalently capable. The only
difference between these two cases is in terms of how many active difference between these two cases is in terms of how many active
CEs there are. Distributed control is the case where two or more CEs there are. Distributed control is the case where two or more
CEs are concurrently active but where certain requests can only be CEs are concurrently active but where certain requests can only be
serviced by certain CEs. serviced by certain CEs.
When multiple CEs are employed in a ForCES NE, their internal When multiple CEs are employed in a ForCES NE, their internal
organization is considered an implementation issue that is beyond organization is considered an implementation issue that is beyond
the scope of ForCES. CEs are wholly responsible for coordinating the scope of ForCES. CEs are wholly responsible for coordinating
amongst themselves via the Fr reference point to provide consistency amongst themselves via the Fr reference point to provide consistency
and synchronization. However, ForCES does not define the and synchronization. However, ForCES does not define the
implementation or protocols used between CEs, nor does it define how implementation or protocols used between CEs, nor does it define how
to distribute functionality among CEs. Nevertheless, ForCES will to distribute functionality among CEs. Nevertheless, ForCES will
support mechanisms for CE redundancy or fail over, and it is support mechanisms for CE redundancy or fail over, and it is
expected that vendors will provide redundancy or fail over solutions expected that vendors will provide redundancy or fail over solutions
within this framework. within this framework.
Yang, et. al. Expires April 2003 [Page 8]
3.2. Forwarding Elements and Fi reference point 3.2. Forwarding Elements and Fi reference point
FEs perform per-packet processing and handling as directed by CEs. FEs perform per-packet processing and handling as directed by CEs.
FEs have no initiative of their own. Instead, FEs are slaves and FEs have no initiative of their own. Instead, FEs are slaves and
only do as they are told. FEs may communicate with one or more CEs only do as they are told. FEs may communicate with one or more CEs
concurrently across reference point Fp. FEs have no notion of CE concurrently across reference point Fp. FEs have no notion of CE
Yang, et. al. Expires April 2003 [Page 8]
redundancy, load sharing, or distributed control. Instead, FEs redundancy, load sharing, or distributed control. Instead, FEs
accept commands from any CE authorized to control them, and it is up accept commands from any CE authorized to control them, and it is up
to the CEs to coordinate among themselves to achieve redundancy, to the CEs to coordinate among themselves to achieve redundancy,
load sharing or distributed control. The idea is to keep FEs as load sharing or distributed control. The idea is to keep FEs as
simple and dumb as possible so that FEs can focus its resource on simple and dumb as possible so that FEs can focus its resource on
the packet processing functions. the packet processing functions.
------- Fr ------- ------- Fr -------
| CE1 | ------| CE2 | | CE1 | ------| CE2 |
------- ------- ------- -------
skipping to change at line 454 skipping to change at line 460
| /\ | | /\ |
| / \ | | / \ |
| / \ | | / \ |
------- Fi ------- ------- Fi -------
| FE1 |<----->| FE2 | | FE1 |<----->| FE2 |
------- ------- ------- -------
Figure 5. CE redundancy example. Figure 5. CE redundancy example.
For example, in Figure 5, FE1 and FE2 can be configured to accept For example, in Figure 5, FE1 and FE2 can be configured to accept
commands from both the primary CE (CE1) and the backup CE (CE2). At commands from both the primary CE (CE1) and the backup CE (CE2).
the beginning, CE1 issues commands to FEs while CE2 silently remains Upon detection of CE1 failure, perhaps across the Fr reference
in sync with CE1 via CE to CE protocol over Fr reference point. When point, CE2 is configured to take over activities of CE1. This is
CE1 fails, CE2 detects it and starts to take over. Before CE2 starts beyond the scope of ForCES and is not discussed further.
issuing commands to the FEs, it might need to recheck the FEs' state
and instruct FEs whether or not it is ok to preserve their current
state.
Distributed control can be achieved in the similar fashion, without Distributed control can be achieved in the similar fashion, without
much intelligence on the part of FEs. For example, FEs can be much intelligence on the part of FEs. For example, FEs can be
configured to detect RSVP and BGP protocol packets, and forward RSVP configured to detect RSVP and BGP protocol packets, and forward RSVP
packets to one CE and BGP packets to another CE. Hence, FEs may need packets to one CE and BGP packets to another CE. Hence, FEs may need
to do packet filtering for forwarding packets to specific CEs. to do packet filtering for forwarding packets to specific CEs.
This architecture permits multiple FEs to be present in a NE. This architecture permits multiple FEs to be present in a NE.
[FORCES-REQ] dictates that the ForCES protocol MUST be able to scale [FORCES-REQ] dictates that the ForCES protocol must be able to scale
to at least hundreds of FEs (see [FORCES-REQ] Section 5, requirement to at least hundreds of FEs (see [FORCES-REQ] Section 5, requirement
#11). Each of these FEs may potentially have a different set of #11). Each of these FEs may potentially have a different set of
packet processing functions, with different media interfaces. FEs packet processing functions, with different media interfaces. FEs
are responsible for basic maintenance of layer-2 connectivity with are responsible for basic maintenance of layer-2 connectivity with
other FEs and with external entities. Many layer-2 media include other FEs and with external entities. Many layer-2 media include
sophisticated control protocols. The FORCES protocol (over the Fp sophisticated control protocols. The FORCES protocol (over the Fp
reference point) will be able to carry messages for such protools so reference point) will be able to carry messages for such protools so
Yang, et. al. Expires April 2003 [Page 9]
that, in keeping with the "dumb FE model, the CE can provide that, in keeping with the "dumb FE model, the CE can provide
appropriate intelligence and control over these media. appropriate intelligence and control over these media.
When multiple FEs are present, ForCES requires that packets MUST be When multiple FEs are present, ForCES requires that packets must be
able to arrive at the NE by one FE and leave the NE via a different able to arrive at the NE by one FE and leave the NE via a different
Yang, et. al. Expires April 2003 [Page 9]
FE (See [FORCES-REQ], Section 5, Requirement #3). Packets that FE (See [FORCES-REQ], Section 5, Requirement #3). Packets that
enter the NE via one FE and leave the NE via a different FE are enter the NE via one FE and leave the NE via a different FE are
transferred between FEs across the Fi reference point. The Fi transferred between FEs across the Fi reference point. The Fi
reference point is a separate protocol from the Fp reference point reference point is a separate protocol from the Fp reference point
and is not currently defined by the ForCES architecture. and is not currently defined by the ForCES architecture.
FEs could be connected in different kinds of topologies and packet
processing may spread across several FEs in the topology. Hence,
logical packet flow may be different from physical FE topology.
Figure 6 provides some topology examples. When it is necessary to
forward packets between FEs, CE needs to understand the FE topology.
The FE topology can be queried from FEs by CEs.
----------------- -----------------
| CE | | CE |
----------------- -----------------
^ ^ ^ ^ ^ ^
/ | \ / | \
/ v \ / v \
/ ------- \ / ------- \
/ +->| FE3 |<-+ \ / +->| FE3 |<-+ \
/ | | | | \ / | | | | \
v | ------- | v v | ------- | v
skipping to change at line 533 skipping to change at line 529
v v v v v v v v
------- ------- ------- ------- ------- ------- ------- -------
| FE1 |<->| FE2 |<->| FE3 |<->| FE4 | | FE1 |<->| FE2 |<->| FE3 |<->| FE4 |
------- ------- ------- ------- ------- ------- ------- -------
^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ |
| | | | | | | | | | | | | | | |
| v | v | v | v | v | v | v | v
(b) Multiple FEs in a daisy chain (b) Multiple FEs in a daisy chain
Yang, et. al. Expires April 2003 [Page 10]
^ | ^ |
Yang, et. al. Expires April 2003 [Page 10]
| v | v
----------- -----------
| FE1 |<-----------------------| | FE1 |<-----------------------|
----------- | ----------- |
^ ^ | ^ ^ |
/ \ | / \ |
| ^ / \ ^ | V | ^ / \ ^ | V
v | v v | v ---------- v | v v | v ----------
--------- --------- | | --------- --------- | |
| FE2 | | FE3 |<------------>| CE | | FE2 | | FE3 |<------------>| CE |
skipping to change at line 562 skipping to change at line 559
| ----------- | | ----------- |
| | ^ | | | ^ |
| v | | | v | |
| | | |
|----------------------------------------| |----------------------------------------|
(c) Multiple FEs connected by a ring (c) Multiple FEs connected by a ring
Figure 6. Some examples of FE topology. Figure 6. Some examples of FE topology.
FEs could be connected in different kinds of topologies and packet
processing may spread across several FEs in the topology. Hence,
logical packet flow may be different from physical FE topology.
Figure 6 provides some topology examples. When it is necessary to
forward packets between FEs, the CE needs to understand the FE
topology. The FE topology can be queried from the FEs by CEs.
3.3. CE Managers 3.3. CE Managers
CE managers are responsible for determining which FEs a CE should CE managers are responsible for determining which FEs a CE should
control. It is legitimate for CE managers to be hard-coded with the control. It is legitimate for CE managers to be hard-coded with the
knowledge of with which FEs its CEs should communicate. A CE manager knowledge of with which FEs its CEs should communicate. A CE manager
may also be physically embedded into a CE and be implemented as a may also be physically embedded into a CE and be implemented as a
simple keypad or other direct configuration mechanism on the CE. simple keypad or other direct configuration mechanism on the CE.
Finally, CE managers may be physically and logically separate Finally, CE managers may be physically and logically separate
entities that configure the CE with FE information via such entities that configure the CE with FE information via such
mechanisms as COPS-PR [RFC3084] or SNMP [RFC1157]. mechanisms as COPS-PR [RFC3084] or SNMP [RFC1157].
3.4. FE Managers 3.4. FE Managers
FE managers are responsible for determining to which CE any FE managers are responsible for determining to which CE any
particular FE should initially communicate. Like CE managers, no particular FE should initially communicate. Like CE managers, no
restrictions are placed on how a FE manager decides to which CEs its restrictions are placed on how a FE manager decides to which CE its
FEs should communicate, nor are restrictions placed on how FE FEs should communicate, nor are restrictions placed on how FE
managers are implemented. managers are implemented.
Yang, et. al. Expires April 2003 [Page 11]
4. Operational Phases 4. Operational Phases
Both FEs and CEs require some configuration in place before they can Both FEs and CEs require some configuration in place before they can
start information exchange and function as a coherent network start information exchange and function as a coherent network
element. Two operational phases are identified in this framework -- element. Two operational phases are identified in this framework --
pre-association and post-association. pre-association and post-association.
Yang, et. al. Expires April 2003 [Page 11]
4.1.Pre-association Phase 4.1.Pre-association Phase
Pre-association phase is the period of time during which a FE Pre-association phase is the period of time during which a FE
Manager and a CE Manager are determining which FE and CE should be Manager and a CE Manager are determining which FE and CE should be
part of the same network element. The protocols used during this part of the same network element. The protocols used during this
phase may include all or some of the message exchange over Fl, Ff phase may include all or some of the message exchange over Fl, Ff
and Fc reference points. However, all these may be optional and none and Fc reference points. However, all these may be optional and none
of this is within the scope of ForCES protocol. of this is within the scope of ForCES protocol.
4.1.1. Fl Reference Point 4.1.1. Fl Reference Point
skipping to change at line 633 skipping to change at line 637
CE managers and FE managers may be operated by different entities. CE managers and FE managers may be operated by different entities.
The operator of the CE manager may not want to divulge, except to The operator of the CE manager may not want to divulge, except to
specified FE managers, any characteristics of the CEs it manages. specified FE managers, any characteristics of the CEs it manages.
Similarly, the operator of the FE manager may not want to divulge FE Similarly, the operator of the FE manager may not want to divulge FE
characteristics, except to authorized entities. As such, CE characteristics, except to authorized entities. As such, CE
managers and FE managers may need to authenticate one another. managers and FE managers may need to authenticate one another.
Subsequent communication between CE managers and FE managers may Subsequent communication between CE managers and FE managers may
require other security functions such as privacy, non-repudiation, require other security functions such as privacy, non-repudiation,
freshness, and integrity. freshness, and integrity.
Yang, et. al. Expires April 2003 [Page 12]
Once the necessary security functions have been performed, the CE Once the necessary security functions have been performed, the CE
and FE managers communicate to determine which CEs and FEs should and FE managers communicate to determine which CEs and FEs should
communicate with each other. At the very minimum, the CE and FE communicate with each other. At the very minimum, the CE and FE
managers need to learn of the existence of available FEs and CEs managers need to learn of the existence of available FEs and CEs
respectively. This discovery process may or may not entail one or respectively. This discovery process may or may not entail one or
both managers learning the capabilities of the discovered ForCES both managers learning the capabilities of the discovered ForCES
Yang, et. al. Expires April 2003 [Page 12]
protocol elements. Figure 7 shows an example of possible message protocol elements. Figure 7 shows an example of possible message
exchange between CE manager and FE manager over Fl reference point. exchange between CE manager and FE manager over Fl reference point.
4.1.2. Ff Reference Point 4.1.2. Ff Reference Point
FE Manager FE CE Manager CE FE Manager FE CE Manager CE
| | | | | | | |
| | | | | | | |
|(security exchange) |(security exchange) |(security exchange) |(security exchange)
1|<------------>|authentication 1|<----------->|authentication 1|<------------>|authentication 1|<----------->|authentication
skipping to change at line 687 skipping to change at line 690
4.1.3. Fc Reference Point 4.1.3. Fc Reference Point
The Fc reference point is used to inform control elements of the The Fc reference point is used to inform control elements of the
association decisions made by CE managers in pre-association phase. association decisions made by CE managers in pre-association phase.
When the CE manager is remote, only authorized entities may instruct When the CE manager is remote, only authorized entities may instruct
a CE to control certain FEs. Privacy, integrity, freshness and a CE to control certain FEs. Privacy, integrity, freshness and
authentication are also required across this reference point in such authentication are also required across this reference point in such
a configuration. Once appropriate security has been established, a configuration. Once appropriate security has been established,
the CE manager instructs CEs as to which FEs they should control and the CE manager instructs CEs as to which FEs they should control and
Yang, et. al. Expires April 2003 [Page 13]
how they should control them. Figure 7 shows example of message how they should control them. Figure 7 shows example of message
exchange over Fc reference point. exchange over Fc reference point.
As with the FE manager and FEs, configurations are possible where As with the FE manager and FEs, configurations are possible where
the CE manager and CE are co-located and no protocol is used for the CE manager and CE are co-located and no protocol is used for
this function. this function.
Yang, et. al. Expires April 2003 [Page 13]
4.2. Post-association Phase and Fp reference point 4.2. Post-association Phase and Fp reference point
Post-association phase is the period of time during which a FE and Post-association phase is the period of time during which a FE and
CE have been configured with information necessary to contact each CE have been configured with information necessary to contact each
other and includes both association establishment and steady-state other and includes both association establishment and steady-state
communication. The communication between CE and FE is performed communication. The communication between CE and FE is performed
across the Fp ("p" meaning protocol) reference point. ForCES across the Fp ("p" meaning protocol) reference point. ForCES
protocol is exclusively used for all communication across the Fp protocol is exclusively used for all communication across the Fp
reference point. reference point.
skipping to change at line 726 skipping to change at line 730
CEs and FEs can be connected by a variety of interconnect CEs and FEs can be connected by a variety of interconnect
technologies, including Ethernet connections, backplanes, ATM (cell) technologies, including Ethernet connections, backplanes, ATM (cell)
fabrics, etc. ForCES should be able to support each of these fabrics, etc. ForCES should be able to support each of these
interconnects (see [FORCES-REQ] Section 5, requirement #1). ForCES interconnects (see [FORCES-REQ] Section 5, requirement #1). ForCES
will make use of an existing RFC2914 compliant L4 protocol with will make use of an existing RFC2914 compliant L4 protocol with
adequate reliability, security and congestion control (e.g. TCP, adequate reliability, security and congestion control (e.g. TCP,
SCTP) for transport purposes. SCTP) for transport purposes.
4.2.2. Association Establishment 4.2.2. Association Establishment
As an example, figure 9 shows some of the message exchange that need As an example, figure 9 shows some of the message exchange that may
to happen before the association between CE and FE is fully happen before the association between the CE and FE is fully
established. Typically, FE would need to inform the CE of its own established. Either the CE or FE can initiate the connection. The FE
capability and its topology in relation to other FEs. The capability needs to inform the CE of its own capability and its topology in
of FE is represented by FE model, described in another separate relation to other FEs. The capability of the FE is represented by
document. The model would allow FE to describe what kind of packet the FE model, described in another separate document. The model
processing functions it contains, in what order these processing would allow a FE to describe what kind of packet processing
happen, what kind of configurable parameters it allows, what functions it contains, in what order the processing happens, what
statistics it collects and what events it might throw, etc. Once kinds of configurable parameters it allows, what statistics it
such information is available to CE, CE sends all necessary collects and what events it might throw, etc. Once such information
configuration to FE so that FE can start receiving and processing is available to the CE, the CE sends all necessary configuration to
packets. For example, CE might need to send a snapshot of the the FE so that the FE can start receiving and processing packets
current routing table to FE so that FE can start routing packets correctly. For example, the CE might need to send a snapshot of the
correctly. Once FE starts accepting packets for processing, we say current forwarding table to the FE so that the FE can start routing
the association of this FE with its CE is now established. From then packets correctly. Once FE starts accepting packets for processing,
on, CE and FE enter steady-state communication as described next.
Yang, et. al. Expires April 2003 [Page 14]
we say the association of this FE with its CE is now established.
From then on, the CE and FE enter steady-state communication.
FE CE FE CE
| | | |
|(Hello, are you there?)| |(Hello, are you there?)|
1|<----------------------| 1|<----------------------|
Yang, et. al. Expires April 2003 [Page 14]
| | | |
|(Yes. let me join the NE please.) |(Yes. let me join the NE please.)
2|---------------------->| 2|---------------------->|
| | | |
|(Security exchange.) |
3|<--------------------->|
| |
|(What kind of FE are you? -- capability query) |(What kind of FE are you? -- capability query)
4|<----------------------| 3|<----------------------|
| | | |
|(Here is my FE functions/state: use model to describe) |(Here is my FE functions/state: use model to describe)
5|---------------------->| 4|---------------------->|
| | | |
|(How are you connected with others? -- topology query) |(How are you connected with others? -- topology query)
6|<----------------------| 5|<----------------------|
| | | |
|(Here is the topology info) |(Here is the topology info)
7|---------------------->| 6|---------------------->|
| | | |
|(Config for FE initialization, e.g. routing table) |(Config for FE, e.g. forwarding table)
8|<----------------------| 7|<----------------------|
| | | |
|(I am ready to go. Shall I?) |(I am ready to go. Shall I?)
9|---------------------->| 8|---------------------->|
| | | |
|(Go ahead!) | |(Go ahead!) |
10|<----------------------| 9|<----------------------|
| | | |
Figure 9. Example of message exchange between CE and FE Figure 9. Example of message exchange between CE and FE
over Fp to establish NE association over Fp to establish NE association
4.2.3. Steady-state Communication 4.2.3. Steady-state Communication
Once an association is established between the CE and the FE, the Once an association is established between the CE and FE, the ForCES
ForCES protocol is used by the CE and the FE over Fp reference point protocol is used by the CE and FE over Fp reference point to
to exchange information to facilitate packet processing. exchange information to facilitate packet processing.
FE CE FE CE
| | | |
|(Add these new routes.)| |(Add these new routes.)|
1|<----------------------| 1|<----------------------|
| | | |
|(Successful.) | |(Successful.) |
2|---------------------->| 2|---------------------->|
| | | |
| | | |
Yang, et. al. Expires April 2003 [Page 15]
|(Query some stats.) | |(Query some stats.) |
1|<----------------------| 1|<----------------------|
| | | |
|(Reply with stats collected.) |(Reply with stats collected.)
2|---------------------->| 2|---------------------->|
Yang, et. al. Expires April 2003 [Page 15]
| | | |
| | | |
|(My port is down, with port #.) |(My port is down, with port #.)
1|---------------------->| 1|---------------------->|
| | | |
|(Route to this port instead...) |(Route to this port instead...)
2|<----------------------| 2|<----------------------|
| | | |
| | | |
Figure 10. Examples of message exchange between CE and FE Figure 10. Examples of message exchange between CE and FE
over Fp during steady-state communication over Fp during steady-state communication
Based on the information acquired through CEs' control processing, Based on the information acquired through CEs' control processing,
CEs will frequently need to manipulate the packet-forwarding CEs will frequently need to manipulate the packet-forwarding
behaviors of their FE(s) by sending instructions to FEs. For behaviors of their FE(s) by sending instructions to FEs. For
example, Figure 10 shows message exchange examples in which CE sends example, Figure 10 shows message exchange examples in which the CE
new routes to FE so that FE can add them to its routing table. CE sends new routes to the FE so that the FE can add them to its
can also query FE for statistics collected by FE and FE can also forwarding table. The CE may query the FE for statistics collected
notify CE of some important events, like interface up and down, etc. by the FE and the FE may notify the CE of important events such as
port failure.
4.2.4. Data Packets across Fp reference point 4.2.4. Data Packets across Fp reference point
Control plane protocol packets (such as RIP, OSPF messages)
addressed to any of NE's interfaces are typically redirected by the
receiving FE to its CE, and CE may originate packets and have its FE
deliver them to other NEs. Therefore, ForCES protocol over Fp not
only transports the ForCES protocol messages between CEs and FEs,
but also encapsulates the data packets from control plane protocols.
Moreover, one FE may be controlled by multiple CEs for distributed
control. In this configuration, the control protocols supported by
the FORCES NEs may spread across multiple CEs. For example, one CE
may support routing protocols like OSPF and BGP, while signaling and
admission control protocol like RSVP is supported in another CE. FEs
are configured to recognize and filter these protocol packets and
forward them to the corresponding CE.
Figure 11 shows one example of how the BGP packets originated by
router A are passed to router B. In this example, the ForCES
protocol is used to transport the packets from the CE to the FE
inside router A, and then from the FE to the CE inside router B. In
light of the fact that the ForCES protocol is responsible to
transport both the control messages and the data packets between the
CE and FE over Fp reference point, it is possible to use either a
single protocol or multiple protocols to achieve that.
--------------------- ---------------------- --------------------- ----------------------
Yang, et. al. Expires April 2003 [Page 16]
| | | | | | | |
| +--------+ | | +--------+ | | +--------+ | | +--------+ |
| |CE(OSPF)| | | |CE(OSPF)| | | |CE(BGP) | | | |CE(BGP) | |
| +--------+ | | +--------+ | | +--------+ | | +--------+ |
| | | | ^ | | | | | ^ |
| |Fp | | |Fp | | |Fp | | |Fp |
| v | | | | | v | | | |
| +--------+ | | +--------+ | | +--------+ | | +--------+ |
| | FE | | | | FE | | | | FE | | | | FE | |
| +--------+ | | +--------+ | | +--------+ | | +--------+ |
| | | | ^ | | | | | ^ |
| Router | | | Router | | | Router | | | Router | |
| A | | | B | | | A | | | B | |
---------+----------- -----------+---------- ---------+----------- -----------+----------
v ^ v ^
| | | |
| | | |
------------------->--------------- ------------------->---------------
Figure 11. Example to show data packet flow between two NEs. Figure 11. Example to show data packet flow between two NEs.
Control plane protocol packets (such as RIP, OSPF messages)
addressed to any of NE's interfaces are typically redirected by the
receiving FE to its CE, and CE may originate packets and have its FE
deliver them to other NEs. Therefore, ForCES protocol over Fp not
only transports the ForCES protocol messages between CEs and FEs,
but also encapsulates the data packets from control plane protocols.
Yang, et. al. Expires April 2003 [Page 16]
Moreover, one FE may be controlled by multiple CEs for distributed
control. In this configuration, the control protocols supported by
the FORCES NEs may spread across multiple CEs. For example, one CE
may support routing protocols like OSPF and BGP, while signaling and
admission control protocol like RSVP is supported in another CE. FEs
are configured to recognize and filter these protocol packets and
forward them to the corresponding CE.
Figure 11 shows one example of how the OSPF packets originated by
router A are passed to router B. In this example, ForCES protocol is
used to transport the packets from CE to FE inside router A, and
then from FE to CE inside router B. In light of the fact that ForCES
protocol is responsible to transport both the control messages and
the data packets between CE and FE over Fp reference point, it is
possible to use either a single protocol or multiple protocols to
achieve that.
4.2.5. Proxy FE 4.2.5. Proxy FE
In the case where a physical FE cannot implement (e.g., due to the In the case where a physical FE cannot implement (e.g., due to the
lack of a general purpose CPU) the ForCES protocol directly, a proxy lack of a general purpose CPU) the ForCES protocol directly, a proxy
FE can be used in the middle of Fp reference point. This allows the FE can be used in the middle of Fp reference point. This allows the
CE communicate to the physical FE via the proxy by using ForCES, CE communicate to the physical FE via the proxy by using ForCES,
while the proxy manipulates the physical FE using some intermediary while the proxy manipulates the physical FE using some intermediary
form of communication (e.g., a non-ForCES protocol or DMA). In such form of communication (e.g., a non-ForCES protocol or DMA). In such
an implementation, the combination of the proxy and the physical FE an implementation, the combination of the proxy and the physical FE
becomes one logical FE entity. becomes one logical FE entity.
skipping to change at line 904 skipping to change at line 907
for the post-association phase. However, the protocol should provide for the post-association phase. However, the protocol should provide
mechanisms to support association re-establishment (see [FORCES-REQ] mechanisms to support association re-establishment (see [FORCES-REQ]
Section 5, requirement #7). Section 5, requirement #7).
The example in Figure 5 is used to illustrate what happens when the The example in Figure 5 is used to illustrate what happens when the
association is broken and later re-established again. Section 4.2 association is broken and later re-established again. Section 4.2
already explains what happens if CE1 fails and how CE2 can take already explains what happens if CE1 fails and how CE2 can take
over. If no CE redundancy is provided, at the association over. If no CE redundancy is provided, at the association
establishment phase FEs need to be told what to do in the case of CE establishment phase FEs need to be told what to do in the case of CE
failure. FEs may be told to stop packet processing all together if failure. FEs may be told to stop packet processing all together if
Yang, et. al. Expires April 2003 [Page 17]
its CE fails. Or, FEs may be told to continue forwarding packets for its CE fails. Or, FEs may be told to continue forwarding packets for
a limited time even in the face of CE failure. No matter what the a limited time even in the face of CE failure. No matter what the
instruction is, it needs to be part of the configuration when the instruction is, it needs to be part of the configuration when the
association is established. association is established.
Yang, et. al. Expires April 2003 [Page 17]
In the same example in Figure 5, assuming CE1 is the working CE for In the same example in Figure 5, assuming CE1 is the working CE for
the moment, what would happen if it is one of the FEs, say FE1, the moment, what would happen if one of the FEs, say FE1, leaves the
leaves the NE temporarily? FE1 may voluntarily decide to leave the NE temporarily? FE1 may voluntarily decide to leave the association.
association. Or, FE1 may stop functioning simply due to unexpected Or, FE1 may stop functioning simply due to unexpected failure. In
failure. In former case, CE1 receives a "leave-association request" former case, CE1 receives a "leave-association request" from FE1. In
from FE1. In the latter, CE1 detects the failure of FE1 by some the latter, CE1 detects the failure of FE1 by some other mean. In
other mean. In both cases, CE1 keeps a note of such event from FE1 both cases, CE1 keeps a note of such event from FE1 while continue
while continue commanding FE2. When FE1 decides to rejoin again, or commanding FE2. When FE1 decides to rejoin again, or when it is back
when it is back up again from the failure, FE1 needs to re-discover up again from the failure, FE1 needs to re-discover its master (CE).
its master (CE). This can be achieved by several means. It may re- This can be achieved by several means. It may re-enter the pre-
enter the pre-association phase and get that information from its FE association phase and get that information from its FE manager. It
manager. It may retrieve the previous CE information from its cache, may retrieve the previous CE information from its cache, if it can
if it can validate the information freshness. Once it discovers its validate the information freshness. Once it discovers its CE, it
CE, it starts message exchange with CE to re-establish the starts message exchange with CE to re-establish the association just
association just as outlined in Figure 9, with the possible as outlined in Figure 9, with the possible exception that it might
exception that it might be able to bypass the transport of the be able to bypass the transport of the complete initialization
complete initialization information. Suppose that FE1 still has its information. Suppose that FE1 still has its routing table and other
routing table and other state information from the last association, state information from the last association, instead of sending all
instead of sending all the information again from scratch, it can the information again from scratch, it can choose to use more
choose to use more efficient mechanism to re-sync up the state with efficient mechanism to re-sync up the state with its CE. For
its CE. For example, a checksum of the state might give a quick example, a checksum of the state might give a quick indication of
indication of whether or not the state is in-sync with its CE. By whether or not the state is in-sync with its CE. By comparing its
comparing its state with CE first, it sends information update only state with CE first, it sends information update only if it is
if it is needed. needed.
5. Applicability to RFC1812 5. Applicability to RFC1812
[FORCES-REQ] Section 5, requirement #9 dictates that "All proposed [FORCES-REQ] Section 5, requirement #9 dictates that "All proposed
ForCES architecture MUST explain how that architecture supports all ForCES architecture must explain how that architecture supports all
of the router functions as defined in [RFC1812]." RFC1812 discusses of the router functions as defined in [RFC1812]." RFC1812 discusses
many important requirements for IPv4 routers from the link layer to many important requirements for IPv4 routers from the link layer to
the application layer. This section addresses the relevant the application layer. This section addresses the relevant
requirements in RFC1812 for implementing IPv4 routers based on requirements in RFC1812 for implementing IPv4 routers based on
ForCES architecture and explain how ForCES satisfies these ForCES architecture and explains how ForCES satisfies these
requirements. requirements by providing guidelines on how to separate the
functionalities required into forwarding plane and control plane.
In general, the forwarding plane carries out the bulk of the per-
packet processing that is required at line speed, while the control
plane carries most of the computationally complex operations that
are typical of the control and signaling protocols. However, it is
not practical to draw a rigid line to divide the processing into CEs
and FEs cleanly. Nor should the ForCES architecture limits the
innovative approaches in control and forwarding plane separation. As
more and more processing power is available in the FEs, some of the
control functions that traditionally are performed by CEs may now be
moved to FEs for better performance and scalability. Such offloaded
Yang, et. al. Expires April 2003 [Page 18]
functions may include part of ICMP or TCP processing, or part of
routing protocols. Once off-loaded onto the forwarding plane, such
CE functions, even though logically belong to the control plane, now
become part of the FE logical functions. Just like the other logical
functions performed by FEs, such off-loaded functions must be
expressed as part of the FE model so that the CEs can decide how to
best take advantage of these off-loaded functions when present on
the FEs.
5.1. General Router Requirements 5.1. General Router Requirements
Routers have at least two or more logical interfaces. When CEs and Routers have at least two or more logical interfaces. When CEs and
FEs are separated by ForCES within a single NE, some additional FEs are separated by ForCES within a single NE, some additional
interfaces are needed for intra-NE communications. Figure 12 shows interfaces are needed for intra-NE communications. Figure 12 shows
an example to illustrate that. This NE contains one CE and two FEs. an example to illustrate that. This NE contains one CE and two FEs.
Each FE has four interfaces; two of them are used for receiving and Each FE has four interfaces; two of them are used for receiving and
transmitting packets to the external world, while the other two are transmitting packets to the external world, while the other two are
for intra-NE connections. CE has two logical interfaces #9 and #10, for intra-NE connections. CE has two logical interfaces #9 and #10,
connected to interfaces #3 and #6 from FE1 and FE2, respectively. connected to interfaces #3 and #6 from FE1 and FE2, respectively.
Interface #4 and #5 are connected for FE1-FE2 communication. Interface #4 and #5 are connected for FE1-FE2 communication.
Therefore, this router NE provides four external interfaces (#1, 2, Therefore, this router NE provides four external interfaces (#1, 2,
7 and 8). 7 and 8).
IPv4 routers must implement IP to support its packet forwarding IPv4 routers must implement IP to support its packet forwarding
function, which is driven by its FIB (Forwarding Information Base). function, which is driven by its FIB (Forwarding Information Base).
Yang, et. al. Expires April 2003 [Page 18]
This Internet layer forwarding (see [RFC1812] Section 5) This Internet layer forwarding (see [RFC1812] Section 5)
functionality naturally belongs to FEs in the ForCES architecture. functionality naturally belongs to FEs in the ForCES architecture.
--------------------------------- ---------------------------------
| router NE | | router NE |
| ----------- ----------- | | ----------- ----------- |
| | FE1 | | FE2 | | | | FE1 | | FE2 | |
| ----------- ----------- | | ----------- ----------- |
| 1| 2| 3| 4| 5| 6| 7| 8| | | 1| 2| 3| 4| 5| 6| 7| 8| |
| | | | | | | | | | | | | | | | | | | |
skipping to change at line 990 skipping to change at line 1014
| | | | | | | | | | | |
-----+--+----------------+--+---- -----+--+----------------+--+----
| | | | | | | |
| | | | | | | |
Figure 12. A router NE example with four interfaces. Figure 12. A router NE example with four interfaces.
A router may implement transport layer protocols (like TCP and UDP) A router may implement transport layer protocols (like TCP and UDP)
that are required to support application layer protocols (see that are required to support application layer protocols (see
[RFC1812] Section 6). One important class of application protocols [RFC1812] Section 6). One important class of application protocols
Yang, et. al. Expires April 2003 [Page 19]
is routing protocols (see [RFC1812] Section 7). In ForCES is routing protocols (see [RFC1812] Section 7). In ForCES
architecture, routing protocols are naturally implemented by CEs. architecture, routing protocols are naturally implemented by CEs.
Routing protocols require routers communicate with each other. This Routing protocols require routers communicate with each other. This
communication between CEs in different routers is supported in communication between CEs in different routers is supported in
ForCES by FEs' ability to redirect data packets addressed to routers ForCES by FEs' ability to redirect data packets addressed to routers
(i.e., NEs) and CEs' ability to originate packets and have them (i.e., NEs) and CEs' ability to originate packets and have them
delivered by their FEs. This communication occurs across Fp delivered by their FEs. This communication occurs across Fp
reference point inside each router and between neighboring routers' reference point inside each router and between neighboring routers'
external interfaces, as illustrated in Figure 11. external interfaces, as illustrated in Figure 11.
skipping to change at line 1016 skipping to change at line 1042
category -- they may be performed by the FE and may be performed by category -- they may be performed by the FE and may be performed by
the CE. A general guideline is needed to ensure interoperability the CE. A general guideline is needed to ensure interoperability
between separated control and forwarding planes. The guideline we between separated control and forwarding planes. The guideline we
offer here is that in general CEs are required to be capable of offer here is that in general CEs are required to be capable of
these kind of operations while FEs may or may not choose to these kind of operations while FEs may or may not choose to
implement them. FE model should indicate its capabilities in this implement them. FE model should indicate its capabilities in this
regard so that CEs can decide where these functions are implemented. regard so that CEs can decide where these functions are implemented.
Interface parameters, including MTU, IP address, etc., must be Interface parameters, including MTU, IP address, etc., must be
configurable by CEs via ForCES. CEs must be able to determine configurable by CEs via ForCES. CEs must be able to determine
Yang, et. al. Expires April 2003 [Page 19]
whether a physical interface in an FE is available to send packets whether a physical interface in an FE is available to send packets
or not. FEs must also inform CEs the status change of the interfaces or not. FEs must also inform CEs the status change of the interfaces
(like link up/down) via ForCES. (like link up/down) via ForCES.
5.3.Internet Layer Protocols 5.3.Internet Layer Protocols
Both FEs and CEs must implement IP protocol and all mandatory Both FEs and CEs must implement IP protocol and all mandatory
extensions as RFC1812 specified. CEs should implement IP options extensions as RFC1812 specified. CEs should implement IP options
like source route and record route while FEs may choose to implement like source route and record route while FEs may choose to implement
those as well. Timestamp option should be implemented by FEs to those as well. Timestamp option should be implemented by FEs to
skipping to change at line 1045 skipping to change at line 1069
When multiple FEs are involved to process packets, the appearance of When multiple FEs are involved to process packets, the appearance of
single NE must be strictly maintained. For example, Time-To-Live single NE must be strictly maintained. For example, Time-To-Live
(TTL) must be decremented only once within a single NE. For example, (TTL) must be decremented only once within a single NE. For example,
it can be always decremented by the last FE with egress function. it can be always decremented by the last FE with egress function.
FEs must receive and process normally any packets with a broadcast FEs must receive and process normally any packets with a broadcast
destination address or a multicast destination address that the destination address or a multicast destination address that the
router has asked to receive. When IP multicast is supported in router has asked to receive. When IP multicast is supported in
routers, IGMP is implemented in CEs. CEs are also required of ICMP routers, IGMP is implemented in CEs. CEs are also required of ICMP
support, while it is optional for FEs to support ICMP. Such an support, while it is optional for FEs to support ICMP. Such an
Yang, et. al. Expires April 2003 [Page 20]
option can be communicated to CEs as part of the FE model. option can be communicated to CEs as part of the FE model.
Therefore, FEs can always rely upon CEs to send out ICMP error Therefore, FEs can always rely upon CEs to send out ICMP error
messages, but FEs also have the option to generate ICMP error messages, but FEs also have the option to generate ICMP error
messages themselves. messages themselves.
5.4.Internet Layer Forwarding 5.4.Internet Layer Forwarding
IP forwarding is implemented by FEs. When the routing table is IP forwarding is implemented by FEs. When the routing table is
updated at CEs, ForCES is used to send the new route entries from updated at CEs, ForCES is used to send the new route entries from
CEs to FEs. Each FE has its own forwarding table and uses this table CEs to FEs. Each FE has its own forwarding table and uses this table
skipping to change at line 1071 skipping to change at line 1097
belongs to the router itself, the packets are filtered and either belongs to the router itself, the packets are filtered and either
processed locally or forwarded to CE, depending upon the processed locally or forwarded to CE, depending upon the
instructions set-up by CE. Otherwise, FE determines the next hop IP instructions set-up by CE. Otherwise, FE determines the next hop IP
address by looking up in its forwarding table. FE also determines address by looking up in its forwarding table. FE also determines
the network interface it uses to send the packets. Sometimes FE may the network interface it uses to send the packets. Sometimes FE may
need to forward the packets to another FE before packets can be need to forward the packets to another FE before packets can be
forwarded out to the next hop. Right before packets are forwarded forwarded out to the next hop. Right before packets are forwarded
out to the next hop, FE decrements TTL by 1 and processes any IP out to the next hop, FE decrements TTL by 1 and processes any IP
options that cannot be processed before. FE performs any IP options that cannot be processed before. FE performs any IP
fragmentation if necessary, determines link layer address (e.g., by fragmentation if necessary, determines link layer address (e.g., by
Yang, et. al. Expires April 2003 [Page 20]
ARP), and encapsulates the IP datagram (or each of the fragments ARP), and encapsulates the IP datagram (or each of the fragments
thereof) in an appropriate link layer frame and queues it for output thereof) in an appropriate link layer frame and queues it for output
on the interface selected. on the interface selected.
Other options mentioned in RFC1812 for IP forwarding may also be Other options mentioned in RFC1812 for IP forwarding may also be
implemented at FEs, for example, packet filtering. implemented at FEs, for example, packet filtering.
FEs typically forward packets destined locally to CEs. FEs may also FEs typically forward packets destined locally to CEs. FEs may also
forward exceptional packets (packets that FEs don't know how to forward exceptional packets (packets that FEs don't know how to
handle) to CEs. CEs are required to handle packets forwarded by FEs handle) to CEs. CEs are required to handle packets forwarded by FEs
skipping to change at line 1100 skipping to change at line 1124
send the packets. CEs may also originate new packets and deliver send the packets. CEs may also originate new packets and deliver
them to FEs for further forwarding. them to FEs for further forwarding.
Any state change during router operation must also be handled Any state change during router operation must also be handled
correctly according to RFC1812. For example, when an FE ceases correctly according to RFC1812. For example, when an FE ceases
forwarding, the entire NE may continue forwarding packets, but it forwarding, the entire NE may continue forwarding packets, but it
needs to stop advertising routes that are affected by the failed FE. needs to stop advertising routes that are affected by the failed FE.
5.5.Transport Layer 5.5.Transport Layer
Yang, et. al. Expires April 2003 [Page 21]
Transport layer is typically implemented at CEs to support higher Transport layer is typically implemented at CEs to support higher
layer application protocols like routing protocols. In practice, layer application protocols like routing protocols. In practice,
this means that most CEs implement both the Transmission Control this means that most CEs implement both the Transmission Control
Protocol (TCP) and the User Datagram Protocol (UDP). Protocol (TCP) and the User Datagram Protocol (UDP).
Both CEs and FEs need to implement ForCES protocol. If some layer-4 Both CEs and FEs need to implement ForCES protocol. If some layer-4
transport is used to support ForCES, then both CEs and FEs need to transport is used to support ForCES, then both CEs and FEs need to
implement the L4 transport and ForCES protocols. It is possible that implement the L4 transport and ForCES protocols. It is possible that
all FEs inside an NE implements only one such protocol entity. all FEs inside an NE implements only one such protocol entity.
5.6. Application Layer -- Routing Protocols 5.6. Application Layer -- Routing Protocols
Both interior routing protocols and exterior routing protocols are Both interior routing protocols and exterior routing protocols are
implemented on CEs. The routing packets originated by CEs are implemented on CEs. The routing packets originated by CEs are
forwarded to FEs for delivery. The results of such protocols (like forwarded to FEs for delivery. The results of such protocols (like
routing table update) are communicated to FEs via ForCES. forwarding table update) are communicated to FEs via ForCES.
For performance or scalability reasons, portions of the control
plane functions that need faster response may be moved from the CEs
and off-loaded onto the FEs. For example in OSPF, the Hello protocol
packets are generated and processed periodically. When done at CEs,
the inbound Hello packets have to traverse from the external
interfaces at the FEs to the CEs via the internal CE-FE channel.
Similarly, the outbound Hello packets have to go from the CEs to the
FEs and to the external interfaces. Frequent Hello updates place
heavy processing overhead on the CEs and can overwhelm the CE-FE
channel as well. Since typically there are far more FEs than CEs in
a router, when off-loaded, the Hello packets are processed in a much
more distributed and scalable fashion. Interoperability is ensured
by expressing such off-loaded functions in the FE model.
5.7. Application Layer -- Network Management Protocol 5.7. Application Layer -- Network Management Protocol
RFC1812 also dictates "Routers MUST be manageable by SNMP." (see RFC1812 also dictates "Routers MUST be manageable by SNMP." (see
[RFC1157] Section 8) In general, for post-association phase, most [RFC1157] Section 8) In general, for post-association phase, most
external management tasks (including SNMP) should be done through external management tasks (including SNMP) should be done through
interaction with the CE in order to support the appearance of a interaction with the CE in order to support the appearance of a
single functional device. Therefore, it is recommended that SNMP single functional device. Therefore, it is recommended that SNMP
management agent be implemented by CEs and the SNMP messages management agent be implemented by CEs and the SNMP messages
received by FEs be redirected to their CEs. AgentX framework defined received by FEs be redirected to their CEs. AgentX framework defined
Yang, et. al. Expires April 2003 [Page 21]
in RFC2741 may be applied here such that CEs act in the role of in RFC2741 may be applied here such that CEs act in the role of
master agent to process SNMP protocol messages while FEs act in the master agent to process SNMP protocol messages while FEs act in the
role of subagent to provide access to the MIB objects residing on role of subagent to provide access to the MIB objects residing on
FEs. AgentX protocol messages between the master agent (CE) and the FEs. AgentX protocol messages between the master agent (CE) and the
subagent (FE) are encapsulated and transported via ForCES, just like subagent (FE) are encapsulated and transported via ForCES, just like
data packets from any other application layer protocols. data packets from any other application layer protocols.
6. Summary 6. Summary
This document defines an architectural framework for ForCES. It This document defines an architectural framework for ForCES. It
identifies the relevant components for a ForCES network element, identifies the relevant components for a ForCES network element,
including (one or more) FEs, (one or more) CEs, one optional FE including (one or more) FEs, (one or more) CEs, one optional FE
manager, and one optional CE manager. It also identifies the manager, and one optional CE manager. It also identifies the
Yang, et. al. Expires April 2003 [Page 22]
interaction among these components and discusses all the major interaction among these components and discusses all the major
reference points. It is important to point out that, among all the reference points. It is important to point out that, among all the
reference points, only the interface between CEs and FEs is within reference points, only the interface between CEs and FEs is within
the scope of ForCES. ForCES alone may not be enough to support all the scope of ForCES. ForCES alone may not be enough to support all
desirablet NE configurations. However, we believe that ForCES is the desirablet NE configurations. However, we believe that ForCES is the
most important element in realizing physical separation and most important element in realizing physical separation and
interoperability of CEs and FEs, and hence the first interface that interoperability of CEs and FEs, and hence the first interface that
ought to be standardized. Simple and useful configurations can still ought to be standardized. Simple and useful configurations can still
be implemented with only CE-FE interface being standardized, e.g., be implemented with only CE-FE interface being standardized, e.g.,
single CE with full-meshed FEs and static configuration without the single CE with full-meshed FEs and static configuration without the
skipping to change at line 1181 skipping to change at line 1220
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1157] J. Case, et. al., "A Simple Network Management Protocol [RFC1157] J. Case, et. al., "A Simple Network Management Protocol
(SNMP)", RFC1157, May 1990. (SNMP)", RFC1157, May 1990.
[RFC1812] F. Baker, "Requirements for IP Version 4 Routers", [RFC1812] F. Baker, "Requirements for IP Version 4 Routers",
RFC1812, June 1995. RFC1812, June 1995.
Yang, et. al. Expires April 2003 [Page 22]
[RFC2741] M. Daniele, et. al., "Agent Extensibility (AgentX) [RFC2741] M. Daniele, et. al., "Agent Extensibility (AgentX)
Protocol Version 1", RFC2741, Jan 2000. Protocol Version 1", RFC2741, Jan 2000.
[RFC2914] S. Floyd, "Congestion Control Principles", RFC2914, [RFC2914] S. Floyd, "Congestion Control Principles", RFC2914,
September 2000. September 2000.
[RFC3084] K. Chan, et. al., "COPS Usage for Policy Provisioning [RFC3084] K. Chan, et. al., "COPS Usage for Policy Provisioning
(COPS-PR)", RFC3084, March 2001. (COPS-PR)", RFC3084, March 2001.
9.2. Informative References 9.2. Informative References
Yang, et. al. Expires April 2003 [Page 23]
[FORCES-REQ] T. Anderson, et. al., "Requirements for Separation of [FORCES-REQ] T. Anderson, et. al., "Requirements for Separation of
IP Control and Forwarding", work in progress, July 2002, <draft- IP Control and Forwarding", work in progress, July 2002, <draft-
ietf-forces-requirements-06.txt>. ietf-forces-requirements-06.txt>.
[FORCES-APP] A. Crouch, et. al., "ForCES Applicability Statement", [FORCES-APP] A. Crouch, et. al., "ForCES Applicability Statement",
work in progress, June 2002, <draft-ietf-forces-applicability- work in progress, June 2002, <draft-ietf-forces-applicability-
00.txt>. 00.txt>.
10. Acknowledgments 10. Acknowledgments
skipping to change at line 1230 skipping to change at line 1269
Phone: +1 972 883 4653 Phone: +1 972 883 4653
Email: ram.dantu@utdallas.edu Email: ram.dantu@utdallas.edu
Todd A. Anderson Todd A. Anderson
Intel Corp. Intel Corp.
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 USA Hillsboro, OR 97124 USA
Phone: +1 503 712 1760 Phone: +1 503 712 1760
Email: todd.a.anderson@intel.com Email: todd.a.anderson@intel.com
Yang, et. al. Expires April 2003 [Page 23] Yang, et. al. Expires April 2003 [Page 24]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/