draft-ietf-forces-framework-06.txt   draft-ietf-forces-framework-07.txt 
Internet Draft L. Yang Internet Draft L. Yang
Expiration: Dec 2003 Intel Corp. Expiration: Jan 2004 Intel Corp.
File: draft-ietf-forces-framework-06.txt R. Dantu File: draft-ietf-forces-framework-07.txt R. Dantu
Working Group: ForCES Univ. of North Texas Working Group: ForCES Univ. of North Texas
T. Anderson T. Anderson
Intel Corp. Intel Corp.
R. Gopal R. Gopal
Nokia Nokia
June 2003 July 2003
Forwarding and Control Element Separation (ForCES) Framework Forwarding and Control Element Separation (ForCES) Framework
draft-ietf-forces-framework-06.txt draft-ietf-forces-framework-07.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), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also its 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 55 skipping to change at page 2, line ?
Table of Contents Table of Contents
1. Definitions...................................................3 1. Definitions...................................................3
2. Introduction to Forwarding and Control Element Separation 2. Introduction to Forwarding and Control Element Separation
(ForCES).........................................................5 (ForCES).........................................................5
3. Architecture..................................................9 3. Architecture..................................................9
3.1. Control Elements and Fr Reference Point.................10 3.1. Control Elements and Fr Reference Point.................10
3.2. Forwarding Elements and Fi reference point..............11 3.2. Forwarding Elements and Fi reference point..............11
3.3. CE Managers.............................................14 3.3. CE Managers.............................................14
3.4. FE Managers.............................................14 3.4. FE Managers.............................................14
4. Operational Phases...........................................14 4. Operational Phases...........................................15
4.1. Pre-association Phase...................................15 4.1. Pre-association Phase...................................15
4.1.1. Fl Reference Point.................................15 4.1.1. Fl Reference Point.................................15
4.1.2. Ff Reference Point.................................16 4.1.2. Ff Reference Point.................................16
4.1.3. Fc Reference Point.................................17 4.1.3. Fc Reference Point.................................17
4.2. Post-association Phase and Fp reference point...........17 4.2. Post-association Phase and Fp reference point...........17
4.2.1. Proximity and Interconnect between CEs and FEs.....17 4.2.1. Proximity and Interconnect between CEs and FEs.....17
4.2.2. Association Establishment..........................18 4.2.2. Association Establishment..........................18
4.2.3. Steady-state Communication.........................19 4.2.3. Steady-state Communication.........................19
4.2.4. Data Packets across Fp reference point.............20 4.2.4. Data Packets across Fp reference point.............20
4.2.5. Proxy FE...........................................21 4.2.5. Proxy FE...........................................21
skipping to change at line 94 skipping to change at page 3, line 4
7.1.5. Data Integrity.....................................31 7.1.5. Data Integrity.....................................31
7.1.6. Data Confidentiality...............................31 7.1.6. Data Confidentiality...............................31
7.1.7. Sharing security parameters........................31 7.1.7. Sharing security parameters........................31
7.1.8. Denial of Service Attack via External Interface....32 7.1.8. Denial of Service Attack via External Interface....32
7.2. Security Recommendations for ForCES.....................32 7.2. Security Recommendations for ForCES.....................32
7.2.1. Security Configuration.............................32 7.2.1. Security Configuration.............................32
7.2.2. Using TLS with ForCES..............................33 7.2.2. Using TLS with ForCES..............................33
7.2.3. Using IPsec with ForCES............................34 7.2.3. Using IPsec with ForCES............................34
8. Normative References.........................................35 8. Normative References.........................................35
9. Informative References.......................................36 9. Informative References.......................................36
Yang, et al. Expires December 2003 [Page 2]
10. Acknowledgements............................................36 10. Acknowledgements............................................36
11. Authors' Addresses..........................................37 11. Authors' Addresses..........................................37
12. Intellectual Property Right.................................37 12. Intellectual Property Right.................................37
13. Full Copyright Statement....................................38 13. Full Copyright Statement....................................38
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].
skipping to change at line 142 skipping to change at page 4, line 4
Physical Control Element (PCE) - An AE that includes hardware used Physical Control Element (PCE) - An AE that includes hardware used
to provide control functionality. This hardware typically includes to provide control functionality. This hardware typically includes
a general-purpose processor. a general-purpose processor.
PCE Partition - A logical partition of a PCE consisting of some PCE Partition - A logical partition of a PCE consisting of some
subset of each of the resources available on the PCE. subset of each of the resources available on the PCE.
Forwarding Element (FE) - A logical entity that implements the Forwarding Element (FE) - A logical entity that implements the
ForCES protocol. FEs use the underlying hardware to provide per- ForCES protocol. FEs use the underlying hardware to provide per-
packet processing and handling as directed by a CE via the ForCES packet processing and handling as directed by a CE via the ForCES
Yang, et al. Expires December 2003 [Page 3]
protocol. FEs may happen to be a single blade (or PFE), a protocol. FEs may happen to be a single blade (or PFE), a
partition of a PFE or multiple PFEs. partition of a PFE or multiple PFEs.
Control Element (CE) - A logical entity that implements the ForCES Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs how to process protocol and uses it to instruct one or more FEs how to process
packets. CEs handle functionality such as the execution of control packets. CEs handle functionality such as the execution of control
and signaling protocols. CEs may consist of PCE partitions or and signaling protocols. CEs may consist of PCE partitions or
whole PCEs. whole PCEs.
ForCES Network Element (NE) - An entity composed of one or more CEs ForCES Network Element (NE) - An entity composed of one or more CEs
skipping to change at line 192 skipping to change at page 5, line 5
FE Manager - A logical entity that operates in the pre-association FE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which CE(s) an FE phase and is responsible for determining to which CE(s) an FE
should communicate. This process is called CE discovery and may should communicate. This process is called CE discovery and may
involve the FE manager learning the capabilities of available CEs. involve the FE manager learning the capabilities of available CEs.
A FE manager may use anything from a static configuration to a pre- A FE manager may use anything from a static configuration to a pre-
association phase protocol (see below) to determine which CE(s) to association phase protocol (see below) to determine which CE(s) to
use, however this is currently out of scope. Being a logical use, however this is currently out of scope. Being a logical
entity, an FE manager might be physically combined with any of the entity, an FE manager might be physically combined with any of the
other logical entities mentioned in this section. other logical entities mentioned in this section.
Yang, et al. Expires December 2003 [Page 4]
CE Manager - A logical entity that operates in the pre-association CE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which FE(s) a CE should phase and is responsible for determining to which FE(s) a CE should
communicate. This process is called FE discovery and may involve communicate. This process is called FE discovery and may involve
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 association phase protocol (see below) to determine which FE to
use, however this is currently out of scope. Being a logical use, however this is currently out of scope. Being a logical
entity, a CE manager might be physically combined with any of the entity, a CE manager might be physically combined with any of the
other logical entities mentioned in this section. other logical entities mentioned in this section.
skipping to change at line 214 skipping to change at page 5, line 26
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 pre-association phase protocol may include a CE and/or FE
capability discovery mechanism. Note that this capability capability discovery mechanism. Note that this capability
discovery process is wholly separate from (and does not replace) discovery process is wholly separate from (and does not replace)
that used within the ForCES protocol. However, the two capability that used within the ForCES protocol. However, the two capability
discovery mechanisms may utilize the same FE model. discovery mechanisms 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 an FE. of an FE.
ForCES Protocol Element - A FE or CE. ForCES Protocol Element - An FE or CE.
FE Topology -- Representation of how the multiple FEs in a single Intra-FE topology - Representation of how a single FE is realized
by combining possibly multiple logical functional blocks along
multiple data path. This is defined by the FE model.
FE Topology - Representation of how the multiple FEs in a single
NE are interconnected. Sometimes it is called inter-FE topology, NE are interconnected. Sometimes it is called inter-FE topology,
to be distinguished from intra-FE topology (or FE block topology) to be distinguished from intra-FE topology used by the FE model.
used by FE model.
Inter-FE topology - see FE Topology. Inter-FE topology - see FE Topology.
2. Introduction to Forwarding and Control Element Separation (ForCES) 2. Introduction to Forwarding and Control Element Separation (ForCES)
An IP network element (NE) appears to external entities as a An IP network element (NE) appears to external entities as a
monolithic piece of network equipment, e.g., a router, NAT, monolithic piece of network equipment, e.g., a router, NAT,
firewall, or load balancer. Internally, however, an IP network firewall, or load balancer. Internally, however, an IP network
element (NE) (such as a router) is composed of numerous logically element (NE) (such as a router) is composed of numerous logically
separated entities that cooperate to provide a given functionality separated entities that cooperate to provide a given functionality
(such as routing). Two types of network element components exist: (such as routing). Two types of network element components exist:
control element (CE) in control plane and forwarding element (FE) control element (CE) in control plane and forwarding element (FE)
in forwarding plane (or data plane). Forwarding elements typically in forwarding plane (or data plane). Forwarding elements typically
are ASIC, network-processor, or general-purpose processor-based are ASIC, network-processor, or general-purpose processor-based
devices that handle data path operations for each packet. Control devices that handle data path operations for each packet. Control
elements are typically based on general-purpose processors that elements are typically based on general-purpose processors that
provide control functionality like routing and signaling protocols. provide 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
Yang, et al. Expires December 2003 [Page 5]
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 the CEs and FEs from different Standard protocol also allows the CEs and FEs from different
component vendors to interoperate with each other and hence it component vendors to interoperate with each other and hence it
becomes possible for system vendors to integrate together the CEs becomes possible for system vendors to integrate together the CEs
and FEs from different component suppliers. This interoperability and FEs from different component suppliers. This interoperability
translates into a lot more design choices and flexibility for the translates into a lot more design choices and flexibility for the
skipping to change at line 289 skipping to change at page 7, line 7
| V | V | V | V | V | V
Figure 1. A router configuration example with separate blades. Figure 1. A router configuration example with separate blades.
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 a chassis interconnected into a switch fabric backplane. In such a 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
Yang, et al. Expires December 2003 [Page 6]
physical interconnect for all the blades. Control blade A may be physical interconnect for all the blades. Control blade A may be
the primary CE while control blade B may be the backup CE providing the primary CE while control blade B may be 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
for high availability support. Routers today with this kind of for high availability support. Routers today with this kind of
configuration use proprietary interfaces for messaging between CEs configuration use proprietary interfaces for messaging between CEs
and FEs. The goal of ForCES is to replace such proprietary and FEs. The goal of ForCES is to replace such proprietary
interfaces with a standard protocol. With a standard protocol like interfaces with a standard protocol. With a standard protocol like
ForCES implemented on all blades, it becomes possible for control ForCES implemented on all blades, it becomes possible for control
blades from vendor X and routing blades from vendor Y to work blades from vendor X and routing blades from vendor Y to work
seamlessly together in one chassis. seamlessly together in one chassis.
skipping to change at line 338 skipping to change at page 8, line 8
routing unit to the external world. Figure 2 shows such an example. routing unit to the external world. Figure 2 shows such an example.
In both examples shown here, the same physical interconnect is used In both examples shown here, the same physical interconnect is used
for both CE-to-FE and FE-to-FE communication. However, that does for both CE-to-FE and FE-to-FE communication. However, that does
not have to be the case. One reason to use different interconnects not have to be the case. One reason to use different interconnects
is that CE-to-FE interconnect does not have to be as fast as the is that CE-to-FE interconnect does not have to be as fast as the
FE-to-FE interconnect, so the more expensive fast connections can FE-to-FE interconnect, so the more expensive fast connections can
be saved for FE-to-FE. The separate interconnects may also provide be saved for FE-to-FE. The separate interconnects may also provide
reliability and redundancy benefits for the NE. reliability and redundancy benefits for the NE.
Yang, et al. Expires December 2003 [Page 7]
Some examples of control functions that can be implemented in the Some examples of control functions that can be implemented in the
CE include routing protocols like RIP, OSPF and BGP, control and CE include routing protocols like RIP, OSPF and BGP, control and
signaling protocols like RSVP (Resource Reservation Protocol), LDP signaling protocols like RSVP (Resource Reservation Protocol), LDP
(Label Distribution Protocol) for MPLS, etc. Examples of (Label Distribution Protocol) for MPLS, etc. Examples of
forwarding functions in the FE include LPM (longest prefix match) forwarding functions in the FE include LPM (longest prefix match)
forwarder, classifiers, traffic shaper, meter, NAT (Network Address forwarder, classifiers, traffic shaper, meter, NAT (Network Address
Translators), etc. Figure 3 provides example functions in both CE Translators), etc. Figure 3 provides example functions in both CE
and FE. Any given NE may contain one or many of these CE and FE and FE. Any given NE may contain one or many of these CE and FE
functions in it. The diagram also shows that ForCES protocol is functions in it. The diagram also shows that ForCES protocol is
used to transport both the control messages for ForCES itself and used to transport both the control messages for ForCES itself and
skipping to change at line 384 skipping to change at page 9, line 7
Figure 3. Examples of CE and FE functions Figure 3. Examples of CE and FE functions
A set of requirements for control and forwarding separation is A set of requirements for control and forwarding separation is
identified in [3]. This document describes a ForCES architecture identified in [3]. This document describes a ForCES architecture
that satisfies the architectural requirements of that document and that satisfies the architectural requirements of that document and
defines a framework for ForCES network elements and the associated defines a framework for ForCES network elements and the associated
entities to facilitate protocol definition. Whenever necessary, entities to facilitate protocol definition. Whenever necessary,
this document uses many examples to illustrate the issues and/or this document uses many examples to illustrate the issues and/or
possible solutions in ForCES. These examples are intended to be possible solutions in ForCES. These examples are intended to be
Yang, et al. Expires December 2003 [Page 8]
just examples, and should not be taken as the only or definite ways just examples, and should not be taken as the only or definite ways
of doing certain things. It is expected that separate document of doing certain things. It is expected that separate document
will be produced by the ForCES working group to specify the ForCES will be produced by the ForCES working group to specify the ForCES
protocol(s). 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.
skipping to change at line 430 skipping to change at page 10, line 4
Figure 4. ForCES Architectural Diagram Figure 4. ForCES Architectural Diagram
The diagram in Figure 4 shows the logical components of the ForCES The diagram in Figure 4 shows the logical components of the ForCES
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) components inside a ForCES network element: control element (CE)
and forwarding element (FE). The framework allows multiple and forwarding element (FE). The framework allows multiple
instances of CE and FE inside one NE. Each FE contains one or instances of CE and FE inside one NE. Each FE contains one or
more physical media interfaces for receiving and transmitting more physical media interfaces for receiving and transmitting
packets from/to the external world. The aggregation of these FE packets from/to the external world. The aggregation of these FE
interfaces becomes the NEs external interfaces. In addition to interfaces becomes the NE's external interfaces. In addition to
the external interfaces, there must also exist some kind of the external interfaces, there must also exist some kind of
interconnect within the NE so that the CE and FE can communicate interconnect within the NE so that the CE and FE can communicate
Yang, et al. Expires December 2003 [Page 9]
with each other, and one FE can forward packets to another FE. with each other, and one FE can forward packets to another FE.
The diagram also shows two entities outside of the ForCES NE: CE The diagram also shows two entities outside of the ForCES NE: CE
Manager and FE Manager. These two entities provide configuration Manager and FE Manager. These two entities provide configuration
to the corresponding CE or FE in the pre-association phase (see to the corresponding CE or FE in the pre-association phase (see
Section 5.1). There is no defined role for FE Manager and CE Section 5.1). There is no defined role for FE Manager and CE
Manager in post-association phase, thus these logical components Manager in post-association phase, thus these logical components
are not considered part of the ForCES NE. are not considered part of the ForCES NE.
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 are labeled by reference points Fp, Fc, Ff, Fr, Fl, and Fi, as
skipping to change at line 482 skipping to change at page 11, line 9
sharing, the CEs involved are equivalently capable. The only 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 certain requests can only be CEs are concurrently active but 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 amongst themselves via the Fr reference point to provide
Yang, et al. Expires December 2003 [Page 10]
consistency and synchronization. However, ForCES does not define consistency and synchronization. However, ForCES does not define
the implementation or protocols used between CEs, nor does it the implementation or protocols used between CEs, nor does it
define how to distribute functionality among CEs. Nevertheless, define how to distribute functionality among CEs. Nevertheless,
ForCES will support mechanisms for CE redundancy or fail over, and ForCES will support mechanisms for CE redundancy or fail over, and
it is expected that vendors will provide redundancy or fail over it is expected that vendors will provide redundancy or fail over
solutions within this framework. solutions within this framework.
3.2. Forwarding Elements and Fi reference point 3.2. Forwarding Elements and Fi reference point
An FE is a logical entity that implements the ForCES protocol and An FE is a logical entity that implements the ForCES protocol and
skipping to change at line 531 skipping to change at page 12, line 9
reference point, CE2 is configured to take over activities of CE1. reference point, CE2 is configured to take over activities of CE1.
This is beyond the scope of ForCES and is not discussed further. This is beyond the scope of ForCES and is not discussed further.
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 configured to detect RSVP and BGP protocol packets, and forward
RSVP packets to one CE and BGP packets to another CE. Hence, FEs RSVP packets to one CE and BGP packets to another CE. Hence, FEs
may need to do packet filtering for forwarding packets to specific may need to do packet filtering for forwarding packets to specific
CEs. CEs.
Yang, et al. Expires December 2003 [Page 11]
------- Fr ------- ------- Fr -------
| CE1 | ------| CE2 | | CE1 | ------| CE2 |
------- ------- ------- -------
| \ / | | \ / |
| \ / | | \ / |
| \ / | | \ / |
| \/Fp | | \/Fp |
| /\ | | /\ |
| / \ | | / \ |
| / \ | | / \ |
skipping to change at line 577 skipping to change at page 13, line 7
separate protocol from the Fp reference point and is not currently separate protocol from the Fp reference point and is not currently
defined by the ForCES architecture. defined by the ForCES architecture.
FEs could be connected in different kinds of topologies and packet FEs could be connected in different kinds of topologies and packet
processing may spread across several FEs in the topology. Hence, processing may spread across several FEs in the topology. Hence,
logical packet flow may be different from physical FE topology. logical packet flow may be different from physical FE topology.
Figure 6 provides some topology examples. When it is necessary to Figure 6 provides some topology examples. When it is necessary to
forward packets between FEs, the CE needs to understand the FE forward packets between FEs, the CE needs to understand the FE
topology. The FE topology can be queried from the FEs by CEs. topology. The FE topology can be queried from the FEs by CEs.
Yang, et al. Expires December 2003 [Page 12]
----------------- -----------------
| CE | | CE |
----------------- -----------------
^ ^ ^ ^ ^ ^
/ | \ / | \
/ v \ / v \
/ ------- \ / ------- \
/ +->| FE3 |<-+ \ / +->| FE3 |<-+ \
/ | | | | \ / | | | | \
v | ------- | v v | ------- | v
skipping to change at line 621 skipping to change at page 14, line 8
(b) Multiple FEs in a daisy chain (b) Multiple FEs in a daisy chain
^ | ^ |
| v | v
----------- -----------
| FE1 |<-----------------------| | FE1 |<-----------------------|
----------- | ----------- |
^ ^ | ^ ^ |
/ \ | / \ |
Yang, et al. Expires December 2003 [Page 13]
| ^ / \ ^ | V | ^ / \ ^ | V
v | v v | v ---------- v | v v | v ----------
--------- --------- | | --------- --------- | |
| FE2 | | FE3 |<------------>| CE | | FE2 | | FE3 |<------------>| CE |
--------- --------- | | --------- --------- | |
^ ^ ^ ---------- ^ ^ ^ ----------
| \ / ^ ^ | \ / ^ ^
| \ / | | | \ / | |
| v v | | | v v | |
| ----------- | | | ----------- | |
skipping to change at line 670 skipping to change at page 15, line 9
its FEs should communicate, nor are restrictions placed on how FE its FEs should communicate, nor are restrictions placed on how FE
managers are implemented. Each FE should have one and only one FE managers are implemented. Each FE should have one and only one FE
manager, while different FEs may have the same or different FE manager, while different FEs may have the same or different FE
manager(s). Each manager can choose to exist and operate manager(s). Each manager can choose to exist and operate
independently of other manager. independently of other manager.
4. Operational Phases 4. Operational Phases
Both FEs and CEs require some configuration in place before they Both FEs and CEs require some configuration in place before they
can start information exchange and function as a coherent network can start information exchange and function as a coherent network
Yang, et al. Expires December 2003 [Page 14]
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.
4.1.Pre-association Phase 4.1.Pre-association Phase
Pre-association phase is the period of time during which an FE Pre-association phase is the period of time during which an 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 and Fc reference points. However, all these may be optional and
skipping to change at line 719 skipping to change at page 16, line 8
2|<-------------------------------| | 2|<-------------------------------| |
| | | | | | | |
|(a list of FEs and their attributes) | |(a list of FEs and their attributes) |
3|------------------------------->| | 3|------------------------------->| |
| | | | | | | |
| | | | | | | |
|<----------------Fl------------>| | |<----------------Fl------------>| |
Figure 7. An example of message exchange over Fl reference point Figure 7. An example of message exchange over Fl reference point
Yang, et al. Expires December 2003 [Page 15]
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 entail one or both respectively. This discovery process may entail one or both
managers learning the capabilities of the discovered ForCES managers learning the capabilities of the discovered ForCES
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
skipping to change at line 764 skipping to change at page 17, line 6
| | | | | | | |
3|------------->|response 3|------------>|response 3|------------->|response 3|------------>|response
|(corresponding CE ID) |(corresponding FE ID) |(corresponding CE ID) |(corresponding FE ID)
| | | | | | | |
| | | | | | | |
|<-----Ff----->| |<-----Fc---->| |<-----Ff----->| |<-----Fc---->|
Figure 8. Examples of message exchange Figure 8. Examples of message exchange
over Ff and Fc reference points. over Ff and Fc reference points.
Yang, et al. Expires December 2003 [Page 16]
Note that the FE manager function may be co-located with the FE Note that the FE manager function may be co-located with the FE
(such as by manual keypad entry of the CE IP address), in which (such as by manual keypad entry of the CE IP address), in which
case this reference point is reduced to a built-in function. case this reference point is reduced to a built-in function.
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 When the CE manager is remote, only authorized entities may
instruct a CE to control certain FEs. Privacy, integrity, instruct a CE to control certain FEs. Privacy, integrity,
skipping to change at line 804 skipping to change at page 17, line 45
4.2.1. Proximity and Interconnect between CEs and FEs 4.2.1. Proximity and Interconnect between CEs and FEs
The ForCES Working Group has made a conscious decision that the The ForCES Working Group has made a conscious decision that the
first version of ForCES will not be designed to support first version of ForCES will not be designed to support
configurations where the CE and FE are located arbitrarily in the configurations where the CE and FE are located arbitrarily in the
network. In particular, ForCES is intended for "very close" CE/FE network. In particular, ForCES is intended for "very close" CE/FE
localities in IP networks, as defined by ForCES Applicability localities in IP networks, as defined by ForCES Applicability
Statement ([7]). Very Close localities consist of control and Statement ([7]). Very Close localities consist of control and
forwarding elements that either are components in the same physical forwarding elements that either are components in the same physical
box, or are separated at most by one local network hop. box, or are separated at most by one local network hop. CEs and
FEs can be connected by a variety of interconnect technologies,
CEs and FEs can be connected by a variety of interconnect including Ethernet connections, backplanes, ATM (cell) fabrics,
technologies, including Ethernet connections, backplanes, ATM etc. ForCES should be able to support each of these interconnects
(cell) fabrics, etc. ForCES should be able to support each of (see [3] Section 5, requirement #1). When the CEs and FEs are
these interconnects (see [3] Section 5, requirement #1). ForCES separated beyond a single hop, the ForCES protocol will make use of
will make use of an existing RFC2914 ([2]) compliant L4 protocol an existing RFC2914 compliant L4 protocol with adequate
reliability, security and congestion control (e.g. TCP, SCTP) for
Yang, et al. Expires December 2003 [Page 17] transport purposes.
with adequate reliability, security and congestion control (e.g.
TCP, SCTP) for transport purposes.
4.2.2. Association Establishment 4.2.2. Association Establishment
FE CE FE CE
| | | |
|(Security exchange.) | |(Security exchange.) |
1|<--------------------->| 1|<--------------------->|
| | | |
|(Let me join the NE please.) |(Let me join the NE please.)
2|---------------------->| 2|---------------------->|
skipping to change at line 859 skipping to change at page 19, line 6
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
As an example, figure 9 shows some of the message exchange that may As an example, figure 9 shows some of the message exchange that may
happen before the association between the CE and FE is fully happen before the association between the CE and FE is fully
established. Either the CE or FE can initiate the connection. established. Either the CE or FE can initiate the connection.
Security handshake is necessary to authenticate the two Security handshake is necessary to authenticate the two
communication endpoints to each other before any further message communication endpoints to each other before any further message
exchange can happen. The exact details of the security handshake exchange can happen. The exact details of the security handshake
depend on the security solution chosen by ForCES protocol. It is depend on the security solution chosen by ForCES protocol. It is
Yang, et al. Expires December 2003 [Page 18]
most likely that either IPSec or TLS will be used. Section 9 most likely that either IPSec or TLS will be used. Section 9
provides more details on the security considerations for ForCES. provides more details on the security considerations for ForCES.
After the successful security handshake, the FE needs to inform the After the successful security handshake, the FE needs to inform the
CE of its own capability and its topology in relation to other FEs. CE of its own capability and its topology in relation to other FEs.
The capability of the FE is represented by the FE model, described The capability of the FE is represented by the FE model, described
in a separate document. The model would allow an FE to describe in a separate document. The model would allow an FE to describe
what kind of packet processing functions it contains, in what order what kind of packet processing functions it contains, in what order
the processing happens, what kinds of configurable parameters it the processing happens, what kinds of configurable parameters it
allows, what statistics it collects and what events it might throw, allows, what statistics it collects and what events it might throw,
etc. Once such information is available to the CE, the CE may etc. Once such information is available to the CE, the CE may
skipping to change at line 907 skipping to change at page 20, line 6
|(Reply with stats collected.) |(Reply with stats collected.)
2|---------------------->| 2|---------------------->|
| | | |
| | | |
|(My port is down, with port #.) |(My port is down, with port #.)
1|---------------------->| 1|---------------------->|
| | | |
|(Here is a new forwarding table) |(Here is a new forwarding table)
2|<----------------------| 2|<----------------------|
| | | |
Yang, et al. Expires December 2003 [Page 19]
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 the CE example, Figure 10 shows message exchange examples in which the CE
sends new routes to the FE so that the FE can add them to its sends new routes to the FE so that the FE can add them to its
forwarding table. The CE may query the FE for statistics collected forwarding table. The CE may query the FE for statistics collected
by the FE and the FE may notify the CE of important events such as by the FE and the FE may notify the CE of important events such as
skipping to change at line 956 skipping to change at page 21, line 6
addressed to any of NE's interfaces are typically redirected by the 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 receiving FE to its CE, and CE may originate packets and have its
FE deliver them to other NEs. Therefore, ForCES protocol over Fp FE deliver them to other NEs. Therefore, ForCES protocol over Fp
not only transports the ForCES protocol messages between CEs and not only transports the ForCES protocol messages between CEs and
FEs, but also encapsulates the data packets from control plane FEs, but also encapsulates the data packets from control plane
protocols. Moreover, one FE may be controlled by multiple CEs for protocols. Moreover, one FE may be controlled by multiple CEs for
distributed control. In this configuration, the control protocols distributed control. In this configuration, the control protocols
supported by the FORCES NEs may spread across multiple CEs. For supported by the FORCES NEs may spread across multiple CEs. For
example, one CE may support routing protocols like OSPF and BGP, example, one CE may support routing protocols like OSPF and BGP,
while a signaling and admission control protocol like RSVP is while a signaling and admission control protocol like RSVP is
Yang, et al. Expires December 2003 [Page 20]
supported in another CE. FEs are configured to recognize and supported in another CE. FEs are configured to recognize and
filter these protocol packets and forward them to the corresponding filter these protocol packets and forward them to the corresponding
CE. CE.
Figure 11 shows one example of how the BGP packets originated by Figure 11 shows one example of how the BGP packets originated by
router A are passed to router B. In this example, the ForCES 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 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. 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 for In light of the fact that the ForCES protocol is responsible for
transporting both the control messages and the data packets between transporting both the control messages and the data packets between
skipping to change at line 1002 skipping to change at page 22, line 4
applicable for the post-association phase. However, the protocol applicable for the post-association phase. However, the protocol
should provide mechanisms to support association re-establishment. should provide mechanisms to support association re-establishment.
This includes the ability for CEs and FEs to determine when there This includes the ability for CEs and FEs to determine when there
is a loss of association between them, ability to restore is a loss of association between them, ability to restore
association and efficient state (re)synchronization mechanisms (see association and efficient state (re)synchronization mechanisms (see
[3] Section 5, requirement #7). Note that security association and [3] Section 5, requirement #7). Note that security association and
state must be also re-established to guarantee the same level of state must be also re-established to guarantee the same level of
security exists before and after the association re-establishment. security exists before and after the association re-establishment.
4.3.1. CE graceful restart 4.3.1. CE graceful restart
The failure and restart of the CE in a router can potentially cause The failure and restart of the CE in a router can potentially cause
much stress and disruption on the control plane throughout a much stress and disruption on the control plane throughout a
Yang, et al. Expires December 2003 [Page 21]
network. Because when a CE has to restart for any reason, the network. Because when a CE has to restart for any reason, the
router loses routing adjacencies or sessions with its routing router loses routing adjacencies or sessions with its routing
neighbors. Neighbors who detect the lost adjacency normally re- neighbors. Neighbors who detect the lost adjacency normally re-
compute new routes and then send routing updates to their own compute new routes and then send routing updates to their own
neighbors to communicate the lost adjacency. Their neighbors do neighbors to communicate the lost adjacency. Their neighbors do
the same thing to propagate throughout the network. In the the same thing to propagate throughout the network. In the
meantime, the restarting router cannot receive traffic from other meantime, the restarting router cannot receive traffic from other
routers because the neighbors have stopped using the routers routers because the neighbors have stopped using the router's
previously advertised routes. When the restarting router restores previously advertised routes. When the restarting router restores
adjacencies, neighbors must once again re-compute new routes and adjacencies, neighbors must once again re-compute new routes and
send out additional routing updates. The restarting router is send out additional routing updates. The restarting router is
unable to forward packets until it has re-established routing unable to forward packets until it has re-established routing
adjacencies with neighbors, received route updates through these adjacencies with neighbors, received route updates through these
adjacencies, and computed new routes. Until convergence takes adjacencies, and computed new routes. Until convergence takes
place throughout the network, packets may be lost in transient place throughout the network, packets may be lost in transient
black holes or forwarding loops. black holes or forwarding loops.
A high availability mechanism known as the "graceful restart" has A high availability mechanism known as the "graceful restart" has
skipping to change at line 1039 skipping to change at page 22, line 38
routers is avoided, and a restarting router can continue to forward routers is avoided, and a restarting router can continue to forward
packets that would otherwise be dropped. packets that would otherwise be dropped.
While the details differ from protocol to protocol, the general While the details differ from protocol to protocol, the general
idea behind the graceful restart mechanism remains the same. With idea behind the graceful restart mechanism remains the same. With
the graceful restart, a restarting router can inform its neighbors the graceful restart, a restarting router can inform its neighbors
when it restarts. The neighbors may detect the lost adjacency but when it restarts. The neighbors may detect the lost adjacency but
do not recompute new routes or send routing updates to their do not recompute new routes or send routing updates to their
neighbors. The neighbors also hold on to the routes received from neighbors. The neighbors also hold on to the routes received from
the restarting router before restart and assume they are still the restarting router before restart and assume they are still
valid for a limited time. By doing so, the restarting routers FEs valid for a limited time. By doing so, the restarting router's FEs
can also continue to receive and forward traffic from other can also continue to receive and forward traffic from other
neighbors for a limited time by using the routes they already have. neighbors for a limited time by using the routes they already have.
The restarting router then re-establishes routing adjacencies, The restarting router then re-establishes routing adjacencies,
downloads updated routes from all its neighbors, recomputes new downloads updated routes from all its neighbors, recomputes new
routes and uses them to replace the older routes it was using. It routes and uses them to replace the older routes it was using. It
then sends these updated routes to its neighbors and signals the then sends these updated routes to its neighbors and signals the
completion of the graceful restart process. completion of the graceful restart process.
Non-stop forwarding is a requirement for graceful restart. It is Non-stop forwarding is a requirement for graceful restart. It is
necessary so a router can continue to forward packets while it is necessary so a router can continue to forward packets while it is
downloading routing information and recomputing new routes. This downloading routing information and recomputing new routes. This
ensures that packets will not be dropped. As one can see, one of ensures that packets will not be dropped. As one can see, one of
the benefits afforded by the separation of CE and FE is exactly the the benefits afforded by the separation of CE and FE is exactly the
ability of non-stop forwarding in the face of the CE failure and ability of non-stop forwarding in the face of the CE failure and
Yang, et al. Expires December 2003 [Page 22]
restart. The support of dynamic changes to CE/FE association in restart. The support of dynamic changes to CE/FE association in
ForCES also makes it compatible with high availability mechanisms ForCES also makes it compatible with high availability mechanisms
such as graceful restart. such as graceful restart.
ForCES should be able to support CE graceful restart easily. When ForCES should be able to support CE graceful restart easily. When
the association is established the first time, the CE must inform the association is established the first time, the CE must inform
the FEs what to do in the case of CE failure. If graceful restart the FEs what to do in the case of CE failure. If graceful restart
is not supported, the FEs may be told to stop packet processing all is not supported, the FEs may be told to stop packet processing all
together if its CE fails. If graceful restart is supported, the together if its CE fails. If graceful restart is supported, the
FEs should be told to cache and hold on to its FE state including FEs should be told to cache and hold on to its FE state including
skipping to change at line 1103 skipping to change at page 24, line 6
just as outlined in Figure 9, with the possible exception that it just as outlined in Figure 9, with the possible exception that it
might be able to bypass the transport of the complete initial might be able to bypass the transport of the complete initial
configuration. Suppose that FE1 still has its routing table and configuration. Suppose that FE1 still has its routing table and
other state information from the last association, instead of other state information from the last association, instead of
sending all the information again from scratch, it may be able to sending all the information again from scratch, it may be able to
use more efficient mechanism to re-sync up the state with its CE if use more efficient mechanism to re-sync up the state with its CE if
such mechanism is supported by the ForCES protocol. For example, such mechanism is supported by the ForCES protocol. For example,
CRC-32 of the state might give a quick indication of whether or not CRC-32 of the state might give a quick indication of whether or not
the state is in-sync with its CE. By comparing its state with CE the state is in-sync with its CE. By comparing its state with CE
first, it sends information update only if it is needed. ForCES first, it sends information update only if it is needed. ForCES
Yang, et al. Expires December 2003 [Page 23]
protocol may choose to implement similar optimization mechanisms, protocol may choose to implement similar optimization mechanisms,
but it may also choose not to, as this is not a requirement. but it may also choose not to, as this is not a requirement.
5. Applicability to RFC1812 5. Applicability to RFC1812
[3] Section 5, requirement #9 dictates "Any proposed ForCES [3] Section 5, requirement #9 dictates "Any proposed ForCES
architecture must explain how that architecture supports all of the architecture must explain how that architecture supports all of the
router functions as defined in RFC1812." RFC1812 discusses many router functions as defined in RFC1812." RFC1812 discusses many
important requirements for IPv4 routers from the link layer to the important requirements for IPv4 routers from the link layer to the
application layer. This section addresses the relevant application layer. This section addresses the relevant
skipping to change at line 1150 skipping to change at page 25, line 5
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 an example to illustrate that. This NE contains one CE and two
FEs. Each FE has four interfaces; two of them are used for FEs. Each FE has four interfaces; two of them are used for
receiving and transmitting packets to the external world, while the receiving and transmitting packets to the external world, while the
other two are for intra-NE connections. CE has two logical other two are for intra-NE connections. CE has two logical
interfaces #9 and #10, connected to interfaces #3 and #6 from FE1 interfaces #9 and #10, connected to interfaces #3 and #6 from FE1
and FE2, respectively. Interface #4 and #5 are connected for FE1- and FE2, respectively. Interface #4 and #5 are connected for FE1-
Yang, et al. Expires December 2003 [Page 24]
FE2 communication. Therefore, this router NE provides four FE2 communication. Therefore, this router NE provides four
external interfaces (#1, 2, 7 and 8). external interfaces (#1, 2, 7 and 8).
--------------------------------- ---------------------------------
| 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 1187 skipping to change at page 25, line 40
This Internet layer forwarding (see RFC1812 [1] Section 5) This Internet layer forwarding (see RFC1812 [1] Section 5)
functionality naturally belongs to FEs in the ForCES architecture. functionality naturally belongs to FEs in the ForCES architecture.
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 [1] Section 6). One important class of application RFC1812 [1] Section 6). One important class of application
protocols is routing protocols (see RFC1812 [1] Section 7). In protocols is routing protocols (see RFC1812 [1] Section 7). In
ForCES architecture, routing protocols are naturally implemented by ForCES architecture, routing protocols are naturally implemented by
CEs. Routing protocols require routers communicate with each CEs. Routing protocols require routers communicate with each
other. This communication between CEs in different routers is other. This communication between CEs in different routers is
supported in ForCES by FEs∆ ability to redirect data packets supported in ForCES by FEs' ability to redirect data packets
addressed to routers (i.e., NEs) and CEs∆ ability to originate addressed to routers (i.e., NEs) and CEs' ability to originate
packets and have them delivered by their FEs. This communication packets and have them delivered by their FEs. This communication
occurs across Fp reference point inside each router and between occurs across Fp reference point inside each router and between
neighboring routers' external interfaces, as illustrated in Figure neighboring routers' external interfaces, as illustrated in Figure
11. 11.
5.2.Link Layer 5.2.Link Layer
Since FEs own all the external interfaces for the router, FEs need Since FEs own all the external interfaces for the router, FEs need
to conform to the link layer requirements in RFC1812. Arguably, to conform to the link layer requirements in RFC1812. Arguably,
ARP support may be implemented in either CEs or FEs. As we will ARP support may be implemented in either CEs or FEs. As we will
Yang, et al. Expires December 2003 [Page 25]
see later, a number of behaviors that RFC1812 mandates fall into see later, a number of behaviors that RFC1812 mandates fall into
this category -- they may be performed by the FE and may be this category -- they may be performed by the FE and may be
performed by the CE. A general guideline is needed to ensure performed by the CE. A general guideline is needed to ensure
interoperability between separated control and forwarding planes. interoperability between separated control and forwarding planes.
The guideline we offer here is that CEs MUST be capable of these The guideline we offer here is that CEs MUST be capable of these
kind of operations while FEs MAY choose to implement them. FE kind of operations while FEs MAY choose to implement them. FE
model should indicate its capabilities in this regard so that CEs model should indicate its capabilities in this regard so that CEs
can decide where these functions are implemented. 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
skipping to change at line 1246 skipping to change at page 27, line 4
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
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
Yang, et al. Expires December 2003 [Page 26]
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 CEs to FEs. Each FE has its own forwarding table and uses this
table to direct packets to the next hop interface. table to direct packets to the next hop interface.
Upon receiving IP packets, the FE verifies the IP header and Upon receiving IP packets, the FE verifies the IP header and
processes most of the IP options. Some options cannot be processed processes most of the IP options. Some options cannot be processed
until the routing decision has been made. The routing decision is until the routing decision has been made. The routing decision is
made after examining the destination IP address. If the made after examining the destination IP address. If the
destination address belongs to the router itself, the packets are destination address belongs to the router itself, the packets are
skipping to change at line 1295 skipping to change at page 28, line 4
or modify and re-send the packets. CEs may also originate new or modify and re-send the packets. CEs may also originate new
packets and deliver them to FEs for further forwarding. packets and deliver 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 needs to stop advertising routes that are affected by the failed
FE. FE.
5.5. Transport Layer 5.5. Transport Layer
Yang, et al. Expires December 2003 [Page 27]
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- 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 4 transport is used to support ForCES, then both CEs and FEs need
to implement the L4 transport and ForCES protocols. to implement the L4 transport and ForCES protocols.
5.6. Application Layer -- Routing Protocols 5.6. Application Layer -- Routing Protocols
skipping to change at line 1326 skipping to change at page 28, line 33
protocol packets are generated and processed periodically. When protocol packets are generated and processed periodically. When
done at CEs, the inbound Hello packets have to traverse from the 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 external interfaces at the FEs to the CEs via the internal CE-FE
channel. Similarly, the outbound Hello packets have to go from the channel. Similarly, the outbound Hello packets have to go from the
CEs to the FEs and to the external interfaces. Frequent Hello CEs to the FEs and to the external interfaces. Frequent Hello
updates place heavy processing overhead on the CEs and can updates place heavy processing overhead on the CEs and can
overwhelm the CE-FE channel as well. Since typically there are far overwhelm the CE-FE channel as well. Since typically there are far
more FEs than CEs in a router, the off-loaded Hello packets are more FEs than CEs in a router, the off-loaded Hello packets are
processed in a much more distributed and scalable fashion. By processed in a much more distributed and scalable fashion. By
expressing such off-loaded functions in the FE model, we can ensure expressing such off-loaded functions in the FE model, we can ensure
interoperability. interoperability. However, the exact description of the off-loaded
functionality corresponding to the off-loaded functions expressed
in the FE model are not part of the model itself and will need to
be worked out as a separate specification.
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
[4] Section 8) In general, for post-association phase, most [4] 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 received by FEs be redirected to their CEs. AgentX framework
defined in RFC2741 ([5]) may be applied here such that CEs act in defined in RFC2741 ([5]) may be applied here such that CEs act in
the role of master agent to process SNMP protocol messages while the role of master agent to process SNMP protocol messages while
FEs act in the role of subagent to provide access to the MIB FEs act in the role of subagent to provide access to the MIB
objects residing on FEs. AgentX protocol messages between the objects residing on FEs. AgentX protocol messages between the
master agent (CE) and the subagent (FE) are encapsulated and master agent (CE) and the subagent (FE) are encapsulated and
Yang, et al. Expires December 2003 [Page 28]
transported via ForCES, just like data packets from any other transported via ForCES, just like data packets from any other
application layer protocols. 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
interaction among these components and discusses all the major interaction among these components and discusses all the major
skipping to change at line 1388 skipping to change at page 30, line 4
7.1. Analysis of Potential Threats Introduced by ForCES 7.1. Analysis of Potential Threats Introduced by ForCES
This section provides the threat analysis for ForCES, with a focus This section provides the threat analysis for ForCES, with a focus
on Fp interface. Each threat is described in details with the on Fp interface. Each threat is described in details with the
effects on the ForCES protocol entities or/and the NE as a whole, effects on the ForCES protocol entities or/and the NE as a whole,
and the required functionalities that need to be in place to defend and the required functionalities that need to be in place to defend
the threat. the threat.
7.1.1. "Join" or "Remove" Message Flooding on CEs 7.1.1. "Join" or "Remove" Message Flooding on CEs
Threats: A malicious node could send a stream of false "join NE" Threats: A malicious node could send a stream of false "join NE"
or "remove from NE" requests on behalf of non-existent or or "remove from NE" requests on behalf of non-existent or
Yang, et al. Expires December 2003 [Page 29]
unauthorized FE to legitimate CEs at a very rapid rate and thereby unauthorized FE to legitimate CEs at a very rapid rate and thereby
create unnecessary state in the CEs. create unnecessary state in the CEs.
Effects: If by maintaining state for non-existent or unauthorized Effects: If by maintaining state for non-existent or unauthorized
FEs, a CE may become unavailable for other processing and hence FEs, a CE may become unavailable for other processing and hence
suffer from denial of service (DoS) attack similar to the TCP SYN suffer from denial of service (DoS) attack similar to the TCP SYN
DoS. If multiple CEs are used, the unnecessary state information DoS. If multiple CEs are used, the unnecessary state information
may also be conveyed to multiple CEs via Fr interface (e.g., from may also be conveyed to multiple CEs via Fr interface (e.g., from
the active CE to the stand-by CE) and hence subject multiple CEs to the active CE to the stand-by CE) and hence subject multiple CEs to
DoS attack. DoS attack.
skipping to change at line 1437 skipping to change at page 31, line 5
7.1.4. Attack during Fail Over 7.1.4. Attack during Fail Over
Threat: A malicious node may exploit the CE fail-over mechanism to Threat: A malicious node may exploit the CE fail-over mechanism to
take over the control of NE. For example, suppose two CEs, say CE-A take over the control of NE. For example, suppose two CEs, say CE-A
and CE-B, are controlling several FEs. CE-A is active and CE-B is and CE-B, are controlling several FEs. CE-A is active and CE-B is
stand-by. When CE-A fails, CE-B is taking over the active CE stand-by. When CE-A fails, CE-B is taking over the active CE
position. The FEs already had a trusted relationship with CE-A, position. The FEs already had a trusted relationship with CE-A,
but the FEs may not have the same trusted relationship established but the FEs may not have the same trusted relationship established
with CE-B prior to the fail-over. A malicious node can take over as with CE-B prior to the fail-over. A malicious node can take over as
Yang, et al. Expires December 2003 [Page 30]
CE-B if such trusted relationship is not established during the CE-B if such trusted relationship is not established during the
fail-over. fail-over.
Effect: The NE may be compromised after such insecure fail-over. Effect: The NE may be compromised after such insecure fail-over.
Requirement: The level of trust relationship between the stand-by Requirement: The level of trust relationship between the stand-by
CE and the FEs must be as strong as the one between the active CE CE and the FEs must be as strong as the one between the active CE
and the FEs. The security association between the FEs and the and the FEs. The security association between the FEs and the
stand-by CE may be established prior to fail-over. If not already stand-by CE may be established prior to fail-over. If not already
in place, such security association must be re-established before in place, such security association must be re-established before
skipping to change at line 1483 skipping to change at page 32, line 5
7.1.7. Sharing security parameters 7.1.7. Sharing security parameters
Threat: Consider a scenario where several FEs communicating to the Threat: Consider a scenario where several FEs communicating to the
same CE share the same authentication keys for the Fp interface. If same CE share the same authentication keys for the Fp interface. If
any FE or the CE is compromised, all other entities are any FE or the CE is compromised, all other entities are
compromised. compromised.
Effect: The whole NE is compromised. Effect: The whole NE is compromised.
Requirement: To avoid this side effect, its better to configure Requirement: To avoid this side effect, it is better to configure
different security parameters for each FE-CE communication over Fp different security parameters for each FE-CE communication over Fp
interface. interface.
Yang, et al. Expires December 2003 [Page 31]
7.1.8. Denial of Service Attack via External Interface 7.1.8. Denial of Service Attack via External Interface
Threat: When an FE receives a packet that is destined for its CE, Threat: When an FE receives a packet that is destined for its CE,
the FE forwards the packet over the Fp interface. Malicious node the FE forwards the packet over the Fp interface. Malicious node
can generate huge message storm like routing protocol packets etc. can generate huge message storm like routing protocol packets etc.
through the external Fi/f interface so that the FE has to process through the external Fi/f interface so that the FE has to process
and forward all packets to CE through Fp interface. and forward all packets to CE through Fp interface.
Effect: CE encounters resource exhaustion and bandwidth starvation Effect: CE encounters resource exhaustion and bandwidth starvation
on Fp interface due to an overwhelming number of packets from FEs. on Fp interface due to an overwhelming number of packets from FEs.
skipping to change at line 1534 skipping to change at page 33, line 7
integrity can be provided by the physical security of the box. integrity can be provided by the physical security of the box.
7.2.1. Security Configuration 7.2.1. Security Configuration
The NE administrator has the freedom to determine the exact The NE administrator has the freedom to determine the exact
security configuration that is needed for the specific deployment. security configuration that is needed for the specific deployment.
For example, ForCES may be deployed between CEs and FEs connected For example, ForCES may be deployed between CEs and FEs connected
to each other inside a box over a backplane. In such scenario, to each other inside a box over a backplane. In such scenario,
physical security of the box ensures that most of the attacks such physical security of the box ensures that most of the attacks such
as man-in-the-middle, snooping, and impersonation are not possible, as man-in-the-middle, snooping, and impersonation are not possible,
Yang, et al. Expires December 2003 [Page 32]
and hence ForCES architecture may rely on the physical security of and hence ForCES architecture may rely on the physical security of
the box to defend against these attacks and protocol mechanisms may the box to defend against these attacks and protocol mechanisms may
be turned off. However, it is also shown that denial of service be turned off. However, it is also shown that denial of service
attack via external interface as described in Section 7.1.8 is attack via external interface as described in Section 7.1.8 is
still a potential threat even for such "all-in-one-box" deployment still a potential threat even for such "all-in-one-box" deployment
scenario and hence the rate limiting mechanism is still necessary. scenario and hence the rate limiting mechanism is still necessary.
This is just one example to show that it is important to assess the This is just one example to show that it is important to assess the
security needs of the ForCES-enabled network elements under security needs of the ForCES-enabled network elements under
different deployment scenarios. It should be possible for the different deployment scenarios. It should be possible for the
administrator to configure the level of security needed for the administrator to configure the level of security needed for the
skipping to change at line 1583 skipping to change at page 34, line 8
5) If any of the check fails in step 5 or step 6, endpoint must 5) If any of the check fails in step 5 or step 6, endpoint must
generate an error message and abort. generate an error message and abort.
6) After successful mutual authentication, a TLS session is 6) After successful mutual authentication, a TLS session is
established between CE and FE. established between CE and FE.
7) The FE sends a "join NE" message to the CE. 7) The FE sends a "join NE" message to the CE.
8) The FE and CE use TLS session for further communication. 8) The FE and CE use TLS session for further communication.
Note that there are different ways for the CE and FE to validate a Note that there are different ways for the CE and FE to validate a
received certificate. One way is to configure the FE Manager or CE received certificate. One way is to configure the FE Manager or CE
Manager or other central component as CA, so that the CE or FE can Manager or other central component as CA, so that the CE or FE can
Yang, et al. Expires December 2003 [Page 33]
query this pre-configured CA to validate that the certificate has query this pre-configured CA to validate that the certificate has
not been revoked. Another way is to have the CE and the FE not been revoked. Another way is to have the CE and the FE
configured directly a list of valid certificates in the pre- configured directly a list of valid certificates in the pre-
association phase. association phase.
In the case of fail-over, it is the responsibility of the active CE In the case of fail-over, it is the responsibility of the active CE
and the standby CE to synchronize ForCES states including the TLS and the standby CE to synchronize ForCES states including the TLS
states to minimize the state reestablishment during fail-over. Care states to minimize the state reestablishment during fail-over. Care
must be taken to ensure that the standby CE is also authenticated must be taken to ensure that the standby CE is also authenticated
in the same way as the active CE, either before or during the fail- in the same way as the active CE, either before or during the fail-
skipping to change at line 1606 skipping to change at page 34, line 29
7.2.3. Using IPsec with ForCES 7.2.3. Using IPsec with ForCES
IPsec [14] can be used with any transport protocol, such as UDP, IPsec [14] can be used with any transport protocol, such as UDP,
SCTP and TCP over Fp interface for ForCES. We recommend using ESP SCTP and TCP over Fp interface for ForCES. We recommend using ESP
in transport mode for ForCES because message confidentiality is in transport mode for ForCES because message confidentiality is
required for ForCES and the communication between the CE and FE is required for ForCES and the communication between the CE and FE is
point-to-point. point-to-point.
IPsec can be used with both manual and automated SA and IPsec can be used with both manual and automated SA and
cryptographic key management. But Ipsecs replay protection cryptographic key management. But Ipsec's replay protection
mechanisms are not available if manual key management is used. mechanisms are not available if manual key management is used.
Hence, automatic key management is recommended if replay protection Hence, automatic key management is recommended if replay protection
is deemed important. Otherwise, manual key management might be is deemed important. Otherwise, manual key management might be
sufficient for some deployment scenarios, esp. when the number of sufficient for some deployment scenarios, esp. when the number of
CEs and FEs is relatively small. It is recommended that the keys CEs and FEs is relatively small. It is recommended that the keys
be changed periodically even for manual key management. be changed periodically even for manual key management.
Unlike TLS, IPsec provides security services between the CE and FE Unlike TLS, IPsec provides security services between the CE and FE
at IP level, and so the security handshake as illustrated in Figure at IP level, and so the security handshake as illustrated in Figure
9 amounts to a "no-op" when manual key management is used. The 9 amounts to a "no-op" when manual key management is used. The
skipping to change at line 1631 skipping to change at page 35, line 7
2) The FE sends a "join NE" message to the CE. This message and 2) The FE sends a "join NE" message to the CE. This message and
all others that follow are afforded security service according to all others that follow are afforded security service according to
the manually configured IPsec SA parameters, but replay protection the manually configured IPsec SA parameters, but replay protection
is not available. is not available.
It is up to the administrator to decide whether to share the same It is up to the administrator to decide whether to share the same
key across multiple FE-CE communication, but it is recommended that key across multiple FE-CE communication, but it is recommended that
different keys be used. Similarly, it is recommended that different keys be used. Similarly, it is recommended that
different keys be used for inbound and outbound traffic. different keys be used for inbound and outbound traffic.
Yang, et al. Expires December 2003 [Page 34]
If automatic key management is needed, IKE [15] can be used for If automatic key management is needed, IKE [15] can be used for
that purpose. Other automatic key distribution techniques such as that purpose. Other automatic key distribution techniques such as
Kerberos may be used as well. The key exchange process constitutes Kerberos may be used as well. The key exchange process constitutes
the security handshake as illustrated in Figure 9. The following the security handshake as illustrated in Figure 9. The following
shows the steps involved in using IKE with IPsec for ForCES. Steps shows the steps involved in using IKE with IPsec for ForCES. Steps
1) to 6) constitute the security handshake in Figure 9. 1) to 6) constitute the security handshake in Figure 9.
1) During Pre-association phase all FEs are configured with the CEs 1) During Pre-association phase all FEs are configured with the CEs
(including active CE and standby CE), IPsec policy etc. (including active CE and standby CE), IPsec policy etc.
2) The FE kicks off IKE process and tries to establish an IPsec SA 2) The FE kicks off IKE process and tries to establish an IPsec SA
skipping to change at line 1677 skipping to change at page 36, line 5
state transfer across IPsec layer though Fr (CE-CE) Interface. state transfer across IPsec layer though Fr (CE-CE) Interface.
8. Normative References 8. Normative References
[1] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, [1] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995. June 1995.
[2] Floyd, S., "Congestion Control Principles", RFC 2914, September [2] Floyd, S., "Congestion Control Principles", RFC 2914, September
2000. 2000.
Yang, et al. Expires December 2003 [Page 35]
[3] Khosravi, H. et al., "Requirements for Separation of IP Control [3] Khosravi, H. et al., "Requirements for Separation of IP Control
and Forwarding", work in progress, May 2003, <draft-ietf-forces- and Forwarding", work in progress, May 2003, <draft-ietf-forces-
requirements-09.txt>. requirements-09.txt>.
9. Informative References 9. Informative References
[4] Case, J., et al., "A Simple Network Management Protocol [4] Case, J., et al., "A Simple Network Management Protocol
(SNMP)", RFC 1157, May 1990. (SNMP)", RFC 1157, May 1990.
[5] Daniele, M. et al., "Agent Extensibility (AgentX) Protocol [5] Daniele, M. et al., "Agent Extensibility (AgentX) Protocol
skipping to change at line 1724 skipping to change at page 37, line 4
[14] Kent, S. and R. Atkinson, "Security Architecture for the [14] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE) ", [15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE) ",
RFC 2409, November 1998. RFC 2409, November 1998.
[16] Bellovin, S., "Guidelines for Mandating the Use of Ipsec", [16] Bellovin, S., "Guidelines for Mandating the Use of Ipsec",
work in progress, October 2002, <draft-bellovin-useipsec-00.txt>. work in progress, October 2002, <draft-bellovin-useipsec-00.txt>.
10. Acknowledgements 10. Acknowledgements
Yang, et al. Expires December 2003 [Page 36]
Joel M. Halpern gave us many insightful comments and suggestions Joel M. Halpern gave us many insightful comments and suggestions
and pointed out several major issues. T. Sridhar suggested that and pointed out several major issues. T. Sridhar suggested that
the AgentX protocol could be used with SNMP to manage the ForCES the AgentX protocol could be used with SNMP to manage the ForCES
network elements. Many of our colleagues and people in the ForCES network elements. Many of our colleagues and people in the ForCES
mailing list also provided valuable feedback. mailing list also provided valuable feedback.
11. Authors' Addresses 11. Authors' Addresses
Lily L. Yang Lily L. Yang
Intel Corp., MS JF3-206, Intel Corp., MS JF3-206,
skipping to change at line 1773 skipping to change at page 38, line 6
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in RFC 2026. Copies standards-related documentation can be found in RFC 2026. Copies
of of
Yang, et al. Expires December 2003 [Page 37]
claims of rights made available for publication and any assurances claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF this standard. Please address the information to the IETF
skipping to change at line 1813 skipping to change at line 1754
other than English. other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Yang, et al. Expires December 2003 [Page 38]
 End of changes. 

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