draft-ietf-forces-requirements-02.txt   draft-ietf-forces-requirements-03.txt 
Internet Draft T. Anderson Internet Draft T. Anderson
Expiration: August 2002 Intel Expiration: October 2002 Intel
File: draft-ietf-forces-requirements-02.txt E. Bowen File: draft-ietf-forces-requirements-03.txt E. Bowen
Working Group: ForCES IBM Working Group: ForCES IBM
R. Dantu R. Dantu
Netrake Inc. Netrake Inc.
A. Doria A. Doria
LTU LTU
R. Gopal R. Gopal
Nokia Nokia
J. Hadi Salim J. Hadi Salim
Znyx Networks Znyx Networks
H. Khosravi H. Khosravi
Intel Intel
M. Minhazuddin M. Minhazuddin
Avaya Inc. Avaya Inc.
M. Wasserman M. Wasserman
Wind River Wind River
February 2002 April 2002
Requirements for Separation of IP Control and Forwarding Requirements for Separation of IP Control and Forwarding
draft-ietf-forces-requirements-02.txt draft-ietf-forces-requirements-03.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 13 skipping to change at page 2, line 13
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119]. this document are to be interpreted as described in [RFC-2119].
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 networking separate the control and data forwarding planes of an IP (IPv4,
device. IPv6, etc.) networking device.
2. Definitions 2. 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
Ethernet, an AE is a device to which we can communicate using an Ethernet, an AE is a device to which we can communicate using an
Ethernet MAC address; on IP networks, it is a device to which we can Ethernet MAC address; on IP networks, it is a device to which we can
communicate using an IP address; and on a switch fabric, it is a communicate using an IP address; and on a switch fabric, it is a
device to which we can communicate using a switch fabric port device to which we can communicate using a switch fabric port
number. 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,
or general-purpose processors. For example, line cards in a line cards with multiple chips or stand alone box with general-
backplane are PFEs. 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
that of the resources assigned to a virtual router [REQ-PART]. that of the resources assigned to a virtual router [REQ-PART].
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.
skipping to change at page 3, line 16 skipping to change at page 3, line 16
of a general purpose CPU). of a general purpose CPU).
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 whole and signaling protocols. CEs may consist of PCE partitions or whole
PCEs. PCEs.
Pre-association Phase - The period of time during which a FE Manager Pre-association Phase - The period of time during which a FE Manager
(see below) and a CE Manager (see below) are determining which FE (see below) and a CE Manager (see below) are determining which FE
and CE should be part of the same network element. 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 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 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 post- ForCES Post-Association Phase Protocol - The protocol used for post-
association phase communication between CEs and FEs. This protocol association phase communication between CEs and FEs. This protocol
does not apply to CE-to-CE communication, FE-to-FE communication, or does not apply to CE-to-CE communication, FE-to-FE communication, or
to communication between FE and CE managers. The ForCES protocol is to communication between FE and CE managers. The ForCES protocol is
a master-slave protocol in which FEs are slaves and CEs are masters. a master-slave protocol in which FEs are slaves and CEs are masters.
This protocol includes both the management of the communication This protocol includes both the management of the communication
channel (e.g., connection establishment, heartbeats) and the control channel (e.g., connection establishment, heartbeats) and the control
messages themselves. 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 FE Model - A model that describes the logical processing functions
of a FE. of a FE.
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) a FE should phase and is responsible for determining to which CE(s) a FE should
communicate. This process is called CE discovery and may involve communicate. This process is called CE discovery and may involve
the FE manager learning the capabilities of available CEs. A FE the FE manager learning the capabilities of available CEs. A FE
manager may use anything from a static configuration to a pre- manager may use anything from a static configuration to a pre-
association phase protocol (see below) to determine which CE(s) to association phase protocol (see below) to determine which CE(s) to
skipping to change at page 7, line 18 skipping to change at page 7, line 18
6) A FE MUST be able to asynchronously inform the CE of an 6) A FE MUST be able to asynchronously inform the CE of an
increase/decrease in available resources or capabilities on the FE. increase/decrease in available resources or capabilities on the FE.
(Since there is not a strict 1-to-1 mapping between FEs and PFEs, it (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 is possible for the relationship between a FE and its physical
resources to change over time). For example, the number of 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. 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 CE needs to be informed of such changes so that it can control
the FE in an accurate way. the FE in an accurate way.
7) The architecture MUST support mechanisms for high availability. 7) The architecture MUST support mechanisms for CE redundancy or CE
This includes the ability for CEs and FEs to determine when there is failover. This includes the ability for CEs and FEs to determine
a loss of association between them, ability to restore association when there is a loss of association between them, ability to restore
and efficient state (re)synchronization mechanisms. High association and efficient state (re)synchronization mechanisms. This
Availability also includes the ability to preset the actions an FE also includes the ability to preset the actions an FE will take in
will take in reaction to loss of association to its CE e.g., whether reaction to loss of association to its CE e.g., whether the FE will
the FE will continue to forward packets or whether it will halt continue to forward packets or whether it will halt operations.
operations.
8) FEs MUST redirect packets addressed to their interfaces to their 8) FEs MUST be able to redirect control packets (such as RIP, OSPF
CE for further processing. Furthermore, FEs MUST redirect other messages) addressed to their interfaces to the CE. They MUST also
required packets (e.g., such as those with the router alert option redirect other relevant packets (e.g., such as those with Router
set) to their CE as well. (FEs MAY provide any other Alert Option set) to their CE. The CEs MUST be able to configure the
classification/redirection capabilities that they desire as packet redirection information/filters on the FEs. The CEs MUST also
described in Section 6.5 requirement #4.) Similarly, CEs MUST be be able to create packets and have its FEs deliver them.
able to create packets and have its FEs deliver them.
9) Any proposed ForCES architectures MUST explain how that 9) Any proposed ForCES architectures MUST explain how that
architecture supports all of the router functions as defined in architecture supports all of the router functions as defined in
[RFC1812]. [RFC1812].
10) In a ForCES NE, the FEs MUST be able to provide their topology 10) In a ForCES NE, the FEs MUST be able 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). the CE(s).
11) The ForCES NE architecture MUST be capable of supporting (i.e., 11) The ForCES NE architecture MUST be capable of supporting (i.e.,
skipping to change at page 8, line 24 skipping to change at page 8, line 22
behavior without the CE being notified. behavior without the CE being notified.
6. FE Model Requirements 6. FE Model Requirements
The variety of FE functionality that the ForCES architecture allows The variety of FE functionality that the ForCES architecture allows
poses a potential problem for CEs. In order for a CE to effectively 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. 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 We therefore REQUIRE that a FE model be created that can express the
logical packet processing capabilities of a FE. This model will be logical packet processing capabilities of a FE. This model will be
used in the ForCES protocol to describe FE capabilities (see Section used in the ForCES protocol to describe FE capabilities (see Section
7, requirement #1). 7, requirement #1). The FE model MUST also support multiple FEs in
the NE architecture.
6.1. Types of Logical Functions 6.1. Types of Logical Functions
The FE model MUST express what logical functions can be applied to The FE model MUST express what logical functions can be applied to
packets as they pass through a FE. packets as they pass through a FE.
Logical functions are the packet processing functions that are Logical functions are the packet processing functions that are
applied to the packets as they are forwarded through a FE. Examples applied to the packets as they are forwarded through a FE. Examples
of logical functions are layer 3 forwarding, firewall, NAT, shaping. of logical functions are layer 3 forwarding, firewall, NAT, shaping.
Section 6.5 defines the minimal set of logical functions that the FE Section 6.5 defines the minimal set of logical functions that the FE
Model MUST support. Model MUST support.
skipping to change at page 10, line 17 skipping to change at page 10, line 16
MUST be capable of expressing what actions these filtering functions MUST be capable of expressing what actions these filtering functions
can perform on packets that the classifier matches. can perform on packets that the classifier matches.
5)Vendor-Specific Functions 5)Vendor-Specific Functions
The FE model SHOULD be extensible so that vendor-specific FE The FE model SHOULD be extensible so that vendor-specific FE
functionality can be expressed. functionality can be expressed.
6)High-Touch Functions 6)High-Touch Functions
The FE model MUST be capable of expressing the encapsulation and The FE model MUST be capable of expressing the encapsulation and
tunneling capabilities of a FE. The FE model MUST support functions tunneling capabilities of a FE. The FE model MUST support functions
that mark the IPv4 header TOS octet or the IPv6 Traffic Class octet. that mark the class of service that a packet should receive (i.e.
The FE model MAY support other high touch functions (e.g., NAT, IPv4 header TOS octet or the IPv6 Traffic Class octet). The FE
ALG). model MAY support other high touch functions (e.g., NAT, ALG).
7)Security Functions 7)Security Functions
The FE model MUST be capable of expressing the types of encryption The FE model MUST be capable of expressing the types of encryption
that may be applied to packets in the forwarding path. that may be applied to packets in the forwarding path.
7. ForCES Protocol Requirements 7. ForCES Protocol Requirements
This section specifies some of the requirements that the ForCES This section specifies some of the requirements that the ForCES
protocol MUST meet. protocol MUST meet.
skipping to change at page 11, line 37 skipping to change at page 11, line 37
defined so long as they provide a datagram service to the ForCES defined so long as they provide a datagram service to the ForCES
protocol. However, since some messages will need to be reliably protocol. However, since some messages will need to be reliably
delivered to FEs, the ForCES protocol MUST provide internal support delivered to FEs, the ForCES protocol MUST provide internal support
for reliability mechanisms such as message acknowledgements and/or for reliability mechanisms such as message acknowledgements and/or
state change confirmations. state change confirmations.
7)Interconnect Independence 7)Interconnect Independence
The ForCES protocol MUST support a variety of interconnect The ForCES protocol MUST support a variety of interconnect
technologies. (refer to section 5, requirement# 1) technologies. (refer to section 5, requirement# 1)
8)High Availability 8)CE redundancy or CE failover
The ForCES protocol MUST support mechanisms for high availability. The ForCES protocol MUST support mechanisms for CE redundancy or CE
This includes the ability for CEs and FEs to determine when there is failover. This includes the ability for CEs and FEs to determine
a loss of association between them, ability to restore association when there is a loss of association between them, ability to restore
and efficient state (re)synchronization mechanisms. High association and efficient state (re)synchronization mechanisms. This
Availability also includes the ability to preset the actions an FE also includes the ability to preset the actions an FE will take in
will take in reaction to loss of association to its CE e.g., whether reaction to loss of association to its CE e.g., whether the FE will
the FE will continue to forward packets or whether it will halt continue to forward packets or whether it will halt operations.
operations. (refer to section 5, requirement# 7) (refer to section 5, requirement# 7)
9)Packet Redirection 9)Packet Redirection
The ForCES protocol MUST support the redirection of packets from FEs FEs MUST be able to redirect control packets (such as RIP, OSPF
to their CEs. It MUST also support CEs to send packets to FEs for messages) addressed to their interfaces to the CE. They MUST also
delivery.(refer to section 5, requirement# 8) 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. (refer to
section 5, requirement# 8)
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)
skipping to change at page 12, line 24 skipping to change at page 12, line 28
to a FE. Each such group of commands SHOULD be sent to the FE in as 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 few messages as possible. Furthermore, the protocol MUST support the
ability to specify if a command group MUST have all-or-nothing ability to specify if a command group MUST have all-or-nothing
semantics. semantics.
13)Asynchronous Event Notification 13)Asynchronous Event Notification
The ForCES protocol MUST be able to asynchronously notify the CE of The ForCES protocol MUST be able to asynchronously notify the CE of
events on the FE such as change in available resources or events on the FE such as change in available resources or
capabilities. (refer to section 5, requirement# 6) capabilities. (refer to section 5, 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.
8. Security Considerations 8. Security Considerations
See architecture requirement #5 and protocol requirement #2. See architecture requirement #5 and protocol requirement #2.
9. Normative References 9. Normative References
[DS-MODEL] Y. Bernet, et. al., "An Informal Management Model for [DS-MODEL] Y. Bernet, et. al., "An Informal Management Model for
DiffServ Routers", work in progress, September 2001, <draft-ietf- DiffServ Routers", work in progress, September 2001, <draft-ietf-
diffserv-model-06.txt>. diffserv-model-06.txt>.
[RFC1812] F. Baker, "Requirements for IP Version 4 Routers", [RFC1812] F. Baker, "Requirements for IP Version 4 Routers",
RFC1812, June 1995. RFC1812, June 1995.
[RFC2211] J. Wroclawski, "Specification of the Controlled-Load [RFC2211] J. Wroclawski, "Specification of the Controlled-Load
Network Element Service", RFC2211, September 1997. Network Element Service", RFC2211, September 1997.
[RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of [RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of
Guaranteed Quality of Service", RFC2212, September 1997. Guaranteed Quality of Service", RFC2212, September 1997.
[RFC2212] S. Shenker, J. Wroclawski, "General Characterization [RFC2215] S. Shenker, J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC2215, Parameters for Integrated Service Network Elements", RFC2215,
September 1997. September 1997.
[RFC2475] S. Blake, et. Al., "An Architecture for Differentiated [RFC2475] S. Blake, et. Al., "An Architecture for Differentiated
Service", RFC2475, December 1998. Service", RFC2475, December 1998.
[RFC2914] S. Floyd, "Congestion Control Principles", RFC2914, [RFC2914] S. Floyd, "Congestion Control Principles", RFC2914,
September 2000. September 2000.
[RFC2663] P. Srisuresh & M. Holdrege, "IP Network Address [RFC2663] P. Srisuresh & M. Holdrege, "IP Network Address
 End of changes. 

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