draft-ietf-forces-applicability-09.txt   rfc6041.txt 
ForCES Working Group A. Crouch Internet Engineering Task Force (IETF) A. Crouch
Internet-Draft H. Khosravi Request for Comments: 6041 H. Khosravi
Intended status: Informational Intel Category: Informational Intel
Expires: December 29, 2010 A. Doria (ed.) ISSN: 2070-1721 A. Doria, Ed.
LTU LTU
X. Wang X. Wang
Huawei Huawei
K. Ogawa K. Ogawa
NTT Corporation NTT Corporation
June 27, 2010 October 2010
ForCES Applicability Statement Forwarding and Control Element Separation (ForCES)
draft-ietf-forces-applicability-09 Applicability Statement
Abstract Abstract
The ForCES protocol defines a standard framework and mechanism for The Forwarding and Control Element Separation (ForCES) protocol
the interconnection between Control Elements and Forwarding Elements defines a standard framework and mechanism for the interconnection
in IP routers and similar devices. In this document we describe the between control elements and forwarding elements in IP routers and
applicability of the ForCES model and protocol. We provide example similar devices. In this document we describe the applicability of
deployment scenarios and functionality, as well as document the ForCES model and protocol. We provide example deployment
applications that would be inappropriate for ForCES. scenarios and functionality, as well as document applications that
would be inappropriate for ForCES.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on December 29, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6041.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Purpose .........................................................4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology .....................................................4
4. Applicability to IP Networks . . . . . . . . . . . . . . . . . 5 4. Applicability to IP Networks ....................................4
4.1. Applicable Services . . . . . . . . . . . . . . . . . . . 5 4.1. Applicable Services ........................................5
4.1.1. Association, Capability Discovery and Information 4.1.1. Association, Capability Discovery, and
Exchange . . . . . . . . . . . . . . . . . . . . . . . 5 Information Exchange ................................5
4.1.2. Topology Information Exchange . . . . . . . . . . . . 6 4.1.2. Topology Information Exchange .......................6
4.1.3. Configuration . . . . . . . . . . . . . . . . . . . . 6 4.1.3. Configuration .......................................6
4.1.4. Routing Exchange . . . . . . . . . . . . . . . . . . . 6 4.1.4. Routing Exchange ....................................6
4.1.5. QoS Capabilities Exchange and Configuration . . . . . 6 4.1.5. QoS Capabilities Exchange and Configuration .........7
4.1.6. Security Exchange . . . . . . . . . . . . . . . . . . 7 4.1.6. Security Exchange ...................................7
4.1.7. Filtering Exchange and Firewalls . . . . . . . . . . . 7 4.1.7. Filtering Exchange and Firewalls ....................7
4.1.8. Encapsulation, Tunneling Exchange . . . . . . . . . . 7 4.1.8. Encapsulation/Tunneling Exchange ....................7
4.1.9. NAT and Application-level Gateways . . . . . . . . . . 7 4.1.9. NAT and Application-Level Gateways ..................7
4.1.10. Measurement and Accounting . . . . . . . . . . . . . . 7 4.1.10. Measurement and Accounting .........................7
4.1.11. Diagnostics . . . . . . . . . . . . . . . . . . . . . 7 4.1.11. Diagnostics ........................................8
4.1.12. Redundancy and Failover . . . . . . . . . . . . . . . 7 4.1.12. Redundancy and Failover ............................8
4.2. CE-FE Link Capability . . . . . . . . . . . . . . . . . . 8 4.2. CE-FE Link Capability ......................................8
4.3. CE/FE Locality . . . . . . . . . . . . . . . . . . . . . . 8 4.3. CE/FE Locality .............................................8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations .........................................9
6. ForCES Manageability . . . . . . . . . . . . . . . . . . . . . 9 6. ForCES Manageability ............................................9
6.1. NE as an Atomic Element . . . . . . . . . . . . . . . . . 9 6.1. The NE as an Atomic Element ...............................10
6.2. NE as Composed of Manageable Elements . . . . . . . . . . 10 6.2. The NE as Composed of Manageable Elements .................10
6.3. ForCES Protocol MIB . . . . . . . . . . . . . . . . . . . 10 6.3. ForCES Protocol MIB .......................................10
6.3.1. MIB Management of an FE . . . . . . . . . . . . . . . 10 6.3.1. MIB Management of an FE ............................11
6.4. The FEM and CEM . . . . . . . . . . . . . . . . . . . . . 11 6.4. The FEM and CEM ...........................................12
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Contributors ...................................................12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments ................................................12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. References .....................................................12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References ......................................12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References ....................................13
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Purpose
The purpose of the ForCES Applicability Statement is to capture the
intent of the ForCES protocol [RFC5810] designers as to how the
protocol could be used in conjunction with the ForCES model [RFC5812]
and a Transport Mapping Layer [RFC5811].
2. Overview 1. Introduction
The ForCES protocol defines a standard framework and mechanism for The Forwarding and Control Element Separation (ForCES) protocol
the exchange of information between the logically separate defines a standard framework and mechanism for the exchange of
functionality of the control and data forwarding planes of IP routers information between the logically separate functionality of the
and similar devices. It focuses on the communication necessary for control and data forwarding planes of IP routers and similar devices.
separation of control plane functionality such as routing protocols, It focuses on the communication necessary for separation of control
signaling protocols, and admission control from data forwarding plane plane functionality such as routing protocols, signaling protocols,
per-packet activities such as packet forwarding, queuing, and header and admission control from data forwarding plane per-packet
editing. 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.
2. Purpose
The purpose of the ForCES Applicability Statement is to capture the
intent of the ForCES protocol [RFC5810] designers as to how the
protocol could be used in conjunction with the ForCES model [RFC5812]
and a Transport Mapping Layer [RFC5811].
3. Terminology 3. Terminology
A set of concepts associated with ForCES was introduced in A set of concepts associated with ForCES was introduced in
Requirements for Separation of IP Control and Forwarding[RFC3654] and "Requirements for Separation of IP Control and Forwarding" [RFC3654]
in Forwarding and Control Element Separation (ForCES) and in "Forwarding and Control Element Separation (ForCES) Framework"
Framework[RFC3746]. The terminology associated with these concepts [RFC3746]. The terminology associated with these concepts and with
and the protocol elements in ForCES is defined in the Forwarding and the protocol elements in ForCES is defined in the "Forwarding and
Control Element Separation (ForCES) Protocol Specification[RFC5810]. Control Element Separation (ForCES) Protocol Specification"
[RFC5810].
The reader is directed to these documents for the conceptual The reader is directed to these documents for the conceptual
introduction and the definitions including of the following acronyms: introduction and for definitions, including the following acronyms:
o CE: control element
o CEM: CE Manager
o FE: forwarding element
o FEM: FE Manager
o CE: Control Element
o CEM: Control element manager
o FE: Forwarding Element
o FEM: Forwarding element manager
o ForCES: Forwarding and Control Element Separation protocol o ForCES: Forwarding and Control Element Separation protocol
o LFB: Logical Function Block o LFB: Logical Function Block
o NE: ForCES network element o NE: ForCES network element
o TML: Transport Mapping Layer o TML: Transport Mapping Layer
4. Applicability to IP Networks 4. Applicability to IP Networks
This section lists the areas of ForCES applicability in IP network This section lists the areas of ForCES applicability in IP network
devices. Some relatively low-end routing systems may be implemented devices. Some relatively low-end routing systems may be implemented
on simple hardware which performs both control and packet forwarding on simple hardware that performs both control and packet forwarding
functionality. ForCES may not be useful for such devices. functionality. ForCES may not be useful for such devices.
Higher end routing systems typically distribute work amongst several Higher-end routing systems typically distribute work amongst several
interface processing elements, and these devices (FEs) therefore need interface-processing elements, and these devices (FEs) therefore need
to communicate with the control element(s) to perform their job. A to communicate with the control element(s) to perform their job. A
higher end router may also distribute control processing amongst higher-end router may also distribute control processing amongst
several processing elements (CEs). ForCES provides a standard way to several processing elements (CEs). ForCES provides a standard way to
do this communication. ForCES also provides support for High do this communication. ForCES also provides support for high-
Availability configurations that include a primary CE and one or more availability configurations that include a primary CE and one or more
secondary CEs. secondary CEs.
The remainder of this section lists the applicable services which The remainder of this section lists the applicable services that
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:
o Association, Capability Discovery, and Information Exchange
o Association, Capability discovery and Information Exchange
o Topology Information Exchange o Topology Information Exchange
o Configuration o Configuration
o Routing Exchange o Routing Exchange
o QoS Exchange
o Quality of Service (QoS) Exchange
o Security Exchange o Security Exchange
o Filtering Exchange o Filtering Exchange
o Encapsulation/Tunneling Exchange o Encapsulation/Tunneling Exchange
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. Association, Capability Discovery and Information Exchange 4.1.1. Association, Capability Discovery, and Information Exchange
Association is the first step of the ForCES protocol exchange in Association is the first step of the ForCES protocol exchange in
which capability discovery and exchange happens between one or more which capability discovery and exchange happens between one or more
CEs and the FEs. ForCES assumes that CEs and FEs already have CEs and the FEs. ForCES assumes that CEs and FEs already have
sufficient information to begin communication in a secure manner. sufficient information to begin communication in a secure manner.
The ForCES protocol is only applicable after CEs and FEs have The ForCES protocol is only applicable after CEs and FEs have
discovered each other. ForCES makes no assumption about whether discovered each other. ForCES makes no assumption about whether
discovery was performed using a dynamic protocol or merely static discovery was performed using a dynamic protocol or merely static
configuration. Some discussion about how this can occur can be found configuration. Some discussion about how this can occur can be found
later in this document in Section 6.4. in Section 6.4 of this document.
During the association phase, CEs and FEs exchange capability During the association phase, CEs and FEs exchange capability
information with each other. For example, the FEs express the number information with each other. For example, the FEs express the 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 also exchange In addition to initial configuration, the CEs and FEs also exchange
dynamic configuration changes using ForCES. For example, FEs dynamic configuration changes using ForCES. For example, FEs
asynchronously inform the CEs of an increase/decrease in available asynchronously inform the CEs of an increase/decrease in 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.
Topology discovery is outside the scope of the ForCES protocol. An Topology discovery is outside the scope of the ForCES protocol. An
implementation can choose its own method of topology discovery (for implementation can choose its own method of topology discovery (for
example use a standard topology discovery protocol; or apply a static example, it can use a standard topology discovery protocol or apply a
topology configuration policy). Once the topology is established, static topology configuration policy). Once the topology is
ForCES protocol may be used to transmit the resulting information to established, the ForCES protocol may be used to transmit the
the CEs. resulting information to the CEs.
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 resulting ForCES may be used to deliver packet forwarding information resulting
from CE routing calculations. For example, CEs may send forwarding from CE routing calculations. For example, CEs may send forwarding
table updates to the FEs, so that they can make forwarding decisions. table updates to the FEs, so that they can make forwarding decisions.
FEs may inform the CEs in the event of a forwarding table miss. FEs may inform the CEs in the event of a forwarding table miss.
ForCES may also be used to configure ECMP capability. ForCES may also be used to configure Equal Cost Multi-Path (ECMP)
capability.
4.1.5. QoS Capabilities Exchange and Configuration 4.1.5. QoS Capabilities Exchange and Configuration
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 a CE and ForCES may be used to exchange security information between a CE and
the FEs it controls. For example, the FE may use ForCES to express the FEs it controls. For example, the FE may use ForCES to express
the types of encryption that it is capable of using in an IPsec the types of encryption that it is capable of using in an IP Security
tunnel. The CE may use ForCES to configure such a tunnel. The CEs (IPsec) tunnel. The CE may use ForCES to configure such a tunnel.
would be responsible for the NE dynamic key exchanges and updates. The CEs would be responsible for the NE dynamic key exchanges and
updates.
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
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 Address Translators. Whilst ForCES is not specifically designed for
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 network
alternative network management mechanisms such as SNMP. In some management mechanisms such as the Simple Network Management Protocol
cases ForCES may be used to convey information to the CE to be (SNMP). In some cases, ForCES may be used to convey information to
reported externally using SNMP. A further discussion of this the CE to be reported externally using SNMP. A further discussion of
capability is covered in Section 6 of this document. this capability is covered in Section 6 of this document.
4.1.11. Diagnostics 4.1.11. Diagnostics
ForCES may be used for CEs and FEs 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 a CE. information. For example, an FE can send self-test results to a CE.
4.1.12. Redundancy and Failover 4.1.12. Redundancy and Failover
The ForCES architecture includes mechanisms which allow for multiple The ForCES architecture includes mechanisms that allow for multiple
redundant CEs and FEs in a ForCES NE. The ForCES model LFB redundant CEs and FEs in a ForCES NE. The ForCES-model LFB
definitions provide sufficient component details via component definitions provide sufficient component details via component
identifiers to be universally unique within an NE. The ForCES identifiers to be universally unique within an NE. The ForCES
protocol includes mechanisms to facilitate transactions as well as protocol includes mechanisms to facilitate transactions as well as
atomicity across the NE. atomicity across the NE.
Given the above it is possible to deploy redundant CEs and FEs which Given the above, it is possible to deploy redundant CEs and FEs that
incorporate failover. incorporate failover.
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 is reasonable over a high bandwidth link, but could be routing table is reasonable over a high-bandwidth link, but could be
non-trivial over a lower-bandwidth link. ForCES should be non-trivial over a lower-bandwidth link. ForCES should be
sufficiently future-proof to be applicable in scenarios where routing sufficiently future-proof to be applicable in scenarios where routing
tables grow to several orders of magnitude greater than their current tables grow to several orders of magnitude greater than their current
size. However, we also note that not all IP routers need full size. However, we also note that not all IP routers need full
routing tables. routing tables.
4.3. CE/FE Locality 4.3. CE/FE Locality
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, where reliability is high, closely controlled, and not LAN, where reliability is high, closely controlled, and not
susceptible to external disruption that does not also affect the susceptible to external disruption that does not also affect the
CEs and/or FEs. CEs and/or FEs.
o The control interconnect shares fate with the FE's forwarding
o The control interconnect shares its fate with the FE's forwarding
function. Typically this is because the control connection is function. Typically this is because the control connection is
also the FE's primary packet forwarding connection, and so if that also the FE's primary packet forwarding connection, and so if that
link goes down, the FE cannot forward packets anyway. link 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 be
significantly reduced by the separation of control and forwarding significantly reduced by the separation of control and forwarding
functionality. functionality.
Taking this into account, ForCES is applicable in the following CE/FE Taking this into account, ForCES is applicable in the following CE/FE
localities: localities:
Single Box NE: chassis with multiple CEs and FEs setup. ForCES is Single Box NE:
applicable in localities consisting of control and forwarding chassis with multiple CEs and FEs set up. ForCES is applicable in
elements which are components in the same physical box. localities consisting of control and forwarding elements that 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 more forwarding blades, all present in the same chassis and
sharing an interconnect such as Ethernet or PCI. In this sharing an interconnect such as Ethernet or Peripheral Component
locality, the majority of the data traffic being forwarded Interconnect (PCI). In this locality, the majority of the data
typically does not traverse the same links as the ForCES control traffic being forwarded typically does not traverse the same links
traffic. as the ForCES control traffic.
Multiple Box NE: separated CE and FE where physical locality could Multiple Box NE:
be same rack, room, building, or long distance which could span separated CE and FE, where physical locality could be the same
across continents and oceans. ForCES is applicable in localities rack, room, or building; or long distances that could span across
consisting of control and forwarding elements which are separated continents and oceans. ForCES is applicable in localities
consisting of control and forwarding elements that are separated
by a single hop or multiple hops in the network. by a single hop or multiple hops in the network.
5. Security Considerations 5. Security Considerations
The ForCES protocol allows for a variety of security levels The ForCES protocol allows for a variety of security levels
[RFC5810]. When operating under a secured physical environment, or [RFC5810]. When operating under a secured physical environment, or
for other operational concerns (in some cases performance issues) the for other operational concerns (in some cases, performance issues),
operator may turn off all the security functions between CEs and FEs. the operator may turn off all the security functions between CEs and
When the operator makes a decision to secure the path between the FEs FEs. When the operator makes a decision to secure the path between
and CEs then the operator chooses from one of the options provided by the FEs and CEs, then the operator chooses from one of the options
the TML. Security choices provided by the TML take effect during the provided by the TML. Security choices provided by the TML take
pre-association phase of the ForCES protocol. An operator may choose effect during the pre-association phase of the ForCES protocol. An
to use all, some or none of the security services provided by the TML operator may choose to use all, some, or none of the security
in a CE-FE connection. A ForCES NE is required to provide CE/FE node services provided by the TML in a CE-FE connection. A ForCES NE is
authentication services, and may provide message integrity and required to provide CE/FE node authentication services, and may
confidentially services. The NE may provide these services by provide message integrity and confidentiality services. The NE may
employing IPsec or TLS depending on the choice of TML used in the provide these services by employing IPsec or Transport Layer Security
deployment of the NE. (TLS), depending on the choice of TML used in the deployment of
the NE.
6. ForCES Manageability 6. ForCES Manageability
From the architectural perspective, the ForCES NE is a single network From the architectural perspective, the ForCES NE is a single network
element; as an example if the ForCES NE is specifically a router that element. As an example, if the ForCES NE is specifically a router
needs to be managed, then it should be managed in essentially the that needs to be managed, then it should be managed in essentially
same way any router should be managed. From another perspective the same way any router should be managed. From another perspective,
element management could view the individual entities and interfaces element management could directly view the individual entities and
that make up a ForCES NE but this may cause risk on the control interfaces that make up a ForCES NE. However, any element management
relationship between the CEs and the FEs unless it has been accounted updates made directly on these entities and interfaces may compromise
for in the model used by the NE. the control relationship between the CEs and the FEs, unless the
update mechanism has been accounted for in the model used by the NE.
6.1. NE as an Atomic Element 6.1. The NE as an Atomic Element
From the ForCES requirements [RFC3654] Section 4, point 4: From the ForCES Requirements [RFC3654], 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
the protocols has it own existing manageability aspects that are of the protocols has its own existing manageability aspects that are
documented elsewhere. As an example, router would also have a documented elsewhere. As an example, a router would also have a
configuration interface. When viewed in this manner, the NE is configuration interface. When viewed in this manner, the NE is
controlled as a single routing entity and no new management beyond controlled as a single routing entity, and no new management beyond
what is already available for routers and routing protocols would be what is already available for routers and routing protocols would be
required for a ForCES NE. Management commands on a management required for a ForCES NE. Management commands on a management
interface to the NE will arrive at the CE and may require ForCES interface to the NE will arrive at the CE and may require ForCES
interactions between the CE and FEs to complete. This may impact the interactions between the CE and FEs to complete. This may impact the
atomicity of such commands and may require careful implementation by atomicity of such commands and may require careful implementation by
the CE. the CE.
6.2. NE as Composed of Manageable Elements 6.2. The 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. A MIB module is provided for the provided by the ForCES protocol. A MIB module is provided for the
purpose of gaining management information on the operation of the purpose of gaining management information on the operation of the
protocol describe in Section 6.3 of this document. protocol described in Section 6.3 of this document.
Additionally the architecture makes provision for configuration Additionally, the architecture makes provisions 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 called the FE Manager (FEM) and the CE Manager (CEM). Specifically,
the ForCES requirements RFC [RFC3654], Section 4, point 4: from the ForCES Requirements RFC [RFC3654], Section 4, point 4:
However, external entities (e.g., FE managers and CE managers) may However, external entities (e.g., FE Managers and CE Managers) MAY
have direct access to individual ForCES protocol elements for have direct access to individual ForCES protocol elements for
providing information to transition them from the pre-association to providing information to transition them from the pre-association
post-association phase. to the post-association phase.
6.3. ForCES Protocol MIB 6.3. ForCES Protocol MIB
The ForCES MIB [RFC5813] defines a primarily read-only MIB module The ForCES MIB [RFC5813] defines a primarily read-only MIB module
that captures information related to the ForCES protocol. This that captures information related to the ForCES protocol. This
includes 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 MIB modules, such as packet counters for interfaces, etc. other MIB modules, such as packet counters for interfaces, etc.
skipping to change at page 10, line 44 skipping to change at page 11, line 12
includes 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 MIB modules, such as packet counters for interfaces, etc. other MIB modules, such as packet counters for interfaces, etc.
More specifically, the information in the ForCES MIB module relative More specifically, the information in the ForCES MIB module relative
to associations includes: to associations includes:
o identifiers of the elements in the association o identifiers of the elements in the association
o state of the association o state of the association
o configuration parameters of the association o configuration parameters of the association
o statistics of the association o statistics of the association
6.3.1. MIB Management of an FE 6.3.1. MIB Management of an FE
While it is possible to manage a FE from an element manager, several While it is possible to manage an FE from an 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 [RFC3654], Section 4, point 14: From the ForCES Requirements [RFC3654], Section 4, point 14:
1. The ability for a management tool (e.g., SNMP) to be used to read 1. The ability for a management tool (e.g., SNMP) to be used to
(but not change) the state of FE should not be precluded. 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 [RFC3654], Section 5.7, goes further in 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 Framework [RFC3746], 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:
For a ForCES NE that is an IP router, [RFC1812] also dictates that (For a ForCES NE that is an IP router,) RFC 1812 [RFC1812] also
"Routers must be manageable by SNMP". In general, for the post- dictates that "Routers must be manageable by SNMP". In general,
association phase, most external management tasks (including SNMP) for the post-association phase, most external management tasks
should be done through interaction with the CE in order to support (including SNMP) should be done through interaction with the CE in
the appearance of a single functional device. Therefore, it is order to support the appearance of a single functional device.
recommended that an SNMP agent be implemented by CEs and that the Therefore, it is recommended that an SNMP agent be implemented by
SNMP messages received by FEs be redirected to their CEs. AgentX CEs and that the SNMP messages received by FEs be redirected to
framework defined in [RFC2741]) may be applied here such that CEs act their CEs. AgentX framework defined in RFC 2741 [RFC2741]) may be
in the role of master agent to process SNMP protocol messages while applied here such that CEs act in the role of master agent to
FEs act in the role of sub-agent to provide access to the MIB objects process SNMP messages while FEs act in the role of subagent to
residing on FEs. AgentX protocol messages between the master agent provide access to the MIB objects residing on FEs. AgentX
(CE) and the sub-agent (FE) are encapsulated and transported via protocol messages between the master agent (CE) and the subagent
ForCES, just like data packets from any other application layer (FE) are encapsulated and transported via ForCES, just like data
protocols. packets from any other application layer protocols.
6.4. The FEM and CEM 6.4. The FEM and CEM
Though out of scope for the initial ForCES specification effort, the Though out of scope for the initial ForCES specification effort, the
ForCES architecture include two entities, the CE Manager (CEM) and ForCES architecture includes two entities: the CE Manager (CEM) and
the FE Manager (FEM). From the ForCES Protocols Specification the FE Manager (FEM). From the ForCES Protocol Specification
[RFC5810]. [RFC5810]:
CE Manager (CEM) - A logical entity responsible for generic CE CE Manager (CEM):
management tasks. It is particularly used during the pre- A logical entity responsible for generic CE management tasks. It
association phase to determine with which FE(s) a CE should is particularly used during the pre-association phase to determine
communicate. 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 FE Manager (FEM):
determine with which CE(s) an FE should communicate. A logical entity responsible for generic FE management tasks. It
is used during the pre-association phase to determine with which
CE(s) an FE should communicate.
7. Contributors 7. Contributors
Mark Handley was an initial author involved in the earlier versions Mark Handley was an initial author involved in the earlier versions
of this document. of this document.
8. IANA Considerations 8. Acknowledgments
This document has no IANA actions.
[RFC Editor: please remove this section prior to publication.]
9. Acknowledgments
Many of the participants in the ForCES as well as fellow employees of Many of the participants in the ForCES WG, as well as fellow
the authors, have provided valuable input into this work. Particular employees of the authors, have provided valuable input into this
thanks go to Jamal Hadi Salim, our WG chair and document shepherd and work. Particular thanks go to Jamal Hadi Salim, our WG chair and
to Adrian Farrel the AD for the area for their review, comments and document shepherd; and to Adrian Farrel, the AD for the area; for
encouragement without whom this document might never have been their review, comments, and encouragement, without which this
completed. document might never have been completed.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
June 1995. RFC 1812, June 1995.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010. Specification", RFC 5810, March 2010.
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport
Layer (TML) for the Forwarding and Control Element Mapping Layer (TML) for the Forwarding and Control
Separation (ForCES) Protocol", March 2010. Element Separation (ForCES) Protocol", RFC 5811,
March 2010.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model", Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010. RFC 5812, March 2010.
[RFC5813] Haas, R., "Forwarding and Control Element Separation [RFC5813] Haas, R., "Forwarding and Control Element Separation
(ForCES) MIB", RFC 5813, March 2010. (ForCES) MIB", RFC 5813, March 2010.
10.2. Informative References 9.2. Informative References
[RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco,
"Agent Extensibility (AgentX) Protocol Version 1", "Agent Extensibility (AgentX) Protocol Version 1",
January 2000. RFC 2741, January 2000.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation [RFC3654] Khosravi, H. and T. Anderson, "Requirements for
of IP Control and Forwarding", RFC 3654, November 2003. Separation of IP Control and Forwarding", RFC 3654,
November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES) "Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004. Framework", RFC 3746, April 2004.
Authors' Addresses 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 USA 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
Avri Doria Avri Doria (editor)
LTU LTU
Lulea University of Technology Lulea University of Technology
Sweden Sweden
Phone: +46 73 277 1788 Phone: +46 73 277 1788
Email: avri@acm.org EMail: avri@acm.org
Xin-ping Wang Xin-ping Wang
Huawei Huawei
Beijing Beijing
China China
Phone: +86 10 82836067 Phone: +86 10 82836067
Email: carly.wang@huawei.com EMail: carly.wang@huawei.com
Kentaro Ogawa Kentaro Ogawa
NTT Corporation NTT Corporation
3-9-11 Midori-cho 3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
Email: ogawa.kentaro@lab.ntt.co.jp EMail: ogawa.kentaro@lab.ntt.co.jp
 End of changes. 93 change blocks. 
245 lines changed or deleted 272 lines changed or added

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