Network Working Group
`Request for Comments: 3746
`Category: Informational
`
`L. Yang
`Intel Corp.
`R. Dantu
`Univ. of North Texas
`T. Anderson
`Intel Corp.
`R. Gopal
`Nokia
`April 2004
`
`Forwarding and Control Element Separation (ForCES) Framework
`
`Status of this Memo
`
` This memo provides information for the Internet community. It does
` not specify an Internet standard of any kind. Distribution of this
` memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2004). All Rights Reserved.
`
`Abstract
`
` This document defines the architectural framework for the ForCES
` (Forwarding and Control Element Separation) network elements, and
` identifies the associated entities and their interactions.
`
`Table of Contents
`
`1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
`1.1. Conventions used in this document . . . . . . . . . . . . 2
`1.2. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3
`2. Introduction to Forwarding and Control Element Separation
`(ForCES) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
`3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 8
`3.1. Control Elements and Fr Reference Point . . . . . . . . . 10
`3.2. Forwarding Elements and Fi reference point. . . . . . . . 11
`3.3. CE Managers . . . . . . . . . . . . . . . . . . . . . . . 14
`3.4. FE Managers . . . . . . . . . . . . . . . . . . . . . . . 14
`4. Operational Phases . . . . . . . . . . . . . . . . . . . . . . 15
`4.1. Pre-association Phase . . . . . . . . . . . . . . . . . . 15
`4.1.1. Fl Reference Point . . . . . . . . . . . . . . . . 15
`4.1.2. Ff Reference Point . . . . . . . . . . . . . . . . 16
`4.1.3. Fc Reference Point . . . . . . . . . . . . . . . . 17
`4.2. Post-association Phase and Fp reference point . . . . . . 17
`4.2.1. Proximity and Interconnect between CEs and FEs . . 18
`
`Yang, et al.
`
`Informational
`
`[Page 1]
`
`EX 1012 Page 1
`
`

`

`RFC 3746 ForCES Framework April 2004
`
` 4.2.2. Association Establishment. . . . . . . . . . . . . 18
` 4.2.3. Steady-state Communication . . . . . . . . . . . . 19
` 4.2.4. Data Packets across Fp reference point . . . . . . 21
` 4.2.5. Proxy FE . . . . . . . . . . . . . . . . . . . . . 22
` 4.3. Association Re-establishment. . . . . . . . . . . . . . . 22
` 4.3.1. CE graceful restart. . . . . . . . . . . . . . . . 23
` 4.3.2. FE restart . . . . . . . . . . . . . . . . . . . . 24
` 5. Applicability to RFC 1812. . . . . . . . . . . . . . . . . . . 25
` 5.1. General Router Requirements . . . . . . . . . . . . . . . 25
` 5.2. Link Layer. . . . . . . . . . . . . . . . . . . . . . . . 26
` 5.3. Internet Layer Protocols. . . . . . . . . . . . . . . . . 27
` 5.4. Internet Layer Forwarding . . . . . . . . . . . . . . . . 27
` 5.5. Transport Layer . . . . . . . . . . . . . . . . . . . . . 28
` 5.6. Application Layer -- Routing Protocols. . . . . . . . . . 29
` 5.7. Application Layer -- Network Management Protocol. . . . . 29
` 6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
` 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
` 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 30
` 8.1. Analysis of Potential Threats Introduced by ForCES. . . . 31
` 8.1.1. "Join" or "Remove" Message Flooding on CEs . . . . 31
` 8.1.2. Impersonation Attack . . . . . . . . . . . . . . . 31
` 8.1.3. Replay Attack. . . . . . . . . . . . . . . . . . . 31
` 8.1.4. Attack during Fail Over. . . . . . . . . . . . . . 32
` 8.1.5. Data Integrity . . . . . . . . . . . . . . . . . . 32
` 8.1.6. Data Confidentiality . . . . . . . . . . . . . . . 32
` 8.1.7. Sharing security parameters. . . . . . . . . . . . 33
` 8.1.8. Denial of Service Attack via External Interface. . 33
` 8.2. Security Recommendations for ForCES . . . . . . . . . . . 33
` 8.2.1. Using TLS with ForCES. . . . . . . . . . . . . . . 34
` 8.2.2. Using IPsec with ForCES. . . . . . . . . . . . . . 35
` 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
` 9.1. Normative References. . . . . . . . . . . . . . . . . . . 37
` 9.2. Informative References. . . . . . . . . . . . . . . . . . 37
` 10. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 39
` 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 40
`
`1. Definitions
`
`1.1. Conventions used in this document
`
` The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
` "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
` document are to be interpreted as described in BCP 14, RFC 2119 [1].
`
`Yang, et al. Informational [Page 2]
`
`EX 1012 Page 2
`
`

