forces
ForCES Working Group                                           A. Crouch
Internet-Draft                                               H. Khosravi
Intended status: Informational                                     Intel
Expires: August 26, December 29, 2010                                A. Doria (ed.)
                                                                     LTU
                                                                 X. Wang
                                                                  Huawei
                                                                K. Ogawa
                                                         NTT Corporation
                                                       February 22,
                                                           June 27, 2010

                     ForCES Applicability Statement
                   draft-ietf-forces-applicability-08
                   draft-ietf-forces-applicability-09

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

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 26, December 29, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   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 Simplified BSD License.

   This document may contain material 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.

Table of Contents

   1.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Applicability to IP Networks . . . . . . . . . . . . . . . . .  4  5
     4.1.  Applicable Services  . . . . . . . . . . . . . . . . . . .  5
       4.1.1.  Discovery,  Association, Capability Discovery and Information
               Exchange . . . . . .  5
       4.1.2.  Topology Information Exchange  . . . . . . . . . . . .  6
       4.1.3.  Configuration . . . . . . . .  5
       4.1.2.  Topology Information Exchange  . . . . . . . . . . . .  6
       4.1.4.  Routing Exchange
       4.1.3.  Configuration  . . . . . . . . . . . . . . . . . . . .  6
       4.1.5.  QoS
       4.1.4.  Routing Exchange . . . . . . . . . . . . . . . . . . .  6
       4.1.5.  QoS Capabilities Exchange and Configuration  . . . . .  6
       4.1.6.  Security Exchange  . . . . . . . . . . . . . . . . . .  6  7
       4.1.7.  Filtering Exchange and Firewalls . . . . . . . . . . .  7
       4.1.8.  Encapsulation, Tunneling Exchange  . . . . . . . . . .  7
       4.1.9.  NAT and Application-level Gateways . . . . . . . . . .  7
       4.1.10. Measurement and Accounting . . . . . . . . . . . . . .  7
       4.1.11. Diagnostics  . . . . . . . . . . . . . . . . . . . . .  7
       4.1.12. Redundancy and Failover  . . . . . . . . . . . . . . .  7
     4.2.  CE-FE Link Capability  . . . . . . . . . . . . . . . . . .  8
     4.3.  CE/FE Locality . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  ForCES Manageability . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  NE as an atomic element Atomic Element  . . . . . . . . . . . . . . . . .  9
     6.2.  NE as composed Composed of manageable elements Manageable Elements  . . . . . . . . . .  9 10
     6.3.  ForCES Protocol MIB  . . . . . . . . . . . . . . . . . . . 10
       6.3.1.  MIB Management of an FE  . . . . . . . . . . . . . . . 10
     6.4.  The FEM and CEM  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11 12
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     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 [I-D.ietf-forces-protocol] [RFC5810] designers as to how the
   protocol could be used (in in conjunction with the ForCES model [I-D.ietf-forces-model]). [RFC5812]
   and a Transport Mapping Layer [RFC5811].

2.  Overview

   The ForCES protocol defines a standard framework and mechanism for
   the exchange of information between the logically separate
   functionality of the control and data forwarding planes of IP routers
   and similar devices.  It focuses on the communication necessary for
   separation of control plane functionality such as routing protocols,
   signaling protocols, and admission control from data forwarding plane
   per-packet activities such as packet forwarding, queuing, and header
   editing.

   This document defines the applicability of the ForCES mechanisms.  It
   describes types of configurations and settings where ForCES is most
   appropriately applied.  This document also describes scenarios and
   configurations where ForCES would not be appropriate for use.

3.  Terminology

   A set of concepts associated with ForCES was introduced in
   Requirements for Separation of IP Control and Forwarding[RFC3654] and
   in Forwarding and Control Element Separation (ForCES)
   Framework[RFC3746].  The terminology associated with these concepts
   and the protocol elements in ForCES is defined in [3, 4].
   That terminology is reused here and the Forwarding and
   Control Element Separation (ForCES) Protocol Specification[RFC5810].

   The reader is directed to [3, 4] these documents for the conceptual
   introduction and the definitions including of the following definitions: acronyms:

   o  CE: Control Element. Element
   o  CEM: Control element manager
   o  FE: Forwarding Element. Element
   o  FEM: Forwarding element manager
   o  ForCES: Forwarding and Control Element Separation protocol
   o  LFB: Logical Function Block
   o  NE: ForCES protocol. network element
   o  TML: Transport Mapping Layer. Layer

