draft-ietf-forces-requirements-04.txt   draft-ietf-forces-requirements-05.txt 
Internet Draft T. Anderson Internet Draft H. Khosravi, Editor
Expiration: December 2002 Intel Expiration: December 2002 Intel
File: draft-ietf-forces-requirements-04.txt E. Bowen File: draft-ietf-forces-requirements-05.txt
Working Group: ForCES IBM Working Group: ForCES June 2002
R. Dantu
Netrake Inc.
A. Doria
LTU
R. Gopal
Nokia
J. Hadi Salim
Znyx Networks
H. Khosravi
Intel
M. Minhazuddin
Avaya Inc.
M. Wasserman
Wind River
June 2002
Requirements for Separation of IP Control and Forwarding Requirements for Separation of IP Control and Forwarding
draft-ietf-forces-requirements-04.txt draft-ietf-forces-requirements-05.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 4, line 19 skipping to change at page 4, line 7
with any of the other logical entities mentioned in this section. with any of the other logical entities mentioned in this section.
Pre-association Phase Protocol - A protocol between FE managers and Pre-association Phase Protocol - A protocol between FE managers and
CE managers that is used to determine which CEs or FEs to use. A 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 pre-association phase protocol may include a CE and/or FE capability
discovery mechanism. Note that this capability discovery process is discovery mechanism. Note that this capability discovery process is
wholly separate from (and does not replace) that used within the wholly separate from (and does not replace) that used within the
ForCES protocol (see Section 7, requirement #1). However, the two ForCES protocol (see Section 7, requirement #1). However, the two
capability discovery mechanisms may utilize the same FE model (see capability discovery mechanisms may utilize the same FE model (see
Section 6). Pre-association phase protocols are not discussed Section 6). Pre-association phase protocols are not discussed
further in this document (see Section 11.3). further in this document.
ForCES Network Element (NE) - An entity composed of one or more CEs 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 and one or more FEs. To entities outside a NE, the NE represents a
single point of management. Similarly, a NE usually hides its single point of management. Similarly, a NE usually hides its
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
skipping to change at page 4, line 52 skipping to change at page 4, line 40
network-processor, or general-purpose processor-based devices that network-processor, or general-purpose processor-based devices that
handle all data path operations. Conversely, control-plane handle all data path operations. Conversely, control-plane
components are typically based on general-purpose processors that components are typically based on general-purpose processors that
provide control functionality such as the processing of routing or provide control functionality such as the processing of routing or
signaling protocols. A standard set of mechanisms for connecting signaling protocols. A standard set of mechanisms for connecting
these components provides increased scalability and allows the these components provides increased scalability and allows the
control and forwarding planes to evolve independently, thus control and forwarding planes to evolve independently, thus
promoting faster innovation. promoting faster innovation.
For the purpose of illustration, let us consider the architecture of For the purpose of illustration, let us consider the architecture of
a router to illustrate the concept and value of separate control and a router to illustrate the concept of separate control and
forwarding planes. The architecture of a router is composed of two forwarding planes. The architecture of a router is composed of two
main parts. These components, while inter-related, perform main parts. These components, while inter-related, perform
functions that are largely independent of each other. At the bottom functions that are largely independent of each other. At the bottom
is the forwarding path that operates in the data-forwarding plane is the forwarding path that operates in the data-forwarding plane
and is responsible for per-packet processing and forwarding. Above and is responsible for per-packet processing and forwarding. Above
the forwarding plane is the network operating system that is the forwarding plane is the network operating system that is
responsible for operations in the control plane. In the case of a responsible for operations in the control plane. In the case of a
router or switch, the network operating system runs routing, router or switch, the network operating system runs routing,
signaling and control protocols (e.g., RIP, OSPF and RSVP) and signaling and control protocols (e.g., RIP, OSPF and RSVP) and
dictates the forwarding behavior by manipulating forwarding tables, dictates the forwarding behavior by manipulating forwarding tables,
skipping to change at page 9, line 51 skipping to change at page 9, line 51
The FE model MUST be capable of expressing the data that can be used The FE model MUST be capable of expressing the data that can be used
by the forwarding function to make a forwarding decision. Support by the forwarding function to make a forwarding decision. Support
for IPv4 and IPv6 unicast and multicast forwarding functions MUST be for IPv4 and IPv6 unicast and multicast forwarding functions MUST be
provided by the model. provided by the model.
3)QoS Functions 3)QoS Functions
The FE model MUST allow a FE to express its QoS capabilities in The FE model MUST allow a FE to express its QoS capabilities in
terms of, e.g., metering, policing, shaping, and queuing functions. terms of, e.g., metering, policing, shaping, and queuing functions.
The FE model MUST be capable of expressing the use of these The FE model MUST be capable of expressing the use of these
functions to provide IntServ or DiffServ functionality as described functions to provide IntServ or DiffServ functionality as described
in [RFC2211], [RFC2212], [RFC2215], [RFC2475], and [DS-MODEL]. in [RFC2211], [RFC2212], [RFC2215], [RFC2475], and [RFC3290].
4)Generic Filtering Functions 4)Generic Filtering Functions
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.
skipping to change at page 13, line 8 skipping to change at page 13, line 8
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. 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 [RFC3290] Y. Bernet, et. al., "An Informal Management Model for
DiffServ Routers", work in progress, September 2001, <draft-ietf- DiffServ Routers", , May 2002.
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.
skipping to change at page 13, line 38 skipping to change at page 13, line 37
[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 10. Informative References
[REQ-PART] T. Anderson, C. Wang, J. Buerkle, "Requirements for the [REQ-PART] T. Anderson, C. Wang, J. Buerkle, "Requirements for the
Dynamic Partitioning of Network Elements", work in progress, August Dynamic Partitioning of Switching Elements", work in progress, June
2001, <draft-ietf-gsmp-dyn-part-reqs-00.txt>. 2002, <draft-ietf-gsmp-dyn-part-reqs-02.txt>.
11. Acknowledgments 11. Authors' Addresses & Acknowledgments
The authors would like to thank Vip Sharma and Lily Yang for their
valuable contributions.
12. Authors' Addresses This document was written by the ForCES Requirements design team:
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
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
Ram Dantu Ram Dantu
Netrake Corporation Netrake Corporation
3000 Technology Drive, #100, 3000 Technology Drive, #100,
skipping to change at page 14, line 38 skipping to change at page 14, line 37
Burlington, MA 01803 Burlington, MA 01803
Phone: 1-781-993-3685 Phone: 1-781-993-3685
Email: ram.gopal@nokia.com Email: ram.gopal@nokia.com
Jamal Hadi Salim Jamal Hadi Salim
Znyx Networks Znyx Networks
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Email: hadi@znyx.com Email: hadi@znyx.com
Hormuzd Khosravi Hormuzd Khosravi (Editor)
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124 USA
Phone: +1 503 264 0334
Email: hormuzd.m.khosravi@intel.com
Muneyb Minhazuddin Muneyb Minhazuddin
Avaya Inc. Avaya Inc.
123, Epping road, 123, Epping road,
North Ryde, NSW 2113, Australia North Ryde, NSW 2113, Australia
Phone: +61 2 9352 8620 Phone: +61 2 9352 8620
email: muneyb@avaya.com email: muneyb@avaya.com
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
valuable contributions.
1. Abstract........................................................2 12. 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
1. Abstract........................................................1
2. Definitions.....................................................2 2. Definitions.....................................................2
3. Introduction....................................................4 3. Introduction....................................................4
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. Security Considerations........................................12 8. Security Considerations........................................12
9. Normative References...........................................13 9. Normative References...........................................13
10. Informative References........................................13 10. Informative References........................................13
11. Acknowledgments...............................................13 11. Authors' Addresses & Acknowledgments..........................13
12. Authors' Addresses............................................13 12. Editors' Contact Information..................................15
 End of changes. 

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