`

`RFC 3746
`
`ForCES Framework
`
`April 2004
`
`1.2. Terminologies
`
` A set of terminology associated with the ForCES requirements is
` defined in [4] and we only include the definitions that are most
` relevant to this document here.
`
` Addressable Entity (AE) - An entity that is directly addressable
` given some interconnect technology. For example, on IP networks, it
` is a device to which we can communicate using an IP address; on a
` switch fabric, it is a device to which we can communicate using a
` switch fabric port number.
`
` Physical Forwarding Element (PFE) - An AE that includes hardware used
` to provide per-packet processing and handling. This hardware may
` consist of (but is not limited to) network processors, ASICs
` (Application-Specific Integrated Circuits), or general purpose
` processors, installed on line cards, daughter boards, mezzanine
` cards, or in stand-alone boxes.
`
` PFE Partition - A logical partition of a PFE consisting of some
` subset of each of the resources (e.g., ports, memory, forwarding
` table entries) available on the PFE. This concept is analogous to
` that of the resources assigned to a virtual switching element as
` described in [9].
`
` Physical Control Element (PCE) - An AE that includes hardware used to
` provide control functionality. This hardware typically includes a
` general purpose processor.
`
` PCE Partition - A logical partition of a PCE consisting of some
` subset of each of the resources available on the PCE.
`
` Forwarding Element (FE) - A logical entity that implements the ForCES
` Protocol. FEs use the underlying hardware to provide per-packet
` processing and handling as directed by a CE via the ForCES Protocol.
` FEs may happen to be a single blade (or PFE), a partition of a PFE,
` or multiple PFEs.
`
` Control Element (CE) - A logical entity that implements the ForCES
` Protocol and uses it to instruct one or more FEs on how to process
` packets. CEs handle functionality such as the execution of control
` and signaling protocols. CEs may consist of PCE partitions or whole
` PCEs.
`
` ForCES Network Element (NE) - An entity composed of one or more CEs
` and one or more FEs. An NE usually hides its internal organization
` from external entities and represents a single point of management to
` entities outside the NE.
`
`Yang, et al.
`
`Informational
`
`[Page 3]
`
`EX 1012 Page 3
`
`

`

`RFC 3746 ForCES Framework April 2004
`
` Pre-association Phase - The period of time during which an FE Manager
` (see below) and a CE Manager (see below) are determining 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 knows
` which CE is to control it and vice versa, including the time during
` which the CE and FE are establishing communication with one another.
`
` ForCES Protocol - While there may be multiple protocols used within
` the overall ForCES architecture, the term "ForCES Protocol" refers
` only to the ForCES post-association phase protocol (see below).
`
` ForCES Post-Association Phase Protocol - The protocol used for post-
` association phase communication between CEs and FEs. This protocol
` does not apply to CE-to-CE communication, FE-to-FE communication, or
` to communication between FE and CE managers. The ForCES Protocol is
` a master-slave protocol in which FEs are slaves and CEs are masters.
` This protocol includes both the management of the communication
` channel (e.g., connection establishment, heartbeats) and the control
` messages themselves. This protocol could be a single protocol or
` could consist of multiple protocols working together, and may be
` unicast or multicast based. A separate protocol document will
` specify this information.
`
` FE Manager - A logical entity that operates in the pre-association
` phase and is responsible for determining to which CE(s) an FE should
` communicate. This process is called CE discovery and may involve the
` FE manager learning the capabilities of available CEs. An FE manager
` may use anything from a static configuration to a pre-association
` phase protocol (see below) to determine which CE(s) to use; however,
` this is currently out of scope. Being a logical entity, an FE
` manager might be physically combined with any of the other logical
` entities mentioned in this section.
`
` CE Manager - A logical entity that operates in the pre-association
` phase and is responsible for determining to which FE(s) a CE should
` communicate. This process is called FE discovery and may involve the
` CE manager learning the capabilities of available FEs. A CE manager
` may use anything from a static configuration to a pre-association
` phase protocol (see below) to determine which FE to use; however,
` this is currently out of scope. Being a logical entity, a CE manager
` might be physically combined with any of the other logical entities
` mentioned in this section.
`
`Yang, et al. Informational [Page 4]
`
`EX 1012 Page 4
`
`

`

`RFC 3746 ForCES Framework April 2004
`
` Pre-association Phase Protocol - A protocol between FE managers and
` CE managers that is used to determine which CEs or FEs to use. A
` pre-association phase protocol may include a CE and/or FE capability
` discovery mechanism. Note that this capability discovery process is
` wholly separate from (and does not replace) that used within the
` ForCES Protocol. However, the two capability discovery mechanisms
` may utilize the same FE model.
`
` FE Model - A model that describes the logical processing functions of
` an FE.
`
` ForCES Protocol Element - An FE or CE.
`
` Intra-FE topology - Representation of how a single FE is realized by
` combining possibly multiple logical functional blocks along multiple
` data paths. 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, to be
` distinguished from intra-FE topology used by the FE model.
`
` Inter-FE topology - See FE Topology.
`
`2. Introduction to Forwarding and Control Element Separation (ForCES)
`
` An IP network element (NE) appears to external entities as a
` monolithic piece of network equipment, e.g., a router, NAT, firewall,
` or load balancer. Internally, however, an IP network element (NE)
` (such as a router) is composed of numerous logically separated
` entities that cooperate to provide a given functionality (such as
` routing). Two types of network element components exist: control
` element (CE) in control plane and forwarding element (FE) in
` forwarding plane (or data plane). Forwarding elements are typically
` ASIC, network-processor, or general-purpose processor-based devices
` that handle data path operations for each packet. Control elements
` are typically based on general-purpose processors that provide
` control functionality, like routing and signaling protocols.
`
` ForCES aims to define a framework and associated protocol(s) to
` standardize information exchange between the control and forwarding
` plane. Having standard mechanisms allows CEs and FEs to become
` physically separated standard components. This physical separation
` accrues several benefits to the ForCES architecture. Separate
` components would allow component vendors to specialize in one
` component without having to become experts in all components.
` Standard protocol also allows the CEs and FEs from different
` component vendors to interoperate with each other and hence it
` becomes possible for system vendors to integrate together the CEs and
`
`Yang, et al. Informational [Page 5]
`
`EX 1012 Page 5
`
`

`

`RFC 3746 ForCES Framework April 2004
`
` FEs from different component suppliers. This interoperability
` translates into increased design choices and flexibility for the
` system vendors. Overall, ForCES will enable rapid innovation in both
` the control and forwarding planes while maintaining interoperability.
` Scalability is also easily provided by this architecture in that
` additional forwarding or control capacity can be added to existing
` network elements without the need for forklift upgrades.
`
` ------------------------- -------------------------
` | Control Blade A | | Control Blade B |
` | (CE) | | (CE) |
` ------------------------- -------------------------
` ^ | ^ |
` | | | |
` | V | V
` ---------------------------------------------------------
` | Switch Fabric Backplane |
` ---------------------------------------------------------
` ^ | ^ | ^ |
` | | | | . . . | |
` | V | V | V
` ------------ ------------ ------------
` |Router | |Router | |Router |
` |Blade #1 | |Blade #2 | |Blade #N |
` | (FE) | | (FE) | | (FE) |
` ------------ ------------ ------------
` ^ | ^ | ^ |
` | | | | . . . | |
` | V | V | V
`
` Figure 1. A router configuration example with separate blades.
`
` One example of such physical separation is at the blade level. Figure
` 1 shows such an example configuration of a router, with two control
` blades and multiple forwarding blades, all interconnected into a
` switch fabric backplane. In such a chassis configuration, the
` control blades are the CEs while the router blades are the FEs, and
` the switch fabric backplane provides the physical interconnect for
` all the blades. Control blade A may be the primary CE while control
` blade B may be the backup CE providing redundancy. It is also
` possible to have a redundant switch fabric for high availability
` support. Routers today with this kind of configuration use
` proprietary interfaces for messaging between CEs and FEs. The goal
` of ForCES is to replace such proprietary interfaces with a standard
` protocol. With a standard protocol like ForCES implemented on all
` blades, it becomes possible for control blades from vendor X and
` forwarding blades from vendor Y to work seamlessly together in one
` chassis.
`
`Yang, et al. Informational [Page 6]
`
`EX 1012 Page 6
`
`

`

`RFC 3746 ForCES Framework April 2004
`
` ------- -------
` | CE1 | | CE2 |
` ------- -------
` ^ ^
` | |
` V V
` ============================================ Ethernet
` ^ ^ . . . ^
` | | |
` V V V
` ------- ------- --------
` | FE#1| | FE#2| | FE#n |
` ------- ------- --------
` ^ | ^ | ^ |
` | | | | | |
` | V | V | V
`
` Figure 2. A router configuration example with separate boxes.
`
` Another level of physical separation between the CEs and FEs can be
` at the box level. In such a configuration, all the CEs and FEs are
` physically separated boxes, interconnected with some kind of high
` speed LAN connection (like Gigabit Ethernet). These separated CEs
` and FEs are only one hop away from each other within a local area
` network. The CEs and FEs communicate to each other by running
` ForCES, and the collection of these CEs and FEs together become one
` routing unit to the external world. Figure 2 shows such an example.
`
` In both examples shown here, the same physical interconnect is used
` 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 is
` that the CE-to-FE interconnect does not have to be as fast as the
` FE-to-FE interconnect, so the more faster and more expensive
` connections can be saved for FE-to-FE. The separate interconnects
` may also provide reliability and redundancy benefits for the NE.
`
` Some examples of control functions that can be implemented in the CE
` include routing protocols like RIP, OSPF, and BGP, control and
` signaling protocols like RSVP (Resource Reservation Protocol), LDP
` (Label Distribution Protocol) for MPLS, etc. Examples of forwarding
` functions in the FE include LPM (longest prefix match) forwarder,
` classifiers, traffic shaper, meter, NAT (Network Address
` 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
` functions in it. The diagram also shows that the ForCES Protocol is
` used to transport both the control messages for ForCES itself and the
`
`Yang, et al. Informational [Page 7]
`
`EX 1012 Page 7
`
`

`

`RFC 3746 ForCES Framework April 2004
`
` data packets that are originated/destined from/to the control
` functions in the CE (e.g., routing packets). Section 4.2.4 provides
` more detail on this.
`
` -------------------------------------------------
` | | | | | | |
` |OSPF |RIP |BGP |RSVP |LDP |. . . |
` | | | | | | |
` -------------------------------------------------
` | ForCES Interface |
` -------------------------------------------------
` ^ ^
` ForCES | |data
` control | |packets
` messages| |(e.g., routing packets)
` v v
` -------------------------------------------------
` | ForCES Interface |
` -------------------------------------------------
` | | | | | | |
` |LPM Fwd|Meter |Shaper |NAT |Classi-|. . . |
` | | | | |fier | |
` -------------------------------------------------
` | FE resources |
` -------------------------------------------------
`
` Figure 3. Examples of CE and FE functions.
`
` A set of requirements for control and forwarding separation is
` identified in [4]. This document describes a ForCES architecture
` that satisfies the architectural requirements of [4] and defines a
` framework for ForCES network elements and the associated entities to
` facilitate protocol definition. Whenever necessary, this document
` uses many examples to illustrate the issues and/or possible solutions
` in ForCES. These examples are intended to be just examples, and
` should not be taken as the only or definite ways of doing certain
` things. It is expected that a separate document will be produced by
` the ForCES working group to specify the ForCES Protocol.
`
`3. Architecture
`
` This section defines the ForCES architectural framework and the
` associated logical components. This ForCES framework defines
` components of ForCES NEs, including several ancillary components.
` These components may be connected in different kinds of topologies
` for flexible packet processing.
`
`Yang, et al. Informational [Page 8]
`
`EX 1012 Page 8
`
`

`

`RFC 3746 ForCES Framework April 2004
`
` ---------------------------------------
` | ForCES Network Element |
` -------------- Fc | -------------- -------------- |
` | CE Manager |---------+-| CE 1 |------| CE 2 | |
` -------------- | | | Fr | | |
` | | -------------- -------------- |
` | Fl | | | Fp / |
` | | Fp| |----------| / |
` | | | |/ |
` | | | | |
` | | | Fp /|----| |
` | | | /--------/ | |
` -------------- Ff | -------------- -------------- |
` | FE Manager |---------+-| FE 1 | Fi | FE 2 | |
` -------------- | | |------| | |
` | -------------- -------------- |
` | | | | | | | | | |
` ----+--+--+--+----------+--+--+--+-----
` | | | | | | | |
` | | | | | | | |
` 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
`
` The diagram in Figure 4 shows the logical components of the ForCES
` architecture and their relationships. There are two kinds of
` components inside a ForCES network element: control element (CE) and
` forwarding element (FE). The framework allows multiple instances of
` CE and FE inside one NE. Each FE contains one or more physical media
` interfaces for receiving and transmitting packets from/to the
` external world. The aggregation of these FE interfaces becomes the
` NE’s external interfaces. In addition to the external interfaces,
` there must also exist some kind of interconnect within the NE so that
` the CE and FE can communicate with each other, and one FE can forward
` packets to another FE. The diagram also shows two entities outside
` of the ForCES NE: CE Manager and FE Manager. These two ancillary
` entities provide configuration to the corresponding CE or FE in the
` pre-association phase (see Section 4.1).
`
`Yang, et al. Informational [Page 9]
`
`EX 1012 Page 9
`
`

`

`RFC 3746 ForCES Framework April 2004
`
` For convenience, the logical interactions between these components
` are labeled by reference points Fp, Fc, Ff, Fr, Fl, and Fi, as shown
` in Figure 4. The FE external interfaces are labeled as Fi/f. More
` detail is provided in Section 3 and 4 for each of these reference
` points. All these reference points are important in understanding
` the ForCES architecture, however, the ForCES Protocol is only defined
` over one reference point -- Fp.
`
` The interface between two ForCES NEs is identical to the interface
` between two conventional routers and these two NEs exchange the
` protocol packets through the external interfaces at Fi/f. ForCES NEs
` connect to existing routers transparently.
`
`3.1. Control Elements and Fr Reference Point
`
` It is not necessary to define any protocols across the Fr reference
` point to enable control and forwarding separation for simple
` configurations like single CE and multiple FEs. However, this
` architecture permits multiple CEs to be present in a network element.
` In cases where an implementation uses multiple CEs, the invariant
` that the CEs and FEs together appear as a single NE must be
` maintained.
`
` Multiple CEs may be used for redundancy, load sharing, distributed
` control, or other purposes. Redundancy is the case where one or more
` CEs are prepared to take over should an active CE fail. Load sharing
` is the case where two or more CEs are concurrently active and any
` request that can be serviced by one of the CEs can also be serviced
` by any of the other CEs. For both redundancy and load sharing, the
` CEs involved are equivalently capable. The only difference between
` these two cases is in terms of how many active CEs there are
` simultaneously. Distributed control is the case where two or more
` CEs are concurrently active but certain requests can only be serviced
` by certain CEs.
`
` When multiple CEs are employed in a ForCES NE, their internal
` organization is considered an implementation issue that is beyond the
` scope of ForCES. CEs are wholly responsible for coordinating amongst
` themselves via the Fr reference point to provide consistency and
` synchronization. However, ForCES does not define the implementation
` or protocols used between CEs, nor does it define how to distribute
` functionality among CEs. Nevertheless, ForCES will support
` mechanisms for CE redundancy or fail over, and it is expected that
` vendors will provide redundancy or fail over solutions within this
` framework.
`
`Yang, et al. Informational [Page 10]
`
`EX 1012 Page 10
`
`

`

`RFC 3746 ForCES Framework April 2004
`
`3.2. Forwarding Elements and Fi reference point
`
` An FE is a logical entity that implements the ForCES Protocol and
` uses the underlying hardware to provide per-packet processing and
` handling as directed by a CE. It is possible to partition one
` physical FE into multiple logical FEs. It is also possible for one
` FE to use multiple physical FEs. The mapping between physical FE(s)
` and logical FE(s) is beyond the scope of ForCES. For example, a
` logical partition of a physical FE can be created by assigning some
` portion of each of the resources (e.g., ports, memory, forwarding
` table entries) available on the ForCES physical FE to each of the
` logical FEs. Such a concept of FE virtualization is analogous to a
` virtual switching element as described in [9]. If FE virtualization
` occurs only in the pre-association phase, it has no impact on ForCES.
` However, if FE virtualization results in a resource change taken from
` an existing FE (already participating in ForCES post-association
` phase), the ForCES Protocol needs to be able to inform the CE of such
` a change via asynchronous messages (see [4], Section 5, requirement
` #6).
`
` FEs perform all packet processing functions as directed by CEs. 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
` concurrently across reference point Fp. FEs have no notion of CE
` redundancy, load sharing, or distributed control. Instead, FEs
` accept commands from any CE authorized to control them, and it is up
` to the CEs to coordinate among themselves to achieve redundancy, load
` sharing, or distributed control. The idea is to keep FEs as simple
` and dumb as possible so that FEs can focus their resources on 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
` commands from both the primary CE (CE1) and the backup CE (CE2).
` Upon detection of CE1 failure, perhaps across the Fr or Fp reference
` point, CE2 is configured to take over activities of CE1. This is
` beyond the scope of ForCES and is not discussed further.
`
` Distributed control can be achieved in a similar fashion, without
` much intelligence on the part of FEs. For example, FEs can be
` configured to detect RSVP and BGP protocol packets, and forward RSVP
` packets to one CE and BGP packets to another CE. Hence, FEs may need
` to do packet filtering for forwarding packets to specific CEs.
`
`Yang, et al. Informational [Page 11]
`
`EX 1012 Page 11
`
`

