Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5810

Forwarding and Control Element Separation (ForCES) Protocol Specification

Pages: 124
Proposed Standard
Errata
Updated by:  71217391
Part 1 of 5 – Pages 1 to 10
None   None   Next

Top   ToC   RFC5810 - Page 1
Internet Engineering Task Force (IETF)                     A. Doria, Ed.
Request for Comments: 5810                Lulea University of Technology
Category: Standards Track                             J. Hadi Salim, Ed.
ISSN: 2070-1721                                                     Znyx
                                                            R. Haas, Ed.
                                                                     IBM
                                                        H. Khosravi, Ed.
                                                                   Intel
                                                            W. Wang, Ed.
                                                                 L. Dong
                                           Zhejiang Gongshang University
                                                                R. Gopal
                                                                   Nokia
                                                              J. Halpern
                                                              March 2010


           Forwarding and Control Element Separation (ForCES)
                         Protocol Specification

Abstract

This document specifies the Forwarding and Control Element Separation (ForCES) protocol. The ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC 3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML). Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. 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/rfc5810.
Top   ToC   RFC5810 - Page 2
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.
Top   ToC   RFC5810 - Page 3

Table of Contents

1. Introduction ....................................................5 2. Terminology and Conventions .....................................6 2.1. Requirements Language ......................................6 2.2. Other Notation .............................................6 2.3. Integers ...................................................6 3. Definitions .....................................................6 4. Overview .......................................................10 4.1. Protocol Framework ........................................11 4.1.1. The PL .............................................13 4.1.2. The TML ............................................14 4.1.3. The FEM/CEM Interface ..............................14 4.2. ForCES Protocol Phases ....................................15 4.2.1. Pre-association ....................................16 4.2.2. Post-association ...................................18 4.3. Protocol Mechanisms .......................................19 4.3.1. Transactions, Atomicity, Execution, and Responses ..19 4.3.2. Scalability ........................................25 4.3.3. Heartbeat Mechanism ................................26 4.3.4. FE Object and FE Protocol LFBs .....................27 4.4. Protocol Scenarios ........................................27 4.4.1. Association Setup State ............................27 4.4.2. Association Established State or Steady State ......29 5. TML Requirements ...............................................31 5.1. TML Parameterization ......................................34 6. Message Encapsulation ..........................................35 6.1. Common Header .............................................35 6.2. Type Length Value (TLV) Structuring .......................40 6.2.1. Nested TLVs ........................................41 6.2.2. Scope of the T in TLV ..............................41 6.3. ILV .......................................................41 6.4. Important Protocol Encapsulations .........................42 6.4.1. Paths ..............................................42 6.4.2. Keys ...............................................42 6.4.3. DATA TLVs ..........................................43 6.4.4. Addressing LFB Entities ............................43 7. Protocol Construction ..........................................44 7.1. Discussion on Encoding ....................................48 7.1.1. Data Packing Rules .................................48 7.1.2. Path Flags .........................................49 7.1.3. Relation of Operational Flags with Global Message Flags ......................................49 7.1.4. Content Path Selection .............................49 7.1.5. LFBselect-TLV ......................................49 7.1.6. OPER-TLV ...........................................50 7.1.7. RESULT TLV .........................................52 7.1.8. DATA TLV ...........................................55
Top   ToC   RFC5810 - Page 4
           7.1.9. SET and GET Relationship ...........................56
      7.2. Protocol Encoding Visualization ...........................56
      7.3. Core ForCES LFBs ..........................................59
           7.3.1. FE Protocol LFB ....................................60
           7.3.2. FE Object LFB ......................................63
      7.4. Semantics of Message Direction ............................63
      7.5. Association Messages ......................................64
           7.5.1. Association Setup Message ..........................64
           7.5.2. Association Setup Response Message .................66
           7.5.3. Association Teardown Message .......................68
      7.6. Configuration Messages ....................................69
           7.6.1. Config Message .....................................69
           7.6.2. Config Response Message ............................71
      7.7. Query Messages ............................................73
           7.7.1. Query Message ......................................73
           7.7.2. Query Response Message .............................75
      7.8. Event Notification Message ................................77
      7.9. Packet Redirect Message ...................................79
      7.10. Heartbeat Message ........................................82
   8. High Availability Support ......................................83
      8.1. Relation with the FE Protocol .............................83
      8.2. Responsibilities for HA ...................................86
   9. Security Considerations ........................................87
      9.1. No Security ...............................................87
           9.1.1. Endpoint Authentication ............................88
           9.1.2. Message Authentication .............................88
      9.2. ForCES PL and TML Security Service ........................88
           9.2.1. Endpoint Authentication Service ....................88
           9.2.2. Message Authentication Service .....................89
           9.2.3. Confidentiality Service ............................89
   10. Acknowledgments ...............................................89
   11. References ....................................................89
      11.1. Normative References .....................................89
      11.2. Informative References ...................................90
   Appendix A.  IANA Considerations ..................................91
     A.1.  Message Type Namespace ....................................91
     A.2.  Operation Selection .......................................92
     A.3.  Header Flags ..............................................93
     A.4.  TLV Type Namespace ........................................93
     A.5.  RESULT-TLV Result Values ..................................94
     A.6.  Association Setup Response ................................94
     A.7.  Association Teardown Message ..............................95
   Appendix B.  ForCES Protocol LFB Schema ...........................96
     B.1.  Capabilities .............................................102
     B.2.  Components ...............................................102
   Appendix C.  Data Encoding Examples ..............................103
   Appendix D.  Use Cases ...........................................107