4.  Applicability to IP Networks

   The purpose of this

   This section is to list lists the areas of ForCES applicability in IP network
   devices.  Relatively low end  Some relatively low-end routing systems may be implemented
   on simple hardware which performs both control and packet forwarding
   functionality.  ForCES may not make
   sense be useful for such devices.

   Higher end routing systems typically distribute work amongst several
   interface processing elements, and these devices (FEs) therefore need
   to communicate with the control element(s) to perform their job.  A
   higher end router may also distribute control processing amongst
   several processing elements (CEs).  ForCES provides a standard way to
   do this communication.  ForCES also provides support for High
   Availability configurations that include a primary CE and one or more
   secondary CEs.

   The remainder of this section lists the applicable services which
   ForCES may support, applicable FE functionality, applicable CE-FE
   link scenarios, and applicable topologies in which ForCES may be
   deployed.

4.1.  Applicable Services

   In this section we describe the applicability of ForCES for the
   following control-forwarding plane services:

   o Discovery,  Association, Capability discovery and Information Exchange
   o  Topology Information Exchange
   o  Configuration
   o  Routing Exchange
   o  QoS Exchange
   o  Security Exchange
   o  Filtering Exchange
   o  Encapsulation/Tunneling Exchange
   o  NAT and Application-level Gateways
   o  Measurement and Accounting
   o  Diagnostics
   o  CE Redundancy or CE Failover

4.1.1.  Discovery,  Association, Capability Discovery and Information Exchange

   Discovery

   Association is the process by first step of the ForCES protocol exchange in
   which capability discovery and exchange happens between one or more
   CEs and FEs learn of each other's
   existence. the FEs.  ForCES assumes that CEs and FEs already know have
   sufficient information to begin communication in a secure manner.
   The ForCES protocol is only applicable after CEs and FEs have found
   discovered each other.  ForCES makes no assumption about whether
   discovery was performed using a dynamic protocol or merely static
   configuration.  Some discussion about how this can occur can be found
   later in this document in Section 6.4.

   During the discovery association phase, CEs and FEs exchange capability
   information with each other.  For example, the FEs express the number
   of interface ports they provide, as well as the static and
   configurable attributes of each port.

   In addition to initial configuration, the CEs and FEs also exchange
   dynamic configuration changes using ForCES.  For example, FEs
   asynchronously inform the CE CEs of an increase/decrease in available
   resources or capabilities on the FE.

4.1.2.  Topology Information Exchange

   In this context, topology information relates to how the FEs are
   interconnected with each other with respect to packet forwarding.
   Topology discovery is outside the scope of the ForCES protocol.  An
   implementation can choose its own method of topology discovery (for
   example use a standard topology discovery protocol like LLDP, BFD; protocol; or apply a static
   topology configuration policy).  Once the topology is established,
   ForCES protocol may be used to transmit the resulting information to
   the CE. CEs.

4.1.3.  Configuration

   ForCES is used to perform FE configuration.  For example, CEs set
   configurable FE attributes such as IP addresses, etc. for their
   interfaces.

4.1.4.  Routing Exchange

   ForCES may be used to deliver packet forwarding information resulting
   from CE routing calculations.  For example, CEs may send forwarding
   table updates to the FEs, so that they can make forwarding decisions.
   FEs may inform the CE CEs in the event of a forwarding table miss.
   ForCES may also be used to configure ECMP capability.

4.1.5.  QoS Capabilities Exchange and Configuration

   ForCES may be used to exchange QoS capabilities between CEs and FEs.
   For example, an FE may express QoS capabilities to the CE.  Such
   capabilities might include metering, policing, shaping, and queuing
   functions.  The CE may use ForCES to configure these capabilities.

