idnits 2.17.1 draft-ietf-forces-protoextension-04.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 (July 30, 2014) is 3557 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) No issues found here. Summary: 0 errors (**), 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) July 30, 2014 5 Intended status: Standards Track 6 Expires: January 31, 2015 8 ForCES Protocol Extensions 9 draft-ietf-forces-protoextension-04 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 This documents updates both RFC 5810 and RFC 7121 semantics to 17 achieve that end goal. 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 January 31, 2015. 36 Copyright Notice 38 Copyright (c) 2014 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology and Conventions . . . . . . . . . . . . . . . 3 55 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 3 56 1.1.2. Definitions . . . . . . . . . . . . . . . . . . . . . 3 57 2. Problem Overview . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Error codes . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Protocol Update Proposal . . . . . . . . . . . . . . . . . . . 5 61 3.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.2.1. New Codes . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.2. Private Vendor Codes . . . . . . . . . . . . . . . . . 8 65 3.2.3. Extended Result TLV . . . . . . . . . . . . . . . . . 8 66 3.2.3.1. Extended Result Backward compatibility . . . . . . 9 67 3.3. Large Table Dumping . . . . . . . . . . . . . . . . . . . 9 68 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Appendix A. Appendix A - New FEPO version . . . . . . . . . . . . 12 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 77 1. Introduction 79 Experience in implementing and deploying ForCES architecture has 80 demonstrated need for a few small extensions both to ease 81 programmability and to improve wire efficiency of some transactions. 82 This document describes a few extensions to the ForCES Protocol 83 Specification [RFC5810] semantics to achieve that end goal. 85 This document describes and justifies the need for 2 small extensions 86 which are backward compatible. The document also clarifies details 87 of how dumping of a large table residing on an FE is achieved. To 88 summarize: 90 1. A table range operation to allow a controller or control 91 application to request an arbitrary range of table rows is 92 introduced. 94 2. Additional error codes returned to the controller (or control 95 application) by an FE are introduced. Additionally a new 96 extension to carry details on error codes is introduced. As a 97 result the (FE Protocol Object) FEPO LFB is updated over the 98 definition in [RFC7121]. 100 3. While already supported, an FE response to a GET request of a 101 large table which does not fit in a single PL message is not 102 described in [RFC5810]. This document clarifies the details. 104 1.1. Terminology and Conventions 106 1.1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 1.1.2. Definitions 114 This document reiterates the terminology defined in several ForCES 115 documents [RFC3746], [RFC5810], [RFC5811], and [RFC5812] for the sake 116 of contexual clarity. 118 FE Model 120 LFB (Logical Functional Block) Class (or type) 121 LFB Instance 123 LFB Model 125 LFB Metadata 127 ForCES Component 129 LFB Component 131 ForCES Protocol the ForCES Framework [RFC3746]. the ForCES SCTP 132 TML [RFC5811] describes a TML 134 ForCES Protocol Layer (ForCES PL) 136 ForCES Protocol Transport Mapping Layer (ForCES TML) 138 2. Problem Overview 140 In this section we present sample use cases to illustrate each 141 challenge being addressed. 143 2.1. Table Ranges 145 Consider, for the sake of illustration, an FE table with 1 million 146 reasonably sized table rows which are sparsely populated. Assume, 147 again for the sake of illustration, that there are 2000 table rows 148 sparsely populated between the row indices 23-10023. 150 Implementation experience has shown that existing approaches for 151 retrieving or deleting a sizeable number of table rows is at the 152 programmatically level (from an application point of view) 153 unfriendly, tedious, and abusive of both compute and bandwidth 154 resources. 156 By Definition, ForCES GET and DEL requests sent from a controller (or 157 control app) are prepended with a path to a component and sent to the 158 FE. In the case of indexed tables, the component path can either 159 point to a table or a table row index. 161 As an example, a control application attempting to retrieve the first 162 2000 table rows appearing between row indices 23 and 10023 can 163 achieve its goal in one of: 165 o Dump the whole table and filter for the needed 2000 table rows. 167 o Send upto 10000 ForCES PL requests with monotonically incrementing 168 indices and stop when the needed 2000 entries are retrieved. 170 o If the application had knowledge of which table rows existed (not 171 unreasonable given the controller is supposed to be aware of state 172 within an NE), then the application could take advantage of ForCES 173 batching to send fewer large messages (each with different path 174 entries for a total of two thousand). 176 As argued, while the above options exist - all are tedious. 178 2.2. Error codes 180 [RFC5810] has defined a generic set of error codes that are to be 181 returned to the CE from an FE. Deployment experience has shown that 182 it would be useful to have more fine grained error codes. As an 183 example, the error code E_NOT_SUPPORTED could be mapped to many FE 184 error source possibilities that need to be then interpreted by the 185 caller based on some understanding of the nature of the sent request. 186 This makes debugging more time consuming. 188 3. Protocol Update Proposal 190 This section describes proposals to update the protocol for issues 191 discussed in Section 2 193 3.1. Table Ranges 195 We define a new TLV, TABLERANGE-TLV (type ID 0x117) that will be 196 associated with the PATH-DATA TLV in the same manner the KEYINFO-TLV 197 is. 199 +---------------------+---------------------+ 200 | Type (0x117) | Length | 201 +---------------------+---------------------+ 202 | Start Index | 203 +-------------------------------------------+ 204 | End Index | 205 +-------------------------------------------+ 207 Figure 1: ForCES table range request Layout 209 Figure 1 shows how this new TLV is constructed. 211 OPER = GET 212 PATH-DATA: 213 flags = F_SELTABRANGE, IDCount = 2, IDs = {1,6} 214 TABLERANGE-TLV content = {11,23} 216 Figure 2: ForCES table range request 218 Figure 2 illustrates a GET request for a range of rows 11 to 23 of a 219 table with component path of "1/6". 221 Path flag of F_SELTABRANGE (0x2 i.e bit 1, where bit 0 is F_SELKEY as 222 defined in RFC 5810) MUST be set to indicate the presence of the 223 TABLERANGE-TLV. The pathflag bit F_SELTABRANGE can only be used in a 224 GET or DEL and is mutually exclusive with F_SELKEY. The FE MUST 225 enforce the path flag constraints and ensure that the selected path 226 belongs to a defined indexed table component. Any violation of these 227 constraints MUST be rejected with an error code of E_INVALID_TFLAGS 228 with a description of what the problem is when using extended error 229 reporting (refer to Section 3.2). 231 The TABLERANGE-TLV contents constitute: 233 o A 32 bit start index. An index of 0 implies the beggining of the 234 table row. 236 o A 32 bit end index. A value of 0xFFFFFFFFFFFFFFFF implies the 237 last entry. 239 The response for a table range query will either be: 241 o The requested table data returned (when at least one referenced 242 row is available); in such a case, a response with a path pointing 243 to the table and whose data content contain the row(s) will be 244 sent to the CE. The data content MUST be encapsulated in 245 sparsedata TLV. The sparse data TLV content will have the "I" (in 246 ILV) for each table row indicating the table indices. 248 o An EXTENDEDRESULT-TLV (refer to Section 3.2.3) when: 250 * Response is to a range delete request. The Result will either 251 be: 253 + A success if any of the requested-for rows is deleted 255 + A proper error code if none of the requested for rows can be 256 deleted 258 * data is absent where the result code of E_EMPTY with an 259 optional content string describing the nature of the error 260 (refer to Section 3.2). 262 * When both a path key and path table range are reflected on the 263 the pathflags, an error code of E_INVALID_TFLAGS with an 264 optional content string describing the nature of the error 265 (refer to Section 3.2). 267 * other standard ForCES errors (such as ACL constraints trying to 268 retrieve contents of an unreadable table), accessing unknown 269 components etc. 271 3.2. Error Codes 273 We define several things: 275 1. A new set of error codes. 277 2. Allocating some reserved codes for private use. 279 3. A new TLV, EXTENDEDRESULT-TLV (0x118) that will carry a code 280 (which will be a superset of what is currently specified in 281 [RFC5810]) but also an optional cause content. This is 282 illustrated in Figure 3. 284 3.2.1. New Codes 286 EXTENDEDRESULT-TLV Result Value is 32 bits and is a superset of RFC 287 5810 Result TLV Result Value. The new version code space is 32 bits 288 as opposed to the RFC 5810 code size of 8 bits. The first 8 bit 289 values are common to both old 291 +------------+-------------------------+----------------------------+ 292 | Code | Mnemonic | Details | 293 +------------+-------------------------+----------------------------+ 294 | 0x18 | E_TIMED_OUT | A time out occured while | 295 | | | processing the message | 296 | 0x19 | E_INVALID_TFLAGS | Invalid table flags | 297 | 0x1A | E_INVALID_OP | Requested operation is | 298 | | | invalid | 299 | 0x1B | E_CONGEST_NT | Node Congestion | 300 | | | notification | 301 | 0x1C | E_COMPONENT_NOT_A_TABLE | Component not a table | 302 | 0x1D | E_PERM | Operation not permitted | 303 | 0x1E | E_BUSY | System is Busy | 304 | 0x1F | E_EMPTY | Table is empty | 305 | 0x20 | E_UNKNOWN | A generic catch all error | 306 | | | code. Carries a string to | 307 | | | further extrapolate what | 308 | | | the error implies. | 309 +------------+-------------------------+----------------------------+ 311 Table 1: New codes 313 3.2.2. Private Vendor Codes 315 Codes 0x100-0x200 are reserved for use as private codes. Since these 316 are freely available it is expected that the FE and CE side 317 implementations will both understand/interpret the semantics of any 318 used codes and avoid any conflicts. 320 3.2.3. Extended Result TLV 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type = EXTENDEDRESULT-TLV | Length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Result Value | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Optional Cause content | 330 . . 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 3: EXTENDEDRESULT-TLV 336 o Like all other ForCES TLVs, the EXTENDEDRESULT-TLV is expected to 337 be 32 bit aligned. 339 o The EXTENDEDRESULT-TLV Result Value derives and extends from the 340 same current namespace that is used by RESULT-TLV Result Value as 341 specified in RFC 5810, section 7.1.7. The main difference is that 342 we now have 32 bit result value (as opposed to the old 8 bit). 344 o The optional result content is defined to further disambiguate the 345 result value. It is expected Utf-8 string values to be used. 346 However, vendor specific error codes may choose to specify 347 different contents. Additionally, future codes may specify cause 348 contents to be of types other than string.. 350 o It is recommended that the maximum size of the cause string should 351 not exceed 32 bytes. We do not propose the cause string be 352 standardized. 354 3.2.3.1. Extended Result Backward compatibility 356 To support backward compatibility, we update and the FEPO LFB 357 Appendix A version to 1.2. We also add a new component ID 16 (named 358 EResultAdmin) and a capability Component ID 32 (named EResultCapab). 360 An FE will advertise its capability to support extended TLVs via the 361 EResultCapab table. When an FE is capable of responding with both 362 extended results and older result TLVs, it will have two table rows 363 one for each supported value. By default an FE capable of supporting 364 both modes will assume the lowest common denominator i.e EResultAdmin 365 will be EResultNotSupported; and will issue responses using RESULT- 366 TLVs. It should be noted an FE advertising FEPO version 1.2 MUST 367 support EXTENDEDRESULT-TLVs at minimum. 369 On an FE which supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a 370 master CE can turn on support for extended results by setting the 371 value to 2 in which case the FE MUST switch over to sending only 372 EXTENDEDRESULT-TLVs. Likewise a master CE can turn off extended 373 result responses by writting a 1 to the EResultAdmin. An FE that 374 does not support one mode or other MUST reject setting of 375 EResultAdmin to a value it does not support by responding with an 376 error code of E_NOT_SUPPORTED. 378 3.3. Large Table Dumping 380 Imagine a GET request to a path that is a table i.e a table dump. 381 Such a request is sent to the FE with a specific correlator, say X. 382 Imagine this table to have a large number of entries at the FE. For 383 the sake of illustration, lets say millions of rows. This requires 384 that the FE delivers the response over multiple messages, all using 385 the same correlator X. 387 The protocol document [RFC5810] does not adequately describe how a 388 GET response to such a large message is delivered. The text in this 389 section clarifies. We limit the discussion to a table object only. 391 Implementation experience of dumping large tables indicates we can 392 use the transaction flags to indicate that a GET response is the 393 beginning, middle or end of a multi-part message. In other words we 394 mirror the effect of an atomic transaction sent by a CE to an FE. 396 CE PL FE PL 398 | | 399 | (0) Query, Path-to-a-large-table, OP=GET | 400 |----------------------------------------------------->| 401 | correlattor = X | 402 | | 403 | (1) Query-Response, SOT,AT, OP=GET-RESPONSE, DATA | 404 |<-----------------------------------------------------| 405 | correlattor = X | 406 | DATA TLV (SPARSE/FULL) | 407 | | 408 | (2) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA | 409 |<-----------------------------------------------------| 410 | correlattor = X | 411 | DATA TLV (SPARSE/FULL) | 412 | | 413 | (3) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA | 414 |<-----------------------------------------------------| 415 | correlattor = X | 416 | DATA TLV (SPARSE/FULL) | 417 . . 418 . . 419 . . 420 . . 421 | | 422 | (N) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA | 423 |<-----------------------------------------------------| 424 | correlattor = X | 425 | DATA TLV (SPARSE/FULL) | 426 | | 427 | (N) Query-Response, EOT,AT, OP=GET-RESPONSE | 428 |<-----------------------------------------------------| 429 | correlattor = X | 430 | RESULT TLV (SUCCESS) | 431 | | 433 Figure 4: EXTENDEDRESULT-TLV 435 The last message which carries the EOT flag to go the CE MUST NOT 436 carry any data. This allows us to mirror ForCES 2PC messaging 437 [RFC5810] where the last message is an empty commit message. GET 438 response will carry a result code TLV in such a case. 440 4. Acknowledgements 442 The author would like to thank Evangelos Haleplidis and Joel Halpern 443 for discussions that made this document better. Adrian Farrel did an 444 excellent AD review of the document which improved the quality of 445 this document. 447 5. IANA Considerations 449 This document registers two new top Level TLVs and two new path flags 450 and updates an IANA registered FE Protocol object Logical Functional 451 Block (LFB). 453 The Appendix A defines an update to the FE Protocol Object LFB to 454 version 1.2. XXX: comment to IANA: The IANA registry 455 https://www.iana.org/assignments/forces/forces.xml sub-registy 456 "Logical Functional Block (LFB) Class Names and Class Identifiers" 457 will need to be updated for FE Protocol Object LFB version from 1.1 458 to 1.2 and this document reflected in the reference column. 460 XXX: comments to IANA - updates required to the "TLV types" 461 subregistry for the TLVs below. 463 The following new TLVs are defined: 465 o TABLERANGE-TLV (type ID 0x117) 467 o EXTENDEDRESULT-TLV (type ID 0x118) 469 XXX: Comment to IANA, section below affects subregistry "RESULT-TLV 470 Result Values" 472 The Defined RESULT-TLV Result Values are changed: 474 o codes 0x21-0xFE are unassigned. 476 o codes 0x18-0x20 are defined by this document in Section 3.2.1. 478 o codes 0x100-0x200 are reserved for private use. 480 XXX: Note to IANA - codes 0x18-0x20 need approval of the designated 481 expert (In this case Joel Halpern since the author is the other 482 expert). 484 A a new sub-registry for EXTENDEDRESULT-TLV Result Values needs to be 485 created. The codes 0x00-0xff are mirrored from the RESULT-TLV Result 486 Values sub-registry and must not be allocated. The codes 0x100-0x200 487 are reserved for private use as described earlier and the codes 488 0x200-0xffffffff are reserved for future use; these codes will be 489 allocated on First Come First Served basis and require specification 490 as well approval of an expert review. 492 6. Security Considerations 494 The security considerations that have been described in the ForCES 495 protocol [RFC5810] apply to this document as well. 497 7. References 499 7.1. Normative References 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, March 1997. 504 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 505 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 506 Control Element Separation (ForCES) Protocol 507 Specification", RFC 5810, March 2010. 509 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 510 Layer (TML) for the Forwarding and Control Element 511 Separation (ForCES) Protocol", RFC 5811, March 2010. 513 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 514 Element Separation (ForCES) Forwarding Element Model", 515 RFC 5812, March 2010. 517 [RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, 518 "High Availability within a Forwarding and Control Element 519 Separation (ForCES) Network Element", RFC 7121, 520 February 2014. 522 7.2. Informative References 524 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 525 "Forwarding and Control Element Separation (ForCES) 526 Framework", RFC 3746, April 2004. 528 Appendix A. Appendix A - New FEPO version 530 533 534 535 536 CEHBPolicyValues 537 538 The possible values of CE heartbeat policy 539 540 541 uchar 542 543 544 CEHBPolicy0 545 546 The CE will send heartbeats to the FE 547 every CEHDI timeout if no other messages 548 have been sent since. 549 550 551 552 CEHBPolicy1 553 554 The CE will not send heartbeats to the FE 555 556 557 558 559 560 561 FEHBPolicyValues 562 563 The possible values of FE heartbeat policy 564 565 566 uchar 567 568 569 FEHBPolicy0 570 571 The FE will not generate any heartbeats 572 to the CE 573 574 575 576 FEHBPolicy1 577 578 The FE generates heartbeats to the CE every FEHI 579 if no other messages have been sent to the CE. 580 581 583 584 585 586 587 FERestartPolicyValues 588 589 The possible values of FE restart policy 590 591 592 uchar 593 594 595 FERestartPolicy0 596 597 The FE restart restats its state from scratch 598 599 600 601 602 603 604 HAModeValues 605 606 The possible values of HA modes 607 608 609 uchar 610 611 612 NoHA 613 614 The FE is not running in HA mode 615 616 617 618 ColdStandby 619 620 The FE is running in HA mode cold Standby 621 622 623 624 HotStandby 625 626 The FE is running in HA mode hot Standby 627 628 629 630 632 633 634 CEFailoverPolicyValues 635 636 The possible values of CE failover policy 637 638 639 uchar 640 641 642 CEFailoverPolicy0 643 644 The FE should stop functioning immediate and 645 transition to the FE OperDisable state 646 647 648 649 CEFailoverPolicy1 650 651 The FE should continue forwarding even 652 without an associated CE for CEFTI. The 653 FE goes to FE OperDisable when the CEFTI 654 expires and no association. Requires 655 graceful restart support. 656 657 658 659 660 661 662 FEHACapab 663 664 The supported HA features 665 666 667 uchar 668 669 670 GracefullRestart 671 672 The FE supports Graceful Restart 673 674 675 676 HA 677 678 The FE supports HA 679 681 682 683 684 685 686 CEStatusType 687 Status values. Status for each CE 688 689 uchar 690 691 692 Disconnected 693 No connection attempt with the CE yet 694 695 696 697 Connected 698 The FE connection with the CE at the TML 699 has been completed 700 701 702 703 Associated 704 The FE has associated with the CE 705 706 707 708 IsMaster 709 The CE is the master (and associated) 710 711 712 713 LostConnection 714 The FE was associated with the CE but 715 lost the connection 716 717 718 719 Unreachable 720 The CE is deemed as unreachable by the FE 721 722 723 724 725 726 727 StatisticsType 728 Statistics Definition 729 730 731 RecvPackets 732 Packets Received 733 uint64 734 735 736 RecvErrPackets 737 Packets Received from CE with errors 738 739 uint64 740 741 742 RecvBytes 743 Bytes Received from CE 744 uint64 745 746 747 RecvErrBytes 748 Bytes Received from CE in Error 749 uint64 750 751 752 TxmitPackets 753 Packets Transmitted to CE 754 uint64 755 756 757 TxmitErrPackets 758 759 Packets Transmitted to CE that incurred 760 errors 761 762 uint64 763 764 765 TxmitBytes 766 Bytes Transmitted to CE 767 uint64 768 769 770 TxmitErrBytes 771 Bytes Transmitted to CE incurring errors 772 773 uint64 774 775 776 777 778 AllCEType 779 Table Type for AllCE component 780 781 782 CEID 783 ID of the CE 784 uint32 785 786 787 Statistics 788 Statistics per CE 789 StatisticsType 790 791 792 CEStatus 793 Status of the CE 794 CEStatusType 795 796 797 798 799 ExtendedResultType 800 801 Possible extended result support 802 803 804 uchar 805 806 807 808 809 810 EResultNotSupported 811 812 Extended Results are not supported 813 814 815 816 EResultSupported 817 818 Extended Results are supported 819 820 821 822 823 824 825 826 827 FEPO 828 829 The FE Protocol Object, with EXtended Result control 830 831 1.2 832 833 834 CurrentRunningVersion 835 Currently running ForCES version 836 uchar 837 838 839 FEID 840 Unicast FEID 841 uint32 842 843 844 MulticastFEIDs 845 846 the table of all multicast IDs 847 848 849 uint32 850 851 852 853 CEHBPolicy 854 855 The CE Heartbeat Policy 856 857 CEHBPolicyValues 858 859 860 CEHDI 861 862 The CE Heartbeat Dead Interval in millisecs 863 864 uint32 865 866 867 FEHBPolicy 868 869 The FE Heartbeat Policy 870 871 FEHBPolicyValues 872 873 874 FEHI 875 876 The FE Heartbeat Interval in millisecs 877 878 uint32 879 880 881 CEID 882 883 The Primary CE this FE is associated with 884 885 uint32 886 887 888 BackupCEs 889 890 The table of all backup CEs other than the 891 primary 892 893 894 uint32 895 896 897 898 CEFailoverPolicy 899 900 The CE Failover Policy 901 902 CEFailoverPolicyValues 903 904 905 CEFTI 906 907 The CE Failover Timeout Interval in millisecs 908 909 uint32 910 911 912 FERestartPolicy 913 914 The FE Restart Policy 915 916 FERestartPolicyValues 917 918 919 LastCEID 920 921 The Primary CE this FE was last associated 922 with 923 924 uint32 925 926 927 HAMode 928 929 The HA mode used 930 931 HAModeValues 932 933 934 AllCEs 935 The table of all CEs 936 937 AllCEType 938 939 940 941 EResultAdmin 942 943 Turn Extended results off or on. 944 default to off 945 946 ExtendedResultType 947 1 948 949 950 951 952 SupportableVersions 953 954 the table of ForCES versions that FE supports 955 956 957 uchar 958 959 960 961 HACapabilities 962 963 the table of HA capabilities the FE supports 964 965 966 FEHACapab 967 968 969 970 EResultCapab 971 972 the table of supported result capabilities 973 974 975 ExtendedResultType 976 977 978 979 980 981 PrimaryCEDown 982 983 The primary CE has changed 984 985 986 LastCEID 987 988 989 990 991 LastCEID 992 993 994 995 996 PrimaryCEChanged 997 A New primary CE has been selected 998 999 1000 CEID 1001 1002 1003 1004 1005 CEID 1006 1007 1008 1009 1010 1011 1012 1014 Author's Address 1016 Jamal Hadi Salim 1017 Mojatatu Networks 1018 Suite 400, 303 Moodie Dr. 1019 Ottawa, Ontario K2H 9R4 1020 Canada 1022 Email: hadi@mojatatu.com