GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3654

Network Working Group H. Khosravi, Ed. Request for Comments: 3654 T. Anderson, Ed. Category: Informational Intel

                                                         November 2003
     Requirements for Separation of IP Control and Forwarding

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 (2003).  All Rights Reserved.

Abstract

 This document introduces the Forwarding and Control Element
 Separation (ForCES) architecture and defines a set of associated
 terminology.  This document also defines a set of architectural,
 modeling, and protocol requirements to logically separate the control
 and data forwarding planes of an IP (IPv4, IPv6, etc.) networking
 device.

Table of Contents

 1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
 2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   2
 3.  Architecture. . . . . . . . . . . . . . . . . . . . . . . . .   4
 4.  Architectural Requirements. . . . . . . . . . . . . . . . . .   5
 5.  FE Model Requirements . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Types of Logical Functions. . . . . . . . . . . . . . .   8
     5.2.  Variations of Logical Functions . . . . . . . . . . . .   8
     5.3.  Ordering of Logical Functions . . . . . . . . . . . . .   8
     5.4.  Flexibility . . . . . . . . . . . . . . . . . . . . . .   8
     5.5   Minimal Set of Logical Functions. . . . . . . . . . . .   9
 6.  ForCES Protocol Requirements. . . . . . . . . . . . . . . . .  10
 7.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Normative References. . . . . . . . . . . . . . . . . .  14
     7.2.  Informative References. . . . . . . . . . . . . . . . .  15
 8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
 9.  Authors' Addresses & Acknowledgments. . . . . . . . . . . . .  15
 10. Editors' Contact Information. . . . . . . . . . . . . . . . .  17
 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  18

Khosravi & Anderson Informational [Page 1] RFC 3654 ForCES Requirements November 2003

1. Introduction

 An IP network element is composed of numerous logically separate
 entities that cooperate to provide a given functionality (such as a
 routing or IP switching) and yet appear as a normal integrated
 network element to external entities.  Two primary types of network
 element components exist: control-plane components and forwarding-
 plane components.  In general, forwarding-plane components are ASIC,
 network-processor, or general-purpose processor-based devices that
 handle all data path operations.  Conversely, control-plane
 components are typically based on general-purpose processors that
 provide control functionality such as the processing of routing or
 signaling protocols.  A standard set of mechanisms for connecting
 these components provides increased scalability and allows the
 control and forwarding planes to evolve independently, thus promoting
 faster innovation.
 For the purpose of illustration, let us consider the architecture of
 a router to illustrate the concept of separate control and forwarding
 planes.  The architecture of a router is composed of two main parts.
 These components, while inter-related, perform functions that are
 largely independent of each other.  At the bottom is the forwarding
 path that operates in the data-forwarding plane and is responsible
 for per-packet processing and forwarding.  Above the forwarding plane
 is the network operating system that is responsible for operations in
 the control plane.  In the case of a router or switch, the network
 operating system runs routing, signaling and control protocols (e.g.,
 RIP, OSPF and RSVP) and dictates the forwarding behavior by
 manipulating forwarding tables, per-flow QoS tables and access
 control lists.  Typically, the architecture of these devices combines
 all of this functionality into a single functional whole with respect
 to external entities.

2. Definitions

 Addressable Entity (AE) - A physical device 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; and 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, ASIC's, line
 cards with multiple chips or stand alone box with general-purpose
 processors.

Khosravi & Anderson Informational [Page 2] RFC 3654 ForCES Requirements November 2003

 Physical Control Element (PCE) - An AE that includes hardware used to
 provide control functionality.  This hardware typically includes a
 general-purpose processor.
 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/controlled 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 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.
 Pre-association Phase - The period of time during which a FE Manager
 (see below) and a CE Manager (see below) are determining which FE and
 CE should be part of the same network element.  Any partitioning of
 PFEs and PCEs occurs during this phase.
 Post-association Phase - The period of time during which a FE does
 know which CE is to control it and vice versa, including the time
 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.
 FE Model - A model that describes the logical processing functions of
 a FE.
 FE Manager - A logical entity that operates in the pre-association
 phase and is responsible for determining to which CE(s) a FE should
 communicate.  This process is called CE discovery and may involve the
 FE manager learning the capabilities of available CEs.  A FE manager
 may use anything from a static configuration to a pre-association