4.1.6.  Security Exchange

   ForCES may be used to exchange Security information between CEs a CE and
   FEs.
   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
   tunnel.  The CE may use ForCES to configure such a tunnel.  The CEs
   would be responsible for the NE dynamic key exchanges and updates.

4.1.7.  Filtering Exchange and Firewalls

   ForCES may be used to exchange filtering information.  For example,
   FEs may use ForCES to express the filtering functions such as
   classification and action that they can perform, and the CE may
   configure these capabilities.

4.1.8.  Encapsulation, Tunneling Exchange

   ForCES may be used to exchange encapsulation capabilities of an FE,
   such as tunneling, and the configuration of such capabilities.

4.1.9.  NAT and Application-level Gateways

   ForCES may be used to exchange configuration information for Network
   Address Translators.  Whilst ForCES is not specifically designed for
   the configuration of application-level gateway functionality, this
   may be in scope for some types of application-level gateways.

4.1.10.  Measurement and Accounting

   ForCES may be used to exchange configuration information regarding
   traffic measurement and accounting functionality.  In this area,
   ForCES may overlap somewhat with functionality provided by
   alternative network management mechanisms such as SNMP.  In some
   cases ForCES may be used to convey information to the CE to be
   reported externally using SNMP.  A further discussion of this
   capability is covered in Section 6 of this document.

4.1.11.  Diagnostics

   ForCES may be used for CEs and FEs to exchange diagnostic
   information.  For example, an FE can send self-test results to the a CE.

4.1.12.  Redundancy and Failover

   The ForCES architecture includes mechanisms which allow for multiple
   redundant CEs and FEs in a ForCES NE.  The ForCES model LFB
   definitions provide sufficient component details via component
   identifiers to be universally unique within an NE.  The ForCES
   protocol includes mechanisms to facilitate transactions as well as
   atomicity across the NE.

   Given the above it is possible to deploy redundant CEs and FEs which
   incorporate failover.

4.2.  CE-FE Link Capability

   When using ForCES, the bandwidth of the CE-FE link is a
   consideration, and cannot be ignored.  For example, sending a full
   routing table is reasonable over a high bandwidth link, but could be
   non-trivial over a lower-bandwidth link.  ForCES should be
   sufficiently future-proof to be applicable in scenarios where routing
   tables grow to several orders of magnitude greater than their current
   size.  However, we also note that not all IP routers need full
   routing tables.

4.3.  CE/FE Locality

   ForCES is intended for environments where one of the following
   applies:

   o  The control interconnect is some form of local bus, switch, or
      LAN, where reliability is high, closely controlled, and not
      susceptible to external disruption that does not also affect the
      CEs and/or FEs.
   o  The control interconnect shares fate with the FE's forwarding
      function.  Typically this is because the control connection is
      also the FE's primary packet forwarding connection, and so if that
      link goes down, the FE cannot forward packets anyway.

   The key guideline is that the reliability of the device should not be
   significantly reduced by the separation of control and forwarding
   functionality.

   Taking this into account, ForCES is applicable in the following CE/FE
   localities:

   o single box

   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
      more forwarding blades, all present in the same chassis and
      sharing an interconnect such as Ethernet or PCI.  In this
      locality, the majority of the data traffic being forwarded
      typically does not traverse the same links as the ForCES control
      traffic.

   o multiple boxes:

   Multiple Box NE:   separated CE and FE where physical locality could
      be same rack, room, building, or long distance which could span
      across continents and oceans.  ForCES is applicable in localities
      consisting of control and forwarding elements which are separated
      by a single hop or multiple hops in the network.

5.  Security Considerations

   The ForCES architecture protocol allows for a variety of security levels[6]. levels
   [RFC5810].  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 CEs and FE. FEs.
   When the operator makes a decision to secure the path between the FE FEs
   and CE CEs 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 IPsec or TLS depending on the choice of TML used in the
   deployment of the NE.

