idnits 2.17.1 draft-ietf-forces-protocol-07.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 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4625. ** 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 == Line 3983 has weird spacing: '...j2value entri...' == 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 5, 2006) is 6617 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 == Unused Reference: 'RFC2629' is defined on line 3235, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FE-MODEL' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Downref: Normative reference to an Informational RFC: RFC 3654 ** Downref: Normative reference to an Informational RFC: RFC 3746 Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 8 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 6, 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 13 March 5, 2006 15 ForCES Protocol Specification 16 draft-ietf-forces-protocol-07.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 6, 2006. 43 Copyright Notice 45 Copyright (C) The Internet Society (2006). 47 Abstract 49 This document specifies the Forwarding and Control Element Separation 50 (ForCES) protocol. ForCES protocol is used for communications 51 between Control Elements(CEs) and Forwarding Elements (FEs) in a 52 ForCES Network Element (ForCES NE). This specification is intended 53 to meet the ForCES protocol requirements defined in RFC3654. Besides 54 the ForCES protocol messages, the specification also defines the 55 framework, the mechanisms, and the Transport Mapping Layer (TML) 56 requirements for ForCES protocol. 58 Authors 60 The participants in the ForCES Protocol Team, primary co-authors and 61 co-editors, of this protocol specification, are: 63 Ligang Dong (Zhejiang Gongshang University), Avri Doria (ETRI), Ram 64 Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M 65 Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). 67 Table of Contents 69 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 70 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 11 74 4.1.1. The PL layer . . . . . . . . . . . . . . . . . . . . 13 75 4.1.2. The TML layer . . . . . . . . . . . . . . . . . . . . 14 76 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 14 77 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 15 78 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 16 79 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18 80 4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 19 81 4.3.1. Transactions, Atomicity, Execution and Responses . . 19 82 4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 23 83 4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 23 84 4.3.4. FE Object and FE protocol LFBs . . . . . . . . . . . 24 85 5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 25 86 5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 26 87 6. Message encapsulation . . . . . . . . . . . . . . . . . . . . 27 88 6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 27 89 6.2. Type Length Value(TLV) Structuring . . . . . . . . . . . 32 90 6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 32 91 6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 32 92 6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 93 7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 34 94 7.1. Protocol Grammar . . . . . . . . . . . . . . . . . . . . 34 95 7.1.1. Protocol BNF . . . . . . . . . . . . . . . . . . . . 34 96 7.1.2. Protocol Visualization . . . . . . . . . . . . . . . 42 97 7.2. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 45 98 7.2.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 46 99 7.2.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 49 100 7.3. Semantics of message Direction . . . . . . . . . . . . . 49 101 7.4. Association Messages . . . . . . . . . . . . . . . . . . 49 102 7.4.1. Association Setup Message . . . . . . . . . . . . . . 49 103 7.4.2. Association Setup Response Message . . . . . . . . . 51 104 7.4.3. Association Teardown Message . . . . . . . . . . . . 52 105 7.5. Configuration Messages . . . . . . . . . . . . . . . . . 53 106 7.5.1. Config Message . . . . . . . . . . . . . . . . . . . 53 107 7.5.2. Config Response Message . . . . . . . . . . . . . . . 55 108 7.6. Query Messages . . . . . . . . . . . . . . . . . . . . . 56 109 7.6.1. Query Message . . . . . . . . . . . . . . . . . . . . 57 110 7.6.2. Query Response Message . . . . . . . . . . . . . . . 58 111 7.7. Event Notification Message . . . . . . . . . . . . . . . 59 112 7.8. Packet Redirect Message . . . . . . . . . . . . . . . . . 61 113 7.9. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 64 114 7.10. Operation Summary . . . . . . . . . . . . . . . . . . . . 65 116 8. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . 68 117 8.1. Association Setup state . . . . . . . . . . . . . . . . . 68 118 8.2. Association Established state or Steady State . . . . . . 69 119 9. High Availability Support . . . . . . . . . . . . . . . . . . 72 120 9.1. Responsibilities for HA . . . . . . . . . . . . . . . . . 74 121 10. Security Considerations . . . . . . . . . . . . . . . . . . . 76 122 10.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 76 123 10.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 76 124 10.1.2. Message authentication . . . . . . . . . . . . . . . 77 125 10.2. ForCES PL and TML security service . . . . . . . . . . . 77 126 10.2.1. Endpoint authentication service . . . . . . . . . . . 77 127 10.2.2. Message authentication service . . . . . . . . . . . 77 128 10.2.3. Confidentiality service . . . . . . . . . . . . . . . 78 129 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 131 12.1. Normative References . . . . . . . . . . . . . . . . . . 80 132 12.2. Informational References . . . . . . . . . . . . . . . . 80 133 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 81 134 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 81 135 A.2. Operation Type . . . . . . . . . . . . . . . . . . . . . 82 136 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 82 137 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 83 138 A.5. LFB Class Id Name Space . . . . . . . . . . . . . . . . . 83 139 A.6. Association Setup Response . . . . . . . . . . . . . . . 84 140 A.7. Association Teardown Message . . . . . . . . . . . . . . 84 141 A.8. Configuration Request Result . . . . . . . . . . . . . . 85 142 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 86 143 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 91 144 B.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 91 145 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 92 146 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 96 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 112 148 Intellectual Property and Copyright Statements . . . . . . . . . 114 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 0 = success 1651 1 = no such object 1653 2 = permission denied (e.g., trying to configure an attribute that 1654 is read- only) 1656 3 = invalid value (the encoded data could not validly be stored in 1657 the field) 1659 4 = invalid array creation (when the subscript in an array create is 1660 not allowed) 1662 255 = unspecified error (for when the FE can not decide what went 1663 wrong) 1665 others = Reserved 1667 7.1.1.1.8. DATA TLV 1669 A FULLDATA TLV has "T"= FULLDATA, and a 16bit Length followed by the 1670 data value/contents. Likewise, a SPARSEDATA TLV has "T" = 1671 SPARSEDATA, a 16bit Length followed by the data value/contents. In 1672 the case of the SPARSEDATA each element in the Value part of the TLV 1673 will be further encapsulated in an ILV. Rules: 1675 1. Both ILVs and TLVs MUST 32 bit aligned. Any padding bits used 1676 for the alignment MUST be zero on transmission and MUST be 1677 ignored upon reception. 1679 2. FULLDATA TLV may be used at a particular path only if every 1680 element at that path level is present. This requirement holds 1681 whether the fields are fixed or variable length, mandatory or 1682 optional. 1684 * If a FULLDATA TLV is used, the encoder MUST layout data for 1685 each element in the same order in which the data was defined 1686 in the LFB specification. This ensures the decoder is 1687 guaranteed to retrieve the data. 1689 * In the case of a SPARSEDATA, it does not need to be ordered 1690 since the "I" in the ILV uniquely identifies the element. 1692 3. Inside a FULLDATA TLV 1694 * The values for atomic, fixed-length fields are given without 1695 any TLV or ILV encapsulation. 1697 * The values for atomic, variable-length fields are given inside 1698 FULLDATA TLVs. 1700 4. Inside a SPARSE TLV 1702 * the values for atomic fields may be given with ILVs (32-bit 1703 index, 32-bit length) 1705 5. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot 1706 contain a FULLDATA. This is because it is hard to disambiguate 1707 ILV since an I is 32 bit and a T is 16 bit. 1709 6. A FULLDATA can also contain a FULLDATA for variable sized 1710 elements. The decoding disambiguation is assumed from rule #3 1711 above. 1713 7.1.1.1.9. SET and GET Relationship 1715 It is expected that a GET-RESPONSE would satisfy the following: 1717 o it would have exactly the same path definitions as those sent in 1718 the GET. The only difference being a GET-RESPONSE will contain 1719 FULLDATA TLVs. 1721 o it should be possible to take the same GET-RESPONSE and convert it 1722 to a SET-REPLACE successfully by merely changing the T in the 1723 operational TLV. 1725 o There are exceptions to this rule: 1727 1. When a KEY selector is used with a path in a GET operation, 1728 that selector is not returned in the GET-RESPONSE; instead the 1729 cooked result is returned. Refer to the examples using KEYS 1730 to see this. 1732 2. When dumping a whole table in a GET, the GET-RESPONSE that 1733 merely edits the T to be SET will end up overwriting the 1734 table. 1736 7.1.2. Protocol Visualization 1738 The figure below shows a general layout of the PL PDU. A main header 1739 is followed by one or more LFB selections each of which may contain 1740 one or more operation. 1742 main hdr (Config in this case) 1743 | 1744 | 1745 +--- T = LFBselect 1746 | | 1747 | +-- LFBCLASSID 1748 | | 1749 | | 1750 | +-- LFBInstance 1751 | | 1752 | +-- T = SET-CREATE 1753 | | | 1754 | | +-- // one or more path targets 1755 | | // with their data here to be added 1756 | | 1757 | +-- T = DEL 1758 | . | 1759 | . +-- // one or more path targets to be deleted 1760 | 1761 | 1762 +--- T = LFBselect 1763 | | 1764 | +-- LFBCLASSID 1765 | | 1766 | | 1767 | +-- LFBInstance 1768 | | 1769 | + -- T= SET-REPLACE 1770 | | 1771 | | 1772 | + -- T= DEL 1773 | | 1774 | + -- T= SET-REPLACE 1775 | 1776 | 1777 +--- T = LFBselect 1778 | 1779 +-- LFBCLASSID 1780 | 1781 +-- LFBInstance 1782 . 1783 . 1784 . 1786 Figure 16: PL PDU logical layout 1787 The figure below shows an example general layout of the operation 1788 within a targeted LFB selection. The idea is to show the different 1789 nesting levels a path could take to get to the target path. 1791 T = SET-CREATE 1792 | | 1793 | +- T = Path-data 1794 | | 1795 | + -- flags 1796 | + -- IDCount 1797 | + -- IDs 1798 | | 1799 | +- T = Path-data 1800 | | 1801 | + -- flags 1802 | + -- IDCount 1803 | + -- IDs 1804 | | 1805 | +- T = Path-data 1806 | | 1807 | + -- flags 1808 | + -- IDCount 1809 | + -- IDs 1810 | + -- T = KEYINFO 1811 | | + -- KEY_ID 1812 | | + -- KEY_DATA 1813 | | 1814 | + -- T = FULLDATA 1815 | + -- data 1816 | 1817 | 1818 T = SET-REPLACE 1819 | | 1820 | +- T = Path-data 1821 | | | 1822 | | + -- flags 1823 | | + -- IDCount 1824 | | + -- IDs 1825 | | | 1826 | | + -- T = FULLDATA 1827 | | + -- data 1828 | +- T = Path-data 1829 | | 1830 | + -- flags 1831 | + -- IDCount 1832 | + -- IDs 1833 | | 1834 | + -- T = FULLDATA 1835 | + -- data 1836 T = DEL 1837 | 1838 +- T = Path-data 1839 | 1840 + -- flags 1841 + -- IDCount 1842 + -- IDs 1843 | 1844 +- T = Path-data 1845 | 1846 + -- flags 1847 + -- IDCount 1848 + -- IDs 1849 | 1850 +- T = Path-data 1851 | 1852 + -- flags 1853 + -- IDCount 1854 + -- IDs 1855 + -- T = KEYINFO 1856 | + -- KEY_ID 1857 | + -- KEY_DATA 1858 +- T = Path-data 1859 | 1860 + -- flags 1861 + -- IDCount 1862 + -- IDs 1864 Figure 17: Sample operation layout 1866 7.2. Core ForCES LFBs 1868 There are two LFBs that are used to control the operation of the 1869 ForCES protocol and to interact with FEs and CEs: 1871 o FE Protocol LFB 1873 o FE Object LFB 1875 Although these LFBs have the same form and interface as other LFBs, 1876 they are special in many respects: they have fixed well-known LFB 1877 Class and Instance IDs. They are statically defined (no dynamic 1878 instantiation allowed) and their status cannot be changed by the 1879 protocol: any operation to change the state of such LFBs (for 1880 instance, in order to disable the LFB) must result in an error. 1881 Moreover, these LFBs must exist before the first ForCES message can 1882 be sent or received. All attributes in these LFBs must have pre- 1883 defined default values. Finally, these LFBs do not have input or 1884 output ports and do not integrate into the intra-FE LFB topology. 1886 7.2.1. FE Protocol LFB 1888 The FE Protocol LFB is a logical entity in each FE that is used to 1889 control the ForCES protocol. The FE Protocol LFB Class ID is 1890 assigned the value 0x1. The FE Protocol LFB Instance ID is assigned 1891 the value 0x1. There MUST be one and only one instance of the FE 1892 Protocol LFB in an FE. The values of the attributes in the FE 1893 Protocol LFB have pre-defined default values that are specified here. 1894 Unless explicit changes are made to these values using Config 1895 messages from the CE, these default values MUST be used for correct 1896 operation of the protocol. 1898 The formal definition of the FE Protocol LFB can be found in 1899 Appendix B. 1901 The FE Protocol LFB consists of the following elements: 1903 o FE Protocol capabilities (read-only): 1905 * Supported ForCES protocol version(s) by the FE 1907 * Any TML capability description(s) 1909 o FE Protocol attributes (can be read and set): 1911 * Current version of the ForCES protocol 1913 * FE unicast ID 1915 * FE multicast ID(s) list - this is a list of multicast IDs that 1916 the FE belongs to. These IDs are configured by the CE. 1918 * CE heartbeat policy - This policy, along with the parameter 'CE 1919 Heartbeat Dead Interval (CE HDI)' as described below defines 1920 the operating parameters for the FE to check the CE liveness. 1921 The policy values with meanings are listed as below: 1923 0 (default) - This policy specifies that the CE will send a 1924 Heartbeat Message to the FE(s) whenever the CE reaches a 1925 time interval within which no other PL messages were sent 1926 from the CE to the FE(s); refer to Section 4.3.3 for 1927 details. The CE HDI attribute as described below is tied to 1928 this policy. If the FE has not received any PL messages 1929 within a CE HDI period it declares the connectivity lost. 1930 The CE independently chooses the time interval for sending 1931 the Heartbeat messages to FE(s) - care must be exercised to 1932 ensure the CE->FE HB interval is smaller than the assigned 1933 CE HDI. 1935 CE HDI SHOULD be at least 3 times as long as the HB 1936 interval. Shorter rates MAY be appropriate in 1937 implementations working across a reliable internal 1938 interface. 1940 1 - The CE will not generate any HB messages. This actually 1941 means CE does not want the FE to check the CE liveness. 1943 Others - reserved. 1945 * CE Heartbeat Dead Interval (CE HDI) - The time interval the FE 1946 uses to check the CE liveness. If FE has not received any 1947 messages from CE within this time interval, FE deduces lost 1948 connectivity which implies that the CE is dead or the 1949 association to the CE is lost. Default value 30 s. 1951 * FE heartbeat policy - This policy, along with the parameter 'FE 1952 Heartbeat Interval (FE HI)', defines the operating parameters 1953 for how the FE should behave so that the CE can deduce its 1954 liveness. The policy values and the meanings are: 1956 0(default) - The FE should not generate any Heartbeat 1957 messages. In this scenario, the CE is responsible for 1958 checking FE liveness by setting the PL header ACK flag of 1959 the message it sends to AlwaysACK. The FE responds to CE 1960 whenever CE sends such Heartbeat Request Message. Refer to 1961 Section 7.9 and Section 4.3.3 for details. 1963 1 - This policy specifies that FE must actively send a 1964 Heartbeat Message if it reaches the time interval assigned 1965 by the FE HI as long as no other messages were sent from FE 1966 to CE during that interval as described in Section 4.3.3. 1968 Others - Reserved. 1970 * FE Heartbeat Interval (FE HI) - The time interval the FE should 1971 use to send HB as long as no other messages were sent from FE 1972 to CE during that interval as described in Section 4.3.3. The 1973 default value for an FE HI is 500ms. 1975 * Primary CEID - The CEID that the FE is associated with. 1977 * Backup CEs - The list of backup CEs an FE is associated with. 1978 Refer to Section 9 for details. 1980 * FE restart policy - This specifies the behavior of the FE 1981 during an FE restart. The restart may be from an FE failure or 1982 other reasons that have made FE down and then need to restart. 1983 The values are defined as below: 1985 0(default)- just restart the FE from scratch. In this case, 1986 the FE should start from the pre-association phase. 1988 1 - restart the FE from an intermediate state. In this 1989 case, the FE decides from which state it restarts. For 1990 example, if the FE is able to retain enough information of 1991 pre-association phase after some failure, it then has the 1992 ability to start from the post-association phase in this 1993 case. 1995 Others - Reserved 1997 * CE failover policy - This specifies the behavior of the FE 1998 during a CE failure and restart time interval, or when the FE 1999 loses the CE association. It should be noted that this policy 2000 in the case of HA only takes effect after total failure to 2001 connect to a new CE. A timeout parameter, the CE Timeout 2002 Interval (CE TI) is associated with this attribute. Values of 2003 this policy are defined as below: 2005 0(default) - The FE should continue running and do what it 2006 can even without an associated CE. This basically requires 2007 that the FE support CE Graceful restart. Note that if the 2008 CE still has not been restarted or hasn't been associated 2009 back to the FE, after the CE TI has expired, the FE will go 2010 operationally down. 2012 1 - FE should go down to stop functioning immediately. 2014 2 - FE should go inactive to temporarily stop functioning. 2015 If the CE still has not been restarted after a time interval 2016 of specified by the CE TI, the FE will go down completely. 2018 Others - Reserved 2020 * CE Timeout Interval (CE TI) - The time interval associated with 2021 the CE failover policy case '0' and '2'. The default value is 2022 set to 300 seconds. Note that it is advisable to set the CE TI 2023 value much higher than the CE Heartbeat Dead Interval (CE HDI) 2024 since the effect of expiring this parameter is devastating to 2025 the operation of the FE. 2027 7.2.2. FE Object LFB 2029 The FE Object LFB is a logical entity in each FE and contains 2030 attributes relative to the FE itself, and not to the operation of the 2031 ForCES protocol. 2033 The formal definition of the FE Object LFB can be found in [FE- 2034 MODEL]. The model captures the high level properties of the FE that 2035 the CE needs to know to begin working with the FE. The class ID for 2036 this LFB Class is also assigned in [FE-MODEL]. The singular instance 2037 of this class will always exist, and will always have instance ID 1 2038 within its class. It is common, although not mandatory, for a CE to 2039 fetch much of the attribute and capability information from this LFB 2040 instance when the CE begins controlling the operation of the FE. 2042 7.3. Semantics of message Direction 2044 Recall: The PL protocol provides a master(CE)-Slave(FE) relationship. 2045 The LFBs reside at the FE and are controlled by CE. 2047 When messages go from the CE, the LFB Selector (Class and instance) 2048 refers to the destination LFB selection which resides in the FE. 2050 When messages go from the FE->CE, the LFB Selector (Class and 2051 instance) refers to the source LFB selection which resides in the FE. 2053 7.4. Association Messages 2055 The ForCES Association messages are used to establish and teardown 2056 associations between FEs and CEs. 2058 7.4.1. Association Setup Message 2060 This message is sent by the FE to the CE to setup a ForCES 2061 association between them. 2063 Message transfer direction: 2064 FE to CE 2066 Message Header: 2067 The Message Type in the header is set MessageType= 2068 'AssociationSetup'. The ACK flag in the header MUST be ignored, 2069 and the association setup message always expects to get a response 2070 from the message receiver (CE) whether the setup is successful or 2071 not. The Correlator field in the header is set, so that FE can 2072 correlate the response coming back from CE correctly. The Src ID 2073 (FE ID) may be set to O in the header which means that the FE 2074 would like the CE to assign an FE ID for the FE in the setup 2075 response message. 2077 Message body: 2078 The association setup message body optionally consists of one or 2079 more LFB select TLV as described in Section 7.1.1.1.5. The 2080 association setup message only operates toward the FE Object and 2081 FE Protocol LFBs, therefore, the LFB class ID in the LFB select 2082 TLV only points to these two kinds of LFBs. 2084 The Operation TLV in the LFB select TLV is defined as a 'REPORT' 2085 operation. More than one attribute may be announced in this 2086 message using REPORT operation to let the FE declare its 2087 configuration parameters in an unsolicited manner. These may 2088 contain attributes like the Heart Beat Interval parameter, etc. 2089 The Operation TLV for event notification is is defined below. 2091 Operation TLV for Association Setup: 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | Type = REPORT | Length | 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | PATH-DATA-TLV for REPORT | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 Figure 18: Operation TLV 2101 Type: 2102 Only one operation type is defined for the association setup 2103 message: 2105 Type = "REPORT" --- this type of operation is for FE to 2106 report something to CE. 2108 PATH-DATA-TLV for REPORT: 2109 This is generically a PATH-DATA-TLV format that has been defined 2110 in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF 2111 definition. The PATH-DATA-TLV for REPORT operation MAY contain 2112 FULLDATA-TLV(s) but SHALL NOT contain any RESULT-TLV in the data 2113 format. The RESULT-TLV is defined in Section 7.1.1.1.7 and the 2114 FULLDATA-TLV is defined in Section 7.1.1.1.8. 2116 To better illustrate the above PDU format, a tree structure for the 2117 format is shown below: 2119 main hdr (eg type = Association setup) 2120 | 2121 | 2122 +--- T = LFBselect 2123 | | 2124 | +-- LFBCLASSID = FE object 2125 | | 2126 | | 2127 | +-- LFBInstance = 0x1 2128 | | 2129 +--- T = LFBselect 2130 | 2131 +-- LFBCLASSID = FE Protocol object 2132 | 2133 | 2134 +-- LFBInstance = 0x1 2135 | 2136 +-- Path-data to one or more attributes 2137 including suggested HB parameters 2139 Figure 19: PDU Format 2141 7.4.2. Association Setup Response Message 2143 This message is sent by the CE to the FE in response to the Setup 2144 message. It indicates to the FE whether the setup is successful or 2145 not, i.e. whether an association is established. 2147 Message transfer direction: 2148 CE to FE 2150 Message Header: 2151 The Message Type in the header is set MessageType= 2152 'AssociationSetupResponse'. The ACK flag in the header MUST be 2153 ignored, and the setup response message never expects to get any 2154 more responses from the message receiver (FE). The Correlator 2155 field in the header MUST be the same as that of the corresponding 2156 association setup message, so that the association setup message 2157 sender can correlate the response correctly. The Dst ID in the 2158 header will be set to some FE ID value assigned by the CE if the 2159 FE had requested that in the setup message (by SrcID = 0). 2161 Message body: 2162 The association setup response message body only consists of one 2163 TLV, the Association Result TLV, the format of which is as 2164 follows: 2166 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 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | Type = ASRresult | Length | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | Association Setup Result | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 Figure 20: Message Body 2175 Type (16 bits): 2176 The type of the TLV is "ASRresult". 2178 Length (16 bits): 2179 Length of the TLV including the T and L fields, in octets. 2181 Association Setup Result (32 bits): 2182 This indicates whether the setup msg was successful or whether 2183 the FE request was rejected by the CE. the defined values are: 2185 0 = success 2187 1 = FE ID invalid 2189 2 = too many associations 2191 3 = permission denied 2193 7.4.3. Association Teardown Message 2195 This message can be sent by the FE or CE to any ForCES element to end 2196 its ForCES association with that element. 2198 Message transfer direction: 2199 CE to FE, or FE to CE (or CE to CE) 2201 Message Header: 2202 The Message Type in the header is set MessageType= 2203 "AssociationTeardown". The ACK flag MUST be ignored The 2204 correlator field in the header MUST be set to zero and MUST be 2205 ignored by the receiver. 2207 Message Body: 2208 The association teardown message body only consists of one TLV, 2209 the Association Teardown Reason 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 = ASTreason | Length | 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 | Teardown Reason | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 Figure 21: ASTreason TLV 2221 Type (16 bits): 2222 The type of the TLV is "ASTreason". 2224 Length (16 bits): 2225 Length of the TLV including the T and L fields, in octets. 2227 Teardown Reason (32 bits): 2228 This indicates the reason why the association is being 2229 terminated. Several reason codes are defined as follows. 2231 0 - normal teardown by administrator 2233 1 - error - loss of heartbeats 2235 2 - error - out of bandwidth 2237 3 - error - out of memory 2239 4 - error - application crash 2241 255 - error - other or unspecified 2243 7.5. Configuration Messages 2245 The ForCES Configuration messages are used by CE to configure the FEs 2246 in a ForCES NE and report the results back to the CE. 2248 7.5.1. Config Message 2250 This message is sent by the CE to the FE to configure LFB attributes 2251 in the FE. This message is also used by the CE to subscribe/ 2252 unsubscribe to LFB events. 2254 As usual, a config message is composed of a common header followed by 2255 a message body that consists of one or more TLV data format. 2256 Detailed description of the message is as below. 2258 Message transfer direction: 2259 CE to FE 2261 Message Header: 2262 The Message Type in the header is set MessageType= 'Config'. The 2263 ACK flag in the header can be set to any value defined in 2264 Section 6.1, to indicate whether or not a response from FE is 2265 expected by the message ( the flag is set to 'NoACK' or 2266 'AlwaysACK'), or to indicate under which conditions a response is 2267 generated (the flag is set to 'SuccessACK' or 'FailureACK'). The 2268 default behavior for the ACK flag is set to always expect a full 2269 response from FE. This happens when the ACK flag is not set to 2270 any defined value. The correlator field in the message header 2271 MUST be set if a response is expected, so that CE can correlate 2272 the response correctly. The correlator field can be ignored if 2273 no response is expected. 2275 Message body: 2276 The config message body MUST consist of at least one LFB select 2277 TLV as described in Section 7.1.1.1.5. The Operation TLV in the 2278 LFB select TLV is defined below. 2280 Operation TLV for Config: 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | Type | Length | 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2285 | PATH-DATA-TLV | 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 Figure 22: Operation TLV for Config 2290 Type: 2291 The operation type for config message. two types of operations 2292 for the config message are defined: 2294 Type = "SET" --- this operation is to set LFB attributes 2296 Type = "DEL" --- this operation to delete some LFB 2297 attributes 2299 PATH-DATA-TLV: 2300 This is generically a PATH-DATA-TLV format that has been defined 2301 in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF 2302 definition. The restriction on the use of PATH-DATA-TLV for SET 2303 operation is, it MUST contain either a FULLDATA or SPARSEDATA 2304 TLV(s), but MUST NOT contain any RESULT-TLV. The restriction on 2305 the use of PATH-DATA-TLV for DEL operation is it MAY contain 2306 FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain any RESULT- 2307 TLV. The RESULT-TLV is defined in Section 7.1.1.1.7 and FULLDATA 2308 and SPARSEDATA TLVs is defined in Section 7.1.1.1.8. 2310 *Note: For Event subscription, the events will be defined by the 2311 individual LFBs. 2313 To better illustrate the above PDU format, a tree structure for the 2314 format is shown below: 2316 main hdr (eg type = config) 2317 | 2318 | 2319 +--- T = LFBselect 2320 | | 2321 | +-- LFBCLASSID = target LFB class 2322 | | 2323 | | 2324 | +-- LFBInstance = target LFB instance 2325 | | 2326 | | 2327 | +-- T = operation { SET } 2328 | | | 2329 | | +-- // one or more path targets 2330 | | // associated with FULL or SPARSEDATA TLV(s) 2331 | | 2332 | +-- T = operation { DEL } 2333 | | | 2334 | | +-- // one or more path targets 2336 Figure 23: PDU Format 2338 7.5.2. Config Response Message 2340 This message is sent by the FE to the CE in response to the Config 2341 message. It indicates whether the Config was successful or not on 2342 the FE and also gives a detailed response regarding the configuration 2343 result of each attribute. 2345 Message transfer direction: 2346 FE to CE 2348 Message Header: 2349 The Message Type in the header is set MessageType= 'Config 2350 Response'. The ACK flag in the header is always ignored, and the 2351 config response message never expects to get any further response 2352 from the message receiver (CE). The Correlator field in the 2353 header MUST keep the same as that of the config message to be 2354 responded, so that the config message sender can correlate the 2355 response with the original message correctly. 2357 Message body: 2358 The config message body MUST consist of at least one LFB select 2359 TLV as described in Section 7.1.1.1.5. The Operation TLV in the 2360 LFB select TLV is defined below. 2362 Operation TLV for Config Response: 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 | Type | Length | 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2367 | PATH-DATA-TLV | 2368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 Figure 24: Operation TLV for Config Response 2372 Type: 2373 The operation type for config response message. Two types of 2374 operations for the config response message are defined: 2376 Type = "SET-RESPONSE" --- this operation is for the 2377 response of SET operation of LFB attributes 2379 Type = "DEL-RESPONSE" --- this operation is for the 2380 response of the DELETE operation of LFB attributes 2382 PATH-DATA-TLV: 2383 This is generically a PATH-DATA-TLV format that has been defined 2384 in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF 2385 definition. The restriction on the use of PATH-DATA-TLV for SET- 2386 RESPONSE operation is it MUST contain RESULT-TLV(s). The 2387 restriction on the use of PATH-DATA-TLV for DEL-RESPONSE 2388 operation is it also MUST contain RESULT-TLV(s). The RESULT-TLV 2389 is defined in Section 7.1.1.1.7. 2391 7.6. Query Messages 2393 The ForCES query messages are used by the CE to query LFBs in the FE 2394 for informations like LFB attributes, capabilities, statistics, etc. 2395 Query Messages include the Query Message and the Query Response 2396 Message. 2398 7.6.1. Query Message 2400 A query message is composed of a common header and a message body 2401 that consists of one or more TLV data format. Detailed description 2402 of the message is as below. 2404 Message transfer direction: 2405 from CE to FE. 2407 Message Header: 2408 The Message Type in the header is set to MessageType= 'Query'. 2409 The ACK flag in the header is always ignored, and a full response 2410 for a query message is always expected. The Correlator field in 2411 the header is set, so that CE can locate the response back from 2412 FE correctly. 2414 Message body: 2415 The query message body MUST consist of at least one LFB select 2416 TLV as described in Section 7.1.1.1.5. The Operation TLV in the 2417 LFB select TLV is defined below. 2419 Operation TLV for Query: 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | Type = GET | Length | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | PATH-DATA-TLV for GET | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2427 Figure 25: TLV for Query 2429 Type: 2430 The operation type for query. One operation type is defined: 2432 Type = "GET" --- this operation is to request to get LFB 2433 attributes. 2435 PATH-DATA-TLV for GET: 2436 This is generically a PATH-DATA-TLV format that has been defined 2437 in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF 2438 definition. The restriction on the use of PATH-DATA-TLV for GET 2439 operation is it MUST NOT contain any SPARSEDATA or FULLDATA TLV 2440 and RESULT-TLV in the data format. 2442 To better illustrate the above PDU format, a tree structure for the 2443 format is shown below: 2445 main hdr (type = Query) 2446 | 2447 | 2448 +--- T = LFBselect 2449 | | 2450 | +-- LFBCLASSID = target LFB class 2451 | | 2452 | | 2453 | +-- LFBInstance = target LFB instance 2454 | | 2455 | | 2456 | +-- T = operation { GET } 2457 | | | 2458 | | +-- // one or more path targets 2459 | | 2460 | +-- T = operation { GET } 2461 | | | 2462 | | +-- // one or more path targets 2463 | | 2465 Figure 26: PDU Format 2467 7.6.2. Query Response Message 2469 When receiving a query message, the receiver should process the 2470 message and come up with a query result. The receiver sends the 2471 query result back to the message sender by use of the Query Response 2472 Message. The query result can be the information being queried if 2473 the query operation is successful, or can also be error codes if the 2474 query operation fails, indicating the reasons for the failure. 2476 A query response message is also composed of a common header and a 2477 message body consists of one or more TLVs describing the query 2478 result. Detailed description of the message is as below. 2480 Message transfer direction: 2481 from FE to CE. 2483 Message Header: 2484 The Message Type in the header is set to MessageType= 2485 'QueryResponse'. The ACK flag in the header is ignored. As a 2486 response itself, the message does not expect a further response 2487 anymore. The Correlator field in the header MUST be the same as 2488 that of the associated query, so that the query message sender 2489 can keep track of the response. 2491 Message body: 2492 The query response message body MUST consist of at least one LFB 2493 select TLV as described in Section 7.1.1.1.5. The Operation TLV 2494 in the LFB select TLV is defined below. 2496 Operation TLV for Query Response: 2498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 | Type = GET-RESPONSE | Length | 2500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2501 | PATH-DATA-TLV for GET-RESPONSE | 2502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2504 Figure 27: TLV for Query Response 2506 Type: 2507 The operation type for query response. One operation type is 2508 defined: 2510 Type = "GET-RESPONSE" --- this operation is to response to 2511 get operation of LFB attributes. 2513 PATH-DATA-TLV for GET-RESPONSE: 2514 This is generically a PATH-DATA-TLV format that has been defined 2515 in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF 2516 definition. The PATH-DATA-TLV for GET-RESPONSE operation MAY 2517 contain SPARSEDATA TLV, FULLDATA TLV and/or RESULT-TLV(s) in the 2518 data encoding. The RESULT-TLV is defined in Section 7.1.1.1.7 2519 and the SPARSEDATA and FULLDATA TLVs are defined in 2520 Section 7.1.1.1.8. 2522 7.7. Event Notification Message 2524 Event Notification Message is used by FE to asynchronously notify CE 2525 of events that happen in the FE. 2527 All events that can be generated in an FE are subscribable by CE. A 2528 config message is used by CE to subscribe/unsubscribe for an event in 2529 FE. To subscribe to an event is usually by specifying to the path of 2530 such an event as described by FE-Model and defined by LFB library. 2532 As usual, an Event Notification Message is composed of a common 2533 header and a message body that consists of one or more TLV data 2534 format. Detailed description of the message is as below. 2536 Message Transfer Direction: 2537 FE to CE 2539 Message Header: 2540 The Message Type in the message header is set to 2541 MessageType = 'EventNotification'. The ACK flag in the header 2542 MUST be ignored by the CE, and the event notification message does 2543 not expect any response from the receiver. The Correlator field 2544 in the header is also ignored because the response is not 2545 expected. 2547 Message Body: 2548 The event notification message body MUST consist of at least one 2549 LFB select TLV as described in Section 7.1.1.1.5. The Operation 2550 TLV in the LFB select TLV is defined below. 2552 Operation TLV for Event Notification: 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2555 | Type = REPORT | Length | 2556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 | PATH-DATA-TLV for REPORT | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 Figure 28: TLV for Event Notification 2562 Type: 2563 Only one operation type is defined for the event notification 2564 message: 2566 Type = "REPORT" --- this type of operation is for FE to 2567 report something to CE. 2569 PATH-DATA-TLV for REPORT: 2570 This is generically a PATH-DATA-TLV format that has been defined 2571 in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF 2572 definition. The PATH-DATA-TLV for REPORT operation MAY contain 2573 FULLDATA or SPARSEDATA TLV(s) but MUST NOT contain any RESULT-TLV 2574 in the data format. 2576 To better illustrate the above PDU format, a tree structure for the 2577 format is shown below: 2579 main hdr (type = Event Notification) 2580 | 2581 | 2582 +--- T = LFBselect 2583 | | 2584 | +-- LFBCLASSID = target LFB class 2585 | | 2586 | | 2587 | +-- LFBInstance = target LFB instance 2588 | | 2589 | | 2590 | +-- T = operation { REPORT } 2591 | | | 2592 | | +-- // one or more path targets 2593 | | // associated with FULL/SPARSE DATA TLV(s) 2594 | +-- T = operation { REPORT } 2595 | | | 2596 | | +-- // one or more path targets 2597 | | // associated with FULL/SPARSE DATA TLV(s) 2599 Figure 29: PDU Format 2601 7.8. Packet Redirect Message 2603 Packet redirect message is used to transfer data packets between CE 2604 and FE. Usually these data packets are IP packets, though they may 2605 sometimes be associated with some metadata generated by other LFBs in 2606 the model. They may also occasionally be other protocol packets, 2607 which usually happens when CE and FE are jointly implementing some 2608 high-touch operations. Packets redirected from FE to CE are the data 2609 packets that come from forwarding plane, and usually are the data 2610 packets that need high-touch operations in CE,or packets for which 2611 the IP destination address is the NE. Packets redirected from CE to 2612 FE are the data packets that come from the CE and that the CE decides 2613 to put into forwarding plane, i.e. an FE. 2615 Supplying such a redirect path between CE and FE actually leads to a 2616 possibility of this path being DoS attacked. Attackers may 2617 maliciously try to send huge spurious packets that will be redirected 2618 by FE to CE, resulting in the redirect path becoming congested. 2619 ForCES protocol and the TML layer will jointly supply approaches to 2620 prevent such DoS attack. To define a specific 'Packet Redirect 2621 Message' makes TML and CE able to distinguish the redirect messages 2622 from other ForCES protocol messages. 2624 By properly configuring related LFBs in FE, a packet can also be 2625 mirrored to CE instead of purely redirected to CE, i.e., the packet 2626 is duplicated and one is redirected to CE and the other continues its 2627 way in the LFB topology. 2629 The Packet Redirect Message data format is formated as follows: 2631 Message Direction: 2632 CE to FE or FE to CE 2634 Message Header: 2635 The Message Type in the header is set to MessageType= 2636 'PacketRedirect'. The ACK flags in the header MUST be ignored, 2637 and no response is expected by this message. The correlator field 2638 is also ignored because no response is expected. 2640 Message Body: 2641 Consists of (at least) one or more than one TLV that describes 2642 packet redirection. The TLV is specifically a Redirect TLV (with 2643 the TLV Type="Redirect"). Detailed data format of a Redirect TLV 2644 for packet redirect message is as below: 2646 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 2647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2648 | Type = Redirect | Length | 2649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 | LFB Class ID | 2651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2652 | LFB Instance ID | 2653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2654 | Meta Data TLV | 2655 . . 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 | Redirect Data TLV | 2658 . . 2659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 Figure 30: Redirect_Data TLV 2663 LFB class ID: 2664 There are only two possible LFB classes here, the 'RedirectSink' 2665 LFB or the 'RedirectSource' LFB[FE-MODEL]. If the message is from 2666 FE to CE, the LFB class should be 'RedirectSink'. If the message 2667 is from CE to FE, the LFB class should be 'RedirectSource'. 2669 Instance ID: 2670 Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. 2672 Meta Data TLV: 2673 This is a TLV that specifies meta-data associated with followed 2674 redirected data. The TLV is as follows: 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 | Type = META-DATA | Length | 2678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2679 | Meta Data ILV | 2680 . . 2681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 ~ ... ~ 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 | Meta Data ILV | 2685 . . 2686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2688 Figure 31: Redirected_Data TLV 2690 Meta Data ILV: 2691 This is an Identifier-Length-Value format that is used to describe 2692 one meta data. The ILV has the format as: 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 | Meta Data ID | 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | Length | 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 | Meta Data Value | 2700 . . 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 Figure 32: Meta Data ILV 2705 Where, Meta Data ID is an identifier for the meta data, which is 2706 statically assigned by the LFB definition. This actually implies 2707 a Meta Data ID transcoding mechanism may be necessary if a 2708 metadata traverses several LFBs while these LFBs define the 2709 metadata with different Meta Data IDs. 2711 Usually there are two meta data that are necessary for CE-FE 2712 redirect operation. One is the redirected data type (e.g., IP 2713 packet, TCP packet, or UDP Packet). For an FE->CE redirect 2714 operation, redirected packet type meta data is usually a meta data 2715 specified by a Classifier LFB that filter out redirected packets 2716 from packet stream and sends the packets to Redirect Sink LFB. 2717 For an CE->FE redirect operation, the redirected packet type meta 2718 data is usually directly generated by CE. 2720 Another meta data that should be associated with redirected data 2721 is the port number in a redirect LFB. For a RedirectSink LFB, the 2722 port number meta data tells CE from which port in the lFB the 2723 redirected data come. For a RedirectSource LFB, via the meta 2724 data, CE tells FE which port in the LFB the redirected data should 2725 go out. 2727 Redirect Data TLV 2728 This is a TLV describing one packet of data to be directed via the 2729 redirect operation. The TLV format is as follows: 2731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 | Type = REDIRECTDATA | Length | 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 | Redirected Data | 2735 . . 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 Figure 33: Redirect Data TLV 2740 Redirected Data: 2741 This field presents the whole packet that is to be redirected. 2742 The packet should be 32bits aligned. 2744 7.9. Heartbeat Message 2746 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 2747 to asynchronously notify one or more other ForCES elements in the 2748 same ForCES NE on its liveness. 2750 A Heartbeat Message is sent by a ForCES element periodically. The 2751 parameterization and policy definition for heartbeats for an FE is 2752 managed as attributes of the FE protocol LFB, and can be set by CE 2753 via a config message. The Heartbeat message is a little different 2754 from other protocol messages in that it is only composed of a common 2755 header, with the message body left empty. Detailed description of 2756 the message is as below. 2758 Message Transfer Direction: 2759 FE to CE, or CE to FE 2761 Message Header: 2762 The Message Type in the message header is set to MessageType = 2763 'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. 2764 The ACK flag in the header MUST be set to either 'NoACK' or 2765 'AlwaysACK' when the HB is sent. 2767 * When set to 'NoACK', the HB is not soliciting for a response. 2769 * When set to 'AlwaysACK', the HB Message sender is always 2770 expecting a response from its receiver. According the HB 2771 policies defined in Section 7.2.1, only the CE can send such 2772 a HB message to query FE liveness. For simplicity and 2773 because of the minimal nature of the HB message, the response 2774 to a HB message is another HB message, i.e. no specific HB 2775 response message is defined. Whenever an FE receives a HB 2776 message marked with 'AlwaysACK' from the CE, the FE MUST send 2777 a HB message back immediately. The HB message sent by the FE 2778 in response to the 'AlwasyACK' MUST modify the source and 2779 destination IDs so that the ID of the FE is the source ID and 2780 the CEID of the sender is the destination ID, and MUST change 2781 the ACK information to 'NoACK'. A CE MUST NOT respond to an 2782 HB message with 'AlwasyACK' set. 2784 The correlator field in the HB message header SHOULD be set 2785 accordingly when a response is expected so that a receiver can 2786 correlate the response correctly. The correlator field MAY be 2787 ignored if no response is expected. 2789 Message Body: 2790 The message body is empty for the Heartbeat Message. 2792 7.10. Operation Summary 2794 The following table summarizes the TLVs that compose messages, and 2795 the applicabiity of operation TLVs to the messages. 2797 +---------------------------+-----------+---------------------------+ 2798 | Messages | TLVs | Operations | 2799 +---------------------------+-----------+---------------------------+ 2800 | Association Setup | LFBselect | REPORT | 2801 | | | | 2802 | Association Setup | ASRresult | None | 2803 | Response | | | 2804 | | | | 2805 | Association Teardown | ASTreason | None | 2806 | | | | 2807 | Config | LFBselect | SET, DEL | 2808 | | | | 2809 | Config Response | LFBselect | SET-RESPONSE, | 2810 | | | DEL-RESPONSE | 2811 | | | | 2812 | Query | LFBselect | GET | 2813 | | | | 2814 | Query Response | LFBselect | GET-RESPONSE | 2815 | | | | 2816 | Event Notification | LFBselect | REPORT | 2817 | | | | 2818 | Packet Redirect | Redirect | None | 2819 | | | | 2820 | Heartbeat | None | None | 2821 +---------------------------+-----------+---------------------------+ 2823 The following table summarises the applicability of the FULL/SPARSE 2824 DATA TLV and the RESULT TLV to the Operation TLVs. 2826 +--------------+--------------+----------------+------------+ 2827 | Operations | FULLDATA TLV | SPARSEDATA TLV | RESULT TLV | 2828 +--------------+--------------+----------------+------------+ 2829 | SET | MAY | MAY | MUST NOT | 2830 | | | | | 2831 | SET-RESPONSE | MAY | MUST NOT | MUST | 2832 | | | | | 2833 | DEL | MAY | MAY | MUST NOT | 2834 | | | | | 2835 | DEL-RESPONSE | MAY | MUST NOT | MUST | 2836 | | | | | 2837 | GET | MUST NOT | MUST NOT | MUST NOT | 2838 | | | | | 2839 | GET-RESPONSE | MUST | MUST NOT | MAY | 2840 | | | | | 2841 | REPORT | MAY | MUST NOT | MUST NOT | 2842 +--------------+--------------+----------------+------------+ 2844 8. Protocol Scenarios 2846 8.1. Association Setup state 2848 The associations among CEs and FEs are initiated via Association 2849 setup message from the FE. If a setup request is granted by the CE, 2850 a successful setup response message is sent to the FE. If CEs and 2851 FEs are operating in an insecure environment then the security 2852 associations have to be established between them before any 2853 association messages can be exchanged. The TML will take care of 2854 establishing any security associations. 2856 This is typically followed by capability query, topology query, etc. 2857 When the FE is ready to start forwarding data traffic, it sends an FE 2858 UP Event message to the CE. When the CE is ready, it repsonds by 2859 enabling the FE by setting the FEStatus to Adminup [Refer to [FE- 2860 MODEL] for details]. This indicates to the FE to start forwarding 2861 data traffic. At this point the association establishment is 2862 complete. These sequences of messages are illustrated in the Figure 2863 below. 2865 FE PL CE PL 2867 | | 2868 | Asso Setup Req | 2869 |---------------------->| 2870 | | 2871 | Asso Setup Resp | 2872 |<----------------------| 2873 | | 2874 | LFBx Query capability | 2875 |<----------------------| 2876 | | 2877 | LFBx Query Resp | 2878 |---------------------->| 2879 | | 2880 | FEO Query (Topology) | 2881 |<----------------------| 2882 | | 2883 | FEO Query Resp | 2884 |---------------------->| 2885 | | 2886 | Config FEO Adminup | 2887 |<----------------------| 2888 | | 2889 | FEO Config-Resp | 2890 |---------------------->| 2891 | | 2892 | FEO UP Event | 2893 |---------------------->| 2894 | | 2896 Figure 34: Message exchange between CE and FE to establish an NE 2897 association 2899 On successful completion of this state, the FE joins the NE. 2901 8.2. Association Established state or Steady State 2903 In this state the FE is continously updated or queried. The FE may 2904 also send asynchronous event notifications to the CE or synchronous 2905 heartbeat messages. This continues until a termination (or 2906 deactivation) is initiated by either the CE or FE. The figure below 2907 helps illustrate this state. 2909 FE PL CE PL 2911 | | 2912 | Heart Beat | 2913 |<---------------------------->| 2914 | | 2915 | Heart Beat | 2916 |----------------------------->| 2917 | | 2918 | Config-set LFBy (Event sub.) | 2919 |<-----------------------------| 2920 | | 2921 | Config Resp LFBy | 2922 |----------------------------->| 2923 | | 2924 | Config-set LFBx Attr | 2925 |<-----------------------------| 2926 | | 2927 | Config Resp LFBx | 2928 |----------------------------->| 2929 | | 2930 |Config-Query LFBz (Stats) | 2931 |<--------------------------- -| 2932 | | 2933 | Query Resp LFBz | 2934 |----------------------------->| 2935 | | 2936 | FE Event Report | 2937 |----------------------------->| 2938 | | 2939 | Config-Del LFBx Attr | 2940 |<-----------------------------| 2941 | | 2942 | Config Resp LFBx | 2943 |----------------------------->| 2944 | | 2945 | Packet Redirect LFBx | 2946 |----------------------------->| 2947 | | 2948 | Heart Beat | 2949 |<-----------------------------| 2950 . . 2951 . . 2952 | | 2954 Figure 35: Message exchange between CE and FE during steady-state 2955 communication 2956 Note that the sequence of messages shown in the figure serve only as 2957 examples and the messages exchange sequences could be different from 2958 what is shown in the figure. Also, note that the protocol scenarios 2959 described in this section do not include all the different message 2960 exchanges which would take place during failover. That is described 2961 in the HA section 8. 2963 9. High Availability Support 2965 The ForCES protocol provides mechanisms for CE redundancy and 2966 failover, in order to support High Availability as defined in 2967 [RFC3654]. FE redundancy and FE to FE interaction is currently out 2968 of scope of this draft. There can be multiple redundant CEs and FEs 2969 in a ForCES NE. However, at any one time only one Primary CE can 2970 control the FEs though there can be multiple secondary CEs. The FE 2971 and the CE PL are aware of the primary and secondary CEs. This 2972 information (primary, secondary CEs) is configured in the FE and in 2973 the CE PLs during pre-association by the FEM and the CEM 2974 respectively. Only the primary CE sends Control messages to the FEs. 2976 Two HA modes are defined in the ForCES protocol, Report Primary Mode 2977 and Report All Mode. The Report Primary Mode is the default mode of 2978 the protocol, in which the FEs only associate with one CE (primary) 2979 at a time. The Report All mode is for future study and not part of 2980 the current protocol version. In this mode, the FE would establish 2981 association with multiple CEs (primary and secondary) and report 2982 events, packets, Heart Beats to all the CEs. However, only the 2983 primary CE would configure/control the FE in this mode as well. This 2984 would help with keeping state between CEs synchronized, although it 2985 would not guarantee synchronization. 2987 The HA Modes are configured during Association setup phase, though 2988 currently only Report Primary Mode can be configured. A CE-to-CE 2989 synchronization protocol would be needed to support fast failover as 2990 well as address some of the corner cases, however this will not be 2991 defined by the ForCES protocol as it is out of scope for this 2992 specification. 2994 During a communication failure between the FE and CE (which is caused 2995 due to CE or link reasons, i.e. not FE related), either the TML on 2996 the FE will trigger the FE PL regarding this failure or it will be 2997 detected using the HB messages between FEs and CEs. The 2998 communication failure, regardless of how it is detected, MUST be 2999 considered as a loss of association between the CE and corresponding 3000 FE. In the Report Primary mode, as there should be no other existing 3001 CE-FE associations, the FE PL MUST at this point establish 3002 association with the secondary CE. Once the process has started, if 3003 the original primary CE comes alive and starts sending commands 3004 message to the FE, the FE MUST ignore those messages. If the 3005 original CE begins a new association phase with the FE then the FE 3006 MUST send an Association Setup Response message with Result = 2 3007 indicating that there are too many associations. It will be up to 3008 CE-CE communications, out of scope for this specification, to 3009 determine what what, if any changes should be made to FE 3010 configuration following the recovery process. 3012 An explicit message (Config message setting Primary CE attribute in 3013 ForCES Protocol object) from the primary CE, can also be used to 3014 change the Primary CE for an FE during normal protocol operation. 3016 Also note that the FEs in a ForCES NE could also use a multicast 3017 CEID, i.e. they are associated with a group of CEs (this assumes the 3018 use of a CE-CE synchronization protocol, which is out of scope for 3019 this specification). In this case the loss of association would mean 3020 that communication with the entire multicast group of CEs has been 3021 lost. The mechanisms described above will apply for this case as 3022 well during the loss of association. If, however, the secondary CE 3023 was also using the multicast CEID that was lost, then the FE will 3024 need to form a new association using a different CEID. If the 3025 capability exists, the FE MAY first attempt to form a new association 3026 with original primary CE using a different non multicast CEID. 3028 These two scenarios, Report Primary (default), Report Primary 3029 (currently unsupported), are illustrated in the Figure 36 and 3030 Figure 37 below. 3032 FE CE Primary CE Secondary 3033 | | | 3034 | Asso Estb,Caps exchg | | 3035 1 |<--------------------->| | 3036 | | | 3037 | All msgs | | 3038 2 |<--------------------->| | 3039 | | | 3040 | | | 3041 | FAILURE | 3042 | | 3043 | Asso Estb,Caps exchange | 3044 3 |<------------------------------------------>| 3045 | | 3046 | Event Report (pri CE down) | 3047 4 |------------------------------------------->| 3048 | | 3049 | All Msgs | 3050 5 |<------------------------------------------>| 3052 Figure 36: CE Failover for Report Primary Mode 3053 FE CE Primary CE Secondary 3054 | | | 3055 | Asso Estb,Caps exchg | | 3056 1 |<--------------------->| | 3057 | | | 3058 | Asso Estb,Caps|exchange | 3059 2 |<----------------------|------------------->| 3060 | | | 3061 | All msgs | | 3062 3 |<--------------------->| | 3063 | | | 3064 | packet redirection,|events, HBs | 3065 4 |-----------------------|------------------->| 3066 | | | 3067 | FAILURE | 3068 | | 3069 | Event Report (pri CE down) | 3070 5 |------------------------------------------->| 3071 | | 3072 | All Msgs | 3073 6 |<------------------------------------------>| 3075 Figure 37: CE Failover for Report All mode 3077 9.1. Responsibilities for HA 3079 TML level - Transport level: 3081 1. The TML controls logical connection availability and failover. 3083 2. The TML also controls peer HA management. 3085 At this level, control of all lower layers, for example transport 3086 level (such as IP addresses, MAC addresses etc) and associated links 3087 going down are the role of the TML. 3089 PL Level: 3090 For all other functionality including configuring the HA behavior 3091 during setup, the CEIDs are used to identify primary, secondary CEs, 3092 protocol Messages used to report CE failure (Event Report), Heartbeat 3093 messages used to detect association failure, messages to change 3094 primary CE (config - move), and other HA related operations described 3095 before are the PL responsibility. 3097 To put the two together, if a path to a primary CE is down, the TML 3098 would take care of failing over to a backup path, if one is 3099 available. If the CE is totally unreachable then the PL would be 3100 informed and it will take the appropriate actions described before. 3102 10. Security Considerations 3104 ForCES architecture identifies several levels of security in 3105 [RFC3746]. ForCES PL uses security services provided by the ForCES 3106 TML layer. TML layer provides security services such as endpoint 3107 authentication service, message authentication service and 3108 confidentiality service. Endpoint authentication service is invoked 3109 at the time of pre-association connection establishment phase and 3110 message authentication is performed whenever FE or CE receives a 3111 packet from its peer. 3113 The following are the general security mechanisms that needs to be in 3114 place for ForCES PL layer. 3116 o Security mechanisms are session controlled - that is, once the 3117 security is turned ON depending upon the chosen security level (No 3118 Security, Authentication only, Confidentiality), it will be in 3119 effect for the entire duration of the session. 3121 o Operator should configure the same security policies for both 3122 primary and backup FE's and CE's (if available). This will ensure 3123 uniform operations, and to avoid unnecessary complexity in policy 3124 configuration. 3126 o ForCES PL endpoints SHOULD pre-established connections with both 3127 primary and backup CE's. This will reduce the security messages 3128 and enable rapid switchover operations for HA. 3130 10.1. No Security 3132 When "No security" is chosen for ForCES protocol communication, both 3133 endpoint authentication and message authentication service needs to 3134 be performed by ForCES PL layer. Both these mechanism are weak and 3135 does not involve cryptographic operation. Operator can choose "No 3136 security" level when the ForCES protocol endpoints are within a 3137 single box. 3139 In order to have interoperable and uniform implementation across 3140 various security levels, each CE and FE endpoint MUST implement this 3141 level. The operations that are being performed for "No security" 3142 level is required even if lower TML security services are being used. 3144 10.1.1. Endpoint Authentication 3146 Each CE and FE PL layer maintains set of associations list as part of 3147 configuration. This is done via CEM and FEM interfaces. FE MUST 3148 connect to only those CE's that are configured via FEM similarly, a 3149 CE should accept the connection and establish associations for the 3150 FE's which are configured via CEM. CE should validate the FE 3151 identifier before accepting the connection during the pre-association 3152 phase. 3154 10.1.2. Message authentication 3156 When CE or FE generates initiates a message, the receiving endpoint 3157 MUST validate the initiator of the message by checking the common 3158 header CE or FE identifiers. This will ensure proper protocol 3159 functioning. This extra processing step is recommend even if the 3160 underlying TLM layer security services. 3162 10.2. ForCES PL and TML security service 3164 This section is applicable if operator wishes to use the TML security 3165 services. ForCES TML layer MUST support one or more security service 3166 such as endpoint authentication service, message authentication 3167 service, confidentiality service as part of TML security layer 3168 functions. It is the responsibility of the operator to select 3169 appropriate security service and configure security policies 3170 accordingly. The details of such configuration is outside the scope 3171 of ForCES PL and is depending upon the type of transport protocol, 3172 nature of connection. 3174 All these configurations should be done prior to starting the CE and 3175 FE. 3177 When certificates-based authentication is being used at TML layer, 3178 the certificate can use ForCES specific naming structure as 3179 certificate names and accordingly the security policies can be 3180 configured at CE and FE. 3182 10.2.1. Endpoint authentication service 3184 When TML security services are enabled. ForCES TML layer performs 3185 endpoint authentication. Security association is established between 3186 CE and FE and is transparent to the ForCES PL layer. 3188 It is recommended that an FE, after establishing the connection with 3189 the primary CE, should establish the security association with the 3190 backup CE (if available). During the switchover operation CE's 3191 security state associated with each SA's are not transferred. SA 3192 between primary CE and FE and backup CE and FE are treated as two 3193 separate SA's. 3195 10.2.2. Message authentication service 3197 This is TML specific operation and is transparent to ForCES PL layer. 3199 For details refer to Section 5. 3201 10.2.3. Confidentiality service 3203 This is TML specific operation and is transparent to ForCES PL layer. 3204 For details refer to Section 5. 3206 11. Acknowledgments 3208 The authors of this draft would like to acknowledge and thank the 3209 ForCES Working Group and especially the following: Furquan Ansari, 3210 Alex Audu, Steven Blake, Shuchi Chawla Alan DeKok, Ellen M. 3211 Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel M. 3212 Halpern (who should probably be listed among the authors), Zsolt 3213 Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, 3214 T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their 3215 contributions. We would also like to thank David Putzolu, and 3216 Patrick Droz for their comments and suggestions on the protocol and 3217 for their infinite patience. 3219 12. References 3221 12.1. Normative References 3223 [FE-MODEL] 3224 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., 3225 and S. Blake, "ForCES Forwarding Element Model", 3226 Feb. 2005. 3228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3229 Requirement Levels", BCP 14, RFC 2119, March 1997. 3231 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3232 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3233 October 1998. 3235 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 3236 June 1999. 3238 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 3239 of IP Control and Forwarding", RFC 3654, November 2003. 3241 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 3242 "Forwarding and Control Element Separation (ForCES) 3243 Framework", RFC 3746, April 2004. 3245 12.2. Informational References 3247 [2PCREF] Gray, J., "Notes on database operating systems. In 3248 Operating Systems: An Advanced Course. Lecture Notes in 3249 Computer Science, Vol. 60, pp. 394-481, Springer-Verlag", 3250 1978. 3252 [ACID] Haerder, T. and A. Reuter, "Principles of Transaction- 3253 Orientated Database Recovery", 1983. 3255 Appendix A. IANA Considerations 3257 Following the policies outlined in "Guidelines for Writing an IANA 3258 Considerations Section in RFCs" (RFC 2434 [RFC2434]), the following 3259 name spaces are defined in ForCES. 3261 o Message Type Name Space Section 7.1.1 3263 o Operation Type Name Space Section 7.1.1.1.6 3265 o Header Flags Section 6.1 3267 o TLV Type Section 7.1.1 3269 o LFB Class ID Section 7.1.1.1.5 3271 o Result: Association Setup Response Section 7.4.2 3273 o Reason: Association Teardown Message Section 7.4.3 3275 o Configuration Request: Operation Result Section 7.5.1 3277 A.1. Message Type Name Space 3279 The Message Type is an 8 bit value. The following is the guideline 3280 for defining the Message Type namespace 3282 Message Types 0x00 - 0x0F 3283 Message Types in this range are part of the base ForCES Protocol. 3284 Message Types in this range are allocated through an IETF 3285 consensus action. [RFC2434] 3286 Values assigned by this specification: 3288 0x00 ............... Reserved 3289 0x01 ............... AssociationSetup 3290 0x02 ............... AssociationTeardown 3291 0x03 ............... Config 3292 0x04 ............... Query 3293 0x05 ............... EventNotification 3294 0x06 ............... PacketRedirect 3295 0x07 - 0x0E ........ Reserved 3296 0x0F ............... Hearbeat 3297 0x11 ............... AssociationSetupRepsonse 3298 0x12 ............... Reserved 3299 0x13 ............... ConfigRepsonse 3300 0x14 ............... QueryResponse 3302 Message Types 0x20 - 0x7F 3303 Message Types in this range are Specification Required [RFC2434] 3304 Message Types using this range must be documented in an RFC or 3305 other permanent and readily available references. 3307 Message Types 0x80 - 0xFF 3308 Message Types in this range are reserved for vendor private 3309 extensions and are the responsibility of individual vendors. IANA 3310 management of this range of the Message Type Name Space is 3311 unnecessary. 3313 A.2. Operation Type 3315 The Operation Type name space is 16 bits long. The following is the 3316 guideline for managing the Operation Type Name Space. 3318 Operation Type 0x0000-0x00FF 3319 Operation Types in this range are allocated through an IETF 3320 consensus process. [RFC2434]. 3321 Values assigned by this specification: 3323 0x0000 Reserved 3324 0x0001 SET 3325 0x0002 SET-RESPONSE 3326 0x0003 DEL 3327 0x0004 DEL-RESPONSE 3328 0x0005 GET 3329 0x0006 GET-RESPONSE 3330 0x0007 REPORT 3332 Operation Type 0x0100-0x7FFF 3333 Operation Types using this range must be documented in an RFC or 3334 other permanent and readily available references. [RFC2434]. 3336 Operation Type 0x8000-0xFFFF 3337 Operation Types in this range are reserved for vendor private 3338 extensions and are the responsibility of individual vendors. IANA 3339 management of this range of the Operation Type Name Space is 3340 unnecessary. 3342 A.3. Header Flags 3344 The Header flag field is 32 bits long Header flags are part of the 3345 ForCES base protocol. Header flags are allocated through an IETF 3346 consensus action [RFC2434]. 3348 A.4. TLV Type Name Space 3350 The TLV Type name space is 16 bits long. The following is the 3351 guideline for managing the TLV Type Name Space. 3353 TLV Type 0x0000-0x00FF 3354 TLV Types in this range are allocated through an IETF consensus 3355 process. [RFC2434]. 3356 Values assigned by this specification: 3358 0x0000 Reserved 3359 0x0001 MAIN_TLV 3360 0x0002 REDIRECT-TLV 3361 0x0010 ASResult-TLV 3362 0x0011 ASTreason-TLV 3363 0x1000 LFBselect-TLV 3364 0x0101 OPER-TLV 3365 0x0110 PATH-DATA-TLV 3366 0x0111 KEYINFO-TLV 3367 0x0112 FULLDATA-TLV 3368 0x0113 SPARSEDATA-TLV 3369 0x0114 RESULT-TLV 3371 TLV Type 0x0200-0x7FFF 3372 TLV Types using this range must be documented in an RFC or other 3373 permanent and readily available references. [RFC2434]. 3375 TLV Type 0x8000-0xFFFF 3376 TLV Types in this range are reserved for vendor private extensions 3377 and are the responsibility of individual vendors. IANA management 3378 of this range of the TLV Type Name Space is unnecessary. 3380 A.5. LFB Class Id Name Space 3382 The LFB Class ID name space is 32 bits long. The following is the 3383 guideline for managing the TLV Result Name Space. 3385 LFB Class ID 0x00000000-0x0000FFFF 3386 LFB Class IDs in this range are allocated through an IETF 3387 consensus process. [RFC2434]. 3388 Values assigned by this specification: 3390 0x00000000 Reserved 3391 0x00000001 FE Protocol LFB 3392 0x00000002 FE Object LFB 3394 LFB Class ID 0x00010000-0x7FFFFFFF 3395 LFB Class IDs in this range are Specification Required [RFC2434] 3396 LFB Class ID using this range must be documented in an RFC or 3397 other permanent and readily available references. [RFC2434]. 3399 LFB Class Id 0x80000000-0xFFFFFFFFF 3400 LFB Class IDs in this range are reserved for vendor private 3401 extensions and are the responsibility of individual vendors. IANA 3402 management of this range of the LFB Class ID Space is unnecessary. 3404 A.6. Association Setup Response 3406 The Association Setup Response name space is 16 bits long. The 3407 following is the guideline for managing the Association Setup 3408 Response Name Space. 3410 Association Setup Response 0x0000-0x00FF 3411 Association Setup Responses in this range are allocated through an 3412 IETF consensus process. [RFC2434]. 3413 Values assigned by this specification: 3415 0x0000 Success 3416 0x0001 FE ID Invalid 3417 0x0002 Too many associations 3418 0x0003 Permission Denied 3420 Association Setup Response 0x0100-0x0FFF 3421 Association Setup Responses in this range are Specification 3422 Required [RFC2434] Values using this range must be documented in 3423 an RFC or other permanent and readily available references. 3424 [RFC2434]. 3426 Association Setup Response 0x80000000-0xFFFFFFFFF 3427 Association Setup Responses in this range are reserved for vendor 3428 private extensions and are the responsibility of individual 3429 vendors. IANA management of this range of the Association Setup 3430 Responses Name Space is unnecessary. 3432 A.7. Association Teardown Message 3434 The Association Teardown Message name space is 32 bits long. The 3435 following is the guideline for managing the TLV Result Name Space. 3437 Association Teardown Message 0x00000000-0x0000FFFF 3438 Association Teardown Messages in this range are allocated through 3439 an IETF consensus process. [RFC2434]. 3440 Values assigned by this specification: 3442 0x00000000 Normal - Teardown by Administrator 3443 0x00000001 Error - Out of Memory 3444 0x00000002 Error - Application Crash 3445 0x000000FF Error - Unspecified 3447 Association Teardown Message 0x00010000-0x7FFFFFFF 3448 Association Teardown Messages in this range are Specification 3449 Required [RFC2434] Association Teardown Messages using this range 3450 must be documented in an RFC or other permanent and readily 3451 available references. [RFC2434]. 3453 LFB Class Id 0x80000000-0xFFFFFFFFF 3454 Association Teardown Messages in this range are reserved for 3455 vendor private extensions and are the responsibility of individual 3456 vendors. IANA management of this range of the Association 3457 Teardown Message Name Space is unnecessary. 3459 A.8. Configuration Request Result 3461 The Configuration Request name space is 32 bits long. The following 3462 is the guideline for managing the Configuration Request Name Space. 3464 Configuration Request 0x0000-0x00FF 3465 Configuration Requests in this range are allocated through an IETF 3466 consensus process. [RFC2434]. 3467 Values assigned by this specification: 3469 0x0000 Success 3470 0x0001 FE ID Invalid 3471 0x0003 Permission Denied 3473 Configuration Request 0x0100-0x7FFF 3474 Configuration Requests in this range are Specification Required 3475 [RFC2434] Configuration Requests using this range must be 3476 documented in an RFC or other permanent and readily available 3477 references. [RFC2434]. 3479 0x8000-0xFFFF 3480 Configuration Requests in this range are reserved for vendor 3481 private extensions and are the responsibility of individual 3482 vendors. IANA management of this range of the Configuration 3483 Request Name Space is unnecessary. 3485 Appendix B. ForCES Protocol LFB schema 3487 The schema described below conforms to the LFB schema described in 3488 ForCES Model draft[FE-MODEL] 3490 3495 3496 3497 3498 CEHBPolicyValues 3499 3500 The possible values of CE heartbeat policy 3501 3502 3503 uchar 3504 3505 3506 CEHBPolicy0 3507 3508 The CE heartbeat policy 0, refer to 3509 for details 3510 3511 3512 3513 CEHBPolicy1 3514 3515 The CE heartbeat policy 1, refer to 3516 for details 3517 3518 3519 3520 3521 3523 3524 FEHBPolicyValues 3525 3526 The possible values of FE heartbeat policy 3527 3528 3529 uchar 3530 3531 3532 FEHBPolicy0 3533 3534 The FE heartbeat policy 0, refer to 3535 for details 3536 3537 3538 3539 FEHBPolicy1 3540 3541 The FE heartbeat policy 1, refer to 3542 for details 3543 3544 3545 3546 3547 3549 3550 FERestartPolicyValues 3551 3552 The possible values of FE restart policy 3553 3554 3555 uchar 3556 3557 3558 FERestartPolicy0 3559 3560 The FE restart policy 0, refer to 3561 for details 3562 3563 3564 3565 FERestartPolicy1 3566 3567 The FE restart policy 1, refer to 3568 for details 3569 3570 3571 3572 3573 3575 3576 CEFailoverPolicyValues 3577 3578 The possible values of CE failover policy 3579 3580 3581 uchar 3582 3583 3584 CEFailoverPolicy0 3585 3586 The CE failover policy 0, refer to 3587 for details 3588 3589 3590 3591 CEFailoverPolicy1 3592 3593 The CE failover policy 1, refer to 3594 for details 3595 3596 3597 3598 CEFailoverPolicy2 3599 3600 The CE failover policy 2, refer to 3601 for details 3602 3603 3604 3605 3606 3607 3609 3610 3611 FEPO 3612 1 3613 3614 The FE Protocol Object 3615 3616 1.0 3617 baseclass 3619 3620 3621 CurrentRunningVersion 3622 Currently running ForCES version 3623 u8 3624 3625 3626 FEID 3627 Unicast FEID 3628 uint32 3630 3631 3632 MulticastFEIDs 3633 3634 the table of all multicast IDs 3635 3636 3637 uint32 3638 3639 3640 3641 CEHBPolicy 3642 3643 The CE Heartbeat Policy 3644 3645 CEHBPolicyValues 3646 3647 3648 CEHDI 3649 3650 The CE Heartbeat Dead Interval in millisecs 3651 3652 uint32 3653 3654 3655 FEHBPolicy 3656 3657 The FE Heartbeat Policy 3658 3659 FEHBPolicyValues 3660 3661 3662 FEHI 3663 3664 The FE Heartbeat Interval in millisecs 3665 3666 uint32 3667 3668 3669 CEID 3670 3671 The Primary CE this FE is associated with 3672 3673 uint32 3674 3675 3676 BackupCEs 3677 3678 The table of all backup CEs other than the primary 3679 3680 3681 uint32 3682 3683 3684 3685 FERestartPolicy 3686 3687 The FE Restart Policy 3688 3689 FERestartPolicyValues 3690 3692 3693 CEFailoverPolicy 3694 3695 The CE Failover Policy 3696 3697 CEFailoverPolicyValues 3698 3700 3701 CETI 3702 3703 The CE Timeout Interval in millisecs 3704 3705 uint32 3706 3707 3708 3709 3710 SupportableVersions 3711 3712 the table of ForCES versions that FE supports 3713 3714 3715 u8 3716 3717 3718 3719 3720 3721 3723 B.1. Capabilities 3725 At the moment only the SupportableVersions capability is owned by 3726 this LFB. 3728 Supportable Versions enumerates all ForCES versions that an FE 3729 supports. 3731 B.2. Attributes 3733 All Attributes are explained in Section 7.2.1. 3735 Appendix C. Data Encoding Examples 3737 In this section a few examples of data encoding are discussed. these 3738 example, however, do not show any padding. 3740 ========== 3741 Example 1: 3742 ========== 3744 Structure with three fixed-lengthof, mandatory fields. 3746 struct S { 3747 uint16 a 3748 uint16 b 3749 uint16 c 3750 } 3752 (a) Describing all fields using SPARSEDATA 3754 Path-Data TLV 3755 Path to an instance of S ... 3756 SPARSEDATA TLV 3757 ElementIDof(a), lengthof(a), valueof(a) 3758 ElementIDof(b), lengthof(b), valueof(b) 3759 ElementIDof(c), lengthof(c), valueof(c) 3761 (b) Describing a subset of fields 3763 Path-Data TLV 3764 Path to an instance of S ... 3765 SPARSEDATA TLV 3766 ElementIDof(a), lengthof(a), valueof(a) 3767 ElementIDof(c), lengthof(c), valueof(c) 3769 Note: Even though there are non-optional elements in structure S, 3770 since one can uniquely identify elements, one can selectively send 3771 element of structure S (eg in the case of an update from CE to FE). 3773 (c) Describing all fields using a FULLDATA TLV 3775 Path-Data TLV 3776 Path to an instance of S ... 3777 FULLDATA TLV 3778 valueof(a) 3779 valueof(b) 3780 valueof(c) 3782 ========== 3783 Example 2: 3784 ========== 3786 Structure with three fixed-lengthof fields, one mandatory, two 3787 optional. 3789 struct T { 3790 uint16 a 3791 uint16 b (optional) 3792 uint16 c (optional) 3793 } 3795 This example is identical to Example 1, as illustrated below. 3797 (a) Describing all fields using SPARSEDATA 3799 Path-Data TLV 3800 Path to an instance of S ... 3801 SPARSEDATA TLV 3802 ElementIDof(a), lengthof(a), valueof(a) 3803 ElementIDof(b), lengthof(b), valueof(b) 3804 ElementIDof(c), lengthof(c), valueof(c) 3806 (b) Describing a subset of fields using SPARSEDATA 3808 Path-Data TLV 3809 Path to an instance of S ... 3810 SPARSEDATA TLV 3811 ElementIDof(a), lengthof(a), valueof(a) 3812 ElementIDof(c), lengthof(c), valueof(c) 3814 (c) Describing all fields using a FULLDATA TLV 3816 Path-Data TLV 3817 Path to an instance of S ... 3818 FULLDATA TLV 3819 valueof(a) 3820 valueof(b) 3821 valueof(c) 3823 Note: FULLDATA TLV _cannot_ be used unless all fields are being 3824 described. 3826 ========== 3827 Example 3: 3828 ========== 3829 Structure with a mix of fixed-lengthof and variable-lengthof fields, 3830 some mandatory, some optional. 3832 struct U { 3833 uint16 a 3834 string b (optional) 3835 uint16 c (optional) 3836 } 3838 (a) Describing all fields using SPARSEDATA 3840 Path to an instance of U ... 3841 SPARSEDATA TLV 3842 ElementIDof(a), lengthof(a), valueof(a) 3843 ElementIDof(b), lengthof(b), valueof(b) 3844 ElementIDof(c), lengthof(c), valueof(c) 3846 (b) Describing a subset of fields using SPARSEDATA 3848 Path to an instance of U ... 3849 SPARSEDATA TLV 3850 ElementIDof(a), lengthof(a), valueof(a) 3851 ElementIDof(c), lengthof(c), valueof(c) 3853 (c) Describing all fields using FULLDATA TLV 3855 Path to an instance of U ... 3856 FULLDATA TLV 3857 valueof(a) 3858 FULLDATA TLV 3859 valueof(b) 3860 valueof(c) 3862 Note: The variable-length field requires the addition of a FULLDATA 3863 TLV within the outer FULLDATA TLV as in the case of element b above. 3865 ========== 3866 Example 4: 3867 ========== 3869 Structure containing an array of another structure type. 3871 struct V { 3872 uint32 x 3873 uint32 y 3874 struct U z[] 3875 } 3877 (a) Encoding using SPARSEDATA, with two instances of z[], also 3878 described with SPARSEDATA, assuming only the 10th and 15th subscript 3879 of z[] are encoded. 3881 path to instance of V ... 3882 SPARSEDATA TLV 3883 ElementIDof(x), lengthof(x), valueof(x) 3884 ElementIDof(y), lengthof(y), valueof(y) 3885 ElementIDof(z), lengthof(all below) 3886 ElementID = 10 (i.e index 10 from z[]), lengthof(all below) 3887 ElementIDof(a), lengthof(a), valueof(a) 3888 ElementIDof(b), lengthof(b), valueof(b) 3889 ElementID = 15 (index 15 from z[]), lengthof(all below) 3890 ElementIDof(a), lengthof(a), valueof(a) 3891 ElementIDof(c), lengthof(c), valueof(c) 3893 Note the holes in the elements of z (10 followed by 15). Also note 3894 the gap in index 15 with only elements a and c appearing but not b. 3896 Appendix D. Use Cases 3898 Assume LFB with following attributes for the following use cases. 3900 foo1, type u32, ID = 1 3902 foo2, type u32, ID = 2 3904 table1: type array, ID = 3 3905 elements are: 3906 t1, type u32, ID = 1 3907 t2, type u32, ID = 2 // index into table 2 3908 KEY: nhkey, ID = 1, V = t2 3910 table2: type array, ID = 4 3911 elements are: 3912 j1, type u32, ID = 1 3913 j2, type u32, ID = 2 3914 KEY: akey, ID = 1, V = { j1,j2 } 3916 table3: type array, ID = 5 3917 elements are: 3918 someid, type u32, ID = 1 3919 name, type string variable sized, ID = 2 3921 table4: type array, ID = 6 3922 elements are: 3923 j1, type u32, ID = 1 3924 j2, type u32, ID = 2 3925 j3, type u32, ID = 3 3926 j4, type u32, ID = 4 3927 KEY: mykey, ID = 1, V = { j1} 3929 table5: type array, ID = 7 3930 elements are: 3931 p1, type u32, ID = 1 3932 p2, type array, ID = 2, array elements of type-X 3934 Type-X: 3935 x1, ID 1, type u32 3936 x2, ID2 , type u32 3937 KEY: tkey, ID = 1, V = { x1} 3939 All examples will show an attribute suffixed with "v" or "val" to 3940 indicate the value of the referenced attribute. example for attribute 3941 foo2, foo1v or foo1value will indicate the value of foo1. In the 3942 case where F_SEL** are missing (bits equal to 00) then the flags will 3943 not show any selection. 3945 All the examples only show use of FULLDATA for data encoding; 3946 although SPARSEDATA would make more sense in certain occasions, the 3947 emphasis is on showing the message layout. Refer to Appendix C for 3948 examples that show usage of both FULLDATA and SPARSEDATA. 3950 1. To get foo1 3952 OPER = GET-TLV 3953 Path-data TLV: IDCount = 1, IDs = 1 3954 Result: 3955 OPER = GET-RESPONSE-TLV 3956 Path-data-TLV: 3957 flags=0, IDCount = 1, IDs = 1 3958 FULLDATA-TLV L = 4+4, V = foo1v 3960 2. To set foo2 to 10 3962 OPER = SET-REPLACE-TLV 3963 Path-data-TLV: 3964 flags = 0, IDCount = 1, IDs = 2 3965 FULLDATA TLV: L = 4+4, V=10 3967 Result: 3968 OPER = SET-RESPONSE-TLV 3969 Path-data-TLV: 3970 flags = 0, IDCount = 1, IDs = 2 3971 RESULT-TLV 3973 3. To dump table2 3975 OPER = GET-TLV 3976 Path-data-TLV: 3977 IDCount = 1, IDs = 4 3978 Result: 3979 OPER = GET-RESPONSE-TLV 3980 Path-data-TLV: 3981 flags = 0, IDCount = 1, IDs = 4 3982 FULLDATA=TLV: L = XXX, V= 3983 a series of: index, j1value,j2value entries 3984 representing the entire table 3986 Note: One should be able to take a GET-RESPONSE-TLV and convert 3987 it to a SET-REPLACE-TLV. If the result in the above example 3988 is sent back in a SET-REPLACE-TLV, (instead of a GET- 3989 RESPONSE_TLV) then the entire contents of the table will be 3990 replaced at that point. 3992 4. Multiple operations Example. To create entry 0-5 of table2 3993 (Error conditions are ignored) 3995 OPER = SET-CREATE-TLV 3996 Path-data-TLV: 3997 flags = 0 , IDCount = 1, IDs=4 3998 PATH-DATA-TLV 3999 flags = 0, IDCount = 1, IDs = 0 4000 FULLDATA-TLV containing j1, j2 value for entry 0 4001 PATH-DATA-TLV 4002 flags = 0, IDCount = 1, IDs = 1 4003 FULLDATA-TLV containing j1, j2 value for entry 1 4004 PATH-DATA-TLV 4005 flags = 0, IDCount = 1, IDs = 2 4006 FULLDATA-TLV containing j1, j2 value for entry 2 4007 PATH-DATA-TLV 4008 flags = 0, IDCount = 1, IDs = 3 4009 FULLDATA-TLV containing j1, j2 value for entry 3 4010 PATH-DATA-TLV 4011 flags = 0, IDCount = 1, IDs = 4 4012 FULLDATA-TLV containing j1, j2 value for entry 4 4013 PATH-DATA-TLV 4014 flags = 0, IDCount = 1, IDs = 5 4015 FULLDATA-TLV containing j1, j2 value for entry 5 4017 Result: 4018 OPER = SET-RESPONSE-TLV 4019 Path-data-TLV: 4020 flags = 0 , IDCount = 1, IDs=4 4021 PATH-DATA-TLV 4022 flags = 0, IDCount = 1, IDs = 0 4023 RESULT-TLV 4024 PATH-DATA-TLV 4025 flags = 0, IDCount = 1, IDs = 1 4026 RESULT-TLV 4027 PATH-DATA-TLV 4028 flags = 0, IDCount = 1, IDs = 2 4029 RESULT-TLV 4030 PATH-DATA-TLV 4031 flags = 0, IDCount = 1, IDs = 3 4032 RESULT-TLV 4033 PATH-DATA-TLV 4034 flags = 0, IDCount = 1, IDs = 4 4035 RESULT-TLV 4036 PATH-DATA-TLV 4037 flags = 0, IDCount = 1, IDs = 5 4038 RESULT-TLV 4040 5. Block operations (with holes) example. Replace entry 0,2 of 4041 table2 4043 OPER = SET-REPLACE-TLV 4044 Path-data TLV: 4045 flags = 0 , IDCount = 1, IDs=4 4046 PATH-DATA-TLV 4047 flags = 0, IDCount = 1, IDs = 0 4048 FULLDATA-TLV containing j1, j2 value for entry 0 4049 PATH-DATA-TLV 4050 flags = 0, IDCount = 1, IDs = 2 4051 FULLDATA-TLV containing j1, j2 value for entry 2 4053 Result: 4054 OPER = SET-REPLACE-TLV 4055 Path-data TLV: 4056 flags = 0 , IDCount = 1, IDs=4 4057 PATH-DATA-TLV 4058 flags = 0, IDCount = 1, IDs = 0 4059 RESULT-TLV 4060 PATH-DATA-TLV 4061 flags = 0, IDCount = 1, IDs = 2 4062 RESULT-TLV 4064 6. Getting rows example. Get first entry of table2. 4066 OPER = GET-TLV 4067 Path-data TLV: 4068 IDCount = 2, IDs=4.0 4070 Result: 4071 OPER = GET-RESPONSE-TLV 4072 Path-data TLV: 4073 IDCount = 2, IDs=4.0 4074 FULLDATA TLV, Length = XXX, V = 4075 j1value,j2value entry 4077 7. Get entry 0-5 of table2. 4079 OPER = GET-TLV 4080 Path-data-TLV: 4081 flags = 0, IDCount = 1, IDs=4 4082 PATH-DATA-TLV 4083 flags = 0, IDCount = 1, IDs = 0 4084 PATH-DATA-TLV 4085 flags = 0, IDCount = 1, IDs = 1 4086 PATH-DATA-TLV 4087 flags = 0, IDCount = 1, IDs = 2 4088 PATH-DATA-TLV 4089 flags = 0, IDCount = 1, IDs = 3 4090 PATH-DATA-TLV 4091 flags = 0, IDCount = 1, IDs = 4 4092 PATH-DATA-TLV 4093 flags = 0, IDCount = 1, IDs = 5 4095 Result: 4096 OPER = GET-RESPONSE-TLV 4097 Path-data-TLV: 4098 flags = 0, IDCount = 1, IDs=4 4099 PATH-DATA-TLV 4100 flags = 0, IDCount = 1, IDs = 0 4101 FULLDATA-TLV containing j1value j2value 4102 PATH-DATA-TLV 4103 flags = 0, IDCount = 1, IDs = 1 4104 FULLDATA-TLV containing j1value j2value 4105 PATH-DATA-TLV 4106 flags = 0, IDCount = 1, IDs = 2 4107 FULLDATA-TLV containing j1value j2value 4108 PATH-DATA-TLV 4109 flags = 0, IDCount = 1, IDs = 3 4110 FULLDATA-TLV containing j1value j2value 4111 PATH-DATA-TLV 4112 flags = 0, IDCount = 1, IDs = 4 4113 FULLDATA-TLV containing j1value j2value 4114 PATH-DATA-TLV 4115 flags = 0, IDCount = 1, IDs = 5 4116 FULLDATA-TLV containing j1value j2value 4118 8. Create a row in table2, index 5. 4120 OPER = SET-CREATE-TLV 4121 Path-data-TLV: 4122 flags = 0, IDCount = 2, IDs=4.5 4123 FULLDATA TLV, Length = XXX 4124 j1value,j2value 4126 Result: 4127 OPER = SET-RESPONSE-TLV 4128 Path-data TLV: 4129 flags = 0, IDCount = 1, IDs=4.5 4130 RESULT-TLV 4132 9. An example of "create and give me an index" Assuming one asked 4133 for verbose response back in the main message header. 4135 OPER = SET-CREATE-TLV 4136 Path-data -TLV: 4137 flags = FIND-EMPTY, IDCount = 1, IDs=4 4138 FULLDATA TLV, Length = XXX 4139 j1value,j2value 4141 Result 4142 If 7 were the first unused entry in the table: 4143 OPER = SET-RESPONSE 4144 Path-data TLV: 4145 flags = 0, IDCount = 2, IDs=4.7 4146 RESULT-TLV indicating success, and 4147 FULLDATA-TLV, Length = XXX j1value,j2value 4149 10. Dump contents of table1. 4151 OPER = GET-TLV 4152 Path-data TLV: 4153 flags = 0, IDCount = 1, IDs=3 4155 Result: 4156 OPER = GET-RESPONSE-TLV 4157 Path-data TLV 4158 flags = 0, IDCount = 1, IDs=3 4159 FULLDATA TLV, Length = XXXX 4160 (depending on size of table1) 4161 index, t1value, t2value 4162 index, t1value, t2value 4163 . 4165 . 4166 . 4168 11. Using Keys. Get row entry from table4 where j1=100. Recall, j1 4169 is a defined key for this table and its keyid is 1. 4171 OPER = GET-TLV 4172 Path-data-TLV: 4173 flags = F_SELKEY IDCount = 1, IDs=6 4174 KEYINFO-TLV = KEYID=1, KEY_DATA=100 4176 Result: 4177 If j1=100 was at index 10 4178 OPER = GET-RESPONSE-TLV 4179 Path-data TLV: 4180 flags = 0, IDCount = 1, IDs=6.10 4181 FULLDATA TLV, Length = XXXX 4182 j1value,j2value, j3value, j4value 4184 12. Delete row with KEY match (j1=100, j2=200) in table 2. Note 4185 that the j1,j2 pair are a defined key for the table 2. 4187 OPER = DEL-TLV 4188 Path-data TLV: 4189 flags = F_SELKEY IDCount = 1, IDs=4 4190 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} 4192 Result: 4193 If (j1=100, j2=200) was at entry 15: 4194 OPER = DELETE-RESPONSE-TLV 4195 Path-data TLV: 4196 flags = 0 IDCount = 2, IDs=4.15 4197 RESULT-TLV (with FULLDATA if verbose) 4199 13. Dump contents of table3. It should be noted that this table has 4200 a column with element name that is variable sized. The purpose 4201 of this use case is to show how such an element is to be 4202 encoded. 4204 OPER = GET-TLV 4205 Path-data-TLV: 4206 flags = 0 IDCount = 1, IDs=5 4208 Result: 4209 OPER = GET-RESPONSE-TLV 4210 Path-data TLV: 4211 flags = 0 IDCount = 1, IDs=5 4212 FULLDATA TLV, Length = XXXX 4213 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4214 V = namev 4215 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4216 V = namev 4217 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4218 V = namev 4219 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4220 V = namev 4221 . 4222 . 4223 . 4225 14. Multiple atomic operations. 4227 Note 1: This emulates adding a new nexthop entry and then 4228 atomically updating the L3 entries pointing to an old NH to 4229 point to a new one. The assumption is both tables are in the 4230 same LFB 4232 Note2: Main header has atomic flag set and the request is for 4233 verbose/full results back; Two operations on the LFB 4234 instance, both are SET operations. 4236 //Operation 1: Add a new entry to table2 index #20. 4237 OPER = SET-CREATE-TLV 4238 Path-TLV: 4239 flags = 0, IDCount = 2, IDs=4.20 4240 FULLDATA TLV, V= j1value,j2value 4242 // Operation 2: Update table1 entry which 4243 // was pointing with t2 = 10 to now point to 20 4244 OPER = SET-REPLACE-TLV 4245 Path-data-TLV: 4246 flags = F_SELKEY, IDCount = 1, IDs=3 4247 KEYINFO = KEYID=1 KEY_DATA=10 4248 Path-data-TLV 4249 flags = 0 IDCount = 1, IDs=2 4250 FULLDATA TLV, V= 20 4252 Result: 4253 //first operation, SET 4254 OPER = SET-RESPONSE-TLV 4255 Path-data-TLV 4256 flags = 0 IDCount = 3, IDs=4.20 4257 RESULT-TLV code = success 4258 FULLDATA TLV, V = j1value,j2value 4259 // second opertion SET - assuming entry 16 was updated 4260 OPER = SET-RESPONSE-TLV 4261 Path-data TLV 4262 flags = 0 IDCount = 2, IDs=3.16 4263 Path-Data TLV 4264 flags = 0 IDCount = 1, IDs = 2 4265 SET-RESULT-TLV code = success 4266 FULLDATA TLV, Length = XXXX v=20 4267 // second opertion SET 4268 OPER = SET-RESPONSE-TLV 4269 Path-data TLV 4270 flags = 0 IDCount = 1, IDs=3 4271 KEYINFO = KEYID=1 KEY_DATA=10 4272 Path-Data TLV 4273 flags = 0 IDCount = 1, IDs = 2 4274 SET-RESULT-TLV code = success 4275 FULLDATA TLV, Length = XXXX v=20 4277 15. Selective setting. On table 4 -- for indices 1, 3, 5, 7, and 9. 4278 Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. 4280 PER = SET-REPLACE-TLV 4281 Path-data TLV 4282 flags = 0, IDCount = 1, IDs = 6 4283 Path-data TLV 4284 flags = 0, IDCount = 1, IDs = 1 4285 Path-data TLV 4286 flags = 0, IDCount = 1, IDs = 1 4287 FULLDATA TLV, Length = XXXX, V = {100} 4288 Path-data TLV 4289 flags = 0, IDCount = 1, IDs = 2 4290 FULLDATA TLV, Length = XXXX, V = {200} 4291 Path-data TLV 4292 flags = 0, IDCount = 1, IDs = 3 4293 FULLDATA TLV, Length = XXXX, V = {300} 4294 Path-data TLV 4295 flags = 0, IDCount = 1, IDs = 3 4296 Path-data TLV 4297 flags = 0, IDCount = 1, IDs = 1 4298 FULLDATA TLV, Length = XXXX, V = {100} 4299 Path-data TLV 4300 flags = 0, IDCount = 1, IDs = 2 4301 FULLDATA TLV, Length = XXXX, V = {200} 4302 Path-data TLV 4303 flags = 0, IDCount = 1, IDs = 3 4304 FULLDATA TLV, Length = XXXX, V = {300} 4305 Path-data TLV 4306 flags = 0, IDCount = 1, IDs = 5 4307 Path-data TLV 4308 flags = 0, IDCount = 1, IDs = 1 4309 FULLDATA TLV, Length = XXXX, V = {100} 4310 Path-data TLV 4311 flags = 0, IDCount = 1, IDs = 2 4312 FULLDATA TLV, Length = XXXX, V = {200} 4313 Path-data TLV 4314 flags = 0, IDCount = 1, IDs = 3 4315 FULLDATA TLV, Length = XXXX, V = {300} 4316 Path-data TLV 4317 flags = 0, IDCount = 1, IDs = 7 4318 Path-data TLV 4319 flags = 0, IDCount = 1, IDs = 1 4320 FULLDATA TLV, Length = XXXX, V = {100} 4321 Path-data TLV 4322 flags = 0, IDCount = 1, IDs = 2 4323 FULLDATA TLV, Length = XXXX, V = {200} 4324 Path-data TLV 4325 flags = 0, IDCount = 1, IDs = 3 4326 FULLDATA TLV, Length = XXXX, V = {300} 4327 Path-data TLV 4328 flags = 0, IDCount = 1, IDs = 9 4329 Path-data TLV 4330 flags = 0, IDCount = 1, IDs = 1 4331 FULLDATA TLV, Length = XXXX, V = {100} 4332 Path-data TLV 4333 flags = 0, IDCount = 1, IDs = 2 4334 FULLDATA TLV, Length = XXXX, V = {200} 4335 Path-data TLV 4336 flags = 0, IDCount = 1, IDs = 3 4337 FULLDATA TLV, Length = XXXX, V = {300} 4339 Non-verbose response mode shown: 4341 OPER = SET-RESPONSE-TLV 4342 Path-data TLV 4343 flags = 0, IDCount = 1, IDs = 6 4344 Path-data TLV 4345 flags = 0, IDCount = 1, IDs = 1 4346 Path-data TLV 4347 flags = 0, IDCount = 1, IDs = 1 4348 RESULT-TLV 4349 Path-data TLV 4350 flags = 0, IDCount = 1, IDs = 2 4351 RESULT-TLV 4352 Path-data TLV 4353 flags = 0, IDCount = 1, IDs = 3 4354 RESULT-TLV 4355 Path-data TLV 4356 flags = 0, IDCount = 1, IDs = 3 4357 Path-data TLV 4358 flags = 0, IDCount = 1, IDs = 1 4359 RESULT-TLV 4360 Path-data TLV 4361 flags = 0, IDCount = 1, IDs = 2 4362 RESULT-TLV 4363 Path-data TLV 4364 flags = 0, IDCount = 1, IDs = 3 4365 RESULT-TLV 4366 Path-data TLV 4367 flags = 0, IDCount = 1, IDs = 5 4368 Path-data TLV 4369 flags = 0, IDCount = 1, IDs = 1 4370 RESULT-TLV 4371 Path-data TLV 4372 flags = 0, IDCount = 1, IDs = 2 4373 RESULT-TLV 4374 Path-data TLV 4375 flags = 0, IDCount = 1, IDs = 3 4376 RESULT-TLV 4378 Path-data TLV 4379 flags = 0, IDCount = 1, IDs = 7 4380 Path-data TLV 4381 flags = 0, IDCount = 1, IDs = 1 4382 RESULT-TLV 4383 Path-data TLV 4384 flags = 0, IDCount = 1, IDs = 2 4385 RESULT-TLV 4386 Path-data TLV 4387 flags = 0, IDCount = 1, IDs = 3 4388 RESULT-TLV 4389 Path-data TLV 4390 flags = 0, IDCount = 1, IDs = 9 4391 Path-data TLV 4392 flags = 0, IDCount = 1, IDs = 1 4393 RESULT-TLV 4394 Path-data TLV 4395 flags = 0, IDCount = 1, IDs = 2 4396 RESULT-TLV 4397 Path-data TLV 4398 flags = 0, IDCount = 1, IDs = 3 4399 RESULT-TLV 4401 16. Manipulation of table of table examples. Get x1 from table10 4402 row with index 4, inside table5 entry 10 4404 operation = GET-TLV 4405 Path-data-TLV 4406 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4408 Results: 4409 operation = GET-RESPONSE-TLV 4410 Path-data-TLV 4411 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4412 FULLDATA TLV: L=XXXX, V = {x1 value} 4414 17. From table5's row 10 table10, get X2s based on on the value of 4415 x1 equaling 10 (recall x1 is KeyID 1) 4417 operation = GET-TLV 4418 Path-data-TLV 4419 flag = F_SELKEY, IDCount=3, IDS = 7.10.2 4420 KEYINFO TLV, KEYID = 1, KEYDATA = 10 4421 Path-data TLV 4422 IDCount = 1, IDS = 2 //select x2 4424 Results: 4425 If x1=10 was at entry 11: 4426 operation = GET-RESPONSE-TLV 4427 Path-data-TLV 4428 flag = 0, IDCount=5, IDS = 7.10.2.11 4429 Path-data TLV 4430 flags = 0 IDCount = 1, IDS = 2 4431 FULLDATA TLV: L=XXXX, V = {x2 value} 4433 18. Further example of manipulating a table of tables 4435 Consider table 6 which is defined as: 4436 table6: type array, ID = 8 4437 elements are: 4438 p1, type u32, ID = 1 4439 p2, type array, ID = 2, array elements of type type-A 4441 type-A: 4442 a1, type u32, ID 1, 4443 a2, type array ID2 ,array elements of type type-B 4445 type-B: 4446 b1, type u32, ID 1 4447 b2, type u32, ID 2 4449 If for example one wanted to set by replacing: 4450 table6.10.p1 to 111 4451 table6.10.p2.20.a1 to 222 4452 table6.10.p2.20.a2.30.b1 to 333 4454 in one message and one operation. 4456 There are two ways to do this: 4457 a) using nesting 4458 b) using a flat path data 4460 A. Method using nesting 4461 in one message with a single operation 4463 operation = SET-REPLACE-TLV 4464 Path-data-TLV 4465 flags = 0 IDCount = 2, IDs=6.10 4466 Path-data-TLV 4467 flags = 0, IDCount = 1, IDs=1 4468 FULLDATA TLV: L=XXXX, 4469 V = {111} 4470 Path-data-TLV 4471 flags = 0 IDCount = 2, IDs=2.20 4472 Path-data-TLV 4473 flags = 0, IDCount = 1, IDs=1 4474 FULLDATA TLV: L=XXXX, 4475 V = {222} 4476 Path-data TLV : 4477 flags = 0, IDCount = 3, IDs=2.30.1 4478 FULLDATA TLV: L=XXXX, 4479 V = {333} 4480 Result: 4481 operation = SET-RESPONSE-TLV 4482 Path-data-TLV 4483 flags = 0 IDCount = 2, IDs=6.10 4484 Path-data-TLV 4485 flags = 0, IDCount = 1, IDs=1 4486 RESULT-TLV 4487 Path-data-TLV 4488 flags = 0 IDCount = 2, IDs=2.20 4489 Path-data-TLV 4490 flags = 0, IDCount = 1, IDs=1 4491 RESULT-TLV 4492 Path-data TLV : 4493 flags = 0, IDCount = 3, IDs=2.30.1 4494 RESULT-TLV 4496 B. Method using a flat path data in 4497 one message with a single operation 4499 operation = SET-REPLACE-TLV 4500 Path-data TLV : 4501 flags = 0, IDCount = 3, IDs=6.10.1 4502 FULLDATA TLV: L=XXXX, 4503 V = {111} 4504 Path-data TLV : 4505 flags = 0, IDCount = 5, IDs=6.10.1.20.1 4506 FULLDATA TLV: L=XXXX, 4507 V = {222} 4508 Path-data TLV : 4509 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 4510 FULLDATA TLV: L=XXXX, 4511 V = {333} 4512 Result: 4513 operation = SET-REPLACE-TLV 4514 Path-data TLV : 4515 flags = 0, IDCount = 3, IDs=6.10.1 4516 RESULT-TLV 4517 Path-data TLV : 4518 flags = 0, IDCount = 5, IDs=6.10.1.20.1 4519 RESULT-TLV 4520 Path-data TLV : 4521 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 4522 RESULT-TLV 4524 19. Get a whole LFB (all its attributes, etc.). 4526 For example: at startup a CE might well want the entire FE 4527 OBJECT LFB. So, in a request targeted at class 1, instance 4528 1, one might find: 4530 operation = GET-TLV 4531 Path-data-TLV 4532 flags = 0 IDCount = 0 4534 result: 4535 operation = GET-RESPONSE-TLV 4536 Path-data-TLV 4537 flags = 0 IDCount = 0 4538 FULLDATA encoding of the FE Object LFB 4540 Authors' Addresses 4542 Ligang Dong 4543 Zhejiang Gongshang University 4544 149 Jiaogong Road 4545 Hangzhou 310035 4546 P.R.China 4548 Phone: +86-571-88071024 4549 Email: donglg@mail.zjgsu.edu.cn 4551 Avri Doria 4552 ETRI 4553 Lulea University of Technology 4554 Lulea 4555 Sweden 4557 Phone: +46 73 277 1788 4558 Email: avri@acm.org 4560 Ram Gopal 4561 Nokia 4562 5, Wayside Road 4563 Burlington, MA 310035 4564 USA 4566 Phone: +1-781-993-3685 4567 Email: ram.gopal@nokia.com 4569 Robert Haas 4570 IBM 4571 Saumerstrasse 4 4572 8803 Ruschlikon 4573 Switzerland 4575 Phone: 4576 Email: rha@zurich.ibm.com 4577 Jamal Hadi Salim 4578 Znyx 4579 Ottawa, Ontario 4580 Canada 4582 Phone: 4583 Email: hadi@znyx.com 4585 Hormuzd M Khosravi 4586 Intel 4587 2111 NE 25th Avenue 4588 Hillsboro, OR 97124 4589 USA 4591 Phone: +1 503 264 0334 4592 Email: hormuzd.m.khosravi@intel.com 4594 Weiming Wang 4595 Zhejiang Gongshang University 4596 149 Jiaogong Road 4597 Hangzhou 310035 4598 P.R.China 4600 Phone: +86-571-88057712 4601 Email: wmwang@mail.zjgsu.edu.cn 4603 Intellectual Property Statement 4605 The IETF takes no position regarding the validity or scope of any 4606 Intellectual Property Rights or other rights that might be claimed to 4607 pertain to the implementation or use of the technology described in 4608 this document or the extent to which any license under such rights 4609 might or might not be available; nor does it represent that it has 4610 made any independent effort to identify any such rights. Information 4611 on the procedures with respect to rights in RFC documents can be 4612 found in BCP 78 and BCP 79. 4614 Copies of IPR disclosures made to the IETF Secretariat and any 4615 assurances of licenses to be made available, or the result of an 4616 attempt made to obtain a general license or permission for the use of 4617 such proprietary rights by implementers or users of this 4618 specification can be obtained from the IETF on-line IPR repository at 4619 http://www.ietf.org/ipr. 4621 The IETF invites any interested party to bring to its attention any 4622 copyrights, patents or patent applications, or other proprietary 4623 rights that may cover technology that may be required to implement 4624 this standard. Please address the information to the IETF at 4625 ietf-ipr@ietf.org. 4627 Disclaimer of Validity 4629 This document and the information contained herein are provided on an 4630 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4631 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4632 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4633 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4634 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4635 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4637 Copyright Statement 4639 Copyright (C) The Internet Society (2006). This document is subject 4640 to the rights, licenses and restrictions contained in BCP 78, and 4641 except as set forth therein, the authors retain all their rights. 4643 Acknowledgment 4645 Funding for the RFC Editor function is currently provided by the 4646 Internet Society.