Khosravi & Anderson Informational [Page 3] RFC 3654 ForCES Requirements November 2003

 phase protocol (see below) to determine which CE to use.  However,
 this pre-association phase protocol is currently out of scope.  Being
 a logical entity, a 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.  Again, this
 pre-association phase protocol 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.
 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) what is used within the
 ForCES protocol (see Section 6, requirement #1).  However, the two
 capability discovery mechanisms may utilize the same FE model (see
 Section 5).  Pre-association phase protocols are not discussed
 further in this document.
 ForCES Network Element (NE) - An entity composed of one or more CEs
 and one or more FEs.  To entities outside a NE, the NE represents a
 single point of management.  Similarly, a NE usually hides its
 internal organization from external entities.
 ForCES Protocol Element - A FE or CE.
 High Touch Capability - This term will be used to apply to the
 capabilities found in some forwarders to take action on the contents
 or headers of a packet based on content other than what is found in
 the IP header.  Examples of these capabilities include NAT-PT,
 firewall, and L7 content recognition.

3. Architecture

 The chief components of a NE architecture are the CE, the FE, and the
 interconnect protocol.  The CE is responsible for operations such as
 signaling and control protocol processing and the implementation of
 management protocols.  Based on the information acquired through
 control processing, the CE(s) dictates the packet-forwarding behavior
 of the FE(s) via the interconnect protocol.  For example, the CE
 might control a FE by manipulating its forwarding tables, the state
 of its interfaces, or by adding or removing a NAT binding.

Khosravi & Anderson Informational [Page 4] RFC 3654 ForCES Requirements November 2003

 The FE operates in the forwarding plane and is responsible for per-
 packet processing and handling.  By allowing the control and
 forwarding planes to evolve independently, different types of FEs can
 be developed - some general purpose and others more specialized.
 Some functions that FEs could perform include layer 3 forwarding,
 metering, shaping, firewall, NAT, encapsulation (e.g., tunneling),
 decapsulation, encryption, accounting, etc.  Nearly all combinations
 of these functions may be present in practical FEs.
 Below is a diagram illustrating an example NE composed of a CE and
 two FEs.  Both FEs and CE require minimal configuration as part of
 the pre-configuration process and this may be done by FE Manager and
 CE Manager respectively.  Apart from this, there is no defined role
 for FE Manager and CE Manager.  These components are out of scope of
 the architecture and requirements for the ForCES protocol, which only
 involves CEs and FEs.
  1. ——————————-

| NE |

       |        -------------         |
       |        |    CE     |         |
       |        -------------         |
       |          /        \          |
       |         /          \         |
       |        /            \        |
       |       /              \       |
       |  -----------     ----------- |
       |  |   FE    |     |    FE   | |
       |  -----------     ----------- |
       |    | | | |         | | | |   |
       |    | | | |         | | | |   |
       |    | | | |         | | | |   |
       |    | | | |         | | | |   |
       --------------------------------
            | | | |         | | | |
            | | | |         | | | |

4. Architectural Requirements

 The following are the architectural requirements:
 1) CEs and FEs MUST be able to connect by a variety of interconnect
 technologies.  Examples of interconnect technologies used in current
 architectures include Ethernet, bus backplanes, and ATM (cell)
 fabrics.  FEs MAY be connected to each other via a different
 technology than that used for CE/FE communication.

