draft-ietf-forces-applicability-02.txt   draft-ietf-forces-applicability-03.txt 
Internet Engineering Task Force ForCES WG Alan Crouch
INTERNET-DRAFT Alan Crouch/Intel Internet Draft Hormuzd Khosravi
draft-ietf-forces-applicability-02.txt Mark Handley/ICIR Document: draft-ietf-forces-applicability- Intel Corp.
03.txt
Expires: July 2006 Mark Handley
Working Group: ForCES ICIR
26 June 2003 Feb 2006
Expires: December 2003
ForCES Applicability Statement ForCES Applicability Statement
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all By submitting this Internet-Draft, each author represents that any
provisions of Section 10 of RFC2026. applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that
may also distribute working documents as Internet- Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference material at any time. It is inappropriate to use Internet-Drafts as
or to cite them other than as "work in progress." reference material or to cite them other than as ``work in
progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2006).
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [2].
Abstract Abstract
The ForCES protocol defines a standard framework and mechanism ForCES Applicability Statement Feb 2006
for the interconnection between Control Elements and
Forwarding Engines in IP routers and similar devices. In this The ForCES protocol defines a standard framework and mechanism for
document we describe the applicability of the ForCES model and the interconnection between Control Elements and Forwarding Elements
protocol. We provide example deployment scenarios and in IP routers and similar devices. In this document we describe the
functionality, as well as document applications that would be applicability of the ForCES model and protocol. We provide example
inappropriate for ForCES. deployment scenarios and functionality, as well as document
applications that would be inappropriate for ForCES.
Table of Contents
1. Purpose.........................................................2
2. Overview........................................................3
3. Terminology.....................................................3
4. Applicability to IP Networks....................................3
4.1. Applicable Services...........................................4
4.1.1. Discovery, Capability Information Exchange..................4
4.1.2. Topology Information Exchange...............................5
4.1.3. Configuration...............................................5
4.1.4. Routing Exchange............................................5
4.1.5. QoS Exchange................................................5
4.1.6. Security Exchange...........................................5
4.1.7. Filtering Exchange and Firewalls............................5
4.1.8. Encapsulation, Tunneling Exchange...........................6
4.1.9. NAT and Application-level Gateways..........................6
4.1.10. Measurement and Accounting.................................6
4.1.11. Diagnostics................................................6
4.1.12. CE Redundancy or CE Failover...............................6
4.2. CE-FE Link Capability.........................................6
4.3. CE/FE Locality................................................7
5. Limitations and Out-of-Scope Items..............................7
5.1. Out of Scope Services.........................................8
5.1.1. Label Switching.............................................8
5.1.2. Separation of Control and Forwarding in Multimedia Gateways.8
5.2. Localities....................................................8
6. Security Considerations.........................................8
7. Manageability...................................................9
8. References......................................................9
8.1. Normative References..........................................9
8.2. Informative References........................................9
9. Acknowledgments.................................................9
10. Authors' Addresses............................................10
1. Purpose 1. Purpose
The purpose of the ForCES Applicability Statement is to capture the The purpose of the ForCES Applicability Statement is to capture the
intent of the ForCES protocol designers as to how the protocol should be intent of the ForCES protocol designers as to how the protocol
used. The Applicability Statement will evolve alongside the protocol,
and will go to RFC as informational around the same time the as the ForCES Applicability Statement Feb 2006
protocol goes to RFC.
should be used. The Applicability Statement will evolve alongside
the protocol, and will go to RFC as informational around the same
time the as the protocol goes to RFC.
2. Overview 2. Overview
The ForCES protocol defines a standard framework and mechanism for the The ForCES protocol defines a standard framework and mechanism for
exchange of information between the logically separate functionality of the exchange of information between the logically separate
the control and data forwarding planes of IP routers and similar functionality of the control and data forwarding planes of IP
devices. It focuses on the communication necessary for separation of routers and similar devices. It focuses on the communication
control plane functionality such as routing protocols, signaling necessary for separation of control plane functionality such as
protocols, and admission control from data forwarding plane per-packet routing protocols, signaling protocols, and admission control from
activities such as packet forwarding, queuing, and header editing. data forwarding plane per-packet activities such as packet
forwarding, queuing, and header editing.
This document defines the applicability of the ForCES mechanisms. It This document defines the applicability of the ForCES mechanisms. It
describes types of configurations and settings where ForCES is most describes types of configurations and settings where ForCES is most
appropriately applied. This document also describes scenarios and appropriately applied. This document also describes scenarios and
configurations where ForCES would not be appropriate for use. configurations where ForCES would not be appropriate for use.
3. Terminology A set of terminology associated with ForCES is defined 3. Terminology
in [1]. That terminology is reused here and the reader is directed to
[1] for the following definitions: A set of terminology associated with ForCES is defined in [3, 4].
That terminology is reused here and the reader is directed to [3, 4]
for the following definitions:
o CE: Control Element. o CE: Control Element.
o FE: Forwarding Element. o FE: Forwarding Element.
o ForCES: ForCES protocol. o ForCES: ForCES protocol.
4. Applicability to IP Networks 4. Applicability to IP Networks
The purpose of this section is to list the areas of ForCES applicability The purpose of this section is to list the areas of ForCES
in IP network devices. Relatively low performance devices may be applicability in IP network devices. Relatively low performance
implemented on a simple processor which performs both control and packet devices may be implemented on a simple processor which performs both
forwarding functionality. ForCES is not applicable for such devices. control and packet forwarding functionality. ForCES is not
Higher performance devices typically distribute work amongst interface applicable for such devices.
processors, and these devices (FEs) therefore need to communicate with
the control element(s) to perform their job. ForCES provides a standard
way to do this communication.
The remainder of this section lists the applicable services which ForCES Higher performance devices typically distribute work amongst
may support, applicable FE functionality, applicable CE-FE link interface processors, and these devices (FEs) therefore need to
scenarios, and applicable topologies in which ForCES may be deployed. communicate with the control element(s) to perform their job.
ForCES provides a standard way to do this communication.
ForCES Applicability Statement Feb 2006
The remainder of this section lists the applicable services which
ForCES may support, applicable FE functionality, applicable CE-FE
link scenarios, and applicable topologies in which ForCES may be
deployed.
4.1. Applicable Services 4.1. Applicable Services
In this section we describe the applicability of ForCES for the In this section we describe the applicability of ForCES for the
following control-forwarding plane services: following control-forwarding plane services:
o Discovery, Capability Information Exchange o Discovery, Capability Information Exchange
o Topology Information Exchange o Topology Information Exchange
skipping to change at page 4, line 16 skipping to change at page 5, line 4
Discovery is the process by which CEs and FEs learn of each other's Discovery is the process by which CEs and FEs learn of each other's
existence. ForCES assumes that CEs and FEs already know sufficient existence. ForCES assumes that CEs and FEs already know sufficient
information to begin communication in a secure manner. information to begin communication in a secure manner.
The ForCES protocol is only applicable after CEs and FEs have found The ForCES protocol is only applicable after CEs and FEs have found
each other. ForCES makes no assumption about whether discovery was each other. ForCES makes no assumption about whether discovery was
performed using a dynamic protocol or merely static configuration. performed using a dynamic protocol or merely static configuration.
During the discovery phase, CEs and FEs may exchange capability During the discovery phase, CEs and FEs may exchange capability
information with each other. For example, the FEs may express the information with each other. For example, the FEs may express the
ForCES Applicability Statement Feb 2006
number of interface ports they provide, as well as the static and number of interface ports they provide, as well as the static and
configurable attributes of each port. configurable attributes of each port.
In addition to initial configuration, the CEs and FEs may also exchange In addition to initial configuration, the CEs and FEs may also
dynamic configuration changes using ForCES. For example, FE's exchange dynamic configuration changes using ForCES. For example,
asynchronously inform the CE of an increase/decrease in available FE's asynchronously inform the CE of an increase/decrease in
resources or capabilities on the FE. available resources or capabilities on the FE.
4.1.2. Topology Information Exchange 4.1.2. Topology Information Exchange
In this context, topology information relates to how the FEs are In this context, topology information relates to how the FEs are
interconnected with each other with respect to packet forwarding. interconnected with each other with respect to packet forwarding.
Whilst topology discovery is outside the scope of the ForCES protocol, a Whilst topology discovery is outside the scope of the ForCES
standard topology discovery protocol may be selected and used to "learn" protocol, a standard topology discovery protocol may be selected and
the topology, and then the ForCES protocol may be used to transmit the used to "learn" the topology, and then the ForCES protocol may be
resulting information to the CE. used to transmit the resulting information to the CE.
4.1.3. Configuration 4.1.3. Configuration
ForCES is used to perform FE configuration. For example, CEs set ForCES is used to perform FE configuration. For example, CEs set
configurable FE attributes such as IP addresses. configurable FE attributes such as IP addresses, etc. for their
interfaces.
4.1.4. Routing Exchange 4.1.4. Routing Exchange
ForCES may be used to deliver packet forwarding information resulting ForCES may be used to deliver packet forwarding information
from CE routing calculations. For example, CEs may send forwarding resulting from CE routing calculations. For example, CEs may send
table updates to the FEs, so that they can make forwarding decisions. forwarding table updates to the FEs, so that they can make
FEs may inform the CE in the event of a forwarding table miss. forwarding decisions. FEs may inform the CE in the event of a
forwarding table miss.
4.1.5. QoS Exchange 4.1.5. QoS Exchange
ForCES may be used to exchange QoS capabilities between CEs and FEs. ForCES may be used to exchange QoS capabilities between CEs and FEs.
For example, an FE may express QoS capabilities to the CE. Such For example, an FE may express QoS capabilities to the CE. Such
capabilities might include metering, policing, shaping, and queuing capabilities might include metering, policing, shaping, and queuing
functions. The CE may use ForCES to configure these capabilities. functions. The CE may use ForCES to configure these capabilities.
4.1.6. Security Exchange 4.1.6. Security Exchange
ForCES may be used to exchange Security information between CEs and FEs. ForCES may be used to exchange Security information between CEs and
For example, the FE may use ForCES to express the types of encryption FEs. For example, the FE may use ForCES to express the types of
that it is capable of using in an IPsec tunnel. The CE may use ForCES encryption that it is capable of using in an IPsec tunnel. The CE
to configure such a tunnel. may use ForCES to configure such a tunnel.
4.1.7. Filtering Exchange and Firewalls 4.1.7. Filtering Exchange and Firewalls
ForCES may be used to exchange filtering information. For example, FEs ForCES Applicability Statement Feb 2006
may use ForCES to express the filtering functions such as classification
and action that they can perform, and the CE may configure these ForCES may be used to exchange filtering information. For example,
capabilities. Fes may use ForCES to express the filtering functions such as
classification and action that they can perform, and the CE may
configure these capabilities.
4.1.8. Encapsulation, Tunneling Exchange 4.1.8. Encapsulation, Tunneling Exchange
ForCES may be used to exchange encapsulation capabilities of an FE, such ForCES may be used to exchange encapsulation capabilities of an FE,
as tunneling, and the configuration of such capabilities. such as tunneling, and the configuration of such capabilities.
4.1.9. NAT and Application-level Gateways 4.1.9. NAT and Application-level Gateways
ForCES may be used to exchange configuration information for Network ForCES may be used to exchange configuration information for Network
Address Translators. Whilst ForCES is not specifically designed for the Address Translators. Whilst ForCES is not specifically designed for
configuration of application-level gateway functionality, this may be in the configuration of application-level gateway functionality, this
scope for some types of application-level gateways. may be in scope for some types of application-level gateways.
4.1.10. Measurement and Accounting 4.1.10. Measurement and Accounting
ForCES may be used to exchange configuration information regarding ForCES may be used to exchange configuration information regarding
traffic measurement and accounting functionality. In this area, ForCES traffic measurement and accounting functionality. In this area,
may overlap somewhat with functionality provided by alternative network ForCES may overlap somewhat with functionality provided by
management mechanisms such as SNMP. In some cases ForCES may be used to alternative network management mechanisms such as SNMP. In some
convey information to the CE to be reported externally using SNMP. cases ForCES may be used to convey information to the CE to be
However, in other cases it may make more sense for the FE to directly reported externally using SNMP. However, in other cases it may make
speak SNMP. more sense for the FE to directly speak SNMP.
4.1.11. Diagnostics 4.1.11. Diagnostics
ForCES may be used for CE's and FE's to exchange diagnostic information. ForCES may be used for CE's and FE's to exchange diagnostic
For example, an FE can send self-test results to the CE. information. For example, an FE can send self-test results to the
CE.
4.1.12. CE Redundancy or CE Failover 4.1.12. CE Redundancy or CE Failover
ForCES is a master-slave protocol where FE's are slaves and CE's are ForCES is a master-slave protocol where FE's are slaves and CE's are
masters. Basic mechanisms for CE redundancy/failover are provided in masters. Basic mechanisms for CE redundancy/failover are provided
ForCES protocol. Broad concepts such as implementing CE Redundancy, CE in ForCES protocol. Broad concepts such as implementing CE
Failover, and CE-CE communication, while not precluded by the ForCES Redundancy, CE Failover, and CE-CE communication, while not
architecture, are considered outside the scope of ForCES protocol. precluded by the ForCES architecture, are considered outside the
ForCES protocol is designed to handle CE-FE communication, and is not scope of ForCES protocol. ForCES protocol is designed to handle CE-
intended for CE-CE communication. FE communication, and is not intended for CE-CE communication.
4.2. CE-FE Link Capacity 4.2.CE-FE Link Capability
When using ForCES, the bandwidth of the CE-FE link is a consideration, When using ForCES, the bandwidth of the CE-FE link is a
and cannot be ignored. For example, sending a full routing table of consideration, and cannot be ignored. For example, sending a full
110K routes is reasonable over a 100Mbit Ethernet interconnect, but routing table of 110K routes is reasonable over a 100Mbit Ethernet
could be non-trivial over a lower-bandwidth link. ForCES should be
sufficiently future-proof to be applicable in scenarios where routing ForCES Applicability Statement Feb 2006
tables grow to several orders of magnitude greater than their current
size (approximately 100K routes). However, we also note that not all IP interconnect, but could be non-trivial over a lower-bandwidth link.
routers need full routing tables. ForCES should be sufficiently future-proof to be applicable in
scenarios where routing tables grow to several orders of magnitude
greater than their current size (approximately 100K routes).
However, we also note that not all IP routers need full routing
tables.
4.3. CE/FE Locality 4.3. CE/FE Locality
We do not intend ForCES to be applicable in configurations where the CE We do not intend ForCES to be applicable in configurations where the
and FE are located arbitrarily in the network. In particular, ForCES is CE and FE are located arbitrarily in the network. In particular,
intended for environments where one of the following applies: ForCES is intended for environments where one of the following
applies:
o The control interconnect is some form of local bus, switch, or LAN, o The control interconnect is some form of local bus, switch, or
where reliability is high, closely controlled, and not susceptible LAN, where reliability is high, closely controlled, and not
to external disruption that does not also affect the CEs and/or susceptible to external disruption that does not also affect the CEs
FEs. and/or FEs.
o The control interconnect shares fate with the FE's forwarding o The control interconnect shares fate with the FE's forwarding
function. Typically this is because the control connection is also function. Typically this is because the control connection is also
the FE's primary packet forwarding connection, and so if that link the FE's primary packet forwarding connection, and so if that link
goes down, the FE cannot forward packets anyway. goes down, the FE cannot forward packets anyway.
The key guideline is that the reliability of the device should not be The key guideline is that the reliability of the device should not
significantly reduced by the separation of control and forwarding be significantly reduced by the separation of control and forwarding
functionality. functionality.
ForCES is applicable in localities consisting of control and forwarding ForCES is applicable in localities consisting of control and
elements which are either components in the same physical box, or are forwarding elements which are either components in the same physical
separated at most by one local network hop (historically referred to as box, or are separated at most by one local network hop (historically
"Very Close" localities). referred to as "Very Close" localities).
Example: a network element with a single control blade, and one or more Example: a network element with a single control blade, and one or
forwarding blades, all present in the same chassis and sharing an more forwarding blades, all present in the same chassis and sharing
interconnect such as Ethernet or PCI. In this locality, the majority of an interconnect such as Ethernet or PCI. In this locality, the
the data traffic being forwarded typically does not traverse the same majority of the data traffic being forwarded typically does not
links as the ForCES control traffic. traverse the same links as the ForCES control traffic.
5. Limitations and Out-of-Scope Items 5. Limitations and Out-of-Scope Items
ForCES was designed to enable logical separation of control and ForCES was designed to enable logical separation of control and
forwarding planes in IP network devices. However, ForCES is not forwarding planes in IP network devices. However, ForCES is not
intended to be applicable to all services or to all possible CE/FE intended to be applicable to all services or to all possible CE/FE
localities. localities.
The purpose of this section is to list limitations and out-of-scope The purpose of this section is to list limitations and out-of-scope
items for ForCES. items for ForCES.
ForCES Applicability Statement Feb 2006
5.1. Out of Scope Services 5.1. Out of Scope Services
The following control-forwarding plane services are explicitly not The following control-forwarding plane services are explicitly not
addressed by ForCES: addressed by ForCES:
o Label Switching o Label Switching
o Multimedia Gateway Control (MEGACO). o Multimedia Gateway Control (MEGACO).
5.1.1. Label Switching 5.1.1. Label Switching
Label Switching is the purview of the GSMP Working Group in the Sub- IP Label Switching is the purview of the GSMP Working Group in the Sub-
Area of the IETF. GSMP is a general purpose protocol to control a label IP Area of the IETF. GSMP is a general purpose protocol to control
switch. GSMP defines mechanisms to separate the label switch data plane a label switch. GSMP defines mechanisms to separate the label
from the control plane label protocols such as LDP [5]. For more switch data plane from the control plane label protocols such as LDP
information on GSMP, see [4]. [8]. For more information on GSMP, see [7].
5.1.2. Separation of Control and Forwarding in Multimedia Gateways" 5.1.2.Separation of Control and Forwarding in Multimedia Gateways
MEGACO defines a protocol used between elements of a physically MEGACO defines a protocol used between elements of a physically
decomposed multimedia gateway. Separation of call control channels from decomposed multimedia gateway. Separation of call control channels
bearer channels is the purview of MEGACO. For more information on from bearer channels is the purview of MEGACO. For more information
MEGACO, see [7]. on MEGACO, see [9].
5.2. Localities 5.2. Localities
ForCES protocol was intended to work within the localities described in ForCES protocol was intended to work within the localities described
the last section. Outside these boundaries, care must be taken or the in the last section. Outside these boundaries, care must be taken
protocol may not work right. Examples of localities where ForCES was or the protocol may not work right. Examples of localities where
not originally intended to be used: ForCES was not originally intended to be used:
o Localities where there are multiple hops between CE and FE. o Localities where there are multiple hops between CE and FE.
o Localities where hops between the CE and FE are dynamically routing o Localities where hops between the CE and FE are dynamically
using IP routing protocols. routing using IP routing protocols.
o Localities where the loss of the CE-FE link is of non-negligible o Localities where the loss of the CE-FE link is of non-
probability. negligible probability.
o Localities where two or more FEs controlled by the same CE cannot o Localities where two or more FEs controlled by the same CE
communicate, either directly, or indirectly via other FEs cannot communicate, either directly, or indirectly via other Fes
controlled by the same CE. controlled by the same CE.
6. Security Considerations 6. Security Considerations
The security of ForCES protocol will be addressed in the Protocol The security of ForCES protocol will be addressed in the Protocol
Specification [2]. For security requirements, see architecture Specification [6]. For security requirements, see architecture
ForCES Applicability Statement Feb 2006
requirement #5 and protocol requirement #2 in the Requirements Draft requirement #5 and protocol requirement #2 in the Requirements Draft
[1]. The ForCES protocol assumes that the CE and FE are in the same [3]. The ForCES protocol assumes that the CE and FE are in the same
administration, and have shared secrets as a means of administration. administration, and have shared secrets as a means of
Whilst it might be technically feasible to have the CE and FE administration. Whilst it might be technically feasible to have the
administered independently, we strongly discourage such uses, because CE and FE administered independently, we strongly discourage such
they would require a significantly different trust model from that uses, because they would require a significantly different trust
ForCES assumes. model from that ForCES assumes.
7. Normative 7. Manageability
TBD
[1] Anderson, T et. al., "Requirements for Separation of IP Control and 8. References
Forwarding", draft-ietf-forces-requirements-09.txt, May 2003 8.1.Normative References
[2] ForCES Protocol Specification (to-be-written) 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026,
October 1996.
8. Informative 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement
Levels", RFC2119 (BCP), IETF, March 1997.
[3] Salim, J e. al., "Netlink as an IP Services Protocol", draft-ietf- 3. Khosravi, et al., ’’Requirements for Separation of IP Control and
forces-netlink-04.txt, December 2002 Forwarding”, RFC 3654, November 2003.
[4] Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General Switch 4. L. Yang, et al., ” ForCES Architectural Framework”, RFC 3746,
Management Protocol (GSMP) V3" RFC 3292, June 2002 April 2004.
[5] Andersson et al., "LDP Specification" RFC 3036, January 2001 5. Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.,and S.
Blake, "ForCES Forwarding Element Model", Feb. 2005.
[6] Bradner, S, "Key words for use in RFCs to Indicate Requirement 6. A. Doria, et al., ”ForCES Protocol Specification”, draft-ietf-
Levels", RFC 2119, Harvard University, March 1997 forces-protocol-06.txt, December 2005.
[7] F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November 8.2.Informative References
7. A. Doria, F. Hellstrand, K. Sundell, T. Worster, “General Switch
Management Protocol (GSMP) V3”, RFC 3292, June 2002.
8. Andersson et al., "LDP Specification" RFC 3036, January 2001
9. F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November
2000 2000
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Jamal Hadi Salim, Avri Doria, Vip
The authors wish to thank Jamal Hadi Salim, Hormuzd Khosravi, Vip
Sharma, and many others for their invaluable contributions. Sharma, and many others for their invaluable contributions.
10. Author's Addresses ForCES Applicability Statement Feb 2006
10. Authors' Addresses
Alan Crouch Alan Crouch
Intel Intel
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 USA Hillsboro, OR 97124 USA
Phone: +1 503 264 2196 Phone: +1 503 264 2196
Email: alan.crouch@intel.com Email: alan.crouch@intel.com
Hormuzd Khosravi
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: 1-503-264-0334
Email: hormuzd.m.khosravi@intel.com
Mark Handley Mark Handley
ICIR ICIR
1947 Center Street, Suite 600 1947 Center Street, Suite 600
Berkeley, CA 94708, USA Berkeley, CA 94708, USA
Email: mjh@icsi.berkeley.edu Email: mjh@icsi.berkeley.edu
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
 End of changes. 56 change blocks. 
158 lines changed or deleted 255 lines changed or added

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