draft-ietf-forces-requirements-07.txt   draft-ietf-forces-requirements-08.txt 
Internet Draft H. Khosravi, Internet Draft H. Khosravi,
Expiration: April 2003 T. Anderson (Editors) Expiration: July 2003 T. Anderson (Editors)
File: draft-ietf-forces-requirements-07.txt Intel File: draft-ietf-forces-requirements-08.txt Intel
Working Group: ForCES October 2002 Working Group: ForCES January 2003
Requirements for Separation of IP Control and Forwarding Requirements for Separation of IP Control and Forwarding
draft-ietf-forces-requirements-07.txt draft-ietf-forces-requirements-08.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 its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts. also 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 6 skipping to change at page 2, line 6
1. Abstract 1. Abstract
This document introduces the ForCES architecture and defines a set This document introduces the ForCES architecture and defines a set
of associated terminology. This document also defines a set of of associated terminology. This document also defines a set of
architectural, modeling, and protocol requirements to logically architectural, modeling, and protocol requirements to logically
separate the control and data forwarding planes of an IP (IPv4, separate the control and data forwarding planes of an IP (IPv4,
IPv6, etc.) networking device. IPv6, etc.) networking device.
1. Abstract........................................................1 1. Abstract........................................................1
2. Definitions.....................................................2 2. Introduction....................................................2
3. Introduction....................................................4 3. Definitions.....................................................3
4. Architecture....................................................5 4. Architecture....................................................5
5. Architectural Requirements......................................6 5. Architectural Requirements......................................6
6. FE Model Requirements...........................................8 6. FE Model Requirements...........................................8
6.1. Types of Logical Functions......................................8 6.1. Types of Logical Functions......................................8
6.2. Variations of Logical Functions.................................8 6.2. Variations of Logical Functions.................................8
6.3. Ordering of Logical Functions...................................8 6.3. Ordering of Logical Functions...................................8
6.4. Flexibility.....................................................9 6.4. Flexibility.....................................................9
6.5. Minimal Set of Logical Functions................................9 6.5. Minimal Set of Logical Functions................................9
7. ForCES Protocol Requirements...................................10 7. ForCES Protocol Requirements...................................10
8. References.....................................................13 8. References.....................................................13
8.1. Normative References...........................................13 8.1. Normative References...........................................13
8.2. Informative References.........................................13 8.2. Informative References.........................................13
9. Security Considerations........................................13 9. Security Considerations........................................13
10. Authors' Addresses & Acknowledgments..........................13 10. Authors' Addresses & Acknowledgments..........................14
11. Editors' Contact Information..................................15 11. Editors' Contact Information..................................15
2. Definitions 2. 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.
3. Definitions
Addressable Entity (AE) - A physical device that is directly Addressable Entity (AE) - A physical device that is directly
addressable given some interconnect technology. For example, on addressable given some interconnect technology. For example, on IP
Ethernet, an AE is a device to which we can communicate using an networks, it is a device to which we can communicate using an IP
Ethernet MAC address; on IP networks, it is a device to which we can address; and on a switch fabric, it is a device to which we can
communicate using an IP address; and on a switch fabric, it is a communicate using a switch fabric port number.
device to which we can communicate using a switch fabric port
number.
Physical Forwarding Element (PFE) - An AE that includes hardware Physical Forwarding Element (PFE) - An AE that includes hardware
used to provide per-packet processing and handling. This hardware used to provide per-packet processing and handling. This hardware
may consist of (but is not limited to) network processors, ASIC's, may consist of (but is not limited to) network processors, ASIC's,
line cards with multiple chips or stand alone box with general- line cards with multiple chips or stand alone box with general-
purpose processors. purpose processors.
PFE Partition - A logical partition of a PFE consisting of some PFE Partition - A logical partition of a PFE consisting of some
subset of each of the resources (e.g., ports, memory, forwarding subset of each of the resources (e.g., ports, memory, forwarding
table entries) available on the PFE. This concept is analogous to table entries) available on the PFE. This concept is analogous to
skipping to change at page 4, line 42 skipping to change at page 5, line 24
internal organization from external entities. internal organization from external entities.
ForCES Protocol Element - A FE or CE. ForCES Protocol Element - A FE or CE.
High Touch Capability - This term will be used to apply to the High Touch Capability - This term will be used to apply to the
capabilities found in some forwarders to take action on the contents 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 or headers of a packet based on content other than what is found in
the IP header. Examples of these capabilities include NAT-PT, the IP header. Examples of these capabilities include NAT-PT,
firewall, and L7 content recognition. firewall, and L7 content recognition.
3. 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.
4. Architecture 4. Architecture
The chief components of a NE architecture are the CE, the FE, and The chief components of a NE architecture are the CE, the FE, and
the interconnect protocol. The CE is responsible for operations the interconnect protocol. The CE is responsible for operations
such as signaling and control protocol processing and the such as signaling and control protocol processing and the
implementation of management protocols. Based on the information implementation of management protocols. Based on the information
acquired through control processing, the CE(s) dictates the packet- acquired through control processing, the CE(s) dictates the packet-
forwarding behavior of the FE(s) via the interconnect protocol. For forwarding behavior of the FE(s) via the interconnect protocol. For
example, the CE might control a FE by manipulating its forwarding example, the CE might control a FE by manipulating its forwarding
tables, the state of its interfaces, or by adding or removing a NAT tables, the state of its interfaces, or by adding or removing a NAT
skipping to change at page 11, line 23 skipping to change at page 11, line 21
a) FE configuration will contain information critical to the a) FE configuration will contain information critical to the
functioning of a network (e.g. IP Forwarding Tables). As such, it functioning of a network (e.g. IP Forwarding Tables). As such, it
MUST be possible to ensure the authenticity and integrity of MUST be possible to ensure the authenticity and integrity of
ForCES protocol messages. ForCES protocol messages.
b) FE configuration information may also contain information derived b) FE configuration information may also contain information derived
from business relationships (e.g. service level agreements). from business relationships (e.g. service level agreements).
Therefore, it MUST be possible to secure (make private) ForCES Therefore, it MUST be possible to secure (make private) ForCES
protocol messages. protocol messages.
c) In order to provide authentication, integrity and privacy for a c) In order to provide authentication, integrity and privacy for a
proposed ForCES protocol, existing security mechanisms such as proposed ForCES protocol, existing security mechanisms such as
IPSec/IKE, TLS, etc. MUST be used/leveraged if applicable. IPSec/IKE, TLS (if transport is reliable), etc. MUST be
used/leveraged if applicable.
3)Scalability 3)Scalability
The ForCES protocol MUST be capable of supporting (i.e., must scale 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 to) at least hundreds of FEs and tens of thousands of ports. For
example, the ForCES protocol field sizes corresponding to FE or port example, the ForCES protocol field sizes corresponding to FE or port
numbers SHALL be large enough to support the minimum required numbers SHALL be large enough to support the minimum required
numbers. This requirement does not relate to the performance of a numbers. This requirement does not relate to the performance of a
NE as the number of FEs or ports in the NE grows. NE as the number of FEs or ports in the NE grows.
4)Multihop 4)Multihop
skipping to change at page 12, line 26 skipping to change at page 12, line 26
8)CE redundancy or CE failover 8)CE redundancy or CE failover
The ForCES protocol MUST support mechanisms for CE redundancy or CE The ForCES protocol MUST support mechanisms for CE redundancy or CE
failover. This includes the ability for CEs and FEs to determine failover. This includes the ability for CEs and FEs to determine
when there is a loss of association between them, ability to restore when there is a loss of association between them, ability to restore
association and efficient state (re)synchronization mechanisms. This association and efficient state (re)synchronization mechanisms. This
also includes the ability to preset the actions an FE will take in 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 reaction to loss of association to its CE e.g., whether the FE will
continue to forward packets or whether it will halt operations. continue to forward packets or whether it will halt operations.
(refer to section 5, requirement# 7) (refer to section 5, requirement# 7)
9)Packet Redirection 9)Packet Redirection/Mirroring
The ForCES protocol MUST define a way for FEs to be able to redirect a) The ForCES protocol MUST define a way to redirect packets from the
control packets (such as RIP, OSPF messages) addressed to their FE to the CE and vice-versa. Packet redirection terminates any
interfaces to the CE and vice-versa. It MUST also allow redirection further processing of the redirected packet at the FE.
of other relevant packets (e.g., such as those with Router Alert b) The ForCES protocol MUST define a way to mirror packets from the
Option set) to the CE. The ForCES protocol MUST also allow CEs to FE to the CE. Mirroring allows the packet duplicated by the FE at
configure the packet redirection information/filters on the FEs. the mirroring point to be sent to the CE while the original packet
(refer to section 5, requirement# 8) 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 10)Topology Exchange
The ForCES protocol MUST allow the FEs to provide their topology The ForCES protocol MUST allow the FEs to provide their topology
information (topology by which the FEs in the NE are connected) to information (topology by which the FEs in the NE are connected) to
the CE(s). (refer to section 5, requirement# 10) the CE(s). (refer to section 5, requirement# 10)
11)Dynamic Association 11)Dynamic Association
The ForCES protocol MUST allow CEs and FEs to join and leave a NE The ForCES protocol MUST allow CEs and FEs to join and leave a NE
dynamically. (refer to section 5, requirement# 12) dynamically. (refer to section 5, requirement# 12)
 End of changes. 

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