idnits 2.17.1 draft-jhs-forces-protoextenstion-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5810]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 225 has weird spacing: '... update using...' -- The document date (July 05, 2013) is 3945 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'N' is mentioned on line 353, but not defined == Unused Reference: 'RFC5812' is defined on line 426, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Hadi Salim 3 Internet-Draft Mojatatu Networks 4 Intended status: Informational July 05, 2013 5 Expires: January 06, 2014 7 ForCES Protocol Extensions 8 draft-jhs-forces-protoextenstion-01 10 Abstract 12 Experience in implementing and deploying ForCES architecture has 13 demonstrated need for a few small extensions both to ease 14 programmability and to improve wire efficiency of some transactions. 15 This document describes a few extensions to the ForCES Protocol 16 Specification [RFC5810] semantics to achieve that end goal. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 06, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Table Append . . . . . . . . . . . . . . . . . . . . . . 5 59 3.3. Error codes . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.4. Bitmap Datatype . . . . . . . . . . . . . . . . . . . . . 6 61 4. Protocol Update Proposal . . . . . . . . . . . . . . . . . . 6 62 4.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Table Append . . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.4. Bitmap Datatype . . . . . . . . . . . . . . . . . . . . . 9 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 7.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Terminology and Conventions 75 1.1. Requirements Language 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 1.2. Definitions 83 This document reiterates the terminology defined by the ForCES 84 architecture in various documents for the sake of clarity. 86 FE Model - The FE model is designed to model the logical 87 processing functions of an FE. The FE model proposed in this 88 document includes three components; the LFB modeling of individual 89 Logical Functional Block (LFB model), the logical interconnection 90 between LFBs (LFB topology), and the FE-level attributes, 91 including FE capabilities. The FE model provides the basis to 92 define the information elements exchanged between the CE and the 93 FE in the ForCES protocol [RFC5810]. 95 LFB (Logical Functional Block) Class (or type) - A template that 96 represents a fine-grained, logically separable aspect of FE 97 processing. Most LFBs relate to packet processing in the data 98 path. LFB classes are the basic building blocks of the FE model. 100 LFB Instance - As a packet flows through an FE along a data path, 101 it flows through one or multiple LFB instances, where each LFB is 102 an instance of a specific LFB class. Multiple instances of the 103 same LFB class can be present in an FE's data path. Note that we 104 often refer to LFBs without distinguishing between an LFB class 105 and LFB instance when we believe the implied reference is obvious 106 for the given context. 108 LFB Model - The LFB model describes the content and structures in 109 an LFB, plus the associated data definition. XML is used to 110 provide a formal definition of the necessary structures for the 111 modeling. Four types of information are defined in the LFB model. 112 The core part of the LFB model is the LFB class definitions; the 113 other three types of information define constructs associated with 114 and used by the class definition. These are reusable data types, 115 supported frame (packet) formats, and metadata. 117 LFB Metadata - Metadata is used to communicate per-packet state 118 from one LFB to another, but is not sent across the network. The 119 FE model defines how such metadata is identified, produced, and 120 consumed by the LFBs, but not how the per-packet state is 121 implemented within actual hardware. Metadata is sent between the 122 FE and the CE on redirect packets. 124 ForCES Component - A ForCES Component is a well-defined, uniquely 125 identifiable and addressable ForCES model building block. A 126 component has a 32-bit ID, name, type, and an optional synopsis 127 description. These are often referred to simply as components. 129 LFB Component - An LFB component is a ForCES component that 130 defines the Operational parameters of the LFBs that must be 131 visible to the CEs. 133 ForCES Protocol - Protocol that runs in the Fp reference points in 134 the ForCES Framework [RFC3746]. 136 ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol 137 architecture that defines the ForCES protocol messages, the 138 protocol state transfer scheme, and the ForCES protocol 139 architecture itself as defined in the ForCES Protocol 140 Specification [RFC5810]. 142 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 143 ForCES protocol architecture that uses the capabilities of 144 existing transport protocols to specifically address protocol 145 message transportation issues, such as how the protocol messages 146 are mapped to different transport media (like TCP, IP, ATM, 147 Ethernet, etc.), and how to achieve and implement reliability, 148 ordering, etc. the ForCES SCTP TML [RFC5811] describes a TML that 149 is mandated for ForCES. 151 2. Introduction 153 Experience in implementing and deploying ForCES architecture has 154 demonstrated need for a few small extensions both to ease 155 programmability and to improve wire efficiency of some transactions. 156 This document describes a few extensions to the ForCES Protocol 157 Specification [RFC5810] semantics to achieve that end goal. 159 This document describes and justifies the need for 4 small extensions 160 which are backward compatible. 162 1. A table range operation to allow a controller or control 163 application to request or delete an arbitrary range of table 164 rows. 166 2. A table append operation to allow a controller to add a new table 167 row using the next available table index. 169 3. Improved Error codes returned to the controller (or control 170 application) to improve granularity of existing defined error 171 codes. 173 4. Optimization to packing and addressing commonly used bitmap 174 structure. 176 3. Problem Overview 178 In this section we present sample use cases to illustrate the 179 challenge being addressed. 181 3.1. Table Ranges 183 Consider, for the sake of illustration, an FE table with 1 million 184 reasonably sized table rows which are sparsely populated. 186 ForCES GET requests sent from a controller (or control app) are 187 prepended with a path to a component and sent to the FE. In the case 188 of indexed tables, the component path can either be to a table or a 189 table row index. A control application attempting to retrieve the 190 first 2000 table rows appearing between row indices 23 and 10023 can 191 achieve its goal in one of: 193 o Dump the whole table and filter for the needed 2000 table rows. 195 o Send upto 10000 ForCES PL requests with monotonically incrementing 196 indices and stop when the needed 2000 entries are retrieved. 198 o Use ForCES batching to send fewer large messages (several path 199 requests at a time with incrementing indices until you hit the 200 require number of entries). 202 All of these approaches are programmatically (from an application 203 point of view) unfriendly, tedious, and are seen as abuse of both 204 compute and bandwidth resources. 206 3.2. Table Append 208 For the sake of illustration, assume that a newly spawned controller 209 application wishes to install a table row but it has no apriori 210 knowledge of which table index to use. 212 ForCES allows a controller/control app to request for the next 213 available table index as demonstrated in (Figure 1) (refer to 214 [RFC5810] section 4.8.2 for details of table properties). 216 CE/App FE 217 | | 218 | | 219 |GETproperty firstUnusedSubscript of table X | 220 1 |------------------------------------------->| 221 | | 222 | Table X firstUnusedSubscript is 1234 | 223 2 |<-------------------------------------------| 224 | | 225 | Table update using index 1234 | 226 3 |<------------------------------------------>| 227 | | 229 Figure 1: ForCES table property request 231 The problem with the above setup is the application requires one 232 roundtrip time to figure out the index to insert into. Moreover, 233 depending on implementation (and in presence of multiple control 234 applications): 236 1. there is no guarantee that the next available subscript in the 237 above example would stay at 1234 at the moment an application 238 chooses to do the update; this will entirely depend on 239 implementation at the FE and/or available holes in the table. 241 2. In case of multiple apps wishing to insert rows to the same table 242 concurently, all contending apps will be returned the same value 243 for unused subscript; however, if all the contending apps try to 244 insert at the same time, only the first one to reach the FE row 245 will succeed. A solution involving a reservation mechanism to 246 ask for an index will contribute complexity. 248 We conclude that even in the best case scenario, if the application 249 wishes to insert more than one entry, it will have to incur the 250 roundtrip time for every to-be-inserted table row. This greatly 251 affects table add latencies and update rates. 253 3.3. Error codes 255 [RFC5810] has defined a generic set of error codes that are to be 256 returned to the CE from an FE. Deployment experience has shown that 257 it would be useful to have more fine grained error codes. As an 258 example, the error code E_NOT_SUPPORTED could be mapped to many FE 259 error source possibilities that need to be then interpreted by the 260 caller based on some understanding of the nature of the sent request. 261 This makes debugging more time consuming. 263 3.4. Bitmap Datatype 265 TBA 267 4. Protocol Update Proposal 269 This section describes proposals to update the protocol for issues 270 discussed in Section 3 272 4.1. Table Ranges 274 We propose to add a Table-range TLV (type ID 0x117) that will be 275 associated with the PATH-DATA TLV in the same manner the KEYINFO-TLV 276 is. 278 OPER = GET 279 PATH-DATA: 280 flags = F_SELTABRANGE, IDCount = 2, IDs = {1,6} 281 TABLERANGE-TLV = {11,23} 283 Figure 2: ForCES table range request 285 Figure 2 illustrates a GET request for a a table range for rows 11 to 286 23 of a table with component path of 1/6. 288 Path flag of F_SELTABRANGE (0x2 i.e bit 1, where bit 0 is F_SELKEY as 289 defined in RFC 5810) is set to indicate the presence of the Table- 290 range TLV. The pathflag bit F_SELTABRANGE can only be used in a GET 291 and is mutually exclusive with F_SELKEY. The FE MUST enforce those 292 constraints and reject a request with an error code of 293 E_INVALID_FLAGS with an english description of what the problem is 294 (refer to Section 4.3). 296 The Table-range TLV contents constitute: 298 o A 32 bit start index. An index of 0 implies the beggining of the 299 table row. 301 o A 32 bit end index. A value of 0xFFFFFFFFFFFFFFFF implies the 302 last entry. XXX: Do we need to define the "end wildcard"? 304 The response for a table range query will either be: 306 o The requested table data returned (when at least one referenced 307 row is available); in such a case, a response with a path pointing 308 to the table and whose data content contain the row(s) will be 309 sent to the CE. The data content MUST be encapsulated in 310 sparsedata TLV. The sparse data TLV content will have the "I" (in 311 ILV) for each table row indicating the table indices. 313 o A result TLV when: 315 * data is absent where the result code of E_NOT_SUPPORTED 316 (typically returned in current implementations when accessing 317 an empty table entry) with an english message describing the 318 nature of the error (refer to Section 4.3). 320 * When both a path key and path table range are reflected on the 321 the pathflags, an error code of E_INVALID_FLAGS with an english 322 message describing the nature of the erro (refer to 323 Section 4.3). 325 * other standard ForCES errors (such as ACL constraints trying to 326 retrieve contents of an unreadable table), accessing unknown 327 components etc. 329 4.2. Table Append 331 We propose using a path flag, F_TABAPPEND(0x4, bit 2) to achieve this 332 goal. 334 When a CE application wishes to append to the table, it will set the 335 path to a desired table index and set the path flag to F_TABAPPEND. 336 The FE will first attempt to use the specified index and when 337 unsuccessful will use an available table row index. 339 On success or failure to insert the table row, a result TLV will be 340 returned with the appropriate code. Alternatively a the new 341 EXTENDED-RESULT-TLV (refer to Section 4.3) maybe returned. The path 342 of the response will contain the table row index where the table row 343 was inserted (which the application can then learn). 345 When successful, an E_SUCCESS return code is sent back to the CE. 347 Upon failure to append the table row, an appropriate error code is 348 sent back to the CE. 350 4.3. Error Codes 352 We propose a new TLV, EXTENDED-RESULT-TLV (0x118) that will carry 353 both a result code as currently specified but also a string[N] cause. 354 This is illustrated in Figure 3. 356 0 1 2 3 357 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Type = EXTENDED-RESULT-TLV | Length | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Result Value | Reserved | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Cause string | 364 . . 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Figure 3: Extended Result TLV 370 o Like all other ForCES TLVs, the Extended Result TLV is expected to 371 be 32 bit aligned. 373 o The Result Value is derived from the same current namespace as 374 specified in RFC 5810, section 7.1.7. 376 o It is recommended that the maximum size of the cause string should 377 not exceed 32 bytes. We do not propose the cause string be 378 standardized. 380 XXX: Backward compatibility may require that we add a FEPO capability 381 to advertise ability to do extended results so that the CE is able to 382 interpret the results. 384 4.4. Bitmap Datatype 386 TBA 388 5. IANA Considerations 390 This document registers two new top Level TLVs and two new path 391 flags. 393 The following new TLVs are defined: 395 o Table-range TLV (type ID 0x117) 397 o EXTENDED-RESULT-TLV (type ID 0x118) 399 The following new path flags are defined: 401 o F_SELTABRANGE (value 0x2 i.e bit 1) 403 o F_TABAPPEND (value 0x4 i.e bit 2) 405 6. Security Considerations 407 TBD 409 7. References 411 7.1. Normative References 413 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 414 "Forwarding and Control Element Separation (ForCES) 415 Framework", RFC 3746, April 2004. 417 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 418 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 419 Control Element Separation (ForCES) Protocol 420 Specification", RFC 5810, March 2010. 422 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 423 Layer (TML) for the Forwarding and Control Element 424 Separation (ForCES) Protocol", RFC 5811, March 2010. 426 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 427 Element Separation (ForCES) Forwarding Element Model", RFC 428 5812, March 2010. 430 7.2. Informative References 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 Author's Address 437 Jamal Hadi Salim 438 Mojatatu Networks 439 Suite 400, 303 Moodie Dr. 440 Ottawa, Ontario K2H 9R4 441 Canada 443 Email: hadi@mojatatu.com