draft-ietf-forces-requirements-03.txt   draft-ietf-forces-requirements-04.txt 
Internet Draft T. Anderson Internet Draft T. Anderson
Expiration: October 2002 Intel Expiration: December 2002 Intel
File: draft-ietf-forces-requirements-03.txt E. Bowen File: draft-ietf-forces-requirements-04.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
April 2002 June 2002
Requirements for Separation of IP Control and Forwarding Requirements for Separation of IP Control and Forwarding
draft-ietf-forces-requirements-03.txt draft-ietf-forces-requirements-04.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 7, line 9 skipping to change at page 7, line 9
decremented only once as it traverses the NE regardless of how many decremented only once as it traverses the NE regardless of how many
FEs through which it passes. However, external entities (e.g., FE FEs through which it passes. However, external entities (e.g., FE
managers and CE managers) MAY have direct access to individual managers and CE managers) MAY have direct access to individual
ForCES protocol elements for providing information to transition ForCES protocol elements for providing information to transition
them from the pre-association to post-association phase. them from the pre-association to post-association phase.
5) The architecture MUST provide a way to prevent unauthorized 5) The architecture MUST provide a way to prevent unauthorized
ForCES protocol elements from joining a NE.(For more protocol ForCES protocol elements from joining a NE.(For more protocol
details, refer to section 7 requirement# 2) details, refer to section 7 requirement# 2)
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 a failure or
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 Thus the FE MUST support error monitoring and reporting. (Since
is possible for the relationship between a FE and its physical 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
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 CE redundancy or CE 7) The architecture 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
skipping to change at page 8, line 22 skipping to change at page 8, line 23
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). The FE model MUST also support multiple FEs in 7, requirement #1). The FE model MUST define both a capability model
the NE architecture. and a state model, which expresses the current configuration of the
device. 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 9, line 39 skipping to change at page 9, line 42
expressing the capabilities that FEs may choose to provide. expressing the capabilities that FEs may choose to provide.
1)Port Functions 1)Port Functions
The FE model MUST be capable of expressing the number of ports on The FE model MUST be capable of expressing the number of ports on
the device, the static attributes of each port (e.g., port type, the device, the static attributes of each port (e.g., port type,
link speed), and the configurable attributes of each port (e.g., IP link speed), and the configurable attributes of each port (e.g., IP
address, administrative status). address, administrative status).
2)Forwarding Functions 2)Forwarding Functions
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. by the forwarding function to make a forwarding decision. Support
for IPv4 and IPv6 unicast and multicast forwarding functions MUST be
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 [DS-MODEL].
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
skipping to change at page 10, line 24 skipping to change at page 10, line 30
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
that may be applied to packets in the forwarding path. that may be applied to packets in the forwarding path.
8)Off-loaded Functions
Per-packet processing can leave state in the FE, so that logical
functions executed during packet processing can perform in a
consistent manner (for instance, each packet may update the state of
the token bucket occupancy of a give policer). In addition, FEs MUST
allow logical functions to execute asynchronously from packet
processing, according to a certain finite-state machine, in order to
perform functions that are, for instance, off-loaded from the CE to
the FE. The FE model MUST be capable of expressing these
asynchronous functions. Examples of such functions include the
finite-state machine execution required by TCP termination or OSPF
Hello processing, triggered not only by packet events, but by timer
events as well.
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.
1)Configuration of Modeled Elements 1)Configuration of Modeled Elements
The ForCES protocol MUST allow the CEs to determine the capabilities The ForCES protocol MUST allow the CEs to determine the capabilities
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
skipping to change at page 12, line 25 skipping to change at page 12, line 44
12)Command Bundling 12)Command Bundling
The ForCES protocol MUST be able to group an ordered set of commands 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 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 failures or change in available resources
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. 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.
skipping to change at page 15, line 6 skipping to change at page 15, line 24
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...........................................12 9. Normative References...........................................13
10. Informative References........................................13 10. Informative References........................................13
11. Acknowledgments...............................................13 11. Acknowledgments...............................................13
12. Authors' Addresses............................................13 12. Authors' Addresses............................................13
 End of changes. 

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