idnits 2.17.1 draft-ietf-forces-protocol-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4722. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4712. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 'NoACK' (0b00) - to indicate that the message receiver MUST not to send any response message back to this message sender. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 23, 2006) is 6609 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: 'MAIN-TLV' is mentioned on line 1366, but not defined == Missing Reference: 'LFBselect-TLV' is mentioned on line 1367, but not defined == Missing Reference: 'REDIRECT-TLV' is mentioned on line 1367, but not defined == Missing Reference: 'ASResult-TLV' is mentioned on line 1368, but not defined == Missing Reference: 'ASTreason-TLV' is mentioned on line 1368, but not defined == Missing Reference: 'DATA' is mentioned on line 1371, but not defined == Missing Reference: 'SELECTOR' is mentioned on line 1372, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FE-MODEL' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 3654 ** Downref: Normative reference to an Informational RFC: RFC 3746 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 9 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 ETRI 4 Expires: September 24, 2006 R. Haas (Ed.) 5 IBM 6 J. Hadi Salim (Ed.) 7 Znyx 8 H. Khosravi (Ed.) 9 Intel 10 W. M. Wang (Ed.) 11 Zhejiang Gongshang University 12 March 23, 2006 14 ForCES Protocol Specification 15 draft-ietf-forces-protocol-08.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 24, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This document specifies the Forwarding and Control Element Separation 49 (ForCES) protocol. ForCES protocol is used for communications 50 between Control Elements(CEs) and Forwarding Elements (FEs) in a 51 ForCES Network Element (ForCES NE). This specification is intended 52 to meet the ForCES protocol requirements defined in RFC3654. Besides 53 the ForCES protocol messages, the specification also defines the 54 framework, the mechanisms, and the Transport Mapping Layer (TML) 55 requirements for ForCES protocol. 57 Authors 59 The participants in the ForCES Protocol Team, primary co-authors and 60 co-editors, of this protocol specification, are: 62 Ligang Dong (Zhejiang Gongshang University), Avri Doria (ETRI), Ram 63 Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M 64 Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). 66 Table of Contents 68 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 11 73 4.1.1. The PL layer . . . . . . . . . . . . . . . . . . . . 13 74 4.1.2. The TML layer . . . . . . . . . . . . . . . . . . . . 14 75 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 14 76 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 15 77 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 16 78 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18 79 4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 19 80 4.3.1. Transactions, Atomicity, Execution and Responses . . 19 81 4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 23 82 4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 23 83 4.3.4. FE Object and FE protocol LFBs . . . . . . . . . . . 24 84 5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 25 85 5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 26 86 6. Message encapsulation . . . . . . . . . . . . . . . . . . . . 27 87 6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 27 88 6.2. Type Length Value(TLV) Structuring . . . . . . . . . . . 32 89 6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 32 90 6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 32 91 6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 92 7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 34 93 7.1. Protocol Grammar . . . . . . . . . . . . . . . . . . . . 34 94 7.1.1. Protocol BNF . . . . . . . . . . . . . . . . . . . . 34 95 7.1.2. Protocol Visualization . . . . . . . . . . . . . . . 43 96 7.2. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 46 97 7.2.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 47 98 7.2.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 50 99 7.3. Semantics of message Direction . . . . . . . . . . . . . 50 100 7.4. Association Messages . . . . . . . . . . . . . . . . . . 50 101 7.4.1. Association Setup Message . . . . . . . . . . . . . . 50 102 7.4.2. Association Setup Response Message . . . . . . . . . 52 103 7.4.3. Association Teardown Message . . . . . . . . . . . . 53 104 7.5. Configuration Messages . . . . . . . . . . . . . . . . . 54 105 7.5.1. Config Message . . . . . . . . . . . . . . . . . . . 54 106 7.5.2. Config Response Message . . . . . . . . . . . . . . . 56 107 7.6. Query Messages . . . . . . . . . . . . . . . . . . . . . 57 108 7.6.1. Query Message . . . . . . . . . . . . . . . . . . . . 58 109 7.6.2. Query Response Message . . . . . . . . . . . . . . . 59 110 7.7. Event Notification Message . . . . . . . . . . . . . . . 60 111 7.8. Packet Redirect Message . . . . . . . . . . . . . . . . . 62 112 7.9. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 65 113 7.10. Operation Summary . . . . . . . . . . . . . . . . . . . . 66 115 8. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . 69 116 8.1. Association Setup state . . . . . . . . . . . . . . . . . 69 117 8.2. Association Established state or Steady State . . . . . . 70 118 9. High Availability Support . . . . . . . . . . . . . . . . . . 73 119 9.1. Responsibilities for HA . . . . . . . . . . . . . . . . . 75 120 10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 121 10.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 77 122 10.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 77 123 10.1.2. Message authentication . . . . . . . . . . . . . . . 78 124 10.2. ForCES PL and TML security service . . . . . . . . . . . 78 125 10.2.1. Endpoint authentication service . . . . . . . . . . . 78 126 10.2.2. Message authentication service . . . . . . . . . . . 78 127 10.2.3. Confidentiality service . . . . . . . . . . . . . . . 79 128 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80 129 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 130 12.1. Normative References . . . . . . . . . . . . . . . . . . 81 131 12.2. Informational References . . . . . . . . . . . . . . . . 81 132 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 82 133 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 82 134 A.2. Operation Type . . . . . . . . . . . . . . . . . . . . . 83 135 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 83 136 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 84 137 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 84 138 A.6. LFB Class Id Name Space . . . . . . . . . . . . . . . . . 85 139 A.7. Association Setup Response . . . . . . . . . . . . . . . 86 140 A.8. Association Teardown Message . . . . . . . . . . . . . . 86 141 A.9. Configuration Request Result . . . . . . . . . . . . . . 87 142 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 88 143 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 93 144 B.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 93 145 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 94 146 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 98 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114 148 Intellectual Property and Copyright Statements . . . . . . . . . 116 150 1. Terminology and Conventions 152 The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 153 RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted 154 as described in BCP 14, RFC 2119 [RFC2119]. 156 2. Introduction 158 Forwarding and Control Element Separation (ForCES) defines an 159 architectural framework and associated protocols to standardize 160 information exchange between the control plane and the forwarding 161 plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined 162 the ForCES requirements, and RFC 3764 has defined the ForCES 163 framework. While there may be multiple protocols used within the 164 overall ForCES architecture, the term "ForCES protocol" and 165 "protocol" as used in this document refers to the protocol used to 166 standardize the information exchange between Control Elements(CEs) 167 and Forwarding Elements(FEs) only. ForCES FE model [FE-MODEL] 168 presents the capabilities, state and configuration of FEs within the 169 context of the ForCES protocol, so that CEs can accordingly control 170 the FEs in a standardizded way and by means of the ForCES protocol. 172 This document defines the ForCES protocol specifications. The ForCES 173 protocol works in a master-slave mode in which FEs are slaves and CEs 174 are masters. Information exchanged between FEs and CEs makes 175 extensive use of TLVs. The protocol includes commands for transport 176 of LFB configuration information, association setup, status and event 177 notifications, etc. 179 This specification does not define a transport mechanism for protocol 180 messages, but does include a discussion of service primitives that 181 must be provided by the underlying transport interface. 183 Section 3 provides a glossary of terminology used in the 184 specification. 186 Section 4 provides an overview of the protocol including a discussion 187 on the protocol framework, descriptions of the Protocol Layer (PL) 188 and a Transport Mapping Layer (TML), as well as of the ForCES 189 protocol mechanisms. 191 While this document does not define the TML, Section 5 details the 192 services that a TML must provide (TML requirements). 194 The ForCES protocol defines a common header for all protocol 195 messages. The header is defined in Section 6.1, while the protocol 196 messages are defined in Section 7. 198 Section 8 describes several Protocol Scenarios and includes message 199 exchange descriptions. 201 Section 9 describes a mechanism in the protocol to support high 202 availability mechanisms including redundancy and fail over. 203 Section 10 defines the security mechanisms provided by the PL and 204 TML. 206 3. Definitions 208 This document follows the terminology defined by the ForCES 209 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 210 The definitions below are repeated below for clarity. 212 Addressable Entity (AE) - A physical device that is directly 213 addressable given some interconnect technology. For example, on IP 214 networks, it is a device which can be reached using an IP address; 215 and on a switch fabric, it is a device which can be reached using a 216 switch fabric port number. 218 Forwarding Element (FE) - A logical entity that implements the ForCES 219 protocol. FEs use the underlying hardware to provide per-packet 220 processing and handling as directed/controlled by a CE via the ForCES 221 protocol. 223 Control Element (CE) - A logical entity that implements the ForCES 224 protocol and uses it to instruct one or more FEs on how to process 225 packets. CEs handle functionality such as the execution of control 226 and signaling protocols. 228 Pre-association Phase - The period of time during which an FE Manager 229 (see below) and a CE Manager (see below) are determining which FE(s) 230 and CE(s) should be part of the same network element. 232 Post-association Phase - The period of time during which an FE knows 233 which CE is to control it and vice versa. This includes the time 234 during which the CE and FE are establishing communication with one 235 another. 237 FE Model - A model that describes the logical processing functions of 238 an FE. 240 FE Manager (FEM) - A logical entity responsible for generic FE 241 management tasks. It is used during pre-association phase to 242 determine with which CE(s) an FE should communicate. This process is 243 called CE discovery and may involve the FE manager learning the 244 capabilities of available CEs. An FE manager may use anything from a 245 static configuration to a pre-association phase protocol (see below) 246 to determine which CE(s) to use. Being a logical entity, an FE 247 manager might be physically combined with any of the other logical 248 entities such as FEs. 250 CE Manager (CEM) - A logical entity responsible for generic CE 251 management tasks. It is particularly used during the pre-association 252 phase to determine with which FE(s) a CE should communicate. This 253 process is called FE discovery and may involve the CE manager 254 learning the capabilities of available FEs. 256 ForCES Network Element (NE) - An entity composed of one or more CEs 257 and one or more FEs. To entities outside a NE, the NE represents a 258 single point of management. Similarly, a NE usually hides its 259 internal organization from external entities. 261 High Touch Capability - This term will be used to apply to the 262 capabilities found in some forwarders to take action on the contents 263 or headers of a packet based on content other than what is found in 264 the IP header. Examples of these capabilities include NAT-PT, 265 firewall, and L7 content recognition. 267 Datapath -- A conceptual path taken by packets within the forwarding 268 plane inside an FE. 270 LFB (Logical Function Block) -- The basic building block that is 271 operated on by the ForCES protocol. The LFB is a well defined, 272 logically separable functional block that resides in an FE and is 273 controlled by the CE via ForCES protocol. The LFB may reside at the 274 FE's datapath and process packets or may be purely an FE control or 275 configuration entity that is operated on by the CE. Note that the 276 LFB is a functionally accurate abstraction of the FE's processing 277 capabilities, but not a hardware-accurate representation of the FE 278 implementation. 280 LFB (Logical Function Block) and LFB Instance -- LFBs are categorized 281 by LFB Classes(or Types). An LFB Instance represents an LFB Class 282 (or Type) existence. There may be multiple instances of the same LFB 283 Class (or Type) in an FE. An LFB Class is represented by an LFB 284 Class ID, and an LFB Instance is represented by an LFB Instance ID. 285 As a result, an LFB Class ID associated with an LFB Instance ID 286 uniquely specify an LFB existence. 288 LFB Metadata -- Metadata is used to communicate per-packet state from 289 one LFB to another, but is not sent across the network. The FE model 290 defines how such metadata is identified, produced and consumed by the 291 LFBs. It defines the functionality but not how metadata is encoded 292 within an implementation. 294 LFB Attribute -- Operational parameters of the LFBs that must be 295 visible to the CEs are conceptualized in the FE model as the LFB 296 attributes. The LFB attributes include, for example, flags, single 297 parameter arguments, complex arguments, and tables that the CE can 298 read or/and write via the ForCES protocol (see below). 300 LFB Topology -- Representation of how the LFB instances are logically 301 interconnected and placed along the datapath within one FE. 303 Sometimes it is also called intra-FE topology, to be distinguished 304 from inter-FE topology. 306 FE Topology -- A representation of how the multiple FEs within a 307 single NE are interconnected. Sometimes this is called inter-FE 308 topology, to be distinguished from intra-FE topology (i.e., LFB 309 topology). 311 Inter-FE Topology -- See FE Topology. 313 Intra-FE Topology -- See LFB Topology. 315 ForCES Protocol - While there may be multiple protocols used within 316 the overall ForCES architecture, the term "ForCES protocol" and 317 "protocol" refer to the Fp reference point in the ForCES Framework in 318 [RFC3746]. This protocol does not apply to CE-to-CE communication, 319 FE-to-FE communication, or to communication between FE and CE 320 managers. Basically, the ForCES protocol works in a master-slave 321 mode in which FEs are slaves and CEs are masters. This document 322 defines the specifications for this ForCES protocol. 324 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 325 architecture that defines the ForCES protocol messages, the protocol 326 state transfer scheme, as well as the ForCES protocol architecture 327 itself (including requirements of ForCES TML (see below)). 328 Specifications of ForCES PL are defined by this document. 330 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 331 ForCES protocol architecture that uses the capabilities of existing 332 transport protocols to specifically address protocol message 333 transportation issues, such as how the protocol messages are mapped 334 to different transport media (like TCP, IP, ATM, Ethernet, etc), and 335 how to achieve and implement reliability, multicast, ordering, etc. 336 The ForCES TML specifications are detailed in separate ForCES 337 documents, one for each TML. 339 4. Overview 341 The reader is referred to the Framework document [RFC3746], and in 342 particular sections 3 and 4, for an architectural overview and an 343 explanation of how the ForCES protocol fits in. There may be some 344 content overlap between the framework document and this section in 345 order to provide clarity. 347 4.1. Protocol Framework 349 Figure 1 below is reproduced from the Framework document for clarity. 350 It shows a NE with two CEs and two FEs. 352 --------------------------------------- 353 | ForCES Network Element | 354 -------------- Fc | -------------- -------------- | 355 | CE Manager |---------+-| CE 1 |------| CE 2 | | 356 -------------- | | | Fr | | | 357 | | -------------- -------------- | 358 | Fl | | | Fp / | 359 | | Fp| |----------| / | 360 | | | |/ | 361 | | | | | 362 | | | Fp /|----| | 363 | | | /--------/ | | 364 -------------- Ff | -------------- -------------- | 365 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 366 -------------- | | |------| | | 367 | -------------- -------------- | 368 | | | | | | | | | | 369 ----+--+--+--+----------+--+--+--+----- 370 | | | | | | | | 371 | | | | | | | | 372 Fi/f Fi/f 374 Fp: CE-FE interface 375 Fi: FE-FE interface 376 Fr: CE-CE interface 377 Fc: Interface between the CE Manager and a CE 378 Ff: Interface between the FE Manager and an FE 379 Fl: Interface between the CE Manager and the FE Manager 380 Fi/f: FE external interface 382 Figure 1: ForCES Architectural Diagram 384 The ForCES protocol domain is found in the Fp Reference Point. The 385 Protocol Element configuration reference points, Fc and Ff also play 386 a role in the booting up of the ForCES Protocol. The protocol 387 element configuration (indicated by reference points Fc, Ff, and Fl) 388 is out of scope of the ForCES protocol but is touched on in this 389 document in discussion of FEM and CEM since it is an integral part of 390 the protocol pre-association phase. 392 Figure 2 below shows further breakdown of the Fp interface by example 393 of an MPLS QoS enabled Network Element. 395 ------------------------------------------------- 396 | | | | | | | 397 |OSPF |RIP |BGP |RSVP |LDP |. . . | 398 | | | | | | | 399 ------------------------------------------------- CE 400 | ForCES Interface | 401 ------------------------------------------------- 402 ^ ^ 403 | | 404 ForCES | |data 405 control | |packets 406 messages| |(e.g., routing packets) 407 | | 408 v v 409 ------------------------------------------------- 410 | ForCES Interface | 411 ------------------------------------------------- FE 412 | | | | | | | 413 |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | 414 | | | | |fier | | 415 ------------------------------------------------- 417 Figure 2: Examples of CE and FE functions 419 The ForCES Interface shown in Figure 2 constitutes two pieces: the PL 420 layer and the TML layer. 422 This is depicted in Figure 3 below. 424 +------------------------------------------------ 425 | CE PL layer | 426 +------------------------------------------------ 427 | CE TML layer | 428 +------------------------------------------------ 429 ^ 430 | 431 ForCES | (i.e ForCES data + control 432 PL | packets ) 433 messages | 434 over | 435 specific | 436 TML | 437 encaps | 438 and | 439 transport | 440 | 441 v 442 +------------------------------------------------ 443 | FE TML layer | 444 +------------------------------------------------ 445 | FE PL layer | 446 +------------------------------------------------ 448 Figure 3: ForCES Interface 450 The PL layer is in fact the ForCES protocol. Its semantics and 451 message layout are defined in this document. The TML Layer is 452 necessary to connect two ForCES PL layers as shown in Figure 3 above. 453 The TML is out of scope for this document but is within scope of 454 ForCES. This document defines requirements the PL needs the TML to 455 meet. 457 Both the PL and the TML layers are standardized by the IETF. While 458 only one PL layer is defined, different TMLs are expected to be 459 standardized. To interoperate the TML layer at the CE and FE are 460 expected to conform to the same definition. 462 On transmit, the PL layer delivers its messages to the TML layer. 463 The TML layer delivers the message to the destination TML layer(s). 464 On receive, the TML delivers the message to its destination PL 465 layer(s). 467 4.1.1. The PL layer 469 The PL is common to all implementations of ForCES and is standardized 470 by the IETF as defined in this document. The PL layer is responsible 471 for associating an FE or CE to an NE. It is also responsible for 472 tearing down such associations. An FE uses the PL layer to transmit 473 various subscribed-to events to the CE PL layer as well as to respond 474 to various status requests issued from the CE PL. The CE configures 475 both the FE and associated LFBs' operational parameters using the PL 476 layer. In addition the CE may send various requests to the FE to 477 activate or deactivate it, reconfigure its HA parameterization, 478 subscribe to specific events etc. More details can be found in 479 Section 7. 481 4.1.2. The TML layer 483 The TML layer transports the PL layer messages. The TML is where the 484 issues of how to achieve transport level reliability, congestion 485 control, multicast, ordering, etc. are handled. It is expected more 486 than one TML will be standardized. The various possible TMLs could 487 vary their implementations based on the capabilities of underlying 488 media and transport. However, since each TML is standardized, 489 interoperability is guaranteed as long as both endpoints support the 490 same TML. All ForCES Protocol Layer implementations MUST be portable 491 across all TMLs, because all TMLs MUST have the top edge semantics 492 defined in this document. 494 4.1.3. The FEM/CEM Interface 496 The FEM and CEM components, although valuable in the setup and 497 configurations of both the PL and TML layers, are out of scope of the 498 ForCES protocol. The best way to think of them are as 499 configurations/parameterizations for the PL and TML before they 500 become active (or even at runtime based on implementation). In the 501 simplest case, the FE or CE read a static configuration file. RFC 502 3746 has a more detailed descriptions on how the FEM and CEM could be 503 used. The pre-association phase, where the CEM and FEM can be used, 504 are described briefly in Section 4.2.1. 506 An example of typical of things the FEM/CEM could configure would be 507 TML specific parameterizations such as: 509 a. how the TML connection should happen (for example what IP 510 addresses to use, transport modes etc); 512 b. Issuing the ID for the FE or CE would also be issued during the 513 pre-association phase. 515 c. Security parameterization such as keys etc. 517 d. Connection association parameters 519 Example of this might be: 521 o simple parameters: send up to 3 association messages every 1 522 second 524 o or more complex parameters: send up to 4 association messages with 525 increasing exponential timeout 527 4.2. ForCES Protocol Phases 529 ForCES, in relation to NEs, involves two phases: the Pre-Association 530 phase where configuration/initialization/bootup of the TML and PL 531 layer happens, and the association phase where the ForCES protocol 532 operates to manipulate the parameters of the FEs. 534 FE start CE configures 535 -------+ +--->---->---->---->------->----+ 536 | | Y 537 Y | | 538 | | Y 539 +------+--+ +--------+ 540 | FE | | FE | 541 | DOWN | | UP | 542 | State | | State | 543 | | | | 544 +---------+ +--------+ 545 ^ Y 546 | | 547 +-<---<------<-----<------<----<---+ 548 CE configures or FE loses association 550 Figure 4: The FE State Machine 552 The FE can only be in one of two states as indicated above. When the 553 FE is in the DOWN state, it is not forwarding packets. When the FE 554 is in the UP state it may be forwarding packets depending on the 555 configuration of its specific LFBs. 557 CE configures FE states transitions by means of a so-called FEObject 558 LFB, which is defined in [FE-MODEL] and also explained in Section 559 4.3.3 of this document. In FEObject LFB, FE state is defined as an 560 attribute of the LFB, and CE configuration of the FE state equals CE 561 configuration of this attribute. Note that even in the FE DOWN 562 state, the FEObject LFB itself is active. 564 On start up the FE is in the DOWN state unless it is explicitly 565 configured by the CE to transition to the UP state via an FE Object 566 admin action. This must be done before configuring any other LFBs 567 that affect packet forwarding. 569 The FE transitions from the UP state to the DOWN state when it 570 receives a FEObject Admin Down action or when it loses its 571 association with the CE. For the FE to properly complete the 572 transition to the DOWN state, it MUST stop Packet forwarding and this 573 may impact multiple LFBS. How this is achieved is outside the scope 574 of this specification. 576 Note: in the case of loss of association, the FE can also be 577 configured to not go to the DOWN state. 579 For the FE to properly complete the transition to the DOWN state it 580 must stop packet forwarding and that this may affect multiple LFBs. 581 How this is achieved is outside the scope of this specification. 583 4.2.1. Pre-association 585 The ForCES interface is configured during the pre-association phase. 586 In a simple setup, the configuration is static and is read from a 587 saved configuration file. All the parameters for the association 588 phase are well known after the pre-association phase is complete. A 589 protocol such as DHCP may be used to retrieve the configuration 590 parameters instead of reading them from a static configuration file. 591 Note, this will still be considered static pre-association. Dynamic 592 configuration may also happen using the Fc, Ff and Fl reference 593 points. Vendors may use their own proprietary service discovery 594 protocol to pass the parameters. Essentially only guidelines are 595 provided here and the details are left to the implementation. 597 The following are scenarios reproduced from the Framework Document to 598 show a pre-association example. 600 <----Ff ref pt---> <--Fc ref pt-------> 601 FE Manager FE CE Manager CE 602 | | | | 603 | | | | 604 (security exchange) (security exchange) 605 1|<------------>| authentication 1|<----------->|authentication 606 | | | | 607 (FE ID, attributes) (CE ID, attributes) 608 2|<-------------| request 2|<------------|request 609 | | | | 610 3|------------->| response 3|------------>|response 611 (corresponding CE ID) (corresponding FE ID) 612 | | | | 613 | | | | 615 Figure 5: Examples of a message exchange over the Ff and Fc reference 616 points 618 <-----------Fl ref pt--------------> | 620 FE Manager FE CE Manager CE 621 | | | | 622 | | | | 623 (security exchange) | | 624 1|<------------------------------>| | 625 | | | | 626 (a list of CEs and their attributes) | 627 2|<-------------------------------| | 628 | | | | 629 (a list of FEs and their attributes) | 630 3|------------------------------->| | 631 | | | | 632 | | | | 634 Figure 6: An example of a message exchange over the Fl reference 635 point 637 Before the transition to the association phase, the FEM will have 638 established contact with a CEM component. Initialization of the 639 ForCES interface will have completed, and authentication as well as 640 capability discovery may be complete. Both the FE and CE would have 641 the necessary information for connecting to each other for 642 configuration, accounting, identification and authentication 643 purposes. To summarize, at the completion of this stage both sides 644 have all the necessary protocol parameters such as timers, etc. The 645 Fl reference point may continue to operate during the association 646 phase and may be used to force a disassociation of an FE or CE. 647 Because the pre-association phase is out of scope, these details are 648 not discussed any further in this specification. The reader is 649 referred to the framework document [RFC3746] for a slightly more 650 detailed discussion. 652 4.2.2. Post-association 654 In this phase, the FE and CE components communicate with each other 655 using the ForCES protocol (PL over TML) as defined in this document. 656 There are three sub-phases: 658 o Association Setup stage 660 o Established Stage 662 o Association Lost stage 664 4.2.2.1. Association Setup stage 666 The FE attempts to join the NE. The FE may be rejected or accepted. 667 Once granted access into the NE, capabilities exchange happens with 668 the CE querying the FE. Once the CE has the FE capability 669 information, the CE can offer an initial configuration (possibly to 670 restore state) and can query certain attributes within either an LFB 671 or the FE itself. 673 More details are provided in Section 8. 675 On successful completion of this stage, the FE joins the NE and is 676 moved to the Established State. 678 4.2.2.2. Association Established stage 680 In this stage the FE is continuously updated or queried. The FE may 681 also send asynchronous event notifications to the CE or synchronous 682 heartbeat notifications if programmed to do so. This continues until 683 a termination occurs because of loss of connectivity or is initiated 684 by either the CE or the FE. 686 Refer to section on protocol scenarios, Section 8, for more details. 688 4.2.2.3. Association Lost stage 690 In this state, both or either the CE or FE declare the other side is 691 no longer associated. The disconnection could be physically 692 initiated by either party for administrative purposes but may also be 693 driven by operational reasons such as loss of connectivity. 695 It should be noted that loss of connectivity between TMLs is not 696 necessarily indicative of loss of association between respective PL 697 layers unless the programmed FE Protocol Object time limit is 698 exceeded. In other words if the TML repairs the transport loss 699 before then, the association would still be valid. 701 When an association is lost between a CE and FE, the FE continues to 702 operate as instructed by the CE via the CE failover policy (for 703 further discussion refer to Section 9 and Appendix B). 705 For this version of the protocol (as defined in this document), the 706 FE, upon re-association, MUST discard any state it has as invalid and 707 retrieve new state. This approach is motivated by a desire for 708 simplicity (as opposed to efficiency). 710 4.3. Protocol Mechanisms 712 Various semantics are exposed to the protocol users via the PL header 713 including: transaction capabilities, atomicity of transactions, two 714 phase commits, batching/parallelization, high availability and 715 failover as well as command windows. 717 The EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP 718 (Transaction Phase) flag as defined in Common Header Section (Section 719 6.1) are relevant to these mechanisms. 721 4.3.1. Transactions, Atomicity, Execution and Responses 723 In the master-slave relationship the CE instructs one or more FEs on 724 how to execute operations and how to report the results. 726 This section details the different modes of execution that a CE can 727 order the FE(s) to perform as defined in Section 4.3.1.1. It also 728 describes the different modes a CE can ask the FE(s) to use for 729 formatting the responses after processing the operations as 730 requested. These modes relate to the transactional two phase 731 commitment operations. 733 4.3.1.1. Execution 735 There are 3 execution modes that can be requested for a batch of 736 operations spanning one or more LFB selectors in one protocol 737 message. The EM flag defined in Common Header Section (Section 6.1) 738 selects the execution mode for a protocol message, as below: 740 a. execute-all-or-none 742 b. execute-until-failure 744 c. continue-execute-on-failure 746 4.3.1.1.1. execute-all-or-none 748 When set to this mode, independent operations in a message targeted 749 at one or more LFB selectors will all be executed if no failure 750 occurs for any of the operations. If there is any failure for any of 751 the operations then none of the operations will be executed, i.e 752 there is roll back for this mode of operation. 754 4.3.1.1.2. continue-execute-on-failure 756 If several independent operations are targeted at one or more LFB 757 selectors, execution continues for all operations at the FE even if 758 one or more operations fail. 760 4.3.1.1.3. execute-until-failure 762 In this mode all operations are executed on the FE sequentially until 763 the first failure. The rest of the operations are not executed but 764 operations already completed are not undone, i.e. there is no roll 765 back in this mode of operation. 767 4.3.1.2. Transaction and Atomicity 769 4.3.1.2.1. Transaction Definition 771 A transaction is defined as a collection of one or more ForCES 772 operations within one or more PL messages that MUST meet the ACIDity 773 properties[ACID], defined as: 775 Atomicity: In a transaction involving two or more discrete pieces 776 of information, either all of the pieces are committed 777 or none are. 779 Consistency: A transaction either creates a new and valid state of 780 data, or, if any failure occurs, returns all data to the 781 state it was in before the transaction was started. 783 Isolation: A transaction in process and not yet committed must 784 remain isolated from any other transaction. 786 Committed data is saved by the system such that, even in 787 the event of a failure and a system restart, the data is 788 available in its correct state. 790 There are cases where the CE knows exact memory and implementation 791 details of the FE such as in the case of an FE-CE pair from the same 792 vendor where the FE-CE pair is tightly coupled. In such a case, the 793 transactional operations may be simplified further by extra 794 computation at the CE. This view is not discussed further other than 795 to mention that it is not disallowed. 797 As defined above, a transaction is always atomic and MAY be 799 a. Within an FE alone 800 Example: updating multiple tables that are dependent on each 801 other. If updating one fails, then any that were already updated 802 must be undone. 804 b. Distributed across the NE 805 Example: updating table(s) that are inter-dependent across 806 several FEs (such as L3 forwarding related tables). 808 4.3.1.2.2. Transaction protocol 810 By use of the execute mode as defined in Section 4.3.1.1, the 811 protocol has provided a mechanism for transactional operations within 812 one stand-alone message. The 'execute-all-or-none' mode can meet the 813 ACID requirements. 815 For transactional operations of multiple messages within one FE or 816 across FEs, a classical transactional protocol known as Two Phase 817 Commit (2PC) [2PCREF] is supported by the protocol to achieve the 818 transactional operations. 820 The AT flag and the TP flag in Common Header (Section 6.1) are 821 provided for 2PC based transactional operations spanning multiple 822 messages. 824 The AT flag, when set, indicates this message belongs to an Atomic 825 Transaction. All messages for a transaction operation must have the 826 AT flag set. If not set, it means the message is a stand-alone 827 message and does not participate in any transaction operation that 828 spans multiple messages. 830 The TP flag indicates the Transaction Phase this message belongs to. 831 There are four (4) possible phases for an transactional operation 832 known as: 834 SOT (Start of Transaction) 836 MOT (Middle of Transaction) 838 EOT (End of Transaction) 840 ABT (Abort) 842 A transaction operation is started with a message the TP flag is set 843 to Start of Transaction (SOT). Multi-part messages, after the first 844 one, are indicated by the Middle of Transaction flag (MOT). The last 845 message is indicated by by EOT. 847 Any failure notified by the FE causes the CE to execute an Abort 848 Transaction (ABT) to all FEs involved in the transaction, rolling 849 back all previously executed operations in the transaction. 851 The transaction commitment phase is signaled from the CE to the FE 852 by an End of Transaction (EOT) configuration message. The FE MUST 853 respond to the CE's EOT message. If no response is received from 854 the FE within a specified timeout, the transaction MUST be aborted 855 by the CE. 857 Note that a transactional operation is generically atomic, therefore 858 it requires that the execute modes of all messages in a transaction 859 operation should always be kept the same and be set to 'execute-all- 860 or-none'. If the EM flag is set to other execute modes, it will 861 result in a transaction failure. 863 As noted above, a transaction may span multiple messages. It is up 864 to the CE to keep track of the different outstanding messages making 865 up a transaction. As an example, the correlator field could be used 866 to mark transactions and a sequence field to label the different 867 messages within the same atomic transaction, but this is out of scope 868 and up to implementations. 870 4.3.1.2.3. Recovery 872 Any of the participating FEs, or the CE, or the associations between 873 them, may fail after the EOT response message has been sent by the FE 874 but before it has received all the responses, e.g. if the EOT 875 response never reaches the CE. 877 In this protocol revision, for sake of simplicity as indicated in 878 Section 4.2.2.3, an FE losing an association would be required to get 879 entirely new state from the newly associated CE upon a re- 880 association. The decision on what an FE should do after a lost 881 association is dictated by the CE Failover policy (refer to Section 9 882 and Section 7.2). 884 4.3.2. Scalability 886 It is desirable that the PL layer not become the bottleneck when 887 larger bandwidth pipes become available. To pick a hypothetical 888 example in today's terms, if a 100Gbps pipe is available and there is 889 sufficient work then the PL layer should be able to take advantage of 890 this and use all of the 100Gbps pipe. Two mechanisms have been 891 provided to achieve this. The first one is batching and the second 892 one is a command window. 894 Batching is the ability to send multiple commands (such as Config) in 895 one Protocol Data Unit (PDU). The size of the batch will be affected 896 by, amongst other things, the path MTU. The commands may be part of 897 the same transaction or may be part of unrelated transactions that 898 are independent of each other. 900 Command windowing allows for pipelining of independent transactions 901 which do not affect each other. Each independent transaction could 902 consist of one or more batches. 904 4.3.2.1. Batching 906 There are several batching levels at different protocol hierarchies. 908 o multiple PL PDUs can be aggregated under one TML message 910 o multiple LFB classes and instances (as indicated in the LFB 911 selector) can be addressed within one PL PDU 913 o Multiple operations can be addressed to a single LFB class and 914 instance 916 4.3.2.2. Command Pipelining 918 The protocol allows any number of messages to be issued by the CE 919 before the corresponding acknowledgments (if requested) have been 920 returned by the FE. Hence pipelining is inherently supported by the 921 protocol. Matching responses with requests messages can be done 922 using the correlator field in the message header. 924 4.3.3. Heartbeat Mechanism 926 Heartbeats (HB) between FEs and CEs are traffic sensitive. An HB is 927 sent only if no PL traffic is sent between the CE and FE within a 928 configured interval. This has the effect of reducing the amount of 929 HB traffic in the case of busy PL periods. 931 An HB can be sourced by either the CE or FE. When sourced by the CE, 932 a response can be requested (similar to the ICMP ping protocol). The 933 FE can only generate HBs in the case of being configured to do so by 934 the CE. Refer to Section 7.2.1 and Section 7.9 for details. 936 4.3.4. FE Object and FE protocol LFBs 938 All PL messages operate on LFB constructs as this provides more 939 flexibility for future enhancements. This means that maintenance and 940 configurability of FEs, NE, as well as the ForCES protocol itself 941 must be expressed in terms of this LFB architecture. For this reason 942 special LFBs are created to accommodate this need. 944 In addition, this shows how the ForCES protocol itself can be 945 controlled by the very same type of structures (LFBs) it uses to 946 control functions such as IP forwarding, filtering, etc. 948 To achieve this, the following specialized LFBs are introduced: 950 o FE Protocol LFB which is used to control the ForCES protocol. 952 o FE Object LFB which is used to controls attributes relative to the 953 FE itself. Such attributes include FEState [FE-MODEL], vendor, 954 etc. 956 These LFBs are detailed in Section 7.2. 958 5. TML Requirements 960 The requirements below are expected to be delivered by the TML. This 961 text does not define how such mechanisms are delivered. As an 962 example they could be defined to be delivered via hardware or between 963 2 or more TML processes on different CEs or FEs in protocol level 964 schemes. 966 Each TML must describe how it contributes to achieving the listed 967 ForCES requirements. If for any reason a TML does not provide a 968 service listed below a justification needs to be provided. 970 1. Reliability 971 As defined by RFC 3654, section 6 #6. 973 2. Security 974 TML provides security services to the ForCES PL. TML layer 975 should support the following security services and describe how 976 they are achieved. 978 * Endpoint authentication of FE and CE. 980 * Message Authentication 982 * Confidentiality service 984 3. Congestion Control 985 The congestion control scheme used needs to be defined. The 986 congestion control mechanism defined by the TML should prevent 987 the FE from being overloaded by the CE or the CE from being 988 overwhelmed by traffic from the FE. Additionally, the 989 circumstances under which notification is sent to the PL to 990 notify it of congestion must be defined. 992 4. Uni/multi/broadcast addressing/delivery if any 993 If there is any mapping between PL and TML level Uni/Multi/ 994 Broadcast addressing it needs to be defined. 996 5. HA decisions 997 It is expected that availability of transport links is the TML's 998 responsibility. However, on config basis, the PL layer may wish 999 to participate in link failover schemes and therefore the TML 1000 must support this capability. 1001 Please refer to Section 9 for details. 1003 6. Encapsulations used. 1004 Different types of TMLs will encapsulate the PL messages on 1005 different types of headers. The TML needs to specify the 1006 encapsulation used. 1008 7. Prioritization 1009 It is expected that the TML will be able to handle up to 8 1010 priority levels needed by the PL layer and will provide 1011 preferential treatment. 1012 While the TML needs to define how this is achieved, it should be 1013 noted that the requirement for supporting up to 8 priority levels 1014 does not mean that the underlying TML MUST be capable of 1015 providing up to 8 actual priority levels. In the event that the 1016 underlying TML layer does not have support for 8 priority levels, 1017 the supported priority levels should be divided between the 1018 available TML priority levels. For example, if the TML only 1019 supports 2 priority levels, the 0-3 could go in one TML priority 1020 level, while 4-7 could go in the other. 1022 8. Protection against DoS attacks 1023 As described in the Requirements RFC 3654, section 6 1025 5.1. TML Parameterization 1027 It is expected that it should be possible to use a configuration 1028 reference point, such as the FEM or the CEM, to configure the TML. 1030 Some of the configured parameters may include: 1032 o PL ID 1034 o Connection Type and associated data. For example if a TML uses 1035 IP/TCP/UDP then parameters such as TCP and UDP ports, IP addresses 1036 need to be configured. 1038 o Number of transport connections 1040 o Connection Capability, such as bandwidth, etc. 1042 o Allowed/Supported Connection QoS policy (or Congestion Control 1043 Policy) 1045 6. Message encapsulation 1047 All PL layer PDUs start with a common header [Section 6.1] followed 1048 by a one or more TLVs [Section 6.2] which may nest other TLVs 1049 [Section 6.2.1]. All fields are in network byte order. 1051 6.1. Common Header 1053 0 1 2 3 1054 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 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 |version| rsvd | Message Type | Length | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Source ID | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Destination ID | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Correlator | 1063 | | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Flags | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 Figure 7: Common Header 1070 The message is 32 bit aligned. 1072 Version (4 bit): 1073 Version number. Current version is 1. 1075 rsvd (4 bit): 1076 Unused at this point. A receiver should not interpret this 1077 field. Senders MUST set it to zero and receivers MUST ignore 1078 this field. 1080 Message Type (8 bits): 1081 Commands are defined in Section 7. 1083 Length (16 bits): 1084 length of header + the rest of the message in DWORDS (4 byte 1085 increments). 1087 Source ID (32 bit): 1089 Dest ID (32 bit): 1091 * Each of the source and Dest IDs are 32 bit IDs which are 1092 unique NE-wide and which recognize the termination points of 1093 a ForCES PL message. 1095 * IDs allow multi/broad/unicast addressing with the following 1096 approach: 1098 a. A split address space is used to distinguish FEs from 1099 CEs. Even though in a large NE there are typically two 1100 or more orders of magnitude more FEs than CEs, the 1101 address space is split uniformly for simplicity. 1103 b. The address space allows up to 2^30 (over a billion) CEs 1104 and the same amount of FEs. 1106 0 1 2 3 1107 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 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 |TS | sub-ID | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 Figure 8: ForCES ID Format 1114 c. The 2 most significant bits called Type Switch (TS) are 1115 used to split the ID space as follows: 1117 TS Corresponding ID range Assignment 1118 -- ---------------------- ---------- 1119 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 1120 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 1121 0b10 0x80000000 to 0xBFFFFFFF reserved 1122 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16) 1123 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 1124 0b11 0xFFFFFFFD all CEs broadcast 1125 0b11 0xFFFFFFFE all FEs broadcast 1126 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast 1128 Figure 9: Type Switch ID Space 1130 * Multicast or broadcast IDs are used to group endpoints (such 1131 as CEs and FES). As an example one could group FEs in some 1132 functional group, by assigning a multicast ID. Likewise, 1133 subgroups of CEs that act, for instance, in a back-up mode 1134 may be assigned a multicast ID to hide them from the FE. 1136 * This document does not discuss how a particular multicast ID 1137 is associated to a given group though it could be done via 1138 configuration process. The list of IDs an FE owns or is part 1139 of are listed on the FE Object LFB. 1141 Correlator (64 bits) 1142 This field is set by the CE to correlate ForCES Request Messages 1143 with the corresponding Response messages from the FE. 1144 Essentially it is a cookie. The Correlator is handled 1145 transparently by the FE, i.e. for a particular Request message 1146 the FE MUST assign the same correlator value in the corresponding 1147 Response message. In the case where the message from the CE does 1148 not elicit a response, this field may not be useful. 1150 The Correlator field could be used in many implementations 1151 specific ways by the CE. For example, the CE could split the 1152 Correlator into a 32-bit transactional identifier and 32-bit 1153 message sequence identifier. Another example a 64 bit pointer to 1154 a context block. All such implementation specific use of the 1155 Correlator is outside the scope of this specification. 1157 Flags(32 bits): 1158 Identified so far: 1160 0 1 2 3 1161 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 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | | | | | | | | 1164 |ACK| Pri |Rsr |EM |A|TP | Reserved | 1165 | | | vd. | |T| | | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 Figure 10: Header Flags 1170 - ACK: ACK indicator(2 bit) 1171 The ACK indicator flag is only used by the CE when sending a 1172 Config Message(Section 7.5.1) or a HB message (Section 7.9) 1173 to indicate to the message receiver whether or not a response 1174 is required by the sender. Note that for all other messages 1175 than the Config Message or the HB Message this flag MUST be 1176 ignored. 1178 The flag values are defined as below: 1180 'NoACK' (0b00) - to indicate that the message receiver 1181 MUST not to send any response message back to this 1182 message sender. 1184 'SuccessACK'(0b01) - to indicate the message receiver 1185 MUST send a response message back only when the message 1186 has been successfully processed by the receiver. 1188 'FailureACK'(0b10) - to indicate the message receiver 1189 MUST send a response message back only when there is was 1190 failure by the receiver in processing (executing) the 1191 message. In other words, if the message can be processed 1192 successfully, the sender will not expect any response 1193 from the receiver. 1195 'AlwaysACK' (0b11) - to indicate the message receiver 1196 MUST send a response message. 1198 Note that in above definitions, the term success implies a 1199 complete execution without any failure of the message. 1200 Anything else than a complete successful execution is defined 1201 as a failure for the message processing. As a result, for 1202 the execution modes (defined in Section 4.3.1.1) like 1203 execute-all-or-none, execute-until-failure, and continue- 1204 execute-on-failure, if any single operation among several 1205 operations in the same message fails, it will be treated as a 1206 failure and result in a response if the ACK indicator has 1207 been set to 'FailureACK' or 'AlwaysACK'. 1209 Also note that, other than in Config and HB Messages, 1210 requirements for responses of messages are all given in a 1211 default way rather than by ACK flags. The default 1212 requirements of these messages and the expected responses are 1213 summarized below. Detailed descriptions can be found in the 1214 individual message definitions: 1216 + Association Setup Message always expects a response. 1218 + Association Teardown Message, and Packet Redirect 1219 Message, never expect responses. 1221 + Query Message always expects a response. 1223 + Response messages never expect further responses. 1225 - Pri: Priority (3 bits) 1226 ForCES protocol defines 8 different levels of priority (0-7). 1227 The priority level can be used to distinguish between 1228 different protocol message types as well as between the same 1229 message type. For example, the REDIRECT PACKET message could 1230 have different priorities to distinguish between Routing 1231 protocols packets and ARP packets being redirected from FE to 1232 CE. The Normal priority level is 1. 1234 - EM: Execution mode (2 bits) 1235 There are 3 execution modes refer to Section 4.3.1.1 for 1236 details. 1238 Reserved..................... (0b00) 1240 `execute-all-or-none` ....... (0b01) 1242 `execute-until-failure` ..... (0b10) 1244 `continue-execute-on-failure` (0b11) 1246 - AT Atomic Transaction (1 bit) 1247 This flag indicates if the message is stand-alone message or 1248 one of multiple messages that belongs to 2PC transaction 1249 operations. See Section 4.3.1.2.2 for details. 1251 Stand-alone message ......... (0b0) 1253 2PC transaction message ..... (0b1) 1255 - TP: Transaction phase (2 bits) 1256 A message from the CE to the FE within a transaction could be 1257 indicative of the different phases the transaction is in. 1258 Refer to Section 4.3.1.2.2 for details. 1260 SOT (start of transaction) ..... (0b00) 1262 MOT (Middle of transaction) .... (0b01) 1264 EOT (end of transaction) ........(0b10) 1266 ABT (abort) .....................(0b11) 1268 6.2. Type Length Value(TLV) Structuring 1270 0 1 2 3 1271 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 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | TLV Type | variable TLV Length | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Value (Data of size TLV length) | 1276 ~ ~ 1277 ~ ~ 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 Figure 11: TLV Representation 1282 TLV Type (16): 1283 The TLV type field is two octets, and indicates the 1284 type of data encapsulated within the TLV. 1286 TLV Length (16): 1287 The TLV Length field is two octets, and indicates 1288 the length of this TLV including the TLV Type, TLV 1289 Length, and the TLV data in octets. 1291 TLV Value (variable): 1292 The TLV Value field carries the data. For 1293 extensibility, the TLV value may in fact be a TLV. 1294 TLVs must be 32 bit aligned. 1296 6.2.1. Nested TLVs 1298 TLV values can be other TLVs. This provides the benefits of protocol 1299 flexibility (being able to add new extensions by introducing new TLVs 1300 when needed). The nesting feature also allows for an conceptual 1301 optimization with the XML LFB definitions to binary PL representation 1302 (represented by nested TLVs). 1304 6.2.2. Scope of the T in TLV 1306 The "Type" values in the TLV are global in scope. This means that 1307 wherever TLVs occur in the PDU, a specific Type value refers to the 1308 same Type of TLV. This is a design choice that was made to ease 1309 debugging of the protocol. 1311 6.3. ILV 1313 A slight variation of the TLV known as the ILV. This sets the type 1314 ("T") to be a 32-bit local index that refers to a ForCES element ID. 1315 The Length part of the ILV is fixed at 32 bits. 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Identifier | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Length | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Value | 1323 . . 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 Figure 12: ILV Representation 1328 It should be noted that the "I" values are of local scope and are 1329 defined by the data declarations from the LFB definition. Refer to 1330 Section 7.1.1.1.8 for discussions on usage of ILVs. 1332 7. Protocol Construction 1334 7.1. Protocol Grammar 1336 The protocol construction is formally defined using a BNF-like syntax 1337 to describe the structure of the PDU layout. This is matched to a 1338 precise binary format later in the document. 1340 Since the protocol is very flexible and hierarchical in nature, it is 1341 easier at times to see the visualization layout. This is provided in 1342 Section 7.1.2 1344 7.1.1. Protocol BNF 1346 The format used is based on RFC 2234. The terminals of this grammar 1347 are flags, IDcount, IDs, KEYID, and encoded data, described after the 1348 grammar. 1350 1. A TLV will have the word "-TLV" suffix at the end of its name 1352 2. An ILV will have the word "-ILV" suffix at the end of its name 1354 3. / is used to separate alternatives 1356 4. parenthesized elements are treated as a single item 1358 5. * before an item indicates 0 or more repetitions 1360 6. 1* before an item indicates 1 or more repetitions 1362 7. [] around an item indicates that it is optional (equal to *1) 1364 The BNF of the PL level PDU is as follows: 1366 PL level PDU := MAINHDR [MAIN-TLV] 1367 MAIN-TLV := [LFBselect-TLV] / [REDIRECT-TLV] / 1368 [ASResult-TLV] / [ASTreason-TLV] 1369 LFBselect-TLV := LFBCLASSID LFBInstance OPER-TLV 1370 OPER-TLV := 1*PATH-DATA-TLV 1371 PATH-DATA-TLV := PATH [DATA] 1372 PATH := flags IDcount IDs [SELECTOR] 1373 SELECTOR := KEYINFO-TLV 1374 DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / 1375 1*PATH-DATA-TLV 1376 KEYINFO-TLV := KEYID FULLDATA-TLV 1377 SPARSEDATA-TLV := encoded data that may have optionally 1378 appearing elements 1379 FULLDATA-TLV := encoded data element which may nest 1380 further FULLDATA-TLVs 1381 RESULT-TLV := Holds result code and optional FULLDATA-TLV 1383 Figure 13: BNF of PL level PDU 1385 o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR 1386 also defines the content. As an example the content of a "config" 1387 message would be different from an "association" message. 1389 o MAIN-TLV is one of several TLVs that could follow the Mainheader. 1390 The appearance of these TLVs is message type specific. 1392 o LFBCLASSID is a 32 bit unique identifier per LFB class defined at 1393 class Definition time. 1395 o LFBInstance is a 32 bit unique instance identifier of an LFB class 1397 o OPER-TLV uses the Type field in the TLV to uniquely identify the 1398 type of operation i.e one of {SET, GET, DEL,etc.} depending on the 1399 message type. 1401 o PATH-DATA-TLV identifies the exact element targeted and may have 1402 zero or more paths associated with it. The last PATH-DATA-TLV in 1403 the case of nesting of paths via the DATA construct in the case of 1404 SET requests and GET response is terminated by encoded data or 1405 response in the form of either FULLDATA-TLV or SPARSEDATA-TLV or 1406 RESULT-TLV. 1408 o PATH provides the path to the data being referenced. 1410 * flags (16 bits) are used to further refine the operation to be 1411 applied on the Path. More on these later. 1413 * IDcount(16 bit): count of 32 bit IDs 1415 * IDs: zero or more 32bit IDs (whose count is given by IDcount) 1416 defining the main path. Depending on the flags, IDs could be 1417 field IDs only or a mix of field and dynamic IDs. Zero is used 1418 for the special case of using the entirety of the containing 1419 context as the result of the path. 1421 o SELECTOR is an optional construct that further defines the PATH. 1422 Currently, the only defined selector is the KEYINFO-TLV, used for 1423 selecting an array entry by the value of a key field. The 1424 presence of a SELECTOR is correct only when the flags also 1425 indicate its presence. A mismatch is a protocol format error. 1427 o A KEYINFO TLV contains information used in content keying. 1429 * A KeyID is used in a KEYINFO TLV. It indicates which key for 1430 the current array is being used as the content key for array 1431 entry selection. 1433 * The key's data is the data to look for in the array, in the 1434 fields identified by the key field. The information is encoded 1435 according to the rules for the contents of a FULLDATA-TLV, and 1436 represent the field or fields which make up the key identified 1437 by the KEYID. 1439 o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV or 1 1440 or more further PATH-DATA selection. FULLDATA and SPARSEDATA are 1441 only allowed on SET requests, or on responses which return content 1442 information (GET-RESPONSE for example). PATH-DATA may be included 1443 to extend the path on any request. 1445 * Note: Nested PATH-DATA TLVs are supported as an efficiency 1446 measure to permit common subexpression extraction. 1448 * FULLDATA and SPARSEDATA contain "the data" whose path has been 1449 selected by the PATH. Refer to Section 7.1.1.1 for details. 1451 o RESULT contains the indication of whether the individual SET 1452 succeeded. If there is an indication for verbose response, then 1453 SET-RESPONSE will also contain the FULLDATA TLV showing the data 1454 that was set. RESULT-TLV is included on the assumption that 1455 individual parts of a SET request can succeed or fail separately. 1457 In summary this approach has the following characteristic: 1459 o There can be one or more LFB Class + InstanceId combination 1460 targeted in a message (batch) 1462 o There can one or more operations on an addressed LFB classid+ 1463 instanceid combination (batch) 1465 o There can be one or more path targets per operation (batch) 1467 o Paths may have zero or more data values associated (flexibility 1468 and operation specific) 1470 It should be noted that the above is optimized for the case of a 1471 single classid+instance targeting. To target multiple instances 1472 within the same class, multiple LFBselect are needed. 1474 7.1.1.1. Discussion on Grammar 1476 In the case of FULLDATA encoding, data is packed in such a way that a 1477 receiver of such data with knowledge of the path can correlate what 1478 it means by inferring in the LFB definition. This is an optimization 1479 that helps reducing the amount of description for the data in the 1480 protocol. 1482 In other words: 1484 It is assumed that the type of the data can be inferred by the 1485 context in which data is used. Hence, data will not include its type 1486 information. The basis for the inference is typically the LFB class 1487 id and the path. 1489 It is expected that a substantial number of operations in ForCES will 1490 need to reference optional data within larger structures. For this 1491 reason, the SPARSEDATA encoding is introduced to make it easier to 1492 encapsulate optionally appearing data elements. 1494 7.1.1.1.1. Data Packing Rules 1496 The scheme for encoding data used in this doc adheres to the 1497 following rules: 1499 o The Value ("V" of TLV) of FULLDATA TLV will contain the data being 1500 transported. This data will be as was described in the LFB 1501 definition. 1503 o Variable sized data within a FULLDATA TLV will be encapsulated 1504 inside another FULLDATA TLV inside the V of the outer TLV. For 1505 example of such a setup refer to Appendix D and Appendix C. 1507 o In the case of FULLDATA TLVs: 1509 * When a table is referred to in the PATH (ids) of a PATH-DATA- 1510 TLV, then the FULLDATA's "V" will contain that table's row 1511 content prefixed by its 32 bit index/subscript. OTOH, when 1512 PATH flags are 00, the PATH may contain an index pointing to a 1513 row in table; in such a case, the FULLDATA's "V" will only 1514 contain the content with the index in order to avoid ambiguity. 1516 7.1.1.1.2. Path Flags 1518 The following flags are currently defined: 1520 o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present 1521 following this path information, and should be considered in 1522 evaluating the path. 1524 o FIND-EMPTY Bit: This must not be set if the F_SEL_KEY bit is set. 1525 This must only be used on a create operation. If set, this 1526 indicates that although the path identifies an array, the SET 1527 operation should be applied to the first unused element in the 1528 array. The result of the operation will not have this flag set, 1529 and will have the assigned index in the path. 1531 Example: For a given LFB class, the path 2.5 might select an 1532 array in a structure. If one wanted to set element 6 in this 1533 array, then the path 2.5.6 would define that element. However 1534 if one wanted to create an element in the first empty spot in 1535 the array, the CE would then send the TLV with the FIND-EMPTY 1536 bit set with the path set to 2.5. 1538 7.1.1.1.3. Relation of operational flags with global message flags 1540 Global flags, such as the execution mode and the atomicity indicators 1541 defined in the header, apply to all operations in a message. Global 1542 flags provide semantics that are orthogonal to those provided by the 1543 operational flags, such as the flags defined in Path Data. The scope 1544 of operational flags is restricted to the operation. 1546 7.1.1.1.4. Content Path Selection 1548 The KEYINFO TLV describes the KEY as well as associated KEY data. 1549 KEYs, used for content searches, are restricted and described in the 1550 LFB definition. 1552 7.1.1.1.5. LFB select TLV 1554 The LFB select TLV is an instance of TLV defined in Section 6.2. The 1555 definition is as below: 1557 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 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | Type = LFBselect | Length | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | LFB Class ID | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | LFB Instance ID | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 | Operation TLV | 1566 . . 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 ~ ... ~ 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Operation TLV | 1571 . . 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 Figure 14: PL PDU layout 1576 Type: 1577 The type of the TLV is "LFBselect" 1579 Length: 1580 Length of the TLV including the T and L fields, in octets. 1582 LFB Class ID: 1583 This field uniquely recognizes the LFB class/type. 1585 LFB Instance ID: 1586 This field uniquely identifies the LFB instance. 1588 Operation TLV: 1589 It describes an operation nested in the LFB select TLV. Note 1590 that usually there SHOULD be at least one Operation TLV present 1591 for an LFB select TLV, but for the Association Setup Message 1592 defined in Section 7.4.1. the Operation TLV is optional. In this 1593 case there might not be an Operation TLV followed in the LFB 1594 select TLV. 1596 7.1.1.1.6. Operation TLV 1598 The Operation TLV is an instance of TLV defined in Section 6.2. It 1599 is assumed that specific operations are identified by the Type code 1600 of the TLV. Definitions for individual Types of operation TLVs are 1601 in corresponding message description sections followed. 1603 SET and GET Requests do not have result information (they are 1604 requests). SET and GET Responses have result information. SET and 1605 GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. 1607 For a GET response, individual GETs which succeed will have FULLDATA 1608 TLVs added to the leaf paths to carry the requested data. For GET 1609 elements that fail, instead of the FULLDATA TLV there will be a 1610 RESULT TLV. 1612 For a SET response, each FULLDATA or or SPARSEDATA TLV in the 1613 original request will be replaced with a RESULT TLV in the response. 1614 If the request was for Ack-fail, then only those items which failed 1615 will appear in the response. If the request was for ack-all, then 1616 all elements of the request will appear in the response with RESULT 1617 TLVs. 1619 Note that if a SET request with a structure in a FULLDATA is issued, 1620 and some field in the structure is invalid, the FE will not attempt 1621 to indicate which field was invalid, but rather will indicate that 1622 the operation failed. Note further that if there are multiple errors 1623 in a single leaf path-data / FULLDATA, the FE can select which error 1624 it chooses to return. So if a FULLDATA for a SET of a structure 1625 attempts to write one field which is read only, and attempts to set 1626 another field to an invalid value, the FE can return whatever error 1627 it likes. 1629 A SET operation on a variable length element with a length of 0 for 1630 the item is not the same as deleting it. If the CE wishes to delete 1631 then the DEL operation should be used whether the path refers to an 1632 array element or an optional structure element. 1634 7.1.1.1.7. Result TLV 1636 The RESULT TLV is an instance of TLV defined in Section 6.2. The 1637 definition is as below: 1639 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 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | Type = RESULT | Length | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | Result Value | Reserved | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 Figure 15: Result TLV 1648 The defined Result Values are 1649 0x00 = Success 1651 0x01 = Unspecified error with header. 1653 0x02 = Header length field does not match actual packet length. 1655 0x03 = Unresolvable mismatch in versions. 1657 0x04 = Destination PID is invalid for the message receiver. 1659 0x05 = LFB Class ID is not known by receiver. 1661 0x06 = LFB Class ID is known by receiver but not currently in use. 1663 0x07 = LFB Class ID is known but the specified instance of that 1664 class does not exist. 1666 0x08 = The specified path is impossible. 1668 0x09 = The specified path is possible but the element does not exist 1669 (e.g., attempt to modify a table row that has not been created). 1671 0x0A = The specified object exists but it cannot exist for the 1672 operation to succeed (e.g., attempt to add an existing LFB 1673 instance or array subscript). 1675 0x0B = The specified object does not exist but it must exist for the 1676 operation to succeed (e.g., attempt to delete an non-existing 1677 LFB instance or array subscript). 1679 0x0C = Attempt to modify a read-only value. 1681 0x0D = Attempt to create an array with an unallowed subscript. 1683 0x0E = Attempt to set a parameter to a value outside of its 1684 allowable range. 1686 0x0D = Attempt to write contents larger than the target object space 1687 (i.e., exceeding a buffer). 1689 0x10 = Any other error with data parameters. 1691 0x11 = Message type is not acceptable. 1693 0x12 = Message flags are not acceptable for the given message type. 1695 0x13 = A TLV is not acceptable for the given message type. 1697 0x14 = Unspecified error while handling an event. 1699 0x15 = Attempt to perform a valid ForCES operation that is 1700 unsupported by the message receiver. 1702 0x16 = A memory error occurred while processing a message (no error 1703 detected in the message itself) 1705 0x17 = An unspecified error occured while processing a message (no 1706 error detected in the message itself). 1708 others = Reserved 1710 0xFF = unspecified error (for when the FE can not decide what went 1711 wrong) 1713 7.1.1.1.8. DATA TLV 1715 A FULLDATA TLV has "T"= FULLDATA, and a 16bit Length followed by the 1716 data value/contents. Likewise, a SPARSEDATA TLV has "T" = 1717 SPARSEDATA, a 16bit Length followed by the data value/contents. In 1718 the case of the SPARSEDATA each element in the Value part of the TLV 1719 will be further encapsulated in an ILV. Rules: 1721 1. Both ILVs and TLVs MUST 32 bit aligned. Any padding bits used 1722 for the alignment MUST be zero on transmission and MUST be 1723 ignored upon reception. 1725 2. FULLDATA TLV may be used at a particular path only if every 1726 element at that path level is present. This requirement holds 1727 whether the fields are fixed or variable length, mandatory or 1728 optional. 1730 * If a FULLDATA TLV is used, the encoder MUST layout data for 1731 each element in the same order in which the data was defined 1732 in the LFB specification. This ensures the decoder is 1733 guaranteed to retrieve the data. 1735 * In the case of a SPARSEDATA, it does not need to be ordered 1736 since the "I" in the ILV uniquely identifies the element. 1738 3. Inside a FULLDATA TLV 1740 * The values for atomic, fixed-length fields are given without 1741 any TLV or ILV encapsulation. 1743 * The values for atomic, variable-length fields are given inside 1744 FULLDATA TLVs. 1746 4. Inside a SPARSE TLV 1748 * the values for atomic fields may be given with ILVs (32-bit 1749 index, 32-bit length) 1751 5. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot 1752 contain a FULLDATA. This is because it is hard to disambiguate 1753 ILV since an I is 32 bit and a T is 16 bit. 1755 6. A FULLDATA can also contain a FULLDATA for variable sized 1756 elements. The decoding disambiguation is assumed from rule #3 1757 above. 1759 7.1.1.1.9. SET and GET Relationship 1761 It is expected that a GET-RESPONSE would satisfy the following: 1763 o it would have exactly the same path definitions as those sent in 1764 the GET. The only difference being a GET-RESPONSE will contain 1765 FULLDATA TLVs. 1767 o it should be possible to take the same GET-RESPONSE and convert it 1768 to a SET-REPLACE successfully by merely changing the T in the 1769 operational TLV. 1771 o There are exceptions to this rule: 1773 1. When a KEY selector is used with a path in a GET operation, 1774 that selector is not returned in the GET-RESPONSE; instead the 1775 cooked result is returned. Refer to the examples using KEYS 1776 to see this. 1778 2. When dumping a whole table in a GET, the GET-RESPONSE that 1779 merely edits the T to be SET will end up overwriting the 1780 table. 1782 7.1.2. Protocol Visualization 1784 The figure below shows a general layout of the PL PDU. A main header 1785 is followed by one or more LFB selections each of which may contain 1786 one or more operation. 1788 main hdr (Config in this case) 1789 | 1790 | 1791 +--- T = LFBselect 1792 | | 1793 | +-- LFBCLASSID 1794 | | 1795 | | 1796 | +-- LFBInstance 1797 | | 1798 | +-- T = SET-CREATE 1799 | | | 1800 | | +-- // one or more path targets 1801 | | // with their data here to be added 1802 | | 1803 | +-- T = DEL 1804 | . | 1805 | . +-- // one or more path targets to be deleted 1806 | 1807 | 1808 +--- T = LFBselect 1809 | | 1810 | +-- LFBCLASSID 1811 | | 1812 | | 1813 | +-- LFBInstance 1814 | | 1815 | + -- T= SET-REPLACE 1816 | | 1817 | | 1818 | + -- T= DEL 1819 | | 1820 | + -- T= SET-REPLACE 1821 | 1822 | 1823 +--- T = LFBselect 1824 | 1825 +-- LFBCLASSID 1826 | 1827 +-- LFBInstance 1828 . 1829 . 1830 . 1832 Figure 16: PL PDU logical layout 1833 The figure below shows an example general layout of the operation 1834 within a targeted LFB selection. The idea is to show the different 1835 nesting levels a path could take to get to the target path. 1837 T = SET-CREATE 1838 | | 1839 | +- T = Path-data 1840 | | 1841 | + -- flags 1842 | + -- IDCount 1843 | + -- IDs 1844 | | 1845 | +- T = Path-data 1846 | | 1847 | + -- flags 1848 | + -- IDCount 1849 | + -- IDs 1850 | | 1851 | +- T = Path-data 1852 | | 1853 | + -- flags 1854 | + -- IDCount 1855 | + -- IDs 1856 | + -- T = KEYINFO 1857 | | + -- KEY_ID 1858 | | + -- KEY_DATA 1859 | | 1860 | + -- T = FULLDATA 1861 | + -- data 1862 | 1863 | 1864 T = SET-REPLACE 1865 | | 1866 | +- T = Path-data 1867 | | | 1868 | | + -- flags 1869 | | + -- IDCount 1870 | | + -- IDs 1871 | | | 1872 | | + -- T = FULLDATA 1873 | | + -- data 1874 | +- T = Path-data 1875 | | 1876 | + -- flags 1877 | + -- IDCount 1878 | + -- IDs 1879 | | 1880 | + -- T = FULLDATA 1881 | + -- data 1882 T = DEL 1883 | 1884 +- T = Path-data 1885 | 1886 + -- flags 1887 + -- IDCount 1888 + -- IDs 1889 | 1890 +- T = Path-data 1891 | 1892 + -- flags 1893 + -- IDCount 1894 + -- IDs 1895 | 1896 +- T = Path-data 1897 | 1898 + -- flags 1899 + -- IDCount 1900 + -- IDs 1901 + -- T = KEYINFO 1902 | + -- KEY_ID 1903 | + -- KEY_DATA 1904 +- T = Path-data 1905 | 1906 + -- flags 1907 + -- IDCount 1908 + -- IDs 1910 Figure 17: Sample operation layout 1912 7.2. Core ForCES LFBs 1914 There are two LFBs that are used to control the operation of the 1915 ForCES protocol and to interact with FEs and CEs: 1917 o FE Protocol LFB 1919 o FE Object LFB 1921 Although these LFBs have the same form and interface as other LFBs, 1922 they are special in many respects: they have fixed well-known LFB 1923 Class and Instance IDs. They are statically defined (no dynamic 1924 instantiation allowed) and their status cannot be changed by the 1925 protocol: any operation to change the state of such LFBs (for 1926 instance, in order to disable the LFB) must result in an error. 1927 Moreover, these LFBs must exist before the first ForCES message can 1928 be sent or received. All attributes in these LFBs must have pre- 1929 defined default values. Finally, these LFBs do not have input or 1930 output ports and do not integrate into the intra-FE LFB topology. 1932 7.2.1. FE Protocol LFB 1934 The FE Protocol LFB is a logical entity in each FE that is used to 1935 control the ForCES protocol. The FE Protocol LFB Class ID is 1936 assigned the value 0x1. The FE Protocol LFB Instance ID is assigned 1937 the value 0x1. There MUST be one and only one instance of the FE 1938 Protocol LFB in an FE. The values of the attributes in the FE 1939 Protocol LFB have pre-defined default values that are specified here. 1940 Unless explicit changes are made to these values using Config 1941 messages from the CE, these default values MUST be used for correct 1942 operation of the protocol. 1944 The formal definition of the FE Protocol LFB can be found in 1945 Appendix B. 1947 The FE Protocol LFB consists of the following elements: 1949 o FE Protocol capabilities (read-only): 1951 * Supported ForCES protocol version(s) by the FE 1953 * Any TML capability description(s) 1955 o FE Protocol attributes (can be read and set): 1957 * Current version of the ForCES protocol 1959 * FE unicast ID 1961 * FE multicast ID(s) list - this is a list of multicast IDs that 1962 the FE belongs to. These IDs are configured by the CE. 1964 * CE heartbeat policy - This policy, along with the parameter 'CE 1965 Heartbeat Dead Interval (CE HDI)' as described below defines 1966 the operating parameters for the FE to check the CE liveness. 1967 The policy values with meanings are listed as below: 1969 0 (default) - This policy specifies that the CE will send a 1970 Heartbeat Message to the FE(s) whenever the CE reaches a 1971 time interval within which no other PL messages were sent 1972 from the CE to the FE(s); refer to Section 4.3.3 for 1973 details. The CE HDI attribute as described below is tied to 1974 this policy. If the FE has not received any PL messages 1975 within a CE HDI period it declares the connectivity lost. 1976 The CE independently chooses the time interval for sending 1977 the Heartbeat messages to FE(s) - care must be exercised to 1978 ensure the CE->FE HB interval is smaller than the assigned 1979 CE HDI. 1981 CE HDI SHOULD be at least 3 times as long as the HB 1982 interval. Shorter rates MAY be appropriate in 1983 implementations working across a reliable internal 1984 interface. 1986 1 - The CE will not generate any HB messages. This actually 1987 means CE does not want the FE to check the CE liveness. 1989 Others - reserved. 1991 * CE Heartbeat Dead Interval (CE HDI) - The time interval the FE 1992 uses to check the CE liveness. If FE has not received any 1993 messages from CE within this time interval, FE deduces lost 1994 connectivity which implies that the CE is dead or the 1995 association to the CE is lost. Default value 30 s. 1997 * FE heartbeat policy - This policy, along with the parameter 'FE 1998 Heartbeat Interval (FE HI)', defines the operating parameters 1999 for how the FE should behave so that the CE can deduce its 2000 liveness. The policy values and the meanings are: 2002 0(default) - The FE should not generate any Heartbeat 2003 messages. In this scenario, the CE is responsible for 2004 checking FE liveness by setting the PL header ACK flag of 2005 the message it sends to AlwaysACK. The FE responds to CE 2006 whenever CE sends such Heartbeat Request Message. Refer to 2007 Section 7.9 and Section 4.3.3 for details. 2009 1 - This policy specifies that FE must actively send a 2010 Heartbeat Message if it reaches the time interval assigned 2011 by the FE HI as long as no other messages were sent from FE 2012 to CE during that interval as described in Section 4.3.3. 2014 Others - Reserved. 2016 * FE Heartbeat Interval (FE HI) - The time interval the FE should 2017 use to send HB as long as no other messages were sent from FE 2018 to CE during that interval as described in Section 4.3.3. The 2019 default value for an FE HI is 500ms. 2021 * Primary CEID - The CEID that the FE is associated with. 2023 * Backup CEs - The list of backup CEs an FE is associated with. 2024 Refer to Section 9 for details. 2026 * FE restart policy - This specifies the behavior of the FE 2027 during an FE restart. The restart may be from an FE failure or 2028 other reasons that have made FE down and then need to restart. 2029 The values are defined as below: 2031 0(default)- just restart the FE from scratch. In this case, 2032 the FE should start from the pre-association phase. 2034 1 - restart the FE from an intermediate state. In this 2035 case, the FE decides from which state it restarts. For 2036 example, if the FE is able to retain enough information of 2037 pre-association phase after some failure, it then has the 2038 ability to start from the post-association phase in this 2039 case. 2041 Others - Reserved 2043 * CE failover policy - This specifies the behavior of the FE 2044 during a CE failure and restart time interval, or when the FE 2045 loses the CE association. It should be noted that this policy 2046 in the case of HA only takes effect after total failure to 2047 connect to a new CE. A timeout parameter, the CE Timeout 2048 Interval (CE TI) is associated with this attribute. Values of 2049 this policy are defined as below: 2051 0(default) - The FE should continue running and do what it 2052 can even without an associated CE. This basically requires 2053 that the FE support CE Graceful restart. Note that if the 2054 CE still has not been restarted or hasn't been associated 2055 back to the FE, after the CE TI has expired, the FE will go 2056 operationally down. 2058 1 - FE should go down to stop functioning immediately. 2060 2 - FE should go inactive to temporarily stop functioning. 2061 If the CE still has not been restarted after a time interval 2062 of specified by the CE TI, the FE will go down completely. 2064 Others - Reserved 2066 * CE Timeout Interval (CE TI) - The time interval associated with 2067 the CE failover policy case '0' and '2'. The default value is 2068 set to 300 seconds. Note that it is advisable to set the CE TI 2069 value much higher than the CE Heartbeat Dead Interval (CE HDI) 2070 since the effect of expiring this parameter is devastating to 2071 the operation of the FE. 2073 7.2.2. FE Object LFB 2075 The FE Object LFB is a logical entity in each FE and contains 2076 attributes relative to the FE itself, and not to the operation of the 2077 ForCES protocol. 2079 The formal definition of the FE Object LFB can be found in [FE- 2080 MODEL]. The model captures the high level properties of the FE that 2081 the CE needs to know to begin working with the FE. The class ID for 2082 this LFB Class is also assigned in [FE-MODEL]. The singular instance 2083 of this class will always exist, and will always have instance ID 1 2084 within its class. It is common, although not mandatory, for a CE to 2085 fetch much of the attribute and capability information from this LFB 2086 instance when the CE begins controlling the operation of the FE. 2088 7.3. Semantics of message Direction 2090 Recall: The PL protocol provides a master(CE)-Slave(FE) relationship. 2091 The LFBs reside at the FE and are controlled by CE. 2093 When messages go from the CE, the LFB Selector (Class and instance) 2094 refers to the destination LFB selection which resides in the FE. 2096 When messages go from the FE->CE, the LFB Selector (Class and 2097 instance) refers to the source LFB selection which resides in the FE. 2099 7.4. Association Messages 2101 The ForCES Association messages are used to establish and teardown 2102 associations between FEs and CEs. 2104 7.4.1. Association Setup Message 2106 This message is sent by the FE to the CE to setup a ForCES 2107 association between them. 2109 Message transfer direction: 2110 FE to CE 2112 Message Header: 2113 The Message Type in the header is set MessageType= 2114 'AssociationSetup'. The ACK flag in the header MUST be ignored, 2115 and the association setup message always expects to get a response 2116 from the message receiver (CE) whether the setup is successful or 2117 not. The Correlator field in the header is set, so that FE can 2118 correlate the response coming back from CE correctly. The Src ID 2119 (FE ID) may be set to O in the header which means that the FE 2120 would like the CE to assign an FE ID for the FE in the setup 2121 response message. 2123 Message body: 2124 The association setup message body optionally consists of one or 2125 more LFB select TLV as described in Section 7.1.1.1.5. The 2126 association setup message only operates toward the FE Object and 2127 FE Protocol LFBs, therefore, the LFB class ID in the LFB select 2128 TLV only points to these two kinds of LFBs. 2130 The Operation TLV in the LFB select TLV is defined as a 'REPORT' 2131 operation. More than one attribute may be announced in this 2132 message using REPORT operation to let the FE declare its 2133 configuration parameters in an unsolicited manner. These may 2134 contain attributes like the Heart Beat Interval parameter, etc. 2135 The Operation TLV for event notification is is defined below. 2137 Operation TLV for Association Setup: 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | Type = REPORT | Length | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 | PATH-DATA-TLV for REPORT | 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 Figure 18: Operation TLV 2147 Type: 2148 Only one operation type is defined for the association setup 2149 message: 2151 Type = "REPORT" --- this type of operation is for FE to 2152 report something to CE. 2154 PATH-DATA-TLV for REPORT: 2155 This is generically a PATH-DATA-TLV format that has been defined 2156 in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF 2157 definition. The PATH-DATA-TLV for REPORT operation MAY contain 2158 FULLDATA-TLV(s) but SHALL NOT contain any RESULT-TLV in the data 2159 format. The RESULT-TLV is defined in Section 7.1.1.1.7 and the 2160 FULLDATA-TLV is defined in Section 7.1.1.1.8. 2162 To better illustrate the above PDU format, a tree structure for the 2163 format is shown below: 2165 main hdr (eg type = Association setup) 2166 | 2167 | 2168 +--- T = LFBselect 2169 | | 2170 | +-- LFBCLASSID = FE object 2171 | | 2172 | | 2173 | +-- LFBInstance = 0x1 2174 | | 2175 +--- T = LFBselect 2176 | 2177 +-- LFBCLASSID = FE Protocol object 2178 | 2179 | 2180 +-- LFBInstance = 0x1 2181 | 2182 +-- Path-data to one or more attributes 2183 including suggested HB parameters 2185 Figure 19: PDU Format 2187 7.4.2. Association Setup Response Message 2189 This message is sent by the CE to the FE in response to the Setup 2190 message. It indicates to the FE whether the setup is successful or 2191 not, i.e. whether an association is established. 2193 Message transfer direction: 2194 CE to FE 2196 Message Header: 2197 The Message Type in the header is set MessageType= 2198 'AssociationSetupResponse'. The ACK flag in the header MUST be 2199 ignored, and the setup response message never expects to get any 2200 more responses from the message receiver (FE). The Correlator 2201 field in the header MUST be the same as that of the corresponding 2202 association setup message, so that the association setup message 2203 sender can correlate the response correctly. The Dst ID in the 2204 header will be set to some FE ID value assigned by the CE if the 2205 FE had requested that in the setup message (by SrcID = 0). 2207 Message body: 2208 The association setup response message body only consists of one 2209 TLV, the Association Result TLV, the format of which is as 2210 follows: 2212 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 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2214 | Type = ASRresult | Length | 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 | Association Setup Result | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 Figure 20: Message Body 2221 Type (16 bits): 2222 The type of the TLV is "ASRresult". 2224 Length (16 bits): 2225 Length of the TLV including the T and L fields, in octets. 2227 Association Setup Result (32 bits): 2228 This indicates whether the setup msg was successful or whether 2229 the FE request was rejected by the CE. the defined values are: 2231 0 = success 2233 1 = FE ID invalid 2235 2 = too many associations 2237 3 = permission denied 2239 7.4.3. Association Teardown Message 2241 This message can be sent by the FE or CE to any ForCES element to end 2242 its ForCES association with that element. 2244 Message transfer direction: 2245 CE to FE, or FE to CE (or CE to CE) 2247 Message Header: 2248 The Message Type in the header is set MessageType= 2249 "AssociationTeardown". The ACK flag MUST be ignored The 2250 correlator field in the header MUST be set to zero and MUST be 2251 ignored by the receiver. 2253 Message Body: 2254 The association teardown message body only consists of one TLV, 2255 the Association Teardown Reason TLV, the format of which is as 2256 follows: 2258 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 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 | Type = ASTreason | Length | 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 | Teardown Reason | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 Figure 21: ASTreason TLV 2267 Type (16 bits): 2268 The type of the TLV is "ASTreason". 2270 Length (16 bits): 2271 Length of the TLV including the T and L fields, in octets. 2273 Teardown Reason (32 bits): 2274 This indicates the reason why the association is being 2275 terminated. Several reason codes are defined as follows. 2277 0 - normal teardown by administrator 2279 1 - error - loss of heartbeats 2281 2 - error - out of bandwidth 2283 3 - error - out of memory 2285 4 - error - application crash 2287 255 - error - other or unspecified 2289 7.5. Configuration Messages 2291 The ForCES Configuration messages are used by CE to configure the FEs 2292 in a ForCES NE and report the results back to the CE. 2294 7.5.1. Config Message 2296 This message is sent by the CE to the FE to configure LFB attributes 2297 in the FE. This message is also used by the CE to subscribe/ 2298 unsubscribe to LFB events. 2300 As usual, a config message is composed of a common header followed by 2301 a message body that consists of one or more TLV data format. 2302 Detailed description of the message is as below. 2304 Message transfer direction: 2305 CE to FE 2307 Message Header: 2308 The Message Type in the header is set MessageType= 'Config'. The 2309 ACK flag in the header can be set to any value defined in 2310 Section 6.1, to indicate whether or not a response from FE is 2311 expected by the message ( the flag is set to 'NoACK' or 2312 'AlwaysACK'), or to indicate under which conditions a response is 2313 generated (the flag is set to 'SuccessACK' or 'FailureACK'). The 2314 default behavior for the ACK flag is set to always expect a full 2315 response from FE. This happens when the ACK flag is not set to 2316 any defined value. The correlator field in the message header 2317 MUST be set if a response is expected, so that CE can correlate 2318 the response correctly. The correlator field can be ignored if 2319 no response is expected. 2321 Message body: 2322 The config message body MUST consist of at least one LFB select 2323 TLV as described in Section 7.1.1.1.5. The Operation TLV in the 2324 LFB select TLV is defined below. 2326 Operation TLV for Config: 2328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2329 | Type | Length | 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2331 | PATH-DATA-TLV | 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 Figure 22: Operation TLV for Config 2336 Type: 2337 The operation type for config message. two types of operations 2338 for the config message are defined: 2340 Type = "SET" --- this operation is to set LFB attributes 2342 Type = "DEL" --- this operation to delete some LFB 2343 attributes 2345 PATH-DATA-TLV: 2346 This is generically a PATH-DATA-TLV format that has been defined 2347 in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF 2348 definition. The restriction on the use of PATH-DATA-TLV for SET 2349 operation is, it MUST contain either a FULLDATA or SPARSEDATA 2350 TLV(s), but MUST NOT contain any RESULT-TLV. The restriction on 2351 the use of PATH-DATA-TLV for DEL operation is it MAY contain 2352 FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain any RESULT- 2353 TLV. The RESULT-TLV is defined in Section 7.1.1.1.7 and FULLDATA 2354 and SPARSEDATA TLVs is defined in Section 7.1.1.1.8. 2356 *Note: For Event subscription, the events will be defined by the 2357 individual LFBs. 2359 To better illustrate the above PDU format, a tree structure for the 2360 format is shown below: 2362 main hdr (eg type = config) 2363 | 2364 | 2365 +--- T = LFBselect 2366 | | 2367 | +-- LFBCLASSID = target LFB class 2368 | | 2369 | | 2370 | +-- LFBInstance = target LFB instance 2371 | | 2372 | | 2373 | +-- T = operation { SET } 2374 | | | 2375 | | +-- // one or more path targets 2376 | | // associated with FULL or SPARSEDATA TLV(s) 2377 | | 2378 | +-- T = operation { DEL } 2379 | | | 2380 | | +-- // one or more path targets 2382 Figure 23: PDU Format 2384 7.5.2. Config Response Message 2386 This message is sent by the FE to the CE in response to the Config 2387 message. It indicates whether the Config was successful or not on 2388 the FE and also gives a detailed response regarding the configuration 2389 result of each attribute. 2391 Message transfer direction: 2392 FE to CE 2394 Message Header: 2395 The Message Type in the header is set MessageType= 'Config 2396 Response'. The ACK flag in the header is always ignored, and the 2397 config response message never expects to get any further response 2398 from the message receiver (CE). The Correlator field in the 2399 header MUST keep the same as that of the config message to be 2400 responded, so that the config message sender can correlate the 2401 response with the original message correctly. 2403 Message body: 2404 The config message body MUST consist of at least one LFB select 2405 TLV as described in Section 7.1.1.1.5. The Operation TLV in the 2406 LFB select TLV is defined below. 2408 Operation TLV for Config Response: 2410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2411 | Type | Length | 2412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2413 | PATH-DATA-TLV | 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 Figure 24: Operation TLV for Config Response 2418 Type: 2419 The operation type for config response message. Two types of 2420 operations for the config response message are defined: 2422 Type = "SET-RESPONSE" --- this operation is for the 2423 response of SET operation of LFB attributes 2425 Type = "DEL-RESPONSE" --- this operation is for the 2426 response of the DELETE operation of LFB attributes 2428 PATH-DATA-TLV: 2429 This is generically a PATH-DATA-TLV format that has been defined 2430 in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF 2431 definition. The restriction on the use of PATH-DATA-TLV for SET- 2432 RESPONSE operation is it MUST contain RESULT-TLV(s). The 2433 restriction on the use of PATH-DATA-TLV for DEL-RESPONSE 2434 operation is it also MUST contain RESULT-TLV(s). The RESULT-TLV 2435 is defined in Section 7.1.1.1.7. 2437 7.6. Query Messages 2439 The ForCES query messages are used by the CE to query LFBs in the FE 2440 for informations like LFB attributes, capabilities, statistics, etc. 2441 Query Messages include the Query Message and the Query Response 2442 Message. 2444 7.6.1. Query Message 2446 A query message is composed of a common header and a message body 2447 that consists of one or more TLV data format. Detailed description 2448 of the message is as below. 2450 Message transfer direction: 2451 from CE to FE. 2453 Message Header: 2454 The Message Type in the header is set to MessageType= 'Query'. 2455 The ACK flag in the header is always ignored, and a full response 2456 for a query message is always expected. The Correlator field in 2457 the header is set, so that CE can locate the response back from 2458 FE correctly. 2460 Message body: 2461 The query message body MUST consist of at least one LFB select 2462 TLV as described in Section 7.1.1.1.5. The Operation TLV in the 2463 LFB select TLV is defined below. 2465 Operation TLV for Query: 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 | Type = GET | Length | 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2470 | PATH-DATA-TLV for GET | 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 Figure 25: TLV for Query 2475 Type: 2476 The operation type for query. One operation type is defined: 2478 Type = "GET" --- this operation is to request to get LFB 2479 attributes. 2481 PATH-DATA-TLV for GET: 2482 This is generically a PATH-DATA-TLV format that has been defined 2483 in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF 2484 definition. The restriction on the use of PATH-DATA-TLV for GET 2485 operation is it MUST NOT contain any SPARSEDATA or FULLDATA TLV 2486 and RESULT-TLV in the data format. 2488 To better illustrate the above PDU format, a tree structure for the 2489 format is shown below: 2491 main hdr (type = Query) 2492 | 2493 | 2494 +--- T = LFBselect 2495 | | 2496 | +-- LFBCLASSID = target LFB class 2497 | | 2498 | | 2499 | +-- LFBInstance = target LFB instance 2500 | | 2501 | | 2502 | +-- T = operation { GET } 2503 | | | 2504 | | +-- // one or more path targets 2505 | | 2506 | +-- T = operation { GET } 2507 | | | 2508 | | +-- // one or more path targets 2509 | | 2511 Figure 26: PDU Format 2513 7.6.2. Query Response Message 2515 When receiving a query message, the receiver should process the 2516 message and come up with a query result. The receiver sends the 2517 query result back to the message sender by use of the Query Response 2518 Message. The query result can be the information being queried if 2519 the query operation is successful, or can also be error codes if the 2520 query operation fails, indicating the reasons for the failure. 2522 A query response message is also composed of a common header and a 2523 message body consists of one or more TLVs describing the query 2524 result. Detailed description of the message is as below. 2526 Message transfer direction: 2527 from FE to CE. 2529 Message Header: 2530 The Message Type in the header is set to MessageType= 2531 'QueryResponse'. The ACK flag in the header is ignored. As a 2532 response itself, the message does not expect a further response 2533 anymore. The Correlator field in the header MUST be the same as 2534 that of the associated query, so that the query message sender 2535 can keep track of the response. 2537 Message body: 2538 The query response message body MUST consist of at least one LFB 2539 select TLV as described in Section 7.1.1.1.5. The Operation TLV 2540 in the LFB select TLV is defined below. 2542 Operation TLV for Query Response: 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | Type = GET-RESPONSE | Length | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | PATH-DATA-TLV for GET-RESPONSE | 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2550 Figure 27: TLV for Query Response 2552 Type: 2553 The operation type for query response. One operation type is 2554 defined: 2556 Type = "GET-RESPONSE" --- this operation is to response to 2557 get operation of LFB attributes. 2559 PATH-DATA-TLV for GET-RESPONSE: 2560 This is generically a PATH-DATA-TLV format that has been defined 2561 in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF 2562 definition. The PATH-DATA-TLV for GET-RESPONSE operation MAY 2563 contain SPARSEDATA TLV, FULLDATA TLV and/or RESULT-TLV(s) in the 2564 data encoding. The RESULT-TLV is defined in Section 7.1.1.1.7 2565 and the SPARSEDATA and FULLDATA TLVs are defined in 2566 Section 7.1.1.1.8. 2568 7.7. Event Notification Message 2570 Event Notification Message is used by FE to asynchronously notify CE 2571 of events that happen in the FE. 2573 All events that can be generated in an FE are subscribable by CE. A 2574 config message is used by CE to subscribe/unsubscribe for an event in 2575 FE. To subscribe to an event is usually by specifying to the path of 2576 such an event as described by FE-Model and defined by LFB library. 2578 As usual, an Event Notification Message is composed of a common 2579 header and a message body that consists of one or more TLV data 2580 format. Detailed description of the message is as below. 2582 Message Transfer Direction: 2583 FE to CE 2585 Message Header: 2586 The Message Type in the message header is set to 2587 MessageType = 'EventNotification'. The ACK flag in the header 2588 MUST be ignored by the CE, and the event notification message does 2589 not expect any response from the receiver. The Correlator field 2590 in the header is also ignored because the response is not 2591 expected. 2593 Message Body: 2594 The event notification message body MUST consist of at least one 2595 LFB select TLV as described in Section 7.1.1.1.5. The Operation 2596 TLV in the LFB select TLV is defined below. 2598 Operation TLV for Event Notification: 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 | Type = REPORT | Length | 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 | PATH-DATA-TLV for REPORT | 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2606 Figure 28: TLV for Event Notification 2608 Type: 2609 Only one operation type is defined for the event notification 2610 message: 2612 Type = "REPORT" --- this type of operation is for FE to 2613 report something to CE. 2615 PATH-DATA-TLV for REPORT: 2616 This is generically a PATH-DATA-TLV format that has been defined 2617 in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF 2618 definition. The PATH-DATA-TLV for REPORT operation MAY contain 2619 FULLDATA or SPARSEDATA TLV(s) but MUST NOT contain any RESULT-TLV 2620 in the data format. 2622 To better illustrate the above PDU format, a tree structure for the 2623 format is shown below: 2625 main hdr (type = Event Notification) 2626 | 2627 | 2628 +--- T = LFBselect 2629 | | 2630 | +-- LFBCLASSID = target LFB class 2631 | | 2632 | | 2633 | +-- LFBInstance = target LFB instance 2634 | | 2635 | | 2636 | +-- T = operation { REPORT } 2637 | | | 2638 | | +-- // one or more path targets 2639 | | // associated with FULL/SPARSE DATA TLV(s) 2640 | +-- T = operation { REPORT } 2641 | | | 2642 | | +-- // one or more path targets 2643 | | // associated with FULL/SPARSE DATA TLV(s) 2645 Figure 29: PDU Format 2647 7.8. Packet Redirect Message 2649 Packet redirect message is used to transfer data packets between CE 2650 and FE. Usually these data packets are IP packets, though they may 2651 sometimes be associated with some metadata generated by other LFBs in 2652 the model. They may also occasionally be other protocol packets, 2653 which usually happens when CE and FE are jointly implementing some 2654 high-touch operations. Packets redirected from FE to CE are the data 2655 packets that come from forwarding plane, and usually are the data 2656 packets that need high-touch operations in CE,or packets for which 2657 the IP destination address is the NE. Packets redirected from CE to 2658 FE are the data packets that come from the CE and that the CE decides 2659 to put into forwarding plane, i.e. an FE. 2661 Supplying such a redirect path between CE and FE actually leads to a 2662 possibility of this path being DoS attacked. Attackers may 2663 maliciously try to send huge spurious packets that will be redirected 2664 by FE to CE, resulting in the redirect path becoming congested. 2665 ForCES protocol and the TML layer will jointly supply approaches to 2666 prevent such DoS attack. To define a specific 'Packet Redirect 2667 Message' makes TML and CE able to distinguish the redirect messages 2668 from other ForCES protocol messages. 2670 By properly configuring related LFBs in FE, a packet can also be 2671 mirrored to CE instead of purely redirected to CE, i.e., the packet 2672 is duplicated and one is redirected to CE and the other continues its 2673 way in the LFB topology. 2675 The Packet Redirect Message data format is formated as follows: 2677 Message Direction: 2678 CE to FE or FE to CE 2680 Message Header: 2681 The Message Type in the header is set to MessageType= 2682 'PacketRedirect'. The ACK flags in the header MUST be ignored, 2683 and no response is expected by this message. The correlator field 2684 is also ignored because no response is expected. 2686 Message Body: 2687 Consists of (at least) one or more than one TLV that describes 2688 packet redirection. The TLV is specifically a Redirect TLV (with 2689 the TLV Type="Redirect"). Detailed data format of a Redirect TLV 2690 for packet redirect message is as below: 2692 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 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2694 | Type = Redirect | Length | 2695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 | LFB Class ID | 2697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2698 | LFB Instance ID | 2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 | Meta Data TLV | 2701 . . 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 | Redirect Data TLV | 2704 . . 2705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2707 Figure 30: Redirect_Data TLV 2709 LFB class ID: 2710 There are only two possible LFB classes here, the 'RedirectSink' 2711 LFB or the 'RedirectSource' LFB[FE-MODEL]. If the message is from 2712 FE to CE, the LFB class should be 'RedirectSink'. If the message 2713 is from CE to FE, the LFB class should be 'RedirectSource'. 2715 Instance ID: 2716 Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. 2718 Meta Data TLV: 2719 This is a TLV that specifies meta-data associated with followed 2720 redirected data. The TLV is as follows: 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 | Type = META-DATA | Length | 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 | Meta Data ILV | 2726 . . 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2728 ~ ... ~ 2729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 | Meta Data ILV | 2731 . . 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 Figure 31: Redirected_Data TLV 2736 Meta Data ILV: 2737 This is an Identifier-Length-Value format that is used to describe 2738 one meta data. The ILV has the format as: 2740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2741 | Meta Data ID | 2742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2743 | Length | 2744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2745 | Meta Data Value | 2746 . . 2747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2749 Figure 32: Meta Data ILV 2751 Where, Meta Data ID is an identifier for the meta data, which is 2752 statically assigned by the LFB definition. This actually implies 2753 a Meta Data ID transcoding mechanism may be necessary if a 2754 metadata traverses several LFBs while these LFBs define the 2755 metadata with different Meta Data IDs. 2757 Usually there are two meta data that are necessary for CE-FE 2758 redirect operation. One is the redirected data type (e.g., IP 2759 packet, TCP packet, or UDP Packet). For an FE->CE redirect 2760 operation, redirected packet type meta data is usually a meta data 2761 specified by a Classifier LFB that filter out redirected packets 2762 from packet stream and sends the packets to Redirect Sink LFB. 2763 For an CE->FE redirect operation, the redirected packet type meta 2764 data is usually directly generated by CE. 2766 Another meta data that should be associated with redirected data 2767 is the port number in a redirect LFB. For a RedirectSink LFB, the 2768 port number meta data tells CE from which port in the lFB the 2769 redirected data come. For a RedirectSource LFB, via the meta 2770 data, CE tells FE which port in the LFB the redirected data should 2771 go out. 2773 Redirect Data TLV 2774 This is a TLV describing one packet of data to be directed via the 2775 redirect operation. The TLV format is as follows: 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 | Type = REDIRECTDATA | Length | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2780 | Redirected Data | 2781 . . 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 Figure 33: Redirect Data TLV 2786 Redirected Data: 2787 This field presents the whole packet that is to be redirected. 2788 The packet should be 32bits aligned. 2790 7.9. Heartbeat Message 2792 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 2793 to asynchronously notify one or more other ForCES elements in the 2794 same ForCES NE on its liveness. 2796 A Heartbeat Message is sent by a ForCES element periodically. The 2797 parameterization and policy definition for heartbeats for an FE is 2798 managed as attributes of the FE protocol LFB, and can be set by CE 2799 via a config message. The Heartbeat message is a little different 2800 from other protocol messages in that it is only composed of a common 2801 header, with the message body left empty. Detailed description of 2802 the message is as below. 2804 Message Transfer Direction: 2805 FE to CE, or CE to FE 2807 Message Header: 2808 The Message Type in the message header is set to MessageType = 2809 'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. 2810 The ACK flag in the header MUST be set to either 'NoACK' or 2811 'AlwaysACK' when the HB is sent. 2813 * When set to 'NoACK', the HB is not soliciting for a response. 2815 * When set to 'AlwaysACK', the HB Message sender is always 2816 expecting a response from its receiver. According the HB 2817 policies defined in Section 7.2.1, only the CE can send such 2818 a HB message to query FE liveness. For simplicity and 2819 because of the minimal nature of the HB message, the response 2820 to a HB message is another HB message, i.e. no specific HB 2821 response message is defined. Whenever an FE receives a HB 2822 message marked with 'AlwaysACK' from the CE, the FE MUST send 2823 a HB message back immediately. The HB message sent by the FE 2824 in response to the 'AlwasyACK' MUST modify the source and 2825 destination IDs so that the ID of the FE is the source ID and 2826 the CEID of the sender is the destination ID, and MUST change 2827 the ACK information to 'NoACK'. A CE MUST NOT respond to an 2828 HB message with 'AlwasyACK' set. 2830 The correlator field in the HB message header SHOULD be set 2831 accordingly when a response is expected so that a receiver can 2832 correlate the response correctly. The correlator field MAY be 2833 ignored if no response is expected. 2835 Message Body: 2836 The message body is empty for the Heartbeat Message. 2838 7.10. Operation Summary 2840 The following table summarizes the TLVs that compose messages, and 2841 the applicabiity of operation TLVs to the messages. 2843 +---------------------------+-----------+---------------------------+ 2844 | Messages | TLVs | Operations | 2845 +---------------------------+-----------+---------------------------+ 2846 | Association Setup | LFBselect | REPORT | 2847 | | | | 2848 | Association Setup | ASRresult | None | 2849 | Response | | | 2850 | | | | 2851 | Association Teardown | ASTreason | None | 2852 | | | | 2853 | Config | LFBselect | SET, DEL | 2854 | | | | 2855 | Config Response | LFBselect | SET-RESPONSE, | 2856 | | | DEL-RESPONSE | 2857 | | | | 2858 | Query | LFBselect | GET | 2859 | | | | 2860 | Query Response | LFBselect | GET-RESPONSE | 2861 | | | | 2862 | Event Notification | LFBselect | REPORT | 2863 | | | | 2864 | Packet Redirect | Redirect | None | 2865 | | | | 2866 | Heartbeat | None | None | 2867 +---------------------------+-----------+---------------------------+ 2869 The following table summarises the applicability of the FULL/SPARSE 2870 DATA TLV and the RESULT TLV to the Operation TLVs. 2872 +--------------+--------------+----------------+------------+ 2873 | Operations | FULLDATA TLV | SPARSEDATA TLV | RESULT TLV | 2874 +--------------+--------------+----------------+------------+ 2875 | SET | MAY | MAY | MUST NOT | 2876 | | | | | 2877 | SET-RESPONSE | MAY | MUST NOT | MUST | 2878 | | | | | 2879 | DEL | MAY | MAY | MUST NOT | 2880 | | | | | 2881 | DEL-RESPONSE | MAY | MUST NOT | MUST | 2882 | | | | | 2883 | GET | MUST NOT | MUST NOT | MUST NOT | 2884 | | | | | 2885 | GET-RESPONSE | MUST | MUST NOT | MAY | 2886 | | | | | 2887 | REPORT | MAY | MUST NOT | MUST NOT | 2888 +--------------+--------------+----------------+------------+ 2890 8. Protocol Scenarios 2892 8.1. Association Setup state 2894 The associations among CEs and FEs are initiated via Association 2895 setup message from the FE. If a setup request is granted by the CE, 2896 a successful setup response message is sent to the FE. If CEs and 2897 FEs are operating in an insecure environment then the security 2898 associations have to be established between them before any 2899 association messages can be exchanged. The TML will take care of 2900 establishing any security associations. 2902 This is typically followed by capability query, topology query, etc. 2903 When the FE is ready to start forwarding data traffic, it sends an FE 2904 UP Event message to the CE. When the CE is ready, it repsonds by 2905 enabling the FE by setting the FEStatus to Adminup [Refer to [FE- 2906 MODEL] for details]. This indicates to the FE to start forwarding 2907 data traffic. At this point the association establishment is 2908 complete. These sequences of messages are illustrated in the Figure 2909 below. 2911 FE PL CE PL 2913 | | 2914 | Asso Setup Req | 2915 |---------------------->| 2916 | | 2917 | Asso Setup Resp | 2918 |<----------------------| 2919 | | 2920 | LFBx Query capability | 2921 |<----------------------| 2922 | | 2923 | LFBx Query Resp | 2924 |---------------------->| 2925 | | 2926 | FEO Query (Topology) | 2927 |<----------------------| 2928 | | 2929 | FEO Query Resp | 2930 |---------------------->| 2931 | | 2932 | Config FEO Adminup | 2933 |<----------------------| 2934 | | 2935 | FEO Config-Resp | 2936 |---------------------->| 2937 | | 2938 | FEO UP Event | 2939 |---------------------->| 2940 | | 2942 Figure 34: Message exchange between CE and FE to establish an NE 2943 association 2945 On successful completion of this state, the FE joins the NE. 2947 8.2. Association Established state or Steady State 2949 In this state the FE is continously updated or queried. The FE may 2950 also send asynchronous event notifications to the CE or synchronous 2951 heartbeat messages. This continues until a termination (or 2952 deactivation) is initiated by either the CE or FE. The figure below 2953 helps illustrate this state. 2955 FE PL CE PL 2957 | | 2958 | Heart Beat | 2959 |<---------------------------->| 2960 | | 2961 | Heart Beat | 2962 |----------------------------->| 2963 | | 2964 | Config-set LFBy (Event sub.) | 2965 |<-----------------------------| 2966 | | 2967 | Config Resp LFBy | 2968 |----------------------------->| 2969 | | 2970 | Config-set LFBx Attr | 2971 |<-----------------------------| 2972 | | 2973 | Config Resp LFBx | 2974 |----------------------------->| 2975 | | 2976 |Config-Query LFBz (Stats) | 2977 |<--------------------------- -| 2978 | | 2979 | Query Resp LFBz | 2980 |----------------------------->| 2981 | | 2982 | FE Event Report | 2983 |----------------------------->| 2984 | | 2985 | Config-Del LFBx Attr | 2986 |<-----------------------------| 2987 | | 2988 | Config Resp LFBx | 2989 |----------------------------->| 2990 | | 2991 | Packet Redirect LFBx | 2992 |----------------------------->| 2993 | | 2994 | Heart Beat | 2995 |<-----------------------------| 2996 . . 2997 . . 2998 | | 3000 Figure 35: Message exchange between CE and FE during steady-state 3001 communication 3002 Note that the sequence of messages shown in the figure serve only as 3003 examples and the messages exchange sequences could be different from 3004 what is shown in the figure. Also, note that the protocol scenarios 3005 described in this section do not include all the different message 3006 exchanges which would take place during failover. That is described 3007 in the HA section 8. 3009 9. High Availability Support 3011 The ForCES protocol provides mechanisms for CE redundancy and 3012 failover, in order to support High Availability as defined in 3013 [RFC3654]. FE redundancy and FE to FE interaction is currently out 3014 of scope of this draft. There can be multiple redundant CEs and FEs 3015 in a ForCES NE. However, at any one time only one Primary CE can 3016 control the FEs though there can be multiple secondary CEs. The FE 3017 and the CE PL are aware of the primary and secondary CEs. This 3018 information (primary, secondary CEs) is configured in the FE and in 3019 the CE PLs during pre-association by the FEM and the CEM 3020 respectively. Only the primary CE sends Control messages to the FEs. 3022 Two HA modes are defined in the ForCES protocol, Report Primary Mode 3023 and Report All Mode. The Report Primary Mode is the default mode of 3024 the protocol, in which the FEs only associate with one CE (primary) 3025 at a time. The Report All mode is for future study and not part of 3026 the current protocol version. In this mode, the FE would establish 3027 association with multiple CEs (primary and secondary) and report 3028 events, packets, Heart Beats to all the CEs. However, only the 3029 primary CE would configure/control the FE in this mode as well. This 3030 would help with keeping state between CEs synchronized, although it 3031 would not guarantee synchronization. 3033 The HA Modes are configured during Association setup phase, though 3034 currently only Report Primary Mode can be configured. A CE-to-CE 3035 synchronization protocol would be needed to support fast failover as 3036 well as address some of the corner cases, however this will not be 3037 defined by the ForCES protocol as it is out of scope for this 3038 specification. 3040 During a communication failure between the FE and CE (which is caused 3041 due to CE or link reasons, i.e. not FE related), either the TML on 3042 the FE will trigger the FE PL regarding this failure or it will be 3043 detected using the HB messages between FEs and CEs. The 3044 communication failure, regardless of how it is detected, MUST be 3045 considered as a loss of association between the CE and corresponding 3046 FE. In the Report Primary mode, as there should be no other existing 3047 CE-FE associations, the FE PL MUST at this point establish 3048 association with the secondary CE. Once the process has started, if 3049 the original primary CE comes alive and starts sending commands 3050 message to the FE, the FE MUST ignore those messages. If the 3051 original CE begins a new association phase with the FE then the FE 3052 MUST send an Association Setup Response message with Result = 2 3053 indicating that there are too many associations. It will be up to 3054 CE-CE communications, out of scope for this specification, to 3055 determine what what, if any changes should be made to FE 3056 configuration following the recovery process. 3058 An explicit message (Config message setting Primary CE attribute in 3059 ForCES Protocol object) from the primary CE, can also be used to 3060 change the Primary CE for an FE during normal protocol operation. 3062 Also note that the FEs in a ForCES NE could also use a multicast 3063 CEID, i.e. they are associated with a group of CEs (this assumes the 3064 use of a CE-CE synchronization protocol, which is out of scope for 3065 this specification). In this case the loss of association would mean 3066 that communication with the entire multicast group of CEs has been 3067 lost. The mechanisms described above will apply for this case as 3068 well during the loss of association. If, however, the secondary CE 3069 was also using the multicast CEID that was lost, then the FE will 3070 need to form a new association using a different CEID. If the 3071 capability exists, the FE MAY first attempt to form a new association 3072 with original primary CE using a different non multicast CEID. 3074 These two scenarios, Report Primary (default), Report Primary 3075 (currently unsupported), are illustrated in the Figure 36 and 3076 Figure 37 below. 3078 FE CE Primary CE Secondary 3079 | | | 3080 | Asso Estb,Caps exchg | | 3081 1 |<--------------------->| | 3082 | | | 3083 | All msgs | | 3084 2 |<--------------------->| | 3085 | | | 3086 | | | 3087 | FAILURE | 3088 | | 3089 | Asso Estb,Caps exchange | 3090 3 |<------------------------------------------>| 3091 | | 3092 | Event Report (pri CE down) | 3093 4 |------------------------------------------->| 3094 | | 3095 | All Msgs | 3096 5 |<------------------------------------------>| 3098 Figure 36: CE Failover for Report Primary Mode 3099 FE CE Primary CE Secondary 3100 | | | 3101 | Asso Estb,Caps exchg | | 3102 1 |<--------------------->| | 3103 | | | 3104 | Asso Estb,Caps|exchange | 3105 2 |<----------------------|------------------->| 3106 | | | 3107 | All msgs | | 3108 3 |<--------------------->| | 3109 | | | 3110 | packet redirection,|events, HBs | 3111 4 |-----------------------|------------------->| 3112 | | | 3113 | FAILURE | 3114 | | 3115 | Event Report (pri CE down) | 3116 5 |------------------------------------------->| 3117 | | 3118 | All Msgs | 3119 6 |<------------------------------------------>| 3121 Figure 37: CE Failover for Report All mode 3123 9.1. Responsibilities for HA 3125 TML level - Transport level: 3127 1. The TML controls logical connection availability and failover. 3129 2. The TML also controls peer HA management. 3131 At this level, control of all lower layers, for example transport 3132 level (such as IP addresses, MAC addresses etc) and associated links 3133 going down are the role of the TML. 3135 PL Level: 3136 For all other functionality including configuring the HA behavior 3137 during setup, the CEIDs are used to identify primary, secondary CEs, 3138 protocol Messages used to report CE failure (Event Report), Heartbeat 3139 messages used to detect association failure, messages to change 3140 primary CE (config - move), and other HA related operations described 3141 before are the PL responsibility. 3143 To put the two together, if a path to a primary CE is down, the TML 3144 would take care of failing over to a backup path, if one is 3145 available. If the CE is totally unreachable then the PL would be 3146 informed and it will take the appropriate actions described before. 3148 10. Security Considerations 3150 ForCES architecture identifies several levels of security in 3151 [RFC3746]. ForCES PL uses security services provided by the ForCES 3152 TML layer. TML layer provides security services such as endpoint 3153 authentication service, message authentication service and 3154 confidentiality service. Endpoint authentication service is invoked 3155 at the time of pre-association connection establishment phase and 3156 message authentication is performed whenever FE or CE receives a 3157 packet from its peer. 3159 The following are the general security mechanisms that needs to be in 3160 place for ForCES PL layer. 3162 o Security mechanisms are session controlled - that is, once the 3163 security is turned ON depending upon the chosen security level (No 3164 Security, Authentication only, Confidentiality), it will be in 3165 effect for the entire duration of the session. 3167 o Operator should configure the same security policies for both 3168 primary and backup FE's and CE's (if available). This will ensure 3169 uniform operations, and to avoid unnecessary complexity in policy 3170 configuration. 3172 o ForCES PL endpoints SHOULD pre-established connections with both 3173 primary and backup CE's. This will reduce the security messages 3174 and enable rapid switchover operations for HA. 3176 10.1. No Security 3178 When "No security" is chosen for ForCES protocol communication, both 3179 endpoint authentication and message authentication service needs to 3180 be performed by ForCES PL layer. Both these mechanism are weak and 3181 does not involve cryptographic operation. Operator can choose "No 3182 security" level when the ForCES protocol endpoints are within a 3183 single box. 3185 In order to have interoperable and uniform implementation across 3186 various security levels, each CE and FE endpoint MUST implement this 3187 level. The operations that are being performed for "No security" 3188 level is required even if lower TML security services are being used. 3190 10.1.1. Endpoint Authentication 3192 Each CE and FE PL layer maintains set of associations list as part of 3193 configuration. This is done via CEM and FEM interfaces. FE MUST 3194 connect to only those CE's that are configured via FEM similarly, a 3195 CE should accept the connection and establish associations for the 3196 FE's which are configured via CEM. CE should validate the FE 3197 identifier before accepting the connection during the pre-association 3198 phase. 3200 10.1.2. Message authentication 3202 When CE or FE generates initiates a message, the receiving endpoint 3203 MUST validate the initiator of the message by checking the common 3204 header CE or FE identifiers. This will ensure proper protocol 3205 functioning. This extra processing step is recommend even if the 3206 underlying TLM layer security services. 3208 10.2. ForCES PL and TML security service 3210 This section is applicable if operator wishes to use the TML security 3211 services. ForCES TML layer MUST support one or more security service 3212 such as endpoint authentication service, message authentication 3213 service, confidentiality service as part of TML security layer 3214 functions. It is the responsibility of the operator to select 3215 appropriate security service and configure security policies 3216 accordingly. The details of such configuration is outside the scope 3217 of ForCES PL and is depending upon the type of transport protocol, 3218 nature of connection. 3220 All these configurations should be done prior to starting the CE and 3221 FE. 3223 When certificates-based authentication is being used at TML layer, 3224 the certificate can use ForCES specific naming structure as 3225 certificate names and accordingly the security policies can be 3226 configured at CE and FE. 3228 10.2.1. Endpoint authentication service 3230 When TML security services are enabled. ForCES TML layer performs 3231 endpoint authentication. Security association is established between 3232 CE and FE and is transparent to the ForCES PL layer. 3234 It is recommended that an FE, after establishing the connection with 3235 the primary CE, should establish the security association with the 3236 backup CE (if available). During the switchover operation CE's 3237 security state associated with each SA's are not transferred. SA 3238 between primary CE and FE and backup CE and FE are treated as two 3239 separate SA's. 3241 10.2.2. Message authentication service 3243 This is TML specific operation and is transparent to ForCES PL layer. 3245 For details refer to Section 5. 3247 10.2.3. Confidentiality service 3249 This is TML specific operation and is transparent to ForCES PL layer. 3250 For details refer to Section 5. 3252 11. Acknowledgments 3254 The authors of this draft would like to acknowledge and thank the 3255 ForCES Working Group and especially the following: Furquan Ansari, 3256 Alex Audu, Steven Blake, Shuchi Chawla Alan DeKok, Ellen M. 3257 Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel M. 3258 Halpern (who should probably be listed among the authors), Zsolt 3259 Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, 3260 T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their 3261 contributions. We would also like to thank David Putzolu, and 3262 Patrick Droz for their comments and suggestions on the protocol and 3263 for their infinite patience. 3265 The editors have used the xml2rfc [RFC2629] tools in creating this 3266 document and are very grateful for the existence and quality of these 3267 tools. 3269 12. References 3271 12.1. Normative References 3273 [FE-MODEL] 3274 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., 3275 and S. Blake, "ForCES Forwarding Element Model", 3276 Feb. 2005. 3278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3279 Requirement Levels", BCP 14, RFC 2119, March 1997. 3281 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3282 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3283 October 1998. 3285 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 3286 of IP Control and Forwarding", RFC 3654, November 2003. 3288 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 3289 "Forwarding and Control Element Separation (ForCES) 3290 Framework", RFC 3746, April 2004. 3292 12.2. Informational References 3294 [2PCREF] Gray, J., "Notes on database operating systems. In 3295 Operating Systems: An Advanced Course. Lecture Notes in 3296 Computer Science, Vol. 60, pp. 394-481, Springer-Verlag", 3297 1978. 3299 [ACID] Haerder, T. and A. Reuter, "Principles of Transaction- 3300 Orientated Database Recovery", 1983. 3302 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 3303 June 1999. 3305 Appendix A. IANA Considerations 3307 Following the policies outlined in "Guidelines for Writing an IANA 3308 Considerations Section in RFCs" (RFC 2434 [RFC2434]), the following 3309 name spaces are defined in ForCES. 3311 o Message Type Name Space Section 7.1.1 3313 o Operation Type Name Space Section 7.1.1.1.6 3315 o Header Flags Section 6.1 3317 o TLV Type Section 7.1.1 3319 o TLV Result Values Section 7.1.1.1.7 3321 o LFB Class ID Section 7.1.1.1.5 3323 o Result: Association Setup Response Section 7.4.2 3325 o Reason: Association Teardown Message Section 7.4.3 3327 o Configuration Request: Operation Result Section 7.5.1 3329 A.1. Message Type Name Space 3331 The Message Type is an 8 bit value. The following is the guideline 3332 for defining the Message Type namespace 3334 Message Types 0x00 - 0x0F 3335 Message Types in this range are part of the base ForCES Protocol. 3336 Message Types in this range are allocated through an IETF 3337 consensus action. [RFC2434] 3338 Values assigned by this specification: 3340 0x00 Reserved 3341 0x01 AssociationSetup 3342 0x02 AssociationTeardown 3343 0x03 Config 3344 0x04 Query 3345 0x05 EventNotification 3346 0x06 PacketRedirect 3347 0x07 - 0x0E Reserved 3348 0x0F Hearbeat 3349 0x11 AssociationSetupRepsonse 3350 0x12 Reserved 3351 0x13 ConfigRepsonse 3352 0x14 QueryResponse 3354 Message Types 0x20 - 0x7F 3355 Message Types in this range are Specification Required [RFC2434] 3356 Message Types using this range must be documented in an RFC or 3357 other permanent and readily available references. 3359 Message Types 0x80 - 0xFF 3360 Message Types in this range are reserved for vendor private 3361 extensions and are the responsibility of individual vendors. IANA 3362 management of this range of the Message Type Name Space is 3363 unnecessary. 3365 A.2. Operation Type 3367 The Operation Type name space is 16 bits long. The following is the 3368 guideline for managing the Operation Type Name Space. 3370 Operation Type 0x0000-0x00FF 3371 Operation Types in this range are allocated through an IETF 3372 consensus process. [RFC2434]. 3373 Values assigned by this specification: 3375 0x0000 Reserved 3376 0x0001 SET 3377 0x0002 SET-RESPONSE 3378 0x0003 DEL 3379 0x0004 DEL-RESPONSE 3380 0x0005 GET 3381 0x0006 GET-RESPONSE 3382 0x0007 REPORT 3384 Operation Type 0x0100-0x7FFF 3385 Operation Types using this range must be documented in an RFC or 3386 other permanent and readily available references. [RFC2434]. 3388 Operation Type 0x8000-0xFFFF 3389 Operation Types in this range are reserved for vendor private 3390 extensions and are the responsibility of individual vendors. IANA 3391 management of this range of the Operation Type Name Space is 3392 unnecessary. 3394 A.3. Header Flags 3396 The Header flag field is 32 bits long Header flags are part of the 3397 ForCES base protocol. Header flags are allocated through an IETF 3398 consensus action [RFC2434]. 3400 A.4. TLV Type Name Space 3402 The TLV Type name space is 16 bits long. The following is the 3403 guideline for managing the TLV Type Name Space. 3405 TLV Type 0x0000-0x00FF 3406 TLV Types in this range are allocated through an IETF consensus 3407 process. [RFC2434]. 3408 Values assigned by this specification: 3410 0x0000 Reserved 3411 0x0001 MAIN_TLV 3412 0x0002 REDIRECT-TLV 3413 0x0010 ASResult-TLV 3414 0x0011 ASTreason-TLV 3415 0x1000 LFBselect-TLV 3416 0x0101 OPER-TLV 3417 0x0110 PATH-DATA-TLV 3418 0x0111 KEYINFO-TLV 3419 0x0112 FULLDATA-TLV 3420 0x0113 SPARSEDATA-TLV 3421 0x0114 RESULT-TLV 3423 TLV Type 0x0200-0x7FFF 3424 TLV Types using this range must be documented in an RFC or other 3425 permanent and readily available references. [RFC2434]. 3427 TLV Type 0x8000-0xFFFF 3428 TLV Types in this range are reserved for vendor private extensions 3429 and are the responsibility of individual vendors. IANA management 3430 of this range of the TLV Type Name Space is unnecessary. 3432 A.5. Result-TLV Result Values 3434 The RESULT-TLV RTesult Value is an 8 bit value. 3436 0x00 SUCCESS 3437 0x01 INVALID_HEADER 3438 0x02 LENGTH_MISMATCH 3439 0x03 VERSION_MISMATCH 3440 0x04 INVALID_DESTINATION_PID 3441 0x05 LFB_UNKNOWN 3442 0x06 LFB_NOT_FOUND 3443 0x07 LFB_INSTANCE_ID_NOT_FOUND 3444 0x08 INVALID_PATH 3445 0x09 ELEMENT_DOES_NOT_EXIST 3446 0x0A EXISTS 3447 0x0B NOT_FOUND 3448 0x0C READ_ONLY 3449 0x0D INVALID_ARRAY_CREATION 3450 0x0E VALUE_OUT_OF_RANGE 3451 0x0F CONTENTS_TOO_LONG 3452 0x10 INVALID_PARAMETERS 3453 0x11 INVALID_MESSAGE_TYPE 3454 0x12 INVALID_FLAGS 3455 0x13 INVALID_TLV 3456 0x14 EVENT_ERROR 3457 0x15 NOT_SUPPORTED 3458 0x16 MEMORY_ERROR 3459 0x17 INTERNAL_ERROR 3460 0x18-0xFE Reserved 3461 0xFF UNSPECIFIED_ERROR 3463 All values not assigned in this specification are designated as 3464 Assignment by Expert review. 3466 A.6. LFB Class Id Name Space 3468 The LFB Class ID name space is 32 bits long. The following is the 3469 guideline for managing the LFB Class Id Name Space. 3471 LFB Class ID 0x00000000-0x0000FFFF 3472 LFB Class IDs in this range are allocated through an IETF 3473 consensus process. [RFC2434]. 3474 Values assigned by this specification: 3476 0x00000000 Reserved 3477 0x00000001 FE Protocol LFB 3478 0x00000002 FE Object LFB 3480 LFB Class ID 0x00010000-0x7FFFFFFF 3481 LFB Class IDs in this range are Specification Required [RFC2434] 3482 LFB Class ID using this range must be documented in an RFC or 3483 other permanent and readily available references. [RFC2434]. 3485 LFB Class Id 0x80000000-0xFFFFFFFFF 3486 LFB Class IDs in this range are reserved for vendor private 3487 extensions and are the responsibility of individual vendors. IANA 3488 management of this range of the LFB Class ID Space is unnecessary. 3490 A.7. Association Setup Response 3492 The Association Setup Response name space is 16 bits long. The 3493 following is the guideline for managing the Association Setup 3494 Response Name Space. 3496 Association Setup Response 0x0000-0x00FF 3497 Association Setup Responses in this range are allocated through an 3498 IETF consensus process. [RFC2434]. 3499 Values assigned by this specification: 3501 0x0000 Success 3502 0x0001 FE ID Invalid 3503 0x0002 Too many associations 3504 0x0003 Permission Denied 3506 Association Setup Response 0x0100-0x0FFF 3507 Association Setup Responses in this range are Specification 3508 Required [RFC2434] Values using this range must be documented in 3509 an RFC or other permanent and readily available references. 3510 [RFC2434]. 3512 Association Setup Response 0x80000000-0xFFFFFFFFF 3513 Association Setup Responses in this range are reserved for vendor 3514 private extensions and are the responsibility of individual 3515 vendors. IANA management of this range of the Association Setup 3516 Responses Name Space is unnecessary. 3518 A.8. Association Teardown Message 3520 The Association Teardown Message name space is 32 bits long. The 3521 following is the guideline for managing the Association Teardown 3522 Message Name Space. 3524 Association Teardown Message 0x00000000-0x0000FFFF 3525 Association Teardown Messages in this range are allocated through 3526 an IETF consensus process. [RFC2434]. 3527 Values assigned by this specification: 3529 0x00000000 Normal - Teardown by Administrator 3530 0x00000001 Error - Out of Memory 3531 0x00000002 Error - Application Crash 3532 0x000000FF Error - Unspecified 3534 Association Teardown Message 0x00010000-0x7FFFFFFF 3535 Association Teardown Messages in this range are Specification 3536 Required [RFC2434] Association Teardown Messages using this range 3537 must be documented in an RFC or other permanent and readily 3538 available references. [RFC2434]. 3540 LFB Class Id 0x80000000-0xFFFFFFFFF 3541 Association Teardown Messages in this range are reserved for 3542 vendor private extensions and are the responsibility of individual 3543 vendors. IANA management of this range of the Association 3544 Teardown Message Name Space is unnecessary. 3546 A.9. Configuration Request Result 3548 The Configuration Request name space is 32 bits long. The following 3549 is the guideline for managing the Configuration Request Name Space. 3551 Configuration Request 0x0000-0x00FF 3552 Configuration Requests in this range are allocated through an IETF 3553 consensus process. [RFC2434]. 3554 Values assigned by this specification: 3556 0x0000 Success 3557 0x0001 FE ID Invalid 3558 0x0003 Permission Denied 3560 Configuration Request 0x0100-0x7FFF 3561 Configuration Requests in this range are Specification Required 3562 [RFC2434] Configuration Requests using this range must be 3563 documented in an RFC or other permanent and readily available 3564 references. [RFC2434]. 3566 0x8000-0xFFFF 3567 Configuration Requests in this range are reserved for vendor 3568 private extensions and are the responsibility of individual 3569 vendors. IANA management of this range of the Configuration 3570 Request Name Space is unnecessary. 3572 Appendix B. ForCES Protocol LFB schema 3574 The schema described below conforms to the LFB schema described in 3575 ForCES Model draft[FE-MODEL] 3577 3582 3583 3584 3585 CEHBPolicyValues 3586 3587 The possible values of CE heartbeat policy 3588 3589 3590 uchar 3591 3592 3593 CEHBPolicy0 3594 3595 The CE heartbeat policy 0, refer to 3596 for details 3597 3598 3599 3600 CEHBPolicy1 3601 3602 The CE heartbeat policy 1, refer to 3603 for details 3604 3605 3606 3607 3608 3610 3611 FEHBPolicyValues 3612 3613 The possible values of FE heartbeat policy 3614 3615 3616 uchar 3617 3618 3619 FEHBPolicy0 3620 3621 The FE heartbeat policy 0, refer to 3622 for details 3623 3624 3625 3626 FEHBPolicy1 3627 3628 The FE heartbeat policy 1, refer to 3629 for details 3630 3631 3632 3633 3634 3636 3637 FERestartPolicyValues 3638 3639 The possible values of FE restart policy 3640 3641 3642 uchar 3643 3644 3645 FERestartPolicy0 3646 3647 The FE restart policy 0, refer to 3648 for details 3649 3650 3651 3652 FERestartPolicy1 3653 3654 The FE restart policy 1, refer to 3655 for details 3656 3657 3658 3659 3660 3662 3663 CEFailoverPolicyValues 3664 3665 The possible values of CE failover policy 3666 3667 3668 uchar 3669 3670 3671 CEFailoverPolicy0 3672 3673 The CE failover policy 0, refer to 3674 for details 3675 3676 3677 3678 CEFailoverPolicy1 3679 3680 The CE failover policy 1, refer to 3681 for details 3682 3683 3684 3685 CEFailoverPolicy2 3686 3687 The CE failover policy 2, refer to 3688 for details 3689 3690 3691 3692 3693 3694 3696 3697 3698 FEPO 3699 1 3700 3701 The FE Protocol Object 3702 3703 1.0 3704 baseclass 3706 3707 3708 CurrentRunningVersion 3709 Currently running ForCES version 3710 u8 3711 3712 3713 FEID 3714 Unicast FEID 3715 uint32 3717 3718 3719 MulticastFEIDs 3720 3721 the table of all multicast IDs 3722 3723 3724 uint32 3725 3726 3727 3728 CEHBPolicy 3729 3730 The CE Heartbeat Policy 3731 3732 CEHBPolicyValues 3733 3734 3735 CEHDI 3736 3737 The CE Heartbeat Dead Interval in millisecs 3738 3739 uint32 3740 3741 3742 FEHBPolicy 3743 3744 The FE Heartbeat Policy 3745 3746 FEHBPolicyValues 3747 3748 3749 FEHI 3750 3751 The FE Heartbeat Interval in millisecs 3752 3753 uint32 3754 3755 3756 CEID 3757 3758 The Primary CE this FE is associated with 3759 3760 uint32 3761 3762 3763 BackupCEs 3764 3765 The table of all backup CEs other than the primary 3766 3767 3768 uint32 3769 3770 3771 3772 FERestartPolicy 3773 3774 The FE Restart Policy 3775 3776 FERestartPolicyValues 3777 3779 3780 CEFailoverPolicy 3781 3782 The CE Failover Policy 3783 3784 CEFailoverPolicyValues 3785 3787 3788 CETI 3789 3790 The CE Timeout Interval in millisecs 3791 3792 uint32 3793 3794 3795 3796 3797 SupportableVersions 3798 3799 the table of ForCES versions that FE supports 3800 3801 3802 u8 3803 3804 3805 3806 3807 3808 3810 B.1. Capabilities 3812 At the moment only the SupportableVersions capability is owned by 3813 this LFB. 3815 Supportable Versions enumerates all ForCES versions that an FE 3816 supports. 3818 B.2. Attributes 3820 All Attributes are explained in Section 7.2.1. 3822 Appendix C. Data Encoding Examples 3824 In this section a few examples of data encoding are discussed. these 3825 example, however, do not show any padding. 3827 ========== 3828 Example 1: 3829 ========== 3831 Structure with three fixed-lengthof, mandatory fields. 3833 struct S { 3834 uint16 a 3835 uint16 b 3836 uint16 c 3837 } 3839 (a) Describing all fields using SPARSEDATA 3841 Path-Data TLV 3842 Path to an instance of S ... 3843 SPARSEDATA TLV 3844 ElementIDof(a), lengthof(a), valueof(a) 3845 ElementIDof(b), lengthof(b), valueof(b) 3846 ElementIDof(c), lengthof(c), valueof(c) 3848 (b) Describing a subset of fields 3850 Path-Data TLV 3851 Path to an instance of S ... 3852 SPARSEDATA TLV 3853 ElementIDof(a), lengthof(a), valueof(a) 3854 ElementIDof(c), lengthof(c), valueof(c) 3856 Note: Even though there are non-optional elements in structure S, 3857 since one can uniquely identify elements, one can selectively send 3858 element of structure S (eg in the case of an update from CE to FE). 3860 (c) Describing all fields using a FULLDATA TLV 3862 Path-Data TLV 3863 Path to an instance of S ... 3864 FULLDATA TLV 3865 valueof(a) 3866 valueof(b) 3867 valueof(c) 3869 ========== 3870 Example 2: 3871 ========== 3873 Structure with three fixed-lengthof fields, one mandatory, two 3874 optional. 3876 struct T { 3877 uint16 a 3878 uint16 b (optional) 3879 uint16 c (optional) 3880 } 3882 This example is identical to Example 1, as illustrated below. 3884 (a) Describing all fields using SPARSEDATA 3886 Path-Data TLV 3887 Path to an instance of S ... 3888 SPARSEDATA TLV 3889 ElementIDof(a), lengthof(a), valueof(a) 3890 ElementIDof(b), lengthof(b), valueof(b) 3891 ElementIDof(c), lengthof(c), valueof(c) 3893 (b) Describing a subset of fields using SPARSEDATA 3895 Path-Data TLV 3896 Path to an instance of S ... 3897 SPARSEDATA TLV 3898 ElementIDof(a), lengthof(a), valueof(a) 3899 ElementIDof(c), lengthof(c), valueof(c) 3901 (c) Describing all fields using a FULLDATA TLV 3903 Path-Data TLV 3904 Path to an instance of S ... 3905 FULLDATA TLV 3906 valueof(a) 3907 valueof(b) 3908 valueof(c) 3910 Note: FULLDATA TLV _cannot_ be used unless all fields are being 3911 described. 3913 ========== 3914 Example 3: 3915 ========== 3916 Structure with a mix of fixed-lengthof and variable-lengthof fields, 3917 some mandatory, some optional. 3919 struct U { 3920 uint16 a 3921 string b (optional) 3922 uint16 c (optional) 3923 } 3925 (a) Describing all fields using SPARSEDATA 3927 Path to an instance of U ... 3928 SPARSEDATA TLV 3929 ElementIDof(a), lengthof(a), valueof(a) 3930 ElementIDof(b), lengthof(b), valueof(b) 3931 ElementIDof(c), lengthof(c), valueof(c) 3933 (b) Describing a subset of fields using SPARSEDATA 3935 Path to an instance of U ... 3936 SPARSEDATA TLV 3937 ElementIDof(a), lengthof(a), valueof(a) 3938 ElementIDof(c), lengthof(c), valueof(c) 3940 (c) Describing all fields using FULLDATA TLV 3942 Path to an instance of U ... 3943 FULLDATA TLV 3944 valueof(a) 3945 FULLDATA TLV 3946 valueof(b) 3947 valueof(c) 3949 Note: The variable-length field requires the addition of a FULLDATA 3950 TLV within the outer FULLDATA TLV as in the case of element b above. 3952 ========== 3953 Example 4: 3954 ========== 3956 Structure containing an array of another structure type. 3958 struct V { 3959 uint32 x 3960 uint32 y 3961 struct U z[] 3962 } 3964 (a) Encoding using SPARSEDATA, with two instances of z[], also 3965 described with SPARSEDATA, assuming only the 10th and 15th subscript 3966 of z[] are encoded. 3968 path to instance of V ... 3969 SPARSEDATA TLV 3970 ElementIDof(x), lengthof(x), valueof(x) 3971 ElementIDof(y), lengthof(y), valueof(y) 3972 ElementIDof(z), lengthof(all below) 3973 ElementID = 10 (i.e index 10 from z[]), lengthof(all below) 3974 ElementIDof(a), lengthof(a), valueof(a) 3975 ElementIDof(b), lengthof(b), valueof(b) 3976 ElementID = 15 (index 15 from z[]), lengthof(all below) 3977 ElementIDof(a), lengthof(a), valueof(a) 3978 ElementIDof(c), lengthof(c), valueof(c) 3980 Note the holes in the elements of z (10 followed by 15). Also note 3981 the gap in index 15 with only elements a and c appearing but not b. 3983 Appendix D. Use Cases 3985 Assume LFB with following attributes for the following use cases. 3987 foo1, type u32, ID = 1 3989 foo2, type u32, ID = 2 3991 table1: type array, ID = 3 3992 elements are: 3993 t1, type u32, ID = 1 3994 t2, type u32, ID = 2 // index into table 2 3995 KEY: nhkey, ID = 1, V = t2 3997 table2: type array, ID = 4 3998 elements are: 3999 j1, type u32, ID = 1 4000 j2, type u32, ID = 2 4001 KEY: akey, ID = 1, V = { j1,j2 } 4003 table3: type array, ID = 5 4004 elements are: 4005 someid, type u32, ID = 1 4006 name, type string variable sized, ID = 2 4008 table4: type array, ID = 6 4009 elements are: 4010 j1, type u32, ID = 1 4011 j2, type u32, ID = 2 4012 j3, type u32, ID = 3 4013 j4, type u32, ID = 4 4014 KEY: mykey, ID = 1, V = { j1} 4016 table5: type array, ID = 7 4017 elements are: 4018 p1, type u32, ID = 1 4019 p2, type array, ID = 2, array elements of type-X 4021 Type-X: 4022 x1, ID 1, type u32 4023 x2, ID2 , type u32 4024 KEY: tkey, ID = 1, V = { x1} 4026 All examples will show an attribute suffixed with "v" or "val" to 4027 indicate the value of the referenced attribute. example for attribute 4028 foo2, foo1v or foo1value will indicate the value of foo1. In the 4029 case where F_SEL** are missing (bits equal to 00) then the flags will 4030 not show any selection. 4032 All the examples only show use of FULLDATA for data encoding; 4033 although SPARSEDATA would make more sense in certain occasions, the 4034 emphasis is on showing the message layout. Refer to Appendix C for 4035 examples that show usage of both FULLDATA and SPARSEDATA. 4037 1. To get foo1 4039 OPER = GET-TLV 4040 Path-data TLV: IDCount = 1, IDs = 1 4041 Result: 4042 OPER = GET-RESPONSE-TLV 4043 Path-data-TLV: 4044 flags=0, IDCount = 1, IDs = 1 4045 FULLDATA-TLV L = 4+4, V = foo1v 4047 2. To set foo2 to 10 4049 OPER = SET-REPLACE-TLV 4050 Path-data-TLV: 4051 flags = 0, IDCount = 1, IDs = 2 4052 FULLDATA TLV: L = 4+4, V=10 4054 Result: 4055 OPER = SET-RESPONSE-TLV 4056 Path-data-TLV: 4057 flags = 0, IDCount = 1, IDs = 2 4058 RESULT-TLV 4060 3. To dump table2 4062 OPER = GET-TLV 4063 Path-data-TLV: 4064 IDCount = 1, IDs = 4 4065 Result: 4066 OPER = GET-RESPONSE-TLV 4067 Path-data-TLV: 4068 flags = 0, IDCount = 1, IDs = 4 4069 FULLDATA=TLV: L = XXX, V= 4070 a series of: index, j1value, j2value entries 4071 representing the entire table 4073 Note: One should be able to take a GET-RESPONSE-TLV and convert 4074 it to a SET-REPLACE-TLV. If the result in the above example 4075 is sent back in a SET-REPLACE-TLV, (instead of a GET- 4076 RESPONSE_TLV) then the entire contents of the table will be 4077 replaced at that point. 4079 4. Multiple operations Example. To create entry 0-5 of table2 4080 (Error conditions are ignored) 4082 OPER = SET-CREATE-TLV 4083 Path-data-TLV: 4084 flags = 0 , IDCount = 1, IDs=4 4085 PATH-DATA-TLV 4086 flags = 0, IDCount = 1, IDs = 0 4087 FULLDATA-TLV containing j1, j2 value for entry 0 4088 PATH-DATA-TLV 4089 flags = 0, IDCount = 1, IDs = 1 4090 FULLDATA-TLV containing j1, j2 value for entry 1 4091 PATH-DATA-TLV 4092 flags = 0, IDCount = 1, IDs = 2 4093 FULLDATA-TLV containing j1, j2 value for entry 2 4094 PATH-DATA-TLV 4095 flags = 0, IDCount = 1, IDs = 3 4096 FULLDATA-TLV containing j1, j2 value for entry 3 4097 PATH-DATA-TLV 4098 flags = 0, IDCount = 1, IDs = 4 4099 FULLDATA-TLV containing j1, j2 value for entry 4 4100 PATH-DATA-TLV 4101 flags = 0, IDCount = 1, IDs = 5 4102 FULLDATA-TLV containing j1, j2 value for entry 5 4104 Result: 4105 OPER = SET-RESPONSE-TLV 4106 Path-data-TLV: 4107 flags = 0 , IDCount = 1, IDs=4 4108 PATH-DATA-TLV 4109 flags = 0, IDCount = 1, IDs = 0 4110 RESULT-TLV 4111 PATH-DATA-TLV 4112 flags = 0, IDCount = 1, IDs = 1 4113 RESULT-TLV 4114 PATH-DATA-TLV 4115 flags = 0, IDCount = 1, IDs = 2 4116 RESULT-TLV 4117 PATH-DATA-TLV 4118 flags = 0, IDCount = 1, IDs = 3 4119 RESULT-TLV 4120 PATH-DATA-TLV 4121 flags = 0, IDCount = 1, IDs = 4 4122 RESULT-TLV 4123 PATH-DATA-TLV 4124 flags = 0, IDCount = 1, IDs = 5 4125 RESULT-TLV 4127 5. Block operations (with holes) example. Replace entry 0,2 of 4128 table2 4130 OPER = SET-REPLACE-TLV 4131 Path-data TLV: 4132 flags = 0 , IDCount = 1, IDs=4 4133 PATH-DATA-TLV 4134 flags = 0, IDCount = 1, IDs = 0 4135 FULLDATA-TLV containing j1, j2 value for entry 0 4136 PATH-DATA-TLV 4137 flags = 0, IDCount = 1, IDs = 2 4138 FULLDATA-TLV containing j1, j2 value for entry 2 4140 Result: 4141 OPER = SET-REPLACE-TLV 4142 Path-data TLV: 4143 flags = 0 , IDCount = 1, IDs=4 4144 PATH-DATA-TLV 4145 flags = 0, IDCount = 1, IDs = 0 4146 RESULT-TLV 4147 PATH-DATA-TLV 4148 flags = 0, IDCount = 1, IDs = 2 4149 RESULT-TLV 4151 6. Getting rows example. Get first entry of table2. 4153 OPER = GET-TLV 4154 Path-data TLV: 4155 IDCount = 2, IDs=4.0 4157 Result: 4158 OPER = GET-RESPONSE-TLV 4159 Path-data TLV: 4160 IDCount = 2, IDs=4.0 4161 FULLDATA TLV, Length = XXX, V = 4162 j1value,j2value entry 4164 7. Get entry 0-5 of table2. 4166 OPER = GET-TLV 4167 Path-data-TLV: 4168 flags = 0, IDCount = 1, IDs=4 4169 PATH-DATA-TLV 4170 flags = 0, IDCount = 1, IDs = 0 4171 PATH-DATA-TLV 4172 flags = 0, IDCount = 1, IDs = 1 4173 PATH-DATA-TLV 4174 flags = 0, IDCount = 1, IDs = 2 4175 PATH-DATA-TLV 4176 flags = 0, IDCount = 1, IDs = 3 4177 PATH-DATA-TLV 4178 flags = 0, IDCount = 1, IDs = 4 4179 PATH-DATA-TLV 4180 flags = 0, IDCount = 1, IDs = 5 4182 Result: 4183 OPER = GET-RESPONSE-TLV 4184 Path-data-TLV: 4185 flags = 0, IDCount = 1, IDs=4 4186 PATH-DATA-TLV 4187 flags = 0, IDCount = 1, IDs = 0 4188 FULLDATA-TLV containing j1value j2value 4189 PATH-DATA-TLV 4190 flags = 0, IDCount = 1, IDs = 1 4191 FULLDATA-TLV containing j1value j2value 4192 PATH-DATA-TLV 4193 flags = 0, IDCount = 1, IDs = 2 4194 FULLDATA-TLV containing j1value j2value 4195 PATH-DATA-TLV 4196 flags = 0, IDCount = 1, IDs = 3 4197 FULLDATA-TLV containing j1value j2value 4198 PATH-DATA-TLV 4199 flags = 0, IDCount = 1, IDs = 4 4200 FULLDATA-TLV containing j1value j2value 4201 PATH-DATA-TLV 4202 flags = 0, IDCount = 1, IDs = 5 4203 FULLDATA-TLV containing j1value j2value 4205 8. Create a row in table2, index 5. 4207 OPER = SET-CREATE-TLV 4208 Path-data-TLV: 4209 flags = 0, IDCount = 2, IDs=4.5 4210 FULLDATA TLV, Length = XXX 4211 j1value,j2value 4213 Result: 4214 OPER = SET-RESPONSE-TLV 4215 Path-data TLV: 4216 flags = 0, IDCount = 1, IDs=4.5 4217 RESULT-TLV 4219 9. An example of "create and give me an index" Assuming one asked 4220 for verbose response back in the main message header. 4222 OPER = SET-CREATE-TLV 4223 Path-data -TLV: 4224 flags = FIND-EMPTY, IDCount = 1, IDs=4 4225 FULLDATA TLV, Length = XXX 4226 j1value,j2value 4228 Result 4229 If 7 were the first unused entry in the table: 4230 OPER = SET-RESPONSE 4231 Path-data TLV: 4232 flags = 0, IDCount = 2, IDs=4.7 4233 RESULT-TLV indicating success, and 4234 FULLDATA-TLV, Length = XXX j1value,j2value 4236 10. Dump contents of table1. 4238 OPER = GET-TLV 4239 Path-data TLV: 4240 flags = 0, IDCount = 1, IDs=3 4242 Result: 4243 OPER = GET-RESPONSE-TLV 4244 Path-data TLV 4245 flags = 0, IDCount = 1, IDs=3 4246 FULLDATA TLV, Length = XXXX 4247 (depending on size of table1) 4248 index, t1value, t2value 4249 index, t1value, t2value 4250 . 4252 . 4253 . 4255 11. Using Keys. Get row entry from table4 where j1=100. Recall, j1 4256 is a defined key for this table and its keyid is 1. 4258 OPER = GET-TLV 4259 Path-data-TLV: 4260 flags = F_SELKEY IDCount = 1, IDs=6 4261 KEYINFO-TLV = KEYID=1, KEY_DATA=100 4263 Result: 4264 If j1=100 was at index 10 4265 OPER = GET-RESPONSE-TLV 4266 Path-data TLV: 4267 flags = 0, IDCount = 1, IDs=6.10 4268 FULLDATA TLV, Length = XXXX 4269 j1value,j2value, j3value, j4value 4271 12. Delete row with KEY match (j1=100, j2=200) in table 2. Note 4272 that the j1,j2 pair are a defined key for the table 2. 4274 OPER = DEL-TLV 4275 Path-data TLV: 4276 flags = F_SELKEY IDCount = 1, IDs=4 4277 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} 4279 Result: 4280 If (j1=100, j2=200) was at entry 15: 4281 OPER = DELETE-RESPONSE-TLV 4282 Path-data TLV: 4283 flags = 0 IDCount = 2, IDs=4.15 4284 RESULT-TLV (with FULLDATA if verbose) 4286 13. Dump contents of table3. It should be noted that this table has 4287 a column with element name that is variable sized. The purpose 4288 of this use case is to show how such an element is to be 4289 encoded. 4291 OPER = GET-TLV 4292 Path-data-TLV: 4293 flags = 0 IDCount = 1, IDs=5 4295 Result: 4296 OPER = GET-RESPONSE-TLV 4297 Path-data TLV: 4298 flags = 0 IDCount = 1, IDs=5 4299 FULLDATA TLV, Length = XXXX 4300 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4301 V = namev 4302 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4303 V = namev 4304 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4305 V = namev 4306 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4307 V = namev 4308 . 4309 . 4310 . 4312 14. Multiple atomic operations. 4314 Note 1: This emulates adding a new nexthop entry and then 4315 atomically updating the L3 entries pointing to an old NH to 4316 point to a new one. The assumption is both tables are in the 4317 same LFB 4319 Note2: Main header has atomic flag set and the request is for 4320 verbose/full results back; Two operations on the LFB 4321 instance, both are SET operations. 4323 //Operation 1: Add a new entry to table2 index #20. 4324 OPER = SET-CREATE-TLV 4325 Path-TLV: 4326 flags = 0, IDCount = 2, IDs=4.20 4327 FULLDATA TLV, V= j1value,j2value 4329 // Operation 2: Update table1 entry which 4330 // was pointing with t2 = 10 to now point to 20 4331 OPER = SET-REPLACE-TLV 4332 Path-data-TLV: 4333 flags = F_SELKEY, IDCount = 1, IDs=3 4334 KEYINFO = KEYID=1 KEY_DATA=10 4335 Path-data-TLV 4336 flags = 0 IDCount = 1, IDs=2 4337 FULLDATA TLV, V= 20 4339 Result: 4340 //first operation, SET 4341 OPER = SET-RESPONSE-TLV 4342 Path-data-TLV 4343 flags = 0 IDCount = 3, IDs=4.20 4344 RESULT-TLV code = success 4345 FULLDATA TLV, V = j1value,j2value 4346 // second opertion SET - assuming entry 16 was updated 4347 OPER = SET-RESPONSE-TLV 4348 Path-data TLV 4349 flags = 0 IDCount = 2, IDs=3.16 4350 Path-Data TLV 4351 flags = 0 IDCount = 1, IDs = 2 4352 SET-RESULT-TLV code = success 4353 FULLDATA TLV, Length = XXXX v=20 4354 // second opertion SET 4355 OPER = SET-RESPONSE-TLV 4356 Path-data TLV 4357 flags = 0 IDCount = 1, IDs=3 4358 KEYINFO = KEYID=1 KEY_DATA=10 4359 Path-Data TLV 4360 flags = 0 IDCount = 1, IDs = 2 4361 SET-RESULT-TLV code = success 4362 FULLDATA TLV, Length = XXXX v=20 4364 15. Selective setting. On table 4 -- for indices 1, 3, 5, 7, and 9. 4365 Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. 4367 PER = SET-REPLACE-TLV 4368 Path-data TLV 4369 flags = 0, IDCount = 1, IDs = 6 4370 Path-data TLV 4371 flags = 0, IDCount = 1, IDs = 1 4372 Path-data TLV 4373 flags = 0, IDCount = 1, IDs = 1 4374 FULLDATA TLV, Length = XXXX, V = {100} 4375 Path-data TLV 4376 flags = 0, IDCount = 1, IDs = 2 4377 FULLDATA TLV, Length = XXXX, V = {200} 4378 Path-data TLV 4379 flags = 0, IDCount = 1, IDs = 3 4380 FULLDATA TLV, Length = XXXX, V = {300} 4381 Path-data TLV 4382 flags = 0, IDCount = 1, IDs = 3 4383 Path-data TLV 4384 flags = 0, IDCount = 1, IDs = 1 4385 FULLDATA TLV, Length = XXXX, V = {100} 4386 Path-data TLV 4387 flags = 0, IDCount = 1, IDs = 2 4388 FULLDATA TLV, Length = XXXX, V = {200} 4389 Path-data TLV 4390 flags = 0, IDCount = 1, IDs = 3 4391 FULLDATA TLV, Length = XXXX, V = {300} 4392 Path-data TLV 4393 flags = 0, IDCount = 1, IDs = 5 4394 Path-data TLV 4395 flags = 0, IDCount = 1, IDs = 1 4396 FULLDATA TLV, Length = XXXX, V = {100} 4397 Path-data TLV 4398 flags = 0, IDCount = 1, IDs = 2 4399 FULLDATA TLV, Length = XXXX, V = {200} 4400 Path-data TLV 4401 flags = 0, IDCount = 1, IDs = 3 4402 FULLDATA TLV, Length = XXXX, V = {300} 4403 Path-data TLV 4404 flags = 0, IDCount = 1, IDs = 7 4405 Path-data TLV 4406 flags = 0, IDCount = 1, IDs = 1 4407 FULLDATA TLV, Length = XXXX, V = {100} 4408 Path-data TLV 4409 flags = 0, IDCount = 1, IDs = 2 4410 FULLDATA TLV, Length = XXXX, V = {200} 4411 Path-data TLV 4412 flags = 0, IDCount = 1, IDs = 3 4413 FULLDATA TLV, Length = XXXX, V = {300} 4414 Path-data TLV 4415 flags = 0, IDCount = 1, IDs = 9 4416 Path-data TLV 4417 flags = 0, IDCount = 1, IDs = 1 4418 FULLDATA TLV, Length = XXXX, V = {100} 4419 Path-data TLV 4420 flags = 0, IDCount = 1, IDs = 2 4421 FULLDATA TLV, Length = XXXX, V = {200} 4422 Path-data TLV 4423 flags = 0, IDCount = 1, IDs = 3 4424 FULLDATA TLV, Length = XXXX, V = {300} 4426 Non-verbose response mode shown: 4428 OPER = SET-RESPONSE-TLV 4429 Path-data TLV 4430 flags = 0, IDCount = 1, IDs = 6 4431 Path-data TLV 4432 flags = 0, IDCount = 1, IDs = 1 4433 Path-data TLV 4434 flags = 0, IDCount = 1, IDs = 1 4435 RESULT-TLV 4436 Path-data TLV 4437 flags = 0, IDCount = 1, IDs = 2 4438 RESULT-TLV 4439 Path-data TLV 4440 flags = 0, IDCount = 1, IDs = 3 4441 RESULT-TLV 4442 Path-data TLV 4443 flags = 0, IDCount = 1, IDs = 3 4444 Path-data TLV 4445 flags = 0, IDCount = 1, IDs = 1 4446 RESULT-TLV 4447 Path-data TLV 4448 flags = 0, IDCount = 1, IDs = 2 4449 RESULT-TLV 4450 Path-data TLV 4451 flags = 0, IDCount = 1, IDs = 3 4452 RESULT-TLV 4453 Path-data TLV 4454 flags = 0, IDCount = 1, IDs = 5 4455 Path-data TLV 4456 flags = 0, IDCount = 1, IDs = 1 4457 RESULT-TLV 4458 Path-data TLV 4459 flags = 0, IDCount = 1, IDs = 2 4460 RESULT-TLV 4461 Path-data TLV 4462 flags = 0, IDCount = 1, IDs = 3 4463 RESULT-TLV 4465 Path-data TLV 4466 flags = 0, IDCount = 1, IDs = 7 4467 Path-data TLV 4468 flags = 0, IDCount = 1, IDs = 1 4469 RESULT-TLV 4470 Path-data TLV 4471 flags = 0, IDCount = 1, IDs = 2 4472 RESULT-TLV 4473 Path-data TLV 4474 flags = 0, IDCount = 1, IDs = 3 4475 RESULT-TLV 4476 Path-data TLV 4477 flags = 0, IDCount = 1, IDs = 9 4478 Path-data TLV 4479 flags = 0, IDCount = 1, IDs = 1 4480 RESULT-TLV 4481 Path-data TLV 4482 flags = 0, IDCount = 1, IDs = 2 4483 RESULT-TLV 4484 Path-data TLV 4485 flags = 0, IDCount = 1, IDs = 3 4486 RESULT-TLV 4488 16. Manipulation of table of table examples. Get x1 from table10 4489 row with index 4, inside table5 entry 10 4491 operation = GET-TLV 4492 Path-data-TLV 4493 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4495 Results: 4496 operation = GET-RESPONSE-TLV 4497 Path-data-TLV 4498 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4499 FULLDATA TLV: L=XXXX, V = {x1 value} 4501 17. From table5's row 10 table10, get X2s based on on the value of 4502 x1 equaling 10 (recall x1 is KeyID 1) 4504 operation = GET-TLV 4505 Path-data-TLV 4506 flag = F_SELKEY, IDCount=3, IDS = 7.10.2 4507 KEYINFO TLV, KEYID = 1, KEYDATA = 10 4508 Path-data TLV 4509 IDCount = 1, IDS = 2 //select x2 4511 Results: 4512 If x1=10 was at entry 11: 4513 operation = GET-RESPONSE-TLV 4514 Path-data-TLV 4515 flag = 0, IDCount=5, IDS = 7.10.2.11 4516 Path-data TLV 4517 flags = 0 IDCount = 1, IDS = 2 4518 FULLDATA TLV: L=XXXX, V = {x2 value} 4520 18. Further example of manipulating a table of tables 4522 Consider table 6 which is defined as: 4523 table6: type array, ID = 8 4524 elements are: 4525 p1, type u32, ID = 1 4526 p2, type array, ID = 2, array elements of type type-A 4528 type-A: 4529 a1, type u32, ID 1, 4530 a2, type array ID2 ,array elements of type type-B 4532 type-B: 4533 b1, type u32, ID 1 4534 b2, type u32, ID 2 4536 If for example one wanted to set by replacing: 4537 table6.10.p1 to 111 4538 table6.10.p2.20.a1 to 222 4539 table6.10.p2.20.a2.30.b1 to 333 4541 in one message and one operation. 4543 There are two ways to do this: 4544 a) using nesting 4545 b) using a flat path data 4547 A. Method using nesting 4548 in one message with a single operation 4550 operation = SET-REPLACE-TLV 4551 Path-data-TLV 4552 flags = 0 IDCount = 2, IDs=6.10 4553 Path-data-TLV 4554 flags = 0, IDCount = 1, IDs=1 4555 FULLDATA TLV: L=XXXX, 4556 V = {111} 4557 Path-data-TLV 4558 flags = 0 IDCount = 2, IDs=2.20 4559 Path-data-TLV 4560 flags = 0, IDCount = 1, IDs=1 4561 FULLDATA TLV: L=XXXX, 4562 V = {222} 4563 Path-data TLV : 4564 flags = 0, IDCount = 3, IDs=2.30.1 4565 FULLDATA TLV: L=XXXX, 4566 V = {333} 4567 Result: 4568 operation = SET-RESPONSE-TLV 4569 Path-data-TLV 4570 flags = 0 IDCount = 2, IDs=6.10 4571 Path-data-TLV 4572 flags = 0, IDCount = 1, IDs=1 4573 RESULT-TLV 4574 Path-data-TLV 4575 flags = 0 IDCount = 2, IDs=2.20 4576 Path-data-TLV 4577 flags = 0, IDCount = 1, IDs=1 4578 RESULT-TLV 4579 Path-data TLV : 4580 flags = 0, IDCount = 3, IDs=2.30.1 4581 RESULT-TLV 4583 B. Method using a flat path data in 4584 one message with a single operation 4586 operation = SET-REPLACE-TLV 4587 Path-data TLV : 4588 flags = 0, IDCount = 3, IDs=6.10.1 4589 FULLDATA TLV: L=XXXX, 4590 V = {111} 4591 Path-data TLV : 4592 flags = 0, IDCount = 5, IDs=6.10.1.20.1 4593 FULLDATA TLV: L=XXXX, 4594 V = {222} 4595 Path-data TLV : 4596 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 4597 FULLDATA TLV: L=XXXX, 4598 V = {333} 4599 Result: 4600 operation = SET-REPLACE-TLV 4601 Path-data TLV : 4602 flags = 0, IDCount = 3, IDs=6.10.1 4603 RESULT-TLV 4604 Path-data TLV : 4605 flags = 0, IDCount = 5, IDs=6.10.1.20.1 4606 RESULT-TLV 4607 Path-data TLV : 4608 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 4609 RESULT-TLV 4611 19. Get a whole LFB (all its attributes, etc.). 4613 For example: at startup a CE might well want the entire FE 4614 OBJECT LFB. So, in a request targeted at class 1, instance 4615 1, one might find: 4617 operation = GET-TLV 4618 Path-data-TLV 4619 flags = 0 IDCount = 0 4621 result: 4622 operation = GET-RESPONSE-TLV 4623 Path-data-TLV 4624 flags = 0 IDCount = 0 4625 FULLDATA encoding of the FE Object LFB 4627 Authors' Addresses 4629 Ligang Dong 4630 Zhejiang Gongshang University 4631 149 Jiaogong Road 4632 Hangzhou 310035 4633 P.R.China 4635 Phone: +86-571-88071024 4636 Email: donglg@mail.zjgsu.edu.cn 4638 Avri Doria 4639 ETRI 4640 Lulea University of Technology 4641 Lulea 4642 Sweden 4644 Phone: +46 73 277 1788 4645 Email: avri@acm.org 4647 Ram Gopal 4648 Nokia 4649 5, Wayside Road 4650 Burlington, MA 310035 4651 USA 4653 Phone: +1-781-993-3685 4654 Email: ram.gopal@nokia.com 4656 Robert Haas 4657 IBM 4658 Saumerstrasse 4 4659 8803 Ruschlikon 4660 Switzerland 4662 Phone: 4663 Email: rha@zurich.ibm.com 4664 Jamal Hadi Salim 4665 Znyx 4666 Ottawa, Ontario 4667 Canada 4669 Phone: 4670 Email: hadi@znyx.com 4672 Hormuzd M Khosravi 4673 Intel 4674 2111 NE 25th Avenue 4675 Hillsboro, OR 97124 4676 USA 4678 Phone: +1 503 264 0334 4679 Email: hormuzd.m.khosravi@intel.com 4681 Weiming Wang 4682 Zhejiang Gongshang University 4683 149 Jiaogong Road 4684 Hangzhou 310035 4685 P.R.China 4687 Phone: +86-571-88057712 4688 Email: wmwang@mail.zjgsu.edu.cn 4690 Intellectual Property Statement 4692 The IETF takes no position regarding the validity or scope of any 4693 Intellectual Property Rights or other rights that might be claimed to 4694 pertain to the implementation or use of the technology described in 4695 this document or the extent to which any license under such rights 4696 might or might not be available; nor does it represent that it has 4697 made any independent effort to identify any such rights. Information 4698 on the procedures with respect to rights in RFC documents can be 4699 found in BCP 78 and BCP 79. 4701 Copies of IPR disclosures made to the IETF Secretariat and any 4702 assurances of licenses to be made available, or the result of an 4703 attempt made to obtain a general license or permission for the use of 4704 such proprietary rights by implementers or users of this 4705 specification can be obtained from the IETF on-line IPR repository at 4706 http://www.ietf.org/ipr. 4708 The IETF invites any interested party to bring to its attention any 4709 copyrights, patents or patent applications, or other proprietary 4710 rights that may cover technology that may be required to implement 4711 this standard. Please address the information to the IETF at 4712 ietf-ipr@ietf.org. 4714 Disclaimer of Validity 4716 This document and the information contained herein are provided on an 4717 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4718 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4719 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4720 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4721 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4722 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4724 Copyright Statement 4726 Copyright (C) The Internet Society (2006). This document is subject 4727 to the rights, licenses and restrictions contained in BCP 78, and 4728 except as set forth therein, the authors retain all their rights. 4730 Acknowledgment 4732 Funding for the RFC Editor function is currently provided by the 4733 Internet Society.