6.  ForCES Manageability

   From one the architectural perspective, it the ForCES NE is a single network
   element; as an example if the ForCES NE is specifically a router that
   needs to be managed managed, then it is should be managed in essentially the
   same way any router is should be managed.  From another perspective
   element management can could view the individual entities and interfaces
   that make up a ForCES NE but this may cause risk on the control
   relationship between the CEs and the FEs unless it has been accounted
   for in the model used by the NE.

6.1.  NE as an atomic element Atomic Element

   From the ForCES requirements RFC 3654, [RFC3654] Section 4, point 4:

   A NE must support the appearance of a single functional device.

   As a single functional device a ForCES NE runs protocols and each of
   the protocols has it own existing manageability aspects that are
   documented elsewhere.  As an example, router would also have a
   configuration interface.  When viewed in this manner, the NE is
   controlled as a single routing entity and no new management beyond
   what is already available for routers and routing protocols would be
   required for a ForCES NE.  Management commands on a management
   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
   atomicity of such commands and may require careful implementation by
   the CE.

6.2.  NE as composed Composed of manageable elements Manageable Elements

   When viewed as a decomposed set of elements from the management
   perspective, the ForCES NE is divided into a set of one of more
   Control Elements, Forwarding Elements and the interfaces between
   them.  The interface functionality between the CE and the FE is
   provided by the ForCES protocol.  As with all IETF protocols a  A MIB module is provided for the purposes
   purpose of managing gaining management information on the protocol. operation of the
   protocol describe in Section 6.3 of this document.

   Additionally the architecture makes provision for configuration
   control of the individual CEs and FEs.  This is handled by elements
   named FE manager (FEM) and the CE manager (CEM).  Specifically from
   the ForCES requirements RFC [RFC 3654], [RFC3654], 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.

6.3.  ForCES Protocol MIB

   The ForCES MIB [I-D.ietf-forces-mib] is [RFC5813] defines a primarily read-only MIB module
   that captures information related to the ForCES protocol.  This
   includes state information about the associations between CE(s) and
   FE(s) in the NE.

   The ForCES MIB does not include information that is specified in
   other MIBs, MIB modules, such as packet counters for interfaces, etc.

   More specifically, the information in the ForCES MIB module relative
   to associations includes:

   -

   o  identifiers of the elements in the association

   -
   o  state of the association

   -
   o  configuration parameters of the association

   -
   o  statistics of the association

6.3.1.  MIB Management of an FE

   While it is possible to manage a FE from a an element manager, several
   requirements relating to this have been included in the ForCES
   Requirements.

   From the ForCES Requirements [RFC 3654], [RFC3654], Section 4, point 14:

   1.  The ability for a management tool (e.g., SNMP) to be used to read
       (but not change) the state of FE should not be precluded.
   2.  It must not be possible for management tools (e.g., SNMP, etc) to
       change the state of a FE in a manner that affects overall NE
       behavior without the CE being notified.

   The ForCES Requirements [RFC 3654], [RFC3654], Section 5.7, goes further in
   discussing the manner in which FEs should handle management requests
   that are specifically directed to the FE:

   For a ForCES NE that is an IP router, RFC 1812 [2] [RFC1812] also dictates that
   "Routers must be manageable by SNMP".  In general, for the post-
   association phase, most external management tasks (including SNMP)
   should be done through interaction with the CE in order to support
   the appearance of a single functional device.  Therefore, it is
   recommended that an SNMP agent be implemented by CEs and that the
   SNMP messages received by FEs be redirected to their CEs.  AgentX
   framework defined in RFC 2741 ([6]) [RFC2741]) may be applied here such that CEs act
   in the role of master agent to process SNMP protocol messages while
   FEs act in the role of subagent sub-agent to provide access to the MIB objects
   residing on FEs.  AgentX protocol messages between the master agent
   (CE) and the subagent sub-agent (FE) are encapsulated and transported via
   ForCES, just like data packets from any other application layer
   protocols.

