idnits 2.17.1 draft-djjhs-forces-lfbstate-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 13, 2012) is 4213 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Joachimpillai 3 Internet-Draft Verizon 4 Intended status: Informational Hadi Salim 5 Expires: April 16, 2013 Mojatatu Networks 6 October 13, 2012 8 ForCES LFB Instance State 9 draft-djjhs-forces-lfbstate-00 11 Abstract 13 The ForCES LFB Topology currently defines that once an instance of an 14 LFB class is created it becomes immediately active in the datatapath. 15 This document makes a slight extension to add state to an 16 instantiated LFB class allowing the CE to decide when an LFB instance 17 becomes operational on the datapath. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 16, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Terminology and Conventions . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 55 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Changed XML . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Terminology and Conventions 70 1.1. Requirements Language 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 1.2. Definitions 78 This document follows the terminology defined by the ForCES Model in 79 [RFC5812]. The required definitions are repeated below for clarity. 81 FE Model - The FE model is designed to model the logical 82 processing functions of an FE. The FE model proposed in this 83 document includes three components; the LFB modeling of individual 84 Logical Functional Block (LFB model), the logical interconnection 85 between LFBs (LFB topology), and the FE-level attributes, 86 including FE capabilities. The FE model provides the basis to 87 define the information elements exchanged between the CE and the 88 FE in the ForCES protocol [RFC5810]. 90 LFB (Logical Functional Block) Class (or type) - A template that 91 represents a fine-grained, logically separable aspect of FE 92 processing. Most LFBs relate to packet processing in the data 93 path. LFB classes are the basic building blocks of the FE model. 95 LFB Instance - As a packet flows through an FE along a data path, 96 it flows through one or multiple LFB instances, where each LFB is 97 an instance of a specific LFB class. Multiple instances of the 98 same LFB class can be present in an FE's data path. Note that we 99 often refer to LFBs without distinguishing between an LFB class 100 and LFB instance when we believe the implied reference is obvious 101 for the given context. 103 LFB Model - The LFB model describes the content and structures in 104 an LFB, plus the associated data definition. XML is used to 105 provide a formal definition of the necessary structures for the 106 modeling. Four types of information are defined in the LFB model. 107 The core part of the LFB model is the LFB class definitions; the 108 other three types of information define constructs associated with 109 and used by the class definition. These are reusable data types, 110 supported frame (packet) formats, and metadata. 112 LFB Metadata - Metadata is used to communicate per-packet state 113 from one LFB to another, but is not sent across the network. The 114 FE model defines how such metadata is identified, produced, and 115 consumed by the LFBs, but not how the per-packet state is 116 implemented within actual hardware. Metadata is sent between the 117 FE and the CE on redirect packets. 119 ForCES Component - A ForCES Component is a well-defined, uniquely 120 identifiable and addressable ForCES model building block. A 121 component has a 32-bit ID, name, type, and an optional synopsis 122 description. These are often referred to simply as components. 124 LFB Component - An LFB component is a ForCES component that 125 defines the Operational parameters of the LFBs that must be 126 visible to the CEs. 128 LFB Topology - LFB topology is a representation of the logical 129 interconnection and the placement of LFB instances along the data 130 path within one FE. Sometimes this representation is called 131 intra-FE topology, to be distinguished from inter-FE topology. 132 LFB topology is outside of the LFB model, but is part of the FE 133 model. 135 FE Topology - FE topology is a representation of how multiple FEs 136 within a single network element (NE) are interconnected. 137 Sometimes this is called inter-FE topology, to be distinguished 138 from intra-FE topology (i.e., LFB topology). An individual FE 139 might not have the global knowledge of the full FE topology, but 140 the local view of its connectivity with other FEs is considered to 141 be part of the FE model. 143 2. Introduction 145 In the ForCES architecture, a packet service can be modelled by 146 composing a graph of one or more LFB instances. The reader is 147 refered to the details in the ForCES Model [RFC5812]. The CE 148 instantiates a class on the FE making it available for component 149 update (eg table updates) as well as datapath processing. 151 If an FE is capable of dealing with modifiable LFB topology, then the 152 CE may create a packet service when describing LFB instance graph 153 connections by updating the FEOBject LFBTopology component. 155 3. Problem Scope 157 Sometimes it is prudent, after an LFB class is instantiated, to first 158 populate an LFB instance with its configuration before activating it. 159 There are various challenges we face which motivate this document: 161 o There are cases where an LFB instance may require some minimalist 162 configuration before it can pass data. Any data received before 163 the full configuration is updated may cause race conditions or 164 corruptions. 166 o The LFB instance may require to receive configuration without 167 being active in the datapath until a future determined time the CE 168 deems. Such is the case when an LFB instance on an LFB is acting 169 as backup of another instance running in another FE. 171 In both cases described above, we require ability for the CE to 172 instantiate, populate the LFB instance with control data then later 173 activate the populated LFB instance. We also need the ability to 174 offline an LFB instance by having the CE deactivate it. 176 It should be noted that the FE Object LFB already allows the FE to be 177 activated or offlined from the datapath. The CE may set the 178 component FEState to be either administratively disabled or 179 operationally disabled as well as operationally enabled. The new 180 requirement in this document is to refine the granularity to be at 181 the LFB instance level. 183 4. Proposal Overview 185 We propose a backward and forward compatible solution by extending 186 the FEObject LFB. 188 We propose 3 changes: 190 1. Introduce a new FEObject Datatypedef which extends the 191 LFBSelectorType. The newLFBSelectorType will have, in addition 192 to the LFB class and instance identification, state definition in 193 the form of a reference to FEStateValues. 195 2. Introduce a new component which is a table of newLFBSelectorType. 196 This table will parallel the LFBSelectors(ID 2) but will 197 additionally carry the LFB instance state. Old CE 198 implementations can continue to update the LFBSelectors table and 199 ignore the newLFBSelectors table. Such old CE implementations 200 will not be able to use this new feature even if the FE was 201 capable. New CE implementations can update newLFBSelectors table 202 while ignoring the LFBSelectors table. To meet our stated goals, 203 the default state in the newLFBSelectors state will be 204 OperDisable. The CE will have to take the extra step of 205 activating by setting it the state to OperDisable. 207 3. Introduce a capability advertised by the FE to announce its 208 ability to handle the newLFBSelectors table. XXX: do we require 209 a change to the FEO version? 211 4.1. Changed XML 213 TBA 215 5. Acknowledgements 217 TBA 219 6. IANA Considerations 221 This memo includes no request to IANA. 223 7. Security Considerations 225 TBA 227 8. References 229 8.1. Normative References 231 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 232 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 233 Control Element Separation (ForCES) Protocol 234 Specification", RFC 5810, March 2010. 236 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 237 Element Separation (ForCES) Forwarding Element Model", 238 RFC 5812, March 2010. 240 8.2. Informative References 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, March 1997. 245 Authors' Addresses 247 Damascane M. Joachimpillai 248 Verizon 249 60 Sylvan Rd 250 Waltham, Mass. 02451 251 USA 253 Email: damascene.joachimpillai@verizon.com 255 Jamal Hadi Salim 256 Mojatatu Networks 257 Moodie Dr. 258 Ottawa, Ontario 259 Canada 261 Email: hadi@mojatatu.com