idnits 2.17.1 draft-ietf-forces-protoextension-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 -- The document date (March 17, 2014) is 3683 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 5810' is mentioned on line 16, but not defined == Unused Reference: 'RFC5812' is defined on line 455, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 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 March 17, 2014 5 Expires: September 18, 2014 7 ForCES Protocol Extensions 8 draft-ietf-forces-protoextension-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 extensions to the ForCES Protocol 16 Specification[RFC 5810] 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 September 18, 2014. 35 Copyright Notice 37 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Error codes . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Protocol Update Proposal . . . . . . . . . . . . . . . . . . . 6 60 4.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.2.1. New Codes . . . . . . . . . . . . . . . . . . . . . . 8 63 4.2.2. Vendor Codes . . . . . . . . . . . . . . . . . . . . . 8 64 4.2.3. Extended Result TLV . . . . . . . . . . . . . . . . . 8 65 4.3. Large Object Dumping . . . . . . . . . . . . . . . . . . . 9 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Terminology and Conventions 76 1.1. Requirements Language 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 1.2. Definitions 84 This document reiterates the terminology defined by the ForCES 85 architecture in various documents for the sake of clarity. 87 FE Model - The FE model is designed to model the logical 88 processing functions of an FE. The FE model proposed in this 89 document includes three components; the LFB modeling of individual 90 Logical Functional Block (LFB model), the logical interconnection 91 between LFBs (LFB topology), and the FE-level attributes, 92 including FE capabilities. The FE model provides the basis to 93 define the information elements exchanged between the CE and the 94 FE in the ForCES protocol [RFC5810]. 96 LFB (Logical Functional Block) Class (or type) - A template that 97 represents a fine-grained, logically separable aspect of FE 98 processing. Most LFBs relate to packet processing in the data 99 path. LFB classes are the basic building blocks of the FE model. 101 LFB Instance - As a packet flows through an FE along a data path, 102 it flows through one or multiple LFB instances, where each LFB is 103 an instance of a specific LFB class. Multiple instances of the 104 same LFB class can be present in an FE's data path. Note that we 105 often refer to LFBs without distinguishing between an LFB class 106 and LFB instance when we believe the implied reference is obvious 107 for the given context. 109 LFB Model - The LFB model describes the content and structures in 110 an LFB, plus the associated data definition. XML is used to 111 provide a formal definition of the necessary structures for the 112 modeling. Four types of information are defined in the LFB model. 113 The core part of the LFB model is the LFB class definitions; the 114 other three types of information define constructs associated with 115 and used by the class definition. These are reusable data types, 116 supported frame (packet) formats, and metadata. 118 LFB Metadata - Metadata is used to communicate per-packet state 119 from one LFB to another, but is not sent across the network. The 120 FE model defines how such metadata is identified, produced, and 121 consumed by the LFBs, but not how the per-packet state is 122 implemented within actual hardware. Metadata is sent between the 123 FE and the CE on redirect packets. 125 ForCES Component - A ForCES Component is a well-defined, uniquely 126 identifiable and addressable ForCES model building block. A 127 component has a 32-bit ID, name, type, and an optional synopsis 128 description. These are often referred to simply as components. 130 LFB Component - An LFB component is a ForCES component that 131 defines the Operational parameters of the LFBs that must be 132 visible to the CEs. 134 ForCES Protocol - Protocol that runs in the Fp reference points in 135 the ForCES Framework [RFC3746]. 137 ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol 138 architecture that defines the ForCES protocol messages, the 139 protocol state transfer scheme, and the ForCES protocol 140 architecture itself as defined in the ForCES Protocol 141 Specification [RFC5810]. 143 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 144 ForCES protocol architecture that uses the capabilities of 145 existing transport protocols to specifically address protocol 146 message transportation issues, such as how the protocol messages 147 are mapped to different transport media (like TCP, IP, ATM, 148 Ethernet, etc.), and how to achieve and implement reliability, 149 ordering, etc. the ForCES SCTP TML [RFC5811] describes a TML that 150 is mandated for ForCES. 152 2. Introduction 154 Experience in implementing and deploying ForCES architecture has 155 demonstrated need for a few small extensions both to ease 156 programmability and to improve wire efficiency of some transactions. 157 This document describes a few extensions to the ForCES Protocol 158 Specification [RFC5810] semantics to achieve that end goal. 160 This document describes and justifies the need for 2 small extensions 161 which are backward compatible. The document also clarifies on top of 162 [RFC5810] how dumping of large components is achieved. 164 1. A table range operation to allow a controller or control 165 application to request an arbitrary range of table rows. 167 2. Improved Error codes returned to the controller (or control 168 application) to improve granularity of existing defined error 169 codes. 171 3. FE response to a GET request (example to a large table) may not 172 fit in one PL message, for example due to limited TLV space. 174 3. Problem Overview 176 In this section we present sample use cases to illustrate the 177 challenge being addressed. 179 3.1. Table Ranges 181 Consider, for the sake of illustration, an FE table with 1 million 182 reasonably sized table rows which are sparsely populated. Assume, 183 again for the sake of illustration, that there are 2000 table rows 184 sparsely populated between the row indices 23-10023. 186 ForCES GET and DEL requests sent from a controller (or control app) 187 are prepended with a path to a component and sent to the FE. In the 188 case of indexed tables, the component path can either be to a table 189 or a table row index. The approaches for retrieving or deleting a 190 sizeable number of table rows is at the programmatically level (from 191 an application point of view) unfriendly, tedious, and abusive of 192 both compute and bandwidth resources. 194 As an example, a control application attempting to retrieve the first 195 2000 table rows appearing between row indices 23 and 10023 can 196 achieve its goal in one of: 198 o Dump the whole table and filter for the needed 2000 table rows. 200 o Send upto 10000 ForCES PL requests with monotonically incrementing 201 indices and stop when the needed 2000 entries are retrieved. 203 o If the application had knowledge of which table rows existed (not 204 unreasonable given the controller is supposed to be aware of state 205 within an NE), then the application could take advantage of ForCES 206 batching to send fewer large messages (each with different path 207 entries for a total of two thousand). 209 As argued, while the above options exist - all are tedious. 211 3.2. Error codes 213 [RFC5810] has defined a generic set of error codes that are to be 214 returned to the CE from an FE. Deployment experience has shown that 215 it would be useful to have more fine grained error codes. As an 216 example, the error code E_NOT_SUPPORTED could be mapped to many FE 217 error source possibilities that need to be then interpreted by the 218 caller based on some understanding of the nature of the sent request. 219 This makes debugging more time consuming. 221 4. Protocol Update Proposal 223 This section describes proposals to update the protocol for issues 224 discussed in Section 3 226 4.1. Table Ranges 228 We propose to add a Table-range TLV (type ID 0x117) that will be 229 associated with the PATH-DATA TLV in the same manner the KEYINFO-TLV 230 is. 232 +---------------------+---------------------+ 233 | Type (0x117) | Length | 234 +---------------------+---------------------+ 235 | Start Index | 236 +-------------------------------------------+ 237 | End Index | 238 +-------------------------------------------+ 240 Figure 1: ForCES table range request Layout 242 Figure 1 shows how this new TLV is constructed. 244 OPER = GET 245 PATH-DATA: 246 flags = F_SELTABRANGE, IDCount = 2, IDs = {1,6} 247 TABLERANGE-TLV content = {11,23} 249 Figure 2: ForCES table range request 251 Figure 2 illustrates a GET request for a range of rows 11 to 23 of a 252 table with component path of "1/6". 254 Path flag of F_SELTABRANGE (0x2 i.e bit 1, where bit 0 is F_SELKEY as 255 defined in RFC 5810) is set to indicate the presence of the 256 TABLERANGE-TLV. The pathflag bit F_SELTABRANGE can only be used in a 257 GET or DEL and is mutually exclusive with F_SELKEY. The FE MUST 258 enforce those constraints and reject a request with an error code of 259 E_INVALID_TFLAGS with a description of what the problem is (refer to 260 Section 4.2). 262 The TABLERANGE-TLV contents constitute: 264 o A 32 bit start index. An index of 0 implies the beggining of the 265 table row. 267 o A 32 bit end index. A value of 0xFFFFFFFFFFFFFFFF implies the 268 last entry. 270 The response for a table range query will either be: 272 o The requested table data returned (when at least one referenced 273 row is available); in such a case, a response with a path pointing 274 to the table and whose data content contain the row(s) will be 275 sent to the CE. The data content MUST be encapsulated in 276 sparsedata TLV. The sparse data TLV content will have the "I" (in 277 ILV) for each table row indicating the table indices. 279 o An EXTENDEDRESULT-TLV (refer to Section 4.2.3) when: 281 * Response is to a range delete request. The Result will either 282 be: 284 + A success if any of the requested-for rows is deleted 286 + A proper error code if none of the requested for rows can be 287 deleted 289 * data is absent where the result code of E_EMPTY with an 290 optional content string describing the nature of the error 291 (refer to Section 4.2). 293 * When both a path key and path table range are reflected on the 294 the pathflags, an error code of E_INVALID_TFLAGS with an 295 optional content string describing the nature of the error 296 (refer to Section 4.2). 298 * other standard ForCES errors (such as ACL constraints trying to 299 retrieve contents of an unreadable table), accessing unknown 300 components etc. 302 4.2. Error Codes 304 We propose several things: 306 1. A new set of error codes. 308 2. Allocating currently reserved codes for vendor use. 310 3. A new TLV, EXTENDEDRESULT-TLV (0x118) that will carry a code 311 (which will be a superset of what is currently specified in RFC 312 5812) but also an optional cause content. This is illustrated in 313 Figure 3. 315 4.2.1. New Codes 317 EXTENDEDRESULT-TLV Result Value is 32 bits and is a superset of RFC 318 5810 Result TLV Result Value. The new version code space is 32 bits 319 as opposed to the RFC 5810 code size of 8 bits. 321 +------------+-------------------------+----------------------------+ 322 | Code | Mnemonic | Details | 323 +------------+-------------------------+----------------------------+ 324 | 0x100 | E_EMPTY | Table is empty | 325 | 0x101 | E_INVALID_TFLAGS | Invalid table flags | 326 | 0x102 | E_INVALID_OP | Requested operation is | 327 | | | invalid | 328 | 0x103 | E_CONGEST_NT | Node Congestion | 329 | | | notification | 330 | 0x104 | E_COMPONENT_NOT_A_TABLE | Component not a table | 331 | 0x105 | E_PERM | Operation not permitted | 332 | 0x107 | E_BUSY | System is Busy | 333 | 0x108 | E_TIMED_OUT | A time out occured while | 334 | | | processing the message | 335 | 0x106 | E_UNKNOWN | A generic catch all error | 336 | | | code. Carries a string to | 337 | | | further extrapolate what | 338 | | | the error implies. | 339 +------------+-------------------------+----------------------------+ 341 Table 1: New codes 343 4.2.2. Vendor Codes 345 Codes 0x18-0xFE are reserved for use as vendor codes. Since these 346 are freely available it is expected that the FE and CE side will both 347 understand/interpret the semantics of any used codes. 349 4.2.3. Extended Result TLV 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type = EXTENDEDRESULT-TLV | Length | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Result Value | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Optional Cause content | 358 . . 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 3: EXTENDEDRESULT-TLV 364 o Like all other ForCES TLVs, the EXTENDEDRESULT-TLV is expected to 365 be 32 bit aligned. 367 o The Result Value derives and extends from the same current 368 namespace as specified in RFC 5810, section 7.1.7. The main 369 difference is that we now have 32 bit result value (as opposed to 370 the old 8 bit). 372 o The optional result content is defined to further disambiguate the 373 result value. It is expected Utf-8 values to be used. However, 374 vendor specific error codes may choose to specify different 375 contents. Additionally, future codes may specify cause contents 376 to be of types other than string.. 378 o It is recommended that the maximum size of the cause string should 379 not exceed 32 bytes. We do not propose the cause string be 380 standardized. 382 XXX: Backward compatibility may require that we add a FEPO capability 383 to advertise ability to do extended results so that the CE is able to 384 interpret the results and a FEPO compatibility flag to define what 385 TLV setting would be used. Alternatively, the backward compatibility 386 can be made a configuration option (which helps reduce clutter on 387 FEPO LFB given that it is expected that in the future it makes sense 388 for implementations to support only EXTENDEDRESULT-TLVs). 390 4.3. Large Object Dumping 392 Imagine a GET request to a path that is a table i.e a table dump. 393 Such a request is sent to the FE with a specific correlator, say X. 394 Imagine this table to have a large number of entries at the FE. For 395 the sake of illustration, lets say millions of rows. This requires 396 that the FE delivers the response over multiple messages, all using 397 the same correlator X. 399 RFC 5810 does not describe how a GET response is to indicate "I have 400 more messages coming for this correlator". 402 Implementation experience indicates we can use the transaction flags 403 to indicate that a GET response is the beginning, middle or end of a 404 multi-part message. In other words we mirror the effect of an atomic 405 transaction sent by a CE to an FE. 407 XXX: Add in the next update diagram and details of how this takes 408 place. 410 5. Acknowledgements 412 TBA 414 6. IANA Considerations 416 This document registers two new top Level TLVs and two new path 417 flags. 419 The following new TLVs are defined: 421 o TABLERANGE-TLV (type ID 0x117) 423 o EXTENDEDRESULT-TLV (type ID 0x118) 425 The following new path flags are defined: 427 o F_SELTABRANGE (value 0x2 i.e bit 1) 429 The Defined Result Values are changed: 431 o codes 0x18-0xFE are reserved for vendor use. 433 o codes 0x100-102 are defined by this document. 435 7. Security Considerations 437 TBD 439 8. References 440 8.1. Normative References 442 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 443 "Forwarding and Control Element Separation (ForCES) 444 Framework", RFC 3746, April 2004. 446 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 447 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 448 Control Element Separation (ForCES) Protocol 449 Specification", RFC 5810, March 2010. 451 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 452 Layer (TML) for the Forwarding and Control Element 453 Separation (ForCES) Protocol", RFC 5811, March 2010. 455 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 456 Element Separation (ForCES) Forwarding Element Model", 457 RFC 5812, March 2010. 459 8.2. Informative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 Author's Address 466 Jamal Hadi Salim 467 Mojatatu Networks 468 Suite 400, 303 Moodie Dr. 469 Ottawa, Ontario K2H 9R4 470 Canada 472 Email: hadi@mojatatu.com