6.4.  The FEM and CEM

   Though out of scope for the initial ForCES specification effort, the
   ForCES architecture include two entities, the CE Manager (CEM) and
   the FE Manager (FEM).  From the ForCES Protocols Specification
   [I-D.ietf-forces-protocol].
   [RFC5810].

   CE Manager (CEM) -   A logical entity responsible for generic CE
      management tasks.  It is particularly used during the pre-association pre-
      association phase to determine with which FE(s) a CE should
      communicate.
   FE Manager (FEM) -   A logical entity responsible for generic FE
      management tasks.  It is used during pre-association phase to
      determine with which CE(s) an FE should communicate.

7.  Contributors

   The following are the contributors who were instrumental

   Mark Handley was an initial author involved in the
   creation of earlier releases versions
   of this document or who gave good
   suggestions to this document.

   Mark Handley, ICIR.

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 ForCES mailing list as well as fellow employees of
   the authors, have provided invaluable valuable input into this work.  Particular
   thanks go to Jamal Hadi Salim. Salim, our WG chair and document shepherd and
   to Adrian Farrel the AD for the area for their review, comments and
   encouragement without whom this document might never have been
   completed.

10.  References

10.1.  Normative References

   [I-D.ietf-forces-mib]
              HAAS,

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              June 1995.

   [RFC5810]  Doria, A., Hadi Salim, J., Haas, R., "ForCES MIB", draft-ietf-forces-mib-10 (work in
              progress), September 2008.

   [I-D.ietf-forces-model] Khosravi, H., Wang,
              W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
              Control Element Separation (ForCES) Protocol
              Specification", RFC 5810, March 2010.

   [RFC5811]  Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
              Layer (TML) for the Forwarding and Control Element
              Separation (ForCES) Protocol", March 2010.

   [RFC5812]  Halpern, J. and J. Hadi Salim, "ForCES "Forwarding and Control
              Element Separation (ForCES) Forwarding Element Model", draft-ietf-forces-model-16 (work in progress),
              October 2008.

   [I-D.ietf-forces-protocol]
              Dong, L., Doria, A., Gopal, R., HAAS,
              RFC 5812, March 2010.

   [RFC5813]  Haas, R., Salim, J.,
              Khosravi, H., "Forwarding and W. Wang, "ForCES Protocol
              Specification", draft-ietf-forces-protocol-22 (work in
              progress), Control Element Separation
              (ForCES) MIB", RFC 5813, March 2009.

   [RFC2629]  Rose, 2010.

10.2.  Informative References

   [RFC2741]  Daniele, M., Wijnen, B., Ellison, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999. D. Francisco,
              "Agent Extensibility (AgentX) Protocol Version 1",
              January 2000.

   [RFC3654]  Khosravi, H. and T. Anderson, "Requirements for Separation
              of IP Control and Forwarding", RFC 3654, November 2003.

   [RFC3746]  Yang, L., Dantu, R., Anderson, T., and R. Gopal,
              "Forwarding and Control Element Separation (ForCES)
              Framework", RFC 3746, April 2004.

10.2.  Informative References

   [RFC3015]  Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen,
              B., and J. Segers, "Megaco Protocol Version 1.0",
              RFC 3015, November 2000.

   [RFC3292]  Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
              "General Switch Management Protocol (GSMP) V3", RFC 3292,
              June 2002.

Authors' Addresses

   Alan Crouch
   Intel
   2111 NE 25th Avenue
   Hillsboro, OR 97124 USA
   USA

   Phone: +1 503 264 2196
   Email: alan.crouch@intel.com

   Hormuzd Khosravi
   Intel
   2111 NE 25th Avenue
   Hillsboro, OR 97124 USA
   USA

   Phone: 1-503-264-0334
   Email: hormuzd.m.khosravi@intel.com

   Avri Doria
   LTU
   Lulea University of Technology
   Sweden

   Phone: +46 73 277 1788
   Email: avri@acm.org

   Xin-ping Wang
   Huawei
   Beijing
   China

   Phone: +86 10 82836067
   Email: carly.wang@huawei.com
   Kentaro Ogawa
   NTT Corporation
   3-9-11 Midori-cho
   Musashino-shi, Tokyo  180-8585
   Japan

   Email: ogawa.kentaro@lab.ntt.co.jp