idnits 2.17.1 draft-ietf-forces-protoextension-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 : ---------------------------------------------------------------------------- ** 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 (September 16, 2013) is 3875 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'N' is mentioned on line 348, but not defined -- Looks like a reference, but probably isn't: '32' on line 358 == Unused Reference: 'RFC5812' is defined on line 404, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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 September 16, 2013 5 Expires: March 20, 2014 7 ForCES Protocol Extensions 8 draft-ietf-forces-protoextension-00 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 March 20, 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. Error codes . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Protocol Update Proposal . . . . . . . . . . . . . . . . . . 5 60 4.1. Extending Result-TLV . . . . . . . . . . . . . . . . . . 5 61 4.2. Table Ranges . . . . . . . . . . . . . . . . . . . . . . 6 62 4.3. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.3.1. New Codes . . . . . . . . . . . . . . . . . . . . . . 7 64 4.3.2. Extending Result TLV . . . . . . . . . . . . . . . . 8 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 7.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Terminology and Conventions 74 1.1. Requirements Language 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 1.2. Definitions 82 This document reiterates the terminology defined by the ForCES 83 architecture in various documents for the sake of clarity. 85 FE Model - The FE model is designed to model the logical 86 processing functions of an FE. The FE model proposed in this 87 document includes three components; the LFB modeling of individual 88 Logical Functional Block (LFB model), the logical interconnection 89 between LFBs (LFB topology), and the FE-level attributes, 90 including FE capabilities. The FE model provides the basis to 91 define the information elements exchanged between the CE and the 92 FE in the ForCES protocol [RFC5810]. 94 LFB (Logical Functional Block) Class (or type) - A template that 95 represents a fine-grained, logically separable aspect of FE 96 processing. Most LFBs relate to packet processing in the data 97 path. LFB classes are the basic building blocks of the FE model. 99 LFB Instance - As a packet flows through an FE along a data path, 100 it flows through one or multiple LFB instances, where each LFB is 101 an instance of a specific LFB class. Multiple instances of the 102 same LFB class can be present in an FE's data path. Note that we 103 often refer to LFBs without distinguishing between an LFB class 104 and LFB instance when we believe the implied reference is obvious 105 for the given context. 107 LFB Model - The LFB model describes the content and structures in 108 an LFB, plus the associated data definition. XML is used to 109 provide a formal definition of the necessary structures for the 110 modeling. Four types of information are defined in the LFB model. 111 The core part of the LFB model is the LFB class definitions; the 112 other three types of information define constructs associated with 113 and used by the class definition. These are reusable data types, 114 supported frame (packet) formats, and metadata. 116 LFB Metadata - Metadata is used to communicate per-packet state 117 from one LFB to another, but is not sent across the network. The 118 FE model defines how such metadata is identified, produced, and 119 consumed by the LFBs, but not how the per-packet state is 120 implemented within actual hardware. Metadata is sent between the 121 FE and the CE on redirect packets. 123 ForCES Component - A ForCES Component is a well-defined, uniquely 124 identifiable and addressable ForCES model building block. A 125 component has a 32-bit ID, name, type, and an optional synopsis 126 description. These are often referred to simply as components. 128 LFB Component - An LFB component is a ForCES component that 129 defines the Operational parameters of the LFBs that must be 130 visible to the CEs. 132 ForCES Protocol - Protocol that runs in the Fp reference points in 133 the ForCES Framework [RFC3746]. 135 ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol 136 architecture that defines the ForCES protocol messages, the 137 protocol state transfer scheme, and the ForCES protocol 138 architecture itself as defined in the ForCES Protocol 139 Specification [RFC5810]. 141 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 142 ForCES protocol architecture that uses the capabilities of 143 existing transport protocols to specifically address protocol 144 message transportation issues, such as how the protocol messages 145 are mapped to different transport media (like TCP, IP, ATM, 146 Ethernet, etc.), and how to achieve and implement reliability, 147 ordering, etc. the ForCES SCTP TML [RFC5811] describes a TML that 148 is mandated for ForCES. 150 2. Introduction 152 Experience in implementing and deploying ForCES architecture has 153 demonstrated need for a few small extensions both to ease 154 programmability and to improve wire efficiency of some transactions. 155 This document describes a few extensions to the ForCES Protocol 156 Specification [RFC5810] semantics to achieve that end goal. 158 This document describes and justifies the need for 2 small extensions 159 which are backward compatible. 161 1. A table range operation to allow a controller or control 162 application to request an arbitrary range of table rows. 164 2. Improved Error codes returned to the controller (or control 165 application) to improve granularity of existing defined error 166 codes. 168 3. Problem Overview 170 In this section we present sample use cases to illustrate the 171 challenge being addressed. 173 3.1. Table Ranges 175 Consider, for the sake of illustration, an FE table with 1 million 176 reasonably sized table rows which are sparsely populated. Assume, 177 again for the sake of illustration, that there are 2000 table rows 178 sparsely populated between the row indices 23-10023. 180 ForCES GET requests sent from a controller (or control app) are 181 prepended with a path to a component and sent to the FE. In the case 182 of indexed tables, the component path can either be to a table or a 183 table row index. A control application attempting to retrieve the 184 first 2000 table rows appearing between row indices 23 and 10023 can 185 achieve its goal in one of: 187 o Dump the whole table and filter for the needed 2000 table rows. 189 o Send upto 10000 ForCES PL requests with monotonically incrementing 190 indices and stop when the needed 2000 entries are retrieved. 192 o Use ForCES batching to send fewer large messages (several path 193 requests at a time with incrementing indices until you hit the 194 require number of entries). 196 All of these approaches are programmatically (from an application 197 point of view) unfriendly, tedious, and are seen as abuse of both 198 compute and bandwidth resources. 200 3.2. Error codes 202 [RFC5810] has defined a generic set of error codes that are to be 203 returned to the CE from an FE. Deployment experience has shown that 204 it would be useful to have more fine grained error codes. As an 205 example, the error code E_NOT_SUPPORTED could be mapped to many FE 206 error source possibilities that need to be then interpreted by the 207 caller based on some understanding of the nature of the sent request. 208 This makes debugging more time consuming. 210 4. Protocol Update Proposal 212 This section describes proposals to update the protocol for issues 213 discussed in Section 3 215 4.1. Extending Result-TLV 217 We extend the RESULT-TLV (0x114) to additionally carry an optional 218 description of the result. This is illustrated in Figure 1. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Type = RESULT-TLV | Length | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Result Value | Cause code | Reserved | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Cause Content | 228 . . 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 1: Extended Result TLV 234 o As before, the Result TLV is expected to be 32 bit aligned. 236 o The Result Value is derived from the same current namespace as 237 specified in RFC 5810, section 7.1.7 with some new values added in 238 Section 4.3. 240 o The cause code is an enumeration which describes additional 241 content. This field was originally part of a reserved field. By 242 definition, the user was not supposed to interpret the reserved 243 field and the sender was expected to set it to 0. By default, 244 therefore, we assume 0 to imply the status quo i.e ignore cause 245 content if present. For this reason, we expect this new extension 246 to be both backward compatible and forward compatible because old 247 implementations ignore the reserved fields and always set them to 248 zero and new implementations will set and intepret the cause code. 250 4.2. Table Ranges 252 We propose to add a Table-range TLV (type ID 0x117) that will be 253 associated with the PATH-DATA TLV in the same manner the KEYINFO-TLV 254 is. 256 OPER = GET 257 PATH-DATA: 258 flags = F_SELTABRANGE, IDCount = 2, IDs = {1,6} 259 TABLERANGE-TLV = {11,23} 261 Figure 2: ForCES table range request 263 Figure 2 illustrates a GET request for a a table range for rows 11 to 264 23 of a table with component path of 1/6. 266 Path flag of F_SELTABRANGE (0x2 i.e bit 1, where bit 0 is F_SELKEY as 267 defined in RFC 5810) is set to indicate the presence of the Table- 268 range TLV. The pathflag bit F_SELTABRANGE can only be used in a GET 269 and is mutually exclusive with F_SELKEY. The FE MUST enforce those 270 constraints and reject a request with an error code of 271 E_INVALID_FLAGS with an english description of what the problem is 272 (refer to Section 4.3). 274 The Table-range TLV contents constitute: 276 o A 32 bit start index. An index of 0 implies the beggining of the 277 table row. 279 o A 32 bit end index. A value of 0xFFFFFFFFFFFFFFFF implies the 280 last entry. XXX: Do we need to define the "end wildcard"? 282 The response for a table range query will either be: 284 o The requested table data returned (when at least one referenced 285 row is available); in such a case, a response with a path pointing 286 to the table and whose data content contain the row(s) will be 287 sent to the CE. The data content MUST be encapsulated in 288 sparsedata TLV. The sparse data TLV content will have the "I" (in 289 ILV) for each table row indicating the table indices. 291 o A result TLV when: 293 * data is absent where the result code of E_NOT_SUPPORTED 294 (typically returned in current implementations when accessing 295 an empty table entry) with an english message describing the 296 nature of the error (refer to Section 4.3). 298 * When both a path key and path table range are reflected on the 299 the pathflags, an error code of E_INVALID_FLAGS with an english 300 message describing the nature of the erro (refer to 301 Section 4.3). 303 * other standard ForCES errors (such as ACL constraints trying to 304 retrieve contents of an unreadable table), accessing unknown 305 components etc. 307 4.3. Error Codes 309 We propose two things: 311 o A new set of error codes. 313 o A cause string to be carried in the new proposed RESULT-TLV. 315 4.3.1. New Codes 317 The following error codes are added. 319 +-----------------------+--------+----------------------------------+ 320 | Result Value | Value | Definition | 321 +-----------------------+--------+----------------------------------+ 322 | E_TIMED_OUT | 0x18 | A time out occured while | 323 | | | processing the message | 324 | E_CONGEST_NT | 0x19 | The message was successfully | 325 | | | processed but there is | 326 | | | congestion detected. | 327 | E_EMPTY | 0x1A | A requested for table in a GET | 328 | | | operation is empty | 329 | E_INVALID_PATH_FLGS | 0x1B | The submitted path flags in a | 330 | | | request are invalid | 331 | E_UNKNOWN | 0x1C | A generic error catch all error | 332 | | | code. To be useful, presented | 333 | | | only in association with | 334 | | | extended Result TLV from below | 335 | | | and carries a string to further | 336 | | | extrapolate what the error | 337 | | | implies. | 338 +-----------------------+--------+----------------------------------+ 340 Table 1 342 XXX: More error codes to be added in later doc revisions. 344 4.3.2. Extending Result TLV 346 We introduce a cause content of a string to further describe the 347 error code. The result TLV is shown in Figure 3. The content code 348 will be 1 indicating the cause content is an UTF-8 string[N] cause 349 description. 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type = RESULT-TLV | Length | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Result Value |Cause code = 1 | Reserved | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Cause String[32] | 359 . . 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 3: Extending The Result TLV 365 It is recommended that the maximum size of the cause string should 366 not exceed 32 bytes. We do not propose the cause string be 367 standardized. 369 5. IANA Considerations 371 This document registers two new top Level TLVs and two new path 372 flags. 374 The following new TLVs are defined: 376 o Table-range TLV (type ID 0x117) 378 o EXTENDED RESULT-TLV Cause codes. 380 The following new path flags are defined: 382 o F_SELTABRANGE (value 0x2 i.e bit 1) 384 6. Security Considerations 386 TBD 388 7. References 389 7.1. Normative References 391 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 392 "Forwarding and Control Element Separation (ForCES) 393 Framework", RFC 3746, April 2004. 395 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 396 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 397 Control Element Separation (ForCES) Protocol 398 Specification", RFC 5810, March 2010. 400 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 401 Layer (TML) for the Forwarding and Control Element 402 Separation (ForCES) Protocol", RFC 5811, March 2010. 404 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 405 Element Separation (ForCES) Forwarding Element Model", RFC 406 5812, March 2010. 408 7.2. Informative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 Author's Address 415 Jamal Hadi Salim 416 Mojatatu Networks 417 Suite 400, 303 Moodie Dr. 418 Ottawa, Ontario K2H 9R4 419 Canada 421 Email: hadi@mojatatu.com