draft-ietf-forces-applicability-06.txt   draft-ietf-forces-applicability-07.txt 
forces A. Crouch forces A. Crouch
Internet-Draft H. Khosravi Internet-Draft H. Khosravi
Intended status: Informational Intel Intended status: Informational Intel
Expires: January 3, 2010 A. Doria Expires: April 13, 2010 A. Doria
LTU LTU
X. Wang X. Wang
Huawei Huawei
K. Ogawa K. Ogawa
NTT Corporation NTT Corporation
July 2, 2009 October 10, 2009
ForCES Applicability Statement ForCES Applicability Statement
draft-ietf-forces-applicability-06 draft-ietf-forces-applicability-07
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 January 3, 2010. This Internet-Draft will expire on April 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 34 skipping to change at page 3, line 34
4.2. CE-FE Link Capability . . . . . . . . . . . . . . . . . . 7 4.2. CE-FE Link Capability . . . . . . . . . . . . . . . . . . 7
4.3. CE/FE Locality . . . . . . . . . . . . . . . . . . . . . . 8 4.3. CE/FE Locality . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
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 [I-D.ietf-forces-protocol] designers as intent of the ForCES protocol [I-D.ietf-forces-protocol] designers as
to how the protocol could be used (in conjunction with the ForCES to how the protocol could be used (in conjunction with the ForCES
model [I-D.ietf-forces-model]). model [I-D.ietf-forces-model]).
2. Overview 2. Overview
skipping to change at page 6, line 21 skipping to change at page 6, line 21
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 portocol 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.
skipping to change at page 8, line 4 skipping to change at page 8, line 4
presently implemented. Broad concepts such as implementing CE presently implemented. Broad concepts such as implementing CE
Redundancy, CE Failover, and CE-CE communication, while not precluded Redundancy, CE Failover, and CE-CE communication, while not precluded
by the ForCES architecture, are considered outside the scope of by the ForCES architecture, are considered outside the scope of
ForCES protocol. ForCES protocol is designed to handle CE- FE ForCES protocol. ForCES protocol is designed to handle CE- 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 is reasonable over a high bandwidth link, but could be
interconnect, but could be non-trivial over a lower-bandwidth link. non-trivial over a lower-bandwidth link. ForCES should be
ForCES should be sufficiently future-proof to be applicable in sufficiently future-proof to be applicable in scenarios where routing
scenarios where routing tables grow to several orders of magnitude tables grow to several orders of magnitude greater than their current
greater than their current size. However, we also note that not all size. However, we also note that not all IP routers need full
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 LAN, o The control interconnect is some form of local bus, switch, or LAN,
where reliability is high, closely controlled, and not susceptible to where reliability is high, closely controlled, and not susceptible to
external disruption that does not also affect the CEs and/or FEs. external disruption that does not also affect the CEs and/or FEs.
skipping to change at page 8, line 45 skipping to change at page 8, line 45
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.
o multiple boxes: separated CE and FE where physical locality could o multiple boxes: separated CE and FE where physical locality could
be same rack, room, building, or long distance which could span be same rack, room, building, or long distance which could span
across continents and oceans. ForCES is applicable in localities across continents and oceans. ForCES is applicable in localities
consisting of control and forwarding elements which are separated at consisting of control and forwarding elements which are separated by
single hop or multiple hops network. a single hop or multiple hops in the network.
5. Security Considerations 5. Security Considerations
The ForCES architecture allows for a variety of security levels[6]. The ForCES architecture allows for a variety of security levels[6].
When operating under a secured physical environment, or for other When operating under a secured physical environment, or for other
operational concerns (in some cases performance issues) the operator operational concerns (in some cases performance issues) the operator
may turn off all the security functions between CE and FE. When the 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 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 then the operator chooses from one of the options provided by the
skipping to change at page 9, line 32 skipping to change at page 9, line 32
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.
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
document elsewhere. As a router it would also have a configuration documented 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 a
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.
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.
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 RFC [RFC 3654], Section 4, point 4: the ForCES requirements RFC [RFC 3654], 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 to
post-association phase. post-association phase.
6.3. ForCES Protocol MIB 6.3. ForCES Protocol MIB
The ForCES MIB [I-D.ietf-forces-mib] is a primarily read-only MIB The ForCES MIB [I-D.ietf-forces-mib] is a primarily read-only MIB
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.
skipping to change at page 10, line 43 skipping to change at page 10, line 43
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 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 to read 1. The ability for a management tool (e.g., SNMP) to be used to read
(but not change) the state of FE SHOULD NOT be precluded. (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". RFC 1812 [2] also dictates that "Routers must be manageable by SNMP".
In general, for the post-association phase, most external management In general, for the post-association phase, most external management
tasks (including SNMP) should be done through interaction with the CE tasks (including SNMP) should be done through interaction with the CE
in order to support the appearance of a single functional device. in order to support the appearance of a single functional device.
Therefore, it is recommended that an SNMP agent be implemented by CEs Therefore, it is recommended that an SNMP agent be implemented by CEs
and that the SNMP messages received by FEs be redirected to their and 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 here
such that CEs act in the role of master agent to process SNMP such that CEs act in the role of master agent to process SNMP
protocol messages while FEs act in the role of subagent to provide protocol messages while FEs act in the role of subagent to provide
access to the MIB objects residing on FEs. AgentX protocol messages access to the MIB objects residing on FEs. AgentX protocol messages
between the master agent (CE) and the subagent (FE) are encapsulated between the master agent (CE) and the subagent (FE) are encapsulated
skipping to change at page 11, line 42 skipping to change at page 11, line 42
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. Acknowledgments 8. IANA Considerations
This document has no IANA actions.
[RFC Editor: please remove this section prior to publication.]
9. Acknowledgments
Many of the colleagues in our companies and participants in the Many of the colleagues in our companies and participants in the
ForCES mailing list have provided invaluable input into this work. ForCES mailing list have provided invaluable input into this work.
Particular thanks to Jamal Hadi Salim. Particular thanks to Jamal Hadi Salim.
9. References 10. References
9.1. Normative References
10.1. Normative References
[I-D.ietf-forces-mib] [I-D.ietf-forces-mib]
HAAS, R., "ForCES MIB", draft-ietf-forces-mib-10 (work in HAAS, R., "ForCES MIB", draft-ietf-forces-mib-10 (work in
progress), September 2008. progress), September 2008.
[I-D.ietf-forces-model] [I-D.ietf-forces-model]
Halpern, J. and J. Salim, "ForCES Forwarding Element Halpern, J. and J. Salim, "ForCES Forwarding Element
Model", draft-ietf-forces-model-16 (work in progress), Model", draft-ietf-forces-model-16 (work in progress),
October 2008. October 2008.
skipping to change at page 12, line 31 skipping to change at page 12, line 40
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003. 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.
9.2. Informative References 10.2. Informative References
[RFC3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, [RFC3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen,
B., and J. Segers, "Megaco Protocol Version 1.0", B., and J. Segers, "Megaco Protocol Version 1.0",
RFC 3015, November 2000. RFC 3015, November 2000.
[RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
"General Switch Management Protocol (GSMP) V3", RFC 3292, "General Switch Management Protocol (GSMP) V3", RFC 3292,
June 2002. June 2002.
Authors' Addresses Authors' Addresses
 End of changes. 17 change blocks. 
29 lines changed or deleted 37 lines changed or added

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