draft-ietf-forces-requirements-08.txt   draft-ietf-forces-requirements-09.txt 
Internet Draft H. Khosravi, Internet Draft H. Khosravi,
Expiration: July 2003 T. Anderson (Editors) Expiration: November 2003 T. Anderson (Editors)
File: draft-ietf-forces-requirements-08.txt Intel File: draft-ietf-forces-requirements-09.txt Intel
Working Group: ForCES January 2003 Working Group: ForCES May 2003
Requirements for Separation of IP Control and Forwarding Requirements for Separation of IP Control and Forwarding
draft-ietf-forces-requirements-08.txt draft-ietf-forces-requirements-09.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 17 skipping to change at page 2, line 17
3. Definitions.....................................................3 3. Definitions.....................................................3
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. References.....................................................13 8. References.....................................................14
8.1. Normative References...........................................13 8.1. Normative References...........................................14
8.2. Informative References.........................................13 8.2. Informative References.........................................14
9. Security Considerations........................................13 9. Security Considerations........................................15
10. Authors' Addresses & Acknowledgments..........................14 10. Authors' Addresses & Acknowledgments..........................15
11. Editors' Contact Information..................................15 11. Editors' Contact Information..................................16
2. Introduction 2. Introduction
An IP network element is composed of numerous logically separate An IP network element is composed of numerous logically separate
entities that cooperate to provide a given functionality (such as a entities that cooperate to provide a given functionality (such as a
routing or IP switching) and yet appear as a normal integrated routing or IP switching) and yet appear as a normal integrated
network element to external entities. Two primary types of network network element to external entities. Two primary types of network
element components exist: control-plane components and forwarding- element components exist: control-plane components and forwarding-
plane components. In general, forwarding-plane components are ASIC, plane components. In general, forwarding-plane components are ASIC,
network-processor, or general-purpose processor-based devices that network-processor, or general-purpose processor-based devices that
skipping to change at page 3, line 22 skipping to change at page 3, line 22
networks, it is a device to which we can communicate using an IP networks, it is a device to which we can communicate using an IP
address; and on a switch fabric, it is a device to which we can address; and on a switch fabric, it is a device to which we can
communicate using a switch fabric port number. communicate using a switch fabric port 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
subset of each of the resources (e.g., ports, memory, forwarding
table entries) available on the PFE. This concept is analogous to
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
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-
packet processing and handling as directed by a CE via the ForCES packet processing and handling as directed/controlled by a CE via
protocol. FEs may use PFE partitions, whole PFEs, or multiple PFEs. the ForCES protocol. FEs may happen to be a single blade(or PFE), a
partition of a PFE or multiple PFEs.
Proxy FE - A name for a type of FE that cannot directly modify its
underlying hardware but instead manipulates that hardware using some
intermediate form of communication (e.g., a non-ForCES protocol or
DMA). A proxy FE will typically be used in the case where a PFE
cannot implement the ForCES protocol directly (e.g., due to the lack
of a general purpose CPU).
Control Element (CE) - A logical entity that implements the ForCES Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs how to process protocol and uses it to instruct one or more FEs how to process
packets. CEs handle functionality such as the execution of control packets. CEs handle functionality such as the execution of control
and signaling protocols. CEs may consist of PCE partitions or whole and signaling protocols. CEs may consist of PCE partitions or whole
PCEs. PCEs.
Pre-association Phase - The period of time during which a FE Manager Pre-association Phase - The period of time during which a FE Manager
(see below) and a CE Manager (see below) are determining which FE (see below) and a CE Manager (see below) are determining which FE
and CE should be part of the same network element. Any partitioning and CE should be part of the same network element. Any partitioning
skipping to change at page 4, line 38 skipping to change at page 4, line 24
FE Model - A model that describes the logical processing functions FE Model - A model that describes the logical processing functions
of a FE. of a FE.
FE Manager - A logical entity that operates in the pre-association FE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which CE(s) a FE should phase and is responsible for determining to which CE(s) a FE should
communicate. This process is called CE discovery and may involve communicate. This process is called CE discovery and may involve
the FE manager learning the capabilities of available CEs. A FE the FE manager learning the capabilities of available CEs. A FE
manager may use anything from a static configuration to a pre- manager may use anything from a static configuration to a pre-
association phase protocol (see below) to determine which CE(s) to association phase protocol (see below) to determine which CE(s) to
use. Being a logical entity, a FE manager might be physically use, however this is currently out of scope. Being a logical
combined with any of the other logical entities mentioned in this entity, a FE manager might be physically combined with any of the
section. other logical entities mentioned in this section.
CE Manager - A logical entity that operates in the pre-association CE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which FE(s) a CE should phase and is responsible for determining to which FE(s) a CE should
communicate. This process is called FE discovery and may involve communicate. This process is called FE discovery and may involve
the CE manager learning the capabilities of available FEs. A CE the CE manager learning the capabilities of available FEs. A CE
manager may use anything from a static configuration to a pre- manager may use anything from a static configuration to a pre-
association phase protocol (see below) to determine which FE to use. association phase protocol (see below) to determine which FE to use,
Being a logical entity, a CE manager might be physically combined however this is currently out of scope. Being a logical entity, a
with any of the other logical entities mentioned in this section. CE manager might be physically combined 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. further in this document.
skipping to change at page 5, line 49 skipping to change at page 5, line 36
can be developed - some general purpose and others more specialized. can be developed - some general purpose and others more specialized.
Some functions that FEs could perform include layer 3 forwarding, Some functions that FEs could perform include layer 3 forwarding,
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. These components are out of scope of
for clarification purpose. These components are out of scope of the the architecture and requirements for the ForCES protocol, which
architecture and requirements for the ForCES protocol, which only only involves CEs and FEs.
involves CEs and FEs.
-------------------------------- --------------------------------
| NE | | NE |
| ------------- | | ------------- |
| | CE | | | | CE | |
| ------------- | | ------------- |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
skipping to change at page 7, line 36 skipping to change at page 7, line 22
8) FEs MUST be able to redirect control packets (such as RIP, OSPF 8) FEs MUST be able to redirect control packets (such as RIP, OSPF
messages) addressed to their interfaces to the CE. They MUST also messages) addressed to their interfaces to the CE. They MUST also
redirect other relevant packets (e.g., such as those with Router redirect other relevant packets (e.g., such as those with Router
Alert Option set) to their CE. The CEs MUST be able to configure the Alert Option set) to their CE. The CEs MUST be able to configure the
packet redirection information/filters on the FEs. The CEs MUST also packet redirection information/filters on the FEs. The CEs MUST also
be able to create packets and have its FEs deliver them. be able to create packets and have its FEs deliver them.
9) Any proposed ForCES architectures MUST explain how that 9) Any proposed ForCES architectures MUST explain how that
architecture supports all of the router functions as defined in architecture supports all of the router functions as defined in
[RFC1812]. [RFC1812]. IPv4 Forwarding functions such IP header validation,
performing longest prefix match algorithm, TTL decrement, Checksum
calculation, generation of ICMP error messages, etc defined in RFC
1812 should be explained.
10) In a ForCES NE, the FEs MUST be able to provide their topology 10) In a ForCES NE, the FEs MUST be able 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). the CE(s).
11) The ForCES NE architecture MUST be capable of supporting (i.e., 11) The ForCES NE architecture MUST be capable of supporting (i.e.,
must scale to) at least hundreds of FEs and tens of thousands of must scale to) at least hundreds of FEs and tens of thousands of
ports. ports.
12) The ForCES architecture MUST allow FEs AND CEs to join and leave 12) The ForCES architecture MUST allow FEs AND CEs to join and leave
NEs dynamically. NEs dynamically.
13) The ForCES NE architecture MUST support multiple CEs and FEs. 13) The ForCES NE architecture MUST support multiple CEs and FEs.
However, coordination between CEs is out of scope of ForCES.
14) For pre-association phase setup, monitoring, configuration 14) For pre-association phase setup, monitoring, configuration
issues, it MAY be useful to use standard management mechanisms for issues, it MAY be useful to use standard management mechanisms for
CEs and FEs. The ForCES architecture and requirements do not CEs and FEs. The ForCES architecture and requirements do not
preclude this. In general, for post-association phase, most preclude this. In general, for post-association phase, most
management tasks SHOULD be done through interaction with the CE. In management tasks SHOULD be done through interaction with the CE. In
certain conditions (e.g. CE/FE disconnection), it may be useful to certain conditions (e.g. CE/FE disconnection), it may be useful to
allow management tools (e.g. SNMP) to be used to diagnose and repair allow management tools (e.g. SNMP) to be used to diagnose and repair
problems. The following guidelines MUST be observed: problems. The following guidelines MUST be observed:
1. The ability for a management tool (e.g. SNMP) to be used to read 1. The ability for a management tool (e.g. SNMP) to be used to read
skipping to change at page 10, line 44 skipping to change at page 10, line 34
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, FEs MUST
allow logical functions to execute asynchronously from packet allow logical functions to execute asynchronously from packet
processing, according to a certain finite-state machine, in order to processing, according to a certain finite-state machine, in order to
perform functions that are, for instance, off-loaded from the CE to perform functions that are, for instance, off-loaded from the CE to
the FE. The FE model MUST be capable of expressing these 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. 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
Off-loaded functions on an FE.
7. ForCES Protocol Requirements 9)IPFLOW/PSAMP Functions
Several applications such as, Usage-based Accounting, Traffic
engineering, require flow-based IP traffic measurements from Network
Elements. [IPFLOW] defines architecture for IP traffic flow
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.
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
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 authenticity and integrity of MUST be possible to ensure the integrity of all ForCES protocol
ForCES protocol messages. messages and protect against man-in-the-middle attacks.
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 Because of the confidential nature of the information, it MUST be
protocol messages. possible to secure (make private) all ForCES protocol messages.
c) In order to provide authentication, integrity and privacy for a c) In order to ensure that authorized CEs and FEs are participating
proposed ForCES protocol, existing security mechanisms such as in a NE and defend against CE or FE impersonation attacks, the
IPSec/IKE, TLS (if transport is reliable), etc. MUST be ForCES architecture MUST select a means of authentication for CEs
used/leveraged if applicable. 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 3)Scalability
The ForCES protocol MUST be capable of supporting (i.e., must scale 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 to) at least hundreds of FEs and tens of thousands of ports. For
example, the ForCES protocol field sizes corresponding to FE or port example, the ForCES protocol field sizes corresponding to FE or port
numbers SHALL be large enough to support the minimum required numbers SHALL be large enough to support the minimum required
numbers. This requirement does not relate to the performance of a numbers. This requirement does not relate to the performance of a
NE as the number of FEs or ports in the NE grows. NE as the number of FEs or ports in the NE grows.
4)Multihop 4)Multihop
When the CEs and FEs are separated beyond a single hop, the ForCES When the CEs and FEs are separated beyond a single hop, the ForCES
protocol will make use of an existing RFC2914 compliant L4 protocol protocol will make use of an existing RFC2914 compliant L4 protocol
with adequate reliability, security and congestion control (e.g. with adequate reliability, security and congestion control (e.g.
TCP, SCTP) for transport purposes. TCP, SCTP) for transport purposes.
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 a) The ForCES protocol will be used to transport information that
unreliable, datagram service. For IP networks, an encapsulation of requires varying levels of reliability. By strict or robust
the ForCES protocol SHALL be defined that uses a [RFC2914]-compliant reliability in this requirement we mean, no losses, no corruption,
transport protocol and provides a datagram service (that could be no re-ordering of information being transported and delivery in a
unreliable). timely fashion.
For non-IP networks such as FastEth, GigE, cell fabric between b) Some information or payloads, such as redirected packets or packet
control and forwarding elements, additional encapsulations MAY be sampling, may not require robust reliability (can tolerate some
defined so long as they provide a datagram service to the ForCES degree of losses). For information of this sort, ForCES MAY NOT
impose strict reliability.
c) Payloads such as configuration information, e.g. ACLs, FIB
entries, or FE capability information (described in section 7,
(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 7, (8)), may prefer timeliness over reliable delivery. For
information of this sort, ForCES MAY NOT impose 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. protocol.
f) In cases where ForCES is not running over an IP network such as an
However, reliability in the ForCES context means the ability to Ethernet or cell fabric between CE and FE, then reliability still
acknowledge the content and execution of messages, rather than just MUST be provided when carrying critical information of the types
their delivery. For this reason, the ForCES protocol MUST provide specified in (c) above, either by the underlying link/network/
internal support for reliability mechanisms such as message transport layers or by built-in protocol mechanisms.
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
skipping to change at page 13, line 16 skipping to change at page 13, line 47
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.
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).
8. References 8. References
8.1.Normative References 8.1.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
skipping to change at page 13, line 51 skipping to change at page 14, line 47
[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.
8.2.Informative References 8.2.Informative References
[REQ-PART] T. Anderson, J. Buerkle, "Requirements for the Dynamic [REQ-PART] T. Anderson, J. Buerkle, "Requirements for the Dynamic
Partitioning of Switching Elements", work in progress, July 2002, Partitioning of Switching Elements", work in progress, July 2002,
<draft-ietf-gsmp-dyn-part-reqs-02.txt>. <draft-ietf-gsmp-dyn-part-reqs-02.txt>.
[IPFLOW] Quittek, et. Al., "Requirements for IP Flow Information
Export", work in progress, February 2003, <draft-ietf-ipfix-reqs-
09.txt>.
[PSAMP] Duffield, et. Al., "A Framework for Passive Packet
Measurement ", work in progress, March 2003, <draft-ietf-psamp-
framework-02.txt>.
9. Security Considerations 9. Security Considerations
See architecture requirement #5 and protocol requirement #2. See architecture requirement #5 and protocol requirement #2.
10. Authors' Addresses & Acknowledgments 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
skipping to change at page 14, line 20 skipping to change at page 15, line 27
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
Ram Dantu Ram Dantu
Netrake Corporation Department of Computer Science
3000 Technology Drive, #100, University of North Texas,
Plano, Texas, 75074 Denton, Texas, 76203
Email: rdantu@netrake.com Email: rdantu@unt.edu
Phone: 214 291 1111 Phone: 940 565 2822
Avri Doria Avri Doria
Institute for System Technology Institute for System Technology
Lulea University of Technology Lulea University of Technology
SE-971 87, Lulea, Sweden SE-971 87, Lulea, Sweden
Phone: +46 (0)920 49 3030 Phone: +46 (0)920 49 3030
Email: avri@sm.luth.se Email: avri@sm.luth.se
Ram Gopal Ram Gopal
Nokia Research Center Nokia Research Center
 End of changes. 

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