draft-ietf-forces-applicability-03.txt   draft-ietf-forces-applicability-04.txt 
Alan Crouch Alan Crouch
Internet Draft Hormuzd Khosravi Internet Draft Hormuzd Khosravi
Document: draft-ietf-forces-applicability- Intel Corp. Document: draft-ietf-forces-applicability- Intel Corp.
03.txt 04.txt
Expires: July 2006 Mark Handley Expires: July 2006 Mark Handley
Working Group: ForCES ICIR Working Group: ForCES ICIR
Avri Doria
ETRI
Feb 2006 Feb 2006
ForCES Applicability Statement ForCES Applicability Statement
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 have been or will be disclosed, and any of which he or she becomes
skipping to change at page 2, line 16 skipping to change at page 2, line 16
The ForCES protocol defines a standard framework and mechanism for The ForCES protocol defines a standard framework and mechanism for
the interconnection between Control Elements and Forwarding Elements the interconnection between Control Elements and Forwarding Elements
in IP routers and similar devices. In this document we describe the in IP routers and similar devices. In this document we describe the
applicability of the ForCES model and protocol. We provide example applicability of the ForCES model and protocol. We provide example
deployment scenarios and functionality, as well as document deployment scenarios and functionality, as well as document
applications that would be inappropriate for ForCES. applications that would be inappropriate for ForCES.
Table of Contents Table of Contents
1. Purpose.........................................................2 1. Purpose.........................................................3
2. Overview........................................................3 2. Overview........................................................3
3. Terminology.....................................................3 3. Terminology.....................................................3
4. Applicability to IP Networks....................................3 4. Applicability to IP Networks....................................3
4.1. Applicable Services...........................................4 4.1. Applicable Services...........................................4
4.1.1. Discovery, Capability Information Exchange..................4 4.1.1. Discovery, Capability Information Exchange..................4
4.1.2. Topology Information Exchange...............................5 4.1.2. Topology Information Exchange...............................5
4.1.3. Configuration...............................................5 4.1.3. Configuration...............................................5
4.1.4. Routing Exchange............................................5 4.1.4. Routing Exchange............................................5
4.1.5. QoS Exchange................................................5 4.1.5. QoS Exchange................................................5
4.1.6. Security Exchange...........................................5 4.1.6. Security Exchange...........................................5
4.1.7. Filtering Exchange and Firewalls............................5 4.1.7. Filtering Exchange and Firewalls............................6
4.1.8. Encapsulation, Tunneling Exchange...........................6 4.1.8. Encapsulation, Tunneling Exchange...........................6
4.1.9. NAT and Application-level Gateways..........................6 4.1.9. NAT and Application-level Gateways..........................6
4.1.10. Measurement and Accounting.................................6 4.1.10. Measurement and Accounting.................................6
4.1.11. Diagnostics................................................6 4.1.11. Diagnostics................................................6
4.1.12. CE Redundancy or CE Failover...............................6 4.1.12. CE Redundancy or CE Failover...............................6
4.2. CE-FE Link Capability.........................................6 4.2. CE-FE Link Capability.........................................7
4.3. CE/FE Locality................................................7 4.3. CE/FE Locality................................................7
5. Limitations and Out-of-Scope Items..............................7 5. Limitations and Out-of-Scope Items..............................7
5.1. Out of Scope Services.........................................8 5.1. Out of Scope Services.........................................8
5.1.1. Label Switching.............................................8 5.1.1. Label Switching.............................................8
5.1.2. Separation of Control and Forwarding in Multimedia Gateways.8 5.1.2. Separation of Control and Forwarding in Multimedia Gateways.8
5.2. Localities....................................................8 5.2. Localities....................................................8
6. Security Considerations.........................................8 6. Security Considerations.........................................9
7. Manageability...................................................9 7. ForCES Manageability............................................9
8. References......................................................9 7.1. NE as an atomic element.......................................9
8.1. Normative References..........................................9 7.2. NE as composed of manageable elements.........................9
8.2. Informative References........................................9 7.3. ForCES Protocol MIB..........................................10
9. Acknowledgments.................................................9 7.3.1. MIB Management of an FE....................................10
10. Authors' Addresses............................................10 7.4. The FEM and CEM..............................................11
8. References.....................................................11
8.1. Normative References.........................................11
8.2. Informative References.......................................12
9. Acknowledgments................................................12
10. Authors' Addresses............................................12
ForCES Applicability Statement Feb 2006
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 intent of the ForCES protocol designers as to how the protocol
ForCES Applicability Statement Feb 2006
should be used. The Applicability Statement will evolve alongside should be used. The Applicability Statement will evolve alongside
the protocol, and will go to RFC as informational around the same the protocol, and will go to RFC as informational around the same
time the as the protocol goes to RFC. time the as the protocol goes to RFC.
2. Overview 2. Overview
The ForCES protocol defines a standard framework and mechanism for The ForCES protocol defines a standard framework and mechanism for
the exchange of information between the logically separate the exchange of information between the logically separate
functionality of the control and data forwarding planes of IP functionality of the control and data forwarding planes of IP
routers and similar devices. It focuses on the communication routers and similar devices. It focuses on the communication
skipping to change at page 3, line 47 skipping to change at page 4, line 5
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 The purpose of this section is to list the areas of ForCES
applicability in IP network devices. Relatively low performance applicability in IP network devices. Relatively low performance
devices may be implemented on a simple processor which performs both devices may be implemented on a simple processor which performs both
control and packet forwarding functionality. ForCES is not control and packet forwarding functionality. ForCES is not
applicable for such devices. applicable for such devices.
ForCES Applicability Statement Feb 2006
Higher performance devices typically distribute work amongst Higher performance devices typically distribute work amongst
interface processors, and these devices (FEs) therefore need to interface processors, and these devices (FEs) therefore need to
communicate with the control element(s) to perform their job. communicate with the control element(s) to perform their job.
ForCES provides a standard way to do this communication. ForCES provides a standard way to do this communication.
ForCES Applicability Statement Feb 2006
The remainder of this section lists the applicable services which The remainder of this section lists the applicable services which
ForCES may support, applicable FE functionality, applicable CE-FE ForCES may support, applicable FE functionality, applicable CE-FE
link scenarios, and applicable topologies in which ForCES may be link scenarios, and applicable topologies in which ForCES may be
deployed. 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:
skipping to change at page 4, line 46 skipping to change at page 5, line 4
o Diagnostics o Diagnostics
o CE Redundancy or CE Failover o CE Redundancy or CE Failover
4.1.1.Discovery, Capability Information Exchange 4.1.1.Discovery, Capability Information Exchange
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.
ForCES Applicability Statement Feb 2006
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 In addition to initial configuration, the CEs and FEs may also
exchange dynamic configuration changes using ForCES. For example, exchange dynamic configuration changes using ForCES. For example,
FE's asynchronously inform the CE of an increase/decrease in FE's asynchronously inform the CE of an increase/decrease in
available 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
skipping to change at page 5, line 49 skipping to change at page 6, line 4
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 ForCES may be used to exchange Security information between CEs and
FEs. For example, the FE may use ForCES to express the types of FEs. For example, the FE may use ForCES to express the types of
ForCES Applicability Statement Feb 2006
encryption that it is capable of using in an IPsec tunnel. The CE encryption that it is capable of using in an IPsec tunnel. The CE
may use ForCES 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 Applicability Statement Feb 2006
ForCES may be used to exchange filtering information. For example, ForCES may be used to exchange filtering information. For example,
Fes may use ForCES to express the filtering functions such as Fes may use ForCES to express the filtering functions such as
classification and action that they can perform, and the CE may classification and action that they can perform, and the CE may
configure these capabilities. 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, ForCES may be used to exchange encapsulation capabilities of an FE,
such as tunneling, and the configuration of such capabilities. such as tunneling, and the configuration of such capabilities.
skipping to change at page 6, line 50 skipping to change at page 7, line 5
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 masters. Basic mechanisms for CE redundancy/failover are provided
in ForCES protocol. Broad concepts such as implementing CE in ForCES protocol. Broad concepts such as implementing CE
Redundancy, CE Failover, and CE-CE communication, while not Redundancy, CE Failover, and CE-CE communication, while not
precluded by the ForCES architecture, are considered outside the precluded by the ForCES architecture, are considered outside the
scope of ForCES protocol. ForCES protocol is designed to handle CE- scope of ForCES protocol. ForCES protocol is designed to handle CE-
FE communication, and is not intended for CE-CE communication. FE communication, and is not intended for CE-CE communication.
ForCES Applicability Statement Feb 2006
4.2.CE-FE Link Capability 4.2.CE-FE Link Capability
When using ForCES, the bandwidth of the CE-FE link is a When using ForCES, the bandwidth of the CE-FE link is a
consideration, and cannot be ignored. For example, sending a full consideration, and cannot be ignored. For example, sending a full
routing table of 110K routes is reasonable over a 100Mbit Ethernet routing table of 110K routes is reasonable over a 100Mbit Ethernet
ForCES Applicability Statement Feb 2006
interconnect, but could be non-trivial over a lower-bandwidth link. interconnect, but could be non-trivial over a lower-bandwidth link.
ForCES should be sufficiently future-proof to be applicable in ForCES should be sufficiently future-proof to be applicable in
scenarios where routing tables grow to several orders of magnitude scenarios where routing tables grow to several orders of magnitude
greater than their current size (approximately 100K routes). greater than their current size (approximately 100K routes).
However, we also note that not all IP routers need full routing However, we also note that not all IP routers need full routing
tables. tables.
4.3.CE/FE Locality 4.3.CE/FE Locality
We do not intend ForCES to be applicable in configurations where the We do not intend ForCES to be applicable in configurations where the
skipping to change at page 7, line 50 skipping to change at page 8, line 4
Example: a network element with a single control blade, and one or Example: a network element with a single control blade, and one or
more forwarding blades, all present in the same chassis and sharing more forwarding blades, all present in the same chassis and sharing
an interconnect such as Ethernet or PCI. In this locality, the an interconnect such as Ethernet or PCI. In this locality, the
majority of the data traffic being forwarded typically does not majority of the data traffic being forwarded typically does not
traverse the same 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
ForCES Applicability Statement Feb 2006
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
skipping to change at page 8, line 50 skipping to change at page 9, line 5
o Localities where hops between the CE and FE are dynamically o Localities where hops between the CE and FE are dynamically
routing using IP routing protocols. routing using IP routing protocols.
o Localities where the loss of the CE-FE link is of non- o Localities where the loss of the CE-FE link is of non-
negligible probability. negligible probability.
o Localities where two or more FEs controlled by the same CE o Localities where two or more FEs controlled by the same CE
cannot 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.
ForCES Applicability Statement Feb 2006
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 [6]. 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
[3]. 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, and have shared secrets as a means of
administration. Whilst it might be technically feasible to have the administration. Whilst it might be technically feasible to have the
CE and FE administered independently, we strongly discourage such CE and FE administered independently, we strongly discourage such
uses, because they would require a significantly different trust uses, because they would require a significantly different trust
model from that ForCES assumes. model from that ForCES assumes.
7. Manageability 7. ForCES Manageability
TBD From the management perspective, an NE can be viewed in at least two
ways. From one perspective, it is a single network element,
specifically a router that needs to be managed in essentially the
same way any router is managed. From another perspective element
management can view the individual entities and interfaces that make
of a ForCES NE.
7.1.NE as an atomic element
From the ForCES requirements RFC [RFC 3654], Section 4, point 4:
A NE MUST support the appearance of a single functional device.
As a single functional device a ForCES NE runs protocols and each of
the protocols has it own existing manageability aspects which are
document elsewhere. As a router it would also have a configuration
interface. When viewed in this manner, the NE is controlled as
single routing entity and no new management beyond what is already
available for routers and routing protocols would be required for a
ForCES NE.
7.2.NE as composed of manageable elements
When viewed as a decomposed set of elements from the management
perspective, the ForCES NE is divided into a set of one of more
Control Elements, Forwarding Elements and the interfaces between
them. The interface functionality between the CE and the FE is
provided by the ForCES protocol. As with all IETF protocols a MIB
is provided for the purposes of managing the protocol.
Additionally the architecture make provision for configuration
control of the individual CEs and FEs. This is handled by elements
names FE manager and the CE manager. Specifically from the ForCES
requirements
ForCES Applicability Statement Feb 2006
RFC [RFC 3654], Section 4, point 4:
However, external entities (e.g., FE managers and CE managers) MAY
have direct access to individual ForCES protocol elements for
providing information to transition them from the pre-association to
post-association phase.
7.3.ForCES Protocol MIB
From the ForCES MIB RFC [TBD], section X
The ForCES MIB is a primarily read-only MIB that captures
information related to the ForCES protocol. This includes state
information about the associations between CE(s) and FE(s) in the
NE.
The ForCES MIB does not include information that is specified in
other MIBs, such as packet counters for interfaces, etc.
More specifically, the information in the ForCES MIB relative to
associations includes:
- identifiers of the elements in the association
- state of the association
- configuration parameters of the association
- statistics of the association
7.3.1.MIB Management of an FE
While it is possible to manage a FE from a element manager, several
requirements relating to this have been included in the ForCES
Requirements.
From the ForCES Requirements [RFC 3654], Section 4, point 14:
1. The ability for a management tool (e.g., SNMP) to be used to read
(but not change) the state of FE SHOULD NOT be precluded.
2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to
change the state of a FE in a manner that affects overall NE
behavior without the CE being notified.
The ForCES Requirements [RFC 3746], Section 5.7, goes further in
discussing the manner in which FEs should handle management requests
that are specifically directed to the FE:
RFC 1812 [2] also dictates that "Routers MUST be manageable by
SNMP". In general, for the post-association phase, most external
ForCES Applicability Statement Feb 2006
management tasks (including SNMP) should be done through interaction
with the CE in order to support the appearance of a single
functional device. Therefore, it is recommended that an SNMP agent
be implemented by CEs and that the SNMP messages received by FEs be
redirected to their CEs. AgentX framework defined in RFC 2741 ([6])
may be applied here such that CEs act in the role of master agent to
process SNMP protocol messages while FEs act in the role of subagent
to provide access to the MIB objects residing on FEs. AgentX
protocol messages between the master agent (CE) and the subagent
(FE) are encapsulated and transported via ForCES, just like data
packets from any other application layer protocols.
7.4.The FEM and CEM
Though out of scope for the initial ForCES specification effort, the
ForCES architecture include two entities, the CE Manager (CEM) and
the FE Manager (FEM)
From the ForCES Protocols Specification [RFCXXXX]
CE Manager (CEM) - A logical entity responsible for generic CE
management tasks. It is particularly used during the pre-
association phase to determine with which FE(s) a CE should
communicate.
FE Manager (FEM) - A logical entity responsible for generic FE
management tasks. It is used during pre-association phase to
determine with which CE(s) an FE should communicate.
8. References 8. References
8.1.Normative References 8.1.Normative References
1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026, 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026,
October 1996. October 1996.
2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement
Levels", RFC2119 (BCP), IETF, March 1997. Levels", RFC2119 (BCP), IETF, March 1997.
3. Khosravi, et al., ’’Requirements for Separation of IP Control and 3. Khosravi, et al., ’’Requirements for Separation of IP Control and
Forwarding”, RFC 3654, November 2003. Forwarding”, RFC 3654, November 2003.
4. L. Yang, et al., ” ForCES Architectural Framework”, RFC 3746, 4. L. Yang, et al., ” ForCES Architectural Framework”, RFC 3746,
April 2004. April 2004.
ForCES Applicability Statement Feb 2006
5. Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.,and S. 5. Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.,and S.
Blake, "ForCES Forwarding Element Model", Feb. 2005. Blake, "ForCES Forwarding Element Model", Feb. 2005.
6. A. Doria, et al., ”ForCES Protocol Specification”, draft-ietf- 6. A. Doria, et al., ”ForCES Protocol Specification”, draft-ietf-
forces-protocol-06.txt, December 2005. forces-protocol-06.txt, December 2005.
8.2.Informative References 8.2.Informative References
7. A. Doria, F. Hellstrand, K. Sundell, T. Worster, “General Switch 7. A. Doria, F. Hellstrand, K. Sundell, T. Worster, “General Switch
Management Protocol (GSMP) V3”, RFC 3292, June 2002. Management Protocol (GSMP) V3”, RFC 3292, June 2002.
8. Andersson et al., "LDP Specification" RFC 3036, January 2001 8. Andersson et al., "LDP Specification" RFC 3036, January 2001
9. F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November 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, Vip Sharma, and many
Sharma, and many others for their invaluable contributions. others for their invaluable contributions.
ForCES Applicability Statement Feb 2006
10. Authors' Addresses 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
skipping to change at page 10, line 29 skipping to change at page 12, line 49
Hillsboro, OR 97124 Hillsboro, OR 97124
Phone: 1-503-264-0334 Phone: 1-503-264-0334
Email: hormuzd.m.khosravi@intel.com 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
Avri Doria
ETRI
Lulea University of Technology
Lulea, Sweden
ForCES Applicability Statement Feb 2006
Phone: +46 73 277 1788
Email: avri@acm.org
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
 End of changes. 23 change blocks. 
35 lines changed or deleted 166 lines changed or added

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