ForCES WG B. Khasnabish Internet-Draft ZTE TX, Inc. Intended status: Standards Track E. Haleplidis Expires: April 10, 2015 University of Patras J. Hadi Salim, Ed. Mojatatu Networks October 7, 2014 IETF ForCES Logical Function Block (LFB) Subsidiary Management draft-khs-forces-lfb-subsidiary-management-03.txt Abstract This document discusses ForCES Logical Function Block (LFB) Subsidiary Management (SM). Note that LFB SM is useful for introducing and supporting virtualization of ForCES Network Element (NE) including control Element (CE) and Forwarding Element (FE). The objective is to standardize an LFB to support this virtualization. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- 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." This Internet-Draft will expire on April 10, 2015. Copyright Notice Copyright (c) 2014 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 Khasnabish, et al. Expires April 10, 2015 [Page 1] Internet-Draft ForCES LFB Subsidiary Management October 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Conventions and Definitions . . . . . . . . . . . . . . . 4 2. Use of Virtualized ForCES Elements . . . . . . . . . . . . . 5 2.1. Use of Virtualized CEs . . . . . . . . . . . . . . . . . 6 2.2. Use of Virtualized FEs . . . . . . . . . . . . . . . . . 6 2.3. Generic Lifecycle of Physical/Virtual Elements . . . . . 6 3. Potential Scenarios . . . . . . . . . . . . . . . . . . . . . 7 3.1. Recovery from FE failure . . . . . . . . . . . . . . . . 7 3.2. Recovery from CE failure . . . . . . . . . . . . . . . . 9 3.3. Load Balancing . . . . . . . . . . . . . . . . . . . . . 10 3.4. Scalable/Robust Service Function Chaining . . . . . . . . 10 3.5. Orchestration . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Generic LFB Lifecycle Management . . . . . . . . . . . . 10 3.6.1. Booting a CE/FE . . . . . . . . . . . . . . . . . . . 10 3.6.2. Bootstrapping the Configuration . . . . . . . . . . . 10 3.6.3. Runtime Management . . . . . . . . . . . . . . . . . 10 4. FEM Library . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Frame Definitions . . . . . . . . . . . . . . . . . . . . 11 4.2. Datatype Definitions . . . . . . . . . . . . . . . . . . 11 4.3. Metadata Definitions . . . . . . . . . . . . . . . . . . 11 4.4. FEM . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4.1. Data Handling . . . . . . . . . . . . . . . . . . . . 12 4.4.2. Components . . . . . . . . . . . . . . . . . . . . . 12 4.4.3. Capabilities . . . . . . . . . . . . . . . . . . . . 12 4.4.4. Events . . . . . . . . . . . . . . . . . . . . . . . 12 5. XML for FEM LFB . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This document discusses ForCES Logical Function Block (LFB) Subsidiary Management (SM). Note that LFB SM is useful for Khasnabish, et al. Expires April 10, 2015 [Page 2] Internet-Draft ForCES LFB Subsidiary Management October 2014 introducing and supporting virtualization of ForCES Network Element (NE) including control Element (CE) and Network Element (NE). Deployment experience has demonstrated the value of using ForCES to control the Forwarding Element Manager (FEM) by creating an LFB to represent its function using the same encoding rules as for any other LFB. This allows it to be controlled by the same Control Element (CE). This work item assumes the presence of an initially booted FE whose configuration could then be updated at runtime via an FEM LFB for runtime config purposes (e.g., by adding a new CE and its associated IP address). This work item can also be useful in addressing control of virtual FEs where individual FEM Managers can be addressed to control the creation, configuration, and resource assignment of such virtual FEs within a physical FE. This work would result in a standards track LFB FEM library RFC. 1.1. Scope The scope of this document is discussion (and standardization) of utilizing virtualized NEs (VNEs)for virtual CEs (VCEs) and virtual FEs (VFEs). Subsidiary management refers to utilizing (via e.g., proper bootstraping) VCEs and VFEs from the pools of these elements. The intention is to form pools of VCEs and VFEs rather than discussing the details of addition/deletion of VCE/VFE to these pools. Note that the currently existing techniques and solutions may be either slow or not directly applicable to ForCES LFB subsidiary management. 1.2. Abbreviations o API: Application Programming Interface o CE: Control Element o CEM: CE Manager o CEV: CE Visor o FE: Forwarding Element o FEM: FE Manager Khasnabish, et al. Expires April 10, 2015 [Page 3] Internet-Draft ForCES LFB Subsidiary Management October 2014 o FEV: FE Visor o FEVM: FE Virtualization Manager o ForCES: Forwarding and Control Element Separation o LFB: Logical Functional Block o NE: Network Element o PL: Protocol Layer o SFC: Service Function Chaining o TML: Transport Mapping Layer o VCE: Virtual CE o VFE: Virtual FE o VNE: Virtual NE 1.3. Conventions and Definitions 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 [6]. The following definitions are taken from [7], [8] and [1]. They are repeated here for convenience as needed, but the normative definitions are found in the referenced RFCs: o Logical Functional Block (LFB) -- A template that represents a fine-grained, logically separate aspects of FE processing. This is also an FB that standardizes and assists the creation of NEs. o 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 by a CE via the ForCES Protocol. o 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. o ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. An NE usually hides its internal Khasnabish, et al. Expires April 10, 2015 [Page 4] Internet-Draft ForCES LFB Subsidiary Management October 2014 organization from external entities and represents a single point of management to entities outside the NE. o FE Manager (FEM) - A logical entity that operates in the pre- association phase and is responsible for determining to 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. This is also a logical entity that is responsible for generic FE management tasks such as the settings of TML protocol parameters and secure parameters; the functions of FEM are open and extensible. o FE Virtualization Manager(FEVM) - This is a Virtualization Manager. Note that there is an inheritance relationship between FEM LFB and FEVM LFB. o CE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to 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. o ForCES Protocol -- The protocol used for communication communication between CEs and FEs. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or to communication between FE and CE managers. The ForCES protocol is a master-slave protocol in which FEs are slaves and CEs are masters. This protocol includes both the management of the communication channel (e.g., connection establishment, heartbeats) and the control messages themselves. o 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 in [1] o ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in ForCES protocol architecture that specifically addresses the protocol message transportation issues, such as how the protocol messages are mapped to different transport media (like SCTP, IP, TCP, UDP, ATM, Ethernet, etc), and how to achieve and implement reliability, security, etc. 2. Use of Virtualized ForCES Elements Virtualization of ForCES Elements allows efficient, scalable, and robust utilization of network control and transmission resources. Virtualization has been discussed (and deployed) widely in the Khasnabish, et al. Expires April 10, 2015 [Page 5] Internet-Draft ForCES LFB Subsidiary Management October 2014 Computing Industry (e.g., server) in the context of efficient utilization of server resources. As mentioned before, the currently existing techniques and solutions may be either slow or not directly applicable to ForCES LFB subsidiary management. 2.1. Use of Virtualized CEs In this section we discuss the use of virtualized ForCES control elements (CEs). The resulting operating entities in virtualized environment are Virtual CEs of VCEs. The CE Visor (CEV) has the visibility to all of the VCEs in a domain, and can assign one of the VCEs as primary Master-VCE and another as secondary Master-VCE. CEV can dynamically manage the role of primary and secondary master-VCEs from a pool of VCEs. 2.2. Use of Virtualized FEs In this section we discuss the use of virtualized ForCES forwarding elements (FEs). The resulting operating entities in virtualized environment are Virtual FEs of VFEs. The FE Visor (FEV) has the visibility to all of the VFEs in a domain, and can assign one of the VFEs as primary Master-VFE and another as secondary Master-VFE. FEV can dynamically manage the role of primary and secondary master-VFEs from a pool of VFEs. 2.3. Generic Lifecycle of Physical/Virtual Elements The generic lifecycle of physical/virtual elements including NEs, FEs, VNEs, VCEs, VFEs, etc. consists of the following FOUR states: o (a)Instantiation -- This refers to instantiation of CEs and FEs. o (b) Association -- This refers to associating FEs to the CEs o (c) Activation -- This refers to activation of CEs and FEs for normal operation. This state may include monitoring as well with an objective to satisfy both scaling and reliability requirements. o (d) Release -- This refers to releasing resources (both physical and virtual elements) to the pool of available (that is un- assigned) elements, and reporting this to the appropriate (CE or FE) manager. It may be required to cleanse the physical/virtual elements before releasing in order to prevent harvesting of data/ information by the the next user of the CEs/FEs. The details of the cleansing operation is out of scope of this draft. Khasnabish, et al. Expires April 10, 2015 [Page 6] Internet-Draft ForCES LFB Subsidiary Management October 2014 Figure 1 shows physical/virtual elements states and their transition. o--------------o o--------------o | | | | |Instantiation +----------------->| Association | | | | | o--------------o o------+-------o ^ | | | | | | | | | o------+-------o o------V-------o | | | | | Release |<-----------------+ Activation | | | | | o--------------o o--------------o Figure 1: Physical/Virtual Elements States and their Transition 3. Potential Scenarios In this section we discuss a few potential scenarios that can utilize ForCES LFB subsidiary management for efficient and robust operation of networks without using excessive additional resources. 3.1. Recovery from FE failure In this section we discuss how virtualization of FEs can be used for efficient recovery from FE failure(s). An FE can initially boot using a default Association and Configuration. The Association and Configuration can be updated at runtime via an FE-Visor or FEM LFB for runtime configuration purposes. This can be achieved, for example, by adding a new CE and its associated IP address. A CE can initially boot using a default Configuration and State(s). The Configuration and State(s) can be updated at runtime via a CE-Visor or CEM LFB to satisfy the runtime requirements. Khasnabish, et al. Expires April 10, 2015 [Page 7] Internet-Draft ForCES LFB Subsidiary Management October 2014 .--------------. [Apps/ | | Service]--|Orchestration | | | .--------------. | | .--------. .-----------. | | | | | |---| |---------------------------| | |Controller | | | | | | | .-|-----|---. |Hyper- | | | |Visor | 4 2 | | | | | | | CEy CEw .... CE? | | | | \ /\ | | | | \----/--\-------------------------------|----| | | | / \ | .-|-. | | FEM-----/ \-----------------------------|--| | | .-->(FEz)<-----------------3----------------------|--|FEx| | | .---. | (1)----->| | .--------. Figure 2: Sequence of Events in FEM for Recovery from FE Failure Note: 1.(Hyervisor) Boots up FEx, and connects to CEy and CEw, 2. Boot a VM of Type FE 3. FEx Boots FEz, and Connects to CEy, 4.Connect to CEw As described in Figure 2, the following is a sequence of events in FEM (an example). o Step-1: Hypervisor boots up with FEx that connects to CEy and CEw. o Step-2: The Controller (attached to CEy) instructs FEx to boot an FE-type VM. o Step-3: FEx boots FEz and instructs it to connect to CEy o Step-4: The Controller (attached to FEz) instructs FEz to also connect to CEw. This is essentially the "Association" part of Association and Configuration, as discussed earlier. Khasnabish, et al. Expires April 10, 2015 [Page 8] Internet-Draft ForCES LFB Subsidiary Management October 2014 o Step-5: The Controller (attached to FEz) instructs FEz to increase its Syslog debug level. This is essentially the "Configuration" part of Association and Configuration, as discussed earlier. Note that the 4th (FEM part of the charter) and 5th steps are what we would like to achieve here. In addition, the FEVM may not need to be aware which Virtual FEs are in one Virtual NE, it only needs know of the information about a Virtual FE in the physical FE. CE Manager may need to have visibility to all Virtual NEs. The component "NE" of the LFB may be considered as Virtual NE as well. 3.2. Recovery from CE failure In this section we discuss how virtualization of CEs can be used for efficient recovery from CE failure(s). A CE can initially boot using a default Association, State, and Configuration. The Association and Configuration can be updated at runtime via a CE-Visor or CEM-LFB for runtime configuration purposes, for example, by adding a new CE and its associated IP address. An FE can initially boot using a default Configuration, Association, with a CE, and State. The Configuration, Association can be updated at runtime via a FE-Visor or FEM LFB to satisfy runtime requirements. The sequence of events, an example, can be as follows. o Step-1: The CEx is Active with CEy as its Standby with Standby- Active or Active-Active setup. o Step-2: The CEx controls FEy and FEw with both FEy and FEw having Standby control links to CEy, with Standby-Active or Active-Active setup. Note that CEx and CEy are controlled, assigned, by CE- visor, and may have a common, virtual, IP address. o Step-3: The Controller is fully aware of the status of all of the CEs, physical and virtual; When CEx fails, its states are fully transferred (may already be synced) to CEy. o Step-4: The Standby links from CEy to FEy and FEw become fully active, and the control, of FEy and FEw, is fully transferred from CEx and CEy. o Step-5: A graceful-smooth failover of CEx to CEy is now successfully complete, and SysLog debug level for CEy is increased.. As discussed earlier, the last two steps are concerned with Subsidiary management. Although we discuss the recovery method by Khasnabish, et al. Expires April 10, 2015 [Page 9] Internet-Draft ForCES LFB Subsidiary Management October 2014 using virtualization of CEs, the role of FEVM in the recovery process will be described further later. 3.3. Load Balancing In this section we discuss efficient load balancing of both CE and FE in virtualized environment. 3.4. Scalable/Robust Service Function Chaining In this section we discuss how LFB subsidiary management can contribute to the robust/scalable implementation of Service Function Chaining (SFC). 3.5. Orchestration In this section we discuss efficient Orchestration of both CE and FE in virtualized multi-admin-domain environment. 3.6. Generic LFB Lifecycle Management In this section we discuss generic lifecycle management of subsidiaries of LFBs in virtualized environment(s). The typical management activities in the life of FE/CE are discussed in the following sub-sections. 3.6.1. Booting a CE/FE When an entity needs to boot a CE/FE, if this is a VM, some orchestration would scheme/plan to do this. In case of ForCES, we have a control App that boots a CE or an FE via a management FE. So here we have a management plane details that is described either in FEM or other LFB. 3.6.2. Bootstrapping the Configuration The FE, e.g., the VM which has just been booted, as described in the previous sub-section, needs initial bootstrap configuration (e.g., what CEs to connect to etc). This clearly falls in the FEM LFB domain. 3.6.3. Runtime Management At runtime of the FE, for example, the management could introduce a new CE for the FE to associate with; it may also be for an FE to dissociate from a CE, and so on. Khasnabish, et al. Expires April 10, 2015 [Page 10] Internet-Draft ForCES LFB Subsidiary Management October 2014 4. FEM Library 4.1. Frame Definitions This LFB does not define any frames 4.2. Datatype Definitions This library defines the following datatypes. +----------+-----------------------------------------+--------------+ | DataType | Type | Synopsis | | Name | | | +----------+-----------------------------------------+--------------+ | IPs | A Struct of 2 components. IPv4 | A struct | | | (byte[4]) and IPv6 (byte[16]) | that defines | | | addresses. | an IPv4 and | | | | an IPv6 | | | | address | | LFBDefs | A Struct that contains three | A struct | | | components. The LFB Class ID (uint32), | that defines | | | the LFB version (string)and the LFB | basic LFB | | | name (string) | definitions | | CEParams | A Struct that contains two components. | A struct | | | A CE's ID (uint32) and the CE's IPs | that defines | | | (array of IPs) | CE | | | | parameters. | | FEParams | A Struct that contains four components. | A struct | | | An FE's ID (uint32), the FE's IPs | that defines | | | (array of IPs), the LFBs this FE | the FE | | | supports (array of LFBDefs) and the CEs | parameters. | | | this FE is part of (array of CEParams). | | +----------+-----------------------------------------+--------------+ FEM Data Types 4.3. Metadata Definitions This LFB does not define any metadata definition 4.4. FEM The LFB is an LFB that standardizes and assists creation of NEs. Khasnabish, et al. Expires April 10, 2015 [Page 11] Internet-Draft ForCES LFB Subsidiary Management October 2014 4.4.1. Data Handling The FEM LFB does not handle any packets. It's function is to subsidize creation of NEs. A CE or a CEM will request from the FEM the creation of the NE, it will provide the requirements, e.g. FEs, LFBs in FEs etc..., and depending on the implementation the FEM may create these FE instances, or if these instances exist, provide the bootstrap information to FEs how and where to connect to the CEs. 4.4.2. Components This LFB has only one component specified. The NEs component, is a component that contains all the Network Elements this FEM is responsible for maintaining. It is a table and each row is a struct of the NEID, a uint32 and an array of FE parameters. 4.4.3. Capabilities This LFB has no Capabilities specified. 4.4.4. Events This LFB has three events specified. These events notify the CE whether an NE has been added, deleted or changed. The event report is the NEs row that created the event. 5. XML for FEM LFB IPs IP definition FEIPv4 The FEs IPv4 byte[4] FEIPv6 The FEs IPv6 byte[16] Khasnabish, et al. Expires April 10, 2015 [Page 12] Internet-Draft ForCES LFB Subsidiary Management October 2014 LFBDefs LFB parameters inside the FE LFBClassID The LFB Class ID uint32 LFBVersion The Version of the LFB string LFBName The name of the LFB string CEParams CE parameters CEID The CE ID uint32 CEIP The CEIP IPs FEParams FE parameters FEID The FEID Khasnabish, et al. Expires April 10, 2015 [Page 13] Internet-Draft ForCES LFB Subsidiary Management October 2014 uint32 FEIP The FE's IP IPs LFBparameters The LFBs in this FE LFBDefs CEs The CEs that should be associated with this FE CEParams FEM The Forwarding Element Manager LFB 1.0 NEs All the Network Elements this FEM is responsible for maintaining NEID ID of the Network Element uint32 FEs FEs in the Network Element Khasnabish, et al. Expires April 10, 2015 [Page 14] Internet-Draft ForCES LFB Subsidiary Management October 2014 FEParams NEchanged The NE definition has changed NEs NEs _NEsrowid_ NEcreated An NE has been created NEs NEs _NEsrowid_ NEdeleted An NE has been deleted NEs NEs _NEsrowid_ Khasnabish, et al. Expires April 10, 2015 [Page 15] Internet-Draft ForCES LFB Subsidiary Management October 2014 Figure 1: FEM XML LFB library 6. Security Considerations Security considerations for ForCES LFB subsidiary management will be added in a future version of this daft. 7. IANA Considerations 7.1. LFB Class Names and LFB Class Identifiers LFB classes defined by this document belong to LFBs defined by Standards Track RFCs. According to IANA, the registration procedure is Standards Action for the range 0 to 65535 and First Come First Served with any publicly available specification for over 65535. This specification includes the following LFB class names and LFB class identifiers: +------------+---------+---------+----------------------+-----------+ | LFB Class | LFB | LFB | Description | Reference | | Identifier | Class | Version | | | | | Name | | | | +------------+---------+---------+----------------------+-----------+ | 21 | FEM | 1.0 | An FEM LFB to | This | | | | | standardize creation | document | | | | | of ForCES Network | | | | | | Elements | | +------------+---------+---------+----------------------+-----------+ Logical Functional Block (LFB) Class Names and Class Identifiers 8. Acknowledgments The authors would like to thank DJ, Joel, ChuanhuangLi, and many others for their discussions and support. Khasnabish, et al. Expires April 10, 2015 [Page 16] Internet-Draft ForCES LFB Subsidiary Management October 2014 9. References 9.1. Normative References [1] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010. [2] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010. [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [4] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013. 9.2. Informative References [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003. [8] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. Authors' Addresses Bhumip Khasnabish ZTE TX, Inc. 55 Madison Avenue, Suite 160 Morristown, New Jersey 07960 USA Phone: +001-781-752-8003 Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com URI: http://tinyurl.com/bhumip/ Khasnabish, et al. Expires April 10, 2015 [Page 17] Internet-Draft ForCES LFB Subsidiary Management October 2014 Evangelos Haleplidis University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece Email: ehalep@ece.upatras.gr Jamal Hadi Salim (editor) Mojatatu Networks Suite 400, 303 Moodie Dr. Ottawa, Ontario K2H 9R4 Canada Email: hadi@mojatatu.com Khasnabish, et al. Expires April 10, 2015 [Page 18]