idnits 2.17.1 draft-ietf-forces-protoextension-03.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 3, 2014) is 3585 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 3, 2014 5 Intended status: Standards Track 6 Expires: January 4, 2015 8 ForCES Protocol Extensions 9 draft-ietf-forces-protoextension-03 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 4, 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. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Error codes . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Protocol Update Proposal . . . . . . . . . . . . . . . . . . . 6 61 4.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.2.1. New Codes . . . . . . . . . . . . . . . . . . . . . . 8 64 4.2.2. Vendor Codes . . . . . . . . . . . . . . . . . . . . . 9 65 4.2.3. Extended Result TLV . . . . . . . . . . . . . . . . . 9 66 4.2.3.1. Extended Result Backward compatibility . . . . . . 9 67 4.3. Large Table Dumping . . . . . . . . . . . . . . . . . . . 10 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Appendix A. Appendix A - New FEPO version . . . . . . . . . . . . 13 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 77 1. Terminology and Conventions 79 1.1. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 1.2. Definitions 87 This document reiterates the terminology defined by the ForCES 88 architecture in various documents for the sake of clarity. 90 FE Model - The FE model is designed to model the logical 91 processing functions of an FE. The FE model proposed in this 92 document includes three components; the LFB modeling of individual 93 Logical Functional Block (LFB model), the logical interconnection 94 between LFBs (LFB topology), and the FE-level attributes, 95 including FE capabilities. The FE model provides the basis to 96 define the information elements exchanged between the CE and the 97 FE in the ForCES protocol [RFC5810]. 99 LFB (Logical Functional Block) Class (or type) - A template that 100 represents a fine-grained, logically separable aspect of FE 101 processing. Most LFBs relate to packet processing in the data 102 path. LFB classes are the basic building blocks of the FE model. 104 LFB Instance - As a packet flows through an FE along a data path, 105 it flows through one or multiple LFB instances, where each LFB is 106 an instance of a specific LFB class. Multiple instances of the 107 same LFB class can be present in an FE's data path. Note that we 108 often refer to LFBs without distinguishing between an LFB class 109 and LFB instance when we believe the implied reference is obvious 110 for the given context. 112 LFB Model - The LFB model describes the content and structures in 113 an LFB, plus the associated data definition. XML is used to 114 provide a formal definition of the necessary structures for the 115 modeling. Four types of information are defined in the LFB model. 116 The core part of the LFB model is the LFB class definitions; the 117 other three types of information define constructs associated with 118 and used by the class definition. These are reusable data types, 119 supported frame (packet) formats, and metadata. 121 LFB Metadata - Metadata is used to communicate per-packet state 122 from one LFB to another, but is not sent across the network. The 123 FE model defines how such metadata is identified, produced, and 124 consumed by the LFBs, but not how the per-packet state is 125 implemented within actual hardware. Metadata is sent between the 126 FE and the CE on redirect packets. 128 ForCES Component - A ForCES Component is a well-defined, uniquely 129 identifiable and addressable ForCES model building block. A 130 component has a 32-bit ID, name, type, and an optional synopsis 131 description. These are often referred to simply as components. 133 LFB Component - An LFB component is a ForCES component that 134 defines the Operational parameters of the LFBs that must be 135 visible to the CEs. 137 ForCES Protocol - Protocol that runs in the Fp reference points in 138 the ForCES Framework [RFC3746]. 140 ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol 141 architecture that defines the ForCES protocol messages, the 142 protocol state transfer scheme, and the ForCES protocol 143 architecture itself as defined in the ForCES Protocol 144 Specification [RFC5810]. 146 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 147 ForCES protocol architecture that uses the capabilities of 148 existing transport protocols to specifically address protocol 149 message transportation issues, such as how the protocol messages 150 are mapped to different transport media (like TCP, IP, ATM, 151 Ethernet, etc.), and how to achieve and implement reliability, 152 ordering, etc. the ForCES SCTP TML [RFC5811] describes a TML that 153 is mandated for ForCES. 155 2. Introduction 157 Experience in implementing and deploying ForCES architecture has 158 demonstrated need for a few small extensions both to ease 159 programmability and to improve wire efficiency of some transactions. 160 This document describes a few extensions to the ForCES Protocol 161 Specification [RFC5810] semantics to achieve that end goal. 163 This document describes and justifies the need for 2 small extensions 164 which are backward compatible. The document also clarifies details 165 of how dumping of a large table residing on an FE is achieved. To 166 summarize: 168 1. A table range operation to allow a controller or control 169 application to request an arbitrary range of table rows is 170 introduced. 172 2. Additional error codes returned to the controller (or control 173 application) by an FE are introduced. Additionally a new 174 extension to carry details on error codes is introduced. As a 175 result the FEPO LFB is updated over [RFC7121]. 177 3. While already supported FE response to a GET request of a large 178 table which does not fit in a single PL message is not described 179 in [RFC5810]. This document clarifies the details. 181 3. Problem Overview 183 In this section we present sample use cases to illustrate each 184 challenge being addressed. 186 3.1. Table Ranges 188 Consider, for the sake of illustration, an FE table with 1 million 189 reasonably sized table rows which are sparsely populated. Assume, 190 again for the sake of illustration, that there are 2000 table rows 191 sparsely populated between the row indices 23-10023. 193 Implementation experience has shown that existing approaches for 194 retrieving or deleting a sizeable number of table rows is at the 195 programmatically level (from an application point of view) 196 unfriendly, tedious, and abusive of both compute and bandwidth 197 resources. 199 By Definition, ForCES GET and DEL requests sent from a controller (or 200 control app) are prepended with a path to a component and sent to the 201 FE. In the case of indexed tables, the component path can either 202 point to a table or a table row index. 204 As an example, a control application attempting to retrieve the first 205 2000 table rows appearing between row indices 23 and 10023 can 206 achieve its goal in one of: 208 o Dump the whole table and filter for the needed 2000 table rows. 210 o Send upto 10000 ForCES PL requests with monotonically incrementing 211 indices and stop when the needed 2000 entries are retrieved. 213 o If the application had knowledge of which table rows existed (not 214 unreasonable given the controller is supposed to be aware of state 215 within an NE), then the application could take advantage of ForCES 216 batching to send fewer large messages (each with different path 217 entries for a total of two thousand). 219 As argued, while the above options exist - all are tedious. 221 3.2. Error codes 223 [RFC5810] has defined a generic set of error codes that are to be 224 returned to the CE from an FE. Deployment experience has shown that 225 it would be useful to have more fine grained error codes. As an 226 example, the error code E_NOT_SUPPORTED could be mapped to many FE 227 error source possibilities that need to be then interpreted by the 228 caller based on some understanding of the nature of the sent request. 229 This makes debugging more time consuming. 231 4. Protocol Update Proposal 233 This section describes proposals to update the protocol for issues 234 discussed in Section 3 236 4.1. Table Ranges 238 We propose to add a Table-range TLV (type ID 0x117) that will be 239 associated with the PATH-DATA TLV in the same manner the KEYINFO-TLV 240 is. 242 +---------------------+---------------------+ 243 | Type (0x117) | Length | 244 +---------------------+---------------------+ 245 | Start Index | 246 +-------------------------------------------+ 247 | End Index | 248 +-------------------------------------------+ 250 Figure 1: ForCES table range request Layout 252 Figure 1 shows how this new TLV is constructed. 254 OPER = GET 255 PATH-DATA: 256 flags = F_SELTABRANGE, IDCount = 2, IDs = {1,6} 257 TABLERANGE-TLV content = {11,23} 259 Figure 2: ForCES table range request 261 Figure 2 illustrates a GET request for a range of rows 11 to 23 of a 262 table with component path of "1/6". 264 Path flag of F_SELTABRANGE (0x2 i.e bit 1, where bit 0 is F_SELKEY as 265 defined in RFC 5810) MUST be set to indicate the presence of the 266 TABLERANGE-TLV. The pathflag bit F_SELTABRANGE can only be used in a 267 GET or DEL and is mutually exclusive with F_SELKEY. The FE MUST 268 enforce the path flag constraints and ensure that the selected path 269 belongs to a defined indexed table component. Any violation of these 270 constraints MUST be rejected with an error code of E_INVALID_TFLAGS 271 with a description of what the problem is when using extended error 272 reporting (refer to Section 4.2). 274 The TABLERANGE-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. 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 An EXTENDEDRESULT-TLV (refer to Section 4.2.3) when: 293 * Response is to a range delete request. The Result will either 294 be: 296 + A success if any of the requested-for rows is deleted 298 + A proper error code if none of the requested for rows can be 299 deleted 301 * data is absent where the result code of E_EMPTY with an 302 optional content string describing the nature of the error 303 (refer to Section 4.2). 305 * When both a path key and path table range are reflected on the 306 the pathflags, an error code of E_INVALID_TFLAGS with an 307 optional content string describing the nature of the error 308 (refer to Section 4.2). 310 * other standard ForCES errors (such as ACL constraints trying to 311 retrieve contents of an unreadable table), accessing unknown 312 components etc. 314 4.2. Error Codes 316 We propose several things: 318 1. A new set of error codes. 320 2. Allocating some reserved codes for vendor use. 322 3. A new TLV, EXTENDEDRESULT-TLV (0x118) that will carry a code 323 (which will be a superset of what is currently specified in 324 [RFC5810]) but also an optional cause content. This is 325 illustrated in Figure 3. 327 4.2.1. New Codes 329 EXTENDEDRESULT-TLV Result Value is 32 bits and is a superset of RFC 330 5810 Result TLV Result Value. The new version code space is 32 bits 331 as opposed to the RFC 5810 code size of 8 bits. The first 8 bit 332 values are common to both old 334 +------------+-------------------------+----------------------------+ 335 | Code | Mnemonic | Details | 336 +------------+-------------------------+----------------------------+ 337 | 0x18 | E_TIMED_OUT | A time out occured while | 338 | | | processing the message | 339 | 0x19 | E_INVALID_TFLAGS | Invalid table flags | 340 | 0x1A | E_INVALID_OP | Requested operation is | 341 | | | invalid | 342 | 0x1B | E_CONGEST_NT | Node Congestion | 343 | | | notification | 344 | 0x1C | E_COMPONENT_NOT_A_TABLE | Component not a table | 345 | 0x1D | E_PERM | Operation not permitted | 346 | 0x1E | E_BUSY | System is Busy | 347 | 0x1F | E_EMPTY | Table is empty | 348 | 0x20 | E_UNKNOWN | A generic catch all error | 349 | | | code. Carries a string to | 350 | | | further extrapolate what | 351 | | | the error implies. | 352 +------------+-------------------------+----------------------------+ 354 Table 1: New codes 356 4.2.2. Vendor Codes 358 Codes 0x100-0x200 are reserved for use as vendor codes. Since these 359 are freely available it is expected that the FE and CE side will both 360 understand/interpret the semantics of any used codes. 362 4.2.3. Extended Result TLV 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type = EXTENDEDRESULT-TLV | Length | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Result Value | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Optional Cause content | 372 . . 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Figure 3: EXTENDEDRESULT-TLV 378 o Like all other ForCES TLVs, the EXTENDEDRESULT-TLV is expected to 379 be 32 bit aligned. 381 o The EXTENDEDRESULT-TLV Result Value derives and extends from the 382 same current namespace that is used by RESULT-TLV Result Value as 383 specified in RFC 5810, section 7.1.7. The main difference is that 384 we now have 32 bit result value (as opposed to the old 8 bit). 386 o The optional result content is defined to further disambiguate the 387 result value. It is expected Utf-8 string values to be used. 388 However, vendor specific error codes may choose to specify 389 different contents. Additionally, future codes may specify cause 390 contents to be of types other than string.. 392 o It is recommended that the maximum size of the cause string should 393 not exceed 32 bytes. We do not propose the cause string be 394 standardized. 396 4.2.3.1. Extended Result Backward compatibility 398 To support backward compatibility, we add a new component ID 16 399 (named EResultAdmin), a capability Component ID 32 (named 400 EResultCapab), and updated the version to 1.2 for the FEPO LFB 401 Appendix A. 403 An FE will advertise its capability to support extended TLVs via the 404 EResultCapab table. When an FE is capable of responding with both 405 extended results and older result TLVs, it will have two table rows 406 one for each supported value. By default an FE capable of supporting 407 both modes will assume the lowest common denominator i.e EResultAdmin 408 will be EResultNotSupported; and will issue responses using RESULT- 409 TLVs. 411 A master CE can turn on support for extended results by setting the 412 value to 2 in which case the FE MUST switch over to sending only 413 EXTENDEDRESULT-TLVs. Likewise a master CE can turn off extended 414 result responses by writting a 1 to the EResultAdmin. An FE that 415 does not support one mode or other MUST reject setting of 416 EResultAdmin to a value it does not support by responding with an 417 error code of E_NOT_SUPPORTED. 419 4.3. Large Table Dumping 421 Imagine a GET request to a path that is a table i.e a table dump. 422 Such a request is sent to the FE with a specific correlator, say X. 423 Imagine this table to have a large number of entries at the FE. For 424 the sake of illustration, lets say millions of rows. This requires 425 that the FE delivers the response over multiple messages, all using 426 the same correlator X. 428 The protocol document [RFC5810] does not adequately describe how a 429 GET response to such a large message is delivered. The text in this 430 section clarifies. We limit the discussion to a table object only. 432 Implementation experience of dumping large tables indicates we can 433 use the transaction flags to indicate that a GET response is the 434 beginning, middle or end of a multi-part message. In other words we 435 mirror the effect of an atomic transaction sent by a CE to an FE. 437 CE PL FE PL 439 | | 440 | (0) Query, Path-to-a-large-table, OP=GET | 441 |----------------------------------------------------->| 442 | correlattor = X | 443 | | 444 | (1) Query-Response, SOT,AT, OP=GET-RESPONSE, DATA | 445 |<-----------------------------------------------------| 446 | correlattor = X | 447 | DATA TLV (SPARSE/FULL) | 448 | | 449 | (2) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA | 450 |<-----------------------------------------------------| 451 | correlattor = X | 452 | DATA TLV (SPARSE/FULL) | 453 | | 454 | (3) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA | 455 |<-----------------------------------------------------| 456 | correlattor = X | 457 | DATA TLV (SPARSE/FULL) | 458 . . 459 . . 460 . . 461 . . 462 | | 463 | (N) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA | 464 |<-----------------------------------------------------| 465 | correlattor = X | 466 | DATA TLV (SPARSE/FULL) | 467 | | 468 | (N) Query-Response, EOT,AT, OP=GET-RESPONSE | 469 |<-----------------------------------------------------| 470 | correlattor = X | 471 | RESULT TLV (SUCCESS) | 472 | | 474 Figure 4: EXTENDEDRESULT-TLV 476 The last message which carries the EOT flag to go the CE MUST NOT 477 carry any data. This allows us to mirror ForCES 2PC messaging 478 [RFC5810] where the last message is an empty commit message. GET 479 response will carry a result code TLV in such a case. 481 5. Acknowledgements 483 The author would like to thank Evangelos Haleplidis and Joel Halpern 484 for discussions that made this document better. 486 6. IANA Considerations 488 This document registers two new top Level TLVs and two new path flags 489 and updates an IANA registered FE Protocol object Logical Functional 490 Block (LFB). 492 XXX: when this document is undergoing IANA review we should update 493 https://www.iana.org/assignments/forces/forces.xml section on FEPO to 494 have the new version reflected. 496 The following new TLVs are defined: 498 o TABLERANGE-TLV (type ID 0x117) 500 o EXTENDEDRESULT-TLV (type ID 0x118) 502 The following new path flags are defined: 504 o F_SELTABRANGE (value 0x2 i.e bit 1) 506 The Defined Result Values are changed: 508 o codes 0x21-0xFE are reserved. 510 o codes 0x18-0x20 are defined by this document. 512 o codes 0x100-0x200 are reserved for vendor use. 514 7. Security Considerations 516 The security considerations that have been described in the ForCES 517 protocol [RFC5810] apply to this document as well. 519 8. References 521 8.1. Normative References 523 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 524 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 525 Control Element Separation (ForCES) Protocol 526 Specification", RFC 5810, March 2010. 528 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 529 Layer (TML) for the Forwarding and Control Element 530 Separation (ForCES) Protocol", RFC 5811, March 2010. 532 [RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, 533 "High Availability within a Forwarding and Control Element 534 Separation (ForCES) Network Element", RFC 7121, 535 February 2014. 537 8.2. Informative References 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 543 "Forwarding and Control Element Separation (ForCES) 544 Framework", RFC 3746, April 2004. 546 Appendix A. Appendix A - New FEPO version 548 551 552 553 554 CEHBPolicyValues 555 556 The possible values of CE heartbeat policy 557 558 559 uchar 560 561 562 CEHBPolicy0 563 564 The CE will send heartbeats to the FE 565 every CEHDI timeout if no other messages 566 have been sent since. 567 568 569 570 CEHBPolicy1 571 572 The CE will not send heartbeats to the FE 573 574 576 577 578 579 580 FEHBPolicyValues 581 582 The possible values of FE heartbeat policy 583 584 585 uchar 586 587 588 FEHBPolicy0 589 590 The FE will not generate any heartbeats 591 to the CE 592 593 594 595 FEHBPolicy1 596 597 The FE generates heartbeats to the CE every FEHI 598 if no other messages have been sent to the CE. 599 600 601 602 603 604 605 FERestartPolicyValues 606 607 The possible values of FE restart policy 608 609 610 uchar 611 612 613 FERestartPolicy0 614 615 The FE restart restats its state from scratch 616 617 618 619 620 621 622 HAModeValues 623 624 The possible values of HA modes 625 626 627 uchar 628 629 630 NoHA 631 632 The FE is not running in HA mode 633 634 635 636 ColdStandby 637 638 The FE is running in HA mode cold Standby 639 640 641 642 HotStandby 643 644 The FE is running in HA mode hot Standby 645 646 647 648 649 650 651 CEFailoverPolicyValues 652 653 The possible values of CE failover policy 654 655 656 uchar 657 658 659 CEFailoverPolicy0 660 661 The FE should stop functioning immediate and 662 transition to the FE OperDisable state 663 664 665 666 CEFailoverPolicy1 667 668 The FE should continue forwarding even 669 without an associated CE for CEFTI. The 670 FE goes to FE OperDisable when the CEFTI 671 expires and no association. Requires 672 graceful restart support. 673 674 675 676 677 678 679 FEHACapab 680 681 The supported HA features 682 683 684 uchar 685 686 687 GracefullRestart 688 689 The FE supports Graceful Restart 690 691 692 693 HA 694 695 The FE supports HA 696 697 698 699 700 701 702 CEStatusType 703 Status values. Status for each CE 704 705 uchar 706 707 708 Disconnected 709 No connection attempt with the CE yet 710 711 712 713 Connected 714 The FE connection with the CE at the TML 715 has been completed 716 717 718 719 Associated 720 The FE has associated with the CE 721 722 723 724 IsMaster 725 The CE is the master (and associated) 726 727 728 729 LostConnection 730 The FE was associated with the CE but 731 lost the connection 732 733 734 735 Unreachable 736 The CE is deemed as unreachable by the FE 737 738 739 740 741 742 743 StatisticsType 744 Statistics Definition 745 746 747 RecvPackets 748 Packets Received 749 uint64 750 751 752 RecvErrPackets 753 Packets Received from CE with errors 754 755 uint64 756 757 758 RecvBytes 759 Bytes Received from CE 760 uint64 761 762 763 RecvErrBytes 764 Bytes Received from CE in Error 765 uint64 766 767 768 TxmitPackets 769 Packets Transmitted to CE 770 uint64 771 772 773 TxmitErrPackets 774 775 Packets Transmitted to CE that incurred 776 errors 777 778 uint64 779 780 781 TxmitBytes 782 Bytes Transmitted to CE 783 uint64 784 785 786 TxmitErrBytes 787 Bytes Transmitted to CE incurring errors 788 789 uint64 790 791 792 793 794 AllCEType 795 Table Type for AllCE component 796 797 798 CEID 799 ID of the CE 800 uint32 801 802 803 Statistics 804 Statistics per CE 805 StatisticsType 806 807 808 CEStatus 809 Status of the CE 810 CEStatusType 811 812 813 814 815 ExtendedResultType 816 817 Possible extended result support 818 819 820 uchar 821 822 823 824 825 826 EResultNotSupported 827 828 Extended Results are not supported 829 830 831 832 EResultSupported 833 834 Extended Results are supported 835 836 837 838 839 840 841 842 843 FEPO 844 845 The FE Protocol Object, with EXtended Result control 846 847 1.2 848 849 850 CurrentRunningVersion 851 Currently running ForCES version 852 uchar 853 854 855 FEID 856 Unicast FEID 857 uint32 858 859 860 MulticastFEIDs 861 862 the table of all multicast IDs 863 864 865 uint32 866 867 868 869 CEHBPolicy 870 871 The CE Heartbeat Policy 872 873 CEHBPolicyValues 874 875 876 CEHDI 877 878 The CE Heartbeat Dead Interval in millisecs 879 880 uint32 881 882 883 FEHBPolicy 884 885 The FE Heartbeat Policy 886 887 FEHBPolicyValues 888 889 890 FEHI 891 892 The FE Heartbeat Interval in millisecs 893 894 uint32 895 896 897 CEID 898 899 The Primary CE this FE is associated with 900 901 uint32 902 903 904 BackupCEs 905 906 The table of all backup CEs other than the 907 primary 908 909 910 uint32 911 913 914 915 CEFailoverPolicy 916 917 The CE Failover Policy 918 919 CEFailoverPolicyValues 920 921 922 CEFTI 923 924 The CE Failover Timeout Interval in millisecs 925 926 uint32 927 928 929 FERestartPolicy 930 931 The FE Restart Policy 932 933 FERestartPolicyValues 934 935 936 LastCEID 937 938 The Primary CE this FE was last associated 939 with 940 941 uint32 942 943 944 HAMode 945 946 The HA mode used 947 948 HAModeValues 949 950 951 AllCEs 952 The table of all CEs 953 954 AllCEType 955 956 957 958 EResultAdmin 959 960 Turn Extended results off or on. 962 default to off 963 964 ExtendedResultType 965 1 966 967 968 969 970 SupportableVersions 971 972 the table of ForCES versions that FE supports 973 974 975 uchar 976 977 978 979 HACapabilities 980 981 the table of HA capabilities the FE supports 982 983 984 FEHACapab 985 986 987 988 EResultCapab 989 990 the table of supported result capabilities 991 992 993 ExtendedResultType 994 995 996 997 998 999 PrimaryCEDown 1000 1001 The primary CE has changed 1002 1003 1004 LastCEID 1005 1006 1007 1008 1009 LastCEID 1011 1012 1013 1014 1015 PrimaryCEChanged 1016 A New primary CE has been selected 1017 1018 1019 CEID 1020 1021 1022 1023 1024 CEID 1025 1026 1027 1028 1029 1030 1031 1033 Author's Address 1035 Jamal Hadi Salim 1036 Mojatatu Networks 1037 Suite 400, 303 Moodie Dr. 1038 Ottawa, Ontario K2H 9R4 1039 Canada 1041 Email: hadi@mojatatu.com