draft-ietf-forces-applicability-05.txt   draft-ietf-forces-applicability-06.txt 
Alan Crouch forces A. Crouch
Internet Draft Hormuzd Khosravi Internet-Draft H. Khosravi
Document: draft-ietf-forces-applicability- Intel Corp. Intended status: Informational Intel
05.txt Expires: January 3, 2010 A. Doria
Expires: January 2007 Mark Handley LTU
Working Group: ForCES ICIR X. Wang
Avri Doria Huawei
ETRI K. Ogawa
NTT Corporation
July 2, 2009
ForCES Applicability Statement ForCES Applicability Statement
draft-ietf-forces-applicability-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as ``work in material or to cite them other than as "work in progress."
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 This Internet-Draft will expire on January 3, 2010.
Copyright (C) The Internet Society (2006). Copyright Notice
Conventions used in this document Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document is subject to BCP 78 and the IETF Trust's Legal
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in Provisions Relating to IETF Documents in effect on the date of
this document are to be interpreted as described in [2]. publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
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........................................................3 1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview.......................................................3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology....................................................3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability to IP Networks...................................3 4. Applicability to IP Networks . . . . . . . . . . . . . . . . . 4
4.1. Applicable Services.........................................4 4.1. Applicable Services . . . . . . . . . . . . . . . . . . . 5
4.1.1. Discovery, Capability Information Exchange................4 4.1.1. Discovery, Capability Information Exchange . . . . . . 5
4.1.2. Topology Information Exchange.............................5 4.1.2. Topology Information Exchange . . . . . . . . . . . . 6
4.1.3. Configuration.............................................5 4.1.3. Configuration . . . . . . . . . . . . . . . . . . . . 6
4.1.4. Routing Exchange..........................................5 4.1.4. Routing Exchange . . . . . . . . . . . . . . . . . . . 6
4.1.5. QoS Exchange..............................................5 4.1.5. QoS Exchange . . . . . . . . . . . . . . . . . . . . . 6
4.1.6. Security Exchange.........................................5 4.1.6. Security Exchange . . . . . . . . . . . . . . . . . . 6
4.1.7. Filtering Exchange and Firewalls..........................6 4.1.7. Filtering Exchange and Firewalls . . . . . . . . . . . 7
4.1.8. Encapsulation, Tunneling Exchange.........................6 4.1.8. Encapsulation, Tunneling Exchange . . . . . . . . . . 7
4.1.9. NAT and Application-level Gateways........................6 4.1.9. NAT and Application-level Gateways . . . . . . . . . . 7
4.1.10. Measurement and Accounting................................6 4.1.10. Measurement and Accounting . . . . . . . . . . . . . . 7
4.1.11. Diagnostics...............................................6 4.1.11. Diagnostics . . . . . . . . . . . . . . . . . . . . . 7
4.1.12. CE Redundancy or CE Failover..............................6 4.1.12. CE Redundancy or CE Failover . . . . . . . . . . . . . 7
4.2. CE-FE Link Capability.......................................7 4.2. CE-FE Link Capability . . . . . . . . . . . . . . . . . . 7
4.3. CE/FE Locality..............................................7 4.3. CE/FE Locality . . . . . . . . . . . . . . . . . . . . . . 8
5. Limitations and Out-of-Scope Items.............................7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Out of Scope Services.......................................8 6. ForCES Manageability . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Label Switching...........................................8 6.1. NE as an atomic element . . . . . . . . . . . . . . . . . 9
5.1.2. Separation of Control and Forwarding in Multimedia Gateways8 6.2. NE as composed of manageable elements . . . . . . . . . . 9
5.2. Localities..................................................8 6.3. ForCES Protocol MIB . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations........................................9 6.3.1. MIB Management of an FE . . . . . . . . . . . . . . . 10
7. ForCES Manageability...........................................9 6.4. The FEM and CEM . . . . . . . . . . . . . . . . . . . . . 11
7.1. NE as an atomic element.....................................9 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. NE as composed of manageable elements.......................9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. ForCES Protocol MIB........................................10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3.1. MIB Management of an FE..................................10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.4. CE to CE communication.....................................11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
7.5. The FEM and CEM............................................11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
8. References....................................................12
8.1. Normative References.......................................12
8.2. Informative References.....................................12
9. Acknowledgments...............................................12
10. Authors' Addresses..........................................12
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 [I-D.ietf-forces-protocol] designers as
should be used. The Applicability Statement will evolve alongside to how the protocol could be used (in conjunction with the ForCES
the protocol, and will go to RFC as informational around the same model [I-D.ietf-forces-model]).
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
routers and similar devices. It focuses on the communication and similar devices. It focuses on the communication necessary for
necessary for separation of control plane functionality such as separation of control plane functionality such as routing protocols,
routing protocols, signaling protocols, and admission control from signaling protocols, and admission control from data forwarding plane
data forwarding plane per-packet activities such as packet per-packet activities such as packet forwarding, queuing, and header
forwarding, queuing, and header editing. 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 3. Terminology
A set of terminology associated with ForCES is defined in [3, 4]. 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] That terminology is reused here and the reader is directed to [3, 4]
for the following definitions: 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.
o TML: Transport Mapping Layer.
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 end routing
devices may be implemented on a simple processor which performs both systems may be implemented on simple hardware which performs both
control and packet forwarding functionality. ForCES is not control and packet forwarding functionality. ForCES may not make
applicable for such devices. sense for such devices.
Higher performance devices typically distribute work amongst Higher end routing systems typically distribute work amongst
interface processors, and these devices (FEs) therefore need to interface processing elements, and these devices (FEs) therefore need
communicate with the control element(s) to perform their job. to 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.
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
skipping to change at page 5, line 4 skipping to change at page 5, line 45
o NAT and Application-level Gateways o NAT and Application-level Gateways
o Measurement and Accounting o Measurement and Accounting
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. The ForCES
The ForCES protocol is only applicable after CEs and FEs have found protocol is only applicable after CEs and FEs have found each other.
each other. ForCES makes no assumption about whether discovery was ForCES makes no assumption about whether discovery was performed
performed using a dynamic protocol or merely static configuration. 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 exchange capability
information with each other. For example, the FEs may express the information with each other. For example, the FEs express the number
number of interface ports they provide, as well as the static and 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 also exchange
exchange dynamic configuration changes using ForCES. For example, dynamic configuration changes using ForCES. For example, FEs
FE's asynchronously inform the CE of an increase/decrease in asynchronously inform the CE of an increase/decrease in available
available resources or capabilities on the FE. 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 Topology discovery is outside the scope of the ForCES protocol. An
protocol, a standard topology discovery protocol may be selected and implementation can choose its own method of topology discovery(for
used to "learn" the topology, and then the ForCES protocol may be example use a standard topology discovery portocol like LLDP, BFD;or
used to transmit the resulting information to the CE. apply a static topology configuration policy).Once the topology is
established, ForCES protocol may be 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, etc. for their configurable FE attributes such as IP addresses, etc. for their
interfaces. interfaces.
4.1.4. Routing Exchange 4.1.4. Routing Exchange
ForCES may be used to deliver packet forwarding information ForCES may be used to deliver packet forwarding information resulting
resulting from CE routing calculations. For example, CEs may send from CE routing calculations. For example, CEs may send forwarding
forwarding table updates to the FEs, so that they can make table updates to the FEs, so that they can make forwarding decisions.
forwarding decisions. FEs may inform the CE in the event of a FEs may inform the CE in the event of a forwarding table miss.
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 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
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 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.
4.1.9. NAT and Application-level Gateways 4.1.9. NAT and Application-level Gateways
skipping to change at page 6, line 35 skipping to change at page 7, line 31
the configuration of application-level gateway functionality, this the configuration of application-level gateway functionality, this
may be in 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, traffic measurement and accounting functionality. In this area,
ForCES may overlap somewhat with functionality provided by ForCES may overlap somewhat with functionality provided by
alternative network management mechanisms such as SNMP. In some alternative network management mechanisms such as SNMP. In some
cases ForCES may be used to convey information to the CE to be cases ForCES may be used to convey information to the CE to be
reported externally using SNMP. However, in other cases it may make reported externally using 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 ForCES may be used for CEs and FEs to exchange diagnostic
information. For example, an FE can send self-test results to the information. For example, an FE can send self-test results to the
CE. 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 CE failover and redundancy are out of scope in the initial version of
masters. Basic mechanisms for CE redundancy/failover are provided ForCES protocol. Basic mechanisms for CE redundancy/failover are not
in ForCES protocol. Broad concepts such as implementing CE presently implemented. 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
precluded by the ForCES architecture, are considered outside the by the ForCES architecture, are considered outside the scope of
scope of ForCES protocol. ForCES protocol is designed to handle CE- ForCES protocol. ForCES protocol is designed to handle CE- FE
FE communication, and is not intended for CE-CE communication. communication, and is not intended for CE-CE communication.
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
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. However, we also note that not all
However, we also note that not all IP routers need full routing 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
CE and FE are located arbitrarily in the network. In particular,
ForCES is intended for environments where one of the following ForCES is intended for environments where one of the following
applies: applies:
o The control interconnect is some form of local bus, switch, or o The control interconnect is some form of local bus, switch, or LAN,
LAN, where reliability is high, closely controlled, and not where reliability is high, closely controlled, and not susceptible to
susceptible to external disruption that does not also affect the CEs external disruption that does not also affect the CEs and/or 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 The key guideline is that the reliability of the device should not be
be significantly reduced by the separation of control and forwarding significantly reduced by the separation of control and forwarding
functionality. functionality.
ForCES is applicable in localities consisting of control and Taking this into account, ForCES is applicable in the following CE/FE
forwarding elements which are either components in the same physical localities:
box, or are separated at most by one local network hop (historically
referred to as "Very Close" localities). o single box NE: chassis with multiple CEs and FEs setup. ForCES is
applicable in localities consisting of control and forwarding
elements which are components in the same physical box.
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 o multiple boxes: separated CE and FE where physical locality could
ForCES was designed to enable logical separation of control and be same rack, room, building, or long distance which could span
forwarding planes in IP network devices. However, ForCES is not across continents and oceans. ForCES is applicable in localities
intended to be applicable to all services or to all possible CE/FE consisting of control and forwarding elements which are separated at
localities. single hop or multiple hops network.
The purpose of this section is to list limitations and out-of-scope
items for ForCES.
5.1. Out of Scope Services
The following control-forwarding plane services are explicitly not
addressed by ForCES:
o Label Switching
o Multimedia Gateway Control (MEGACO).
5.1.1. Label Switching
Label Switching is the purview of the GSMP Working Group in the Sub-
IP Area of the IETF. GSMP is a general purpose protocol to control
a label switch. GSMP defines mechanisms to separate the label
switch data plane from the control plane label protocols such as LDP
[8]. For more information on GSMP, see [7].
5.1.2. Separation of Control and Forwarding in Multimedia Gateways
MEGACO defines a protocol used between elements of a physically
decomposed multimedia gateway. Separation of call control channels
from bearer channels is the purview of MEGACO. For more information
on MEGACO, see [9].
5.2. Localities
ForCES protocol was intended to work within the localities described
in the last section. Outside these boundaries, care must be taken
or the protocol may not work right. Examples of localities where
ForCES was not originally intended to be used:
o Localities where there are multiple hops between CE and FE.
o Localities where hops between the CE and FE are dynamically
routing using IP routing protocols.
o Localities where the loss of the CE-FE link is of non- 5. Security Considerations
negligible probability.
o Localities where two or more FEs controlled by the same CE The ForCES architecture allows for a variety of security levels[6].
cannot communicate, either directly, or indirectly via other Fes
controlled by the same CE.
6. Security Considerations When operating under a secured physical environment, or for other
operational concerns (in some cases performance issues) the operator
may turn off all the security functions between CE and FE. When the
operator makes a decision to secure the path between the FE and CE
then the operator chooses from one of the options provided by the
TML. Security choices provided by the TML take effect during the
pre-association phase of the ForCES protocol. An operator may choose
to use all, some or none of the security services provided by the TML
in a CE-FE connection. A ForCES NE is required to provide CE/FE node
authentication services, and may provide message integrity and
confidentially services. The NE may provide these services by
employing IPSEC or TLS depending on the choice of TML used in the
deployment of the NE.
The security of ForCES protocol will be addressed in the Protocol 6. ForCES Manageability
Specification [6]. For security requirements, see architecture
requirement #5 and protocol requirement #2 in the Requirements Draft
[3]. The ForCES protocol assumes that the CE and FE are in the same
administration, and have shared secrets as a means of
administration. Whilst it might be technically feasible to have the
CE and FE administered independently, we strongly discourage such
uses, because they would require a significantly different trust
model from that ForCES assumes.
7. ForCES Manageability
From the management perspective, an NE can be viewed in at least two From the management perspective, an NE can be viewed in at least two
ways. From one perspective, it is a single network element, ways. From one perspective, it is a single network element,
specifically a router that needs to be managed in essentially the specifically a router that needs to be managed in essentially the
same way any router is managed. From another perspective element same way any router is managed. From another perspective element
management can view the individual entities and interfaces that make management can view the individual entities and interfaces that make
up a ForCES NE. up a ForCES NE.
7.1. NE as an atomic element 6.1. NE as an atomic element
From the ForCES requirements RFC [RFC 3654], Section 4, point 4: From the ForCES requirements RFC 3654, Section 4, point 4:
A NE MUST support the appearance of a single functional device. A NE MUST support the appearance of a single functional device.
As a single functional device a ForCES NE runs protocols and each of As a single functional device a ForCES NE runs protocols and each of
the protocols has it own existing manageability aspects that are the protocols has it own existing manageability aspects that are
document elsewhere. As a router it would also have a configuration document elsewhere. As a router it would also have a configuration
interface. When viewed in this manner, the NE is controlled as interface. When viewed in this manner, the NE is controlled as
single routing entity and no new management beyond what is already single routing entity and no new management beyond what is already
available for routers and routing protocols would be required for a available for routers and routing protocols would be required for a
ForCES NE. ForCES NE.
7.2. NE as composed of manageable elements 6.2. NE as composed of manageable elements
When viewed as a decomposed set of elements from the management When viewed as a decomposed set of elements from the management
perspective, the ForCES NE is divided into a set of one of more perspective, the ForCES NE is divided into a set of one of more
Control Elements, Forwarding Elements and the interfaces between Control Elements, Forwarding Elements and the interfaces between
them. The interface functionality between the CE and the FE is them. The interface functionality between the CE and the FE is
provided by the ForCES protocol. As with all IETF protocols a MIB provided by the ForCES protocol. As with all IETF protocols a MIB is
is provided for the purposes of managing the protocol. provided for the purposes of managing the protocol.
Additionally the architecture makes provision for configuration Additionally the architecture makes provision for configuration
control of the individual CEs and FEs. This is handled by elements control of the individual CEs and FEs. This is handled by elements
named FE manager (FEM) and the CE manager (CEM). Specifically from named FE manager (FEM) and the CE manager (CEM). Specifically from
the ForCES requirements the ForCES requirements RFC [RFC 3654], Section 4, point 4:
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 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.
From the ForCES MIB RFC [TBD], section X 6.3. ForCES Protocol MIB
The ForCES MIB is a primarily read-only MIB that captures The ForCES MIB [I-D.ietf-forces-mib] is a primarily read-only MIB
information related to the ForCES protocol. This includes that captures information related to the ForCES protocol. This
state information about the associations between CE(s) and includes state information about the associations between CE(s) and
FE(s) in the NE. FE(s) in the NE.
The ForCES MIB does not include information that is specified in The ForCES MIB does not include information that is specified in
other MIBs, such as packet counters for interfaces, etc. other MIBs, such as packet counters for interfaces, etc.
More specifically, the information in the ForCES MIB relative to More specifically, the information in the ForCES MIB relative to
associations includes: associations includes:
- identifiers of the elements in the association - identifiers of the elements in the association
- state of the association - state of the association
- configuration parameters of the association - configuration parameters of the association
- statistics of the association - statistics of the association
7.3.1. MIB Management of an FE 6.3.1. MIB Management of an FE
While it is possible to manage a FE from a element manager, several While it is possible to manage a FE from a element manager, several
requirements relating to this have been included in the ForCES requirements relating to this have been included in the ForCES
Requirements. Requirements.
From the ForCES Requirements [RFC 3654], Section 4, point 14: From the ForCES Requirements [RFC 3654], Section 4, point 14:
1. The ability for a management tool (e.g., SNMP) to be used 1. The ability for a management tool (e.g., SNMP) to be used to read
to read (but not change) the state of FE SHOULD NOT be (but not change) the state of FE SHOULD NOT be precluded.
precluded.
2. It MUST NOT be possible for management tools 2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to
(e.g., SNMP, etc) to change the state of a FE in a manner change the state of a FE in a manner that affects overall NE behavior
that affects overall NE behavior without the CE being without the CE being notified.
notified.
The ForCES Requirements [RFC 3746], Section 5.7, goes further in The ForCES Requirements [RFC 3654], Section 5.7, goes further in
discussing the manner in which FEs should handle management requests discussing the manner in which FEs should handle management requests
that are specifically directed to the FE: that are specifically directed to the FE:
RFC 1812 [2] also dictates that "Routers MUST be manageable RFC 1812 [2] also dictates that "Routers MUST be manageable by SNMP".
by SNMP". In general, for the post-association phase, most In general, for the post-association phase, most external management
external management tasks (including SNMP) should be done tasks (including SNMP) should be done through interaction with the CE
through interaction with the CE in order to support the in order to support the appearance of a single functional device.
appearance of a single functional device. Therefore, it is Therefore, it is recommended that an SNMP agent be implemented by CEs
recommended that an SNMP agent be implemented by CEs and and that the SNMP messages received by FEs be redirected to their
that the SNMP messages received by FEs be redirected to their CEs. AgentX framework defined in RFC 2741 ([6]) may be applied here
CEs. AgentX framework defined in RFC 2741 ([6]) may be applied such that CEs act in the role of master agent to process SNMP
here such that CEs act in the role of master agent to process protocol messages while FEs act in the role of subagent to provide
SNMP protocol messages while FEs act in the role of subagent access to the MIB objects residing on FEs. AgentX protocol messages
to provide access to the MIB objects residing on FEs. AgentX between the master agent (CE) and the subagent (FE) are encapsulated
protocol messages between the master agent (CE) and the and transported via ForCES, just like data packets from any other
subagent (FE) are encapsulated and transported via ForCES, application layer protocols.
just like data packets from any other application layer
protocols.
7.4. CE to CE communication 6.4. The FEM and CEM
The ForCES architecture allows for multiple CEs within a single NE. Though out of scope for the initial ForCES specification effort, the
The operating presumption is that the CEs will coordinate their ForCES architecture include two entities, the CE Manager (CEM) and
efforts in those cases where multiple CEs are available. Currently the FE Manager (FEM). From the ForCES Protocols Specification
the only specified method for CE to interact with FE is for there to [I-D.ietf-forces-protocol].
be one master CE, though there can be many backup CEs. Other
solutions that have been discussed include having multiple
specialist CEs per FE, however, the protocol does not support this
option.
The creation of a protocol or method for CE coordination is out of CE Manager (CEM) - A logical entity responsible for generic CE
scope for the initial ForCES specification effort. Any NE that uses management tasks. It is particularly used during the pre-association
multiple CEs for reliability must provide its own coordination phase to determine with which FE(s) a CE should communicate.
mechanisms.
7.5. The FEM and CEM 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.
Though out of scope for the initial ForCES specification effort, the 7. Contributors
ForCES architecture include two entities, the CE Manager (CEM) and
the FE Manager (FEM)
From the ForCES Protocols Specification [RFCXXXX] The following are the contributors who were instrumental in the
creation of earlier releases of this document or who gave good
suggestions to this document.
CE Manager (CEM) - A logical entity responsible for generic CE Mark Handley,ICIR.
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 8. Acknowledgments
FE management tasks. It is used during pre-association phase
to determine with which CE(s) an FE should communicate.
8. References Many of the colleagues in our companies and participants in the
8.1. Normative References ForCES mailing list have provided invaluable input into this work.
Particular thanks to Jamal Hadi Salim.
1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 9. References
2026, October 1996.
2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement 9.1. Normative References
Levels", RFC2119 (BCP), IETF, March 1997.
3. Khosravi, et al., ’’Requirements for Separation of IP Control and [I-D.ietf-forces-mib]
Forwarding”, RFC 3654, November 2003. HAAS, R., "ForCES MIB", draft-ietf-forces-mib-10 (work in
progress), September 2008.
4. L. Yang, et al., ” ForCES Architectural Framework”, RFC 3746, [I-D.ietf-forces-model]
April 2004. Halpern, J. and J. Salim, "ForCES Forwarding Element
Model", draft-ietf-forces-model-16 (work in progress),
October 2008.
5. Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.,and S. [I-D.ietf-forces-protocol]
Blake, "ForCES Forwarding Element Model", Feb. 2005. Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J.,
Khosravi, H., and W. Wang, "ForCES Protocol
Specification", draft-ietf-forces-protocol-22 (work in
progress), March 2009.
6. A. Doria, et al., ”ForCES Protocol Specification”, draft-ietf- [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
forces-protocol-06.txt, December 2005. June 1999.
8.2. Informative References [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003.
7. A. Doria, F. Hellstrand, K. Sundell, T. Worster, “General Switch [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
Management Protocol (GSMP) V3”, RFC 3292, June 2002. "Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004.
8. Andersson et al., "LDP Specification" RFC 3036, January 2001 9.2. Informative References
9. F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November [RFC3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen,
2000 B., and J. Segers, "Megaco Protocol Version 1.0",
RFC 3015, November 2000.
9. Acknowledgments [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
The authors wish to thank Jamal Hadi Salim, Vip Sharma, and many "General Switch Management Protocol (GSMP) V3", RFC 3292,
others for their invaluable contributions. June 2002.
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
USA
Phone: +1 503 264 2196 Phone: +1 503 264 2196
Email: alan.crouch@intel.com Email: alan.crouch@intel.com
Hormuzd Khosravi Hormuzd Khosravi
Intel Intel
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 Hillsboro, OR 97124 USA
USA
Phone: 1-503-264-0334 Phone: 1-503-264-0334
Email: hormuzd.m.khosravi@intel.com Email: hormuzd.m.khosravi@intel.com
Mark Handley
ICIR
1947 Center Street, Suite 600
Berkeley, CA 94708, USA
Email: mjh@icsi.berkeley.edu
Avri Doria Avri Doria
ETRI LTU
Lulea University of Technology Lulea University of Technology
Lulea, Sweden Sweden
Phone: +46 73 277 1788 Phone: +46 73 277 1788
Email: avri@acm.org Email: avri@acm.org
Copyright Statement Xin-ping Wang
Huawei
Beijing
China
Copyright (C) The Internet Society (2006). This document is subject Phone: +86 10 82836067
to the rights, licenses and restrictions contained in BCP 78, and Email: carly.wang@huawei.com
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on Kentaro Ogawa
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE NTT Corporation
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 3-9-11 Midori-cho
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR Musashino-shi, Tokyo 180-8585
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF Japan
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Email: ogawa.kentaro@lab.ntt.co.jp
 End of changes. 81 change blocks. 
286 lines changed or deleted 255 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/