draft-ietf-forces-applicability-07.txt   draft-ietf-forces-applicability-08.txt 
forces A. Crouch forces A. Crouch
Internet-Draft H. Khosravi Internet-Draft H. Khosravi
Intended status: Informational Intel Intended status: Informational Intel
Expires: April 13, 2010 A. Doria Expires: August 26, 2010 A. Doria
LTU LTU
X. Wang X. Wang
Huawei Huawei
K. Ogawa K. Ogawa
NTT Corporation NTT Corporation
October 10, 2009 February 22, 2010
ForCES Applicability Statement ForCES Applicability Statement
draft-ietf-forces-applicability-07 draft-ietf-forces-applicability-08
Abstract
The ForCES protocol defines a standard framework and mechanism for
the interconnection between Control Elements and Forwarding Elements
in IP routers and similar devices. In this document we describe the
applicability of the ForCES model and protocol. We provide example
deployment scenarios and functionality, as well as document
applications that would be inappropriate for ForCES.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
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 months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 13, 2010. This Internet-Draft will expire on August 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
The ForCES protocol defines a standard framework and mechanism for This document may contain material from IETF Documents or IETF
the interconnection between Control Elements and Forwarding Elements Contributions published or made publicly available before November
in IP routers and similar devices. In this document we describe the 10, 2008. The person(s) controlling the copyright in some of this
applicability of the ForCES model and protocol. We provide example material may not have granted the IETF Trust the right to allow
deployment scenarios and functionality, as well as document modifications of such material outside the IETF Standards Process.
applications that would be inappropriate for ForCES. 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.
Table of Contents Table of Contents
1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability to IP Networks . . . . . . . . . . . . . . . . . 4 4. Applicability to IP Networks . . . . . . . . . . . . . . . . . 4
4.1. Applicable Services . . . . . . . . . . . . . . . . . . . 5 4.1. Applicable Services . . . . . . . . . . . . . . . . . . . 5
4.1.1. Discovery, Capability Information Exchange . . . . . . 5 4.1.1. Discovery, Capability 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 Exchange . . . . . . . . . . . . . . . . . . . . . 6 4.1.5. QoS Exchange . . . . . . . . . . . . . . . . . . . . . 6
4.1.6. Security Exchange . . . . . . . . . . . . . . . . . . 6 4.1.6. Security Exchange . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . 7
4.1.12. CE Redundancy or CE Failover . . . . . . . . . . . . . 7 4.1.12. Redundancy and Failover . . . . . . . . . . . . . . . 7
4.2. CE-FE Link Capability . . . . . . . . . . . . . . . . . . 7 4.2. CE-FE Link Capability . . . . . . . . . . . . . . . . . . 8
4.3. CE/FE Locality . . . . . . . . . . . . . . . . . . . . . . 8 4.3. CE/FE Locality . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. ForCES Manageability . . . . . . . . . . . . . . . . . . . . . 9 6. ForCES Manageability . . . . . . . . . . . . . . . . . . . . . 9
6.1. NE as an atomic element . . . . . . . . . . . . . . . . . 9 6.1. NE as an atomic element . . . . . . . . . . . . . . . . . 9
6.2. NE as composed of manageable elements . . . . . . . . . . 9 6.2. NE as composed of manageable elements . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . 10
6.4. The FEM and CEM . . . . . . . . . . . . . . . . . . . . . 11 6.4. The FEM and CEM . . . . . . . . . . . . . . . . . . . . . 11
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 6, line 20 skipping to change at page 6, line 20
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 CE of an increase/decrease in available asynchronously inform the CE 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 like LLDP, BFD;or example use a standard topology discovery protocol like LLDP, BFD; or
apply a static topology configuration policy).Once the topology is apply a static topology configuration policy). Once the topology is
established, ForCES protocol may be used to transmit the resulting established, ForCES protocol may be used to transmit the resulting
information to the CE. 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
skipping to change at page 7, line 39 skipping to change at page 7, line 39
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. reported externally using SNMP.
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 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. Redundancy and Failover
CE failover and redundancy are out of scope in the initial version of The ForCES architecture includes mechanisms which allow for multiple
ForCES protocol. Basic mechanisms for CE redundancy/failover are not redundant CEs and FEs in a ForCES NE. The ForCES model LFB
presently implemented. Broad concepts such as implementing CE definitions provide sufficient component details via component
Redundancy, CE Failover, and CE-CE communication, while not precluded identifiers to be universally unique within an NE. The ForCES
by the ForCES architecture, are considered outside the scope of protocol includes mechanisms to facilitate transactions as well as
ForCES protocol. ForCES protocol is designed to handle CE- FE atomicity across the NE.
communication, and is not intended for CE-CE communication.
Given the above it is possible to deploy redundant CEs and FEs which
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
skipping to change at page 9, line 21 skipping to change at page 9, line 24
pre-association phase of the ForCES protocol. An operator may choose 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 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 in a CE-FE connection. A ForCES NE is required to provide CE/FE node
authentication services, and may provide message integrity and authentication services, and may provide message integrity and
confidentially services. The NE may provide these services by confidentially services. The NE may provide these services by
employing IPSEC or TLS depending on the choice of TML used in the employing IPSEC or TLS depending on the choice of TML used in the
deployment of the NE. deployment of the NE.
6. ForCES Manageability 6. ForCES Manageability
From the management perspective, an NE can be viewed in at least two From one perspective, it is a single network element; as an example
ways. From one perspective, it is a single network element, if the ForCES NE is specifically a router that needs to be managed
specifically a router that needs to be managed in essentially the then it is managed in essentially the same way any router is managed.
same way any router is managed. From another perspective element From another perspective element management can view the individual
management can view the individual entities and interfaces that make entities and interfaces that make up a ForCES NE.
up a ForCES NE.
6.1. NE as an atomic element 6.1. NE as an atomic element
From the ForCES requirements 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
documented elsewhere. As a router it would also have a configuration documented elsewhere. As an example, router would also have a
interface. When viewed in this manner, the NE is controlled as a configuration interface. When viewed in this manner, the NE is
single routing entity and no new management beyond what is already controlled as a single routing entity and no new management beyond
available for routers and routing protocols would be required for a what is already available for routers and routing protocols would be
ForCES NE. required for a ForCES NE.
6.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 is provided by the ForCES protocol. As with all IETF protocols a MIB is
provided for the purposes of managing the protocol. provided for the purposes of managing the protocol.
skipping to change at page 11, line 5 skipping to change at page 11, line 6
(but not change) the state of FE should not be precluded. (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 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 change the state of a FE in a manner that affects overall NE behavior
without the CE being notified. without the CE being notified.
The ForCES Requirements [RFC 3654], 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 by SNMP". For a ForCES NE that is an IP router, RFC 1812 [2] also dictates that
In general, for the post-association phase, most external management "Routers must be manageable by SNMP". In general, for the post-
tasks (including SNMP) should be done through interaction with the CE association phase, most external management tasks (including SNMP)
in order to support the appearance of a single functional device. should be done through interaction with the CE in order to support
Therefore, it is recommended that an SNMP agent be implemented by CEs the appearance of a single functional device. Therefore, it is
and that the SNMP messages received by FEs be redirected to their recommended that an SNMP agent be implemented by CEs and that the
CEs. AgentX framework defined in RFC 2741 ([6]) may be applied here SNMP messages received by FEs be redirected to their CEs. AgentX
such that CEs act in the role of master agent to process SNMP framework defined in RFC 2741 ([6]) may be applied here such that CEs
protocol messages while FEs act in the role of subagent to provide act in the role of master agent to process SNMP protocol messages
access to the MIB objects residing on FEs. AgentX protocol messages while FEs act in the role of subagent to provide access to the MIB
between the master agent (CE) and the subagent (FE) are encapsulated objects residing on FEs. AgentX protocol messages between the master
and transported via ForCES, just like data packets from any other agent (CE) and the subagent (FE) are encapsulated and transported via
application layer protocols. ForCES, just like data 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 include two entities, the CE Manager (CEM) and
the FE Manager (FEM). From the ForCES Protocols Specification the FE Manager (FEM). From the ForCES Protocols Specification
[I-D.ietf-forces-protocol]. [I-D.ietf-forces-protocol].
CE Manager (CEM) - A logical entity responsible for generic CE CE Manager (CEM) - A logical entity responsible for generic CE
management tasks. It is particularly used during the pre-association management tasks. It is particularly used during the pre-association
skipping to change at page 11, line 40 skipping to change at page 11, line 42
FE Manager (FEM) - A logical entity responsible for generic FE FE Manager (FEM) - A logical entity responsible for generic FE
management tasks. It is used during pre-association phase to management tasks. It is used during pre-association phase to
determine with which CE(s) an FE should communicate. determine with which CE(s) an FE should communicate.
7. Contributors 7. Contributors
The following are the contributors who were instrumental in the The following are the contributors who were instrumental in the
creation of earlier releases of this document or who gave good creation of earlier releases of this document or who gave good
suggestions to this document. suggestions to this document.
Mark Handley,ICIR. Mark Handley, ICIR.
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
[RFC Editor: please remove this section prior to publication.] [RFC Editor: please remove this section prior to publication.]
9. Acknowledgments 9. Acknowledgments
Many of the colleagues in our companies and participants in the Many of the colleagues in our companies and participants in the
 End of changes. 17 change blocks. 
68 lines changed or deleted 75 lines changed or added

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