idnits 2.17.1 draft-ietf-forces-protocol-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4704. ** 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 546: '...he UP state. This MUST be done before...' RFC 2119 keyword, line 678: '... re-association, MUST declare all the ...' RFC 2119 keyword, line 730: '...PL messages that MUST meet the ACIDity...' RFC 2119 keyword, line 779: '... The FE MUST respond to the CE's EOT...' RFC 2119 keyword, line 780: '...pecified timeout, the transaction MUST...' (49 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 3823 has weird spacing: '...j2value entri...' -- 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 (October 23, 2005) is 6760 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 1287, but not defined == Missing Reference: 'LFBselect-TLV' is mentioned on line 1288, but not defined == Missing Reference: 'REDIRECT-TLV' is mentioned on line 1288, but not defined == Missing Reference: 'ASResult-TLV' is mentioned on line 1289, but not defined == Missing Reference: 'ASTreason-TLV' is mentioned on line 1289, but not defined == Missing Reference: 'DATA' is mentioned on line 1292, but not defined == Missing Reference: 'SELECTOR' is mentioned on line 1293, but not defined == Unused Reference: 'RFC2629' is defined on line 3073, but no explicit reference was found in the text ** 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: 8 errors (**), 0 flaws (~~), 12 warnings (==), 7 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: April 26, 2006 R. Haas (Ed.) 5 IBM 6 J. Hadi Salim (Ed.) 7 Znyx 8 H. Khosravi (Ed.) 9 Intel 10 W. M. Wang (Ed.) 11 Zhejiang Gongshang University 12 October 23, 2005 14 ForCES Protocol Specification 15 draft-ietf-forces-protocol-05.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 26, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This document specifies the Forwarding and Control Element Separation 49 (ForCES) protocol. ForCES protocol is a message exchange protocol 50 that is used for communications between Control Elements(CEs) and 51 Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). 52 This specification is intended to meet the ForCES protocol 53 requirements defined in RFC3654. Besides the ForCES protocol 54 messages, the specification also defines the framework, the 55 mechanisms, and the Transport Mapping Layer (TML) requirements for 56 ForCES protocol. 58 Authors 60 The participants in the ForCES Protocol Team, co-authors and co- 61 editors, of this draft, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 9 73 3.1.1. The PL layer . . . . . . . . . . . . . . . . . . . . 11 74 3.1.2. The TML layer . . . . . . . . . . . . . . . . . . . . 12 75 3.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 12 76 3.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 13 77 3.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 14 78 3.2.2. Post-association . . . . . . . . . . . . . . . . . . 15 79 3.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 17 80 3.3.1. Transactions, Atomicity, Execution and Responses . . 17 81 3.3.2. Heartbeating Mechanism . . . . . . . . . . . . . . . 20 82 3.3.3. FE Object and FE protocol LFBs . . . . . . . . . . . 20 83 3.3.4. Scaling by Concurrency . . . . . . . . . . . . . . . 20 84 4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 22 85 4.1. TML Parameterization . . . . . . . . . . . . . . . . . . 23 86 5. Message encapsulation . . . . . . . . . . . . . . . . . . . . 24 87 5.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 24 88 5.2. Type Length Value(TLV) Structuring . . . . . . . . . . . 28 89 5.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 29 90 5.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 29 91 5.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 92 6. Protocol Construction . . . . . . . . . . . . . . . . . . . . 31 93 6.1. Protocol Grammar . . . . . . . . . . . . . . . . . . . . 31 94 6.1.1. Protocol BNF . . . . . . . . . . . . . . . . . . . . 31 95 6.1.2. Protocol Visualization . . . . . . . . . . . . . . . 39 96 6.2. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 42 97 6.2.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 43 98 6.2.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 46 99 6.3. Semantics of message Direction . . . . . . . . . . . . . 46 100 6.4. Association Messages . . . . . . . . . . . . . . . . . . 46 101 6.4.1. Association Setup Message . . . . . . . . . . . . . . 46 102 6.4.2. Association Setup Response Message . . . . . . . . . 48 103 6.4.3. Association Teardown Message . . . . . . . . . . . . 49 104 6.5. Configuration Messages . . . . . . . . . . . . . . . . . 50 105 6.5.1. Config Message . . . . . . . . . . . . . . . . . . . 50 106 6.5.2. Config Response Message . . . . . . . . . . . . . . . 52 107 6.6. Query Messages . . . . . . . . . . . . . . . . . . . . . 53 108 6.6.1. Query Message . . . . . . . . . . . . . . . . . . . . 53 109 6.6.2. Query Response Message . . . . . . . . . . . . . . . 55 110 6.7. Event Notification Message . . . . . . . . . . . . . . . 56 111 6.8. Packet Redirect Message . . . . . . . . . . . . . . . . . 58 112 6.9. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 61 113 6.10. Operation Summary . . . . . . . . . . . . . . . . . . . . 62 114 7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . 64 115 7.1. Association Setup state . . . . . . . . . . . . . . . . . 64 116 7.2. Association Established state or Steady State . . . . . . 65 117 8. High Availability Support . . . . . . . . . . . . . . . . . . 68 118 8.1. Responsibilities for HA . . . . . . . . . . . . . . . . . 70 119 9. Security Considerations . . . . . . . . . . . . . . . . . . . 71 120 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 71 121 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 71 122 9.1.2. Message authentication . . . . . . . . . . . . . . . 72 123 9.2. ForCES PL and TML security service . . . . . . . . . . . 72 124 9.2.1. Endpoint authentication service . . . . . . . . . . . 72 125 9.2.2. Message authentication service . . . . . . . . . . . 72 126 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 73 127 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 74 128 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 75 129 11.1. Normative References . . . . . . . . . . . . . . . . . . 75 130 11.2. Informational References . . . . . . . . . . . . . . . . 75 131 Appendix A. Authors' Addresses . . . . . . . . . . . . . . . . . 76 132 Appendix B. IANA Considerations . . . . . . . . . . . . . . . . 78 133 B.1. Message Type Name Space . . . . . . . . . . . . . . . . . 78 134 B.2. Operation Type . . . . . . . . . . . . . . . . . . . . . 79 135 B.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 79 136 B.4. LFB Class Id Name Space . . . . . . . . . . . . . . . . . 79 137 B.5. Association Setup Repsonse . . . . . . . . . . . . . . . 80 138 B.6. Association Teardown Message . . . . . . . . . . . . . . 80 139 B.7. Configuration Request Result . . . . . . . . . . . . . . 81 140 Appendix C. Forces Protocol LFB schema . . . . . . . . . . . . . 82 141 C.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 86 142 C.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 86 143 Appendix D. Data Encoding Examples . . . . . . . . . . . . . . . 87 144 Appendix E. Use Cases . . . . . . . . . . . . . . . . . . . . . 91 145 Appendix F. changes between -03, -04, and -05 . . . . . . . . . 107 146 Appendix G. changes between -02 and -03 . . . . . . . . . . . . 111 147 Appendix H. Changes between -01 and -02 . . . . . . . . . . . . 112 148 Appendix I. Changes between -00 and -01 . . . . . . . . . . . . 113 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114 150 Intellectual Property and Copyright Statements . . . . . . . . . 116 152 1. Introduction 154 Forwarding and Control Element Separation (ForCES) aims to define an 155 architectural framework and associated protocols to standardize 156 information exchange between the control plane and the forwarding 157 plane in an ForCES Network Element (ForCES NE). RFC 3654 has defined 158 the ForCES requirements, and RFC 3764 has defined the ForCES 159 framework. While there may be multiple protocols used within the 160 overall ForCES architecture, the term "ForCES protocol" refers only 161 to the protocol used to standardize the information exchange between 162 Control Elements(CEs) and Forwarding Elements(FEs) only. ForCES FE 163 model [FE-MODEL] represents the capabilities, state and configuration 164 of FEs within the context of the ForCES protocol, so that CEs can 165 accordingly control the FEs in a standardizded way and by means of 166 the ForCES protocol. 168 This document defines the ForCES protocol specifications. The ForCES 169 protocol works in a master-slave mode in which FEs are slaves and CEs 170 are masters. Information exchanged between FEs and CEs makes 171 extensive use of TLVs. The protocol includes commands for transport 172 of LFB configuration information as well as for association, status, 173 and event notifications, etc. 175 This specification does not define a transport mechanism for protocol 176 messages, but does include a discussion of service primitives that 177 must be provided by the underlying transport interface. 179 Section 2 provides a glossary of terminology used in the 180 specification. 182 Section 3 provides an overview of the protocol including a discussion 183 on the protocol framework, descriptions of the Protocol Layer (PL) 184 and a Transport Mapping Layer (TML), as well as of the ForCES 185 protocol mechanisms. 187 While this document does not define the TML, Section 4 details the 188 services that a TML must provide (TML requirements). 190 The ForCES protocol is defined to have a common header for all 191 protocol messages. The header is defined in Section 5.1, while the 192 protocol messages are defined in Section 6. 194 Section 7 describes several Protocol Scenarios and includes message 195 exchange descriptions. 197 Section 8 describes mechanism in the protocol to support high 198 availability mechanisms including redundancy and fail over. 199 Section 9 defines the security mechanisms provided by the PL and TML. 201 2. Definitions 203 This document follows the terminology defined by the ForCES 204 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 205 This document also uses the terminology defined by ForCES FE model in 206 [FE-MODEL] repeated below for clarity. 208 Addressable Entity (AE) - A physical device that is directly 209 addressable given some interconnect technology. For example, on IP 210 networks, it is a device to which we can communicate using an IP 211 address; and on a switch fabric, it is a device to which we can 212 communicate using a switch fabric port number. 214 Forwarding Element (FE) - A logical entity that implements the ForCES 215 protocol. FEs use the underlying hardware to provide per-packet 216 processing and handling as directed/controlled by a CE via the ForCES 217 protocol. 219 Control Element (CE) - A logical entity that implements the ForCES 220 protocol and uses it to instruct one or more FEs how to process 221 packets. CEs handle functionality such as the execution of control 222 and signaling protocols. 224 Pre-association Phase - The period of time during which a FE Manager 225 (see below) and a CE Manager (see below) are determining which FE and 226 CE should be part of the same network element. 228 Post-association Phase - The period of time during which a FE does 229 know which CE is to control it and vice versa, including the time 230 during which the CE and FE are establishing communication with one 231 another. 233 FE Model - A model that describes the logical processing functions of 234 a FE. 236 FE Manager (FEM) - A logical entity that operates in the pre- 237 association phase and is responsible for determining to which CE(s) a 238 FE should communicate. This process is called CE discovery and may 239 involve the FE manager learning the capabilities of available CEs. A 240 FE manager may use anything from a static configuration to a pre- 241 association phase protocol (see below) to determine which CE(s) to 242 use. Being a logical entity, a FE manager might be physically 243 combined with any of the other logical entities such as FEs. 245 CE Manager (CEM) - A logical entity that operates in the pre- 246 association phase and is responsible for determining to which FE(s) a 247 CE should communicate. This process is called FE discovery and may 248 involve the CE manager learning the capabilities of available FEs. A 249 CE manager may use anything from a static configuration to a pre- 250 association phase protocol (see below) to determine which FE to use. 251 Being a logical entity, a CE manager might be physically combined 252 with any of the other logical entities such as CEs. 254 ForCES Network Element (NE) - An entity composed of one or more CEs 255 and one or more FEs. To entities outside a NE, the NE represents a 256 single point of management. Similarly, a NE usually hides its 257 internal organization from external entities. 259 High Touch Capability - This term will be used to apply to the 260 capabilities found in some forwarders to take action on the contents 261 or headers of a packet based on content other than what is found in 262 the IP header. Examples of these capabilities include NAT-PT, 263 firewall, and L7 content recognition. 265 Datapath -- A conceptual path taken by packets within the forwarding 266 plane inside an FE. 268 LFB (Logical Function Block) Class (or Type) -- the basic building 269 blocks that are operated on by the Forces protocol. The LFB is a 270 well defined, logically separable functional block that resides in 271 the FE and is controlled by the CE via ForCES protocol. The LFB may 272 reside at the FE's datapath and process packets or may be purely a 273 control entity that is operated on by the CE. 275 LFB (Logical Function Block) Instance -- As a packet flows through an 276 FE along a datapath, it flows through one or multiple LFB instances, 277 with each implementing an instance of a certain LFB type. There may 278 be multiple instances of the same LFB in an FE's datapath. Note that 279 we often refer to LFBs without distinguishing between LFB type and 280 LFB instance when we believe the implied reference is obvious for the 281 given context. 283 LFB Metadata -- Metadata is used to communicate per-packet state from 284 one LFB to another, but is not sent across the network. The FE model 285 defines how such metadata is identified, produced and consumed by the 286 LFBs, but not how metadata is encoded within an implementation. 288 LFB Attribute -- Operational parameters of the LFBs that must be 289 visible to the CEs are conceptualized in the FE model as the LFB 290 attributes. The LFB attributes include, for example, flags, single 291 parameter arguments, complex arguments, and tables that the CE can 292 read or/and write via the ForCES protocol (see below). 294 LFB Topology -- Representation of how the LFB instances are logically 295 interconnected and placed along the datapath within one FE. 296 Sometimes it is also called intra-FE topology, to be distinguished 297 from inter-FE topology. 299 FE Topology -- A representation of how the multiple FEs within a 300 single NE are interconnected. Sometimes this is called inter-FE 301 topology, to be distinguished from intra-FE topology (i.e., LFB 302 topology). 304 Inter-FE Topology -- See FE Topology. 306 Intra-FE Topology -- See LFB Topology. 308 Following terminologies are defined by this document: 310 ForCES Protocol - While there may be multiple protocols used within 311 the overall ForCES architecture, the term "ForCES protocol" refers 312 only to the protocol used at the Fp reference point in the ForCES 313 Framework in [RFC3746]. This protocol does not apply to CE-to-CE 314 communication, FE-to-FE communication, or to communication between FE 315 and CE managers. Basically, the ForCES protocol works in a master- 316 slave mode in which FEs are slaves and CEs are masters. This 317 document defines the specifications for this ForCES protocol. 319 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 320 architecture that defines the ForCES protocol messages, the protocol 321 state transfer scheme, as well as the ForCES protocol architecture 322 itself (including requirements of ForCES TML (see below)). 323 Specifications of ForCES PL are defined by this document. 325 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 326 ForCES protocol architecture that specifically addresses the protocol 327 message transportation issues, such as how the protocol messages are 328 mapped to different transport media (like TCP, IP, ATM, Ethernet, 329 etc), and how to achieve and implement reliability, multicast, 330 ordering, etc. The ForCES TML specifications are detailed in 331 separate ForCES documents one for each TML. 333 3. Overview 335 The reader is referred to the Framework document [RFC3746], and in 336 particular sections 3 and 4, for an architectural overview and an 337 explanation of how the ForCES protocol fits in. There may be some 338 content overlap between the framework document and this section in 339 order to provide clarity. 341 3.1. Protocol Framework 343 Figure 1 below is reproduced from the Framework document for clarity. 344 It shows a NE with two CEs and two FEs. 346 --------------------------------------- 347 | ForCES Network Element | 348 -------------- Fc | -------------- -------------- | 349 | CE Manager |---------+-| CE 1 |------| CE 2 | | 350 -------------- | | | Fr | | | 351 | | -------------- -------------- | 352 | Fl | | | Fp / | 353 | | Fp| |----------| / | 354 | | | |/ | 355 | | | | | 356 | | | Fp /|----| | 357 | | | /--------/ | | 358 -------------- Ff | -------------- -------------- | 359 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 360 -------------- | | |------| | | 361 | -------------- -------------- | 362 | | | | | | | | | | 363 ----+--+--+--+----------+--+--+--+----- 364 | | | | | | | | 365 | | | | | | | | 366 Fi/f Fi/f 368 Fp: CE-FE interface 369 Fi: FE-FE interface 370 Fr: CE-CE interface 371 Fc: Interface between the CE Manager and a CE 372 Ff: Interface between the FE Manager and an FE 373 Fl: Interface between the CE Manager and the FE Manager 374 Fi/f: FE external interface 376 Figure 1: ForCES Architectural Diagram 378 The ForCES protocol domain is found in the Fp Reference Point. The 379 Protocol Element configuration reference points, Fc and Ff also play 380 a role in the booting up of the Forces Protocol. The protocol 381 element configuration is out of scope of the ForCES protocol but is 382 touched on in this document since it is an integral part of the 383 protocol pre-association phase. 385 Figure 2 below shows further breakdown of the Fp interface by example 386 of a MPLS QoS enabled Network Element. 388 ------------------------------------------------- 389 | | | | | | | 390 |OSPF |RIP |BGP |RSVP |LDP |. . . | 391 | | | | | | | 392 ------------------------------------------------- 393 | ForCES Interface | 394 ------------------------------------------------- 395 ^ ^ 396 | | 397 ForCES | |data 398 control | |packets 399 messages| |(e.g., routing packets) 400 | | 401 v v 402 ------------------------------------------------- 403 | ForCES Interface | 404 ------------------------------------------------- 405 | | | | | | | 406 |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | 407 | | | | |fier | | 408 ------------------------------------------------- 410 Figure 2: Examples of CE and FE functions 412 The ForCES Interface shown in Figure 2 constitutes two pieces: the PL 413 and TML layer. 415 This is depicted in Figure 3 below. 417 +------------------------------------------------ 418 | CE PL layer | 419 +------------------------------------------------ 420 | CE TML layer | 421 +------------------------------------------------ 422 ^ 423 | 424 ForCES | (i.e Forces data + control 425 PL | packets ) 426 messages | 427 over | 428 specific | 429 TML | 430 encaps | 431 and | 432 transport | 433 | 434 v 435 +------------------------------------------------ 436 | FE TML layer | 437 +------------------------------------------------ 438 | FE PL layer | 439 +------------------------------------------------ 441 Figure 3: ForCES Interface 443 The PL layer is in fact the ForCES protocol. Its semantics and 444 message layout are defined in this document. The TML Layer is 445 necessary to connect two ForCES PL layers as shown in Figure 3 above. 446 The TML is out of scope for this document but is within scope of 447 ForCES. This document defines requirements the PL needs the TML to 448 meet. 450 Both the PL and the TML layers are standardized by the IETF. While 451 only one PL layer is defined, different TMLs are expected to be 452 standardized. To interoperate the TML layer at the CE and FE are 453 expected to conform to the same definition. 455 On transmit, the PL layer delivers its messages to the TML layer. 456 The TML layer delivers the message to the destination TML layer(s). 457 On receive, the TML delivers the message to its destination PL 458 layer(s). 460 3.1.1. The PL layer 462 The PL is common to all implementations of ForCES and is standardized 463 by the IETF as defined in this document. The PL layer is responsible 464 for associating an FE or CE to an NE. It is also responsible for 465 tearing down such associations. An FE uses the PL layer to throw 466 various subscribed-to events to the CE PL layer as well as respond to 467 various status requests issued from the CE PL. The CE configures 468 both the FE and associated LFB'ss operational parameters using the PL 469 layer. In addition the CE may send various requests to the FE to 470 activate or deactivate it, reconfigure its HA parameterization, 471 subscribe to specific events etc. More details in Section 6. 473 3.1.2. The TML layer 475 The TML layer is essentially responsible for transport of the PL 476 layer messages. The TML is where the issues of how to achieve 477 transport level reliability, congestion control, multicast, ordering, 478 etc are handled. It is expected more than one TML will be 479 standardized. The different TMLs each could implement things 480 differently based on capabilities of underlying media and transport. 481 However, since each TML is standardized, interoperability is 482 guaranteed as long as both endpoints support the same TML. All 483 ForCES Protocol Layer implementations should be portable across all 484 TMLs, because all TMLs have the same top edge semantics as defined in 485 this document. 487 3.1.3. The FEM/CEM Interface 489 The FEM and CEM components, although valuable in the setup and 490 configurations of both the PL and TML layers, are out of scope of the 491 ForCES protocol. The best way to think of them are as 492 configurations/parameterizations for the PL and TML before they 493 become active (or even at runtime based on implementation). In the 494 simplest case, the FE or CE read a static configuration file. RFC 495 3746 has a lot more detailed descriptions on how the FEM and CEM 496 could be used. We discuss the pre-association phase where the CEM 497 and FEM play briefly in section Section 3.2.1. 499 An example of typical things FEM/CEM would configure would be TML 500 specific parameterizations such as: 502 a. how the TML connection should happen (example what IP addresses 503 to use, transport modes etc); 505 b. the ID for the FE or CE would also be issued at this point. 507 c. Security parameterization such as keys etc. 509 d. Connection association parameters 510 Example "send up to 3 association messages each 1 second apart" Vs " 511 send up to 4 association messages with increasing exponential 512 timeout". 514 3.2. ForCES Protocol Phases 516 ForCES, in relation to NEs, involves two phases: the Pre-Association 517 phase where configuration/initialization/bootup of the TML and PL 518 layer happens, and the association phase where the ForCES protocol 519 operates to manipulate the parameters of the FEs. 521 start FEObject Admin up 522 -------+ +--->---->---->---->------->----+ 523 | | Y 524 Y | | 525 | | Y 526 +------+--+ +--------+ 527 | | | | 528 | DOWN | | UP | 529 | State | | State | 530 | | | | 531 +---------+ +--------+ 532 ^ Y 533 | | 534 +-<---<------<-----<------<----<---+ 535 FEObject Admin Down/ 536 Association lost 538 Figure 4: The FE State Machine 540 The FE can only be in one of two states as indicated above. When the 541 FE is in the DOWN state, it is not forwarding packets. When the FE 542 is in the UP state it may be forwarding packets depending on the 543 configuration of its specific LFBs. 545 On start up the FE is in the DOWN state unless explicitly configured 546 by the CE to transition to the UP state. This MUST be done before 547 configuring any other LFBs that affect packet forwarding. 549 The FE transitions from the DOWN to the UP state when explicitly 550 configured to do so by the CE or when it looses its association with 551 the CE. It should be noted that what needs to be done for the FE to 552 properly complete the transition to the DOWN state is to stop packet 553 forwarding and that this may affect multiple LFBs. How this is 554 achieved is left as an implementation detail. 556 3.2.1. Pre-association 558 The ForCES interface is configured during the pre-association phase. 559 In a simple setup, the configuration is static and is read from a 560 saved config file. All the parameters for the association phase are 561 well known after the pre-association phase is complete. A protocol 562 such as DHCP may be used to retrieve the config parameters instead of 563 reading them from a static config file. Note, this will still be 564 considered static pre-association. Dynamic configuration may also 565 happen using the Fc, Ff and Fl reference points. Vendors may use 566 their own proprietary service discovery protocol to pass the 567 parameters. Essentially only guidelines are provided here and the 568 details are left to the implementation. 570 The following are scenarios reproduced from the Framework Document to 571 show a pre-association example. 573 <----Ff ref pt---> <--Fc ref pt-------> 574 FE Manager FE CE Manager CE 575 | | | | 576 | | | | 577 (security exchange) (security exchange) 578 1|<------------>| authentication 1|<----------->|authentication 579 | | | | 580 (FE ID, attributes) (CE ID, attributes) 581 2|<-------------| request 2|<------------|request 582 | | | | 583 3|------------->| response 3|------------>|response 584 (corresponding CE ID) (corresponding FE ID) 585 | | | | 586 | | | | 588 Figure 5: Examples of a message exchange over the Ff and Fc reference 589 points 590 <-----------Fl ref pt--------------> | 592 FE Manager FE CE Manager CE 593 | | | | 594 | | | | 595 (security exchange) | | 596 1|<------------------------------>| | 597 | | | | 598 (a list of CEs and their attributes) | 599 2|<-------------------------------| | 600 | | | | 601 (a list of FEs and their attributes) | 602 3|------------------------------->| | 603 | | | | 604 | | | | 606 Figure 6: An example of a message exchange over the Fl reference 607 point 609 Before the transition to the association phase, the FEM will have 610 established contact with the appropriate CEM component. 611 Initialization of the ForCES interface will have completed, and 612 authentication as well as capability discovery may be complete. Both 613 the FE and CE would have the necessary information for connecting to 614 each other for configuration, accounting, identification and 615 authentication purposes. To summarize, at the completion of this 616 stage both sides have all the necessary protocol parameters such as 617 timers, etc. The Fl reference point may continue to operate during 618 the association phase and may be used to force a disassociation of an 619 FE or CE. Because the pre-association phase is out of scope, these 620 details are not discussed any further in this specification. The 621 reader is referred to the framework document [RFC3746] for a slightly 622 more detailed discussion. 624 3.2.2. Post-association 626 In this phase, the FE and CE components communicate with each other 627 using the ForCES protocol (PL over TML) as defined in this document. 628 There are three sub-phases: 630 o Association Setup stage 632 o Established Stage 634 o Association Lost stage 636 3.2.2.1. Association Setup stage 638 The FE attempts to join the NE. The FE may be rejected or accepted. 639 Once granted access into the NE, capabilities exchange happens with 640 the CE querying the FE. Once the CE has the FE capability 641 information, the CE can offer an initial configuration (possibly to 642 restore state) and can query certain attributes within either an LFB 643 or the FE itself. 645 More details are provided in the protocol scenarios section. 647 On successful completion of this stage, the FE joins the NE and is 648 moved to the Established State. 650 3.2.2.2. Association Established stage 652 In this stage the FE is continuously updated or queried. The FE may 653 also send asynchronous event notifications to the CE or synchronous 654 heartbeat notifications if programmed to do so. This continues until 655 a termination occurs because of loss of connectivity or is initiated 656 by either the CE or the FE. 658 Refer to section on protocol scenarios Section 7 for more details. 660 3.2.2.3. Association Lost stage 662 In this state, both or either the CE or FE declare the other side is 663 no longer associated. The disconnection could be physically 664 initiated by either party for administrative purposes but may also be 665 driven by operation reasons such as loss of connectivity. 667 It should be noted that loss of connectivity between TMLs is not 668 necessarily indictive of loss of association between respective PL 669 layers unless the programmed FE Protocol Object time limit is 670 exceeded. In other words if the TML repairs the transport loss 671 before then, the association would still be valid. 673 When an association is lost between a CE and FE, the FE continues to 674 operate as instructed by the CE via the CE failover policy (for 675 further discussion refer to Section 8 and Appendix C). 677 For this revision of the protocol (as defined in this document), the 678 FE, upon re-association, MUST declare all the state it has as invalid 679 and retrieve new state. This approach is motivated by a desire for 680 simplicity (as opposed to efficiency). 682 3.3. Protocol Mechanisms 684 Various semantics are exposed to the protocol users via the PL header 685 including: Transaction capabilities, atomicity of transactions, two 686 phase commits, batching/parallelization, High Availability and 687 failover as well as command windows. 689 3.3.1. Transactions, Atomicity, Execution and Responses 691 In the master-slave relationship the CE instructs one or more FEs on 692 how to execute operations and how to report back the results. 694 This section details the different modes of execution that a CE can 695 order the FE(s) to perform in Section 3.3.1.1. It also describes the 696 different modes a CE can ask the FE(s) to format the responses back 697 after processing the operations requested. 699 3.3.1.1. Execution 701 There are 3 execution modes that could be requested for a batch of 702 operations spanning on one or more LFB selectors: 704 a. Transactional execute-all-or-none 706 b. Loose transactional execute-until-failure 708 c. Non-transactional continue-execute-on-failure 710 3.3.1.1.1. 'all-or-none' Atomic transaction 712 A transaction maybe atomic: 714 a. Within an FE alone 715 Example: updating multiple tables which are dependent on each 716 other. If updating one fails, then any others already updated 717 must be undone. 719 b. Distributed across the NE 720 Example: updating table(s) that are inter-dependent across 721 several FEs (such as L3 forwarding related tables). 723 For distributed transactional consistency across FEs, a classical 724 transactional protocol known as Two Phase Commit [2PCREF] is 725 supported. 727 3.3.1.1.2. Transaction Definition 729 We define a transaction as a collection of one or more ForCES 730 operations within one or more PL messages that MUST meet the ACIDity 731 properties[ACID], defined as: 733 o *Atomicity*. In a transaction involving two or more discrete 734 pieces of information, either all of the pieces are committed or 735 none are. 737 o *Consistency*. A transaction either creates a new and valid state 738 of data, or, if any failure occurs, returns all data to its state 739 before the transaction was started. 741 o *Isolation*. A transaction in process and not yet committed must 742 remain isolated from any other transaction. 744 o *Durability*. Committed data is saved by the system such that, 745 even in the event of a failure and system restart, the data is 746 available in its correct state. 748 There are cases where the CE knows exact memory and implementation 749 details of the FE such as in the case of a FE-CE pair from the same 750 vendor where the FE-CE pair is tightly coupled. In such a case, the 751 transactional operations maybe simplified further by extra 752 computation at the CE. We do not discuss this view further other 753 than to mention it is not dissallowed. For the purpose of 754 interopability, we define a classical transactional protocol known as 755 two phase commit which meets the ACID properties to be used for 756 transactions. 758 3.3.1.1.3. Transaction protocol 760 A 2PC [2PCREF] configuration message starts with the header flags 761 containg a SOT(start of transaction) and AT (Atomic Transaction) on 762 its first message configuration message. A transaction may span 763 multiple messages. It is up to the CE to keep track of the different 764 outstanding messages making up a transaction. As an example, one 765 could use the correlator field to mark transactions and a sequence 766 field to label the different messages within the same atomic 767 transaction. 769 Any failure notified by the FE causes the CE to execute an ABT (Abort 770 Transaction) to all FEs involved in the transaction, rolling back all 771 previously executed operations in the transaction. 773 [Editorial Note: We need to discuss how to issue the ABORT - flags vs 774 type] 776 The transaction commitment phase is signalled from the CE to the FE 777 by an empty EOT configuration message. 779 The FE MUST respond to the CE's EOT message. If no response is 780 received from the CE within a specified timeout, the transaction MUST 781 be aborted by the CE. 783 3.3.1.1.4. Recovery 785 Any of the participating FEs, or the CE, or the associations between 786 them, may fail after the EOT response message has left the FE and 787 before it has received all the responses, (possibly the EOT response 788 never reached the CE). 790 In this protocol revision, for sake of simplicity as indicated in 791 Section 3.2.2.3, an FE losing an association would be required to get 792 new state from the newly associated CE from scratch upon a 793 reassociation. The decision on what an FE should do after a lost 794 association is dictated by the CE Failover policy (refer to Section 8 795 and Section 6.2). 797 3.3.1.1.5. continue-execute-on-failure 799 In which several independent operations are targeted at one or more 800 LFB selectors. Execution continues at the FE when one or more 801 operations fail. This mode is signalled by a missing AT flag. 803 3.3.1.1.6. execute-until-failure 805 In which all operations are executed on FE sequentially until first 806 failure. The rest of the operations are not executed but everything 807 up to failed is not undone unlike the case of all-or-none execution. 809 Editorial note we need an extra main header flag to signal this . 810 EUF for lack of a better name. 812 3.3.1.1.7. Relation to Multipart messages 814 Multipart messages after the first one are indicated by the MOT flag 815 (Middle of Transaction). The first message is indicated by SOT and 816 the last by EOT. 818 Multi-part messages MUST be consistent in their use of execution 819 modes. If the first message starts with one mode (such as continue- 820 execute-on-failure mode), then it implies the rest that are part of 821 the same multi-part messages do. Any inconsitency implies an error 822 and a cancelled transaction in which all messages are dropped and the 823 sender NACKED. 825 3.3.2. Heartbeating Mechanism 827 Hearbeats between FEs and CEs are traffic sensitive. A HB is sent 828 only if no PL traffic is sent between the CE and FE within a 829 configured interval. This has the effect of reducing the amount of 830 HB traffic in the case of busy PL periods. 832 A HB can be sourced by either the CE or FE. When sourced by the CE, 833 a response can be requested (similar to the ICMP ping protocol). The 834 FE can only generate HBs in the case of being configured to do so by 835 the CE. Refer to Section 6.2.1 and Section 6.9 for details. 837 3.3.3. FE Object and FE protocol LFBs 839 All PL messages operate on LFB constructs as this provides more 840 flexibility for future enhancements. This means that maintenance and 841 configurability of FEs, NE, as well as the ForCES protocol itself 842 must be expressed in terms of this LFB architecture. For this reason 843 special LFBs are created to accomodate this need. 845 In addition, this shows how the ForCES protocol itself can be 846 controlled by the very same type of structures (LFBs) it uses to 847 control functions such as IP forwarding, filtering, etc. 849 To achieve this, the following speacilized LFBs are introduced: 851 o FE Protocol LFB which is used to control the ForCES protocol. 853 o FE Object LFB which is used to controls attributes relative to the 854 FE itself. Such attributes include FEState (refer to model 855 draft), vendor, etc. 857 These LFBs are detailed in Section 6.2. 859 3.3.4. Scaling by Concurrency 861 It is desirable that the PL layer not become the bottleneck when 862 larger bandwidth pipes become available. To pick a mythical example 863 in today's terms, if a 100Gbps pipe is available and there is 864 sufficient work then the PL layer should be able to take advantage of 865 this and use all of the 100Gbps pipe. Two mechanisms are provided to 866 achieve this. The first one is batching and the second one is a 867 command window. 869 Batching is the ability to send multiple commands (such as Config) in 870 one PDU. The size of the batch will be affected by, amongst other 871 things, the path MTU. The commands may be part of the same 872 transaction or part of unrelated transactions that are independent of 873 each other. 875 Command windowing allows for pipelining of independent transactions 876 which do not affect each other. Each independent transaction could 877 consist of one or more batches. 879 3.3.4.1. Batching 881 There are several batching levels at different protocol hierarchies. 883 o multiple PL PDUs can be aggregated under one TML message 885 o multiple LFB classes and instances (as indicated in the LFB 886 selector) can be addressed within one PL PDU 888 o Multiple operations can be addressed to a single LFB class and 889 instance 891 3.3.4.2. Command Pipelining 893 The protocol allows any number of messages to be issued by the CE 894 before the corresponding acknowledgments (if requested) have been 895 returned by the FE. Hence pipelining is inherently supported by the 896 protocol. Matching responses with requests messages can be done 897 using the correlator field in the message header. 899 4. TML Requirements 901 The requirements below are expected to be delivered by the TML. This 902 text does not define how such mechanisms are delivered. As an 903 example they could be defined to be delivered via hardware or between 904 2 or more TML processes on different CEs or FEs in protocol level 905 schemes. 907 Each TML must describe how it contributes to achieving the listed 908 ForCES requirements. If for any reason a TML does not provide a 909 service listed below a justification needs to be provided. 911 1. Reliability 912 As defined by RFC 3654, section 6 #6. 914 2. Security 915 TML provides security services to the ForCES PL. TML layer 916 should support the following security services and describe how 917 they are achieved. 919 * Endpoint authentication of FE and CE. 921 * Message Authentication 923 * Confidentiality service 925 3. Congestion Control 926 The congestion control scheme used needs to be defined. The 927 congestion control mechanism defined by the TML should prevent 928 the FE from being overloaded by the CE. Additionally, the 929 circumstances under which notification is sent to the PL to 930 notify it of congestion must be defined. 932 4. Uni/multi/broadcast addressing/delivery if any 933 If there is any mapping between PL and TML level Uni/Multi/ 934 Broadcast addressing it needs to be defined. 936 5. HA decisions 937 It is expected that availability of transport links is the TML's 938 responsibility. However, on config basis, the PL layer may wish 939 to participate in link failover schemes and therefore the TML 940 must support this capability. 941 Please refer to Section 8 for details. 943 6. Encapsulations used. 944 Different types of TMLs will encapsulate the PL messages on 945 different types of headers. The TML needs to specify the 946 encapsulation used. 948 7. Prioritization 949 It is expected that the TML will be able to handle up to 8 950 priority levels needed by the PL layer and will provide 951 preferential treatment. 952 TML needs to define how this is achieved. 954 8. The requirement for supporting up to 8 priority levels does not 955 mean that the underlying TML MUST be capable of handling up to 8 956 priority levels. In such an event the priority levels should be 957 divided between the available TML priotity levels. For example, 958 if the TML only support 2 priority levels, the 0-3 could go in 959 one TML priority level, while 4-7 could go in the other. 961 9. Protection against DoS attacks 962 As described in the Requirements RFC 3654, section 6 964 4.1. TML Parameterization 966 It is expected that it should be possible to use a configuration 967 reference point, such as the FEM or the CEM, to configure the TML. 969 Some of the configured parameters may include: 971 o PL ID 973 o Connection Type and associated data. For example if a TML uses 974 IP/TCP/UDP then parameters such as TCP and UDP ports, IP addresses 975 need to be configured. 977 o Number of transport connections 979 o Connection Capability, such as bandwidth, etc. 981 o Allowed/Supported Connection QoS policy (or Congestion Control 982 Policy) 984 5. Message encapsulation 986 All PL layer PDUs start with a common header [Section 5.1] followed 987 by a one or more TLVs [Section 5.2] which may nest other TLVs 988 [Section 5.2.1]. 990 5.1. Common Header 992 0 1 2 3 993 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 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 |version| rsvd | Message Type | Length | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Source ID | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Destination ID | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | Correlator | 1002 | | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | Flags | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 Figure 7: Common Header 1009 The message is 32 bit aligned. 1011 Version (4 bit): 1012 Version number. Current version is 1. 1014 rsvd (4 bit): 1015 Unused at this point. A receiver should not interpret this 1016 field. Senders SHOULD set it to zero. 1018 Message Type (8 bits): 1019 Commands are defined in Section 6. 1021 Length (16 bits): 1022 length of header + the rest of the message in DWORDS (4 byte 1023 increments). 1025 Source ID (32 bit): 1027 Dest ID (32 bit): 1029 * Each of the source and Dest IDs are 32 bit IDs which are 1030 unique NE-wide and which recognize the termination points of 1031 a ForCES PL message. 1033 * IDs allow multi/broad/unicast addressing with the following 1034 approach: 1036 a. A split address space is used to distinguish FEs from 1037 CEs. Even though we can assume that in a large NE there 1038 are typically two or more orders of magnitude more FEs 1039 than CEs, the address space is split uniformly for 1040 simplicity. 1042 b. The address space allows up to 2^30 (over a billion) CEs 1043 and the same amount of FEs. 1045 0 1 2 3 1046 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 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 |TS | sub-ID | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 Figure 8: ForCES ID Format 1053 c. The 2 most significant bits called Type Switch (TS) are 1054 used to split the ID space as follows: 1056 A. TS Corresponding ID range Assignment 1058 B. -- ---------------------- ---------- 1060 C. 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 1062 D. 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 1064 E. 0b10 0x80000000 to 0xBFFFFFFF reserved 1066 F. 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 1067 16) 1069 G. 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 1071 H. 0b11 0xFFFFFFFD all CEs broadcast 1073 I. 0b11 0xFFFFFFFE all FEs broadcast 1075 J. 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast 1077 * Multicast or broadcast IDs are used to group endpoints (such 1078 as CEs and FES). As an example one could group FEs in some 1079 functional group, by assigning a multicast ID. Likewise, 1080 subgroups of CEs that act, for instance, in a back-up mode 1081 may be assigned a multicast ID to hide them from the FE. 1083 * We donot discuss how a particular multicast ID is associated 1084 to a given group though we note that it could be done via 1085 configuration process. The list of IDs an FE owns or is part 1086 of are listed on the FE Object LFB. 1088 Correlator (64 bits) 1089 This field is set by the CE to correlate ForCES Requests messages 1090 with the corresponding Response messages from the Fe. 1091 Essentially it is a cookie. The Correlator is handled 1092 transparently by the FE, i.e. for a particular Request message it 1093 will assign the same correlator value in the corresponding 1094 Response message. In the case where the message from the CE does 1095 not elicit a response, this field may not be useful. 1097 The Correlator field could be used in many ways by the CE. For 1098 example, the CE could split the Correlator into a 32-bit 1099 transactional identifier and 32-bit message sequence identifier. 1100 Another example a 64 bit pointer to a context block. 1102 Flags(32 bits): 1103 Identified so far: 1105 0 1 2 3 1106 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 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | | | | | | 1109 |ACK| Pri | EM|TP | Reserved | 1110 | | | | | | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 - ACK: ACK indicator(2 bit) 1114 The ACK indicator flag is only used by the CE when sending a 1115 Config Message(Section 6.5.1) or a HB message (Section 6.9) 1116 to indicate to the message receiver whether or not a config 1117 response is required by the sender. Note that for all other 1118 messages than Config Message this flag MUST be ignored. 1120 The flag values are defined as below: 1122 'NoACK' (00) - to indicate the message receiver not to 1123 send any response message back to this message sender. 1125 'SuccessACK'(01) - to inidcate the message receiver to 1126 send a response message back only when the message has 1127 been successfully processed by the receiver. 1129 'FailureACK'(10) - to indicate the message receiver to 1130 send a response message back only when there is any 1131 failure for the receiver to process(execute) the message. 1132 In other words, if the message can be processed 1133 successfully, the sender will not expect any response 1134 from the receiver. 1136 'AlwaysACK' (11) - to indicate the message receiver to 1137 send a response message back in any case. 1139 Note that in above definitions, the term success implies a 1140 complete execution without any failure of the message. 1141 Anything else than a complete successful execution is defined 1142 as a failure for the message processing. As a result, for 1143 the execution modes (defined in Section 3.3.1.1) like 1144 execute-all-or-none, execute-until-failure, and continue- 1145 execute-on-failure, if any single operation among several 1146 operations in the same message fails, it will be treated as a 1147 failure and result in a response if the ACK indicator has 1148 been set to 'FailureACK' or 'AlwaysACK'. 1150 Also note that messages other than Config and HB Messages, 1151 whose requirements for responses are described by the message 1152 definitions in Section 6, we summarise the default 1153 requirements of these messages and the expected responses 1154 below. Detailed descriptions can be found in the individual 1155 message definitions: 1157 + Association Setup Message always expects a response. 1159 + Association Teardown Message, and Packet Redirect 1160 Message, never expect responses. 1162 + Query Message always expects a response. 1164 + Any kind of response messages never expect further 1165 responses. 1167 - Pri: Priority (3 bits) 1168 ForCES protocol defines 8 different levels of priority (0-7). 1169 The priority level can be used to distinguish between 1170 different protocol message types as well as between the same 1171 message type. For example, the REDIRECT PACKET message could 1172 have different priorities to distinguish between Routing 1173 protocols packets and ARP packets being redirected from FE to 1174 CE. The Normal priority level is 1. 1176 - EM: Execution mode (2 bits) 1177 There are 3 execution modes refer to Section 3.3.1.1 for 1178 details. 1180 `execute-all-or-none` (01) 1182 `execute-until-failure` (10) 1184 `continue-execute-on-failure` (11) 1186 binary 00 is reserved 1188 - TP: Transaction phase (2 bits) 1189 A message from the CE to the FE within a transaction could be 1190 indicative of the different phases the transaction is in. 1191 Refer to Section 3.3.1.1.3 for details. 1193 `MOT (Middle of transaction)` (00) 1195 `SOT (start of transaction)` (01) 1197 `EOT (end of transaction)` (10) 1199 `ABT (abort)` (11) 1201 5.2. Type Length Value(TLV) Structuring 1202 0 1 2 3 1203 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 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | TLV Type | variable TLV Length | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Value (Data of size TLV length) | 1208 ~ ~ 1209 ~ ~ 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 Figure 10: TLV 1214 TLV Type (16): 1215 The TLV type field is two octets, and indicates the 1216 type of data encapsulated within the TLV. 1218 TLV Length (16): 1219 The TLV Length field is two octets, and indicates 1220 the length of this TLV including the TLV Type, TLV 1221 Length, and the TLV data. 1223 TLV Value (variable): 1224 The TLV Value field carries the data. For 1225 extensibility, the TLV value may infact be a TLV. 1226 TLVs must be 32 bit aligned. 1228 5.2.1. Nested TLVs 1230 TLV values can be other TLVs. This provides the benefits of protocol 1231 flexibility (being able to add new extensions by introducing new TLVs 1232 when needed). The nesting feature also allows for an conceptual 1233 optimization with the XML LFB definitions to binary PL representation 1234 (reperesented by nested TLVs). 1236 5.2.2. Scope of the T in TLV 1238 The "Type" value in TLV is of global scope. This means that wherever 1239 in the PDU hierachy a Type has global connotations. This is a design 1240 choice to ease debugging of the protocol. 1242 5.3. ILV 1244 A slight variation of the TLV known as the ILV is introduced to allow 1245 to the "T" to be a 32-bit index that is a ForCES element ID. The 1246 Length part of the ILV is also 32 bits to allow of the referenced 1247 data to be arbitrarily large in size. 1249 It should be noted that the "I" values are of local scope and are 1250 defined by the data declarations from the LFB definition. Refer to 1251 Section 6.1.1.1.8 for discussions on usage of ILVs. 1253 6. Protocol Construction 1255 6.1. Protocol Grammar 1257 The protocol construction is formally defined using a BNF-like syntax 1258 to describe the structure of the PDU layout. This is matched to a 1259 precise binary format later in the document. 1261 Since the protocol is very flexible and hierachical in nature, it is 1262 easier at times to see the visualization layout. This is provided in 1263 Section 6.1.2 1265 6.1.1. Protocol BNF 1267 The format used is based on RFC 2234. The terminals of this gramar 1268 are flags, IDcount, IDs, KEYID, and encoded data, described after the 1269 grammar. 1271 1. A TLV will have the word "-TLV" suffix at the end of its name 1273 2. An ILV will have the word "-ILV" suffix at the end of its name 1275 3. / is used to separate alternatives 1277 4. parenthesised elements are treated as a single item 1279 5. * before an item indicates 0 or more repetitions 1281 6. 1* before an item indicates 1 or more repetitions 1283 7. [] around an item indicates that it is optional (equal to *0) 1285 The BNF of the PL level PDU is as follows: 1287 PL level PDU := MAINHDR [MAIN-TLV] 1288 MAIN-TLV := [LFBselect-TLV] / [REDIRECT-TLV] / 1289 [ASResult-TLV] / [ASTreason-TLV] 1290 LFBselect-TLV := LFBCLASSID LFBInstance OPER-TLV 1291 OPER-TLV := 1*PATH-DATA-TLV 1292 PATH-DATA-TLV := PATH [DATA] 1293 PATH := flags IDcount IDs [SELECTOR] 1294 SELECTOR := KEYINFO-TLV 1295 DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / 1296 1*PATH-DATA-TLV 1297 KEYINFO-TLV := KEYID FULLDATA-TLV 1298 SPARSEDATA-TLV := encoded data that may have optionally 1299 appearing elements 1300 FULLDATA-TLV := encoded data element which may nest 1301 further FULLDATA-TLVs 1302 RESULT-TLV := Holds result code and optional FULLDATA-TLV 1304 o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR 1305 also defines the content. As an example the content of a "config" 1306 message would be different from an "association" message. 1308 o MAIN-TLV is one of several TLVs that could follow the Mainheader. 1309 The appearance of these TLVs is message type specific. 1311 o LFBCLASSID is a 32 bit unique identifier per LFB class defined at 1312 class Definition time. 1314 o LFBInstance is a 32 bit unique instance identifier of an LFB class 1316 o OPER-TLV uses the Type field in the TLV to uniquely identify the 1317 type of operation i.e one of {SET, GET, DEL,etc.} depending on the 1318 message type. 1320 o PATH-DATA-TLV identifies the exact element targeted and may have 1321 zero or more paths associated with it. The last PATH-DATA-TLV in 1322 the case of nesting of paths via the DATA construct in the case of 1323 SET requests and GET response is terminated by encoded data or 1324 response in the form of either FULLDATA-TLV or SPARSEDATA-TLV or 1325 RESULT-TLV. 1327 o PATH provides the path to the data being referenced. 1329 * flags (16 bits) are used to further refine the operation to be 1330 applied on the Path. More on these later. 1332 * IDcount(16 bit): count of 32 bit IDs 1333 * IDs: zero or more 32bit IDs (whose count is given by IDcount) 1334 defining the main path. Depending on the flags, IDs could be 1335 field IDs only or a mix of field and dynamic IDs. Zero is used 1336 for the special case of using the entirety of the containing 1337 context as the result of the path. 1339 o SELECTOR is an optional construct that further defines the PATH. 1340 Currently, the only defined selector is the KEYINFO-TLV, used for 1341 selecting an array entry by the value of a key field. The 1342 presence of a SELECTOR is correct only when the flags also 1343 indicate its presence. A mismatch is a protocol format error. 1345 o A KEYINFO TLV contains information used in content keying. 1347 * A KeyID is used in a KEYINFO TLV. It indicates which key for 1348 the current array is being used as the content key for array 1349 entry selection. 1351 * The key's data is the data to look for in the array, in the 1352 fields identified by the keyfield. The information is encoded 1353 according to the rules for the contents of a FULLDATA-TLV, and 1354 represent the field or fields which make up the key identified 1355 by the KEYID. 1357 o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV or 1 1358 or more further PATH-DATA selection. FULLDATA and SPARSEDATA are 1359 only allowed on SET requests, or on responses which return content 1360 information (GET-RESPONSE for example). PATH-DATA may be included 1361 to extend the path on any request. 1363 * Note: Nested PATH-DATA TLVs are supported as an efficiency 1364 measure to permit common subexpression extraction. 1366 * FULLDATA and SPARSEDATA contain "the data" whose path has been 1367 selected by the PATH. Refer to Section 6.1.1.1 for details. 1369 o RESULT contains the indication of whether the individual SET 1370 succeeded. If there is an indication for verbose response, then 1371 SET-RESPONSE will also contain the FULLDATA TLV showing the data 1372 that was set. RESULT-TLV is included on the assumption that 1373 individual parts of a SET request can succeed or fail separately. 1375 In summary this approach has the following characteristic: 1377 o There can be one or more LFB Class + InstanceId combo targeted in 1378 a message (batch) 1380 o There can one or more operations on an addressed LFB classid+ 1381 instanceid combo(batch) 1383 o There can be one or more path targets per operation (batch) 1385 o Paths may have zero or more data values associated (flexibility 1386 and operation specific) 1388 It should be noted that the above is optimized for the case of a 1389 single classid+instance targeting. To target multiple instances 1390 within the same class, multiple LFBselect are needed. 1392 6.1.1.1. Discussion on Grammar 1394 In the case of FULLDATA encoding, data is packed in such a way that a 1395 receiver of such data with knowledge of the path can correlate what 1396 it means by infering in the LFB definition. This is an optimization 1397 that helps reducing the amount of description for the data in the 1398 protocol. 1400 In other words: 1402 It is assumed that the type of the data can be inferred by the 1403 context in which data is used. Hence, data will not include its type 1404 information. The basis for the inference is typically the LFB class 1405 id and the path. 1407 It is expected that a substantial amount of operations in ForCES will 1408 need to reference optional data within larger structures. For this 1409 reason, the SPARSEDATA encoding is introduced to make it easier to 1410 encapsulate optionaly appearing data elements. 1412 6.1.1.1.1. Data Packing Rules 1414 The scheme for encoding data used in this doc adheres to the 1415 following rules: 1417 o The Value ("V" of TLV) of FULLDATA TLV will contain the data being 1418 transported. This data will be as was described in the LFB 1419 definition. 1421 o Variable sized data within a FULLDATA TLV will be encapsulated 1422 inside another FULLDATA TLV inside the V of the outer TLV. For 1423 example of such a setup refer to Appendix E and Appendix D. 1425 o In the case of FULLDATA TLVs: 1427 o When a table is refered to in the PATH (ids) of a PATH-DATA-TLV, 1428 then the FULLDATA's "V" will contain that table's row content 1429 prefixed by its 32 bit index/subscript. OTOH, when PATH flags are 1430 00, the PATH may contain an index pointing to a row in table; in 1431 such a case, the FULLDATA's "V" will only contain the content with 1432 the index in order to avoid ambiguity. 1434 6.1.1.1.2. Path Flags 1436 The following flags are currently defined: 1438 o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present 1439 following this path information, and should be considered in 1440 evaluating the path. 1442 o FIND-EMPTY Bit: This must not be set if the F_SEL_KEY bit is set. 1443 This must only be used on a create operation. If set, this 1444 indicates that although the path identifies an array, the SET 1445 operation should be applied to the first unused element in the 1446 array. The result of the operation will not have this flag set, 1447 and will have the assigned index in the path. 1449 6.1.1.1.3. Relation of operational flags with global message flags 1451 Should be noted that other applicable flags such as atomicity 1452 indicators as well as verbosity result formaters are in the main 1453 headers flags area. 1455 6.1.1.1.4. Content Path Selection 1457 The KEYINFO TLV describes the KEY as well as associated KEY data. 1458 KEYs, used for content searches, are restricted and described in the 1459 LFB definition. 1461 6.1.1.1.5. LFB select TLV 1463 The LFB select TLV is an instance of TLV defined in Section 5.2. The 1464 definition is as below: 1466 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 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | Type = LFBselect | Length | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | LFB Class ID | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | LFB Instance ID | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | Operation TLV | 1475 . . 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 ~ ... ~ 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Operation TLV | 1480 . . 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 Figure 12: PL PDU layout 1485 Type: 1486 The type of the TLV is "LFBselect" 1488 Length: 1489 Length of the TLV including the T and L fields, in bytes. 1491 LFB Class ID: 1492 This field uniquely recognizes the LFB class/type. 1494 LFB Instance ID: 1495 This field uniquely identifies the LFB instance. 1497 Operation TLV: 1498 It describes an operation nested in the LFB select TLV. Note 1499 that usually there SHOULD be at least one Operation TLV present 1500 for an LFB select TLV, but for Association Setup Message defined 1501 in Section 6.4.1, Operation TLV is totally optional, therefore 1502 there might be no any Operation TLV followed in the LFB select 1503 TLV there. 1505 6.1.1.1.6. Operation TLV 1507 The Operation TLV is an instance of TLV Idefined in Section 5.2. It 1508 is assumed that specific operations are identified by the Type code 1509 of the TLV. Definitions for individual Types of operation TLVs are 1510 in corresponding message description sections followed. 1512 SET and GET Requests do not have result information (they are 1513 requests). SET and GET Responses have result information. SET and 1514 GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. 1516 For a GET responses, individual gets which succeed will have FULLDATA 1517 TLVs added to the leaf paths to carry the requested data. For GET 1518 elements that fail, instead of the FULLDATA TLV there will be a 1519 RESULT TLV. 1521 For a SET response, each FULLDATA or or SPARSEDATA TLV in the 1522 original request will be replaced with a RESULT TLV in the response. 1523 If the request was for Ack-fail, then only those items which failed 1524 will appear in the response. If the request was for ack-all, then 1525 all elements of the request will appear in the response with RESULT 1526 TLVs. 1528 Note that if a SET request with a structure in a FULLDATA is issued, 1529 and some field in the structure is invalid, the FE will not attempt 1530 to indicate which field was invalid, but rather will indicate that 1531 the operation failed. Note further that if there are multiple errors 1532 in a single leaf path-data / FULLDATA, the FE can select which error 1533 it chooses to return. So if a FULLDATA for a SET of a structure 1534 attempts to write one field which is read only, and attempts to set 1535 another field to an invalid value, the FE can return whatever error 1536 it likes. 1538 A SET operation on a variable length element with a length of 0 for 1539 the item is not the same as deleteing it. If the CE wishes to delete 1540 then the DEL operation should be used whether the the path refers to 1541 an array element or an optional structure element. 1543 6.1.1.1.7. Result TLV 1545 A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 1546 byte) value. 1548 The defined values are 1550 0 = success 1552 1 = no such object 1554 2 = permission denied 1556 3 = invalid value (the encoded data could not validly be stored in 1557 the field) 1559 4 = invalid array creation (when the subscript in an array create is 1560 not allowed) 1561 255 = unspecified error (for when the FE can not decide what went 1562 wrong) 1564 6.1.1.1.8. DATA TLV 1566 A FULLDATA TLV has "T"= FULLDATA, and a 16bit Length followed by the 1567 data value/contents. Likewise, a SPARSEDATA TLV has "T" = 1568 SPARSEDATA, a 16bit Length followed by the data value/contents. In 1569 the case of the SPARSEDATA each element in the Value part of the TLV 1570 will be further encapsulated in an ILV. Rules: 1572 1. Both ILVs and TLVs MUST 32 bit aligned. If need be they MUST be 1573 padded to achieve the alignement. 1575 2. FULLDATA TLV may be used at a particular path only if every 1576 element at that path level is present. This requirement holds 1577 whether the fields are fixed or variable length, mandatory or 1578 optional. 1580 * If a FULLDATA TLV is used, the encoder MUST layout data for 1581 each element ordered by the order in which the data was 1582 defined in the LFB specification. This ensures the decoder is 1583 guaranteed to retrieve the data. 1585 * In the case of a SPARSEDATA we dont need to order since the 1586 "I" in the ILV uniquely identifies the element. 1588 3. Inside a FULLDATA TLV 1590 * The values for atomic, fixed-length fields are given without 1591 any TLV or ILV encapsulation. 1593 * The values for atomic, variable-length fields are given inside 1594 FULLDATA TLVs. 1596 4. Inside a SPARSE TLV 1598 * the values for atomic fields may be given with ILVs (32-bit 1599 index, 32-bit length) 1601 5. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot 1602 contain a FULLDATA. This is because it is hard to disambiguate 1603 ILV since an I is 32 bit and a T is 16 bit. 1605 6. A FULLDATA can also contain a FULLDATA for variable sized 1606 elements. The decoding disambiguation is assumed from rule #3 1607 above. 1609 6.1.1.1.9. SET and GET Relationship 1611 It is expected that a GET-RESPONSE would satisfy the following 1612 desires: 1614 o it would have exactly the same path definitions as that was sent 1615 in the GET. The only difference being a GET-RESPONSE will contain 1616 FULLDATA TLVs. 1618 o it should be possible that one would take the same GET-RESPONSE 1619 and convert it to a SET-REPLACE successfully by merely changing 1620 the T in the operational TLV. 1622 o There are exceptions to this rule: 1624 1. When a KEY selector is used with a path in a GET operation, 1625 that selector is not returned in the GET-RESPONSE; instead the 1626 cooked result is returned. Refer to the examples using KEYS 1627 to see this. 1629 2. When dumping a whole table in a GET, the GET-RESPONSE, merely 1630 editing the T to be SET will endup overwritting the table. 1632 6.1.2. Protocol Visualization 1634 The figure below shows a general layout of the PL PDU. A main header 1635 is followed by one or more LFB selections each of which may contain 1636 one or more operation. 1638 main hdr (Config in this case) 1639 | 1640 | 1641 +--- T = LFBselect 1642 | | 1643 | +-- LFBCLASSID 1644 | | 1645 | | 1646 | +-- LFBInstance 1647 | | 1648 | +-- T = SET-CREATE 1649 | | | 1650 | | +-- // one or more path targets 1651 | | // with their data here to be added 1652 | | 1653 | +-- T = DEL 1654 | . | 1655 | . +-- // one or more path targets to be deleted 1656 | 1657 | 1658 +--- T = LFBselect 1659 | | 1660 | +-- LFBCLASSID 1661 | | 1662 | | 1663 | +-- LFBInstance 1664 | | 1665 | + -- T= SET-REPLACE 1666 | | 1667 | | 1668 | + -- T= DEL 1669 | | 1670 | + -- T= SET-REPLACE 1671 | 1672 | 1673 +--- T = LFBselect 1674 | 1675 +-- LFBCLASSID 1676 | 1677 +-- LFBInstance 1678 . 1679 . 1680 . 1682 Figure 13: PL PDU logical layout 1683 The figure below shows an example general layout of the operation 1684 within a targetted LFB selection. The idea is to show the different 1685 nesting levels a path could take to get to the target path. 1687 T = SET-CREATE 1688 | | 1689 | +- T = Path-data 1690 | | 1691 | + -- flags 1692 | + -- IDCount 1693 | + -- IDs 1694 | | 1695 | +- T = Path-data 1696 | | 1697 | + -- flags 1698 | + -- IDCount 1699 | + -- IDs 1700 | | 1701 | +- T = Path-data 1702 | | 1703 | + -- flags 1704 | + -- IDCount 1705 | + -- IDs 1706 | + -- T = KEYINFO 1707 | | + -- KEY_ID 1708 | | + -- KEY_DATA 1709 | | 1710 | + -- T = FULLDATA 1711 | + -- data 1712 | 1713 | 1714 T = SET-REPLACE 1715 | | 1716 | +- T = Path-data 1717 | | | 1718 | | + -- flags 1719 | | + -- IDCount 1720 | | + -- IDs 1721 | | | 1722 | | + -- T = FULLDATA 1723 | | + -- data 1724 | +- T = Path-data 1725 | | 1726 | + -- flags 1727 | + -- IDCount 1728 | + -- IDs 1729 | | 1730 | + -- T = FULLDATA 1731 | + -- data 1732 T = DEL 1733 | 1734 +- T = Path-data 1735 | 1736 + -- flags 1737 + -- IDCount 1738 + -- IDs 1739 | 1740 +- T = Path-data 1741 | 1742 + -- flags 1743 + -- IDCount 1744 + -- IDs 1745 | 1746 +- T = Path-data 1747 | 1748 + -- flags 1749 + -- IDCount 1750 + -- IDs 1751 + -- T = KEYINFO 1752 | + -- KEY_ID 1753 | + -- KEY_DATA 1754 +- T = Path-data 1755 | 1756 + -- flags 1757 + -- IDCount 1758 + -- IDs 1760 Figure 14: Sample operation layout 1762 6.2. Core ForCES LFBs 1764 There are two LFBs that are used to control the operation of the 1765 ForCES protocol and to interact with FEs and CEs: 1767 FE Protocol LFB 1769 FE Object LFB 1771 Although these LFBs have the same form and interface as other LFBs, 1772 they are special in many respects: they have fixed well-known LFB 1773 Class and Instance IDs. They are statically defined (no dynamic 1774 instantiation allowed) and their status cannot be changed by the 1775 protocol: any operation to change the state of such LFBs (for 1776 instance, in order to disable the LFB) must result in an error. 1777 Moreover, these LFBs must exist before the first ForCES message can 1778 be sent or received. All attributes in these LFBs must have pre- 1779 defined default values. Finally, these LFBs do not have input or 1780 output ports and do not integrate into the intra-FE LFB topology. 1782 6.2.1. FE Protocol LFB 1784 The FE Protocol LFB is a logical entity in each FE that is used to 1785 control the ForCES protocol. The FE Protocol LFB Class ID is 1786 assigned the value 0x1. The FE Protocol LFB Instance ID is assigned 1787 the value 0x1. There MAY be one and only one instance of the FE 1788 Protocol LFB in an FE. The values of the attributes in the FE 1789 Protocol LFB have pre-defined default values that are specified here. 1790 Unless explicit changes are made to these values using Config 1791 messages from the CE, these default values MUST be used for the 1792 operation of the protocol. 1794 The formal definition of the FE Protocol LFB can be found in 1795 Appendix C 1797 The FE Protocol LFB consists of the following elements: 1799 o FE Protocol capabilities (read-only): 1801 * Supported ForCES protocol version(s) by the FE 1803 * Any TML capability description(s) 1805 o FE Protocol attributes (can be read and set): 1807 * Current version of the ForCES protocol 1809 * FE unicast ID 1811 * FE multicast ID(s) list - this is a list of multicast IDs that 1812 the FE belongs to. These IDs are configured by the CE. 1814 * CE heartbeat policy - This policy, along with the parameter 'CE 1815 Heartbeat Dead Interval (CE HDI)' as described below defines 1816 the operating parameters for the FE to check the CE liveness. 1817 The policy values with meanings are listed as below: 1819 0(default) - This policy specifies that CE will send a 1820 Heartbeat Message to FE whenever CE reaches a time interval 1821 within which no other PL messages were sent from CE to FE; 1822 refer to Section 3.3.2 for details. The CE HDI attribute as 1823 described below is tied to this policy. If the FE has not 1824 received any PL messages within CE HDI period it declares 1825 the connectivity lost. The CE independently chooses the 1826 time interval to send the Heartbeat messages to FE - care 1827 must be exercised to ensure the CE->FE HB interval is 1828 smaller than the CE HDI assigned. 1830 1 - The CE will not generate any HB messages. This actually 1831 means CE does not want the FE to check the CE liveness. 1833 Others - reserved. 1835 * CE Heartbeat Dead Interval (CE HDI) - The time interval the FE 1836 uses to check the CE liveness. If FE has not received any 1837 messages from CE within this time interval, FE deduces lost 1838 connectivity which implies that the CE is dead or the 1839 association to the CE is lost. Default value 30 s. 1841 * FE heartbeat policy - This policy, along with the parameter 'FE 1842 Heartbeat Interval (FE HI)', define the operating parameters 1843 for how the FE should behave so that the CE can deduce its 1844 liveliness. The policy values and the meanings are: 1846 0(default) - The FE should not generate any Heartbeat 1847 messages. In this scenario, the CE is responsible for 1848 checking FE liveness by setting the PL header ACK flag of 1849 the message it sends to AlwaysACK. The FE responds to CE 1850 whenever CE sends such Heartbeat Request Message. Refer to 1851 Section 6.9 and Section 3.3.2 for details. 1853 1 - This policy specifies that FE must actively send a 1854 Heartbeat Message if it reaches the time interval assigned 1855 by the FE HI as long as no other messages were sent from FE 1856 to CE during that interval as described in Section 3.3.2. 1858 Others - Reserved. 1860 * FE Heartbeat Interval (FE HI) - The time interval the FE should 1861 use to send HB as long as no other messages were sent from FE 1862 to CE during that interval as described in Section 3.3.2. The 1863 deafult value for a FE HI is 500ms. 1865 * Primary CEID - The CEID that the FE is associated with. 1867 * Backup CEs - The list of backup CEs an FE is associated with. 1868 Refer to Section 8 for details. 1870 * FE restart policy - This specifies the behavior of the FE 1871 during a FE restart. The restart may be from a FE failure or 1872 other reasons that have made FE down and then need to restart. 1873 The values are defined as below: 1875 0(default)- just restart the FE from scratch. In this case, 1876 the FE should start from pre-association phase definitely. 1878 1 - restart the FE from an intermediate state. In this 1879 case, the FE itself decides from which state it restarts. 1880 For example, if the FE still keeps enough infomation of pre- 1881 association phase after some failure, it then has the right 1882 just to start from post-associatin phase with this policy 1883 case. 1885 Others - Reserved 1887 * CE failover policy - This specifies the behavior of the FE 1888 during a CE failure and restart time interval, or when the FE 1889 loses the CE association. It should be noted that this policy 1890 in the case of HA only takes effect after total failure to 1891 connect to a new CE. A timeout parameter, the CE Timeout 1892 Interval (CE TI) is associated with this attribute. Values of 1893 this policy are defined as below: 1895 0(default) - The FE should continue running and do what it 1896 can even without an associated CE. This basically makes the 1897 FE support CE Graceful restart. Note that if the CE still 1898 has not been restarted or hasn't been associated back to the 1899 FE, after the CE TI has expired, the FE will go 1900 operationally down. 1902 1 - FE should go down to stop functioning immediately. 1904 2 - FE should go inactive to temporarily stop functioning. 1905 If the CE still has not been restarted after a time interval 1906 of specified by the CE TI, the FE will go down completely. 1908 Others - Reserved 1910 * CE Timeout Interval (CE TI) - The time interval associated with 1911 the CE failover policy case '0' and '2'. The default value is 1912 set to 300 seconds. Note that it is advisable to set the CE TI 1913 value much higher than the CE Heartbeat Dead Interval (CE HDI) 1914 since the effect of expiring this parameter is devastating to 1915 the operation of the FE. 1917 6.2.2. FE Object LFB 1919 The FE Object LFB is a logical entity in each FE and contains 1920 attributes relative to the FE itself, and not to the operation of the 1921 ForCES protocol. 1923 The formal definition of the FE Object LFB can be found in [FE- 1924 MODEL]. The model captures the high level properties of the FE that 1925 the CE needs to know to begin working with the FE. The class ID for 1926 this LFB Class is also assigned in [FE-MODEL]. The singular instance 1927 of this class will always exist, and will always have instance ID 1 1928 within its class. It is common, although not mandatory, for a CE to 1929 fetch much of the attribute and capability information from this LFB 1930 instance when the CE begins controlling the operation of the FE. 1932 6.3. Semantics of message Direction 1934 Recall: The PL protocol provides a master(CE)-Slave(FE) relationship. 1935 The LFBs reside at the FE and are controlled by CE. 1937 When messages go from the CE, the LFB Selector (Class and instance) 1938 refers to the destination LFB selection which resides in the FE. 1940 When messages go from the FE->CE, the LFB Selector (Class and 1941 instance) refers to the source LFB selection which resides in the FE. 1943 6.4. Association Messages 1945 The ForCES Association messages are used to establish and teardown 1946 associations between FEs and CEs. 1948 6.4.1. Association Setup Message 1950 This message is sent by the FE to the CE to setup a ForCES 1951 association between them. This message could also be used by CEs to 1952 join a ForCES NE, however CE-to-CE communication is not covered by 1953 this protocol. 1955 Message transfer direction: 1956 FE to CE 1958 Message Header: 1959 The Message Type in the header is set MessageType= 1960 'AssociationSetup'. The ACK flag in the header MUST be ignored, 1961 and the association setup message always expects to get a response 1962 from the message receiver (CE) whether the setup is successful or 1963 not. The Correlator field in the header is set, so that FE can 1964 correlate the response coming back from CE correctly. The Src ID 1965 (FE ID) may be set to O in the header which means that the FE 1966 would like the CE to assign a FE ID for the FE in the setup 1967 response message. 1969 Message body: 1970 The association setup message body optionally consist of one or 1971 more LFB select TLV as described in Section 6.1.1.1.5. The 1972 association setup message only operates toward the FE Object and 1973 FE Protocol LFBs, therefore, the LFB class ID in the LFB select 1974 TLV only points to these two kinds of LFBs. There is only one FE 1975 object LFB and one FE protocol LFB per FE, therefore, the LFB 1976 instance IDs for the FE object LFB and the FE protocol LFB are 1977 usually assigned to the value 0x1. 1979 The Operation TLV in the LFB select TLV is defined as a 'REPORT' 1980 operation. More than one attribute may be announced in this 1981 message using REPORT operation to let the FE declare its 1982 configuration parameters in an unsolicited manner. These may 1983 contain attributes like the Heart Beat Interval parameter, etc. 1984 The Operation TLV for event notificationis is defined below. 1986 Operation TLV for Association Setup: 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 | Type = REPORT | Length | 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | PATH-DATA-TLV for REPORT | 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 Type: 1995 Only one operation type is defined for the association setup 1996 message: 1998 Type = "REPORT" --- this type of operation is for FE to 1999 report something to CE. 2001 PATH-DATA-TLV for REPORT: 2002 This is generically a PATH-DATA-TLV format that has been defined 2003 in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF 2004 definition. The PATH-DATA-TLV for REPORT operation MAY contain 2005 FULLDATA-TLV(s) but SHALL NOT contain any RESULT-TLV in the data 2006 format. The RESULT-TLV is defined in Section 6.1.1.1.7 and the 2007 FULLDATA-TLV is defined in Section 6.1.1.1.8. 2009 To better illustrate the above PDU format, we show a tree structure 2010 for the format as below: 2012 main hdr (eg type = Association setup) 2013 | 2014 | 2015 +--- T = LFBselect 2016 | | 2017 | +-- LFBCLASSID = FE object 2018 | | 2019 | | 2020 | +-- LFBInstance = 0x1 2021 | | 2022 +--- T = LFBselect 2023 | 2024 +-- LFBCLASSID = FE Protocol object 2025 | 2026 | 2027 +-- LFBInstance = 0x1 2028 | 2029 +-- Path-data to one or more attibutes 2030 including suggested HB parameters 2032 Figure 16 2034 6.4.2. Association Setup Response Message 2036 This message is sent by the CE to the FE in response to the Setup 2037 message. It indicates to the FE whether the setup is successful or 2038 not, i.e. whether an association is established. 2040 Message transfer direction: 2041 CE to FE 2043 Message Header: 2044 The Message Type in the header is set MessageType= 2045 'AssociationSetupResponse'. The ACK flag in the header MUST be 2046 ignored, and the setup response message never expects to get any 2047 more response from the message receiver (FE). The Correlator 2048 field in the header MUST keep the same as that of the association 2049 setup message to be responded, so that the association setup 2050 message sender can correlate the response correctly. The Dst ID 2051 in the header will be set to some FE ID value assigned by the CE 2052 if the FE had requested that in the setup message (by SrcID = 0). 2054 Message body: 2055 The association setup response message body only consists of one 2056 TLV, the Association Result TLV, the format of which is as 2057 follows: is: 2059 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 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | Type = ASRresult | Length | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | Association Setup Result | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 Type (16 bits): 2067 The type of the TLV is "ASRresult". 2069 Length (16 bits): 2070 Length of the TLV including the T and L fields, in bytes. 2072 Association Setup Result (32 bits): 2073 This indicates whether the setup msg was successful or whether 2074 the FE request was rejected by the CE. the defined values are: 2076 0 = success 2078 1 = FE ID invalid 2080 2 = too many associations 2082 3 = permission denied 2084 6.4.3. Association Teardown Message 2086 This message can be sent by the FE or CE to any ForCES element to end 2087 its ForCES association with that element. 2089 Message transfer direction: 2090 CE to FE, or FE to CE (or CE to CE) 2092 Message Header: 2093 The Message Type in the header is set MessageType= 2094 "AssociationTeardown". The ACK flag MUST be ignored, and the 2095 association teardown message never expects to get any further 2096 response from the message receiver. The correlator field in the 2097 header is also ignored owing to no further response expected. 2099 Message Body: 2100 The association teardown message body only consists of one TLV, 2101 the Association Teardown Reason TLV, the format of which is as 2102 follows: 2104 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 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 | Type = ASTreason | Length | 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 | Teardown Reason | 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 Type (16 bits): 2112 The type of the TLV is "ASTreason". 2114 Length (16 bits): 2115 Length of the TLV including the T and L fields, in bytes. 2117 Teardonw Reason (32 bits): 2118 This indicates the reason why the association is being 2119 terminated. Several reason codes are defined as follows. 2121 0 - normal teardown by administrator 2123 1 - error - loss of heartbeats 2125 2 - error - out of bandwidth 2127 3 - error - out of memory 2129 4 - error - application crash 2131 255 - error - other or unspecified 2133 6.5. Configuration Messages 2135 The ForCES Configuration messages are used by CE to configure the FEs 2136 in a ForCES NE and report the results back to the CE. 2138 6.5.1. Config Message 2140 This message is sent by the CE to the FE to configure LFB attributes 2141 in the FE. This message is also used by the CE to subscribe/ 2142 unsubscribe to LFB events. 2144 As usual, a config message is composed of a common header followed by 2145 a message body that consists of one or more TLV data format. 2146 Detailed description of the message is as below. 2148 Message transfer direction: 2149 CE to FE 2151 Message Header: 2152 The Message Type in the header is set MessageType= 'Config'. The 2153 ACK flag in the header can be set to any value defined in 2154 Section 5.1, to inidcate whether or not a response from FE is 2155 expected by the message ( the flag is set to 'NoACK' or 2156 'AlwaysACK'), or to indicate in which case a response is 2157 generated (the flag is set to 'SuccessACK' or 'FailureACK'). The 2158 default behavior for the ACK flag is set to always expect a full 2159 response from FE. This happens when the ACK flag is not set to 2160 any defined value. The correlator field in the messge header 2161 MUST be set if a response is expected, so that CE can correlate 2162 the response correctly. The correlator field can be ignored if 2163 no response is expected. 2165 Message body: 2166 The config message body MUST consist of at least one LFB select 2167 TLV as described in Section 6.1.1.1.5. The Operation TLV in the 2168 LFB select TLV is defined below. 2170 Operation TLV for Config: 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 | Type | Length | 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 | PATH-DATA-TLV | 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 Type: 2179 The operation type for config message. two types of operations 2180 for the config message are defined: 2182 Type = "SET" --- this operation is to set LFB attributes 2184 Type = "DEL" --- this operation to delete some LFB 2185 attributes 2187 PATH-DATA-TLV: 2188 This is generically a PATH-DATA-TLV format that has been defined 2189 in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF 2190 definition. The restriction on the use of PATH-DATA-TLV for SET 2191 operation is, it MUST contain either a FULLDATA or SPARSEDATA 2192 TLV(s), but MUST NOT contain any RESULT-TLV. The restriction on 2193 the use of PATH-DATA-TLV for DEL operation is it MAY contain 2194 FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain any RESULT- 2195 TLV. The RESULT-TLV is defined in Section 6.1.1.1.7 and FULLDATA 2196 and SPARSEDATA TLVs is defined in Section 6.1.1.1.8. 2198 *Note: For Event subscription, the events will be defined by the 2199 individual LFBs. 2201 To better illustrate the above PDU format, we show a tree structure 2202 for the format as below: 2204 main hdr (eg type = config) 2205 | 2206 | 2207 +--- T = LFBselect 2208 | | 2209 | +-- LFBCLASSID = target LFB class 2210 | | 2211 | | 2212 | +-- LFBInstance = target LFB instance 2213 | | 2214 | | 2215 | +-- T = operation { SET } 2216 | | | 2217 | | +-- // one or more path targets 2218 | | // associated with FULL or SPARSEDATA TLV(s) 2219 | | 2220 | +-- T = operation { DEL } 2221 | | | 2222 | | +-- // one or more path targets 2224 6.5.2. Config Response Message 2226 This message is sent by the FE to the CE in response to the Config 2227 message. It indicates whether the Config was successful or not on 2228 the FE and also gives a detailed response regarding the configuration 2229 result of each attribute. 2231 Message transfer direction: 2232 FE to CE 2234 Message Header: 2235 The Message Type in the header is set MessageType= 'Config 2236 Response'. The ACK flag in the header is always ignored, and the 2237 config response message never expects to get any further response 2238 from the message receiver (CE). The Correlator field in the 2239 header MUST keep the same as that of the config message to be 2240 responded, so that the config message sender can correlate the 2241 response with the original message correctly. 2243 Message body: 2244 TThe config message body MUST consist of at least one LFB select 2245 TLV as described in Section 6.1.1.1.5. The Operation TLV in the 2246 LFB select TLV is defined below. 2248 Operation TLV for Config Response: 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 | Type | Length | 2252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2253 | PATH-DATA-TLV | 2254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 Type: 2257 The operation type for config response message. Two types of 2258 operations for the config response message are defined: 2260 Type = "SET-RESPONSE" --- this operation is for the 2261 response of SET operation of LFB attributes 2263 Type = "DEL-RESPONSE" --- this operation is for the 2264 response of DELete operation of LFB attributes 2266 PATH-DATA-TLV: 2267 This is generically a PATH-DATA-TLV format that has been defined 2268 in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF 2269 definition. The restriction on the use of PATH-DATA-TLV for SET- 2270 RESPONSE operation is it MUST contain RESULT-TLV(s). The 2271 restriction on the use of PATH-DATA-TLV for DEL-RESPONSE 2272 operation is it also MUST contain RESULT-TLV(s). The RESULT-TLV 2273 is defined in Section 6.1.1.1.7. 2275 6.6. Query Messages 2277 The ForCES query messages are used by the CE to query LFBs in the FE 2278 for informations like LFB attributes, capabilities, statistics, etc. 2279 Query Messages include the Query Message and the Query Response 2280 Message. 2282 6.6.1. Query Message 2284 As usual, a query message is composed of a common header and a 2285 message body that consists of one or more TLV data format. Detailed 2286 description of the message is as below. 2288 Message transfer direction: 2289 from CE to FE. 2291 Message Header: 2292 The Message Type in the header is set to MessageType= 'Query'. 2293 The ACK flag in the header is always ignored, and a full response 2294 for a query message is always expected. The Correlator field in 2295 the header is set, so that CE can locate the response back from 2296 FE correctly. 2298 Message body: 2299 The query message body MUST consist of at least one LFB select 2300 TLV as described in Section 6.1.1.1.5. The Operation TLV in the 2301 LFB select TLV is defined below. 2303 Operation TLV for Query: 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 | Type = GET | Length | 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 | PATH-DATA-TLV for GET | 2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 Figure 22 2313 Type: 2314 The operation type for query. One operation type is defined: 2316 Type = "GET" --- this operation is to request to get LFB 2317 attributes. 2319 PATH-DATA-TLV for GET: 2320 This is generically a PATH-DATA-TLV format that has been defined 2321 in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF 2322 definition. The restriction on the use of PATH-DATA-TLV for GET 2323 operation is it MUST NOT contain any SPARSEDATA or FULLDATA TLV 2324 and RESULT-TLV in the data format. 2326 To better illustrate the above PDU format, we show a tree structure 2327 for the format as below: 2329 main hdr (type = Query) 2330 | 2331 | 2332 +--- T = LFBselect 2333 | | 2334 | +-- LFBCLASSID = target LFB class 2335 | | 2336 | | 2337 | +-- LFBInstance = target LFB instance 2338 | | 2339 | | 2340 | +-- T = operation { GET } 2341 | | | 2342 | | +-- // one or more path targets 2343 | | 2344 | +-- T = operation { GET } 2345 | | | 2346 | | +-- // one or more path targets 2347 | | 2349 Figure 23 2351 6.6.2. Query Response Message 2353 When receiving a query message, the receiver should process the 2354 message and come up with a query result. The receiver sends the 2355 query result back to the message sender by use of the Query Response 2356 Message. The query result can be the information being queried if 2357 the query operation is successful, or can also be error codes if the 2358 query operation fails, indicating the reasons for the failure. 2360 A query response message is also composed of a common header and a 2361 message body consists of one or more TLVs describing the query 2362 result. Detailed description of the message is as below. 2364 Message transfer direction: 2365 from FE to CE. 2367 Message Header: 2368 The Message Type in the header is set to MessageType= 2369 'QueryResponse'. The ACK flag in the header is ignored. As a 2370 response itself, the message does not expect a further response 2371 anymore. The Correlator field in the header MUST keep the same 2372 as that of the query message to be responded, so that the query 2373 message sender can keep track of the response. 2375 Message body: 2376 The query response message body MUST consist of at least one LFB 2377 select TLV as described in Section 6.1.1.1.5. The Operation TLV 2378 in the LFB select TLV is defined below. 2380 Operation TLV for Query Response: 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 | Type = GET-RESPONSE | Length | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | PATH-DATA-TLV for GET-RESPONSE | 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 Figure 24 2390 Type: 2391 The operation type for query response. One operation type is 2392 defined: 2394 Type = "GET-RESPONSE" --- this operation is to response to 2395 get operation of LFB attributes. 2397 PATH-DATA-TLV for GET-RESPONSE: 2398 This is generically a PATH-DATA-TLV format that has been defined 2399 in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF 2400 definition. The PATH-DATA-TLV for GET-RESPONSE operation MAY 2401 contain SPARSEDATA TLV, FULLDATA TLV and/or RESULT-TLV(s) in the 2402 data encoding. The RESULT-TLV is defined in Section 6.1.1.1.7 2403 and the SPARSEDATA and FULLDATA TLVs are defined in 2404 Section 6.1.1.1.8. 2406 6.7. Event Notification Message 2408 Event Notification Message is used by FE to asynchronously notify CE 2409 of events that happen in the FE. 2411 All events happen in FE are subscribable by CE. A config message is 2412 used by CE to subscribe/unsubscribe for an event in FE. To subscribe 2413 to an event is usually by specifying to the path of such an event as 2414 described by FE-Model and defined by LFB library. 2416 As usual, an Event Notification Message is composed of a common 2417 header and a message body that consists of one or more TLV data 2418 format. Detailed description of the message is as below. 2420 Message Transfer Direction: 2421 FE to CE 2423 Message Header: 2424 The Message Type in the message header is set to 2425 MessageType = 'EventNotification'. The ACK flag in the header 2426 MUST be ignored, and the event notification message does not 2427 expect any response from the receiver. The Correlator field in 2428 the header is also ignored because the response is not expected. 2430 Message Body: 2431 The event notification message body MUST consist of at least one 2432 LFB select TLV as described in Section 6.1.1.1.5. The Operation 2433 TLV in the LFB select TLV is defined below. 2435 Operation TLV for Event Notification: 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | Type = REPORT | Length | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 | PATH-DATA-TLV for REPORT | 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2443 Type: 2444 Only one operation type is defined for the event notification 2445 message: 2447 Type = "REPORT" --- this type of operation is for FE to 2448 report something to CE. 2450 PATH-DATA-TLV for REPORT: 2451 This is generically a PATH-DATA-TLV format that has been defined 2452 in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF 2453 definition. The PATH-DATA-TLV for REPORT operation MAY contain 2454 FULLDATA or SPARSEDATA TLV(s) but MUST NOT contain any RESULT-TLV 2455 in the data format. 2457 To better illustrate the above PDU format, we show a tree structure 2458 for the format as below: 2460 main hdr (type = Event Notification) 2461 | 2462 | 2463 +--- T = LFBselect 2464 | | 2465 | +-- LFBCLASSID = target LFB class 2466 | | 2467 | | 2468 | +-- LFBInstance = target LFB instance 2469 | | 2470 | | 2471 | +-- T = operation { REPORT } 2472 | | | 2473 | | +-- // one or more path targets 2474 | | // associated with FULL/SPARSE DATA TLV(s) 2475 | +-- T = operation { REPORT } 2476 | | | 2477 | | +-- // one or more path targets 2478 | | // associated with FULL/SPARSE DATA TLV(s) 2480 Figure 26 2482 6.8. Packet Redirect Message 2484 Packet redirect message is used to transfer data packets between CE 2485 and FE. Usually these data packets are IP packets, though they may 2486 sometimes associated with some metadata generated by other LFBs in 2487 the model, or they may occasionally be other protocol packets, which 2488 usually happen when CE and FE are jointly implementing some high- 2489 touch operations. Packets redirected from FE to CE are the data 2490 packets that come from forwarding plane, and usually are the data 2491 packets that need high-touch operations in CE,or packets for which 2492 the IP destination address is the NE. Packets redirected from CE to 2493 FE are the data packets that come from the CE and are decided by CE 2494 to put into forwarding plane in FE. 2496 Supplying such a redirect path between CE and FE actually leads to a 2497 possibility of this path being DoS attacked. Attackers may 2498 maliciously try to send huge spurious packets that will be redirected 2499 by FE to CE, making the redirect path been congested. ForCES 2500 protocol and the TML layer will jointly supply approaches to prevent 2501 such DoS attack. To define a specific 'Packet Redirect Message' 2502 makes TML and CE able to distinguish the redirect messages from other 2503 ForCES protocol messages. 2505 By properly configuring related LFBs in FE, a packet can also be 2506 mirrored to CE instead of purely redirected to CE, i.e., the packet 2507 is duplicated and one is redirected to CE and the other continues its 2508 way in the LFB topology. 2510 The Packet Redirect Message data format is formated as follows: 2512 Message Direction: 2513 CE to FE or FE to CE 2515 Message Header: 2516 The Message Type in the header is set to MessageType= 2517 'PacketRedirect'. The ACK flags in the header MUST be ignored, 2518 and no response is expected by this message. The correlator field 2519 is also ignored because no response is expected. 2521 Message Body: 2522 Consists of (at least) one or more than one TLV that describes the 2523 packet redirection. The TLV is specifically a Redirect TLV (with 2524 the TLV Type="Redirect"). Detailed data format of a Redirect TLV 2525 for packet redirect message is as below: 2527 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 2528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2529 | Type = Redirect | Length | 2530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 | LFB Class ID | 2532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2533 | LFB Instance ID | 2534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 | Meta Data TLV | 2536 . . 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 | Redirect Data TLV | 2539 . . 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2542 Figure 27 2544 LFB class ID: 2545 There are only two possible LFB classes here, the 'RedirectSink' 2546 LFB or the 'RedirectSource' LFB[FE-MODEL]. If the message is from 2547 FE to CE, the LFB class should be 'RedirectSink'. If the message 2548 is from CE to FE, the LFB class should be 'RedirectSource'. 2550 Instance ID: 2551 Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. 2553 Meta Data TLV: 2554 This is a TLV that specifies meta-data associated with followed 2555 redirected data. The TLV is as follows: 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | Type = META-DATA | Length | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | Meta Data ILV | 2561 . . 2562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 ~ ... ~ 2564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2565 | Meta Data ILV | 2566 . . 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 Figure 28 2571 Meta Data ILV: 2572 This is an Identifier-Length-Value format that is used to describe 2573 one meta data. The ILV has the format as: 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2576 | Meta Data ID | 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 | Length | 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 | Meta Data Value | 2581 . . 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 Where, Meta Data ID is an identifier for the meta data, which is 2585 statically assigned by the LFB definition. This actually implies 2586 a Meta Data ID transcoding mechanism may be necessary if a 2587 metadata traverses several LFBs while these LFBs define the 2588 metadata with different Meta Data IDs. 2590 Usually there are two meta data that are necessary for CE-FE 2591 redirect operation. One is the redirected data type (e.g., IP 2592 packet, TCP packet, or UDP Packet). For an FE->CE redirect 2593 operation, redirected packet type meta data is usually a meta data 2594 specified by a Classifier LFB that filter out redirected packets 2595 from packet stream and sends the packets to Redirect Sink LFB. 2596 For an CE->FE redirect operation, the redirected packet type meta 2597 data is usually directly generated by CE. 2599 Another meta data that should be associated with redirected data 2600 is the port number in a redirect LFB. For a RedirectSink LFB, the 2601 port number meta data tells CE from which port in the lFB the 2602 redirected data come. For a RedriectSource LFB, via the meta 2603 data, CE tells FE which port in the LFB the redirected data should 2604 go out. 2606 Redirect Data TLV 2607 This is a TLV describing one packet of data to be directed via the 2608 redirect operation. The TLV format is as follows: 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 | Type = REDIRECTDATA | Length | 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2613 | Redirected Data | 2614 . . 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2617 Redirected Data: 2618 This field presents the whole packet that is to be redirected. 2619 The packet should be 32bits aligned. 2621 6.9. Heartbeat Message 2623 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 2624 to asynchronously notify one or more other ForCES elements in the 2625 same ForCES NE on its liveness. 2627 A Heartbeat Message is sent by a ForCES element periodically. The 2628 parameterization and policy definition for heartbeats for an FE is 2629 managed as attributes of the FE protocol LFB, and can be set by CE 2630 via a config message. The Heartbeat message is a little different 2631 from other protocol messages in that it is only composed of a common 2632 header, with the message body left empty. Detailed description of 2633 the message is as below. 2635 Message Transfer Direction: 2636 FE to CE, or CE to FE 2638 Message Header: 2639 The Message Type in the message header is set to MessageType = 2640 'Heartbeat'. Section 3.3.2 describes the HB mechanisms used. 2641 The ACK flag in the header can be set to 'NoACK' or 'AlwaysACK' 2642 when the HB is sent. When set to 'AlwaysACK', the HB Message 2643 sender is always expecting a response from its receiver. When a 2644 response is sent it is always an echo of the original message 2645 with reversed IDs and the ACK information set to 'NoACK'. When 2646 not soliciting for response(default behavior), the ACK flag is 2647 set to 'NoACK' The correlator field in the HB message header must 2648 be set accordingly when a response is expected so that a receiver 2649 can correlate the response correctly. The correlator field can 2650 be ignored if no response is expected. Also note that by virtue 2651 of Heartbeat policies defined in Section 6.2.1 only CE can send a 2652 HB Message with a response request. 2654 Message Body: 2655 The message body is empty for the Heartbeat Message. 2657 6.10. Operation Summary 2659 The following table summarizes the TLVs that compose messages, and 2660 the applicabiity of operation TLVs to the messages. 2662 +---------------------------+-----------+---------------------------+ 2663 | Messages | TLVs | Operations | 2664 +---------------------------+-----------+---------------------------+ 2665 | Association Setup | LFBselect | REPORT | 2666 | | | | 2667 | Association Setup | ASRresult | None | 2668 | Response | | | 2669 | | | | 2670 | Association Teardown | ASTreason | None | 2671 | | | | 2672 | Config | LFBselect | SET, DEL | 2673 | | | | 2674 | Config Response | LFBselect | SET-RESPONSE, | 2675 | | | DEL-RESPONSE | 2676 | | | | 2677 | Query | LFBselect | GET | 2678 | | | | 2679 | Query Response | LFBselect | GET-RESPONSE | 2680 | | | | 2681 | Event Notification | LFBselect | REPORT | 2682 | | | | 2683 | Packet Redirect | Redirect | None | 2684 | | | | 2685 | Heartbeat | None | None | 2686 +---------------------------+-----------+---------------------------+ 2688 The following talbe summarises the applicability of the FULL/SPARSE 2689 DATA TLV and the RESULT TLV to the Operation TLVs. 2691 +--------------+--------------+----------------+------------+ 2692 | Operations | FULLDATA TLV | SPARSEDATA TLV | RESULT TLV | 2693 +--------------+--------------+----------------+------------+ 2694 | SET | MAY | MAY | MUST NOT | 2695 | | | | | 2696 | SET-RESPONSE | MAY | MUST NOT | MUST | 2697 | | | | | 2698 | DEL | MAY | MAY | MUST NOT | 2699 | | | | | 2700 | DEL-RESPONSE | MAY | MUST NOT | MUST | 2701 | | | | | 2702 | GET | MUST NOT | MUST NOT | MUST NOT | 2703 | | | | | 2704 | GET-RESPONSE | MUST | MUST NOT | MAY | 2705 | | | | | 2706 | REPORT | MAY | MUST NOT | MUST NOT | 2707 +--------------+--------------+----------------+------------+ 2709 7. Protocol Scenarios 2711 7.1. Association Setup state 2713 The associations among CEs and FEs are initiated via Association 2714 setup message from the FE. If a setup request is granted by the CE, 2715 a successful setup response message is sent to the FE. If CEs and 2716 FEs are operating in an insecure environment then the security 2717 association have to be established between them before any 2718 association messages can be exchanged. The TML will take care of 2719 establishing any security associations. 2721 This is typically followed by capability query, topology query, etc. 2722 When the FE is ready to start forwarding data traffic, it sends a FE 2723 UP Event message to the CE. When the CE is ready, it by enabling the 2724 FE by setting the FEStatus to Adminup [Refer to Model draft for 2725 details]. This indicates to the FE to start forwarding data traffic. 2726 At this point the association establishment is complete. These 2727 sequences of messages are illustrated in the Figure below. 2729 FE PL CE PL 2731 | | 2732 | Asso Setup Req | 2733 |---------------------->| 2734 | | 2735 | Asso Setup Resp | 2736 |<----------------------| 2737 | | 2738 | LFBx Query capability | 2739 |<----------------------| 2740 | | 2741 | LFBx Query Resp | 2742 |---------------------->| 2743 | | 2744 | FEO Query (Topology) | 2745 |<----------------------| 2746 | | 2747 | FEO Query Resp | 2748 |---------------------->| 2749 | | 2750 | Config FEO Adminup | 2751 |<----------------------| 2752 | | 2753 | FEO Config-Resp | 2754 |---------------------->| 2755 | | 2756 | FEO UP Event | 2757 |---------------------->| 2758 | | 2760 Figure 31: Message exchange between CE and FE to establish an NE 2761 association 2763 On successful completion of this state, the FE joins the NE. 2765 7.2. Association Established state or Steady State 2767 In this state the FE is continously updated or queried. The FE may 2768 also send asynchronous event notifications to the CE or synchronous 2769 heartbeat messages. This continues until a termination (or 2770 deactivation) is initiated by either the CE or FE. Figure below 2771 helps illustrate this state. 2773 FE PL CE PL 2775 | | 2776 | Heart Beat | 2777 |<---------------------------->| 2778 | | 2779 | Heart Beat | 2780 |----------------------------->| 2781 | | 2782 | Config-set LFBy (Event sub.) | 2783 |<-----------------------------| 2784 | | 2785 | Config Resp LFBy | 2786 |----------------------------->| 2787 | | 2788 | Config-set LFBx Attr | 2789 |<-----------------------------| 2790 | | 2791 | Config Resp LFBx | 2792 |----------------------------->| 2793 | | 2794 |Config-Query LFBz (Stats) | 2795 |<--------------------------- -| 2796 | | 2797 | Query Resp LFBz | 2798 |----------------------------->| 2799 | | 2800 | FE Event Report | 2801 |----------------------------->| 2802 | | 2803 | Config-Del LFBx Attr | 2804 |<-----------------------------| 2805 | | 2806 | Config Resp LFBx | 2807 |----------------------------->| 2808 | | 2809 | Packet Redirect LFBx | 2810 |----------------------------->| 2811 | | 2812 | Heart Beat | 2813 |<-----------------------------| 2814 . . 2815 . . 2816 | | 2818 Figure 32: Message exchange between CE and FE during steady-state 2819 communication 2820 Note that the sequence of messages shown in the figure serve only as 2821 examples and the messages exchange sequences could be different from 2822 what is shown in the figure. Also, note that the protocol scenarios 2823 described in this section do not include all the different message 2824 exchanges which would take place during failover. That is described 2825 in the HA section 8. 2827 8. High Availability Support 2829 The ForCES protocol provides mechanisms for CE redundancy and 2830 failover, in order to support High Availability as defined in 2831 [RFC3654]. FE redundancy and FE to FE interaction is currently out 2832 of scope of this draft. There can be multiple redundant CEs and FEs 2833 in a ForCES NE. However, at any time there can only be one Primary 2834 CE controlling the FEs and there can be multiple secondary CEs. The 2835 FE and the CE PL are aware of the primary and secondary CEs. This 2836 information (primary, secondary CEs) is configured in the FE, CE PLs 2837 during pre-association by FEM, CEM respectively. Only the primary CE 2838 sends Control messages to the FEs. 2840 There are 2 modes of HA defined in the ForCES protocol, Report 2841 Primary Mode and Report All Mode. The Report Primary Mode is the 2842 default mode of the protocol, in which the FEs only associate with 2843 one CE (primary) at a time. The Report All mode is for future study 2844 and not part of the current protocol version. In this mode, the FE 2845 would establish association with multiple CEs (primary and secondary) 2846 and report events, packets, Heart Beats to all the CEs. However, 2847 only the primary CE would configure/control the FE in this mode as 2848 well. This helps with keeping state between CEs synchronized, 2849 although it does not guarantee synchronization. 2851 The HA Modes are configured during Association setup phase, currently 2852 only Report Primary Mode is configured. A CE-to-CE synchronization 2853 protocol will be needed to support fast failover as well as address 2854 some of the corner cases, however this will not be defined by the 2855 ForCES protocol (since it is out of scope). 2857 During a communication failure between the FE and CE (which is caused 2858 due to CE or link reasons, i.e. not FE related), the TML on the FE 2859 will trigger the FE PL regarding this failure. This can also be 2860 detected using the HB messages between FEs and CEs. The 2861 communication failure (detected via either of the two means described 2862 before) is considered as a loss of association between the CE and 2863 corresponding FE and the FE PL must establish association with the 2864 secondary CE at this point. During this phase, if the original 2865 primary CE comes alive and starts sending any commands to the FE, the 2866 FE should ignore those messages and send an Event to all CEs 2867 indicating its change in Primary CE. Thus the FE only has one 2868 primary CE at a time. 2870 An explicit message (Config message setting Primary CE attribute in 2871 ForCES Protocol object) from the primary CE, can also be used to 2872 change the Primary CE for an FE during normal protocol operation. 2874 Also note that the FEs in a ForCES NE could also use a multicast 2875 CEID, i.e. they are associated with a group of CEs (assumes some form 2876 of CE-CE synchronization protocol). In this case the loss of 2877 association would mean that communication with the entire multicast 2878 group of CEs has been lost. The mechanisms described above will 2879 apply for this case as well during the loss of association. 2881 These two scenarios (Report All, Report Primary) have been 2882 illustrated in the figures below. 2884 FE CE Primary CE Secondary 2885 | | | 2886 | Asso Estb,Caps exchg | | 2887 1 |<--------------------->| | 2888 | | | 2889 | Asso Estb,Caps|exchange | 2890 2 |<----------------------|------------------->| 2891 | | | 2892 | All msgs | | 2893 3 |<--------------------->| | 2894 | | | 2895 | packet redirection,|events, HBs | 2896 4 |-----------------------|------------------->| 2897 | | | 2898 | FAILURE | 2899 | | 2900 | Event Report (pri CE down) | 2901 5 |------------------------------------------->| 2902 | | 2903 | All Msgs | 2904 6 |------------------------------------------->| 2906 Figure 33: CE Failover for Report All mode 2907 FE CE Primary CE Secondary 2908 | | | 2909 | Asso Estb,Caps exchg | | 2910 1 |<--------------------->| | 2911 | | | 2912 | All msgs | | 2913 2 |<--------------------->| | 2914 | | | 2915 | | | 2916 | FAILURE | 2917 | | 2918 | Asso Estb,Caps exchange | 2919 3 |<------------------------------------------>| 2920 | | 2921 | Event Report (pri CE down) | 2922 4 |------------------------------------------->| 2923 | | 2924 | All Msgs | 2925 5 |------------------------------------------->| 2927 Figure 34: CE Failover for Report Primary Mode 2929 8.1. Responsibilities for HA 2931 TML level - Transport level: 2933 1. The TML controls logical connection availability and failover. 2935 2. The TML also controls peer HA managements. 2937 At this level, control of all lower layers, for example transport 2938 level (such as IP addresses, MAC addresses etc) and associated links 2939 going down are the role of the TML. 2941 PL Level: 2942 All the other functionality including configuring the HA behavior 2943 during setup, the CEIDs are used to identify primary, secondary CEs, 2944 protocol Messages used to report CE failure (Event Report), Heartbeat 2945 messages used to detect association failure, messages to change 2946 primary CE (config - move), and other HA related operations described 2947 before are the PL responsibility. 2949 To put the two together, if a path to a primary CE is down, the TML 2950 would take care of failing over to a backup path, if one is 2951 available. If the CE is totally unreachable then the PL would be 2952 informed and it will take the appropriate actions described before. 2954 9. Security Considerations 2956 ForCES architecture identifies several levels of security in 2957 [RFC3746]. ForCES PL uses security services provided by the ForCES 2958 TML layer. TML layer provides security services such as endpoint 2959 authentication service, message authentication service and 2960 confidentiality service. Endpoint authentication service is invoked 2961 at the time of pre-association connection establishment phase and 2962 message authentication is performed whenever FE or CE receives a 2963 packet from its peer. 2965 Following are the general security mechanism that needs to be in 2966 place for ForCES PL layer. 2968 o Security mechanism are session controlled that is once the 2969 security is turned ON depending upon the chosen security level (No 2970 Security, Authentication only, Confidentiality), it will be in 2971 effect for the entire duration of the session. 2973 o Operator should configure the same security policies for both 2974 primary and backup FE's and CE's (if available). This will ensure 2975 uniform operations, and to avoid unnecessary complexity in policy 2976 configuration. 2978 o ForCES PL endpoints SHOULD pre-established connections with both 2979 primary and backup CE's. This will reduce the security messages 2980 and enable rapid switchover operations for HA. 2982 9.1. No Security 2984 When No security is chosen for ForCES protocol communication, both 2985 endpoint authentication and message authentication service needs be 2986 performed by ForCES PL layer. Both these mechanism are weak and does 2987 not involve cryptographic operation. Operator can choose "No 2988 security" level when the ForCES protocol endpoints are within an 2989 single box. 2991 In order to have interoperable and uniform implementation across 2992 various security levels, each CE and FE endpoint MUST implement this 2993 level. The operations that are being performed for "No security" 2994 level is required even if lower TML security services are being used. 2996 9.1.1. Endpoint Authentication 2998 Each CE and FE PL layer maintain set of associations list as part of 2999 configuration. This is done via CEM and FEM interfaces. FE MUST 3000 connect to only those CE's that are configured via FEM similarly CE 3001 should accept the connection and establish associations for the FE's 3002 which are configured via CEM. CE should validate the FE identifier 3003 before accepting the connection during the pre-association phase. 3005 9.1.2. Message authentication 3007 When CE or FE generates initiates a message, the receiving endpoint 3008 MUST validate the initiator of the message by checking the common 3009 header CE or FE identifiers. This will ensure proper protocol 3010 functioning. We recommend this extra step processing even if the 3011 underlying TLM layer security services. 3013 9.2. ForCES PL and TML security service 3015 This section is applicable if operator wishes to use the TML security 3016 services. ForCES TML layer MUST support one or more security service 3017 such as endpoint authentication service, message authentication 3018 service, confidentiality service as part of TML security layer 3019 functions. It is the responsibility of the operator to select 3020 appropriate security service and configure security policies 3021 accordingly. The details of such configuration is outside the scope 3022 of ForCES PL and is depending upon the type of transport protocol, 3023 nature of connection. 3025 All these configurations should be done prior to starting the CE and 3026 FE. 3028 When certificates-based authentication is being used at TML layer, 3029 the certificate can use ForCES specific naming structure as 3030 certificate names and accordingly the security policies can be 3031 configured at CE and FE. 3033 9.2.1. Endpoint authentication service 3035 When TML security services are enabled. ForCES TML layer performs 3036 endpoint authentication. Security association is established between 3037 CE and FE and is transparent to the ForCES PL layer. 3039 We recommend that FE after establishing the connection with the 3040 primary CE, should establish the security association with the backup 3041 CE (if available). During the switchover operation CE's security 3042 state associated with each SA's are not transferred. SA between 3043 primary CE and FE and backup CE and FE are treated as two separate 3044 SA's. 3046 9.2.2. Message authentication service 3048 This is TML specific operation and is transparent to ForCES PL layer. 3049 For details refer to Section 4. 3051 9.2.3. Confidentiality service 3053 This is TML specific operation and is transparent to ForCES PL layer. 3054 For details refer to Section 4. 3056 10. Acknowledgments 3058 The authors of this draft would like to acknowledge and thank the 3059 following: Alex Audu, Steven Blake, Allan DeKok, Ellen M. Deleganes, 3060 Yunfei Guo, Joel M. Halpern, Zsolt Haraszti, Jeff Pickering, 3061 Guangming Wang, Chaoping Wu, Lily L. Yang, and Alistair Munro for 3062 their contributions. We would also like to thank David Putzolu, and 3063 Patrick Droz for their comments and suggestions on the protocol. 3065 11. References 3067 11.1. Normative References 3069 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3070 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3071 October 1998. 3073 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 3074 June 1999. 3076 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 3077 of IP Control and Forwarding", RFC 3654, November 2003. 3079 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 3080 "Forwarding and Control Element Separation (ForCES) 3081 Framework", RFC 3746, April 2004. 3083 11.2. Informational References 3085 [2PCREF] Gray, J., "Notes on database operating systems. In 3086 Operating Systems: An Advanced Course. Lecture Notes in 3087 Computer Science, Vol. 60, pp. 394-481, Springer-Verlag", 3088 1978. 3090 [ACID] Haerder, T. and A. Reuter, "Principles of Transaction- 3091 Orientated Database Recovery", 1983. 3093 [FE-MODEL] 3094 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., 3095 and S. Blake, "ForCES Forwarding Element Model", 3096 Feb. 2005. 3098 Appendix A. Authors' Addresses 3100 Ligang Dong 3101 Zhejiang Gongshang University 3102 149 Jiaogong Road 3103 Hangzhou 310035 3104 P.R.China 3105 Phone: +86-571-88071024 3106 EMail: donglg@mail.zjgsu.edu.cn 3108 Avri Doria 3109 ETRI 3110 EMail: avri@acm.org 3112 Ram Gopal 3113 Nokia 3114 5, Wayside Road 3115 Burlington MA 01803 3116 USA 3117 Phone: 1-781-993-3685 3118 EMail: ram.gopal@nokia.com 3120 Robert Haas 3121 IBM 3122 Saumerstrasse 4 3123 8803 Ruschlikon 3124 Switzerland 3125 EMail: rha@zurich.ibm.com 3127 Jamal Hadi Salim 3128 Znyx 3129 Ottawa, Ontario 3130 Canada 3131 EMail: hadi@znyx.com 3133 Hormuzd M Khosravi 3134 Intel 3135 2111 NE 25th Avenue 3136 Hillsboro, OR 97124 3137 USA 3138 Phone: +1 503 264 0334 3139 EMail: hormuzd.m.khosravi@intel.com 3140 Weiming Wang 3141 Zhejiang Gongshang University 3142 149 Jiaogong Road 3143 Hangzhou 310035 3144 P.R.China 3145 Phone: +86-571-88071024 3146 EMail: wmwang@mail.zjgsu.edu.cn 3148 Appendix B. IANA Considerations 3150 Following the policies outlined in "Guidelines for Writing an IANA 3151 Considerations Section in RFCs" (RFC 2434 [RFC2434]), the following 3152 name spaces are defined in ForCES. 3154 o Message Type Name Space (add xref) 3156 o Header Flags (add xref) 3158 o TLV Type (add xref) 3160 o Result TLV value (add xref) 3162 o LFB Class ID (add xref) 3164 o Result: Association Setup Repsonse (add xref) 3166 o Reason: Association Teardown Message (add xref) 3168 o Operation type (add xref) 3170 o Configuration Request: Operation Result (add xref) 3172 B.1. Message Type Name Space 3174 The Message Type is an 8 bit value. The following is the guideline 3175 for defining the Message Type namespace 3177 Message Types 0x00 - 0x0F 3178 Message Types in this range are part of the base ForCES Protocol. 3179 Message Types in this range are allocated through an IETF 3180 consensus action. [RFC2434] 3181 Values assigned by this specification: 3183 0x00 ............... Heartbeat 3184 0x01 ............... Association Messages 3185 0x02 ............... Configuration Messages 3186 0x03 ............... Query Messages 3187 0x04 ............... Event Notifications 3188 0x05 ............... Packet Redirection 3190 Message Types 0x10 - 0x7F 3191 Message Types in this range are Specification Required [RFC2434] 3192 Message Types using this range must be documented in an RFC or 3193 other permanent and readily available references. 3195 Message Types 0x80 - 0xFF 3196 Message Types in this range are reserved for vendor private 3197 extensions and are the responsibility of individual vendors. IANA 3198 management of this range of the Message Type Name Space is 3199 unnecessary. 3201 B.2. Operation Type 3203 The Operation Type name space is 16 bits long. The following is the 3204 guideline for managing the Operation Type Name Space. 3206 Operation Type 0x0000-0x00FF 3207 Operation Types in this range are allocated through an IETF 3208 consensus process. [RFC2434]. 3209 Values assigned by this specification: 3211 0x0000 Reserved 3212 0x0001 ADD 3214 Operation Type 0x0100-0x7FFF 3215 Operation Types using this range must be documented in an RFC or 3216 other permanent and readily available references. [RFC2434]. 3218 Operation Type 0x8000-0xFFFF 3219 Operation Types in this range are reserved for vendor private 3220 extensions and are the responsibility of individual vendors. IANA 3221 management of this range of the Operation Type Name Space is 3222 unnecessary. 3224 B.3. Header Flags 3226 The Header flag field is 32 bits long Header flags are part of the 3227 ForCES base protocol. Header flags are allocated through an IETF 3228 consensus action [RFC2434]. TLV Result Values in this range are 3229 allocated through an IETF consensus process. [RFC2434]. 3230 Values assigned by this specification: 3232 B.4. LFB Class Id Name Space 3234 TheLFB Class ID name space is 32 bits long. The following iws the 3235 guideline for managing the TLV Result Name Space. 3237 LFB Class ID 0x00000000-0x0000FFFF 3238 LFB Class IDs in this range are allocated through an IETF 3239 consensus process. [RFC2434]. 3240 Values assigned by this specification: 3242 0x00000000 Reserved 3243 0x00000001 FE Protocol LFB 3244 0x00000002 FE LFB 3246 LFB Class ID 0x00010000-0x7FFFFFFF 3247 LFB Class IDs in this range are Specification Required [RFC2434] 3248 LFB Class ID using this range must be documented in an RFC or 3249 other permanent and readily available references. [RFC2434]. 3251 LFB Class Id 0x80000000-0xFFFFFFFFF 3252 LFB Class IDs in this range are reserved for vendor private 3253 extensions and are the responsibility of individual vendors. IANA 3254 management of this range of the LFB Class ID Space is unnecessary. 3256 B.5. Association Setup Repsonse 3258 The Association Setup Repsonse name space is 16 bits long. The 3259 following is the guideline for managing the Association Setup 3260 Repsonse Name Space. 3262 Association Setup Repsonse 0x0000-0x00FF 3263 Association Setup Repsonses in this range are allocated through an 3264 IETF consensus process. [RFC2434]. 3265 Values assigned by this specification: 3267 0x0000 Succcess 3268 0x0001 FE ID Invalid 3269 0x0002 Too many associations 3270 0x0003 Permission Denied 3272 Association Setup Repsonse 0x0100-0x0FFF 3273 Association Setup Repsonses in this range are Specification 3274 Required [RFC2434] Values using this range must be documented in 3275 an RFC or other permanent and readily available references. 3276 [RFC2434]. 3278 Association Setup Repsonse 0x80000000-0xFFFFFFFFF 3279 Association Setup Repsonses in this range are reserved for vendor 3280 private extensions and are the responsibility of individual 3281 vendors. IANA management of this range of the Association Setup 3282 Repsonses Name Space is unnecessary. 3284 B.6. Association Teardown Message 3286 The Association Teardown Message name space is 32 bits long. The 3287 following is the guideline for managing the TLV Result Name Space. 3289 Association Teardown Message 0x00000000-0x0000FFFF 3290 Association Teardown Messages in this range are allocated through 3291 an IETF consensus process. [RFC2434]. 3292 Values assigned by this specification: 3294 0x00000000 Normal - Teardown by Administrator 3295 0x00000001 Error - Out of Memory 3296 0x00000002 Error - Application Crash 3297 0x000000FF Error - Unspecified 3299 Association Teardown Message 0x00010000-0x7FFFFFFF 3300 Association Teardown Messages in this range are Specification 3301 Required [RFC2434] Association Teardown Messages using this range 3302 must be documented in an RFC or other permanent and readily 3303 available references. [RFC2434]. 3305 LFB Class Id 0x80000000-0xFFFFFFFFF 3306 Association Teardown Messages in this range are reserved for 3307 vendor private extensions and are the responsibility of individual 3308 vendors. IANA management of this range of the Association 3309 Teardown Message Name Space is unnecessary. 3311 B.7. Configuration Request Result 3313 The Configuration Request name space is 32 bits long. The following 3314 is the guideline for managing the Configuration Request Name Space. 3316 Configuration Request 0x0000-0x00FF 3317 Configuration Requests in this range are allocated through an IETF 3318 consensus process. [RFC2434]. 3319 Values assigned by this specification: 3321 0x0000 Success 3322 0x0001 FE ID Invalid 3323 0x0003 Permission Denied 3325 Configuration Request 0x0100-0x7FFF 3326 Configuration Requests in this range are Specification Required 3327 [RFC2434] Configuration Requests using this range must be 3328 documented in an RFC or other permanent and readily available 3329 references. [RFC2434]. 3331 0x8000-0xFFFF 3332 Configuration Requests in this range are reserved for vendor 3333 private extensions and are the responsibility of individual 3334 vendors. IANA management of this range of the Configuration 3335 Request Name Space is unnecessary. 3337 Appendix C. Forces Protocol LFB schema 3339 The schema described below conforms to the LFB schema (language?) 3340 described in Forces Model draft[FE-MODEL] 3342 3347 3348 3349 3350 CEHBPolicyValues 3351 3352 uchar 3353 3354 3355 CEHBPolicy0 3356 3357 The CE heartbeat policy 0, refer to RFC 3358 xxxx (ForCES protocol specification) Section 3359 6.2.1 for details 3360 3361 3362 3363 CEHBPolicy1 3364 3365 The CE heartbeat policy 1, refer to RFC xxxx 3366 Section 6.2.1 for details 3367 3368 3369 3370 3371 3373 3374 FEHBPolicyValues 3375 3376 uchar 3377 3378 3379 FEHBPolicy0 3380 3381 The FE heartbeat policy 0, refer to RFCxxxx 3382 Section 6.2.1 for details 3383 3384 3385 3386 FEHBPolicy1 3387 3388 The FE heartbeat policy 1, refer to RFC xxxx 3389 Section 6.2.1 for details 3390 3391 3392 3393 3394 3396 3397 FERestartPolicyValues 3398 3399 uchar 3400 3401 3402 FERestartPolicy0 3403 3404 The FE restart policy 0, refer to RFCxxxx 3405 Section 6.2.1 for details 3406 3407 3408 3409 FERestartPolicy1 3410 3411 The FE restart policy 1, refer to RFC xxxx 3412 Section 6.2.1 for details 3413 3414 3415 3416 3417 3419 3420 CEFailoverPolicyValues 3421 3422 uchar 3423 3424 3425 CEFailoverPolicy0 3426 3427 The CE failover policy 0, refer to RFCxxxx 3428 Section 6.2.1 for details 3429 3430 3431 3432 CEFailoverPolicy1 3433 3434 The CE failover policy 1, refer to RFC xxxx 3435 Section 6.2.1 for details 3436 3437 3438 3439 CEFailoverPolicy2 3440 3441 The CE failover policy 2, refer to RFC xxxx 3442 Section 6.2.1 for details 3443 3444 3445 3446 3447 3448 3450 3451 3452 FEPO 3453 1 3454 3455 The FE Protocol Object 3456 3457 1.0 3458 baseclass 3459 3460 3461 SupportableVersions 3462 3463 the table of ForCES versions that FE supports 3464 3465 3466 u8 3467 3468 3469 3470 3471 3472 CurrentRunningVersion 3473 Currently running ForCES version 3474 u8 3475 3476 3477 FEID 3478 Unicast FEID 3479 uint32 3480 3481 3482 MulticastFEIDs 3483 3484 the table of all multicast IDs 3485 3486 3487 uint32 3488 3489 3490 3491 CEHBPolicy 3492 3493 The CE Heartbeat Policy 3494 3495 CEHBPolicyValues 3496 3497 3498 CEHDI 3499 3500 The CE Heartbeat Dead Interval in millisecs 3501 3502 uint32 3503 3504 3505 FEHBPolicy 3506 3507 The FE Heartbeat Policy 3508 3509 FEHBPolicyValues 3510 3511 3512 FEHI 3513 3514 The FE Heartbeat Interval in millisecs 3515 3516 uint32 3517 3518 3519 CEID 3520 3521 The Primary CE this FE is associated with 3522 3523 uint32 3524 3525 3526 BackupCEs 3527 3528 The table of all backup CEs other than the primary 3530 3531 3532 uint32 3533 3534 3535 3536 FERestartPolicy 3537 3538 The FE Restart Policy 3539 3540 FERestartPolicyValues 3541 3543 3544 CEFailoverPolicy 3545 3546 The CE Failover Policy 3547 3548 CEFailoverPolicyValues 3549 3551 3552 CETI 3553 3554 The CE Timeout Interval in millisecs 3555 3556 uint32 3557 3558 3559 3560 3561 3563 C.1. Capabilities 3565 At the moment only the SupportableVersions capability is owned by 3566 this LFB. 3568 Supportable Versions enumerates all ForCES versions that an FE 3569 supports. 3571 C.2. Attributes 3573 All Attributes are explained in Section 6.2.1. 3575 Appendix D. Data Encoding Examples 3577 We give a few examples below but dont show the padding. 3579 ========== 3580 Example 1: 3581 ========== 3583 Structure with three fixed-lengthof, mandatory fields. 3585 struct S { 3586 uint16 a 3587 uint16 b 3588 uint16 c 3589 } 3591 (a) Describing all fields using SPARSEDATA 3593 Path-Data TLV 3594 Path to an instance of S ... 3595 SPARSEDATA TLV 3596 ElementIDof(a), lengthof(a), valueof(a) 3597 ElementIDof(b), lengthof(b), valueof(b) 3598 ElementIDof(c), lengthof(c), valueof(c) 3600 (b) Describing a subset of fields 3602 Path-Data TLV 3603 Path to an instance of S ... 3604 SPARSEDATA TLV 3605 ElementIDof(a), lengthof(a), valueof(a) 3606 ElementIDof(c), lengthof(c), valueof(c) 3608 Note: Even though we have non-optional elements in structure S, since 3609 we can uniquely identify elements, we can selectively send element of 3610 structure S (eg in the case of an update from CE to FE). 3612 (c) Describing all fields using a FULLDATA TLV 3614 Path-Data TLV 3615 Path to an instance of S ... 3616 FULLDATA TLV 3617 valueof(a) 3618 valueof(b) 3619 valueof(c) 3621 ========== 3622 Example 2: 3623 ========== 3625 Structure with three fixed-lengthof fields, one mandatory, two 3626 optional. 3628 struct T { 3629 uint16 a 3630 uint16 b (optional) 3631 uint16 c (optional) 3632 } 3634 This example is identical to Example 1, as illustrated below. 3636 (a) Describing all fields using SPARSEDATA 3638 Path-Data TLV 3639 Path to an instance of S ... 3640 SPARSEDATA TLV 3641 ElementIDof(a), lengthof(a), valueof(a) 3642 ElementIDof(b), lengthof(b), valueof(b) 3643 ElementIDof(c), lengthof(c), valueof(c) 3645 (b) Describing a subset of fields using SPARSEDATA 3647 Path-Data TLV 3648 Path to an instance of S ... 3649 SPARSEDATA TLV 3650 ElementIDof(a), lengthof(a), valueof(a) 3651 ElementIDof(c), lengthof(c), valueof(c) 3653 (c) Describing all fields using a FULLDATA TLV 3655 Path-Data TLV 3656 Path to an instance of S ... 3657 FULLDATA TLV 3658 valueof(a) 3659 valueof(b) 3660 valueof(c) 3662 Note: FULLDATA TLV _cannot_ be used unless all fields are being 3663 described. 3665 ========== 3666 Example 3: 3667 ========== 3668 Structure with a mix of fixed-lengthof and variable-lengthof fields, 3669 some mandatory, some optional (would be a good idea to show unions 3670 maybe). 3672 struct U { 3673 uint16 a 3674 string b (optional) 3675 uint16 c (optional) 3676 } 3678 (a) Describing all fields using SPARSEDATA 3680 Path to an instance of U ... 3681 SPARSEDATA TLV 3682 ElementIDof(a), lengthof(a), valueof(a) 3683 ElementIDof(b), lengthof(b), valueof(b) 3684 ElementIDof(c), lengthof(c), valueof(c) 3686 (b) Describing a subset of fields using SPARSEDATA 3688 Path to an instance of U ... 3689 SPARSEDATA TLV 3690 ElementIDof(a), lengthof(a), valueof(a) 3691 ElementIDof(c), lengthof(c), valueof(c) 3693 (c) Describing all fields using FULLDATA TLV 3695 Path to an instance of U ... 3696 FULLDATA TLV 3697 valueof(a) 3698 FULLDATA TLV 3699 valueof(b) 3700 valueof(c) 3702 Note: The variable-length field requires the addition of a FULLDATA 3703 TLV within the outer FULLDATA TLV as in the case of element b above. 3705 ========== 3706 Example 4: 3707 ========== 3709 Structure containing an array of another structure type. 3711 struct V { 3712 uint32 x 3713 uint32 y 3714 struct U z[] 3715 } 3717 (a) Encoding using SPARSEDATA, with two instances of z[], also 3718 described with SPARSEDATA, assuming only the 10th and 15th subscript 3719 of z[] are encoded. 3721 path to instance of V ... 3722 SPARSEDATA TLV 3723 ElementIDof(x), lengthof(x), valueof(x) 3724 ElementIDof(y), lengthof(y), valueof(y) 3725 ElementIDof(z), lengthof(all below) 3726 ElementID = 10 (i.e index 10 from z[]), lengthof(all below) 3727 ElementIDof(a), lengthof(a), valueof(a) 3728 ElementIDof(b), lengthof(b), valueof(b) 3729 ElementID = 15 (index 15 from z[]), lengthof(all below) 3730 ElementIDof(a), lengthof(a), valueof(a) 3731 ElementIDof(c), lengthof(c), valueof(c) 3733 Note the holes in the elements of z (10 followed by 15). Also note 3734 the gap in index 15 with only elements a and c appearing but not b. 3736 Appendix E. Use Cases 3738 Assume LFB with following attributes for the following use cases. 3740 foo1, type u32, ID = 1 3742 foo2, type u32, ID = 2 3744 table1: type array, ID = 3 3745 elements are: 3746 t1, type u32, ID = 1 3747 t2, type u32, ID = 2 // index into table 2 3748 KEY: nhkey, ID = 1, V = t2 3750 table2: type array, ID = 4 3751 elements are: 3752 j1, type u32, ID = 1 3753 j2, type u32, ID = 2 3754 KEY: akey, ID = 1, V = { j1,j2 } 3756 table3: type array, ID = 5 3757 elements are: 3758 someid, type u32, ID = 1 3759 name, type string variable sized, ID = 2 3761 table4: type array, ID = 6 3762 elements are: 3763 j1, type u32, ID = 1 3764 j2, type u32, ID = 2 3765 j3, type u32, ID = 3 3766 j4, type u32, ID = 4 3767 KEY: mykey, ID = 1, V = { j1} 3769 table5: type array, ID = 7 3770 elements are: 3771 p1, type u32, ID = 1 3772 p2, type array, ID = 2, array elements of type-X 3774 Type-X: 3775 x1, ID 1, type u32 3776 x2, ID2 , type u32 3777 KEY: tkey, ID = 1, V = { x1} 3779 All examples will show an attribute suffixed with "v" or "val" to 3780 indicate the value of the referenced attribute. example for attribute 3781 foo2, foo1v or foo1value will indicate the value of foo1. In the 3782 case where F_SEL** are missing (bits equal to 00) then the flags will 3783 not show any selection. 3785 All the examples only show use of FULLDATA for data encoding; 3786 although SPARSEDATA would make more sense in certain occassions, the 3787 emphasis is on showing the message layout. Refer to Appendix D for 3788 examples that show usage of both FULLDATA and SPARSEDATA. 3790 1. To get foo1 3792 OPER = GET-TLV 3793 Path-data TLV: IDCount = 1, IDs = 1 3794 Result: 3795 OPER = GET-RESPONSE-TLV 3796 Path-data-TLV: 3797 flags=0, IDCount = 1, IDs = 1 3798 FULLDATA-TLV L = 4+4, V = foo1v 3800 2. To set foo2 to 10 3802 OPER = SET-REPLACE-TLV 3803 Path-data-TLV: 3804 flags = 0, IDCount = 1, IDs = 2 3805 FULLDATA TLV: L = 4+4, V=10 3807 Result: 3808 OPER = SET-RESPONSE-TLV 3809 Path-data-TLV: 3810 flags = 0, IDCount = 1, IDs = 2 3811 RESULT-TLV 3813 3. To dump table2 3815 OPER = GET-TLV 3816 Path-data-TLV: 3817 IDCount = 1, IDs = 4 3818 Result: 3819 OPER = GET-RESPONSE-TLV 3820 Path-data-TLV: 3821 flags = 0, IDCount = 1, IDs = 4 3822 FULLDATA=TLV: L = XXX, V= 3823 a series of: index, j1value,j2value entries 3824 representing the entire table 3826 4. Note: One should be able to take a GET-RESPONSE-TLV and convert 3827 it to a SET-REPLACE-TLV. If the result in the above example is 3828 sent back in a SET-REPLACE-TLV, (instead of a GET-RESPONSE_TLV) 3829 then the entire contents of the table will be replaced at that 3830 point. 3832 5. Multiple operations Example. To create entry 0-5 of table2 3833 (Ignore error conditions for now) 3835 OPER = SET-CREATE-TLV 3836 Path-data-TLV: 3837 flags = 0 , IDCount = 1, IDs=4 3838 PATH-DATA-TLV 3839 flags = 0, IDCount = 1, IDs = 0 3840 FULLDATA-TLV containing j1, j2 value for entry 0 3841 PATH-DATA-TLV 3842 flags = 0, IDCount = 1, IDs = 1 3843 FULLDATA-TLV containing j1, j2 value for entry 1 3844 PATH-DATA-TLV 3845 flags = 0, IDCount = 1, IDs = 2 3846 FULLDATA-TLV containing j1, j2 value for entry 2 3847 PATH-DATA-TLV 3848 flags = 0, IDCount = 1, IDs = 3 3849 FULLDATA-TLV containing j1, j2 value for entry 3 3850 PATH-DATA-TLV 3851 flags = 0, IDCount = 1, IDs = 4 3852 FULLDATA-TLV containing j1, j2 value for entry 4 3853 PATH-DATA-TLV 3854 flags = 0, IDCount = 1, IDs = 5 3855 FULLDATA-TLV containing j1, j2 value for entry 5 3857 Result: 3858 OPER = SET-RESPONSE-TLV 3859 Path-data-TLV: 3860 flags = 0 , IDCount = 1, IDs=4 3861 PATH-DATA-TLV 3862 flags = 0, IDCount = 1, IDs = 0 3863 RESULT-TLV 3864 PATH-DATA-TLV 3865 flags = 0, IDCount = 1, IDs = 1 3866 RESULT-TLV 3867 PATH-DATA-TLV 3868 flags = 0, IDCount = 1, IDs = 2 3869 RESULT-TLV 3870 PATH-DATA-TLV 3871 flags = 0, IDCount = 1, IDs = 3 3872 RESULT-TLV 3873 PATH-DATA-TLV 3874 flags = 0, IDCount = 1, IDs = 4 3875 RESULT-TLV 3876 PATH-DATA-TLV 3877 flags = 0, IDCount = 1, IDs = 5 3878 RESULT-TLV 3880 6. Block operations (with holes) example. Replace entry 0,2 of 3881 table2 3883 OPER = SET-REPLACE-TLV 3884 Path-data TLV: 3885 flags = 0 , IDCount = 1, IDs=4 3886 PATH-DATA-TLV 3887 flags = 0, IDCount = 1, IDs = 0 3888 FULLDATA-TLV containing j1, j2 value for entry 0 3889 PATH-DATA-TLV 3890 flags = 0, IDCount = 1, IDs = 2 3891 FULLDATA-TLV containing j1, j2 value for entry 2 3893 Result: 3894 OPER = SET-REPLACE-TLV 3895 Path-data TLV: 3896 flags = 0 , IDCount = 1, IDs=4 3897 PATH-DATA-TLV 3898 flags = 0, IDCount = 1, IDs = 0 3899 RESULT-TLV 3900 PATH-DATA-TLV 3901 flags = 0, IDCount = 1, IDs = 2 3902 RESULT-TLV 3904 7. Getting rows example. Get first entry of table2. 3906 OPER = GET-TLV 3907 Path-data TLV: 3908 IDCount = 2, IDs=4.0 3910 Result: 3911 OPER = GET-RESPONSE-TLV 3912 Path-data TLV: 3913 IDCount = 2, IDs=4.0 3914 FULLDATA TLV, Length = XXX, V = 3915 j1value,j2value entry 3917 8. Get entry 0-5 of table2. 3919 OPER = GET-TLV 3920 Path-data-TLV: 3921 flags = 0, IDCount = 1, IDs=4 3922 PATH-DATA-TLV 3923 flags = 0, IDCount = 1, IDs = 0 3924 PATH-DATA-TLV 3925 flags = 0, IDCount = 1, IDs = 1 3926 PATH-DATA-TLV 3927 flags = 0, IDCount = 1, IDs = 2 3928 PATH-DATA-TLV 3929 flags = 0, IDCount = 1, IDs = 3 3930 PATH-DATA-TLV 3931 flags = 0, IDCount = 1, IDs = 4 3932 PATH-DATA-TLV 3933 flags = 0, IDCount = 1, IDs = 5 3935 Result: 3936 OPER = GET-RESPONSE-TLV 3937 Path-data-TLV: 3938 flags = 0, IDCount = 1, IDs=4 3939 PATH-DATA-TLV 3940 flags = 0, IDCount = 1, IDs = 0 3941 FULLDATA-TLV containing j1value j2value 3942 PATH-DATA-TLV 3943 flags = 0, IDCount = 1, IDs = 1 3944 FULLDATA-TLV containing j1value j2value 3945 PATH-DATA-TLV 3946 flags = 0, IDCount = 1, IDs = 2 3947 FULLDATA-TLV containing j1value j2value 3948 PATH-DATA-TLV 3949 flags = 0, IDCount = 1, IDs = 3 3950 FULLDATA-TLV containing j1value j2value 3951 PATH-DATA-TLV 3952 flags = 0, IDCount = 1, IDs = 4 3953 FULLDATA-TLV containing j1value j2value 3954 PATH-DATA-TLV 3955 flags = 0, IDCount = 1, IDs = 5 3956 FULLDATA-TLV containing j1value j2value 3958 9. Create a row in table2, index 5. 3960 OPER = SET-CREATE-TLV 3961 Path-data-TLV: 3962 flags = 0, IDCount = 2, IDs=4.5 3963 FULLDATA TLV, Length = XXX 3964 j1value,j2value 3966 Result: 3967 OPER = SET-RESPONSE-TLV 3968 Path-data TLV: 3969 flags = 0, IDCount = 1, IDs=4.5 3970 RESULT-TLV 3972 10. An example of "create and give me an index" Assuming we asked 3973 for verbose response back in the main message header. 3975 OPER = SET-CREATE-TLV 3976 Path-data -TLV: 3977 flags = FIND-EMPTY, IDCount = 1, IDs=4 3978 FULLDATA TLV, Length = XXX 3979 j1value,j2value 3981 Result 3982 If 7 were the first unused entry in the table: 3983 OPER = SET-RESPONSE 3984 Path-data TLV: 3985 flags = 0, IDCount = 2, IDs=4.7 3986 RESULT-TLV indicating success, and 3987 FULLDATA-TLV, Length = XXX j1value,j2value 3989 11. Dump contents of table1. 3991 OPER = GET-TLV 3992 Path-data TLV: 3993 flags = 0, IDCount = 1, IDs=3 3995 Result: 3996 OPER = GET-RESPONSE-TLV 3997 Path-data TLV 3998 flags = 0, IDCount = 1, IDs=3 3999 FULLDATA TLV, Length = XXXX 4000 (depending on size of table1) 4001 index, t1value, t2value 4002 index, t1value, t2value 4003 . 4005 . 4006 . 4008 12. Using Keys. Get row entry from table4 where j1=100. Recall, j1 4009 is a defined key for this table and its keyid is 1. 4011 OPER = GET-TLV 4012 Path-data-TLV: 4013 flags = F_SELKEY IDCount = 1, IDs=6 4014 KEYINFO-TLV = KEYID=1, KEY_DATA=100 4016 Result: 4017 If j1=100 was at index 10 4018 OPER = GET-RESPONSE-TLV 4019 Path-data TLV: 4020 flags = 0, IDCount = 1, IDs=6.10 4021 FULLDATA TLV, Length = XXXX 4022 j1value,j2value, j3value, j4value 4024 13. Delete row with KEY match (j1=100, j2=200) in table 2. Note 4025 that the j1,j2 pair are a defined key for the table 2. 4027 OPER = DEL-TLV 4028 Path-data TLV: 4029 flags = F_SELKEY IDCount = 1, IDs=4 4030 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} 4032 Result: 4033 If (j1=100, j2=200) was at entry 15: 4034 OPER = DELETE-RESPONSE-TLV 4035 Path-data TLV: 4036 flags = 0 IDCount = 2, IDs=4.15 4037 RESULT-TLV (with FULLDATA if verbose) 4039 14. Dump contents of table3. It should be noted that this table has 4040 a column with element name that is variable sized. The purpose 4041 of this use case is to show how such an element is to be 4042 encoded. 4044 OPER = GET-TLV 4045 Path-data-TLV: 4046 flags = 0 IDCount = 1, IDs=5 4048 Result: 4049 OPER = GET-RESPONSE-TLV 4050 Path-data TLV: 4051 flags = 0 IDCount = 1, IDs=5 4052 FULLDATA TLV, Length = XXXX 4053 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4054 V = namev 4055 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4056 V = namev 4057 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4058 V = namev 4059 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4060 V = namev 4061 . 4062 . 4063 . 4065 15. Multiple atomic operations. 4067 16. Note: This emulates adding a new nexthop entry and then 4068 atomically updating the L3 entries pointing to an old NH to 4069 point to a new one. The assumption is both tables are in the 4070 same LFB 4072 17. Main header has atomic flag set and we are request for verbose/ 4073 full results back; Two operations on the LFB instance, both are 4074 SET operations. 4076 //Operation 1: Add a new entry to table2 index #20. 4077 OPER = SET-CREATE-TLV 4078 Path-TLV: 4079 flags = 0, IDCount = 2, IDs=4.20 4080 FULLDATA TLV, V= j1value,j2value 4082 // Operation 2: Update table1 entry which 4083 // was pointing with t2 = 10 to now point to 20 4084 OPER = SET-REPLACE-TLV 4085 Path-data-TLV: 4086 flags = F_SELKEY, IDCount = 1, IDs=3 4087 KEYINFO = KEYID=1 KEY_DATA=10 4088 Path-data-TLV 4089 flags = 0 IDCount = 1, IDs=2 4090 FULLDATA TLV, V= 20 4092 Result: 4093 //first operation, SET 4094 OPER = SET-RESPONSE-TLV 4095 Path-data-TLV 4096 flags = 0 IDCount = 3, IDs=4.20 4097 RESULT-TLV code = success 4098 FULLDATA TLV, V = j1value,j2value 4099 // second opertion SET - assuming entry 16 was updated 4100 OPER = SET-RESPONSE-TLV 4101 Path-data TLV 4102 flags = 0 IDCount = 2, IDs=3.16 4103 Path-Data TLV 4104 flags = 0 IDCount = 1, IDs = 2 4105 SET-RESULT-TLV code = success 4106 FULLDATA TLV, Length = XXXX v=20 4107 // second opertion SET 4108 OPER = SET-RESPONSE-TLV 4109 Path-data TLV 4110 flags = 0 IDCount = 1, IDs=3 4111 KEYINFO = KEYID=1 KEY_DATA=10 4112 Path-Data TLV 4113 flags = 0 IDCount = 1, IDs = 2 4114 SET-RESULT-TLV code = success 4115 FULLDATA TLV, Length = XXXX v=20 4117 18. Selective setting (Example posted by Weiming). On table 4 -- 4118 for indices 1, 3, 5, 7, and 9. Replace j1 to 100, j2 to 200, j3 4119 to 300. Leave j4 as is. 4121 PER = SET-REPLACE-TLV 4122 Path-data TLV 4123 flags = 0, IDCount = 1, IDs = 6 4124 Path-data TLV 4125 flags = 0, IDCount = 1, IDs = 1 4126 Path-data TLV 4127 flags = 0, IDCount = 1, IDs = 1 4128 FULLDATA TLV, Length = XXXX, V = {100} 4129 Path-data TLV 4130 flags = 0, IDCount = 1, IDs = 2 4131 FULLDATA TLV, Length = XXXX, V = {200} 4132 Path-data TLV 4133 flags = 0, IDCount = 1, IDs = 3 4134 FULLDATA TLV, Length = XXXX, V = {300} 4135 Path-data TLV 4136 flags = 0, IDCount = 1, IDs = 3 4137 Path-data TLV 4138 flags = 0, IDCount = 1, IDs = 1 4139 FULLDATA TLV, Length = XXXX, V = {100} 4140 Path-data TLV 4141 flags = 0, IDCount = 1, IDs = 2 4142 FULLDATA TLV, Length = XXXX, V = {200} 4143 Path-data TLV 4144 flags = 0, IDCount = 1, IDs = 3 4145 FULLDATA TLV, Length = XXXX, V = {300} 4146 Path-data TLV 4147 flags = 0, IDCount = 1, IDs = 5 4148 Path-data TLV 4149 flags = 0, IDCount = 1, IDs = 1 4150 FULLDATA TLV, Length = XXXX, V = {100} 4151 Path-data TLV 4152 flags = 0, IDCount = 1, IDs = 2 4153 FULLDATA TLV, Length = XXXX, V = {200} 4154 Path-data TLV 4155 flags = 0, IDCount = 1, IDs = 3 4156 FULLDATA TLV, Length = XXXX, V = {300} 4157 Path-data TLV 4158 flags = 0, IDCount = 1, IDs = 7 4159 Path-data TLV 4160 flags = 0, IDCount = 1, IDs = 1 4161 FULLDATA TLV, Length = XXXX, V = {100} 4162 Path-data TLV 4163 flags = 0, IDCount = 1, IDs = 2 4164 FULLDATA TLV, Length = XXXX, V = {200} 4165 Path-data TLV 4166 flags = 0, IDCount = 1, IDs = 3 4167 FULLDATA TLV, Length = XXXX, V = {300} 4168 Path-data TLV 4169 flags = 0, IDCount = 1, IDs = 9 4170 Path-data TLV 4171 flags = 0, IDCount = 1, IDs = 1 4172 FULLDATA TLV, Length = XXXX, V = {100} 4173 Path-data TLV 4174 flags = 0, IDCount = 1, IDs = 2 4175 FULLDATA TLV, Length = XXXX, V = {200} 4176 Path-data TLV 4177 flags = 0, IDCount = 1, IDs = 3 4178 FULLDATA TLV, Length = XXXX, V = {300} 4180 Non-verbose response mode shown: 4182 OPER = SET-RESPONSE-TLV 4183 Path-data TLV 4184 flags = 0, IDCount = 1, IDs = 6 4185 Path-data TLV 4186 flags = 0, IDCount = 1, IDs = 1 4187 Path-data TLV 4188 flags = 0, IDCount = 1, IDs = 1 4189 RESULT-TLV 4190 Path-data TLV 4191 flags = 0, IDCount = 1, IDs = 2 4192 RESULT-TLV 4193 Path-data TLV 4194 flags = 0, IDCount = 1, IDs = 3 4195 RESULT-TLV 4196 Path-data TLV 4197 flags = 0, IDCount = 1, IDs = 3 4198 Path-data TLV 4199 flags = 0, IDCount = 1, IDs = 1 4200 RESULT-TLV 4201 Path-data TLV 4202 flags = 0, IDCount = 1, IDs = 2 4203 RESULT-TLV 4204 Path-data TLV 4205 flags = 0, IDCount = 1, IDs = 3 4206 RESULT-TLV 4207 Path-data TLV 4208 flags = 0, IDCount = 1, IDs = 5 4209 Path-data TLV 4210 flags = 0, IDCount = 1, IDs = 1 4211 RESULT-TLV 4212 Path-data TLV 4213 flags = 0, IDCount = 1, IDs = 2 4214 RESULT-TLV 4215 Path-data TLV 4216 flags = 0, IDCount = 1, IDs = 3 4217 RESULT-TLV 4218 Path-data TLV 4219 flags = 0, IDCount = 1, IDs = 7 4220 Path-data TLV 4221 flags = 0, IDCount = 1, IDs = 1 4222 RESULT-TLV 4223 Path-data TLV 4224 flags = 0, IDCount = 1, IDs = 2 4225 RESULT-TLV 4226 Path-data TLV 4227 flags = 0, IDCount = 1, IDs = 3 4228 RESULT-TLV 4229 Path-data TLV 4230 flags = 0, IDCount = 1, IDs = 9 4231 Path-data TLV 4232 flags = 0, IDCount = 1, IDs = 1 4233 RESULT-TLV 4234 Path-data TLV 4235 flags = 0, IDCount = 1, IDs = 2 4236 RESULT-TLV 4237 Path-data TLV 4238 flags = 0, IDCount = 1, IDs = 3 4239 RESULT-TLV 4241 19. Manipulation of table of table examples. Get x1 from table10 4242 row with index 4, inside table5 entry 10 4244 operation = GET-TLV 4245 Path-data-TLV 4246 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4248 Results: 4249 operation = GET-RESPONSE-TLV 4250 Path-data-TLV 4251 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4252 FULLDATA TLV: L=XXXX, V = {x1 value} 4254 20. From table5's row 10 table10, get X2s based on on the value of 4255 x1 equlaing 10 (recal x1 is KeyID 1) 4257 operation = GET-TLV 4258 Path-data-TLV 4259 flag = F_SELKEY, IDCount=3, IDS = 7.10.2 4260 KEYINFO TLV, KEYID = 1, KEYDATA = 10 4261 Path-data TLV 4262 IDCount = 1, IDS = 2 //select x2 4264 Results: 4265 If x1=10 was at entry 11: 4266 operation = GET-RESPONSE-TLV 4267 Path-data-TLV 4268 flag = 0, IDCount=5, IDS = 7.10.2.11 4269 Path-data TLV 4270 flags = 0 IDCount = 1, IDS = 2 4271 FULLDATA TLV: L=XXXX, V = {x2 value} 4273 21. Further example of table of table 4275 Consider table 6 which is defined as: 4276 table6: type array, ID = 8 4277 elements are: 4278 p1, type u32, ID = 1 4279 p2, type array, ID = 2, array elements of type type-A 4281 type-A: 4282 a1, type u32, ID 1, 4283 a2, type array ID2 ,array elements of type type-B 4285 type-B: 4286 b1, type u32, ID 1 4287 b2, type u32, ID 2 4289 So lets say we wanted to set by replacing: 4290 table6.10.p1 to 111 4291 table6.10.p2.20.a1 to 222 4292 table6.10.p2.20.a2.30.b1 to 333 4294 in one message and one operation. 4296 There are two ways to do this: 4297 a) using nesting 4299 operation = SET-REPLACE-TLV 4300 Path-data-TLV 4301 flags = 0 IDCount = 2, IDs=6.10 4302 Path-data-TLV 4303 flags = 0, IDCount = 1, IDs=1 4304 FULLDATA TLV: L=XXXX, 4305 V = {111} 4306 Path-data-TLV 4307 flags = 0 IDCount = 2, IDs=2.20 4308 Path-data-TLV 4309 flags = 0, IDCount = 1, IDs=1 4310 FULLDATA TLV: L=XXXX, 4311 V = {222} 4312 Path-data TLV : 4313 flags = 0, IDCount = 3, IDs=2.30.1 4314 FULLDATA TLV: L=XXXX, 4315 V = {333} 4316 Result: 4317 operation = SET-RESPONSE-TLV 4318 Path-data-TLV 4319 flags = 0 IDCount = 2, IDs=6.10 4320 Path-data-TLV 4321 flags = 0, IDCount = 1, IDs=1 4322 RESULT-TLV 4323 Path-data-TLV 4324 flags = 0 IDCount = 2, IDs=2.20 4325 Path-data-TLV 4326 flags = 0, IDCount = 1, IDs=1 4327 RESULT-TLV 4328 Path-data TLV : 4329 flags = 0, IDCount = 3, IDs=2.30.1 4330 RESULT-TLV 4331 b) using a flat path data 4332 operation = SET-REPLACE-TLV 4333 Path-data TLV : 4334 flags = 0, IDCount = 3, IDs=6.10.1 4335 FULLDATA TLV: L=XXXX, 4336 V = {111} 4337 Path-data TLV : 4338 flags = 0, IDCount = 5, IDs=6.10.1.20.1 4339 FULLDATA TLV: L=XXXX, 4340 V = {222} 4341 Path-data TLV : 4342 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 4343 FULLDATA TLV: L=XXXX, 4344 V = {333} 4345 Result: 4346 operation = SET-REPLACE-TLV 4347 Path-data TLV : 4348 flags = 0, IDCount = 3, IDs=6.10.1 4349 RESULT-TLV 4350 Path-data TLV : 4352 flags = 0, IDCount = 5, IDs=6.10.1.20.1 4353 RESULT-TLV 4354 Path-data TLV : 4355 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 4356 RESULT-TLV 4358 22. Get a whole LFB (all its attributes etc). 4360 23. For example, at startup a CE might well want the entire FE 4361 OBJECT LFB. So, in a request targetted at class 1, instance 1, 4362 one might find: 4364 operation = GET-TLV 4365 Path-data-TLV 4366 flags = 0 IDCount = 0 4368 result: 4369 operation = GET-RESPONSE-TLV 4370 Path-data-TLV 4371 flags = 0 IDCount = 0 4372 FULLDATA encoding of the FE Object LFB 4374 Appendix F. changes between -03, -04, and -05 4376 Changes raised by issue tracker: 4378 o Issue 9: changes to definiton of LFB Class (or type) (Weiming-05) 4380 o Issue 21: removed timeliness list item since the references to 4381 obsoleting messages was removed and it was the only content in the 4382 section. (Hormuzd-04) 4384 o Issue 22 and issue 56: changed msg_Config_Repsonse message layout. 4385 changed defintion of RESULT-TLV (Hormuzd-04) 4387 o Issue 23: closed (Hormuzd-04) 4389 o Issue 24: removed all reference to CE-LFB (Hormuzd-04) 4391 o Issue 25: closed (Hormuzd-04) 4393 o Issue 26: Replaced Teardown TLV (Hormuzd-04) 4395 o Issue 28: Added clarification of RangeMark 0xffffffff (Hormuzd-04) 4397 o Issue 30: closed (Hormuzd-04) 4399 o Issue 32: Inserted new Redirect Message text. (Weiming-04) 4401 o Issue 33: text proposed by Robert has been added in the section. 4402 (Weiming-05) 4404 o Issue 34: Added text on Priority field (Hormuzd-04), added ACK 4405 indicator text (Weiming-05) 4407 o Issue 35: Removed reference to FE TML events (Hormuzd-04) 4409 o Issue 36: Added explanation for FE and CE Failover and restart 4410 policy with the values (Hormuzd-04, Weiming-05) 4412 o Issue 37: Indicated that the MAY be one and only one LFB as 4413 opposed to MUST be one and only one. (Hormuzd-04) 4415 o Issue 38: Editorial remove forgotten editorial note. (Hormuzd-04) 4417 o Issue 39: No change. Hope Hormuzd can provode text for this. 4418 (Weiming-05) 4420 o Issue 40:checked the file and assured all BLOCK operation has been 4421 removed. This issue can be closed.(Weiming-05) 4423 o Issue 41: Closed (Hormuzd-04) 4425 o Issue 42: added some text provided by Avri. (Weiming-05) 4427 o Issue 43: already fixed. (Weiming-05) 4429 o Issue 44: Replaced FE, CE, and FE protocol LFB introduction with 4430 new text. (Hormuzd-04) 4432 o Issue 45: Replaced inter-TML with explicit text (Hormuzd-04) 4434 o Issue 46: Added clarifying text on priority levels. (Hormuzd-04) 4436 o Issue 47: Still underdiscussion. No change.(Weiming-05) 4438 o Issue 48: fixed indent editorial. Replaced SELECTOR flags with 4439 PATH flags (Hormuzd-04), need Jamal's check.(Weiming-05) 4441 o Issue 49: Changes to Association setup message, clarify use of SET 4442 and GET-RESPONSE (Hormuzd-04), samll change to sec 6.1.1.1.9, SET- 4443 REPLACE is required to be modified next turn(Weiming-05) 4445 o Issue 50: no change. next turn? (Weiming-05) 4447 o Issue 51: updated according to the new updated messages 4448 text.(Weiming-05) 4450 o Issue 52: Change to Association Setup message (Hormuzd-04),updated 4451 the whole text for Association Setup Message by defining the 4452 (Optional) Operation TLV for Association Setup msg as REPORT. 4453 (Weiming-05) 4455 o Issue 53: was already solved by weiming's new text about Packet 4456 redirect msg in the previous version. (Weiming-05) 4458 o Issue 54: overlap of Issue 47.(Weiming-05) 4460 o Issue 55: updated text on transaction types (Hormuzd-04) 4462 o Issue 56: Added error for Assocition Setup Repsonse and Config 4463 Response Message (Hormuzd-04) 4465 o Issue 57: updated the operation types for consistency. 4466 (Weiming-05) 4468 Changes raised by review process: 4470 1. Modified editor list (Weiming-05) 4472 2. Modified Abstract Section (Weiming-05) 4474 3. Modified Introduction Section (Weiming-05) 4476 4. modified Flags text in common header(5.1) by adding flag 4477 figure.(Weiming-05) 4479 5. The following sections are modified.(Weiming-05) 4481 6.4 Association Messages 4482 6.4.1 Association Setup Message 4483 6.4.2 Association Setup Response Message 4484 6.4.3 Association Teardown Message 4485 6.5 Configuration Messages 4486 6.5.1 Config Message 4487 6.5.2 Config Response Message 4488 6.6 Query Messages 4489 6.6.1 Query Message 4490 6.6.2 Query Response Message 4491 6.7 Event Notification Message 4492 6.8 Packet Redirect Message 4493 6.9 Heartbeat Message 4494 6.10 Operation Summary 4496 The modification is based on: 4497 a. LFB select TLV is in a specific section (section 6.1.1.1.5) 4499 b. ACK flag is updated according to new definitions 4500 in Section 5.1. The key is ACK is only applied to 4501 Config Message. 4503 c. Note that another big change is, 4504 .event notification response is removed. 4505 .event from CE is not supported anymore, 4506 i.e., only FE to CE event notification is there. 4508 d. TLVs and Operations as below: 4510 TLVs Operations 4512 AssoSetup LFBselect REPORT 4514 AssoSetupResp ASRresult none 4516 AssoTeardown ASTreason none 4517 Config LFBselect SET, DEL 4519 Config Response LFBselect SET-RESPONSE 4520 DEL-RESPONSE 4522 Query LFBselect GET 4524 Query Response LFBselect GET-RESPONSE 4526 Event Notification LFBselect REPORT 4528 Redirect Redirect none 4530 Heartbeat None none 4532 6. Added Dataraw Examples section in the Appendix. (Weiming-05) 4534 Appendix G. changes between -02 and -03 4536 1. Remove most all editorial notes and replaced them with entries in 4537 tracker. 4539 2. Marked TBD with tracker issue number 4541 3. In section on config message replaced GET in the example figures 4542 to SET 4544 4. ISSUE: 12 - replaced Command with Message type in Common Header 4546 5. ISSUE: 12 - in Data Packing Rules replaced 'sans' with 'without 4547 the' 4549 6. Removed an uncountably large multitude of tabs that were making 4550 xml2rfc-1.29 choke. 4552 7. fixed many nits 4554 Appendix H. Changes between -01 and -02 4556 1. Renamed definitions.xml to Definitions.xml 4558 2. Added Alistair Munro to acks list. 4560 3. path-data additions + full BNF conformant to RFC 2234 4562 4. Appendix C with examples. #3 and #4 are the biggest changes 4563 incorporate many many days of discussion. 4565 5. appendix with beginings of FE protocol LFB xml. The FE Object 4566 is referenced as being in the Model draft 4568 6. Some cosmetic things like: 4570 1. For readability, introducing section 'protocol construction' 4571 which now encapsulates 'Protocol Messages' (which used to be 4572 a top section) 4574 2. A new subsection "protocol grammar' goes underneath the same 4575 section. 4577 3. added TLV definition subsection 4579 4. Many new "editorial notes" 4581 7. Closure of all but one outstanding issue from the tracker. 4583 8. Any other cosmetic changes posted (Hormuzd, David, Robert, 4584 Avri). 4586 9. Rearranged text a little to introduce new sections to make text 4587 more readable 4589 10. Rewrote the atomicity section (still under construction input 4590 text on ACID from Robert and Alistair) 4592 11. fixed up the model reference to have all authors and added acid 4593 reference 4595 12. Weiming's updates to query and event msgs to add path-data. 4597 Appendix I. Changes between -00 and -01 4599 1. Major Protocol changes 4601 * Restructured message format to apply operation to LFB as 4602 opposed to having operation be the primary organizing 4603 principle 4605 * Worked with model team to bring the draft into harmony with 4606 their model approach 4608 2. Document changes 4610 * Replaced FE protocol Object and FE Object sections with 4611 combined section on FE, CE and FE protocol LFBs 4613 * Removed minor version id 4615 * Added Header flags 4617 * Added BNF description of message structure 4619 * Added tree structure description of PDUs 4621 * Added section on each type of LFB 4623 * Added structural description of each message 4625 * Moved query messages section to come after config message 4626 section 4628 * Replace state maintenance section 4630 * Added section with tables showing the operations relevant to 4631 particular messages 4633 * Reworked HA section 4635 * Many spelling and grammatical corrections 4637 Authors' Addresses 4639 Avri Doria 4640 ETRI 4641 Lulea University of Technology 4642 Lulea 4643 Sweden 4645 Phone: +1 401 663 5024 4646 Email: avri@acm.org 4648 Robert Haas 4649 IBM 4650 Saumerstrasse 4 4651 8803 Ruschlikon 4652 Switzerland 4654 Phone: 4655 Email: rha@zurich.ibm.com 4657 Jamal Hadi Salim 4658 Znyx 4659 Ottawa, Ontario 4660 Canada 4662 Phone: 4663 Email: hadi@znyx.com 4665 Hormuzd M Khosravi 4666 Intel 4667 2111 NE 25th Avenue 4668 Hillsboro, OR 97124 4669 USA 4671 Phone: +1 503 264 0334 4672 Email: hormuzd.m.khosravi@intel.com 4673 Weiming Wang 4674 Zhejiang Gongshang University 4675 149 Jiaogong Road 4676 Hangzhou 310035 4677 P.R.China 4679 Phone: +86-571-88057712 4680 Email: wmwang@mail.zjgsu.edu.cn 4682 Intellectual Property Statement 4684 The IETF takes no position regarding the validity or scope of any 4685 Intellectual Property Rights or other rights that might be claimed to 4686 pertain to the implementation or use of the technology described in 4687 this document or the extent to which any license under such rights 4688 might or might not be available; nor does it represent that it has 4689 made any independent effort to identify any such rights. Information 4690 on the procedures with respect to rights in RFC documents can be 4691 found in BCP 78 and BCP 79. 4693 Copies of IPR disclosures made to the IETF Secretariat and any 4694 assurances of licenses to be made available, or the result of an 4695 attempt made to obtain a general license or permission for the use of 4696 such proprietary rights by implementers or users of this 4697 specification can be obtained from the IETF on-line IPR repository at 4698 http://www.ietf.org/ipr. 4700 The IETF invites any interested party to bring to its attention any 4701 copyrights, patents or patent applications, or other proprietary 4702 rights that may cover technology that may be required to implement 4703 this standard. Please address the information to the IETF at 4704 ietf-ipr@ietf.org. 4706 Disclaimer of Validity 4708 This document and the information contained herein are provided on an 4709 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4710 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4711 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4712 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4713 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4714 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4716 Copyright Statement 4718 Copyright (C) The Internet Society (2005). This document is subject 4719 to the rights, licenses and restrictions contained in BCP 78, and 4720 except as set forth therein, the authors retain all their rights. 4722 Acknowledgment 4724 Funding for the RFC Editor function is currently provided by the 4725 Internet Society.