draft-ietf-forces-requirements-06.txt   draft-ietf-forces-requirements-07.txt 
Internet Draft H. Khosravi, Internet Draft H. Khosravi,
Expiration: December 2002 T. Anderson (Editors) Expiration: April 2003 T. Anderson (Editors)
File: draft-ietf-forces-requirements-06.txt Intel File: draft-ietf-forces-requirements-07.txt Intel
Working Group: ForCES July 2002 Working Group: ForCES October 2002
Requirements for Separation of IP Control and Forwarding Requirements for Separation of IP Control and Forwarding
draft-ietf-forces-requirements-06.txt draft-ietf-forces-requirements-07.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 5 skipping to change at page 2, line 5
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 (IPv4, separate the control and data forwarding planes of an IP (IPv4,
IPv6, etc.) networking device. IPv6, etc.) networking device.
1. Abstract........................................................1
2. Definitions.....................................................2
3. Introduction....................................................4
4. Architecture....................................................5
5. Architectural Requirements......................................6
6. FE Model Requirements...........................................8
6.1. Types of Logical Functions......................................8
6.2. Variations of Logical Functions.................................8
6.3. Ordering of Logical Functions...................................8
6.4. Flexibility.....................................................9
6.5. Minimal Set of Logical Functions................................9
7. ForCES Protocol Requirements...................................10
8. References.....................................................13
8.1. Normative References...........................................13
8.2. Informative References.........................................13
9. Security Considerations........................................13
10. Authors' Addresses & Acknowledgments..........................13
11. Editors' Contact Information..................................15
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,
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
that of the resources assigned to a virtual router [REQ-PART]. that of the resources assigned to a virtual switching element as
described in [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.
PCE Partition - A logical partition of a PCE consisting of some PCE Partition - A logical partition of a PCE consisting of some
subset of each of the resources available on the PCE. subset of each of the resources available on the PCE.
Forwarding Element (FE) - A logical entity that implements the Forwarding Element (FE) - A logical entity that implements the
ForCES protocol. FEs use the underlying hardware to provide per- ForCES protocol. FEs use the underlying hardware to provide per-
skipping to change at page 5, line 34 skipping to change at page 6, line 4
metering, shaping, firewall, NAT, encapsulation (e.g., tunneling), metering, shaping, firewall, NAT, encapsulation (e.g., tunneling),
decapsulation, encryption, accounting, etc. Nearly all combinations decapsulation, encryption, accounting, etc. Nearly all combinations
of these functions may be present in practical FEs. of these functions may be present in practical FEs.
Below is a diagram illustrating an example NE composed of a CE and 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 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 the pre-configuration process and this may be done by FE Manager and
CE Manager respectively. Apart from this, there is no defined role CE Manager respectively. Apart from this, there is no defined role
for FE Manager and CE Manager. The Proxy FE has also been defined for FE Manager and CE Manager. The Proxy FE has also been defined
for clarification purpose. These components are out of scope of the for clarification purpose. These components are out of scope of the
architecture and requirements for ForCES protocol, which only architecture and requirements for the ForCES protocol, which only
involves CEs and FEs. involves CEs and FEs.
-------------------------------- --------------------------------
| NE | | NE |
| ------------- | | ------------- |
| | CE | | | | CE | |
| ------------- | | ------------- |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
skipping to change at page 9, line 22 skipping to change at page 9, line 23
typically performed before the forwarding decision (packets arriving typically performed before the forwarding decision (packets arriving
externally have their public addresses replaced with private externally have their public addresses replaced with private
addresses) and one NAT function is performed after the forwarding addresses) and one NAT function is performed after the forwarding
decision (for packets exiting the domain, their private addresses decision (for packets exiting the domain, their private addresses
are replaced by public ones). are replaced by public ones).
6.4. Flexibility 6.4. Flexibility
Finally, the FE model SHOULD provide a flexible infrastructure in Finally, the FE model SHOULD provide a flexible infrastructure in
which new logical functions and new classification, action, and which new logical functions and new classification, action, and
parameterization data can be easily added. Also, the FE model MUST parameterization data can be easily added. In addition, the FE
be capable of describing the types of statistics gathered by each model MUST be capable of describing the types of statistics gathered
logical function. by each logical function.
6.5. Minimal Set of Logical Functions 6.5. Minimal Set of Logical Functions
The rest of this section defines a 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 any FE model MUST support. This minimal set DOES NOT imply
that all FEs must provide this functionality. Instead, these that all FEs must provide this functionality. Instead, these
requirements only specify that the model must be capable of requirements only specify that the model must be capable of
expressing the capabilities that FEs may choose to provide. expressing the capabilities that FEs may choose to provide.
1)Port Functions 1)Port Functions
skipping to change at page 10, line 16 skipping to change at page 10, line 16
The FE model MUST be capable of expressing complex sets of filtering 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. The model MUST be able to express the existence of these
functions at arbitrary points in the sequence of a FE's packet functions at arbitrary points in the sequence of a FE's packet
processing functions. The FE model MUST be capable of expressing a processing functions. The FE model MUST be capable of expressing a
wide range of classification abilities from single fields (e.g., wide range of classification abilities from single fields (e.g.,
destination address) to arbitrary n-tuples. Similarly, the FE model destination address) to arbitrary n-tuples. Similarly, the FE model
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 new, currently unknown FE
functionality can be expressed. 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 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 class of service that a packet should receive (i.e. 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 IPv4 header TOS octet or the IPv6 Traffic Class octet). The FE
model MAY support other high touch functions (e.g., NAT, 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
skipping to change at page 11, line 11 skipping to change at page 11, line 15
of each FE. These capabilities SHALL be expressed using the FE of each FE. These capabilities SHALL be expressed using the FE
model whose requirements are defined in Section 6. Furthermore, the model whose requirements are defined in Section 6. Furthermore, the
protocol MUST provide a means for the CEs to control all the FE protocol MUST provide a means for the CEs to control all the FE
capabilities that are discovered through the FE model. The protocol capabilities that are discovered through the FE model. The protocol
MUST be able to add/remove classification/action entries, set/delete MUST be able to add/remove classification/action entries, set/delete
parameters, query statistics, and register for and receive events. parameters, query statistics, and register for and receive events.
2)Support for Secure Communication 2)Support for Secure Communication
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 authentication 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, etc. MUST be used/leveraged if applicable.
3)Scalability 3)Scalability
skipping to change at page 11, line 44 skipping to change at page 11, line 48
5)Message Priority 5)Message Priority
The ForCES protocol MUST provide a means to express the protocol The ForCES protocol MUST provide a means to express the protocol
message priorities. message priorities.
6)Reliability 6)Reliability
The ForCES protocol SHALL assume that it runs on top of an The ForCES protocol SHALL assume that it runs on top of an
unreliable, datagram service. For IP networks, an encapsulation of unreliable, datagram service. For IP networks, an encapsulation of
the ForCES protocol SHALL be defined that uses a [RFC2914]-compliant the ForCES protocol SHALL be defined that uses a [RFC2914]-compliant
transport protocol and provides a datagram service (that could be transport protocol and provides a datagram service (that could be
unreliable). For non-IP networks, additional encapsulations MAY be unreliable).
For non-IP networks such as FastEth, GigE, cell fabric between
control and forwarding elements, additional encapsulations MAY be
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.
delivered to FEs, the ForCES protocol MUST provide internal support
for reliability mechanisms such as message acknowledgements and/or However, reliability in the ForCES context means the ability to
state change confirmations. acknowledge the content and execution of messages, rather than just
their delivery. For this reason, the ForCES protocol MUST provide
internal support for reliability mechanisms such as message
acknowledgements and/or state change confirmations. This is required
for both IP and non-IP networks.
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)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
FEs MUST be able to redirect control packets (such as RIP, OSPF The ForCES protocol MUST define a way for FEs to be able to redirect
messages) addressed to their interfaces to the CE. They MUST also control packets (such as RIP, OSPF messages) addressed to their
redirect other relevant packets (e.g., such as those with Router interfaces to the CE and vice-versa. It MUST also allow redirection
Alert Option set) to their CE. The CEs MUST be able to configure the of other relevant packets (e.g., such as those with Router Alert
packet redirection information/filters on the FEs. The CEs MUST also Option set) to the CE. The ForCES protocol MUST also allow CEs to
be able to create packets and have its FEs deliver them. (refer to configure the packet redirection information/filters on the FEs.
section 5, requirement# 8) (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 51 skipping to change at page 13, line 12
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 failures or change in available resources events on the FE such as failures or change in available resources
or capabilities. (refer to section 5, requirement# 6) or capabilities. (refer to section 5, requirement# 6)
14)Query Statistics 14)Query Statistics
The ForCES protocol MUST provide a means for the CE to be able to The ForCES protocol MUST provide a means for the CE to be able to
query statistics (monitor performance) from the FE. query statistics (monitor performance) from the FE.
8. Security Considerations 8. References
See architecture requirement #5 and protocol requirement #2. 8.1.Normative References
9. Normative References
[RFC3290] Y. Bernet, et. al., "An Informal Management Model for [RFC3290] Y. Bernet, et. al., "An Informal Management Model for
DiffServ Routers", , May 2002. DiffServ Routers", , May 2002.
[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.
skipping to change at page 13, line 34 skipping to change at page 13, line 41
[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
Translator (NAT) Terminology and Considerations", RFC2663, August Translator (NAT) Terminology and Considerations", RFC2663, August
1999. 1999.
10. Informative References 8.2.Informative References
[REQ-PART] T. Anderson, C. Wang, J. Buerkle, "Requirements for the [REQ-PART] T. Anderson, J. Buerkle, "Requirements for the Dynamic
Dynamic Partitioning of Switching Elements", work in progress, June Partitioning of Switching Elements", work in progress, July 2002,
2002, <draft-ietf-gsmp-dyn-part-reqs-02.txt>. <draft-ietf-gsmp-dyn-part-reqs-02.txt>.
11. Authors' Addresses & Acknowledgments 9. Security Considerations
See architecture requirement #5 and protocol requirement #2.
10. Authors' Addresses & Acknowledgments
This document was written by the ForCES Requirements design team: This document was written by the ForCES Requirements design team:
Todd A. Anderson (Editor) Todd A. Anderson (Editor)
Ed Bowen Ed Bowen
IBM Zurich Research Laboratory IBM Zurich Research Laboratory
Saumerstrasse 4 Saumerstrasse 4
CH-8803 Rueschlikon Switzerland CH-8803 Rueschlikon Switzerland
Phone: +41 1 724 83 68 Phone: +41 1 724 83 68
Email: edbowen@us.ibm.com Email: edbowen@us.ibm.com
skipping to change at page 14, line 50 skipping to change at page 15, line 13
Margaret Wasserman Margaret Wasserman
Wind River Wind River
10 Tara Blvd., Suite 330 10 Tara Blvd., Suite 330
Nashua, NH 03062 Nashua, NH 03062
Phone: +1 603 897 2067 Phone: +1 603 897 2067
Email: mrw@windriver.com Email: mrw@windriver.com
The authors would like to thank Vip Sharma and Lily Yang for their The authors would like to thank Vip Sharma and Lily Yang for their
valuable contributions. valuable contributions.
12. Editors' Contact Information 11. Editors' Contact Information
Hormuzd Khosravi Hormuzd Khosravi
Intel Intel
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 USA Hillsboro, OR 97124 USA
Phone: +1 503 264 0334 Phone: +1 503 264 0334
Email: hormuzd.m.khosravi@intel.com Email: hormuzd.m.khosravi@intel.com
Todd A. Anderson Todd A. Anderson
Intel Intel
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 USA Hillsboro, OR 97124 USA
Phone: +1 503 712 1760 Phone: +1 503 712 1760
Email: todd.a.anderson@intel.com Email: todd.a.anderson@intel.com
1. Abstract........................................................1
2. Definitions.....................................................2
3. Introduction....................................................4
4. Architecture....................................................5
5. Architectural Requirements......................................6
6. FE Model Requirements...........................................8
6.1. Types of Logical Functions......................................8
6.2. Variations of Logical Functions.................................8
6.3. Ordering of Logical Functions...................................8
6.4. Flexibility.....................................................9
6.5. Minimal Set of Logical Functions................................9
7. ForCES Protocol Requirements...................................10
8. Security Considerations........................................12
9. Normative References...........................................13
10. Informative References........................................13
11. Authors' Addresses & Acknowledgments..........................13
12. Editors' Contact Information..................................14
 End of changes. 

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