RFC 5810
Forwarding and Control Element Separation (ForCES) Protocol Specification
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 SpecificationAbstract
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.
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.
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
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
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.
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.
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.
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.
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.
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)
