draft-ietf-forces-requirements-09.txt   draft-ietf-forces-requirements-10.txt 
Internet Draft H. Khosravi, Internet Draft H. Khosravi,
Expiration: November 2003 T. Anderson (Editors) Expiration: January 2004 T. Anderson (Editors)
File: draft-ietf-forces-requirements-09.txt Intel File: draft-ietf-forces-requirements-10.txt Intel
Working Group: ForCES May 2003 Working Group: ForCES July 2003
Requirements for Separation of IP Control and Forwarding Requirements for Separation of IP Control and Forwarding
draft-ietf-forces-requirements-09.txt draft-ietf-forces-requirements-10.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 10, line 26 skipping to change at page 10, line 26
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
that may be applied to packets in the forwarding path. that may be applied to packets in the forwarding path.
8)Off-loaded Functions 8)Off-loaded Functions
Per-packet processing can leave state in the FE, so that logical Per-packet processing can leave state in the FE, so that logical
functions executed during packet processing can perform in a functions executed during packet processing can perform in a
consistent manner (for instance, each packet may update the state of consistent manner (for instance, each packet may update the state of
the token bucket occupancy of a give policer). In addition, FEs MUST the token bucket occupancy of a give policer). In addition, the FE
allow logical functions to execute asynchronously from packet Model MUST allow logical functions to execute asynchronously from
processing, according to a certain finite-state machine, in order to packet processing, according to a certain finite-state machine, in
perform functions that are, for instance, off-loaded from the CE to order to perform functions that are, for instance, off-loaded from
the FE. The FE model MUST be capable of expressing these the CE to the FE. The FE model MUST be capable of expressing these
asynchronous functions. Examples of such functions include the asynchronous functions. Examples of such functions include the
finite-state machine execution required by TCP termination or OSPF finite-state machine execution required by TCP termination or OSPF
Hello processing, triggered not only by packet events, but by timer Hello processing, triggered not only by packet events, but by timer
events as well. This Does NOT mean off-loading of any piece of code events as well. This Does NOT mean off-loading of any piece of code
to an FE, just that the FE Model should be able to express existing to an FE, just that the FE Model should be able to express existing
Off-loaded functions on an FE. Off-loaded functions on an FE.
9)IPFLOW/PSAMP Functions 9)IPFLOW/PSAMP Functions
Several applications such as, Usage-based Accounting, Traffic Several applications such as, Usage-based Accounting, Traffic
engineering, require flow-based IP traffic measurements from Network engineering, require flow-based IP traffic measurements from Network
skipping to change at page 12, line 19 skipping to change at page 12, line 19
message priorities. message priorities.
6)Reliability 6)Reliability
a) The ForCES protocol will be used to transport information that a) The ForCES protocol will be used to transport information that
requires varying levels of reliability. By strict or robust requires varying levels of reliability. By strict or robust
reliability in this requirement we mean, no losses, no corruption, reliability in this requirement we mean, no losses, no corruption,
no re-ordering of information being transported and delivery in a no re-ordering of information being transported and delivery in a
timely fashion. timely fashion.
b) Some information or payloads, such as redirected packets or packet b) Some information or payloads, such as redirected packets or packet
sampling, may not require robust reliability (can tolerate some sampling, may not require robust reliability (can tolerate some
degree of losses). For information of this sort, ForCES MAY NOT degree of losses). For information of this sort, ForCES MUST NOT
impose strict reliability. be restricted to strict reliability.
c) Payloads such as configuration information, e.g. ACLs, FIB c) Payloads such as configuration information, e.g. ACLs, FIB
entries, or FE capability information (described in section 7, entries, or FE capability information (described in section 7,
(1)) are mission critical and must be delivered in a robust (1)) are mission critical and must be delivered in a robust
reliable fashion. Thus, for information of this sort, ForCES MUST reliable fashion. Thus, for information of this sort, ForCES MUST
either provide built-in protocol mechanisms or use a reliable either provide built-in protocol mechanisms or use a reliable
transport protocol for achieving robust/strict reliability. transport protocol for achieving robust/strict reliability.
d) Some information or payloads, such as heartbeat packets that may d) Some information or payloads, such as heartbeat packets that may
be used to detect loss of association between CE and FEs (see be used to detect loss of association between CE and FEs (see
section 7, (8)), may prefer timeliness over reliable delivery. For section 7, (8)), may prefer timeliness over reliable delivery. For
information of this sort, ForCES MAY NOT impose strict information of this sort, ForCES MUST NOT be restricted to strict
reliability. reliability.
e) When ForCES is carried over multi-hop IP networks, it is a e) When ForCES is carried over multi-hop IP networks, it is a
requirement that ForCES MUST use a [RFC2914]-compliant transport requirement that ForCES MUST use a [RFC2914]-compliant transport
protocol. protocol.
f) In cases where ForCES is not running over an IP network such as an 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 Ethernet or cell fabric between CE and FE, then reliability still
MUST be provided when carrying critical information of the types MUST be provided when carrying critical information of the types
specified in (c) above, either by the underlying link/network/ specified in (c) above, either by the underlying link/network/
transport layers or by built-in protocol mechanisms. transport layers or by built-in protocol mechanisms.
 End of changes. 

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