`

`RFC 3746 ForCES Framework April 2004
`
` ------- Fr -------
` | CE1 | ------| CE2 |
` ------- -------
` | \ / |
` | \ / |
` | \ / |
` | \/Fp |
` | /\ |
` | / \ |
` | / \ |
` ------- Fi -------
` | FE1 |<----->| FE2 |
` ------- -------
`
` Figure 5. CE redundancy example.
`
` This architecture permits multiple FEs to be present in an NE. [4]
` dictates that the ForCES Protocol must be able to scale to at least
` hundreds of FEs (see [4] Section 5, requirement #11). Each of these
` FEs may potentially have a different set of packet processing
` functions, with different media interfaces. FEs are responsible for
` basic maintenance of layer-2 connectivity with other FEs and with
` external entities. Many layer-2 media include sophisticated control
` protocols. The FORCES Protocol (over the Fp reference point) will be
` able to carry messages for such protocols so that, in keeping with
` the dumb FE model, the CE can provide appropriate intelligence and
` control over these media.
`
` 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
` FE (See [4], Section 5, Requirement #3). Packets that enter the NE
` via one FE and leave the NE via a different FE are transferred
` between FEs across the Fi reference point. The Fi reference point
` could be used by FEs to discover their (inter-FE) topology, perhaps
` during the pre-association phase. The Fi reference point is a
` separate protocol from the Fp reference point and is not currently
` defined by the ForCES Protocol.
`
` FEs could be connected in different kinds of topologies and packet
` processing may spread across several FEs in the topology. Hence,
` logical packet flow may be different from physical FE topology.
` Figure 6 provides some topology examples. When it is necessary to
` forward packets between FEs, the CE needs to understand the FE
` topology. The FE topology may be queried from the FEs by the CEs via
` the ForCES Protocol, but the FEs are not required to provide that
` information to the CEs. So, the FE topology information may also be
` gathered by other means outside of the ForCES Protocol (like inter-FE
` topology discovery protocol).
`
`Yang, et al. Informational [Page 12]
`
`EX 1012 Page 12
`
`

`

`RFC 3746 ForCES Framework April 2004
`
` -----------------
` | CE |
` -----------------
` ^ ^ ^
` / | \
` / v \
` / ------- \
` / +->| FE3 |<-+ \
` / | | | | \
` v | ------- | v
` ------- | | -------
` | FE1 |<-+ +->| FE2 |
` | |<--------------->| |
` ------- -------
` ^ | ^ |
` | | | |
` | v | v
`
` (a) Full mesh among FE1, FE2, and FE3
`
`