draft-ietf-forces-framework-12.txt   draft-ietf-forces-framework-13.txt 
Internet Draft L. Yang Internet Draft L. Yang
Expiration: June 2004 Intel Corp. Expiration: July 2004 Intel Corp.
File: draft-ietf-forces-framework-12.txt R. Dantu File: draft-ietf-forces-framework-13.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
December 2003 January 2004
Forwarding and Control Element Separation (ForCES) Framework Forwarding and Control Element Separation (ForCES) Framework
draft-ietf-forces-framework-12.txt draft-ietf-forces-framework-13.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 page 2, line ? skipping to change at page 2, line ?
Table of Contents Table of Contents
1. Definitions...................................................3 1. Definitions...................................................3
1.1. Conventions used in this document........................3 1.1. Conventions used in this document........................3
1.2. Terminologies............................................3 1.2. Terminologies............................................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.............................................15
3.4. FE Managers.............................................15 3.4. FE Managers.............................................15
4. Operational Phases...........................................15 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.....18
4.2.2. Association Establishment..........................18 4.2.2. Association Establishment..........................18
4.2.3. Steady-state Communication.........................20 4.2.3. Steady-state Communication.........................20
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...........................................22
4.3. Association Re-establishment............................22 4.3. Association Re-establishment............................22
4.3.1. CE graceful restart................................22 4.3.1. CE graceful restart................................22
4.3.2. FE restart.........................................24 4.3.2. FE restart.........................................24
5. Applicability to RFC1812.....................................25 5. Applicability to RFC1812.....................................25
5.1. General Router Requirements.............................25 5.1. General Router Requirements.............................25
5.2. Link Layer..............................................26 5.2. Link Layer..............................................26
5.3. Internet Layer Protocols................................27 5.3. Internet Layer Protocols................................27
5.4. Internet Layer Forwarding...............................27 5.4. Internet Layer Forwarding...............................28
5.5. Transport Layer.........................................28 5.5. Transport Layer.........................................29
5.6. Application Layer -- Routing Protocols..................29 5.6. Application Layer -- Routing Protocols..................29
5.7. Application Layer -- Network Management Protocol........29 5.7. Application Layer -- Network Management Protocol........29
6. Summary......................................................30 6. Summary......................................................30
7. Acknowledgements.............................................30 7. Acknowledgements.............................................30
8. Security Considerations......................................30 8. Security Considerations......................................30
8.1. Analysis of Potential Threats Introduced by ForCES......30 8.1. Analysis of Potential Threats Introduced by ForCES......31
8.1.1. "Join" or "Remove" Message Flooding on CEs.........31 8.1.1. "Join" or "Remove" Message Flooding on CEs.........31
8.1.2. Impersonation Attack...............................31 8.1.2. Impersonation Attack...............................32
8.1.3. Replay Attack......................................31 8.1.3. Replay Attack......................................32
8.1.4. Attack during Fail Over............................32 8.1.4. Attack during Fail Over............................32
8.1.5. Data Integrity.....................................32 8.1.5. Data Integrity.....................................32
8.1.6. Data Confidentiality...............................32 8.1.6. Data Confidentiality...............................33
8.1.7. Sharing security parameters........................33 8.1.7. Sharing security parameters........................33
8.1.8. Denial of Service Attack via External Interface....33 8.1.8. Denial of Service Attack via External Interface....33
8.2. Security Recommendations for ForCES.....................33 8.2. Security Recommendations for ForCES.....................34
8.2.1. Security Configuration.............................34 8.2.1. Using TLS with ForCES..............................34
8.2.2. Using TLS with ForCES..............................34 8.2.2. Using IPsec with ForCES............................35
8.2.3. Using IPsec with ForCES............................35
9. Normative References.........................................37 9. Normative References.........................................37
10. Informative References......................................37 10. Informative References......................................37
11. Authors' Addresses..........................................38 11. Authors' Addresses..........................................38
12. Intellectual Property Right.................................39 12. Intellectual Property Right.................................39
13. Full Copyright Statement....................................39 13. Full Copyright Statement....................................39
1. Definitions 1. Definitions
1.1. Conventions used in this document 1.1. Conventions used in this document
skipping to change at page 4, line 9 skipping to change at page 4, line 6
described in [8]. described in [8].
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
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
and one or more FEs. To entities outside an NE, the NE represents and one or more FEs. To entities outside an NE, the NE represents
a single point of management. Similarly, an NE usually hides its a single point of management. Similarly, an NE usually hides its
internal organization from external entities. internal organization from external entities.
Pre-association Phase - The period of time during which an FE Pre-association Phase - The period of time during which an FE
Manager (see below) and a CE Manager (see below) are determining Manager (see below) and a CE Manager (see below) are determining
which FE and CE should be part of the same network element. whether an FE and a CE should be part of the same network element.
It is possible for some elements of the NE to be in pre-association
phase while other elements are in the post-association phase.
Post-association Phase - The period of time during which an FE does Post-association Phase - The period of time during which an 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).
ForCES Post-Association Phase Protocol - The protocol used for ForCES Post-Association Phase Protocol - The protocol used for
post-association phase communication between CEs and FEs. This post-association phase communication between CEs and FEs. This
protocol does not apply to CE-to-CE communication, FE-to-FE protocol does not apply to CE-to-CE communication, FE-to-FE
communication, nor to communication between FE and CE managers. communication, nor to communication between FE and CE managers.
The ForCES protocol is a master-slave protocol in which FEs are The ForCES Protocol is a master-slave protocol in which FEs are
slaves and CEs are masters. This protocol includes both the slaves and CEs are masters. This protocol includes both the
management of the communication channel (e.g., connection management of the communication channel (e.g., connection
establishment, heartbeats) and the control messages themselves. establishment, heartbeats) and the control messages themselves.
This protocol could be a single protocol or could consist of This protocol could be a single protocol or could consist of
multiple protocols working together, and may be unicast based or multiple protocols working together, and may be unicast based or
multicast based. A separate protocol document will specify this multicast based. A separate protocol document will specify this
information. information.
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
skipping to change at page 5, line 30 skipping to change at page 5, line 30
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.
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 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 - An FE or CE. ForCES Protocol Element - An FE or CE.
Intra-FE topology - Representation of how a single FE is realized Intra-FE topology - Representation of how a single FE is realized
by combining possibly multiple logical functional blocks along by combining possibly multiple logical functional blocks along
multiple data path. This is defined by the FE model. multiple data path. This is defined by the FE model.
skipping to change at page 8, line 24 skipping to change at page 8, line 24
reliability and redundancy benefits for the NE. reliability and redundancy benefits for the NE.
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
the data packets that are originated/destined from/to the control the data packets that are originated/destined from/to the control
functions in CE (e.g., routing packets). Section 4.2.4 provides functions in CE (e.g., routing packets). Section 4.2.4 provides
more detail on this. more detail on this.
------------------------------------------------- -------------------------------------------------
| | | | | | | | | | | | | |
|OSPF |RIP |BGP |RSVP |LDP |. . . | |OSPF |RIP |BGP |RSVP |LDP |. . . |
| | | | | | | | | | | | | |
------------------------------------------------- -------------------------------------------------
skipping to change at page 9, line 16 skipping to change at page 9, line 16
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
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.
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 page 9, line 48 skipping to change at page 9, line 48
-------------- Ff | -------------- -------------- | -------------- Ff | -------------- -------------- |
| FE Manager |---------+-| FE 1 | Fi | FE 2 | | | FE Manager |---------+-| FE 1 | Fi | FE 2 | |
-------------- | | |------| | | -------------- | | |------| | |
| -------------- -------------- | | -------------- -------------- |
| | | | | | | | | | | | | | | | | | | |
----+--+--+--+----------+--+--+--+----- ----+--+--+--+----------+--+--+--+-----
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Fi/f Fi/f Fi/f Fi/f
Fp: CE-FE interface
Fi: FE-FE interface
Fr: CE-CE interface
Fc: Interface between the CE Manager and a CE
Ff: Interface between the FE Manager and an FE
Fl: Interface between the CE Manager and the FE Manager
Fi/f: FE external interface
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 more instances of CE and FE inside one NE. Each FE contains one or more
physical media interfaces for receiving and transmitting packets physical media interfaces for receiving and transmitting packets
from/to the external world. The aggregation of these FE interfaces from/to the external world. The aggregation of these FE interfaces
becomes the NE's external interfaces. In addition to the external becomes the NE's external interfaces. In addition to the external
interfaces, there must also exist some kind of interconnect within interfaces, there must also exist some kind of interconnect within
the NE so that the CE and FE can communicate with each other, and the NE so that the CE and FE can communicate with each other, and
skipping to change at page 10, line 16 skipping to change at page 10, line 25
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 more instances of CE and FE inside one NE. Each FE contains one or more
physical media interfaces for receiving and transmitting packets physical media interfaces for receiving and transmitting packets
from/to the external world. The aggregation of these FE interfaces from/to the external world. The aggregation of these FE interfaces
becomes the NE's external interfaces. In addition to the external becomes the NE's external interfaces. In addition to the external
interfaces, there must also exist some kind of interconnect within interfaces, there must also exist some kind of interconnect within
the NE so that the CE and FE can communicate with each other, and the NE so that the CE and FE can communicate with each other, and
one FE can forward packets to another FE. The diagram also shows one FE can forward packets to another FE. The diagram also shows
two entities outside of the ForCES NE: CE Manager and FE Manager. two entities outside of the ForCES NE: CE Manager and FE Manager.
These two entities provide configuration to the corresponding CE or These two ancillary entities provide configuration to the
FE in the pre-association phase (see Section 4.1). There is no corresponding CE or FE in the pre-association phase (see Section
defined role for FE Manager and CE Manager in post-association 4.1).
phase, thus these logical components 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
shown in Figure 4. The FE external interfaces are labeled as Fi/f. shown in Figure 4. The FE external interfaces are labeled as Fi/f.
More detail is provided in Section 3 and 4 for each of these More detail is provided in Section 3 and 4 for each of these
reference points. All these reference points are important in reference points. All these reference points are important in
understanding the ForCES architecture, however, the ForCES protocol understanding the ForCES architecture, however, the ForCES Protocol
is only defined over one reference point -- Fp. is only 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 protocol packets through the external interfaces at Fi/f. ForCES
NEs connect to existing routers transparently. NEs 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
skipping to change at page 11, line 24 skipping to change at page 11, line 30
amongst themselves via the Fr reference point to provide amongst themselves via the Fr reference point to provide
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
uses the underlying hardware to provide per-packet processing and uses the underlying hardware to provide per-packet processing and
handling as directed by a CE. It is possible to partition one handling as directed by a CE. It is possible to partition one
physical FE into multiple logical FEs. It is also possible for one physical FE into multiple logical FEs. It is also possible for one
FE to use multiple physical FEs. The mapping between physical FE to use multiple physical FEs. The mapping between physical
FE(s) and the logical FE(s) is beyond the scope of ForCES. For FE(s) and the logical FE(s) is beyond the scope of ForCES. For
example, a logical partition of a physical FE can be created by example, a logical partition of a physical FE can be created by
assigning some portion of each of the resources (e.g., ports, assigning some portion of each of the resources (e.g., ports,
memory, forwarding table entries) available on the physical FE to memory, forwarding table entries) available on the ForCES physical
each of the logical FEs. Such concept of FE virtualization is FE to each of the logical FEs. Such concept of FE virtualization
analogous to a virtual switching element as described in [8]. If is analogous to a virtual switching element as described in [8].
FE virtualization occurs only in the pre-association phase, it has If FE virtualization occurs only in the pre-association phase, it
no impact on ForCES. However, if FE virtualization results in has no impact on ForCES. However, if FE virtualization results in
dynamic resource change on FE during post-association phase, the FE resource change taken from an existing FE (already participating in
model needs to be able to report such capability and the ForCES ForCES post-association phase), the ForCES Protocol needs to be
protocol needs to be able to inform the CE of such change via able to inform the CE of such change via asynchronous messages (see
asynchronous messages (see [3], Section 5, requirement #6). [3], Section 5, requirement #6).
FEs perform all packet processing functions as directed by CEs. FEs perform all packet processing functions 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
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 accept commands from any CE authorized to control them, and it is
up to the CEs to coordinate among themselves to achieve redundancy, up 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 their resource on simple and dumb as possible so that FEs can focus their resource on
the packet processing functions. the packet processing functions. Unless otherwise configured or
determined by a ForCEs Protocol exchange, each FE will process
authorized incoming commands directed at it as it receives them on
a first come first serve basis.
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). commands from both the primary CE (CE1) and the backup CE (CE2).
Upon detection of CE1 failure, perhaps across the Fr or Fp Upon detection of CE1 failure, perhaps across the Fr or Fp
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 a similar fashion, without Distributed control can be achieved in a 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
skipping to change at page 12, line 37 skipping to change at page 12, line 48
| /\ | | /\ |
| / \ | | / \ |
| / \ | | / \ |
------- Fi ------- ------- Fi -------
| FE1 |<----->| FE2 | | FE1 |<----->| FE2 |
------- ------- ------- -------
Figure 5. CE redundancy example. Figure 5. CE redundancy example.
This architecture permits multiple FEs to be present in an NE. [3] This architecture permits multiple FEs to be present in an NE. [3]
dictates that the ForCES protocol must be able to scale to at least dictates that the ForCES Protocol must be able to scale to at least
hundreds of FEs (see [3] Section 5, requirement #11). Each of hundreds of FEs (see [3] Section 5, requirement #11). Each of
these FEs may potentially have a different set of packet processing these FEs may potentially have a different set of packet processing
functions, with different media interfaces. FEs are responsible functions, with different media interfaces. FEs are responsible
for basic maintenance of layer-2 connectivity with other FEs and for basic maintenance of layer-2 connectivity with other FEs and
with external entities. Many layer-2 media include sophisticated with external entities. Many layer-2 media include sophisticated
control protocols. The FORCES protocol (over the Fp reference control protocols. The FORCES Protocol (over the Fp reference
point) will be able to carry messages for such protocols so that, point) will be able to carry messages for such protocols so that,
in keeping with the dumb FE model, the CE can provide appropriate in keeping with the dumb FE model, the CE can provide appropriate
intelligence and control over these media. 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
FE (See [3], Section 5, Requirement #3). Packets that enter the NE FE (See [3], Section 5, Requirement #3). Packets that enter the NE
via one FE and leave the NE via a different FE are transferred via one FE and leave the NE via a different FE are transferred
between FEs across the Fi reference point. Fi reference point between FEs across the Fi reference point. Fi reference point
could be used by FEs to discovery their (inter-FE) topology, could be used by FEs to discovery their (inter-FE) topology,
perhaps during pre-association phase. The Fi reference point is a perhaps during pre-association phase. The Fi reference point is a
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 may be queried from the FEs by the CEs topology. The FE topology may be queried from the FEs by the CEs
via ForCES protocol, but the FEs are not required to provide that via ForCES Protocol, but the FEs are not required to provide that
information to the CEs. So, the FE topology information may also be information to the CEs. So, the FE topology information may also be
gathered by other means outside of the ForCES protocol (like inter- gathered by other means outside of the ForCES Protocol (like inter-
FE topology discovery protocol). FE topology discovery protocol).
----------------- -----------------
| CE | | CE |
----------------- -----------------
^ ^ ^ ^ ^ ^
/ | \ / | \
/ v \ / v \
/ ------- \ / ------- \
/ +->| FE3 |<-+ \ / +->| FE3 |<-+ \
skipping to change at page 15, line 28 skipping to change at page 15, line 37
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
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 whether an FE and a CE
part of the same network element. The protocols used during this should be part of the same network element. The protocols used
phase may include all or some of the message exchange over Fl, Ff during this phase may include all or some of the message exchange
and Fc reference points. However, all these may be optional and over Fl, Ff and Fc reference points. However, all these may be
none of this is within the scope of ForCES protocol. optional and none of this is within the scope of ForCES Protocol.
4.1.1. Fl Reference Point 4.1.1. Fl Reference Point
CE managers and FE managers may communicate across the Fl reference CE managers and FE managers may communicate across the Fl reference
point in the pre-association phase in order to determine which CEs point in the pre-association phase in order to determine whether an
and FEs should communicate with each other. Communication across individual CE and FE, or a set of CEs and FEs should be associated.
the Fl reference point is optional in this architecture. No Communication across the Fl reference point is optional in this
requirements are placed on this reference point. architecture. No requirements are placed on this reference point.
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 Similarly, the operator of the FE manager may not want to divulge
FE characteristics, except to authorized entities. As such, CE FE 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.
skipping to change at page 17, line 40 skipping to change at page 18, line 4
reference point in such a configuration. Once appropriate security reference point in such a configuration. Once appropriate security
has been established, the CE manager instructs CEs as to which FEs has been established, the CE manager instructs CEs as to which FEs
they should control and how they should control them. Figure 8 they should control and how they should control them. Figure 8
shows example of message exchange over Fc reference point. shows example of message 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.
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 an FE and Post-association phase is the period of time during which an 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.
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 be focused on "very close" CE/FE first version of ForCES will be focused on "very close" CE/FE
localities in IP networks. Very Close localities consist of localities in IP networks. Very Close localities consist of
control and forwarding elements that either are components in the control and forwarding elements that either are components in the
same physical box, or are separated at most by one local network same physical box, or are separated at most by one local network
hop ([7]). CEs and FEs can be connected by a variety of hop ([7]). CEs and FEs can be connected by a variety of
interconnect technologies, including Ethernet connections, interconnect technologies, including Ethernet connections,
backplanes, ATM (cell) fabrics, etc. ForCES should be able to backplanes, ATM (cell) fabrics, etc. ForCES should be able to
support each of these interconnects (see [3] Section 5, requirement support each of these interconnects (see [3] Section 5, requirement
#1). When the CEs and FEs are separated beyond a single L3 routing #1). When the CEs and FEs are separated beyond a single L3 routing
skipping to change at page 18, line 14 skipping to change at page 18, line 24
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 be focused on "very close" CE/FE first version of ForCES will be focused on "very close" CE/FE
localities in IP networks. Very Close localities consist of localities in IP networks. Very Close localities consist of
control and forwarding elements that either are components in the control and forwarding elements that either are components in the
same physical box, or are separated at most by one local network same physical box, or are separated at most by one local network
hop ([7]). CEs and FEs can be connected by a variety of hop ([7]). CEs and FEs can be connected by a variety of
interconnect technologies, including Ethernet connections, interconnect technologies, including Ethernet connections,
backplanes, ATM (cell) fabrics, etc. ForCES should be able to backplanes, ATM (cell) fabrics, etc. ForCES should be able to
support each of these interconnects (see [3] Section 5, requirement support each of these interconnects (see [3] Section 5, requirement
#1). When the CEs and FEs are separated beyond a single L3 routing #1). When the CEs and FEs are separated beyond a single L3 routing
hop, the ForCES protocol will make use of an existing RFC2914 hop, the ForCES Protocol will make use of an existing RFC2914
compliant L4 protocol with adequate reliability, security and compliant L4 protocol with adequate reliability, security and
congestion control (e.g. TCP, SCTP) for transport purposes. 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|---------------------->|
| | | |
|(What kind of FE are you? -- capability query) |(What kind of FE are you? -- capability query)
3|<----------------------| 3|<----------------------|
| | | |
|(Here is my FE functions/state: use model to |(Here is my FE functions/state: use model to
describe) describe)
4|---------------------->| 4|---------------------->|
| | | |
|(How are you connected with other FEs?)
5|<----------------------|
| |
|(Here is the FE topology info)
6|---------------------->|
| |
|(Initial config for FE -- optional) |(Initial config for FE -- optional)
7|<----------------------| 5|<----------------------|
| | | |
|(I am ready to go. Shall I?) |(I am ready to go. Shall I?)
8|---------------------->| 6|---------------------->|
| | | |
|(Go ahead!) | |(Go ahead!) |
9|<----------------------| 7|<----------------------|
| | | |
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 security handshake should include mutual exchange can happen. The security handshake should include mutual
authentication and authorization between the CE and FE, but the authentication and authorization between the CE and FE, but the
exact details depend on the security solution chosen by ForCES exact details depend on the security solution chosen by ForCES
protocol. Authorization can be as simple as checking against the Protocol. Authorization can be as simple as checking against the
list of authorized end points provided by the FE or CE manager list of authorized end points provided by the FE or CE manager
during the pre-association phase. Both authentication and during the pre-association phase. Both authentication and
authorization must be successful before the association can be authorization must be successful before the association can be
established. If either authentication or authorization fails, the established. If either authentication or authorization fails, the
end point must not be allowed to join the NE. After the successful end point must not be allowed to join the NE. After the successful
security handshake, message authentication and confidentiality are security handshake, message authentication and confidentiality are
still necessary for the on-going information exchange between the still necessary for the on-going information exchange between the
CE and FE, unless some form of physical security exists. Whenever CE and FE, unless some form of physical security exists. Whenever
a packet fails authentication, it must be dropped and a a packet fails authentication, it must be dropped and a
notification may be sent to alert the sender of the potential notification may be sent to alert the sender of the potential
attack. Section 8 provides more details on the security attack. Section 8 provides more details on the security
considerations for ForCES. 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 optionally its topology in relation to
The capability of the FE is represented by the FE model, described other FEs. The capability of the FE is represented by the FE model,
in a separate document. The model would allow an FE to describe described in a separate document. The model would allow an FE to
what kind of packet processing functions it contains, in what order describe what kind of packet processing functions it contains, in
the processing happens, what kinds of configurable parameters it what order the processing happens, what kinds of configurable
allows, what statistics it collects and what events it might throw, parameters it allows, what statistics it collects and what events
etc. Once such information is available to the CE, the CE may it might throw, etc. Once such information is available to the CE,
choose to send some initial or default configuration to the FE so the CE may choose to send some initial or default configuration to
that the FE can start receiving and processing packets correctly. the FE so that the FE can start receiving and processing packets
Such initialization may not be necessary if the FE already obtains correctly. Such initialization may not be necessary if the FE
the information from its own bootstrap process. Once FE starts already obtains the information from its own bootstrap process.
accepting packets for processing, we say the association of this FE Once the necessary initial information is exchanged, the process of
with its CE is now established. From then on, the CE and FE enter association is completed. Packet processing and forwarding at the
steady-state communication. FE cannot begin until association is established. After the
association is established, the CE and FE enter steady-state
communication.
4.2.3. Steady-state Communication 4.2.3. Steady-state Communication
Once an association is established between the CE and FE, the Once an association is established between the CE and FE, the
ForCES protocol is used by the CE and FE over Fp reference point to ForCES Protocol is used by the CE and FE over Fp reference point 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|---------------------->|
| | | |
skipping to change at page 21, line 28 skipping to change at page 21, line 29
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) Control plane protocol packets (such as RIP, OSPF messages)
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
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
the CE and FE over Fp reference point, it is possible to use either the CE and FE over Fp reference point, it is possible to use either
a single protocol or multiple protocols to achieve this. a single protocol or multiple protocols to achieve this.
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 lack of a general purpose CPU) the ForCES Protocol directly, a
proxy FE can be used in the middle of Fp reference point. This proxy FE can be used to terminate the Fp reference point instead of
allows the CE communicate to the physical FE via the proxy by using the physical FE. This allows the CE communicate to the physical FE
ForCES, while the proxy manipulates the physical FE using some via the proxy by using ForCES, while the proxy manipulates the
intermediary form of communication (e.g., a non-ForCES protocol or physical FE using some intermediary form of communication (e.g., a
DMA). In such an implementation, the combination of the proxy and non-ForCES protocol or DMA). In such an implementation, the
the physical FE becomes one logical FE entity. combination of the proxy and the physical FE becomes one logical FE
entity. It is also possible that one proxy act on behalf of
multiple physical FEs.
One needs to be aware of the security implication introduced by the One needs to be aware of the security implication introduced by the
proxy FE. Since the physical FE is not capable of implementing proxy FE. Since the physical FE is not capable of implementing
ForCES itself, the security mechanism of ForCES can only secure the ForCES itself, the security mechanism of ForCES can only secure the
communication channel between the CE and the proxy FE, but not all communication channel between the CE and the proxy FE, but not all
the way to the physical FE. It is recommended that other security the way to the physical FE. It is recommended that other security
mechanisms (including physical security property) be employed to mechanisms (including physical security property) be employed to
ensure the security between the CE and the physical FE. ensure the security between the CE and the physical FE.
4.3. Association Re-establishment 4.3. Association Re-establishment
FEs and CEs may join and leave NEs dynamically (see [3] Section 5, FEs and CEs may join and leave NEs dynamically (see [3] Section 5,
requirements #12). When an FE or CE leaves the NE, the association requirements #12). When an FE or CE leaves the NE, the association
with the NE is broken. If the leaving party rejoins an NE later, with the NE is broken. If the leaving party rejoins an NE later,
to re-establish the association, it may need to re-enter the pre- to re-establish the association, it may need to re-enter the pre-
association phase. Loss of association can also happen association phase. Loss of association can also happen
unexpectedly due to loss of connection between the CE and the FE. unexpectedly due to loss of connection between the CE and the FE.
Therefore, the framework allows the bi-directional transition Therefore, the framework allows the bi-directional transition
between these two phases, but the ForCES protocol is only between these two phases, but the ForCES Protocol is only
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 (including both authentication and authorization) exists security (including both authentication and authorization) exists
before and after the association re-establishment. before and after the association re-establishment.
When an FE leaves or joins an existing NE that is already in post- When an FE leaves or joins an existing NE that is already in
association phase, the CE needs to be aware of the impact on FE operation, the CE needs to be aware of the impact on FE topology
topology and deals with the change accordingly. and deals with the change accordingly.
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
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 router's routers because the neighbors have stopped using the router's
skipping to change at page 23, line 20 skipping to change at page 23, line 24
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
been used by the IP routing protocols (OSPF [10], BGP [11], BGP been used by the IP routing protocols (OSPF [10], BGP [11]) and
[11]) and MPLS label distribution protocol (LDP [9]) to help MPLS label distribution protocol (LDP [9]) to help minimize the
minimize the negative effects on routing throughout an entire negative effects on routing throughout an entire network caused by
network caused by a restarting router. Route flap on neighboring a restarting router. Route flap on neighboring routers is avoided,
routers is avoided, and a restarting router can continue to forward and a restarting router can continue to forward packets that would
packets that would otherwise be dropped. 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 router's 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
skipping to change at page 24, line 46 skipping to change at page 24, line 49
phase and get that information from its FE manager. It may phase and get that information from its FE manager. It may
retrieve the previous CE information from its cache, if it can retrieve the previous CE information from its cache, if it can
validate the information freshness. Once it discovers its CE, it validate the information freshness. Once it discovers its CE, it
starts message exchange with the CE to re-establish the association starts message exchange with the CE to re-establish the association
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 the the state is in-sync with its CE. By comparing its state with the
CE first, it sends an information update only if it is needed. CE first, it sends an information update only if it is needed.
ForCES protocol may choose to implement similar optimization ForCES Protocol may choose to implement similar optimization
mechanisms, but it may also choose not to, as this is not a mechanisms, but it may also choose not to, as this is not a
requirement. 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 page 29, line 4 skipping to change at page 29, line 6
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
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
Interior and exterior routing protocols are implemented on CEs. Interior and exterior routing protocols are implemented on CEs.
The routing packets originated by CEs are forwarded to FEs for The routing packets originated by CEs are forwarded to FEs for
delivery. The results of such protocols (like forwarding table delivery. The results of such protocols (like forwarding table
updates) are communicated to FEs via ForCES. updates) are communicated to FEs via ForCES.
For performance or scalability reasons, portions of the control For performance or scalability reasons, portions of the control
plane functions that need faster response may be moved from the CEs plane functions that need faster response may be moved from the CEs
skipping to change at page 30, line 30 skipping to change at page 30, line 32
physical separation and interoperability of CEs and FEs, and hence physical separation and interoperability of CEs and FEs, and hence
the first interface that ought to be standardized. Simple and the first interface that ought to be standardized. Simple and
useful configurations can still be implemented with only CE-FE useful configurations can still be implemented with only CE-FE
interface being standardized, e.g., single CE with full-meshed FEs. interface being standardized, e.g., single CE with full-meshed FEs.
7. Acknowledgements 7. Acknowledgements
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. Susan Hares pointed out the issue of graceful
mailing list also provided valuable feedback. restart with ForCES. Russ Housley, Avri Doria, Jamal Hadi Salim
and many others in the ForCES mailing list also provided valuable
feedback.
8. Security Considerations 8. Security Considerations
The NE administrator has the freedom to determine the exact
security configuration that is needed for the specific deployment.
For example, ForCES may be deployed between CEs and FEs connected
to each other inside a box over a backplane. In such scenario,
physical security of the box ensures that most of the attacks such
as man-in-the-middle, snooping, and impersonation are not possible,
and hence ForCES architecture may rely on the physical security of
the box to defend against these attacks and protocol mechanisms may
be turned off. However, it is also shown that denial of service
attack via external interface as described below in Section 8.1.8
is still a potential threat even for such "all-in-one-box"
deployment scenario and hence the rate limiting mechanism is still
necessary. This is just one example to show that it is important
to assess the security needs of the ForCES-enabled network elements
under different deployment scenarios. It should be possible for
the administrator to configure the level of security needed for the
ForCES Protocol.
In general, the physical separation of two entities usually results In general, the physical separation of two entities usually results
in a potentially insecure link between the two entities and hence in a potentially insecure link between the two entities and hence
much stricter security measurements are required. For example, we much stricter security measurements are required. For example, we
pointed out in Section 4.1 that authentication becomes necessary pointed out in Section 4.1 that authentication becomes necessary
between CE manager and FE manager, between CE and CE manager, between CE manager and FE manager, between CE and CE manager,
between FE and FE manager in some configurations. The physical between FE and FE manager in some configurations. The physical
separation of CE and FE also imposes serious security requirement separation of CE and FE also imposes serious security requirement
for ForCES protocol over Fp interface. This section first attempts for ForCES Protocol over Fp interface. This section first attempts
to describe the security threats that may be introduced by the to describe the security threats that may be introduced by the
physical separation of the FEs and the CEs, and then it provides physical separation of the FEs and the CEs, and then it provides
recommendation and guidelines for secure operation and management recommendation and guidelines for secure operation and management
of ForCES protocol over Fp interface based on existing standard of ForCES Protocol over Fp interface based on existing standard
security solutions. security solutions.
8.1. Analysis of Potential Threats Introduced by ForCES 8.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.
8.1.1. "Join" or "Remove" Message Flooding on CEs 8.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
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.
skipping to change at page 32, line 17 skipping to change at page 32, line 36
8.1.4. Attack during Fail Over 8.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 with CE-B prior to the fail-over. A malicious node can take over
as CE-B if such trusted relationship is not established during the as CE-B if such trusted relationship has not been established prior
fail-over. or during the 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
the stand-by CE takes over. the stand-by CE takes over.
skipping to change at page 33, line 30 skipping to change at page 33, line 50
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.
Requirement: Some sort of rate limiting mechanism MUST to be in Requirement: Some sort of rate limiting mechanism MUST to be in
place at both FE and CE. Examples of such mechanisms include place at both the FE and CE. Rate Limiter SHOULD be configured at
explicit rate limiters or congestion control algorithms. Rate the FE for each message type that are being received through Fi/F
Limiter SHOULD be configured at FE for each message type that are interface.
being received through Fi/F interface.
8.2. Security Recommendations for ForCES 8.2. Security Recommendations for ForCES
The requirements document [3] suggested that ForCES protocol should The requirements document [3] suggested that ForCES Protocol should
support reliability over Fp interface, but no particular transport support reliability over Fp interface, but no particular transport
protocol is yet specified for ForCES. This framework document does protocol is yet specified for ForCES. This framework document does
not intend to specify the particular transport either, and so we not intend to specify the particular transport either, and so we
only provide recommendations and guidelines based on the existing only provide recommendations and guidelines based on the existing
standard security protocols that can work with the common transport standard security protocols [18] that can work with the common
candidates suitable for ForCES. transport candidates suitable for ForCES.
We review two existing security protocol solutions, namely IPsec We review two existing security protocol solutions, namely IPsec
(IP Security) [14] or TLS (Transport Layer Security) [13]. TLS (IP Security) [14] or TLS (Transport Layer Security) [13]. TLS
works with reliable transports such as TCP or SCTP for unicast, works with reliable transports such as TCP or SCTP for unicast,
while IPsec can be used with any transport (UDP, TCP, SCTP) and while IPsec can be used with any transport (UDP, TCP, SCTP) and
supports both unicast and multicast. Both TLS and IPsec can be supports both unicast and multicast. Both TLS and IPsec can be
used potentially to satisfy all of the security requirements for used potentially to satisfy all of the security requirements for
ForCES protocol. In addition, other approaches may be used as well ForCES Protocol. In addition, other approaches may be used as well
but are not documented here, including using L2 security mechanisms but are not documented here, including using L2 security mechanisms
for a given L2 interconnect technology, as long as the requirements for a given L2 interconnect technology, as long as the requirements
can be satisfied. can be satisfied.
When ForCES is deployed between CEs and FEs inside a box or a When ForCES is deployed between CEs and FEs inside a box or a
physically secured room, authentication, confidentiality and physically secured room, authentication, confidentiality and
integrity may be provided by the physical security of the box and integrity may be provided by the physical security of the box and
so the security mechanisms may be turned off, depending on the so the security mechanisms may be turned off, depending on the
networking topology and its administration policy. However, it is networking topology and its administration policy. However, it is
important to realize that even if the NE is in a single-box, the important to realize that even if the NE is in a single-box, the
DoS attacks as described in Section 8.1.8 can still be launched DoS attacks as described in Section 8.1.8 can still be launched
through Fi/f interfaces. Therefore, it is important to have the through Fi/f interfaces. Therefore, it is important to have the
corresponding counter-measurement in place even for single-box corresponding counter-measurement in place even for single-box
deployment. deployment.
8.2.1. Security Configuration 8.2.1. Using TLS with ForCES
The NE administrator has the freedom to determine the exact
security configuration that is needed for the specific deployment.
For example, ForCES may be deployed between CEs and FEs connected
to each other inside a box over a backplane. In such scenario,
physical security of the box ensures that most of the attacks such
as man-in-the-middle, snooping, and impersonation are not possible,
and hence ForCES architecture may rely on the physical security of
the box to defend against these attacks and protocol mechanisms may
be turned off. However, it is also shown that denial of service
attack via external interface as described in Section 8.1.8 is
still a potential threat even for such "all-in-one-box" deployment
scenario and hence the rate limiting mechanism is still necessary.
This is just one example to show that it is important to assess the
security needs of the ForCES-enabled network elements under
different deployment scenarios. It should be possible for the
administrator to configure the level of security needed for the
ForCES protocol.
8.2.2. Using TLS with ForCES
TLS [13] can be used if a reliable unicast transport such as TCP or TLS [13] can be used if a reliable unicast transport such as TCP or
SCTP is used for ForCES over the Fp interface. The TLS handshake SCTP is used for ForCES over the Fp interface. The TLS handshake
protocol is used during association establishment or re- protocol is used during association establishment or re-
establishment phase to negotiate a TLS session between the CE and establishment phase to negotiate a TLS session between the CE and
FE. Once the session is in place, the TLS record protocol is used FE. Once the session is in place, the TLS record protocol is used
to secure ForCES communication messages between the CE and FE. to secure ForCES communication messages between the CE and FE.
A basic outline of how TLS can be used with ForCES is described A basic outline of how TLS can be used with ForCES is described
below. Steps 1) till 7) complete the security handshake as below. Steps 1) till 7) complete the security handshake as
skipping to change at page 35, line 39 skipping to change at page 35, line 39
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. states to minimize the state reestablishment during fail-over.
Care must be taken to ensure that the standby CE is also Care must be taken to ensure that the standby CE is also
authenticated in the same way as the active CE, either before or authenticated in the same way as the active CE, either before or
during the fail-over. during the fail-over.
8.2.3. Using IPsec with ForCES 8.2.2. 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. When using IPsec, we SCTP and TCP over Fp interface for ForCES. When using IPsec, we
recommend using ESP in transport mode for ForCES because message recommend using ESP in transport mode for ForCES because message
confidentiality is required for ForCES. confidentiality is required for ForCES.
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 IPsec's 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
skipping to change at page 37, line 37 skipping to change at page 37, line 37
Interface. Interface.
9. Normative References 9. 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.
[3] Khosravi, H. et al., "Requirements for Separation of IP Control [3] Khosravi, H. and Anderson, T., "Requirements for Separation of
and Forwarding", work in progress, May 2003, <draft-ietf-forces- IP Control and Forwarding", RFC 3654, November 2003.
requirements-09.txt>.
10. Informative References 10. Informative References
[4] Case, J., et al., "Introduction and Applicability Statements [4] Case, J., et al., "Introduction and Applicability Statements
for Internet Standard Management Framework", RFC 3410, December for Internet Standard Management Framework", RFC 3410, December
2002. 2002.
[5] Daniele, M. et al., "Agent Extensibility (AgentX) Protocol [5] Daniele, M. et al., "Agent Extensibility (AgentX) Protocol
Version 1", RFC 2741, January 2000. Version 1", RFC 2741, January 2000.
[6] Chan, K. et al., "COPS Usage for Policy Provisioning (COPS- [6] Chan, K. et al., "COPS Usage for Policy Provisioning (COPS-
PR)", RFC 3084, March 2001. PR)", RFC 3084, March 2001.
[7] Crouch, A. et al., "ForCES Applicability Statement", work in [7] Crouch, A. et al., "ForCES Applicability Statement", work in
progress, June 2002, <draft-ietf-forces-applicability-00.txt>. progress, June 2003, <draft-ietf-forces-applicability-02.txt>.
[8] Anderson, T. and J. Buerkle, "Requirements for the Dynamic [8] Anderson, T. and J. Buerkle, "Requirements for the Dynamic
Partitioning of Switching Elements", RFC 3532, May 2003. Partitioning of Switching Elements", RFC 3532, May 2003.
[9] Leelanivas, M. et al., "Graceful Restart Mechanism for Label [9] Leelanivas, M. et al., "Graceful Restart Mechanism for Label
Distribution Protocol", RFC 3478, February 2003. Distribution Protocol", RFC 3478, February 2003.
[10] Moy, J. et al., "Graceful OSPF Restart", work in progress, [10] Moy, J. et al., "Graceful OSPF Restart", RFC 3623, November
March 2003, <draft-ietf-ospf-hitless-restart-07.txt>. 2003.
[11] Sangli, S. et al., "Graceful Restart Mechanism for BGP", work [11] Sangli, S. et al., "Graceful Restart Mechanism for BGP", work
in progress, January 2003, < draft-ietf-idr-restart-06.txt>. in progress, September 2003, < draft-ietf-idr-restart-08.txt>.
[12] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", work [12] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", work
in progress, March 2003, <draft-ietf-isis-restart-03.txt>. in progress, July 2003, <draft-ietf-isis-restart-04.txt>.
[13] Dierks, T. and C. Allen, "The TLS Protocol, version 1.0", RFC [13] Dierks, T. and C. Allen, "The TLS Protocol, version 1.0", RFC
2246, January 1999. 2246, January 1999.
[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 2003, <draft-bellovin-useipsec-02.txt>.
[17] Hardjono, T. and Weis, B. "The Multicast Security [17] Hardjono, T. and Weis, B. "The Multicast Security
Architecture", work in progress, August 2003, <draft-ietf-msec- Architecture", work in progress, November 2003, <draft-ietf-msec-
arch-03.txt>. arch-04.txt>.
[18] S. Bellovin, J. Schiller, and C. Kaufman, "Security Mechanisms
for the Internet", RFC 3631, December, 2003.
11. Authors' Addresses 11. Authors' Addresses
L. Lily Yang L. Lily Yang
Intel Corp., MS JF3-206, Intel Corp., MS JF3-206,
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124, USA Hillsboro, OR 97124, USA
Phone: +1 503 264 8813 Phone: +1 503 264 8813
Email: lily.l.yang@intel.com Email: lily.l.yang@intel.com
 End of changes. 

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