idnits 2.17.1 draft-ietf-forces-protocol-20.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 (February 3, 2009) is 5554 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 1867, but not defined == Missing Reference: 'SELECTOR' is mentioned on line 1868, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FE-MODEL' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 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: August 7, 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 February 3, 2009 15 ForCES Protocol Specification 16 draft-ietf-forces-protocol-20.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 August 7, 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 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Abstract 55 This document specifies the Forwarding and Control Element Separation 56 (ForCES) protocol. ForCES protocol is used for communications 57 between Control Elements(CEs) and Forwarding Elements (FEs) in a 58 ForCES Network Element (ForCES NE). This specification is intended 59 to meet the ForCES protocol requirements defined in RFC3654. Besides 60 the ForCES protocol, this specification also defines the requirements 61 for the Transport Mapping Layer (TML). 63 Authors 65 The participants in the ForCES Protocol Team, primary co-authors and 66 co-editors, of this protocol specification, are: 68 Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea 69 University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), 70 Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang 71 (Zhejiang Gongshang University). Special acknowledgement goes to 72 Joel Halpern who has done extensive editing in support of congruence 73 between the model and this protocol specification. Without his 74 participation and persistence, this specification might never have 75 been completed. 77 Table of Contents 79 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 7 80 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 7 81 1.2. Other Notation . . . . . . . . . . . . . . . . . . . . . 7 82 1.3. Integers . . . . . . . . . . . . . . . . . . . . . . . . 7 83 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 84 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 12 87 4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 14 88 4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 15 89 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 15 90 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 16 91 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 17 92 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18 93 4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 20 94 4.3.1. Transactions, Atomicity, Execution and Responses . . 20 95 4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 26 96 4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 27 97 4.3.4. FE Object and FE Protocol LFBs . . . . . . . . . . . 27 98 4.4. Protocol Scenarios . . . . . . . . . . . . . . . . . . . 28 99 4.4.1. Association Setup State . . . . . . . . . . . . . . . 28 100 4.4.2. Association Established state or Steady State . . . . 29 101 5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 32 102 5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 34 103 6. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 35 104 6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 35 105 6.2. Type Length Value (TLV) Structuring . . . . . . . . . . . 40 106 6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 41 107 6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 41 108 6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 109 6.4. Important Protocol encapsulations . . . . . . . . . . . . 42 110 6.4.1. Paths . . . . . . . . . . . . . . . . . . . . . . . . 42 111 6.4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 43 112 6.4.3. DATA TLVs . . . . . . . . . . . . . . . . . . . . . . 43 113 6.4.4. Addressing LFB entities . . . . . . . . . . . . . . . 43 114 7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 45 115 7.1. Discussion on encoding . . . . . . . . . . . . . . . . . 49 116 7.1.1. Data Packing Rules . . . . . . . . . . . . . . . . . 49 117 7.1.2. Path Flags . . . . . . . . . . . . . . . . . . . . . 49 118 7.1.3. Relation of operational flags with global message 119 flags . . . . . . . . . . . . . . . . . . . . . . . . 50 120 7.1.4. Content Path Selection . . . . . . . . . . . . . . . 50 121 7.1.5. LFBselect-TLV . . . . . . . . . . . . . . . . . . . . 50 122 7.1.6. OPER-TLV . . . . . . . . . . . . . . . . . . . . . . 51 123 7.1.7. RESULT TLV . . . . . . . . . . . . . . . . . . . . . 53 124 7.1.8. DATA TLV . . . . . . . . . . . . . . . . . . . . . . 56 125 7.1.9. SET and GET Relationship . . . . . . . . . . . . . . 57 126 7.2. Protocol Encoding Visualization . . . . . . . . . . . . . 58 127 7.3. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 61 128 7.3.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 62 129 7.3.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 65 130 7.4. Semantics of Message Direction . . . . . . . . . . . . . 65 131 7.5. Association Messages . . . . . . . . . . . . . . . . . . 66 132 7.5.1. Association Setup Message . . . . . . . . . . . . . . 66 133 7.5.2. Association Setup Response Message . . . . . . . . . 68 134 7.5.3. Association Teardown Message . . . . . . . . . . . . 69 135 7.6. Configuration Messages . . . . . . . . . . . . . . . . . 71 136 7.6.1. Config Message . . . . . . . . . . . . . . . . . . . 71 137 7.6.2. Config Response Message . . . . . . . . . . . . . . . 73 138 7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 75 139 7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 75 140 7.7.2. Query Response Message . . . . . . . . . . . . . . . 77 141 7.8. Event Notification Message . . . . . . . . . . . . . . . 79 142 7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 81 143 7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 84 144 8. High Availability Support . . . . . . . . . . . . . . . . . . 86 145 8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 86 146 8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 89 147 9. Security Considerations . . . . . . . . . . . . . . . . . . . 90 148 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 90 149 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 91 150 9.1.2. Message Authentication . . . . . . . . . . . . . . . 91 151 9.2. ForCES PL and TML security service . . . . . . . . . . . 91 152 9.2.1. Endpoint authentication service . . . . . . . . . . . 91 153 9.2.2. Message authentication service . . . . . . . . . . . 92 154 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 92 155 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 93 156 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 94 157 11.1. Normative References . . . . . . . . . . . . . . . . . . 94 158 11.2. Informational References . . . . . . . . . . . . . . . . 94 159 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 95 160 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 95 161 A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 96 162 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 97 163 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 97 164 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 97 165 A.6. Association Setup Response . . . . . . . . . . . . . . . 98 166 A.7. Association Teardown Message . . . . . . . . . . . . . . 99 167 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 100 168 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 105 169 B.2. Components . . . . . . . . . . . . . . . . . . . . . . . 105 170 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 106 171 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 110 172 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125 174 1. Terminology and Conventions 176 1.1. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in RFC 2119 [RFC2119]. 182 1.2. Other Notation 184 In Table 1 and Table 2 the following notation is used to indicate 185 multiplicity: 187 (value)+ .... means "1 or more instance of value" 189 (value)* .... means "0 or more instance of value" 191 1.3. Integers 193 All integers are to be coded as unsigned binary integers of 194 appropriate length. 196 2. Introduction 198 Forwarding and Control Element Separation (ForCES) defines an 199 architectural framework and associated protocols to standardize 200 information exchange between the control plane and the forwarding 201 plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined 202 the ForCES requirements, and RFC 3746 has defined the ForCES 203 framework. While there may be multiple protocols used within the 204 overall ForCES architecture, the term "ForCES protocol" and 205 "protocol" as used in this document refers to the protocol used to 206 standardize the information exchange between Control Elements (CEs) 207 and Forwarding Elements (FEs) only. 209 The ForCES FE model [FE-MODEL] presents a formal way to define FE 210 Logical Function Blocks (LFBs) using XML. LFB configuration 211 components, capabilities, and associated events are defined when the 212 LFB is formally created. The LFBs within the FE are accordingly 213 controlled in a standardized way by the ForCES protocol. 215 This document defines the ForCES protocol specifications. The ForCES 216 protocol works in a master-slave mode in which FEs are slaves and CEs 217 are masters. The protocol includes commands for transport of Logical 218 Function Block (LFB) configuration information, association setup, 219 status, and event notifications, etc. 221 Section 3 provides a glossary of terminology used in the 222 specification. 224 Section 4 provides an overview of the protocol, including a 225 discussion on the protocol framework, descriptions of the Protocol 226 Layer (PL) and a Transport Mapping Layer (TML), as well as of the 227 ForCES protocol mechanisms. Section 4.4 describes several Protocol 228 scenarios and includes message exchange descriptions. 230 While this document does not define the TML, Section 5 details the 231 services that a TML must provide (TML requirements). 233 The ForCES protocol defines a common header for all protocol 234 messages. The header is defined in Section 6.1, while the protocol 235 messages are defined in Section 7. 237 Section 8 describes the protocol support for high availability 238 mechanisms including redundancy and fail over. 240 Section 9 defines the security mechanisms provided by the PL and TML. 242 3. Definitions 244 This document follows the terminology defined by the ForCES 245 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 246 The definitions below are repeated below for clarity. 248 Addressable Entity (AE) - A physical device that is directly 249 addressable given some interconnect technology. For example, on IP 250 networks, it is a device which can be reached using an IP address; 251 and on a switch fabric, it is a device which can be reached using a 252 switch fabric port number. 254 Control Element (CE) - A logical entity that implements the ForCES 255 protocol and uses it to instruct one or more FEs on how to process 256 packets. CEs handle functionality such as the execution of control 257 and signaling protocols. 259 CE Manager (CEM) - A logical entity responsible for generic CE 260 management tasks. It is particularly used during the pre-association 261 phase to determine with which FE(s) a CE should communicate. This 262 process is called FE discovery and may involve the CE manager 263 learning the capabilities of available FEs. 265 Datapath - A conceptual path taken by packets within the forwarding 266 plane inside an FE. 268 Forwarding Element (FE) - A logical entity that implements the ForCES 269 protocol. FEs use the underlying hardware to provide per-packet 270 processing and handling as directed/controlled by one or more CEs via 271 the ForCES protocol. 273 FE Model - A model that describes the logical processing functions of 274 an FE. The FE model is defined using Logical Function Blocks (LFBs). 276 FE Manager (FEM) - A logical entity responsible for generic FE 277 management tasks. It is used during pre-association phase to 278 determine with which CE(s) an FE should communicate. This process is 279 called CE discovery and may involve the FE manager learning the 280 capabilities of available CEs. An FE manager may use anything from a 281 static configuration to a pre-association phase protocol (see below) 282 to determine which CE(s) to use. Being a logical entity, an FE 283 manager might be physically combined with any of the other logical 284 entities such as FEs. 286 ForCES Network Element (NE) - An entity composed of one or more CEs 287 and one or more FEs. To entities outside an NE, the NE represents a 288 single point of management. Similarly, an NE usually hides its 289 internal organization from external entities. 291 High Touch Capability - This term will be used to apply to the 292 capabilities found in some forwarders to take action on the contents 293 or headers of a packet based on content other than what is found in 294 the IP header. Examples of these capabilities include quality of 295 service policies, virtual private networks, firewall, and L7 content 296 recognition. 298 Inter-FE Topology - See FE Topology. 300 Intra-FE Topology - See LFB Topology. 302 LFB (Logical Function Block) - The basic building block that is 303 operated on by the ForCES protocol. The LFB is a well defined, 304 logically separable functional block that resides in an FE and is 305 controlled by the CE via ForCES protocol. The LFB may reside at the 306 FE's datapath and process packets or may be purely an FE control or 307 configuration entity that is operated on by the CE. Note that the 308 LFB is a functionally accurate abstraction of the FE's processing 309 capabilities, but not a hardware-accurate representation of the FE 310 implementation. 312 FE Topology - A representation of how the multiple FEs within a 313 single NE are interconnected. Sometimes this is called inter-FE 314 topology, to be distinguished from intra-FE topology (i.e., LFB 315 topology). 317 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. An 318 LFB Instance represents an LFB Class (or Type) existence. There may 319 be multiple instances of the same LFB Class (or Type) in an FE. An 320 LFB Class is represented by an LFB Class ID, and an LFB Instance is 321 represented by an LFB Instance ID. As a result, an LFB Class ID 322 associated with an LFB Instance ID uniquely specifies an LFB 323 existence. 325 LFB Metadata - Metadata is used to communicate per-packet state from 326 one LFB to another, but is not sent across the network. The FE model 327 defines how such metadata is identified, produced and consumed by the 328 LFBs. It defines the functionality but not how metadata is encoded 329 within an implementation. 331 LFB Attribute - Operational parameters of the LFBs that must be 332 visible to the CEs are conceptualized in the FE model as the LFB 333 attributes. The LFB attributes include, for example, flags, single 334 parameter arguments, complex arguments, and tables that the CE can 335 read and/or write via the ForCES protocol (see below). 337 LFB Topology - Representation of how the LFB instances are logically 338 interconnected and placed along the datapath within one FE. 340 Sometimes it is also called intra-FE topology, to be distinguished 341 from inter-FE topology. 343 Pre-association Phase - The period of time during which an FE Manager 344 and a CE Manager are determining which FE(s) and CE(s) should be part 345 of the same network element. 347 Post-association Phase - The period of time during which an FE knows 348 which CE is to control it and vice versa. This includes the time 349 during which the CE and FE are establishing communication with one 350 another. 352 ForCES Protocol - While there may be multiple protocols used within 353 the overall ForCES architecture, the term "ForCES protocol" and 354 "protocol" refer to the Fp reference points in the ForCES Framework 355 in [RFC3746]. This protocol does not apply to CE-to-CE 356 communication, FE-to-FE communication, or to communication between FE 357 and CE managers. Basically, the ForCES protocol works in a master- 358 slave mode in which FEs are slaves and CEs are masters. This 359 document defines the specifications for this ForCES protocol. 361 ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol 362 architecture that defines the ForCES protocol messages, the protocol 363 state transfer scheme, as well as the ForCES protocol architecture 364 itself (including requirements of ForCES TML as shown below). 365 Specifications of ForCES PL are defined by this document. 367 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 368 ForCES protocol architecture that uses the capabilities of existing 369 transport protocols to specifically address protocol message 370 transportation issues, such as how the protocol messages are mapped 371 to different transport media (like TCP, IP, ATM, Ethernet, etc), and 372 how to achieve and implement reliability, multicast, ordering, etc. 373 The ForCES TML specifications are detailed in separate ForCES 374 documents, one for each TML. 376 4. Overview 378 The reader is referred to the Framework document [RFC3746], and in 379 particular sections 3 and 4, for an architectural overview and an 380 explanation of how the ForCES protocol fits in. There may be some 381 content overlap between the framework document and this section in 382 order to provide clarity. This document is authoritative on the 383 protocol whereas [RFC3746] is authoritative on the architecture. 385 4.1. Protocol Framework 387 Figure 1 below is reproduced from the Framework document for clarity. 388 It shows a NE with two CEs and two FEs. 390 --------------------------------------- 391 | ForCES Network Element | 392 -------------- Fc | -------------- -------------- | 393 | CE Manager |---------+-| CE 1 |------| CE 2 | | 394 -------------- | | | Fr | | | 395 | | -------------- -------------- | 396 | Fl | | | Fp / | 397 | | Fp| |----------| / | 398 | | | |/ | 399 | | | | | 400 | | | Fp /|----| | 401 | | | /--------/ | | 402 -------------- Ff | -------------- -------------- | 403 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 404 -------------- | | |------| | | 405 | -------------- -------------- | 406 | | | | | | | | | | 407 ----+--+--+--+----------+--+--+--+----- 408 | | | | | | | | 409 | | | | | | | | 410 Fi/f Fi/f 412 Fp: CE-FE interface 413 Fi: FE-FE interface 414 Fr: CE-CE interface 415 Fc: Interface between the CE Manager and a CE 416 Ff: Interface between the FE Manager and an FE 417 Fl: Interface between the CE Manager and the FE Manager 418 Fi/f: FE external interface 420 Figure 1: ForCES Architectural Diagram 422 The ForCES protocol domain is found in the Fp Reference Points. The 423 Protocol Element configuration reference points, Fc and Ff also play 424 a role in the booting up of the ForCES Protocol. The protocol 425 element configuration (indicated by reference points Fc, Ff, and Fl 426 in [RFC3746] ) is out of scope of the ForCES protocol but is touched 427 on in this document in discussion of FEM and CEM since it is an 428 integral part of the protocol pre-association phase. 430 Figure 2 below shows further breakdown of the Fp interfaces by means 431 of the example of an MPLS QoS enabled Network Element. 433 ------------------------------------------------- 434 | | | | | | | 435 |OSPF |RIP |BGP |RSVP |LDP |. . . | 436 | | | | | | | 437 ------------------------------------------------- CE 438 | ForCES Interface | 439 ------------------------------------------------- 440 ^ ^ 441 | | 442 ForCES | |data 443 control | |packets 444 messages| |(e.g., routing packets) 445 | | 446 v v 447 ------------------------------------------------- 448 | ForCES Interface | 449 ------------------------------------------------- FE 450 | | | | | | | 451 |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | 452 | | | | |fier | | 453 ------------------------------------------------- 455 Figure 2: Examples of CE and FE functions 457 The ForCES Interface shown in Figure 2 constitutes two pieces: the PL 458 and the TML. 460 This is depicted in Figure 3 below. 462 +------------------------------------------------ 463 | CE PL | 464 +------------------------------------------------ 465 | CE TML | 466 +------------------------------------------------ 467 ^ 468 | 469 ForCES | (i.e ForCES data + control 470 PL | packets ) 471 messages | 472 over | 473 specific | 474 TML | 475 encaps | 476 and | 477 transport | 478 | 479 v 480 +------------------------------------------------ 481 | FE TML | 482 +------------------------------------------------ 483 | FE PL | 484 +------------------------------------------------ 486 Figure 3: ForCES Interface 488 The PL is in fact the ForCES protocol. Its semantics and message 489 layout are defined in this document. The TML Layer is necessary to 490 connect two ForCES PLs as shown in Figure 3 above. The TML is out of 491 scope for this document but is within scope of ForCES. This document 492 defines requirements the PL needs the TML to meet. 494 Both the PL and the TML are standardized by the IETF. While only one 495 PL is defined, different TMLs are expected to be standardized. To 496 interoperate the TML at the CE and FE are expected to conform to the 497 same definition. 499 On transmit, the PL delivers its messages to the TML. The local TML 500 delivers the message to the destination TML. On receive, the TML 501 delivers the message to its destination PL. 503 4.1.1. The PL 505 The PL is common to all implementations of ForCES and is standardized 506 by the IETF as defined in this document. The PL is responsible for 507 associating an FE or CE to an NE. It is also responsible for tearing 508 down such associations. An FE uses the PL to transmit various 509 subscribed-to events to the CE PL as well as to respond to various 510 status requests issued from the CE PL. The CE configures both the FE 511 and associated LFBs' operational parameters using the PL. In 512 addition the CE may send various requests to the FE to activate or 513 deactivate it, reconfigure its HA parameterization, subscribe to 514 specific events etc. More details can be found in Section 7. 516 4.1.2. The TML 518 The TML transports the PL messages. The TML is where the issues of 519 how to achieve transport level reliability, congestion control, 520 multicast, ordering, etc. are handled. It is expected that more than 521 one TML will be standardized. The various possible TMLs could vary 522 their implementations based on the capabilities of underlying media 523 and transport. However, since each TML is standardized, 524 interoperability is guaranteed as long as both endpoints support the 525 same TML. All ForCES Protocol Layer implementations MUST be portable 526 across all TMLs, because all TMLs MUST have the top edge semantics 527 defined in this document. 529 4.1.3. The FEM/CEM Interface 531 The FEM and CEM components, although valuable in the setup and 532 configurations of both the PL and TML, are out of scope of the ForCES 533 protocol. The best way to think of them is as configurations/ 534 parameterizations for the PL and TML before they become active (or 535 even at runtime based on implementation). In the simplest case, the 536 FE or CE reads a static configuration file. RFC 3746 has a more 537 detailed description on how the FEM and CEM could be used. The pre- 538 association phase, where the CEM and FEM can be used, are described 539 briefly in Section 4.2.1. 541 An example of typical things the FEM/CEM could configure would be TML 542 specific parameterizations such as: 544 a. How the TML connection should happen (for example what IP 545 addresses to use, transport modes etc); 547 b. The ID for the FE (FEID) or CE (CEID) (which would also be issued 548 during the pre-association phase). 550 c. Security parameterization such as keys etc. 552 d. Connection association parameters 554 Example of connection association parameters this might be: 556 o simple parameters: send up to 3 association messages every 1 557 second 559 o complex parameters: send up to 4 association messages with 560 increasing exponential timeout 562 4.2. ForCES Protocol Phases 564 ForCES, in relation to NEs, involves two phases: the pre-association 565 phase, where configuration/initialization/bootup of the TML and PL 566 layer happens, and the post-association phase where the ForCES 567 protocol operates to manipulate the parameters of the FEs. 569 CE sends Association Setup 570 +---->--->------------>---->---->---->------->----+ 571 | Y 572 ^ | 573 | Y 574 +---+-------+ +-------------+ 575 |FE Pre- | | FE Post- | 576 |Association| CE sends Association Teardown | Association | 577 |Phase |<------- <------<-----<------<-------+ Phase | 578 | | | | 579 +-----------+ +-------------+ 580 ^ Y 581 | | 582 +-<---<------<-----<------<----<---------<------+ 583 FE loses association 585 Figure 4: The FE Protocol Phases 587 In the mandated case, once associated, the FE may forward packets 588 depending on the configuration of its specific LFBs. An FE which is 589 associated to a CE will continue sending packets until it receives an 590 Association teardown message or until it loses association. An 591 unassociated FE MAY continue sending packets when it has a high 592 availability capability. The extra details are explained in 593 Section 8 and not discussed here to allow for a clear explanation of 594 the basics. 596 The FE state transitions are controlled by means of the FE Object LFB 597 FEState component, which is defined in [FE-MODEL] section 5.1 and 598 also explained in Section 7.3.2. 600 The FE initializes in the FEState OperDisable. When the FE is ready 601 to process packets in the data path it transitions itself to the 602 OperEnable state. 604 The CE may decide to pause the FE after it already came up as 605 OperEnable. It does this by setting the FEState to AdminDisable. 606 The FE stays in the AdminDisable state until it is explicitly 607 configured by the CE to transition to the OperEnable state. 609 When the FE loses its association with the CE it may go into the pre- 610 association phase depending on the programmed policy. For the FE to 611 properly complete the transition to the AdminDisable state, it MUST 612 stop Packet forwarding and this may impact multiple LFBS. How this 613 is achieved is outside the scope of this specification. 615 4.2.1. Pre-association 617 The ForCES interface is configured during the pre-association phase. 618 In a simple setup, the configuration is static and is typically read 619 from a saved configuration file. All the parameters for the 620 association phase are well known after the pre-association phase is 621 complete. A protocol such as DHCP may be used to retrieve the 622 configuration parameters instead of reading them from a static 623 configuration file. Note, this will still be considered static pre- 624 association. Dynamic configuration may also happen using the Fc, Ff 625 and Fl reference points (refer to [RFC3746]). Vendors may use their 626 own proprietary service discovery protocol to pass the parameters. 627 Essentially, only guidelines are provided here and the details are 628 left to the implementation. 630 The following are scenarios reproduced from the Framework Document to 631 show a pre-association example. 633 <----Ff ref pt---> <--Fc ref pt-------> 634 FE Manager FE CE Manager CE 635 | | | | 636 | | | | 637 (security exchange) (security exchange) 638 1|<------------>| authentication 1|<----------->|authentication 639 | | | | 640 (FE ID, components) (CE ID, components) 641 2|<-------------| request 2|<------------|request 642 | | | | 643 3|------------->| response 3|------------>|response 644 (corresponding CE ID) (corresponding FE ID) 645 | | | | 646 | | | | 648 Figure 5: Examples of a message exchange over the Ff and Fc reference 649 points 651 <-----------Fl ref pt--------------> | 653 FE Manager FE CE Manager CE 654 | | | | 655 | | | | 656 (security exchange) | | 657 1|<------------------------------>| | 658 | | | | 659 (a list of CEs and their components) | 660 2|<-------------------------------| | 661 | | | | 662 (a list of FEs and their components) | 663 3|------------------------------->| | 664 | | | | 665 | | | | 667 Figure 6: An example of a message exchange over the Fl reference 668 point 670 Before the transition to the association phase, the FEM will have 671 established contact with a CEM component. Initialization of the 672 ForCES interface will have completed, and authentication as well as 673 capability discovery may be complete. Both the FE and CE would have 674 the necessary information for connecting to each other for 675 configuration, accounting, identification, and authentication 676 purposes. To summarize, at the completion of this stage both sides 677 have all the necessary protocol parameters such as timers, etc. The 678 Fl reference point may continue to operate during the association 679 phase and may be used to force a disassociation of an FE or CE. The 680 specific interactions of the CEM and the FEM that are part of the 681 pre-association phase are out of scope; for this reason these details 682 are not discussed any further in this specification. The reader is 683 referred to the framework document [RFC3746] for a slightly more 684 detailed discussion. 686 4.2.2. Post-association 688 In this phase, the FE and CE components communicate with each other 689 using the ForCES protocol (PL over TML) as defined in this document. 690 There are three sub-phases: 692 o Association Setup Stage 694 o Established Stage 695 o Association Lost Stage 697 4.2.2.1. Association Setup Stage 699 The FE attempts to join the NE. The FE may be rejected or accepted. 700 Once granted access into the NE, capabilities exchange happens with 701 the CE querying the FE. Once the CE has the FE capability 702 information, the CE can offer an initial configuration (possibly to 703 restore state) and can query certain components within either an LFB 704 or the FE itself. 706 More details are provided in Section 4.4. 708 On successful completion of this stage, the FE joins the NE and is 709 moved to the Established Stage. 711 4.2.2.2. Established Stage 713 In this stage, the FE is continuously updated or queried. The FE may 714 also send asynchronous event notifications to the CE or synchronous 715 heartbeat notifications if programmed to do so. This stage continues 716 until a termination occurs, either due to loss of connectivity or due 717 to a termination initiated by either the CE or the FE. 719 Refer to the section on protocol scenarios, Section 4.4, for more 720 details. 722 4.2.2.3. Association Lost Stage 724 In this state, both or either the CE or FE declare the other side is 725 no longer associated. The disconnection could be initiated by either 726 party for administrative purposes but may also be driven by 727 operational reasons such as loss of connectivity. 729 A core LFB known as FE Protocol Object (FEPO) is defined (refer to 730 Appendix B and Section 7.3.1). FEPO defines various timers which can 731 be used in conjunction with traffic sensitive heartbeat mechanism 732 (Section 4.3.3) to detect loss of connectivity. 734 The loss of connectivity between TMLs does not indicate a loss of 735 association between respective PL layers. If the TML cannot repair 736 the transport loss before the programmed FEPO timer thresholds 737 associated with the FE is exceeded, then the association between the 738 respective PL layers will be lost. 740 FEPO defines several policies that can be programmed to define 741 behavior upon a detected loss of association. The FEPO's programmed 742 CE failover policy (refer to Section 8, Section 7.3.1, Section 4.3.3 743 and Appendix B) defines what takes place upon loss of association. 745 For this version of the protocol (as defined in this document), the 746 FE, upon re-association, MUST discard any state it has as invalid and 747 retrieve new state. This approach is motivated by a desire for 748 simplicity (as opposed to efficiency). 750 4.3. Protocol Mechanisms 752 Various semantics are exposed to the protocol users via the PL header 753 including: transaction capabilities, atomicity of transactions, two 754 phase commits, batching/parallelization, high availability and 755 failover as well as command pipelines. 757 The EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP 758 (Transaction Phase) flag as defined in the Common Header 759 (Section 6.1) are relevant to these mechanisms. 761 4.3.1. Transactions, Atomicity, Execution and Responses 763 In the master-slave relationship the CE instructs one or more FEs on 764 how to execute operations and how to report the results. 766 This section details the different modes of execution that a CE can 767 order the FE(s) to perform, as defined in Section 4.3.1.1. It also 768 describes the different modes a CE can ask the FE(s) to use for 769 formatting the responses after processing the operations as 770 requested. These modes relate to the transactional two phase 771 commitment operations. 773 4.3.1.1. Execution 775 There are 3 execution modes that can be requested for a batch of 776 operations spanning one or more LFB selectors (refer to 777 Section 7.1.5) in one protocol message. The EM flag defined in the 778 Common Header Section 6.1 selects the execution mode for a protocol 779 message, as below: 781 a. execute-all-or-none 783 b. continue-execute-on-failure 785 c. execute-until-failure 787 4.3.1.1.1. execute-all-or-none 789 When set to this mode of execution, independent operations in a 790 message MAY be targeted at one or more LFB selectors within an FE. 791 All these operations are executed serially and the FE MUST have no 792 execution failure for any of the operations. If any operation fails 793 to execute, then all the previous ones that have been executed prior 794 to the failure will need to be undone. I.e., there is rollback for 795 this mode of operation. 797 Refer to Section 4.3.1.2.2 for how this mode is used in cases of 798 transactions. In such a case, no operation is executed unless a 799 commit is issued by the CE. 801 Care should be taken on how this mode is used because a mis- 802 configuration could result in traffic losses. To add certainty to 803 the success of an operation, one should use this mode in a 804 transactional operation as described in Section 4.3.1.2.2 806 4.3.1.1.2. continue-execute-on-failure 808 If several independent operations are targeted at one or more LFB 809 selectors, execution continues for all operations at the FE even if 810 one or more operations fail. 812 4.3.1.1.3. execute-until-failure 814 In this mode all operations are executed on the FE sequentially until 815 the first failure. The rest of the operations are not executed but 816 operations already completed are not undone. I.e., there is no 817 rollback in this mode of operation. 819 4.3.1.2. Transaction and Atomicity 821 4.3.1.2.1. Transaction Definition 823 A transaction is defined as a collection of one or more ForCES 824 operations within one or more PL messages that MUST meet the ACIDity 825 properties [ACID], defined as: 827 Atomicity: In a transaction involving two or more discrete pieces 828 of information, either all of the pieces are committed 829 or none are. 831 Consistency: A transaction either creates a new and valid state of 832 data, or, if any failure occurs, returns all data to the 833 state it was in before the transaction was started. 835 Isolation: A transaction in process and not yet committed must 836 remain isolated from any other transaction. 838 Durability: Committed data is saved by the system such that, even in 839 the event of a failure and a system restart, the data is 840 available in its correct state. 842 There are cases where the CE knows exact memory and implementation 843 details of the FE such as in the case of an FE-CE pair from the same 844 vendor where the FE-CE pair is tightly coupled. In such a case, the 845 transactional operations may be simplified further by extra 846 computation at the CE. This view is not discussed further other than 847 to mention that it is not disallowed. 849 As defined above, a transaction is always atomic and MAY be 851 a. Within an FE alone 852 Example: updating multiple tables that are dependent on each 853 other. If updating one fails, then any that were already updated 854 must be undone. 856 b. Distributed across the NE 857 Example: updating table(s) that are inter-dependent across 858 several FEs (such as L3 forwarding related tables). 860 4.3.1.2.2. Transaction Protocol 862 By use of the execute mode, as defined in Section 4.3.1.1, the 863 protocol has provided a mechanism for transactional operations within 864 one stand-alone message. The 'execute-all-or-none' mode can meet the 865 ACID requirements. 867 For transactional operations of multiple messages within one FE or 868 across FEs, a classical transactional protocol known as Two Phase 869 Commit (2PC) [2PCREF] is supported by the protocol to achieve the 870 transactional operations utilizing Config messages (Section 7.6.1). 872 The COMMIT and TRCOMP operations in conjunction with the AT and the 873 TP flags in Common Header (Section 6.1) are provided for 2PC-based 874 transactional operations spanning multiple messages. 876 The AT flag, when set, indicates this message belongs to an Atomic 877 Transaction. All messages for a transaction operation must have the 878 AT flag set. If not set, it means the message is a stand-alone 879 message and does not participate in any transaction operation that 880 spans multiple messages. 882 The TP flag indicates the Transaction Phase this message belongs to. 884 There are four (4) possible phases for an transactional operation 885 known as: 887 SOT (Start of Transaction) 889 MOT (Middle of Transaction) 891 EOT (End of Transaction) 893 ABT (Abort) 895 The COMMIT operation is used by the CE to signal to the FE(s) to 896 commit a transaction. When used with an ABT TP flag, the COMMIT 897 operation signals the FE(s) to rollback (i.e un-COMMIT) a previously 898 committed transaction. 900 The TRCOMP operation is a small addition to the classical 2PC 901 approach. TRCOMP is sent by the CE to signal the FE(s) that the 902 transaction they have COMMITed is now over. This allows the FE(s) an 903 opportunity to clear state they may have kept around to perform a 904 rollback (if it became necessary). 906 A transaction operation is started with a message in which the TP 907 flag is set to Start of Transaction (SOT). Multi-part messages, 908 after the first one, are indicated by the Middle of Transaction flag 909 (MOT). All messages from the CE MUST set the AlwaysACK flag 910 (Section 6) to solicit responses from the FE(s). 912 Before the CE issues a commit (described further below) the FE MUST 913 only validate that the operation can be executed but not execute it. 915 Any failure notified by an FE causes the CE to abort the 916 transaction on all FEs involved in the transaction. This is 917 achieved by sending a Config message with an ABT flag and a COMMIT 918 operation. 920 If there are no failures by any participating FE, the transaction 921 commitment phase is signaled from the CE to the FE by an End of 922 Transaction (EOT) configuration message with a COMMIT operation. 924 The FE MUST respond to the CE's EOT message. There are two possible 925 failure scenarios in which the CE MUST abort the transaction (as 926 described above): 928 a. If any participating FE responds with a failure message in 929 relation to the transaction. 931 b. If no response is received from a participating FE within a 932 specified timeout. 934 If all participating FE(s) respond with a success indicator within 935 the expected time, then the CE MUST issue a TRCOMP operation to all 936 participating FEs. An FE MUST NOT respond to a TRCOMP. 938 Note that a transactional operation is generically atomic, therefore 939 it requires that the execute modes of all messages in a transaction 940 operation should always be kept the same and be set to 'execute-all- 941 or-none'. If the EM flag is set to other execute modes, it will 942 result in a transaction failure. 944 As noted above, a transaction may span multiple messages. It is up 945 to the CE to keep track of the different outstanding messages making 946 up a transaction. As an example, the correlator field could be used 947 to mark transactions and a sequence field to label the different 948 messages within the same atomic transaction, but this is out of scope 949 and up to implementations. 951 4.3.1.2.3. Recovery 953 Any of the participating FEs, or the CE, or the associations between 954 them, may fail after the EOT response message has been sent by the FE 955 but before the CE has received all the responses, e.g. if the EOT 956 response never reaches the CE. 958 In this protocol revision, as indicated in Section 4.2.2.3, an FE 959 losing an association would be required to get entirely new state 960 from the newly associated CE upon a re-association. Although this 961 approach is simplistic and provides likeliness of loosing datapath 962 traffic, it is a design choice to avoid the additional complexity of 963 managing graceful restarts. The HA mechanisms (Section 8) are 964 provided to allow for a continuous operation in case of FE failures. 966 Flexibility is provided on how to react when an FE looses 967 association. This is dictated by the CE Failover policy (refer to 968 Section 8 and Section 7.3). 970 4.3.1.2.4. Transaction Messaging Example 972 This section illustrates an example of how a successful two phase 973 commit between a CE and an FE would look like in the simple case. 975 FE PL CE PL 977 | | 978 | (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc | 979 |<-----------------------------------------------------| 980 | | 981 | (2) ACKnowledge | 982 |----------------------------------------------------->| 983 | | 984 | (3) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc | 985 |<-----------------------------------------------------| 986 | | 987 | (4) ACKnowledge | 988 |----------------------------------------------------->| 989 | | 990 | (5) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc | 991 |<-----------------------------------------------------| 992 | | 993 | (6) ACKnowledge | 994 |----------------------------------------------------->| 995 . . 996 . . 997 . . 998 . . 999 | | 1000 | (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT | 1001 |<-----------------------------------------------------| 1002 | | 1003 | (N+1)Config-response, ACKnowledge, OP=COMMIT-RESPONSE| 1004 |----------------------------------------------------->| 1005 | | 1006 | (N+2) Config, OP=TRCOMP | 1007 |<-----------------------------------------------------| 1009 Figure 7: Example of a two phase commit 1011 For the scenario illustrated above: 1013 o In step #1, the CE issues a Config message with an operation of 1014 choice like a DEL or SET. The transactional flag are set to 1015 indicate a Start of Transaction (SOT), Atomic Transaction (AT), 1016 execute-all-or-none. 1018 o The FE validates that it can execute the request successfully and 1019 then issues an acknowledgment back to the the CE in step #2. 1021 o In step #3, the same sort of construct as in step #1 is repeated 1022 by the CE with the transaction flag changed to Middle of 1023 Transaction(MOT). 1025 o The FE validates that it can execute the request successfully and 1026 then issues an acknowledgment back to the the CE in step #4. 1028 o The CE-FE exchange continues in the same manner until all the 1029 operations and their parameters are transferred to the FE. This 1030 happens in step #(N-1). 1032 o In step #N, the CE issues a commit. A commit is a config message 1033 with an operation of type COMMIT. The transactional flags are set 1034 to End of Transaction (EOT). Essentially, this is an "empty" 1035 message asking the FE to execute all the operations it has 1036 gathered since the beginning of the transaction (message #1). 1038 o The FE at this point executes the full transaction. It then 1039 issues an acknowledgment back to the the CE in step #(N+1) which 1040 contains a COMMIT-RESPONSE. 1042 o The CE in this case has the simple task of issuing a TRCOMP 1043 operation the the FE in step #(N+2) 1045 4.3.2. Scalability 1047 It is desirable that the PL not become the bottleneck when larger 1048 bandwidth pipes become available. To pick a hypothetical example in 1049 today's terms, if a 100Gbps pipe is available and there is sufficient 1050 work then the PL should be able to take advantage of this and use all 1051 of the 100Gbps pipe. Two mechanisms have been provided to achieve 1052 this. The first one is batching and the second one is a command 1053 pipeline. 1055 Batching is the ability to send multiple commands (such as Config) in 1056 one Protocol Data Unit (PDU). The size of the batch will be affected 1057 by, amongst other things, the path MTU. The commands may be part of 1058 the same transaction or may be part of unrelated transactions that 1059 are independent of each other. 1061 Command pipelining allows for pipelining of independent transactions 1062 which do not affect each other. Each independent transaction could 1063 consist of one or more batches. 1065 4.3.2.1. Batching 1067 There are several batching levels at different protocol hierarchies. 1069 o multiple PL PDUs can be aggregated under one TML message 1070 o multiple LFB classes and instances (as indicated in the LFB 1071 selector) can be addressed within one PL PDU 1073 o Multiple operations can be addressed to a single LFB class and 1074 instance 1076 4.3.2.2. Command Pipelining 1078 The protocol allows any number of messages to be issued by the CE 1079 before the corresponding acknowledgments (if requested) have been 1080 returned by the FE. Hence pipelining is inherently supported by the 1081 protocol. Matching responses with requests messages can be done 1082 using the correlator field in the message header. 1084 4.3.3. Heartbeat Mechanism 1086 Heartbeats (HB) between FEs and CEs are traffic sensitive. An HB is 1087 sent only if no PL traffic is sent between the CE and FE within a 1088 configured interval. This has the effect of reducing the amount of 1089 HB traffic in the case of busy PL periods. 1091 An HB can be sourced by either the CE or FE. When sourced by the CE, 1092 a response can be requested (similar to the ICMP ping protocol). The 1093 FE can only generate HBs in the case of being configured to do so by 1094 the CE. Refer to Section 7.3.1 and Section 7.10 for details. 1096 4.3.4. FE Object and FE Protocol LFBs 1098 All PL messages operate on LFB constructs, as this provides more 1099 flexibility for future enhancements. This means that maintenance and 1100 configurability of FEs, NE, as well as the ForCES protocol itself 1101 must be expressed in terms of this LFB architecture. For this reason 1102 special LFBs are created to accommodate this need. 1104 In addition, this shows how the ForCES protocol itself can be 1105 controlled by the very same type of structures (LFBs) it uses to 1106 control functions such as IP forwarding, filtering, etc. 1108 To achieve this, the following specialized LFBs are introduced: 1110 o FE Protocol LFB which is used to control the ForCES protocol. 1112 o FE Object LFB which is used to control attributes relative to the 1113 FE itself. Such attributes include FEState [FE-MODEL], vendor, 1114 etc. 1116 These LFBs are detailed in Section 7.3. 1118 4.4. Protocol Scenarios 1120 This section provides a very high level description of sample message 1121 sequences between a CE and FE. For protocol message encoding refer 1122 to Section 6.1 and for the semantics of the protocol refer to 1123 Section 4.3. 1125 4.4.1. Association Setup State 1127 The associations among CEs and FEs are initiated via Association 1128 setup message from the FE. If a setup request is granted by the CE, 1129 a successful setup response message is sent to the FE. If CEs and 1130 FEs are operating in an insecure environment then the security 1131 associations have to be established between them before any 1132 association messages can be exchanged. The TML MUST take care of 1133 establishing any security associations. 1135 This is typically followed by capability query, topology query, etc. 1136 When the FE is ready to start processing the data path, it sets the 1137 FEO FEState component to OperEnable (Refer to [FE-MODEL] for details) 1138 and reports it to the CE as such when it is first queried. Typically 1139 the FE is expected to be ready to process the data path before it 1140 associates, but there maybe rare cases where it needs time do some 1141 pre-processing - in such a case the FE will start in the OperDisable 1142 state and when it is ready will transition to OperEnable state. An 1143 example of an FE starting in the OperDisable then transitioning to 1144 OperEnable is illustrated in Figure 8. The CE could at any time also 1145 disable the FEs datapath operations by setting the FEState to 1146 AdminDisable. The FE MUST NOT process packets during this state 1147 unless the CE sets the state back to OperEnable. These sequences of 1148 messages are illustrated in Figure 8 below. 1150 FE PL CE PL 1152 | | 1153 | Asso Setup Req | 1154 |---------------------->| 1155 | | 1156 | Asso Setup Resp | 1157 |<----------------------| 1158 | | 1159 | LFBx Query capability | 1160 |<----------------------| 1161 | | 1162 | LFBx Query Resp | 1163 |---------------------->| 1164 | | 1165 | FEO Query (Topology) | 1166 |<----------------------| 1167 | | 1168 | FEO Query Resp | 1169 |---------------------->| 1170 | | 1171 | FEO OperEnable Event | 1172 |---------------------->| 1173 | | 1174 | Config FEO Adminup | 1175 |<----------------------| 1176 | | 1177 | FEO Config-Resp | 1178 |---------------------->| 1179 | | 1181 Figure 8: Message exchange between CE and FE to establish an NE 1182 association 1184 On successful completion of this state, the FE joins the NE. 1186 4.4.2. Association Established state or Steady State 1188 In this state, the FE is continuously updated or queried. The FE may 1189 also send asynchronous event notifications to the CE, synchronous 1190 heartbeat messages, or packet redirect message to the CE. This 1191 continues until a termination (or deactivation) is initiated by 1192 either the CE or FE. Figure 9 below, helps illustrate this state. 1194 FE PL CE PL 1196 | | 1197 | Heart Beat | 1198 |<---------------------------->| 1199 | | 1200 | Heart Beat | 1201 |----------------------------->| 1202 | | 1203 | Config-set LFBy (Event sub.) | 1204 |<-----------------------------| 1205 | | 1206 | Config Resp LFBy | 1207 |----------------------------->| 1208 | | 1209 | Config-set LFBx Attr | 1210 |<-----------------------------| 1211 | | 1212 | Config Resp LFBx | 1213 |----------------------------->| 1214 | | 1215 |Config-Query LFBz (Stats) | 1216 |<--------------------------- -| 1217 | | 1218 | Query Resp LFBz | 1219 |----------------------------->| 1220 | | 1221 | FE Event Report | 1222 |----------------------------->| 1223 | | 1224 | Config-Del LFBx Attr | 1225 |<-----------------------------| 1226 | | 1227 | Config Resp LFBx | 1228 |----------------------------->| 1229 | | 1230 | Packet Redirect LFBx | 1231 |----------------------------->| 1232 | | 1233 | Heart Beat | 1234 |<-----------------------------| 1235 . . 1236 . . 1237 | | 1239 Figure 9: Message exchange between CE and FE during steady-state 1240 communication 1242 Note that the sequence of messages shown in the figure serve only as 1243 examples and the message exchange sequences could be different from 1244 what is shown in the figure. Also, note that the protocol scenarios 1245 described in this section do not include all the different message 1246 exchanges that would take place during failover. That is described 1247 in the HA section (Section 8) . 1249 5. TML Requirements 1251 The requirements below are expected to be delivered by the TML. This 1252 text does not define how such mechanisms are delivered. As an 1253 example they could be defined to be delivered via hardware or between 1254 2 or more TML processes on different CEs or FEs in protocol level 1255 schemes. 1257 Each TML must describe how it contributes to achieving the listed 1258 ForCES requirements. If for any reason a TML does not provide a 1259 service listed below a justification needs to be provided. 1261 Implementations that support the ForCES Protocol Specification MUST 1262 IMPLEMENT [SCTP-TML]. Note that additional TMLs might be specified 1263 in the future, and if a new TML defined in the future that meets the 1264 requirements listed here proves to be better, then the MUST IMPLEMENT 1265 TML may redefined. 1267 1. Reliability 1268 As defined by [RFC3654], section 6 requirement #6. 1270 2. Security 1271 TML provides security services to the ForCES PL. Because a 1272 ForCES PL is used to operate an NE, attacks designed to confuse, 1273 disable, or take information from a ForCES-based NE may be seen 1274 as a prime objective during a network attack. 1276 An attacker in a position to inject false messages into a PL 1277 stream can either affect the FE's treatment of the data path 1278 (example by falsifying control data reported as coming from the 1279 CE), or the CE itself (by modifying events or responses reported 1280 as coming from the FE); for this reason, CE and FE node 1281 authentication and TML Message authentication is important. 1283 The PL messages may also contain information of value to an 1284 attacker, including information about the configuration of the 1285 network, encryption keys and other sensitive control data, so 1286 care must be taken to confine their visibility to authorized user 1288 * The TML must provide a mechanism to authenticate ForCES CEs 1289 and FEs in order to prevent the participation of unauthorized 1290 CEs and unauthorized FEs in the control and data path 1291 processing of a ForCES NE. 1293 * The TML SHOULD provide a mechanism to ensure message 1294 authentication of PL data transferred from the CE to FE (and 1295 vice-versa) in order to prevent the injection of incorrect 1296 data into PL messages. 1298 * The TML SHOULD provide a mechanism to ensure the 1299 confidentiality of data transferred from the ForCES PL, in 1300 order to prevent disclosure of PL level information 1301 transported via the TML. 1303 The TML SHOULD provide these services by employing TLS or IPSEC. 1305 3. Congestion control 1306 The transport congestion control scheme used by the TML needs to 1307 be defined. The congestion control mechanism defined by the TML 1308 MUST prevent transport congestive collapse [RFC2914] on either 1309 the FE or CE side. 1311 4. Uni/multi/broadcast addressing/delivery, if any 1312 If there is any mapping between PL and TML level uni/multi/ 1313 broadcast addressing it needs to be defined. 1315 5. HA decisions 1316 It is expected that availability of transport links is the TML's 1317 responsibility. However, based upon its configuration, the PL 1318 may wish to participate in link failover schemes and therefore 1319 the TML must support this capability. 1320 Please refer to Section 8 for details. 1322 6. Encapsulations used 1323 Different types of TMLs will encapsulate the PL messages on 1324 different types of headers. The TML needs to specify the 1325 encapsulation used. 1327 7. Prioritization 1328 It is expected that the TML will be able to handle up to 8 1329 priority levels needed by the PL and will provide preferential 1330 treatment. 1332 While the TML needs to define how this is achieved, it should be 1333 noted that the requirement for supporting up to 8 priority levels 1334 does not mean that the underlying TML MUST be capable of 1335 providing up to 8 actual priority levels. In the event that the 1336 underlying TML layer does not have support for 8 priority levels, 1337 the supported priority levels should be divided between the 1338 available TML priority levels. For example, if the TML only 1339 supports 2 priority levels, the 0-3 could go in one TML priority 1340 level, while 4-7 could go in the other. 1342 The TML MUST NOT reorder config packets with the same priority. 1344 8. Protection against DoS attacks 1345 As described in RFC 3654, section 6 1347 5.1. TML Parameterization 1349 It is expected that it should be possible to use a configuration 1350 reference point, such as the FEM or the CEM, to configure the TML. 1352 Some of the configured parameters may include: 1354 o PL ID 1356 o Connection Type and associated data. For example if a TML uses 1357 IP/TCP/UDP, then parameters such as TCP and UDP port and IP 1358 addresses need to be configured. 1360 o Number of transport connections 1362 o Connection capability, such as bandwidth, etc. 1364 o Allowed/supported connection QoS policy (or congestion control 1365 policy) 1367 6. Message Encapsulation 1369 All PL PDUs start with a common header [Section 6.1] followed by a 1370 one or more TLVs [Section 6.2] which may nest other TLVs 1371 [Section 6.2.1]. All fields are in network byte order. 1373 6.1. Common Header 1375 0 1 2 3 1376 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 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 |version| rsvd | Message Type | Length | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | Source ID | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 | Destination ID | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | Correlator[63:32] | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | Correlator[31:0] | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | Flags | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 Figure 10: Common Header 1393 The message is 32 bit aligned. 1395 Version (4 bit): 1396 Version number. Current version is 1. 1398 rsvd (4 bit): 1399 Unused at this point. A receiver should not interpret this 1400 field. Senders MUST set it to zero and receivers MUST ignore 1401 this field. 1403 Message Type (8 bits): 1404 Commands are defined in Section 7. 1406 Length (16 bits): 1407 length of header + the rest of the message in DWORDS (4 byte 1408 increments). 1410 Source ID (32 bit): 1412 Dest ID (32 bit): 1414 * Each of the source and destination IDs are 32 bit IDs which 1415 are unique NE-wide and which identify the termination points 1416 of a ForCES PL message. 1418 * IDs allow multi/broad/unicast addressing with the following 1419 approach: 1421 a. A split address space is used to distinguish FEs from 1422 CEs. Even though in a large NE there are typically two 1423 or more orders of magnitude more FEs than CEs, the 1424 address space is split uniformly for simplicity. 1426 b. The address space allows up to 2^30 (over a billion) CEs 1427 and the same amount of FEs. 1429 0 1 2 3 1430 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 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 |TS | sub-ID | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 Figure 11: ForCES ID Format 1437 c. The 2 most significant bits called Type Switch (TS) are 1438 used to split the ID space as follows: 1440 TS Corresponding ID range Assignment 1441 -- ---------------------- ---------- 1442 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 1443 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 1444 0b10 0x80000000 to 0xBFFFFFFF reserved 1445 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16) 1446 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 1447 0b11 0xFFFFFFFD all CEs broadcast 1448 0b11 0xFFFFFFFE all FEs broadcast 1449 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast 1451 Figure 12: Type Switch ID Space 1453 * Multicast or broadcast IDs are used to group endpoints (such 1454 as CEs and FES). As an example one could group FEs in some 1455 functional group, by assigning a multicast ID. Likewise, 1456 subgroups of CEs that act, for instance, in a back-up mode 1457 may be assigned a multicast ID to hide them from the FE. 1459 + Multicast IDs can be used for both source or destination 1460 IDs. 1462 + Broadcast IDs can be used only for destination IDs. 1464 * This document does not discuss how a particular multicast ID 1465 is associated to a given group though it could be done via 1466 configuration process. The list of IDs an FE owns or is part 1467 of are listed on the FE Object LFB. 1469 Correlator (64 bits) 1470 This field is set by the CE to correlate ForCES Request Messages 1471 with the corresponding Response messages from the FE. 1472 Essentially it is a cookie. The correlator is handled 1473 transparently by the FE, i.e., for a particular Request message 1474 the FE MUST assign the same correlator value in the corresponding 1475 Response message. In the case where the message from the CE does 1476 not elicit a response, this field may not be useful. 1478 The correlator field could be used in many implementations 1479 specific ways by the CE. For example, the CE could split the 1480 correlator into a 32-bit transactional identifier and 32-bit 1481 message sequence identifier. Another example is a 64-bit pointer 1482 to a context block. All such implementation specific use of the 1483 correlator is outside the scope of this specification. 1485 It should be noted that the correlator is transmitted on the 1486 network as if it were a 64 bit unsigned integer with the leftmost 1487 or most significant octet (bits 63-56) transmitted first. 1489 Whenever the correlator field is not relevant, because no message 1490 is expected, the correlator field is set to 0. 1492 Flags(32 bits): 1493 Identified so far: 1495 0 1 2 3 1496 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 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | | | | | | | | 1499 |ACK| Pri |Rsr |EM |A|TP | Reserved | 1500 | | | vd. | |T| | | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 Figure 13: Header Flags 1504 - ACK: ACK indicator (2 bit) 1505 The ACK indicator flag is only used by the CE when sending a 1506 Config Message (Section 7.6.1) or a HB message (Section 7.10) 1507 to indicate to the message receiver whether or not a response 1508 is required by the sender. Note that for all other messages 1509 than the Config Message or the HB Message this flag MUST be 1510 ignored. 1512 The flag values are defined as below: 1514 'NoACK' (0b00) - to indicate that the message receiver 1515 MUST NOT send any response message back to this message 1516 sender. 1518 'SuccessACK'(0b01) - to indicate the message receiver 1519 MUST send a response message back only when the message 1520 has been successfully processed by the receiver. 1522 'FailureACK'(0b10) - to indicate the message receiver 1523 MUST send a response message back only when there is 1524 failure by the receiver in processing (executing) the 1525 message. In other words, if the message can be processed 1526 successfully, the sender will not expect any response 1527 from the receiver. 1529 'AlwaysACK' (0b11) - to indicate the message receiver 1530 MUST send a response message. 1532 Note that in above definitions, the term success implies a 1533 complete execution without any failure of the message. 1534 Anything else than a complete successful execution is defined 1535 as a failure for the message processing. As a result, for 1536 the execution modes (defined in Section 4.3.1.1) like 1537 execute-all-or-none, execute-until-failure, and continue- 1538 execute-on-failure, if any single operation among several 1539 operations in the same message fails, it will be treated as a 1540 failure and result in a response if the ACK indicator has 1541 been set to 'FailureACK' or 'AlwaysACK'. 1543 Also note that, other than in Config and HB Messages, 1544 requirements for responses of messages are all given in a 1545 default way rather than by ACK flags. The default 1546 requirements of these messages and the expected responses are 1547 summarized below. Detailed descriptions can be found in the 1548 individual message definitions: 1550 + Association Setup Message always expects a response. 1552 + Association Teardown Message, and Packet Redirect 1553 Message, never expect responses. 1555 + Query Message always expects a response. 1557 + Response message never expects further responses. 1559 - Pri: Priority (3 bits) 1560 ForCES protocol defines 8 different levels of priority (0-7). 1561 The priority level can be used to distinguish between 1562 different protocol message types as well as between the same 1563 message type. The higher the priority value, the more 1564 important the PDU is. For example, the REDIRECT packet 1565 message could have different priorities to distinguish 1566 between routing protocols packets and ARP packets being 1567 redirected from FE to CE. The Normal priority level is 1. 1568 The different priorities imply messages could be re-ordered; 1569 however, re-ordering is undesirable when it comes to a set of 1570 messages within a transaction and caution should be exercised 1571 to avoid this from happening. 1573 - EM: Execution Mode (2 bits) 1574 There are 3 execution modes refer to Section 4.3.1.1 for 1575 details. 1577 Reserved..................... (0b00) 1579 `execute-all-or-none` ....... (0b01) 1581 `execute-until-failure` ..... (0b10) 1583 `continue-execute-on-failure` (0b11) 1585 - AT: Atomic Transaction (1 bit) 1586 This flag indicates if the message is stand-alone message or 1587 one of multiple messages that belongs to 2PC transaction 1588 operations. See Section 4.3.1.2.2 for details. 1590 Stand-alone message ......... (0b0) 1591 2PC transaction message ..... (0b1) 1593 - TP: Transaction Phase (2 bits) 1594 A message from the CE to the FE within a transaction could be 1595 indicative of the different phases the transaction is in. 1596 Refer to Section 4.3.1.2.2 for details. 1598 SOT (start of transaction) ..... (0b00) 1600 MOT (Middle of transaction) .... (0b01) 1602 EOT (end of transaction) ........(0b10) 1604 ABT (abort) .....................(0b11) 1606 6.2. Type Length Value (TLV) Structuring 1608 TLVs are extensively used by the ForCES protocol. TLVs have some 1609 very nice properties which make them a good candidate for encoding 1610 the XML definitions of the LFB class model. These are: 1612 o Providing for binary type-value encoding that is close to the XML 1613 string tag-value scheme. 1615 o Allowing for fast generalized binary-parsing functions. 1617 o Allowing for forward and backward tag compatibility. This is 1618 equivalent to the XML approach i.e old applications can ignore new 1619 TLVs and newer applications can ignore older TLVs. 1621 0 1 2 3 1622 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 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | TLV Type | TLV Length | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | Value (Essentially the TLV Data) | 1627 ~ ~ 1628 ~ ~ 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 Figure 14: TLV Representation 1633 TLV Type (16): 1634 The TLV type field is two octets, and semantically 1635 indicates the type of data encapsulated within the 1636 TLV. 1638 TLV Length (16): 1639 The TLV length field is two octets, and includes the 1640 length of the TLV type (2 octets), TLV Length (2 1641 octets), and the length of the TLV data found in the 1642 value field, in octets. Note that this length is 1643 the actual length of the value, before any padding 1644 for alignment is added. 1646 TLV Value (variable): 1647 The TLV value field carries the data. For 1648 extensibility, the TLV value may in fact be a TLV. 1649 Padding is required when the length is not a 1650 multiple of 32 bits, and is the minimum number of 1651 octets required to bring the TLV to a multiple of 32 1652 bits. The length of the value before padding is 1653 indicated by the TLV Length field. Note: The value 1654 field could be empty which implies the minimal 1655 length a TLV could be is 4 (length of "T" field and 1656 length of "L" field). 1658 6.2.1. Nested TLVs 1660 TLV values can be other TLVs. This provides the benefits of protocol 1661 flexibility (being able to add new extensions by introducing new TLVs 1662 when needed). The nesting feature also allows for a conceptual 1663 optimization with the XML LFB definitions to binary PL representation 1664 (represented by nested TLVs). 1666 6.2.2. Scope of the T in TLV 1668 The "Type" values in the TLV are global in scope. This means that 1669 wherever TLVs occur in the PDU, a specific Type value refers to the 1670 same Type of TLV. This is a design choice that was made to ease 1671 debugging of the protocol. 1673 6.3. ILV 1675 A slight variation of the TLV known as the ILV. This sets the type 1676 ("T") to be a 32-bit local index that refers to a ForCES component 1677 ID. (refer to Section 6.4.1). 1679 The ILV length field is a 4 octet integer, and includes the length of 1680 the ILV type (4 octets), ILV Length (4 octets), and the length of the 1681 ILV data found in the value field, in octets. Note that, as in the 1682 case of the TLV, this length is the actual length of the value, 1683 before any padding for alignment is added. 1685 0 1 2 3 1686 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 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | Identifier | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 | Length | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Value | 1693 . . 1694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 Figure 15: ILV Representation 1698 It should be noted that the "I" values are of local scope and are 1699 defined by the data declarations from the LFB definition. Refer to 1700 Section 7.1.8 for discussions on usage of ILVs. 1702 6.4. Important Protocol encapsulations 1704 In this section, we review a few encapsulation concepts that are used 1705 by the ForCES protocol for its operations. 1707 We briefly re-introduce two concepts, Paths and Keys, from the model 1708 draft [FE-MODEL] in order to provide context. The reader is referred 1709 to [FE-MODEL] for a lot of the finer details. 1711 For readability reasons, we introduce the encapsulation schemes that 1712 are used to carry content in a protocol message, namely FULLDATA-TLV, 1713 SPARSEDATA-TLV, and RESULT-TLV. 1715 6.4.1. Paths 1717 The model draft [FE-MODEL] defines an XML-based language that allows 1718 for a formal definition of LFBs. This is similar to the relationship 1719 between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB 1720 and ASN.1 being analogous to the XML model language). Any entity 1721 that the CE configures on an FE MUST be formally defined in an LFB. 1722 These entities could be scalars (e.g., a 32-bit IPv4 address) or 1723 vectors (such as a nexthop table). Each entity within the LFB is 1724 given a numeric 32-bit identifier known as an "component id". This 1725 scheme allows the attribute to be "addressed" in a protocol 1726 construct. 1728 These addressable entities could be hierarchical (e.g., a table 1729 column or a cell within a table row). In order to address 1730 hierarchical data, the concept of a path is introduced by the model 1731 [FE-MODEL]. A path is a series of 32-bit component IDs which are 1732 typically presented in a dot-notation (e.g., 1.2.3.4). Section 1733 (Section 7) formally defines how paths are used to reference data 1734 that is being encapsulated within a protocol message. 1736 6.4.2. Keys 1738 The model draft [FE-MODEL] defines two ways to address table rows. 1739 The standard/common mechanism is to allow table rows to be referenced 1740 by a 32-bit index. The secondary mechanism is via Keys which allow 1741 for content addressing. An example key is a multi-field content key 1742 that uses the IP address and prefix length to uniquely reference an 1743 IPv4 routing table row. In essence, while the common scheme to 1744 address a table row is via its table index, a table row's path could 1745 be derived from a key. The KEYINFO-TLV (Section 7) is used to carry 1746 the data that is used to do the lookup. 1748 6.4.3. DATA TLVs 1750 Data from or to the FE is carried in two types of TLVs: FULLDATA-TLV 1751 and SPARSEDATA-TLV. Responses to operations executed by the FE are 1752 carried in RESULT-TLVs. 1754 In FULLDATA-TLV, the data is encoded in such a way that a receiver of 1755 such data, by virtue of being armed with knowledge of the path and 1756 the LFB definition, can infer or correlate the TLV "Value" contents. 1757 This is essentially an optimization that helps reduce the amount of 1758 description required for the transported data in the protocol 1759 grammar. Refer to Appendix C for an example of FULLDATA-TLVs. 1761 A number of operations in ForCES will need to reference optional data 1762 within larger structures. The SPARSEDATA-TLV encoding is provided to 1763 make it easier to encapsulate optionally appearing data components. 1764 Refer to Appendix C for an example of SPARSEDATA-TLV. 1766 RESULT-TLVs carry responses back from the FE based on a config issued 1767 by the CE. Refer to Appendix C for examples of RESULT-TLVs and 1768 Section 7.1.7 for layout. 1770 6.4.4. Addressing LFB entities 1772 Section 6.4.1 and Section 6.4.2 discuss how to target an entity 1773 within an LFB. However, the addressing mechanism used requires that 1774 an LFB type and instance is selected first. The LFB Selector is used 1775 to select an LFB type and instance being targeted. Section 1776 (Section 7) goes into more details; for our purpose, we illustrate 1777 this concept using Figure 16 below. More examples of layouts can be 1778 found reading further into the text (Example: Figure 21). 1780 main hdr (Message type: example "config") 1781 | 1782 | 1783 | 1784 +- T = LFBselect 1785 | 1786 +-- LFBCLASSID (unique per LFB defined) 1787 | 1788 | 1789 +-- LFBInstance (runtime configuration) 1790 | 1791 +-- T = An operation TLV describes what we do to an entity 1792 | //Refer to the OPER-TLV values enumerated below 1793 | //the TLVs that can be used for operations 1794 | 1795 | 1796 +--+-- one or more path encodings to target an entity 1797 | // Refer to the discussion on keys and paths 1798 | 1799 | 1800 +-- The associated data, if any, for the entity 1801 // Refer to discussion on FULL/SPARSE DATA TLVs 1803 Figure 16: Entity Addressing 1805 7. Protocol Construction 1807 A protocol layer PDU consists of a Common Header (defined in Section 1808 Section 6.1 ) and a message body. The Common Header is followed by a 1809 message-type-specific message body. Each message body is formed from 1810 one or more top-level TLVs. A top-level TLV may contain one or more 1811 sub-TLVs; these sub-TLVs are described in this document as OPER-TLVs, 1812 because they describe an operation to be done. 1814 +-------------+---------------+---------------------+---------------+ 1815 | Message | Top-Level TLV | OPER-TLV(s) | Reference | 1816 | Name | | | | 1817 +-------------+---------------+---------------------+---------------+ 1818 | Association | (LFBselect)* | REPORT | Section 7.5.2 | 1819 | Setup | | | | 1820 | | | | | 1821 | Association | ASRresult-TLV | none | Section 7.5.2 | 1822 | Setup | | | | 1823 | Response | | | | 1824 | | | | | 1825 | Association | ASTreason-TLV | none | Section 7.5.3 | 1826 | Teardown | | | | 1827 | | | | | 1828 | Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 | 1829 | | | DEL | COMMIT | | | 1830 | | | TRCOMP)+ | | 1831 | | | | | 1832 | Config | (LFBselect)+ | (SET-RESPONSE | | Section 7.6.2 | 1833 | Response | | SET-PROP-RESPONSE | | | 1834 | | | DEL-RESPONSE | | | 1835 | | | COMMIT-RESPONSE)+ | | 1836 | | | | | 1837 | Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 | 1838 | | | | | 1839 | Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 | 1840 | Response | | GET-PROP-RESPONSE)+ | | 1841 | | | | | 1842 | Event | LFBselect | REPORT | Section 7.8 | 1843 | Notifi- | | | | 1844 | cation | | | | 1845 | | | | | 1846 | Packet | REDIRECT-TLV | none | Section 7.9 | 1847 | Redirect | | | | 1848 | | | | | 1849 | Heartbeat | none | none | Section 7.10 | 1850 +-------------+---------------+---------------------+---------------+ 1852 Table 1 1854 The different messages are illustrated in Table 1. The different 1855 message type numerical values are defined in Appendix A.1. All the 1856 TLVs values are defined in Appendix A.2. 1858 An LFBselect TLV (refer to Section 7.1.5) contains the LFB Classid 1859 and LFB Instance being referenced as well as the OPER-TLV(s) being 1860 applied to that reference. 1862 Each type of OPER-TLV is constrained as to how it describes the paths 1863 and selectors of interest. The following BNF describes the basic 1864 structure of an OPER-TLV and Table 2 gives the details for each type 1866 OPER-TLV := 1*PATH-DATA-TLV 1867 PATH-DATA-TLV := PATH [DATA] 1868 PATH := flags IDcount IDs [SELECTOR] 1869 SELECTOR := KEYINFO-TLV 1870 DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / 1871 1*PATH-DATA-TLV 1872 KEYINFO-TLV := KeyID FULLDATA-TLV 1873 FULLDATA-TLV := encoded data component which may nest 1874 further FULLDATA-TLVs 1875 SPARSEDATA-TLV := encoded data that may have optionally 1876 appearing components 1877 RESULT-TLV := Holds result code and optional FULLDATA-TLV 1879 Figure 17: BNF of OPER-TLV 1881 o PATH-DATA-TLV identifies the exact component targeted and may have 1882 zero or more paths associated with it. The last PATH-DATA-TLV in 1883 the case of nesting of paths via the DATA construct in the case of 1884 SET, SET-PROP requests and GET-RESPONSE/GET-PROP-RESPONSE is 1885 terminated by encoded data or response in the form of either 1886 FULLDATA-TLV or SPARSEDATA-TLV or RESULT-TLV. 1888 o PATH provides the path to the data being referenced. 1890 * flags (16 bits) are used to further refine the operation to be 1891 applied on the Path. More on these later. 1893 * IDcount(16 bit): count of 32 bit IDs 1895 * IDs: zero or more 32bit IDs (whose count is given by IDcount) 1896 defining the main path. Depending on the flags, IDs could be 1897 field IDs only or a mix of field and dynamic IDs. Zero is used 1898 for the special case of using the entirety of the containing 1899 context as the result of the path. 1901 o SELECTOR is an optional construct that further defines the PATH. 1902 Currently, the only defined selector is the KEYINFO-TLV, used for 1903 selecting an array entry by the value of a key field. The 1904 presence of a SELECTOR is correct only when the flags also 1905 indicate its presence. A mismatch is a protocol format error. 1907 o A KEYINFO-TLV contains information used in content keying. 1909 * A KeyID is used in a KEYINFO-TLV. It indicates which key for 1910 the current array is being used as the content key for array 1911 entry selection. 1913 * The key's data is the data to look for in the array, in the 1914 fields identified by the key field. The information is encoded 1915 according to the rules for the contents of a FULLDATA-TLV, and 1916 represent the field or fields which make up the key identified 1917 by the KeyID. 1919 o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV or 1 1920 or more further PATH-DATA selection. FULLDATA-TLV and SPARSEDATA- 1921 TLV are only allowed on SET or SET-PROP requests, or on responses 1922 which return content information (GET-RESPONSE for example). 1923 PATH-DATA may be included to extend the path on any request. 1925 * Note: Nested PATH-DATA-TLVs are supported as an efficiency 1926 measure to permit common subexpression extraction. 1928 * FULLDATA-TLV and SPARSEDATA-TLV contain "the data" whose path 1929 has been selected by the PATH. Refer to Section 7.1 for 1930 details. 1932 * The following table summarizes the applicability and 1933 restrictions of the FULL/SPARSEDATA-TLVs and the RESULT-TLV to 1934 the OPER-TLVs. 1936 +-------------------+-------------------------------+---------------+ 1937 | OPER-TLV | DATA TLV | RESULT-TLV | 1938 +-------------------+-------------------------------+---------------+ 1939 | SET | (FULLDATA-TLV | | none | 1940 | | SPARSEDATA-TLV)+ | | 1941 | | | | 1942 | SET-PROP | (FULLDATA-TLV | | none | 1943 | | SPARSEDATA-TLV)+ | | 1944 | | | | 1945 | SET-RESPONSE | none | (RESULT-TLV)+ | 1946 | | | | 1947 | SET-PROP-RESPONSE | none | (RESULT-TLV)+ | 1948 | | | | 1949 | DEL | (FULLDATA-TLV | | none | 1950 | | SPARSEDATA-TLV)+ | | 1951 | | | | 1952 | DEL-RESPONSE | none | (RESULT-TLV)+ | 1953 | | | | 1954 | GET | none | none | 1955 | | | | 1956 | GET-PROP | none | none | 1957 | | | | 1958 | GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | 1959 | | | | 1960 | GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | 1961 | | | | 1962 | REPORT | (FULLDATA-TLV)+ | none | 1963 | | | | 1964 | COMMIT | none | none | 1965 | | | | 1966 | COMMIT-RESPONSE | none | (RESULT-TLV)+ | 1967 | | | | 1968 | TRCOMP | none | none | 1969 +-------------------+-------------------------------+---------------+ 1971 Table 2 1973 o RESULT-TLV contains the indication of whether the individual SET 1974 or SET-PROP succeeded. RESULT-TLV is included on the assumption 1975 that individual parts of a SET request can succeed or fail 1976 separately. 1978 In summary this approach has the following characteristic: 1980 o There can be one or more LFB class ID and instance ID combination 1981 targeted in a message (batch) 1983 o There can one or more operations on an addressed LFB class ID/ 1984 instance ID combination (batch) 1986 o There can be one or more path targets per operation (batch) 1988 o Paths may have zero or more data values associated (flexibility 1989 and operation specific) 1991 It should be noted that the above is optimized for the case of a 1992 single LFB class ID and instance ID targeting. To target multiple 1993 instances within the same class, multiple LFBselects are needed. 1995 7.1. Discussion on encoding 1997 Section 6.4.3 discusses the two types of DATA encodings (FULLDATA-TLV 1998 and SPARSEDATA-TLV) and the justifications for their existence. In 1999 this section we explain how they are encoded. 2001 7.1.1. Data Packing Rules 2003 The scheme for encoding data used in this doc adheres to the 2004 following rules: 2006 o The Value ("V" of TLV) of FULLDATA-TLV will contain the data being 2007 transported. This data will be as was described in the LFB 2008 definition. 2010 o Variable sized data within a FULLDATA-TLV will be encapsulated 2011 inside another FULLDATA-TLV inside the V of the outer TLV. For 2012 example of such a setup refer to Appendix C and Appendix D 2014 o In the case of FULLDATA-TLVs: 2016 * When a table is referred to in the PATH (IDs) of a PATH-DATA- 2017 TLV, then the FULLDATA-TLV's "V" will contain that table's row 2018 content prefixed by its 32 bit index/subscript. On the other 2019 hand, when PATH flags are 00, the PATH may contain an index 2020 pointing to a row in table; in such a case, the FULLDATA-TLV's 2021 "V" will only contain the content with the index in order to 2022 avoid ambiguity. 2024 7.1.2. Path Flags 2026 The following flags are currently defined: 2028 o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present 2029 following this path information, and should be considered in 2030 evaluating the path. 2032 7.1.3. Relation of operational flags with global message flags 2034 Global flags, such as the execution mode and the atomicity indicators 2035 defined in the header, apply to all operations in a message. Global 2036 flags provide semantics that are orthogonal to those provided by the 2037 operational flags, such as the flags defined in Path Data. The scope 2038 of operational flags is restricted to the operation. 2040 7.1.4. Content Path Selection 2042 The KEYINFO-TLV describes the KEY as well as associated KEY data. 2043 KEYs, used for content searches, are restricted and described in the 2044 LFB definition. 2046 7.1.5. LFBselect-TLV 2048 The LFBselect TLV is an instance of a TLV as defined in Section 6.2. 2049 The definition is as below: 2051 0 1 2 3 2052 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 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 | Type = LFBselect | Length | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 | LFB Class ID | 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 | LFB Instance ID | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 | OPER-TLV | 2061 . . 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 ~ ... ~ 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | OPER-TLV | 2066 . . 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 Figure 18: PL PDU layout 2071 Type: 2072 The type of the TLV is "LFBselect" 2074 Length: 2075 Length of the TLV including the T and L fields, in octets. 2077 LFB Class ID: 2078 This field uniquely recognizes the LFB class/type. 2080 LFB Instance ID: 2081 This field uniquely identifies the LFB instance. 2083 OPER-TLV: 2084 It describes an operation nested in the LFBselect TLV. Note that 2085 usually there SHOULD be at least one OPER-TLV present for an LFB 2086 select TLV, but for the Association Setup Message defined in 2087 Section 7.5.1 where the OPER-TLV is optional. 2089 7.1.6. OPER-TLV 2091 The OPER-TLV is a place holder in the grammar for TLVs that define 2092 operations. The different types are defined in Table 3, below. 2094 +-------------------+--------+--------------------------------------+ 2095 | OPER-TLV | TLV | Comments | 2096 | | "Type" | | 2097 +-------------------+--------+--------------------------------------+ 2098 | SET | 0x0001 | From CE to FE. Used to create or add | 2099 | | | or update attributes | 2100 | | | | 2101 | SET-PROP | 0x0002 | From CE to FE. Used to create or add | 2102 | | | or update attribute properties | 2103 | | | | 2104 | SET-RESPONSE | 0x0003 | From FE to CE. Used to carry | 2105 | | | response of a SET | 2106 | | | | 2107 | SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry | 2108 | | | response of a SET-PROP | 2109 | | | | 2110 | DEL | 0x0005 | From CE to FE. Used to delete or | 2111 | | | remove an attribute | 2112 | | | | 2113 | DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry | 2114 | | | response of a DEL | 2115 | | | | 2116 | GET | 0x0007 | From CE to FE. Used to retrieve an | 2117 | | | attribute | 2118 | | | | 2119 | GET-PROP | 0x0008 | From CE to FE. Used to retrieve an | 2120 | | | attribute property | 2121 | | | | 2122 | GET-RESPONSE | 0x0009 | From FE to CE. Used to carry | 2123 | | | response of a GET | 2124 | | | | 2125 | GET-PROP-RESPONSE | 0x000A | From FE to CE. Used to carry | 2126 | | | response of a GET-PROP | 2127 | | | | 2128 | REPORT | 0x000B | From FE to CE. Used to carry an | 2129 | | | asynchronous event | 2130 | | | | 2131 | COMMIT | 0x000C | From CE to FE. Used to issue a | 2132 | | | commit in a 2PC transaction | 2133 | | | | 2134 | COMMIT-RESPONSE | 0x000D | From an FE to CE. Used to confirm a | 2135 | | | commit in a 2PC transaction | 2136 | | | | 2137 | TRCOMP | 0x000E | From CE to FE. Used to indicate | 2138 | | | NE-wide success of 2PC transaction | 2139 +-------------------+--------+--------------------------------------+ 2141 Table 3 2143 Different messages define OPER-TLV are valid and how they are used 2144 (refer to Table 1 and Table 2). 2146 SET, SET-PROP, and GET/GET-PROP requests are issued by the CE and do 2147 not carry RESULT-TLVs. On the other hand, SET-RESPONSE, SET-PROP- 2148 RESPONSE and GET-RESPONSE/GET-PROP-RESPONSE carry RESULT-TLVs. 2150 A GET-RESPONSE in response to a successful GET will have FULLDATA- 2151 TLVs added to the leaf paths to carry the requested data. For GET 2152 operations that fail, instead of the FULLDATA-TLV there will be a 2153 RESULT-TLV. 2155 For a SET-RESPONSE/SET-PROP-RESPONSE, each FULLDATA-TLV or 2156 SPARSEDATA-TLV in the original request will be replaced with a 2157 RESULT-TLV in the response. If the request set the FailureACK flag, 2158 then only those items which failed will appear in the response. If 2159 the request was for AlwaysACK, then all components of the request 2160 will appear in the response with RESULT-TLVs. 2162 Note that if a SET/SET-PROP request with a structure in a FULLDATA- 2163 TLV is issued, and some field in the structure is invalid, the FE 2164 will not attempt to indicate which field was invalid, but rather will 2165 indicate that the operation failed. Note further that if there are 2166 multiple errors in a single leaf PATH-DATA/FULLDATA-TLB, the FE can 2167 select which error it chooses to return. So if a FULLDATA-TLV for a 2168 SET/SET-PROP of a structure attempts to write one field which is read 2169 only, and attempts to set another field to an invalid value, the FE 2170 can return indication of either error. 2172 A SET/SET-PROP operation on a variable length component with a length 2173 of 0 for the item is not the same as deleting it. If the CE wishes 2174 to delete then the DEL operation should be used whether the path 2175 refers to an array component or an optional structure component. 2177 7.1.7. RESULT TLV 2179 The RESULT-TLV is an instance of TLV defined in Section 6.2. The 2180 definition is as below: 2182 0 1 2 3 2183 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 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 | Type = RESULT-TLV | Length | 2186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 | Result Value | Reserved | 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 Figure 19: RESULT-TLV 2191 Defined Result Values 2193 +-----------------------------+-----------+-------------------------+ 2194 | Result Value | Value | Definition | 2195 +-----------------------------+-----------+-------------------------+ 2196 | E_SUCCESS | 0x00 | Success | 2197 | | | | 2198 | E_INVALID_HEADER | 0x01 | Unspecified error with | 2199 | | | header. | 2200 | | | | 2201 | E_LENGTH_MISMATCH | 0x02 | Header length field | 2202 | | | does not match actual | 2203 | | | packet length. | 2204 | | | | 2205 | E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch | 2206 | | | in versions. | 2207 | | | | 2208 | E_INVALID_DESTINATION_PID | 0x04 | Destination PID is | 2209 | | | invalid for the message | 2210 | | | receiver. | 2211 | | | | 2212 | E_LFB_UNKNOWN | 0x05 | LFB Class ID is not | 2213 | | | known by receiver. | 2214 | | | | 2215 | E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known | 2216 | | | by receiver but not | 2217 | | | currently in use. | 2218 | | | | 2219 | E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known | 2220 | | | but the specified | 2221 | | | instance of that class | 2222 | | | does not exist. | 2223 | | | | 2224 | E_INVALID_PATH | 0x08 | The specified path is | 2225 | | | impossible. | 2226 | | | | 2227 | E_COMPONENT_DOES_NOT_EXIST | 0x09 | The specified path is | 2228 | | | possible but the | 2229 | | | component does not | 2230 | | | exist (e.g., attempt to | 2231 | | | modify a table row that | 2232 | | | has not been created). | 2233 | | | | 2234 | E_EXISTS | 0x0A | The specified object | 2235 | | | exists but it cannot | 2236 | | | exist for the operation | 2237 | | | to succeed (e.g., | 2238 | | | attempt to add an | 2239 | | | existing LFB instance | 2240 | | | or array subscript). | 2241 | | | | 2242 | E_NOT_FOUND | 0x0B | The specified object | 2243 | | | does not exist but it | 2244 | | | must exist for the | 2245 | | | operation to succeed | 2246 | | | (e.g., attempt to | 2247 | | | delete a non-existing | 2248 | | | LFB instance or array | 2249 | | | subscript). | 2250 | | | | 2251 | E_READ_ONLY | 0x0C | Attempt to modify a | 2252 | | | read-only value. | 2253 | | | | 2254 | E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an | 2255 | | | array with an unallowed | 2256 | | | subscript. | 2257 | | | | 2258 | E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a | 2259 | | | parameter to a value | 2260 | | | outside of its | 2261 | | | allowable range. | 2262 | | | | 2263 | E_CONTENTS_TOO_LONG | 0x0D | Attempt to write | 2264 | | | contents larger than | 2265 | | | the target object space | 2266 | | | (i.e., exceeding a | 2267 | | | buffer). | 2268 | | | | 2269 | E_INVALID_PARAMETERS | 0x10 | Any other error with | 2270 | | | data parameters. | 2271 | | | | 2272 | E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not | 2273 | | | acceptable. | 2274 | | | | 2275 | E_INVALID_FLAGS | 0x12 | Message flags are not | 2276 | | | acceptable for the | 2277 | | | given message type. | 2278 | | | | 2279 | E_INVALID_TLV | 0x13 | A TLV is not acceptable | 2280 | | | for the given message | 2281 | | | type. | 2282 | E_EVENT_ERROR | 0x14 | Unspecified error while | 2283 | | | handling an event. | 2284 | | | | 2285 | E_NOT_SUPPORTED | 0x15 | Attempt to perform a | 2286 | | | valid ForCES operation | 2287 | | | that is unsupported by | 2288 | | | the message receiver. | 2289 | | | | 2290 | E_MEMORY_ERROR | 0x16 | A memory error occurred | 2291 | | | while processing a | 2292 | | | message (no error | 2293 | | | detected in the message | 2294 | | | itself) | 2295 | | | | 2296 | E_INTERNAL_ERROR | 0x17 | An unspecified error | 2297 | | | occurred while | 2298 | | | processing a message | 2299 | | | (no error detected in | 2300 | | | the message itself) | 2301 | | | | 2302 | - | 0x18-0xFE | Reserved | 2303 | | | | 2304 | E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for | 2305 | | | when the FE can not | 2306 | | | decide what went wrong) | 2307 +-----------------------------+-----------+-------------------------+ 2309 Table 4 2311 7.1.8. DATA TLV 2313 A FULLDATA-TLV has "T"= FULLDATA-TLV and a 16-bit Length followed by 2314 the data value/contents. Likewise, a SPARSEDATA-TLV has "T" = 2315 SPARSEDATA-TLV, a 16-bit Length, followed by the data value/contents. 2316 In the case of the SPARSEDATA-TLV, each component in the Value part 2317 of the TLV will be further encapsulated in an ILV. 2319 Below are the encoding rules for the FULLDATA-TLV and SPARSEDATA- 2320 TLVs. Appendix C is very useful in illustrating these rules: 2322 1. Both ILVs and TLVs MUST be 32 bit aligned. Any padding bits used 2323 for the alignment MUST be zero on transmission and MUST be 2324 ignored upon reception. 2326 2. FULLDATA-TLVs may be used at a particular path only if every 2327 component at that path level is present. In example 1(c) of 2328 Appendix C this concept is illustrated by the presence of all 2329 components of the structure S in the FULLDATA-TLV encoding. This 2330 requirement holds regardless of whether the fields are fixed or 2331 variable length, mandatory or optional. 2333 * If a FULLDATA-TLV is used, the encoder MUST lay out data for 2334 each component in the same order in which the data was 2335 defined in the LFB specification. This ensures the decoder 2336 is able to retrieve the data. To use the example 1 again in 2337 Appendix C, this implies the encoder/decoder is assumed to 2338 have knowledge of how structure S is laid out in the 2339 definition. 2341 * In the case of a SPARSEDATA-TLV, it does not need to be 2342 ordered since the "I" in the ILV uniquely identifies the 2343 component. Examples 1(a) and 1(b) in Appendix C illustrate 2344 the power of SPARSEDATA-TLV encoding. 2346 3. Inside a FULLDATA-TLV 2348 * The values for atomic, fixed-length fields are given without 2349 any TLV or ILV encapsulation. 2351 * The values for atomic, variable-length fields are given 2352 inside FULLDATA-TLVs. 2354 4. Inside a SPARSEDATA-TLV 2356 * The values for atomic fields may be given with ILVs (32-bit 2357 index, 32-bit length) 2359 5. Any of the FULLDATA-TLVs can contain an ILV but an ILV cannot 2360 contain a FULLDATA-TLV. This is because it is hard to 2361 disambiguate the ILV since an I is 32 bits and a T is 16 bits. 2363 6. A FULLDATA-TLV can also contain a FULLDATA-TLV for variable sized 2364 components. The decoding disambiguation is assumed from rule #3 2365 above. 2367 7.1.9. SET and GET Relationship 2369 It is expected that a GET-RESPONSE would satisfy the following: 2371 o It would have exactly the same path definitions as those sent in 2372 the GET. The only difference being a GET-RESPONSE will contain 2373 FULLDATA-TLVs. 2375 o It should be possible to take the same GET-RESPONSE and convert 2376 it to a SET successfully by merely changing the T in the 2377 operational TLV. 2379 o There are exceptions to this rule: 2381 1. When a KEY selector is used with a path in a GET operation, 2382 that selector is not returned in the GET-RESPONSE; instead 2383 the cooked result is returned. Refer to the examples using 2384 KEYS to see this. 2386 2. When dumping a whole table in a GET, the GET-RESPONSE that 2387 merely edits the T to be SET will end up overwriting the 2388 table. 2390 7.2. Protocol Encoding Visualization 2392 The figure below shows a general layout of the PL PDU. A main header 2393 is followed by one or more LFB selections each of which may contain 2394 one or more operation. 2396 main hdr (Config in this case) 2397 | 2398 | 2399 +--- T = LFBselect 2400 | | 2401 | +-- LFBCLASSID 2402 | | 2403 | | 2404 | +-- LFBInstance 2405 | | 2406 | +-- T = SET 2407 | | | 2408 | | +-- // one or more path targets 2409 | | // with their data here to be added 2410 | | 2411 | +-- T = DEL 2412 | . | 2413 | . +-- // one or more path targets to be deleted 2414 | 2415 | 2416 +--- T = LFBselect 2417 | | 2418 | +-- LFBCLASSID 2419 | | 2420 | | 2421 | +-- LFBInstance 2422 | | 2423 | + -- T= SET 2424 | | . 2425 | | . 2426 | + -- T= DEL 2427 | | . 2428 | | . 2429 | | 2430 | + -- T= SET 2431 | | . 2432 | | . 2433 | 2434 | 2435 +--- T = LFBselect 2436 | 2437 +-- LFBCLASSID 2438 | 2439 +-- LFBInstance 2440 . 2441 . 2442 . 2444 Figure 20: PL PDU logical layout 2446 The figure below shows a more detailed example of the general layout 2447 of the operation within a targeted LFB selection. The idea is to 2448 show the different nesting levels a path could take to get to the 2449 target path. 2451 T = SET 2452 | | 2453 | +- T = Path-data 2454 | | 2455 | + -- flags 2456 | + -- IDCount 2457 | + -- IDs 2458 | | 2459 | +- T = Path-data 2460 | | 2461 | + -- flags 2462 | + -- IDCount 2463 | + -- IDs 2464 | | 2465 | +- T = Path-data 2466 | | 2467 | + -- flags 2468 | + -- IDCount 2469 | + -- IDs 2470 | + -- T = KEYINFO-TLV 2471 | | + -- KEY_ID 2472 | | + -- KEY_DATA 2473 | | 2474 | + -- T = FULLDATA-TLV 2475 | + -- data 2476 | 2477 | 2478 T = SET 2479 | | 2480 | +- T = Path-data 2481 | | | 2482 | | + -- flags 2483 | | + -- IDCount 2484 | | + -- IDs 2485 | | | 2486 | | + -- T = FULLDATA-TLV 2487 | | + -- data 2488 | +- T = Path-data 2489 | | 2490 | + -- flags 2491 | + -- IDCount 2492 | + -- IDs 2493 | | 2494 | + -- T = FULLDATA-TLV 2495 | + -- data 2496 T = DEL 2497 | 2498 +- T = Path-data 2499 | 2500 + -- flags 2501 + -- IDCount 2502 + -- IDs 2503 | 2504 +- T = Path-data 2505 | 2506 + -- flags 2507 + -- IDCount 2508 + -- IDs 2509 | 2510 +- T = Path-data 2511 | 2512 + -- flags 2513 + -- IDCount 2514 + -- IDs 2515 + -- T = KEYINFO-TLV 2516 | + -- KEY_ID 2517 | + -- KEY_DATA 2518 +- T = Path-data 2519 | 2520 + -- flags 2521 + -- IDCount 2522 + -- IDs 2524 Figure 21: Sample operation layout 2526 Appendix D shows a more concise set of use-cases on how the data 2527 encoding is done. 2529 7.3. Core ForCES LFBs 2531 There are two LFBs that are used to control the operation of the 2532 ForCES protocol and to interact with FEs and CEs: 2534 o FE Protocol LFB 2535 o FE Object LFB 2537 Although these LFBs have the same form and interface as other LFBs, 2538 they are special in many respects. They have fixed well-known LFB 2539 Class and Instance IDs. They are statically defined (no dynamic 2540 instantiation allowed) and their status cannot be changed by the 2541 protocol: any operation to change the state of such LFBs (for 2542 instance, in order to disable the LFB) must result in an error. 2543 Moreover, these LFBs must exist before the first ForCES message can 2544 be sent or received. All attributes in these LFBs must have pre- 2545 defined default values. Finally, these LFBs do not have input or 2546 output ports and do not integrate into the intra-FE LFB topology. 2548 7.3.1. FE Protocol LFB 2550 The FE Protocol LFB is a logical entity in each FE that is used to 2551 control the ForCES protocol. The FE Protocol LFB Class ID is 2552 assigned the value 0x2. The FE Protocol LFB Instance ID is assigned 2553 the value 0x1. There MUST be one and only one instance of the FE 2554 Protocol LFB in an FE. The values of the attributes in the FE 2555 Protocol LFB have pre-defined default values that are specified here. 2556 Unless explicit changes are made to these values using Config 2557 messages from the CE, these default values MUST be used for correct 2558 operation of the protocol. 2560 The formal definition of the FE Protocol Object LFB can be found in 2561 Appendix B. 2563 7.3.1.1. FE Protocol capabilities 2565 FE Protocol capabilities are read-only. 2567 7.3.1.1.1. SupportableVersions 2569 ForCES protocol version(s) supported by the FE 2571 7.3.1.1.2. FE Protocol Attributes 2573 FE Protocol attributes (can be read and set). 2575 7.3.1.1.2.1. CurrentRunningVersion 2577 Current running version of the ForCES protocol 2579 7.3.1.1.2.2. FEID 2581 FE unicast ID 2583 7.3.1.1.2.3. MulticastFEIDs 2585 FE multicast ID(s) list - this is a list of multicast IDs that the FE 2586 belongs to. These IDs are configured by the CE. 2588 7.3.1.1.2.4. CEHBPolicy 2590 CE heartbeat policy - This policy, along with the parameter 'CE 2591 Heartbeat Dead Interval (CE HDI)' as described below defines the 2592 operating parameters for the FE to check the CE liveness. The policy 2593 values with meanings are listed as below: 2595 o 0 (default) - This policy specifies that the CE will send a 2596 Heartbeat Message to the FE(s) whenever the CE reaches a time 2597 interval within which no other PL messages were sent from the CE 2598 to the FE(s); refer to Section 4.3.3 and Section 7.10 for details. 2599 The CE HDI attribute as described below is tied to this policy. 2601 o 1 - The CE will not generate any HB messages. This actually means 2602 CE does not want the FE to check the CE liveness. 2604 o Others - reserved. 2606 7.3.1.1.2.5. CEHDI 2608 CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses 2609 to check the CE liveness. If FE has not received any messages from 2610 CE within this time interval, FE deduces lost connectivity which 2611 implies that the CE is dead or the association to the CE is lost. 2612 Default value 30 s. 2614 7.3.1.1.2.6. FEHBPolicy 2616 FE heartbeat policy - This policy, along with the parameter 'FE 2617 Heartbeat Interval (FE HI)', defines the operating parameters for how 2618 the FE should behave so that the CE can deduce its liveness. The 2619 policy values and the meanings are: 2621 o 0 (default) - The FE should not generate any Heartbeat messages. 2622 In this scenario, the CE is responsible for checking FE liveness 2623 by setting the PL header ACK flag of the message it sends to 2624 AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat 2625 Request Message. Refer to Section 7.10 and Section 4.3.3 for 2626 details. 2628 o 1 - This policy specifies that FE must actively send a Heartbeat 2629 Message if it reaches the time interval assigned by the FE HI as 2630 long as no other messages were sent from FE to CE during that 2631 interval as described in Section 4.3.3. 2633 o Others - Reserved. 2635 7.3.1.1.2.7. FEHI 2637 FE Heartbeat Interval (FE HI) - The time interval the FE should use 2638 to send HB as long as no other messages were sent from FE to CE 2639 during that interval as described in Section 4.3.3. The default 2640 value for an FE HI is 500ms. 2642 7.3.1.1.2.8. CEID 2644 Primary CEID - The CEID that the FE is associated with. 2646 7.3.1.1.2.9. LastCEID 2648 Last Primary CEID - The CEID of the last CE that that the FE 2649 associated with. This CE ID is reported to the new Primary CEID. 2651 7.3.1.1.2.10. BackupCEs 2653 The list of backup CEs an FE can use as backups. Refer to Section 8 2654 for details. 2656 7.3.1.1.2.11. CEFailoverPolicy 2658 CE failover policy - This specifies the behavior of the FE when the 2659 association with the CE is lost. There is a very tight relation 2660 between CE failover policy and Section 7.3.1.1.2.8, 2661 Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an 2662 association is lost, depending on configuration, one of the policies 2663 listed below is activated. 2665 o 0 (default) - FE should stop functioning immediately and 2666 transition to FE OperDisable. 2668 o 1 - The FE should continue running and do what it can even without 2669 an associated CE. This basically requires that the FE support CE 2670 Graceful restart (and defines such support in its capabilities). 2671 If the CEFTI expires before the FE re-associates with either the 2672 primary (Section 7.3.1.1.2.8) or one of possibly several backup 2673 CEs (Section 7.3.1.1.2.10), the FE will go operationally down. 2675 o Others - Reserved 2677 7.3.1.1.2.12. CEFTI 2679 CE Failover Timeout Interval (CEFTI) - The time interval associated 2680 with the CE failover policy case '0' and '2'. The default value is 2681 set to 300 seconds. Note that it is advisable to set the CEFTI value 2682 much higher than the CE Heartbeat Dead Interval (CE HDI) since the 2683 effect of expiring this parameter is devastating to the operation of 2684 the FE. 2686 7.3.1.1.2.13. FERestartPolicy 2688 FE restart policy - This specifies the behavior of the FE during an 2689 FE restart. The restart may be from an FE failure or other reasons 2690 that have made FE down and then need to restart. The values are 2691 defined as below: 2693 o 0(default)- Restart the FE from scratch. In this case, the FE 2694 should start from the pre-association phase. 2696 o others - Reserved for future use. 2698 7.3.2. FE Object LFB 2700 The FE Object LFB is a logical entity in each FE and contains 2701 attributes relative to the FE itself, and not to the operation of the 2702 ForCES protocol. 2704 The formal definition of the FE Object LFB can be found in 2705 [FE-MODEL]. The model captures the high level properties of the FE 2706 that the CE needs to know to begin working with the FE. The class ID 2707 for this LFB Class is also assigned in [FE-MODEL]. The singular 2708 instance of this class will always exist, and will always have 2709 instance ID 0x1 within its class. It is common, although not 2710 mandatory, for a CE to fetch much of the component and capability 2711 information from this LFB instance when the CE begins controlling the 2712 operation of the FE. 2714 7.4. Semantics of Message Direction 2716 Recall: The PL provides a master(CE)-Slave(FE) relationship. The 2717 LFBs reside at the FE and are controlled by CE. 2719 When messages go from the CE, the LFB Selector (Class and instance) 2720 refers to the destination LFB selection which resides in the FE. 2722 When messages go from the FE to the CE, the LFB Selector (Class and 2723 instance) refers to the source LFB selection which resides in the FE. 2725 7.5. Association Messages 2727 The ForCES Association messages are used to establish and teardown 2728 associations between FEs and CEs. 2730 7.5.1. Association Setup Message 2732 This message is sent by the FE to the CE to setup a ForCES 2733 association between them. 2735 Message transfer direction: 2736 FE to CE 2738 Message header: 2739 The Message Type in the header is set MessageType= 2740 'AssociationSetup'. The ACK flag in the header MUST be ignored, 2741 and the association setup message always expects to get a response 2742 from the message receiver (CE), whether the setup is successful or 2743 not. The correlator field in the header is set, so that FE can 2744 correlate the response coming back from the CE correctly. The FE 2745 may set the source ID to 0 in the header to request that the CE 2746 should assign an FE ID for the FE in the setup response message. 2748 Message body: 2749 The association setup message body optionally consists of zero, 2750 one or two LFBselect TLVs, as described in Section 7.1.5. The 2751 Association Setup message only operates on the FE Object and FE 2752 Protocol LFBs, therefore, the LFB class ID in the LFBselect TLV 2753 only points to these two kinds of LFBs. 2755 The OPER-TLV in the LFBselect TLV is defined as a 'REPORT' 2756 operation. More than one component may be announced in this 2757 message using REPORT operation to let the FE declare its 2758 configuration parameters in an unsolicited manner. These may 2759 contain components suggesting values such as the FE HB Interval, 2760 or the FEID. The OPER-TLV used is defined below. 2762 OPER-TLV for Association Setup: 2764 0 1 2 3 2765 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 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2767 | Type = REPORT | Length | 2768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2769 | PATH-DATA-TLV for REPORT | 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 Figure 22: OPER-TLV 2774 Type: 2775 Only one operation type is defined for the association setup 2776 message: 2778 Type = "REPORT" - this type of operation is for FE to 2779 report something to CE. 2781 PATH-DATA-TLV for REPORT: 2782 This is generically a PATH-DATA-TLV format that has been defined 2783 in section (Section 7) in the PATH-DATA BNF definition. The PATH- 2784 DATA-TLV for REPORT operation MAY contain FULLDATA-TLV(s) but 2785 SHALL NOT contain any RESULT-TLV in the data format. The RESULT- 2786 TLV is defined in Section 7.1.7 and the FULLDATA-TLV is defined in 2787 Section 7.1.8. 2789 To better illustrate the above PDU format, a tree structure for the 2790 format is shown below: 2792 main hdr (type = Association Setup) 2793 | 2794 | 2795 +--- T = LFBselect 2796 | | 2797 | +-- LFBCLASSID = FE object 2798 | | 2799 | | 2800 | +-- LFBInstance = 0x1 2801 | 2802 +--- T = LFBselect 2803 | 2804 +-- LFBCLASSID = FE Protocol object 2805 | 2806 | 2807 +-- LFBInstance = 0x1 2808 | 2809 +---OPER-TLV = REPORT 2810 | 2811 +-- Path-data to one or more components 2813 Figure 23: PDU Format For Association Setup Message 2815 7.5.2. Association Setup Response Message 2817 This message is sent by the CE to the FE in response to the Setup 2818 message. It indicates to the FE whether the setup is successful or 2819 not, i.e., whether an association is established. 2821 Message transfer direction: 2822 CE to FE 2824 Message Header: 2825 The Message Type in the header is set MessageType= 2826 'AssociationSetupResponse'. The ACK flag in the header MUST be 2827 ignored, and the setup response message never expects to get any 2828 more responses from the message receiver (FE). The destination 2829 ID in the header will be set to the source ID in the 2830 corresponding association setup message, unless that source ID 2831 was 0. If the corresponding source ID was 0, then the CE will 2832 assign an FE ID value and use that value for the destination ID. 2834 0 1 2 3 2835 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 2836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2837 | Type = ASRresult | Length | 2838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2839 | Association Setup Result | 2840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 Figure 24: ASResult OPER-TLV 2844 Type (16 bits): 2845 The type of the TLV is "ASResult". 2847 Length (16 bits): 2848 Length of the TLV including the T and L fields, in octets. 2850 Association Setup Result (32 bits): 2851 This indicates whether the setup msg was successful or whether 2852 the FE request was rejected by the CE. the defined values are: 2854 0 = success 2856 1 = FE ID invalid 2858 2 = permission denied 2860 To better illustrate the above PDU format, a tree structure for the 2861 format is shown below: 2863 main hdr (type = Association Setup Response) 2864 | 2865 | 2866 +--- T = ASResult-TLV 2868 Figure 25: PDU Format for Association Setup Repsonse Message 2870 7.5.3. Association Teardown Message 2872 This message can be sent by the FE or CE to any ForCES element to end 2873 its ForCES association with that element. 2875 Message transfer direction: 2876 CE to FE, or FE to CE (or CE to CE) 2878 Message Header: 2879 The Message Type in the header is set MessageType= 2880 "AssociationTeardown". The ACK flag MUST be ignored. The 2881 correlator field in the header MUST be set to zero and MUST be 2882 ignored by the receiver. 2884 0 1 2 3 2885 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 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2887 | Type = ASTreason | Length | 2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2889 | Teardown Reason | 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2892 Figure 26: ASTreason-TLV 2894 Type (16 bits): 2895 The type of the TLV is "ASTreason". 2897 Length (16 bits): 2898 Length of the TLV including the T and L fields, in octets. 2900 Teardown Reason (32 bits): 2901 This indicates the reason why the association is being 2902 terminated. Several reason codes are defined as follows. 2904 0 - normal teardown by administrator 2906 1 - error - loss of heartbeats 2908 2 - error - out of bandwidth 2910 3 - error - out of memory 2912 4 - error - application crash 2914 255 - error - other or unspecified 2916 To better illustrate the above PDU format, a tree structure for the 2917 format is shown below: 2919 main hdr (type = Association Teardown) 2920 | 2921 | 2922 +--- T = ASTreason-TLV 2924 Figure 27: PDU Format for Association Teardown Message 2926 7.6. Configuration Messages 2928 The ForCES Configuration messages are used by CE to configure the FEs 2929 in a ForCES NE and report the results back to the CE. 2931 7.6.1. Config Message 2933 This message is sent by the CE to the FE to configure LFB components 2934 in the FE. This message is also used by the CE to subscribe/ 2935 unsubscribe to LFB events. 2937 As usual, a config message is composed of a common header followed by 2938 a message body that consists of one or more TLV data format. 2939 Detailed description of the message is as below. 2941 Message transfer direction: 2942 CE to FE 2944 Message Header: 2945 The Message Type in the header is set MessageType= 'Config'. The 2946 ACK flag in the header can be set to any value defined in 2947 Section 6.1, to indicate whether or not a response from FE is 2948 expected by the message. 2950 OPER-TLV for Config: 2952 0 1 2 3 2953 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 2954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2955 | Type | Length | 2956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2957 | PATH-DATA-TLV | 2958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 Figure 28: OPER-TLV for Config 2962 Type: 2963 The operation type for config message. two types of operations 2964 for the config message are defined: 2966 Type = "SET" - this operation is to set LFB components 2968 Type = "SET-PROP" - this operation is to set LFB component 2969 properties 2970 Type = "DEL" - this operation to delete some LFB 2971 components 2973 Type = "COMMIT" - this operation is sent to the FE to 2974 commit in a 2pc transaction. A COMMIT TLV is an empty TLV 2975 i.e it has no "V"alue. In other words, There is a Length 2976 of 4 (which is for the header only). 2978 Type = "TRCOMP" - this operation is sent to the FE to mark 2979 the success from an NE perspective of a 2pc transaction. 2980 A TRCOMP TLV is an empty TLV i.e it has no "V"alue. In 2981 other words, There is a Length of 4 (which is for the 2982 header only). 2984 PATH-DATA-TLV: 2985 This is generically a PATH-DATA-TLV format that has been defined 2986 in section (Section 7) in the PATH-DATA-TLV BNF definition. The 2987 restriction on the use of PATH-DATA-TLV for SET/SET-PROP 2988 operation is that it MUST contain either a FULLDATA-TLV or 2989 SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The 2990 restriction on the use of PATH-DATA-TLV for DEL operation is it 2991 MAY contain FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT 2992 contain any RESULT-TLV. The RESULT-TLV is defined in 2993 Section 7.1.7 and FULLDATA-TLV and SPARSEDATA-TLVs is defined in 2994 Section 7.1.8. 2996 *Note: For Event subscription, the events will be defined by the 2997 individual LFBs. 2999 To better illustrate the above PDU format, a tree structure for the 3000 format is shown below: 3002 main hdr (type = Config) 3003 | 3004 | 3005 +--- T = LFBselect 3006 . | 3007 . +-- LFBCLASSID = target LFB class 3008 . | 3009 | 3010 +-- LFBInstance = target LFB instance 3011 | 3012 | 3013 +-- T = operation { SET } 3014 | | 3015 | +-- // one or more path targets 3016 | // associated with FULLDATA-TLV or SPARSEDATA-TLV(s) 3017 | 3018 +-- T = operation { DEL } 3019 | | 3020 | +-- // one or more path targets 3021 | 3022 +-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV 3023 . 3024 . 3026 Figure 29: PDU Format for Configuration Message 3028 7.6.2. Config Response Message 3030 This message is sent by the FE to the CE in response to the Config 3031 message. It indicates whether the Config was successful or not on 3032 the FE and also gives a detailed response regarding the configuration 3033 result of each component. 3035 Message transfer direction: 3036 FE to CE 3038 Message Header: 3039 The Message Type in the header is set MessageType= 'Config 3040 Response'. The ACK flag in the header is always ignored, and the 3041 Config Response message never expects to get any further response 3042 from the message receiver (CE). 3044 OPER-TLV for Config Response: 3046 0 1 2 3 3047 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 3048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3049 | Type | Length | 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3051 | PATH-DATA-TLV | 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3054 Figure 30: OPER-TLV for Config Response 3056 Type: 3057 The operation type for Config Response message. Two types of 3058 operations for the Config Response message are defined: 3060 Type = "SET-RESPONSE" - this operation is for the response 3061 of SET operation of LFB components 3063 Type = "SET-PROP-RESPONSE" - this operation is for the 3064 response of SET-PROP operation of LFB component properties 3066 Type = "DEL-RESPONSE" - this operation is for the response 3067 of the DELETE operation of LFB components 3069 Type = "COMMIT-RESPONSE" - this operation is sent to the 3070 CE to confirm a commit success in a 2pc transaction. A 3071 COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating 3072 success or failure. 3074 PATH-DATA-TLV: 3075 This is generically a PATH-DATA-TLV format that has been defined 3076 in section (Section 7) in the PATH-DATA-TLV BNF definition. The 3077 restriction on the use of PATH-DATA-TLV for SET-RESPONSE 3078 operation is that it MUST contain RESULT-TLV(s). The restriction 3079 on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also 3080 MUST contain RESULT-TLV(s). The RESULT-TLV is defined in 3081 Section 7.1.7. 3083 To better illustrate the above PDU format, a tree structure for the 3084 format is shown below: 3086 main hdr (type = ConfigResponse) 3087 | 3088 | 3089 +--- T = LFBselect 3090 . | 3091 . +-- LFBCLASSID = target LFB class 3092 . | 3093 | 3094 +-- LFBInstance = target LFB instance 3095 | 3096 | 3097 +-- T = operation { SET-RESPONSE } 3098 | | 3099 | +-- // one or more path targets 3100 | // associated with FULL or SPARSEDATA-TLV(s) 3101 | 3102 +-- T = operation { DEL-RESPONSE } 3103 | | 3104 | +-- // one or more path targets 3105 | 3106 +-- T = operation { COMMIT-RESPONSE } 3107 | | 3108 | +-- RESULT-TLV 3110 Figure 31: PDU Format for Configuration Response message 3112 7.7. Query Messages 3114 The ForCES query messages are used by the CE to query LFBs in the FE 3115 for information like LFB components, capabilities, statistics, etc. 3116 Query Messages include the Query Message and the Query Response 3117 Message. 3119 7.7.1. Query Message 3121 A Query message is composed of a common header and a message body 3122 that consists of one or more TLV data format. Detailed description 3123 of the message is as below. 3125 Message transfer direction: 3126 from CE to FE 3128 Message Header: 3129 The Message Type in the header is set to MessageType= 'Query'. 3130 The ACK flag in the header is always ignored, and a full response 3131 for a query message is always expected. The Correlator field in 3132 the header is set, so that the CE can locate the response back 3133 from FE correctly. 3135 OPER-TLV for Query: 3137 0 1 2 3 3138 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 3139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3140 | Type = GET/GET-PROP | Length | 3141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3142 | PATH-DATA-TLV for GET/GET-PROP | 3143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3145 Figure 32: TLV for Query 3147 Type: 3148 The operation type for query. Two operation types are defined: 3150 Type = "GET" - this operation is to request to get LFB 3151 components. 3153 Type = "GET-PROP" - this operation is to request to get 3154 LFB components. 3156 PATH-DATA-TLV for GET/GET-PROP: 3157 This is generically a PATH-DATA-TLV format that has been defined 3158 in section (Section 7) in the PATH-DATA-TLV BNF definition. The 3159 restriction on the use of PATH-DATA-TLV for GET/GET-PROP 3160 operation is it MUST NOT contain any SPARSEDATA-TLV or FULLDATA- 3161 TLV and RESULT-TLV in the data format. 3163 To better illustrate the above PDU format, a tree structure for the 3164 format is shown below: 3166 main hdr (type = Query) 3167 | 3168 | 3169 +--- T = LFBselect 3170 . | 3171 . +-- LFBCLASSID = target LFB class 3172 . | 3173 | 3174 +-- LFBInstance = target LFB instance 3175 | 3176 | 3177 +-- T = operation { GET } 3178 | | 3179 | +-- // one or more path targets 3180 | 3181 +-- T = operation { GET } 3182 . | 3183 . +-- // one or more path targets 3184 . 3186 Figure 33: PDU Format for Query Message 3188 7.7.2. Query Response Message 3190 When receiving a Query message, the receiver should process the 3191 message and come up with a query result. The receiver sends the 3192 query result back to the message sender by use of the Query Response 3193 Message. The query result can be the information being queried if 3194 the query operation is successful, or can also be error codes if the 3195 query operation fails, indicating the reasons for the failure. 3197 A Query Response message is also composed of a common header and a 3198 message body consisting of one or more TLVs describing the query 3199 result. Detailed description of the message is as below. 3201 Message transfer direction: 3202 from FE to CE 3204 Message Header: 3205 The Message Type in the header is set to MessageType= 3206 'QueryResponse'. The ACK flag in the header is ignored. As a 3207 response itself, the message does not expect a further response. 3209 OPER-TLV for Query Response: 3211 0 1 2 3 3212 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 3213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3214 |Type = GET-RESPONSE/GET-PROP-RESPONSE| Length | 3215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3216 | PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE | 3217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3219 Figure 34: TLV for Query Response 3221 Type: 3222 The operation type for query response. One operation type is 3223 defined: 3225 Type = "GET-RESPONSE" - this operation is to response to 3226 get operation of LFB components. 3228 Type = "GET-PROP-RESPONSE" - this operation is to response 3229 to GET-PROP operation of LFB components. 3231 PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE: 3232 This is generically a PATH-DATA-TLV format that has been defined 3233 in section (Section 7) in the PATH-DATA-TLV BNF definition. The 3234 PATH-DATA-TLV for GET-RESPONSE operation MAY contain SPARSEDATA- 3235 TLV, FULLDATA-TLV and/or RESULT-TLV(s) in the data encoding. The 3236 RESULT-TLV is defined in Section 7.1.7 and the SPARSEDATA-TLVs 3237 and FULLDATA-TLVs are defined in Section 7.1.8. 3239 To better illustrate the above PDU format, a tree structure for the 3240 format is shown below: 3242 main hdr (type = QueryResponse) 3243 | 3244 | 3245 +--- T = LFBselect 3246 . | 3247 . +-- LFBCLASSID = target LFB class 3248 . | 3249 | 3250 +-- LFBInstance = target LFB instance 3251 | 3252 | 3253 +-- T = operation { GET-RESPONSE } 3254 | | 3255 | +-- // one or more path targets 3256 | 3257 +-- T = operation { GET-PROP-RESPONSE } 3258 . | 3259 . +-- // one or more path targets 3260 . 3262 Figure 35: PDU Format for Query Response Message 3264 7.8. Event Notification Message 3266 Event Notification Message is used by FE to asynchronously notify CE 3267 of events that happen in the FE. 3269 All events that can be generated in an FE are subscribable by the CE. 3270 The CE can subscribe to an event via a Config message with SET-PROP 3271 operation, where the included path specifies the event, as defined by 3272 the LFB Library and described by the FE Model. 3274 As usual, an Event Notification Message is composed of a common 3275 header and a message body that consists of one or more TLV data 3276 format. Detailed description of the message is as below. 3278 Message Transfer Direction: 3279 FE to CE 3281 Message Header: 3282 The Message Type in the message header is set to 3283 MessageType = 'EventNotification'. The ACK flag in the header 3284 MUST be ignored by the CE, and the event notification message does 3285 not expect any response from the receiver. 3287 OPER-TLV for Event Notification: 3289 0 1 2 3 3290 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 3291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3292 | Type = REPORT | Length | 3293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3294 | PATH-DATA-TLV for REPORT | 3295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3297 Figure 36: TLV for Event Notification 3299 Type: 3300 Only one operation type is defined for the event notification 3301 message: 3303 Type = "REPORT" - this type of operation is for FE to 3304 report something to CE. 3306 PATH-DATA-TLV for REPORT: 3307 This is generically a PATH-DATA-TLV format that has been defined 3308 in section (Section 7) in the PATH-DATA-TLV BNF definition. The 3309 PATH-DATA-TLV for REPORT operation MAY contain FULLDATA-TLV or 3310 SPARSEDATA-TLV(s) but MUST NOT contain any RESULT-TLV in the data 3311 format. 3313 To better illustrate the above PDU format, a tree structure for the 3314 format is shown below: 3316 main hdr (type = Event Notification) 3317 | 3318 | 3319 +--- T = LFBselect 3320 | 3321 +-- LFBCLASSID = target LFB class 3322 | 3323 | 3324 +-- LFBInstance = target LFB instance 3325 | 3326 | 3327 +-- T = operation { REPORT } 3328 | | 3329 | +-- // one or more path targets 3330 | // associated with FULL/SPARSE DATA TLV(s) 3331 +-- T = operation { REPORT } 3332 . | 3333 . +-- // one or more path targets 3334 . // associated with FULL/SPARSE DATA TLV(s) 3336 Figure 37: PDU Format for Event Notification Message 3338 7.9. Packet Redirect Message 3340 A packet Redirect message is used to transfer data packets between CE 3341 and FE. Usually these data packets are control packets but they may 3342 be just data-path packets which need further (exception or high- 3343 touch) processing. It is also feasible that this message carries no 3344 data packets and rather just metadata. 3346 The Packet Redirect message data format is formatted as follows: 3348 Message Direction: 3349 CE to FE or FE to CE 3351 Message Header: 3352 The Message Type in the header is set to MessageType= 3353 'PacketRedirect'. 3355 Message Body: 3356 This consists of one or more TLVs that contain or describe the 3357 packet being redirected. The TLV is specifically a Redirect TLV 3358 (with the TLV Type="Redirect"). Detailed data format of a 3359 Redirect TLV for packet redirect message is as below: 3361 0 1 2 3 3362 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 3363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3364 | Type = Redirect | Length | 3365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3366 | Meta Data TLV | 3367 . . 3368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3369 | Redirect Data TLV | 3370 . . 3371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3373 Figure 38: Redirect_Data TLV 3375 Meta Data TLV: 3376 This is a TLV that specifies meta-data associated with followed 3377 redirected data. The TLV is as follows: 3379 0 1 2 3 3380 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 3381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3382 | Type = METADATA-TLV | Length | 3383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3384 | Meta Data ILV | 3385 . . 3386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3387 ~ ... ~ 3388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3389 | Meta Data ILV | 3390 . . 3391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3393 Figure 39: METADATA-TLV 3395 Meta Data ILV: 3396 This is an Identifier-Length-Value format that is used to describe 3397 one meta data. The ILV has the format as: 3399 0 1 2 3 3400 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 3401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3402 | Meta Data ID | 3403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3404 | Length | 3405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3406 | Meta Data Value | 3407 . . 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3410 Figure 40: Meta Data ILV 3412 Where, Meta Data ID is an identifier for the meta data, which is 3413 statically assigned by the LFB definition. 3415 Redirect Data TLV 3416 This is a TLV describing one packet of data to be directed via the 3417 redirect operation. The TLV format is as follows: 3419 0 1 2 3 3420 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 3421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3422 | Type = REDIRECTDATA-TLV | Length | 3423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3424 | Redirected Data | 3425 . . 3426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3428 Figure 41: Redirect Data TLV 3430 Redirected Data: 3431 This field contains the packet that is to be redirected in network 3432 byte order. The packet should be 32-bits aligned as is the data 3433 for all TLVs. The metadata infers what kind of packet is carried 3434 in value field and therefore allows for easy decoding of data 3435 encapsulated 3437 To better illustrate the above PDU format, a tree structure for the 3438 format is shown below: 3440 main hdr (type = PacketRedirect) 3441 | 3442 | 3443 +--- T = Redirect 3444 . | 3445 . +-- T = METADATA-TLV 3446 | | 3447 | +-- Meta Data ILV 3448 | | 3449 | +-- Meta Data ILV 3450 | . 3451 | . 3452 | 3453 +-- T = REDIRECTDATA-TLV 3454 | 3455 +-- // Redirected Data 3457 Figure 42: PDU Format for Packet Redirect Message 3459 7.10. Heartbeat Message 3461 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 3462 to asynchronously notify one or more other ForCES elements in the 3463 same ForCES NE on its liveness. Section 4.3.3 describes the traffic- 3464 sensitive approach used. 3466 A Heartbeat Message is sent by a ForCES element periodically. The 3467 parameterization and policy definition for heartbeats for an FE is 3468 managed as components of the FE Protocol Object LFB, and can be set 3469 by CE via a Config message. The Heartbeat message is a little 3470 different from other protocol messages in that it is only composed of 3471 a common header, with the message body left empty. A detailed 3472 description of the message is as below. 3474 Message Transfer Direction: 3475 FE to CE or CE to FE 3477 Message Header: 3478 The Message Type in the message header is set to MessageType = 3479 'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. 3480 The ACK flag in the header MUST be set to either 'NoACK' or 3481 'AlwaysACK' when the HB is sent. 3483 * When set to 'NoACK', the HB is not soliciting for a response. 3485 * When set to 'AlwaysACK', the HB Message sender is always 3486 expecting a response from its receiver. According the HB 3487 policies defined in Section 7.3.1, only the CE can send such 3488 an HB message to query FE liveness. For simplicity and 3489 because of the minimal nature of the HB message, the response 3490 to a HB message is another HB message, i.e., no specific HB 3491 response message is defined. Whenever an FE receives a HB 3492 message marked with 'AlwaysACK' from the CE, the FE MUST send 3493 a HB message back immediately. The HB message sent by the FE 3494 in response to the 'AlwasyACK' MUST modify the source and 3495 destination IDs so that the ID of the FE is the source ID and 3496 the CE ID of the sender is the destination ID, and MUST 3497 change the ACK information to 'NoACK'. A CE MUST NOT respond 3498 to an HB message with 'AlwasyACK' set. 3500 * When set to anything else other than 'NoACK' or 'AlwaysACK', 3501 the HB Message is treated as if it was a 'NoACK'. 3503 The correlator field in the HB message header SHOULD be set 3504 accordingly when a response is expected so that a receiver can 3505 correlate the response correctly. The correlator field MAY be 3506 ignored if no response is expected. 3508 Message Body: 3509 The message body is empty for the Heartbeat Message. 3511 8. High Availability Support 3513 The ForCES protocol provides mechanisms for CE redundancy and 3514 failover, in order to support High Availability as defined in 3515 [RFC3654]. FE redundancy and FE to FE interaction is currently out 3516 of scope of this document. There can be multiple redundant CEs and 3517 FEs in a ForCES NE. However, at any one time only one primary CE can 3518 control the FEs though there can be multiple secondary CEs. The FE 3519 and the CE PL are aware of the primary and secondary CEs. This 3520 information (primary, secondary CEs) is configured in the FE and in 3521 the CE PLs during pre-association by the FEM and the CEM 3522 respectively. Only the primary CE sends control messages to the FEs. 3524 8.1. Relation with the FE Protocol 3526 High Availability parameterization in an FE is driven by configuring 3527 the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1). 3528 The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE 3529 Heartbeat policy help in detecting connectivity problems between an 3530 FE and CE. The CE Failover policy defines the reaction on a detected 3531 failure. 3533 Figure 43 extends the state machine illustrated in Figure 4 to allow 3534 for new states that facilitate connection recovery. 3536 (CE issues Teardown || +-----------------+ 3537 Lost association) && | Pre-Association | 3538 CE failover policy = 0 | (Association | 3539 +------------>-->-->| in +<----+ 3540 | | progress) | | 3541 | CE Issues +--------+--------+ | 3542 | Association | | CFTI 3543 | Setup V | timer 3544 | ___________________+ | expires 3545 | | | 3546 | V ^ 3547 +-+-----------+ +-------+-----+ 3548 | | | Not | 3549 | | (CE issues Teardown || | Associated | 3550 | | Lost association) && | | 3551 | Associated | CE Failover Policy = 1 | (May | 3552 | | | Continue | 3553 | |---------->------->------>| Forwarding)| 3554 | | | | 3555 +-------------+ +-------------+ 3556 ^ V 3557 | | 3558 | CE Issues | 3559 | Association | 3560 | Setup | 3561 +_________________________________________+ 3563 Figure 43: FE State Machine considering HA 3565 Section 4.2 describes transitions between the Pre-association, 3566 associated and not associated states. 3568 When communication fails between the FE and CE (which can be caused 3569 by either the CE or link failure but not FE related), either the TML 3570 on the FE will trigger the FE PL regarding this failure or it will be 3571 detected using the HB messages between FEs and CEs. The 3572 communication failure, regardless of how it is detected, MUST be 3573 considered as a loss of association between the CE and corresponding 3574 FE. 3576 If the FE's FEPO CE Failover Policy is configured to mode 0 (the 3577 default), it will immediately transition to the pre-association 3578 phase. This means that if association is again established, all FE 3579 state will need to be re-established. 3581 If the FE's FEPO CE Failover Policy is configured to mode 1, it 3582 indicates that the FE is capable of HA restart recovery. In such a 3583 case, the FE transitions to the not associated state and the CEFTI 3584 timer is started. The FE MAY continue to forward packets during this 3585 state. It MAY also recycle through any configured secondary CEs in a 3586 round-robin fashion. It first adds its primary CE to the tail of 3587 backup CEs and sets its primary CE to be the first secondary. It 3588 then attempts to associate with the CE designated as the new primary 3589 CE. If it fails to re-associate with any CE and the CEFTI expires, 3590 the FE then transitions to the pre-association state. 3592 If the FE, while in the not associated state, manages to reconnect to 3593 a new primary CE before CEFTI expires it transitions to the 3594 Associated state. Once re-associated, the FE tries to recover any 3595 state that may have been lost during the not associated state. How 3596 the FE achieves re-synchronizes it state is out of scope for this 3597 document. 3599 Figure 44 below illustrates the Forces message sequences that the FE 3600 uses to recover the connection. 3602 FE CE Primary CE Secondary 3603 | | | 3604 | Asso Estb,Caps exchg | | 3605 1 |<--------------------->| | 3606 | | | 3607 | All msgs | | 3608 2 |<--------------------->| | 3609 | | | 3610 | | | 3611 | FAILURE | 3612 | | 3613 | Asso Estb,Caps exchange | 3614 3 |<------------------------------------------>| 3615 | | 3616 | Event Report (pri CE down) | 3617 4 |------------------------------------------->| 3618 | | 3619 | All Msgs | 3620 5 |<------------------------------------------>| 3622 Figure 44: CE Failover for Report Primary Mode 3624 A CE-to-CE synchronization protocol would be needed to support fast 3625 failover as well as to address some of the corner cases, however this 3626 will not be defined by the ForCES protocol as it is out of scope for 3627 this specification. 3629 An explicit message (a Config message setting Primary CE component in 3630 ForCES Protocol object) from the primary CE, can also be used to 3631 change the Primary CE for an FE during normal protocol operation. 3633 Also note that the FEs in a ForCES NE could also use a multicast CE 3634 ID, i.e., they could be associated with a group of CEs (this assumes 3635 the use of a CE-CE synchronization protocol, which is out of scope 3636 for this specification). In this case, the loss of association would 3637 mean that communication with the entire multicast group of CEs has 3638 been lost. The mechanisms described above will apply for this case 3639 as well during the loss of association. If, however, the secondary 3640 CE was also using the multicast CE ID that was lost, then the FE will 3641 need to form a new association using a different CE ID. If the 3642 capability exists, the FE MAY first attempt to form a new association 3643 with original primary CE using a different non multicast CE ID. 3645 8.2. Responsibilities for HA 3647 TML Level: 3649 1. The TML controls logical connection availability and failover. 3651 2. The TML also controls peer HA management. 3653 At this level, control of all lower layers, for example transport 3654 level (such as IP addresses, MAC addresses etc) and associated links 3655 going down are the role of the TML. 3657 PL Level: 3658 All other functionality, including configuring the HA behavior during 3659 setup, the CE IDs used to identify primary and secondary CEs, 3660 protocol messages used to report CE failure (Event Report), Heartbeat 3661 messages used to detect association failure, messages to change the 3662 primary CE (Config), and other HA related operations described 3663 before, are the PL responsibility. 3665 To put the two together, if a path to a primary CE is down, the TML 3666 would take care of failing over to a backup path, if one is 3667 available. If the CE is totally unreachable then the PL would be 3668 informed and it would take the appropriate actions described before. 3670 9. Security Considerations 3672 ForCES Framework document [RFC3746], section 8 goes into extensive 3673 detail on a variety of security threats, the possible effects of 3674 those threats on the protocol and responses to those threats. This 3675 document does not repeat that discussion, the reader is referred to 3676 the ForCES Framework document [RFC3746] for those details and how the 3677 ForCES architecture addresses them. 3679 ForCES PL uses security services provided by the ForCES TML. The TML 3680 provides security services such as endpoint authentication service, 3681 message authentication service and confidentiality service. Endpoint 3682 authentication service is invoked at the time of the pre-association 3683 connection establishment phase and message authentication is 3684 performed whenever the FE or CE receives a packet from its peer. 3686 The following are the general security mechanisms that need to be in 3687 place for ForCES PL. 3689 o Security mechanisms are session controlled - that is, once the 3690 security is turned on depending upon the chosen security level (No 3691 Security, Authentication, Confidentiality), it will be in effect 3692 for the entire duration of the session. 3694 o An operator should configure the same security policies for both 3695 primary and backup FEs and CEs (if available). This will ensure 3696 uniform operations and avoid unnecessary complexity in policy 3697 configuration. 3699 9.1. No Security 3701 When "No security" is chosen for ForCES protocol communication, both 3702 endpoint authentication and message authentication service needs to 3703 be performed by ForCES PL. Both these mechanism are weak and do not 3704 involve cryptographic operation. An operator can choose "No 3705 Security" level when the ForCES protocol endpoints are within a 3706 single box, for example. 3708 In order to have interoperable and uniform implementation across 3709 various security levels, each CE and FE endpoint MUST implement this 3710 level. 3712 What is described below (in Section 9.1.1 and Section 9.1.2) are 3713 error checks and not security procedures. The reader is referred to 3714 section Section 9.2. for security procedures. 3716 9.1.1. Endpoint Authentication 3718 Each CE and FE PL maintains a list of associations as part its of 3719 configuration. This is done via the CEM and FEM interfaces. An FE 3720 MUST connect to only those CEs that are configured via the FEM; 3721 similarly, a CE should accept the connection and establish 3722 associations for the FEs which are configured via the CEM. The CE 3723 should validate the FE identifier before accepting the connections 3724 during the pre-association phase. 3726 9.1.2. Message Authentication 3728 When a CE or FE initiates a message, the receiving endpoint MUST 3729 validate the initiator of the message by checking the common header 3730 CE or FE identifiers. This will ensure proper protocol functioning. 3731 This extra processing step is recommended even when the underlying 3732 TML layer security services exist. 3734 9.2. ForCES PL and TML security service 3736 This section is applicable if an operator wishes to use the TML 3737 security services. A ForCES TML MUST support one or more security 3738 services such as endpoint authentication service, message 3739 authentication service, and confidentiality service, as part of TML 3740 security layer functions. It is the responsibility of the operator 3741 to select an appropriate security service and configure security 3742 policies accordingly. The details of such configuration are outside 3743 the scope of the ForCES PL and are dependent on the type of transport 3744 protocol and the nature of the connection. 3746 All these configurations should be done prior to starting the CE and 3747 FE. 3749 When certificates-based authentication is being used at the TML, the 3750 certificate can use a ForCES-specific naming structure as certificate 3751 names and, accordingly, the security policies can be configured at 3752 the CE and FE. 3754 The reader is asked to refer to specific TML documents for details on 3755 the security requirements specific to that TML 3757 9.2.1. Endpoint authentication service 3759 When TML security services are enabled, the ForCES TML performs 3760 endpoint authentication. Security association is established between 3761 CE and FE and is transparent to the ForCES PL. 3763 9.2.2. Message authentication service 3765 This is a TML specific operation and is transparent to the ForCES PL. 3766 For details, refer to Section 5. 3768 9.2.3. Confidentiality service 3770 This is a TML specific operation and is transparent to the ForCES PL. 3771 For details, refer to Section 5. 3773 10. Acknowledgements 3775 The authors of this draft would like to acknowledge and thank the 3776 ForCES Working Group and especially the following: Furquan Ansari, 3777 Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M. 3778 Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel M. 3779 Halpern (who should probably be listed among the authors), Zsolt 3780 Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, 3781 T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their 3782 contributions. We would also like to thank David Putzolu, and 3783 Patrick Droz for their comments and suggestions on the protocol and 3784 for their infinite patience. We would also like to thank Sue Hares 3785 and Alia Atlas for extensive reviews of the document. 3787 Alia Atlas has done a wonderful job of shaping the draft to make it 3788 more readable by providing the IESG feedback. 3790 The editors have used the xml2rfc [RFC2629] tools in creating this 3791 document and are very grateful for the existence and quality of these 3792 tools. The editor is also grateful to Elwyn Davies for his help in 3793 correcting the XML source of this document. 3795 11. References 3797 11.1. Normative References 3799 [FE-MODEL] 3800 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., 3801 and S. Blake, "ForCES Forwarding Element Model", 3802 Feb. 2005. 3804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3805 Requirement Levels", BCP 14, RFC 2119, March 1997. 3807 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 3808 RFC 2914, September 2000. 3810 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3811 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3812 May 2008. 3814 [SCTP-TML] Hadi Salim, J. and K. Ogawa, "SCTP based TML (Transport 3815 Mapping Layer) for ForCES protocol", internet 3816 draft draft-ietf-forces-sctptml, work in progress, 3817 Feb. 2009. 3819 11.2. Informational References 3821 [2PCREF] Gray, J., "Notes on database operating systems. In 3822 Operating Systems: An Advanced Course. Lecture Notes in 3823 Computer Science, Vol. 60, pp. 394-481, Springer-Verlag", 3824 1978. 3826 [ACID] Haerder, T. and A. Reuter, "Principles of Transaction- 3827 Orientated Database Recovery", 1983. 3829 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 3830 June 1999. 3832 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 3833 of IP Control and Forwarding", RFC 3654, November 2003. 3835 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 3836 "Forwarding and Control Element Separation (ForCES) 3837 Framework", RFC 3746, April 2004. 3839 Appendix A. IANA Considerations 3841 Following the policies outlined in "Guidelines for Writing an IANA 3842 Considerations Section in RFCs" (RFC 5226 [RFC5226]), the following 3843 name spaces are defined in ForCES. 3845 o Message Type Name Space Section 7 3847 o Operation Type Name Space Section 7.1.6 3849 o Header Flags Section 6.1 3851 o TLV Type Section 7 3853 o TLV Result Values Section 7.1.7 3855 o LFB Class ID Section 7.1.5 3857 o Result: Association Setup Response Section 7.5.2 3859 o Reason: Association Teardown Message Section 7.5.3 3861 A.1. Message Type Name Space 3863 The Message Type is an 8 bit value. The following is the guideline 3864 for defining the Message Type namespace 3866 Message Types 0x00 - 0x0F 3867 Message Types in this range are part of the base ForCES Protocol. 3868 Message Types in this range are allocated through an IETF 3869 consensus action. [RFC5226] 3871 Values assigned by this specification: 3873 0x00 Reserved 3874 0x01 AssociationSetup 3875 0x02 AssociationTeardown 3876 0x03 Config 3877 0x04 Query 3878 0x05 EventNotification 3879 0x06 PacketRedirect 3880 0x07 - 0x0E Reserved 3881 0x0F Hearbeat 3882 0x11 AssociationSetupRepsonse 3883 0x12 Reserved 3884 0x13 ConfigRepsonse 3885 0x14 QueryResponse 3887 Message Types 0x20 - 0x7F 3888 Message Types in this range are Specification Required [RFC5226] 3889 Message Types using this range must be documented in an RFC or 3890 other permanent and readily available reference. 3892 Message Types 0x80 - 0xFF 3893 Message Types in this range are reserved for vendor private 3894 extensions and are the responsibility of individual vendors. IANA 3895 management of this range of the Message Type Name Space is 3896 unnecessary. 3898 A.2. Operation Selection 3900 The Operation Selection (OPER-TLV) name space is 16 bits long. The 3901 following is the guideline for managing the OPER-TLV Name Space. 3903 OPER-TLV Type 0x0000-0x00FF 3904 OPER-TLV Types in this range are allocated through an IETF 3905 consensus process. [RFC5226]. 3907 Values assigned by this specification: 3909 0x0000 Reserved 3910 0x0001 SET 3911 0x0002 SET-PROP 3912 0x0003 SET-RESPONSE 3913 0x0004 SET-PROP-RESPONSE 3914 0x0005 DEL 3915 0x0006 DEL-RESPONSE 3916 0x0007 GET 3917 0x0008 GET-PROP 3918 0x0009 GET-RESPONSE 3919 0x000A GET-PROP-RESPONSE 3920 0x000B REPORT 3921 0x000C COMMIT 3922 0x000D COMMIT-RESPONSE 3923 0x000E TRCOMP 3925 OPER-TLV Type 0x0100-0x7FFF 3926 OPER-TLV Types using this range must be documented in an RFC or 3927 other permanent and readily available reference. [RFC5226]. 3929 OPER-TLV Type 0x8000-0xFFFF 3930 OPER-TLV Types in this range are reserved for vendor private 3931 extensions and are the responsibility of individual vendors. IANA 3932 management of this range of the OPER-TLV Type Name Space is 3933 unnecessary. 3935 A.3. Header Flags 3937 The Header flag field is 32 bits long. Header flags are part of 3938 the ForCES base protocol. Header flags are allocated through an 3939 IETF consensus action [RFC5226]. 3941 A.4. TLV Type Name Space 3943 The TLV Type name space is 16 bits long. The following is the 3944 guideline for managing the TLV Type Name Space. 3946 TLV Type 0x0000-0x00FF 3947 TLV Types in this range are allocated through an IETF consensus 3948 process. [RFC5226]. 3950 Values assigned by this specification: 3952 0x0000 Reserved 3953 0x0001 REDIRECT-TLV 3954 0x0010 ASResult-TLV 3955 0x0011 ASTreason-TLV 3956 0x1000 LFBselect-TLV 3957 0x0110 PATH-DATA-TLV 3958 0x0111 KEYINFO-TLV 3959 0x0112 FULLDATA-TLV 3960 0x0113 SPARSEDATA-TLV 3961 0x0114 RESULT-TLV 3962 0x0115 METADATA-TLV 3963 0x0116 REDIRECTDATA-TLV 3965 TLV Type 0x0200-0x7FFF 3966 TLV Types using this range must be documented in an RFC or other 3967 permanent and readily available reference [RFC5226]. 3969 TLV Type 0x8000-0xFFFF 3970 TLV Types in this range are reserved for vendor private extensions 3971 and are the responsibility of individual vendors. IANA management 3972 of this range of the TLV Type Name Space is unnecessary. 3974 A.5. Result-TLV Result Values 3976 The RESULT-TLV RTesult Value is an 8 bit value. 3978 0x00 E_SUCCESS 3979 0x01 E_INVALID_HEADER 3980 0x02 E_LENGTH_MISMATCH 3981 0x03 E_VERSION_MISMATCH 3982 0x04 E_INVALID_DESTINATION_PID 3983 0x05 E_LFB_UNKNOWN 3984 0x06 E_LFB_NOT_FOUND 3985 0x07 E_LFB_INSTANCE_ID_NOT_FOUND 3986 0x08 E_INVALID_PATH 3987 0x09 E_COMPONENT_DOES_NOT_EXIST 3988 0x0A E_EXISTS 3989 0x0B E_NOT_FOUND 3990 0x0C E_READ_ONLY 3991 0x0D E_INVALID_ARRAY_CREATION 3992 0x0E E_VALUE_OUT_OF_RANGE 3993 0x0F E_CONTENTS_TOO_LONG 3994 0x10 E_INVALID_PARAMETERS 3995 0x11 E_INVALID_MESSAGE_TYPE 3996 0x12 E_E_INVALID_FLAGS 3997 0x13 E_INVALID_TLV 3998 0x14 E_EVENT_ERROR 3999 0x15 E_NOT_SUPPORTED 4000 0x16 E_MEMORY_ERROR 4001 0x17 E_INTERNAL_ERROR 4002 0x18-0xFE Reserved 4003 0xFF E_UNSPECIFIED_ERROR 4005 All values not assigned in this specification are designated as 4006 Assignment by Expert review. 4008 A.6. Association Setup Response 4010 The Association Setup Response name space is 32 bits long. The 4011 following is the guideline for managing the Association Setup 4012 Response Name Space. 4014 Association Setup Response 0x0000-0x00FF 4015 Association Setup Responses in this range are allocated through an 4016 IETF consensus process [RFC5226]. 4018 Values assigned by this specification: 4020 0x0000 Success 4021 0x0001 FE ID Invalid 4022 0x0002 Permission Denied 4024 Association Setup Response 0x0100-0x0FFF 4025 Association Setup Responses in this range are Specification 4026 Required [RFC5226] Values using this range must be documented in 4027 an RFC or other permanent and readily available reference 4028 [RFC5226]. 4030 Association Setup Response 0x1000-0xFFFFFFFFF 4031 Association Setup Responses in this range are reserved for vendor 4032 private extensions and are the responsibility of individual 4033 vendors. IANA management of this range of the Association Setup 4034 Responses Name Space is unnecessary. 4036 A.7. Association Teardown Message 4038 The Association Teardown Message name space is 32 bits long. The 4039 following is the guideline for managing the Association Teardown 4040 Message Name Space. 4042 Association Teardown Message 0x00000000-0x0000FFFF 4043 Association Teardown Messages in this range are allocated through 4044 an IETF consensus process [RFC5226]. 4046 Values assigned by this specification: 4048 0x00000000 Normal - Teardown by Administrator 4049 0x00000001 Error - loss of heartbeats 4050 0x00000002 Error - loss of bandwidth 4051 0x00000003 Error - Out of Memory 4052 0x00000004 Error - Application Crash 4053 0x000000FF Error - Unspecified 4055 Association Teardown Message 0x00010000-0x7FFFFFFF 4056 Association Teardown Messages in this range are Specification 4057 Required [RFC5226] Association Teardown Messages using this range 4058 must be documented in an RFC or other permanent and readily 4059 available references. [RFC5226]. 4061 Association Teardown Message 0x80000000-0xFFFFFFFFF 4062 Association Teardown Messages in this range are reserved for 4063 vendor private extensions and are the responsibility of individual 4064 vendors. IANA management of this range of the Association 4065 Teardown Message Name Space is unnecessary. 4067 Appendix B. ForCES Protocol LFB schema 4069 The schema described below conforms to the LFB schema described in 4070 ForCES Model draft. [FE-MODEL] 4072 Section 7.3.1 describes the details of the different components 4073 defined in this definition. 4075 4078 4079 4080 4081 CEHBPolicyValues 4082 4083 The possible values of CE heartbeat policy 4084 4085 4086 uchar 4087 4088 4089 CEHBPolicy0 4090 4091 The CE heartbeat policy 0 4092 4093 4094 4095 CEHBPolicy1 4096 4097 The CE heartbeat policy 1 4098 4099 4100 4101 4102 4104 4105 FEHBPolicyValues 4106 4107 The possible values of FE heartbeat policy 4108 4109 4110 uchar 4111 4112 4113 FEHBPolicy0 4114 4115 The FE heartbeat policy 0 4116 4117 4118 4119 FEHBPolicy1 4120 4121 The FE heartbeat policy 1 4122 4123 4124 4125 4126 4128 4129 FERestartPolicyValues 4130 4131 The possible values of FE restart policy 4132 4133 4134 uchar 4135 4136 4137 FERestartPolicy0 4138 4139 The FE restart policy 0 4140 4141 4142 4143 4144 4146 4147 CEFailoverPolicyValues 4148 4149 The possible values of CE failover policy 4150 4151 4152 uchar 4153 4154 4155 CEFailoverPolicy0 4156 4157 The CE failover policy 0 4158 4159 4160 4161 CEFailoverPolicy1 4162 4163 The CE failover policy 1 4164 4165 4166 4167 4168 4170 4171 FEHACapab 4172 4173 The supported HA features 4174 4175 4176 uchar 4177 4178 4179 GracefullRestart 4180 4181 The FE supports Graceful Restart 4182 4183 4184 4185 HA 4186 4187 The FE supports HA 4188 4189 4190 4191 4192 4193 4195 4196 4197 FEPO 4198 4199 The FE Protocol Object 4200 4201 1.0 4203 4204 4205 CurrentRunningVersion 4206 Currently running ForCES version 4207 u8 4208 4209 4210 FEID 4211 Unicast FEID 4212 uint32 4213 4214 4215 MulticastFEIDs 4216 4217 the table of all multicast IDs 4218 4219 4220 uint32 4221 4222 4223 4224 CEHBPolicy 4225 4226 The CE Heartbeat Policy 4227 4228 CEHBPolicyValues 4229 4230 4231 CEHDI 4232 4233 The CE Heartbeat Dead Interval in millisecs 4234 4235 uint32 4236 4237 4238 FEHBPolicy 4239 4240 The FE Heartbeat Policy 4241 4242 FEHBPolicyValues 4243 4244 4245 FEHI 4246 4247 The FE Heartbeat Interval in millisecs 4248 4249 uint32 4250 4251 4252 CEID 4253 4254 The Primary CE this FE is associated with 4255 4256 uint32 4257 4258 4259 BackupCEs 4260 4261 The table of all backup CEs other than the primary 4262 4263 4264 uint32 4265 4266 4267 4268 CEFailoverPolicy 4269 4270 The CE Failover Policy 4271 4272 CEFailoverPolicyValues 4273 4275 4276 CEFTI 4277 4278 The CE Failover Timeout Interval in millisecs 4279 4280 uint32 4281 4282 4283 FERestartPolicy 4284 4285 The FE Restart Policy 4286 4287 FERestartPolicyValues 4288 4289 4290 LastCEID 4291 4292 The Primary CE this FE was last associated with 4293 4294 uint32 4295 4296 4298 4299 4300 SupportableVersions 4301 4302 the table of ForCES versions that FE supports 4303 4304 4305 u8 4307 4308 4309 4310 HACapabilities 4311 4312 the table of HA capabilities the FE supports 4313 4314 4315 FEHACapab 4316 4317 4318 4320 4321 4322 PrimaryCEDown 4323 4324 The pimary CE has changed 4325 4326 4327 LastCEID 4328 4329 4330 4331 4332 LastCEID 4333 4334 4335 4336 4338 4339 4340 4342 B.1. Capabilities 4344 Supportable Versions enumerates all ForCES versions that an FE 4345 supports. 4347 FEHACapab enumerates the HA capabilities of the FE. If the FE is not 4348 capable of Graceful restarts or HA, then it will not be able to 4349 participate in HA as described in Section 8.1 4351 B.2. Components 4353 All Components are explained in Section 7.3.1. 4355 Appendix C. Data Encoding Examples 4357 In this section a few examples of data encoding are discussed. these 4358 example, however, do not show any padding. 4360 ========== 4361 Example 1: 4362 ========== 4364 Structure with three fixed-lengthof, mandatory fields. 4366 struct S { 4367 uint16 a 4368 uint16 b 4369 uint16 c 4370 } 4372 (a) Describing all fields using SPARSEDATA-TLV 4374 PATH-DATA-TLV 4375 Path to an instance of S ... 4376 SPARSEDATA-TLV 4377 ComponentIDof(a), lengthof(a), valueof(a) 4378 ComponentIDof(b), lengthof(b), valueof(b) 4379 ComponentIDof(c), lengthof(c), valueof(c) 4381 (b) Describing a subset of fields 4383 PATH-DATA-TLV 4384 Path to an instance of S ... 4385 SPARSEDATA-TLV 4386 ComponentIDof(a), lengthof(a), valueof(a) 4387 ComponentIDof(c), lengthof(c), valueof(c) 4389 Note: Even though there are non-optional components in structure S, 4390 since one can uniquely identify components, one can selectively send 4391 component of structure S (eg in the case of an update from CE to FE). 4393 (c) Describing all fields using a FULLDATA-TLV 4395 PATH-DATA-TLV 4396 Path to an instance of S ... 4397 FULLDATA-TLV 4398 valueof(a) 4399 valueof(b) 4400 valueof(c) 4402 ========== 4403 Example 2: 4404 ========== 4406 Structure with three fixed-lengthof fields, one mandatory, two 4407 optional. 4409 struct T { 4410 uint16 a 4411 uint16 b (optional) 4412 uint16 c (optional) 4413 } 4415 This example is identical to Example 1, as illustrated below. 4417 (a) Describing all fields using SPARSEDATA-TLV 4419 PATH-DATA-TLV 4420 Path to an instance of S ... 4421 SPARSEDATA-TLV 4422 ComponentIDof(a), lengthof(a), valueof(a) 4423 ComponentIDof(b), lengthof(b), valueof(b) 4424 ComponentIDof(c), lengthof(c), valueof(c) 4426 (b) Describing a subset of fields using SPARSEDATA-TLV 4428 PATH-DATA-TLV 4429 Path to an instance of S ... 4430 SPARSEDATA-TLV 4431 ComponentIDof(a), lengthof(a), valueof(a) 4432 ComponentIDof(c), lengthof(c), valueof(c) 4434 (c) Describing all fields using a FULLDATA-TLV 4436 PATH-DATA-TLV 4437 Path to an instance of S ... 4438 FULLDATA-TLV 4439 valueof(a) 4440 valueof(b) 4441 valueof(c) 4443 Note: FULLDATA-TLV _cannot_ be used unless all fields are being 4444 described. 4446 ========== 4447 Example 3: 4448 ========== 4449 Structure with a mix of fixed-lengthof and variable-lengthof fields, 4450 some mandatory, some optional. Note in this case, b is variable 4451 sized 4453 struct U { 4454 uint16 a 4455 string b (optional) 4456 uint16 c (optional) 4457 } 4459 (a) Describing all fields using SPARSEDATA-TLV 4461 Path to an instance of U ... 4462 SPARSEDATA-TLV 4463 ComponentIDof(a), lengthof(a), valueof(a) 4464 ComponentIDof(b), lengthof(b), valueof(b) 4465 ComponentIDof(c), lengthof(c), valueof(c) 4467 (b) Describing a subset of fields using SPARSEDATA-TLV 4469 Path to an instance of U ... 4470 SPARSEDATA-TLV 4471 ComponentIDof(a), lengthof(a), valueof(a) 4472 ComponentIDof(c), lengthof(c), valueof(c) 4474 (c) Describing all fields using FULLDATA-TLV 4476 Path to an instance of U ... 4477 FULLDATA-TLV 4478 valueof(a) 4479 FULLDATA-TLV 4480 valueof(b) 4481 valueof(c) 4483 Note: The variable-length field requires the addition of a FULLDATA- 4484 TLV within the outer FULLDATA-TLV as in the case of component b 4485 above. 4487 ========== 4488 Example 4: 4489 ========== 4491 Structure containing an array of another structure type. 4493 struct V { 4494 uint32 x 4495 uint32 y 4496 struct U z[] 4497 } 4499 (a) Encoding using SPARSEDATA-TLV, with two instances of z[], also 4500 described with SPARSEDATA-TLV, assuming only the 10th and 15th 4501 subscript of z[] are encoded. 4503 path to instance of V ... 4504 SPARSEDATA-TLV 4505 ComponentIDof(x), lengthof(x), valueof(x) 4506 ComponentIDof(y), lengthof(y), valueof(y) 4507 ComponentIDof(z), lengthof(all below) 4508 ComponentID = 10 (i.e index 10 from z[]), lengthof(all below) 4509 ComponentIDof(a), lengthof(a), valueof(a) 4510 ComponentIDof(b), lengthof(b), valueof(b) 4511 ComponentID = 15 (index 15 from z[]), lengthof(all below) 4512 ComponentIDof(a), lengthof(a), valueof(a) 4513 ComponentIDof(c), lengthof(c), valueof(c) 4515 Note the holes in the components of z (10 followed by 15). Also note 4516 the gap in index 15 with only components a and c appearing but not b. 4518 Appendix D. Use Cases 4520 Assume LFB with following components for the following use cases. 4522 foo1, type u32, ID = 1 4524 foo2, type u32, ID = 2 4526 table1: type array, ID = 3 4527 components are: 4528 t1, type u32, ID = 1 4529 t2, type u32, ID = 2 // index into table2 4530 KEY: nhkey, ID = 1, V = t2 4532 table2: type array, ID = 4 4533 components are: 4534 j1, type u32, ID = 1 4535 j2, type u32, ID = 2 4536 KEY: akey, ID = 1, V = { j1,j2 } 4538 table3: type array, ID = 5 4539 components are: 4540 someid, type u32, ID = 1 4541 name, type string variable sized, ID = 2 4543 table4: type array, ID = 6 4544 components are: 4545 j1, type u32, ID = 1 4546 j2, type u32, ID = 2 4547 j3, type u32, ID = 3 4548 j4, type u32, ID = 4 4549 KEY: mykey, ID = 1, V = { j1} 4551 table5: type array, ID = 7 4552 components are: 4553 p1, type u32, ID = 1 4554 p2, type array, ID = 2, array components of type-X 4556 Type-X: 4557 x1, ID 1, type u32 4558 x2, ID2 , type u32 4559 KEY: tkey, ID = 1, V = { x1} 4561 All examples will use valueof(x) to indicate the value of the 4562 referenced component x. In the case where F_SEL** are missing (bits 4563 equal to 00) then the flags will not show any selection. 4565 All the examples only show use of FULLDATA-TLV for data encoding; 4566 although SPARSEDATA-TLV would make more sense in certain occasions, 4567 the emphasis is on showing the message layout. Refer to Appendix C 4568 for examples that show usage of both FULLDATA-TLV and SPARSEDATA-TLV. 4570 1. To get foo1 4572 OPER = GET-TLV 4573 PATH-DATA-TLV: IDCount = 1, IDs = 1 4574 Result: 4575 OPER = GET-RESPONSE-TLV 4576 PATH-DATA-TLV: 4577 flags=0, IDCount = 1, IDs = 1 4578 FULLDATA-TLV L = 4+4, V = valueof(foo1) 4580 2. To set foo2 to 10 4582 OPER = SET-TLV 4583 PATH-DATA-TLV: 4584 flags = 0, IDCount = 1, IDs = 2 4585 FULLDATA-TLV: L = 4+4, V=10 4587 Result: 4588 OPER = SET-RESPONSE-TLV 4589 PATH-DATA-TLV: 4590 flags = 0, IDCount = 1, IDs = 2 4591 RESULT-TLV 4593 3. To dump table2 4595 OPER = GET-TLV 4596 PATH-DATA-TLV: 4597 IDCount = 1, IDs = 4 4598 Result: 4599 OPER = GET-RESPONSE-TLV 4600 PATH-DATA-TLV: 4601 flags = 0, IDCount = 1, IDs = 4 4602 FULLDATA-TLV: L = XXX, V= 4603 a series of: index, valueof(j1), valueof(j2) 4604 representing the entire table 4606 Note: One should be able to take a GET-RESPONSE-TLV and 4607 convert it to a SET-TLV. If the result in the above example 4608 is sent back in a SET-TLV, (instead of a GET-RESPONSE_TLV) 4609 then the entire contents of the table will be replaced at 4610 that point. 4612 4. Multiple operations Example. To create entry 0-5 of table2 4613 (Error conditions are ignored) 4615 OPER = SET-TLV 4616 PATH-DATA-TLV: 4617 flags = 0 , IDCount = 1, IDs=4 4618 PATH-DATA-TLV 4619 flags = 0, IDCount = 1, IDs = 0 4620 FULLDATA-TLV valueof(j1), valueof(j2) of entry 0 4621 PATH-DATA-TLV 4622 flags = 0, IDCount = 1, IDs = 1 4623 FULLDATA-TLV valueof(j1), valueof(j2) of entry 1 4624 PATH-DATA-TLV 4625 flags = 0, IDCount = 1, IDs = 2 4626 FULLDATA-TLV valueof(j1), valueof(j2) of entry 2 4627 PATH-DATA-TLV 4628 flags = 0, IDCount = 1, IDs = 3 4629 FULLDATA-TLV valueof(j1), valueof(j2) of entry 3 4630 PATH-DATA-TLV 4631 flags = 0, IDCount = 1, IDs = 4 4632 FULLDATA-TLV valueof(j1), valueof(j2) of entry 4 4633 PATH-DATA-TLV 4634 flags = 0, IDCount = 1, IDs = 5 4635 FULLDATA-TLV valueof(j1), valueof(j2) of entry 5 4637 Result: 4638 OPER = SET-RESPONSE-TLV 4639 PATH-DATA-TLV: 4640 flags = 0 , IDCount = 1, IDs=4 4641 PATH-DATA-TLV 4642 flags = 0, IDCount = 1, IDs = 0 4643 RESULT-TLV 4644 PATH-DATA-TLV 4645 flags = 0, IDCount = 1, IDs = 1 4646 RESULT-TLV 4647 PATH-DATA-TLV 4648 flags = 0, IDCount = 1, IDs = 2 4649 RESULT-TLV 4650 PATH-DATA-TLV 4651 flags = 0, IDCount = 1, IDs = 3 4652 RESULT-TLV 4653 PATH-DATA-TLV 4654 flags = 0, IDCount = 1, IDs = 4 4655 RESULT-TLV 4656 PATH-DATA-TLV 4657 flags = 0, IDCount = 1, IDs = 5 4658 RESULT-TLV 4660 5. Block operations (with holes) example. Replace entry 0,2 of 4661 table2 4663 OPER = SET-TLV 4664 PATH-DATA-TLV: 4665 flags = 0 , IDCount = 1, IDs=4 4666 PATH-DATA-TLV 4667 flags = 0, IDCount = 1, IDs = 0 4668 FULLDATA-TLV containing valueof(j1), valueof(j2) of 0 4669 PATH-DATA-TLV 4670 flags = 0, IDCount = 1, IDs = 2 4671 FULLDATA-TLV containing valueof(j1), valueof(j2) of 2 4673 Result: 4674 OPER = SET-TLV 4675 PATH-DATA-TLV: 4676 flags = 0 , IDCount = 1, IDs=4 4677 PATH-DATA-TLV 4678 flags = 0, IDCount = 1, IDs = 0 4679 RESULT-TLV 4680 PATH-DATA-TLV 4681 flags = 0, IDCount = 1, IDs = 2 4682 RESULT-TLV 4684 6. Getting rows example. Get first entry of table2. 4686 OPER = GET-TLV 4687 PATH-DATA-TLV: 4688 IDCount = 2, IDs=4.0 4690 Result: 4691 OPER = GET-RESPONSE-TLV 4692 PATH-DATA-TLV: 4693 IDCount = 2, IDs=4.0 4694 FULLDATA-TLV containing valueof(j1), valueof(j2) 4696 7. Get entry 0-5 of table2. 4698 OPER = GET-TLV 4699 PATH-DATA-TLV: 4700 flags = 0, IDCount = 1, IDs=4 4701 PATH-DATA-TLV 4702 flags = 0, IDCount = 1, IDs = 0 4703 PATH-DATA-TLV 4704 flags = 0, IDCount = 1, IDs = 1 4705 PATH-DATA-TLV 4706 flags = 0, IDCount = 1, IDs = 2 4707 PATH-DATA-TLV 4708 flags = 0, IDCount = 1, IDs = 3 4709 PATH-DATA-TLV 4710 flags = 0, IDCount = 1, IDs = 4 4711 PATH-DATA-TLV 4712 flags = 0, IDCount = 1, IDs = 5 4714 Result: 4715 OPER = GET-RESPONSE-TLV 4716 PATH-DATA-TLV: 4717 flags = 0, IDCount = 1, IDs=4 4718 PATH-DATA-TLV 4719 flags = 0, IDCount = 1, IDs = 0 4720 FULLDATA-TLV containing valueof(j1), valueof(j2) 4721 PATH-DATA-TLV 4722 flags = 0, IDCount = 1, IDs = 1 4723 FULLDATA-TLV containing valueof(j1), valueof(j2) 4724 PATH-DATA-TLV 4725 flags = 0, IDCount = 1, IDs = 2 4726 FULLDATA-TLV containing valueof(j1), valueof(j2) 4727 PATH-DATA-TLV 4728 flags = 0, IDCount = 1, IDs = 3 4729 FULLDATA-TLV containing valueof(j1), valueof(j2) 4730 PATH-DATA-TLV 4731 flags = 0, IDCount = 1, IDs = 4 4732 FULLDATA-TLV containing valueof(j1), valueof(j2) 4733 PATH-DATA-TLV 4734 flags = 0, IDCount = 1, IDs = 5 4735 FULLDATA-TLV containing valueof(j1), valueof(j2) 4737 8. Create a row in table2, index 5. 4739 OPER = SET-TLV 4740 PATH-DATA-TLV: 4741 flags = 0, IDCount = 2, IDs=4.5 4742 FULLDATA-TLV containing valueof(j1), valueof(j2) 4744 Result: 4745 OPER = SET-RESPONSE-TLV 4746 PATH-DATA-TLV: 4747 flags = 0, IDCount = 1, IDs=4.5 4748 RESULT-TLV 4750 9. Dump contents of table1. 4752 OPER = GET-TLV 4753 PATH-DATA-TLV: 4754 flags = 0, IDCount = 1, IDs=3 4756 Result: 4757 OPER = GET-RESPONSE-TLV 4758 PATH-DATA-TLV 4759 flags = 0, IDCount = 1, IDs=3 4760 FULLDATA-TLV, Length = XXXX 4761 (depending on size of table1) 4762 index, valueof(t1),valueof(t2) 4763 index, valueof(t1),valueof(t2) 4764 . 4765 . 4766 . 4768 10. Using Keys. Get row entry from table4 where j1=100. Recall, j1 4769 is a defined key for this table and its KeyID is 1. 4771 OPER = GET-TLV 4772 PATH-DATA-TLV: 4773 flags = F_SELKEY IDCount = 1, IDs=6 4774 KEYINFO-TLV = KeyID=1, KEY_DATA=100 4776 Result: 4777 If j1=100 was at index 10 4778 OPER = GET-RESPONSE-TLV 4779 PATH-DATA-TLV: 4780 flags = 0, IDCount = 1, IDs=6.10 4781 FULLDATA-TLV containing 4782 valueof(j1), valueof(j2),valueof(j3),valueof(j4) 4784 11. Delete row with KEY match (j1=100, j2=200) in table2. Note that 4785 the j1,j2 pair are a defined key for the table2. 4787 OPER = DEL-TLV 4788 PATH-DATA-TLV: 4789 flags = F_SELKEY IDCount = 1, IDs=4 4790 KEYINFO-TLV: {KeyID =1 KEY_DATA=100,200} 4792 Result: 4793 If (j1=100, j2=200) was at entry 15: 4794 OPER = DELETE-RESPONSE-TLV 4795 PATH-DATA-TLV: 4796 flags = 0 IDCount = 2, IDs=4.15 4797 RESULT-TLV 4799 12. Dump contents of table3. It should be noted that this table has 4800 a column with component name that is variable sized. The 4801 purpose of this use case is to show how such an component is to 4802 be encoded. 4804 OPER = GET-TLV 4805 PATH-DATA-TLV: 4806 flags = 0 IDCount = 1, IDs=5 4808 Result: 4809 OPER = GET-RESPONSE-TLV 4810 PATH-DATA-TLV: 4811 flags = 0 IDCount = 1, IDs=5 4812 FULLDATA-TLV, Length = XXXX 4813 index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), 4814 V = valueof(v) 4815 index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), 4816 V = valueof(v) 4817 index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), 4818 V = valueof(v) 4819 index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev), 4820 V = valueof(v) 4821 . 4822 . 4823 . 4825 13. Multiple atomic operations. 4827 Note 1: This emulates adding a new nexthop entry and then 4828 atomically updating the L3 entries pointing to an old NH to 4829 point to a new one. The assumption is both tables are in the 4830 same LFB 4832 Note2: Observe the two operations on the LFB instance, both 4833 are SET operations. 4835 //Operation 1: Add a new entry to table2 index #20. 4836 OPER = SET-TLV 4837 Path-TLV: 4838 flags = 0, IDCount = 2, IDs=4.20 4839 FULLDATA-TLV, V= valueof(j1),valueof(j2) 4841 // Operation 2: Update table1 entry which 4842 // was pointing with t2 = 10 to now point to 20 4843 OPER = SET-TLV 4844 PATH-DATA-TLV: 4845 flags = F_SELKEY, IDCount = 1, IDs=3 4846 KEYINFO-TLV = KeyID=1 KEY_DATA=10 4847 PATH-DATA-TLV 4848 flags = 0 IDCount = 1, IDs=2 4849 FULLDATA-TLV, V= 20 4851 Result: 4852 //first operation, SET 4853 OPER = SET-RESPONSE-TLV 4854 PATH-DATA-TLV 4855 flags = 0 IDCount = 3, IDs=4.20 4856 RESULT-TLV code = success 4857 FULLDATA-TLV, V = valueof(j1),valueof(j2) 4858 // second operation SET - assuming entry 16 was updated 4859 OPER = SET-RESPONSE-TLV 4860 PATH-DATA-TLV 4861 flags = 0 IDCount = 2, IDs=3.16 4862 PATH-DATA-TLV 4863 flags = 0 IDCount = 1, IDs = 2 4864 RESULT-TLV code = success 4865 FULLDATA-TLV, Length = XXXX v=20 4867 14. Selective setting. On table4 -- for indices 1, 3, 5, 7, and 9. 4868 Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. 4870 PER = SET-TLV 4871 PATH-DATA-TLV 4872 flags = 0, IDCount = 1, IDs = 6 4873 PATH-DATA-TLV 4874 flags = 0, IDCount = 1, IDs = 1 4875 PATH-DATA-TLV 4876 flags = 0, IDCount = 1, IDs = 1 4877 FULLDATA-TLV, Length = XXXX, V = {100} 4878 PATH-DATA-TLV 4879 flags = 0, IDCount = 1, IDs = 2 4880 FULLDATA-TLV, Length = XXXX, V = {200} 4881 PATH-DATA-TLV 4882 flags = 0, IDCount = 1, IDs = 3 4883 FULLDATA-TLV, Length = XXXX, V = {300} 4884 PATH-DATA-TLV 4885 flags = 0, IDCount = 1, IDs = 3 4886 PATH-DATA-TLV 4887 flags = 0, IDCount = 1, IDs = 1 4888 FULLDATA-TLV, Length = XXXX, V = {100} 4889 PATH-DATA-TLV 4890 flags = 0, IDCount = 1, IDs = 2 4891 FULLDATA-TLV, Length = XXXX, V = {200} 4892 PATH-DATA-TLV 4893 flags = 0, IDCount = 1, IDs = 3 4894 FULLDATA-TLV, Length = XXXX, V = {300} 4895 PATH-DATA-TLV 4896 flags = 0, IDCount = 1, IDs = 5 4897 PATH-DATA-TLV 4898 flags = 0, IDCount = 1, IDs = 1 4899 FULLDATA-TLV, Length = XXXX, V = {100} 4900 PATH-DATA-TLV 4901 flags = 0, IDCount = 1, IDs = 2 4902 FULLDATA-TLV, Length = XXXX, V = {200} 4903 PATH-DATA-TLV 4904 flags = 0, IDCount = 1, IDs = 3 4905 FULLDATA-TLV, Length = XXXX, V = {300} 4906 PATH-DATA-TLV 4907 flags = 0, IDCount = 1, IDs = 7 4908 PATH-DATA-TLV 4909 flags = 0, IDCount = 1, IDs = 1 4910 FULLDATA-TLV, Length = XXXX, V = {100} 4911 PATH-DATA-TLV 4912 flags = 0, IDCount = 1, IDs = 2 4913 FULLDATA-TLV, Length = XXXX, V = {200} 4914 PATH-DATA-TLV 4915 flags = 0, IDCount = 1, IDs = 3 4916 FULLDATA-TLV, Length = XXXX, V = {300} 4917 PATH-DATA-TLV 4918 flags = 0, IDCount = 1, IDs = 9 4919 PATH-DATA-TLV 4920 flags = 0, IDCount = 1, IDs = 1 4921 FULLDATA-TLV, Length = XXXX, V = {100} 4922 PATH-DATA-TLV 4923 flags = 0, IDCount = 1, IDs = 2 4924 FULLDATA-TLV, Length = XXXX, V = {200} 4925 PATH-DATA-TLV 4926 flags = 0, IDCount = 1, IDs = 3 4927 FULLDATA-TLV, Length = XXXX, V = {300} 4929 response: 4931 OPER = SET-RESPONSE-TLV 4932 PATH-DATA-TLV 4933 flags = 0, IDCount = 1, IDs = 6 4934 PATH-DATA-TLV 4935 flags = 0, IDCount = 1, IDs = 1 4936 PATH-DATA-TLV 4937 flags = 0, IDCount = 1, IDs = 1 4938 RESULT-TLV 4939 PATH-DATA-TLV 4940 flags = 0, IDCount = 1, IDs = 2 4941 RESULT-TLV 4942 PATH-DATA-TLV 4943 flags = 0, IDCount = 1, IDs = 3 4944 RESULT-TLV 4945 PATH-DATA-TLV 4946 flags = 0, IDCount = 1, IDs = 3 4947 PATH-DATA-TLV 4948 flags = 0, IDCount = 1, IDs = 1 4949 RESULT-TLV 4950 PATH-DATA-TLV 4951 flags = 0, IDCount = 1, IDs = 2 4952 RESULT-TLV 4953 PATH-DATA-TLV 4954 flags = 0, IDCount = 1, IDs = 3 4955 RESULT-TLV 4956 PATH-DATA-TLV 4957 flags = 0, IDCount = 1, IDs = 5 4958 PATH-DATA-TLV 4959 flags = 0, IDCount = 1, IDs = 1 4960 RESULT-TLV 4961 PATH-DATA-TLV 4962 flags = 0, IDCount = 1, IDs = 2 4963 RESULT-TLV 4964 PATH-DATA-TLV 4965 flags = 0, IDCount = 1, IDs = 3 4966 RESULT-TLV 4967 PATH-DATA-TLV 4968 flags = 0, IDCount = 1, IDs = 7 4969 PATH-DATA-TLV 4970 flags = 0, IDCount = 1, IDs = 1 4971 RESULT-TLV 4972 PATH-DATA-TLV 4973 flags = 0, IDCount = 1, IDs = 2 4974 RESULT-TLV 4975 PATH-DATA-TLV 4976 flags = 0, IDCount = 1, IDs = 3 4977 RESULT-TLV 4978 PATH-DATA-TLV 4979 flags = 0, IDCount = 1, IDs = 9 4980 PATH-DATA-TLV 4981 flags = 0, IDCount = 1, IDs = 1 4982 RESULT-TLV 4983 PATH-DATA-TLV 4984 flags = 0, IDCount = 1, IDs = 2 4985 RESULT-TLV 4986 PATH-DATA-TLV 4987 flags = 0, IDCount = 1, IDs = 3 4988 RESULT-TLV 4990 15. Manipulation of table of table examples. Get x1 from table10 4991 row with index 4, inside table5 entry 10 4993 operation = GET-TLV 4994 PATH-DATA-TLV 4995 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4997 Results: 4998 operation = GET-RESPONSE-TLV 4999 PATH-DATA-TLV 5000 flags = 0 IDCount = 5, IDs=7.10.2.4.1 5001 FULLDATA-TLV: L=XXXX, V = valueof(x1) 5003 16. From table5's row 10 table10, get X2s based on on the value of 5004 x1 equaling 10 (recall x1 is KeyID 1) 5006 operation = GET-TLV 5007 PATH-DATA-TLV 5008 flag = F_SELKEY, IDCount=3, IDS = 7.10.2 5009 KEYINFO-TLV, KeyID = 1, KEYDATA = 10 5010 PATH-DATA-TLV 5011 IDCount = 1, IDS = 2 //select x2 5013 Results: 5014 If x1=10 was at entry 11: 5015 operation = GET-RESPONSE-TLV 5016 PATH-DATA-TLV 5017 flag = 0, IDCount=5, IDS = 7.10.2.11 5018 PATH-DATA-TLV 5019 flags = 0 IDCount = 1, IDS = 2 5020 FULLDATA-TLV: L=XXXX, V = valueof(x2) 5022 17. Further example of manipulating a table of tables 5024 Consider table6 which is defined as: 5025 table6: type array, ID = 8 5026 components are: 5027 p1, type u32, ID = 1 5028 p2, type array, ID = 2, array components of type type-A 5030 type-A: 5031 a1, type u32, ID 1, 5032 a2, type array ID2 ,array components of type type-B 5034 type-B: 5035 b1, type u32, ID 1 5036 b2, type u32, ID 2 5038 If for example one wanted to set by replacing: 5039 table6.10.p1 to 111 5040 table6.10.p2.20.a1 to 222 5041 table6.10.p2.20.a2.30.b1 to 333 5043 in one message and one operation. 5045 There are two ways to do this: 5046 a) using nesting 5047 b) using a flat path data 5049 A. Method using nesting 5050 in one message with a single operation 5052 operation = SET-TLV 5053 PATH-DATA-TLV 5054 flags = 0 IDCount = 2, IDs=6.10 5055 PATH-DATA-TLV 5056 flags = 0, IDCount = 1, IDs=1 5057 FULLDATA-TLV: L=XXXX, 5058 V = {111} 5059 PATH-DATA-TLV 5060 flags = 0 IDCount = 2, IDs=2.20 5061 PATH-DATA-TLV 5062 flags = 0, IDCount = 1, IDs=1 5063 FULLDATA-TLV: L=XXXX, 5064 V = {222} 5065 PATH-DATA-TLV : 5066 flags = 0, IDCount = 3, IDs=2.30.1 5067 FULLDATA-TLV: L=XXXX, 5068 V = {333} 5069 Result: 5070 operation = SET-RESPONSE-TLV 5071 PATH-DATA-TLV 5072 flags = 0 IDCount = 2, IDs=6.10 5073 PATH-DATA-TLV 5074 flags = 0, IDCount = 1, IDs=1 5075 RESULT-TLV 5076 PATH-DATA-TLV 5077 flags = 0 IDCount = 2, IDs=2.20 5078 PATH-DATA-TLV 5079 flags = 0, IDCount = 1, IDs=1 5080 RESULT-TLV 5081 PATH-DATA-TLV : 5082 flags = 0, IDCount = 3, IDs=2.30.1 5083 RESULT-TLV 5085 B. Method using a flat path data in 5086 one message with a single operation 5088 operation = SET-TLV 5089 PATH-DATA-TLV : 5090 flags = 0, IDCount = 3, IDs=6.10.1 5091 FULLDATA-TLV: L=XXXX, 5092 V = {111} 5093 PATH-DATA-TLV : 5094 flags = 0, IDCount = 5, IDs=6.10.1.20.1 5095 FULLDATA-TLV: L=XXXX, 5096 V = {222} 5097 PATH-DATA-TLV : 5098 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 5099 FULLDATA-TLV: L=XXXX, 5100 V = {333} 5101 Result: 5102 operation = SET-TLV 5103 PATH-DATA-TLV : 5104 flags = 0, IDCount = 3, IDs=6.10.1 5105 RESULT-TLV 5106 PATH-DATA-TLV : 5107 flags = 0, IDCount = 5, IDs=6.10.1.20.1 5108 RESULT-TLV 5109 PATH-DATA-TLV : 5110 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 5111 RESULT-TLV 5113 18. Get a whole LFB (all its components, etc.). 5115 For example: at startup a CE might well want the entire FE 5116 OBJECT LFB. So, in a request targeted at class 1, instance 5117 1, one might find: 5119 operation = GET-TLV 5120 PATH-DATA-TLV 5121 flags = 0 IDCount = 0 5123 result: 5124 operation = GET-RESPONSE-TLV 5125 PATH-DATA-TLV 5126 flags = 0 IDCount = 0 5127 FULLDATA-TLV encoding of the FE Object LFB 5129 Authors' Addresses 5131 Ligang Dong 5132 Zhejiang Gongshang University 5133 149 Jiaogong Road 5134 Hangzhou 310035 5135 P.R.China 5137 Phone: +86-571-88071024 5138 Email: donglg@mail.zjgsu.edu.cn 5140 Avri Doria 5141 Lulea University of Technology 5142 Rainbow Way 5143 Lulea SE-971 87 5144 Sweden 5146 Phone: +46 73 277 1788 5147 Email: avri@ltu.se 5149 Ram Gopal 5150 Nokia 5151 5, Wayside Road 5152 Burlington, MA 310035 5153 USA 5155 Phone: +1-781-993-3685 5156 Email: ram.gopal@nsn.com 5158 Robert Haas 5159 IBM 5160 Saumerstrasse 4 5161 8803 Ruschlikon 5162 Switzerland 5164 Phone: 5165 Email: rha@zurich.ibm.com 5166 Jamal Hadi Salim 5167 Znyx 5168 Ottawa, Ontario 5169 Canada 5171 Phone: 5172 Email: hadi@znyx.com 5174 Hormuzd M Khosravi 5175 Intel 5176 2111 NE 25th Avenue 5177 Hillsboro, OR 97124 5178 USA 5180 Phone: +1 503 264 0334 5181 Email: hormuzd.m.khosravi@intel.com 5183 Weiming Wang 5184 Zhejiang Gongshang University 5185 149 Jiaogong Road 5186 Hangzhou 310035 5187 P.R.China 5189 Phone: +86-571-88057712 5190 Email: wmwang@mail.zjgsu.edu.cn