Khosravi & Anderson Informational [Page 5] RFC 3654 ForCES Requirements November 2003

 2) FEs MUST support a minimal set of capabilities necessary for
 establishing network connectivity (e.g., interface discovery, port
 up/down functions).  Beyond this minimal set, the ForCES architecture
 MUST NOT restrict the types or numbers of capabilities that FEs may
 contain.
 3) Packets MUST be able to arrive at the NE by one FE and leave the
 NE via a different FE.
 4) A NE MUST support the appearance of a single functional device.
 For example, in a router, the TTL of the packet should be decremented
 only once as it traverses the NE regardless of how many FEs through
 which it passes.  However, external entities (e.g., FE managers and
 CE managers) MAY have direct access to individual ForCES protocol
 elements for providing information to transition them from the pre-
 association to post-association phase.
 5) The architecture MUST provide a way to prevent unauthorized ForCES
 protocol elements from joining a NE.  (For more protocol details,
 refer to section 6 requirement #2)
 6) A FE MUST be able to asynchronously inform the CE of a failure or
 increase/decrease in available resources or capabilities on the FE.
 Thus, the FE MUST support error monitoring and reporting. (Since
 there is not a strict 1-to-1 mapping between FEs and PFEs, it is
 possible for the relationship between a FE and its physical resources
 to change over time).  For example, the number of physical ports or
 the amount of memory allocated to a FE may vary over time. The CE
 needs to be informed of such changes so that it can control the FE in
 an accurate way.
 7) The architecture MUST support mechanisms for CE redundancy or CE
 failover.  This includes the ability for CEs and FEs to determine
 when there is a loss of association between them, ability to restore
 association and efficient state (re)synchronization mechanisms.  This
 also includes the ability to preset the actions an FE will take in
 reaction to loss of association to its CE e.g., whether the FE will
 continue to forward packets or whether it will halt operations.
 8) FEs MUST be able to redirect control packets (such as RIP, OSPF
 messages) addressed to their interfaces to the CE.  They MUST also
 redirect other relevant packets (e.g., such as those with Router
 Alert Option set) to their CE.  The CEs MUST be able to configure the
 packet redirection information/filters on the FEs.  The CEs MUST also
 be able to create packets and have its FEs deliver them.

Khosravi & Anderson Informational [Page 6] RFC 3654 ForCES Requirements November 2003

 9) Any proposed ForCES architectures MUST explain how that
 architecture supports all of the router functions as defined in
 [RFC1812].  IPv4 Forwarding functions such IP header validation,
 performing longest prefix match algorithm, TTL decrement, Checksum
 calculation, generation of ICMP error messages, etc defined in RFC
 1812 should be explained.
 10) In a ForCES NE, the CE(s) MUST be able to learn the topology by
 which the FEs in the NE are connected.
 11) The ForCES NE architecture MUST be capable of supporting (i.e.,
 must scale to) at least hundreds of FEs and tens of thousands of
 ports.
 12) The ForCES architecture MUST allow FEs AND CEs to join and leave
 NEs dynamically.
 13) The ForCES NE architecture MUST support multiple CEs and FEs.
 However, coordination between CEs is out of scope of ForCES.
 14) For pre-association phase setup, monitoring, configuration
 issues, it MAY be useful to use standard management mechanisms for
 CEs and FEs.  The ForCES architecture and requirements do not
 preclude this.  In general, for post-association phase, most
 management tasks SHOULD be done through interaction with the CE.  In
 certain conditions (e.g., CE/FE disconnection), it may be useful to
 allow management tools (e.g., SNMP) to be used to diagnose and repair
 problems.  The following guidelines MUST be observed:
 1. The ability for a management tool (e.g., SNMP) to be used to read
    (but not change) the state of FE SHOULD NOT be precluded.
 2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to
    change the state of a FE in a manner that affects overall NE
    behavior without the CE being notified.

