idnits 2.17.00 (12 Aug 2021) /tmp/idnits10971/draft-ietf-forces-protocol-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (March 2, 2009) is 4821 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) == Missing Reference: 'DATA' is mentioned on line 1920, but not defined == Missing Reference: 'SELECTOR' is mentioned on line 1921, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FE-MODEL' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5390 == Outdated reference: draft-ietf-forces-sctptml has been published as RFC 5811 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Doria (Ed.) 3 Internet-Draft Lulea University of Technology 4 Intended status: Standards Track R. Haas (Ed.) 5 Expires: September 3, 2009 IBM 6 J. Hadi Salim (Ed.) 7 Znyx 8 H. Khosravi (Ed.) 9 Intel 10 W. M. Wang (Ed.) 11 Zhejiang Gongshang University 13 March 2, 2009 15 ForCES Protocol Specification 16 draft-ietf-forces-protocol-22.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 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 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 3, 2009. 41 Copyright Notice 43 Copyright (c) 2009 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents in effect on the date of 48 publication of this document (http://trustee.ietf.org/license-info). 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. 52 Abstract 54 This document specifies the Forwarding and Control Element Separation 55 (ForCES) protocol. ForCES protocol is used for communications 56 between Control Elements(CEs) and Forwarding Elements (FEs) in a 57 ForCES Network Element (ForCES NE). This specification is intended 58 to meet the ForCES protocol requirements defined in RFC3654. Besides 59 the ForCES protocol, this specification also defines the requirements 60 for the Transport Mapping Layer (TML). 62 Authors 64 The participants in the ForCES Protocol Team, primary co-authors and 65 co-editors, of this protocol specification, are: 67 Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea 68 University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), 69 Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang 70 (Zhejiang Gongshang University). Special acknowledgement goes to 71 Joel Halpern who has done extensive editing in support of congruence 72 between the model and this protocol specification. Without his 73 participation and persistence, this specification might never have 74 been completed. 76 Table of Contents 78 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 7 79 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 7 80 1.2. Other Notation . . . . . . . . . . . . . . . . . . . . . 7 81 1.3. Integers . . . . . . . . . . . . . . . . . . . . . . . . 7 82 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 83 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 12 86 4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 15 88 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 15 89 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 16 90 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 17 91 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18 92 4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 20 93 4.3.1. Transactions, Atomicity, Execution and Responses . . 20 94 4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 26 95 4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 27 96 4.3.4. FE Object and FE Protocol LFBs . . . . . . . . . . . 27 97 4.4. Protocol Scenarios . . . . . . . . . . . . . . . . . . . 28 98 4.4.1. Association Setup State . . . . . . . . . . . . . . . 28 99 4.4.2. Association Established state or Steady State . . . . 29 100 5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 32 101 5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 35 102 6. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 36 103 6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 36 104 6.2. Type Length Value (TLV) Structuring . . . . . . . . . . . 41 105 6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 42 106 6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 42 107 6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 108 6.4. Important Protocol encapsulations . . . . . . . . . . . . 43 109 6.4.1. Paths . . . . . . . . . . . . . . . . . . . . . . . . 43 110 6.4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 44 111 6.4.3. DATA TLVs . . . . . . . . . . . . . . . . . . . . . . 44 112 6.4.4. Addressing LFB entities . . . . . . . . . . . . . . . 44 113 7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 46 114 7.1. Discussion on encoding . . . . . . . . . . . . . . . . . 50 115 7.1.1. Data Packing Rules . . . . . . . . . . . . . . . . . 50 116 7.1.2. Path Flags . . . . . . . . . . . . . . . . . . . . . 50 117 7.1.3. Relation of operational flags with global message 118 flags . . . . . . . . . . . . . . . . . . . . . . . . 51 119 7.1.4. Content Path Selection . . . . . . . . . . . . . . . 51 120 7.1.5. LFBselect-TLV . . . . . . . . . . . . . . . . . . . . 51 121 7.1.6. OPER-TLV . . . . . . . . . . . . . . . . . . . . . . 52 122 7.1.7. RESULT TLV . . . . . . . . . . . . . . . . . . . . . 54 123 7.1.8. DATA TLV . . . . . . . . . . . . . . . . . . . . . . 57 124 7.1.9. SET and GET Relationship . . . . . . . . . . . . . . 58 125 7.2. Protocol Encoding Visualization . . . . . . . . . . . . . 59 126 7.3. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 62 127 7.3.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 63 128 7.3.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 66 129 7.4. Semantics of Message Direction . . . . . . . . . . . . . 66 130 7.5. Association Messages . . . . . . . . . . . . . . . . . . 67 131 7.5.1. Association Setup Message . . . . . . . . . . . . . . 67 132 7.5.2. Association Setup Response Message . . . . . . . . . 69 133 7.5.3. Association Teardown Message . . . . . . . . . . . . 70 134 7.6. Configuration Messages . . . . . . . . . . . . . . . . . 72 135 7.6.1. Config Message . . . . . . . . . . . . . . . . . . . 72 136 7.6.2. Config Response Message . . . . . . . . . . . . . . . 74 137 7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 76 138 7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 76 139 7.7.2. Query Response Message . . . . . . . . . . . . . . . 78 140 7.8. Event Notification Message . . . . . . . . . . . . . . . 80 141 7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 82 142 7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 85 143 8. High Availability Support . . . . . . . . . . . . . . . . . . 87 144 8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 87 145 8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 90 146 9. Security Considerations . . . . . . . . . . . . . . . . . . . 91 147 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 91 148 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 92 149 9.1.2. Message Authentication . . . . . . . . . . . . . . . 92 150 9.2. ForCES PL and TML security service . . . . . . . . . . . 92 151 9.2.1. Endpoint authentication service . . . . . . . . . . . 92 152 9.2.2. Message authentication service . . . . . . . . . . . 93 153 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 93 154 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94 155 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 156 11.1. Normative References . . . . . . . . . . . . . . . . . . 95 157 11.2. Informational References . . . . . . . . . . . . . . . . 95 158 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 96 159 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 96 160 A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 97 161 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 98 162 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 98 163 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 98 164 A.6. Association Setup Response . . . . . . . . . . . . . . . 99 165 A.7. Association Teardown Message . . . . . . . . . . . . . . 100 166 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 101 167 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 106 168 B.2. Components . . . . . . . . . . . . . . . . . . . . . . . 106 169 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 107 170 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 111 171 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 126 173 1. Terminology and Conventions 175 1.1. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC2119]. 181 1.2. Other Notation 183 In Table 1 and Table 2 the following notation is used to indicate 184 multiplicity: 186 (value)+ .... means "1 or more instance of value" 188 (value)* .... means "0 or more instance of value" 190 1.3. Integers 192 All integers are to be coded as unsigned binary integers of 193 appropriate length. 195 2. Introduction 197 Forwarding and Control Element Separation (ForCES) defines an 198 architectural framework and associated protocols to standardize 199 information exchange between the control plane and the forwarding 200 plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined 201 the ForCES requirements, and RFC 3746 has defined the ForCES 202 framework. While there may be multiple protocols used within the 203 overall ForCES architecture, the term "ForCES protocol" and 204 "protocol" as used in this document refers to the protocol used to 205 standardize the information exchange between Control Elements (CEs) 206 and Forwarding Elements (FEs) only. 208 The ForCES FE model [FE-MODEL] presents a formal way to define FE 209 Logical Function Blocks (LFBs) using XML. LFB configuration 210 components, capabilities, and associated events are defined when the 211 LFB is formally created. The LFBs within the FE are accordingly 212 controlled in a standardized way by the ForCES protocol. 214 This document defines the ForCES protocol specifications. The ForCES 215 protocol works in a master-slave mode in which FEs are slaves and CEs 216 are masters. The protocol includes commands for transport of Logical 217 Function Block (LFB) configuration information, association setup, 218 status, and event notifications, etc. 220 Section 3 provides a glossary of terminology used in the 221 specification. 223 Section 4 provides an overview of the protocol, including a 224 discussion on the protocol framework, descriptions of the Protocol 225 Layer (PL) and a Transport Mapping Layer (TML), as well as of the 226 ForCES protocol mechanisms. Section 4.4 describes several Protocol 227 scenarios and includes message exchange descriptions. 229 While this document does not define the TML, Section 5 details the 230 services that a TML MUST provide (TML requirements). 232 The ForCES protocol defines a common header for all protocol 233 messages. The header is defined in Section 6.1, while the protocol 234 messages are defined in Section 7. 236 Section 8 describes the protocol support for high availability 237 mechanisms including redundancy and fail over. 239 Section 9 defines the security mechanisms provided by the PL and TML. 241 3. Definitions 243 This document follows the terminology defined by the ForCES 244 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 245 The definitions below are repeated below for clarity. 247 Addressable Entity (AE) - A physical device that is directly 248 addressable given some interconnect technology. For example, on IP 249 networks, it is a device which can be reached using an IP address; 250 and on a switch fabric, it is a device which can be reached using a 251 switch fabric port number. 253 Control Element (CE) - A logical entity that implements the ForCES 254 protocol and uses it to instruct one or more FEs on how to process 255 packets. CEs handle functionality such as the execution of control 256 and signaling protocols. 258 CE Manager (CEM) - A logical entity responsible for generic CE 259 management tasks. It is particularly used during the pre-association 260 phase to determine with which FE(s) a CE should communicate. This 261 process is called FE discovery and may involve the CE manager 262 learning the capabilities of available FEs. 264 Datapath - A conceptual path taken by packets within the forwarding 265 plane inside an FE. 267 Forwarding Element (FE) - A logical entity that implements the ForCES 268 protocol. FEs use the underlying hardware to provide per-packet 269 processing and handling as directed/controlled by one or more CEs via 270 the ForCES protocol. 272 FE Model - A model that describes the logical processing functions of 273 an FE. The FE model is defined using Logical Function Blocks (LFBs). 275 FE Manager (FEM) - A logical entity responsible for generic FE 276 management tasks. It is used during pre-association phase to 277 determine with which CE(s) an FE should communicate. This process is 278 called CE discovery and may involve the FE manager learning the 279 capabilities of available CEs. An FE manager may use anything from a 280 static configuration to a pre-association phase protocol (see below) 281 to determine which CE(s) to use. Being a logical entity, an FE 282 manager might be physically combined with any of the other logical 283 entities such as FEs. 285 ForCES Network Element (NE) - An entity composed of one or more CEs 286 and one or more FEs. To entities outside an NE, the NE represents a 287 single point of management. Similarly, an NE usually hides its 288 internal organization from external entities. 290 High Touch Capability - This term will be used to apply to the 291 capabilities found in some forwarders to take action on the contents 292 or headers of a packet based on content other than what is found in 293 the IP header. Examples of these capabilities include quality of 294 service policies, virtual private networks, firewall, and L7 content 295 recognition. 297 Inter-FE Topology - See FE Topology. 299 Intra-FE Topology - See LFB Topology. 301 LFB (Logical Function Block) - The basic building block that is 302 operated on by the ForCES protocol. The LFB is a well defined, 303 logically separable functional block that resides in an FE and is 304 controlled by the CE via ForCES protocol. The LFB may reside at the 305 FE's datapath and process packets or may be purely an FE control or 306 configuration entity that is operated on by the CE. Note that the 307 LFB is a functionally accurate abstraction of the FE's processing 308 capabilities, but not a hardware-accurate representation of the FE 309 implementation. 311 FE Topology - A representation of how the multiple FEs within a 312 single NE are interconnected. Sometimes this is called inter-FE 313 topology, to be distinguished from intra-FE topology (i.e., LFB 314 topology). 316 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. An 317 LFB Instance represents an LFB Class (or Type) existence. There may 318 be multiple instances of the same LFB Class (or Type) in an FE. An 319 LFB Class is represented by an LFB Class ID, and an LFB Instance is 320 represented by an LFB Instance ID. As a result, an LFB Class ID 321 associated with an LFB Instance ID uniquely specifies an LFB 322 existence. 324 LFB Metadata - Metadata is used to communicate per-packet state from 325 one LFB to another, but is not sent across the network. The FE model 326 defines how such metadata is identified, produced and consumed by the 327 LFBs. It defines the functionality but not how metadata is encoded 328 within an implementation. 330 LFB Attribute - Operational parameters of the LFBs that must be 331 visible to the CEs are conceptualized in the FE model as the LFB 332 attributes. The LFB attributes include, for example, flags, single 333 parameter arguments, complex arguments, and tables that the CE can 334 read and/or write via the ForCES protocol (see below). 336 LFB Topology - Representation of how the LFB instances are logically 337 interconnected and placed along the datapath within one FE. 339 Sometimes it is also called intra-FE topology, to be distinguished 340 from inter-FE topology. 342 Pre-association Phase - The period of time during which an FE Manager 343 and a CE Manager are determining which FE(s) and CE(s) should be part 344 of the same network element. 346 Post-association Phase - The period of time during which an FE knows 347 which CE is to control it and vice versa. This includes the time 348 during which the CE and FE are establishing communication with one 349 another. 351 ForCES Protocol - While there may be multiple protocols used within 352 the overall ForCES architecture, the term "ForCES protocol" and 353 "protocol" refer to the Fp reference points in the ForCES Framework 354 in [RFC3746]. This protocol does not apply to CE-to-CE 355 communication, FE-to-FE communication, or to communication between FE 356 and CE managers. Basically, the ForCES protocol works in a master- 357 slave mode in which FEs are slaves and CEs are masters. This 358 document defines the specifications for this ForCES protocol. 360 ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol 361 architecture that defines the ForCES protocol messages, the protocol 362 state transfer scheme, as well as the ForCES protocol architecture 363 itself (including requirements of ForCES TML as shown below). 364 Specifications of ForCES PL are defined by this document. 366 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 367 ForCES protocol architecture that uses the capabilities of existing 368 transport protocols to specifically address protocol message 369 transportation issues, such as how the protocol messages are mapped 370 to different transport media (like TCP, IP, ATM, Ethernet, etc), and 371 how to achieve and implement reliability, multicast, ordering, etc. 372 The ForCES TML specifications are detailed in separate ForCES 373 documents, one for each TML. 375 4. Overview 377 The reader is referred to the Framework document [RFC3746], and in 378 particular sections 3 and 4, for an architectural overview and an 379 explanation of how the ForCES protocol fits in. There may be some 380 content overlap between the framework document and this section in 381 order to provide clarity. This document is authoritative on the 382 protocol whereas [RFC3746] is authoritative on the architecture. 384 4.1. Protocol Framework 386 Figure 1 below is reproduced from the Framework document for clarity. 387 It shows a NE with two CEs and two FEs. 389 --------------------------------------- 390 | ForCES Network Element | 391 -------------- Fc | -------------- -------------- | 392 | CE Manager |---------+-| CE 1 |------| CE 2 | | 393 -------------- | | | Fr | | | 394 | | -------------- -------------- | 395 | Fl | | | Fp / | 396 | | Fp| |----------| / | 397 | | | |/ | 398 | | | | | 399 | | | Fp /|----| | 400 | | | /--------/ | | 401 -------------- Ff | -------------- -------------- | 402 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 403 -------------- | | |------| | | 404 | -------------- -------------- | 405 | | | | | | | | | | 406 ----+--+--+--+----------+--+--+--+----- 407 | | | | | | | | 408 | | | | | | | | 409 Fi/f Fi/f 411 Fp: CE-FE interface 412 Fi: FE-FE interface 413 Fr: CE-CE interface 414 Fc: Interface between the CE Manager and a CE 415 Ff: Interface between the FE Manager and an FE 416 Fl: Interface between the CE Manager and the FE Manager 417 Fi/f: FE external interface 419 Figure 1: ForCES Architectural Diagram 421 The ForCES protocol domain is found in the Fp Reference Points. The 422 Protocol Element configuration reference points, Fc and Ff also play 423 a role in the booting up of the ForCES Protocol. The protocol 424 element configuration (indicated by reference points Fc, Ff, and Fl 425 in [RFC3746] ) is out of scope of the ForCES protocol but is touched 426 on in this document in discussion of FEM and CEM since it is an 427 integral part of the protocol pre-association phase. 429 Figure 2 below shows further breakdown of the Fp interfaces by means 430 of the example of an MPLS QoS enabled Network Element. 432 ------------------------------------------------- 433 | | | | | | | 434 |OSPF |RIP |BGP |RSVP |LDP |. . . | 435 | | | | | | | 436 ------------------------------------------------- CE 437 | ForCES Interface | 438 ------------------------------------------------- 439 ^ ^ 440 | | 441 ForCES | |data 442 control | |packets 443 messages| |(e.g., routing packets) 444 | | 445 v v 446 ------------------------------------------------- 447 | ForCES Interface | 448 ------------------------------------------------- FE 449 | | | | | | | 450 |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | 451 | | | | |fier | | 452 ------------------------------------------------- 454 Figure 2: Examples of CE and FE functions 456 The ForCES Interface shown in Figure 2 constitutes two pieces: the PL 457 and the TML. 459 This is depicted in Figure 3 below. 461 +------------------------------------------------ 462 | CE PL | 463 +------------------------------------------------ 464 | CE TML | 465 +------------------------------------------------ 466 ^ 467 | 468 ForCES | (i.e ForCES data + control 469 PL | packets ) 470 messages | 471 over | 472 specific | 473 TML | 474 encaps | 475 and | 476 transport | 477 | 478 v 479 +------------------------------------------------ 480 | FE TML | 481 +------------------------------------------------ 482 | FE PL | 483 +------------------------------------------------ 485 Figure 3: ForCES Interface 487 The PL is in fact the ForCES protocol. Its semantics and message 488 layout are defined in this document. The TML Layer is necessary to 489 connect two ForCES PLs as shown in Figure 3 above. The TML is out of 490 scope for this document but is within scope of ForCES. This document 491 defines requirements the PL needs the TML to meet. 493 Both the PL and the TML are standardized by the IETF. While only one 494 PL is defined, different TMLs are expected to be standardized. To 495 interoperate the TML at the CE and FE are expected to conform to the 496 same definition. 498 On transmit, the PL delivers its messages to the TML. The local TML 499 delivers the message to the destination TML. On receive, the TML 500 delivers the message to its destination PL. 502 4.1.1. The PL 504 The PL is common to all implementations of ForCES and is standardized 505 by the IETF as defined in this document. The PL is responsible for 506 associating an FE or CE to an NE. It is also responsible for tearing 507 down such associations. An FE uses the PL to transmit various 508 subscribed-to events to the CE PL as well as to respond to various 509 status requests issued from the CE PL. The CE configures both the FE 510 and associated LFBs' operational parameters using the PL. In 511 addition the CE may send various requests to the FE to activate or 512 deactivate it, reconfigure its HA parameterization, subscribe to 513 specific events etc. More details can be found in Section 7. 515 4.1.2. The TML 517 The TML transports the PL messages. The TML is where the issues of 518 how to achieve transport level reliability, congestion control, 519 multicast, ordering, etc. are handled. It is expected that more than 520 one TML will be standardized. The various possible TMLs could vary 521 their implementations based on the capabilities of underlying media 522 and transport. However, since each TML is standardized, 523 interoperability is guaranteed as long as both endpoints support the 524 same TML. All ForCES Protocol Layer implementations MUST be portable 525 across all TMLs, because all TMLs MUST have the top edge semantics 526 defined in this document. 528 4.1.3. The FEM/CEM Interface 530 The FEM and CEM components, although valuable in the setup and 531 configurations of both the PL and TML, are out of scope of the ForCES 532 protocol. The best way to think of them is as configurations/ 533 parameterizations for the PL and TML before they become active (or 534 even at runtime based on implementation). In the simplest case, the 535 FE or CE reads a static configuration file. RFC 3746 has a more 536 detailed description on how the FEM and CEM could be used. The pre- 537 association phase, where the CEM and FEM can be used, are described 538 briefly in Section 4.2.1. 540 An example of typical things the FEM/CEM could configure would be TML 541 specific parameterizations such as: 543 a. How the TML connection should happen (for example what IP 544 addresses to use, transport modes etc); 546 b. The ID for the FE (FEID) or CE (CEID) (which would also be issued 547 during the pre-association phase). 549 c. Security parameterization such as keys etc. 551 d. Connection association parameters 553 Example of connection association parameters this might be: 555 o simple parameters: send up to 3 association messages every 1 556 second 558 o complex parameters: send up to 4 association messages with 559 increasing exponential timeout 561 4.2. ForCES Protocol Phases 563 ForCES, in relation to NEs, involves two phases: the pre-association 564 phase, where configuration/initialization/bootup of the TML and PL 565 layer happens, and the post-association phase where the ForCES 566 protocol operates to manipulate the parameters of the FEs. 568 CE sends Association Setup 569 +---->--->------------>---->---->---->------->----+ 570 | Y 571 ^ | 572 | Y 573 +---+-------+ +-------------+ 574 |FE Pre- | | FE Post- | 575 |Association| CE sends Association Teardown | Association | 576 |Phase |<------- <------<-----<------<-------+ Phase | 577 | | | | 578 +-----------+ +-------------+ 579 ^ Y 580 | | 581 +-<---<------<-----<------<----<---------<------+ 582 FE loses association 584 Figure 4: The FE Protocol Phases 586 In the mandated case, once associated, the FE may forward packets 587 depending on the configuration of its specific LFBs. An FE which is 588 associated to a CE will continue sending packets until it receives an 589 Association teardown message or until it loses association. An 590 unassociated FE MAY continue sending packets when it has a high 591 availability capability. The extra details are explained in 592 Section 8 and not discussed here to allow for a clear explanation of 593 the basics. 595 The FE state transitions are controlled by means of the FE Object LFB 596 FEState component, which is defined in [FE-MODEL] section 5.1 and 597 also explained in Section 7.3.2. 599 The FE initializes in the FEState OperDisable. When the FE is ready 600 to process packets in the data path it transitions itself to the 601 OperEnable state. 603 The CE may decide to pause the FE after it already came up as 604 OperEnable. It does this by setting the FEState to AdminDisable. 605 The FE stays in the AdminDisable state until it is explicitly 606 configured by the CE to transition to the OperEnable state. 608 When the FE loses its association with the CE it may go into the pre- 609 association phase depending on the programmed policy. For the FE to 610 properly complete the transition to the AdminDisable state, it MUST 611 stop Packet forwarding and this may impact multiple LFBS. How this 612 is achieved is outside the scope of this specification. 614 4.2.1. Pre-association 616 The ForCES interface is configured during the pre-association phase. 617 In a simple setup, the configuration is static and is typically read 618 from a saved configuration file. All the parameters for the 619 association phase are well known after the pre-association phase is 620 complete. A protocol such as DHCP may be used to retrieve the 621 configuration parameters instead of reading them from a static 622 configuration file. Note, this will still be considered static pre- 623 association. Dynamic configuration may also happen using the Fc, Ff 624 and Fl reference points (refer to [RFC3746]). Vendors may use their 625 own proprietary service discovery protocol to pass the parameters. 626 Essentially, only guidelines are provided here and the details are 627 left to the implementation. 629 The following are scenarios reproduced from the Framework Document to 630 show a pre-association example. 632 <----Ff ref pt---> <--Fc ref pt-------> 633 FE Manager FE CE Manager CE 634 | | | | 635 | | | | 636 (security exchange) (security exchange) 637 1|<------------>| authentication 1|<----------->|authentication 638 | | | | 639 (FE ID, components) (CE ID, components) 640 2|<-------------| request 2|<------------|request 641 | | | | 642 3|------------->| response 3|------------>|response 643 (corresponding CE ID) (corresponding FE ID) 644 | | | | 645 | | | | 647 Figure 5: Examples of a message exchange over the Ff and Fc reference 648 points 650 <-----------Fl ref pt--------------> | 652 FE Manager FE CE Manager CE 653 | | | | 654 | | | | 655 (security exchange) | | 656 1|<------------------------------>| | 657 | | | | 658 (a list of CEs and their components) | 659 2|<-------------------------------| | 660 | | | | 661 (a list of FEs and their components) | 662 3|------------------------------->| | 663 | | | | 664 | | | | 666 Figure 6: An example of a message exchange over the Fl reference 667 point 669 Before the transition to the association phase, the FEM will have 670 established contact with a CEM component. Initialization of the 671 ForCES interface will have completed, and authentication as well as 672 capability discovery may be complete. Both the FE and CE would have 673 the necessary information for connecting to each other for 674 configuration, accounting, identification, and authentication 675 purposes. To summarize, at the completion of this stage both sides 676 have all the necessary protocol parameters such as timers, etc. The 677 Fl reference point may continue to operate during the association 678 phase and may be used to force a disassociation of an FE or CE. The 679 specific interactions of the CEM and the FEM that are part of the 680 pre-association phase are out of scope; for this reason these details 681 are not discussed any further in this specification. The reader is 682 referred to the framework document [RFC3746] for a slightly more 683 detailed discussion. 685 4.2.2. Post-association 687 In this phase, the FE and CE components communicate with each other 688 using the ForCES protocol (PL over TML) as defined in this document. 689 There are three sub-phases: 691 o Association Setup Stage 693 o Established Stage 694 o Association Lost Stage 696 4.2.2.1. Association Setup Stage 698 The FE attempts to join the NE. The FE may be rejected or accepted. 699 Once granted access into the NE, capabilities exchange happens with 700 the CE querying the FE. Once the CE has the FE capability 701 information, the CE can offer an initial configuration (possibly to 702 restore state) and can query certain components within either an LFB 703 or the FE itself. 705 More details are provided in Section 4.4. 707 On successful completion of this stage, the FE joins the NE and is 708 moved to the Established Stage. 710 4.2.2.2. Established Stage 712 In this stage, the FE is continuously updated or queried. The FE may 713 also send asynchronous event notifications to the CE or synchronous 714 heartbeat notifications if programmed to do so. This stage continues 715 until a termination occurs, either due to loss of connectivity or due 716 to a termination initiated by either the CE or the FE. 718 Refer to the section on protocol scenarios, Section 4.4, for more 719 details. 721 4.2.2.3. Association Lost Stage 723 In this state, both or either the CE or FE declare the other side is 724 no longer associated. The disconnection could be initiated by either 725 party for administrative purposes but may also be driven by 726 operational reasons such as loss of connectivity. 728 A core LFB known as FE Protocol Object (FEPO) is defined (refer to 729 Appendix B and Section 7.3.1). FEPO defines various timers which can 730 be used in conjunction with traffic sensitive heartbeat mechanism 731 (Section 4.3.3) to detect loss of connectivity. 733 The loss of connectivity between TMLs does not indicate a loss of 734 association between respective PL layers. If the TML cannot repair 735 the transport loss before the programmed FEPO timer thresholds 736 associated with the FE is exceeded, then the association between the 737 respective PL layers will be lost. 739 FEPO defines several policies that can be programmed to define 740 behavior upon a detected loss of association. The FEPO's programmed 741 CE failover policy (refer to Section 8, Section 7.3.1, Section 4.3.3 742 and Appendix B) defines what takes place upon loss of association. 744 For this version of the protocol (as defined in this document), the 745 FE, upon re-association, MUST discard any state it has as invalid and 746 retrieve new state. This approach is motivated by a desire for 747 simplicity (as opposed to efficiency). 749 4.3. Protocol Mechanisms 751 Various semantics are exposed to the protocol users via the PL header 752 including: transaction capabilities, atomicity of transactions, two 753 phase commits, batching/parallelization, high availability and 754 failover as well as command pipelines. 756 The EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP 757 (Transaction Phase) flag as defined in the Common Header 758 (Section 6.1) are relevant to these mechanisms. 760 4.3.1. Transactions, Atomicity, Execution and Responses 762 In the master-slave relationship the CE instructs one or more FEs on 763 how to execute operations and how to report the results. 765 This section details the different modes of execution that a CE can 766 order the FE(s) to perform, as defined in Section 4.3.1.1. It also 767 describes the different modes a CE can ask the FE(s) to use for 768 formatting the responses after processing the operations as 769 requested. These modes relate to the transactional two phase 770 commitment operations. 772 4.3.1.1. Execution 774 There are 3 execution modes that can be requested for a batch of 775 operations spanning one or more LFB selectors (refer to 776 Section 7.1.5) in one protocol message. The EM flag defined in the 777 Common Header Section 6.1 selects the execution mode for a protocol 778 message, as below: 780 a. execute-all-or-none 782 b. continue-execute-on-failure 784 c. execute-until-failure 786 4.3.1.1.1. execute-all-or-none 788 When set to this mode of execution, independent operations in a 789 message MAY be targeted at one or more LFB selectors within an FE. 790 All these operations are executed serially and the FE MUST have no 791 execution failure for any of the operations. If any operation fails 792 to execute, then all the previous ones that have been executed prior 793 to the failure will need to be undone. I.e., there is rollback for 794 this mode of operation. 796 Refer to Section 4.3.1.2.2 for how this mode is used in cases of 797 transactions. In such a case, no operation is executed unless a 798 commit is issued by the CE. 800 Care should be taken on how this mode is used because a mis- 801 configuration could result in traffic losses. To add certainty to 802 the success of an operation, one should use this mode in a 803 transactional operation as described in Section 4.3.1.2.2 805 4.3.1.1.2. continue-execute-on-failure 807 If several independent operations are targeted at one or more LFB 808 selectors, execution continues for all operations at the FE even if 809 one or more operations fail. 811 4.3.1.1.3. execute-until-failure 813 In this mode all operations are executed on the FE sequentially until 814 the first failure. The rest of the operations are not executed but 815 operations already completed are not undone. I.e., there is no 816 rollback in this mode of operation. 818 4.3.1.2. Transaction and Atomicity 820 4.3.1.2.1. Transaction Definition 822 A transaction is defined as a collection of one or more ForCES 823 operations within one or more PL messages that MUST meet the ACIDity 824 properties [ACID], defined as: 826 Atomicity: In a transaction involving two or more discrete pieces 827 of information, either all of the pieces are committed 828 or none are. 830 Consistency: A transaction either creates a new and valid state of 831 data, or, if any failure occurs, returns all data to the 832 state it was in before the transaction was started. 834 Isolation: A transaction in process and not yet committed MUST 835 remain isolated from any other transaction. 837 Durability: Committed data is saved by the system such that, even in 838 the event of a failure and a system restart, the data is 839 available in its correct state. 841 There are cases where the CE knows exact memory and implementation 842 details of the FE such as in the case of an FE-CE pair from the same 843 vendor where the FE-CE pair is tightly coupled. In such a case, the 844 transactional operations may be simplified further by extra 845 computation at the CE. This view is not discussed further other than 846 to mention that it is not disallowed. 848 As defined above, a transaction is always atomic and MAY be 850 a. Within an FE alone 851 Example: updating multiple tables that are dependent on each 852 other. If updating one fails, then any that were already updated 853 MUST be undone. 855 b. Distributed across the NE 856 Example: updating table(s) that are inter-dependent across 857 several FEs (such as L3 forwarding related tables). 859 4.3.1.2.2. Transaction Protocol 861 By use of the execute mode, as defined in Section 4.3.1.1, the 862 protocol has provided a mechanism for transactional operations within 863 one stand-alone message. The 'execute-all-or-none' mode can meet the 864 ACID requirements. 866 For transactional operations of multiple messages within one FE or 867 across FEs, a classical transactional protocol known as Two Phase 868 Commit (2PC) [2PCREF] is supported by the protocol to achieve the 869 transactional operations utilizing Config messages (Section 7.6.1). 871 The COMMIT and TRCOMP operations in conjunction with the AT and the 872 TP flags in Common Header (Section 6.1) are provided for 2PC-based 873 transactional operations spanning multiple messages. 875 The AT flag, when set, indicates this message belongs to an Atomic 876 Transaction. All messages for a transaction operation MUST have the 877 AT flag set. If not set, it means the message is a stand-alone 878 message and does not participate in any transaction operation that 879 spans multiple messages. 881 The TP flag indicates the Transaction Phase this message belongs to. 883 There are four (4) possible phases for an transactional operation 884 known as: 886 SOT (Start of Transaction) 888 MOT (Middle of Transaction) 890 EOT (End of Transaction) 892 ABT (Abort) 894 The COMMIT operation is used by the CE to signal to the FE(s) to 895 commit a transaction. When used with an ABT TP flag, the COMMIT 896 operation signals the FE(s) to rollback (i.e un-COMMIT) a previously 897 committed transaction. 899 The TRCOMP operation is a small addition to the classical 2PC 900 approach. TRCOMP is sent by the CE to signal the FE(s) that the 901 transaction they have COMMITed is now over. This allows the FE(s) an 902 opportunity to clear state they may have kept around to perform a 903 rollback (if it became necessary). 905 A transaction operation is started with a message in which the TP 906 flag is set to Start of Transaction (SOT). Multi-part messages, 907 after the first one, are indicated by the Middle of Transaction flag 908 (MOT). All messages from the CE MUST set the AlwaysACK flag 909 (Section 6) to solicit responses from the FE(s). 911 Before the CE issues a commit (described further below) the FE MUST 912 only validate that the operation can be executed but not execute it. 914 Any failure notified by an FE causes the CE to abort the 915 transaction on all FEs involved in the transaction. This is 916 achieved by sending a Config message with an ABT flag and a COMMIT 917 operation. 919 If there are no failures by any participating FE, the transaction 920 commitment phase is signaled from the CE to the FE by an End of 921 Transaction (EOT) configuration message with a COMMIT operation. 923 The FE MUST respond to the CE's EOT message. There are two possible 924 failure scenarios in which the CE MUST abort the transaction (as 925 described above): 927 a. If any participating FE responds with a failure message in 928 relation to the transaction. 930 b. If no response is received from a participating FE within a 931 specified timeout. 933 If all participating FE(s) respond with a success indicator within 934 the expected time, then the CE MUST issue a TRCOMP operation to all 935 participating FEs. An FE MUST NOT respond to a TRCOMP. 937 Note that a transactional operation is generically atomic, therefore 938 it requires that the execute modes of all messages in a transaction 939 operation should always be kept the same and be set to 'execute-all- 940 or-none'. If the EM flag is set to other execute modes, it will 941 result in a transaction failure. 943 As noted above, a transaction may span multiple messages. It is up 944 to the CE to keep track of the different outstanding messages making 945 up a transaction. As an example, the correlator field could be used 946 to mark transactions and a sequence field to label the different 947 messages within the same atomic transaction, but this is out of scope 948 and up to implementations. 950 4.3.1.2.3. Recovery 952 Any of the participating FEs, or the CE, or the associations between 953 them, may fail after the EOT response message has been sent by the FE 954 but before the CE has received all the responses, e.g. if the EOT 955 response never reaches the CE. 957 In this protocol revision, as indicated in Section 4.2.2.3, an FE 958 losing an association would be required to get entirely new state 959 from the newly associated CE upon a re-association. Although this 960 approach is simplistic and provides likeliness of loosing datapath 961 traffic, it is a design choice to avoid the additional complexity of 962 managing graceful restarts. The HA mechanisms (Section 8) are 963 provided to allow for a continuous operation in case of FE failures. 965 Flexibility is provided on how to react when an FE looses 966 association. This is dictated by the CE Failover policy (refer to 967 Section 8 and Section 7.3). 969 4.3.1.2.4. Transaction Messaging Example 971 This section illustrates an example of how a successful two phase 972 commit between a CE and an FE would look like in the simple case. 974 FE PL CE PL 976 | | 977 | (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc | 978 |<-----------------------------------------------------| 979 | | 980 | (2) ACKnowledge | 981 |----------------------------------------------------->| 982 | | 983 | (3) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc | 984 |<-----------------------------------------------------| 985 | | 986 | (4) ACKnowledge | 987 |----------------------------------------------------->| 988 | | 989 | (5) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc | 990 |<-----------------------------------------------------| 991 | | 992 | (6) ACKnowledge | 993 |----------------------------------------------------->| 994 . . 995 . . 996 . . 997 . . 998 | | 999 | (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT | 1000 |<-----------------------------------------------------| 1001 | | 1002 | (N+1)Config-response, ACKnowledge, OP=COMMIT-RESPONSE| 1003 |----------------------------------------------------->| 1004 | | 1005 | (N+2) Config, OP=TRCOMP | 1006 |<-----------------------------------------------------| 1008 Figure 7: Example of a two phase commit 1010 For the scenario illustrated above: 1012 o In step #1, the CE issues a Config message with an operation of 1013 choice like a DEL or SET. The transactional flag are set to 1014 indicate a Start of Transaction (SOT), Atomic Transaction (AT), 1015 execute-all-or-none. 1017 o The FE validates that it can execute the request successfully and 1018 then issues an acknowledgment back to the the CE in step #2. 1020 o In step #3, the same sort of construct as in step #1 is repeated 1021 by the CE with the transaction flag changed to Middle of 1022 Transaction(MOT). 1024 o The FE validates that it can execute the request successfully and 1025 then issues an acknowledgment back to the the CE in step #4. 1027 o The CE-FE exchange continues in the same manner until all the 1028 operations and their parameters are transferred to the FE. This 1029 happens in step #(N-1). 1031 o In step #N, the CE issues a commit. A commit is a config message 1032 with an operation of type COMMIT. The transactional flags are set 1033 to End of Transaction (EOT). Essentially, this is an "empty" 1034 message asking the FE to execute all the operations it has 1035 gathered since the beginning of the transaction (message #1). 1037 o The FE at this point executes the full transaction. It then 1038 issues an acknowledgment back to the the CE in step #(N+1) which 1039 contains a COMMIT-RESPONSE. 1041 o The CE in this case has the simple task of issuing a TRCOMP 1042 operation the the FE in step #(N+2) 1044 4.3.2. Scalability 1046 It is desirable that the PL not become the bottleneck when larger 1047 bandwidth pipes become available. To pick a hypothetical example in 1048 today's terms, if a 100Gbps pipe is available and there is sufficient 1049 work then the PL should be able to take advantage of this and use all 1050 of the 100Gbps pipe. Two mechanisms have been provided to achieve 1051 this. The first one is batching and the second one is a command 1052 pipeline. 1054 Batching is the ability to send multiple commands (such as Config) in 1055 one Protocol Data Unit (PDU). The size of the batch will be affected 1056 by, amongst other things, the path MTU. The commands may be part of 1057 the same transaction or may be part of unrelated transactions that 1058 are independent of each other. 1060 Command pipelining allows for pipelining of independent transactions 1061 which do not affect each other. Each independent transaction could 1062 consist of one or more batches. 1064 4.3.2.1. Batching 1066 There are several batching levels at different protocol hierarchies. 1068 o multiple PL PDUs can be aggregated under one TML message 1069 o multiple LFB classes and instances (as indicated in the LFB 1070 selector) can be addressed within one PL PDU 1072 o Multiple operations can be addressed to a single LFB class and 1073 instance 1075 4.3.2.2. Command Pipelining 1077 The protocol allows any number of messages to be issued by the CE 1078 before the corresponding acknowledgments (if requested) have been 1079 returned by the FE. Hence pipelining is inherently supported by the 1080 protocol. Matching responses with requests messages can be done 1081 using the correlator field in the message header. 1083 4.3.3. Heartbeat Mechanism 1085 Heartbeats (HB) between FEs and CEs are traffic sensitive. An HB is 1086 sent only if no PL traffic is sent between the CE and FE within a 1087 configured interval. This has the effect of reducing the amount of 1088 HB traffic in the case of busy PL periods. 1090 An HB can be sourced by either the CE or FE. When sourced by the CE, 1091 a response can be requested (similar to the ICMP ping protocol). The 1092 FE can only generate HBs in the case of being configured to do so by 1093 the CE. Refer to Section 7.3.1 and Section 7.10 for details. 1095 4.3.4. FE Object and FE Protocol LFBs 1097 All PL messages operate on LFB constructs, as this provides more 1098 flexibility for future enhancements. This means that maintenance and 1099 configurability of FEs, NE, as well as the ForCES protocol itself 1100 MUST be expressed in terms of this LFB architecture. For this reason 1101 special LFBs are created to accommodate this need. 1103 In addition, this shows how the ForCES protocol itself can be 1104 controlled by the very same type of structures (LFBs) it uses to 1105 control functions such as IP forwarding, filtering, etc. 1107 To achieve this, the following specialized LFBs are introduced: 1109 o FE Protocol LFB which is used to control the ForCES protocol. 1111 o FE Object LFB which is used to control attributes relative to the 1112 FE itself. Such attributes include FEState [FE-MODEL], vendor, 1113 etc. 1115 These LFBs are detailed in Section 7.3. 1117 4.4. Protocol Scenarios 1119 This section provides a very high level description of sample message 1120 sequences between a CE and FE. For protocol message encoding refer 1121 to Section 6.1 and for the semantics of the protocol refer to 1122 Section 4.3. 1124 4.4.1. Association Setup State 1126 The associations among CEs and FEs are initiated via Association 1127 setup message from the FE. If a setup request is granted by the CE, 1128 a successful setup response message is sent to the FE. If CEs and 1129 FEs are operating in an insecure environment then the security 1130 associations have to be established between them before any 1131 association messages can be exchanged. The TML MUST take care of 1132 establishing any security associations. 1134 This is typically followed by capability query, topology query, etc. 1135 When the FE is ready to start processing the data path, it sets the 1136 FEO FEState component to OperEnable (Refer to [FE-MODEL] for details) 1137 and reports it to the CE as such when it is first queried. Typically 1138 the FE is expected to be ready to process the data path before it 1139 associates, but there maybe rare cases where it needs time do some 1140 pre-processing - in such a case the FE will start in the OperDisable 1141 state and when it is ready will transition to OperEnable state. An 1142 example of an FE starting in the OperDisable then transitioning to 1143 OperEnable is illustrated in Figure 8. The CE could at any time also 1144 disable the FEs datapath operations by setting the FEState to 1145 AdminDisable. The FE MUST NOT process packets during this state 1146 unless the CE sets the state back to OperEnable. These sequences of 1147 messages are illustrated in Figure 8 below. 1149 FE PL CE PL 1151 | | 1152 | Asso Setup Req | 1153 |---------------------->| 1154 | | 1155 | Asso Setup Resp | 1156 |<----------------------| 1157 | | 1158 | LFBx Query capability | 1159 |<----------------------| 1160 | | 1161 | LFBx Query Resp | 1162 |---------------------->| 1163 | | 1164 | FEO Query (Topology) | 1165 |<----------------------| 1166 | | 1167 | FEO Query Resp | 1168 |---------------------->| 1169 | | 1170 | FEO OperEnable Event | 1171 |---------------------->| 1172 | | 1173 | Config FEO Adminup | 1174 |<----------------------| 1175 | | 1176 | FEO Config-Resp | 1177 |---------------------->| 1178 | | 1180 Figure 8: Message exchange between CE and FE to establish an NE 1181 association 1183 On successful completion of this state, the FE joins the NE. 1185 4.4.2. Association Established state or Steady State 1187 In this state, the FE is continuously updated or queried. The FE may 1188 also send asynchronous event notifications to the CE, synchronous 1189 heartbeat messages, or packet redirect message to the CE. This 1190 continues until a termination (or deactivation) is initiated by 1191 either the CE or FE. Figure 9 below, helps illustrate this state. 1193 FE PL CE PL 1195 | | 1196 | Heart Beat | 1197 |<---------------------------->| 1198 | | 1199 | Heart Beat | 1200 |----------------------------->| 1201 | | 1202 | Config-set LFBy (Event sub.) | 1203 |<-----------------------------| 1204 | | 1205 | Config Resp LFBy | 1206 |----------------------------->| 1207 | | 1208 | Config-set LFBx Attr | 1209 |<-----------------------------| 1210 | | 1211 | Config Resp LFBx | 1212 |----------------------------->| 1213 | | 1214 |Config-Query LFBz (Stats) | 1215 |<--------------------------- -| 1216 | | 1217 | Query Resp LFBz | 1218 |----------------------------->| 1219 | | 1220 | FE Event Report | 1221 |----------------------------->| 1222 | | 1223 | Config-Del LFBx Attr | 1224 |<-----------------------------| 1225 | | 1226 | Config Resp LFBx | 1227 |----------------------------->| 1228 | | 1229 | Packet Redirect LFBx | 1230 |----------------------------->| 1231 | | 1232 | Heart Beat | 1233 |<-----------------------------| 1234 . . 1235 . . 1236 | | 1238 Figure 9: Message exchange between CE and FE during steady-state 1239 communication 1241 Note that the sequence of messages shown in the figure serve only as 1242 examples and the message exchange sequences could be different from 1243 what is shown in the figure. Also, note that the protocol scenarios 1244 described in this section do not include all the different message 1245 exchanges that would take place during failover. That is described 1246 in the HA section (Section 8) . 1248 5. TML Requirements 1250 The requirements below are expected to be met by the TML. This text 1251 does not define how such mechanisms are delivered. As an example, 1252 the mechanisms to meet the requirements could be defined to be 1253 delivered via hardware or between 2 or more TML software processes on 1254 different CEs or FEs in protocol level schemes. 1256 Each TML MUST describe how it contributes to achieving the listed 1257 ForCES requirements. If for any reason a TML does not provide a 1258 service listed below a justification needs to be provided. 1260 Implementations that support the ForCES Protocol Specification MUST 1261 IMPLEMENT [SCTP-TML]. Note that additional TMLs might be specified 1262 in the future, and if a new TML defined in the future that meets the 1263 requirements listed here proves to be better, then the MUST IMPLEMENT 1264 TML may redefined. 1266 1. Reliability 1268 Various ForCES messages will require varying degrees of reliable 1269 delivery via the TML. It is the TML's responsibility to provide 1270 these shades of reliability and describe how the different ForCES 1271 messages map to reliability. 1273 The most common level of reliability is what we refer to as 1274 strict or robust reliability in which we mean: no losses, 1275 corruption, or re-ordering of information being transported while 1276 ensuring message delivery in a timely fashion. 1278 Payloads such as configuration from a CE and its response from an 1279 FE are mission critical and must be delivered in a robust 1280 reliable fashion. Thus, for information of this sort, the TML 1281 MUST either provide built-in protocol mechanisms or use a 1282 reliable transport protocol for achieving robust/strict 1283 reliability. 1285 Some information or payloads, such as redirected packets or 1286 packet sampling, may not require robust reliability (can tolerate 1287 some degree of losses). For information of this sort, the TML 1288 could define to use a mechanism that is not strictly reliable 1289 (while conforming to other TML requirements such as congestion 1290 control). 1292 Some information or payloads, such as heartbeat packets that may 1293 prefer timeliness over reliable delivery. For information of 1294 this sort, the TML could define to use a mechanism that is not 1295 strictly reliable (while conforming to other TML requirements 1296 such as congestion control). 1298 2. Security 1299 TML provides security services to the ForCES PL. Because a 1300 ForCES PL is used to operate an NE, attacks designed to confuse, 1301 disable, or take information from a ForCES-based NE may be seen 1302 as a prime objective during a network attack. 1304 An attacker in a position to inject false messages into a PL 1305 stream can either affect the FE's treatment of the data path 1306 (example by falsifying control data reported as coming from the 1307 CE), or the CE itself (by modifying events or responses reported 1308 as coming from the FE); for this reason, CE and FE node 1309 authentication and TML Message authentication is important. 1311 The PL messages may also contain information of value to an 1312 attacker, including information about the configuration of the 1313 network, encryption keys and other sensitive control data, so 1314 care must be taken to confine their visibility to authorized user 1316 * The TML MUST provide a mechanism to authenticate ForCES CEs 1317 and FEs in order to prevent the participation of unauthorized 1318 CEs and unauthorized FEs in the control and data path 1319 processing of a ForCES NE. 1321 * The TML SHOULD provide a mechanism to ensure message 1322 authentication of PL data transferred from the CE to FE (and 1323 vice-versa) in order to prevent the injection of incorrect 1324 data into PL messages. 1326 * The TML SHOULD provide a mechanism to ensure the 1327 confidentiality of data transferred from the ForCES PL, in 1328 order to prevent disclosure of PL level information 1329 transported via the TML. 1331 The TML SHOULD provide these services by employing TLS or IPSEC. 1333 3. Congestion control 1334 The transport congestion control scheme used by the TML needs to 1335 be defined. The congestion control mechanism defined by the TML 1336 MUST prevent transport congestive collapse [RFC2914] on either 1337 the FE or CE side. 1339 4. Uni/multi/broadcast addressing/delivery, if any 1340 If there is any mapping between PL and TML level uni/multi/ 1341 broadcast addressing it needs to be defined. 1343 5. HA decisions 1344 It is expected that availability of transport links is the TML's 1345 responsibility. However, based upon its configuration, the PL 1346 may wish to participate in link failover schemes and therefore 1347 the TML MUST support this capability. 1348 Please refer to Section 8 for details. 1350 6. Encapsulations used 1351 Different types of TMLs will encapsulate the PL messages on 1352 different types of headers. The TML needs to specify the 1353 encapsulation used. 1355 7. Prioritization 1356 It is expected that the TML will be able to handle up to 8 1357 priority levels needed by the PL and will provide preferential 1358 treatment. 1360 While the TML needs to define how this is achieved, it should be 1361 noted that the requirement for supporting up to 8 priority levels 1362 does not mean that the underlying TML MUST be capable of 1363 providing up to 8 actual priority levels. In the event that the 1364 underlying TML layer does not have support for 8 priority levels, 1365 the supported priority levels should be divided between the 1366 available TML priority levels. For example, if the TML only 1367 supports 2 priority levels, the 0-3 could go in one TML priority 1368 level, while 4-7 could go in the other. 1370 The TML MUST NOT reorder config packets with the same priority. 1372 8. Node Overload Prevention 1374 The TML MUST define mechanisms it uses to help prevent node 1375 overload. 1377 Overload results in starvation of node compute cycles and/or 1378 bandwidth resources which reduces the operational capacity of a 1379 ForCES NE. NE node overload could be deliberately instigated by 1380 a hostile node to attack a ForCES NE and create a denial of 1381 service. It could also be created by a variety of other reasons 1382 such as large control protocol updates (eg BGP flaps) which 1383 consequently cause a high frequency of CE to FE table updates, HA 1384 failovers or component failures which migrate an FE or CE load 1385 overwhelming the new CE or FE, etc. Although the environment 1386 under which SIP and ForCES operate are different, [RFC5390] 1387 provides a good guide to generic node requirements one needs to 1388 guard for. 1390 A ForCES node CPU may be overwhelmed because the incoming packet 1391 rate is higher than it can keep up with - in such a case a nodes 1392 transport queues grow and transport congestion subsequently 1393 follows. A ForCES node CPU may also be adversely overloaded with 1394 very few packets i.e no transport congestion at all (eg a in a 1395 DOS attack against a table hashing algorithmn which overflows the 1396 table and/or keeps the CPU busy so it does not process other 1397 tasks) The TML node-overload solution specified MUST address both 1398 types of node overload scenarios. 1400 5.1. TML Parameterization 1402 It is expected that it should be possible to use a configuration 1403 reference point, such as the FEM or the CEM, to configure the TML. 1405 Some of the configured parameters may include: 1407 o PL ID 1409 o Connection Type and associated data. For example if a TML uses 1410 IP/TCP/UDP, then parameters such as TCP and UDP port and IP 1411 addresses need to be configured. 1413 o Number of transport connections 1415 o Connection capability, such as bandwidth, etc. 1417 o Allowed/supported connection QoS policy (or congestion control 1418 policy) 1420 6. Message Encapsulation 1422 All PL PDUs start with a common header [Section 6.1] followed by a 1423 one or more TLVs [Section 6.2] which may nest other TLVs 1424 [Section 6.2.1]. All fields are in network byte order. 1426 6.1. Common Header 1428 0 1 2 3 1429 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 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 |version| rsvd | Message Type | Length | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 | Source ID | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | Destination ID | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | Correlator[63:32] | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Correlator[31:0] | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | Flags | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 Figure 10: Common Header 1446 The message is 32 bit aligned. 1448 Version (4 bit): 1449 Version number. Current version is 1. 1451 rsvd (4 bit): 1452 Unused at this point. A receiver should not interpret this 1453 field. Senders MUST set it to zero and receivers MUST ignore 1454 this field. 1456 Message Type (8 bits): 1457 Commands are defined in Section 7. 1459 Length (16 bits): 1460 length of header + the rest of the message in DWORDS (4 byte 1461 increments). 1463 Source ID (32 bit): 1465 Dest ID (32 bit): 1467 * Each of the source and destination IDs are 32 bit IDs which 1468 are unique NE-wide and which identify the termination points 1469 of a ForCES PL message. 1471 * IDs allow multi/broad/unicast addressing with the following 1472 approach: 1474 a. A split address space is used to distinguish FEs from 1475 CEs. Even though in a large NE there are typically two 1476 or more orders of magnitude more FEs than CEs, the 1477 address space is split uniformly for simplicity. 1479 b. The address space allows up to 2^30 (over a billion) CEs 1480 and the same amount of FEs. 1482 0 1 2 3 1483 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 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 |TS | sub-ID | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 Figure 11: ForCES ID Format 1490 c. The 2 most significant bits called Type Switch (TS) are 1491 used to split the ID space as follows: 1493 TS Corresponding ID range Assignment 1494 -- ---------------------- ---------- 1495 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 1496 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 1497 0b10 0x80000000 to 0xBFFFFFFF reserved 1498 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16) 1499 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 1500 0b11 0xFFFFFFFD all CEs broadcast 1501 0b11 0xFFFFFFFE all FEs broadcast 1502 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast 1504 Figure 12: Type Switch ID Space 1506 * Multicast or broadcast IDs are used to group endpoints (such 1507 as CEs and FES). As an example one could group FEs in some 1508 functional group, by assigning a multicast ID. Likewise, 1509 subgroups of CEs that act, for instance, in a back-up mode 1510 may be assigned a multicast ID to hide them from the FE. 1512 + Multicast IDs can be used for both source or destination 1513 IDs. 1515 + Broadcast IDs can be used only for destination IDs. 1517 * This document does not discuss how a particular multicast ID 1518 is associated to a given group though it could be done via 1519 configuration process. The list of IDs an FE owns or is part 1520 of are listed on the FE Object LFB. 1522 Correlator (64 bits) 1523 This field is set by the CE to correlate ForCES Request Messages 1524 with the corresponding Response messages from the FE. 1525 Essentially it is a cookie. The correlator is handled 1526 transparently by the FE, i.e., for a particular Request message 1527 the FE MUST assign the same correlator value in the corresponding 1528 Response message. In the case where the message from the CE does 1529 not elicit a response, this field may not be useful. 1531 The correlator field could be used in many implementations 1532 specific ways by the CE. For example, the CE could split the 1533 correlator into a 32-bit transactional identifier and 32-bit 1534 message sequence identifier. Another example is a 64-bit pointer 1535 to a context block. All such implementation specific use of the 1536 correlator is outside the scope of this specification. 1538 It should be noted that the correlator is transmitted on the 1539 network as if it were a 64 bit unsigned integer with the leftmost 1540 or most significant octet (bits 63-56) transmitted first. 1542 Whenever the correlator field is not relevant, because no message 1543 is expected, the correlator field is set to 0. 1545 Flags(32 bits): 1546 Identified so far: 1548 0 1 2 3 1549 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 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | | | | | | | | 1552 |ACK| Pri |Rsr |EM |A|TP | Reserved | 1553 | | | vd. | |T| | | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 Figure 13: Header Flags 1557 - ACK: ACK indicator (2 bit) 1558 The ACK indicator flag is only used by the CE when sending a 1559 Config Message (Section 7.6.1) or a HB message (Section 7.10) 1560 to indicate to the message receiver whether or not a response 1561 is required by the sender. Note that for all other messages 1562 than the Config Message or the HB Message this flag MUST be 1563 ignored. 1565 The flag values are defined as below: 1567 'NoACK' (0b00) - to indicate that the message receiver 1568 MUST NOT send any response message back to this message 1569 sender. 1571 'SuccessACK'(0b01) - to indicate the message receiver 1572 MUST send a response message back only when the message 1573 has been successfully processed by the receiver. 1575 'FailureACK'(0b10) - to indicate the message receiver 1576 MUST send a response message back only when there is 1577 failure by the receiver in processing (executing) the 1578 message. In other words, if the message can be processed 1579 successfully, the sender will not expect any response 1580 from the receiver. 1582 'AlwaysACK' (0b11) - to indicate the message receiver 1583 MUST send a response message. 1585 Note that in above definitions, the term success implies a 1586 complete execution without any failure of the message. 1587 Anything else than a complete successful execution is defined 1588 as a failure for the message processing. As a result, for 1589 the execution modes (defined in Section 4.3.1.1) like 1590 execute-all-or-none, execute-until-failure, and continue- 1591 execute-on-failure, if any single operation among several 1592 operations in the same message fails, it will be treated as a 1593 failure and result in a response if the ACK indicator has 1594 been set to 'FailureACK' or 'AlwaysACK'. 1596 Also note that, other than in Config and HB Messages, 1597 requirements for responses of messages are all given in a 1598 default way rather than by ACK flags. The default 1599 requirements of these messages and the expected responses are 1600 summarized below. Detailed descriptions can be found in the 1601 individual message definitions: 1603 + Association Setup Message always expects a response. 1605 + Association Teardown Message, and Packet Redirect 1606 Message, never expect responses. 1608 + Query Message always expects a response. 1610 + Response message never expects further responses. 1612 - Pri: Priority (3 bits) 1613 ForCES protocol defines 8 different levels of priority (0-7). 1614 The priority level can be used to distinguish between 1615 different protocol message types as well as between the same 1616 message type. The higher the priority value, the more 1617 important the PDU is. For example, the REDIRECT packet 1618 message could have different priorities to distinguish 1619 between routing protocols packets and ARP packets being 1620 redirected from FE to CE. The Normal priority level is 1. 1621 The different priorities imply messages could be re-ordered; 1622 however, re-ordering is undesirable when it comes to a set of 1623 messages within a transaction and caution should be exercised 1624 to avoid this from happening. 1626 - EM: Execution Mode (2 bits) 1627 There are 3 execution modes refer to Section 4.3.1.1 for 1628 details. 1630 Reserved..................... (0b00) 1632 `execute-all-or-none` ....... (0b01) 1634 `execute-until-failure` ..... (0b10) 1636 `continue-execute-on-failure` (0b11) 1638 - AT: Atomic Transaction (1 bit) 1639 This flag indicates if the message is stand-alone message or 1640 one of multiple messages that belongs to 2PC transaction 1641 operations. See Section 4.3.1.2.2 for details. 1643 Stand-alone message ......... (0b0) 1644 2PC transaction message ..... (0b1) 1646 - TP: Transaction Phase (2 bits) 1647 A message from the CE to the FE within a transaction could be 1648 indicative of the different phases the transaction is in. 1649 Refer to Section 4.3.1.2.2 for details. 1651 SOT (start of transaction) ..... (0b00) 1653 MOT (Middle of transaction) .... (0b01) 1655 EOT (end of transaction) ........(0b10) 1657 ABT (abort) .....................(0b11) 1659 6.2. Type Length Value (TLV) Structuring 1661 TLVs are extensively used by the ForCES protocol. TLVs have some 1662 very nice properties which make them a good candidate for encoding 1663 the XML definitions of the LFB class model. These are: 1665 o Providing for binary type-value encoding that is close to the XML 1666 string tag-value scheme. 1668 o Allowing for fast generalized binary-parsing functions. 1670 o Allowing for forward and backward tag compatibility. This is 1671 equivalent to the XML approach i.e old applications can ignore new 1672 TLVs and newer applications can ignore older TLVs. 1674 0 1 2 3 1675 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 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | TLV Type | TLV Length | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | Value (Essentially the TLV Data) | 1680 ~ ~ 1681 ~ ~ 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 Figure 14: TLV Representation 1686 TLV Type (16): 1687 The TLV type field is two octets, and semantically 1688 indicates the type of data encapsulated within the 1689 TLV. 1691 TLV Length (16): 1692 The TLV length field is two octets, and includes the 1693 length of the TLV type (2 octets), TLV Length (2 1694 octets), and the length of the TLV data found in the 1695 value field, in octets. Note that this length is 1696 the actual length of the value, before any padding 1697 for alignment is added. 1699 TLV Value (variable): 1700 The TLV value field carries the data. For 1701 extensibility, the TLV value may in fact be a TLV. 1702 Padding is required when the length is not a 1703 multiple of 32 bits, and is the minimum number of 1704 octets required to bring the TLV to a multiple of 32 1705 bits. The length of the value before padding is 1706 indicated by the TLV Length field. Note: The value 1707 field could be empty which implies the minimal 1708 length a TLV could be is 4 (length of "T" field and 1709 length of "L" field). 1711 6.2.1. Nested TLVs 1713 TLV values can be other TLVs. This provides the benefits of protocol 1714 flexibility (being able to add new extensions by introducing new TLVs 1715 when needed). The nesting feature also allows for a conceptual 1716 optimization with the XML LFB definitions to binary PL representation 1717 (represented by nested TLVs). 1719 6.2.2. Scope of the T in TLV 1721 The "Type" values in the TLV are global in scope. This means that 1722 wherever TLVs occur in the PDU, a specific Type value refers to the 1723 same Type of TLV. This is a design choice that was made to ease 1724 debugging of the protocol. 1726 6.3. ILV 1728 A slight variation of the TLV known as the ILV. This sets the type 1729 ("T") to be a 32-bit local index that refers to a ForCES component 1730 ID. (refer to Section 6.4.1). 1732 The ILV length field is a 4 octet integer, and includes the length of 1733 the ILV type (4 octets), ILV Length (4 octets), and the length of the 1734 ILV data found in the value field, in octets. Note that, as in the 1735 case of the TLV, this length is the actual length of the value, 1736 before any padding for alignment is added. 1738 0 1 2 3 1739 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 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | Identifier | 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | Length | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 | Value | 1746 . . 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 Figure 15: ILV Representation 1751 It should be noted that the "I" values are of local scope and are 1752 defined by the data declarations from the LFB definition. Refer to 1753 Section 7.1.8 for discussions on usage of ILVs. 1755 6.4. Important Protocol encapsulations 1757 In this section, we review a few encapsulation concepts that are used 1758 by the ForCES protocol for its operations. 1760 We briefly re-introduce two concepts, Paths and Keys, from the model 1761 draft [FE-MODEL] in order to provide context. The reader is referred 1762 to [FE-MODEL] for a lot of the finer details. 1764 For readability reasons, we introduce the encapsulation schemes that 1765 are used to carry content in a protocol message, namely FULLDATA-TLV, 1766 SPARSEDATA-TLV, and RESULT-TLV. 1768 6.4.1. Paths 1770 The model draft [FE-MODEL] defines an XML-based language that allows 1771 for a formal definition of LFBs. This is similar to the relationship 1772 between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB 1773 and ASN.1 being analogous to the XML model language). Any entity 1774 that the CE configures on an FE MUST be formally defined in an LFB. 1775 These entities could be scalars (e.g., a 32-bit IPv4 address) or 1776 vectors (such as a nexthop table). Each entity within the LFB is 1777 given a numeric 32-bit identifier known as an "component id". This 1778 scheme allows the attribute to be "addressed" in a protocol 1779 construct. 1781 These addressable entities could be hierarchical (e.g., a table 1782 column or a cell within a table row). In order to address 1783 hierarchical data, the concept of a path is introduced by the model 1784 [FE-MODEL]. A path is a series of 32-bit component IDs which are 1785 typically presented in a dot-notation (e.g., 1.2.3.4). Section 1786 (Section 7) formally defines how paths are used to reference data 1787 that is being encapsulated within a protocol message. 1789 6.4.2. Keys 1791 The model draft [FE-MODEL] defines two ways to address table rows. 1792 The standard/common mechanism is to allow table rows to be referenced 1793 by a 32-bit index. The secondary mechanism is via Keys which allow 1794 for content addressing. An example key is a multi-field content key 1795 that uses the IP address and prefix length to uniquely reference an 1796 IPv4 routing table row. In essence, while the common scheme to 1797 address a table row is via its table index, a table row's path could 1798 be derived from a key. The KEYINFO-TLV (Section 7) is used to carry 1799 the data that is used to do the lookup. 1801 6.4.3. DATA TLVs 1803 Data from or to the FE is carried in two types of TLVs: FULLDATA-TLV 1804 and SPARSEDATA-TLV. Responses to operations executed by the FE are 1805 carried in RESULT-TLVs. 1807 In FULLDATA-TLV, the data is encoded in such a way that a receiver of 1808 such data, by virtue of being armed with knowledge of the path and 1809 the LFB definition, can infer or correlate the TLV "Value" contents. 1810 This is essentially an optimization that helps reduce the amount of 1811 description required for the transported data in the protocol 1812 grammar. Refer to Appendix C for an example of FULLDATA-TLVs. 1814 A number of operations in ForCES will need to reference optional data 1815 within larger structures. The SPARSEDATA-TLV encoding is provided to 1816 make it easier to encapsulate optionally appearing data components. 1817 Refer to Appendix C for an example of SPARSEDATA-TLV. 1819 RESULT-TLVs carry responses back from the FE based on a config issued 1820 by the CE. Refer to Appendix C for examples of RESULT-TLVs and 1821 Section 7.1.7 for layout. 1823 6.4.4. Addressing LFB entities 1825 Section 6.4.1 and Section 6.4.2 discuss how to target an entity 1826 within an LFB. However, the addressing mechanism used requires that 1827 an LFB type and instance is selected first. The LFB Selector is used 1828 to select an LFB type and instance being targeted. Section 1829 (Section 7) goes into more details; for our purpose, we illustrate 1830 this concept using Figure 16 below. More examples of layouts can be 1831 found reading further into the text (Example: Figure 21). 1833 main hdr (Message type: example "config") 1834 | 1835 | 1836 | 1837 +- T = LFBselect 1838 | 1839 +-- LFBCLASSID (unique per LFB defined) 1840 | 1841 | 1842 +-- LFBInstance (runtime configuration) 1843 | 1844 +-- T = An operation TLV describes what we do to an entity 1845 | //Refer to the OPER-TLV values enumerated below 1846 | //the TLVs that can be used for operations 1847 | 1848 | 1849 +--+-- one or more path encodings to target an entity 1850 | // Refer to the discussion on keys and paths 1851 | 1852 | 1853 +-- The associated data, if any, for the entity 1854 // Refer to discussion on FULL/SPARSE DATA TLVs 1856 Figure 16: Entity Addressing 1858 7. Protocol Construction 1860 A protocol layer PDU consists of a Common Header (defined in Section 1861 Section 6.1 ) and a message body. The Common Header is followed by a 1862 message-type-specific message body. Each message body is formed from 1863 one or more top-level TLVs. A top-level TLV may contain one or more 1864 sub-TLVs; these sub-TLVs are described in this document as OPER-TLVs, 1865 because they describe an operation to be done. 1867 +-------------+---------------+---------------------+---------------+ 1868 | Message | Top-Level TLV | OPER-TLV(s) | Reference | 1869 | Name | | | | 1870 +-------------+---------------+---------------------+---------------+ 1871 | Association | (LFBselect)* | REPORT | Section 7.5.2 | 1872 | Setup | | | | 1873 | | | | | 1874 | Association | ASRresult-TLV | none | Section 7.5.2 | 1875 | Setup | | | | 1876 | Response | | | | 1877 | | | | | 1878 | Association | ASTreason-TLV | none | Section 7.5.3 | 1879 | Teardown | | | | 1880 | | | | | 1881 | Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 | 1882 | | | DEL | COMMIT | | | 1883 | | | TRCOMP)+ | | 1884 | | | | | 1885 | Config | (LFBselect)+ | (SET-RESPONSE | | Section 7.6.2 | 1886 | Response | | SET-PROP-RESPONSE | | | 1887 | | | DEL-RESPONSE | | | 1888 | | | COMMIT-RESPONSE)+ | | 1889 | | | | | 1890 | Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 | 1891 | | | | | 1892 | Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 | 1893 | Response | | GET-PROP-RESPONSE)+ | | 1894 | | | | | 1895 | Event | LFBselect | REPORT | Section 7.8 | 1896 | Notifi- | | | | 1897 | cation | | | | 1898 | | | | | 1899 | Packet | REDIRECT-TLV | none | Section 7.9 | 1900 | Redirect | | | | 1901 | | | | | 1902 | Heartbeat | none | none | Section 7.10 | 1903 +-------------+---------------+---------------------+---------------+ 1905 Table 1 1907 The different messages are illustrated in Table 1. The different 1908 message type numerical values are defined in Appendix A.1. All the 1909 TLVs values are defined in Appendix A.2. 1911 An LFBselect TLV (refer to Section 7.1.5) contains the LFB Classid 1912 and LFB Instance being referenced as well as the OPER-TLV(s) being 1913 applied to that reference. 1915 Each type of OPER-TLV is constrained as to how it describes the paths 1916 and selectors of interest. The following BNF describes the basic 1917 structure of an OPER-TLV and Table 2 gives the details for each type 1919 OPER-TLV := 1*PATH-DATA-TLV 1920 PATH-DATA-TLV := PATH [DATA] 1921 PATH := flags IDcount IDs [SELECTOR] 1922 SELECTOR := KEYINFO-TLV 1923 DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / 1924 1*PATH-DATA-TLV 1925 KEYINFO-TLV := KeyID FULLDATA-TLV 1926 FULLDATA-TLV := encoded data component which may nest 1927 further FULLDATA-TLVs 1928 SPARSEDATA-TLV := encoded data that may have optionally 1929 appearing components 1930 RESULT-TLV := Holds result code and optional FULLDATA-TLV 1932 Figure 17: BNF of OPER-TLV 1934 o PATH-DATA-TLV identifies the exact component targeted and may have 1935 zero or more paths associated with it. The last PATH-DATA-TLV in 1936 the case of nesting of paths via the DATA construct in the case of 1937 SET, SET-PROP requests and GET-RESPONSE/GET-PROP-RESPONSE is 1938 terminated by encoded data or response in the form of either 1939 FULLDATA-TLV or SPARSEDATA-TLV or RESULT-TLV. 1941 o PATH provides the path to the data being referenced. 1943 * flags (16 bits) are used to further refine the operation to be 1944 applied on the Path. More on these later. 1946 * IDcount(16 bit): count of 32 bit IDs 1948 * IDs: zero or more 32bit IDs (whose count is given by IDcount) 1949 defining the main path. Depending on the flags, IDs could be 1950 field IDs only or a mix of field and dynamic IDs. Zero is used 1951 for the special case of using the entirety of the containing 1952 context as the result of the path. 1954 o SELECTOR is an optional construct that further defines the PATH. 1955 Currently, the only defined selector is the KEYINFO-TLV, used for 1956 selecting an array entry by the value of a key field. The 1957 presence of a SELECTOR is correct only when the flags also 1958 indicate its presence. A mismatch is a protocol format error. 1960 o A KEYINFO-TLV contains information used in content keying. 1962 * A KeyID is used in a KEYINFO-TLV. It indicates which key for 1963 the current array is being used as the content key for array 1964 entry selection. 1966 * The key's data is the data to look for in the array, in the 1967 fields identified by the key field. The information is encoded 1968 according to the rules for the contents of a FULLDATA-TLV, and 1969 represent the field or fields which make up the key identified 1970 by the KeyID. 1972 o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV or 1 1973 or more further PATH-DATA selection. FULLDATA-TLV and SPARSEDATA- 1974 TLV are only allowed on SET or SET-PROP requests, or on responses 1975 which return content information (GET-RESPONSE for example). 1976 PATH-DATA may be included to extend the path on any request. 1978 * Note: Nested PATH-DATA-TLVs are supported as an efficiency 1979 measure to permit common subexpression extraction. 1981 * FULLDATA-TLV and SPARSEDATA-TLV contain "the data" whose path 1982 has been selected by the PATH. Refer to Section 7.1 for 1983 details. 1985 * The following table summarizes the applicability and 1986 restrictions of the FULL/SPARSEDATA-TLVs and the RESULT-TLV to 1987 the OPER-TLVs. 1989 +-------------------+-------------------------------+---------------+ 1990 | OPER-TLV | DATA TLV | RESULT-TLV | 1991 +-------------------+-------------------------------+---------------+ 1992 | SET | (FULLDATA-TLV | | none | 1993 | | SPARSEDATA-TLV)+ | | 1994 | | | | 1995 | SET-PROP | (FULLDATA-TLV | | none | 1996 | | SPARSEDATA-TLV)+ | | 1997 | | | | 1998 | SET-RESPONSE | none | (RESULT-TLV)+ | 1999 | | | | 2000 | SET-PROP-RESPONSE | none | (RESULT-TLV)+ | 2001 | | | | 2002 | DEL | (FULLDATA-TLV | | none | 2003 | | SPARSEDATA-TLV)+ | | 2004 | | | | 2005 | DEL-RESPONSE | none | (RESULT-TLV)+ | 2006 | | | | 2007 | GET | none | none | 2008 | | | | 2009 | GET-PROP | none | none | 2010 | | | | 2011 | GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | 2012 | | | | 2013 | GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | 2014 | | | | 2015 | REPORT | (FULLDATA-TLV)+ | none | 2016 | | | | 2017 | COMMIT | none | none | 2018 | | | | 2019 | COMMIT-RESPONSE | none | (RESULT-TLV)+ | 2020 | | | | 2021 | TRCOMP | none | none | 2022 +-------------------+-------------------------------+---------------+ 2024 Table 2 2026 o RESULT-TLV contains the indication of whether the individual SET 2027 or SET-PROP succeeded. RESULT-TLV is included on the assumption 2028 that individual parts of a SET request can succeed or fail 2029 separately. 2031 In summary this approach has the following characteristic: 2033 o There can be one or more LFB class ID and instance ID combination 2034 targeted in a message (batch) 2036 o There can one or more operations on an addressed LFB class ID/ 2037 instance ID combination (batch) 2039 o There can be one or more path targets per operation (batch) 2041 o Paths may have zero or more data values associated (flexibility 2042 and operation specific) 2044 It should be noted that the above is optimized for the case of a 2045 single LFB class ID and instance ID targeting. To target multiple 2046 instances within the same class, multiple LFBselects are needed. 2048 7.1. Discussion on encoding 2050 Section 6.4.3 discusses the two types of DATA encodings (FULLDATA-TLV 2051 and SPARSEDATA-TLV) and the justifications for their existence. In 2052 this section we explain how they are encoded. 2054 7.1.1. Data Packing Rules 2056 The scheme for encoding data used in this doc adheres to the 2057 following rules: 2059 o The Value ("V" of TLV) of FULLDATA-TLV will contain the data being 2060 transported. This data will be as was described in the LFB 2061 definition. 2063 o Variable sized data within a FULLDATA-TLV will be encapsulated 2064 inside another FULLDATA-TLV inside the V of the outer TLV. For 2065 example of such a setup refer to Appendix C and Appendix D 2067 o In the case of FULLDATA-TLVs: 2069 * When a table is referred to in the PATH (IDs) of a PATH-DATA- 2070 TLV, then the FULLDATA-TLV's "V" will contain that table's row 2071 content prefixed by its 32 bit index/subscript. On the other 2072 hand, when PATH flags are 00, the PATH may contain an index 2073 pointing to a row in table; in such a case, the FULLDATA-TLV's 2074 "V" will only contain the content with the index in order to 2075 avoid ambiguity. 2077 7.1.2. Path Flags 2079 The following flags are currently defined: 2081 o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present 2082 following this path information, and should be considered in 2083 evaluating the path. 2085 7.1.3. Relation of operational flags with global message flags 2087 Global flags, such as the execution mode and the atomicity indicators 2088 defined in the header, apply to all operations in a message. Global 2089 flags provide semantics that are orthogonal to those provided by the 2090 operational flags, such as the flags defined in Path Data. The scope 2091 of operational flags is restricted to the operation. 2093 7.1.4. Content Path Selection 2095 The KEYINFO-TLV describes the KEY as well as associated KEY data. 2096 KEYs, used for content searches, are restricted and described in the 2097 LFB definition. 2099 7.1.5. LFBselect-TLV 2101 The LFBselect TLV is an instance of a TLV as defined in Section 6.2. 2102 The definition is as below: 2104 0 1 2 3 2105 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 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | Type = LFBselect | Length | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | LFB Class ID | 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | LFB Instance ID | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | OPER-TLV | 2114 . . 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 ~ ... ~ 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | OPER-TLV | 2119 . . 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 Figure 18: PL PDU layout 2124 Type: 2125 The type of the TLV is "LFBselect" 2127 Length: 2128 Length of the TLV including the T and L fields, in octets. 2130 LFB Class ID: 2131 This field uniquely recognizes the LFB class/type. 2133 LFB Instance ID: 2134 This field uniquely identifies the LFB instance. 2136 OPER-TLV: 2137 It describes an operation nested in the LFBselect TLV. Note that 2138 usually there SHOULD be at least one OPER-TLV present for an LFB 2139 select TLV, but for the Association Setup Message defined in 2140 Section 7.5.1 where the OPER-TLV is optional. 2142 7.1.6. OPER-TLV 2144 The OPER-TLV is a place holder in the grammar for TLVs that define 2145 operations. The different types are defined in Table 3, below. 2147 +-------------------+--------+--------------------------------------+ 2148 | OPER-TLV | TLV | Comments | 2149 | | "Type" | | 2150 +-------------------+--------+--------------------------------------+ 2151 | SET | 0x0001 | From CE to FE. Used to create or | 2152 | | | add or update attributes | 2153 | | | | 2154 | SET-PROP | 0x0002 | From CE to FE. Used to create or | 2155 | | | add or update attribute properties | 2156 | | | | 2157 | SET-RESPONSE | 0x0003 | From FE to CE. Used to carry | 2158 | | | response of a SET | 2159 | | | | 2160 | SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry | 2161 | | | response of a SET-PROP | 2162 | | | | 2163 | DEL | 0x0005 | From CE to FE. Used to delete or | 2164 | | | remove an attribute | 2165 | | | | 2166 | DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry | 2167 | | | response of a DEL | 2168 | | | | 2169 | GET | 0x0007 | From CE to FE. Used to retrieve an | 2170 | | | attribute | 2171 | | | | 2172 | GET-PROP | 0x0008 | From CE to FE. Used to retrieve an | 2173 | | | attribute property | 2174 | | | | 2175 | GET-RESPONSE | 0x0009 | From FE to CE. Used to carry | 2176 | | | response of a GET | 2177 | | | | 2178 | GET-PROP-RESPONSE | 0x000A | From FE to CE. Used to carry | 2179 | | | response of a GET-PROP | 2180 | | | | 2181 | REPORT | 0x000B | From FE to CE. Used to carry an | 2182 | | | asynchronous event | 2183 | | | | 2184 | COMMIT | 0x000C | From CE to FE. Used to issue a | 2185 | | | commit in a 2PC transaction | 2186 | | | | 2187 | COMMIT-RESPONSE | 0x000D | From an FE to CE. Used to confirm a | 2188 | | | commit in a 2PC transaction | 2189 | | | | 2190 | TRCOMP | 0x000E | From CE to FE. Used to indicate | 2191 | | | NE-wide success of 2PC transaction | 2192 +-------------------+--------+--------------------------------------+ 2194 Table 3 2196 Different messages define OPER-TLV are valid and how they are used 2197 (refer to Table 1 and Table 2). 2199 SET, SET-PROP, and GET/GET-PROP requests are issued by the CE and do 2200 not carry RESULT-TLVs. On the other hand, SET-RESPONSE, SET-PROP- 2201 RESPONSE and GET-RESPONSE/GET-PROP-RESPONSE carry RESULT-TLVs. 2203 A GET-RESPONSE in response to a successful GET will have FULLDATA- 2204 TLVs added to the leaf paths to carry the requested data. For GET 2205 operations that fail, instead of the FULLDATA-TLV there will be a 2206 RESULT-TLV. 2208 For a SET-RESPONSE/SET-PROP-RESPONSE, each FULLDATA-TLV or 2209 SPARSEDATA-TLV in the original request will be replaced with a 2210 RESULT-TLV in the response. If the request set the FailureACK flag, 2211 then only those items which failed will appear in the response. If 2212 the request was for AlwaysACK, then all components of the request 2213 will appear in the response with RESULT-TLVs. 2215 Note that if a SET/SET-PROP request with a structure in a FULLDATA- 2216 TLV is issued, and some field in the structure is invalid, the FE 2217 will not attempt to indicate which field was invalid, but rather will 2218 indicate that the operation failed. Note further that if there are 2219 multiple errors in a single leaf PATH-DATA/FULLDATA-TLB, the FE can 2220 select which error it chooses to return. So if a FULLDATA-TLV for a 2221 SET/SET-PROP of a structure attempts to write one field which is read 2222 only, and attempts to set another field to an invalid value, the FE 2223 can return indication of either error. 2225 A SET/SET-PROP operation on a variable length component with a length 2226 of 0 for the item is not the same as deleting it. If the CE wishes 2227 to delete then the DEL operation should be used whether the path 2228 refers to an array component or an optional structure component. 2230 7.1.7. RESULT TLV 2232 The RESULT-TLV is an instance of TLV defined in Section 6.2. The 2233 definition is as below: 2235 0 1 2 3 2236 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 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 | Type = RESULT-TLV | Length | 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 | Result Value | Reserved | 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 Figure 19: RESULT-TLV 2244 Defined Result Values 2246 +-----------------------------+-----------+-------------------------+ 2247 | Result Value | Value | Definition | 2248 +-----------------------------+-----------+-------------------------+ 2249 | E_SUCCESS | 0x00 | Success | 2250 | | | | 2251 | E_INVALID_HEADER | 0x01 | Unspecified error with | 2252 | | | header. | 2253 | | | | 2254 | E_LENGTH_MISMATCH | 0x02 | Header length field | 2255 | | | does not match actual | 2256 | | | packet length. | 2257 | | | | 2258 | E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch | 2259 | | | in versions. | 2260 | | | | 2261 | E_INVALID_DESTINATION_PID | 0x04 | Destination PID is | 2262 | | | invalid for the message | 2263 | | | receiver. | 2264 | | | | 2265 | E_LFB_UNKNOWN | 0x05 | LFB Class ID is not | 2266 | | | known by receiver. | 2267 | | | | 2268 | E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known | 2269 | | | by receiver but not | 2270 | | | currently in use. | 2271 | | | | 2272 | E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known | 2273 | | | but the specified | 2274 | | | instance of that class | 2275 | | | does not exist. | 2276 | | | | 2277 | E_INVALID_PATH | 0x08 | The specified path is | 2278 | | | impossible. | 2279 | | | | 2280 | E_COMPONENT_DOES_NOT_EXIST | 0x09 | The specified path is | 2281 | | | possible but the | 2282 | | | component does not | 2283 | | | exist (e.g., attempt to | 2284 | | | modify a table row that | 2285 | | | has not been created). | 2286 | | | | 2287 | E_EXISTS | 0x0A | The specified object | 2288 | | | exists but it cannot | 2289 | | | exist for the operation | 2290 | | | to succeed (e.g., | 2291 | | | attempt to add an | 2292 | | | existing LFB instance | 2293 | | | or array subscript). | 2294 | | | | 2295 | E_NOT_FOUND | 0x0B | The specified object | 2296 | | | does not exist but it | 2297 | | | MUST exist for the | 2298 | | | operation to succeed | 2299 | | | (e.g., attempt to | 2300 | | | delete a non-existing | 2301 | | | LFB instance or array | 2302 | | | subscript). | 2303 | | | | 2304 | E_READ_ONLY | 0x0C | Attempt to modify a | 2305 | | | read-only value. | 2306 | | | | 2307 | E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an | 2308 | | | array with an unallowed | 2309 | | | subscript. | 2310 | | | | 2311 | E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a | 2312 | | | parameter to a value | 2313 | | | outside of its | 2314 | | | allowable range. | 2315 | | | | 2316 | E_CONTENTS_TOO_LONG | 0x0D | Attempt to write | 2317 | | | contents larger than | 2318 | | | the target object space | 2319 | | | (i.e., exceeding a | 2320 | | | buffer). | 2321 | | | | 2322 | E_INVALID_PARAMETERS | 0x10 | Any other error with | 2323 | | | data parameters. | 2324 | | | | 2325 | E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not | 2326 | | | acceptable. | 2327 | | | | 2328 | E_INVALID_FLAGS | 0x12 | Message flags are not | 2329 | | | acceptable for the | 2330 | | | given message type. | 2331 | | | | 2332 | E_INVALID_TLV | 0x13 | A TLV is not acceptable | 2333 | | | for the given message | 2334 | | | type. | 2335 | E_EVENT_ERROR | 0x14 | Unspecified error while | 2336 | | | handling an event. | 2337 | | | | 2338 | E_NOT_SUPPORTED | 0x15 | Attempt to perform a | 2339 | | | valid ForCES operation | 2340 | | | that is unsupported by | 2341 | | | the message receiver. | 2342 | | | | 2343 | E_MEMORY_ERROR | 0x16 | A memory error occurred | 2344 | | | while processing a | 2345 | | | message (no error | 2346 | | | detected in the message | 2347 | | | itself) | 2348 | | | | 2349 | E_INTERNAL_ERROR | 0x17 | An unspecified error | 2350 | | | occurred while | 2351 | | | processing a message | 2352 | | | (no error detected in | 2353 | | | the message itself) | 2354 | | | | 2355 | - | 0x18-0xFE | Reserved | 2356 | | | | 2357 | E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for | 2358 | | | when the FE can not | 2359 | | | decide what went wrong) | 2360 +-----------------------------+-----------+-------------------------+ 2362 Table 4 2364 7.1.8. DATA TLV 2366 A FULLDATA-TLV has "T"= FULLDATA-TLV and a 16-bit Length followed by 2367 the data value/contents. Likewise, a SPARSEDATA-TLV has "T" = 2368 SPARSEDATA-TLV, a 16-bit Length, followed by the data value/contents. 2369 In the case of the SPARSEDATA-TLV, each component in the Value part 2370 of the TLV will be further encapsulated in an ILV. 2372 Below are the encoding rules for the FULLDATA-TLV and SPARSEDATA- 2373 TLVs. Appendix C is very useful in illustrating these rules: 2375 1. Both ILVs and TLVs MUST be 32 bit aligned. Any padding bits used 2376 for the alignment MUST be zero on transmission and MUST be 2377 ignored upon reception. 2379 2. FULLDATA-TLVs may be used at a particular path only if every 2380 component at that path level is present. In example 1(c) of 2381 Appendix C this concept is illustrated by the presence of all 2382 components of the structure S in the FULLDATA-TLV encoding. This 2383 requirement holds regardless of whether the fields are fixed or 2384 variable length, mandatory or optional. 2386 * If a FULLDATA-TLV is used, the encoder MUST lay out data for 2387 each component in the same order in which the data was 2388 defined in the LFB specification. This ensures the decoder 2389 is able to retrieve the data. To use the example 1 again in 2390 Appendix C, this implies the encoder/decoder is assumed to 2391 have knowledge of how structure S is laid out in the 2392 definition. 2394 * In the case of a SPARSEDATA-TLV, it does not need to be 2395 ordered since the "I" in the ILV uniquely identifies the 2396 component. Examples 1(a) and 1(b) in Appendix C illustrate 2397 the power of SPARSEDATA-TLV encoding. 2399 3. Inside a FULLDATA-TLV 2401 * The values for atomic, fixed-length fields are given without 2402 any TLV or ILV encapsulation. 2404 * The values for atomic, variable-length fields are given 2405 inside FULLDATA-TLVs. 2407 4. Inside a SPARSEDATA-TLV 2409 * The values for atomic fields may be given with ILVs (32-bit 2410 index, 32-bit length) 2412 5. Any of the FULLDATA-TLVs can contain an ILV but an ILV cannot 2413 contain a FULLDATA-TLV. This is because it is hard to 2414 disambiguate the ILV since an I is 32 bits and a T is 16 bits. 2416 6. A FULLDATA-TLV can also contain a FULLDATA-TLV for variable sized 2417 components. The decoding disambiguation is assumed from rule #3 2418 above. 2420 7.1.9. SET and GET Relationship 2422 It is expected that a GET-RESPONSE would satisfy the following: 2424 o It would have exactly the same path definitions as those sent in 2425 the GET. The only difference being a GET-RESPONSE will contain 2426 FULLDATA-TLVs. 2428 o It should be possible to take the same GET-RESPONSE and convert 2429 it to a SET successfully by merely changing the T in the 2430 operational TLV. 2432 o There are exceptions to this rule: 2434 1. When a KEY selector is used with a path in a GET operation, 2435 that selector is not returned in the GET-RESPONSE; instead 2436 the cooked result is returned. Refer to the examples using 2437 KEYS to see this. 2439 2. When dumping a whole table in a GET, the GET-RESPONSE that 2440 merely edits the T to be SET will end up overwriting the 2441 table. 2443 7.2. Protocol Encoding Visualization 2445 The figure below shows a general layout of the PL PDU. A main header 2446 is followed by one or more LFB selections each of which may contain 2447 one or more operation. 2449 main hdr (Config in this case) 2450 | 2451 | 2452 +--- T = LFBselect 2453 | | 2454 | +-- LFBCLASSID 2455 | | 2456 | | 2457 | +-- LFBInstance 2458 | | 2459 | +-- T = SET 2460 | | | 2461 | | +-- // one or more path targets 2462 | | // with their data here to be added 2463 | | 2464 | +-- T = DEL 2465 | . | 2466 | . +-- // one or more path targets to be deleted 2467 | 2468 | 2469 +--- T = LFBselect 2470 | | 2471 | +-- LFBCLASSID 2472 | | 2473 | | 2474 | +-- LFBInstance 2475 | | 2476 | + -- T= SET 2477 | | . 2478 | | . 2479 | + -- T= DEL 2480 | | . 2481 | | . 2482 | | 2483 | + -- T= SET 2484 | | . 2485 | | . 2486 | 2487 | 2488 +--- T = LFBselect 2489 | 2490 +-- LFBCLASSID 2491 | 2492 +-- LFBInstance 2493 . 2494 . 2495 . 2497 Figure 20: PL PDU logical layout 2499 The figure below shows a more detailed example of the general layout 2500 of the operation within a targeted LFB selection. The idea is to 2501 show the different nesting levels a path could take to get to the 2502 target path. 2504 T = SET 2505 | | 2506 | +- T = Path-data 2507 | | 2508 | + -- flags 2509 | + -- IDCount 2510 | + -- IDs 2511 | | 2512 | +- T = Path-data 2513 | | 2514 | + -- flags 2515 | + -- IDCount 2516 | + -- IDs 2517 | | 2518 | +- T = Path-data 2519 | | 2520 | + -- flags 2521 | + -- IDCount 2522 | + -- IDs 2523 | + -- T = KEYINFO-TLV 2524 | | + -- KEY_ID 2525 | | + -- KEY_DATA 2526 | | 2527 | + -- T = FULLDATA-TLV 2528 | + -- data 2529 | 2530 | 2531 T = SET 2532 | | 2533 | +- T = Path-data 2534 | | | 2535 | | + -- flags 2536 | | + -- IDCount 2537 | | + -- IDs 2538 | | | 2539 | | + -- T = FULLDATA-TLV 2540 | | + -- data 2541 | +- T = Path-data 2542 | | 2543 | + -- flags 2544 | + -- IDCount 2545 | + -- IDs 2546 | | 2547 | + -- T = FULLDATA-TLV 2548 | + -- data 2549 T = DEL 2550 | 2551 +- T = Path-data 2552 | 2553 + -- flags 2554 + -- IDCount 2555 + -- IDs 2556 | 2557 +- T = Path-data 2558 | 2559 + -- flags 2560 + -- IDCount 2561 + -- IDs 2562 | 2563 +- T = Path-data 2564 | 2565 + -- flags 2566 + -- IDCount 2567 + -- IDs 2568 + -- T = KEYINFO-TLV 2569 | + -- KEY_ID 2570 | + -- KEY_DATA 2571 +- T = Path-data 2572 | 2573 + -- flags 2574 + -- IDCount 2575 + -- IDs 2577 Figure 21: Sample operation layout 2579 Appendix D shows a more concise set of use-cases on how the data 2580 encoding is done. 2582 7.3. Core ForCES LFBs 2584 There are two LFBs that are used to control the operation of the 2585 ForCES protocol and to interact with FEs and CEs: 2587 o FE Protocol LFB 2588 o FE Object LFB 2590 Although these LFBs have the same form and interface as other LFBs, 2591 they are special in many respects. They have fixed well-known LFB 2592 Class and Instance IDs. They are statically defined (no dynamic 2593 instantiation allowed) and their status cannot be changed by the 2594 protocol: any operation to change the state of such LFBs (for 2595 instance, in order to disable the LFB) MUST result in an error. 2596 Moreover, these LFBs MUST exist before the first ForCES message can 2597 be sent or received. All attributes in these LFBs MUST have pre- 2598 defined default values. Finally, these LFBs do not have input or 2599 output ports and do not integrate into the intra-FE LFB topology. 2601 7.3.1. FE Protocol LFB 2603 The FE Protocol LFB is a logical entity in each FE that is used to 2604 control the ForCES protocol. The FE Protocol LFB Class ID is 2605 assigned the value 0x2. The FE Protocol LFB Instance ID is assigned 2606 the value 0x1. There MUST be one and only one instance of the FE 2607 Protocol LFB in an FE. The values of the attributes in the FE 2608 Protocol LFB have pre-defined default values that are specified here. 2609 Unless explicit changes are made to these values using Config 2610 messages from the CE, these default values MUST be used for correct 2611 operation of the protocol. 2613 The formal definition of the FE Protocol Object LFB can be found in 2614 Appendix B. 2616 7.3.1.1. FE Protocol capabilities 2618 FE Protocol capabilities are read-only. 2620 7.3.1.1.1. SupportableVersions 2622 ForCES protocol version(s) supported by the FE 2624 7.3.1.1.2. FE Protocol Attributes 2626 FE Protocol attributes (can be read and set). 2628 7.3.1.1.2.1. CurrentRunningVersion 2630 Current running version of the ForCES protocol 2632 7.3.1.1.2.2. FEID 2634 FE unicast ID 2636 7.3.1.1.2.3. MulticastFEIDs 2638 FE multicast ID(s) list - this is a list of multicast IDs that the FE 2639 belongs to. These IDs are configured by the CE. 2641 7.3.1.1.2.4. CEHBPolicy 2643 CE heartbeat policy - This policy, along with the parameter 'CE 2644 Heartbeat Dead Interval (CE HDI)' as described below defines the 2645 operating parameters for the FE to check the CE liveness. The policy 2646 values with meanings are listed as below: 2648 o 0 (default) - This policy specifies that the CE will send a 2649 Heartbeat Message to the FE(s) whenever the CE reaches a time 2650 interval within which no other PL messages were sent from the CE 2651 to the FE(s); refer to Section 4.3.3 and Section 7.10 for details. 2652 The CE HDI attribute as described below is tied to this policy. 2654 o 1 - The CE will not generate any HB messages. This actually means 2655 CE does not want the FE to check the CE liveness. 2657 o Others - reserved. 2659 7.3.1.1.2.5. CEHDI 2661 CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses 2662 to check the CE liveness. If FE has not received any messages from 2663 CE within this time interval, FE deduces lost connectivity which 2664 implies that the CE is dead or the association to the CE is lost. 2665 Default value 30 s. 2667 7.3.1.1.2.6. FEHBPolicy 2669 FE heartbeat policy - This policy, along with the parameter 'FE 2670 Heartbeat Interval (FE HI)', defines the operating parameters for how 2671 the FE should behave so that the CE can deduce its liveness. The 2672 policy values and the meanings are: 2674 o 0 (default) - The FE should not generate any Heartbeat messages. 2675 In this scenario, the CE is responsible for checking FE liveness 2676 by setting the PL header ACK flag of the message it sends to 2677 AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat 2678 Request Message. Refer to Section 7.10 and Section 4.3.3 for 2679 details. 2681 o 1 - This policy specifies that FE MUST actively send a Heartbeat 2682 Message if it reaches the time interval assigned by the FE HI as 2683 long as no other messages were sent from FE to CE during that 2684 interval as described in Section 4.3.3. 2686 o Others - Reserved. 2688 7.3.1.1.2.7. FEHI 2690 FE Heartbeat Interval (FE HI) - The time interval the FE should use 2691 to send HB as long as no other messages were sent from FE to CE 2692 during that interval as described in Section 4.3.3. The default 2693 value for an FE HI is 500ms. 2695 7.3.1.1.2.8. CEID 2697 Primary CEID - The CEID that the FE is associated with. 2699 7.3.1.1.2.9. LastCEID 2701 Last Primary CEID - The CEID of the last CE that that the FE 2702 associated with. This CE ID is reported to the new Primary CEID. 2704 7.3.1.1.2.10. BackupCEs 2706 The list of backup CEs an FE can use as backups. Refer to Section 8 2707 for details. 2709 7.3.1.1.2.11. CEFailoverPolicy 2711 CE failover policy - This specifies the behavior of the FE when the 2712 association with the CE is lost. There is a very tight relation 2713 between CE failover policy and Section 7.3.1.1.2.8, 2714 Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an 2715 association is lost, depending on configuration, one of the policies 2716 listed below is activated. 2718 o 0 (default) - FE should stop functioning immediately and 2719 transition to FE OperDisable. 2721 o 1 - The FE should continue running and do what it can even without 2722 an associated CE. This basically requires that the FE support CE 2723 Graceful restart (and defines such support in its capabilities). 2724 If the CEFTI expires before the FE re-associates with either the 2725 primary (Section 7.3.1.1.2.8) or one of possibly several backup 2726 CEs (Section 7.3.1.1.2.10), the FE will go operationally down. 2728 o Others - Reserved 2730 7.3.1.1.2.12. CEFTI 2732 CE Failover Timeout Interval (CEFTI) - The time interval associated 2733 with the CE failover policy case '0' and '2'. The default value is 2734 set to 300 seconds. Note that it is advisable to set the CEFTI value 2735 much higher than the CE Heartbeat Dead Interval (CE HDI) since the 2736 effect of expiring this parameter is devastating to the operation of 2737 the FE. 2739 7.3.1.1.2.13. FERestartPolicy 2741 FE restart policy - This specifies the behavior of the FE during an 2742 FE restart. The restart may be from an FE failure or other reasons 2743 that have made FE down and then need to restart. The values are 2744 defined as below: 2746 o 0(default)- Restart the FE from scratch. In this case, the FE 2747 should start from the pre-association phase. 2749 o others - Reserved for future use. 2751 7.3.2. FE Object LFB 2753 The FE Object LFB is a logical entity in each FE and contains 2754 attributes relative to the FE itself, and not to the operation of the 2755 ForCES protocol. 2757 The formal definition of the FE Object LFB can be found in 2758 [FE-MODEL]. The model captures the high level properties of the FE 2759 that the CE needs to know to begin working with the FE. The class ID 2760 for this LFB Class is also assigned in [FE-MODEL]. The singular 2761 instance of this class will always exist, and will always have 2762 instance ID 0x1 within its class. It is common, although not 2763 mandatory, for a CE to fetch much of the component and capability 2764 information from this LFB instance when the CE begins controlling the 2765 operation of the FE. 2767 7.4. Semantics of Message Direction 2769 Recall: The PL provides a master(CE)-Slave(FE) relationship. The 2770 LFBs reside at the FE and are controlled by CE. 2772 When messages go from the CE, the LFB Selector (Class and instance) 2773 refers to the destination LFB selection which resides in the FE. 2775 When messages go from the FE to the CE, the LFB Selector (Class and 2776 instance) refers to the source LFB selection which resides in the FE. 2778 7.5. Association Messages 2780 The ForCES Association messages are used to establish and teardown 2781 associations between FEs and CEs. 2783 7.5.1. Association Setup Message 2785 This message is sent by the FE to the CE to setup a ForCES 2786 association between them. 2788 Message transfer direction: 2789 FE to CE 2791 Message header: 2792 The Message Type in the header is set MessageType= 2793 'AssociationSetup'. The ACK flag in the header MUST be ignored, 2794 and the association setup message always expects to get a response 2795 from the message receiver (CE), whether the setup is successful or 2796 not. The correlator field in the header is set, so that FE can 2797 correlate the response coming back from the CE correctly. The FE 2798 may set the source ID to 0 in the header to request that the CE 2799 should assign an FE ID for the FE in the setup response message. 2801 Message body: 2802 The association setup message body optionally consists of zero, 2803 one or two LFBselect TLVs, as described in Section 7.1.5. The 2804 Association Setup message only operates on the FE Object and FE 2805 Protocol LFBs, therefore, the LFB class ID in the LFBselect TLV 2806 only points to these two kinds of LFBs. 2808 The OPER-TLV in the LFBselect TLV is defined as a 'REPORT' 2809 operation. More than one component may be announced in this 2810 message using REPORT operation to let the FE declare its 2811 configuration parameters in an unsolicited manner. These may 2812 contain components suggesting values such as the FE HB Interval, 2813 or the FEID. The OPER-TLV used is defined below. 2815 OPER-TLV for Association Setup: 2817 0 1 2 3 2818 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 2819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2820 | Type = REPORT | Length | 2821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2822 | PATH-DATA-TLV for REPORT | 2823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 Figure 22: OPER-TLV 2827 Type: 2828 Only one operation type is defined for the association setup 2829 message: 2831 Type = "REPORT" - this type of operation is for FE to 2832 report something to CE. 2834 PATH-DATA-TLV for REPORT: 2835 This is generically a PATH-DATA-TLV format that has been defined 2836 in section (Section 7) in the PATH-DATA BNF definition. The PATH- 2837 DATA-TLV for REPORT operation MAY contain FULLDATA-TLV(s) but 2838 SHALL NOT contain any RESULT-TLV in the data format. The RESULT- 2839 TLV is defined in Section 7.1.7 and the FULLDATA-TLV is defined in 2840 Section 7.1.8. 2842 To better illustrate the above PDU format, a tree structure for the 2843 format is shown below: 2845 main hdr (type = Association Setup) 2846 | 2847 | 2848 +--- T = LFBselect 2849 | | 2850 | +-- LFBCLASSID = FE object 2851 | | 2852 | | 2853 | +-- LFBInstance = 0x1 2854 | 2855 +--- T = LFBselect 2856 | 2857 +-- LFBCLASSID = FE Protocol object 2858 | 2859 | 2860 +-- LFBInstance = 0x1 2861 | 2862 +---OPER-TLV = REPORT 2863 | 2864 +-- Path-data to one or more components 2866 Figure 23: PDU Format For Association Setup Message 2868 7.5.2. Association Setup Response Message 2870 This message is sent by the CE to the FE in response to the Setup 2871 message. It indicates to the FE whether the setup is successful or 2872 not, i.e., whether an association is established. 2874 Message transfer direction: 2875 CE to FE 2877 Message Header: 2878 The Message Type in the header is set MessageType= 2879 'AssociationSetupResponse'. The ACK flag in the header MUST be 2880 ignored, and the setup response message never expects to get any 2881 more responses from the message receiver (FE). The destination 2882 ID in the header will be set to the source ID in the 2883 corresponding association setup message, unless that source ID 2884 was 0. If the corresponding source ID was 0, then the CE will 2885 assign an FE ID value and use that value for the destination ID. 2887 0 1 2 3 2888 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 2889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2890 | Type = ASRresult | Length | 2891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2892 | Association Setup Result | 2893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2895 Figure 24: ASResult OPER-TLV 2897 Type (16 bits): 2898 The type of the TLV is "ASResult". 2900 Length (16 bits): 2901 Length of the TLV including the T and L fields, in octets. 2903 Association Setup Result (32 bits): 2904 This indicates whether the setup msg was successful or whether 2905 the FE request was rejected by the CE. the defined values are: 2907 0 = success 2909 1 = FE ID invalid 2911 2 = permission denied 2913 To better illustrate the above PDU format, a tree structure for the 2914 format is shown below: 2916 main hdr (type = Association Setup Response) 2917 | 2918 | 2919 +--- T = ASResult-TLV 2921 Figure 25: PDU Format for Association Setup Repsonse Message 2923 7.5.3. Association Teardown Message 2925 This message can be sent by the FE or CE to any ForCES element to end 2926 its ForCES association with that element. 2928 Message transfer direction: 2929 CE to FE, or FE to CE (or CE to CE) 2931 Message Header: 2932 The Message Type in the header is set MessageType= 2933 "AssociationTeardown". The ACK flag MUST be ignored. The 2934 correlator field in the header MUST be set to zero and MUST be 2935 ignored by the receiver. 2937 0 1 2 3 2938 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 2939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2940 | Type = ASTreason | Length | 2941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2942 | Teardown Reason | 2943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 Figure 26: ASTreason-TLV 2947 Type (16 bits): 2948 The type of the TLV is "ASTreason". 2950 Length (16 bits): 2951 Length of the TLV including the T and L fields, in octets. 2953 Teardown Reason (32 bits): 2954 This indicates the reason why the association is being 2955 terminated. Several reason codes are defined as follows. 2957 0 - normal teardown by administrator 2959 1 - error - loss of heartbeats 2961 2 - error - out of bandwidth 2963 3 - error - out of memory 2965 4 - error - application crash 2967 255 - error - other or unspecified 2969 To better illustrate the above PDU format, a tree structure for the 2970 format is shown below: 2972 main hdr (type = Association Teardown) 2973 | 2974 | 2975 +--- T = ASTreason-TLV 2977 Figure 27: PDU Format for Association Teardown Message 2979 7.6. Configuration Messages 2981 The ForCES Configuration messages are used by CE to configure the FEs 2982 in a ForCES NE and report the results back to the CE. 2984 7.6.1. Config Message 2986 This message is sent by the CE to the FE to configure LFB components 2987 in the FE. This message is also used by the CE to subscribe/ 2988 unsubscribe to LFB events. 2990 As usual, a config message is composed of a common header followed by 2991 a message body that consists of one or more TLV data format. 2992 Detailed description of the message is as below. 2994 Message transfer direction: 2995 CE to FE 2997 Message Header: 2998 The Message Type in the header is set MessageType= 'Config'. The 2999 ACK flag in the header can be set to any value defined in 3000 Section 6.1, to indicate whether or not a response from FE is 3001 expected by the message. 3003 OPER-TLV for Config: 3005 0 1 2 3 3006 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 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3008 | Type | Length | 3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3010 | PATH-DATA-TLV | 3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3013 Figure 28: OPER-TLV for Config 3015 Type: 3016 The operation type for config message. two types of operations 3017 for the config message are defined: 3019 Type = "SET" - this operation is to set LFB components 3021 Type = "SET-PROP" - this operation is to set LFB component 3022 properties 3023 Type = "DEL" - this operation to delete some LFB 3024 components 3026 Type = "COMMIT" - this operation is sent to the FE to 3027 commit in a 2pc transaction. A COMMIT TLV is an empty TLV 3028 i.e it has no "V"alue. In other words, There is a Length 3029 of 4 (which is for the header only). 3031 Type = "TRCOMP" - this operation is sent to the FE to mark 3032 the success from an NE perspective of a 2pc transaction. 3033 A TRCOMP TLV is an empty TLV i.e it has no "V"alue. In 3034 other words, There is a Length of 4 (which is for the 3035 header only). 3037 PATH-DATA-TLV: 3038 This is generically a PATH-DATA-TLV format that has been defined 3039 in section (Section 7) in the PATH-DATA-TLV BNF definition. The 3040 restriction on the use of PATH-DATA-TLV for SET/SET-PROP 3041 operation is that it MUST contain either a FULLDATA-TLV or 3042 SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The 3043 restriction on the use of PATH-DATA-TLV for DEL operation is it 3044 MAY contain FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT 3045 contain any RESULT-TLV. The RESULT-TLV is defined in 3046 Section 7.1.7 and FULLDATA-TLV and SPARSEDATA-TLVs is defined in 3047 Section 7.1.8. 3049 *Note: For Event subscription, the events will be defined by the 3050 individual LFBs. 3052 To better illustrate the above PDU format, a tree structure for the 3053 format is shown below: 3055 main hdr (type = Config) 3056 | 3057 | 3058 +--- T = LFBselect 3059 . | 3060 . +-- LFBCLASSID = target LFB class 3061 . | 3062 | 3063 +-- LFBInstance = target LFB instance 3064 | 3065 | 3066 +-- T = operation { SET } 3067 | | 3068 | +-- // one or more path targets 3069 | // associated with FULLDATA-TLV or SPARSEDATA-TLV(s) 3070 | 3071 +-- T = operation { DEL } 3072 | | 3073 | +-- // one or more path targets 3074 | 3075 +-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV 3076 . 3077 . 3079 Figure 29: PDU Format for Configuration Message 3081 7.6.2. Config Response Message 3083 This message is sent by the FE to the CE in response to the Config 3084 message. It indicates whether the Config was successful or not on 3085 the FE and also gives a detailed response regarding the configuration 3086 result of each component. 3088 Message transfer direction: 3089 FE to CE 3091 Message Header: 3092 The Message Type in the header is set MessageType= 'Config 3093 Response'. The ACK flag in the header is always ignored, and the 3094 Config Response message never expects to get any further response 3095 from the message receiver (CE). 3097 OPER-TLV for Config Response: 3099 0 1 2 3 3100 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 3101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3102 | Type | Length | 3103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3104 | PATH-DATA-TLV | 3105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3107 Figure 30: OPER-TLV for Config Response 3109 Type: 3110 The operation type for Config Response message. Two types of 3111 operations for the Config Response message are defined: 3113 Type = "SET-RESPONSE" - this operation is for the response 3114 of SET operation of LFB components 3116 Type = "SET-PROP-RESPONSE" - this operation is for the 3117 response of SET-PROP operation of LFB component properties 3119 Type = "DEL-RESPONSE" - this operation is for the response 3120 of the DELETE operation of LFB components 3122 Type = "COMMIT-RESPONSE" - this operation is sent to the 3123 CE to confirm a commit success in a 2pc transaction. A 3124 COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating 3125 success or failure. 3127 PATH-DATA-TLV: 3128 This is generically a PATH-DATA-TLV format that has been defined 3129 in section (Section 7) in the PATH-DATA-TLV BNF definition. The 3130 restriction on the use of PATH-DATA-TLV for SET-RESPONSE 3131 operation is that it MUST contain RESULT-TLV(s). The restriction 3132 on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also 3133 MUST contain RESULT-TLV(s). The RESULT-TLV is defined in 3134 Section 7.1.7. 3136 To better illustrate the above PDU format, a tree structure for the 3137 format is shown below: 3139 main hdr (type = ConfigResponse) 3140 | 3141 | 3142 +--- T = LFBselect 3143 . | 3144 . +-- LFBCLASSID = target LFB class 3145 . | 3146 | 3147 +-- LFBInstance = target LFB instance 3148 | 3149 | 3150 +-- T = operation { SET-RESPONSE } 3151 | | 3152 | +-- // one or more path targets 3153 | // associated with FULL or SPARSEDATA-TLV(s) 3154 | 3155 +-- T = operation { DEL-RESPONSE } 3156 | | 3157 | +-- // one or more path targets 3158 | 3159 +-- T = operation { COMMIT-RESPONSE } 3160 | | 3161 | +-- RESULT-TLV 3163 Figure 31: PDU Format for Configuration Response message 3165 7.7. Query Messages 3167 The ForCES query messages are used by the CE to query LFBs in the FE 3168 for information like LFB components, capabilities, statistics, etc. 3169 Query Messages include the Query Message and the Query Response 3170 Message. 3172 7.7.1. Query Message 3174 A Query message is composed of a common header and a message body 3175 that consists of one or more TLV data format. Detailed description 3176 of the message is as below. 3178 Message transfer direction: 3179 from CE to FE 3181 Message Header: 3182 The Message Type in the header is set to MessageType= 'Query'. 3183 The ACK flag in the header is always ignored, and a full response 3184 for a query message is always expected. The Correlator field in 3185 the header is set, so that the CE can locate the response back 3186 from FE correctly. 3188 OPER-TLV for Query: 3190 0 1 2 3 3191 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 3192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3193 | Type = GET/GET-PROP | Length | 3194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3195 | PATH-DATA-TLV for GET/GET-PROP | 3196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3198 Figure 32: TLV for Query 3200 Type: 3201 The operation type for query. Two operation types are defined: 3203 Type = "GET" - this operation is to request to get LFB 3204 components. 3206 Type = "GET-PROP" - this operation is to request to get 3207 LFB components. 3209 PATH-DATA-TLV for GET/GET-PROP: 3210 This is generically a PATH-DATA-TLV format that has been defined 3211 in section (Section 7) in the PATH-DATA-TLV BNF definition. The 3212 restriction on the use of PATH-DATA-TLV for GET/GET-PROP 3213 operation is it MUST NOT contain any SPARSEDATA-TLV or FULLDATA- 3214 TLV and RESULT-TLV in the data format. 3216 To better illustrate the above PDU format, a tree structure for the 3217 format is shown below: 3219 main hdr (type = Query) 3220 | 3221 | 3222 +--- T = LFBselect 3223 . | 3224 . +-- LFBCLASSID = target LFB class 3225 . | 3226 | 3227 +-- LFBInstance = target LFB instance 3228 | 3229 | 3230 +-- T = operation { GET } 3231 | | 3232 | +-- // one or more path targets 3233 | 3234 +-- T = operation { GET } 3235 . | 3236 . +-- // one or more path targets 3237 . 3239 Figure 33: PDU Format for Query Message 3241 7.7.2. Query Response Message 3243 When receiving a Query message, the receiver should process the 3244 message and come up with a query result. The receiver sends the 3245 query result back to the message sender by use of the Query Response 3246 Message. The query result can be the information being queried if 3247 the query operation is successful, or can also be error codes if the 3248 query operation fails, indicating the reasons for the failure. 3250 A Query Response message is also composed of a common header and a 3251 message body consisting of one or more TLVs describing the query 3252 result. Detailed description of the message is as below. 3254 Message transfer direction: 3255 from FE to CE 3257 Message Header: 3258 The Message Type in the header is set to MessageType= 3259 'QueryResponse'. The ACK flag in the header is ignored. As a 3260 response itself, the message does not expect a further response. 3262 OPER-TLV for Query Response: 3264 0 1 2 3 3265 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 3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3267 |Type = GET-RESPONSE/GET-PROP-RESPONSE| Length | 3268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3269 | PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE | 3270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3272 Figure 34: TLV for Query Response 3274 Type: 3275 The operation type for query response. One operation type is 3276 defined: 3278 Type = "GET-RESPONSE" - this operation is to response to 3279 get operation of LFB components. 3281 Type = "GET-PROP-RESPONSE" - this operation is to response 3282 to GET-PROP operation of LFB components. 3284 PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE: 3285 This is generically a PATH-DATA-TLV format that has been defined 3286 in section (Section 7) in the PATH-DATA-TLV BNF definition. The 3287 PATH-DATA-TLV for GET-RESPONSE operation MAY contain SPARSEDATA- 3288 TLV, FULLDATA-TLV and/or RESULT-TLV(s) in the data encoding. The 3289 RESULT-TLV is defined in Section 7.1.7 and the SPARSEDATA-TLVs 3290 and FULLDATA-TLVs are defined in Section 7.1.8. 3292 To better illustrate the above PDU format, a tree structure for the 3293 format is shown below: 3295 main hdr (type = QueryResponse) 3296 | 3297 | 3298 +--- T = LFBselect 3299 . | 3300 . +-- LFBCLASSID = target LFB class 3301 . | 3302 | 3303 +-- LFBInstance = target LFB instance 3304 | 3305 | 3306 +-- T = operation { GET-RESPONSE } 3307 | | 3308 | +-- // one or more path targets 3309 | 3310 +-- T = operation { GET-PROP-RESPONSE } 3311 . | 3312 . +-- // one or more path targets 3313 . 3315 Figure 35: PDU Format for Query Response Message 3317 7.8. Event Notification Message 3319 Event Notification Message is used by FE to asynchronously notify CE 3320 of events that happen in the FE. 3322 All events that can be generated in an FE are subscribable by the CE. 3323 The CE can subscribe to an event via a Config message with SET-PROP 3324 operation, where the included path specifies the event, as defined by 3325 the LFB Library and described by the FE Model. 3327 As usual, an Event Notification Message is composed of a common 3328 header and a message body that consists of one or more TLV data 3329 format. Detailed description of the message is as below. 3331 Message Transfer Direction: 3332 FE to CE 3334 Message Header: 3335 The Message Type in the message header is set to 3336 MessageType = 'EventNotification'. The ACK flag in the header 3337 MUST be ignored by the CE, and the event notification message does 3338 not expect any response from the receiver. 3340 OPER-TLV for Event Notification: 3342 0 1 2 3 3343 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 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 | Type = REPORT | Length | 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 | PATH-DATA-TLV for REPORT | 3348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3350 Figure 36: TLV for Event Notification 3352 Type: 3353 Only one operation type is defined for the event notification 3354 message: 3356 Type = "REPORT" - this type of operation is for FE to 3357 report something to CE. 3359 PATH-DATA-TLV for REPORT: 3360 This is generically a PATH-DATA-TLV format that has been defined 3361 in section (Section 7) in the PATH-DATA-TLV BNF definition. The 3362 PATH-DATA-TLV for REPORT operation MAY contain FULLDATA-TLV or 3363 SPARSEDATA-TLV(s) but MUST NOT contain any RESULT-TLV in the data 3364 format. 3366 To better illustrate the above PDU format, a tree structure for the 3367 format is shown below: 3369 main hdr (type = Event Notification) 3370 | 3371 | 3372 +--- T = LFBselect 3373 | 3374 +-- LFBCLASSID = target LFB class 3375 | 3376 | 3377 +-- LFBInstance = target LFB instance 3378 | 3379 | 3380 +-- T = operation { REPORT } 3381 | | 3382 | +-- // one or more path targets 3383 | // associated with FULL/SPARSE DATA TLV(s) 3384 +-- T = operation { REPORT } 3385 . | 3386 . +-- // one or more path targets 3387 . // associated with FULL/SPARSE DATA TLV(s) 3389 Figure 37: PDU Format for Event Notification Message 3391 7.9. Packet Redirect Message 3393 A packet Redirect message is used to transfer data packets between CE 3394 and FE. Usually these data packets are control packets but they may 3395 be just data-path packets which need further (exception or high- 3396 touch) processing. It is also feasible that this message carries no 3397 data packets and rather just metadata. 3399 The Packet Redirect message data format is formatted as follows: 3401 Message Direction: 3402 CE to FE or FE to CE 3404 Message Header: 3405 The Message Type in the header is set to MessageType= 3406 'PacketRedirect'. 3408 Message Body: 3409 This consists of one or more TLVs that contain or describe the 3410 packet being redirected. The TLV is specifically a Redirect TLV 3411 (with the TLV Type="Redirect"). Detailed data format of a 3412 Redirect TLV for packet redirect message is as below: 3414 0 1 2 3 3415 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 3416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3417 | Type = Redirect | Length | 3418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3419 | Meta Data TLV | 3420 . . 3421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3422 | Redirect Data TLV | 3423 . . 3424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3426 Figure 38: Redirect_Data TLV 3428 Meta Data TLV: 3429 This is a TLV that specifies meta-data associated with followed 3430 redirected data. The TLV is as follows: 3432 0 1 2 3 3433 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 3434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3435 | Type = METADATA-TLV | Length | 3436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3437 | Meta Data ILV | 3438 . . 3439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3440 ~ ... ~ 3441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3442 | Meta Data ILV | 3443 . . 3444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3446 Figure 39: METADATA-TLV 3448 Meta Data ILV: 3449 This is an Identifier-Length-Value format that is used to describe 3450 one meta data. The ILV has the format as: 3452 0 1 2 3 3453 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 3454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3455 | Meta Data ID | 3456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3457 | Length | 3458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3459 | Meta Data Value | 3460 . . 3461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3463 Figure 40: Meta Data ILV 3465 Where, Meta Data ID is an identifier for the meta data, which is 3466 statically assigned by the LFB definition. 3468 Redirect Data TLV 3469 This is a TLV describing one packet of data to be directed via the 3470 redirect operation. The TLV format is as follows: 3472 0 1 2 3 3473 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 3474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3475 | Type = REDIRECTDATA-TLV | Length | 3476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3477 | Redirected Data | 3478 . . 3479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3481 Figure 41: Redirect Data TLV 3483 Redirected Data: 3484 This field contains the packet that is to be redirected in network 3485 byte order. The packet should be 32-bits aligned as is the data 3486 for all TLVs. The metadata infers what kind of packet is carried 3487 in value field and therefore allows for easy decoding of data 3488 encapsulated 3490 To better illustrate the above PDU format, a tree structure for the 3491 format is shown below: 3493 main hdr (type = PacketRedirect) 3494 | 3495 | 3496 +--- T = Redirect 3497 . | 3498 . +-- T = METADATA-TLV 3499 | | 3500 | +-- Meta Data ILV 3501 | | 3502 | +-- Meta Data ILV 3503 | . 3504 | . 3505 | 3506 +-- T = REDIRECTDATA-TLV 3507 | 3508 +-- // Redirected Data 3510 Figure 42: PDU Format for Packet Redirect Message 3512 7.10. Heartbeat Message 3514 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 3515 to asynchronously notify one or more other ForCES elements in the 3516 same ForCES NE on its liveness. Section 4.3.3 describes the traffic- 3517 sensitive approach used. 3519 A Heartbeat Message is sent by a ForCES element periodically. The 3520 parameterization and policy definition for heartbeats for an FE is 3521 managed as components of the FE Protocol Object LFB, and can be set 3522 by CE via a Config message. The Heartbeat message is a little 3523 different from other protocol messages in that it is only composed of 3524 a common header, with the message body left empty. A detailed 3525 description of the message is as below. 3527 Message Transfer Direction: 3528 FE to CE or CE to FE 3530 Message Header: 3531 The Message Type in the message header is set to MessageType = 3532 'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. 3533 The ACK flag in the header MUST be set to either 'NoACK' or 3534 'AlwaysACK' when the HB is sent. 3536 * When set to 'NoACK', the HB is not soliciting for a response. 3538 * When set to 'AlwaysACK', the HB Message sender is always 3539 expecting a response from its receiver. According the HB 3540 policies defined in Section 7.3.1, only the CE can send such 3541 an HB message to query FE liveness. For simplicity and 3542 because of the minimal nature of the HB message, the response 3543 to a HB message is another HB message, i.e., no specific HB 3544 response message is defined. Whenever an FE receives a HB 3545 message marked with 'AlwaysACK' from the CE, the FE MUST send 3546 a HB message back immediately. The HB message sent by the FE 3547 in response to the 'AlwasyACK' MUST modify the source and 3548 destination IDs so that the ID of the FE is the source ID and 3549 the CE ID of the sender is the destination ID, and MUST 3550 change the ACK information to 'NoACK'. A CE MUST NOT respond 3551 to an HB message with 'AlwasyACK' set. 3553 * When set to anything else other than 'NoACK' or 'AlwaysACK', 3554 the HB Message is treated as if it was a 'NoACK'. 3556 The correlator field in the HB message header SHOULD be set 3557 accordingly when a response is expected so that a receiver can 3558 correlate the response correctly. The correlator field MAY be 3559 ignored if no response is expected. 3561 Message Body: 3562 The message body is empty for the Heartbeat Message. 3564 8. High Availability Support 3566 The ForCES protocol provides mechanisms for CE redundancy and 3567 failover, in order to support High Availability as defined in 3568 [RFC3654]. FE redundancy and FE to FE interaction is currently out 3569 of scope of this document. There can be multiple redundant CEs and 3570 FEs in a ForCES NE. However, at any one time only one primary CE can 3571 control the FEs though there can be multiple secondary CEs. The FE 3572 and the CE PL are aware of the primary and secondary CEs. This 3573 information (primary, secondary CEs) is configured in the FE and in 3574 the CE PLs during pre-association by the FEM and the CEM 3575 respectively. Only the primary CE sends control messages to the FEs. 3577 8.1. Relation with the FE Protocol 3579 High Availability parameterization in an FE is driven by configuring 3580 the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1). 3581 The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE 3582 Heartbeat policy help in detecting connectivity problems between an 3583 FE and CE. The CE Failover policy defines the reaction on a detected 3584 failure. 3586 Figure 43 extends the state machine illustrated in Figure 4 to allow 3587 for new states that facilitate connection recovery. 3589 (CE issues Teardown || +-----------------+ 3590 Lost association) && | Pre-Association | 3591 CE failover policy = 0 | (Association | 3592 +------------>-->-->| in +<----+ 3593 | | progress) | | 3594 | CE Issues +--------+--------+ | 3595 | Association | | CFTI 3596 | Setup V | timer 3597 | ___________________+ | expires 3598 | | | 3599 | V ^ 3600 +-+-----------+ +-------+-----+ 3601 | | | Not | 3602 | | (CE issues Teardown || | Associated | 3603 | | Lost association) && | | 3604 | Associated | CE Failover Policy = 1 | (May | 3605 | | | Continue | 3606 | |---------->------->------>| Forwarding)| 3607 | | | | 3608 +-------------+ +-------------+ 3609 ^ V 3610 | | 3611 | CE Issues | 3612 | Association | 3613 | Setup | 3614 +_________________________________________+ 3616 Figure 43: FE State Machine considering HA 3618 Section 4.2 describes transitions between the Pre-association, 3619 associated and not associated states. 3621 When communication fails between the FE and CE (which can be caused 3622 by either the CE or link failure but not FE related), either the TML 3623 on the FE will trigger the FE PL regarding this failure or it will be 3624 detected using the HB messages between FEs and CEs. The 3625 communication failure, regardless of how it is detected, MUST be 3626 considered as a loss of association between the CE and corresponding 3627 FE. 3629 If the FE's FEPO CE Failover Policy is configured to mode 0 (the 3630 default), it will immediately transition to the pre-association 3631 phase. This means that if association is again established, all FE 3632 state will need to be re-established. 3634 If the FE's FEPO CE Failover Policy is configured to mode 1, it 3635 indicates that the FE is capable of HA restart recovery. In such a 3636 case, the FE transitions to the not associated state and the CEFTI 3637 timer is started. The FE MAY continue to forward packets during this 3638 state. It MAY also recycle through any configured secondary CEs in a 3639 round-robin fashion. It first adds its primary CE to the tail of 3640 backup CEs and sets its primary CE to be the first secondary. It 3641 then attempts to associate with the CE designated as the new primary 3642 CE. If it fails to re-associate with any CE and the CEFTI expires, 3643 the FE then transitions to the pre-association state. 3645 If the FE, while in the not associated state, manages to reconnect to 3646 a new primary CE before CEFTI expires it transitions to the 3647 Associated state. Once re-associated, the FE tries to recover any 3648 state that may have been lost during the not associated state. How 3649 the FE achieves re-synchronizes it state is out of scope for this 3650 document. 3652 Figure 44 below illustrates the Forces message sequences that the FE 3653 uses to recover the connection. 3655 FE CE Primary CE Secondary 3656 | | | 3657 | Asso Estb,Caps exchg | | 3658 1 |<--------------------->| | 3659 | | | 3660 | All msgs | | 3661 2 |<--------------------->| | 3662 | | | 3663 | | | 3664 | FAILURE | 3665 | | 3666 | Asso Estb,Caps exchange | 3667 3 |<------------------------------------------>| 3668 | | 3669 | Event Report (pri CE down) | 3670 4 |------------------------------------------->| 3671 | | 3672 | All Msgs | 3673 5 |<------------------------------------------>| 3675 Figure 44: CE Failover for Report Primary Mode 3677 A CE-to-CE synchronization protocol would be needed to support fast 3678 failover as well as to address some of the corner cases, however this 3679 will not be defined by the ForCES protocol as it is out of scope for 3680 this specification. 3682 An explicit message (a Config message setting Primary CE component in 3683 ForCES Protocol object) from the primary CE, can also be used to 3684 change the Primary CE for an FE during normal protocol operation. 3686 Also note that the FEs in a ForCES NE could also use a multicast CE 3687 ID, i.e., they could be associated with a group of CEs (this assumes 3688 the use of a CE-CE synchronization protocol, which is out of scope 3689 for this specification). In this case, the loss of association would 3690 mean that communication with the entire multicast group of CEs has 3691 been lost. The mechanisms described above will apply for this case 3692 as well during the loss of association. If, however, the secondary 3693 CE was also using the multicast CE ID that was lost, then the FE will 3694 need to form a new association using a different CE ID. If the 3695 capability exists, the FE MAY first attempt to form a new association 3696 with original primary CE using a different non multicast CE ID. 3698 8.2. Responsibilities for HA 3700 TML Level: 3702 1. The TML controls logical connection availability and failover. 3704 2. The TML also controls peer HA management. 3706 At this level, control of all lower layers, for example transport 3707 level (such as IP addresses, MAC addresses etc) and associated links 3708 going down are the role of the TML. 3710 PL Level: 3711 All other functionality, including configuring the HA behavior during 3712 setup, the CE IDs used to identify primary and secondary CEs, 3713 protocol messages used to report CE failure (Event Report), Heartbeat 3714 messages used to detect association failure, messages to change the 3715 primary CE (Config), and other HA related operations described 3716 before, are the PL responsibility. 3718 To put the two together, if a path to a primary CE is down, the TML 3719 would take care of failing over to a backup path, if one is 3720 available. If the CE is totally unreachable then the PL would be 3721 informed and it would take the appropriate actions described before. 3723 9. Security Considerations 3725 ForCES Framework document [RFC3746], section 8 goes into extensive 3726 detail on a variety of security threats, the possible effects of 3727 those threats on the protocol and responses to those threats. This 3728 document does not repeat that discussion, the reader is referred to 3729 the ForCES Framework document [RFC3746] for those details and how the 3730 ForCES architecture addresses them. 3732 ForCES PL uses security services provided by the ForCES TML. The TML 3733 provides security services such as endpoint authentication service, 3734 message authentication service and confidentiality service. Endpoint 3735 authentication service is invoked at the time of the pre-association 3736 connection establishment phase and message authentication is 3737 performed whenever the FE or CE receives a packet from its peer. 3739 The following are the general security mechanisms that need to be in 3740 place for ForCES PL. 3742 o Security mechanisms are session controlled - that is, once the 3743 security is turned on depending upon the chosen security level (No 3744 Security, Authentication, Confidentiality), it will be in effect 3745 for the entire duration of the session. 3747 o An operator should configure the same security policies for both 3748 primary and backup FEs and CEs (if available). This will ensure 3749 uniform operations and avoid unnecessary complexity in policy 3750 configuration. 3752 9.1. No Security 3754 When "No security" is chosen for ForCES protocol communication, both 3755 endpoint authentication and message authentication service needs to 3756 be performed by ForCES PL. Both these mechanism are weak and do not 3757 involve cryptographic operation. An operator can choose "No 3758 Security" level when the ForCES protocol endpoints are within a 3759 single box, for example. 3761 In order to have interoperable and uniform implementation across 3762 various security levels, each CE and FE endpoint MUST implement this 3763 level. 3765 What is described below (in Section 9.1.1 and Section 9.1.2) are 3766 error checks and not security procedures. The reader is referred to 3767 section Section 9.2. for security procedures. 3769 9.1.1. Endpoint Authentication 3771 Each CE and FE PL maintains a list of associations as part its of 3772 configuration. This is done via the CEM and FEM interfaces. An FE 3773 MUST connect to only those CEs that are configured via the FEM; 3774 similarly, a CE should accept the connection and establish 3775 associations for the FEs which are configured via the CEM. The CE 3776 should validate the FE identifier before accepting the connections 3777 during the pre-association phase. 3779 9.1.2. Message Authentication 3781 When a CE or FE initiates a message, the receiving endpoint MUST 3782 validate the initiator of the message by checking the common header 3783 CE or FE identifiers. This will ensure proper protocol functioning. 3784 This extra processing step is recommended even when the underlying 3785 TML layer security services exist. 3787 9.2. ForCES PL and TML security service 3789 This section is applicable if an operator wishes to use the TML 3790 security services. A ForCES TML MUST support one or more security 3791 services such as endpoint authentication service, message 3792 authentication service, and confidentiality service, as part of TML 3793 security layer functions. It is the responsibility of the operator 3794 to select an appropriate security service and configure security 3795 policies accordingly. The details of such configuration are outside 3796 the scope of the ForCES PL and are dependent on the type of transport 3797 protocol and the nature of the connection. 3799 All these configurations should be done prior to starting the CE and 3800 FE. 3802 When certificates-based authentication is being used at the TML, the 3803 certificate can use a ForCES-specific naming structure as certificate 3804 names and, accordingly, the security policies can be configured at 3805 the CE and FE. 3807 The reader is asked to refer to specific TML documents for details on 3808 the security requirements specific to that TML 3810 9.2.1. Endpoint authentication service 3812 When TML security services are enabled, the ForCES TML performs 3813 endpoint authentication. Security association is established between 3814 CE and FE and is transparent to the ForCES PL. 3816 9.2.2. Message authentication service 3818 This is a TML specific operation and is transparent to the ForCES PL. 3819 For details, refer to Section 5. 3821 9.2.3. Confidentiality service 3823 This is a TML specific operation and is transparent to the ForCES PL. 3824 For details, refer to Section 5. 3826 10. Acknowledgements 3828 The authors of this draft would like to acknowledge and thank the 3829 ForCES Working Group and especially the following: Furquan Ansari, 3830 Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M. 3831 Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel M. 3832 Halpern (who should probably be listed among the authors), Zsolt 3833 Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, 3834 T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their 3835 contributions. We would also like to thank David Putzolu, and 3836 Patrick Droz for their comments and suggestions on the protocol and 3837 for their infinite patience. We would also like to thank Sue Hares 3838 and Alia Atlas for extensive reviews of the document. 3840 Alia Atlas has done a wonderful job of shaping the draft to make it 3841 more readable by providing the IESG feedback. 3843 The editors have used the xml2rfc [RFC2629] tools in creating this 3844 document and are very grateful for the existence and quality of these 3845 tools. The editor is also grateful to Elwyn Davies for his help in 3846 correcting the XML source of this document. 3848 11. References 3850 11.1. Normative References 3852 [FE-MODEL] 3853 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., 3854 and S. Blake, "ForCES Forwarding Element Model", 3855 Feb. 2005. 3857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3858 Requirement Levels", BCP 14, RFC 2119, March 1997. 3860 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 3861 RFC 2914, September 2000. 3863 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3864 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3865 May 2008. 3867 [RFC5390] Rosenberg, J., "Requirements for Management of Overload in 3868 the Session Initiation Protocol", RFC 5390, December 2008. 3870 [SCTP-TML] 3871 Hadi Salim, J. and K. Ogawa, "SCTP based TML (Transport 3872 Mapping Layer) for ForCES protocol", internet 3873 draft draft-ietf-forces-sctptml, work in progress, 3874 Feb. 2009. 3876 11.2. Informational References 3878 [2PCREF] Gray, J., "Notes on database operating systems. In 3879 Operating Systems: An Advanced Course. Lecture Notes in 3880 Computer Science, Vol. 60, pp. 394-481, Springer-Verlag", 3881 1978. 3883 [ACID] Haerder, T. and A. Reuter, "Principles of Transaction- 3884 Orientated Database Recovery", 1983. 3886 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 3887 June 1999. 3889 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 3890 of IP Control and Forwarding", RFC 3654, November 2003. 3892 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 3893 "Forwarding and Control Element Separation (ForCES) 3894 Framework", RFC 3746, April 2004. 3896 Appendix A. IANA Considerations 3898 Following the policies outlined in "Guidelines for Writing an IANA 3899 Considerations Section in RFCs" (RFC 5226 [RFC5226]), the following 3900 name spaces are defined in ForCES. 3902 o Message Type Name Space Section 7 3904 o Operation Type Name Space Section 7.1.6 3906 o Header Flags Section 6.1 3908 o TLV Type Section 7 3910 o TLV Result Values Section 7.1.7 3912 o LFB Class ID Section 7.1.5 3914 o Result: Association Setup Response Section 7.5.2 3916 o Reason: Association Teardown Message Section 7.5.3 3918 A.1. Message Type Name Space 3920 The Message Type is an 8 bit value. The following is the guideline 3921 for defining the Message Type namespace 3923 Message Types 0x00 - 0x0F 3924 Message Types in this range are part of the base ForCES Protocol. 3925 Message Types in this range are allocated through an IETF 3926 consensus action. [RFC5226] 3928 Values assigned by this specification: 3930 0x00 Reserved 3931 0x01 AssociationSetup 3932 0x02 AssociationTeardown 3933 0x03 Config 3934 0x04 Query 3935 0x05 EventNotification 3936 0x06 PacketRedirect 3937 0x07 - 0x0E Reserved 3938 0x0F Hearbeat 3939 0x11 AssociationSetupRepsonse 3940 0x12 Reserved 3941 0x13 ConfigRepsonse 3942 0x14 QueryResponse 3944 Message Types 0x20 - 0x7F 3945 Message Types in this range are Specification Required [RFC5226] 3946 Message Types using this range MUST be documented in an RFC or 3947 other permanent and readily available reference. 3949 Message Types 0x80 - 0xFF 3950 Message Types in this range are reserved for vendor private 3951 extensions and are the responsibility of individual vendors. IANA 3952 management of this range of the Message Type Name Space is 3953 unnecessary. 3955 A.2. Operation Selection 3957 The Operation Selection (OPER-TLV) name space is 16 bits long. The 3958 following is the guideline for managing the OPER-TLV Name Space. 3960 OPER-TLV Type 0x0000-0x00FF 3961 OPER-TLV Types in this range are allocated through an IETF 3962 consensus process. [RFC5226]. 3964 Values assigned by this specification: 3966 0x0000 Reserved 3967 0x0001 SET 3968 0x0002 SET-PROP 3969 0x0003 SET-RESPONSE 3970 0x0004 SET-PROP-RESPONSE 3971 0x0005 DEL 3972 0x0006 DEL-RESPONSE 3973 0x0007 GET 3974 0x0008 GET-PROP 3975 0x0009 GET-RESPONSE 3976 0x000A GET-PROP-RESPONSE 3977 0x000B REPORT 3978 0x000C COMMIT 3979 0x000D COMMIT-RESPONSE 3980 0x000E TRCOMP 3982 OPER-TLV Type 0x0100-0x7FFF 3983 OPER-TLV Types using this range MUST be documented in an RFC or 3984 other permanent and readily available reference. [RFC5226]. 3986 OPER-TLV Type 0x8000-0xFFFF 3987 OPER-TLV Types in this range are reserved for vendor private 3988 extensions and are the responsibility of individual vendors. IANA 3989 management of this range of the OPER-TLV Type Name Space is 3990 unnecessary. 3992 A.3. Header Flags 3994 The Header flag field is 32 bits long. Header flags are part of 3995 the ForCES base protocol. Header flags are allocated through an 3996 IETF consensus action [RFC5226]. 3998 A.4. TLV Type Name Space 4000 The TLV Type name space is 16 bits long. The following is the 4001 guideline for managing the TLV Type Name Space. 4003 TLV Type 0x0000-0x00FF 4004 TLV Types in this range are allocated through an IETF consensus 4005 process. [RFC5226]. 4007 Values assigned by this specification: 4009 0x0000 Reserved 4010 0x0001 REDIRECT-TLV 4011 0x0010 ASResult-TLV 4012 0x0011 ASTreason-TLV 4013 0x1000 LFBselect-TLV 4014 0x0110 PATH-DATA-TLV 4015 0x0111 KEYINFO-TLV 4016 0x0112 FULLDATA-TLV 4017 0x0113 SPARSEDATA-TLV 4018 0x0114 RESULT-TLV 4019 0x0115 METADATA-TLV 4020 0x0116 REDIRECTDATA-TLV 4022 TLV Type 0x0200-0x7FFF 4023 TLV Types using this range MUST be documented in an RFC or other 4024 permanent and readily available reference [RFC5226]. 4026 TLV Type 0x8000-0xFFFF 4027 TLV Types in this range are reserved for vendor private extensions 4028 and are the responsibility of individual vendors. IANA management 4029 of this range of the TLV Type Name Space is unnecessary. 4031 A.5. Result-TLV Result Values 4033 The RESULT-TLV RTesult Value is an 8 bit value. 4035 0x00 E_SUCCESS 4036 0x01 E_INVALID_HEADER 4037 0x02 E_LENGTH_MISMATCH 4038 0x03 E_VERSION_MISMATCH 4039 0x04 E_INVALID_DESTINATION_PID 4040 0x05 E_LFB_UNKNOWN 4041 0x06 E_LFB_NOT_FOUND 4042 0x07 E_LFB_INSTANCE_ID_NOT_FOUND 4043 0x08 E_INVALID_PATH 4044 0x09 E_COMPONENT_DOES_NOT_EXIST 4045 0x0A E_EXISTS 4046 0x0B E_NOT_FOUND 4047 0x0C E_READ_ONLY 4048 0x0D E_INVALID_ARRAY_CREATION 4049 0x0E E_VALUE_OUT_OF_RANGE 4050 0x0F E_CONTENTS_TOO_LONG 4051 0x10 E_INVALID_PARAMETERS 4052 0x11 E_INVALID_MESSAGE_TYPE 4053 0x12 E_E_INVALID_FLAGS 4054 0x13 E_INVALID_TLV 4055 0x14 E_EVENT_ERROR 4056 0x15 E_NOT_SUPPORTED 4057 0x16 E_MEMORY_ERROR 4058 0x17 E_INTERNAL_ERROR 4059 0x18-0xFE Reserved 4060 0xFF E_UNSPECIFIED_ERROR 4062 All values not assigned in this specification are designated as 4063 Assignment by Expert review. 4065 A.6. Association Setup Response 4067 The Association Setup Response name space is 32 bits long. The 4068 following is the guideline for managing the Association Setup 4069 Response Name Space. 4071 Association Setup Response 0x0000-0x00FF 4072 Association Setup Responses in this range are allocated through an 4073 IETF consensus process [RFC5226]. 4075 Values assigned by this specification: 4077 0x0000 Success 4078 0x0001 FE ID Invalid 4079 0x0002 Permission Denied 4081 Association Setup Response 0x0100-0x0FFF 4082 Association Setup Responses in this range are Specification 4083 Required [RFC5226] Values using this range MUST be documented in 4084 an RFC or other permanent and readily available reference 4085 [RFC5226]. 4087 Association Setup Response 0x1000-0xFFFFFFFFF 4088 Association Setup Responses in this range are reserved for vendor 4089 private extensions and are the responsibility of individual 4090 vendors. IANA management of this range of the Association Setup 4091 Responses Name Space is unnecessary. 4093 A.7. Association Teardown Message 4095 The Association Teardown Message name space is 32 bits long. The 4096 following is the guideline for managing the Association Teardown 4097 Message Name Space. 4099 Association Teardown Message 0x00000000-0x0000FFFF 4100 Association Teardown Messages in this range are allocated through 4101 an IETF consensus process [RFC5226]. 4103 Values assigned by this specification: 4105 0x00000000 Normal - Teardown by Administrator 4106 0x00000001 Error - loss of heartbeats 4107 0x00000002 Error - loss of bandwidth 4108 0x00000003 Error - Out of Memory 4109 0x00000004 Error - Application Crash 4110 0x000000FF Error - Unspecified 4112 Association Teardown Message 0x00010000-0x7FFFFFFF 4113 Association Teardown Messages in this range are Specification 4114 Required [RFC5226] Association Teardown Messages using this range 4115 MUST be documented in an RFC or other permanent and readily 4116 available references. [RFC5226]. 4118 Association Teardown Message 0x80000000-0xFFFFFFFFF 4119 Association Teardown Messages in this range are reserved for 4120 vendor private extensions and are the responsibility of individual 4121 vendors. IANA management of this range of the Association 4122 Teardown Message Name Space is unnecessary. 4124 Appendix B. ForCES Protocol LFB schema 4126 The schema described below conforms to the LFB schema described in 4127 ForCES Model draft. [FE-MODEL] 4129 Section 7.3.1 describes the details of the different components 4130 defined in this definition. 4132 4135 4136 4137 4138 CEHBPolicyValues 4139 4140 The possible values of CE heartbeat policy 4141 4142 4143 uchar 4144 4145 4146 CEHBPolicy0 4147 4148 The CE heartbeat policy 0 4149 4150 4151 4152 CEHBPolicy1 4153 4154 The CE heartbeat policy 1 4155 4156 4157 4158 4159 4161 4162 FEHBPolicyValues 4163 4164 The possible values of FE heartbeat policy 4165 4166 4167 uchar 4168 4169 4170 FEHBPolicy0 4171 4172 The FE heartbeat policy 0 4173 4174 4175 4176 FEHBPolicy1 4177 4178 The FE heartbeat policy 1 4179 4180 4181 4182 4183 4185 4186 FERestartPolicyValues 4187 4188 The possible values of FE restart policy 4189 4190 4191 uchar 4192 4193 4194 FERestartPolicy0 4195 4196 The FE restart policy 0 4197 4198 4199 4200 4201 4203 4204 CEFailoverPolicyValues 4205 4206 The possible values of CE failover policy 4207 4208 4209 uchar 4210 4211 4212 CEFailoverPolicy0 4213 4214 The CE failover policy 0 4215 4216 4217 4218 CEFailoverPolicy1 4219 4220 The CE failover policy 1 4221 4222 4223 4224 4225 4227 4228 FEHACapab 4229 4230 The supported HA features 4231 4232 4233 uchar 4234 4235 4236 GracefullRestart 4237 4238 The FE supports Graceful Restart 4239 4240 4241 4242 HA 4243 4244 The FE supports HA 4245 4246 4247 4248 4249 4250 4252 4253 4254 FEPO 4255 4256 The FE Protocol Object 4257 4258 1.0 4260 4261 4262 CurrentRunningVersion 4263 Currently running ForCES version 4264 u8 4265 4266 4267 FEID 4268 Unicast FEID 4269 uint32 4270 4271 4272 MulticastFEIDs 4273 4274 the table of all multicast IDs 4275 4276 4277 uint32 4278 4279 4280 4281 CEHBPolicy 4282 4283 The CE Heartbeat Policy 4284 4285 CEHBPolicyValues 4286 4287 4288 CEHDI 4289 4290 The CE Heartbeat Dead Interval in millisecs 4291 4292 uint32 4293 4294 4295 FEHBPolicy 4296 4297 The FE Heartbeat Policy 4298 4299 FEHBPolicyValues 4300 4301 4302 FEHI 4303 4304 The FE Heartbeat Interval in millisecs 4305 4306 uint32 4307 4308 4309 CEID 4310 4311 The Primary CE this FE is associated with 4312 4313 uint32 4314 4315 4316 BackupCEs 4317 4318 The table of all backup CEs other than the primary 4319 4320 4321 uint32 4322 4323 4324 4325 CEFailoverPolicy 4326 4327 The CE Failover Policy 4328 4329 CEFailoverPolicyValues 4330 4332 4333 CEFTI 4334 4335 The CE Failover Timeout Interval in millisecs 4336 4337 uint32 4338 4339 4340 FERestartPolicy 4341 4342 The FE Restart Policy 4343 4344 FERestartPolicyValues 4345 4346 4347 LastCEID 4348 4349 The Primary CE this FE was last associated with 4350 4351 uint32 4352 4353 4355 4356 4357 SupportableVersions 4358 4359 the table of ForCES versions that FE supports 4360 4361 4362 u8 4364 4365 4366 4367 HACapabilities 4368 4369 the table of HA capabilities the FE supports 4370 4371 4372 FEHACapab 4373 4374 4375 4377 4378 4379 PrimaryCEDown 4380 4381 The pimary CE has changed 4382 4383 4384 LastCEID 4385 4386 4387 4388 4389 LastCEID 4390 4391 4392 4393 4395 4396 4397 4399 B.1. Capabilities 4401 Supportable Versions enumerates all ForCES versions that an FE 4402 supports. 4404 FEHACapab enumerates the HA capabilities of the FE. If the FE is not 4405 capable of Graceful restarts or HA, then it will not be able to 4406 participate in HA as described in Section 8.1 4408 B.2. Components 4410 All Components are explained in Section 7.3.1. 4412 Appendix C. Data Encoding Examples 4414 In this section a few examples of data encoding are discussed. these 4415 example, however, do not show any padding. 4417 ========== 4418 Example 1: 4419 ========== 4421 Structure with three fixed-lengthof, mandatory fields. 4423 struct S { 4424 uint16 a 4425 uint16 b 4426 uint16 c 4427 } 4429 (a) Describing all fields using SPARSEDATA-TLV 4431 PATH-DATA-TLV 4432 Path to an instance of S ... 4433 SPARSEDATA-TLV 4434 ComponentIDof(a), lengthof(a), valueof(a) 4435 ComponentIDof(b), lengthof(b), valueof(b) 4436 ComponentIDof(c), lengthof(c), valueof(c) 4438 (b) Describing a subset of fields 4440 PATH-DATA-TLV 4441 Path to an instance of S ... 4442 SPARSEDATA-TLV 4443 ComponentIDof(a), lengthof(a), valueof(a) 4444 ComponentIDof(c), lengthof(c), valueof(c) 4446 Note: Even though there are non-optional components in structure S, 4447 since one can uniquely identify components, one can selectively send 4448 component of structure S (eg in the case of an update from CE to FE). 4450 (c) Describing all fields using a FULLDATA-TLV 4452 PATH-DATA-TLV 4453 Path to an instance of S ... 4454 FULLDATA-TLV 4455 valueof(a) 4456 valueof(b) 4457 valueof(c) 4459 ========== 4460 Example 2: 4461 ========== 4463 Structure with three fixed-lengthof fields, one mandatory, two 4464 optional. 4466 struct T { 4467 uint16 a 4468 uint16 b (optional) 4469 uint16 c (optional) 4470 } 4472 This example is identical to Example 1, as illustrated below. 4474 (a) Describing all fields using SPARSEDATA-TLV 4476 PATH-DATA-TLV 4477 Path to an instance of S ... 4478 SPARSEDATA-TLV 4479 ComponentIDof(a), lengthof(a), valueof(a) 4480 ComponentIDof(b), lengthof(b), valueof(b) 4481 ComponentIDof(c), lengthof(c), valueof(c) 4483 (b) Describing a subset of fields using SPARSEDATA-TLV 4485 PATH-DATA-TLV 4486 Path to an instance of S ... 4487 SPARSEDATA-TLV 4488 ComponentIDof(a), lengthof(a), valueof(a) 4489 ComponentIDof(c), lengthof(c), valueof(c) 4491 (c) Describing all fields using a FULLDATA-TLV 4493 PATH-DATA-TLV 4494 Path to an instance of S ... 4495 FULLDATA-TLV 4496 valueof(a) 4497 valueof(b) 4498 valueof(c) 4500 Note: FULLDATA-TLV _cannot_ be used unless all fields are being 4501 described. 4503 ========== 4504 Example 3: 4505 ========== 4506 Structure with a mix of fixed-lengthof and variable-lengthof fields, 4507 some mandatory, some optional. Note in this case, b is variable 4508 sized 4510 struct U { 4511 uint16 a 4512 string b (optional) 4513 uint16 c (optional) 4514 } 4516 (a) Describing all fields using SPARSEDATA-TLV 4518 Path to an instance of U ... 4519 SPARSEDATA-TLV 4520 ComponentIDof(a), lengthof(a), valueof(a) 4521 ComponentIDof(b), lengthof(b), valueof(b) 4522 ComponentIDof(c), lengthof(c), valueof(c) 4524 (b) Describing a subset of fields using SPARSEDATA-TLV 4526 Path to an instance of U ... 4527 SPARSEDATA-TLV 4528 ComponentIDof(a), lengthof(a), valueof(a) 4529 ComponentIDof(c), lengthof(c), valueof(c) 4531 (c) Describing all fields using FULLDATA-TLV 4533 Path to an instance of U ... 4534 FULLDATA-TLV 4535 valueof(a) 4536 FULLDATA-TLV 4537 valueof(b) 4538 valueof(c) 4540 Note: The variable-length field requires the addition of a FULLDATA- 4541 TLV within the outer FULLDATA-TLV as in the case of component b 4542 above. 4544 ========== 4545 Example 4: 4546 ========== 4548 Structure containing an array of another structure type. 4550 struct V { 4551 uint32 x 4552 uint32 y 4553 struct U z[] 4554 } 4556 (a) Encoding using SPARSEDATA-TLV, with two instances of z[], also 4557 described with SPARSEDATA-TLV, assuming only the 10th and 15th 4558 subscript of z[] are encoded. 4560 path to instance of V ... 4561 SPARSEDATA-TLV 4562 ComponentIDof(x), lengthof(x), valueof(x) 4563 ComponentIDof(y), lengthof(y), valueof(y) 4564 ComponentIDof(z), lengthof(all below) 4565 ComponentID = 10 (i.e index 10 from z[]), lengthof(all below) 4566 ComponentIDof(a), lengthof(a), valueof(a) 4567 ComponentIDof(b), lengthof(b), valueof(b) 4568 ComponentID = 15 (index 15 from z[]), lengthof(all below) 4569 ComponentIDof(a), lengthof(a), valueof(a) 4570 ComponentIDof(c), lengthof(c), valueof(c) 4572 Note the holes in the components of z (10 followed by 15). Also note 4573 the gap in index 15 with only components a and c appearing but not b. 4575 Appendix D. Use Cases 4577 Assume LFB with following components for the following use cases. 4579 foo1, type u32, ID = 1 4581 foo2, type u32, ID = 2 4583 table1: type array, ID = 3 4584 components are: 4585 t1, type u32, ID = 1 4586 t2, type u32, ID = 2 // index into table2 4587 KEY: nhkey, ID = 1, V = t2 4589 table2: type array, ID = 4 4590 components are: 4591 j1, type u32, ID = 1 4592 j2, type u32, ID = 2 4593 KEY: akey, ID = 1, V = { j1,j2 } 4595 table3: type array, ID = 5 4596 components are: 4597 someid, type u32, ID = 1 4598 name, type string variable sized, ID = 2 4600 table4: type array, ID = 6 4601 components are: 4602 j1, type u32, ID = 1 4603 j2, type u32, ID = 2 4604 j3, type u32, ID = 3 4605 j4, type u32, ID = 4 4606 KEY: mykey, ID = 1, V = { j1} 4608 table5: type array, ID = 7 4609 components are: 4610 p1, type u32, ID = 1 4611 p2, type array, ID = 2, array components of type-X 4613 Type-X: 4614 x1, ID 1, type u32 4615 x2, ID2 , type u32 4616 KEY: tkey, ID = 1, V = { x1} 4618 All examples will use valueof(x) to indicate the value of the 4619 referenced component x. In the case where F_SEL** are missing (bits 4620 equal to 00) then the flags will not show any selection. 4622 All the examples only show use of FULLDATA-TLV for data encoding; 4623 although SPARSEDATA-TLV would make more sense in certain occasions, 4624 the emphasis is on showing the message layout. Refer to Appendix C 4625 for examples that show usage of both FULLDATA-TLV and SPARSEDATA-TLV. 4627 1. To get foo1 4629 OPER = GET-TLV 4630 PATH-DATA-TLV: IDCount = 1, IDs = 1 4631 Result: 4632 OPER = GET-RESPONSE-TLV 4633 PATH-DATA-TLV: 4634 flags=0, IDCount = 1, IDs = 1 4635 FULLDATA-TLV L = 4+4, V = valueof(foo1) 4637 2. To set foo2 to 10 4639 OPER = SET-TLV 4640 PATH-DATA-TLV: 4641 flags = 0, IDCount = 1, IDs = 2 4642 FULLDATA-TLV: L = 4+4, V=10 4644 Result: 4645 OPER = SET-RESPONSE-TLV 4646 PATH-DATA-TLV: 4647 flags = 0, IDCount = 1, IDs = 2 4648 RESULT-TLV 4650 3. To dump table2 4652 OPER = GET-TLV 4653 PATH-DATA-TLV: 4654 IDCount = 1, IDs = 4 4655 Result: 4656 OPER = GET-RESPONSE-TLV 4657 PATH-DATA-TLV: 4658 flags = 0, IDCount = 1, IDs = 4 4659 FULLDATA-TLV: L = XXX, V= 4660 a series of: index, valueof(j1), valueof(j2) 4661 representing the entire table 4663 Note: One should be able to take a GET-RESPONSE-TLV and 4664 convert it to a SET-TLV. If the result in the above example 4665 is sent back in a SET-TLV, (instead of a GET-RESPONSE_TLV) 4666 then the entire contents of the table will be replaced at 4667 that point. 4669 4. Multiple operations Example. To create entry 0-5 of table2 4670 (Error conditions are ignored) 4672 OPER = SET-TLV 4673 PATH-DATA-TLV: 4674 flags = 0 , IDCount = 1, IDs=4 4675 PATH-DATA-TLV 4676 flags = 0, IDCount = 1, IDs = 0 4677 FULLDATA-TLV valueof(j1), valueof(j2) of entry 0 4678 PATH-DATA-TLV 4679 flags = 0, IDCount = 1, IDs = 1 4680 FULLDATA-TLV valueof(j1), valueof(j2) of entry 1 4681 PATH-DATA-TLV 4682 flags = 0, IDCount = 1, IDs = 2 4683 FULLDATA-TLV valueof(j1), valueof(j2) of entry 2 4684 PATH-DATA-TLV 4685 flags = 0, IDCount = 1, IDs = 3 4686 FULLDATA-TLV valueof(j1), valueof(j2) of entry 3 4687 PATH-DATA-TLV 4688 flags = 0, IDCount = 1, IDs = 4 4689 FULLDATA-TLV valueof(j1), valueof(j2) of entry 4 4690 PATH-DATA-TLV 4691 flags = 0, IDCount = 1, IDs = 5 4692 FULLDATA-TLV valueof(j1), valueof(j2) of entry 5 4694 Result: 4695 OPER = SET-RESPONSE-TLV 4696 PATH-DATA-TLV: 4697 flags = 0 , IDCount = 1, IDs=4 4698 PATH-DATA-TLV 4699 flags = 0, IDCount = 1, IDs = 0 4700 RESULT-TLV 4701 PATH-DATA-TLV 4702 flags = 0, IDCount = 1, IDs = 1 4703 RESULT-TLV 4704 PATH-DATA-TLV 4705 flags = 0, IDCount = 1, IDs = 2 4706 RESULT-TLV 4707 PATH-DATA-TLV 4708 flags = 0, IDCount = 1, IDs = 3 4709 RESULT-TLV 4710 PATH-DATA-TLV 4711 flags = 0, IDCount = 1, IDs = 4 4712 RESULT-TLV 4713 PATH-DATA-TLV 4714 flags = 0, IDCount = 1, IDs = 5 4715 RESULT-TLV 4717 5. Block operations (with holes) example. Replace entry 0,2 of 4718 table2 4720 OPER = SET-TLV 4721 PATH-DATA-TLV: 4722 flags = 0 , IDCount = 1, IDs=4 4723 PATH-DATA-TLV 4724 flags = 0, IDCount = 1, IDs = 0 4725 FULLDATA-TLV containing valueof(j1), valueof(j2) of 0 4726 PATH-DATA-TLV 4727 flags = 0, IDCount = 1, IDs = 2 4728 FULLDATA-TLV containing valueof(j1), valueof(j2) of 2 4730 Result: 4731 OPER = SET-TLV 4732 PATH-DATA-TLV: 4733 flags = 0 , IDCount = 1, IDs=4 4734 PATH-DATA-TLV 4735 flags = 0, IDCount = 1, IDs = 0 4736 RESULT-TLV 4737 PATH-DATA-TLV 4738 flags = 0, IDCount = 1, IDs = 2 4739 RESULT-TLV 4741 6. Getting rows example. Get first entry of table2. 4743 OPER = GET-TLV 4744 PATH-DATA-TLV: 4745 IDCount = 2, IDs=4.0 4747 Result: 4748 OPER = GET-RESPONSE-TLV 4749 PATH-DATA-TLV: 4750 IDCount = 2, IDs=4.0 4751 FULLDATA-TLV containing valueof(j1), valueof(j2) 4753 7. Get entry 0-5 of table2. 4755 OPER = GET-TLV 4756 PATH-DATA-TLV: 4757 flags = 0, IDCount = 1, IDs=4 4758 PATH-DATA-TLV 4759 flags = 0, IDCount = 1, IDs = 0 4760 PATH-DATA-TLV 4761 flags = 0, IDCount = 1, IDs = 1 4762 PATH-DATA-TLV 4763 flags = 0, IDCount = 1, IDs = 2 4764 PATH-DATA-TLV 4765 flags = 0, IDCount = 1, IDs = 3 4766 PATH-DATA-TLV 4767 flags = 0, IDCount = 1, IDs = 4 4768 PATH-DATA-TLV 4769 flags = 0, IDCount = 1, IDs = 5 4771 Result: 4772 OPER = GET-RESPONSE-TLV 4773 PATH-DATA-TLV: 4774 flags = 0, IDCount = 1, IDs=4 4775 PATH-DATA-TLV 4776 flags = 0, IDCount = 1, IDs = 0 4777 FULLDATA-TLV containing valueof(j1), valueof(j2) 4778 PATH-DATA-TLV 4779 flags = 0, IDCount = 1, IDs = 1 4780 FULLDATA-TLV containing valueof(j1), valueof(j2) 4781 PATH-DATA-TLV 4782 flags = 0, IDCount = 1, IDs = 2 4783 FULLDATA-TLV containing valueof(j1), valueof(j2) 4784 PATH-DATA-TLV 4785 flags = 0, IDCount = 1, IDs = 3 4786 FULLDATA-TLV containing valueof(j1), valueof(j2) 4787 PATH-DATA-TLV 4788 flags = 0, IDCount = 1, IDs = 4 4789 FULLDATA-TLV containing valueof(j1), valueof(j2) 4790 PATH-DATA-TLV 4791 flags = 0, IDCount = 1, IDs = 5 4792 FULLDATA-TLV containing valueof(j1), valueof(j2) 4794 8. Create a row in table2, index 5. 4796 OPER = SET-TLV 4797 PATH-DATA-TLV: 4798 flags = 0, IDCount = 2, IDs=4.5 4799 FULLDATA-TLV containing valueof(j1), valueof(j2) 4801 Result: 4802 OPER = SET-RESPONSE-TLV 4803 PATH-DATA-TLV: 4804 flags = 0, IDCount = 1, IDs=4.5 4805 RESULT-TLV 4807 9. Dump contents of table1. 4809 OPER = GET-TLV 4810 PATH-DATA-TLV: 4811 flags = 0, IDCount = 1, IDs=3 4813 Result: 4814 OPER = GET-RESPONSE-TLV 4815 PATH-DATA-TLV 4816 flags = 0, IDCount = 1, IDs=3 4817 FULLDATA-TLV, Length = XXXX 4818 (depending on size of table1) 4819 index, valueof(t1),valueof(t2) 4820 index, valueof(t1),valueof(t2) 4821 . 4822 . 4823 . 4825 10. Using Keys. Get row entry from table4 where j1=100. Recall, j1 4826 is a defined key for this table and its KeyID is 1. 4828 OPER = GET-TLV 4829 PATH-DATA-TLV: 4830 flags = F_SELKEY IDCount = 1, IDs=6 4831 KEYINFO-TLV = KeyID=1, KEY_DATA=100 4833 Result: 4834 If j1=100 was at index 10 4835 OPER = GET-RESPONSE-TLV 4836 PATH-DATA-TLV: 4837 flags = 0, IDCount = 1, IDs=6.10 4838 FULLDATA-TLV containing 4839 valueof(j1), valueof(j2),valueof(j3),valueof(j4) 4841 11. Delete row with KEY match (j1=100, j2=200) in table2. Note that 4842 the j1,j2 pair are a defined key for the table2. 4844 OPER = DEL-TLV 4845 PATH-DATA-TLV: 4846 flags = F_SELKEY IDCount = 1, IDs=4 4847 KEYINFO-TLV: {KeyID =1 KEY_DATA=100,200} 4849 Result: 4850 If (j1=100, j2=200) was at entry 15: 4851 OPER = DELETE-RESPONSE-TLV 4852 PATH-DATA-TLV: 4853 flags = 0 IDCount = 2, IDs=4.15 4854 RESULT-TLV 4856 12. Dump contents of table3. It should be noted that this table has 4857 a column with component name that is variable sized. The 4858 purpose of this use case is to show how such an component is to 4859 be encoded. 4861 OPER = GET-TLV 4862 PATH-DATA-TLV: 4863 flags = 0 IDCount = 1, IDs=5 4865 Result: 4866 OPER = GET-RESPONSE-TLV 4867 PATH-DATA-TLV: 4868 flags = 0 IDCount = 1, IDs=5 4869 FULLDATA-TLV, Length = XXXX 4870 index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), 4871 V = valueof(v) 4872 index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), 4873 V = valueof(v) 4874 index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), 4875 V = valueof(v) 4876 index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), 4877 V = valueof(v) 4878 . 4879 . 4880 . 4882 13. Multiple atomic operations. 4884 Note 1: This emulates adding a new nexthop entry and then 4885 atomically updating the L3 entries pointing to an old NH to 4886 point to a new one. The assumption is both tables are in the 4887 same LFB 4889 Note2: Observe the two operations on the LFB instance, both 4890 are SET operations. 4892 //Operation 1: Add a new entry to table2 index #20. 4893 OPER = SET-TLV 4894 Path-TLV: 4895 flags = 0, IDCount = 2, IDs=4.20 4896 FULLDATA-TLV, V= valueof(j1),valueof(j2) 4898 // Operation 2: Update table1 entry which 4899 // was pointing with t2 = 10 to now point to 20 4900 OPER = SET-TLV 4901 PATH-DATA-TLV: 4902 flags = F_SELKEY, IDCount = 1, IDs=3 4903 KEYINFO-TLV = KeyID=1 KEY_DATA=10 4904 PATH-DATA-TLV 4905 flags = 0 IDCount = 1, IDs=2 4906 FULLDATA-TLV, V= 20 4908 Result: 4909 //first operation, SET 4910 OPER = SET-RESPONSE-TLV 4911 PATH-DATA-TLV 4912 flags = 0 IDCount = 3, IDs=4.20 4913 RESULT-TLV code = success 4914 FULLDATA-TLV, V = valueof(j1),valueof(j2) 4915 // second operation SET - assuming entry 16 was updated 4916 OPER = SET-RESPONSE-TLV 4917 PATH-DATA-TLV 4918 flags = 0 IDCount = 2, IDs=3.16 4919 PATH-DATA-TLV 4920 flags = 0 IDCount = 1, IDs = 2 4921 RESULT-TLV code = success 4922 FULLDATA-TLV, Length = XXXX v=20 4924 14. Selective setting. On table4 -- for indices 1, 3, 5, 7, and 9. 4925 Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. 4927 PER = SET-TLV 4928 PATH-DATA-TLV 4929 flags = 0, IDCount = 1, IDs = 6 4930 PATH-DATA-TLV 4931 flags = 0, IDCount = 1, IDs = 1 4932 PATH-DATA-TLV 4933 flags = 0, IDCount = 1, IDs = 1 4934 FULLDATA-TLV, Length = XXXX, V = {100} 4935 PATH-DATA-TLV 4936 flags = 0, IDCount = 1, IDs = 2 4937 FULLDATA-TLV, Length = XXXX, V = {200} 4938 PATH-DATA-TLV 4939 flags = 0, IDCount = 1, IDs = 3 4940 FULLDATA-TLV, Length = XXXX, V = {300} 4941 PATH-DATA-TLV 4942 flags = 0, IDCount = 1, IDs = 3 4943 PATH-DATA-TLV 4944 flags = 0, IDCount = 1, IDs = 1 4945 FULLDATA-TLV, Length = XXXX, V = {100} 4946 PATH-DATA-TLV 4947 flags = 0, IDCount = 1, IDs = 2 4948 FULLDATA-TLV, Length = XXXX, V = {200} 4949 PATH-DATA-TLV 4950 flags = 0, IDCount = 1, IDs = 3 4951 FULLDATA-TLV, Length = XXXX, V = {300} 4952 PATH-DATA-TLV 4953 flags = 0, IDCount = 1, IDs = 5 4954 PATH-DATA-TLV 4955 flags = 0, IDCount = 1, IDs = 1 4956 FULLDATA-TLV, Length = XXXX, V = {100} 4957 PATH-DATA-TLV 4958 flags = 0, IDCount = 1, IDs = 2 4959 FULLDATA-TLV, Length = XXXX, V = {200} 4960 PATH-DATA-TLV 4961 flags = 0, IDCount = 1, IDs = 3 4962 FULLDATA-TLV, Length = XXXX, V = {300} 4963 PATH-DATA-TLV 4964 flags = 0, IDCount = 1, IDs = 7 4965 PATH-DATA-TLV 4966 flags = 0, IDCount = 1, IDs = 1 4967 FULLDATA-TLV, Length = XXXX, V = {100} 4968 PATH-DATA-TLV 4969 flags = 0, IDCount = 1, IDs = 2 4970 FULLDATA-TLV, Length = XXXX, V = {200} 4971 PATH-DATA-TLV 4972 flags = 0, IDCount = 1, IDs = 3 4973 FULLDATA-TLV, Length = XXXX, V = {300} 4974 PATH-DATA-TLV 4975 flags = 0, IDCount = 1, IDs = 9 4976 PATH-DATA-TLV 4977 flags = 0, IDCount = 1, IDs = 1 4978 FULLDATA-TLV, Length = XXXX, V = {100} 4979 PATH-DATA-TLV 4980 flags = 0, IDCount = 1, IDs = 2 4981 FULLDATA-TLV, Length = XXXX, V = {200} 4982 PATH-DATA-TLV 4983 flags = 0, IDCount = 1, IDs = 3 4984 FULLDATA-TLV, Length = XXXX, V = {300} 4986 response: 4988 OPER = SET-RESPONSE-TLV 4989 PATH-DATA-TLV 4990 flags = 0, IDCount = 1, IDs = 6 4991 PATH-DATA-TLV 4992 flags = 0, IDCount = 1, IDs = 1 4993 PATH-DATA-TLV 4994 flags = 0, IDCount = 1, IDs = 1 4995 RESULT-TLV 4996 PATH-DATA-TLV 4997 flags = 0, IDCount = 1, IDs = 2 4998 RESULT-TLV 4999 PATH-DATA-TLV 5000 flags = 0, IDCount = 1, IDs = 3 5001 RESULT-TLV 5002 PATH-DATA-TLV 5003 flags = 0, IDCount = 1, IDs = 3 5004 PATH-DATA-TLV 5005 flags = 0, IDCount = 1, IDs = 1 5006 RESULT-TLV 5007 PATH-DATA-TLV 5008 flags = 0, IDCount = 1, IDs = 2 5009 RESULT-TLV 5010 PATH-DATA-TLV 5011 flags = 0, IDCount = 1, IDs = 3 5012 RESULT-TLV 5013 PATH-DATA-TLV 5014 flags = 0, IDCount = 1, IDs = 5 5015 PATH-DATA-TLV 5016 flags = 0, IDCount = 1, IDs = 1 5017 RESULT-TLV 5018 PATH-DATA-TLV 5019 flags = 0, IDCount = 1, IDs = 2 5020 RESULT-TLV 5021 PATH-DATA-TLV 5022 flags = 0, IDCount = 1, IDs = 3 5023 RESULT-TLV 5024 PATH-DATA-TLV 5025 flags = 0, IDCount = 1, IDs = 7 5026 PATH-DATA-TLV 5027 flags = 0, IDCount = 1, IDs = 1 5028 RESULT-TLV 5029 PATH-DATA-TLV 5030 flags = 0, IDCount = 1, IDs = 2 5031 RESULT-TLV 5032 PATH-DATA-TLV 5033 flags = 0, IDCount = 1, IDs = 3 5034 RESULT-TLV 5035 PATH-DATA-TLV 5036 flags = 0, IDCount = 1, IDs = 9 5037 PATH-DATA-TLV 5038 flags = 0, IDCount = 1, IDs = 1 5039 RESULT-TLV 5040 PATH-DATA-TLV 5041 flags = 0, IDCount = 1, IDs = 2 5042 RESULT-TLV 5043 PATH-DATA-TLV 5044 flags = 0, IDCount = 1, IDs = 3 5045 RESULT-TLV 5047 15. Manipulation of table of table examples. Get x1 from table10 5048 row with index 4, inside table5 entry 10 5050 operation = GET-TLV 5051 PATH-DATA-TLV 5052 flags = 0 IDCount = 5, IDs=7.10.2.4.1 5054 Results: 5055 operation = GET-RESPONSE-TLV 5056 PATH-DATA-TLV 5057 flags = 0 IDCount = 5, IDs=7.10.2.4.1 5058 FULLDATA-TLV: L=XXXX, V = valueof(x1) 5060 16. From table5's row 10 table10, get X2s based on on the value of 5061 x1 equaling 10 (recall x1 is KeyID 1) 5063 operation = GET-TLV 5064 PATH-DATA-TLV 5065 flag = F_SELKEY, IDCount=3, IDS = 7.10.2 5066 KEYINFO-TLV, KeyID = 1, KEYDATA = 10 5067 PATH-DATA-TLV 5068 IDCount = 1, IDS = 2 //select x2 5070 Results: 5071 If x1=10 was at entry 11: 5072 operation = GET-RESPONSE-TLV 5073 PATH-DATA-TLV 5074 flag = 0, IDCount=5, IDS = 7.10.2.11 5075 PATH-DATA-TLV 5076 flags = 0 IDCount = 1, IDS = 2 5077 FULLDATA-TLV: L=XXXX, V = valueof(x2) 5079 17. Further example of manipulating a table of tables 5081 Consider table6 which is defined as: 5082 table6: type array, ID = 8 5083 components are: 5084 p1, type u32, ID = 1 5085 p2, type array, ID = 2, array components of type type-A 5087 type-A: 5088 a1, type u32, ID 1, 5089 a2, type array ID2 ,array components of type type-B 5091 type-B: 5092 b1, type u32, ID 1 5093 b2, type u32, ID 2 5095 If for example one wanted to set by replacing: 5096 table6.10.p1 to 111 5097 table6.10.p2.20.a1 to 222 5098 table6.10.p2.20.a2.30.b1 to 333 5100 in one message and one operation. 5102 There are two ways to do this: 5103 a) using nesting 5104 b) using a flat path data 5106 A. Method using nesting 5107 in one message with a single operation 5109 operation = SET-TLV 5110 PATH-DATA-TLV 5111 flags = 0 IDCount = 2, IDs=6.10 5112 PATH-DATA-TLV 5113 flags = 0, IDCount = 1, IDs=1 5114 FULLDATA-TLV: L=XXXX, 5115 V = {111} 5116 PATH-DATA-TLV 5117 flags = 0 IDCount = 2, IDs=2.20 5118 PATH-DATA-TLV 5119 flags = 0, IDCount = 1, IDs=1 5120 FULLDATA-TLV: L=XXXX, 5121 V = {222} 5122 PATH-DATA-TLV : 5123 flags = 0, IDCount = 3, IDs=2.30.1 5124 FULLDATA-TLV: L=XXXX, 5125 V = {333} 5126 Result: 5127 operation = SET-RESPONSE-TLV 5128 PATH-DATA-TLV 5129 flags = 0 IDCount = 2, IDs=6.10 5130 PATH-DATA-TLV 5131 flags = 0, IDCount = 1, IDs=1 5132 RESULT-TLV 5133 PATH-DATA-TLV 5134 flags = 0 IDCount = 2, IDs=2.20 5135 PATH-DATA-TLV 5136 flags = 0, IDCount = 1, IDs=1 5137 RESULT-TLV 5138 PATH-DATA-TLV : 5139 flags = 0, IDCount = 3, IDs=2.30.1 5140 RESULT-TLV 5142 B. Method using a flat path data in 5143 one message with a single operation 5145 operation = SET-TLV 5146 PATH-DATA-TLV : 5147 flags = 0, IDCount = 3, IDs=6.10.1 5148 FULLDATA-TLV: L=XXXX, 5149 V = {111} 5150 PATH-DATA-TLV : 5151 flags = 0, IDCount = 5, IDs=6.10.1.20.1 5152 FULLDATA-TLV: L=XXXX, 5153 V = {222} 5154 PATH-DATA-TLV : 5155 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 5156 FULLDATA-TLV: L=XXXX, 5157 V = {333} 5158 Result: 5159 operation = SET-TLV 5160 PATH-DATA-TLV : 5161 flags = 0, IDCount = 3, IDs=6.10.1 5162 RESULT-TLV 5163 PATH-DATA-TLV : 5164 flags = 0, IDCount = 5, IDs=6.10.1.20.1 5165 RESULT-TLV 5166 PATH-DATA-TLV : 5167 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 5168 RESULT-TLV 5170 18. Get a whole LFB (all its components, etc.). 5172 For example: at startup a CE might well want the entire FE 5173 OBJECT LFB. So, in a request targeted at class 1, instance 5174 1, one might find: 5176 operation = GET-TLV 5177 PATH-DATA-TLV 5178 flags = 0 IDCount = 0 5180 result: 5181 operation = GET-RESPONSE-TLV 5182 PATH-DATA-TLV 5183 flags = 0 IDCount = 0 5184 FULLDATA-TLV encoding of the FE Object LFB 5186 Authors' Addresses 5188 Ligang Dong 5189 Zhejiang Gongshang University 5190 149 Jiaogong Road 5191 Hangzhou 310035 5192 P.R.China 5194 Phone: +86-571-88071024 5195 Email: donglg@mail.zjgsu.edu.cn 5197 Avri Doria 5198 Lulea University of Technology 5199 Rainbow Way 5200 Lulea SE-971 87 5201 Sweden 5203 Phone: +46 73 277 1788 5204 Email: avri@ltu.se 5206 Ram Gopal 5207 Nokia 5208 5, Wayside Road 5209 Burlington, MA 310035 5210 USA 5212 Phone: +1-781-993-3685 5213 Email: ram.gopal@nsn.com 5215 Robert Haas 5216 IBM 5217 Saumerstrasse 4 5218 8803 Ruschlikon 5219 Switzerland 5221 Phone: 5222 Email: rha@zurich.ibm.com 5223 Jamal Hadi Salim 5224 Znyx 5225 Ottawa, Ontario 5226 Canada 5228 Phone: 5229 Email: hadi@znyx.com 5231 Hormuzd M Khosravi 5232 Intel 5233 2111 NE 25th Avenue 5234 Hillsboro, OR 97124 5235 USA 5237 Phone: +1 503 264 0334 5238 Email: hormuzd.m.khosravi@intel.com 5240 Weiming Wang 5241 Zhejiang Gongshang University 5242 149 Jiaogong Road 5243 Hangzhou 310035 5244 P.R.China 5246 Phone: +86-571-88057712 5247 Email: wmwang@mail.zjgsu.edu.cn