Top   ToC   RFC5810 - Page 5

1. Introduction

Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework. While there may be multiple protocols used within the overall ForCES architecture, the terms "ForCES protocol" and "protocol" as used in this document refer to the protocol used to standardize the information exchange between Control Elements (CEs) and Forwarding Elements (FEs) only. The ForCES FE model [RFC5812] presents a formal way to define FE Logical Function Blocks (LFBs) using XML. LFB configuration components, capabilities, and associated events are defined when the LFB is formally created. The LFBs within the FE are accordingly controlled in a standardized way by the ForCES protocol. This document defines the ForCES protocol specifications. The ForCES protocol works in a master-slave mode in which FEs are slaves and CEs are masters. The protocol includes commands for transport of LFB configuration information, association setup, status, event notifications, etc. Section 3 provides a glossary of terminology used in the specification. Section 4 provides an overview of the protocol, including a discussion on the protocol framework and descriptions of the Protocol Layer (PL), a Transport Mapping Layer (TML), and the ForCES protocol mechanisms. Section 4.4 describes several protocol scenarios and includes message exchange descriptions. While this document does not define the TML, Section 5 details the services that a TML MUST provide (TML requirements). The ForCES protocol defines a common header for all protocol messages. The header is defined in Section 6.1, while the protocol messages are defined in Section 7. Section 8 describes the protocol support for high-availability mechanisms including redundancy and fail over. Section 9 defines the security mechanisms provided by the PL and TML.
Top   ToC   RFC5810 - Page 6

2. Terminology and Conventions

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2.2. Other Notation

In Table 1 and Table 2, the following notation is used to indicate multiplicity: (value)+ .... means "1 or more instances of value" (value)* .... means "0 or more instances of value"

2.3. Integers

All integers are to be coded as unsigned binary integers of appropriate length.

3. Definitions

This document follows the terminology defined by the ForCES requirements in [RFC3654] and by the ForCES framework in [RFC3746]. The definitions be are repeated below for clarity. Addressable Entity (AE): A physical device that is directly addressable given some interconnect technology. For example, on IP networks, it is a device that can be reached using an IP address; and on a switch fabric, it is a device that can be reached using a switch fabric port number. Control Element (CE): A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs on how to process packets. CEs handle functionality such as the execution of control and signaling protocols.
Top   ToC   RFC5810 - Page 7
   CE Manager (CEM):

   A logical entity responsible for generic CE management tasks.  It is
   particularly used during the pre-association phase to determine with
   which FE(s) a CE should communicate.  This process is called FE
   discovery and may involve the CE manager learning the capabilities of
   available FEs.

   Data Path:

   A conceptual path taken by packets within the forwarding plane inside
   an FE.

   Forwarding Element (FE):

   A logical entity that implements the ForCES protocol.  FEs use the
   underlying hardware to provide per-packet processing and handling as
   directed/controlled by one or more CEs via the ForCES protocol.

   FE Model:

   A model that describes the logical processing functions of an FE.
   The FE model is defined using Logical Function Blocks (LFBs).

   FE Manager (FEM):

   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.  This process is called CE discovery and
   may involve the FE manager learning the capabilities of available
   CEs.  An FE manager may use anything from a static configuration to a
   pre-association phase protocol (see below) to determine which CE(s)
   to use.  Being a logical entity, an FE manager might be physically
   combined with any of the other logical entities such as FEs.

   ForCES Network Element (NE):

   An entity composed of one or more CEs and one or more FEs.  To
   entities outside an NE, the NE represents a single point of
   management.  Similarly, an NE usually hides its internal organization
   from external entities.
