idnits 2.17.1 draft-ietf-forces-protocol-15.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, updated by RFC 4748 on line 5137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5148. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5155. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5161. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 25, 2008) is 5694 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DATA' is mentioned on line 1822, but not defined == Missing Reference: 'SELECTOR' is mentioned on line 1823, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FE-MODEL' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Doria (Ed.) 3 Internet-Draft Lulea University of Technology 4 Intended status: Standards Track R. Haas (Ed.) 5 Expires: February 26, 2009 IBM 6 J. Hadi Salim (Ed.) 7 Znyx 8 H. Khosravi (Ed.) 9 Intel 10 W. M. Wang (Ed.) 11 Zhejiang Gongshang University 12 August 25, 2008 14 ForCES Protocol Specification 15 draft-ietf-forces-protocol-15.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 February 26, 2009. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 This document specifies the Forwarding and Control Element Separation 49 (ForCES) protocol. ForCES protocol is used for communications 50 between Control Elements(CEs) and Forwarding Elements (FEs) in a 51 ForCES Network Element (ForCES NE). This specification is intended 52 to meet the ForCES protocol requirements defined in RFC3654. Besides 53 the ForCES protocol messages, the specification also defines the 54 framework, the mechanisms, and the Transport Mapping Layer (TML) 55 requirements for ForCES protocol. 57 Authors 59 The participants in the ForCES Protocol Team, primary co-authors and 60 co-editors, of this protocol specification, are: 62 Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea 63 University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), 64 Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang 65 (Zhejiang Gongshang University). Special acknowledgement goes to 66 Joel Halpern who has done extensive editing in support of congruence 67 between the model and this protocol specification. Without his 68 participation and persistence, this specification might never have 69 been completed. 71 Table of Contents 73 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 74 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 75 1.2. Other Notation . . . . . . . . . . . . . . . . . . . . . 6 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 12 80 4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 14 81 4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 15 82 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 15 83 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 16 84 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 17 85 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18 86 4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 20 87 4.3.1. Transactions, Atomicity, Execution and Responses . . 20 88 4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 26 89 4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 27 90 4.3.4. FE Object and FE Protocol LFBs . . . . . . . . . . . 27 91 4.4. Protocol Scenarios . . . . . . . . . . . . . . . . . . . 28 92 4.4.1. Association Setup State . . . . . . . . . . . . . . . 28 93 4.4.2. Association Established state or Steady State . . . . 29 94 5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 32 95 5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 33 96 6. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 34 97 6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 34 98 6.2. Type Length Value (TLV) Structuring . . . . . . . . . . . 39 99 6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 40 100 6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 40 101 6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 102 6.4. Important Protocol encapsulations . . . . . . . . . . . . 41 103 6.4.1. Paths . . . . . . . . . . . . . . . . . . . . . . . . 41 104 6.4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 42 105 6.4.3. DATA TLVs . . . . . . . . . . . . . . . . . . . . . . 42 106 6.4.4. Addressing LFB entities . . . . . . . . . . . . . . . 42 107 7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 44 108 7.1. Discussion on encoding . . . . . . . . . . . . . . . . . 48 109 7.1.1. Data Packing Rules . . . . . . . . . . . . . . . . . 48 110 7.1.2. Path Flags . . . . . . . . . . . . . . . . . . . . . 48 111 7.1.3. Relation of operational flags with global message 112 flags . . . . . . . . . . . . . . . . . . . . . . . . 49 113 7.1.4. Content Path Selection . . . . . . . . . . . . . . . 49 114 7.1.5. LFBselect-TLV . . . . . . . . . . . . . . . . . . . . 49 115 7.1.6. OPER-TLV . . . . . . . . . . . . . . . . . . . . . . 50 116 7.1.7. Result TLV . . . . . . . . . . . . . . . . . . . . . 52 117 7.1.8. DATA TLV . . . . . . . . . . . . . . . . . . . . . . 55 118 7.1.9. SET and GET Relationship . . . . . . . . . . . . . . 56 119 7.2. Protocol Encoding Visualization . . . . . . . . . . . . . 57 120 7.3. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 60 121 7.3.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 61 122 7.3.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 64 123 7.4. Semantics of Message Direction . . . . . . . . . . . . . 64 124 7.5. Association Messages . . . . . . . . . . . . . . . . . . 65 125 7.5.1. Association Setup Message . . . . . . . . . . . . . . 65 126 7.5.2. Association Setup Response Message . . . . . . . . . 67 127 7.5.3. Association Teardown Message . . . . . . . . . . . . 68 128 7.6. Configuration Messages . . . . . . . . . . . . . . . . . 70 129 7.6.1. Config Message . . . . . . . . . . . . . . . . . . . 70 130 7.6.2. Config Response Message . . . . . . . . . . . . . . . 72 131 7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 74 132 7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 74 133 7.7.2. Query Response Message . . . . . . . . . . . . . . . 76 134 7.8. Event Notification Message . . . . . . . . . . . . . . . 78 135 7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 80 136 7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 82 137 8. High Availability Support . . . . . . . . . . . . . . . . . . 84 138 8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 84 139 8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 87 140 9. Security Considerations . . . . . . . . . . . . . . . . . . . 88 141 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 88 142 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 88 143 9.1.2. Message authentication . . . . . . . . . . . . . . . 89 144 9.2. ForCES PL and TML security service . . . . . . . . . . . 89 145 9.2.1. Endpoint authentication service . . . . . . . . . . . 89 146 9.2.2. Message authentication service . . . . . . . . . . . 89 147 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 89 148 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90 149 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 150 11.1. Normative References . . . . . . . . . . . . . . . . . . 91 151 11.2. Informational References . . . . . . . . . . . . . . . . 91 153 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 92 154 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 92 155 A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 93 156 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 94 157 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 94 158 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 94 159 A.6. Association Setup Response . . . . . . . . . . . . . . . 95 160 A.7. Association Teardown Message . . . . . . . . . . . . . . 96 161 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 97 162 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 102 163 B.2. Components . . . . . . . . . . . . . . . . . . . . . . . 102 164 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 103 165 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 107 166 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122 167 Intellectual Property and Copyright Statements . . . . . . . . . 124 169 1. Terminology and Conventions 171 1.1. Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [RFC2119]. 177 1.2. Other Notation 179 In table Table 1 and table Table 2 the following notation is used to 180 indicate multiplicity: 182 (value)+ .... means "1 or more instance of value" 184 (value)* .... means "0 or more instance of value" 186 2. Introduction 188 Forwarding and Control Element Separation (ForCES) defines an 189 architectural framework and associated protocols to standardize 190 information exchange between the control plane and the forwarding 191 plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined 192 the ForCES requirements, and RFC 3746 has defined the ForCES 193 framework. While there may be multiple protocols used within the 194 overall ForCES architecture, the term "ForCES protocol" and 195 "protocol" as used in this document refers to the protocol used to 196 standardize the information exchange between Control Elements (CEs) 197 and Forwarding Elements (FEs) only. 199 The ForCES FE model [FE-MODEL] presents a formal way to define FE 200 Logical Function Blocks (LFBs) using XML. LFB configuration 201 components, capabilities, and associated events are defined when the 202 LFB is formally created. The LFBs within the FE are accordingly 203 controlled in a standardized way by the ForCES protocol. 205 This document defines the ForCES protocol specifications. The ForCES 206 protocol works in a master-slave mode in which FEs are slaves and CEs 207 are masters. The protocol includes commands for transport of Logical 208 Function Block(LFB) configuration information, association setup, 209 status, and event notifications, etc. 211 This specification does not define a transport mechanism for protocol 212 messages. A discussion of service primitives that must be provided 213 by the underlying transport interface will be discussed in a future 214 document. 216 Section 3 provides a glossary of terminology used in the 217 specification. 219 Section 4 provides an overview of the protocol, including a 220 discussion on the protocol framework, descriptions of the Protocol 221 Layer (PL) and a Transport Mapping Layer (TML), as well as of the 222 ForCES protocol mechanisms. Section 4.4 describes several Protocol 223 scenarios and includes message exchange descriptions. 225 While this document does not define the TML, Section 5 details the 226 services that a TML must provide (TML requirements). 228 The ForCES protocol defines a common header for all protocol 229 messages. The header is defined in Section 6.1, while the protocol 230 messages are defined in Section 7. 232 Section 8 describes the protocol support for high availability 233 mechanisms including redundancy and fail over. 235 Section 9 defines the security mechanisms provided by the PL and TML. 237 3. Definitions 239 This document follows the terminology defined by the ForCES 240 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 241 The definitions below are repeated below for clarity. 243 Addressable Entity (AE) - A physical device that is directly 244 addressable given some interconnect technology. For example, on IP 245 networks, it is a device which can be reached using an IP address; 246 and on a switch fabric, it is a device which can be reached using a 247 switch fabric port number. 249 Control Element (CE) - A logical entity that implements the ForCES 250 protocol and uses it to instruct one or more FEs on how to process 251 packets. CEs handle functionality such as the execution of control 252 and signaling protocols. 254 CE Manager (CEM) - A logical entity responsible for generic CE 255 management tasks. It is particularly used during the pre-association 256 phase to determine with which FE(s) a CE should communicate. This 257 process is called FE discovery and may involve the CE manager 258 learning the capabilities of available FEs. 260 Datapath - A conceptual path taken by packets within the forwarding 261 plane inside an FE. 263 Forwarding Element (FE) - A logical entity that implements the ForCES 264 protocol. FEs use the underlying hardware to provide per-packet 265 processing and handling as directed/controlled by one or more CEs via 266 the ForCES protocol. 268 FE Model - A model that describes the logical processing functions of 269 an FE. The FE model is defined using Logical Function Blocks (LFBs). 271 FE Manager (FEM) - A logical entity responsible for generic FE 272 management tasks. It is used during pre-association phase to 273 determine with which CE(s) an FE should communicate. This process is 274 called CE discovery and may involve the FE manager learning the 275 capabilities of available CEs. An FE manager may use anything from a 276 static configuration to a pre-association phase protocol (see below) 277 to determine which CE(s) to use. Being a logical entity, an FE 278 manager might be physically combined with any of the other logical 279 entities such as FEs. 281 ForCES Network Element (NE) - An entity composed of one or more CEs 282 and one or more FEs. To entities outside an NE, the NE represents a 283 single point of management. Similarly, an NE usually hides its 284 internal organization from external entities. 286 High Touch Capability - This term will be used to apply to the 287 capabilities found in some forwarders to take action on the contents 288 or headers of a packet based on content other than what is found in 289 the IP header. Examples of these capabilities include NAT-PT, 290 firewall, and L7 content recognition. 292 Inter-FE Topology - See FE Topology. 294 Intra-FE Topology - See LFB Topology. 296 LFB (Logical Function Block) - The basic building block that is 297 operated on by the ForCES protocol. The LFB is a well defined, 298 logically separable functional block that resides in an FE and is 299 controlled by the CE via ForCES protocol. The LFB may reside at the 300 FE's datapath and process packets or may be purely an FE control or 301 configuration entity that is operated on by the CE. Note that the 302 LFB is a functionally accurate abstraction of the FE's processing 303 capabilities, but not a hardware-accurate representation of the FE 304 implementation. 306 FE Topology - A representation of how the multiple FEs within a 307 single NE are interconnected. Sometimes this is called inter-FE 308 topology, to be distinguished from intra-FE topology (i.e., LFB 309 topology). 311 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. An 312 LFB Instance represents an LFB Class (or Type) existence. There may 313 be multiple instances of the same LFB Class (or Type) in an FE. An 314 LFB Class is represented by an LFB Class ID, and an LFB Instance is 315 represented by an LFB Instance ID. As a result, an LFB Class ID 316 associated with an LFB Instance ID uniquely specifies an LFB 317 existence. 319 LFB Metadata - Metadata is used to communicate per-packet state from 320 one LFB to another, but is not sent across the network. The FE model 321 defines how such metadata is identified, produced and consumed by the 322 LFBs. It defines the functionality but not how metadata is encoded 323 within an implementation. 325 LFB Attribute - Operational parameters of the LFBs that must be 326 visible to the CEs are conceptualized in the FE model as the LFB 327 attributes. The LFB attributes include, for example, flags, single 328 parameter arguments, complex arguments, and tables that the CE can 329 read and/or write via the ForCES protocol (see below). 331 LFB Topology - Representation of how the LFB instances are logically 332 interconnected and placed along the datapath within one FE. 333 Sometimes it is also called intra-FE topology, to be distinguished 334 from inter-FE topology. 336 Pre-association Phase - The period of time during which an FE Manager 337 and a CE Manager are determining which FE(s) and CE(s) should be part 338 of the same network element. 340 Post-association Phase - The period of time during which an FE knows 341 which CE is to control it and vice versa. This includes the time 342 during which the CE and FE are establishing communication with one 343 another. 345 ForCES Protocol - While there may be multiple protocols used within 346 the overall ForCES architecture, the term "ForCES protocol" and 347 "protocol" refer to the Fp reference point in the ForCES Framework in 348 [RFC3746]. This protocol does not apply to CE-to-CE communication, 349 FE-to-FE communication, or to communication between FE and CE 350 managers. Basically, the ForCES protocol works in a master-slave 351 mode in which FEs are slaves and CEs are masters. This document 352 defines the specifications for this ForCES protocol. 354 ForCES Protocol Layer (ForCES PL) - A layer in ForCES protocol 355 architecture that defines the ForCES protocol messages, the protocol 356 state transfer scheme, as well as the ForCES protocol architecture 357 itself (including requirements of ForCES TML as shown below). 358 Specifications of ForCES PL are defined by this document. 360 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 361 ForCES protocol architecture that uses the capabilities of existing 362 transport protocols to specifically address protocol message 363 transportation issues, such as how the protocol messages are mapped 364 to different transport media (like TCP, IP, ATM, Ethernet, etc), and 365 how to achieve and implement reliability, multicast, ordering, etc. 366 The ForCES TML specifications are detailed in separate ForCES 367 documents, one for each TML. 369 4. Overview 371 The reader is referred to the Framework document [RFC3746], and in 372 particular sections 3 and 4, for an architectural overview and an 373 explanation of how the ForCES protocol fits in. There may be some 374 content overlap between the framework document and this section in 375 order to provide clarity. This document is authoritative on the 376 protocol whereas [RFC3746] is authoritative on the architecture. 378 4.1. Protocol Framework 380 Figure 1 below is reproduced from the Framework document for clarity. 381 It shows a NE with two CEs and two FEs. 383 --------------------------------------- 384 | ForCES Network Element | 385 -------------- Fc | -------------- -------------- | 386 | CE Manager |---------+-| CE 1 |------| CE 2 | | 387 -------------- | | | Fr | | | 388 | | -------------- -------------- | 389 | Fl | | | Fp / | 390 | | Fp| |----------| / | 391 | | | |/ | 392 | | | | | 393 | | | Fp /|----| | 394 | | | /--------/ | | 395 -------------- Ff | -------------- -------------- | 396 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 397 -------------- | | |------| | | 398 | -------------- -------------- | 399 | | | | | | | | | | 400 ----+--+--+--+----------+--+--+--+----- 401 | | | | | | | | 402 | | | | | | | | 403 Fi/f Fi/f 405 Fp: CE-FE interface 406 Fi: FE-FE interface 407 Fr: CE-CE interface 408 Fc: Interface between the CE Manager and a CE 409 Ff: Interface between the FE Manager and an FE 410 Fl: Interface between the CE Manager and the FE Manager 411 Fi/f: FE external interface 413 Figure 1: ForCES Architectural Diagram 415 The ForCES protocol domain is found in the Fp Reference Point. The 416 Protocol Element configuration reference points, Fc and Ff also play 417 a role in the booting up of the ForCES Protocol. The protocol 418 element configuration (indicated by reference points Fc, Ff, and Fl 419 in [RFC3746] ) is out of scope of the ForCES protocol but is touched 420 on in this document in discussion of FEM and CEM since it is an 421 integral part of the protocol pre-association phase. 423 Figure 2 below shows further breakdown of the Fp interface by example 424 of an MPLS QoS enabled Network Element. 426 ------------------------------------------------- 427 | | | | | | | 428 |OSPF |RIP |BGP |RSVP |LDP |. . . | 429 | | | | | | | 430 ------------------------------------------------- CE 431 | ForCES Interface | 432 ------------------------------------------------- 433 ^ ^ 434 | | 435 ForCES | |data 436 control | |packets 437 messages| |(e.g., routing packets) 438 | | 439 v v 440 ------------------------------------------------- 441 | ForCES Interface | 442 ------------------------------------------------- FE 443 | | | | | | | 444 |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | 445 | | | | |fier | | 446 ------------------------------------------------- 448 Figure 2: Examples of CE and FE functions 450 The ForCES Interface shown in Figure 2 constitutes two pieces: the PL 451 and the TML. 453 This is depicted in Figure 3 below. 455 +------------------------------------------------ 456 | CE PL | 457 +------------------------------------------------ 458 | CE TML | 459 +------------------------------------------------ 460 ^ 461 | 462 ForCES | (i.e ForCES data + control 463 PL | packets ) 464 messages | 465 over | 466 specific | 467 TML | 468 encaps | 469 and | 470 transport | 471 | 472 v 473 +------------------------------------------------ 474 | FE TML | 475 +------------------------------------------------ 476 | FE PL | 477 +------------------------------------------------ 479 Figure 3: ForCES Interface 481 The PL is in fact the ForCES protocol. Its semantics and message 482 layout are defined in this document. The TML Layer is necessary to 483 connect two ForCES PLs as shown in Figure 3 above. The TML is out of 484 scope for this document but is within scope of ForCES. This document 485 defines requirements the PL needs the TML to meet. 487 Both the PL and the TML are standardized by the IETF. While only one 488 PL is defined, different TMLs are expected to be standardized. To 489 interoperate the TML at the CE and FE are expected to conform to the 490 same definition. 492 On transmit, the PL delivers its messages to the TML. The local TML 493 delivers the message to the destination TML. On receive, the TML 494 delivers the message to its destination PL. 496 4.1.1. The PL 498 The PL is common to all implementations of ForCES and is standardized 499 by the IETF as defined in this document. The PL is responsible for 500 associating an FE or CE to an NE. It is also responsible for tearing 501 down such associations. An FE uses the PL to transmit various 502 subscribed-to events to the CE PL as well as to respond to various 503 status requests issued from the CE PL. The CE configures both the FE 504 and associated LFBs' operational parameters using the PL. In 505 addition the CE may send various requests to the FE to activate or 506 deactivate it, reconfigure its HA parameterization, subscribe to 507 specific events etc. More details can be found in Section 7. 509 4.1.2. The TML 511 The TML transports the PL messages. The TML is where the issues of 512 how to achieve transport level reliability, congestion control, 513 multicast, ordering, etc. are handled. It is expected that more than 514 one TML will be standardized. The various possible TMLs could vary 515 their implementations based on the capabilities of underlying media 516 and transport. However, since each TML is standardized, 517 interoperability is guaranteed as long as both endpoints support the 518 same TML. All ForCES Protocol Layer implementations MUST be portable 519 across all TMLs, because all TMLs MUST have the top edge semantics 520 defined in this document. 522 4.1.3. The FEM/CEM Interface 524 The FEM and CEM components, although valuable in the setup and 525 configurations of both the PL and TML, are out of scope of the ForCES 526 protocol. The best way to think of them is as configurations/ 527 parameterizations for the PL and TML before they become active (or 528 even at runtime based on implementation). In the simplest case, the 529 FE or CE reads a static configuration file. RFC 3746 has a more 530 detailed description on how the FEM and CEM could be used. The pre- 531 association phase, where the CEM and FEM can be used, are described 532 briefly in Section 4.2.1. 534 An example of typical things the FEM/CEM could configure would be TML 535 specific parameterizations such as: 537 a. How the TML connection should happen (for example what IP 538 addresses to use, transport modes etc); 540 b. The ID for the FE or CE (which would also be issued during the 541 pre-association phase). 543 c. Security parameterization such as keys etc. 545 d. Connection association parameters 547 Example of connection association parameters this might be: 549 o simple parameters: send up to 3 association messages every 1 550 second 552 o complex parameters: send up to 4 association messages with 553 increasing exponential timeout 555 4.2. ForCES Protocol Phases 557 ForCES, in relation to NEs, involves two phases: the Pre-Association 558 phase, where configuration/initialization/bootup of the TML and PL 559 layer happens, and the association phase where the ForCES protocol 560 operates to manipulate the parameters of the FEs. 562 CE sends Association Setup 563 +---->--->------------>---->---->---->------->----+ 564 | Y 565 ^ | 566 | Y 567 +---+-------+ +-------------+ 568 |FE Pre- | | FE | 569 |Association| CE sends Association Teardown | Associated | 570 |Phase |<------- <------<-----<------<-------+ | 571 | | | | 572 +-----------+ +-------------+ 573 ^ Y 574 | | 575 +-<---<------<-----<------<----<---------<------+ 576 FE loses association 578 Figure 4: The FE State Machine 580 In the mandated case, once associated, the FE may forward packets 581 depending on the configuration of its specific LFBs. An FE which is 582 associated to a CE will continue sending packets until it receives an 583 Association teardown message or until it loses association. An 584 unassociated FE MAY continue sending packets when it is capable high 585 availability. The extra details are explained in Section 8 and not 586 discussed here to allow for a clear explanation of the basics. 588 The FE state transitions are controlled by means of the FE Object LFB 589 FEState component, which is defined in [FE-MODEL] and also explained 590 in Section 7.3.2. 592 The FE initializes in the FEState OperDisable. When the FE is ready 593 to process packets in the data path it transitions itself to the 594 OperEnable state. 596 The CE may decide to pause the FE after it already came up as 597 OperEnable. It does this by setting the FEState to AdminDisable. 598 The FE stays in the AdminDisable state until it is explicitly 599 configured by the CE to transition to the OperEnable. 601 When the FE loses its association with the CE it may go into the pre- 602 association phase depending on the programmed policy. For the FE to 603 properly complete the transition to the AdminDisable state, it MUST 604 stop Packet forwarding and this may impact multiple LFBS. How this 605 is achieved is outside the scope of this specification. 607 4.2.1. Pre-association 609 The ForCES interface is configured during the pre-association phase. 610 In a simple setup, the configuration is static and is read from a 611 saved configuration file. All the parameters for the association 612 phase are well known after the pre-association phase is complete. A 613 protocol such as DHCP may be used to retrieve the configuration 614 parameters instead of reading them from a static configuration file. 615 Note, this will still be considered static pre-association. Dynamic 616 configuration may also happen using the Fc, Ff and Fl reference 617 points (refer to [RFC3746]). Vendors may use their own proprietary 618 service discovery protocol to pass the parameters. Essentially, only 619 guidelines are provided here and the details are left to the 620 implementation. 622 The following are scenarios reproduced from the Framework Document to 623 show a pre-association example. 625 <----Ff ref pt---> <--Fc ref pt-------> 626 FE Manager FE CE Manager CE 627 | | | | 628 | | | | 629 (security exchange) (security exchange) 630 1|<------------>| authentication 1|<----------->|authentication 631 | | | | 632 (FE ID, components) (CE ID, components) 633 2|<-------------| request 2|<------------|request 634 | | | | 635 3|------------->| response 3|------------>|response 636 (corresponding CE ID) (corresponding FE ID) 637 | | | | 638 | | | | 640 Figure 5: Examples of a message exchange over the Ff and Fc reference 641 points 643 <-----------Fl ref pt--------------> | 645 FE Manager FE CE Manager CE 646 | | | | 647 | | | | 648 (security exchange) | | 649 1|<------------------------------>| | 650 | | | | 651 (a list of CEs and their components) | 652 2|<-------------------------------| | 653 | | | | 654 (a list of FEs and their components) | 655 3|------------------------------->| | 656 | | | | 657 | | | | 659 Figure 6: An example of a message exchange over the Fl reference 660 point 662 Before the transition to the association phase, the FEM will have 663 established contact with a CEM component. Initialization of the 664 ForCES interface will have completed, and authentication as well as 665 capability discovery may be complete. Both the FE and CE would have 666 the necessary information for connecting to each other for 667 configuration, accounting, identification, and authentication 668 purposes. To summarize, at the completion of this stage both sides 669 have all the necessary protocol parameters such as timers, etc. The 670 Fl reference point may continue to operate during the association 671 phase and may be used to force a disassociation of an FE or CE. 672 Because the pre-association phase is out of scope, these details are 673 not discussed any further in this specification. The reader is 674 referred to the framework document [RFC3746] for a slightly more 675 detailed discussion. 677 4.2.2. Post-association 679 In this phase, the FE and CE components communicate with each other 680 using the ForCES protocol (PL over TML) as defined in this document. 681 There are three sub-phases: 683 o Association Setup Stage 685 o Established Stage 687 o Association Lost Stage 689 4.2.2.1. Association Setup Stage 691 The FE attempts to join the NE. The FE may be rejected or accepted. 692 Once granted access into the NE, capabilities exchange happens with 693 the CE querying the FE. Once the CE has the FE capability 694 information, the CE can offer an initial configuration (possibly to 695 restore state) and can query certain components within either an LFB 696 or the FE itself. 698 More details are provided in Section 4.4. 700 On successful completion of this stage, the FE joins the NE and is 701 moved to the Established Stage. 703 4.2.2.2. Established Stage 705 In this stage, the FE is continuously updated or queried. The FE may 706 also send asynchronous event notifications to the CE or synchronous 707 heartbeat notifications if programmed to do so. This stage continues 708 until a termination occurs, either due to loss of connectivity or due 709 to a termination initiated by either the CE or the FE. 711 Refer to the section on protocol scenarios, Section 4.4, for more 712 details. 714 4.2.2.3. Association Lost Stage 716 In this state, both or either the CE or FE declare the other side is 717 no longer associated. The disconnection could be initiated by either 718 party for administrative purposes but may also be driven by 719 operational reasons such as loss of connectivity. 721 A core LFB known as FE Protocol Object (FEPO) is defined (refer to 722 Appendix B and Section 7.3.1). FEPO defines various timers which can 723 be used in conjunction with traffic sensitive heartbeat mechanism 724 (Section 4.3.3) to detect loss of connectivity. 726 The loss of connectivity between TMLs does not indicate a loss of 727 association between respective PL layers. If the TML cannot repair 728 the transport loss before the programmed FEPO timer thresholds 729 associated with the FE is exceeded, then the association between the 730 respective PL layers will be lost. 732 FEPO defines several policies that can be programmed to define 733 behavior upon a detected loss of association. The FEPO's programmed 734 CE failover policy (refer to Section 8, Section 7.3.1, Section 4.3.3 735 and Appendix B) defines what takes place upon loss of association. 737 For this version of the protocol (as defined in this document), the 738 FE, upon re-association, MUST discard any state it has as invalid and 739 retrieve new state. This approach is motivated by a desire for 740 simplicity (as opposed to efficiency). 742 4.3. Protocol Mechanisms 744 Various semantics are exposed to the protocol users via the PL header 745 including: transaction capabilities, atomicity of transactions, two 746 phase commits, batching/parallelization, high availability and 747 failover as well as command pipelines. 749 The EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP 750 (Transaction Phase) flag as defined in the Common Header 751 (Section 6.1) are relevant to these mechanisms. 753 4.3.1. Transactions, Atomicity, Execution and Responses 755 In the master-slave relationship the CE instructs one or more FEs on 756 how to execute operations and how to report the results. 758 This section details the different modes of execution that a CE can 759 order the FE(s) to perform, as defined in Section 4.3.1.1. It also 760 describes the different modes a CE can ask the FE(s) to use for 761 formatting the responses after processing the operations as 762 requested. These modes relate to the transactional two phase 763 commitment operations. 765 4.3.1.1. Execution 767 There are 3 execution modes that can be requested for a batch of 768 operations spanning one or more LFB selectors (refer to 769 Section 7.1.5) in one protocol message. The EM flag defined in the 770 Common Header Section 6.1 selects the execution mode for a protocol 771 message, as below: 773 a. execute-all-or-none 775 b. execute-until-failure 777 c. continue-execute-on-failure 779 4.3.1.1.1. execute-all-or-none 781 When set to this mode of execution, independent operations in a 782 message MAY be targeted at one or more LFB selectors within an FE. 783 All these operations are executed serially and the FE MUST have no 784 execution failure for any of the operations. If any operation fails 785 to execute, then all the previous ones that have been executed prior 786 to the failure will need to be undone. I.e., there is rollback for 787 this mode of operation. 789 Refer to Section 4.3.1.2.2 for how this mode is used in cases of 790 transactions. In such a case, no operation is executed unless a 791 commit is issued by the CE. 793 Care should be taken on how this mode is used because a mis- 794 configuration could result in traffic losses. To add certainty to 795 the success of an operation, one should use this mode in a 796 transactional operation as described in Section 4.3.1.2.2 798 4.3.1.1.2. continue-execute-on-failure 800 If several independent operations are targeted at one or more LFB 801 selectors, execution continues for all operations at the FE even if 802 one or more operations fail. 804 4.3.1.1.3. execute-until-failure 806 In this mode all operations are executed on the FE sequentially until 807 the first failure. The rest of the operations are not executed but 808 operations already completed are not undone. I.e., there is no 809 rollback in this mode of operation. 811 4.3.1.2. Transaction and Atomicity 813 4.3.1.2.1. Transaction Definition 815 A transaction is defined as a collection of one or more ForCES 816 operations within one or more PL messages that MUST meet the ACIDity 817 properties [ACID], defined as: 819 Atomicity: In a transaction involving two or more discrete pieces 820 of information, either all of the pieces are committed 821 or none are. 823 Consistency: A transaction either creates a new and valid state of 824 data, or, if any failure occurs, returns all data to the 825 state it was in before the transaction was started. 827 Isolation: A transaction in process and not yet committed must 828 remain isolated from any other transaction. 830 Durability: Committed data is saved by the system such that, even in 831 the event of a failure and a system restart, the data is 832 available in its correct state. 834 There are cases where the CE knows exact memory and implementation 835 details of the FE such as in the case of an FE-CE pair from the same 836 vendor where the FE-CE pair is tightly coupled. In such a case, the 837 transactional operations may be simplified further by extra 838 computation at the CE. This view is not discussed further other than 839 to mention that it is not disallowed. 841 As defined above, a transaction is always atomic and MAY be 843 a. Within an FE alone 844 Example: updating multiple tables that are dependent on each 845 other. If updating one fails, then any that were already updated 846 must be undone. 848 b. Distributed across the NE 849 Example: updating table(s) that are inter-dependent across 850 several FEs (such as L3 forwarding related tables). 852 4.3.1.2.2. Transaction Protocol 854 By use of the execute mode, as defined in Section 4.3.1.1, the 855 protocol has provided a mechanism for transactional operations within 856 one stand-alone message. The 'execute-all-or-none' mode can meet the 857 ACID requirements. 859 For transactional operations of multiple messages within one FE or 860 across FEs, a classical transactional protocol known as Two Phase 861 Commit (2PC) [2PCREF] is supported by the protocol to achieve the 862 transactional operations utilizing Config messages (Section 7.6.1). 864 The COMMIT and TRCOMP operations in conjunction with the AT and the 865 TP flags in Common Header (Section 6.1) are provided for 2PC-based 866 transactional operations spanning multiple messages. 868 The AT flag, when set, indicates this message belongs to an Atomic 869 Transaction. All messages for a transaction operation must have the 870 AT flag set. If not set, it means the message is a stand-alone 871 message and does not participate in any transaction operation that 872 spans multiple messages. 874 The TP flag indicates the Transaction Phase this message belongs to. 875 There are four (4) possible phases for an transactional operation 876 known as: 878 SOT (Start of Transaction) 880 MOT (Middle of Transaction) 882 EOT (End of Transaction) 884 ABT (Abort) 886 The COMMIT operation is used by the CE to signal to the FE(s) to 887 commit a transaction. When used with an ABT TP flag, the COMMIT 888 operation signals the FE(s) to rollback (i.e un-COMMIT) a previously 889 committed transaction. 891 The TRCOMP operation is a small addition to the classical 2PC 892 approach. TRCOMP is sent by the CE to signal the FE(s) that the 893 transaction they have COMMITed is now over. This allows the FE(s) an 894 opportunity to clear state they may have kept around to perform a 895 rollback (if it became necessary). 897 A transaction operation is started with a message the TP flag is set 898 to Start of Transaction (SOT). Multi-part messages, after the first 899 one, are indicated by the Middle of Transaction flag (MOT). All 900 messages from the CE MUST set the AlwaysACK flag (Section 6) to 901 solicit responses from the FE(s). 903 Before the CE issues a commit (described further below) the FE MUST 904 only validate that the operation can be executed but not execute it. 906 Any failure notified by an FE causes the CE to abort the 907 transaction on all FEs involved in the transaction. This is 908 achieved by sending a Config message with an ABT flag and a COMMIT 909 operation. 911 If there are no failures by any participating FE, the transaction 912 commitment phase is signaled from the CE to the FE by an End of 913 Transaction (EOT) configuration message with a COMMIT operation. 915 The FE MUST respond to the CE's EOT message. There are two possible 916 failure scenarios in which the CE MUST abort the transaction (as 917 described above): 919 a. If any participating FE responds with a failure message in 920 relation to the transaction. 922 b. If no response is received from a participating FE within a 923 specified timeout. 925 If all participating FE(s) respond with a success indicator within 926 the expected time, then the CE MUST issue a TRCOMP operation to all 927 participating FEs. An FE MUST NOT respond to a TRCOMP. 929 Note that a transactional operation is generically atomic, therefore 930 it requires that the execute modes of all messages in a transaction 931 operation should always be kept the same and be set to 'execute-all- 932 or-none'. If the EM flag is set to other execute modes, it will 933 result in a transaction failure. 935 As noted above, a transaction may span multiple messages. It is up 936 to the CE to keep track of the different outstanding messages making 937 up a transaction. As an example, the correlator field could be used 938 to mark transactions and a sequence field to label the different 939 messages within the same atomic transaction, but this is out of scope 940 and up to implementations. 942 4.3.1.2.3. Recovery 944 Any of the participating FEs, or the CE, or the associations between 945 them, may fail after the EOT response message has been sent by the FE 946 but before the CE has received all the responses, e.g. if the EOT 947 response never reaches the CE. 949 In this protocol revision, as indicated in Section 4.2.2.3, an FE 950 losing an association would be required to get entirely new state 951 from the newly associated CE upon a re-association. Although this 952 approach is simplistic and provides likeliness of loosing datapath 953 traffic, it is a design choice to avoid the additional complexity of 954 managing graceful restarts. The HA mechanisms (Section 8) are 955 provided to allow for a continuous operation in case of FE failures. 957 Flexibility is provided on how to react when an FE looses 958 association. This is dictated by the CE Failover policy (refer to 959 Section 8 and Section 7.3). 961 4.3.1.2.4. Transaction Messaging Example 963 This section illustrates an example of how a successful two phase 964 commit between a CE and an FE would look like in the simple case. 966 FE PL CE PL 968 | | 969 | (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc | 970 |<-----------------------------------------------------| 971 | | 972 | (2) ACKnowledge | 973 |----------------------------------------------------->| 974 | | 975 | (3) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc | 976 |<-----------------------------------------------------| 977 | | 978 | (4) ACKnowledge | 979 |----------------------------------------------------->| 980 | | 981 | (5) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc | 982 |<-----------------------------------------------------| 983 | | 984 | (6) ACKnowledge | 985 |----------------------------------------------------->| 986 . . 987 . . 988 . . 989 . . 990 | | 991 | (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT | 992 |<-----------------------------------------------------| 993 | | 994 | (N+1)Config-response, ACKnowledge, OP=COMMIT-RESPONSE| 995 |----------------------------------------------------->| 996 | | 997 | (N+2) Config, OP=TRCOMP | 998 |<-----------------------------------------------------| 1000 Figure 7: Example of a two phase commit 1002 For the scenario illustrated above: 1004 o In step #1, the CE issues a Config message with an operation of 1005 choice like a DEL or SET. The transactional flag are set to 1006 indicate a Start of Transaction (SOT), Atomic Transaction (AT), 1007 execute-all-or-none. 1009 o The FE validates that it can execute the request successfully and 1010 then issues an acknowledgment back to the the CE in step #2. 1012 o In step #3, the same sort of construct as in step #1 is repeated 1013 by the CE with the transaction flag changed to Middle of 1014 Transaction(MOT). 1016 o The FE validates that it can execute the request successfully and 1017 then issues an acknowledgment back to the the CE in step #4. 1019 o The CE-FE exchange continues in the same manner until all the 1020 operations and their parameters are transferred to the FE. This 1021 happens in step #(N-1). 1023 o In step #N, the CE issues a commit. A commit is a config message 1024 with an operation of type COMMIT. The transactional flags are set 1025 to End of Transaction (EOT). Essentially, this is an "empty" 1026 message asking the FE to execute all the operations it has 1027 gathered since the beginning of the transaction (message #1). 1029 o The FE at this point executes the full transaction. It then 1030 issues an acknowledgment back to the the CE in step #(N+1) which 1031 contains a COMMIT-RESPONSE. 1033 o The CE in this case has the simple task of issuing a TRCOMP 1034 operation the the FE in step #(N+2) 1036 4.3.2. Scalability 1038 It is desirable that the PL not become the bottleneck when larger 1039 bandwidth pipes become available. To pick a hypothetical example in 1040 today's terms, if a 100Gbps pipe is available and there is sufficient 1041 work then the PL should be able to take advantage of this and use all 1042 of the 100Gbps pipe. Two mechanisms have been provided to achieve 1043 this. The first one is batching and the second one is a command 1044 pipeline. 1046 Batching is the ability to send multiple commands (such as Config) in 1047 one Protocol Data Unit (PDU). The size of the batch will be affected 1048 by, amongst other things, the path MTU. The commands may be part of 1049 the same transaction or may be part of unrelated transactions that 1050 are independent of each other. 1052 Command pipelining allows for pipelining of independent transactions 1053 which do not affect each other. Each independent transaction could 1054 consist of one or more batches. 1056 4.3.2.1. Batching 1058 There are several batching levels at different protocol hierarchies. 1060 o multiple PL PDUs can be aggregated under one TML message 1061 o multiple LFB classes and instances (as indicated in the LFB 1062 selector) can be addressed within one PL PDU 1064 o Multiple operations can be addressed to a single LFB class and 1065 instance 1067 4.3.2.2. Command Pipelining 1069 The protocol allows any number of messages to be issued by the CE 1070 before the corresponding acknowledgments (if requested) have been 1071 returned by the FE. Hence pipelining is inherently supported by the 1072 protocol. Matching responses with requests messages can be done 1073 using the correlator field in the message header. 1075 4.3.3. Heartbeat Mechanism 1077 Heartbeats (HB) between FEs and CEs are traffic sensitive. An HB is 1078 sent only if no PL traffic is sent between the CE and FE within a 1079 configured interval. This has the effect of reducing the amount of 1080 HB traffic in the case of busy PL periods. 1082 An HB can be sourced by either the CE or FE. When sourced by the CE, 1083 a response can be requested (similar to the ICMP ping protocol). The 1084 FE can only generate HBs in the case of being configured to do so by 1085 the CE. Refer to Section 7.3.1 and Section 7.10 for details. 1087 4.3.4. FE Object and FE Protocol LFBs 1089 All PL messages operate on LFB constructs, as this provides more 1090 flexibility for future enhancements. This means that maintenance and 1091 configurability of FEs, NE, as well as the ForCES protocol itself 1092 must be expressed in terms of this LFB architecture. For this reason 1093 special LFBs are created to accommodate this need. 1095 In addition, this shows how the ForCES protocol itself can be 1096 controlled by the very same type of structures (LFBs) it uses to 1097 control functions such as IP forwarding, filtering, etc. 1099 To achieve this, the following specialized LFBs are introduced: 1101 o FE Protocol LFB which is used to control the ForCES protocol. 1103 o FE Object LFB which is used to control attributes relative to the 1104 FE itself. Such attributes include FEState [FE-MODEL], vendor, 1105 etc. 1107 These LFBs are detailed in Section 7.3. 1109 4.4. Protocol Scenarios 1111 This section provides a very high level description of sample message 1112 sequences between a CE and FE. For protocol message encoding refer 1113 to Section 6.1 and for the semantics of the protocol refer to 1114 Section 4.3. 1116 4.4.1. Association Setup State 1118 The associations among CEs and FEs are initiated via Association 1119 setup message from the FE. If a setup request is granted by the CE, 1120 a successful setup response message is sent to the FE. If CEs and 1121 FEs are operating in an insecure environment then the security 1122 associations have to be established between them before any 1123 association messages can be exchanged. The TML will take care of 1124 establishing any security associations. 1126 This is typically followed by capability query, topology query, etc. 1127 When the FE is ready to start processing the data path, it sets the 1128 FEO FEState component to OperEnable (Refer to [FE-MODEL] for details) 1129 and reports it to the CE as such when it is first queried. Typically 1130 the FE is expected to be ready to process the data path before it 1131 associates, but there maybe rare cases where it needs time do some 1132 pre-processing - in such a case the FE will start in the OperDisable 1133 state and when it is ready will transition to OperEnable state. An 1134 example of an FE starting in the OperDisable then transitioning to 1135 OperEnable is illustrated in Figure 8. The CE could at any time also 1136 disable the FEs datapath operations by setting the FEState to 1137 AdminDisable. The FE MUST NOT process packets during this state 1138 unless the CE sets the state back to OperEnable. These sequences of 1139 messages are illustrated in Figure 8 below. 1141 FE PL CE PL 1143 | | 1144 | Asso Setup Req | 1145 |---------------------->| 1146 | | 1147 | Asso Setup Resp | 1148 |<----------------------| 1149 | | 1150 | LFBx Query capability | 1151 |<----------------------| 1152 | | 1153 | LFBx Query Resp | 1154 |---------------------->| 1155 | | 1156 | FEO Query (Topology) | 1157 |<----------------------| 1158 | | 1159 | FEO Query Resp | 1160 |---------------------->| 1161 | | 1162 | FEO OperEnable Event | 1163 |---------------------->| 1164 | | 1165 | Config FEO Adminup | 1166 |<----------------------| 1167 | | 1168 | FEO Config-Resp | 1169 |---------------------->| 1170 | | 1172 Figure 8: Message exchange between CE and FE to establish an NE 1173 association 1175 On successful completion of this state, the FE joins the NE. 1177 4.4.2. Association Established state or Steady State 1179 In this state, the FE is continuously updated or queried. The FE may 1180 also send asynchronous event notifications to the CE, synchronous 1181 heartbeat messages, or packet redirect message to the CE. This 1182 continues until a termination (or deactivation) is initiated by 1183 either the CE or FE. Figure 9 below, helps illustrate this state. 1185 FE PL CE PL 1187 | | 1188 | Heart Beat | 1189 |<---------------------------->| 1190 | | 1191 | Heart Beat | 1192 |----------------------------->| 1193 | | 1194 | Config-set LFBy (Event sub.) | 1195 |<-----------------------------| 1196 | | 1197 | Config Resp LFBy | 1198 |----------------------------->| 1199 | | 1200 | Config-set LFBx Attr | 1201 |<-----------------------------| 1202 | | 1203 | Config Resp LFBx | 1204 |----------------------------->| 1205 | | 1206 |Config-Query LFBz (Stats) | 1207 |<--------------------------- -| 1208 | | 1209 | Query Resp LFBz | 1210 |----------------------------->| 1211 | | 1212 | FE Event Report | 1213 |----------------------------->| 1214 | | 1215 | Config-Del LFBx Attr | 1216 |<-----------------------------| 1217 | | 1218 | Config Resp LFBx | 1219 |----------------------------->| 1220 | | 1221 | Packet Redirect LFBx | 1222 |----------------------------->| 1223 | | 1224 | Heart Beat | 1225 |<-----------------------------| 1226 . . 1227 . . 1228 | | 1230 Figure 9: Message exchange between CE and FE during steady-state 1231 communication 1233 Note that the sequence of messages shown in the figure serve only as 1234 examples and the message exchange sequences could be different from 1235 what is shown in the figure. Also, note that the protocol scenarios 1236 described in this section do not include all the different message 1237 exchanges that would take place during failover. That is described 1238 in the HA section (Section 8) . 1240 5. TML Requirements 1242 The requirements below are expected to be delivered by the TML. This 1243 text does not define how such mechanisms are delivered. As an 1244 example they could be defined to be delivered via hardware or between 1245 2 or more TML processes on different CEs or FEs in protocol level 1246 schemes. 1248 Each TML must describe how it contributes to achieving the listed 1249 ForCES requirements. If for any reason a TML does not provide a 1250 service listed below a justification needs to be provided. 1252 1. Reliability 1253 As defined by RFC 3654, section 6 #6. 1255 2. Security 1256 TML provides security services to the ForCES PL. A TML layer 1257 should support the following security services and describe how 1258 they are achieved. 1260 * Endpoint authentication of FE and CE 1262 * Message authentication 1264 * Confidentiality service 1266 3. Congestion control 1267 The congestion control scheme used needs to be defined. The 1268 congestion control mechanism defined by the TML should prevent 1269 the FE from being overloaded by the CE or the CE from being 1270 overwhelmed by traffic from the FE. Additionally, the 1271 circumstances under which notification is sent to the PL to 1272 notify it of congestion must be defined. 1274 4. Uni/multi/broadcast addressing/delivery, if any 1275 If there is any mapping between PL and TML level uni/multi/ 1276 broadcast addressing it needs to be defined. 1278 5. HA decisions 1279 It is expected that availability of transport links is the TML's 1280 responsibility. However, based upon its configuration, the PL 1281 may wish to participate in link failover schemes and therefore 1282 the TML must support this capability. 1283 Please refer to Section 8 for details. 1285 6. Encapsulations used 1286 Different types of TMLs will encapsulate the PL messages on 1287 different types of headers. The TML needs to specify the 1288 encapsulation used. 1290 7. Prioritization 1291 It is expected that the TML will be able to handle up to 8 1292 priority levels needed by the PL and will provide preferential 1293 treatment. 1295 While the TML needs to define how this is achieved, it should be 1296 noted that the requirement for supporting up to 8 priority levels 1297 does not mean that the underlying TML MUST be capable of 1298 providing up to 8 actual priority levels. In the event that the 1299 underlying TML layer does not have support for 8 priority levels, 1300 the supported priority levels should be divided between the 1301 available TML priority levels. For example, if the TML only 1302 supports 2 priority levels, the 0-3 could go in one TML priority 1303 level, while 4-7 could go in the other. 1305 The TML MUST NOT reorder config packets with the same priority. 1307 8. Protection against DoS attacks 1308 As described in RFC 3654, section 6 1310 5.1. TML Parameterization 1312 It is expected that it should be possible to use a configuration 1313 reference point, such as the FEM or the CEM, to configure the TML. 1315 Some of the configured parameters may include: 1317 o PL ID 1319 o Connection Type and associated data. For example if a TML uses 1320 IP/TCP/UDP, then parameters such as TCP and UDP port and IP 1321 addresses need to be configured. 1323 o Number of transport connections 1325 o Connection capability, such as bandwidth, etc. 1327 o Allowed/supported connection QoS policy (or congestion control 1328 policy) 1330 6. Message Encapsulation 1332 All PL PDUs start with a common header [Section 6.1] followed by a 1333 one or more TLVs [Section 6.2] which may nest other TLVs 1334 [Section 6.2.1]. All fields are in network byte order. 1336 6.1. Common Header 1338 0 1 2 3 1339 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 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 |version| rsvd | Message Type | Length | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Source ID | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Destination ID | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | Correlator[32:63] | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Correlator[0:31] | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Flags | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 Figure 10: Common Header 1356 The message is 32 bit aligned. 1358 Version (4 bit): 1359 Version number. Current version is 1. 1361 rsvd (4 bit): 1362 Unused at this point. A receiver should not interpret this 1363 field. Senders MUST set it to zero and receivers MUST ignore 1364 this field. 1366 Message Type (8 bits): 1367 Commands are defined in Section 7. 1369 Length (16 bits): 1370 length of header + the rest of the message in DWORDS (4 byte 1371 increments). 1373 Source ID (32 bit): 1375 Dest ID (32 bit): 1377 * Each of the source and destination IDs are 32 bit IDs which 1378 are unique NE-wide and which identify the termination points 1379 of a ForCES PL message. 1381 * IDs allow multi/broad/unicast addressing with the following 1382 approach: 1384 a. A split address space is used to distinguish FEs from 1385 CEs. Even though in a large NE there are typically two 1386 or more orders of magnitude more FEs than CEs, the 1387 address space is split uniformly for simplicity. 1389 b. The address space allows up to 2^30 (over a billion) CEs 1390 and the same amount of FEs. 1392 0 1 2 3 1393 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 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 |TS | sub-ID | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 Figure 11: ForCES ID Format 1400 c. The 2 most significant bits called Type Switch (TS) are 1401 used to split the ID space as follows: 1403 TS Corresponding ID range Assignment 1404 -- ---------------------- ---------- 1405 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 1406 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 1407 0b10 0x80000000 to 0xBFFFFFFF reserved 1408 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16) 1409 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 1410 0b11 0xFFFFFFFD all CEs broadcast 1411 0b11 0xFFFFFFFE all FEs broadcast 1412 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast 1414 Figure 12: Type Switch ID Space 1416 * Multicast or broadcast IDs are used to group endpoints (such 1417 as CEs and FES). As an example one could group FEs in some 1418 functional group, by assigning a multicast ID. Likewise, 1419 subgroups of CEs that act, for instance, in a back-up mode 1420 may be assigned a multicast ID to hide them from the FE. 1422 + Multicast IDs can be used for both source or destination 1423 IDs. 1425 + Broadcast IDs can be used only for destination IDs. 1427 * This document does not discuss how a particular multicast ID 1428 is associated to a given group though it could be done via 1429 configuration process. The list of IDs an FE owns or is part 1430 of are listed on the FE Object LFB. 1432 Correlator (64 bits) 1433 This field is set by the CE to correlate ForCES Request Messages 1434 with the corresponding Response messages from the FE. 1435 Essentially it is a cookie. The correlator is handled 1436 transparently by the FE, i.e., for a particular Request message 1437 the FE MUST assign the same correlator value in the corresponding 1438 Response message. In the case where the message from the CE does 1439 not elicit a response, this field may not be useful. 1441 The correlator field could be used in many implementations 1442 specific ways by the CE. For example, the CE could split the 1443 correlator into a 32-bit transactional identifier and 32-bit 1444 message sequence identifier. Another example is a 64-bit pointer 1445 to a context block. All such implementation specific use of the 1446 correlator is outside the scope of this specification. 1448 Whenever the correlator field is not relevant, because no message 1449 is expected, the correlator field is set to 0. 1451 Flags(32 bits): 1452 Identified so far: 1454 0 1 2 3 1455 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 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | | | | | | | | 1458 |ACK| Pri |Rsr |EM |A|TP | Reserved | 1459 | | | vd. | |T| | | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 Figure 13: Header Flags 1464 - ACK: ACK indicator (2 bit) 1465 The ACK indicator flag is only used by the CE when sending a 1466 Config Message (Section 7.6.1) or a HB message (Section 7.10) 1467 to indicate to the message receiver whether or not a response 1468 is required by the sender. Note that for all other messages 1469 than the Config Message or the HB Message this flag MUST be 1470 ignored. 1472 The flag values are defined as below: 1474 'NoACK' (0b00) - to indicate that the message receiver 1475 MUST NOT send any response message back to this message 1476 sender. 1478 'SuccessACK'(0b01) - to indicate the message receiver 1479 MUST send a response message back only when the message 1480 has been successfully processed by the receiver. 1482 'FailureACK'(0b10) - to indicate the message receiver 1483 MUST send a response message back only when there is 1484 failure by the receiver in processing (executing) the 1485 message. In other words, if the message can be processed 1486 successfully, the sender will not expect any response 1487 from the receiver. 1489 'AlwaysACK' (0b11) - to indicate the message receiver 1490 MUST send a response message. 1492 Note that in above definitions, the term success implies a 1493 complete execution without any failure of the message. 1494 Anything else than a complete successful execution is defined 1495 as a failure for the message processing. As a result, for 1496 the execution modes (defined in Section 4.3.1.1) like 1497 execute-all-or-none, execute-until-failure, and continue- 1498 execute-on-failure, if any single operation among several 1499 operations in the same message fails, it will be treated as a 1500 failure and result in a response if the ACK indicator has 1501 been set to 'FailureACK' or 'AlwaysACK'. 1503 Also note that, other than in Config and HB Messages, 1504 requirements for responses of messages are all given in a 1505 default way rather than by ACK flags. The default 1506 requirements of these messages and the expected responses are 1507 summarized below. Detailed descriptions can be found in the 1508 individual message definitions: 1510 + Association Setup Message always expects a response. 1512 + Association Teardown Message, and Packet Redirect 1513 Message, never expect responses. 1515 + Query Message always expects a response. 1517 + Response message never expects further responses. 1519 - Pri: Priority (3 bits) 1520 ForCES protocol defines 8 different levels of priority (0-7). 1521 The priority level can be used to distinguish between 1522 different protocol message types as well as between the same 1523 message type. The higher the priority value, the more 1524 important the PDU is. For example, the REDIRECT packet 1525 message could have different priorities to distinguish 1526 between routing protocols packets and ARP packets being 1527 redirected from FE to CE. The Normal priority level is 1. 1528 The different priorities imply messages could be re-ordered; 1529 however, re-ordering is undesirable when it comes to a set of 1530 messages within a transaction and caution should be exercised 1531 to avoid this from happening. 1533 - EM: Execution Mode (2 bits) 1534 There are 3 execution modes refer to Section 4.3.1.1 for 1535 details. 1537 Reserved..................... (0b00) 1539 `execute-all-or-none` ....... (0b01) 1541 `execute-until-failure` ..... (0b10) 1543 `continue-execute-on-failure` (0b11) 1545 - AT: Atomic Transaction (1 bit) 1546 This flag indicates if the message is stand-alone message or 1547 one of multiple messages that belongs to 2PC transaction 1548 operations. See Section 4.3.1.2.2 for details. 1550 Stand-alone message ......... (0b0) 1552 2PC transaction message ..... (0b1) 1554 - TP: Transaction Phase (2 bits) 1555 A message from the CE to the FE within a transaction could be 1556 indicative of the different phases the transaction is in. 1557 Refer to Section 4.3.1.2.2 for details. 1559 SOT (start of transaction) ..... (0b00) 1561 MOT (Middle of transaction) .... (0b01) 1563 EOT (end of transaction) ........(0b10) 1565 ABT (abort) .....................(0b11) 1567 6.2. Type Length Value (TLV) Structuring 1569 TLVs are extensively used by the ForCES protocol. TLVs have some 1570 very nice properties which make them a good candidate for encoding 1571 the XML definitions of the LFB class model. These are: 1573 o Providing for binary type-value encoding that is close to the XML 1574 string tag-value scheme. 1576 o Allowing for fast generalized binary-parsing functions. 1578 o Allowing for forward and backward tag compatibility. This is 1579 equivalent to the XML approach i.e old applications can ignore new 1580 TLVs and newer applications can ignore older TLVs. 1582 0 1 2 3 1583 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 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | TLV Type | TLV Length | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Value (Essentially the TLV Data) | 1588 ~ ~ 1589 ~ ~ 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 Figure 14: TLV Representation 1594 TLV Type (16): 1595 The TLV type field is two octets, and semantically 1596 indicates the type of data encapsulated within the 1597 TLV. 1599 TLV Length (16): 1600 The TLV length field is two octets, and includes the 1601 length of the TLV type (2 octets), TLV Length (2 1602 octets), and the length of the TLV data found in the 1603 value field, in octets. Note that this length is 1604 the actual length of the value, before any padding 1605 for alignment is added. 1607 TLV Value (variable): 1608 The TLV value field carries the data. For 1609 extensibility, the TLV value may in fact be a TLV. 1610 Padding is required when the length is not a 1611 multiple of 32 bits, and is the minimum number of 1612 bytes required to bring the TLV to a multiple of 32 1613 bits. The length of the value before padding is 1614 indicated by the TLV Length field. Note: The value 1615 field could be empty which implies the minimal 1616 length a TLV could be is 4 (length of "T" field and 1617 length of "L" field). 1619 6.2.1. Nested TLVs 1621 TLV values can be other TLVs. This provides the benefits of protocol 1622 flexibility (being able to add new extensions by introducing new TLVs 1623 when needed). The nesting feature also allows for a conceptual 1624 optimization with the XML LFB definitions to binary PL representation 1625 (represented by nested TLVs). 1627 6.2.2. Scope of the T in TLV 1629 The "Type" values in the TLV are global in scope. This means that 1630 wherever TLVs occur in the PDU, a specific Type value refers to the 1631 same Type of TLV. This is a design choice that was made to ease 1632 debugging of the protocol. 1634 6.3. ILV 1636 A slight variation of the TLV known as the ILV. This sets the type 1637 ("T") to be a 32-bit local index that refers to a ForCES component 1638 ID. (refer to Section 6.4.1). The Length part of the ILV is fixed at 1639 32 bits. 1641 0 1 2 3 1642 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 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Identifier | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | Length | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 | Value | 1649 . . 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 Figure 15: ILV Representation 1654 It should be noted that the "I" values are of local scope and are 1655 defined by the data declarations from the LFB definition. Refer to 1656 Section 7.1.8 for discussions on usage of ILVs. 1658 6.4. Important Protocol encapsulations 1660 In this section, we review a few encapsulation concepts that are used 1661 by the ForCES protocol for its operations. 1663 We briefly re-introduce two concepts, Paths and Keys, from the model 1664 draft [FE-MODEL] in order to provide context. The reader is referred 1665 to [FE-MODEL] for a lot of the finer details. 1667 For readability reasons, we introduce the encapsulation schemes that 1668 are used to carry content in a protocol message, namely FULLDATA, 1669 SPARSEDATA, and RESULT TLVs. 1671 6.4.1. Paths 1673 The model draft [FE-MODEL] defines an XML-based language that allows 1674 for a formal definition of LFBs. This is similar to the relationship 1675 between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB 1676 and ASN.1 being analogous to the XML model language). Any entity 1677 that the CE configures on an FE MUST be formally defined in an LFB. 1678 These entities could be scalars (e.g., a 32-bit IPv4 address) or 1679 vectors (such as a nexthop table). Each entity within the LFB is 1680 given a numeric 32-bit identifier known as an "component id". This 1681 scheme allows the attribute to be "addressed" in a protocol 1682 construct. 1684 These addressable entities could be hierarchical (e.g., a table 1685 column or a cell within a table row). In order to address 1686 hierarchical data, the concept of a path is introduced by the model 1687 [FE-MODEL]. A path is a series of 32-bit component IDs which are 1688 typically presented in a dot-notation (e.g., 1.2.3.4). Section 1689 (Section 7) formally defines how paths are used to reference data 1690 that is being encapsulated within a protocol message. 1692 6.4.2. Keys 1694 The model draft [FE-MODEL] defines two ways to address table rows. 1695 The standard/common mechanism is to allow table rows to be referenced 1696 by a 32-bit index. The secondary mechanism is via Keys which allow 1697 for content addressing. An example key is a multi-field content key 1698 that uses the IP address and prefix length to uniquely reference an 1699 IPv4 routing table row. In essence, while the common scheme to 1700 address a table row is via its table index, a table row's path could 1701 be derived from a key. The KEYINFO TLV (Section 7) is used to carry 1702 the data that is used to do the lookup. 1704 6.4.3. DATA TLVs 1706 Data from or to the FE is carried in two types of TLVs: FULLDATA TLV 1707 and SPARSEDATA TLV. Responses on operations executed by the FE are 1708 carried in RESULT TLVs. 1710 In FULLDATA TLV, the data is encoded in such a way that a receiver of 1711 such data, by virtue of being armed with knowledge of the path and 1712 the LFB definition, can infer or correlate the TLV "Value" contents. 1713 This is essentially an optimization that helps reduce the amount of 1714 description required for the transported data in the protocol 1715 grammar. Refer to Appendix C for an example of FULLDATA TLVs. 1717 A number of operations in ForCES will need to reference optional data 1718 within larger structures. The SPARSEDATA TLV encoding is provided to 1719 make it easier to encapsulate optionally appearing data components. 1720 Refer to Appendix C for an example of SPARSEDATA TLV. 1722 RESULT TLVs carry responses back from the FE based on a config issued 1723 by the CE. Refer to Appendix C for examples of RESULT TLVs and 1724 Section 7.1.7 for layout. 1726 6.4.4. Addressing LFB entities 1728 Section 6.4.1 and Section 6.4.2 discuss how to target an entity 1729 within an LFB. However, the addressing mechanism used requires that 1730 an LFB type and instance is selected first. The LFB Selector is used 1731 to select an LFB type and instance being targeted. Section 1732 (Section 7) goes into more details; for our purpose, we illustrate 1733 this concept using Figure 16 below. More examples of layouts can be 1734 found reading further into the text (Example: Figure 21). 1736 main hdr (Message type: example "config") 1737 | 1738 | 1739 | 1740 +- T = LFBselect 1741 | 1742 +-- LFBCLASSID (unique per LFB defined) 1743 | 1744 | 1745 +-- LFBInstance (runtime configuration) 1746 | 1747 +-- T = An operation TLV describes what we do to an entity 1748 | //Refer to the OPER-TLV values enumerated below 1749 | //the TLVs that can be used for operations 1750 | 1751 | 1752 +--+-- one or more path encodings to target an entity 1753 | // Refer to the discussion on keys and paths 1754 | 1755 | 1756 +-- The associated data, if any, for the entity 1757 // Refer to discussion on FULL/SPARSE DATA TLVs 1759 Figure 16: Entity Addressing 1761 7. Protocol Construction 1763 A protocol layer PDU consists of a Common Header (defined in Section 1764 Section 6.1 ) and a message body. The Common Header is followed by a 1765 message-type-specific message body. Each message body is formed from 1766 one or more top-level TLVs. A top-level TLV may contain one or more 1767 sub-TLVs; these sub-TLVs are described in this document as OPER-TLVs, 1768 because they describe an operation to be done. 1770 +--------------+--------------+---------------------+---------------+ 1771 | Message Name | Top-Level | OPER-TLV(s) | Reference | 1772 | | TLV | | | 1773 +--------------+--------------+---------------------+---------------+ 1774 | Association | (LFBselect)* | REPORT | Section 7.5.2 | 1775 | Setup | | | | 1776 | | | | | 1777 | Association | ASRresult | none | Section 7.5.2 | 1778 | Setup | | | | 1779 | Response | | | | 1780 | | | | | 1781 | Association | ASTreason | none | Section 7.5.3 | 1782 | Teardown | | | | 1783 | | | | | 1784 | Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 | 1785 | | | DEL | COMMIT | | | 1786 | | | TRCOMP)+ | | 1787 | | | | | 1788 | Config | (LFBselect)+ | (SET-RESPONSE | | Section 7.6.2 | 1789 | Response | | SET-PROP-RESPONSE | | | 1790 | | | DEL-RESPONSE | | | 1791 | | | COMMIT-RESPONSE)+ | | 1792 | | | | | 1793 | Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 | 1794 | | | | | 1795 | Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 | 1796 | Response | | GET-PROP-RESPONSE)+ | | 1797 | | | | | 1798 | Event | LFBselect | REPORT | Section 7.8 | 1799 | Notification | | | | 1800 | | | | | 1801 | Packet | REDIRECT-TLV | none | Section 7.9 | 1802 | Redirect | | | | 1803 | | | | | 1804 | Heartbeat | none | none | Section 7.10 | 1805 +--------------+--------------+---------------------+---------------+ 1807 Table 1 1809 The different messages are illustrated in Table 1. The different 1810 message type numerical values are defined in Appendix A.1. All the 1811 TLVs values are defined in Appendix A.2. 1813 An LFBselect TLV (refer to Section 7.1.5) contains the LFB Classid 1814 and LFB Instance being referenced as well as the OPER-TLV(s) being 1815 applied to that reference. 1817 Each type of OPER-TLV is constrained as to how it describes the paths 1818 and selectors of interest. The following BNF describes the basic 1819 structure of an OPER-TLV and Table 2 gives the details for each type 1821 OPER-TLV := 1*PATH-DATA-TLV 1822 PATH-DATA-TLV := PATH [DATA] 1823 PATH := flags IDcount IDs [SELECTOR] 1824 SELECTOR := KEYINFO-TLV 1825 DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / 1826 1*PATH-DATA-TLV 1827 KEYINFO-TLV := KeyID FULLDATA-TLV 1828 FULLDATA-TLV := encoded data component which may nest 1829 further FULLDATA-TLVs 1830 SPARSEDATA-TLV := encoded data that may have optionally 1831 appearing components 1832 RESULT-TLV := Holds result code and optional FULLDATA-TLV 1834 Figure 17: BNF of OPER-TLV 1836 o PATH-DATA-TLV identifies the exact component targeted and may have 1837 zero or more paths associated with it. The last PATH-DATA-TLV in 1838 the case of nesting of paths via the DATA construct in the case of 1839 SET, SET-PROP requests and GET-RESPONSE/GET-PROP-RESPONSE is 1840 terminated by encoded data or response in the form of either 1841 FULLDATA-TLV or SPARSEDATA-TLV or RESULT TLV. 1843 o PATH provides the path to the data being referenced. 1845 * flags (16 bits) are used to further refine the operation to be 1846 applied on the Path. More on these later. 1848 * IDcount(16 bit): count of 32 bit IDs 1850 * IDs: zero or more 32bit IDs (whose count is given by IDcount) 1851 defining the main path. Depending on the flags, IDs could be 1852 field IDs only or a mix of field and dynamic IDs. Zero is used 1853 for the special case of using the entirety of the containing 1854 context as the result of the path. 1856 o SELECTOR is an optional construct that further defines the PATH. 1857 Currently, the only defined selector is the KEYINFO-TLV, used for 1858 selecting an array entry by the value of a key field. The 1859 presence of a SELECTOR is correct only when the flags also 1860 indicate its presence. A mismatch is a protocol format error. 1862 o A KEYINFO TLV contains information used in content keying. 1864 * A KeyID is used in a KEYINFO TLV. It indicates which key for 1865 the current array is being used as the content key for array 1866 entry selection. 1868 * The key's data is the data to look for in the array, in the 1869 fields identified by the key field. The information is encoded 1870 according to the rules for the contents of a FULLDATA-TLV, and 1871 represent the field or fields which make up the key identified 1872 by the KeyID. 1874 o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT TLV or 1 1875 or more further PATH-DATA selection. FULLDATA and SPARSEDATA are 1876 only allowed on SET or SET-PROP requests, or on responses which 1877 return content information (GET-RESPONSE for example). PATH-DATA 1878 may be included to extend the path on any request. 1880 * Note: Nested PATH-DATA TLVs are supported as an efficiency 1881 measure to permit common subexpression extraction. 1883 * FULLDATA and SPARSEDATA contain "the data" whose path has been 1884 selected by the PATH. Refer to Section 7.1 for details. 1886 * The following table summarizes the applicability and 1887 restrictions of the FULL/SPARSEDATA TLV and the RESULT TLV to 1888 the OPER-TLVs. 1890 +-------------------+-------------------------------+---------------+ 1891 | OPER-TLV | DATA TLV | RESULT TLV | 1892 +-------------------+-------------------------------+---------------+ 1893 | SET | (FULLDATA-TLV | | none | 1894 | | SPARSEDATA-TLV)+ | | 1895 | | | | 1896 | SET-PROP | (FULLDATA-TLV | | none | 1897 | | SPARSEDATA-TLV)+ | | 1898 | | | | 1899 | SET-RESPONSE | none | (RESULT-TLV)+ | 1900 | | | | 1901 | SET-PROP-RESPONSE | none | (RESULT-TLV)+ | 1902 | | | | 1903 | DEL | (FULLDATA-TLV | | none | 1904 | | SPARSEDATA-TLV)+ | | 1905 | | | | 1906 | DEL-RESPONSE | none | (RESULT-TLV)+ | 1907 | | | | 1908 | GET | none | none | 1909 | | | | 1910 | GET-PROP | none | none | 1911 | | | | 1912 | GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | 1913 | | | | 1914 | GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | 1915 | | | | 1916 | REPORT | (FULLDATA-TLV)+ | none | 1917 | | | | 1918 | COMMIT | none | none | 1919 | | | | 1920 | COMMIT-RESPONSE | none | (RESULT-TLV)+ | 1921 | | | | 1922 | TRCOMP | none | none | 1923 +-------------------+-------------------------------+---------------+ 1925 Table 2 1927 o RESULT contains the indication of whether the individual SET or 1928 SET-PROP succeeded. RESULT TLV is included on the assumption that 1929 individual parts of a SET request can succeed or fail separately. 1931 In summary this approach has the following characteristic: 1933 o There can be one or more LFB class ID and instance ID combination 1934 targeted in a message (batch) 1936 o There can one or more operations on an addressed LFB class ID/ 1937 instance ID combination (batch) 1939 o There can be one or more path targets per operation (batch) 1941 o Paths may have zero or more data values associated (flexibility 1942 and operation specific) 1944 It should be noted that the above is optimized for the case of a 1945 single LFB class ID and instance ID targeting. To target multiple 1946 instances within the same class, multiple LFBselects are needed. 1948 7.1. Discussion on encoding 1950 Section 6.4.3 discusses the two types of DATA encodings (FULLDATA and 1951 SPARSEDATA TLV) and the justifications for their existence. In this 1952 section we explain how they are encoded. 1954 7.1.1. Data Packing Rules 1956 The scheme for encoding data used in this doc adheres to the 1957 following rules: 1959 o The Value ("V" of TLV) of FULLDATA TLV will contain the data being 1960 transported. This data will be as was described in the LFB 1961 definition. 1963 o Variable sized data within a FULLDATA TLV will be encapsulated 1964 inside another FULLDATA TLV inside the V of the outer TLV. For 1965 example of such a setup refer to Appendix C and Appendix D 1967 o In the case of FULLDATA TLVs: 1969 * When a table is referred to in the PATH (IDs) of a PATH-DATA- 1970 TLV, then the FULLDATA's "V" will contain that table's row 1971 content prefixed by its 32 bit index/subscript. On the other 1972 hand, when PATH flags are 00, the PATH may contain an index 1973 pointing to a row in table; in such a case, the FULLDATA's "V" 1974 will only contain the content with the index in order to avoid 1975 ambiguity. 1977 7.1.2. Path Flags 1979 The following flags are currently defined: 1981 o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present 1982 following this path information, and should be considered in 1983 evaluating the path. 1985 7.1.3. Relation of operational flags with global message flags 1987 Global flags, such as the execution mode and the atomicity indicators 1988 defined in the header, apply to all operations in a message. Global 1989 flags provide semantics that are orthogonal to those provided by the 1990 operational flags, such as the flags defined in Path Data. The scope 1991 of operational flags is restricted to the operation. 1993 7.1.4. Content Path Selection 1995 The KEYINFO TLV describes the KEY as well as associated KEY data. 1996 KEYs, used for content searches, are restricted and described in the 1997 LFB definition. 1999 7.1.5. LFBselect-TLV 2001 The LFBselect TLV is an instance of a TLV as defined in Section 6.2. 2002 The definition is as below: 2004 0 1 2 3 2005 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 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | Type = LFBselect | Length | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | LFB Class ID | 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 | LFB Instance ID | 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 | OPER-TLV | 2014 . . 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 ~ ... ~ 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 | OPER-TLV | 2019 . . 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 Figure 18: PL PDU layout 2024 Type: 2025 The type of the TLV is "LFBselect" 2027 Length: 2028 Length of the TLV including the T and L fields, in octets. 2030 LFB Class ID: 2031 This field uniquely recognizes the LFB class/type. 2033 LFB Instance ID: 2034 This field uniquely identifies the LFB instance. 2036 OPER-TLV: 2037 It describes an operation nested in the LFBselect TLV. Note that 2038 usually there SHOULD be at least one OPER-TLV present for an LFB 2039 select TLV, but for the Association Setup Message defined in 2040 Section 7.5.1 where the OPER-TLV is optional. 2042 7.1.6. OPER-TLV 2044 The OPER-TLV is a place holder in the grammar for TLVs that define 2045 operations. The different types are defined in Table 3, below. 2047 +-------------------+--------+--------------------------------------+ 2048 | OPER-TLV | TLV | Comments | 2049 | | "Type" | | 2050 +-------------------+--------+--------------------------------------+ 2051 | SET | 0x0001 | From CE to FE. Used to create or add | 2052 | | | or update attributes | 2053 | | | | 2054 | SET-PROP | 0x0002 | From CE to FE. Used to create or add | 2055 | | | or update attribute properties | 2056 | | | | 2057 | SET-RESPONSE | 0x0003 | From FE to CE. Used to carry | 2058 | | | response of a SET | 2059 | | | | 2060 | SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry | 2061 | | | response of a SET-PROP | 2062 | | | | 2063 | DEL | 0x0005 | From CE to FE. Used to delete or | 2064 | | | remove an attribute | 2065 | | | | 2066 | DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry | 2067 | | | response of a DEL | 2068 | | | | 2069 | GET | 0x0007 | From CE to FE. Used to retrieve an | 2070 | | | attribute | 2071 | | | | 2072 | GET-PROP | 0x0008 | From CE to FE. Used to retrieve an | 2073 | | | attribute property | 2074 | | | | 2075 | GET-RESPONSE | 0x0009 | From FE to CE. Used to carry | 2076 | | | response of a GET | 2077 | | | | 2078 | GET-PROP-RESPONSE | 0x000A | From FE to CE. Used to carry | 2079 | | | response of a GET-PROP | 2080 | | | | 2081 | REPORT | 0x000B | From FE to CE. Used to carry an | 2082 | | | asynchronous event | 2083 | | | | 2084 | COMMIT | 0x000C | From CE to FE. Used to issue a | 2085 | | | commit in a 2PC transaction | 2086 | | | | 2087 | COMMIT-RESPONSE | 0x000D | From an FE to CE. Used to confirm a | 2088 | | | commit in a 2PC transaction | 2089 | | | | 2090 | TRCOMP | 0x000E | From CE to FE. Used to indicate | 2091 | | | NE-wide success of 2PC transaction | 2092 +-------------------+--------+--------------------------------------+ 2094 Table 3 2096 Different messages define OPER-TLV are valid and how they are used 2097 (refer to Table 1 and Table 2). 2099 SET, SET-PROP, and GET/GET-PROP requests are issued by the CE and do 2100 not carry RESULT TLVs. On the other hand, SET-RESPONSE, SET-PROP- 2101 RESPONSE and GET-RESPONSE/GET-PROP-RESPONSE carry RESULT TLVs. 2103 A GET-RESPONSE in response to a successful GET will have FULLDATA 2104 TLVs added to the leaf paths to carry the requested data. For GET 2105 operations that fail, instead of the FULLDATA TLV there will be a 2106 RESULT TLV. 2108 For a SET-RESPONSE/SET-PROP-RESPONSE, each FULLDATA or SPARSEDATA TLV 2109 in the original request will be replaced with a RESULT TLV in the 2110 response. If the request set the FailureACK flag, then only those 2111 items which failed will appear in the response. If the request was 2112 for AlwaysACK, then all components of the request will appear in the 2113 response with RESULT TLVs. 2115 Note that if a SET/SET-PROP request with a structure in a FULLDATA is 2116 issued, and some field in the structure is invalid, the FE will not 2117 attempt to indicate which field was invalid, but rather will indicate 2118 that the operation failed. Note further that if there are multiple 2119 errors in a single leaf PATH-DATA/FULLDATA, the FE can select which 2120 error it chooses to return. So if a FULLDATA for a SET/SET-PROP of a 2121 structure attempts to write one field which is read only, and 2122 attempts to set another field to an invalid value, the FE can return 2123 indication of either error. 2125 A SET/SET-PROP operation on a variable length component with a length 2126 of 0 for the item is not the same as deleting it. If the CE wishes 2127 to delete then the DEL operation should be used whether the path 2128 refers to an array component or an optional structure component. 2130 7.1.7. Result TLV 2132 The RESULT TLV is an instance of TLV defined in Section 6.2. The 2133 definition is as below: 2135 0 1 2 3 2136 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 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | Type = RESULT | Length | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | Result Value | Reserved | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 Figure 19: Result TLV 2144 Defined Result Values 2146 +-----------------------------+-----------+-------------------------+ 2147 | Result Value | Value | Definition | 2148 +-----------------------------+-----------+-------------------------+ 2149 | E_SUCCESS | 0x00 | Success | 2150 | | | | 2151 | E_INVALID_HEADER | 0x01 | Unspecified error with | 2152 | | | header. | 2153 | | | | 2154 | E_LENGTH_MISMATCH | 0x02 | Header length field | 2155 | | | does not match actual | 2156 | | | packet length. | 2157 | | | | 2158 | E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch | 2159 | | | in versions. | 2160 | | | | 2161 | E_INVALID_DESTINATION_PID | 0x04 | Destination PID is | 2162 | | | invalid for the message | 2163 | | | receiver. | 2164 | | | | 2165 | E_LFB_UNKNOWN | 0x05 | LFB Class ID is not | 2166 | | | known by receiver. | 2167 | | | | 2168 | E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known | 2169 | | | by receiver but not | 2170 | | | currently in use. | 2171 | | | | 2172 | E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known | 2173 | | | but the specified | 2174 | | | instance of that class | 2175 | | | does not exist. | 2176 | | | | 2177 | E_INVALID_PATH | 0x08 | The specified path is | 2178 | | | impossible. | 2179 | | | | 2180 | E_COMPONENT_DOES_NOT_EXIST | 0x09 | The specified path is | 2181 | | | possible but the | 2182 | | | component does not | 2183 | | | exist (e.g., attempt to | 2184 | | | modify a table row that | 2185 | | | has not been created). | 2186 | | | | 2187 | E_EXISTS | 0x0A | The specified object | 2188 | | | exists but it cannot | 2189 | | | exist for the operation | 2190 | | | to succeed (e.g., | 2191 | | | attempt to add an | 2192 | | | existing LFB instance | 2193 | | | or array subscript). | 2194 | | | | 2195 | E_NOT_FOUND | 0x0B | The specified object | 2196 | | | does not exist but it | 2197 | | | must exist for the | 2198 | | | operation to succeed | 2199 | | | (e.g., attempt to | 2200 | | | delete a non-existing | 2201 | | | LFB instance or array | 2202 | | | subscript). | 2203 | | | | 2204 | E_READ_ONLY | 0x0C | Attempt to modify a | 2205 | | | read-only value. | 2206 | | | | 2207 | E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an | 2208 | | | array with an unallowed | 2209 | | | subscript. | 2210 | | | | 2211 | E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a | 2212 | | | parameter to a value | 2213 | | | outside of its | 2214 | | | allowable range. | 2215 | | | | 2216 | E_CONTENTS_TOO_LONG | 0x0D | Attempt to write | 2217 | | | contents larger than | 2218 | | | the target object space | 2219 | | | (i.e., exceeding a | 2220 | | | buffer). | 2221 | | | | 2222 | E_INVALID_PARAMETERS | 0x10 | Any other error with | 2223 | | | data parameters. | 2224 | | | | 2225 | E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not | 2226 | | | acceptable. | 2227 | | | | 2228 | E_INVALID_FLAGS | 0x12 | Message flags are not | 2229 | | | acceptable for the | 2230 | | | given message type. | 2231 | | | | 2232 | E_INVALID_TLV | 0x13 | A TLV is not acceptable | 2233 | | | for the given message | 2234 | | | type. | 2235 | E_EVENT_ERROR | 0x14 | Unspecified error while | 2236 | | | handling an event. | 2237 | | | | 2238 | E_NOT_SUPPORTED | 0x15 | Attempt to perform a | 2239 | | | valid ForCES operation | 2240 | | | that is unsupported by | 2241 | | | the message receiver. | 2242 | | | | 2243 | E_MEMORY_ERROR | 0x16 | A memory error occurred | 2244 | | | while processing a | 2245 | | | message (no error | 2246 | | | detected in the message | 2247 | | | itself) | 2248 | | | | 2249 | E_INTERNAL_ERROR | 0x17 | An unspecified error | 2250 | | | occurred while | 2251 | | | processing a message | 2252 | | | (no error detected in | 2253 | | | the message itself) | 2254 | | | | 2255 | - | 0x18-0xFE | Reserved | 2256 | | | | 2257 | E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for | 2258 | | | when the FE can not | 2259 | | | decide what went wrong) | 2260 +-----------------------------+-----------+-------------------------+ 2262 Table 4 2264 7.1.8. DATA TLV 2266 A FULLDATA TLV has "T"= FULLDATA and a 16-bit Length followed by the 2267 data value/contents. Likewise, a SPARSEDATA TLV has "T" = 2268 SPARSEDATA, a 16-bit Length, followed by the data value/contents. In 2269 the case of the SPARSEDATA, each component in the Value part of the 2270 TLV will be further encapsulated in an ILV. 2272 Below are the encoding rules for the FULLDATA and SPARSEDATA TLVs. 2273 Appendix C is very useful in illustrating these rules: 2275 1. Both ILVs and TLVs MUST be 32 bit aligned. Any padding bits used 2276 for the alignment MUST be zero on transmission and MUST be 2277 ignored upon reception. 2279 2. FULLDATA TLVs may be used at a particular path only if every 2280 component at that path level is present. In example 1(c) of 2281 Appendix C this concept is illustrated by the presence of all 2282 components of the structure S in the FULLDATA TLV encoding. This 2283 requirement holds regardless of whether the fields are fixed or 2284 variable length, mandatory or optional. 2286 * If a FULLDATA TLV is used, the encoder MUST lay out data for 2287 each component in the same order in which the data was 2288 defined in the LFB specification. This ensures the decoder 2289 is able to retrieve the data. To use the example 1 again in 2290 Appendix C, this implies the encoder/decoder is assumed to 2291 have knowledge of how structure S is laid out in the 2292 definition. 2294 * In the case of a SPARSEDATA, it does not need to be ordered 2295 since the "I" in the ILV uniquely identifies the component. 2296 Examples 1(a) and 1(b) illustrate the power of SPARSEDATA 2297 encoding. 2299 3. Inside a FULLDATA TLV 2301 * The values for atomic, fixed-length fields are given without 2302 any TLV or ILV encapsulation. 2304 * The values for atomic, variable-length fields are given 2305 inside FULLDATA TLVs. 2307 4. Inside a SPARSEDATA TLV 2309 * The values for atomic fields may be given with ILVs (32-bit 2310 index, 32-bit length) 2312 5. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot 2313 contain a FULLDATA. This is because it is hard to disambiguate 2314 ILV since an I is 32 bits and a T is 16 bits. 2316 6. A FULLDATA can also contain a FULLDATA for variable sized 2317 components. The decoding disambiguation is assumed from rule #3 2318 above. 2320 7.1.9. SET and GET Relationship 2322 It is expected that a GET-RESPONSE would satisfy the following: 2324 o It would have exactly the same path definitions as those sent in 2325 the GET. The only difference being a GET-RESPONSE will contain 2326 FULLDATA TLVs. 2328 o It should be possible to take the same GET-RESPONSE and convert 2329 it to a SET successfully by merely changing the T in the 2330 operational TLV. 2332 o There are exceptions to this rule: 2334 1. When a KEY selector is used with a path in a GET operation, 2335 that selector is not returned in the GET-RESPONSE; instead 2336 the cooked result is returned. Refer to the examples using 2337 KEYS to see this. 2339 2. When dumping a whole table in a GET, the GET-RESPONSE that 2340 merely edits the T to be SET will end up overwriting the 2341 table. 2343 7.2. Protocol Encoding Visualization 2345 The figure below shows a general layout of the PL PDU. A main header 2346 is followed by one or more LFB selections each of which may contain 2347 one or more operation. 2349 main hdr (Config in this case) 2350 | 2351 | 2352 +--- T = LFBselect 2353 | | 2354 | +-- LFBCLASSID 2355 | | 2356 | | 2357 | +-- LFBInstance 2358 | | 2359 | +-- T = SET 2360 | | | 2361 | | +-- // one or more path targets 2362 | | // with their data here to be added 2363 | | 2364 | +-- T = DEL 2365 | . | 2366 | . +-- // one or more path targets to be deleted 2367 | 2368 | 2369 +--- T = LFBselect 2370 | | 2371 | +-- LFBCLASSID 2372 | | 2373 | | 2374 | +-- LFBInstance 2375 | | 2376 | + -- T= SET 2377 | | . 2378 | | . 2379 | + -- T= DEL 2380 | | . 2381 | | . 2382 | | 2383 | + -- T= SET 2384 | | . 2385 | | . 2386 | 2387 | 2388 +--- T = LFBselect 2389 | 2390 +-- LFBCLASSID 2391 | 2392 +-- LFBInstance 2393 . 2394 . 2395 . 2397 Figure 20: PL PDU logical layout 2399 The figure below shows a more detailed example of the general layout 2400 of the operation within a targeted LFB selection. The idea is to 2401 show the different nesting levels a path could take to get to the 2402 target path. 2404 T = SET 2405 | | 2406 | +- T = Path-data 2407 | | 2408 | + -- flags 2409 | + -- IDCount 2410 | + -- IDs 2411 | | 2412 | +- T = Path-data 2413 | | 2414 | + -- flags 2415 | + -- IDCount 2416 | + -- IDs 2417 | | 2418 | +- T = Path-data 2419 | | 2420 | + -- flags 2421 | + -- IDCount 2422 | + -- IDs 2423 | + -- T = KEYINFO 2424 | | + -- KEY_ID 2425 | | + -- KEY_DATA 2426 | | 2427 | + -- T = FULLDATA 2428 | + -- data 2429 | 2430 | 2431 T = SET 2432 | | 2433 | +- T = Path-data 2434 | | | 2435 | | + -- flags 2436 | | + -- IDCount 2437 | | + -- IDs 2438 | | | 2439 | | + -- T = FULLDATA 2440 | | + -- data 2441 | +- T = Path-data 2442 | | 2443 | + -- flags 2444 | + -- IDCount 2445 | + -- IDs 2446 | | 2447 | + -- T = FULLDATA 2448 | + -- data 2449 T = DEL 2450 | 2451 +- T = Path-data 2452 | 2453 + -- flags 2454 + -- IDCount 2455 + -- IDs 2456 | 2457 +- T = Path-data 2458 | 2459 + -- flags 2460 + -- IDCount 2461 + -- IDs 2462 | 2463 +- T = Path-data 2464 | 2465 + -- flags 2466 + -- IDCount 2467 + -- IDs 2468 + -- T = KEYINFO 2469 | + -- KEY_ID 2470 | + -- KEY_DATA 2471 +- T = Path-data 2472 | 2473 + -- flags 2474 + -- IDCount 2475 + -- IDs 2477 Figure 21: Sample operation layout 2479 Appendix D shows a more concise set of use-cases on how the data 2480 encoding is done. 2482 7.3. Core ForCES LFBs 2484 There are two LFBs that are used to control the operation of the 2485 ForCES protocol and to interact with FEs and CEs: 2487 o FE Protocol LFB 2488 o FE Object LFB 2490 Although these LFBs have the same form and interface as other LFBs, 2491 they are special in many respects. They have fixed well-known LFB 2492 Class and Instance IDs. They are statically defined (no dynamic 2493 instantiation allowed) and their status cannot be changed by the 2494 protocol: any operation to change the state of such LFBs (for 2495 instance, in order to disable the LFB) must result in an error. 2496 Moreover, these LFBs must exist before the first ForCES message can 2497 be sent or received. All attributes in these LFBs must have pre- 2498 defined default values. Finally, these LFBs do not have input or 2499 output ports and do not integrate into the intra-FE LFB topology. 2501 7.3.1. FE Protocol LFB 2503 The FE Protocol LFB is a logical entity in each FE that is used to 2504 control the ForCES protocol. The FE Protocol LFB Class ID is 2505 assigned the value 0x2. The FE Protocol LFB Instance ID is assigned 2506 the value 0x1. There MUST be one and only one instance of the FE 2507 Protocol LFB in an FE. The values of the attributes in the FE 2508 Protocol LFB have pre-defined default values that are specified here. 2509 Unless explicit changes are made to these values using Config 2510 messages from the CE, these default values MUST be used for correct 2511 operation of the protocol. 2513 The formal definition of the FE Protocol Object LFB can be found in 2514 Appendix B. 2516 7.3.1.1. FE Protocol capabilities 2518 FE Protocol capabilities are read-only. 2520 7.3.1.1.1. SupportableVersions 2522 ForCES protocol version(s) supported by the FE 2524 7.3.1.1.2. FE Protocol Attributes 2526 FE Protocol attributes (can be read and set). 2528 7.3.1.1.2.1. CurrentRunningVersion 2530 Current running version of the ForCES protocol 2532 7.3.1.1.2.2. FEID 2534 FE unicast ID 2536 7.3.1.1.2.3. MulticastFEIDs 2538 FE multicast ID(s) list - this is a list of multicast IDs that the FE 2539 belongs to. These IDs are configured by the CE. 2541 7.3.1.1.2.4. CEHBPolicy 2543 CE heartbeat policy - This policy, along with the parameter 'CE 2544 Heartbeat Dead Interval (CE HDI)' as described below defines the 2545 operating parameters for the FE to check the CE liveness. The policy 2546 values with meanings are listed as below: 2548 o 0 (default) - This policy specifies that the CE will send a 2549 Heartbeat Message to the FE(s) whenever the CE reaches a time 2550 interval within which no other PL messages were sent from the CE 2551 to the FE(s); refer to Section 4.3.3 and Section 7.10 for details. 2552 The CE HDI attribute as described below is tied to this policy. 2554 o 1 - The CE will not generate any HB messages. This actually means 2555 CE does not want the FE to check the CE liveness. 2557 o Others - reserved. 2559 7.3.1.1.2.5. CEHDI 2561 CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses 2562 to check the CE liveness. If FE has not received any messages from 2563 CE within this time interval, FE deduces lost connectivity which 2564 implies that the CE is dead or the association to the CE is lost. 2565 Default value 30 s. 2567 7.3.1.1.2.6. FEHBPolicy 2569 FE heartbeat policy - This policy, along with the parameter 'FE 2570 Heartbeat Interval (FE HI)', defines the operating parameters for how 2571 the FE should behave so that the CE can deduce its liveness. The 2572 policy values and the meanings are: 2574 o 0 (default) - The FE should not generate any Heartbeat messages. 2575 In this scenario, the CE is responsible for checking FE liveness 2576 by setting the PL header ACK flag of the message it sends to 2577 AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat 2578 Request Message. Refer to Section 7.10 and Section 4.3.3 for 2579 details. 2581 o 1 - This policy specifies that FE must actively send a Heartbeat 2582 Message if it reaches the time interval assigned by the FE HI as 2583 long as no other messages were sent from FE to CE during that 2584 interval as described in Section 4.3.3. 2586 o Others - Reserved. 2588 7.3.1.1.2.7. FEHI 2590 FE Heartbeat Interval (FE HI) - The time interval the FE should use 2591 to send HB as long as no other messages were sent from FE to CE 2592 during that interval as described in Section 4.3.3. The default 2593 value for an FE HI is 500ms. 2595 7.3.1.1.2.8. CEID 2597 Primary CEID - The CEID that the FE is associated with. 2599 7.3.1.1.2.9. LastCEID 2601 Last Primary CEID - The CEID of the last CE that that the FE 2602 associated with. This CE ID is reported to the new Primary CEID. 2604 7.3.1.1.2.10. BackupCEs 2606 The list of backup CEs an FE can use as backups. Refer to Section 8 2607 for details. 2609 7.3.1.1.2.11. CEFailoverPolicy 2611 CE failover policy - This specifies the behavior of the FE when the 2612 association with the CE is lost. There is a very tight relation 2613 between CE failover policy and Section 7.3.1.1.2.8, 2614 Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an 2615 association is lost, depending on configuration, one of the policies 2616 listed below is activated. 2618 o 0 (default) - FE should stop functioning immediately and 2619 transition to FE OperDisable. 2621 o 1 - The FE should continue running and do what it can even without 2622 an associated CE. This basically requires that the FE support CE 2623 Graceful restart (and defines such support in its capabilities). 2624 If the CEFTI expires before the FE re-associates with either the 2625 primary (Section 7.3.1.1.2.8) or one of possibly several backup 2626 CEs (Section 7.3.1.1.2.10), the FE will go operationally down. 2628 o Others - Reserved 2630 7.3.1.1.2.12. CEFTI 2632 CE Failover Timeout Interval (CEFTI) - The time interval associated 2633 with the CE failover policy case '0' and '2'. The default value is 2634 set to 300 seconds. Note that it is advisable to set the CEFTI value 2635 much higher than the CE Heartbeat Dead Interval (CE HDI) since the 2636 effect of expiring this parameter is devastating to the operation of 2637 the FE. 2639 7.3.1.1.2.13. FERestartPolicy 2641 FE restart policy - This specifies the behavior of the FE during an 2642 FE restart. The restart may be from an FE failure or other reasons 2643 that have made FE down and then need to restart. The values are 2644 defined as below: 2646 o 0(default)- Restart the FE from scratch. In this case, the FE 2647 should start from the pre-association phase. 2649 o others - Reserved for future use. 2651 7.3.2. FE Object LFB 2653 The FE Object LFB is a logical entity in each FE and contains 2654 attributes relative to the FE itself, and not to the operation of the 2655 ForCES protocol. 2657 The formal definition of the FE Object LFB can be found in 2658 [FE-MODEL]. The model captures the high level properties of the FE 2659 that the CE needs to know to begin working with the FE. The class ID 2660 for this LFB Class is also assigned in [FE-MODEL]. The singular 2661 instance of this class will always exist, and will always have 2662 instance ID 0x1 within its class. It is common, although not 2663 mandatory, for a CE to fetch much of the component and capability 2664 information from this LFB instance when the CE begins controlling the 2665 operation of the FE. 2667 7.4. Semantics of Message Direction 2669 Recall: The PL provides a master(CE)-Slave(FE) relationship. The 2670 LFBs reside at the FE and are controlled by CE. 2672 When messages go from the CE, the LFB Selector (Class and instance) 2673 refers to the destination LFB selection which resides in the FE. 2675 When messages go from the FE to the CE, the LFB Selector (Class and 2676 instance) refers to the source LFB selection which resides in the FE. 2678 7.5. Association Messages 2680 The ForCES Association messages are used to establish and teardown 2681 associations between FEs and CEs. 2683 7.5.1. Association Setup Message 2685 This message is sent by the FE to the CE to setup a ForCES 2686 association between them. 2688 Message transfer direction: 2689 FE to CE 2691 Message header: 2692 The Message Type in the header is set MessageType= 2693 'AssociationSetup'. The ACK flag in the header MUST be ignored, 2694 and the association setup message always expects to get a response 2695 from the message receiver (CE), whether the setup is successful or 2696 not. The correlator field in the header is set, so that FE can 2697 correlate the response coming back from the CE correctly. The FE 2698 may set the source ID to 0 in the header to request that the CE 2699 should assign an FE ID for the FE in the setup response message. 2701 Message body: 2702 The association setup message body optionally consists of zero, 2703 one or two LFBselect TLVs, as described in Section 7.1.5. The 2704 Association Setup message only operates on the FE Object and FE 2705 Protocol LFBs, therefore, the LFB class ID in the LFBselect TLV 2706 only points to these two kinds of LFBs. 2708 The OPER-TLV in the LFBselect TLV is defined as a 'REPORT' 2709 operation. More than one component may be announced in this 2710 message using REPORT operation to let the FE declare its 2711 configuration parameters in an unsolicited manner. These may 2712 contain components suggesting values such as the FE HB Interval, 2713 or the FEID. The OPER-TLV used is defined below. 2715 OPER-TLV for Association Setup: 2717 0 1 2 3 2718 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 2719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 | Type = REPORT | Length | 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 | PATH-DATA-TLV for REPORT | 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 Figure 22: OPER-TLV 2727 Type: 2728 Only one operation type is defined for the association setup 2729 message: 2731 Type = "REPORT" - this type of operation is for FE to 2732 report something to CE. 2734 PATH-DATA-TLV for REPORT: 2735 This is generically a PATH-DATA-TLV format that has been defined 2736 in section (Section 7) in the PATH-DATA BNF definition. The PATH- 2737 DATA-TLV for REPORT operation MAY contain FULLDATA-TLV(s) but 2738 SHALL NOT contain any RESULT TLV in the data format. The RESULT 2739 TLV is defined in Section 7.1.7 and the FULLDATA-TLV is defined in 2740 Section 7.1.8. 2742 To better illustrate the above PDU format, a tree structure for the 2743 format is shown below: 2745 main hdr (type = Association Setup) 2746 | 2747 | 2748 +--- T = LFBselect 2749 | | 2750 | +-- LFBCLASSID = FE object 2751 | | 2752 | | 2753 | +-- LFBInstance = 0x1 2754 | 2755 +--- T = LFBselect 2756 | 2757 +-- LFBCLASSID = FE Protocol object 2758 | 2759 | 2760 +-- LFBInstance = 0x1 2761 | 2762 +---OPER-TLV = REPORT 2763 | 2764 +-- Path-data to one or more components 2766 Figure 23: PDU Format For Association Setup Message 2768 7.5.2. Association Setup Response Message 2770 This message is sent by the CE to the FE in response to the Setup 2771 message. It indicates to the FE whether the setup is successful or 2772 not, i.e., whether an association is established. 2774 Message transfer direction: 2775 CE to FE 2777 Message Header: 2778 The Message Type in the header is set MessageType= 2779 'AssociationSetupResponse'. The ACK flag in the header MUST be 2780 ignored, and the setup response message never expects to get any 2781 more responses from the message receiver (FE). The destination 2782 ID in the header will be set to the source ID in the 2783 corresponding association setup message, unless that source ID 2784 was 0. If the corresponding source ID was 0, then the CE will 2785 assign an FE ID value and use that value for the destination ID. 2787 0 1 2 3 2788 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 2789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2790 | Type = ASRresult | Length | 2791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2792 | Association Setup Result | 2793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2795 Figure 24: ASResult OPER-TLV 2797 Type (16 bits): 2798 The type of the TLV is "ASResult". 2800 Length (16 bits): 2801 Length of the TLV including the T and L fields, in octets. 2803 Association Setup Result (32 bits): 2804 This indicates whether the setup msg was successful or whether 2805 the FE request was rejected by the CE. the defined values are: 2807 0 = success 2809 1 = FE ID invalid 2811 2 = permission denied 2813 To better illustrate the above PDU format, a tree structure for the 2814 format is shown below: 2816 main hdr (type = Association Setup Response) 2817 | 2818 | 2819 +--- T = ASResult 2821 Figure 25: PDU Format for Association Setup Repsonse Message 2823 7.5.3. Association Teardown Message 2825 This message can be sent by the FE or CE to any ForCES element to end 2826 its ForCES association with that element. 2828 Message transfer direction: 2829 CE to FE, or FE to CE (or CE to CE) 2831 Message Header: 2832 The Message Type in the header is set MessageType= 2833 "AssociationTeardown". The ACK flag MUST be ignored. The 2834 correlator field in the header MUST be set to zero and MUST be 2835 ignored by the receiver. 2837 0 1 2 3 2838 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 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 | Type = ASTreason | Length | 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 | Teardown Reason | 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2845 Figure 26: ASTreason TLV 2847 Type (16 bits): 2848 The type of the TLV is "ASTreason". 2850 Length (16 bits): 2851 Length of the TLV including the T and L fields, in octets. 2853 Teardown Reason (32 bits): 2854 This indicates the reason why the association is being 2855 terminated. Several reason codes are defined as follows. 2857 0 - normal teardown by administrator 2859 1 - error - loss of heartbeats 2861 2 - error - out of bandwidth 2863 3 - error - out of memory 2865 4 - error - application crash 2867 255 - error - other or unspecified 2869 To better illustrate the above PDU format, a tree structure for the 2870 format is shown below: 2872 main hdr (type = Association Teardown) 2873 | 2874 | 2875 +--- T = ASTreason 2877 Figure 27: PDU Format for Association Teardown Message 2879 7.6. Configuration Messages 2881 The ForCES Configuration messages are used by CE to configure the FEs 2882 in a ForCES NE and report the results back to the CE. 2884 7.6.1. Config Message 2886 This message is sent by the CE to the FE to configure LFB components 2887 in the FE. This message is also used by the CE to subscribe/ 2888 unsubscribe to LFB events. 2890 As usual, a config message is composed of a common header followed by 2891 a message body that consists of one or more TLV data format. 2892 Detailed description of the message is as below. 2894 Message transfer direction: 2895 CE to FE 2897 Message Header: 2898 The Message Type in the header is set MessageType= 'Config'. The 2899 ACK flag in the header can be set to any value defined in 2900 Section 6.1, to indicate whether or not a response from FE is 2901 expected by the message. 2903 OPER-TLV for Config: 2905 0 1 2 3 2906 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 2907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2908 | Type | Length | 2909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2910 | PATH-DATA-TLV | 2911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2913 Figure 28: OPER-TLV for Config 2915 Type: 2916 The operation type for config message. two types of operations 2917 for the config message are defined: 2919 Type = "SET" - this operation is to set LFB components 2921 Type = "SET-PROP" - this operation is to set LFB component 2922 properties 2923 Type = "DEL" - this operation to delete some LFB 2924 components 2926 Type = "COMMIT" - this operation is sent to the FE to 2927 commit in a 2pc transaction. A COMMIT TLV is an empty TLV 2928 i.e it has no "V"alue. In other words, There is a Length 2929 of 4 (which is for the header only). 2931 Type = "TRCOMP" - this operation is sent to the FE to mark 2932 the success from an NE perspective of a 2pc transaction. 2933 A TRCOMP TLV is an empty TLV i.e it has no "V"alue. In 2934 other words, There is a Length of 4 (which is for the 2935 header only). 2937 PATH-DATA-TLV: 2938 This is generically a PATH-DATA-TLV format that has been defined 2939 in section (Section 7) in the PATH-DATA BNF definition. The 2940 restriction on the use of PATH-DATA-TLV for SET/SET-PROP 2941 operation is that it MUST contain either a FULLDATA or SPARSEDATA 2942 TLV(s), but MUST NOT contain any RESULT TLV. The restriction on 2943 the use of PATH-DATA-TLV for DEL operation is it MAY contain 2944 FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain any RESULT 2945 TLV. The RESULT TLV is defined in Section 7.1.7 and FULLDATA and 2946 SPARSEDATA TLVs is defined in Section 7.1.8. 2948 *Note: For Event subscription, the events will be defined by the 2949 individual LFBs. 2951 To better illustrate the above PDU format, a tree structure for the 2952 format is shown below: 2954 main hdr (type = Config) 2955 | 2956 | 2957 +--- T = LFBselect 2958 . | 2959 . +-- LFBCLASSID = target LFB class 2960 . | 2961 | 2962 +-- LFBInstance = target LFB instance 2963 | 2964 | 2965 +-- T = operation { SET } 2966 | | 2967 | +-- // one or more path targets 2968 | // associated with FULL or SPARSEDATA TLV(s) 2969 | 2970 +-- T = operation { DEL } 2971 | | 2972 | +-- // one or more path targets 2973 | 2974 +-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV 2975 . 2976 . 2978 Figure 29: PDU Format for Configuration Message 2980 7.6.2. Config Response Message 2982 This message is sent by the FE to the CE in response to the Config 2983 message. It indicates whether the Config was successful or not on 2984 the FE and also gives a detailed response regarding the configuration 2985 result of each component. 2987 Message transfer direction: 2988 FE to CE 2990 Message Header: 2991 The Message Type in the header is set MessageType= 'Config 2992 Response'. The ACK flag in the header is always ignored, and the 2993 Config Response message never expects to get any further response 2994 from the message receiver (CE). 2996 OPER-TLV for Config Response: 2998 0 1 2 3 2999 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 3000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3001 | Type | Length | 3002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3003 | PATH-DATA-TLV | 3004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3006 Figure 30: OPER-TLV for Config Response 3008 Type: 3009 The operation type for Config Response message. Two types of 3010 operations for the Config Response message are defined: 3012 Type = "SET-RESPONSE" - this operation is for the response 3013 of SET operation of LFB components 3015 Type = "SET-PROP-RESPONSE" - this operation is for the 3016 response of SET-PROP operation of LFB component properties 3018 Type = "DEL-RESPONSE" - this operation is for the response 3019 of the DELETE operation of LFB components 3021 Type = "COMMIT-RESPONSE" - this operation is sent to the 3022 CE to confirm a commit success in a 2pc transaction. A 3023 COMMIT-RESPONSE TLV MUST contain a RESULT TLV indicating 3024 success or failure. 3026 PATH-DATA-TLV: 3027 This is generically a PATH-DATA-TLV format that has been defined 3028 in section (Section 7) in the PATH-DATA BNF definition. The 3029 restriction on the use of PATH-DATA-TLV for SET-RESPONSE 3030 operation is that it MUST contain RESULT TLV(s). The restriction 3031 on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also 3032 MUST contain RESULT TLV(s). The RESULT TLV is defined in 3033 Section 7.1.7. 3035 To better illustrate the above PDU format, a tree structure for the 3036 format is shown below: 3038 main hdr (type = ConfigResponse) 3039 | 3040 | 3041 +--- T = LFBselect 3042 . | 3043 . +-- LFBCLASSID = target LFB class 3044 . | 3045 | 3046 +-- LFBInstance = target LFB instance 3047 | 3048 | 3049 +-- T = operation { SET-RESPONSE } 3050 | | 3051 | +-- // one or more path targets 3052 | // associated with FULL or SPARSEDATA TLV(s) 3053 | 3054 +-- T = operation { DEL-RESPONSE } 3055 | | 3056 | +-- // one or more path targets 3057 | 3058 +-- T = operation { COMMIT-RESPONSE } 3059 | | 3060 | +-- RESULT 3062 Figure 31: PDU Format for Configuration Response message 3064 7.7. Query Messages 3066 The ForCES query messages are used by the CE to query LFBs in the FE 3067 for informations like LFB components, capabilities, statistics, etc. 3068 Query Messages include the Query Message and the Query Response 3069 Message. 3071 7.7.1. Query Message 3073 A Query message is composed of a common header and a message body 3074 that consists of one or more TLV data format. Detailed description 3075 of the message is as below. 3077 Message transfer direction: 3078 from CE to FE 3080 Message Header: 3081 The Message Type in the header is set to MessageType= 'Query'. 3082 The ACK flag in the header is always ignored, and a full response 3083 for a query message is always expected. The Correlator field in 3084 the header is set, so that the CE can locate the response back 3085 from FE correctly. 3087 OPER-TLV for Query: 3089 0 1 2 3 3090 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 3091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3092 | Type = GET/GET-PROP | Length | 3093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3094 | PATH-DATA-TLV for GET/GET-PROP | 3095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3097 Figure 32: TLV for Query 3099 Type: 3100 The operation type for query. Two operation types are defined: 3102 Type = "GET" - this operation is to request to get LFB 3103 components. 3105 Type = "GET-PROP" - this operation is to request to get 3106 LFB components. 3108 PATH-DATA-TLV for GET/GET-PROP: 3109 This is generically a PATH-DATA-TLV format that has been defined 3110 in section (Section 7) in the PATH-DATA BNF definition. The 3111 restriction on the use of PATH-DATA-TLV for GET/GET-PROP 3112 operation is it MUST NOT contain any SPARSEDATA or FULLDATA TLV 3113 and RESULT TLV in the data format. 3115 To better illustrate the above PDU format, a tree structure for the 3116 format is shown below: 3118 main hdr (type = Query) 3119 | 3120 | 3121 +--- T = LFBselect 3122 . | 3123 . +-- LFBCLASSID = target LFB class 3124 . | 3125 | 3126 +-- LFBInstance = target LFB instance 3127 | 3128 | 3129 +-- T = operation { GET } 3130 | | 3131 | +-- // one or more path targets 3132 | 3133 +-- T = operation { GET } 3134 . | 3135 . +-- // one or more path targets 3136 . 3138 Figure 33: PDU Format for Query Message 3140 7.7.2. Query Response Message 3142 When receiving a Query message, the receiver should process the 3143 message and come up with a query result. The receiver sends the 3144 query result back to the message sender by use of the Query Response 3145 Message. The query result can be the information being queried if 3146 the query operation is successful, or can also be error codes if the 3147 query operation fails, indicating the reasons for the failure. 3149 A Query Response message is also composed of a common header and a 3150 message body consisting of one or more TLVs describing the query 3151 result. Detailed description of the message is as below. 3153 Message transfer direction: 3154 from FE to CE 3156 Message Header: 3157 The Message Type in the header is set to MessageType= 3158 'QueryResponse'. The ACK flag in the header is ignored. As a 3159 response itself, the message does not expect a further response. 3161 OPER-TLV for Query Response: 3163 0 1 2 3 3164 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 3165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3166 |Type = GET-RESPONSE/GET-PROP-RESPONSE| Length | 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 | PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE | 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3171 Figure 34: TLV for Query Response 3173 Type: 3174 The operation type for query response. One operation type is 3175 defined: 3177 Type = "GET-RESPONSE" - this operation is to response to 3178 get operation of LFB components. 3180 Type = "GET-PROP-RESPONSE" - this operation is to response 3181 to GET-PROP operation of LFB components. 3183 PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE: 3184 This is generically a PATH-DATA-TLV format that has been defined 3185 in section (Section 7) in the PATH-DATA BNF definition. The 3186 PATH-DATA-TLV for GET-RESPONSE operation MAY contain SPARSEDATA 3187 TLV, FULLDATA TLV and/or RESULT TLV(s) in the data encoding. The 3188 RESULT TLV is defined in Section 7.1.7 and the SPARSEDATA and 3189 FULLDATA TLVs are defined in Section 7.1.8. 3191 To better illustrate the above PDU format, a tree structure for the 3192 format is shown below: 3194 main hdr (type = QueryResponse) 3195 | 3196 | 3197 +--- T = LFBselect 3198 . | 3199 . +-- LFBCLASSID = target LFB class 3200 . | 3201 | 3202 +-- LFBInstance = target LFB instance 3203 | 3204 | 3205 +-- T = operation { GET-RESPONSE } 3206 | | 3207 | +-- // one or more path targets 3208 | 3209 +-- T = operation { GET-PROP-RESPONSE } 3210 . | 3211 . +-- // one or more path targets 3212 . 3214 Figure 35: PDU Format for Query Response Message 3216 7.8. Event Notification Message 3218 Event Notification Message is used by FE to asynchronously notify CE 3219 of events that happen in the FE. 3221 All events that can be generated in an FE are subscribable by the CE. 3222 The CE can subscribe to an event via a Config message with SET-PROP 3223 operation, where the included path specifies the event, as defined by 3224 the LFB Library and described by the FE Model. 3226 As usual, an Event Notification Message is composed of a common 3227 header and a message body that consists of one or more TLV data 3228 format. Detailed description of the message is as below. 3230 Message Transfer Direction: 3231 FE to CE 3233 Message Header: 3234 The Message Type in the message header is set to 3235 MessageType = 'EventNotification'. The ACK flag in the header 3236 MUST be ignored by the CE, and the event notification message does 3237 not expect any response from the receiver. 3239 OPER-TLV for Event Notification: 3241 0 1 2 3 3242 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 3243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3244 | Type = REPORT | Length | 3245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3246 | PATH-DATA-TLV for REPORT | 3247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 Figure 36: TLV for Event Notification 3251 Type: 3252 Only one operation type is defined for the event notification 3253 message: 3255 Type = "REPORT" - this type of operation is for FE to 3256 report something to CE. 3258 PATH-DATA-TLV for REPORT: 3259 This is generically a PATH-DATA-TLV format that has been defined 3260 in section (Section 7) in the PATH-DATA BNF definition. The PATH- 3261 DATA-TLV for REPORT operation MAY contain FULLDATA or SPARSEDATA 3262 TLV(s) but MUST NOT contain any RESULT TLV in the data format. 3264 To better illustrate the above PDU format, a tree structure for the 3265 format is shown below: 3267 main hdr (type = Event Notification) 3268 | 3269 | 3270 +--- T = LFBselect 3271 | 3272 +-- LFBCLASSID = target LFB class 3273 | 3274 | 3275 +-- LFBInstance = target LFB instance 3276 | 3277 | 3278 +-- T = operation { REPORT } 3279 | | 3280 | +-- // one or more path targets 3281 | // associated with FULL/SPARSE DATA TLV(s) 3282 +-- T = operation { REPORT } 3283 . | 3284 . +-- // one or more path targets 3285 . // associated with FULL/SPARSE DATA TLV(s) 3287 Figure 37: PDU Format for Event Notification Message 3289 7.9. Packet Redirect Message 3291 A packet Redirect message is used to transfer data packets between CE 3292 and FE. Usually these data packets are control packets but they may 3293 be just data-path packets which need further (exception or high- 3294 touch) processing. It is also feasible that this message carries no 3295 data packets and rather just metadata. 3297 The Packet Redirect message data format is formated as follows: 3299 Message Direction: 3300 CE to FE or FE to CE 3302 Message Header: 3303 The Message Type in the header is set to MessageType= 3304 'PacketRedirect'. 3306 Message Body: 3307 This consists of one or more TLVs that contain or describe the 3308 packet being redirected. The TLV is specifically a Redirect TLV 3309 (with the TLV Type="Redirect"). Detailed data format of a 3310 Redirect TLV for packet redirect message is as below: 3312 0 1 2 3 3313 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 3314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3315 | Type = Redirect | Length | 3316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3317 | Meta Data TLV | 3318 . . 3319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3320 | Redirect Data TLV | 3321 . . 3322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3324 Figure 38: Redirect_Data TLV 3326 Meta Data TLV: 3327 This is a TLV that specifies meta-data associated with followed 3328 redirected data. The TLV is as follows: 3330 0 1 2 3 3331 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 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 | Type = METADATA | Length | 3334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3335 | Meta Data ILV | 3336 . . 3337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3338 ~ ... ~ 3339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3340 | Meta Data ILV | 3341 . . 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3344 Figure 39: METADATA TLV 3346 Meta Data ILV: 3347 This is an Identifier-Length-Value format that is used to describe 3348 one meta data. The ILV has the format as: 3350 0 1 2 3 3351 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 3352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3353 | Meta Data ID | 3354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3355 | Length | 3356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3357 | Meta Data Value | 3358 . . 3359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3361 Figure 40: Meta Data ILV 3363 Where, Meta Data ID is an identifier for the meta data, which is 3364 statically assigned by the LFB definition. 3366 Redirect Data TLV 3367 This is a TLV describing one packet of data to be directed via the 3368 redirect operation. The TLV format is as follows: 3370 0 1 2 3 3371 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 3372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3373 | Type = REDIRECTDATA | Length | 3374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3375 | Redirected Data | 3376 . . 3377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3379 Figure 41: Redirect Data TLV 3381 Redirected Data: 3382 This field contains the packet that is to be redirected in network 3383 byte order. The packet should be 32-bits aligned as is the data 3384 for all TLVs. The metadata infers what kind of packet is carried 3385 in value field and therefore allows for easy decoding of data 3386 encapsulated 3388 To better illustrate the above PDU format, a tree structure for the 3389 format is shown below: 3391 main hdr (type = PacketRedirect) 3392 | 3393 | 3394 +--- T = Redirect 3395 . | 3396 . +-- T = METADATA 3397 | | 3398 | +-- Meta Data ILV 3399 | | 3400 | +-- Meta Data ILV 3401 | . 3402 | . 3403 | 3404 +-- T = REDIRECTDATA 3405 | 3406 +-- // Redirected Data 3408 Figure 42: PDU Format for Packet Redirect Message 3410 7.10. Heartbeat Message 3412 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 3413 to asynchronously notify one or more other ForCES elements in the 3414 same ForCES NE on its liveness. Section 4.3.3 describes the traffic- 3415 sensitive approach used. 3417 A Heartbeat Message is sent by a ForCES element periodically. The 3418 parameterization and policy definition for heartbeats for an FE is 3419 managed as components of the FE Protocol Object LFB, and can be set 3420 by CE via a Config message. The Heartbeat message is a little 3421 different from other protocol messages in that it is only composed of 3422 a common header, with the message body left empty. A detailed 3423 description of the message is as below. 3425 Message Transfer Direction: 3426 FE to CE or CE to FE 3428 Message Header: 3429 The Message Type in the message header is set to MessageType = 3430 'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. 3431 The ACK flag in the header MUST be set to either 'NoACK' or 3432 'AlwaysACK' when the HB is sent. 3434 * When set to 'NoACK', the HB is not soliciting for a response. 3436 * When set to 'AlwaysACK', the HB Message sender is always 3437 expecting a response from its receiver. According the HB 3438 policies defined in Section 7.3.1, only the CE can send such 3439 an HB message to query FE liveness. For simplicity and 3440 because of the minimal nature of the HB message, the response 3441 to a HB message is another HB message, i.e., no specific HB 3442 response message is defined. Whenever an FE receives a HB 3443 message marked with 'AlwaysACK' from the CE, the FE MUST send 3444 a HB message back immediately. The HB message sent by the FE 3445 in response to the 'AlwasyACK' MUST modify the source and 3446 destination IDs so that the ID of the FE is the source ID and 3447 the CE ID of the sender is the destination ID, and MUST 3448 change the ACK information to 'NoACK'. A CE MUST NOT respond 3449 to an HB message with 'AlwasyACK' set. 3451 * When set to anything else other than 'NoACK' or 'AlwaysACK', 3452 the HB Message is treated as if it was a 'NoACK'. 3454 The correlator field in the HB message header SHOULD be set 3455 accordingly when a response is expected so that a receiver can 3456 correlate the response correctly. The correlator field MAY be 3457 ignored if no response is expected. 3459 Message Body: 3460 The message body is empty for the Heartbeat Message. 3462 8. High Availability Support 3464 The ForCES protocol provides mechanisms for CE redundancy and 3465 failover, in order to support High Availability as defined in 3466 [RFC3654]. FE redundancy and FE to FE interaction is currently out 3467 of scope of this document. There can be multiple redundant CEs and 3468 FEs in a ForCES NE. However, at any one time only one primary CE can 3469 control the FEs though there can be multiple secondary CEs. The FE 3470 and the CE PL are aware of the primary and secondary CEs. This 3471 information (primary, secondary CEs) is configured in the FE and in 3472 the CE PLs during pre-association by the FEM and the CEM 3473 respectively. Only the primary CE sends control messages to the FEs. 3475 8.1. Relation with the FE Protocol 3477 High Availability parameterization in an FE is driven by configuring 3478 the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1). 3479 The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE 3480 Heartbeat policy help in detecting connectivity problems between an 3481 FE and CE. The CE Failover policy defines the reaction on a detected 3482 failure. 3484 Figure 43 extends the state machine illustrated in Figure 4 to allow 3485 for new states that facilitate connection recovery. 3487 (CE issues Teardown || +-----------------+ 3488 Lost association) && | Pre-Association | 3489 CE failover policy = 0 | (Association | 3490 +------------>-->-->| in +<----+ 3491 | | progress) | | 3492 | CE Issues +--------+--------+ | 3493 | Association | | CFTI 3494 | Setup V | timer 3495 | ___________________+ | expires 3496 | | | 3497 | V ^ 3498 +-+-----------+ +-------+-----+ 3499 | | | Not | 3500 | | (CE issues Teardown || | Associated | 3501 | | Lost association) && | | 3502 | Associated | CE Failover Policy = 1 | (May | 3503 | | | Continue | 3504 | |---------->------->------>| Forwarding)| 3505 | | | | 3506 +-------------+ +-------------+ 3507 ^ V 3508 | | 3509 | CE Issues | 3510 | Association | 3511 | Setup | 3512 +_________________________________________+ 3514 Figure 43: FE State Machine considering HA 3516 Section 4.2 describes transitions between the Pre-association, 3517 associated and not associated states. 3519 When communication fails between the FE and CE (which can be caused 3520 by either the CE or link failure but not FE related), either the TML 3521 on the FE will trigger the FE PL regarding this failure or it will be 3522 detected using the HB messages between FEs and CEs. The 3523 communication failure, regardless of how it is detected, MUST be 3524 considered as a loss of association between the CE and corresponding 3525 FE. 3527 If the FE's FEPO CE Failover Policy is configured to mode 0 (the 3528 default), it will immediately transition to the pre-association 3529 phase. This means that if association is again established, all FE 3530 state will need to be re-established. 3532 If the FE's FEPO CE Failover Policy is configured to mode 1, it 3533 indicates that the FE is capable of HA restart recovery. In such a 3534 case, the FE transitions to the not associated state and the CEFTI 3535 timer is started. The FE MAY continue to forward packets during this 3536 state. It MAY also recycle through any configured secondary CEs in a 3537 round-robin fashion. It first adds its primary CE to the tail of 3538 backup CEs and sets its primary CE to be the first secondary. It 3539 then attempts to associate with the CE designated as the new primary 3540 CE. If it fails to re-associate with any CE and the CEFTI expires, 3541 the FE then transitions to the Pre-association state. 3543 If the FE, while in the not associated state, manages to reconnect to 3544 a new primary CE before CEFTI expires it transitions to the 3545 Associated state. Once re-associated, the FE tries to recover any 3546 state that may have been lost during the not associated state. How 3547 the FE achieves re-synchronizes it state is out of scope for this 3548 document. 3550 Figure 44 below illustrates the Forces message sequences that the FE 3551 uses to recover the connection. 3553 FE CE Primary CE Secondary 3554 | | | 3555 | Asso Estb,Caps exchg | | 3556 1 |<--------------------->| | 3557 | | | 3558 | All msgs | | 3559 2 |<--------------------->| | 3560 | | | 3561 | | | 3562 | FAILURE | 3563 | | 3564 | Asso Estb,Caps exchange | 3565 3 |<------------------------------------------>| 3566 | | 3567 | Event Report (pri CE down) | 3568 4 |------------------------------------------->| 3569 | | 3570 | All Msgs | 3571 5 |<------------------------------------------>| 3573 Figure 44: CE Failover for Report Primary Mode 3575 A CE-to-CE synchronization protocol would be needed to support fast 3576 failover as well as to address some of the corner cases, however this 3577 will not be defined by the ForCES protocol as it is out of scope for 3578 this specification. 3580 An explicit message (a Config message setting Primary CE component in 3581 ForCES Protocol object) from the primary CE, can also be used to 3582 change the Primary CE for an FE during normal protocol operation. 3584 Also note that the FEs in a ForCES NE could also use a multicast CE 3585 ID, i.e., they could be associated with a group of CEs (this assumes 3586 the use of a CE-CE synchronization protocol, which is out of scope 3587 for this specification). In this case, the loss of association would 3588 mean that communication with the entire multicast group of CEs has 3589 been lost. The mechanisms described above will apply for this case 3590 as well during the loss of association. If, however, the secondary 3591 CE was also using the multicast CE ID that was lost, then the FE will 3592 need to form a new association using a different CE ID. If the 3593 capability exists, the FE MAY first attempt to form a new association 3594 with original primary CE using a different non multicast CE ID. 3596 8.2. Responsibilities for HA 3598 TML Level: 3600 1. The TML controls logical connection availability and failover. 3602 2. The TML also controls peer HA management. 3604 At this level, control of all lower layers, for example transport 3605 level (such as IP addresses, MAC addresses etc) and associated links 3606 going down are the role of the TML. 3608 PL Level: 3609 All other functionality, including configuring the HA behavior during 3610 setup, the CE IDs used to identify primary and secondary CEs, 3611 protocol messages used to report CE failure (Event Report), Heartbeat 3612 messages used to detect association failure, messages to change the 3613 primary CE (Config), and other HA related operations described 3614 before, are the PL responsibility. 3616 To put the two together, if a path to a primary CE is down, the TML 3617 would take care of failing over to a backup path, if one is 3618 available. If the CE is totally unreachable then the PL would be 3619 informed and it would take the appropriate actions described before. 3621 9. Security Considerations 3623 ForCES architecture identifies several levels of security in 3624 [RFC3746]. ForCES PL uses security services provided by the ForCES 3625 TML. The TML provides security services such as endpoint 3626 authentication service, message authentication service and 3627 confidentiality service. Endpoint authentication service is invoked 3628 at the time of the pre-association connection establishment phase and 3629 message authentication is performed whenever the FE or CE receives a 3630 packet from its peer. 3632 The following are the general security mechanisms that need to be in 3633 place for ForCES PL. 3635 o Security mechanisms are session controlled - that is, once the 3636 security is turned on depending upon the chosen security level (No 3637 Security, Authentication, Confidentiality), it will be in effect 3638 for the entire duration of the session. 3640 o An operator should configure the same security policies for both 3641 primary and backup FEs and CEs (if available). This will ensure 3642 uniform operations and avoid unnecessary complexity in policy 3643 configuration. 3645 9.1. No Security 3647 When "No security" is chosen for ForCES protocol communication, both 3648 endpoint authentication and message authentication service needs to 3649 be performed by ForCES PL. Both these mechanism are weak and do not 3650 involve cryptographic operation. An operator can choose "No 3651 Security" level when the ForCES protocol endpoints are within a 3652 single box, for example. 3654 In order to have interoperable and uniform implementation across 3655 various security levels, each CE and FE endpoint MUST implement this 3656 level. 3658 9.1.1. Endpoint Authentication 3660 Each CE and FE PL maintains a list of associations as part its of 3661 configuration. This is done via the CEM and FEM interfaces. An FE 3662 MUST connect to only those CEs that are configured via the FEM; 3663 similarly, a CE should accept the connection and establish 3664 associations for the FEs which are configured via the CEM. The CE 3665 should validate the FE identifier before accepting the connections 3666 during the pre-association phase. 3668 9.1.2. Message authentication 3670 When a CE or FE initiates a message, the receiving endpoint MUST 3671 validate the initiator of the message by checking the common header 3672 CE or FE identifiers. This will ensure proper protocol functioning. 3673 This extra processing step is recommend even when underlying provides 3674 TML layer security services exist. 3676 9.2. ForCES PL and TML security service 3678 This section is applicable if an operator wishes to use the TML 3679 security services. A ForCES TML MUST support one or more security 3680 services such as endpoint authentication service, message 3681 authentication service, and confidentiality service, as part of TML 3682 security layer functions. It is the responsibility of the operator 3683 to select an appropriate security service and configure security 3684 policies accordingly. The details of such configuration are outside 3685 the scope of the ForCES PL and are dependent on the type of transport 3686 protocol and the nature of the connection. 3688 All these configurations should be done prior to starting the CE and 3689 FE. 3691 When certificates-based authentication is being used at the TML, the 3692 certificate can use a ForCES-specific naming structure as certificate 3693 names and, accordingly, the security policies can be configured at 3694 the CE and FE. 3696 9.2.1. Endpoint authentication service 3698 When TML security services are enabled, the ForCES TML performs 3699 endpoint authentication. Security association is established between 3700 CE and FE and is transparent to the ForCES PL. 3702 9.2.2. Message authentication service 3704 This is a TML specific operation and is transparent to the ForCES PL. 3705 For details, refer to Section 5. 3707 9.2.3. Confidentiality service 3709 This is a TML specific operation and is transparent to the ForCES PL. 3710 For details, refer to Section 5. 3712 10. Acknowledgements 3714 The authors of this draft would like to acknowledge and thank the 3715 ForCES Working Group and especially the following: Furquan Ansari, 3716 Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M. 3717 Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel M. 3718 Halpern (who should probably be listed among the authors), Zsolt 3719 Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, 3720 T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their 3721 contributions. We would also like to thank David Putzolu, and 3722 Patrick Droz for their comments and suggestions on the protocol and 3723 for their infinite patience. We would also like to thank Sue Hares 3724 and Alia Atlas for extensive reviews of the document. 3726 Alia Atlas has done a wonderful job of shaping the draft to make it 3727 more readable by providing the IESG feedback. 3729 The editors have used the xml2rfc [RFC2629] tools in creating this 3730 document and are very grateful for the existence and quality of these 3731 tools. The editor is also grateful to Elwyn Davies for his help in 3732 correcting the XML source of this document. 3734 11. References 3736 11.1. Normative References 3738 [FE-MODEL] 3739 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., 3740 and S. Blake, "ForCES Forwarding Element Model", 3741 Feb. 2005. 3743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3744 Requirement Levels", BCP 14, RFC 2119, March 1997. 3746 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3747 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3748 May 2008. 3750 11.2. Informational References 3752 [2PCREF] Gray, J., "Notes on database operating systems. In 3753 Operating Systems: An Advanced Course. Lecture Notes in 3754 Computer Science, Vol. 60, pp. 394-481, Springer-Verlag", 3755 1978. 3757 [ACID] Haerder, T. and A. Reuter, "Principles of Transaction- 3758 Orientated Database Recovery", 1983. 3760 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 3761 June 1999. 3763 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 3764 of IP Control and Forwarding", RFC 3654, November 2003. 3766 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 3767 "Forwarding and Control Element Separation (ForCES) 3768 Framework", RFC 3746, April 2004. 3770 Appendix A. IANA Considerations 3772 Following the policies outlined in "Guidelines for Writing an IANA 3773 Considerations Section in RFCs" (RFC 5226 [RFC5226]), the following 3774 name spaces are defined in ForCES. 3776 o Message Type Name Space Section 7 3778 o Operation Type Name Space Section 7.1.6 3780 o Header Flags Section 6.1 3782 o TLV Type Section 7 3784 o TLV Result Values Section 7.1.7 3786 o LFB Class ID Section 7.1.5 3788 o Result: Association Setup Response Section 7.5.2 3790 o Reason: Association Teardown Message Section 7.5.3 3792 A.1. Message Type Name Space 3794 The Message Type is an 8 bit value. The following is the guideline 3795 for defining the Message Type namespace 3797 Message Types 0x00 - 0x0F 3798 Message Types in this range are part of the base ForCES Protocol. 3799 Message Types in this range are allocated through an IETF 3800 consensus action. [RFC5226] 3802 Values assigned by this specification: 3804 0x00 Reserved 3805 0x01 AssociationSetup 3806 0x02 AssociationTeardown 3807 0x03 Config 3808 0x04 Query 3809 0x05 EventNotification 3810 0x06 PacketRedirect 3811 0x07 - 0x0E Reserved 3812 0x0F Hearbeat 3813 0x11 AssociationSetupRepsonse 3814 0x12 Reserved 3815 0x13 ConfigRepsonse 3816 0x14 QueryResponse 3818 Message Types 0x20 - 0x7F 3819 Message Types in this range are Specification Required [RFC5226] 3820 Message Types using this range must be documented in an RFC or 3821 other permanent and readily available reference. 3823 Message Types 0x80 - 0xFF 3824 Message Types in this range are reserved for vendor private 3825 extensions and are the responsibility of individual vendors. IANA 3826 management of this range of the Message Type Name Space is 3827 unnecessary. 3829 A.2. Operation Selection 3831 The Operation Selection (OPER-TLV) name space is 16 bits long. The 3832 following is the guideline for managing the OPER-TLV Name Space. 3834 OPER-TLV Type 0x0000-0x00FF 3835 OPER-TLV Types in this range are allocated through an IETF 3836 consensus process. [RFC5226]. 3838 Values assigned by this specification: 3840 0x0000 Reserved 3841 0x0001 SET 3842 0x0002 SET-PROP 3843 0x0003 SET-RESPONSE 3844 0x0004 SET-PROP-RESPONSE 3845 0x0005 DEL 3846 0x0006 DEL-RESPONSE 3847 0x0007 GET 3848 0x0008 GET-PROP 3849 0x0009 GET-RESPONSE 3850 0x000A GET-PROP-RESPONSE 3851 0x000B REPORT 3852 0x000C COMMIT 3853 0x000D COMMIT-RESPONSE 3854 0x000E TRCOMP 3856 OPER-TLV Type 0x0100-0x7FFF 3857 OPER-TLV Types using this range must be documented in an RFC or 3858 other permanent and readily available reference. [RFC5226]. 3860 OPER-TLV Type 0x8000-0xFFFF 3861 OPER-TLV Types in this range are reserved for vendor private 3862 extensions and are the responsibility of individual vendors. IANA 3863 management of this range of the OPER-TLV Type Name Space is 3864 unnecessary. 3866 A.3. Header Flags 3868 The Header flag field is 32 bits long. Header flags are part of 3869 the ForCES base protocol. Header flags are allocated through an 3870 IETF consensus action [RFC5226]. 3872 A.4. TLV Type Name Space 3874 The TLV Type name space is 16 bits long. The following is the 3875 guideline for managing the TLV Type Name Space. 3877 TLV Type 0x0000-0x00FF 3878 TLV Types in this range are allocated through an IETF consensus 3879 process. [RFC5226]. 3881 Values assigned by this specification: 3883 0x0000 Reserved 3884 0x0001 REDIRECT-TLV 3885 0x0010 ASResult-TLV 3886 0x0011 ASTreason-TLV 3887 0x1000 LFBselect-TLV 3888 0x0110 PATH-DATA-TLV 3889 0x0111 KEYINFO-TLV 3890 0x0112 FULLDATA-TLV 3891 0x0113 SPARSEDATA-TLV 3892 0x0114 RESULT-TLV 3893 0x0115 METADATA-TLV 3894 0x0116 REDIRECTDATA-TLV 3896 TLV Type 0x0200-0x7FFF 3897 TLV Types using this range must be documented in an RFC or other 3898 permanent and readily available reference [RFC5226]. 3900 TLV Type 0x8000-0xFFFF 3901 TLV Types in this range are reserved for vendor private extensions 3902 and are the responsibility of individual vendors. IANA management 3903 of this range of the TLV Type Name Space is unnecessary. 3905 A.5. Result-TLV Result Values 3907 The RESULT-TLV RTesult Value is an 8 bit value. 3909 0x00 E_SUCCESS 3910 0x01 E_INVALID_HEADER 3911 0x02 E_LENGTH_MISMATCH 3912 0x03 E_VERSION_MISMATCH 3913 0x04 E_INVALID_DESTINATION_PID 3914 0x05 E_LFB_UNKNOWN 3915 0x06 E_LFB_NOT_FOUND 3916 0x07 E_LFB_INSTANCE_ID_NOT_FOUND 3917 0x08 E_INVALID_PATH 3918 0x09 E_COMPONENT_DOES_NOT_EXIST 3919 0x0A E_EXISTS 3920 0x0B E_NOT_FOUND 3921 0x0C E_READ_ONLY 3922 0x0D E_INVALID_ARRAY_CREATION 3923 0x0E E_VALUE_OUT_OF_RANGE 3924 0x0F E_CONTENTS_TOO_LONG 3925 0x10 E_INVALID_PARAMETERS 3926 0x11 E_INVALID_MESSAGE_TYPE 3927 0x12 E_E_INVALID_FLAGS 3928 0x13 E_INVALID_TLV 3929 0x14 E_EVENT_ERROR 3930 0x15 E_NOT_SUPPORTED 3931 0x16 E_MEMORY_ERROR 3932 0x17 E_INTERNAL_ERROR 3933 0x18-0xFE Reserved 3934 0xFF E_UNSPECIFIED_ERROR 3936 All values not assigned in this specification are designated as 3937 Assignment by Expert review. 3939 A.6. Association Setup Response 3941 The Association Setup Response name space is 32 bits long. The 3942 following is the guideline for managing the Association Setup 3943 Response Name Space. 3945 Association Setup Response 0x0000-0x00FF 3946 Association Setup Responses in this range are allocated through an 3947 IETF consensus process [RFC5226]. 3949 Values assigned by this specification: 3951 0x0000 Success 3952 0x0001 FE ID Invalid 3953 0x0002 Permission Denied 3955 Association Setup Response 0x0100-0x0FFF 3956 Association Setup Responses in this range are Specification 3957 Required [RFC5226] Values using this range must be documented in 3958 an RFC or other permanent and readily available reference 3959 [RFC5226]. 3961 Association Setup Response 0x1000-0xFFFFFFFFF 3962 Association Setup Responses in this range are reserved for vendor 3963 private extensions and are the responsibility of individual 3964 vendors. IANA management of this range of the Association Setup 3965 Responses Name Space is unnecessary. 3967 A.7. Association Teardown Message 3969 The Association Teardown Message name space is 32 bits long. The 3970 following is the guideline for managing the Association Teardown 3971 Message Name Space. 3973 Association Teardown Message 0x00000000-0x0000FFFF 3974 Association Teardown Messages in this range are allocated through 3975 an IETF consensus process [RFC5226]. 3977 Values assigned by this specification: 3979 0x00000000 Normal - Teardown by Administrator 3980 0x00000001 Error - loss of heartbeats 3981 0x00000002 Error - loss of bandwidth 3982 0x00000003 Error - Out of Memory 3983 0x00000004 Error - Application Crash 3984 0x000000FF Error - Unspecified 3986 Association Teardown Message 0x00010000-0x7FFFFFFF 3987 Association Teardown Messages in this range are Specification 3988 Required [RFC5226] Association Teardown Messages using this range 3989 must be documented in an RFC or other permanent and readily 3990 available references. [RFC5226]. 3992 Association Teardown Message 0x80000000-0xFFFFFFFFF 3993 Association Teardown Messages in this range are reserved for 3994 vendor private extensions and are the responsibility of individual 3995 vendors. IANA management of this range of the Association 3996 Teardown Message Name Space is unnecessary. 3998 Appendix B. ForCES Protocol LFB schema 4000 The schema described below conforms to the LFB schema described in 4001 ForCES Model draft. [FE-MODEL] 4003 Section 7.3.1 describes the details of the different components 4004 defined in this definition. 4006 4009 4010 4011 4012 CEHBPolicyValues 4013 4014 The possible values of CE heartbeat policy 4015 4016 4017 uchar 4018 4019 4020 CEHBPolicy0 4021 4022 The CE heartbeat policy 0 4023 4024 4025 4026 CEHBPolicy1 4027 4028 The CE heartbeat policy 1 4029 4030 4031 4032 4033 4035 4036 FEHBPolicyValues 4037 4038 The possible values of FE heartbeat policy 4039 4040 4041 uchar 4042 4043 4044 FEHBPolicy0 4045 4046 The FE heartbeat policy 0 4047 4048 4049 4050 FEHBPolicy1 4051 4052 The FE heartbeat policy 1 4053 4054 4055 4056 4057 4059 4060 FERestartPolicyValues 4061 4062 The possible values of FE restart policy 4063 4064 4065 uchar 4066 4067 4068 FERestartPolicy0 4069 4070 The FE restart policy 0 4071 4072 4073 4074 4075 4077 4078 CEFailoverPolicyValues 4079 4080 The possible values of CE failover policy 4081 4082 4083 uchar 4084 4085 4086 CEFailoverPolicy0 4087 4088 The CE failover policy 0 4089 4090 4091 4092 CEFailoverPolicy1 4093 4094 The CE failover policy 1 4095 4096 4097 4098 4099 4101 4102 FEHACapab 4103 4104 The supported HA features 4105 4106 4107 uchar 4108 4109 4110 GracefullRestart 4111 4112 The FE supports Graceful Restart 4113 4114 4115 4116 HA 4117 4118 The FE supports HA 4119 4120 4121 4122 4123 4124 4126 4127 4128 FEPO 4129 4130 The FE Protocol Object 4131 4132 1.0 4134 4135 4136 CurrentRunningVersion 4137 Currently running ForCES version 4138 u8 4139 4140 4141 FEID 4142 Unicast FEID 4143 uint32 4144 4145 4146 MulticastFEIDs 4147 4148 the table of all multicast IDs 4149 4150 4151 uint32 4152 4153 4154 4155 CEHBPolicy 4156 4157 The CE Heartbeat Policy 4158 4159 CEHBPolicyValues 4160 4161 4162 CEHDI 4163 4164 The CE Heartbeat Dead Interval in millisecs 4165 4166 uint32 4167 4168 4169 FEHBPolicy 4170 4171 The FE Heartbeat Policy 4172 4173 FEHBPolicyValues 4174 4175 4176 FEHI 4177 4178 The FE Heartbeat Interval in millisecs 4179 4180 uint32 4181 4182 4183 CEID 4184 4185 The Primary CE this FE is associated with 4186 4187 uint32 4188 4189 4190 BackupCEs 4191 4192 The table of all backup CEs other than the primary 4193 4194 4195 uint32 4196 4197 4198 4199 CEFailoverPolicy 4200 4201 The CE Failover Policy 4202 4203 CEFailoverPolicyValues 4204 4206 4207 CEFTI 4208 4209 The CE Failover Timeout Interval in millisecs 4210 4211 uint32 4212 4213 4214 FERestartPolicy 4215 4216 The FE Restart Policy 4217 4218 FERestartPolicyValues 4219 4220 4221 LastCEID 4222 4223 The Primary CE this FE was last associated with 4224 4225 uint32 4226 4227 4229 4230 4231 SupportableVersions 4232 4233 the table of ForCES versions that FE supports 4234 4235 4236 u8 4238 4239 4240 4241 HACapabilities 4242 4243 the table of HA capabilities the FE supports 4244 4245 4246 FEHACapab 4247 4248 4249 4251 4252 4253 PrimaryCEDown 4254 4255 The pimary CE has changed 4256 4257 4258 LastCEID 4259 4260 4261 4262 4263 LastCEID 4264 4265 4266 4267 4269 4270 4271 4273 B.1. Capabilities 4275 Supportable Versions enumerates all ForCES versions that an FE 4276 supports. 4278 FEHACapab enumerates the HA capabilities of the FE. If the FE is not 4279 capable of Graceful restarts or HA, then it will not be able to 4280 participate in HA as described in Section 8.1 4282 B.2. Components 4284 All Components are explained in Section 7.3.1. 4286 Appendix C. Data Encoding Examples 4288 In this section a few examples of data encoding are discussed. these 4289 example, however, do not show any padding. 4291 ========== 4292 Example 1: 4293 ========== 4295 Structure with three fixed-lengthof, mandatory fields. 4297 struct S { 4298 uint16 a 4299 uint16 b 4300 uint16 c 4301 } 4303 (a) Describing all fields using SPARSEDATA 4305 Path-Data TLV 4306 Path to an instance of S ... 4307 SPARSEDATA TLV 4308 ComponentIDof(a), lengthof(a), valueof(a) 4309 ComponentIDof(b), lengthof(b), valueof(b) 4310 ComponentIDof(c), lengthof(c), valueof(c) 4312 (b) Describing a subset of fields 4314 Path-Data TLV 4315 Path to an instance of S ... 4316 SPARSEDATA TLV 4317 ComponentIDof(a), lengthof(a), valueof(a) 4318 ComponentIDof(c), lengthof(c), valueof(c) 4320 Note: Even though there are non-optional components in structure S, 4321 since one can uniquely identify components, one can selectively send 4322 component of structure S (eg in the case of an update from CE to FE). 4324 (c) Describing all fields using a FULLDATA TLV 4326 Path-Data TLV 4327 Path to an instance of S ... 4328 FULLDATA TLV 4329 valueof(a) 4330 valueof(b) 4331 valueof(c) 4333 ========== 4334 Example 2: 4335 ========== 4337 Structure with three fixed-lengthof fields, one mandatory, two 4338 optional. 4340 struct T { 4341 uint16 a 4342 uint16 b (optional) 4343 uint16 c (optional) 4344 } 4346 This example is identical to Example 1, as illustrated below. 4348 (a) Describing all fields using SPARSEDATA 4350 Path-Data TLV 4351 Path to an instance of S ... 4352 SPARSEDATA TLV 4353 ComponentIDof(a), lengthof(a), valueof(a) 4354 ComponentIDof(b), lengthof(b), valueof(b) 4355 ComponentIDof(c), lengthof(c), valueof(c) 4357 (b) Describing a subset of fields using SPARSEDATA 4359 Path-Data TLV 4360 Path to an instance of S ... 4361 SPARSEDATA TLV 4362 ComponentIDof(a), lengthof(a), valueof(a) 4363 ComponentIDof(c), lengthof(c), valueof(c) 4365 (c) Describing all fields using a FULLDATA TLV 4367 Path-Data TLV 4368 Path to an instance of S ... 4369 FULLDATA TLV 4370 valueof(a) 4371 valueof(b) 4372 valueof(c) 4374 Note: FULLDATA TLV _cannot_ be used unless all fields are being 4375 described. 4377 ========== 4378 Example 3: 4379 ========== 4380 Structure with a mix of fixed-lengthof and variable-lengthof fields, 4381 some mandatory, some optional. Note in this case, b is variable 4382 sized 4384 struct U { 4385 uint16 a 4386 string b (optional) 4387 uint16 c (optional) 4388 } 4390 (a) Describing all fields using SPARSEDATA 4392 Path to an instance of U ... 4393 SPARSEDATA TLV 4394 ComponentIDof(a), lengthof(a), valueof(a) 4395 ComponentIDof(b), lengthof(b), valueof(b) 4396 ComponentIDof(c), lengthof(c), valueof(c) 4398 (b) Describing a subset of fields using SPARSEDATA 4400 Path to an instance of U ... 4401 SPARSEDATA TLV 4402 ComponentIDof(a), lengthof(a), valueof(a) 4403 ComponentIDof(c), lengthof(c), valueof(c) 4405 (c) Describing all fields using FULLDATA TLV 4407 Path to an instance of U ... 4408 FULLDATA TLV 4409 valueof(a) 4410 FULLDATA TLV 4411 valueof(b) 4412 valueof(c) 4414 Note: The variable-length field requires the addition of a FULLDATA 4415 TLV within the outer FULLDATA TLV as in the case of component b 4416 above. 4418 ========== 4419 Example 4: 4420 ========== 4422 Structure containing an array of another structure type. 4424 struct V { 4425 uint32 x 4426 uint32 y 4427 struct U z[] 4428 } 4430 (a) Encoding using SPARSEDATA, with two instances of z[], also 4431 described with SPARSEDATA, assuming only the 10th and 15th subscript 4432 of z[] are encoded. 4434 path to instance of V ... 4435 SPARSEDATA TLV 4436 ComponentIDof(x), lengthof(x), valueof(x) 4437 ComponentIDof(y), lengthof(y), valueof(y) 4438 ComponentIDof(z), lengthof(all below) 4439 ComponentID = 10 (i.e index 10 from z[]), lengthof(all below) 4440 ComponentIDof(a), lengthof(a), valueof(a) 4441 ComponentIDof(b), lengthof(b), valueof(b) 4442 ComponentID = 15 (index 15 from z[]), lengthof(all below) 4443 ComponentIDof(a), lengthof(a), valueof(a) 4444 ComponentIDof(c), lengthof(c), valueof(c) 4446 Note the holes in the components of z (10 followed by 15). Also note 4447 the gap in index 15 with only components a and c appearing but not b. 4449 Appendix D. Use Cases 4451 Assume LFB with following components for the following use cases. 4453 foo1, type u32, ID = 1 4455 foo2, type u32, ID = 2 4457 table1: type array, ID = 3 4458 components are: 4459 t1, type u32, ID = 1 4460 t2, type u32, ID = 2 // index into table 2 4461 KEY: nhkey, ID = 1, V = t2 4463 table2: type array, ID = 4 4464 components are: 4465 j1, type u32, ID = 1 4466 j2, type u32, ID = 2 4467 KEY: akey, ID = 1, V = { j1,j2 } 4469 table3: type array, ID = 5 4470 components are: 4471 someid, type u32, ID = 1 4472 name, type string variable sized, ID = 2 4474 table4: type array, ID = 6 4475 components are: 4476 j1, type u32, ID = 1 4477 j2, type u32, ID = 2 4478 j3, type u32, ID = 3 4479 j4, type u32, ID = 4 4480 KEY: mykey, ID = 1, V = { j1} 4482 table5: type array, ID = 7 4483 components are: 4484 p1, type u32, ID = 1 4485 p2, type array, ID = 2, array components of type-X 4487 Type-X: 4488 x1, ID 1, type u32 4489 x2, ID2 , type u32 4490 KEY: tkey, ID = 1, V = { x1} 4492 All examples will use valueof(x) to indicate the value of the 4493 referenced component x. In the case where F_SEL** are missing (bits 4494 equal to 00) then the flags will not show any selection. 4496 All the examples only show use of FULLDATA for data encoding; 4497 although SPARSEDATA would make more sense in certain occasions, the 4498 emphasis is on showing the message layout. Refer to Appendix C for 4499 examples that show usage of both FULLDATA and SPARSEDATA. 4501 1. To get foo1 4503 OPER = GET-TLV 4504 Path-data TLV: IDCount = 1, IDs = 1 4505 Result: 4506 OPER = GET-RESPONSE-TLV 4507 Path-data-TLV: 4508 flags=0, IDCount = 1, IDs = 1 4509 FULLDATA-TLV L = 4+4, V = valueof(foo1) 4511 2. To set foo2 to 10 4513 OPER = SET-TLV 4514 Path-data-TLV: 4515 flags = 0, IDCount = 1, IDs = 2 4516 FULLDATA TLV: L = 4+4, V=10 4518 Result: 4519 OPER = SET-RESPONSE-TLV 4520 Path-data-TLV: 4521 flags = 0, IDCount = 1, IDs = 2 4522 RESULT-TLV 4524 3. To dump table2 4526 OPER = GET-TLV 4527 Path-data-TLV: 4528 IDCount = 1, IDs = 4 4529 Result: 4530 OPER = GET-RESPONSE-TLV 4531 Path-data-TLV: 4532 flags = 0, IDCount = 1, IDs = 4 4533 FULLDATA=TLV: L = XXX, V= 4534 a series of: index, valueof(j1), valueof(j2) 4535 representing the entire table 4537 Note: One should be able to take a GET-RESPONSE-TLV and 4538 convert it to a SET-TLV. If the result in the above example 4539 is sent back in a SET-TLV, (instead of a GET-RESPONSE_TLV) 4540 then the entire contents of the table will be replaced at 4541 that point. 4543 4. Multiple operations Example. To create entry 0-5 of table2 4544 (Error conditions are ignored) 4546 OPER = SET-TLV 4547 Path-data-TLV: 4548 flags = 0 , IDCount = 1, IDs=4 4549 PATH-DATA-TLV 4550 flags = 0, IDCount = 1, IDs = 0 4551 FULLDATA-TLV valueof(j1), valueof(j2) of entry 0 4552 PATH-DATA-TLV 4553 flags = 0, IDCount = 1, IDs = 1 4554 FULLDATA-TLV valueof(j1), valueof(j2) of entry 1 4555 PATH-DATA-TLV 4556 flags = 0, IDCount = 1, IDs = 2 4557 FULLDATA-TLV valueof(j1), valueof(j2) of entry 2 4558 PATH-DATA-TLV 4559 flags = 0, IDCount = 1, IDs = 3 4560 FULLDATA-TLV valueof(j1), valueof(j2) of entry 3 4561 PATH-DATA-TLV 4562 flags = 0, IDCount = 1, IDs = 4 4563 FULLDATA-TLV valueof(j1), valueof(j2) of entry 4 4564 PATH-DATA-TLV 4565 flags = 0, IDCount = 1, IDs = 5 4566 FULLDATA-TLV valueof(j1), valueof(j2) of entry 5 4568 Result: 4569 OPER = SET-RESPONSE-TLV 4570 Path-data-TLV: 4571 flags = 0 , IDCount = 1, IDs=4 4572 PATH-DATA-TLV 4573 flags = 0, IDCount = 1, IDs = 0 4574 RESULT-TLV 4575 PATH-DATA-TLV 4576 flags = 0, IDCount = 1, IDs = 1 4577 RESULT-TLV 4578 PATH-DATA-TLV 4579 flags = 0, IDCount = 1, IDs = 2 4580 RESULT-TLV 4581 PATH-DATA-TLV 4582 flags = 0, IDCount = 1, IDs = 3 4583 RESULT-TLV 4584 PATH-DATA-TLV 4585 flags = 0, IDCount = 1, IDs = 4 4586 RESULT-TLV 4587 PATH-DATA-TLV 4588 flags = 0, IDCount = 1, IDs = 5 4589 RESULT-TLV 4591 5. Block operations (with holes) example. Replace entry 0,2 of 4592 table2 4594 OPER = SET-TLV 4595 Path-data TLV: 4596 flags = 0 , IDCount = 1, IDs=4 4597 PATH-DATA-TLV 4598 flags = 0, IDCount = 1, IDs = 0 4599 FULLDATA-TLV containing valueof(j1), valueof(j2) of 0 4600 PATH-DATA-TLV 4601 flags = 0, IDCount = 1, IDs = 2 4602 FULLDATA-TLV containing valueof(j1), valueof(j2) of 2 4604 Result: 4605 OPER = SET-TLV 4606 Path-data TLV: 4607 flags = 0 , IDCount = 1, IDs=4 4608 PATH-DATA-TLV 4609 flags = 0, IDCount = 1, IDs = 0 4610 RESULT-TLV 4611 PATH-DATA-TLV 4612 flags = 0, IDCount = 1, IDs = 2 4613 RESULT-TLV 4615 6. Getting rows example. Get first entry of table2. 4617 OPER = GET-TLV 4618 Path-data TLV: 4619 IDCount = 2, IDs=4.0 4621 Result: 4622 OPER = GET-RESPONSE-TLV 4623 Path-data TLV: 4624 IDCount = 2, IDs=4.0 4625 FULLDATA-TLV containing valueof(j1), valueof(j2) 4627 7. Get entry 0-5 of table2. 4629 OPER = GET-TLV 4630 Path-data-TLV: 4631 flags = 0, IDCount = 1, IDs=4 4632 PATH-DATA-TLV 4633 flags = 0, IDCount = 1, IDs = 0 4634 PATH-DATA-TLV 4635 flags = 0, IDCount = 1, IDs = 1 4636 PATH-DATA-TLV 4637 flags = 0, IDCount = 1, IDs = 2 4638 PATH-DATA-TLV 4639 flags = 0, IDCount = 1, IDs = 3 4640 PATH-DATA-TLV 4641 flags = 0, IDCount = 1, IDs = 4 4642 PATH-DATA-TLV 4643 flags = 0, IDCount = 1, IDs = 5 4645 Result: 4646 OPER = GET-RESPONSE-TLV 4647 Path-data-TLV: 4648 flags = 0, IDCount = 1, IDs=4 4649 PATH-DATA-TLV 4650 flags = 0, IDCount = 1, IDs = 0 4651 FULLDATA-TLV containing valueof(j1), valueof(j2) 4652 PATH-DATA-TLV 4653 flags = 0, IDCount = 1, IDs = 1 4654 FULLDATA-TLV containing valueof(j1), valueof(j2) 4655 PATH-DATA-TLV 4656 flags = 0, IDCount = 1, IDs = 2 4657 FULLDATA-TLV containing valueof(j1), valueof(j2) 4658 PATH-DATA-TLV 4659 flags = 0, IDCount = 1, IDs = 3 4660 FULLDATA-TLV containing valueof(j1), valueof(j2) 4661 PATH-DATA-TLV 4662 flags = 0, IDCount = 1, IDs = 4 4663 FULLDATA-TLV containing valueof(j1), valueof(j2) 4664 PATH-DATA-TLV 4665 flags = 0, IDCount = 1, IDs = 5 4666 FULLDATA-TLV containing valueof(j1), valueof(j2) 4668 8. Create a row in table2, index 5. 4670 OPER = SET-TLV 4671 Path-data-TLV: 4672 flags = 0, IDCount = 2, IDs=4.5 4673 FULLDATA-TLV containing valueof(j1), valueof(j2) 4675 Result: 4676 OPER = SET-RESPONSE-TLV 4677 Path-data TLV: 4678 flags = 0, IDCount = 1, IDs=4.5 4679 RESULT-TLV 4681 9. Dump contents of table1. 4683 OPER = GET-TLV 4684 Path-data TLV: 4685 flags = 0, IDCount = 1, IDs=3 4687 Result: 4688 OPER = GET-RESPONSE-TLV 4689 Path-data TLV 4690 flags = 0, IDCount = 1, IDs=3 4691 FULLDATA TLV, Length = XXXX 4692 (depending on size of table1) 4693 index, valueof(t1),valueof(t2) 4694 index, valueof(t1),valueof(t2) 4695 . 4696 . 4697 . 4699 10. Using Keys. Get row entry from table4 where j1=100. Recall, j1 4700 is a defined key for this table and its KeyID is 1. 4702 OPER = GET-TLV 4703 Path-data-TLV: 4704 flags = F_SELKEY IDCount = 1, IDs=6 4705 KEYINFO-TLV = KeyID=1, KEY_DATA=100 4707 Result: 4708 If j1=100 was at index 10 4709 OPER = GET-RESPONSE-TLV 4710 Path-data TLV: 4711 flags = 0, IDCount = 1, IDs=6.10 4712 FULLDATA-TLV containing 4713 valueof(j1), valueof(j2),valueof(j3),valueof(j4) 4715 11. Delete row with KEY match (j1=100, j2=200) in table 2. Note 4716 that the j1,j2 pair are a defined key for the table 2. 4718 OPER = DEL-TLV 4719 Path-data TLV: 4720 flags = F_SELKEY IDCount = 1, IDs=4 4721 KEYINFO TLV: {KeyID =1 KEY_DATA=100,200} 4723 Result: 4724 If (j1=100, j2=200) was at entry 15: 4725 OPER = DELETE-RESPONSE-TLV 4726 Path-data TLV: 4727 flags = 0 IDCount = 2, IDs=4.15 4728 RESULT-TLV 4730 12. Dump contents of table3. It should be noted that this table has 4731 a column with component name that is variable sized. The 4732 purpose of this use case is to show how such an component is to 4733 be encoded. 4735 OPER = GET-TLV 4736 Path-data-TLV: 4737 flags = 0 IDCount = 1, IDs=5 4739 Result: 4740 OPER = GET-RESPONSE-TLV 4741 Path-data TLV: 4742 flags = 0 IDCount = 1, IDs=5 4743 FULLDATA TLV, Length = XXXX 4744 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4745 V = valueof(v) 4746 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4747 V = valueof(v) 4748 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4749 V = valueof(v) 4750 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4751 V = valueof(v) 4752 . 4753 . 4754 . 4756 13. Multiple atomic operations. 4758 Note 1: This emulates adding a new nexthop entry and then 4759 atomically updating the L3 entries pointing to an old NH to 4760 point to a new one. The assumption is both tables are in the 4761 same LFB 4763 Note2: Observe the two operations on the LFB instance, both 4764 are SET operations. 4766 //Operation 1: Add a new entry to table2 index #20. 4767 OPER = SET-TLV 4768 Path-TLV: 4769 flags = 0, IDCount = 2, IDs=4.20 4770 FULLDATA TLV, V= valueof(j1),valueof(j2) 4772 // Operation 2: Update table1 entry which 4773 // was pointing with t2 = 10 to now point to 20 4774 OPER = SET-TLV 4775 Path-data-TLV: 4776 flags = F_SELKEY, IDCount = 1, IDs=3 4777 KEYINFO = KeyID=1 KEY_DATA=10 4778 Path-data-TLV 4779 flags = 0 IDCount = 1, IDs=2 4780 FULLDATA TLV, V= 20 4782 Result: 4783 //first operation, SET 4784 OPER = SET-RESPONSE-TLV 4785 Path-data-TLV 4786 flags = 0 IDCount = 3, IDs=4.20 4787 RESULT-TLV code = success 4788 FULLDATA TLV, V = valueof(j1),valueof(j2) 4789 // second operation SET - assuming entry 16 was updated 4790 OPER = SET-RESPONSE-TLV 4791 Path-data TLV 4792 flags = 0 IDCount = 2, IDs=3.16 4793 Path-Data TLV 4794 flags = 0 IDCount = 1, IDs = 2 4795 SET-RESULT-TLV code = success 4796 FULLDATA TLV, Length = XXXX v=20 4798 14. Selective setting. On table 4 -- for indices 1, 3, 5, 7, and 9. 4799 Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. 4801 PER = SET-TLV 4802 Path-data TLV 4803 flags = 0, IDCount = 1, IDs = 6 4804 Path-data TLV 4805 flags = 0, IDCount = 1, IDs = 1 4806 Path-data TLV 4807 flags = 0, IDCount = 1, IDs = 1 4808 FULLDATA TLV, Length = XXXX, V = {100} 4809 Path-data TLV 4810 flags = 0, IDCount = 1, IDs = 2 4811 FULLDATA TLV, Length = XXXX, V = {200} 4812 Path-data TLV 4813 flags = 0, IDCount = 1, IDs = 3 4814 FULLDATA TLV, Length = XXXX, V = {300} 4815 Path-data TLV 4816 flags = 0, IDCount = 1, IDs = 3 4817 Path-data TLV 4818 flags = 0, IDCount = 1, IDs = 1 4819 FULLDATA TLV, Length = XXXX, V = {100} 4820 Path-data TLV 4821 flags = 0, IDCount = 1, IDs = 2 4822 FULLDATA TLV, Length = XXXX, V = {200} 4823 Path-data TLV 4824 flags = 0, IDCount = 1, IDs = 3 4825 FULLDATA TLV, Length = XXXX, V = {300} 4826 Path-data TLV 4827 flags = 0, IDCount = 1, IDs = 5 4828 Path-data TLV 4829 flags = 0, IDCount = 1, IDs = 1 4830 FULLDATA TLV, Length = XXXX, V = {100} 4831 Path-data TLV 4832 flags = 0, IDCount = 1, IDs = 2 4833 FULLDATA TLV, Length = XXXX, V = {200} 4834 Path-data TLV 4835 flags = 0, IDCount = 1, IDs = 3 4836 FULLDATA TLV, Length = XXXX, V = {300} 4837 Path-data TLV 4838 flags = 0, IDCount = 1, IDs = 7 4839 Path-data TLV 4840 flags = 0, IDCount = 1, IDs = 1 4841 FULLDATA TLV, Length = XXXX, V = {100} 4842 Path-data TLV 4843 flags = 0, IDCount = 1, IDs = 2 4844 FULLDATA TLV, Length = XXXX, V = {200} 4845 Path-data TLV 4846 flags = 0, IDCount = 1, IDs = 3 4847 FULLDATA TLV, Length = XXXX, V = {300} 4848 Path-data TLV 4849 flags = 0, IDCount = 1, IDs = 9 4850 Path-data TLV 4851 flags = 0, IDCount = 1, IDs = 1 4852 FULLDATA TLV, Length = XXXX, V = {100} 4853 Path-data TLV 4854 flags = 0, IDCount = 1, IDs = 2 4855 FULLDATA TLV, Length = XXXX, V = {200} 4856 Path-data TLV 4857 flags = 0, IDCount = 1, IDs = 3 4858 FULLDATA TLV, Length = XXXX, V = {300} 4860 response: 4862 OPER = SET-RESPONSE-TLV 4863 Path-data TLV 4864 flags = 0, IDCount = 1, IDs = 6 4865 Path-data TLV 4866 flags = 0, IDCount = 1, IDs = 1 4867 Path-data TLV 4868 flags = 0, IDCount = 1, IDs = 1 4869 RESULT-TLV 4870 Path-data TLV 4871 flags = 0, IDCount = 1, IDs = 2 4872 RESULT-TLV 4873 Path-data TLV 4874 flags = 0, IDCount = 1, IDs = 3 4875 RESULT-TLV 4876 Path-data TLV 4877 flags = 0, IDCount = 1, IDs = 3 4878 Path-data TLV 4879 flags = 0, IDCount = 1, IDs = 1 4880 RESULT-TLV 4881 Path-data TLV 4882 flags = 0, IDCount = 1, IDs = 2 4883 RESULT-TLV 4884 Path-data TLV 4885 flags = 0, IDCount = 1, IDs = 3 4886 RESULT-TLV 4887 Path-data TLV 4888 flags = 0, IDCount = 1, IDs = 5 4889 Path-data TLV 4890 flags = 0, IDCount = 1, IDs = 1 4891 RESULT-TLV 4892 Path-data TLV 4893 flags = 0, IDCount = 1, IDs = 2 4894 RESULT-TLV 4895 Path-data TLV 4896 flags = 0, IDCount = 1, IDs = 3 4897 RESULT-TLV 4898 Path-data TLV 4899 flags = 0, IDCount = 1, IDs = 7 4900 Path-data TLV 4901 flags = 0, IDCount = 1, IDs = 1 4902 RESULT-TLV 4903 Path-data TLV 4904 flags = 0, IDCount = 1, IDs = 2 4905 RESULT-TLV 4906 Path-data TLV 4907 flags = 0, IDCount = 1, IDs = 3 4908 RESULT-TLV 4909 Path-data TLV 4910 flags = 0, IDCount = 1, IDs = 9 4911 Path-data TLV 4912 flags = 0, IDCount = 1, IDs = 1 4913 RESULT-TLV 4914 Path-data TLV 4915 flags = 0, IDCount = 1, IDs = 2 4916 RESULT-TLV 4917 Path-data TLV 4918 flags = 0, IDCount = 1, IDs = 3 4919 RESULT-TLV 4921 15. Manipulation of table of table examples. Get x1 from table10 4922 row with index 4, inside table5 entry 10 4924 operation = GET-TLV 4925 Path-data-TLV 4926 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4928 Results: 4929 operation = GET-RESPONSE-TLV 4930 Path-data-TLV 4931 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4932 FULLDATA TLV: L=XXXX, V = valueof(x1) 4934 16. From table5's row 10 table10, get X2s based on on the value of 4935 x1 equaling 10 (recall x1 is KeyID 1) 4937 operation = GET-TLV 4938 Path-data-TLV 4939 flag = F_SELKEY, IDCount=3, IDS = 7.10.2 4940 KEYINFO TLV, KeyID = 1, KEYDATA = 10 4941 Path-data TLV 4942 IDCount = 1, IDS = 2 //select x2 4944 Results: 4945 If x1=10 was at entry 11: 4946 operation = GET-RESPONSE-TLV 4947 Path-data-TLV 4948 flag = 0, IDCount=5, IDS = 7.10.2.11 4949 Path-data TLV 4950 flags = 0 IDCount = 1, IDS = 2 4951 FULLDATA TLV: L=XXXX, V = valueof(x2) 4953 17. Further example of manipulating a table of tables 4955 Consider table 6 which is defined as: 4956 table6: type array, ID = 8 4957 components are: 4958 p1, type u32, ID = 1 4959 p2, type array, ID = 2, array components of type type-A 4961 type-A: 4962 a1, type u32, ID 1, 4963 a2, type array ID2 ,array components of type type-B 4965 type-B: 4966 b1, type u32, ID 1 4967 b2, type u32, ID 2 4969 If for example one wanted to set by replacing: 4970 table6.10.p1 to 111 4971 table6.10.p2.20.a1 to 222 4972 table6.10.p2.20.a2.30.b1 to 333 4974 in one message and one operation. 4976 There are two ways to do this: 4977 a) using nesting 4978 b) using a flat path data 4980 A. Method using nesting 4981 in one message with a single operation 4983 operation = SET-TLV 4984 Path-data-TLV 4985 flags = 0 IDCount = 2, IDs=6.10 4986 Path-data-TLV 4987 flags = 0, IDCount = 1, IDs=1 4988 FULLDATA TLV: L=XXXX, 4989 V = {111} 4990 Path-data-TLV 4991 flags = 0 IDCount = 2, IDs=2.20 4992 Path-data-TLV 4993 flags = 0, IDCount = 1, IDs=1 4994 FULLDATA TLV: L=XXXX, 4995 V = {222} 4996 Path-data TLV : 4997 flags = 0, IDCount = 3, IDs=2.30.1 4998 FULLDATA TLV: L=XXXX, 4999 V = {333} 5000 Result: 5001 operation = SET-RESPONSE-TLV 5002 Path-data-TLV 5003 flags = 0 IDCount = 2, IDs=6.10 5004 Path-data-TLV 5005 flags = 0, IDCount = 1, IDs=1 5006 RESULT-TLV 5007 Path-data-TLV 5008 flags = 0 IDCount = 2, IDs=2.20 5009 Path-data-TLV 5010 flags = 0, IDCount = 1, IDs=1 5011 RESULT-TLV 5012 Path-data TLV : 5013 flags = 0, IDCount = 3, IDs=2.30.1 5014 RESULT-TLV 5016 B. Method using a flat path data in 5017 one message with a single operation 5019 operation = SET-TLV 5020 Path-data TLV : 5021 flags = 0, IDCount = 3, IDs=6.10.1 5022 FULLDATA TLV: L=XXXX, 5023 V = {111} 5024 Path-data TLV : 5025 flags = 0, IDCount = 5, IDs=6.10.1.20.1 5026 FULLDATA TLV: L=XXXX, 5027 V = {222} 5028 Path-data TLV : 5029 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 5030 FULLDATA TLV: L=XXXX, 5031 V = {333} 5032 Result: 5033 operation = SET-TLV 5034 Path-data TLV : 5035 flags = 0, IDCount = 3, IDs=6.10.1 5036 RESULT-TLV 5037 Path-data TLV : 5038 flags = 0, IDCount = 5, IDs=6.10.1.20.1 5039 RESULT-TLV 5040 Path-data TLV : 5041 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 5042 RESULT-TLV 5044 18. Get a whole LFB (all its components, etc.). 5046 For example: at startup a CE might well want the entire FE 5047 OBJECT LFB. So, in a request targeted at class 1, instance 5048 1, one might find: 5050 operation = GET-TLV 5051 Path-data-TLV 5052 flags = 0 IDCount = 0 5054 result: 5055 operation = GET-RESPONSE-TLV 5056 Path-data-TLV 5057 flags = 0 IDCount = 0 5058 FULLDATA encoding of the FE Object LFB 5060 Authors' Addresses 5062 Ligang Dong 5063 Zhejiang Gongshang University 5064 149 Jiaogong Road 5065 Hangzhou 310035 5066 P.R.China 5068 Phone: +86-571-88071024 5069 Email: donglg@mail.zjgsu.edu.cn 5071 Avri Doria 5072 Lulea University of Technology 5073 Rainbow Way 5074 Lulea SE-971 87 5075 Sweden 5077 Phone: +46 73 277 1788 5078 Email: avri@ltu.se 5080 Ram Gopal 5081 Nokia 5082 5, Wayside Road 5083 Burlington, MA 310035 5084 USA 5086 Phone: +1-781-993-3685 5087 Email: ram.gopal@nokia.com 5089 Robert Haas 5090 IBM 5091 Saumerstrasse 4 5092 8803 Ruschlikon 5093 Switzerland 5095 Phone: 5096 Email: rha@zurich.ibm.com 5097 Jamal Hadi Salim 5098 Znyx 5099 Ottawa, Ontario 5100 Canada 5102 Phone: 5103 Email: hadi@znyx.com 5105 Hormuzd M Khosravi 5106 Intel 5107 2111 NE 25th Avenue 5108 Hillsboro, OR 97124 5109 USA 5111 Phone: +1 503 264 0334 5112 Email: hormuzd.m.khosravi@intel.com 5114 Weiming Wang 5115 Zhejiang Gongshang University 5116 149 Jiaogong Road 5117 Hangzhou 310035 5118 P.R.China 5120 Phone: +86-571-88057712 5121 Email: wmwang@mail.zjgsu.edu.cn 5123 Full Copyright Statement 5125 Copyright (C) The IETF Trust (2008). 5127 This document is subject to the rights, licenses and restrictions 5128 contained in BCP 78, and except as set forth therein, the authors 5129 retain all their rights. 5131 This document and the information contained herein are provided on an 5132 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5133 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 5134 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 5135 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5136 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5137 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5139 Intellectual Property 5141 The IETF takes no position regarding the validity or scope of any 5142 Intellectual Property Rights or other rights that might be claimed to 5143 pertain to the implementation or use of the technology described in 5144 this document or the extent to which any license under such rights 5145 might or might not be available; nor does it represent that it has 5146 made any independent effort to identify any such rights. Information 5147 on the procedures with respect to rights in RFC documents can be 5148 found in BCP 78 and BCP 79. 5150 Copies of IPR disclosures made to the IETF Secretariat and any 5151 assurances of licenses to be made available, or the result of an 5152 attempt made to obtain a general license or permission for the use of 5153 such proprietary rights by implementers or users of this 5154 specification can be obtained from the IETF on-line IPR repository at 5155 http://www.ietf.org/ipr. 5157 The IETF invites any interested party to bring to its attention any 5158 copyrights, patents or patent applications, or other proprietary 5159 rights that may cover technology that may be required to implement 5160 this standard. Please address the information to the IETF at 5161 ietf-ipr@ietf.org. 5163 Acknowledgment 5165 Funding for the RFC Editor function is provided by the IETF 5166 Administrative Support Activity (IASA).