5. FE Model Requirements

 The variety of FE functionality that the ForCES architecture allows
 poses a potential problem for CEs.  In order for a CE to effectively
 control a FE, the CE must understand how the FE processes packets. We
 therefore REQUIRE that a FE model be created that can express the
 logical packet processing capabilities of a FE.  This model will be
 used in the ForCES protocol to describe FE capabilities (see Section
 6, requirement #1).  The FE model MUST define both a capability model
 and a state model, which expresses the current configuration of the
 device.  The FE model MUST also support multiple FEs in the NE
 architecture.

Khosravi & Anderson Informational [Page 7] RFC 3654 ForCES Requirements November 2003

5.1. Types of Logical Functions

 The FE model MUST express what logical functions can be applied to
 packets as they pass through a FE. Logical functions are the packet
 processing functions that are applied to the packets as they are
 forwarded through a FE.  Examples of logical functions are layer 3
 forwarding, firewall, NAT, and shaping. Section 5.5 defines the
 minimal set of logical functions that the FE Model MUST support.

5.2. Variations of Logical Functions

 The FE model MUST be capable of supporting/allowing variations in the
 way logical functions are implemented on a FE.  For example, on a
 certain FE the forwarding logical function might have information
 about both the next hop IP address and the next hop MAC address,
 while on another FE these might be implemented as separate logical
 functions.  Another example would be NAT functionality that can have
 several flavors such as Traditional/Outbound NAT, Bi-directional NAT,
 Twice NAT,  and Multihomed NAT [RFC2663].  The model must be flexible
 enough to allow such variations in functions.

5.3. Ordering of Logical Functions

 The model MUST be capable of describing the order in which these
 logical functions are applied in a FE.  The ordering of logical
 functions is important in many cases.  For example, a NAT function
 may change a packet's source or destination IP address.  Any number
 of other logical functions (e.g., layer 3 forwarding, ingress/egress
 firewall, shaping, and accounting) may make use of the source or
 destination IP address when making decisions.  The CE needs to know
 whether to configure these logical functions with the pre-NAT or
 post-NAT IP address.  Furthermore, the model MUST be capable of
 expressing multiple instances of the same logical function in a FE's
 processing path.  Using NAT again as an example, one NAT function is
 typically performed before the forwarding decision (packets arriving
 externally have their public addresses replaced with private
 addresses) and one NAT function is performed after the forwarding
 decision (for packets exiting the domain, their private addresses are
 replaced by public ones).

5.4. Flexibility

 Finally, the FE model SHOULD provide a flexible infrastructure in
 which new logical functions and new classification, action, and
 parameterization data can be easily added.  In addition, the FE model
 MUST be capable of describing the types of statistics gathered by
 each logical function.

Khosravi & Anderson Informational [Page 8] RFC 3654 ForCES Requirements November 2003

5.5. Minimal Set of Logical Functions

 The rest of this section defines a minimal set of logical functions
 that any FE model MUST support.  This minimal set DOES NOT imply that
 all FEs must provide this functionality.  Instead, these requirements
 only specify that the model must be capable of expressing the
 capabilities that FEs may choose to provide.
 1) Port Functions
 The FE model MUST be capable of expressing the number of ports on the
 device, the static attributes of each port (e.g., port type, link
 speed), and the configurable attributes of each port (e.g., IP
 address, administrative status).
 2) Forwarding Functions
 The FE model MUST be capable of expressing the data that can be used
 by the forwarding function to make a forwarding decision.  Support
 for IPv4 and IPv6 unicast and multicast forwarding functions MUST be
 provided by the model.
 3) QoS Functions
 The FE model MUST allow a FE to express its QoS capabilities in terms
 of, e.g., metering, policing, shaping, and queuing functions. The FE
 model MUST be capable of expressing the use of these functions to
 provide IntServ or DiffServ functionality as described in [RFC2211],
 [RFC2212], [RFC2215], [RFC2475], and [RFC3290].
 4) Generic Filtering Functions
 The FE model MUST be capable of expressing complex sets of filtering
 functions.  The model MUST be able to express the existence of these
 functions at arbitrary points in the sequence of a FE's packet
 processing functions.  The FE model MUST be capable of expressing a
 wide range of classification abilities from single fields (e.g.,
 destination address) to arbitrary n-tuples.  Similarly, the FE model
 MUST be capable of expressing what actions these filtering functions
 can perform on packets that the classifier matches.
 5) Vendor-Specific Functions
 The FE model SHOULD be extensible so that new, currently unknown FE
 functionality can be expressed.  The FE Model SHOULD NOT be extended
 to express standard/common functions in a proprietary manner.  This
 would NOT be ForCES compliant.
 6) High-Touch Functions
 The FE model MUST be capable of expressing the encapsulation and
 tunneling capabilities of a FE.  The FE model MUST support functions