Top   ToC   RFC5810 - Page 8
   High Touch Capability:

   This term will be used to apply to the capabilities found in some
   forwarders to take action on the contents or headers of a packet
   based on content other than what is found in the IP header.  Examples
   of these capabilities include quality of service (QoS) policies,
   virtual private networks, firewall, and L7 content recognition.

   Inter-FE Topology:

   See FE Topology.

   Intra-FE Topology:

   See LFB Topology.

   LFB (Logical Function Block):

   The basic building block that is operated on by the ForCES protocol.
   The LFB is a well-defined, logically separable functional block that
   resides in an FE and is controlled by the CE via the ForCES protocol.
   The LFB may reside at the FE's data path and process packets or may
   be purely an FE control or configuration entity that is operated on
   by the CE.  Note that the LFB is a functionally accurate abstraction
   of the FE's processing capabilities, but not a hardware-accurate
   representation of the FE implementation.

   FE Topology:

   A representation of how the multiple FEs within a single NE are
   interconnected.  Sometimes this is called inter-FE topology, to be
   distinguished from intra-FE topology (i.e., LFB topology).

   LFB Class and LFB Instance:

   LFBs are categorized by LFB classes.  An LFB instance represents an
   LFB class (or type) existence.  There may be multiple instances of
   the same LFB class (or type) in an FE.  An LFB class is represented
   by an LFB class ID, and an LFB instance is represented by an LFB
   instance ID.  As a result, an LFB class ID associated with an LFB
   instance ID uniquely specifies an LFB existence.
Top   ToC   RFC5810 - Page 9
   LFB Meta Data:

   Meta data is used to communicate per-packet state from one LFB to
   another, but is not sent across the network.  The FE model defines
   how such meta data is identified, produced, and consumed by the LFBs.
   It defines the functionality but not how meta data is encoded within
   an implementation.

   LFB Component:

   Operational parameters of the LFBs that must be visible to the CEs
   are conceptualized in the FE model as the LFB components.  The LFB
   components include, for example, flags, single parameter arguments,
   complex arguments, and tables that the CE can read and/or write via
   the ForCES protocol (see below).

   LFB Topology:

   Representation of how the LFB instances are logically interconnected
   and placed along the data path within one FE.  Sometimes it is also
   called intra-FE topology, to be distinguished from inter-FE topology.

   Pre-association Phase:

   The period of time during which an FE manager and a CE manager are
   determining which FE(s) and CE(s) should be part of the same network
   element.

   Post-association Phase:

   The period of time during which an FE knows which CE is to control it
   and vice versa.  This includes the time during which the CE and FE
   are establishing communication with one another.

   ForCES Protocol:

   While there may be multiple protocols used within the overall ForCES
   architecture, the terms "ForCES protocol" and "protocol" refer to the
   Fp reference points in the ForCES framework in [RFC3746].  This
   protocol does not apply to CE-to-CE communication, FE-to-FE
   communication, or communication between FE and CE managers.
   Basically, the ForCES protocol works in a master-slave mode in which
   FEs are slaves and CEs are masters.  This document defines the
   specifications for this ForCES protocol.
Top   ToC   RFC5810 - Page 10
   ForCES Protocol Layer (ForCES PL):

   A layer in the ForCES protocol architecture that defines the ForCES
   protocol messages, the protocol state transfer scheme, and the ForCES
   protocol architecture itself (including requirements of ForCES TML as
   shown below).  Specifications of ForCES PL are defined by this
   document.

   ForCES Protocol Transport Mapping Layer (ForCES TML):

   A layer in ForCES protocol architecture that uses the capabilities of
   existing transport protocols to specifically address protocol message
   transportation issues, such as how the protocol messages are mapped
   to different transport media (like TCP, IP, ATM, Ethernet, etc.), and
   how to achieve and implement reliability, multicast, ordering, etc.
   The ForCES TML specifications are detailed in separate ForCES
   documents, one for each TML.



(page 10 continued on part 2)

Next Section