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
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.
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
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.
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.
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
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.
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
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.