Khosravi & Anderson Informational [Page 9] RFC 3654 ForCES Requirements November 2003

 that mark the class of service that a packet should receive (i.e.,
 IPv4 header TOS octet or the IPv6 Traffic Class octet).  The FE model
 MAY support other high touch functions (e.g., NAT, ALG).
 7) Security Functions
 The FE model MUST be capable of expressing the types of encryption
 that may be applied to packets in the forwarding path.
 8) Off-loaded Functions
 Per-packet processing can leave state in the FE, so that logical
 functions executed during packet processing can perform in a
 consistent manner (for instance, each packet may update the state of
 the token bucket occupancy of a give policer).  In addition, the FE
 Model MUST allow logical functions to execute asynchronously from
 packet processing, according to a certain finite-state machine, in
 order to perform functions that are, for instance, off-loaded from
 the CE to the FE.  The FE model MUST be capable of expressing these
 asynchronous functions.  Examples of such functions include the
 finite-state machine execution required by TCP termination or OSPF
 Hello processing, triggered not only by packet events, but by timer
 events as well.  This Does NOT mean off-loading of any piece of code
 to an FE, just that the FE Model should be able to express existing
 Off-loaded functions on an FE.
 9) IPFLOW/PSAMP Functions
 Several applications such as, Usage-based Accounting, Traffic
 engineering, require flow-based IP traffic measurements from Network
 Elements. [IPFLOW] defines architecture for IP traffic flow
 monitoring, measuring and exporting.  The FE model SHOULD be able to
 express metering functions and flow accounting needed for exporting
 IP traffic flow information.  Similarly to support measurement-based
 applications, [PSAMP] describes a framework to define a standard set
 of capabilities for network elements to sample subsets of packets by
 statistical and other methods.  The FE model SHOULD be able to
 express statistical packet filtering functions and packet information
 needed for supporting packet sampling applications.

6. ForCES Protocol Requirements

 This section specifies some of the requirements that the ForCES
 protocol MUST meet.
 1) Configuration of Modeled Elements
 The ForCES protocol MUST allow the CEs to determine the capabilities
 of each FE.  These capabilities SHALL be expressed using the FE model
 whose requirements are defined in Section 5.  Furthermore, the
 protocol MUST provide a means for the CEs to control all the FE

Khosravi & Anderson Informational [Page 10] RFC 3654 ForCES Requirements November 2003

 capabilities that are discovered through the FE model.  The protocol
 MUST be able to add/remove classification/action entries, set/delete
 parameters, query statistics, and register for and receive events.
 2) Support for Secure Communication
    a) FE configuration will contain information critical to the
       functioning of a network (e.g., IP Forwarding Tables).  As
       such, it MUST be possible to ensure the integrity of all ForCES
       protocol messages and protect against man-in-the-middle
       attacks.
    b) FE configuration information may also contain information
       derived from business relationships (e.g., service level
       agreements).  Because of the confidential nature of the
       information, it MUST be possible to secure (make private) all
       ForCES protocol messages.
    c) In order to ensure that authorized CEs and FEs are
       participating in a NE and defend against CE or FE impersonation
       attacks, the ForCES architecture MUST select a means of
       authentication for CEs and FEs.
    d) In some deployments ForCES is expected to be deployed between
       CEs and FEs connected to each other inside a box over a
       backplane, where physical security of the box ensures that
       man-in-the-middle, snooping, and impersonation attacks are not
       possible.  In such scenarios the ForCES architecture MAY rely
       on the physical security of the box to defend against these
       attacks and protocol mechanisms May be turned off.
    e) In the case when CEs and FEs are connected over a network,
       security mechanisms MUST be specified or selected that protect
       the ForCES protocol against such attacks.  Any security
       solution used for ForCES MUST specify how it deals with such
       attacks.
 3) Scalability
 The ForCES protocol MUST be capable of supporting (i.e., must scale
 to) at least hundreds of FEs and tens of thousands of ports.  For
 example, the ForCES protocol field sizes corresponding to FE or port
 numbers SHALL be large enough to support the minimum required
 numbers.  This requirement does not relate to the performance of a NE
 as the number of FEs or ports in the NE grows.
 4) Multihop
 When the CEs and FEs are separated beyond a single L3 routing hop,
 the ForCES protocol will make use of an existing RFC2914 compliant L4
 protocol with adequate reliability, security and congestion control
 (e.g., TCP, SCTP) for transport purposes.

