idnits 2.17.1 draft-ietf-forces-protoextension-06.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 draft header indicates that this document updates RFC5810, but the abstract doesn't seem to directly say this. It does mention RFC5810 though, so this could be OK. -- The draft header indicates that this document updates RFC7121, but the abstract doesn't seem to directly say this. It does mention RFC7121 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5810, updated by this document, for RFC5378 checks: 2004-09-30) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 9, 2014) is 3516 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 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 Updates: 7121,5810 (if approved) September 9, 2014 5 Intended status: Standards Track 6 Expires: March 13, 2015 8 ForCES Protocol Extensions 9 draft-ietf-forces-protoextension-06 11 Abstract 13 Experience in implementing and deploying ForCES architecture has 14 demonstrated need for a few small extensions both to ease 15 programmability and to improve wire efficiency of some transactions. 16 The ForCES protocol is extended with a table range operation and a 17 new extension for error handling. This documents updates both RFC 18 5810 and RFC 7121 semantics to achieve that end goal. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 13, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology and Conventions . . . . . . . . . . . . . . . 3 56 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 3 57 1.1.2. Definitions . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problem Overview . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Error codes . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Protocol Update . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.1. New Codes . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2.2. Private Vendor Codes . . . . . . . . . . . . . . . . . 8 66 3.2.3. Extended Result TLV . . . . . . . . . . . . . . . . . 8 67 3.2.3.1. Extended Result Backward compatibility . . . . . . 9 68 3.3. Large Table Dumping . . . . . . . . . . . . . . . . . . . 10 69 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Appendix A. Appendix A - New FEPO version . . . . . . . . . . . . 14 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 78 1. Introduction 80 Experience in implementing and deploying ForCES architecture has 81 demonstrated need for a few small extensions both to ease 82 programmability and to improve wire efficiency of some transactions. 83 This document describes a few extensions to the ForCES Protocol 84 Specification [RFC5810] semantics to achieve that end goal. 86 This document describes and justifies the need for 2 small extensions 87 which are backward compatible. The document also clarifies details 88 of how dumping of a large table residing on an FE (Forwarding Engine) 89 is achieved. To summarize: 91 1. A table range operation to allow a controller or control 92 application to request an arbitrary range of table rows is 93 introduced. 95 2. Additional error codes returned to the controller (or control 96 application) by an FE are introduced. Additionally a new 97 extension to carry details on error codes is introduced. As a 98 result the (FE Protocol Object) FEPO LFB is updated over the 99 definition in [RFC7121]. 101 3. While already supported, an FE response to a GET request of a 102 large table which does not fit in a single PL message is not 103 described in [RFC5810]. This document clarifies the details. 105 1.1. Terminology and Conventions 107 1.1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 1.1.2. Definitions 115 This document reiterates the terminology defined in several ForCES 116 documents [RFC3746], [RFC5810], [RFC5811], and [RFC5812] for the sake 117 of contextual clarity. 119 Control Engine (CE) 121 Forwarding Engine (FE) 122 FE Model 124 LFB (Logical Functional Block) Class (or type) 126 LFB Instance 128 LFB Model 130 LFB Metadata 132 ForCES Component 134 LFB Component 136 ForCES Protocol Layer (ForCES PL) 138 ForCES Protocol Transport Mapping Layer (ForCES TML) 140 2. Problem Overview 142 In this section we present sample use cases to illustrate each 143 challenge being addressed. 145 2.1. Table Ranges 147 Consider, for the sake of illustration, an FE table with 1 million 148 reasonably sized table rows which are sparsely populated. Assume, 149 again for the sake of illustration, that there are 2000 table rows 150 sparsely populated between the row indices 23-10023. 152 Implementation experience has shown that existing approaches for 153 retrieving or deleting a sizable number of table rows to be both 154 programmatically tedious and inefficient on utilization of both 155 compute and wire resources. 157 By Definition, ForCES GET and DEL requests sent from a controller (or 158 control app) are prepended with a path to a component and sent to the 159 FE. In the case of indexed tables, the component path can either 160 point to a table or a table row index. 162 As an example, a control application attempting to retrieve the first 163 2000 table rows appearing between row indices 23 and 10023 can 164 achieve its goal in one of: 166 o Dump the whole table and filter for the needed 2000 table rows. 168 o Send upto 10000 ForCES PL requests, incrementing the index by one 169 each time, and stop when the needed 2000 entries are retrieved. 171 o If the application had knowledge of which table rows existed (not 172 unreasonable given the controller is supposed to be aware of state 173 within an NE), then the application could take advantage of ForCES 174 batching to send fewer large messages (each with different path 175 entries for a total of two thousand). 177 As argued, while the above options exist, all are tedious. 179 2.2. Error codes 181 [RFC5810] has defined a generic set of error codes that are to be 182 returned to the CE from an FE. Deployment experience has shown that 183 it would be useful to have more fine grained error codes. As an 184 example, the error code E_NOT_SUPPORTED could be mapped to many FE 185 error source possibilities that need to be then interpreted by the 186 caller based on some understanding of the nature of the sent request. 187 This makes debugging more time consuming. 189 3. Protocol Update 191 This section describes normative update to the ForCES protocol for 192 issues discussed in Section 2. 194 3.1. Table Ranges 196 We define a new TLV, TABLERANGE-TLV (type ID 0x117) that will be 197 associated with the PATH-DATA TLV in the same manner the KEYINFO-TLV 198 is. 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Type (0x117) | Length | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Start Index | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | End Index | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 1: ForCES table range request Layout 212 Figure 1 shows how this new TLV is constructed. 214 OPER = GET 215 PATH-DATA: 216 flags = F_SELTABRANGE, IDCount = 2, IDs = {1,6} 217 TABLERANGE-TLV content = {11,23} 219 Figure 2: ForCES table range request 221 Figure 2 illustrates a GET request for a range of rows 11 to 23 of a 222 table with component path of "1/6". 224 Path flag of F_SELTABRANGE (0x2 i.e bit 1, where bit 0 is F_SELKEY as 225 defined in RFC 5810) MUST be set to indicate the presence of the 226 TABLERANGE-TLV. The pathflag bit F_SELTABRANGE can only be used in a 227 GET or DEL and is mutually exclusive with F_SELKEY. The FE MUST 228 enforce the path flag constraints and ensure that the selected path 229 belongs to a defined indexed table component. Any violation of these 230 constraints MUST be rejected with an error code of E_INVALID_TFLAGS 231 with a description of what the problem is when using extended error 232 reporting (refer to Section 3.2). 234 It should be noted that there are combination of path selection 235 mechanisms that should not appear together for the sake of simplicity 236 of operations. These include: TABLERANGE-TLV and KEYINFO-TLV as well 237 as multiple nested TABLERANGE-TLVs. 239 The TABLERANGE-TLV contents constitute: 241 o A 32 bit start index. An index of 0 implies the beginning of the 242 table row. 244 o A 32 bit end index. A value of 0xFFFFFFFF implies the last entry. 246 The response for a table range query will either be: 248 o The requested table data returned (when at least one referenced 249 row is available); in such a case, a response with a path pointing 250 to the table and whose data content contains the row(s) will be 251 sent to the CE. The data content MUST be encapsulated in 252 sparsedata TLV. The sparse data TLV content will have the "I" (in 253 ILV) for each table row indicating the table indices. 255 o An EXTENDEDRESULT-TLV (refer to Section 3.2.3) when: 257 * Response is to a range delete request. The Result will either 258 be: 260 + A success if any of the requested-for rows is deleted 261 + A proper error code if none of the requested for rows can be 262 deleted 264 * data is absent where the result code of E_EMPTY with an 265 optional content string describing the nature of the error 266 (refer to Section 3.2). 268 * When both a path key and path table range are reflected on the 269 the pathflags, an error code of E_INVALID_TFLAGS with an 270 optional content string describing the nature of the error 271 (refer to Section 3.2). 273 * other standard ForCES errors (such as ACL constraints trying to 274 retrieve contents of an unreadable table), accessing unknown 275 components etc. 277 3.2. Error Codes 279 We define several things: 281 1. A new set of error codes. 283 2. Allocating some reserved codes for private use. 285 3. A new TLV, EXTENDEDRESULT-TLV (0x118) that will carry a code 286 (which will be a superset of what is currently specified in 287 [RFC5810]) but also an optional cause content. This is 288 illustrated in Figure 3. 290 3.2.1. New Codes 292 EXTENDEDRESULT-TLV Result Value is 32 bits and is a superset of RFC 293 5810 Result TLV Result Value. The new version code space is 32 bits 294 as opposed to the RFC 5810 code size of 8 bits. The first 8 bit 295 values(256 codes) are common to both code spaces. 297 +------------+-------------------------+----------------------------+ 298 | Code | Mnemonic | Details | 299 +------------+-------------------------+----------------------------+ 300 | 0x18 | E_TIMED_OUT | A time out occured while | 301 | | | processing the message | 302 | 0x19 | E_INVALID_TFLAGS | Invalid table flags | 303 | 0x1A | E_INVALID_OP | Requested operation is | 304 | | | invalid | 305 | 0x1B | E_CONGEST_NT | Node Congestion | 306 | | | notification | 307 | 0x1C | E_COMPONENT_NOT_A_TABLE | Component not a table | 308 | 0x1D | E_PERM | Operation not permitted | 309 | 0x1E | E_BUSY | System is Busy | 310 | 0x1F | E_EMPTY | Table is empty | 311 | 0x20 | E_UNKNOWN | A generic catch all error | 312 | | | code. Carries a string to | 313 | | | further extrapolate what | 314 | | | the error implies. | 315 +------------+-------------------------+----------------------------+ 317 Table 1: New codes 319 3.2.2. Private Vendor Codes 321 Codes 0x100-0x200 are reserved for use as private codes. Since these 322 are freely available it is expected that the FE and CE side 323 implementations will both understand/interpret the semantics of any 324 used codes and avoid any conflicts. 326 3.2.3. Extended Result TLV 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type = EXTENDEDRESULT-TLV | Length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Result Value | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Optional Cause content | 336 . . 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 3: EXTENDEDRESULT-TLV 342 o Like all other ForCES TLVs, the EXTENDEDRESULT-TLV is expected to 343 be 32 bit aligned. 345 o The EXTENDEDRESULT-TLV Result Value derives and extends from the 346 same current namespace that is used by RESULT-TLV Result Value as 347 specified in RFC 5810, section 7.1.7. The main difference is that 348 we now have a 32 bit result value (as opposed to old 8 bit). 350 o The optional result content is defined to further disambiguate the 351 result value. It is expected UTF-8 string values to be used. The 352 content result value is intended to be consumed by the (human) 353 operator and implementations may choose to specify different 354 contents for the same error code. Additionally, future codes may 355 specify cause contents to be of types other than string. 357 o It is recommended that the maximum size of the cause string should 358 not exceed 32 bytes. The cause string is not standardized by this 359 document. 361 3.2.3.1. Extended Result Backward compatibility 363 To support backward compatibility, we update and the FEPO LFB (in 364 Appendix A) version to 1.2. We also add a new component ID 16 (named 365 EResultAdmin) and a capability Component ID 32 (named EResultCapab). 367 An FE will advertise its capability to support extended TLVs via the 368 EResultCapab table. When an FE is capable of responding with both 369 extended results and older result TLVs, it will have two table rows 370 one for each supported value. By default an FE capable of supporting 371 both modes will assume the lowest common denominator i.e EResultAdmin 372 will be EResultNotSupported; and will issue responses using RESULT- 373 TLVs. It should be noted an FE advertising FEPO version 1.2 MUST 374 support EXTENDEDRESULT-TLVs at minimum. 376 On an FE which supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a 377 master CE can turn on support for extended results by setting the 378 EResultAdmin value to 2 in which case the FE MUST switch over to 379 sending only EXTENDEDRESULT-TLVs. Likewise a master CE can turn off 380 extended result responses by writing a 1 to the EResultAdmin. An FE 381 that does not support one mode or other MUST reject setting of 382 EResultAdmin to a value it does not support by responding with an 383 error code of E_NOT_SUPPORTED. It is expected that all CEs 384 participating in a high availability(HA) mode be capable of 385 supporting FEPO version 1.2 whenever EResultAdmin is set to strict 386 support of EXTENDEDRESULT-TLVs. The consensus between CEs in an HA 387 setup to set strict support of EXTENDEDRESULT-TLVs is out of scope 388 for this document. 390 3.3. Large Table 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 The protocol document [RFC5810] does not adequately describe how a 400 large multi-part GET response message is delivered. The text in this 401 section clarifies. We limit the discussion to a table object only. 403 Implementation experience of dumping large tables indicates we can 404 use the transaction flags to indicate that a GET response is the 405 beginning, middle or end of a multi-part message. In other words we 406 mirror the effect of an atomic transaction sent by a CE to an FE. 408 CE PL FE PL 410 | | 411 | (0) Query, Path-to-a-large-table, OP=GET | 412 |----------------------------------------------------->| 413 | correlator = X | 414 | | 415 | (1) Query-Response, SOT,AT, OP=GET-RESPONSE, DATA | 416 |<-----------------------------------------------------| 417 | correlator = X | 418 | DATA TLV (SPARSE/FULL) | 419 | | 420 | (2) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA | 421 |<-----------------------------------------------------| 422 | correlator = X | 423 | DATA TLV (SPARSE/FULL) | 424 | | 425 | (3) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA | 426 |<-----------------------------------------------------| 427 | correlator = X | 428 | DATA TLV (SPARSE/FULL) | 429 . . 430 . . 431 . . 432 . . 433 | | 434 | (N) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA | 435 |<-----------------------------------------------------| 436 | correlator = X | 437 | DATA TLV (SPARSE/FULL) | 438 | | 439 | (N) Query-Response, EOT,AT, OP=GET-RESPONSE | 440 |<-----------------------------------------------------| 441 | correlator = X | 442 | RESULT TLV (SUCCESS) | 443 | | 445 Figure 4: EXTENDEDRESULT-TLV 447 The last message to go to the CE, which carries the EOT flag, MUST 448 NOT carry any data. This allows us to mirror ForCES 2PC messaging 449 [RFC5810] where the last message is an empty commit message. GET 450 response will carry a result code TLV in such a case. 452 4. Acknowledgements 454 The author would like to thank Evangelos Haleplidis and Joel Halpern 455 for discussions that made this document better. Adrian Farrel did an 456 excellent AD review of the document which improved the quality of 457 this document. Tobias Gondrom did the Security Directorate review. 458 Brian Carpenter did the Gen-ART review. Nevil Brownlee performed the 459 Operations Directorate review. S Moonesamy(SM) worked hard to review 460 our publication process. Pearl Liang caught issues in the IANA 461 specification. 463 The author would like to thank the following IESG members who 464 reviewed and improved this document: Alia Atlas, Barry Leiba, Brian 465 Haberman, Kathleen Moriarty, Richard Barnes, and Spencer Dawkins. 467 5. IANA Considerations 469 This document registers two new top Level TLVs and two new path flags 470 and updates an IANA registered FE Protocol object Logical Functional 471 Block (LFB). 473 The Appendix A defines an update to the FE Protocol Object LFB to 474 version 1.2. The IANA registry 475 https://www.iana.org/assignments/forces sub-registy "Logical 476 Functional Block (LFB) Class Names and Class Identifiers" will need 477 to be append for FE Protocol Object LFB version 1.2 and this document 478 reflected in the reference column. 480 Updates are required to the "TLV types" subregistry for the TLVs 481 below. 483 The following new TLVs are defined: 485 o TABLERANGE-TLV (type ID 0x117) 487 o EXTENDEDRESULT-TLV (type ID 0x118) 489 subregistry "RESULT-TLV Result Values" is affected by the entries 490 below. 492 The Defined RESULT-TLV Result Values are changed: 494 o codes 0x21-0xFE are unassigned. 496 o codes 0x18-0x20 are defined by this document in Section 3.2.1. 498 o codes 0x100-0x200 are reserved for private use. 500 A new sub-registry for EXTENDEDRESULT-TLV Result Values needs to be 501 created. The codes 0x00-0xff are mirrored from the RESULT-TLV Result 502 Values sub-registry. Any new allocations of this code range (in the 503 range 0x21-0xfe) must happen only within the new sub-registry and not 504 in RESULT-TLV Result Values sub-registry. The codes 0x100-0x200 are 505 reserved for private use as described earlier and the code ranges 506 0x21-0xfe and 0x201-0xffffffff should be marked as Unassigned with 507 the IANA allocation policy of Specification Required [RFC5226]. The 508 Designated Expert (DE) needs to ensure existing deployments are not 509 broken by any specified request. The DE should post a given code 510 request to the ForCES WG mailing list (or a successor designated by 511 the Area Director) for any comment and review. The DE should then 512 either approve or deny the registration request, publish a notice of 513 the decision to the ForCES WG mailing list or its successor, and 514 inform IANA of his/her decision. A denial notice must be justified 515 by an explanation and, in the cases where it is possible, concrete 516 suggestions on how the request can be modified so as to become 517 acceptable. 519 6. Security Considerations 521 The security considerations that have been described in the ForCES 522 protocol [RFC5810] apply to this document as well. 524 7. References 526 7.1. Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 532 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 533 May 2008. 535 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 536 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 537 Control Element Separation (ForCES) Protocol 538 Specification", RFC 5810, March 2010. 540 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 541 Layer (TML) for the Forwarding and Control Element 542 Separation (ForCES) Protocol", RFC 5811, March 2010. 544 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 545 Element Separation (ForCES) Forwarding Element Model", 546 RFC 5812, March 2010. 548 [RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, 549 "High Availability within a Forwarding and Control Element 550 Separation (ForCES) Network Element", RFC 7121, 551 February 2014. 553 7.2. Informative References 555 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 556 "Forwarding and Control Element Separation (ForCES) 557 Framework", RFC 3746, April 2004. 559 Appendix A. Appendix A - New FEPO version 561 This version of FEPO updates the earlier one given in RFC 7121. The 562 xml has been validated against the schema defined in [RFC5812]. 564 567 568 569 570 CEHBPolicyValues 571 572 The possible values of CE heartbeat policy 573 574 575 uchar 576 577 578 CEHBPolicy0 579 580 The CE will send heartbeats to the FE 581 every CEHDI timeout if no other messages 582 have been sent since. 583 584 585 586 CEHBPolicy1 587 588 The CE will not send heartbeats to the FE 589 590 591 592 593 594 595 FEHBPolicyValues 596 597 The possible values of FE heartbeat policy 598 599 600 uchar 601 602 603 FEHBPolicy0 604 605 The FE will not generate any heartbeats 606 to the CE 607 608 609 610 FEHBPolicy1 611 612 The FE generates heartbeats to the CE every FEHI 613 if no other messages have been sent to the CE. 614 615 616 617 618 619 620 FERestartPolicyValues 621 622 The possible values of FE restart policy 623 624 625 uchar 626 627 628 FERestartPolicy0 629 630 The FE restarts its state from scratch 631 632 633 634 635 636 637 HAModeValues 638 639 The possible values of HA modes 640 641 642 uchar 643 644 645 NoHA 646 647 The FE is not running in HA mode 648 649 650 651 ColdStandby 652 653 The FE is running in HA mode cold Standby 654 655 656 657 HotStandby 658 659 The FE is running in HA mode hot Standby 660 661 662 663 664 665 666 CEFailoverPolicyValues 667 668 The possible values of CE failover policy 669 670 671 uchar 672 673 674 CEFailoverPolicy0 675 676 The FE should stop functioning immediate and 677 transition to the FE OperDisable state 678 679 680 681 CEFailoverPolicy1 682 683 The FE should continue forwarding even 684 without an associated CE for CEFTI. The 685 FE goes to FE OperDisable when the CEFTI 686 expires and no association. Requires 687 graceful restart support. 688 689 691 692 693 694 695 FEHACapab 696 697 The supported HA features 698 699 700 uchar 701 702 703 GracefullRestart 704 705 The FE supports Graceful Restart 706 707 708 709 HA 710 711 The FE supports HA 712 713 714 715 716 717 718 CEStatusType 719 Status values. Status for each CE 720 721 uchar 722 723 724 Disconnected 725 No connection attempt with the CE yet 726 727 728 729 Connected 730 The FE connection with the CE at the TML 731 has been completed 732 733 734 735 Associated 736 The FE has associated with the CE 737 738 739 740 IsMaster 741 The CE is the master (and associated) 742 743 744 745 LostConnection 746 The FE was associated with the CE but 747 lost the connection 748 749 750 751 Unreachable 752 The CE is deemed as unreachable by the FE 753 754 755 756 757 758 759 StatisticsType 760 Statistics Definition 761 762 763 RecvPackets 764 Packets Received 765 uint64 766 767 768 RecvErrPackets 769 Packets Received from CE with errors 770 771 uint64 772 773 774 RecvBytes 775 Bytes Received from CE 776 uint64 777 778 779 RecvErrBytes 780 Bytes Received from CE in Error 781 uint64 782 783 784 TxmitPackets 785 Packets Transmitted to CE 786 uint64 788 789 790 TxmitErrPackets 791 792 Packets Transmitted to CE that incurred 793 errors 794 795 uint64 796 797 798 TxmitBytes 799 Bytes Transmitted to CE 800 uint64 801 802 803 TxmitErrBytes 804 Bytes Transmitted to CE incurring errors 805 806 uint64 807 808 809 810 811 AllCEType 812 Table Type for AllCE component 813 814 815 CEID 816 ID of the CE 817 uint32 818 819 820 Statistics 821 Statistics per CE 822 StatisticsType 823 824 825 CEStatus 826 Status of the CE 827 CEStatusType 828 829 830 831 832 ExtendedResultType 833 834 Possible extended result support 835 836 837 uchar 838 839 840 841 842 843 EResultNotSupported 844 845 Extended Results are not supported 846 847 848 849 EResultSupported 850 851 Extended Results are supported 852 853 854 855 856 857 858 859 860 FEPO 861 862 The FE Protocol Object, with EXtended Result control 863 864 1.2 865 866 867 CurrentRunningVersion 868 Currently running ForCES version 869 uchar 870 871 872 FEID 873 Unicast FEID 874 uint32 875 876 877 MulticastFEIDs 878 879 the table of all multicast IDs 880 881 882 uint32 883 885 886 887 CEHBPolicy 888 889 The CE Heartbeat Policy 890 891 CEHBPolicyValues 892 893 894 CEHDI 895 896 The CE Heartbeat Dead Interval in millisecs 897 898 uint32 899 900 901 FEHBPolicy 902 903 The FE Heartbeat Policy 904 905 FEHBPolicyValues 906 907 908 FEHI 909 910 The FE Heartbeat Interval in millisecs 911 912 uint32 913 914 915 CEID 916 917 The Primary CE this FE is associated with 918 919 uint32 920 921 922 BackupCEs 923 924 The table of all backup CEs other than the 925 primary 926 927 928 uint32 929 930 931 932 CEFailoverPolicy 933 934 The CE Failover Policy 935 936 CEFailoverPolicyValues 937 938 939 CEFTI 940 941 The CE Failover Timeout Interval in millisecs 942 943 uint32 944 945 946 FERestartPolicy 947 948 The FE Restart Policy 949 950 FERestartPolicyValues 951 952 953 LastCEID 954 955 The Primary CE this FE was last associated 956 with 957 958 uint32 959 960 961 HAMode 962 963 The HA mode used 964 965 HAModeValues 966 967 968 AllCEs 969 The table of all CEs 970 971 AllCEType 972 973 974 975 EResultAdmin 976 977 Turn Extended results off or on. 978 default to off 979 980 ExtendedResultType 981 1 982 983 984 985 986 SupportableVersions 987 988 the table of ForCES versions that FE supports 989 990 991 uchar 992 993 994 995 HACapabilities 996 997 the table of HA capabilities the FE supports 998 999 1000 FEHACapab 1001 1002 1003 1004 EResultCapab 1005 1006 the table of supported result capabilities 1007 1008 1009 ExtendedResultType 1010 1011 1012 1013 1014 1015 PrimaryCEDown 1016 1017 The primary CE has changed 1018 1019 1020 LastCEID 1021 1022 1023 1024 1025 LastCEID 1026 1027 1028 1029 1030 PrimaryCEChanged 1031 A New primary CE has been selected 1032 1033 1034 CEID 1035 1036 1037 1038 1039 CEID 1040 1041 1042 1043 1044 1045 1046 1048 Author's Address 1050 Jamal Hadi Salim 1051 Mojatatu Networks 1052 Suite 400, 303 Moodie Dr. 1053 Ottawa, Ontario K2H 9R4 1054 Canada 1056 Email: hadi@mojatatu.com