Khosravi & Anderson Informational [Page 11] RFC 3654 ForCES Requirements November 2003

 5) Message Priority
 The ForCES protocol MUST provide a means to express the protocol
 message priorities.
 6) Reliability
    a) The ForCES protocol will be used to transport information that
       requires varying levels of reliability.  By strict or robust
       reliability in this requirement we mean, no losses, no
       corruption, no re-ordering of information being transported and
       delivery in a timely fashion.
    b) Some information or payloads, such as redirected packets or
       packet sampling, may not require robust reliability (can
       tolerate some degree of losses).  For information of this sort,
       ForCES MUST NOT be restricted to strict reliability.
    c) Payloads such as configuration information, e.g., ACLs, FIB
       entries, or FE capability information (described in section 6,
       (1)) are mission critical and must be delivered in a robust
       reliable fashion.  Thus, for information of this sort, ForCES
       MUST either provide built-in protocol mechanisms or use a
       reliable transport protocol for achieving robust/strict
       reliability.
    d) Some information or payloads, such as heartbeat packets that
       may be used to detect loss of association between CE and FEs
       (see section 6, (8)), may prefer timeliness over reliable
       delivery.  For information of this sort, ForCES MUST NOT be
       restricted to strict reliability.
    e) When ForCES is carried over multi-hop IP networks, it is a
       requirement that ForCES MUST use a [RFC2914]-compliant
       transport protocol.
    f) In cases where ForCES is not running over an IP network such as
       an Ethernet or cell fabric between CE and FE, then reliability
       still MUST be provided when carrying critical information of
       the types specified in (c) above, either by the underlying
       link/network/transport layers or by built-in protocol
       mechanisms.
 7) Interconnect Independence
 The ForCES protocol MUST support a variety of interconnect
 technologies. (refer to section 4, requirement #1)
 8) CE redundancy or CE failover
 The ForCES protocol MUST support mechanisms for CE redundancy or CE
 failover.  This includes the ability for CEs and FEs to determine
 when there is a loss of association between them, ability to restore
 association and efficient state (re)synchronization mechanisms.  This
 also includes the ability to preset the actions an FE will take in

Khosravi & Anderson Informational [Page 12] RFC 3654 ForCES Requirements November 2003

 reaction to loss of association to its CE, e.g., whether the FE will
 continue to forward packets or whether it will halt operations.
 (refer to section 4, requirement #7)
 9) Packet Redirection/Mirroring
    a) The ForCES protocol MUST define a way to redirect packets from
       the FE to the CE and vice-versa.  Packet redirection terminates
       any further processing of the redirected packet at the FE.
    b) The ForCES protocol MUST define a way to mirror packets from
       the FE to the CE.  Mirroring allows the packet duplicated by
       the FE at the mirroring point to be sent to the CE while the
       original packet continues to be processed by the FE.
 Examples of packets that may be redirected or mirrored include
 control packets (such as RIP, OSPF messages) addressed to the
 interfaces or any other relevant packets (such as those with Router
 Alert Option set).  The ForCES protocol MUST also define a way for
 the CE to configure the behavior of a) and b) (above), to specify
 which packets are affected by each.
 10) Topology Exchange
 The ForCES protocol or information carried in the ForCES protocol
 MUST allow those FEs which have inter-FE topology information to
 provide that information to the CE(s).
 11) Dynamic Association
 The ForCES protocol MUST allow CEs and FEs to join and leave a NE
 dynamically. (refer to section 4, requirement #12)
 12) Command Bundling
 The ForCES protocol MUST be able to group an ordered set of commands
 to a FE.  Each such group of commands SHOULD be sent to the FE in as
 few messages as possible.  Furthermore, the protocol MUST support the
 ability to specify if a command group MUST have all-or-nothing
 semantics.
 13) Asynchronous Event Notification
 The ForCES protocol MUST be able to asynchronously notify the CE of
 events on the FE such as failures or change in available resources or
 capabilities. (refer to section 4, requirement #6)
 14) Query Statistics
 The ForCES protocol MUST provide a means for the CE to be able to
 query statistics (monitor performance) from the FE.

Khosravi & Anderson Informational [Page 13] RFC 3654 ForCES Requirements November 2003

 15) Protection against Denial of Service Attacks (based on CPU
 overload or queue overflow)
 Systems utilizing the ForCES protocol can be attacked using denial of
 service attacks based on CPU overload or queue overflow. The ForCES
 protocol could be exploited by such attacks to cause the CE to become
 unable to control the FE or appropriately communicate with other
 routers and systems.  The ForCES protocol MUST therefore provide
 mechanisms for controlling FE capabilities that can be used to
 protect against such attacks.  FE capabilities that MUST be
 manipulated via ForCES include the ability to install classifiers and
 filters to detect and drop attack packets, as well as to be able to
 install rate limiters that limit the rate of packets which appear to
 be valid but may be part of an attack (e.g., bogus BGP packets).

7. References

7.1. Normative References

 [RFC3290]  Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An
            Informal Management Model for DiffServ Routers", RFC 3290,
            May 2002.
 [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
            1812, June 1995.
 [RFC2211]  Wroclawski, J., "Specification of the Controlled-Load
            Network Element Service", RFC 2211, September 1997.
 [RFC2212]  Shenker, S., Partridge, C. and R. Guerin, "Specification
            of Guaranteed Quality of Service", RFC 2212, September
            1997.
 [RFC2215]  Shenker, S. and J. Wroclawski, "General Characterization
            Parameters for Integrated Service Network Elements", RFC
            2215, September 1997.
 [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
            and W. Weisss, "An Architecture for Differentiated
            Service", RFC 2475, December 1998.
 [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 14, RFC
            2914, September 2000.
 [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
            Translator (NAT) Terminology and Considerations", RFC
            2663, August 1999.

Khosravi & Anderson Informational [Page 14] RFC 3654 ForCES Requirements November 2003

7.2. Informative References

 [RFC3532]  Anderson, T. and J. Buerkle, "Requirements for the Dynamic
            Partitioning of Switching Elements", RFC 3532, May 2003.
 [IPFLOW]   Quittek, et al., "Requirements for IP Flow Information
            Export", Work in Progress, February 2003.
 [PSAMP]    Duffield, et al., "A Framework for Passive Packet
            Measurement ", Work in Progress, March 2003.

8. Security Considerations

 See architecture requirement #5 and protocol requirement #2.

9. Authors' Addresses & Acknowledgments

 This document was written by the ForCES Requirements design team:
 Todd A. Anderson (Editor)
 Ed Bowen
 IBM Zurich Research Laboratory
 Saumerstrasse 4
 CH-8803 Rueschlikon Switzerland
 Phone: +41 1 724 83 68
 EMail: edbowen@us.ibm.com
 Ram Dantu
 Department of Computer Science
 University of North Texas,
 Denton, Texas, 76203
 Phone: 940 565 2822
 EMail: rdantu@unt.edu
 Avri Doria
 ETRI
 161 Gajeong-dong, Yuseong-gu
 Deajeon 305-350 Korea
 EMail: avri@acm.org

Khosravi & Anderson Informational [Page 15] RFC 3654 ForCES Requirements November 2003

 Ram Gopal
 Nokia Research Center
 5, Wayside Road,
 Burlington, MA 01803
 Phone: 1-781-993-3685
 EMail: ram.gopal@nokia.com
 Jamal Hadi Salim
 Znyx Networks
 Ottawa, Ontario
 Canada
 EMail: hadi@znyx.com
 Hormuzd Khosravi (Editor)
 Muneyb Minhazuddin
 Avaya Inc.
 123, Epping road,
 North Ryde, NSW 2113, Australia
 Phone: +61 2 9352 8620
 EMail: muneyb@avaya.com
 Margaret Wasserman
 Nokia Research Center
 5 Wayside Road
 Burlington, MA 01803
 Phone: +1 781 993 3858
 EMail: margaret.wasserman@nokia.com
 The authors would like to thank Vip Sharma and Lily Yang for their
 valuable contributions.

Khosravi & Anderson Informational [Page 16] RFC 3654 ForCES Requirements November 2003

10. Editors' Contact Information

 Hormuzd Khosravi
 Intel
 2111 NE 25th Avenue
 Hillsboro, OR 97124 USA
 Phone: +1 503 264 0334
 EMail: hormuzd.m.khosravi@intel.com
 Todd A. Anderson
 Intel
 2111 NE 25th Avenue
 Hillsboro, OR 97124 USA
 Phone: +1 503 712 1760
 EMail: todd.a.anderson@intel.com

Khosravi & Anderson Informational [Page 17] RFC 3654 ForCES Requirements November 2003

11. Full Copyright Statement

 Copyright (C) The Internet Society (2003).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assignees.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Khosravi & Anderson Informational [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3654.txt · Last modified: 2003/11/25 18:48 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki